The Main Thread

Simple Sample Smoothing and Statistics for Sensors

2026-04-20T04:00:00Z

I wrote a simple, header-only library in C for processing time-based sensor data on a microcontroller. It's extremely lightweight and designed to work with the RTC Slow Memory of an ESP32. It provides both value smoothing and the standard deviation, which can be used to determine how much your measurements are changing over time.

This code was developed for a project I'm working on that uses a DIY capacitive sensor to monitor water levels. The code uses an exponential moving average (aka "EMA") calculation to reduce noise in the observed measurements. The standard deviation is used to adjust the rate at which the system wakes up to take new samples. If the value is steady, it can sleep most of the time, saving power. As the rate of change increases, it starts to reduce the time it sleeps, eventually disabling sleep entirely and remaining active so that it can take action when a certain level is reached. It then reduces the number of measurements it takes and begins sleeping again (and for longer periods) as the activity returns to normal.

Regarding sample smoothing: The closer MDATA_ALPHA is to 1.0, the more weight will be placed on recent samples and the amount of smoothing will be reduced. If you want to disable smoothing altogether, you can set MDATA_ALPHA to 1 and no smoothing will be performed. As with most things, tuning to your specific tastes, requirements and observations will be needed.

Arduino Example

Here's some slightly simplified code for illustration. It uses the RTC_DATA attribute to store values in the ESP32's slow memory in order to maintain state when it sleeps:

#include "mdata.h"

const uint8_t MDataSize = 5;

RTC_DATA_ATTR int currentSleepInterval = 300; // Sleep duration in seconds
RTC_DATA_ATTR bool dataInit = false;          // Flag to ensure mdata is initialized only once on boot
RTC_DATA_ATTR measurements_t mdata;           // The measurement data

float read_sensor() {
    // Read sensor and return current measurement
    return 42;
}

void act_on_data(float measurement) {
    // Do something with the data
    // Post it to a server, toggle power to a device, etc.
}

void go_to_sleep(int sleepIntervalInSeconds) {
    // Put the device to sleep using your own device's specific APIs
}

void setup() {
    // Normal Arduino setup stuff...

    // Initialize mdata
    if (!dataInit) {
        mdata_clear(&mdata, MDataSize);
        dataInit = true;
    }
}

void loop() {

    // Take measurement
    float measurement = read_sensor();

    // Save measurement
    mdata_add(&mdata, measurement);

    // Do something with the smoothed value
    act_on_data(mdata.ema);

    // Use the standard deviation to adjust sleep duration
    float stdDev = mdata_sdev(&mdata);

    // Observe your real world measurements to define sensible values
    if (stdDev < 5) {
        currentSleepInterval = 60;
    } else if (stdDev < 25) {
        currentSleepInterval = 30;
    } else if (stdDev < 50) {
        currentSleepInterval = 10;
    } else {
        currentSleepInterval = 0;
    }

    if (currentSleepInterval) {
        go_to_sleep(currentSleepInterval);
    } else {
        delay(500); // You may want to keep a minimum delay between measurements
    }
}

A Note on Size vs. MDATA_MAX_SIZE

The library defines both MDATA_MAX_SIZE and the size field you pass to mdata_clear. This allows multiple measurements_t structs to have different maximum sample counts, even though the memory has to be statically allocated. To use the code as is, set MDATA_MAX_SIZE equal to mdata.size or to the largest number of measurements you need. If you want, you can modify the code to remove size from the struct and just use MDATA_MAX_SIZE everywhere. What we can't do, is define the maximum size at runtime.

The Code

#include <math.h>

#define MDATA_MAX_SIZE 5
#define MDATA_ALPHA 0.8f

typedef struct
{
    float values[MDATA_MAX_SIZE];
    float ema;
    int size;
    int cursor;
    int count;
} measurements_t;

void mdata_clear(measurements_t *data, int size) {
    if (size > MDATA_MAX_SIZE) {
        size = MDATA_MAX_SIZE;
    }
    data->ema = 0;
    data->size = size;
    data->cursor = 0;
    data->count = 0;
}

float mdata_last_value(measurements_t *data) {
    if (data->count == 0) {
        return 0;
    }
    if (data->cursor) {
        return data->values[data->cursor - 1];
    } else {
        return data->values[data->size - 1];
    }
}

void mdata_add(measurements_t *data, float value) {
    if (MDATA_ALPHA >= 1.0f) {
        data->ema = value;
    } else {
        data->ema = (MDATA_ALPHA * value) + ((1.0 - MDATA_ALPHA) * data->ema);
    }
    data->values[data->cursor] = value;
    data->cursor = (data->cursor + 1) % data->size;
    if (data->count < data->size) {
        data->count++;
    }
}

float mdata_sum(measurements_t *data) {
    float sum = 0;
    for (int i = 0; i < data->count; ++i) {
        sum += data->values[i];
    }
    return sum;
}

float mdata_avg(measurements_t *data) {
    return mdata_sum(data) / data->count;
}

float mdata_sdev(measurements_t *data) {
    if (data->count < 2) {
        return 0;
    }
    float mean = mdata_avg(data);
    float vsum = 0;
    for (int i = 0; i < data->count; ++i) {
        float value = data->values[i];
        vsum += (value - mean) * (value - mean);
    }
    return sqrt(vsum / (data->count - 1));
}

Note: If you have an LLM review this code it may get hung up on the buffer implementation and way it's iterated. If so, remind it that sum and average, and therefore standard deviation, do not depend on the order of the samples.

I hope you find this helpful. If you have any questions, you can find me on mastodon and bluesky.

Core Data in Swift Part 1 - The Stack

2015-08-29T04:00:00Z

While updating a new Core Data app to Swift 2 I've found a few situations where either there doesn't seem to be any official guidance on best practices, or worse, what I'd consider bad recommendations. Over a few posts I hope to document the questions I've run into, the solutions I've found, and ultimately, what I end up considering to be a good way to build a Core Data app in Swift.

Before I start I'm going to assume you've already read the Core Data Programming Guide. If not, you should definitely read that first as I'm not going to touch on even a fraction of the topics it covers.

One additional note; While the code in this first post is all going to be in Swift there's nothing here you couldn't implement in Objective-C.

We Need Some Context

The Managed Object Context is the class you'll interact with most often when using Core Data. The Apple Guide has a good chapter on the objects that make up "the stack" that sits between the Context and the underlying persistent store. It also includes some sample code for setting up a stack but it stops short of showing you how to actually use it in your app.

If you read the sample code provided by Apple you'll notice that the initializer of their DataController class adds the persistent store to the coordinator asynchronously. This is important and I'm surprised how often I see Core Data code that adds the store on the main thread. Not only does this require accessing the disk (unless it's an in-memory store), there is no way to know how long this operation is going to take to complete. Depending on the number of pending migrations and the amount of user data you can easily cause your entire app to lock up, or worse, fail to launch in time.

So accepting that adding the persistent store on a background thread is a good idea this leaves us with a problem. Let's say we're using their DataController class in our app:

let dataController = DataController()
let managedObjectContext = dataController.managedObjectContext
// Do stuff with the context
managedObjectContext.save()

Ignoring the missing error handling, there's a problem with this code that's not immediately obvious if you haven't read the DataController class. Since the init method dispatches to a background queue to set up the persistent store the persistent store controller is not going to have any persistent stores when init finishes. This means our code is going to throw an exception like this:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This NSPersistentStoreCoordinator has no persistent stores (unknown).  It cannot perform a save operation.'

Isn't asynchronous programming fun?

Ok, so we need to make sure we wait until the store coordinator has finished trying to add the persistent store before we attempt to actually use the context. There are a few ways we can do this. One very Objective-C way would be to use the delegate pattern and notify our delegate when the background code succeeds or fails. Another, more Swifty way, would be to supply a callback to our init method.

func init(callback: NSError -> ()) {
    // ...
}

This approach would probably work well for a simple app but it has a couple of drawbacks. For one, We can only supply one callback. Any code that needs to execute after the context is ready is going to need to be executed from within that callback. Additionally, this code also doesn't do anything to prevent us from trying to use the managed object context before it's ready.

Alright. So how can we work around those two issues? How can we supply an arbitrary number of operations that are guaranteed to execute only after the store is ready and make it hard to accidentally use our managed object context before that?

I'm Super Serial

Serial dispatch queues are great for executing code in the background that needs to happen in a specific order. By using our own serial queue instead of whatever global queue GCD gives us we can ensure that background initialization completes before any other code on that queue is executed.

Here's our new init method:

    private let queue: dispatch_queue_t

    init(modelUrl: NSURL, storeUrl: NSURL, concurrencyType: NSManagedObjectContextConcurrencyType = .MainQueueConcurrencyType) {

        guard let modelAtUrl = NSManagedObjectModel(contentsOfURL: modelUrl) else {
            fatalError("Error initializing managed object model from URL: \(modelUrl)")
        }
        managedObjectModel = modelAtUrl

        persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)

        _managedObjectContext = NSManagedObjectContext(concurrencyType: concurrencyType)
        _managedObjectContext.persistentStoreCoordinator = persistentStoreCoordinator

        let options = [
            NSMigratePersistentStoresAutomaticallyOption: true,
            NSInferMappingModelAutomaticallyOption: true
        ]

        print("Initializing persistent store at URL: \(storeUrl.path!)")

        let dispatch_queue_attr = dispatch_queue_attr_make_with_qos_class(DISPATCH_QUEUE_SERIAL, QOS_CLASS_USER_INITIATED, 0)
        queue = dispatch_queue_create("DataStoreControllerSerialQueue", dispatch_queue_attr)

        dispatch_async(queue) {
            do {
                try self.persistentStoreCoordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: storeUrl, options: options)
            } catch let error as NSError {
                print("Unable to initialize persistent store coordinator:", error)
                self.error = error
            } catch {
                fatalError()
            }
        }
    }

So now we're using our own serial queue to set up the store. It may not be obvious yet how this helps us. Next let's look at how our class stores the managed object context.

    private var _managedObjectContext: NSManagedObjectContext

    var managedObjectContext: NSManagedObjectContext? {
        guard let coordinator = _managedObjectContext.persistentStoreCoordinator else {
            return nil
        }
        if coordinator.persistentStores.isEmpty {
            return nil
        }
        return _managedObjectContext
    }

Instead of a public managedObjectContext instance variable we have a private internal variable and a public accessor that returns an optional. This way we never return an invalid context to any of our clients. Now all we have to do is let our clients request access to the managed object context.

    func inContext(callback: NSManagedObjectContext? -> Void) {
        // Dispatch the request to our serial queue first and then back to the context queue.
        // Since we set up the stack on this queue it will have succeeded or failed before
        // this block is executed.
        dispatch_async(queue) {
            guard let context = self.managedObjectContext else {
                callback(nil)
                return
            }

            context.performBlock {
                callback(context)
            }
        }
    }

Hopefully this code is pretty clear. I've added a method that takes a callback and wraps that function in a block which is passed to our serial queue. Because the setup code is added to that queue as soon as it's created and the queue will only execute one block at a time we can be sure that this code will be executed after the controller has had a chance to try and load the store. When it's run the block checks to make sure we have a valid context and if so, executes the callback on the context's queue. This way we can help make sure our access to the managed object context is happening on the right thread.

Here's the complete class:

//
//  DataStoreController.swift
//

import CoreData

class DataStoreController {

    private var _managedObjectContext: NSManagedObjectContext

    var managedObjectContext: NSManagedObjectContext? {
        guard let coordinator = _managedObjectContext.persistentStoreCoordinator else {
            return nil
        }
        if coordinator.persistentStores.isEmpty {
            return nil
        }
        return _managedObjectContext
    }

    let managedObjectModel: NSManagedObjectModel
    let persistentStoreCoordinator: NSPersistentStoreCoordinator

    var error: NSError?

    func inContext(callback: NSManagedObjectContext? -> Void) {
        // Dispatch the request to our serial queue first and then back to the context queue.
        // Since we set up the stack on this queue it will have succeeded or failed before
        // this block is executed.
        dispatch_async(queue) {
            guard let context = self.managedObjectContext else {
                callback(nil)
                return
            }

            context.performBlock {
                callback(context)
            }
        }
    }

    private let queue: dispatch_queue_t

    init(modelUrl: NSURL, storeUrl: NSURL, concurrencyType: NSManagedObjectContextConcurrencyType = .MainQueueConcurrencyType) {

        guard let modelAtUrl = NSManagedObjectModel(contentsOfURL: modelUrl) else {
            fatalError("Error initializing managed object model from URL: \(modelUrl)")
        }
        managedObjectModel = modelAtUrl

        persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)

        _managedObjectContext = NSManagedObjectContext(concurrencyType: concurrencyType)
        _managedObjectContext.persistentStoreCoordinator = persistentStoreCoordinator

        let options = [
            NSMigratePersistentStoresAutomaticallyOption: true,
            NSInferMappingModelAutomaticallyOption: true
        ]

        print("Initializing persistent store at URL: \(storeUrl.path!)")

        let dispatch_queue_attr = dispatch_queue_attr_make_with_qos_class(DISPATCH_QUEUE_SERIAL, QOS_CLASS_USER_INITIATED, 0)
        queue = dispatch_queue_create("DataStoreControllerSerialQueue", dispatch_queue_attr)

        dispatch_async(queue) {
            do {
                try self.persistentStoreCoordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: storeUrl, options: options)
            } catch let error as NSError {
                print("Unable to initialize persistent store coordinator:", error)
                self.error = error
            } catch {
                fatalError()
            }
        }
    }
}

Not much else to it. If there's an error I store it as an instance variable so that the client code can reference it if needed. Here's an example of how it's used:

let libraryDirectoryUrl = NSFileManager.defaultManager().URLsForDirectory(.LibraryDirectory, inDomains: .UserDomainMask).first!
let storeUrl = libraryDirectoryUrl.URLByAppendingPathComponent("MyStore.sqlite")

guard let modelUrl = NSBundle.mainBundle().URLForResource("MyModel", withExtension: "momd") else {
    fatalError("Error loading Core Data model")
}

let dataStoreController = DataStoreController(modelUrl: modelUrl, storeUrl: storeUrl)
dataStoreController.inContext { context in
    guard let context = context else {
        print("Unable to load context:", dataStoreController.error)
        return
    }

    // Do stuff with context
}

// Elsewhere
dataStoreController.inContext { context in
    guard let context = context else {
        print("Unable to load context:", dataStoreController.error)
        return
    }

    // Do other stuff with context
}

One possible modification to this code would be to make the DataStoreController a singleton class. This could be achieved by simply adding a static constant sharedInstance and making the init private. I'll leave it up to you as to whether you think singletons are always a bad idea but I've used this code both ways and this is one situation I think it can make sense depending on the structure of your app.

In the next post I plan to look at NSManagedObject subclasses in Swift.

How to Check if You're Running on the Simulator in Swift

2015-06-23T04:00:00Z

I haven't posted in a while but here's a quick Swift snippet just so this site doesn't become completely stale.

I spend a lot of my time developing iOS apps that work with our web applications. When I run the app in the simulator I want it to talk to the copy of that web application that's running on my development machine and when I run it on a device (or issue a beta build) it should talk to the staging server. In Objective C this was easy. I'd just use TARGET_IPHONE_SIMULATOR to switch between hosts. Unfortunately, This doesn't work as well in Swift.

If you Google it you'll find this thread on Stack Overflow and this code in particular:

#if (arch(i386) || arch(x86_64)) && os(iOS)
    ...
#endif

From here I ended up with this code:

#if (arch(i386) || arch(x86_64)) && os(iOS)
    let DEVICE_IS_SIMULATOR = true
#else
    let DEVICE_IS_SIMULATOR = false
#endif

This would build and run fine from Xcode but the first time I tried to archive the target for release it would complain that DEVICE_IS_SIMULATOR was undefined.

After some experimentation I came up with the following code that seems to work well:

struct Platform {
    static let isSimulator: Bool = {
        var isSim = false
        #if arch(i386) || arch(x86_64)
            isSim = true
        #endif
        return isSim
    }()
}

// Elsewhere...

if Platform.isSimulator {
    // Do one thing
}
else {
    // Do the other
}

I hope this helps someone. Let me know if you have a better way. I'm off to go grill some burgers.

Trim a String in Swift

2015-04-21T04:00:00Z

I needed to trim whitespace from some user input in a Swift app I'm working on. I could have used the ability to bridge to NSString and called stringByTrimmingCharactersInSet: but doing it in Swift seemed like a fun little exercise.

let whitespaceAndNewlineChars: [Character] = ["\n", "\r", "\t", " "]

extension String {
    func rtrim() -> String {
        if isEmpty { return "" }
        var i = endIndex
        while i >= startIndex {
            i = i.predecessor()
            let c = self[i]
            if find(whitespaceAndNewlineChars, c) == nil {
                break
            }
        }
        return self[startIndex...i]
    }

    func ltrim() -> String {
        if isEmpty { return "" }
        var i = startIndex
        while i < endIndex {
            let c = self[i]
            if find(whitespaceAndNewlineChars, c) == nil {
                break
            }
            i = i.successor()
        }
        return self[i..<endIndex]
    }

    func trim() -> String {
        return ltrim().rtrim()
    }
}

Update: @ChromophoreApp on Twitter pointed out that if you use subscripting instead of substringFromIndex you can avoid importing Foundation at all. What can I say? Old habits die hard. Thanks!

Download this code as a playground.

Simple Auto Layout in Swift

2015-02-22T05:00:00Z

I haven't had much time to spend with Swift lately but with the release of Swift 1.2 it seemed like a good time to refresh my memory. I have one (very unfinished) project written entirely in Swift that helps me keep track of the changes in the language. This project has come to the point where I can no longer rely on storyboards and nibs for layout so the time had come to look seriously at writing Auto Layout code in Swift.

Now I know there are a few open source libraries that provide convenience methods and/or DSLs for working with Auto Layout in both Swift and Objective C and I'm sure they're mostly brilliant. Regardless, I like to really understand the code I'm writing and as a rule I avoid any library I can write (the subset I require of) myself.

So what are the most common things we need to do when laying out views? This is roughly what I came up with:

Place a view within a parent pinned relative to the parent (Struts!)
Place a view within a parent pinned to opposite edges so that it resizes with the parent (Springs!)
Set the explicit width and or height of a view
Set the relative width and or height of a view based on a another view
Place a view relative to another view in the hierarchy
Align a view with another view within the hierarchy

Of course NSLayoutConstraint can do all of this (and a lot more) but this seemed to me to be the low hanging fruit, as it were, for simplifying layout code. So with these requirements in mind, and a goal of simplicity and readability above all else, I threw together some code this afternoon.

import UIKit

struct Inset {
    let value: CGFloat
    let attr: NSLayoutAttribute

    init(_ value: CGFloat, from attr: NSLayoutAttribute) {
        self.attr = attr;
        switch (attr) {
        case .Right, .Bottom:  self.value = -value
        default: self.value = value
        }
    }
}

extension UIView {
    func addSubviews(views: UIView...) {
        for view in views {
            self.addSubview(view)
        }
    }

    func layoutInside(otherView: UIView, insets: Inset...) -> [NSLayoutConstraint] {
        var constraints: [NSLayoutConstraint] = []
        for inset in insets {
            constraints.append(NSLayoutConstraint(item: self, attribute: inset.attr, relatedBy: NSLayoutRelation.Equal, toItem: otherView, attribute: inset.attr, multiplier: 1.0, constant: inset.value))
        }
        return constraints
    }

    func constrainDimension(dimension: NSLayoutAttribute, relation: NSLayoutRelation, constant: CGFloat) -> [NSLayoutConstraint] {
        return [NSLayoutConstraint(item: self, attribute: dimension, relatedBy: relation, toItem: nil, attribute: .NotAnAttribute, multiplier: 1, constant: constant)]
    }

    func constrainDimension(dimension: NSLayoutAttribute, relation: NSLayoutRelation, toView otherView: UIView, constant: CGFloat) -> [NSLayoutConstraint] {
        return [NSLayoutConstraint(item: self, attribute: dimension, relatedBy: relation, toItem: otherView, attribute: dimension, multiplier: 1, constant: constant)]
    }

    func constrainWidth(relation: NSLayoutRelation, toWidth constant: CGFloat) -> [NSLayoutConstraint] {
        return constrainDimension(.Width, relation: relation, constant: constant)
    }

    func constrainWidth(relation: NSLayoutRelation, toView otherView: UIView, plus constant: CGFloat) -> [NSLayoutConstraint] {
        return constrainDimension(.Width, relation: relation, toView: otherView, constant: constant)
    }

    func constrainHeight(relation: NSLayoutRelation, toHeight constant: CGFloat) -> [NSLayoutConstraint] {
        return constrainDimension(.Height, relation: relation, constant: constant)
    }

    func constrainHeight(relation: NSLayoutRelation, toView otherView: UIView, plus constant: CGFloat) -> [NSLayoutConstraint] {
        return constrainDimension(.Height, relation: relation, toView: otherView, constant: constant)
    }

    func layoutBelow(otherView: UIView, distance: CGFloat) -> [NSLayoutConstraint] {
        return [NSLayoutConstraint(item: self, attribute: .Top, relatedBy: .Equal, toItem: otherView, attribute: .Bottom, multiplier: 1, constant: distance)]
    }

    func layoutAfter(otherView: UIView, distance: CGFloat) -> [NSLayoutConstraint] {
        return [NSLayoutConstraint(item: self, attribute: .Left, relatedBy: .Equal, toItem: otherView, attribute: .Right, multiplier: 1, constant: distance)]
    }

    func alignWith(otherView: UIView, edge: NSLayoutAttribute, offsetBy constant: CGFloat) -> [NSLayoutConstraint] {
        return [NSLayoutConstraint(item: self, attribute: edge, relatedBy: .Equal, toItem: otherView, attribute: edge, multiplier: 1, constant: constant)]
    }

    func alignBaselineWith(otherView: UIView, offsetBy constant: CGFloat) -> [NSLayoutConstraint] {
        return [NSLayoutConstraint(item: self, attribute: .Baseline, relatedBy: .Equal, toItem: otherView, attribute: .Baseline, multiplier: 1, constant: constant)]
    }
}

extension Array {
    func withPriority(priority: UILayoutPriority) -> [NSLayoutConstraint] {
        var members: [NSLayoutConstraint] = []
        for member in self {
            switch member {
            case let constraint as NSLayoutConstraint:
                constraint.priority = priority
                members.append(constraint)
            default: break
            }
        }
        return members
    }
}

You might notice that while only one of the functions returns more than one constraint they all return an array. At this point I feel like consistency is more important that any performance hit this may cause but without knowing that much about how Swift allocates arrays and without any real-world benchmarking it's hard to tell. I figure it's very likely I may want to add new functions in the future that return multiple constraints and in my experience constraints are usually built up by combining multiple arrays anyway. Regardless, that's less than 100 lines of code, you can can probably understand most of it it in glance and it makes for some relatively concise and readable layout code:

let v1 = UIView()
v1.setTranslatesAutoresizingMaskIntoConstraints(false)
v1.backgroundColor = UIColor.redColor()

let v2 = UIView()
v2.setTranslatesAutoresizingMaskIntoConstraints(false)
v2.backgroundColor = UIColor.blueColor()

let l1 = UILabel()
l1.setTranslatesAutoresizingMaskIntoConstraints(false)
l1.backgroundColor = UIColor.yellowColor()
l1.text = "Label 1"

let l2 = UILabel()
l2.setTranslatesAutoresizingMaskIntoConstraints(false)
l2.backgroundColor = UIColor.yellowColor()
l2.text = "Label 2"

self.view.addSubviews(v1, v2, l1, l2)

var constraints: [NSLayoutConstraint] = []
constraints += v1.layoutInside(self.view, insets: Inset(120, from: .Top), Inset(60, from: .Left))
constraints += v1.constrainWidth(.Equal, toWidth: 44)
constraints += v1.constrainHeight(.Equal, toHeight: 44)

constraints += v2.constrainWidth(.Equal, toWidth: 64)
constraints += v2.constrainHeight(.Equal, toView: v1, plus: 10).withPriority(500)
constraints += v2.constrainHeight(.Equal, toHeight: 400).withPriority(499) // Is ignored
constraints += v2.alignWith(v1, edge: .Left, offsetBy: 5)
constraints += v2.layoutBelow(v1, distance: 8)

constraints += l1.alignWith(v1, edge: .Left, offsetBy: 0)
constraints += l1.layoutBelow(v2, distance: 40)

constraints += l2.alignBaselineWith(l1, offsetBy: 0)
constraints += l2.layoutAfter(l1, distance: 15)

self.view.addConstraints(constraints)

Which results, roughly, in this. I think that's a pretty big win for a wafer-thin level of abstraction.

Free as in Baby

2014-11-25T05:00:00Z

I've been meaning to write this post but Daniel Compton beat me to it. The phrases "It takes a village to raise a library" and "free as in 'baby'" are too perfect not to repeat.

While open source is free as in beer, it’s also free as in baby

A New Post Script for Jekyll

2014-11-23T05:00:00Z

The Main Thread is a static site generated with Jekyll. I love a lot of things about this setup, like being able to host it on S3, but there's too much friction when adding new posts. Today I finally got around to writing a small bash script for generating new posts. I had previously been using a TextExpander snippet to fill in the metadata but I still had to save the file in the write place with the right filename like an animal.

DATE=`date +%Y-%m-%d`
FILE=source/_posts/$DATE-$1.md
TITLE=$2

shift 2

cat > $FILE <<- EOM
---
layout: post
published: false
title: $TITLE
excerpt:
tags: $@
---
EOM

open $FILE

This dumps some pre-filled metadata into a new file and opens it with BBEdit (on this computer at least):

> cd path/to/project
> ./post.sh file-name-slug "Title of Post" as many tags as I want

OnePad Finally Updated

2014-11-22T05:00:00Z

OnePad version 1.4 is mostly me playing catch-up. The UI has been iOS 7-ified, it has 50% less capitol letters in the name and 100% less skeuomorphism in the icon. It's optimized for the iPhone 6 and 6 Plus and it's built against the iOS 8 SDK for both 32 and 64-bit chips. All pretty standard stuff really. It's still using iCloud CoreData, which is one reason I'm not calling it a "two dot oh", but it's on the "improved" version of the framework now at least.

I did have a chance to add a couple of new features. There's a Today widget for iOS 8 that displays your notes for today's date and a custom URL scheme for saving notes to OnePad from other apps. There are a few other little things here and there which are in the release notes if you're curious.

Version 1.4.1 is in the store now for $2. If you decide to buy it, or you already own it, please consider leaving a rating or a review. I've also posted a bunch of promo codes on Dispensr.net so feel free to grab one while they last.

Two Great Programming Videos

2014-10-05T04:00:00Z

I like to watch videos in bed before I go to sleep (pause for jokes). Technology talks are my favorite. Everything from WWDC sessions to virtual reality. In the best case I'm up late but I've give my brain something to chew on while I sleep. In the worst case they're better than a glass of warm milk. I want to share a couple of exceptional software programming talks that I've watched recently. They're both from game developers but if you're anything like me, these talks will likely challenge many of your assumptions while enforcing other suspicions about the "right" way to write software.

CppCon 2014: Mike Acton "Data-Oriented Design and C++"

Mike Acton is in charge of game engine development for the prolific console game development company Insomniac. I love the way he comes out swinging and smashing idols. He focuses on understanding the platform and the problem while attacking the notion that hiding the realities of either behind programming abstractions is well, bad. Be sure to stick around for the Q&A at the end.

Ideas about a new programming language for games.

In this, the first in a series (or at least 2) videos, game developer Jonathan Blow discusses his ideas for an ideal language for large scale game development. A lot of good insights here, especially in the second part, from an experienced programmer.

Get Your Free Build Numbers Here

2014-09-24T04:00:00Z

You'd think something as simple as an automatically incrementing build number would be a solved problem by now. Instead it seems to be one of those areas where everyone has their own workaround. At least for those of us not blessed, or cursed, with a monolithic shared build system. For Cocoa apps the build number is also known as a CFBundleVersion and it's a very useful thing for lining up bug reports with exact points in your code history.

I still use a mostly manual approach to build numbers. Whenever I'm ready to release either a new ad hoc beta or submit a build to iTunes Connect, I run a small shell script that uses agvtool to set the CFBundleVersion of all the targets in my project. Until recently I was just letting agvtool bump the current project version number, whatever it was. This works great until you're building from multiple branches concurrently at which point you will end up with completely different builds sharing the same build number.

My next idea was to keep a text file with the current version number at the root of the project. This text file has to be excluded from version control however, so that it would always reflect the highest build number of any branch. For a single developer on a single machine this is alright but I have two computers...

So over the weekend I decided to build The World's Stupidest Web App™. It's basically one of those bright red "take a number" things, just hosted on Heroku. You make a GET request to a unique path (a bundle ID works great) and it returns the next build number in a sequence. You can specify a starting number, useful for existing projects, but that's about it.

Here's my current build script:


#!/usr/bin/env sh

if git diff-index --quiet HEAD --; then
  BUILD_NUMBER=$(curl "http://buildnum.herokuapp.com/com.example.myproject?start_at=42")
  agvtool new-version -all "$BUILD_NUMBER"
  git commit -am "New build: $BUILD_NUMBER" 
else
    echo Commit your changes before building.
fi

First I check to make sure there are no uncommitted changes. If there aren't I query the web app using the bundle ID for the project and use the response to set the build number. Last, I add a new commit to mark the spot in the repo. It's not perfect, I'm constantly changing my build script, but at least I know that each build number lines up with a single commit in the code base. The build numbers are also suitable for submission to iTunes Connect so I don't have to have a separate process for ad hoc builds and releases.

Feel free to use the web app if you want. Just replace 'com.example.myproject' with your app's bundle ID and, optionally, '42' with the first number you want to receive. You can leave the start_at param, it will be ignored for any active bundle IDs. Note: I don't recommend using this as part of your normal development cycle if only because it can take the app a few seconds to warm up if it's been put to sleep by Heroku.