Archive for October 14, 2016

Friday, October 14, 2016 [Tweets] [Favorites]

Swifty Delegates

Soroush Khanlou:

These are horrible. Why are both of these methods called messageForm? Also, starting a method with a noun here doesn’t make sense: it usually suggests that you’ll be returning an object of that type (think about data(using:) on NSString, which returns a Data). We’re not returning any message form objects here. That “message form” is actually the name of the first parameter. These are very confusing method names!

Both of these types of delegate methods can be fixed by moving the “sender” to the back of the line, and bringing the verbs forward. For the first one, the event that the sender is informing the delegate about is didTapCancel, instead of messageFormDidTapCancel.


I haven’t found a hard and fast rule for which preposition to use yet. I’ve found “on”, “for”, “with”, and “in” to all be useful in different circumstances.


These rules aren’t endorsed by anyone except for me, but I think they make much more sense than the current rules by which we write delegate methods. Going forward, I’ll probably start writing my Swift delegate methods with this structure.

Well Rounded

Dr. Drang:

The problem with always rounding halves up is that in doing so, you introduce a persistent bias in whatever calculations you do with the rounded number. If you’re adding a list of rounded numbers, for example, the sum will be biased high.

If you round halves to the nearest even number, though, the bias from upward roundings tends to be negated by an equal number of downward roundings.

Declarative API Design in Swift

Benjamin Encz:

It has almost no imperative code. Most code describes network request based on instance variables and previous requests.

It doesn’t call the networking layer, nor does it have any knowledge of the type that actually performs the upload. It just describes the intent of each request. In fact, the code has no observable side effects at all, it only mutates internal state.

There is almost no error handling code here. The responsibility of this type is only to handle errors specific to this request sequence (e.g. missing required data from a previous request). All other errors are generically handled in the networking layer.

With the old version:

Separation of concerns was a lot harder to come by. Instead of simply describing a request sequence, the NSOperations in the NSOperationQueue themselves were responsible for kicking off a network request. This promptly introduced a bunch of other responsibilities such as request cancellation and error handling. While similar code had been implemented in other places that dealt with creating upload requests there was no good way of sharing that implementation. Subclassing wasn’t an option since most upload requests were modeled as a single NSOperation, while this upload request sequence was modeled as an NSOperation that wrapped an NSOperationQueue.

OpenType Variable Fonts

John Hudson (via Avi Drissman):

An OpenType variable font is one in which the equivalent of multiple individual fonts can be compactly packaged within a single font file. This is done by defining variations within the font, which constitute a single- or multi-axis design space within which many font instances can be interpolated. A variable font is a single font file that behaves like multiple fonts.


OpenType Font Variations builds on the model established in Apple’s TrueType GX variations in the mid-1990s, but has fully integrated that model into all aspects of the OpenType format, including OpenType Layout, and is available to both TrueType and Compact Font Format (CFF) flavours of OpenType.


However, unlike master-based interpolation technologies such as Adobe’s earlier multiple master format, an OpenType variable font contains only a single set of glyph outlines, and the other extremes or intermediate shapes are defined as deltas from those outlines.

Git Tower 2.5


Open Quickly dialog is all new: “Open Quickly” (e.g. via CMD+SHIFT+O) is now much faster, more responsive, more clever (and can be closed via ESC).


Custom service accounts are here: In the “Services” view, you can now add an account for your self-managed server. This makes authentication for your own servers as easy as for the supported code hosting platforms like GitHub.


Fetch processes won’t duplicate anymore: If a Fetch process for a remote repository is already running, Tower will not start another Auto-Fetch processes for the same remote.


File tree in historic commits was improved: when navigating through the file tree of an old commit, expanded folders and selections now survive switching to another app and back to Tower.


Commit messages with invalid unicode characters: Until now, invalid characters blocked Tower when trying to load the commit history (and “No commits” was shown). Tower is now smarter and is able to load the history regardless.

A lot has improved since 2.0, but the per-file history feature is still weak, and it still can’t search commit contents or blame. I supplement a lot with BBEdit and the command-line tool.