SoCraTes Germany

SoCraTes Germany 2015 has again been a conference full of superlatives — or should I say “unconference”, given that it consists mainly of a two-day Open Space? Whatever you call it, we had more participants (over 180), more proposed sessions (90 – 100 sessions per day), and more sponsors than ever.

Speaking of sponsors: Of course TIM Group was among them, and all contributions were spent on reducing hotel bills for participants. Not that it was an expensive event anyway: the participants cover their hotel room, breakfast and dinner, and that’s it. But let me start at the beginning…

Six or maybe even seven years ago, my boyfriend Andreas Leidig decided to create a conference for developers — after all, developers deliver the software. If you remove all managers from a software project, chances are you might get something usable out of it, but if you remove all developers, well, I’d say your chances are zero. There were lots of agile events for managers, coaches and other “tree-huggers”, but no general-purpose developer conferences along the lines of software craftsmanship and improvement.

So Andreas created a developer conference, and named it SoCraTes: Software Craftsmanship and Testing Conference. It was designed as a two-day event falling on a Friday and Saturday so that both the developer and the developer’s employer would contribute time to the event. Arrival on the previous evening was mandatory in order to start the first day early and in a relaxed fashion. Another important factor was that it was held off-site — everybody stayed in the conference hotel, which we had to ourselves, allowing us to be together from the first yoga and jogging workout before breakfast to the last beer, song, or boardgame long after midnight.

We started our first SoCraTes in 2011, with the help of a small handful of friends. The first year we had one day of talks and one day of Open Space, because we were afraid companies would not let their employees attend a conference without a programme. The feedback of the 50+ participants reassured us we didn’t need the programmed talks, and from the second year we ran SoCraTes as a two-day Open Space. We sold out in the second year with about 75 participants, confirming our decision. On Saturday evening of the second year, a group of participants decided that they had not yet had enough, so they extended their stay and spontaneously ran a Coderetreat on Sunday. This Coderetreat is now an integral (though optional) part of SoCraTes, accompanied by workshops and other half- or full-day sessions.

In the third year, we sold out so quickly (literally within a minute) that we felt the need to do something. Of course it was nice for everybody who could register, but thinking of those who could not get a spot diminished the joy quite a bit. Also, the SoCraTes “brand” had expanded to the UK, where a sibling event was being run by the London Software Craftsmanship Community. Meeting friends from abroad was an important part of attending SoCraTes; how could this reliably happen with such high demand and such a small number of participant slots?

After some discussion among the organizers, we decided to experiment with increasing the size of the event. We were curious — and also a bit tense — because we wondered whether it would still be the same event, with the same familiar feel we had come to love so much.

The fourth SoCraTes took place last year with twice as many participants, approximately 150. And it was amazing! Of course the event felt different. I was not able to speak to everybody any more. Everything took longer, from the signup to the marketplace to walking around the new hotel, which was of course a bit bigger than the previous one. But at the same time, the SoCraTes spirit was there just like the years before, as the seasoned participants carried it over while the newbies blended in naturally. We heard many positive voices and read enthusiastic blog posts. Our experiment had been a success, and so we did not think twice about continuing in this direction. In 2015, we increased the number of participants to 180, and next year we will try to cross the 200 mark. Although I will slowly pass the management of SoCraTes on to the next “generation” of organizers, I’m looking forward to seeing SoCraTes thrive together with its sibling conferences that sprout all over Europe.

Again, my thanks go to TIM Group and all our other sponsors for supporting SoCraTes and encouraging their employees to participate!

Oh, by the way, are you curious now? Please feel free to have a look at

TDD Masterclass

I recently attended a two day TDD training course by Jason Gorman.

Although we practise TDD on a daily basis, I was interested to see if we are applying all the practises correctly or see if we are missing out on anything.

The Jason presented what he called the baker’s dozen of TDD practises.

  1. Write a failing test
  2. Write the assertion first
  3. Don’t refactor with a failing test
  4. Isolate tests from each other
  5. See the test fail
  6. Triangulate
  7. Organise tests to reflect model code
  8. Write the simplest code to pass the test
  9. Choose meaningful names
  10. Test one thing in each test method
  11. Refactor to remove duplication
  12. Keep test and model code separate
  13. Maintain your tests

The great way Jason reinforced these practises was to apply another great agile practise, pair programming. In pairs we applied TDD to solve various programming problems, e.g. generating Fibonacci numbers, FizzBuzz, etc. Solving these problems in pairs was the most enjoyable aspect of the course. By enforcing frequent pair rotation I met a lot of nice people plus I even got a taste of TDDing in C#!

So what did I find in the end? We are doing pretty well at youDevise. We nearly apply all the practises (we can probably do triangulation more). Overall, I think the course is a good introduction to TDD, especially learning through pair programming.

Testing YUI Menu Button with Selenium

Recently we encountered a snag using YUI’s menu button widget. The button doesn’t respond to Selenium click commands. Given its untestability we seriously questioned whether it was worth using the widget.

However, there is a solution! In Selenium you can select a button’s menu item by clicking the underlying <a> element. For example given the following HTML for a menu button:

<span id="yui-gen3" class="yui-button yui-menu-button">
  <span class="first-child">
    <button id="yui-gen3-button" type="button">Two</button>
<div id="yui-gen4" style="z-index: 1; position: absolute; visibility: hidden;">
  <div class="bd">
    <ul class="first-of-type">
      <li id="yui-gen5" class="yuimenuitem first-of-type" groupindex="0" index="0">
        <a class="yuimenuitemlabel" href="#">One</a>
      <li id="yui-gen6" class="yuimenuitem yui-button-selectedmenuitem" groupindex="0" index="1">
        <a class="yuimenuitemlabel" href="#">Two</a>

Select “One” from the menu using Selenium:

  Command: click
  Target: link=One

Once the <a> has been clicked the selected menu item is accessible in JavaScript via the menu button instance, e.g.

  var menuButton = new YAHOO.widget.Button({...});

Don’t use menuButton.getMenu().activeItem as that doesn’t get set when the <a> is clicked via Selenium.

Pairing uses more of your brain

I have a theory that pair-programming is an acceptable alternative to talking to yourself.

I’ve come to this conclusion while working in pairs with people in the team for the greater part of the last few months. I was wondering why, on a purely qualitative level, our team seems to get more out of its developers when they work as half of a pair, compared to when they work solo. We feel that we can work more carefully and more thoroughly in pairs, and we’ve noticed that our pairing days feel more intense. We’re usually more tired at the end of them, than on days when we’ve been working by ourselves.

I guess the basis of my theory is that we inevitably use more of our brains when we pair. It would take some MRI equipment to be truly scientific in verifying this. Probably beyond our development budget. So instead I’ll just talk about why this might be.

Suppose I’m sitting by myself in my study at home, quietly writing some code. If I were a neuroscientist, I would list the bits of my brain I’m using for this task, including parts of the cerebral cortex for expressing my thoughts in the language of the software, the temporal lobes for memory, the parietal lobes for formulating mental pictures and nonverbal ideas, and coordinating hand-eye movements, and so on.

As time passes, I get deeply involved with what I’m doing. If I had a tape recorder in the room I would notice an amusing change in my behaviour. I start talking to myself.

I’m confident this is no reason suddenly to go check myself into the nearest mental health facility. In fact many people do this, if only for a moment, before they look round the office and remember they’re not actually by themselves.

If I start talking to myself while coding, it shows my brain has started to engage other linguistic and speech-related parts of itself, namely the Wernicke and Broca areas in the left hemisphere. It’s almost as if my brain is chipping in more resources to help out with my coding task. And if I’m totally honest, talking aloud like this does help. I seem to be able to think more clearly about a problem if I can start talking about it, if only to the walls.

Of course, these days I do all my real work in an office. It’s an open plan office in which I’m surrounded by people. I’m not about to start talking to myself. I would be an awkward distraction, and everyone would think I was a loon. So when I’m working solo in the office, Broca and Wernicke can’t get involved, and I have to use less of my brain.

Except, if I’m pair programming, I need those linguistic and speech areas, so I can talk about what I’m doing, and listen to the inflow of ideas from my pairer. I can’t pair without them.

It would be wrong to consider the brain as one big fatty coding engine, that the more of it you could deploy for software development, the faster you could churn out product. But I do think involving more of the brain by introducing a spoken interactive element is a big improvement on working in silence in isolation. Especially as ours is a typical open plan office where there is no silence. If coders can’t have silence, better the primary noises going into their head are their pairer talking about what to type next.

One accusation often levelled at pair programming is that it wastes programmer resources: surely the team could complete more tasks in a development cycle if they paired less? I would love to try and measure whether or not this is true. Without a measurement, developers resort to the usual defensive arguments that pairing improves code quality, distributes knowledge over the team, and so on. Meanwhile, I’m happy in the opinion that if need to get more work done, pairing seems to be a good way of getting the most out of my brain while not sounding like a crackpot.

Capture Screenshots of Selenium Failures

We are constantly fighting a battle with browser-test failures. Our browser tests should be telling us where our application is failing, so we can fix defects quickly and get back to writing more great features – but when you can’t see where an error came from, you can waste hours just trying to reproduce it. The latest weapon we’ve deployed in this battle allows us to capture a screenshot of the browser whenever a test fails.

Unlike other implementations we only want to create a screenshot when a test has failed.

Firstly, our browser tests are written as Java unit tests using the excellent SeleniumRC library. Now capturing a screenshot is really easy as Selenium provides a captureScreenshot() method. The tricky bit is to only capture a screenshot when a test fails. A crude way to achieve this is to wrap every test method with a:

    try { 
      // test here
    } catch (Throwable e) { 
      // capture screenshot here

Instead of doing this we leveraged JUnit’s @RunWith annotation to use a custom runner which catches test failures and trigger the screen capture. To generalise the functionality, our runner will call any method annotated with @AfterFailure.

Here is the source code to our custom runner:

import java.util.List;

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.InitializationError;
import org.junit.runners.model.Statement;

 * JUnit runner which runs all @AfterFailure methods in a test class.
public class RCRunner extends BlockJUnit4ClassRunner {

     * @param klass Test class
     * @throws InitializationError
     *             if the test class is malformed.
    public RCRunner(Class<?> klass) throws InitializationError {

     * Override withAfters() so we can append to the statement which will invoke the test
     * method. We don't override methodBlock() because we wont be able to reference 
     * the target object. 
    protected Statement withAfters(FrameworkMethod method, Object target, 
                                   Statement statement) {
        statement = super.withAfters(method, target, statement);
        return withAfterFailures(method, target, statement);

    protected Statement withAfterFailures(FrameworkMethod method, Object target, 
                                          Statement statement) {
        List<FrameworkMethod> failures =
        return new RunAfterFailures(statement, failures, target);

import java.util.ArrayList;
import java.util.List;

import org.junit.internal.runners.model.MultipleFailureException;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.Statement;

public class RunAfterFailures extends Statement {

    private final Statement fNext;

    private final Object fTarget;

    private final List<FrameworkMethod> fAfterFailures;
    public RunAfterFailures(Statement next, List<FrameworkMethod> afterFailures,
                            Object target) {
        fNext= next;
        fAfterFailures= afterFailures;
        fTarget= target;

    public void evaluate() throws Throwable {
        List<Throwable> fErrors = new ArrayList<Throwable>();
        try {
        } catch (Throwable e) {
            for (FrameworkMethod each : fAfterFailures) {
                try {
                    each.invokeExplosively(fTarget, e);
                } catch (Throwable e2) {
        if (fErrors.isEmpty()) {
        if (fErrors.size() == 1) {
            throw fErrors.get(0);
        throw new MultipleFailureException(fErrors);


import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

 * Annotation to mark a method to be called when a test fails.
public @interface AfterFailure {


Here is an example test using the new runner.

public class MyBrowserTest {
    public void myTest() {
        // Test here

    public void captureScreenShotOnFailure(Throwable failure) {
        // Get test method name
        String testMethodName = null;
        for (StackTraceElement stackTrace : failure.getStackTrace()) {
            if (stackTrace.getClassName().equals(this.getClass().getName())) {
                testMethodName = stackTrace.getMethodName();
        selenium.captureScreenshot("/tmp/" + this.getClass().getName() + "."
                                   + testMethodName + ".png");

Recording VNC Session

Sometimes it’s handy to record a VNC session. For example when the remote machine is running an automated browser test and you want to see what exactly happened when a failure occurred.

pyvnc2swf can record a VNC session and save it as a Flash file.

1. Install pyvnc2swf


yum install pyvnc2swf


apt-get install pyvnc2swf

2. You can use pyvnc2swf via its GUI or on the command line. Using the GUI is pretty straight forward.
The remaining steps describe using it from the command line.
3. Start pyvnc2swf on the command line with the following command:

pyvnc2swf -n -t shape -o <Name of file to save recording> <VNC server name>

For example:

pyvnc2swf -n -t shape -o myrecording.swf

The meaning of each options are:
-n Run pyvnc2swf in console mode.
-t The encoding type. The possible types are shape (.swf), video (.flv), vnc (VNCLog).
-o The name of the file to save the recording.

4. Press Ctrl+c to stop recording.
5. Open myrecording.html in a web browser to view the recording.

I like Hudson

Recently I had to add some new tests to our continuous integration test system. I was dreading it given my previous experience with our CruiseControl setup. However, we have been trialling Hudson so this gave me an opportunity to try it out.

And the verdict…..I like Hudson (kinda gave that away already). It was really easy to modify an existing Hudson project to include my tests. Two Hudson features particularly impressed me.

1. Hudson told me right away when I entered in incorrect path to my artifact file. No need to wait until after a build to realise I had made a typo.

Hudson - Artifact path validation

Hudson immediately validates that the path is correct.

2. It is really easy to see the output from the build. I remember bashing my head against a wall for ages just trying to get the same output from CruiseControl.

Hudson - Console Output

Hudson provides the build output right underneath your fingertips.

PS – The magic incantation to see the build output, as CruiseControl runs the build, is to add uselogger="false" to the <ant> tag in your CruiseControl config file.

Get SeleniumRC Browser Windows Out of Your Way

Here’s a way to stop annoying browser windows popping up and stealing your keyboard focus when running SeleniumRC tests.

  1. Install Xephyr.
    On Fedora: $ sudo yum install xorg-x11-server-Xephyr
    On Ubuntu: $ sudo apt-get install xserver-xephyr
  2. Start Xephyr.
    $ Xephyr :1 -ac -screen 1024x768 &
  3. Open a terminal in the Xephyr xserver.
    $ DISPLAY=:1 gnome-terminal &
  4. Start a window manager in the Xephyr server.
    $ DISPLAY=:1 metacity &
  5. From the terminal within the Xephyr window start SeleniumRC server.
  6. Run your tests. Now the browser will only pop up within the Xephyr window

Browser running SeleniumRC test in Xephyr window

Xephyr is an X windowing system whose display lives entirely within…a window in another X server! See the Xephyr site for more.

Coding Dojo V

Recently we had our fifth coding dojo. The format is similar to our previous dojos with the addition of applying the Extreme OO rules.

The challenge was to implement Tic-tac-toe/3D Tic-tac-toe.

Here are the story cards.

Coding Dojo V - Story Cards 1Coding Dojo V - Story Cards 2Coding Dojo V - Story Cards 3

Click to zoom in.

What Went Well

  • The challenge was good because it lead to lots of domain object.
  • Having a separate monitor for the pilot & co-pilot.
  • Having an on screen timer showing the time remaining.
  • The use of story cards.

What Didn’t Go Well

  • Too much time spent wrangling the Java I/O API.
  • No skeleton structure to give guidance how to solve the challenge, i.e. how to handle input/output.
  • Refactoring code while there are tests still failing


  • Put Kata calculator user story on to (Ben)
  • Automate running of unit tests. (Squirrel)
  • Document machine setup and the need for a skeleton structure. (Tony)
  • Provide skeleton structure for challenge, i.e. to avoid the I/O wrangling experienced in this dojo. (Ian)
  • Consider phrasing story cards from a customer’s perspective.
  • Run next dojo. (Ian)
  • Create reference cards for EasyMock & Eclipse shortcuts. (Ben)
  • Blog about Dojo V (Tony)

Note: All files related to Dojo V is available in Subversion, in the Training project.

Coding Dojo @ MX Telecom

Last week Joel and I went to a coding dojo at MX Telecom. The dojo was in the Randoori Kata style with 7 people participating.

The Setup
The dojo was held in a board room with a big plasma TV for the audience and a monitor for the computer pair. There was also an onscreen timer which counted down the time left for the pair at the computer. I found that this setup worked very well and applied it to our last dojo.

The Challenge
The theme of the dojo was to learn jMock. This meant that we solely wrote unit tests against an existing application, a music player. The organiser provided the following documentation about the music player: MX Telecom Dojo Challenge Documentation. Story cards were used to describe each test which need to be implemented. Interestingly the MX developers got the idea to use story cards from us when they came to our dojo.

The Difference

  • The moderator participated in the dojo. – This didn’t seem to make a difference as the moderator didn’t need to enforce any particular rules.
  • Everyone took turns by going around the table. – I don’t think this was good as we always ended pairing with the same people.

The Conclusion
It was an interesting experience to see how other dojos are run and I feel like I did get something out of it, both in the way learning about jMock and how to run a dojo.