We ran the second coding dojo this week, a repeat of the first one but with the other half of the office. Again, it went well but was heavily constrained by the time limits of lunchtime.I’m hoping that at the very least, it’s shown people an alternative style of software development that they might try to adopt or apply to parts of their work.

Since I’m leaving the company in a weeks time and a couple of people who were keen to participate haven’t made it due to meetings and project commitments, I have decided to run a final exercise. It’s one of my favourites and something I like to do when learning a new language. It’s the Trigrams kata from PragDave‘s website of code katas.

I’m not sticking with the more traditional coding dojo style this time though. Instead of attempting to cram it into a single session, I’ve thrown it open to everyone to attempt, in the langauge of their choice, in any spare time (or lunch time) that they have spare. I’ll make myself available to assist when they encounter problems, and maybe run a couple of ‘catch-up’ or progress sessions, but other than that, they’ll be left to their own devices. I’ll let you know how it works out.

Ruby Refresher

November 10, 2009

Ruby is a language that I’ve enjoyed working with in the past, but feel I’ve never really built anything substantial with it. I’ve got a Ruby on Rails book that I keep starting but never really get anywhere with. I suspect it’s because I don’t have a concrete task to tackle. The majority of my Ruby code was implementing unit tests for stored procedures using Marjoree, but that was over a year ago and I’ve hardly touched it since. Without regular exposure to Ruby, I’ve all but forgotten how to use it.

I was talking to Paul Wilson about this the other day and he suggested that I go to the Vital Ruby/Vital Rails training he’s running this week in Edinburgh. Sadly I can’t talk my work into either paying for it, or giving me the time off at the moment, so Paul suggested I take a look at Ruby Koans. So I downloaded the beta release of RubyMine (2.0 beta 3)  from JetBrains (have I mentioned that I’m a huge fan of IntelliJ?) and got to work. Ruby Koans “walk you along the path to enlightenment in order to learn Ruby” via TDD. It’s a rather large set of failing unit tests that you have to make pass. Each test demonstrates a feature of Ruby which you have to understand before making it pass. It’s the most fun way I’ve ever seen for learning (or re-learning in my case) a language.

Coding Dojo – Review

November 5, 2009

So we had our first Coding Dojo today and it seemed to go quite well. Our biggest problem was time, or lack of it. Before we knew it we had run out of time and people had to get back to work. Before we ran out of time we had three or four tests passing and were working on some refactorings while wondering what the next test might be. We’re running a second group next week and I’m hoping to get started a little more promptly this time.

I posted the code in it’s latest state and the participants are already adding new tests and code. A kind of distributed coding dojo, and someone said they’d put it into GIT so that’s quite good too 🙂

This is the exercise I’m planning on using in our coding dojo this week. One of the problems I often have with TDD examples is that they are too trivial and it can often be difficult to see the real world application of them. So for this exercise I’ve taken a piece of real world application and sanitised it slightly. Originally I tackled this problem with someone who was unfamiliar with TDD and used it to introduce them. Turns out they hadn’t really understood what it was all about until doing this, so hopefully it’ll benefit others too.

The Problem

We have a system that generates requests for an external system and sends them via a Gateway. The Gateway has been expanded from being able to handle a single request to being able to deal with multiple requests at a time. Our task is to introduce a ResourceScheduler between the application and the Gateway to manage the resource usage.

However, things are not quite as simple as that. Each request forms part of a request group, which consists of, say, 4 requests. The application cannot guarantee that all parts of a request group will be sent on to the Gateway before parts of another group are received.

Where possible, requests from different request groups should not be interleaved…but these are expensive resources so we’d prefer the requests to be interleaved rather than having them sit idle.


  • Gateway has been expanded from a single resource to multiple resources
  • Requests have logical grouping, but the order they’re received cannot be guaranteed
  • Requests from different groups should only be interleaved if there are idle resources
  • The ordering of the request groups is the order in which the first part of them is received
  • The Gateway can call completed() on a Request when it has completed being processed


The Gateway interface

public interface Gateway
public void send(Request request);


The first test

Since I’m a helpful guy, I’ll give you the first test for free:

public void testSchedulerSendsTaskOnToGatewayWhenResourcesAreAvailable()
ResourceScheduler testee = new ResourceScheduler(gateway, 1);
Request request = RequestMother.createRequest();


As you can see I’ve defined the constructor of ResourceScheduler to take an implementation of Gateway and the number of resources we’ll be managing. In this case, I’ve written a little stub for Gateway which allows me to retrieve a List of the Requests that have been sent to it. This is useful for making assertions. There is also a RequestMother class which is used for generating the Requests used in the test.

I’d be interested in any solutions you come up with and no doubt I’ve missed some critical detail, so feel free to point them out.

A coding dojo

November 1, 2009

I’m going to experiment with a coding dojo this week. I’m hoping to show that everyone can learn something new when they start pairing with people and trying out TDD. The response to my invitation was better than expected with only one or two people from the entire office not registering an interest.

We’ll be basing it on the Randori (Finnish) approach with one keyboard/mouse and a large screen so that everyone can see. The first session will have 3 pairs and we’ll be tackling my Resource Scheduler TDD problem. I’ll give them the first test for free then the fisrt pair will make the test pass, write a test for the next pair, then bring in the next pair.

I’ll post up a report of how it went along with details of the problem later.