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.
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.
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.
So, I’ve just moved back to Europe after three fantastic years in Australia. One thing I’ll miss for sure is living just a few minutes away from the beach, but on the upside I’m now in easy travelling distance to a lot of great conferences. The following is a list of conferences and gatherings that I’ll be at, and in some case will also speak at. Hope to see you at one!
By the way, you’ve probably noticed that I updated the theme of this site to reflect my new hometown, Hamburg; the picture shows part of the town hall.
Great contributions from the community keep coming to OCMock and I’ve now rolled them into a new release.
A major focus of this release was improved support for iPhone/iOS, and I’m happy to say that OCMock can now build as a static library for iOS and it fully supports tests on devices. There is also improved documentation on the OCMock website and an iPhone example app that shows in detail how to set up a project.
Other features of this release are support for blocks, both for call verification and argument checks, a new method to forward calls from a partial mock to the real object, which can be useful in cases where you want to verify that a method is called but still rely on the real implementation, and, last but not least, a method to reject calls on nice mocks.
More details on the OCMock page at Mulle Kybernetik.
I'm Erik Dörnenburg, a software developer with an interest in using visualisation techniques to better understand code and architecture.
more »