The main features of this release are partial mocks and method swizzling. Sometimes it’s just easier to use a real object rather than setting up a complex mock from scratch, but often in such cases there is at least one method on the real object that has undesirable side effects, or a method returning a value that we would like to change for a test. With the new features in OCMock it is now possible to selectively replace individual methods on existing objects. Did I mention that I love the Objective-C runtime?

As usual the release also includes many contributions and bug-fixes from the community. More details on the OCMock page at Mulle Kybernetik.

Over the past years I have shown everyone who could not run fast enough some of the tools based on Moose. And even now I cannot resist putting a screenshot of CodeCity into this post.

Most of the Moose tools now use the MSE file format as an interchange format. By the way, if you are interested in writing your own visualisations or analysis tools it is probably worthwhile looking at MSE, reading this format is so much more convenient than parsing source code.

In Java it was always relatively easy to create MSE files. Among many other things, iPlasma can read Java source code and export to MSE. That said, iPlasma has so many interesting features itself that oftentimes no export to an external tool is necessary.

For C# the story was different and for one reason or another no tool existed that could create MSE files for C#. This has changed now. As a student project at the University of Lugano such a tool was written and, thanks to Michele Lanza, then donated for general use. I’ve made a few improvements and put the code into this Bitbucket repository.

At some point last year I was asked to review the architecture of the software behind a large and popular website. The resident architect explained how he had followed a modern approach, decoupling the web front-end from back-end services that provide content. To gain further flexibility he had put the front-end and the services on an ESB, mostly to cater for the possibility to make the content available to other consumers. In short, the architecture diagram looked a lot like many others: nothing to see here, move on.

The diagram above only shows one of the content services, which for the sake of this article is a service that provides contact details for a person.

Based on conversations with the project sponsors I began to suspect that at least the introduction of the ESB was a case of RDD, ie. Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV? Talking to the developers I learned that the ESB had introduced “nothing but pain.” But how could something as simple as the architecture in the above diagram cause such pain to the developers? Was this really another case of architect’s dream, developer’s nightmare?

Read the rest of this entry »

Admittedly, I’ve been struggling with the “Architect” title in the IT world. It is not that I think there’s no role for architecture, far from it, but too often I’ve encountered architects who focus too narrowly on architecture, losing track of the realities of actual software development and the context in which the software will be used. I wonder, if there was no “Architect” title and people who are responsible for architecture would be called guide or coach or tech lead, or just the senior developer, whether things would be better.

About a year ago, in a discussion about architects, rather than trying to define what an architect is or does, we looked at what he or she should know. We expressed our ideas as mini-essays, strictly limiting ourselves to one per essay, and it turned out that, at least to my surprise, there was a lot of agreement; maybe because we hadn’t come up with hard and fast rules but with ideas and guidelines.

Luckily Richard Monson-Haefel was part of that discussion and he had the resolve and means to make our thoughts more widely available. Our list of the 97 things every architect should know was collected and refined on this wiki, and is available under a creative commons license. For a more convenient read it has now also been published as a book by O’Reilly. As expected, the discussions have begun.

The JAOO conference is coming to Australia again, and I think it will be the best technical conference in Australia this year. (I admit that I’m somewhat biased as a member of the programme committee.) In the lead up to the conference we have organised what we call JAOO Nights in Brisbane, Melbourne, and Sydney. These are free events, starting at 5pm with two speakers presenting on topics that give a flavour of what the JAOO conference itself will be like.

Check out the JAOO Australia site for information on the sessions, and sign up for your city if your interested!