I noticed my game of life app, Conway, had a couple of cosmetic bugs on newer versions of macOS so I spent a couple of hours fixing them up. While I was at it I couldn’t resist the urge to tinker and added an option for cells to leave trails, which I think makes the app very pretty!

I originally wrote the app as a tribute to John Conway. It’s no longer available on the Mac App Store but you can download it as a zipped app instead. (Warning: the binary has not been notarized so you’ll need to proceed at your own risk by following Apple’s instructions for running unnotarized softare.)

Adding trails was an interesting technical diversion.

Continue ☛

Zed’s new modal editor really simplifies a lot because there’s virtually no need for @FocusState any more.

I also applied extra polish this afternoon in the way of better VoiceOver descriptions and support for other accessibility features like reduced motion and increased contrast. Dynamic Type and dark mode are, of course, well supported.

Continue ☛

I’ve clarified the tabs on iPhone and added task separators. The iPad version of Zeds now shows all lists on the screen at once, and supports drag’n’drop both between lists and as a way to export/import text. But drag’n’drop, focus state, text fields and lists are giving me grief!

Continue ☛

I’m learning some new SwiftUI APIs by writing a “do it later” iPhone app called Zeds (ok fine… it’s a to do app, and yeah, that name is meant to sound like snoring but doesn’t work for US readers).

The premise is to boil everything down into just three lists: things to do later, things to do now, and things I’ve done. These lists are laid out next to each other in space from left to right.

Continue ☛

I played the Chaos Game today to make a Sierpiński gasket (aka Sierpiński triangle). You can read the code below or download the Swift Playground to experiment with it yourself.

Just plot some points using this simple algorithm to see a ghostly fractal triangle appear from nothing:

1. Set your “current” position to any of the three corners of the big triangle
2. Plot a dot at your current position
3. Pick any of the three corners
4. Find the midpoint of your current position and that corner
5. Set your current position to that midpoint
6. Goto 2

Continue ☛

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 ☛

We dragged ourselves back to day 2 following a great party from the night before.

Continue ☛

Another year, another iOSCon at Skills Matter CodeNode. I love this venue, and Carla and the team always put on a good show with plenty of great speakers.

Continue ☛

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 ☛

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 ☛

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:

• Danielle Tomlinson on releasing software
• Maxim Zaks on ECS architecture
• John Sundell on Core Animation
• Paul Hudson on MVC
• Paul Stringer revisiting Storyboards
• Eliasz Sawicki on making builds fast

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

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!

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.

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 ☛

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 ☛

Last Tuesday I gave a talk at Swift London called Swifty? looking at interesting patterns emerging from the community, as well as how Swift 3 will shape idiomatic code.

Continue ☛

I attended the SonarSource City Tour in London today. SonarSource make two “continuous code quality” tools: SonarQube; and SonarLint.

The Radisson Blu Portman Hotel hosted the low-key event with about 50 attendees. We heard several suitably technical presentations from Olivier Gaudin, Freddy Mallet, and Nicolas Peru of SonarSource, and Duncan Pocklington from Microsoft.

Continue ☛

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 ☛

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 ☛

I attended the I ❤ APIs Europe 2016 conference yesterday at Tobacco Dock in London.

It’s a beautiful venue. Originally a 19th century warehouse, this converted space has many conference rooms and lots of exposed brick, wooden beams and vaulted ceilings. It was cold though!

Continue ☛

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 ☛

The API days London event concluded today (September 24th, 2015) with another great set of speakers.

The day began with a pleasant surprise: a shoutout from the organisers for my roundup for the first day! Thanks guys.

Continue ☛

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 ☛

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—

Noob — DILLIGAF?! 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 ☛

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 ☛

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 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 ☛

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 ☛

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 ☛

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

Let’s say we have some legacy code. We’ll use Swift¹ 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 ☛