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 »

The practice of continuous integration is gaining widespread adoption and almost every project I was involved in over the past few years used a continuous integration server to maintain an up-to-date view on the status of the build. Developers can look at the status page of the server or use tools such as CCTray and CCMenu to find out whether a recent check-in has broken the build. Some teams also use build lights, like these for example, or other information radiators to make the status of the build visible.

The reason why developers need an up-to-date build status is a common, and good, practice: new check-ins are only allowed when the build is known to be good. If it is broken chances are that someone is trying to fix it and dumping a whole new set of changes onto them would undoubtedly make that task harder. Similarly, when the server is building nobody knows for sure whether the build will succeed, and checking in changes would make fixing the build harder, should it fail.

To recap: the build must be good for a developer to be able to check in. On one of our projects this was becoming a rare occurrence, though. In fairness, the build performed fairly comprehensive checks in a complex integration environment, involving an ESB and an SSO solution. The team had already relegated some long-running tests to a different build stage, and they had split the short build, ie. the build that determines whether check ins are allowed, into five parallel builds, bringing build time down from over 45 to under ten minutes. Still, developers often found themselves waiting in a queue, maintained with post-its on a wall, for a chance to check in their changes. Not only that but everybody felt the situation was getting worse, that the build was broken more often. This was obviously a huge waste and I was keen to make it visible to management using a visualisation.

Read the rest of this entry »

To begin with an antipodean image, using a service-oriented architecture, when it works out, can be as elegant and exhilarating as surfing on a 10 meter wave, exploiting huge uncontrollable forces to move forward at great speed. However, unfortunately, and maybe much like in the surfing world, the SOA wave often mercilessly rolls over a hapless development team, leaving them confused and wondering whether to give up on the idea or to paddle out again.

Despite its complexity a service-oriented architecture is high on almost every project’s wish list. I have been involved in eight projects over the last year, sometimes directly delivering working software, sometimes reviewing or advising, and out of these eight projects six were, according to the respective architects, building a system with a service-oriented architecture. On these projects I have come across two recurring uses of language around SOA that I found noteworthy.

Firstly, SOA used to, and still should, stand for an architecture that is service-oriented, with “architecture” being the noun. What I have found, though, is that more and more often people use “SOA” as an adjective and then add it to a more or less random noun, such as “approach” or “model” or even “architecture” again. Yes, I have heard people talk about an SOA Architecuture more than once.

This use of language highlights a problem. Sticking the three letters “SOA” onto a random noun, without pronouncing what the letters stand for, makes it easy to forget what this was all about in the first place. In fact, it seems that “SOA” is now put in front of words such as “approach” simply to make something sound contemporary; as in: “How’s your project?” — “Oh, we follow an SOA approach.” Given my experience, chances are that the project’s architecture is not service-oriented. It might use WS-* standards, though.

Secondly, there are people who are referred to as SOA professionals or similar. It usually sounds like it’s their job to build SOAs. But what does that really mean? Shouldn’t developers built software according to a service-oriented architecture? Are the SOA professionals merely advising teams on how to build service-oriented architectures correctly?

In my experience the SOA professionals have a different agenda, and that is to sell SOA. Unfortunately, in the words of my colleague Jim Webber, there are two things money can’t buy: love and an SOA. Again, using the three letters one might think “why not?” but spelled out, would anybody argue you can buy a service-oriented architecture? Or any architecture for that matter? So, what is really being sold is usually a set of products, software and/or hardware, that may or may not help a team implement a service-oriented architecture.

The key problem in this case is that when you “buy SOA” the success criteria shift. It seems that success is defined based on whether something that can be labelled “SOA” is in place, and not whether actual business value is delivered. What is often completely forgotten is an evaluation of the suitability of the architecture, but that’s a topic for another post.