Kerry Buckley

What’s the simplest thing that could possibly go wrong?

TDD example with Rails, Cucumber and RSpec

one comment

In the unlikely event that anyone wants to scroll through the whole history of the TDD demo Rails app I did the other day, I wrote a little script to munge it all into one page. And here it is.

Read the rest of this entry »

Written by Kerry

March 27th, 2015 at 11:22 pm

Posted in Uncategorized

Telling a story with git

leave a comment

This may be the ugliest bash one-liner ever:

git log --pretty=%h | tail -r | while read sha ; do if [[ -z $(git rev-parse --verify $sha^2 2> /dev/null) ]] ; then echo '----' ; git show --summary $sha | tail -n+5 | egrep -v '^ (?:create|delete) mode' ; git --no-pager diff --color -U999 $sha~ $sha | awk '/diff --git/ { sub("^a/", "", $3) ; print "===" $3 } /diff --git/, /@@/ { next } { print }' ; fi ; done | ansifilter -H | sed 's/^----$/<hr \>>/;s/===\(.*\)/<h2>\1<\/h2>/' > history.html

It runs through the git history of a project, printing the full message for each commit, followed by a complete listing of each changed file, with added, removed or changed lines highlighted. It then outputs the result into a big ugly HTML file. Like this.

Written by Kerry

March 27th, 2015 at 11:21 pm

Posted in Software

Setting up a new Mac

leave a comment

I decided to do a clean install on my new [work] Mac, rather than just copying everything across from my old one. I thought I’d note down some of the things I installed, in case it comes in handy for anyone else (particularly new Mac users).

I’ve mostly ignored common cross-platform stuff like DropBox, 1Password etc, and setting up things like git and ruby. If you just want to quickly set up a Mac for ruby development, Thoughtbot’s laptop project (or Adam’s fork) might be the way to go.

If you’ve got any other can’t-live-without Mac apps that I might have missed, let me know!

From the app store:

Other apps:

Packages from homebrew (see above)

brew install direnv dos2unix elixir git mysql node phantomjs postgresql qt redis sqlite ssh-copy-id the_silver_searcher tig youtube-dl

Hidden settings

Show ~/Library in Finder:

chflags nohidden ~/Library

Enable copying from quick look preview windows:

defaults write QLEnableTextSelection -bool TRUE; killall Finder

Written by Kerry

November 8th, 2014 at 10:57 am

Posted in Apple

Quick-and-dirty “edit text in vim” Mac service


Today I wanted to edit a big chunk of text (the source of a wiki page) in a browser textarea, and remembered that I used to have an app that let me open any text in vim, then paste the result back where it came from. Eventually I found the app I was thinking of – QuickCursor – but it turns out it’s no longer available.

Coincidentally I was looking into how to do something else tonight, and the answer was to create a service that ran an AppleScript, and it occurred to me that I could probably make a basic “edit in vim” service fairly easily. Turns out I was right…

Open the “Automator” app, and create a new service. Add a shell script action, and paste in the following script (this assumes you’ve installed the mvim script that comes with MacVim):

filename=`mktemp ~/.edit-in-vim-XXXX`
cat > $filename
/usr/local/bin/mvim -f $filename
cat $filename
rm $filename

Creating a service in Automator

Select “Output replaces selected text” in Automator, save the service, and you’re done. Just select some text (it doesn’t select-all for you like QuickCursor did), right-click and run your new service. You can also assign a keyboard shortcut in System Preferences:

Setting a keyboard shortcut

Written by Kerry

September 5th, 2013 at 8:11 pm

Posted in Software

Tagged with , , ,

FESuffolk Jasmine lightning talk

leave a comment

At last night’s FESuffolk meeting I gave a lightning talk on getting started with unit-testing Javascript/coffeescript using jasmine-headless-webkit. I made a screen recording, so if you missed it you can still experience my frantic babbling (I had Keynote set to auto-advance, using the Ignite 20 × 15 second slide format, and as usual I tried to cram too much into each slide).

If you don’t want to watch the recording, you can look at the slides and guess what I might have been saying, read the example code (the commits try to build up in small steps), or just play with the utterly pointless app that the example implements.

Written by Kerry

March 26th, 2013 at 8:00 pm

Interesting little rSpec gotcha


This one had Adam and me stumped for a while. Trying to check that a method is only called on objects that respond to it:

describe "Foo#call_all_the_things" do
  let(:foo_1) { stub :foo_1, bar: "hello" }
  let(:foo_2) { stub :foo_2 }
  subject { foo_1, foo_2 }

  it "only calls bar on objects that respond to it" do
    foo_1.should_receive :bar
    foo_2.should_not_receive :bar

class Foo
  def initialize *things
    @things = things

  def call_all_the_things method
    @things.each do |thing|
      thing.send method if thing.respond_to? method

  1) Foo#call_all_the_things only calls bar on objects that respond to it
     Failure/Error: thing.send method if thing.respond_to? method
       (Stub :foo_2).bar(no args)
           expected: 0 times
           received: 1 time

Hmm. Why is it calling bar on the thing that doesn’t respond to it? Perhaps rSpec doubles don’t handle respond_to? properly?

[1] pry(main)> require "rspec/mocks/standalone"
=> true
[2] pry(main)> foo = stub foo: 123
=> #<RSpec::Mocks::Mock:0x3fd07d246f34 @name=nil>
[3] pry(main)> foo.respond_to? :foo
=> true
[4] pry(main)> foo.respond_to? :bar
=> false


FX: lightbulb above head

Of course! To do the should_not_receive check, it needs to stub the method, which means it responds to it!

Two possible solutions: either let the fact that the missing method isn’t called be tested implicitly, or specify that when objects that don’t respond to the method exist, no NoMethodError is raised.

Written by Kerry

March 20th, 2013 at 3:04 pm

Posted in rspec,Ruby,Software

Adastral Park code retreat

leave a comment

Code retreat poster

Ever since attending code retreat at Bletchley Park (the UK leg of Corey Haines’s code retreat tour) last year, I’d been vaguely intending to try and run an internal one at work. I finally got round to it this month, when a few people expressed an interest in a code retreat as a one-off alternative to the usual developer conferences we run a couple of times a year. I thought I’d share my experiences facilitating a code retreat for the first time, in case it’s helpful to anyone thinking of doing the same.


The “official” code retreat site has some good information on things to consider when hosting and facilitating. I suspect organising an internal company event is easier than a public one, because hopefully you’ll have a venue available and you won’t need to worry about sponsorship. The only one of Corey’s rules I ignored was the one about giving people decent food at lunchtime, but we did at least manage to beg enough budget (thanks Mel!) to be able to provide cheap Tesco sandwiches at lunchtime and a few random snacks and coffee during the day. I don’t feel too bad because rather than asking people to “come out at eight in the morning to spend the day coding”, we were giving them an excuse to spend a work day away from their projects, getting paid to practice.

We also planned to start at nine o’clock rather than the traditional eight. I think for public events the early start, usually on a Saturday, is a good way of selecting only people who really want to take part, but running it at work I wanted to swing the balance a bit towards encouraging people to come (I work on a large site with probably a couple of hundred developers scattered amongst the 3000-odd BT people, and part of the motivation for running this kind of event is to try and put developers from different teams in touch with each other).

With a bit of publicity via mailing lists and posters on site, 27 people had signed up. That seemed like about the right number, although I had no idea how many of those would turn up, or whether anyone would turn up without registering. I turned up at the office in plenty of time, and was lucky enough to get some last-minute tips from the master:


Getting started

As it turned out we had a few glitches to deal with before we could get going – firstly the venue was locked and we only managed to get in because Rupert knew how to find the secret back entrance, then Adam and Anna got kicked out of Tesco for a fire alarm while buying the food – so we ended up starting at closer to 9.30.

Coffee machine hack

Potentially the biggest disaster though was that the hopper was missing from the coffee machine (most likely locked away to stop people like us using it with our own beans instead of paying for catering). Fortunately it takes more than a little detail like that to defeat a room full of engineers, and we soon had a workaround in place using a plastic cup with the bottom cut out.

Once the caffeine supply was assured and we were finally ready to start, I gave a quick presentation covering the purpose of the day, the four rules of simple design and Conway’s game of life:

First session

With everyone hopefully having a reasonable idea of what was going on, people paired up and started the first session. There were about 25–30 people (I forgot to count), split something like 70:20:10 between Java, Ruby and Groovy. In the first session, as expected, everyone was mostly just getting a feel for the problem, and realising that it’s not quite as simple as it appears from the list of rules.

Getting started

First session

After 45 minutes, I put on my best exam invigilator voice and got everyone to stop typing, delete their code and gather round. Pairs were split roughly evenly between those that started with a grid and those that started with a cell, and we had a short discussion about how a grid approach using a two-dimensional array fitted in with the “infinite grid” constraint. Some of those who had started from a cell were thinking about approaches for allowing cells to know about their neighbours, but no-one had got that far yet.

Mixing it up

For the second session, I suggested that those that had started with a grid tried starting from a cell instead, and vice versa. There were also quite a few people who wanted a chance to try Ruby, so they tried to grab the rubyists before anyone else did. Little did they know that they would find themselves exposed to Vim (and in some cases Mac OS X) at the same time, but that’s just a bonus.

In general people who tried both seemed to prefer the cell approach, partly because it made it easier to test-drive the rules. With a grid, people found they were having to implement some kind of to_string or render method to allow the transformed grid to be compared with the expected result. The biggest puzzle with the cell approach was how to handle the relationship between multiple cells.

I introduced a list of possible constraints people might want to consider to make things more interesting:

  • No if statements (or other conditionals).
  • No loops.
  • No methods longer than five lines (or four, or three…)
  • No more than three methods per class.
  • No ‘naked’ language primitives.
  • No built-in data structures.

I also attempted to explain TDD as if you meant it, in case anyone fancied giving it a go. Unfortunately my description was rather garbled, not helped by the fact that I’m not sure I fully understand it myself (I’m still annoyed that I picked the wrong track at SC2009 and missed Keith’s original presentation of the exercise, and it turns out Adam made the same mistake at SPA2010).


Flying fingers

Session three

By the third session several pairs were starting to experiment with storing cell objects either in a set (with each cell knowing its position) or a hash, keyed by position. Some people used a comma-separated “x,y” string as the key, but with a bit of prodding most ended up replacing it with a point class of some kind.

One pair decided to start with a single cell, then initialise other cells with their neighbours. This initially seemed promising, but soon led to complications with circular references, as well as the need to keep dead cells around to maintain a connection between cells with space between them.

Another pair started developing the rules with a cell class, and initially had an alive? method which performed the life calculation. After some discussion they split the class into two – one for a living cell and another for a dead one. This removed a level of nesting from the calculations (which ended up in a different method), but interestingly left alive? in both classes, hardcoded to true and false respectively. We decided that this would have looked less odd in Java, where the method would have been declared abstractly in a superclass or interface.

One pair had decided to try implementing a solution with no if statements, but resorted to cheating by using a case instead!

In general, a lot of people – particularly those new to TDD – were starting to get frustrated, feeling like they were just getting to the point where they were “about to start the interesting bit” as the 45 minutes were up. I told them that we’d just have two sessions after lunch rather than three, with the second session lengthened to give people a chance of implementing a working game.

The countdown begins

Fourth – and as it turned out final – session

After lunch we started the fourth session, but it soon became clear that several pairs had already decided to abandon TDD and clean code in favour of trying to solve the problem. I completely understand how they felt – I wasted most of the sessions at the code retreat I attended simply pushing for the finish line instead of letting it go and concentrating on perfecting the internal quality of the code – but it seemed like we’d lost sight of the key goal of the day a little. I suspect I’m mostly to blame for that, and I’m sure a more experienced facilitator could have done a better job of gently guiding people in the right direction. Anyway, it seemed sensible to bow to the inevitable, let everyone carry on for another 45 minutes and wrap up a bit earlier than planned.

Basking in the glow

With the extra time, a few pairs did manage to get a working implementation, but the prize for the most impressive (cancelled out by a booby prize for abandoning TDD and neglecting the quality of their code!) goes to Jon and Jia Yan, who produced an SWT app that allowed graphical editing of the grid, variable speed and saving and loading files. They used the “set of live cells” approach, with an effectively infinite grid. Resizing the window on screen allowed you to show or hide cells, but the ones off the edge of the visible area continued to multiply.

Matthew and Rupert decided to look at someone else’s solution in Clojure, to understand how a functional approach using list comprehensions can lead to a very concise solution. They also played around with a Ruby version using the same techniques. Looking at the Clojure code led to a slightly rearranged version of the rules for life at a particular location after a clock tick:

  1. Cells which had three neighbours are alive
  2. Cells which had two neighbours are unchanged
  3. All other cells are dead

Paul, stuck on his own after his pair got dragged off onto a conference call (the perils of being a senior manager!), had a play with TDD as if you meant it. I think by the end of the session he was starting to get somewhere. Further than me, at any rate.

Wrapping it all up

After letting Jon show off a glider gun running in their SWT universe, we gathered round for the closing circle, asking everyone what they’d learned, what had surprised them, and what they’d do differently back at work on Monday as a result. Probably the most common comments revolved around the fact that neither of the two most obvious solutions turned out to be the best, suggesting that it’s worth spiking a few alternative approaches before heading blindly off down what may be a blind alley. Quite a few people were new to pairing, TDD or both, and generally seemed to agree that both provided benefits, although a couple of people felt that TDD was making things take much longer. Reassuringly, of the pairs that had abandoned TDD to concentrate on trying to get a working solution, most had found themselves descending into confusion without the tests to guide them.

Final thoughts

Overall, the event seemed to be a success. For quite a few people this was their first experience of TDD, and the opportunity to get first-hand experience by pairing with someone more experienced seemed to be useful. I was particularly pleased to see someone who’s recently come back into software development after a long time away doing a great job of holding his pair back from rushing into implementation without a failing test.

On a less positive note, I didn’t feel we really concentrated enough on “perfect” code and the four rules of simple design. I know from experience that it’s hard to let go of the natural desire to try and finish solving the problem, and I felt that a lot of people were getting frustrated enough without me peering over their shoulders picking holes in their code (however nicely I tried to do it). Perhaps this is a case of horses for courses, with the concentration on design perfection more suitable for a different mix of participants, or perhaps it just reflects my lack of experience facilitating this kind of event.

Also, I don’t think we really had enough sessions for the code retreat magic to start kicking in properly. We’d planned to have the recommended five or six, but a combination of the late start and a general loss of direction after lunch reduced that to four (with the fourth being double-length).

The important thing, of course, is that people learned something by participating, and I hope that was the case. Maybe we’ll do another one one day, and use the experience of this one to make it even better.

Written by Kerry

November 1st, 2011 at 11:42 am

Build and push to upstream git repository in the background

leave a comment

[Updated 11 Feb 2011 – I’m not sure the original version actually worked properly.]

Quite often I’ll make small changes to a project’s code which I’m 99% sure won’t break the build. Of course thanks to Murphy’s Law that probability falls to about 10% if I decide to risk it push the changes upstream without running the full build locally.

Now even if the build only takes a few minutes to run, that’s a few minutes which I can’t spend doing anything else with the code, because if I save a file I can’t be sure whether the original or changed version will be used in the tests. What I’d like to be able to do is to run the build in the background, with changes automatically pushed upstream if everything’s green, or an alert shown if either the build fails or the push is rejected (because someone else has pushed a change while the build was running).

Fortunately with a distributed version control system like git, this is fairly easy.

Firstly, clone the local working repository and set up a remote pointing to the clone:

git clone . ../myproject-staging
git remote add staging ../myproject-staging

Now set up the cloned copy:

cd ../myproject-staging

# Allow pushing into the checked-out branch
git config receive.denyCurrentBranch ignore

# Create a remote for the upstream server you want to push to (change the URI!)
git remote add upstream [email protected]/your/repository/path.git

Do anything that needs doing to allow the cloned project to build (if you have a test database, create a separate instance to avoid tests interacting with your main workspace), and verify that the build runs.

Now add the following to .git/hooks/post-receive:


cd ..
export GIT_DIR=.git
git reset --hard
nohup .git/hooks/post-reset 1> build_output 2>&1 &

This will reset your checked-out working copy to the pushed master, then run .git/hooks/post-reset in the background. Create that file with the following content:


function error {
  growlnotify -s -t `basename $PWD` -m "$1"
  exit 1

# Replace this with your build command
bundle install --local && rake || error "Rake failed"

git push upstream master || error "Git push failed"
growlnotify -s -t `basename $PWD` -m "Built and pushed successfully"

Make sure both these hooks are executable:

chmod u+x .git/hooks/post*-receive

Now, back in your normal working repository you should just be able to type git push staging (add --force if you’ve rebased your normal master and get an error about the push not being a fast-forward), and the project will build in the staging repo. If everything works, it’ll push upstream and you’ll get a Growl notification (assuming you have Growl and growlnotify, or the equivalents for your OS, installed). If it fails, you’ll also get a Growl notification. I’ve made the alerts sticky, so I don’t miss them – if you don’t want that, just remove the -s flag. The build errors will be in the build_output file.

Written by Kerry

December 20th, 2010 at 5:14 pm

Posted in git,Software

Tagged with , ,

The Wandering Book

one comment

After procrastinating and holding on to the wandering book for much too long, I finally made my entry. You can read it on the site, and here’s the text if you can’t decipher my handwriting:

I work in a large “enterprisey” company where craftsmanship is, unsurprisingly,
not the dominant model of software development. However, a craftsmanship ethos
still exists in some of the remaining pockets of in-house development, and if
anything appears to be strengthening.

For the first few years of my software career, I treated it very much as a day
job. I turned up; I wrote some code (or, for a horrendous proportion of the
time, some documents); I went home. I learned just enough to enable me to
complete whatever I was working on, but no more. I used the tools I was given,
or those I was familiar with, regardless of their suitability for the task at

Then I started working with someone who was trying cool new stuff. Dependency
injection. Automated testing. Continuous integration. I realised how
out-of-touch I was in my ideas of how software should be developed, and started
trying to put that right. I read about XP and Agile, and started following
blogs and reading articles. I went to XPDay, and turned up at the odd XTC pub
night when I happened be in London on a Tuesday.

More importantly, I started caring about my code. Instead of thousand-line
procedures, I started separating concerns and following OO principles. I wrote
unit tests, and after a while I got the hang of TDD. Month-long manual testing
and bug fixing phases gave way to an automated nightly build and a quick
confidence check, and eventually to something approaching continuous

Of course, the more widely I look at what others are doing, the more aware I am
that even when I think I might be doing something reasonably well, there are
always people out there doing it much, much better. I may never approach their
level, but I can learn from their work and thus improve mine. In turn I hope I
can pass something on to others.

So, to finally get to the point, I agree with earlier contributors that
craftsmanship is about caring, learning, practicing and sharing. Underpinning
all this though is community. Not ‘the’ software craftsmanship community, but
the community of other developers you work with; the communities around the
languages and tools you use; the agile, lean and XP communities; the community
of random people you met once at a conference – or maybe have never met at all
– and started following on Twitter.

Without these communities, we become isolated, and may start believing that the
way we currently work is ‘best practice’. We need our fellow professionals to
compare ourselves against and to learn from, otherwise we can lapse into
complacency and let our skills (and our profession) stagnate.

Technorati Tags: , ,

Written by Kerry

July 2nd, 2010 at 8:56 am

Posted in Software

Memoised remote attribute readers for ActiveRecord


I was recently working with an ActiveRecord class that exposed some attributes retrieved from a remote API, rather than from the database. The rules for handling the remote attributes were as follows:

  • If the record is unsaved, return the local value of the attribute, even if it’s nil.
  • If the record is saved and we don’t have a local value, call the remote API and remember and return the value.
  • If the record is saved and we already have a local value, return that.

Here’s the original code (names changed to protect the innocent):

class MyModel < ActiveRecord::Base
  attr_writer :foo, :bar

  def foo
    (new_record? || @foo) ? @foo :

  def bar
    (new_record? || @bar) ? @bar :

  def remote_object
    @remote_object ||= RemoteService.remote_object

The remote_object method makes a call to the remote service, and memoises the returned object (which contains all the attributes we are interested in).

I didn't really like the duplication in all these accessor methods – we had more than the two I've shown here – so decided to factor it out into a common remote_attr_reader class method. Originally I had the method take a block which returned the remote value, but that made the tests more complicated, so I ended up using convention over configuration and having the accessor for foo call a remote_foo method.

Here's the new code in the model:

class MyModel < ActiveRecord::Base
  remote_attr_reader :foo, :bar

  def remote_foo

  def remote_bar

  def remote_object
    @remote_object ||= RemoteService.remote_object

Here's the RemoteAttrReader module that makes it possible:

module RemoteAttrReader
  def remote_attr_reader *names
    names.each do |name|
      attr_writer name
      define_method name do
        if new_record? || instance_variable_get("@#{name}")
          instance_eval "@#{name}"
          instance_eval "remote_#{name}"

To make the module available to all models, I added an initialiser containing this line:

ActiveRecord::Base.send :extend, RemoteAttrReader

Here's the spec for the module:

require File.dirname(__FILE__) + '/../spec_helper'

class RemoteAttrReaderTestClass
  extend RemoteAttrReader
  remote_attr_reader :foo

  def remote_foo
    "remote value"

describe RemoteAttrReader do
  let(:model) { }

  describe "for an unsaved object" do
    before do
      model.stub(:new_record?).and_return true

    describe "When the attribute is not set" do
      it "returns nil" do be_nil

    describe "When the attribute is set" do
      before do = "foo"

      it "returns the attribute" do == "foo"

  describe "for a saved object" do
    before do
      model.stub(:new_record?).and_return false

    describe "When the attribute is set" do
      before do = "foo"

      it "returns the attribute" do == "foo"

    describe "When the attribute is not set" do
      it "returns the result of calling remote_<attribute>" do == "remote value"

To simplify testing of the model, I created a matcher, which I put into a file in spec/support:

class ExposeRemoteAttribute
  def initialize attribute
    @attribute = attribute

  def matches? model
    @model = model
    return false unless model.send(@attribute).nil?
    model.send "#{@attribute}=", "foo"
    return false unless model.send(@attribute) == "foo"
    model.stub(:new_record?).and_return false
    return false unless model.send(@attribute) == "foo"
    model.send "#{@attribute}=", nil
    model.stub("remote_#{@attribute}").and_return "bar"
    model.send(@attribute) == "bar"

  def failure_message_for_should
    "expected #{@model.class} to expose remote attribute #{@attribute}"

  def failure_message_for_should_not
    "expected #{@model.class} not to expose remote attribute #{@attribute}"

  def description
    "expose remote attribute #{@attribute}"

def expose_remote_attribute expected expected

Testing the model now becomes a simple case of testing the remote_ methods in isolation, and using the matcher to test the behaviour of the remote_attr_reader call(s).

require File.dirname(__FILE__) + '/../spec_helper'

describe MyModel do
  it { should expose_remote_attribute(:name) }
  it { should expose_remote_attribute(:origin_server) }
  it { should expose_remote_attribute(:delivery_domain) }

  describe "reading remote foo" do
    # test as a normal method

Technorati Tags: , , , , , , ,

Written by Kerry

April 27th, 2010 at 11:29 am

Posted in Rails,Ruby