April 2009

Goodbye CruiseControl.rb, Hello Hudson

Imagine you have a friend who writes a blog. Maybe you actually do. Let’s call him ‘Chump’. One day you’re chatting, and the conversation turns to technology. It turns out that Chump is using Dreamweaver to write his blog entries, and manually uploading them to his site via FTP. You’re appalled.

How do you update the RSS feed?

you enquire, trying to conceal the horror in your voice.

Oh, I just edit the Atom file manually, it’s not that hard.

says Chump.

Maybe nobody ever told Chump about wordpress.

At work, we just switched our build server from CruiseControl.rb to Hudson, and we won’t be looking back.

Ruby people, for some reason, seem distinctly inclined to use build servers made out of Ruby too. That’s nice and everything, but these things are childsplay in comparison to the maturity, usability, and feature-set of hudson.

Here’s why I recommend you switch to hudson for your Ruby / Git projects:

  • open source
  • piss easy to set up, even if you have no idea what java even is
  • solid git support
  • works with CCMenu (or your favourite CruiseControl monitoring desktop widget)
  • kill builds from the GUI
  • in fact, manage everything from the GUI
  • distributed architecture, allowing you to delegate builds to multiple machines
  • huge, active plug-in support
  • you have better things to do with your time than faff around hacking on your build server

The problem is, it doesn’t have a smug website with fancy branding, so you probably overlooked it the first time. Go back and take another look.

Ruby Programming

Comments (23)

Permalink

The Future of Automated Acceptance Testing

I participated in a workshop today run by Willem van den Ende and Rob Westgeest at SPA2009 on acceptance testing.

As usual at such conferences, it was great to be able to mingle with other people who take the value of acceptance testing for granted, and be able to concentrate on the issues that are facing us as we go ahead and use them. A few people seemed pre-occupied with how best to express their acceptance criteria, and what technology to use to automate their application but our choice of Cucumber and Rails made me feel pretty satisfied we were winning in this regard.

I was more interested in issues of scale:

> Given that you want to drive out each new piece of functionality with automated acceptance tests, and you want to keep adding new functionality to your product, how do you keep your test run fast so that you still get rapid feedback from your test suite?

At Songkick this is starting to become a significant issue for us.

One option is to distribute your test run across multiple machines and run them in parallel. We’ve been impressed by the likes of IMVU and the guys at weplay have spiked a mechanism for doing this with Cucumber test suites. SeleniumGrid has been blazing a trail to parallelize notoriously slow Selenium tests.

Another option, the importance of which only became clear to me today, is to be judicious about which tests to run. At CITCON Amsterdam last year, Keith Braithwaite described how he’s overcoming long test runs by ‘retiring’ tests that have not failed for a long time from the commit built to the nightly build. I have started to play with ideas that map each test to the source code it exercises in order to run only the tests that will cover code that has been changed. Sir Kent Beck has recently revamped JUnit as an intelligent Eclipse plug-in which uses statistical models to run the tests most likely to fail first.

This idea of prioritising the tests with the highest chance of failure seems to be the key here: The reason write automated tests is because we want rapid reliable feedback about any mistakes we’ve made. Fail fast has long been a motto of XP teams, but perhaps we’ve forgotten how it can relate to our build.

Update: Following some discussion about this post on the CITCON mailing list, I discovered the output from this workshop at last year’s agile conference along very similar lines: https://sites.google.com/a/itarra.com/test-grids/

Agile / Lean Software Development

Comments (2)

Permalink

SPA 2009 Day 1 - Real World Haskell

This session was a marathon 6 hour tutorial introduction to Haskell on a sunny Sunday afternoon. I’d installed the GHC beforehand and tried out a couple of ‘hello world’ style tutorials, but other than that walked in with no experience of Haskell or any other functional programming.

Here are my notes:

Basic Syntax

make up new types with

type Lat = Double

Backticks add syntactic sugar to re-arrange the normal order of “function arg arg”:

div 5 6 == 5 `div` 6

indentation is important:

latLngDistance lat1 lng1 lat2 lng2 =
    sqrt((latD * latD) + (lngD * lngD))
    where latD = latDistance lat1 lat2
          lngD = lngDistance lng1 lng2

Lists

Strings are just lists (aka arrays) of characters, but rendered differently.

Use colons to construct lists:

1 : 2 : 3 : [] == [1, 2, 3]

Colon adds to front of list, but is ‘right-associative’ so the right-most expression is evaluated first

1 : (2 : (3 : [])) == [1, 2, 3]

Many operators are written in haskel themselves. ‘Prelude’ is a library full of these.

Functions on lists

westmost [] = 0.0
westmost [lng] = lng
westmost (lng : lngs) = wester lng (westmost lngs)

Left-hand side is a pattern for parsing / matching and then splitting (for use) the input arguments. A more verbose way of doing the last one would be:

westmost lngs = wester (head lngs) (westmost (tail lngs))

Guards can extend the patterns with conditions:

wester lng1 lng2
    | lng1 < lng2     = lng1
    | otherwise       = lng2

Defining Types

type Lat = Double
type Lng = Double
type Name = String
 
data Location = Location Lat Lng Name

Second Location is the name of the constructor. Doesn’t have to match the type name.

With data types, you still have to use pattern matching to pull out the memebers:

distance (Location lat1 lng2 _) (Location lat2 lng2 _)
    sqrt((latD * latD) + (lngD * lngD))
    where latD = latDistance lat1 lat2
          lngD = lngDistance lng1 lng2

Underscore is just used to say ‘blah’ - don’t care about this matched element.

Point-free Style

let double xs = map (*2) xs
let double = map (*2)
 
double [1..5]

This is a name for the practice of leaving the last argument out to build a special function that’s more generic.

prepend s = (s ++)
append s = (++ s)
saveLocs = 
    writeFile "output.blah" . prepend prefix . append suffix

or

saveLocs arg =
    writeFile "output.blah" (prepend prefix (append suffix arg))

You can even do this (with arity 2 functions)

prepend = (++)
append = flip prepend

Dot Function

(.) f g a = f (g a)

Lazy

Haskell is lazy. You can think of each function as pulling just what it needs from the next function. E.g. we can create a list of all integeers:

allInts = [1..]

So you can do stupid stuff:

reverse [1..]

This will just hang forever. Or

infiniteListOfOnes = 1 : infiniteListOfOnes

Parametric Polymorphism

Argh.

Classes

A class is similar to an interface or Mixin, but it NOT a type.

It basically defines a protocol that will be implemented by a type.

class Collection c where
  cLength :: c a -> Int
  cMap    :: (a -> b) -> c a -> c b

instance then defines the implementation for a specific type

instance collection [] where
  cLength = length
  cMap = map
 
instance collection Tree where
  cLength = <tree length function>
  cMap = <tree map function>

Like generics in Java.

IO Actions

IO is impure, so when you want IO done, what you actually do is define an action, which will be lazy evaluated (i.e. executed) as necessary.

There is a syntax for this where you use chevrons to create actions with several steps. Or you can use the nicer ‘do’ syntax.

Type Signatures

It’s common to use type signatures even though you don’t have to. It helps you think about the goal for a new function before you write it, and it gives you machine-run safety checks for free. Common to use them, at least for top-level function.

Uses in the Real World

Ben is using Haskell at Barcap where they have an embedded DSL which quants use to describe products. Haskell then compiles those descriptions, giving them a bunch of checks for the validity of the description.

Seems like Haskell is a good fit where you want to build DLSs with lots of type safety.

Why is it useful?

Key ideas that make Haskell special:

  1. purity - execution and evaluation separate
  2. types - lots of checking
  3. laziness

Community

Hoodlums - A user groups for people into Haskell. Formed at SPA last year. Once a month in London.

http://groups.bangstrom.com/hoodlums

Agile / Lean Software Development

Comments (0)

Permalink

If Code is Written Solo in a Forest, Does it Make a Sound?

I’ve written before about my views on the importance of pair programming as a way of building a common conciousness in a team. When two people work on a piece of code together, not only is it instantly reviewed for correctness and readability, but already two people on the team understand exactly why the code is like that - the design decisions and trade-offs that went into building it that particular way, and are aware of any re-usable modules, patterns, idioms or conventions that emerged during the coding session. When each of those people goes off to work with other members of the team, those memes propogate around the room surprisingly quickly.

When you write code alone, you immediately lose this benefit, and on a system of any significant size, this is really important. You might be writing terrific code, making great decisions and innovating really creatively, but if nobody on your team has experienced those decisions and innovations with you as they happened, all you are really sharing with them is the much more shallow end result: the code.

It’s almost like they never even happened.

Agile / Lean Software Development

Comments (0)

Permalink

WANTED: Software Craftsmen (and Women)

My employer, Songkick.com are hiring for developers.

To join this team you must be, or believe you are capable of being, someone who creates beautiful software. Nothing less.

If you think that sounds like you, do yourself a favour: stop working for those idiots who keep making you rush out all that half-arsed crap and come and work for a proper team where quality matters to everyone.

One catch: you must love live music. Interested? Tell us about yourself.

Agile / Lean Software Development
Ruby Programming

Comments (0)

Permalink