Fun With Rakefiles

I recently ran into an ‘interesting’ issue in a set of  Rakefiles.

Here’s a part of the global Rakefile, which imports the *.rake files from a tasks folder:

$LOAD_PATH.unshift File.join(File.dirname(__FILE__), 'lib')

Dir.glob('tasks/*.rake').each { |r| import r }

Some of these Rakefiles require other Ruby files (which is stored in the lib folder). Since executing one task involves loading all that code, there’s a chance that an error in one supporting Ruby file may cause an error in an entirely unrelated task.

Let’s look at an example, the code is available over at GitHub: https://github.com/s2k/fun_with_rakefiles

For simplicity there are just two rake files within tasks and a ruby file in lib. What we like to run is this:

rake make_it_so

However what we get is an error message pointing to some rather unrelated part of the code:

$rake make_it_so
rake aborted!
Errno::ENOENT: No such file or directory @ rb_sysopen - partlist.txt
…dev/fun_with_rakefiles/lib/thing.rb:7:in `readlines'
…dev/fun_with_rakefiles/lib/thing.rb:7:in `<class:Thing>'
…dev/fun_with_rakefiles/lib/thing.rb:1:in `<top (required)>'
…dev/fun_with_rakefiles/tasks/unrelated_thing_tasks.rake:1:in `require'
…dev/fun_with_rakefiles/tasks/unrelated_thing_tasks.rake:1:in `<top (required)>'
…/.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `eval'
…/.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `'
(See full trace by running task with --trace)

Hmmm… When I first saw the error message I really wondered why suddenly there’s a file partlist.txt missing and then I asked myself where that Thing class was used in the code.

In this example it’s relatively easy to see what’s going on: The ‘central’ Rakefile gathers all the other .rake files that may be necessary (which, in turn, require all the files they need). However, if there are a few (sub) rake files around things can get a bit more confusing.

In my case, it was simple enough to repair the issue, since the missing file could be added to source control and everything worked again. But still there are a few things to think about:

1. Should the be code in a Ruby class definition that’s executed while defining the class? Especially: Should it be there, in case you can avoid it?
   In my opinion it’s a good idea to only have code like that if it’s really necessary. In the example given, one could load the file when an instance of the class is created. Doing so will reduce the consequences of the missing file drastically: Only the rake tasks actually using that class would fail, not every rake task.
2. Could one avoid the failure and still be able to run the desired task?
   It turns out that you can:

   $rake -f tasks/what_we_want_to_do.rake  make_it_so
   Processing something…

   In some cases you may also need to supply this command line parameter, in order to allow rake to find other Ruby files:

   -I, --libdir LIBDIR      Include LIBDIR in the search path for required modules.

3. Can we check that nothing’s broken?
   In fact, we can:

   rake -T

   If that actually lists the available rake tasks and doesn’t exit with an error code, it looks OK, at least it didn’t break everything. However, if a file is missing form the version control system, it’s a works-on-my-machine situation.

In a project with a large number of rake files and supporting library code, it may be worth while to have rake -T as part of a smoke test on the continuous integration system.

 

 

Advertisement

Ruby, Sequel and Trees

While working on some tree structure a couple of unit tests failed, when creating some form of summary of said tree structure. First of all here’s a condensed form of the code:

require 'sequel'

DB = Sequel.sqlite
DB.create_table :items do
  primary_key :id
  String :name
  String :foo, :default => 'NOT SET'
  Integer :item_id
end

class Item < Sequel::Model
  one_to_many :items
  def summary
    if items.empty?
      return [ { self.name => self.foo } ]
    else
      items.inject( [] ){ | r, sub_res | r << sub_res.summary }
    end
  end
end

r1 = Item.create :name => 'R1'
r2 = Item.create :name => 'R2'

r1.add_item r2
r2.foo = 'Ding'
#r2.save

[ r1, r2 ].each{ |i|
  puts "Item    : #{ i.id }"
  puts "Direct Foo: #{ i.foo.inspect }"
  puts "Summary   : #{ i.summary.inspect }"
  puts
}

Notice, that I’ve commented out saving r2. The output is:

Item    : 1
Direct Foo: "NOT SET"
Summary   : [[{"R2"=>"NOT SET"}]]

Item    : 2
Direct Foo: "Ding"
Summary   : [{"R2"=>"Ding"}]

What I didn’t expect – and why the unit tests failed – is the ‘NOT SET’ in the r1 summary.

One way to end up with what I originally expected is to save r2. Another way is to set r2.foo before adding r1 to r1:

r2.foo = 'Ding'
r1.add_item r2

How ever I’m still not sure whether this is intended behaviour and why it should behave like this. (If it is, I’d like to know why.)
What do you think?

Pasting Code Is OK

While reading about the DRY principle (for “Don’t repeat yourself”) and the evil of copy-and-paste coding (again), I started thinking what to do instead. Actually, what to do is more or less obvious: Put the code into a place where its accessible to be reused — a method, may be in a new or existing module or class.

So, whenever I feel the ‘need’ to copy code, I now think about cutting it, creating a new method and calling that. Apart form avoiding duplication, the code is now testable immediately by calling the method (instead of getting the surrounding code exercised). And the methods using the code gets shorter.

In the end, it boils down to pasting code being perfectly OK, it’s the copying that causes the trouble.

RejectConf in Berlin 2007

During the RejectConf 2007 in Berlin yesterday evening I talked about testing, contraints and the relationship between testers and developers. The talk is available as a PDF file at “Test, Test, Test”.

Thank you to all the other presenters and the Berlin Ruby User Group for providing the location etc.

Berlin – Day 3 / RailsConf Europe part 1 – Tutorials

The morning started with me finding out that breakfast at my hotel is served from 8 to 11 — while I had to leave before 8. Anyway there’s so many places in Berlin to get a great breakfast. So I had it on the way to the conference.

The 1^st tutorial I atended was Trotter Cashion’s “Refactoring”. that was a good introduction as well as a few great tips for tools to help refactoring:

• heckle: ‘Bebugs’ your code automatically and will tell you what you didn’t cover in you test cases in quite a few cases. It dynamically changes you code by turning ifs to unlesses, ‘==’ to ‘!=’ etc. You get the idea. It then checks whether you unit/tests are failing, i.e. wether they would allow you to find this particular fault. Which they likely won’t in so many cases.
• grep: Well, it’s grep.
• rcov: Another tool to tell you about test coverage. This one generates HMTL reports which show which code is and isn’t executed when running your test cases. Very useful a lot faster than heckle, at the price of being less rigousus.
• glark: A new way for grepping.

After than lunch time revealed that this time lunch is a lot better than at last year’s RailsConf in London. In fact is was excellent. Fresh fish, salads, lettuce, desserts. Options – more than one indeed – for vegetarians.
A minor issue is, just like in London last year, the wireless network: With about 300 attendees around, the network is really really slow.

Now, I’m attending the GIS tutorial (while typing this post). Anyway the accompanying script seems to be a good starting point.

And my RejectConf talk still isn’t done…