Celebrating a fantastic Code Retreat day

Today, Saturday 7th May 2011, there were six code retreats around the world! They were in Belgium, Spain, UK, USA, and two in Romania! We all did the same challenge: implementing Conway’s Game of Life in pairs, using test-driven development, in iterations of 45 minutes, discarding code at the end of every iteration and pairing with somebody different for the next iteration. We introduced a few extra challenges in every session! ;)

I co-facilitated the code retreat at Sheffield University. We had 18 participants: a good mix of computer science students, professional programmers, people who code for fun, and someone who seemed to have been dragged along but got thoroughly stuck into solving the problem along with everyone else! :)

Tom Crayford co-facilitated with me, and Chris Murray ran around making sure everything went extremely smoothly.

In iteration 1 we gave everyone chance to explore the problem without heckling to see how they would do. The only special challenge was to pair with someone they didn’t know. In the retrospective we talked about the languages and classes used.

For iteration 2 we talked about TDD as in, letting the tests really drive the code in the direction they want to go. We challenged people to do the very simplest thing they could possibly do at each stage. Many people found themselves writing unnecessary code, so we kept bringing them back to the rules of the game. The retrospective brought up questions of where to start, and whether a cell should be responsible for its own state, or whether a separate entity should know where all the cells are.

In iteration 3 we encouraged people to try a different starting point, to see how that worked. We stipulated that the code could not contain any booleans, like true or false or strings or numbers representing boolean states. The third iteration was sneakily only 30 minutes long, which we didn’t tell anyone until after the retrospective! There was a good discussion about using a grid to hold the cells, versus having an array of cells who know their coordinate position.

Throughout the day, at various points, we were able to have Skype video calls with other code retreats. We found this very enjoyable: we discussed the different implementation options with other people who were also tackling the same problems. During the day, Sheffield managed to communicate with all the other code retreats: Valladolid in Spain, Cronos in Belgium, Bucharest and Timisoara in Romania, and finally, towards the end of our day, Pittsburgh in Pennsylvania, USA, just as they were at the end of their second iteration.

We also had two projectors constantly showing the twitter #coderetreat hashtag on tweetviz.com and a slideshow of pictures on hashalbum.com. These things really helped us to feel connected to a bigger community of people sharing a similar experience at the same time.

After lunch we introduced Keith Braithwaite’s TDD as if you meant it and for iteration 4 we challenged people to obey the strict structure given. The purpose of this was to really break everyone’s normal processes to avoid mental shortcuts. It really ensures that the solution is exactly what the tests require, and nothing more. It was a tough challenge but it was taken well. A lot of people found they came to a better solution when these restrictions were applied.

In iteration 5 nobody was allowed to use if statements. (Or case statements, ternary operators, etc.) We also focussed on ping pong pair programming. This is where one person writes the test, the other person writes just enough code to make it pass, then writes the next test and hands back. During the day i had seen a lot of rather uneven pairing, where one person was doing most of the work, and the other was mostly just watching and commenting. Ping pong helps to address that by bouncing back equally between the two. Comments in the retrospective were that you had to concentrate harder, and felt more engaged because of it. I was surprised that many people had not paired that way before.

Iteration 6 was the last one for us. (Unlike Valladolid who went on to 8 iterations!) We gave people a bit longer and told them to just enjoy this one. The restrictions were that no method could be more than 3 lines long, and the code you wrote had to be the best you could possibly do. You had to write something you could be totally proud of. For most people, they said their code wasn’t the best they could possibly do, but they were definitely proud of it! :)

At the end of the day we did a raffle. Entry to the raffle was by way of a donation to Bletchley Park, for which we raised £200. Names were shuffled in a Ruby array and winners received either a copy of Apprenticeship Patterns or a software craftsmanship motivational calendar.

With that done, all that was left was a trip to the pub to relax after a good day’s work! :D

Thanks and kisses

I thank Tom for being a fantastic co-facilitator, and Chris for doing an excellent job of organising everything: food, refreshments, sponsorship, venue, my hotel last night, and probably a whole lot more that went so smoothly it was unnoticed.

Thank you very much indeed to the sponsors and supporters: epiGenesys, University of Sheffield Enterprise, O’Reilly UK and The GIST Foundation. It would have not been nearly as awesome without your help.

Thanks to all the people around the world who talked to us over Skype – it was great to feel part of something so much bigger than just us.

Thank you so very much to everybody who participated today. You really made it a great day for everyone.

Colemak keyboard layout

At eden lately there has been a surge of interest in the Colemak keyboard layout and TypeMatrix keyboards.

Colemak is an alternative keyboard layout to Qwerty, which as legend has it put the keys in a non-optimal position to slow people down on old typewriters in order to reduce jamming.

The diagonal arrangement of keys on most keyboards also harks back to the typewriter era. TypeMatrix avoids this historical baggage by arranging the keys in columns, and providing a hardware switch to both Colemak and Dvorak layouts.

My typing history

I switched to Dvorak almost ten years ago because i wanted a keyboard layout which was designed to be more efficient and comfortable to use than Qwerty. I became pretty fast on Dvorak: my typeracer average score was 97 words per minute.

For a few years i have suspected that Colemak is even better than Dvorak, and i would have switched sooner had i known that my TypeMatrix keyboard supports Colemak. You see, for pair programming, it’s really useful to have a keyboard with your chosen keyboard layout built in, otherwise you have to constantly change the settings on the operating system.

At the end of January, Tom Brand found out that TypeMatrix also enables Colemak. For some reason, they don’t advertise this fact anywhere! For the record, you press Fn+F5 and hey presto you’re in Colemak mode!

The deciding factor for me was this keyboard layout analyzer which allows you to type in your own text and see all sorts of statistics for different layouts. I tried it out with emails i have written, code samples and tweets, and in every case Colemak was significantly better for me than Dvorak (and of course, far better than Qwerty).

Learning Colemak

So at the beginning of February i started learning Colemak. I have been using aTypeTrainer4Mac which has a horrible user interface, but actually works really well in encouraging you with your progress, moving up through the levels at an appropriate pace.

In the middle of February i had a holiday during which i did a lot of Colemak practice, and used Colemak almost exclusively, so that when i came back to eden i was ready to pair program with Colemak.

I am still quite slow going, and have to apologise for all my mistakes, but for the last two weeks i have been getting better all the time. It is starting to come more naturally to me now, patterns are getting stored in my brain, and it feels really comfortable.

Colemak compared to Dvorak

Only now that i’ve switched to Colemak can i realise the flaws of Dvorak. The L was a strain, and i did not like the second finger stretches to Y and F. It turns out the G and J are much more sensible characters to put there.

It’s great to have the X, C and V back to where they were on Qwerty, as well as the comma and full stop, and all the symbol characters. Not that i need to look anyway: my new TypeMatrix skin has none of those keys marked!

My best typeracer Colemak speed so far has been 44 words per minute. Not a patch on my previous Dvorak speed, but i will keep practising and hope one day to break 100 words per minute.

On teaching kids Colemak

I was recently asked whether Colemak/TypeMatrix would be good for school children to learn. Whilst i hate to think that the baggage of the past continues to be passed on to another generation, the truth is that we still live in a Qwerty world.

TypeMatrix keyboards are expensive, and Colemak isn’t easily available on all computers (unlike Dvorak). TypeMatrix does not yet make a Colemak skin, and the skins they do make look cluttered because of the overlap with the function keys. I enormously prefer the blank layout, but i can’t imagine many kids getting on too well with that!

I don’t know what the answer is just yet. I’d like to see more people realise the benefits of Colemak as a superior keyboard layout and make the switch. I would also like to see more Colemak keyboards made that don’t require downloading any software or switching any settings.

Maybe as a society we can begin to wean ourselves off the hangups of obsolete 19th century typing equipment and get used to a 21st century solution!

Code Retreat in Winchester

All day today there was a Code Retreat at Eden Development. About 20 people came, from all over the country, and we spent an excellent Saturday pair programming together, sharing ideas, having stimulating conversations and getting to know each other much better.

At a code retreat everybody works on a single problem: Conway’s Game of Life. You pair with different people in each 45 minute session. You have to TDD the development, but you can use whichever programming language you choose as a pair. At the end of each session all the code must be deleted. You do a retrospective as a group, have a little break, then go and pair with somebody else.

We got through 6 sessions, which means i pair programmed with 6 people i didn’t know very well before today. It was great! The first two sessions i paired with Paul and then Quentin. To start with, we were pretty much feeling our way through the problem, implementing the rules of the game, and then getting stuck with determining the position of each cell.

In the third session i paired with Ben and we decided to try a completely different approach: dealing purely with coordinates to represent the positions of live cells. It actually worked quite nicely, although implementing the rule logic became quite difficult.

After lunch we were invited to try “TDD as if you mean it” which has very strict rules about where and when you should create your code, and when you can move it. It’s quite restricting the rules seemed to hold us back from getting very far. I was with Louis that time, who was very good at helping me to program in Java, which i’m not so familiar with.

At the 5th session we were allowed to just do whatever we want, so long as it was still test driven. I paired with Paweł and we just went a bit wild with linking cells to each other and getting them to link back respectively. We were going with North, South, East, West, but we eventually realised that you could really link any cell to any other, and the direction doesn’t matter. At that point it becomes more of a network problem. You could say that as a software coder i live or die depending on the community and people i know. That was an interesting insight.

In the final session I was with Clive and it turned out to be our best session of all. We were extremely controlled in our TDD, making sure we understood the code at each stage, and only taking small steps, and predicting at each test run whether it would pass or fail and what the failure message would be. We had cells that knew their positions, and could receive other cells and decide whether or not to attach to them as neighbours. Meaning we could pass every cell to every other cell and get them to connect based on their positions, then we could count how many neighbours they each have.

I mostly programmed in Ruby today, but there were people coding in Java, C++, C#, Python, and i think Scala, Clojure and PHP. We learnt a lot about how to program the game of life, and more importantly, how not to! A code retreat is a great opportunity to have fun, get to know other people, and code in an environment where it’s safe to try things out and make mistakes.

To find a code retreat near you, look on coderetreat.com or consider running your own!

What's a pomodoro?

At eden, we often use the Pomodoro Technique™ to manage our time effectively. What exactly is a pomodoro? You could find out on the Dizionario di Italiano but i’ll give you a clue: it’s a tomato.

A tomato?! How does a tomato help us manage time and increase our productivity? Well when we talk about pomodoros, we’re actually talking about a 25-minute block of time followed by a 5-minute break to reflect and assess how we’re doing and what we will do in the next 25 minutes. After four of these we take a longer break. If we’re really serious about the technique, we aim to do 12 pomodoros in a day.

This is the Pomodoro Technique created by Francesco Cirillo in 1992. It is called Pomodoro because Francesco used one of those kitchen timers shaped like a tomato.

These are the five simple steps of the Pomodoro Technique:

1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4. Take a short break (5 minutes is OK)
5. Every 4 Pomodoros take a longer break

We don’t actually use a kitchen timer (though i think it would be cool to have some!) but we use software tools instead. We use Apple’s Pomodoro timer which has Growl integration and keeps track of tasks and interruptions. When pairing remotely we use http://tomatoi.st/ which enables both people to see the time as it counts down.

At eden, pomodoro time is highly respected in terms of not interrupting unless it is really urgent. It’s very easy to say, “We’re on a pomodoro” and people know that you’ll talk to them in your next break.

We find that the Pomodoro Technique increases our focus, keeps us on track with what we’re doing, and keeps us in control of our time, rather than time controlling us. For ideas and resources, visit PomodoroTechnique.com.

Using Cucumber to test concurrency issues

Recently i encountered a concurrency problem of the type where there is a queue of things to do, and users press a button to be automatically assigned the next item in the queue. The bug report was that two users could get assigned the same item.

My pair programmer and i tried to reproduce the problem using two computers, but we couldn’t. We were only running one Rails instance, but we know that in the production environment there are multiple load-balanced servers pointing to one database, so we had an inkling that we’d be able to produce it using multi-threading.

To give it a test, we wrote a Rake task which we ran in two terminal windows to mimic the simultaneous access. The Rake task looked something like this:

require File.join(File.dirname(__FILE__), '..', '..', 'config', 'environment.rb')
namespace :test do
  task :take_next_for, :login do |t, args|
    user = User.find_by_login(args[:login])
    user.take_next_item
    puts user.item.inspect
  end
end

This is easily called by running:

rake test:take_next_for['ann']

We ran it for two users simultaneously and inspected the output. Sure enough they were being assigned the same item.

Since there is only one database, we knew that we could fix it with a carefully placed transaction and lock on the database. But we wanted to add a Cucumber feature so that we could be sure it was working, and to give us confidence that the bug would not come back again in the future.

  Scenario: Two users take next item simultaneously
    Given a user with login "ann"
    And a user with login "bob"
    And an available item called "Item 1"
    And an available item called "Item 2"
    When two users attempt to take the next item at the same time
    Then they should each have taken different items

Notice we can’t actually say who gets which item – it’s a race condition. We can only check that both of them have an item and that they are not the same item. We could alternatively check that both of the items have successfully been taken.

Testing this concurrency issue in Cucumber turned out to be somewhat tricky. We tried using simple Ruby threads in Cucumber, but it wasn’t properly simultaneously. I guess the single Cucumber environment still only does one thing at a time. So it was back to the Rake task.

When /^two users attempt to take the next item at the same time$/ do
  t1 = Thread.new { `RAILS_ENV=cucumber rake test:take_next_for['ann']` }
  t2 = Thread.new { `RAILS_ENV=cucumber rake test:take_next_for['bob']` }
  t1.join
  t2.join
end

We ‘join’ the two threads to make sure they’ve both finished before carrying on.

It’s slow because it loads up a whole new Rails environment for each of the Rake tasks, but that is exactly what we want to do, to mimic the concurrency of the production system.

The next problem we encountered was that Cucumber scenarios are run inside a transaction which means that a Rake task running outside of it cannot see the users and items we just created. So we had to tag the scenario as @no-txn so that they would be available externally and @clean-up-afterwards so that we could remove them from the database.

After "@clean-up-afterwards" do
  User.destroy_all
  Item.destroy_all
end

With this in place the Cucumber scenario failed as we hoped it would! Then it was simply a matter of creating a transaction from the moment we find the next item (with a database lock) until we have successfully assigned the item. This is a simplified version of what we ended up with:

class User < ActiveRecord::Base
  has_one :item

  def take_next_item
    transaction do
      item = Item.available.by_priority.find(:first, :lock => true)
      self.item = item
    end
  end

end

The Cucumber scenario passed and the problem was solved. In the live system, if two users now try to take an item at the same time, one of them has to wait a moment until the database has finished assigning to the first user so that it can assign a different item to the second user.

How would you have tested a concurrency issue like this? Are there better ways of imitating a multi-server production environment than the solution we came up with?

760th day at Eden

We have a new intern at Eden. Tom Crayford studies Software Engineering at Sheffield University and is doing a 2½ month internship with us, with the possibility of becoming an apprentice at the end of it.

In the style of Tom’s two recent blog posts, First day at Eden and Second day at Eden i thought i might also write about my day, since it was a particularly satisfying one. It just so happens to be two years and a month (760 days) since i joined Eden!

Straight after this morning’s stand-up meeting, I had a quick debrief of a meeting we had with a potential new client yesterday evening. Then i helped Todd to write an email. We draft our emails on Google Wave these days, which is often fun. Four of us were editing the email at once, which means we quickly get to something we’re all happy with before sending it.

I went out for a walk with Frances to pay in some cheques and buy some Friday Treats for everyone!

At lunch time some of us had several rounds of TypeRacer in preparation for Learn To Type Correctly Week next week! I think it’s incredible how so many people have got enthusiastic about learning to type well after Corey Haines announced it. If you don’t believe me, check the twitter hashtag, #learn2typewk!

Something quite unusual happened after lunch. We had a message from Richard Knoll at Mercia Cycling Club in trouble and needing help because the site was not responding. Richard had found us on Google after searching for Ruby on Rails. I agreed to look at it with Tom for an hour and see if we could figure out what was wrong. We determined that rubygems and Radiant had been upgraded on the server and we needed to tweak a few configuration files. With help from Chris and Spencer, the site was back within the hour! Chris then helped me to raise an invoice for an hour’s work.

It’s interesting that we can do anything from a fast restore of an unresponsive website, to projects that take several months from start to finish, requiring two or three pairs of developers working at a time.

Tom and i continued to pair together for the rest of the afternoon. We were able to add value to a project to help a charity in Cambodia. I always learn something whenever i pair with someone. Tom is no exception and i very much enjoyed pairing together today. We all have things we can teach each other.

Tonight i think i might learn a bit from the Ruby Kōans, possibly study a bit of SICP, and definitely see who gets evicted from Big Brother!

Remote trio programming

If pair programming is good, trio programming must be great, right?

Well, normally no, probably not, but today i had a trio programming experience that worked really well. Two of us were new to the codebase and together we learnt a lot from the person who knows the code well.

Of course, we all did not crowd around a single computer. That would not be comfortable at all. Due to the snowfall, most of the edenites were working from home today, so it gave us a great opportunity to find an effective way to pair remotely.

Initially we tried iChat screen sharing, but the screen updates are too slow to be satisfying. Steve had the idea of using GNU Screen so that we could all access the same terminal window via SSH.

Using a VPN to the office network, we were able to tunnel to Steve’s laptop and access the screen. In fact we found it useful to have two screens running: one for editing code in Vim and another screen for running Cucumber features. The exciting thing is, we don’t all have to look at the same screen at the same time: each person is free to switch screens on their own machine without affecting the others.

A Skype conference call completed the experience so that we could talk through our thought processes and learn the details of the codebase.

It was altogether a very profitable day. The snow, instead of being a hindrance today, helped us to find a very effective way of allowing three people to collaborate on a codebase.