New podcasts

I've enjoyed a couple of new podcasts lately:

Slate's Working podcast finds people in interesting jobs and interviews them about their workdays. It's brand new. The first episode – with Stephen Colbert – was fantastic. The show is short and dense. David Plotz as the host (along with some helpful editing, I'm sure) gets the guest talking (they usually have a lot to say) and then gets out of the way. I've appreciated finding another non-tech podcast to keep in my roster.

I still have plenty of room for good tech podcasts, though. Thoughtbot have just launched another new podcast, called The Bike Shed, covering their general experiences in web development. This looks like it will be a discussion show with regular hosts Sean Griffin and Derek Prior. They seem humble and grounded, and the first show on Sandi Metz' rules was thoughtful, and directly applicable to my work as a web developer. I'm still thinking over what they shared. I'm also appreciative they've kept the show to under 30 minutes. This makes it easy to cover on a walk into work!

Our Problem with Boxen

Over a year ago, we started using Boxen at Icelab to manage our team’s development environments. It’s worked as advertised, but not well enough. I’m looking for something else.

Our problem with Boxen is that it contains hundreds of different components, all of which are changing, all the time. It needs constant tending. By the time a team is big enough to need something like Boxen, it’s paradoxically too small to look after it properly: to have someone whose job it is to be “Boxenmaster,” someone who knows how these intricate parts all interact and can run the regular clean installs needed to make sure that the experience is smooth for new people (we’ve found it typical for a functional Boxen setup to stay working over repeated updates, while clean installs end up failing). We need a tool that we can set up once for a project and then have it still work reliably 6 months later when we revisit the project for further work.

Boxen can be a trojan horse. If you don’t look after it properly, you risk creating two classes of developers within your team: those who were around to get Boxen working when you first rolled it out, now enjoying their nice functional development environments, and those who get started later, whose first experience in the team is one of frustration, non-productivity and a disheartening, unapproachable web of interconnected packages. And no one is safe: as soon as you want to upgrade that version of PHP, you could slip down there too.

So while Boxen can indeed work as manager of personal development environments, and while Puppet is a serious and capable configuration manager, my recommendation is not to commit to Boxen half-heartedly. In fact, you may not even need something so rigorous and complex if your team is still small. I’m looking into such alternatives right now. I’m not settled on anything yet, but it’ll likely involve virtual machines, and perhaps use Docker as a way to keep it lightweight while working on multiple projects at a time. Fig seems like it could be a good fit. I’ll keep you posted.

Decaf Sucks 2: A New Old Design

The iOS 7 betas are coming thick and fast. If we want to finish the rebuild of Decaf Sucks and ship it close to the iOS 7 launch, we need to be pragmatic with our design changes. We’ll look to change as little as possible, but we still don't want to release the same old app with a slightly different skin. We want to do a little more thinking than this and give people something to make the upgrade worthwhile.

We'll achieve this by focusing on one of the core principles of the new iOS 7 design: deference to content, through a user interface that highlights the content instead of competing with it.

Right now we don't do so well by this measure, even at our very first screen:

The empty Decaf Sucks first screen

Unless our users want to stop and admire our search field and big green button, we can do a lot better than this. This isn't content. It's functionality, and it should be as invisible as possible. A much better idea would be to jump straight to the list of cafes, around the user's current location:

A list of Decaf Sucks cafes in Berlin

When people open Decaf Sucks, it’s usually because they want to find coffee now. The alternative action, looking for a different location, is much less frequent and can be hidden behind a button in the toolbar. It doesn't need prime real estate on the first screen of the app. So what we can do is completely remove the first screen and start showing useful content right away.

This is a good start, but we can do better still, by thinking more deeply about what our “content” really is. It's not just a list of cafes, it's the user's context, their location relative to the cafes around them. It's not enough just to crave a macchiato and see some text saying a café is 200m away; you should also know where that café is and what path you might take to get there. This is where the map view shines. We've had a map right from the app's first release and for all these reasons it's one of the most useful ways to find cafes. But it's still hidden behind a button press. There's no quick way to get an immediate, at-a-glance understanding of the caffeine landscape that surrounds you.

We can solve this by combining the map and list views:

A preview of the Decaf Sucks 2 combined list and map screen

After this, when the user launches the app, not only will it be already primed for their current location, they'll also see the nearby cafes both in a map and a list, and can choose to interact with whichever representation is most useful to them.

These are the main design changes we'll make for Decaf Sucks 2. We'll condense three screens into one and present useful content as early as we can. If this takes you to a suitably excellent coffee a few seconds earlier, then our mission will be accomplished!

Decaf Sucks 2: Starting Over

Decaf Sucks 2: New Xcode Project

They say to avoid the big rewrite. Luckily, Decaf Sucks isn't that big.

Importantly, one of the app's key reasons for being is to give ourselves an opportunity to build something great for iOS. When it comes to great, a lot has changed since the middle of 2011, when we released the app for iOS 4. This includes the development tools, which have grown to include:

  • ARC (Automatic reference counting)
  • Modern Objective-C (literals, object subscripting, automatic synthesizing of properties, no need for private method header declarations, etc.)
  • Storyboards
  • Auto Layout
  • Collection views
  • OS-integrated Twitter & Facebook support
  • Cocoapods
  • And the much improved editing environment in Xcode 5

Getting our hands onto these will make the app more fun to develop and improve our ability to add great new features further down the track. Decaf Sucks was also our first major iOS app. We've learnt a lot since then and there's plenty we can tidy up.

The mobile app development world is moving fast; the list above proves it. For a small app like Decaf Sucks, it makes sense for us to build with the best and latest available tools, and not to handicap ourselves for the sake of the broadest user base (especially when new iOS adoption is so fast). So Decaf Sucks 2 will be built from scratch, and for iOS 7 only. Apple is taking their mobile user experience to a significant new place, and we want to do everything we can to arrive there too.

Check back for the next post, where I'll share some thoughts on our design approach!

Decaf Sucks 2 Is Coming, 2 Hours at a Time

If you know me even a little, you'll know I love drinking coffee. This is why we built Decaf Sucks, as a place to record and share our café experiences. It's turned out that it also offers a great way to travel: finding coffee is usually an interesting axis along which to explore a city. It takes you away from the tourist traps, to interesting neighborhoods, and injects you into the regular lives of the locals. This is how I've explored Bacolod, Tokyo, Hong Kong, and most lately, San Francisco.

It was also in San Francisco that I was lucky enough to attend Apple's WWDC event for 2013. It left me enthused for all the opportunities that iOS 7 affords to developers, and with Decaf Sucks being our biggest stake in the iOS marketplace, I really wanted to take the chance to ship something new.

It so happens that I've just started a 2-week holiday, the first real time away from work in this year's travels. But if you're anything like me, and your work is something you love, then it's unlikely you completely switch off anyway. So I've decided to make the most of this and spend a little time each day on developing Decaf Sucks for iOS 7. It'll start in the mornings: I've been waking up early lately, giving me a whole 2 hours or more before the day really begins. This is how I'll be developing Decaf Sucks: 2 hours at a time. It'll be an exercise of doing a lot with a little, of the bootstrapped side-project.

In the spirit of my last Decaf Sucks development sprint, I'll document my progress here, before slipping my iPhone into my pocket and setting off each day (likely in search of the morning's first coffee). Watch this space!

Sneaking Into the Everyday

Standing in cold, pre-dawn WWDC keynote line, I met a couple of the friendly Mac & iOS engineers from 6wunderkinder, makers of the beautiful Wunderlist apps. I'd tried Wunderlist in the past, but some weeks later, I thought I'd give it another go. Turns out, it's been great! Just the mix of power and simplicity that I need to stay focused on my tasks.

This change made me realise that quite a lot of my most-used tools are also things I'd picked up only in the last year or so. On the Mac, they are:

And on iOS:

All this has happened without any particular conscious effort. Apps come to my attention, and if I like them, there's a good chance they stick around. Granted, as a software developer I may be more curious than most, but I still take this as a heartening thing: no matter when you launch, if you offer something better or compellingly different, you stand a real chance of finding your way into people's everyday.