28 October 2012
When I lived in London I used public transport a lot. Who doesn’t? But for some reason, which I don’t remember now, I started keeping my used travelcards in a box. I also asked Martina, my partner, for hers. As you can imagine, over the years we ended up with quite a collection. In fact, we had to buy travelcards until we moved to Clerkenwell late in 2006 because the station in Hackney, where we had lived before, didn’t have Oyster card readers.
Stumbling across the box when we left London I had an idea: If there’s post-it art, why not make travelcard art? I took a few years but now I’ve finally done it. The Travelcard Invader has arrived.
23 September 2012
Three years ago, unhappy with Apple’s hardware lineup, I decided to dip my toes into the Hackintosh world. It was a resounding success and the machine I built back then has served me well. So, last month, with Intel’s Ivy Bridge and Apple’s Mountain Lion out, I decided to build another Hackintosh. I have written up my experience in this article.
7 September 2012
When a new IT solution is needed in an enterprise, maybe because the business is changing or maybe because an existing manual process should be automated, the people who are in charge of implementing the solution usually quickly get to the question: should we build the solution or should we buy a package? For a long time the accepted wisdom has been to always buy when possible and only build when no suitable packaged solution exists in the market.
In this article series, which will eventually be published in this book, I want to explore the reasons behind the existing preference for buying and, more importantly, I want to challenge the accepted wisdom and explain why I believe that the changes that have occurred in software development over the last decade have shifted the answer to the buy-or-build question away from buy and more towards build. I am not going as far as suggesting that build should be the new default but I think building software should be considered more often and it should be considered even when a suitable package exists.
1 November 2011
Over the past few months I’ve spent a fair bit of time on a project using my MacBook Pro for development. This got me to run CCMenu again and, perhaps predictably, made me work on that in the evenings. While doing some long overdue refactorings I came across the need to construct domain objects in unit tests. So far I had used simple helper methods in the unit test itself, but the Java/Scala project I was on during the day made heavy use of the Builder pattern with fluent interfaces, and that got me thinking.
In the end I’ve come up with three variations of the Builder pattern in Objective-C, all of which have their pros and cons. In this post I want to show these patterns and invite comments on which one you prefer.