Game of Life on Metal

by Dan Cutting

I was sad to hear John Conway had recently died of COVID-19. Conway was a mathematician who contributed much to his field, but for me as a computer scientist, I knew of him for his Game of Life (aka just Life).

Life was one of the first programs I wrote at university. I remember the excitement of watching the cells flicker on and off creating more and more complex behaviour from really simple rules. I’ve been fascinated with it ever since.

I was never very happy with the performance of my code, though, running as it was on a 90’s CPU. Since I’m learning Metal at the moment, it seemed like a good time to pay my respects to John Conway and implement Life on a GPU.

Continue ☛

The shortest possible deadline

by Dan Cutting

Agile software development is partly based on the idea that a series of shorter deadlines is better than a single big crunch. But how short can we go?

The Welsh poet Dylan Thomas was frantically finishing the script to one of his greatest works—the radio play Under Milk Wood—just moments before the voice actors took to the sound stage for its maiden performance. He’d known about the deadline for months, but in the end, Thomas had to be locked in a room by his agent to finally finish the play that had been on his mind in one form or another for much of his life.

If you’re a software developer, this might sound familiar. Even when we have months to complete a project, we often find ourselves struggling as the deadline looms. This isn’t because we’re lazy: it’s because other work gets in the way, or dependencies don’t deliver, or scope changes, or tiny unexpected things bog us down for days. We add developers, or skip tests, or work longer hours. In the last couple of weeks we may even find ourselves locked in a room, as Thomas did, for the final bleary-eyed push.

Continue ☛

Vague tests are clear tests

by Dan Cutting

Specificity is almost always a good thing.

But sometimes when unit testing, I need to pass dummy values to functions just to make the compiler happy.

I don’t care what the values are, but using specific literals can obscure the intent of the tests:

func test_stack_count() {

    let stack = Stack()

    stack.push("hello")
    stack.push("bye")
    stack.push("hello")

    XCTAssertEqual(3, stack.count)
}

This test checks that the number of things on a stack is correct after pushing some strings onto it.

Somebody coming across this test may have a few questions: is it important that these particular values are pushed? Is the duplication of "hello" significant?

In fact, it doesn’t matter what is pushed onto the stack, so this test shouldn’t introduce any doubt in the mind of the reader.

Continue ☛

iOSCon 2018

by Dan Cutting

What a great conference!

iOSCon 2018 just finished and I had a great time hearing and meeting some excellent speakers and attendees.

I presented my App Architectures: Remixed talk (video and slides available) and was very happy with how it turned out. :)

The highlight was certainly meeting Mr Michael Feathers who gave a fascinating talk about how we can avoid having our code deteriorate into the horrible messes he describes in his must-read book.

I also really enjoyed some of the other great talks:

Thanks to all the organisers, particularly Carla and Paul. Looking forward to next year’s conference already!

iOSCon 2018 sneak preview

by Dan Cutting

This year’s iOSCon is gearing up for its March 22nd–23rd run at CodeNode and I’m really pleased to be back again!

My “grand tour” of iOS architectures last year laid out the various patterns my team had been looking at as we faced some tough architectural decisions with our large-scale app.

One year on, we’ve come up with the “Remix” patterns that walk the fine line between code reuse and feature flexibility. As a bonus, we’ve also discovered some amazing techniques to make UX tests run subsecond! ;)

I hope you’ll find the talk useful for rethinking how and why we structure apps the way we do and I’m looking forward to hanging out again with a great bunch of iOS geeks!

Remix at iOSCon Bytes

by Dan Cutting

Last Tuesday, I introduced the Remix architecture at the iOSCon Bytes meetup series. You can see the whole video here or the slides on Speaker Deck.

Remix is a collection of design patterns and principles I’ve been exploring for the work I’m currently doing on apps that need to support different variations of the same underlying core.

It’s aimed at maximising reuse of components such as views, business logic, presentation logic, and flow logic.

This talk walks through a simple app from Apple MVC architecture to Remix architecture, showing how it can support different “just reuse it” scenarios along the way.

The Grand Tour of iOS Architectures

by Dan Cutting

Last week I gave a talk at iOSCon 2017 entitled The Grand Tour of iOS Architectures. #ioscon

Join Dan on this grand tour and discover the plethora of iOS software architectures popping up, from VIPER, VIP and Clean to Flux, Redux and Reactive. Along the way Dan will highlight the common themes and look at some real case studies, to get to the essence of what architecture is and why you should think about it for your app.

You can find the video on SkillsMatter (free registration required) and the slides on SpeakerDeck. The talk centred around an example app, available on GitHub, which is implemented using several different architectures.

I think the talk went well, and I somehow even managed to land exactly on 30 minutes. I got a lot of really fantastic questions that I think demonstrate the importance of this topic, and the desire for the community to step up when it comes to improving the design of our iOS code bases. I couldn’t have been happier!

I had a great time at iOSCon this year. Aside from meeting lots of great people, there were some really interesting talks. Read on for a few personal highlights.

Continue ☛

Blindingly obvious rules for software teams

by Dan Cutting

Writing software is easy. Incredibly, astonishingly, easy.

And when you’re part of a team of other people with dumb opinions of their own, it’s even easier. Easy-peasy, if you will.

It’s so trivial, in fact, that it’s spawned a massive industry of books, training, and certifications explaining just how easy it is, if only you’d follow the right rules.

I figured it was high time I jumped on this bandwagon, so here are my rules for how to write software as a team.

These rules are “synthesised” (stolen) from many books, blogs, and movements (Beck, Cunningham, Feathers, Fowler, Martin, agile, craftsmanship, …), and from my own experience as a developer and team leader over the last decade or two.

No doubt my opinions will change over time, in which case I’ll deny all knowledge of this blog post.

Continue ☛

X/UP

by Dan Cutting

London has a brand new meetup:

X/UP is the quarterly meet-up for Xcoders in the UK. Hosted at CodeNode, London, X/UP brings the best minds in the industry to talk about coding and app development for Apple platforms including iOS, OS X, watchOS and tvOS.

It’s the brainchild of Paul Stringer, who invited me to present Act I of the inaugural X/UP last Thursday at CodeNode. Only after I’d accepted did Paul tell me that Act II would be the legendary Uncle Bob of Clean Code fame! I was honoured to be speaking at the same event, but it certainly raised the pressure.

Continue ☛

Stateful mixins in Swift

by Dan Cutting

Last July, Matthijs Hollemans posted a great article about mixins and traits in Swift. He defines three related concepts:

The interface … has method signatures but no actual code

A trait adds code to an interface

A mixin is like a trait but it also has state

Interfaces in Swift are simply protocols, while traits can be made with protocol extensions. Swift doesn’t support mixins directly, but we can get pretty close.

Continue ☛

Glance'n'grok coding

by Dan Cutting

Let’s be honest: few of us take the time to really read the code we’re working on, whether it’s our own, or — shudder — somebody else’s. We take a glance and (think) we grok it.

With that in mind, here are some programming language features that may have seemed like good ideas at the time, but now wreak havoc in our glance’n’grok culture.

Exhibit A: GOTO

What’s wrong with this code?

10 A = 0
20 PRINT A
30 IF A > 9 THEN GOTO 60
40 A = A + 1
50 GOTO 20
60 PRINT "GOODBYE"

Well, nothing, if we don’t mind wading through GOTOs and conditions and assignments to interpret the intended behaviour. (It’s also got line numbers, AND IT’S A BIT SHOUTY…)

Continue ☛

API days London: day 1 roundup

by Dan Cutting

The API days London event is running today and tomorrow (September 23rd and 24th, 2015). This is a conference about building public and internal APIs for the Banking, Finance, Insurance, and Payment industries.

The venue is Level39, a technology accelerator based on level 39 of the One Canada Square building at Canary Wharf. The view is amazing!

Continue ☛

Pragmatism is next to Godwinism

by Dan Cutting

In which the act of lazily invoking Hitler during an argument is compared to an appeal for programming pragmatism that shuts down constructive debate. But does “pragmatic” have to be a dirty word?

PLAYERS: JOURNEYMAN, NOOB, BOSSMAN, GREYBEARD

Journeyman — The right way to implement this MacGuffin is to replace the singleton with a factory that makes decorated visitor façades.

Noob — Yeah but we don’t have time for that. Let’s just copy and paste this other method and move on.

Journeyman — That’s not DRY. We’ll end up having to maintain the code in two places.

Noob — Not DRY? Well, factories aren’t KISS.

Journeyman — A craftsman makes beautiful apps with beautiful code.

Noob — We don’t have time to make beautiful code.

Journeyman — Steve Jobs’ father taught him to paint the bits of the fence you’d never see—

NoobDILLIGAF?! We’re not in some ivory tower here, this is the real world and Bossman needs to ship. You’ve got to be pragmatic.

Uh oh, did he just drop the P word?

Continue ☛

Completely over-engineering "fizzbuzz" with infinite streams

by Dan Cutting

Have you ever had that “fizzbuzz” interview question? It goes like this:

  • Write a program that prints all the numbers from 1 to 100 but with multiples of 3 replaced by the word “fizz”, multiples of 5 replaced by the word “buzz”, and multiples of both replaced by “fizzbuzz”.

This is a silly interview question. Not because it’s easy, but because it’s common enough that people just reel off an implementation by rote.

Here’s one way to do it in Swift.

for i in (1...100) {
    if i % (3*5) == 0 {
        print("fizzbuzz")
    } else if i % 3 == 0 {
        print("fizz")
    } else if i % 5 == 0 {
        print("buzz")
    } else {
        print(i)
    }
}
// 1, 2, fizz, 4, buzz, fizz, 7, 8, fizz, buzz,
// 11, fizz, 13, 14, fizzbuzz, 16, 17, fizz, 19, buzz ...

But as we’ve come all this way for an interview, let’s waste everybody’s time and make it much more complicated.

We start by noticing that the range 1…100 is actually a subset of the infinite stream of natural numbers. So instead of just dealing with the problem at hand, let’s model infinity. You know, for future flexibility.

Continue ☛

The power of Swift enums

by Dan Cutting

Enumerations, or enums, are a symbolic way to represent a “one of” type. In this post we’ll get a taste of the great flexibility that Swift enums bring to the table, and how they can simplify and clarify our code.

I don’t think it’s untrue to say that a bird can be one of the following: Galah; Kookaburra; or Other.

In C, we might represent the concept like this:

enum {
  Galah,
  Kookaburra,
  Other
};

int main(int argc, char *argv[]) {
  int bird = Kookaburra;
  printf("%d", bird);
}

C enums are a pretty leaky abstraction, however. Since they are essentially just ints, we can do strange things like add them together. What should Galah + Kookaburra mean, and why does it equal 1? (If you don’t know the answer to that, ask your nearest greybeard.)

Continue ☛

Hypermedia ain't that fat

by Dan Cutting

Hypermedia APIs are designed around the concept that clients and services should not be tightly coupled, but discoverable. One prominent feature is that responses should contain explicit links for clients to use to take successive actions.

This post will explore one concern that often arises: that hypermedia responses are much larger than non-hypermedia responses since they need to include a lot of extra information in the form of links.

Continue ☛

Computer aided programming

by Dan Cutting

To me, test-driven development (TDD) sometimes feels like a game of chess between red and green pieces:

  1. Red’s turn: write a failing test.
  2. Green’s turn: counter the move by writing code that passes the test.
  3. Goto 1.

Just like chess, there are an overwhelming number of potential moves and games, and the same game will never be played twice. The alchemy is knowing what test to write, and what code to write that passes the test.

Continue ☛

Packaging iOS apps from the command line

by Dan Cutting

The blessed way to submit an iOS app to the App Store is to use Xcode. This works well for independent developers, but is a pain when working as part of a larger team with a continuous integration system.

In these situations we need to build and package apps via command line scripts to produce build artefacts ready for submission. The command line tools that ship with Xcode enable this:

xcodebuild -workspace "MyApp.xcworkspace" -scheme MyApp clean build
xcrun -sdk iphoneos PackageApplication -v MyApp.app \
  -o MyApp.ipa --sign "iPhone Distribution: My Company"

This (ostensibly) produces an IPA we can upload through Application Loader to iTunes Connect.

Continue ☛

The Four Ways To Bypass Static Cling

by Dan Cutting

How can we test code that calls static functions in other classes?

Let’s say we have some legacy code. We’ll use Swift1 here, but any OO language will be comparable:

class TaxedItemPricer {

  let TaxRate = 1.2

  func totalPriceForItem(itemId: Int) -> Double {
    let price = ItemDAO.priceForItem(itemId);
    return price * TaxRate
  }
}

class ItemDAO {

  class func priceForItem(itemId: Int) -> Double {
    // Connect to a database and query the price.
  }
}

Writing this code was pretty convenient for the original author. The code just reaches out to a database to grab the raw price for the given item then multiplies it by the hard-coded tax rate.

Continue ☛