Hamcrest 1.0

An unexpectedly popular feature of jMock has been its library of Constraints. A constraint is a very simple object: it returns a boolean indicating if it matches another object and can describe itself. People have found this very useful. As well as extending JUnit's assert method, jMock constraints have been used for validating user input, filtering streams and collections and describing validity rules for incoming messages. However, people have felt uncomfortable using them in production code because they are part of a testing library.

Well, they need worry no more. Joe Walnes has pulled the constraints out of jMock into their own library called Hamcrest. Along the way he has renamed them to Matchers — "Hamcrest" is an anagram of "matchers" — and made them work with Java 5's generic type madness.

Hamcrest is split into two layers. A small, stable core API that defines the Matcher interface and abstract base class itself and a large library of matcher implementations. The intention is that the code API will change slowly to provide a stable base for other projects but the library will grow quickly as users contribute new matchers. Users will be able to drop new library releases into their codebase to extend the matchers available without breaking any libraries that are themselves dependent on Hamcrest's core.

The release of Hamcrest 1.0 should enable better integration between projects that provide or need matching. For example jMock 2 will use Hamcrest matchers instead of its own constraints and the Get In Line text pattern matcher is also a Hamcrest matcher. This means that jMock 2 users will be able use the Get In Line embedded domain-specific language to define text patterns in their expectations.

Comic Life (and Work)

Chris Rimmer (on the right in the picture) presented an excellent comic-book style poster at XP Day to publicise the Oxtremists study group in Oxford.

That got me thinking... would a comic book be a good form for end-user documentation? It would be fun to write, would be good for showing graphical user interfaces and comic books have well known conventions for annotating pictures with to show movement and sound and direct the readers attention to detail.

I'm not the only one to think this. The developers of BJS, an open source game project, had the same idea and have already published their user manual as a comic book.

Update: Sun used the comic book form for the user documentation of their AnswerBook product way back in 1991.

Update:These graphic resources could be useful for writing comic-book documentation.

Update:Kevin Cheng has posted a list of resources for creating comic book content for design and end-user documentation.

Scrapheap Challenge, PoMoPro, London, November 2006

Ivan and I ran our Scrapheap Challenge workshop at the PoMoPro conference at the end of November.

The results were quite similar to our previous experience at OOPSLA in 2004: shell pipelines and dynamic languages that can easily run other programs won the day. Unlike last time, a few pairs had some success with Java. However no winning solution used Java and no all-Java solution was completed within the time frame.

As Ivan noted, the process that pairs followed had as much if not more of an effect as the technology they used. Unlike last time, not all pairs actually did pair programming. Some split the solution into parts and worked independently on separate modules and then brought them together for integration. Pairs that did pair programming did noticeably better than those that split the work into individual tasks. From what I observed, I don't think that pair programming itself was the decisive factor. Pairs that split the work were hit by integration problems at the end of the challenge that were too great to solve by the deadline. Pairs that pair-programmed grew the software incrementally and always had a running program. The only pair that did well when working independently integrated every 15 minutes or so instead of once at the end.

A valid criticism of the workshop was that our challenges were could easily be met by batch programs and involved a lot of text processing, so they were biased towards solutions using Unix-style pipes and filters. Next time we run the workshop we'll throw in some challenges to build interactive desktop applications so that Unix pipelines don't have such a strong advantage. If you're going to be at SPA 2007 on the Sunday, brush up on your GUI skills and show those Unix developers what real programming is all about. I hope some Smalltalk, LISP or J developers will turn up and demonstrate the obvious superiority of those development environments (instead of just talking about it).

Fairly Good (and Staggeringly Bad) Practices

Inspired by fairlygoodpractices.com, informativeworkspace.org and various conversations at XTC I create a poster about Fairly Good Practices for XP Day. The poster showed a some good practices from teams I've worked with or talked to.

• At EasyNet the team have made South Park-style caricatures of all team members. They have laminated versions on the planning board that are used to indicate who is working on which story or is available to help with production issues. The caricatures are also displayed by the Build-o-Matic build server to show who committed the changes being built, who contributed to which version and, occasionally, who broke the build. Ivan has written about that in more detail on his blog.
• At Google the testing group run a "Testing on the Toilet" campaign to help programmers to improve their testing skills. They put posters about testing techniques on the toilet walls and above the urinals!

I left space on the poster board for other delegates to pin their own ideas. Here's what had been pinned by the end of the conference:

• Always identify who wrote a TODO in the TODO comment itself.
• Annotate story cards with a common set of markers when the work for the story has been started, is ready for sign-off and has been signed off.
• At the start of every iteration read all the TODOs and turn them into tasks, delete them or put them in the list of future work. Also skim the future work list and delete items that are no longer needed.
• Connextra used to post the current bug-list on the back of their toilet doors.
• Don't worry about being right all the time, only about being right at the end. P.S. there is no end.

Chris Cottee responded by creating his own ad-hoc poster about Staggeringly Bad Practices seen on real projects. Sadly his poster attracted more contributions than mine even though it started out as one hand-written index card. Here's what was on his board by the end of the conference:

• Keep some regression tests always failing to break up the monotonous green colour.
• Put all your logic in one SQL statement that is hundreds of lines long. [Wimps! I've seen application logic in SQL statements that are tens of thousands of lines long]
• Our supplier ceased documenting their core API because of "lack of resource". They still kept changing it, though.
• Replicate the same data twelve times in four sets of tables and build reconciliation between them.
• There's no point in putting code into source control until we know it works in production.
• Every time you have a "bad" day drop a practise and get everyone to reestimate everything until people begin rocking back and forth under tables.
• We lost the source code and decompiled from production.
• Use production passwords in development because it makes it easier to refresh the databases.
• Don't delete unused code: exclude it from the source fileset in the Ant build file.

Thanks to everyone who contributed... whoever you are.