Category Archives: video

Howto use Pageant and Putty

For those of you who already use PuTTY: Here’s a little improvement that’s surprisingly little known. Probably because it is very hard to explain. But I’ll try.

Here is how you can avoid starting programs, entering login information or indeed typing passwords when you use PuTTY:

  1. Download Putty installer from the PuTTY Download Page. Make sure to grab the “Installer”
  2. Install Putty
  3. Start PuttyGen from Start -> PuTTY-> PuttyGen
  4. Generate a new key and save it as a .ppk file without a passphrase
  5. Use Putty to login to the server you want to connect to
  6. Append the Public Key text from PuttyGen to the text of ~/.ssh/authorized_keys
  7. Create a shortcut to your .ppk file from Start -> Putty to Start -> Startup
  8. Select the .ppk shortcut from the Startup menu (this will happen automatically at every startup)
  9. See the Pageant icon in the system tray? Right-click it and select “New session”
  10. Enter username@hostname in the “Host name” field
  11. You will now log in automatically.

This process is a bit hard to explain, so I have made a short video that explains it:

In order to streamline things even more, notice how Saved sessions show up under the Pageant icon in your system tray.

Posted in English, Technology, video | 7 Comments

Video: No-red refactoring

The more I code, the more I’ve learned to appreciate keeping the code clean even during complex refactorings. By “clean”, I mean that the code always compiles and the test always run.

I often find myself in a situation where I have a method call that’s starting to accumulate parameters. Something like this:

After three or four parameters, the need to refactor is starting to become evident. I would rather have something like this:

This is one of the more complex simple refactorings you can make, and it requires several steps. In this five minute video, I show how to perform such a refactoring without any steps that break my code:

The screencast was created using the free BB FlashBack Express on Windows. All the magic you see happening while I program is either ctrl-space (complete) or ctrl-1 (quick fix).

Can you modify your code without going thought long stages of nothing working? I think you can!

Posted in English, Extreme Programming, Java, Software Development, video | 3 Comments

How pair programming and test-driven development looks in real life

Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this.

I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session. The result is the Java EE Spike Kata. My colleagues in Steria, Anders Karlsen and Ivar Nilsen have been great to work with. Between us, we’ve showed the kata at three conferences, and more are coming.

Here is the performance at JavaZone 2010 by Anders Karlsen and myself.

The Java EE Spike Kata from JavaZone on Vimeo.

Make sure to watch the video in full screen mode as there will be LOTS of code.

Some things to watch for when you’re watching a (paired) code kata:

  • How are we working together? How often are we changing who’s at the keyboard? What will the person who’s not at the keyboard be doing?
  • How do we progress from one test to the next? When do we decide to modify an existing test and when do we decide to add a new one? How much of the test do we write before we start modifying the production code?
  • How are we writing the production code? How often are we refactoring existing code?
  • How are we using the IDE? What tricks do we use to take advantage of the code completion facilities? How often do we use the mouse and how often do we use the keyboard?

I also hope to be putting up the video of me and Ivar Nilsen at the TelecomCity conference in Sweden. As we’d both practiced even more for that performance, I think it’s even smoother than the JavaZone performance.


(Kudos to Cisco Norway, formerly Tandberg, for excellent filming services at JavaZone. And thank you to Robert “Uncle Bob” Martin for turning me on to code katas in the first place)

Posted in English, Extreme Programming, Java, Pair programming, video | 10 Comments

Six ideas that improve your software design

“Design” is a verb, not a noun. If I want to create a good program, studying the process of getting there is much more important than the resulting software. This is why I use coding katas as a form of study. I find an interesting problem problem and then solve the same problem over and over again. In this blog post, I will focus on six principles of software design. I will illustrate each with a screencast from a kata.

One of my favorite problems is that of creating a Java EE application from scratch. I call this kata “The Java EE Spike Kata”. In order to understand the role of frameworks, I use no web frameworks in the process of creating this application. I’ve completed this particular exercise about forty times on my own and more than ten times with various pair-programming partners. The whole exercise takes me about 90 minutes, and I still learn new things.

The total time of the screencasts is around 40 minutes, so you may want to pick and choose. Each section provides a link to the starting point for the source code if you want to follow along.

Please notice: The videos are accompanied by loud, pounding music. Keep you headphones on or your volume down if you share offices with someone else. Or mute the videos if you dislike the music.

Idea 1: Build your software from the outside-in

(10 minutes, github starting point)

I start building the application by writing tests that access the application over HTTP and looks at the resulting HTML. As you might have gathered, when I start this test, there is no web application. Only when the tests require a web application to continue do I start creating it. In this example, I had created a basic sketch of the interaction between the three web pages in the application before I started coding. No further design was necessary.

This particular approach uses WebDriver and Jetty to run. The cute assertion library that you may have noticed at the end of the video is FEST-assert.

Idea 2: Specify behavior rather than implementation

(6 minutes, github starting point)

I don’t make much of a distinction between different types of tests. All good tests try to describe what the software should do at some level, rather than how the software does it. But the how at some level may be the what at another level. My first test specified the interaction between the web browser and the server. In this test, one step may be to fill in the form element of a web page. This second video shows how this form works in terms of actual HTML. But the details of what framework (if any) is used, is not visible in the test.

The second thing you’ll notice in the video is that I run the tests more frequently. And each test run is much quicker. As our tests move close to the code, the rate of feedback improves.

This particular test uses Mockito to mock out the Servlet API. The assertions use FEST-assert.

Idea 3: Increase the rate of feedback

(5 minutes, github starting point)

This video illustrates the frequency of feedback. The example test-drives creating an equals-method. This task is often not worth test-driving. The resulting method is usually simple and/or generated by your IDE. But it is a good example to of how quick the cycle between test and production code can be when you’re writing tests that are close to the problem at hand. When I pair program this part of the kata, we usually use a technique called ping-pong programming: One programmer writes a failing test (or failing assertion) and hands the keyboard to his partner, the other programmer makes the test pass and writes another failing test before passing the keyboard back. On a good run, we will switch who’s got the keyboard more often than once per minute.

Notice that I also focus on the behavior of the equals-method in this test.

Idea 4: Grow the API rather than designing it up front

(8 minutes, github starting point)

As the web application grows under my fingers, I discover the need for a Data Access Object (DAO). However, as this represents a major internal interface in my application, I use Mockito to mock the implementation until I’m done with the behavior of my servlet. When this is done, I test-drive the implementation of the DAO in a separate test class.

The video also illustrates another important lesson: The code is getting ripe for a refactoring. But it’s important to resist the urge to refactor until the tests are green. If you refactor on red tests, you have much higher chances of running down a dead-end road and you’ll have to throw away your progress, wondering what went wrong.

The example uses Mockito to mock out the DAO API.

If you want to see how I implement the DAO with Hibernate, you can see the video on

Idea 5: Grow the design rather than speculating

(3 minutes, github starting point)

The video is only a partial example of this principle. Throughout the whole application, I’ve been refactoring, gradually pulling out structure to more well-structured methods and classes. The video illustrates some of the power of IDE’s when it comes to refactoring. Using the IDE to massage your code into a better design makes evolutionary design much easier to do in practice. Make sure to learn your IDE’s most useful refactorings!

The kata may seem like a non-realistic example at this time, but I’ve actually grown a very successful architecture on my current project using much the same approach. If you want to explore where to go next, the next step needed for this application is to factor out the views into separate classes and then use either a View Template language (like Velocity) or a View Transformer (using, for example dom4j) to generate the HTML. (Let me know if you’d like to see the screencast of this as well).

Idea 6: It’s supposed to work the first time around

(5 minutes, github starting point)

In this video, I return to the first test, PersonWebTest, to finish the configuration of the application. I discover a few mistakes I made in the web test as I complete the exercise. Then I try out the code in the browser. And all the scenarios I had planned for work out of the box.

When you try out your code for the first time, it should work. When you master test-driven development, you will probably forget how you programs didn’t use to work the first time. Only when you occasionally run into an unexpected error during manual testing it becomes clear how test-driven development changes you life.

If you want to see the whole, uninterrupted 75 minute code kata, the video is available at You can also take a look at the finished source code at github.

Happy programming!

A big thanks to Trond, Thomas, Ram and Christian who helped improve this post. Thank you to Finn-Robert, Øistein, Mats, Anders, Siv, Peyman, Ivar, Øystein, Cecilia, Nicolay, and Karianne who have pair-programmed this exercise with me. I especially appreciate how Ivar and Karianne both helped influence the way the application is wired together and showed me that even after 30 iterations, I still had things to learn; and how Øistein showed me how two trained developers could complete the exercise faster with pair-programming than alone. And thank you to Nicolay who graciously brought food to our pair-programming exercise.

The videos were made with the excellent (and free!) BB FlashBack Express. The keyboard echo is courtesy of KeyPosé by Magnus Jungsbluth.

Posted in Extreme Programming, Java, video | 7 Comments

Why TDD makes a lot of sense for Sudoko

My colleague Thomas sent me a very interesting link about attempts to solve Sudoku using test-driven development. The article, somewhat unfairly, pits Ron Jeffries’ explorations of Sudoku using test-driven development against Peter Norvig’s “design driven” approach.

I found both attempts lacking. However, while Ron Jeffries freely admitted that he didn’t even know the rules of Sudoku when he started, both Norvig himself and his readers fawn over his solution. I didn’t find it very understandable.

So I took it upon myself to examine the problem myself. I did some up-front thinking in the shower and on the subway, then attacked the problem with TDD. I ended up with a solution that works in all cases (unlike Norvig). My implementation has readable code, readable tests, and solves the problem reasonably fast.

Observations and conjectures

Here are a few things I learned from the exercise:

  • When you’re using TDD to solve a tricky algorithm, you have to think about both the algorithm and the test approach.
  • Solving a problem with a known algorithm using TDD gives more readable code than I otherwise would expect.
  • When I solved the problem with TDD, running the solution on real problems worked the very first time I tried it.
  • The trick to making TDD work is to work from the outside in.
  • When creating a Sudoku solver, don’t think like a human! Think like a machine! The human algorithm is difficult to understand and likely to not work on all problems. This was the biggest problem with Norvig’s code

The journey

I decided on the following approach:

  1. I had decided upon an initial design with a solver class and a board class. The solver should use a recursive depth first search. The solver asks the board what options exists per cell, but it has no knowledge of the rules of Sudoku (such as no duplicate numbers on the same row).
  2. The first step was to get the solver (“the outside”) correct. For this step, I mocked out the board
  3. The second step was to implement the interface that the solver needed for the board. Mainly, this is a matter of specifying the rules for what numbers can occur in which cell on a Sudoku board.
  4. Finally, I wrote some code to read and write the Sudoku board. When trying the solver on real problems, it worked the first time, and solved 95 hard problems correct. It was somewhat slow, though.

After solving the problem the first time, I practices a few times and recorded a screen cast of the solution:

The solver

Testing the solver is a matter of creating a mock board and ensuring that the solver does the correct things. This is the most complex test case:

It specifies that all cells, except (8,7) and (8,8) return exactly one option. (8,7) returns two options. (8,8) returns no options the first time it is called, and one option the second time. The test verifies that a solution is found, and the solver tries to set both options for (8,7).

This drives a rather simple algorithm. Here’s basically the whole algorithm:

The algorithm tries all available options for a cell in order. If no solution works for the rest of the board, the algorithm returns false (for “no solution”).

The algorithm is not how a human would solve Sudoku. But then again, we’re not writing a tutorial on how to solve Sudoku, we’re writing a program that solves Sudoku.
The board

As I implemented the solver, the interface for the board started to emerge. At that point in time, I had to create tests for the Sudoku board itself. A typical test verifies that the board doesn’t allow duplicate values in a row:

The essence of SudokuBoard is finding out what values are legal in an open cell:

TDD as a design guide

I invite you to compare Peter Norvig’s solution to mine (you can find the full source code for my solution in my github repository).

It would probably have been possible for me to code the solution faster without tests, but it probably would not have worked the first time I tried it. I also would have much less confidence in the code. Finally, I think the design imposed by the tests made my code easier to understand.

Posted in Extreme Programming, Java, video | 8 Comments

My first katacast

After seeing some of the great examples of coders working on practiced problems on KataCasts, I decided to try make my own. I am not happy with the pacing of the video. I’m about a minute too early relative to the music.

But I thought I’d post the video here, to see what you all think. Comments are welcome!

I hope the video will demonstrate how to use refactoring effectively to drive the design of a program.

I chose the FizzBuzz kata – that is, to generate a sequence of numbers where every number divisible by three is replaced by “fizz” and every number divisible by five is replaced by “five”. The music changes to be more aggressive just as I induce a new requirement into the kata: The FizzBuzz generator should be programmable, so, in the kata, numbers divisible by two are replaced by “coconut” and numbers divisible by seven are replaced by “banana”.

Thanks to Emily Bache for the inspiration for the kata.


Fizz buzz code kata from Johannes Brodwall on Vimeo.

The video was made with IntelliJ IDEA Community Edition on Windows Vista (!) with BB FlashBack Express (free screen recorder), converted to AVI with Windows Media 1 codec and uploaded to Vimeo.

Posted in English, Extreme Programming, Java, video | 1 Comment