codeRambler Ramblings on code, the web, and technology

Selenium running with Firefox 3
Thursday October 16th 2008, 11:54 am
Filed under: Agile, Web development

If you have been using Selenium as part of your continuous build process, then the release of Firefox 3 has probably caused you some problems – specifically the inability to have Firefox 3 launch with the custom profile to allow Selenium to run.

It turns out Selenium installs a tiny little extension into the Firefox profiles it generates that basically just lets selenium kill firefox by telling it to go to a magic chrome url. Firefox extensions specify which versions they are compatible with and the one embedded in selenium had 2.0.0.* as their maximum version…

It looks like the solution is actually very simple and is described in detail over at Space Vatican.

Comments Off


Agile Merit Badges
Thursday September 06th 2007, 12:57 pm
Filed under: Agile, Ramblings

When I was growing up, I was part of a Scout Troop. In fact, in 1982 I was in the annual Gang Show celebrating 75 years of the Scouting Movement. This year they celebrated 100 years… which makes me feel old.

I really enjoyed Scouts. We did things together as a group – mostly outdoors tasks that involved a lot of running, shouting and general fun times. These tasks accumulated and once completed, allowed the Scout to get a badge that was then sewn on to the Scout uniform. There were badges for many things including First Aid, Camping, and even Helping Others (and Sewing – the badges don’t sew themselves on!).

There are some parallels between the Souting Movement and Agile. We work as a team to do things together – and we have fun doing it. So what about merit badges for Agile?

How about a special Agile scarf (where you can sew the badges on to) and even a woggle (different colours to reflect your Agility)? Maybe you could get a Bronze, Silver or Gold TDD badge to reflect the test driven development experience of a developer! How about a badge for Pair Programming? You can even have one just for regular attendance at the daily stand-up.

It’s all a little bit silly, of course… but it would be so much fun to do!



When is a task considered to be Done?
Tuesday July 31st 2007, 9:57 am
Filed under: Agile, Javascript, Web development

In recent Agile projects I have been involved with, we often talk about the word “Done”. Specifically we are talking about when a task/story that you are working on is finished.

I heard someone in my team say that “it isn’t Done until it’s in the green column” – referring to the colour-coded columns we move story/task card through as we take them from the “holding pen” through “development” (red), “ui review” (black), “customer preview” (orange) and “qa” (blue) to “done” (green).

So when is something considered to be Done? Is it Done when you have finished writing the code? When you have finished testing the code? What has to happen to a story/task before it is allowed to make the green column and be called Done?

My definition of Done:

  • All code has been developed using Pair Programming or Peer Review
  • The acceptance criteria for the story/task have all been met to the customer’s satisfaction
  • Unit tests have been written that test the code and document it’s functionality
  • Supporting acceptance tests that support the acceptance criteria
  • The code is checked in to the build server – and all the tests continue to pass
  • Any QA issues are resolved (which may necessitate returning the story/task to development again)

Of course each story/task will have a different path to Done, and some will take a shorter route than others – but the definition criteria above should remain constant for all. If you make sure your stories/tasks follow this prescribed course to Done, you will have less “returns” later on and produce better quality code from day one.

You will! Try it and see.



It doesn’t smell right!
Thursday July 05th 2007, 2:38 pm
Filed under: Agile, Javascript, Web development

How often do you refactor your code so that it works better or is easier to understand? Hopefully this is a constant process where you are refining and adapting on a regular basis (note that this is not quite the same as just rewriting code for the sake of it). Recognising that a section of code “smells” and needs to be refactored is not a particularly straight-forward task, some of the signs I use to spot “smelly” code include:

  • repeated blocks of the same code in different areas of the code base
  • huge long “if...else if” blocks
  • variable names that have no meaning or description of their contents
  • function names that are not descriptive of their purpose
  • code that doesn’t have supporting unit tests

Of course there will be different “smells” for different programming environments, I’m a Javascript developer and my “nose” is focussed on how my javascript code performs within web applications.

Have you sniffed your code recently to check that it doesn’t smell?