We dragged ourselves back to day 2 following a great party from the night before.
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.
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:
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
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.
What a great conference!
iOSCon 2018 just finished and I had a great time hearing and meeting some excellent speakers and attendees.
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
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 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.
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.
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.
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.
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.
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.
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.
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!
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?
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…)
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.
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!
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?
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.
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.
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:
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.)
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.
To me, test-driven development (TDD) sometimes feels like a game of chess between red and green pieces:
- Red’s turn: write a failing test.
- Green’s turn: counter the move by writing code that passes the test.
- 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.
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:
This (ostensibly) produces an IPA we can upload through Application Loader to iTunes Connect.
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:
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.