The previous entry on continuous testing stirred up some discussion. Marko shows a script he wrote to save and test with vim , Nico dug into the rails setup, and found a way to have rake run only tests that changed in the last ten minutes (and then decides to refactor his blog while I’m writing, so I can’t quote him on that…) and I got an e-mail from June Kim with a very nifty solution to run tests continually, exactly at the time files have changed. I also found an earlier discussion on a testing list about using the ‘watch’ command, to look for changed but I can’t find the discussion back right now, so maybe more on that later.

I’ll comment on Marko’s solution first, and then I’ll discuss the (very nice) results I got with June’s script.

Marko’s script runs tests in vim, at the time of saving. Although this is very useful, I have hat in scite too (press f5 and the current file is ran), so this isn’t exactly what I’m looking for.

Based on a telephone conversation with Marko, I’ll try to refine the statement of what I want. I want tests to run ‘inside out’ Imagine a spiral, with the unit test for the bit of code you’re currently editing to be the focal point. Ideally, I’d want a test to run first for the method I changed last, then for the whole class, then for the suite the class is in, then further out to other dependencies. Tests run outward only when green bars are encountered. If there is a red bar somewhere, the spiraling stops, so we can examine the failure, fix it, and see again from the inside which tests run.

Usually, the further out in the spiral I am, the longer the tests take to run, so I want to run (and fix) the quick running tests inside the spiral first. If I don’t edit for a while, or go for a break, I want all the tests to run, including (at the end, when everything else is green) the integration/acceptance tests.

So, I like Marko’s script, it’s easy to modify, but it doesn’t run continuously, spiraling outwards. The other refinement in my wants, is that I want the run script to be independent of a specific editor. Everyone has their preferences. I can’t stand either vim or emacs. Actually, I have learnt to stand vim for a couple of lines at a time for systems administration tasks, but if I’m programming for a couple of hours, I want something that is modeless, has a mouse too and uses (keyboard) shortcuts I can actually understand (like ctrl-s for saving, and ctrl-mousewheel for zooming). If the script runs separately, any (one or pair) can work in the editor of their choosing, or whichever editor happens to be present at the time. Maybe, like Nico, I’m to young to enjoy working with vim.

I got an e-mail from June Kim, about a continous build script by Ward Cunningham for use with the IO Game :. It’s about seven lines of shell script, which is a bit more than the one line from the previous installment…

The extra lines are more than worth it, however! The script (like the last one) works on one file, checks for modifications in this file and runs the tests only if it is modified. The greatest thing about this one is, that if you save the file while the tests are running, it will kill the tests and start over. This setup seems excellent as a starting point for spiraling out testruns. Except for the fact, that I’m not really comforting with programming shell scripts (and this time for a change, I’m going to stay in my comfort zone), and some of my co-programmers use the windows os, for which the script doesn’t run (yes, it may run under cygwin).

Lucky for me, June has made an adaptation of this script in python . It is more lines, but for me much easier to modify. And, as a nice benefit, it tells us the time since the last testrun. This may tell us something about our courage…

The output looks like this, showing the current time, time of last run, the differences, and the time elapsed since the last run.

$ ./rerun.py sorting_grid_test.rb ruby


sh: line 0: kill: (12077) – No such process



[+] You changed…

previous Mon Dec 19 14:09:05 2005


+ current Mon Dec 19 17:28:27 2005


@ -3,7 +3,7 @


require ‘sorted_grid’


require ‘person’


-


+


class SimplePeopleGrid < UIBuilders::SortedGrid


def initialize


super


[+] 199m 22s elapsed since last run


[+] 14270 started


Loaded suite sorting_grid_test


Started


.FFF…..F


Finished in 1.782504 seconds.


1) Failure:


.... you know the drill

By the way, I got stuck writing this blog entry,because Python’s subprocess.Popen works differently on Linux (or cygwin) than under plain windows. If you want your run scripts to work on both, use the variant that takes a list of strings (e.g. subprocess.Popen([‘ruby’,’mytest.rb’) rather than subprocess.Popen(‘ruby myprocess.rb’)). I prefer to refer to code that has actually worked for me, and now it does .

Nico suggested, that having an all.rb file is duplication. I disagree. Rob and I use a simple script for a course that works with wildcards for files, so no need to change when files are added – it simply takes *test.rb in all subdirectories and runs those by requiring them. It works like this (we made it more fancy in reality, but you don’t have to do that):

!/usr/bin/env ruby

a couple of lines to make ‘require’ in subdirectories work

removed here…


require ‘test/unit’


Dir[’*/test.rb’].each {|t| require t}

The run script in Hourensou is longer, I don’t know why (yet) exactly.

I’m very happy with the results so far. Having tests run all the time, and seeing the changes is cool. I learnt a lot from pair programming with Rob, and from Marko’s, Nico’s and June’s responses.

In a next increment I hope to make a combination between June’s script and Nico’s suggestion to let rake do (part of) the work, or to extend June’s script so it watches all *.rb files in a directory. After that, I’d like to see how it goes for a directory tree, running from the leaves inwards.

As the year is running to an end (I was quietly hoping for it to crawl, but it’s defininetely running), there’s new events to announce.

In case you’ve missed these announcements from Marko ’s weblog:

• XPNL new years drinks , January 3d, King Arthur Cafe, Utrecht, The Netherlands

• Agile Open 2006 on April 27 and 28 (Thursday and Friday) Mechelen, Belgium.

The new years’ drinks are extremely self organised, Agile Open a bit less, as a two day conference takes a bit more preparation. We have yet to refactor the agile open wiki, we hope to do that later this week. The wiki has been temporarily closed to the public due to spam attacks. This year, we’re aiming to keep Agile Open as cosy as last year.

Discussion about a possible theme and to theme or not to theme agile open are still ongoing.

One thing is certain, we’re not going to have a keynote speaker, as the participants will have to make the program themselves, like last year. So I hope you consider visiting agile open, run a session, or post a question, even if you don’t know how to run a session (‘If you can’t afford to run a session, a facilitator will be provided for you’ ).

Yesterday in Mechelen, at the pair programming party, Rob westgeest and I tried out a different way of running tests often. We were working on a  mini-feature in Hourensou We had been having some trouble with the tests before. We were using a freshly installed machine, with only a couple of simple text editors (scite and gedit) present. We wanted to run the tests often. However, I dislike having to switch from window to window all the time (in this case, switching from an editor window to a terminal window with the tests).

Therefore, we tried something simple: run all the tests in a loop, continuously. That way, if we saved, we only had to wait a little while for the tests to run of their own accord. The loop was written in bash shell script, so we get a fresh ruby interpreter each time the tests are run (the alternative was to use irb, the interactive ruby interpreter with a loop around a bunch of ‘require’ statements). We used ‘nice’ to make the tests run at a lower priority than our other processes. The tests are contained (in this case) in all.rb:

while true; do nice ruby all.rb ; done

Having the tests run all the time had an interesting effect. We were even more motivated than usual to make all the tests run, and errors were spotted quickly – just sit back for a moment, relax, and watch the testsrun. Reading the failure messages was a bit more difficult though; as the tests keep on running the results keep scrolling upwards.

I don’t know a simple way (yet) how to run tests only if files are modified. Possibly a rakefile could work, but that’s already a lot more work than the one line of bash script we came up with as the simplest thing that could possibly work.

A customer passes by

screaming

Storycards rustle on the wall

(inspired by Daily Scrum Haiku posted by Simon Baker ).

So, finally, here are my pictures from XP Days London last week. There’s quite a bunch, this time they are grouped by session. I’ll select one from each as a taster.

`Five People in a cab

staring at red lights

A haiku on the table`

Pictures from the eXtreme Tuesday Club

`Lego is so cool`

Pictures from the agile architecture workshop

`Subverting metrics is fun`

dark Pictures from the Do you get what you measure? workshop

`The map is not the terrain`

`it really isn’t`

Dead fish, and other miscellaneous pictures

I found a blog entry by Cedric Girard in French, about xp days Benelux. It’s cool. I hope you can read french, because some of his appreciations are untranslatable.

Cedric writes about how he found the values of Communication, Simplicity and Courage in the way the conference participants gave one-minute presentations on sessions they attended, at the end of the conference. Honest, direct and simple, as he puts it.

We had scheduled one-minute presentations by session organisers on both mornings (Cedric uses the word ‘conferencier’, which means comedian in dutch – several of the presentations were hilarious). The intention was to give participants a more accurate feel for the sessions than a piece of paper or a title can possibly give.

Then, at the bar on Thursday, someone suggested to Vera participants do the same. We decided (courage!) to give it a try. The one minute presentations by participants were as funny as those by presenters, and we got a feel for those sessions we wished we’d attended.

I’m curious who suggested it by the way, as the suggesters’ identity has disappeared in the fog of excellent conversation and drinks apparently .

I measure a decent conference program by the difficulty one has to choose a session – in each timeslot there should be at least two sessions that you really want to attend. Judging from the participants’ presentations and the reactions to them, we succeeded .

In “the previous entry”, I was complaining that I couldn’t find a paper or photo’s of the drift table. Simon Baker informs me this blog entry by Andy Pols has some photo’s of the drift table.

Andy also provides a reference to a paper that is readily downloadable: The drift table, designing for ludic engagement .

Images courtesy of www.interaction.rca.ac.uk/equator/steve_drift_table.html

And, like Andy, I want one!

Well, XP Days London was Fun again. I’ve had a peek at the many photos I took, I’ll publish them later this week, as Rob and I are currently busy preparing the next eXperience Agile course.

In the meantime, I recommend what some other writings on sessions I went to.

• Marko van der Puil on our Temperature Reading Session

• Simon Baker and Pascal van Cauwenberghe on I’m not a bottleneck.

I normally have a funny feeling with keynote sessions. I’ve become so accustomed to interactive sessions, that I find sitting for an hour at a time, watching the slides go by to be a bit boring. Unless the presentation is really engaging. William Gaver ’s presentation on Ludic Design was such a presentation. Unfortunately, I can’t find the videos he used (made by a documentary filmmaker) online. These videos showed very effectively how the drift table (a coffee table with a lense in the middle that lets you drift over the english country side as if you were in a hot air balloon) and another device were used in different ways than the designers anticipated.

It resonates with something I’ve observed from practice quite a bit – people will use your system in ways you’ve never expected. I prefer to be creative with it, and see what we can learn. Others seem to prefer saying `Bad User! This is not the way the system was intended!`…

rant

(Unfortunately, the papers on the drift table (probably written on British taxpayers’ money) seem to be locked behind ACM’s Portal, you have to be a member to access it… Don’t you just love how academic publishing works… ).

/rant

Dave Pollard writes about atomization of software  by using peer produced software consisting of small building blocks. This is a story about how changing only four lines in a template, can make people feel much more welcome in editing a website. I don’t want websites and their ‘back ends’ to be merely usable, I want them to be hospitable (or with a reference to Christopher Alexander, habitable). I’ve been using Wiki2Go produced by my peer Pascal van Cauwenberghe. (by the way ‘toffe peer’ means cool dude in dutch ). It already has a plugin interface on the server side, allowing us to plug in graphs with very little effort. Something that has been bugging me about wikis was what I once considered a feature.

To me, a couple of years ago wikis attracted me for those two main features:

• Easy associative, serendipitous linking by using WikiWords (use a word with several capitals, and it becomes a link. If the corresponding page doesn’t exist yet, you can click on the ? link that appears after the word to create it).
• Easier text formatting than plain html (e.g. by using a * to make a bullet).

With the growing number of wiki implementations that each seem to have their own preference for text formatting, the second one became less and less important. Actually, all those different text formatting engines became annoying. I even developed a prefence for writing in html directly, as that is at least standardized.

I have ranted before about how content management systems can get in the way of my writing process. These days I get to work more often with casual users, for whom the venerable ‘blank text box’ is threatening. You can see a ‘traditional wiki edit screen’ in this screenshot (taken from systemsthinking.net which I co-host):
 

Notice the subtle finger lifting at the text in the bottom ("if you edit, please remember to do it in GoodStyle"), making the bar for a passer-by to edit even higher.

I was ranting to Ira Weinstein about the lack of hospitality in editing websites. He pointed me to fck editor (I find the name a bit dumb, but who am I). Basically, it looks like a regular word processor inside your html place. I was so intrigued by this, that I had to do an experiment with it. Rob Westgeest and I spent half an hour on a spike to add it to an existing wiki. That was enough. It worked. Five different lines in the ‘edit’ template of a wiki, and adding an fckeditor directory on the webserver and that was it. We spent another half an hour trying out the various features, going ‘this is cool, and this, and this…’.

The following is a screenshot from the private wiki on satirworkshops.com, one of several new sites I’m building. I am working with Marc Evers on a handout for the Balancing Act workshop:

(the Satir Change Model picture and the site layout in this screenshot are provided by Nynke Fokma.)
Notice the three rows of icons on the top of the edit box. The ‘page title’ box and the ‘save’ and ‘undo changes’ buttons are the same as in the previous screenshot. Otherwise, the page is pretty much shown as it appears when you’re not editing it:

I find editing a wiki page like this much more comfortable. I often used to click ‘save’ every couple of seconds to see if I formatted bullets correctly, or if the links looked as expected. Now I can keep on typing and adding images, and I save when I’m done, or when Marc wants to take over the keyboard.

What I like most:

• WikiLinks still work.
• Pasting to and from OpenOffice (or the other word processor) works without visible differences.
• I can see the images in the page while I am editing.
• Text layout changes are instant and wysiwig.
• I can still get at the html source if I want to, by clicking on the Source button (unfortunately still necessary, as most, but not all, formatting changes work from within the editor).
• I only needed to modify an edit template to get started, no modifications to the core wiki software were necessary.
• Look and feel, including keyboard combinations, is much like word processors, so the barrier for casual users to edit pages is much lowered.

Having all pages in html can make it fairly easy to convert existing websites to wikis. A small downside is that existing wikis also have to be converted, pages have to be html, rather than wiki formatting. I made a 40 line script for that in ruby that seems to do the trick, converting complete wikis at once. So now I’m converting the closed wiki’s I’m having to see how stable it is. After that, some public wikis are likely to follow.

If you want to try it out, seedwiki hosts free wikis that use the same editor. The fck editor site also has a try out box. If you host wiki’s yourself, I’d suggest you take half an hour to change an edit template and install the editor!

(I know this editor is 100% javascript. Some people who know me may say huh? Well, I changed my mind based on this. With effort, it is possible to make very useful things with javascript. I love ‘voortschrijdend inzicht’ (‘advancing insight’) ).