I finally completed the first increment of a  dutch website for my company Living Software. This one has been on my backlog for quite some time. The english company site will remain at willemvandenende.com.

The main value I hope to get from this site, is that I noticed it isn’t clear (even to some people I know) how I work, that I have my own company and services etc – I hope this clears it up. Other value is, that I noticed not everyone that attends our courses is 100% comfortable with doing everything in english, and sinds this "agile" stuff stil is spreading slowly in the netherlands, I thought I’d give another site on coaching, training and agile in dutch a shot. (This is the third time I’m doing it. First as an employee, then at my first (shared) company and now as an independent)

.

I was having a conversation with Marc yesterday, and he mentioned the false dichotomy between life and work
In case you’re wondering what a false dichotomy is, Pascal van Cauwenberghe recently wrote an analysis of people problem or process problem? that could serve as an example of a false dichotomy.
Making the Living Software site is an instance of how I make the distinction between life and work less and less. I’m following my passions, and make a living out of it at the same time. I enjoy writing, and I enjoy photography, so I used one of my own photographs as a background for the site title and I made the black tree I got from Nynke white so it fits better with the background.

At first I was thinking about doing the site with a (rather elaborate) CMS and link in a weblog. After evaluating textpattern, I decided to try building the whole site with that – so all pages on it have trackback, ping, and comments – a lot of my work is about making feedback loops. If feedback is good, why not have it everywhere on a site? (this weblog still hasn’t, because I’m puzzling about how to keep the links to the 140+ entries working in a new blogging engine).
 In the near future I hope to make the site more self-organizing by adding a tagsonomy to it – the articles all have permanent links, so the structure of the site can vary around that (in any combinations of sections, categories and tags).

There are still a few nits to pick, and many things I want to add, but with a couple of pieces on the background of my company and me being happy enough with the layout, I am good to go, as this site is the simplest thing that could possibly work – at least I’m getting the first value – it’s making it more obvious that I’m independent, and the name of my company is Living Software  .

I had a good laugh about the waterfall 2006 conference conference yesterday. Stalwart Analysis: Especially The Effluvia of Determined Thought by Don Sengroiux made me remember the good old bad days at comp.object (read the names in the paper closesly ). Have fun.

I bought an hp officejet 4215 last week, because, as a laggard, I finally wanted to have a fax machine so I could improve turnaround time on closing some deals and starting work. I wanted to have another machine, but that was sold out, so I took this one. It has an ADF (Automated Document Feeder). I was expecting it would eat only A4 (or Letter, for those of you living on the other side of the pond). As it happens, it feasts on index cards as well (about ten index cards at a time though). As I was working with Rob on some alternative choreographies for eXperience Agile, we made a bunch of index cards with modules. To archive it and mail the results to Rob, I wanted to scan a batch of index cards. Marc suggested to show, not tell how scanned index cards work (I typed the text of the stories, acceptance criteria in alt tags, in case your aggregator doesn’t show pictures, or you can’t read my handwriting… ):

Installing the scanner was a no brainer ‘apt-get install sane’ (sane is the universal scanner package in linux) and printer and scanner were both autodetected.

To get value from the first story, I scanned the 17 index cards for Rob in a couple of minutes (I was doing other things meanwhile). The scanner takes about 10 cards at a time. I made two small scripts (about 4 lines in total ) to cut the cards in the correct size (10×15 centimeter) and convert everything to jpeg. I chose to use ‘scanimage’, a command line tool, since that was less work than xsane (a graphical front end, more suitable for incidental scanning). I made a zip file of the cards and sent them away. That was cool.

Now I was missing one feature from a table with story cards – shuffling them around. We wanted to make three choreographies, and had made markers on the cards for that. I didn’t quite know what to use for that, so I left it for a couple of days. Then it dawned on me, that OpenOffice Impress ( a presentation package) has a slide sorter that makes it very easy to move slides around. Importing the scanned cards one by one was very cumbersome though. Time for the next story:

Messing with open office xml turned out to be a bit error prone (I didn’t bother to read the spec either. I unzipped the sample presentation I made by hand, looked where the images were and manipulated the xml with rexml ( a ruby library for working with xml as a tree representation). I still officially dislike xml, but used this way it was very simple for me to make my openoffice more valuable to me. To see how it looks and feels, you can download these stories as Impress 2.0 (OpenDocument Presentation format) or stories as PDF.

 
Scanned index cards are handy and fun for sharing course layouts, and possibly also for archiving user stories – with other forms of electronic storage (except digital photos, but scanned cards are easier to read) I miss the visual blips and seeing the cards makes it easier for me to relive bits of a planning meeting when necessary .

Maybe there are more applications . If you’re interested in trying out the script, let me know. It might be fun to release this as open source, but I need to do some work on packaging it then – that would go best with some feedback from early users.

This section reads like I’m anti-documentation, which is silly because HELLO I WRITE A WEBLOG.

I came across this quote by Michael “Rands” Lopp in Joel Spolsky’s collection The best software writing I .

So, I’m not against documentation either, since I read books . I recommend “The best software writing I”, since in theory , as Nico Mommaerts suggested, it is a nice bundle of articles, which you could read one at a time. In practice, I read a bunch of articles at a time, because they’re funny, well written and insightful. So pick this up if you want to have a good laugh if you’re interested in e.g. how many microsoft engineers it takes to switch a lightbulb, what to do when you’re screwed or how you can make your company disfunctional by setting individual bonuses.

There’s some great cartoons in it too:

These cartoons are from why the lucky stiffs poignant guide to ruby. I like to step away from the screen every once in a while, lounge on an easy chair and have a good laugh (and a colleciton of urls does not look nearly as nice on my bookshelf).

The first XP Day France is going to happen on March 23d! I’ll be running another incrementally improved Balancing Act – simple tools for feedback, communication and courage. For our french friends, it has been renamed Des outils simples pour la Communication . My french is a bit rusty, so I’ve started watching TV 5 (a french tv channel) every once in a while.

At SPA2006 (the software practice advancment conference, formerly known as OT) I’ll be co-hosting two sessions with Marc Evers and Emmanuel Gaillot: Balancing Act – simple tools for feedback, communication and courage and a new session we came up with especially for the sunday on SPA, These are just some of my favourite tools

These are just some of my favourite tools is an open space session, where we invite the participants to show and/or tell one of their favourite tools, things that make (work) life a lot better. Marc, Emmanuel and I have a preference for ‘people tools’ (e.g. meeting formats, retrospective exercises, iteration choreography), but if you have a more technical tool that’s made you more productive, we’d welcome that too.

As for Balancing Act, we’ve completed the hand outs for the three parts, and are now thinking about running the session in french, as well as perhaps doing the wrap-up of the session slightly differently.

In case I haven’t met you yet this year – happy new year!

I haven’t been blogging for a couple of weeks, as I was busy writing on other sites, together with Marc Evers. Marc also has finally started his own business (currently besides his day job).

The new sites are for showing and selling workshops and courses we already have – instead of inventing new ones, we decided to spend some time consolidating what we already have – more to follow . Both sites feature other facilitators we run these courses with. Agile Workshops is dedicated to a number of beginner and intermediate courses on agile software development. Satir Workshops is a place for workshops based on the work of Virginia Satir, currently featuring Balancing Act.

For Agile Workshops, I got into making some artwork, to give a better feeling for what these workshops (and agile software development) is like:

And, finally, we reorganised the Agile Open wiki, so it is ready for the 2006 conference. We hope you’ll bring many ideas for sessions (and eventually, yourself to the conference ).

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 ).