You can find out everything you need to know by visiting our page on Eventbrite, where you can find FAQs, links to further information, and the all-important sign-me-up button. Oh, and it’s FREE to attend.

Places are limited, and tickets are going fast now, so make sure you book your place soon!

$ rails server
=> Booting WEBrick
=> Rails 3.0.3 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach

Exiting
/path/to/gems/activerecord-3.0.3/lib/active_record/connection_adapters/mysql_adapter.rb:30:
in `mysql_connection': undefined method `init' for Mysql:Class (NoMethodError)

(followed by a huge stacktrace). Googling didn’t help much, because every time anyone has asked about this on a forum, all of the answers are specific to Macs.

It turns out that the problem is that the mysql gem includes native code, which is built when you install the gem. And my existing mysql gem had been built against mysql libraries that are now, since my upgrade, out of date. So the fix turns out to be maddeningly simple. First, get rid of the gem that doesn’t work:

$ gem uninstall mysql

Next, get hold of the developer API libraries for mysql:

$ sudo apt-get install libmysqlclient16-dev

And finally, download and rebuild the gem again:

$ gem install mysql

Simples. I just hope this quick note saves you the hours of trawling through forums that I had to endure this morning.

Cory stops his analysis when he has the following model:

|Cell| <------- |Status|
           |Alive|    |Dead|

At this point Cory says

“Certainly if we implemented a Cell with a Status object with an AliveStatus class and a DeadStatus class someone, somewhere, should slap us upside the head.”

However, I’d like to carry on from that point just a little further…

I like to teach the use of CRC for exploring design, and so I naturally looked at Cory’s objects from the point of view of their behaviours and responsibilities. Thus it struck me that if we don’t make the split suggested by Cory, we’d have a Cell that knows about its position/neighbours and knows what change to make when the clock ticks. That would violate the Single Responsibility Principle. So the above split into Cell and Status makes sense from the point of view of responsibilities, if we give the Status object the job of deciding how the Cell should change.

With those responsibilities in mind, a little mental CRC session suggests that, when the clock ticks, the Cell would tell its Status object how many neighbours it had, and ask for a new Status object in return.

class Cell
  def change
    @status = @status.update_based_on(@number_of_neighbours)
  end
end

The Status objects become Strategy/Policy objects, and thus don’t seem to need any instance state. All of which means that the Status objects could be Flyweights, with only one extant instance of each type, referenced by every Cell that happens to be in the corresponding state.

I think this approach could well be worth a punt during the upcoming Global Day of Coderetreats…

1. Uses, in which I care only about your public API;
2. Creates, in which I also need to know your class;
3. Inherits/extends, in which I can also see some of your workings and I become part of you.

Don’t do that last one. Ever.

Many of the GoF patterns help move code up this list, from tight towards loose coupling. Except TemplateMethod, which not only encourages inheritance, it also creates a circular dependency by having the superclass only “work” in the presence of extensions. Bad.

Don’t inherit code. Bad.

Here’s (a drastically simplified version of) some code I wrote a while back. (It’s from a Rails app, but the message in this post applies to any technology and any kind of system input.)

class Users::RegistrationsController < Devise::RegistrationsController
  def create
    user = create_new_user_account
    if params[:invitation_token]
      sign_in_as(user)
      redirect_to Invitation.find(params[:invitation_token]).shared_content
    else
      redirect_to new_user_session_path
    end
  end
end

This route handles incoming user registrations, and it has a conditional branch to cater for the case in which the new user was invited, via email, by an existing user. If the new user arrived by clicking a link in an email we do one set of things; whereas we do a different set of things if the user got here via the ‘Register now’ button on the home page. Perfectly reasonable, I thought. Sure, it’s conditional code; but it’s sitting on the system boundary and therefore it’s fine, yes? No.

This conditional check represents duplication. Somewhere else in my application already knew, at some time in the recent past, which route should be taken through this method when it was finally invoked. When the app sent that email invitation, it was in a sense delegating to the recipient the task of supplying user account details. The conditional branch that handles the invitation is a callback from across a technology boundary, and the inviting code already knew to expect it.

The duplication also has a nasty side-effect: high complexity. This method is an order of magnitude harder to understand and to test(-drive) because of the conditional construct. (And you’re reading a version from which I’ve elided all manner of error handling.) Oh, and by forcing two routes into the same method I also made it violate the Single Responsibility Principle.

Happily the duplication is really easy to remove. The code that sends the email invitation knows which path it wants the registration code to take, so I just need to create a new input route for “invitation acceptance” and change the email invitation to link to it. As a result I’ll have two controller methods, each with simpler logic than their predecessor:

class Users::RegistrationsController < Devise::RegistrationsController
  def create
    user = create_new_user_account
    redirect_to new_user_session_path
  end
end

class InvitationAcceptancesController < Devise::RegistrationsController
  def create
    user = create_new_user_account
    sign_in_as(user)
    redirect_to Invitation.find(params[:invitation_token]).shared_content
    end
  end
end

So I have now removed the duplication, and the controller code is simpler as a result. These controller methods are also much easier to test(-drive) than the earlier code. And as a final bonus, I can design the user interface to this route with more knowledge, maybe adding some details of the invitation so that the incoming potential user feels a little more at home. In short, now that each code path has its own method (and class) I can pay it more attention, and it will flourish as a result.

Now, having refactored this code, I take away a few points for the future:

• Where appropriate and possible, model system outputs as delegations into a space that your code can’t reach or control; and model the resulting future input as a response.
• Where a system input is due to the system having earlier delegated a responsibility across its boundary, make sure the return route is differentiated from all others.
• Differentiated incoming routes have code that is easier to read and simpler to test.
• When an input route has a single use, the user experience can be tailored and enriched.
• Not every conditional at the system boundary tests external state.

But now I’ve turned spork off, and here’s why: Spork solves the wrong problem.

We enabled guard/spork because our specs were slow, and during the few months we had spork, those specs became even slower. But we never noticed. Most of the time guard/spork guessed correctly which specs to run, and we became quite good at configuring guard to re-load Rails when critical files changed. So we were reasonably comfortable, and our specs ran quickly most of the time. But our design was getting worse every day.

Slow specs are a sign of too much coupling, and in the case of a Rails app that usually means not enough separation between the domain objects and the adapters. So we’ve stopped running spork, so that we can feel the pain of the 15-second Rails load time, and so that we can feel the pain of all that coupling. And slowly we are making the app’s specs faster. Many spec files now run in under a hundredth of a second, and more will follow as we gradually peel domain code out from the Rails infrastructure. We don’t need to test the Rails components, and we have a very good suite of cucumber features that act as end-to-end integration tests. So our specs should be fast, and only need to tell us that our own objects each do their thing. That’s what we are now working towards, and that’s the pot of gold that spork was hiding from us.

$ rspec spec
#...
Finished in 61.82 seconds
475 examples, 0 failures

61 seconds!  (And on top of that I have to wait another 15 seconds for Rails load; that’s a whole other story, and I hope to come back to that in a future post.) A quick dig into the 61 seconds reveals this:

$ rspec spec/controllers
#...
Finished in 22.82 seconds
114 examples, 0 failures

It happens that almost every controller action in our app needs the user to be logged in, so every controller spec needs that too. We’re using Devise, so every spec has something equivalent to this:

before :each do
  sign_in Factory(:user)
end

This implies hits on the database to create the user object, record the IP address and last sign-in time, etc etc. We can do much better by using a mock_model for the User, and stubbing out Warden‘s authentication completely.

First, in the interests of DRYness, I made some helper methods to do some of the jobs that factory_girl does:

module RandomHelpers
  def random_number() SecureRandom.random_number(10000); end
  def random_id() random_number; end
  def random_name() SecureRandom.hex(20); end
end

Next, a method that creates a test double representing the User who will be logged in:

module ControllerHelpers
  def user_double(attrs = {})
    user_attrs = {
      :first_name => random_name,
      :last_name => random_name,
      :authenticatable_salt => 'x'
    }.merge(attrs)
    mock_model(User, user_attrs)
  end
end

This is the place to fill the User double with default attribute values. Our app requires every User to have a first and last name, so I’ve stubbed these with random strings; they can be overridden by the caller if specific values are needed for any test. In your own app, change this method to set any mandatory attributes your user model needs. Note also the stubbed authenticatable_salt() method, which wasn’t required when mocking earlier versions of Devise.

I also need a method that logs a user in:

module ControllerHelpers
  def stub_sign_in_with(user)
    request.env['warden'] = double(Warden,
                                   :authenticate => user,
                                   :authenticate! => user,
                                   :authenticate? => true)
    sign_in(user)
    return user
  end
end

This replaces Warden with a test double, and Devise is none the wiser.
I also create a method to glue these together for the simplest (and most common) case:

module ControllerHelpers
  def stub_sign_in(attrs = {})
    stub_sign_in_with user_double(attrs)
  end
end

(Note that this returns the User double; you’ll see why that’s useful in a moment.)

Finally, I configure the specs so they have access to these helper methods. To achieve that, spec/spec_helper.rb needs to look something like this:

Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

RSpec.configure do |config|
  config.include RandomHelpers
  config.include Devise::TestHelpers, :type => :controller
  config.include ControllerHelpers, :type => :controller
end

Putting all this together allows me to write controller specs with:

before do
  stub_sign_in
end

or, if I need access to the user double:

let(:user) { stub_sign_in }

And the payoff?

$ rspec spec/controllers
#...
Finished in 7.36 seconds
114 examples, 0 failures

I saved as whole 15 seconds! There’s still some work to do in my specs, but stubbing out Warden has made a massive difference to every test run that involves this project’s controller microtests.

Note that the above has been tested only with the following gem versions:

• rails 3.0.3
• devise 1.3.4
• warden 1.0.4
• rspec-core 2.6.4
• rspec-mocks 2.6.0
• rspec-rails 2.6.1
• factory_girl 1.3.3

A condensed gist for the above code is here.

It turns out I co-wrote the feature article in this month’s Better Software magazine!

I just posted this review of Wabi-Sabi: For Artists, Designers, Poets and Philosophers by Leonard Koren:

This is a wonderful little book about the Japanese art style called Wabi-sabi. The book is short, and many of the pages consist solely of full-page photographs illustrating the ideas. So it’s a quick read, but worth taking the time to read slowly, let it sink in, and then read again.

Wabi sabi itself originated as an eclectic style of the Japanese tea ceremony, emphasising the impermanence and ever-changing quality of all things. But the book keeps its feet on the ground and doesn’t spend too much time deep in Zen territory.

I read this book on Kent Beck’s recommendation during the early years of eXtreme Programming — see http://c2.com/cgi/wiki?WabiSabi for more on that. As an XP/agile coach I recommend it to any team that gets hung up on the search for perfection, to remind them that every state is transitional, and the idea of anything being “finished” is an illusion.

While browsing around other folks’ blogs today I came across a link to a post I wrote back in March 2005. Six years on I think it still stands up, and so I commend it to you, dear reader: The Middle Hexagon Should be Independent of the Adapters.

“I smile and start to count on my fingers: One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can be substantially improved; even the sky is not the limit. Five, every person can reach a full life. Six, there is always a win-win solution. Shall I continue to count?”

– Dr. Eliyahu M. Goldratt, 1947- 2011

Eli Goldratt wrote many books, and among them these four stand out as having changed my work (and life, I guess) for the better:

• The Goal — a novel, about a chap who has three months to save a failing factory. This is where it all began, and the ideas apply to so many different situations in so many different fields. I’d include this in my top 5 books of all time.
• It’s Not Luck — another novel, and the sequel to The Goal. Provides a basic introduction to the Thinking Tools by showing how to use them in analysing a variety of business problems.
• The Choice — a manifesto, quoted above. In this book Goldratt takes to the soap-box and presents his manifesto for happiness through logic and clear thinking. I disagree with his logic at one major turning point, but overall the message is good, strong and empowering.
• The Race — a workbook for learning about flow using the Theory of Constraints. This book is not for the faint-hearted, though thankfully it has no differential equations. Even though I had read and understood The Goal, and applied the ideas in many organisations, The Race taught me some deep new surprises.

I read each of those books again every couple of years, and each time my insights deepen. Goldratt was a true genius, and I’m surprised at how much his death has affected me this weekend.

Long live The Goal.

“ I do not view a project as the sum of its code. Rather, it is the view of that code through the tooling that it is designed to take advantage of. By targeting my code towards my tools, I can get a lot of value with a lot less code.“

– Arlo Belshee, setting up the conditions for his mock-free project

This is a nice extension of the idea that code should be “habitable”; that code exists not just to execute, but to be further worked by future developers. I’m very much looking forward to this series of articles from Arlo…

Here’s a quick experience report, about something I noticed myself doing this week…

I’m developing a ruby app that’s something like a library. I have some code that collects the names of the user’s 5 last visited items, which could be books, DVDs, MP3 downloads etc. Right now we only need the items’ names, so the collector calls the <code>name</code> method on each object in the collection, and duck-typing does the rest, right?

Well, only if each class of “visitable” thing defines a <code>name</code> method that has the right semantics for this collection. if this were a statically typed language such as Java we’d define a <code>Visitable</code> interface and have classes Book, DVD, MP3 implement it. But this is Ruby, so we don’t do that. And yet, when I add another “visitable” class, I need to get those semantics right or else I’ll break that collection (or worse, something far away that uses it).

This is where J.B.Rainsberger’s idea of contract tests helps out. If I define a set of tests for the contract between the collection and the “visitables”, I’ll get some advance warning of likely trouble when I add more visitable classes.

In this case, all we need is for the “visitable” object to have a non-nil name. I write that contract as a shared example group:

shared_examples_for 'a visitable item' do
  its(:name) { should_not be_nil }
end

And then check that every “visitable” class implements it correctly:

require 'spec_helper'

describe Book do
  it_should_behave_like 'a visitable item'

  # more specs ...
end

And as if to prove the point, when I added this test to the specs for every “visitable” class, one of them failed. I had a broken collection waiting just around the corner, but the contract tests made sure no-one saw it before it was fixed.

In general, contract tests will be richer than this example. But I think the approach holds good: use a shared example group to “specify” the contract between a client and a polymorphic group of supplier classes.

Update:

Ashley Moran suggests aliasing the standard rspec methods to make it clearer that these are contract tests. And after a wee bit of discussion we settled on this:

contract_for 'a visitable item' do
  its(:name) { should_not be_nil }
end

and this:

describe Book do
  it_satisfies_contract_for 'a visitable item'

  # more specs ...
end

Here’s a nice observation from @mattwynne about vim, which is currently our editor of choice when remotely pairing:

As we become sharper with vim’s text-navigation commands we find we’re using { and } to jump from “paragraph” to paragraph, and particularly to jump from method to method. So when a method has a blank line somewhere inside it, the } won’t jump over the entire method; it jumps to the line break instead.

That’s vim reminding us that this method violates the SRP.