Be sure where your methods are chained to…

I’ve just figured out a quite obscure bug in our app. It all started like this:

record.freeze.things # record is an ActiveRecord, and "things" is an association on that record.
TypeError: can't modify frozen object
	from (irb):2:in `instance_variable_set'
	from (irb):2

The code above shouldn’t crash, because ActiveRecord hast its own #freeze method, which will still allow access to the associations. But our record behaved as if Object#freeze had been called on it. What happend?

Continue reading “Be sure where your methods are chained to…”


Factory Girls secret savings

We like to use FactoryGirl for our test setup. Unlike Rails’ fixtures, it will give you an individual setup for each tests, and thus preventing that tests have side effects on other tests. However, saving objects on each tests comes with a performance penalty.

For your specs, however, you’ll only need to call in many cases, creating an new object without saving it to the database. Only that if you have a factory like the following, the associated objects will always be saved:

Factory.define :project do |f|
  f.association :carrier, :factory => :organisation

That is, even if you call, Factory Girl will internally call Factory.create(:organisation), saving the associated object. If you don’t want that behaviour in your tests, build your objects “manually” in the tests.

Debugger messes up rdoc

Sometimes it seems that ruby still has a way to go in terms of maturity. Today I got a strange error message when trying to build the rdoc files:

uninitialized constant RubyToken::AlreadyDefinedToken (NameError)

Any idea what it means? It turns out that I forgot to remove a require 'ruby-debug' somewhere in the code, which in turn includes some files from irb, which in turn is incompatible with rdoc. Duh…

Runtime Assertions in Ruby

I’ve published my first gem on rubyforge: assit. It does runtime assertions for Ruby.

When I got started with Ruby, I was flabbergasted that there weren’t any runtime assertions at all. I have no idea why – even though there are one gadzillion different unit testing whatnots, a decent debugger and even a profiler. But this basic debugging tool, that has been there since the dawning days of C, is flatly missing; although it’d be even more useful in a language that doesn’t do any static checking.

So I’ve written my own little thing, and put it on for everyone to use. Getting started is easy: Just do

sudo gem install assit

and you’ll be ready to use it.

In the code, it’ll work like this:

require 'assit'

# Just some examples, there are more assertions
assit(defined?(assit)) # Yes, this is self-referential ;-)

x = 2 + 3
assit_equal(5, x, "There seems to be a problem with the addition")

foo =
assit_kind_of(Foo, foo)

Continue reading “Runtime Assertions in Ruby”

Debugging fun

I had some fun with the Visual Studio debugger today, and actually learnt a few new tricks (even though I’m aware this may be an old hat to some 😉

The problem: I had an object which contained an invalid pointer, and crashed the application. Ups. I could see that the object started out fine, but somewhere along the way said pointer was modified to point to nowhere. I had no idea where the pointer was modified, however.

So what I really wanted to do was my program to break whenever that pointer was touched.

Continue reading “Debugging fun”

Fail gently

A recent blog entry by Psycho brought an article about “fail fast” to my attention. The article is sponsored by Martin Fowler (i.e. the King of Refactoring ™). The author is a consultant who “helps software teams work more efficiently”. (Did you ever notice that consultants always seem to have this kind of standard tag line?)

In any case, the article introduces the concept of “failing fast”. The idea is that a developer should get alerted to error conditions as soon as possible.

Continue reading “Fail gently”

Blog at

Up ↑

%d bloggers like this: