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.

Read the rest of this entry »

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!

• JAX London 2010
• JAOO 2010 (in Århus, Denmark)
• Devops Days 2010 Europe (in Hamburg)
• Railscamp Hamburg
• Lean & Kanban eXchange (in London)
• OOP 2011 (in Munich)

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.

As a consultant I often find myself in a position where I have to get to know a large existing code base quickly; I need to understand how the code is structured, how well it is written, whether there are any major issues, and if so, whether they are localised or whether they are spread throughout the code base. To get a feeling for the general quality of the code I have found Toxicity charts useful. To understand the structure, Dependency Structure Matrices come in handy. Conceptually somewhere between those two lie metrics tree maps, which I want to write about today.

A metrics tree map visualises the structure of the code by rendering the hierarchical package (namespace) structure as nested rectangles, with parent packages encompassing child packages. The actual display is taken up by the leaves in this structure, the classes. Have a look at the following tree map which shows the JRuby code base, without worrying too much about the “metrics” part yet.

At the top right I have highlighted the org.jruby.compiler package. The tree map shows that this package contains a few classes, such as ASTCompiler and ASTInspector, as well as three subpackages, namely impl, ir, and util, with util for example containing a class called HandleFactory, visible on the far right. (Visible in the full-size version.) In the following I explain how the tree maps visualise metrics, and I will explain how to create such maps from Java source code. As usual, adapting this other programming languages is relatively easy.

Read the rest of this entry »

This is just a quick post to raise awareness for a technique that has been around for a while. In software architecture a Dependency Structure Matrix (DSM) can be used to understand dependencies between groupings of classes, that is packages in Java and namespaces in C#. There are obviously other uses, and this Wikipedia article has more background information.

Returning to classes and packages, the following matrix shows a view of some of the core classes of the Spring framework:

In this typical package DSM the packages are listed on both axes. If a package has dependencies on another package, the number of dependencies is listed at the intersection. The package that has the dependency is on the top, the package that it depends on is on the left. In the example above the matrix shows that there are seven dependencies from the beans.propertyeditors package to the core.io package.

Read the rest of this entry »