everything is nicely packaged as rpms and debian packages so it can easily be installed within 5 minutes (it really works). even better, the packages at the same time pretend to be ruby gems, so you can safely install other debian packages *and* gems that depend on one of the libraries provided by rubyworks.

now we had already set up a cluster of 6 servers for autoki with everything set up more or less perfectly so why would we need rubyworks? answer: to steal the config files for runit/monit and haproxy. our mongrel setup has always been a bit shaky, especially when it came to restarting the mongrels after a deployment. after using the rubyworks setup with runit now everything is stable. (btw runit can run and supervise any process in *nix and is ready to be the successor of the old init which is used by most linux distros to start up all the processes. one advantage is that it starts all processes at once instead of piece by piece, plus runit handles putting a process in the background and keeping it alive there, something mongrel is especially bad at).

anyway, when thilo installed mingle from one of the cds given out to all conference attendees we first were a bit disappointed. after the installation you basically get a nice looking but totally empty screen leaving you with not much more than a big question mark over your head. we didn’t have much time then so that was it for mingle until i attended the corresponding session where things got a bit clearer: mingle is a completely customizable tool. the only thing that’s hard coded are users and cards/stories/tickets/you-name-it and that everything is a wiki page – the rest is up to you. the main features are these:

• define your own attributes for your cards: you can add new attributes to your cards and in place edit all of them – auto complete shows you a list of values that have been entered into that field before
• filter cards by any combination of attributes and save the filter, after which you can add it as a tab on the top
• card transitions – create a set of transitions where a card with a specific state can be transitioned to another state, e.g. from status open to status accepted and assigned to a person. this enables the project team to map their work flows into mingle
• create graphs and tables from the cards – multiple graph types are supported for easy tracking of iteration progress or number of bugs etc.
• project templates – so you don’t have to sit in front of a blank screen as we did

mingle looks like it could become a really cool tool. after all, trac is getting a bit boring after all these years(?) and we’ve actually stopped using its ticketing system, because it wasn’t easy enough to change it to our needs.

A Half-day of Behavior-driven Development on Rails (rspec)

This was the first session on tutorial day and for me one of the most interesting. It basically gave a looong introduction to behavior driven design, how it evolved from things like TDD and who realized what while enganged in which project back in the good old times. One of the interesting parts for me was when they talked about the whole story writing/specification process. I had heard most of it before but it was a good refreshment. The central statement was to write “Software that matters”, and to achieve this, you’d have to get the specs right – as we XPers know this should be done by collecting user stories. The suggested format for such a story was this:

As a [role]
I want [feature]
so that [outcome]

Example:

As an administrator
I want to see the list of users
so that i can choose which one to delete.

Great, a template for writing story cards. Following the story, you need an acceptance test that verifies that the story has been implemented. The suggested format is this:

given [context]
given [more context]
when [event]
when …
then [outcome]
then …

Example:

Given i am logged in as root
Given a list of users
When i view /users
Then i see all the users

Now in the early days you would write this on a story card or on some other maybe non-digital, maybe digital surface, but you would not do this: run the acceptance test as code. (I’m aware there are some projects who’ve tried/done it but I’ve never found one too convincing and really used it). Now you can. They actually implemented a new feature in rspec trunk called StoryRunner to do exactly this and here’s how it looks:

Story ‘As an administrator
I want to see the list of users
so that i can choose which one to delete.’ do

Scenario ‘logged in as root with 2 users in system’ do

Given ‘i am logged in as’, ‘root’ do |name|
@user = create_user :name => name
post /sessions/create, :name => name, :password => @user.password
end

Given ‘a list of users’ do
@users = [create_user, create_user]
end

When ‘i view’, ‘/users’ do |location|
get location
end

Then ‘i see all the users’ do
@users.each do |user|
response.should have_text(user.name)
end
end

def create_user
…
end

end

end

How cool is that, but it doesn’t even stop here. You can now reuse the code blocks you have created (!!):

Scenario ‘logged in admin with no users in the system’
Given ‘i am logged in as’, ‘root’
Given ‘there are no users’ do
User.delete_all
end
When ‘i view ‘, ‘/users’
Then ‘i see a message that there ar no users’ do
response.should have_text ‘nobody there’
end
end

Ok, technically speaking it’s actually not much more than reusing code but the way it’s done in StoryRunner, you are almost forced to create your own, application specific testing DSL! (Did I mention how fantastic this is?). For a better example which includes a “normal” rails integration test and compares it to an rspec story implementation see the evang.ei.st blog.

Of course they also showed the “usual” rspec stuff (referred to as “classic rspec”) for specing models and controllers. I you haven’t already go back to the evang.eli.st and check out Easy Controller Tests and Expressing Intent Through Expectations – a really good (imho) introduction on writing controllers using test spec first.

Enough for now, I’m sure there will be more on rspec here soon.