DRY Fusion data munging kata in Swift

I worked through one of Dave Thomas’s programming exercises, called a kata, and pushed my Swift 2.2 code to GitHub. The code shows how to apply the Don’t Repeat Yourself (DRY) principle to two similar but different data processing programs.


The end result of this exercise is a satisfyingly readable higher-order function, which is similar to a template method but does not require subclassing to supply context-specific logic.

Here is the kata:


And here is my implementation of the kata’s third challenge:


This was a great learning experience!

Posted in Swift | Tagged , | 1 Comment

Creating an iOS Wizard UI in Swift

I published a reusable framework, written in Swift, for implementing the Wizard UI design pattern, named Wizardry. It simplifies creating a user interface composed of multiple view controllers that enables the user to complete a task. This is a particularly important UI design pattern for mobile apps due to the small screen size.


Over the years I have built wizards for several applications, on various of platforms and with different languages. The design approach seen in Wizardry is the culmination of these efforts, with a simple, clean API that I hope developers find intuitive and complete.

Wizardry’s README file explains how to use it to build your own wizard. For a complete example, refer to the demo project.


Posted in Swift | Tagged ,

Stones on a beach

Suppose that you arrange stones into a spiral on a sandy beach.


After meticulously arranging your stone spiral, the world seems hell-bent on destroying it. A dog steps on some of the stones, a big wave carries some of them away, and a child throws part of your spiral into the ocean.

There are many ways to form a spiral with those stones; countless millions of arrangements that enable someone to perceive a spiral on the sand. However, there is an almost infinite number of ways to arrange those stones that do not form a spiral. The odds are overwhelmingly in favor of your creation losing its spiral-ness simply because there are so many more non-spiral arrangements.

Now suppose that each stone is a tiny piece of a computer program. Like the stones, the individual parts of a program are carefully arranged to induce an emergent phenomenon. Instead of a spiral emerging from stones and sand, features emerge from logic and state.

The unpredictable world in which we live indiscriminately nudges our creations toward chaos. Features break because of minute changes made to those tiny pieces of the program.

What can and should developers do to defend their creations against unceasing entropy?

Posted in Thoughts, Uncategorized | 8 Comments

Find keys by value in Swift dictionary

Here’s a helper method that might come in handy when working with a Swift dictionary. It finds every key mapped to a particular value.

This is similar to the allKeysForObject(_:) method of NSDictionary, but it is generic so it can return an array of properly types keys, instead of an array of AnyObject.

Posted in Swift | Tagged

Striving for excellence as a software developer

I’ve been a professional software developer for over a decade, and have been writing code since I was a kid. Over the years I have read a lot of advice from software developers with far more experience than me, to expand my thinking and perhaps avoid some mistakes that they once made. Some of my colleagues at various companies have been invaluable sources of insight, as well.  I’ve had enough experience at this point to learn more than a few lessons of my own, some the hard way. I want to give back, and share what I’ve learned with others.

There are basic common sense things about how to write good code that seem obvious once you know them, but are not so obvious to people who have not yet learned those lessons. Some excellent advice is repeated so often that it seems like a cliché to even mention (encapsulation is good!).

I increasingly appreciate the importance and benefits of my received wisdom very gradually. The more code I write and fix, year after year, the more these basic principles of software craftsmanship resonate with me (no seriously, encapsulation really is quite good!)

Many thoughts about what it means to write good code flutter around inside my head. In order to structure these thoughts into something coherent and meaningful I’ve started a living document on GitHub, titled “Sustainable Coding“.

Note: I strongly hesitated to use “sustainable” in the title because it is a popular buzzword. I generally consider the presence of buzzwords to be a warning that something lame is afoot. But, as I explain in the introductory section, it truly is the best word I can find that fits my needs.

If you’re interested in reading my take on what it means to strive for excellence as a software developer, here’s the link:


This document is a work-in-progress. There’s a lot more that I want to write about, but I’m not in a rush. The document will grow at its own pace.

Posted in Sustainable Coding | 4 Comments

Finding unused resource strings in an iOS app

If you work on an iOS or OS X app that uses Strings files to store localized display text, over time those files can accumulate entries that are no longer used. Perhaps a developer forgot to remove a resource string when refactoring a view controller, or rapidly changing requirements caused a flurry of changes to display text that was never properly cleaned up. If you share my obsession for having no unused or unnecessary things in a codebase, check out my new tool that finds these abandoned strings.

I posted this simple tool on GitHub, along with some information about what the tool can do and what it cannot do.


Just pass the root directory of your project’s source code as a command line argument and wait a few moments while the program does what would take an OCD-enslaved developer hours to accomplish by hand!

Posted in Swift, Tips and Tricks, Uncategorized | Tagged

Creating Tic-tac-toe in Swift: User interface

This blog post is the third and final update about my Tic-tac-toe game, written in Swift. The source code is available on GitHub:


The app now has a user interface, which allows you to play against the computer or against another person on the same iPhone.


In my article about the Tic-tac-toe gameplay and data model I presented a diagram of domain components, such as the Game and GameBoard classes. The article about artificial intelligence reviewed a perfect-opponent strategy implementation. Now that the app has a user interface which ties these components together, we can see how they fit into the bigger picture.


The containment relationship between Game and GameBoard (i.e. a Game has a GameBoard) is mirrored by GameViewController and GameBoardView. When GameViewController begins a new game of Tic-tac-toe, it creates a GameBoard used as the data source for both a Game and GameBoardView.


The state of a game is visually depicted by GameBoardView. That UIView subclass relies on GameBoardRenderer and GameBoardLayout to perform drawing work.


As the code comments above indicate, creation of the layout and renderer objects is delayed until drawRect(_:) is called to ensure that the view’s graphics context and size are valid. Each object has two properties; one with an underscore prefix to store the object and another, without a prefix, that creates the object when necessary. This is similar to having a custom property accessor that uses an instance variable, in Objective-C.

The rendering work is performed by GameBoardRenderer:


All of the rendering routines are defined in a private class extension:


This code might seem odd if you have experience with CoreGraphics, which is an API of C functions and structures. Thanks to Swift’s all-encompassing support for adding methods to types, I was able to create this wrapper API to hide the ugly details of using CGContext.


Rendering a user interface does not, and should not, involve determining the size and location of each thing in the user interface. This separate responsibility is often referred to as layout calculation. I separated these two responsibilities by having the renderer rely on GameBoardLayout for the size and location of every user interface element. The rendering methods seen above use these properties of a layout object:


These properties are all lazy in order to avoid calculating their values more than once. This optimization is appropriate because a layout object is used multiple times throughout a game.

There is a lot more going on in this app, so if you’re interested be sure to clone the repository and dig in!

Posted in Swift, Tic-tac-toe | Tagged , | 1 Comment