Recently I needed to execute a block of code in Ruby which could possibly throw a few types of errors. For a certain subset of errors, I wanted the block to be retried for a given number of times before giving up, while for other errors, I wanted the block to bomb immediately.

This is what I came up with:

class Gateway
    include Retryable
    ...
    def make_request(url)

My article named "Ruby: a gem of a language" has been published in the October 2008 issue of the IT magazine, "The Smart Techie".

It is an introductory article about Ruby, covering some aspects of its history, the philosophies behind it, and the important features that make it such a special language.

So go grab a copy now!

Continuous Integration is a great idea, one that ThoughtWorks is completely sold on to. We usually practise CI with the help of CruiseControl running on a dedicated CI server. ThoughtWorks Studios (ThoughtWorks' product division) has even launched a CI product targeted at enterprisey applications called Cruise.

We know that it's pretty simple to "reopen" a Ruby class at runtime and change the method definitions in it. Typically you'd want to be very careful when you use this Ruby feature.

One place where it's probably okay to do such a thing is in test code (although I'd much rather use a mocking framework like mocha to stub out methods). However even in test code you need to be careful... as this example will reveal:

Often times, when I'd like to check what all an object can do, I'd fire the following in irb:

obj = DateTime.new # or whatever
obj.methods.sort

obj.methods.grep /sec/

The reason I have to do the above is that I want to avoid listing all the methods that the object can respond to, including ==, <==>, etc.