Auto-completion for IRB

As it turns out, it's really easy to add auto-completion to IRB. Just add the following lines to your ~/.irbrc file.

require 'irb/completion'
ARGV.concat [ "--readline", "--prompt-mode", "simple" ]

I wonder why this is not on by default.

JavaScript: The Good Parts

I recently watch a very interesting Google Tech Talk by Douglas Crockford, an influential JavaScript evangelist and writer. For all of you JavaScript devs out there, I strongly suggest you spare an hour to listen to this really amazing talk.



The talk, JavaScript the good parts is basically an excerpt of the speaker's book.

Although Crockford admits there are problems with JavaScript, even very annoying ones, JavaScript is still a very powerful programming language.

Some of the bad

One of the several shocking example of what 's wrong with JavaScript if the following snippet of code:

return
{
  ok: false
};

Now, consider the very similar code:

return {
  ok: false
};

One could expect that the two snippets would do the same thing. In most traditional language, the position of the curly brackets is simply a mater of personal preference. In JavaScript, it is not.

The fist snippets simply returns without doing anything. This is because JavaScript has the annoying habit of automatically adding semicolons under some circumstances. This is one of them. The second snippet returns a block of code. A simple new line changes completely the execution of the code. Thanks JavaScript...

Some the good

Despite all its faults, JavaScript is just another dynamic languages. So it comes with all the standard dynamic languages goodies like:

• Lambda
• Dynamic Object
• Loose Typing
• Object Literal
• Prototypal Inheritance

Those are the same constructs used by the dynamics languages we all love. Prototypal Inheritance is pretty unique to JavaScript, but Crockford argues that it is as powerful as classical inheritance.

The jist of the talk is that your should go with the grain when working with JavaScript. This mean actually learning the language and take full advantage of it while avoiding the bad parts. JavaScript is a very powerful language to write nice dynamic web applications. It has its faults sure, be there are way to navigate around those.

There's a lot more in the talk, I hope you enjoy it as much as I did!

Test Driven Development: The Benefits

This is the first part of a series of post regarding TDD (Test Driven Development), how it works, why YOU should use it, how to do it and how not to do it.

How I got started

As part of my final year of University, I've started working on a Ruby port an executable specification framework called GreenPepper.

My team and I decided to develop the entire thing while sticking religiously to the TDD methodology. Two months into the project we have over 98% code coverage.

TDD Simply Put

Very simply put, here are the 3 easy steps of TDD.

1. Write a test that fails
   
2. Write code to make it pass
3. Refactor

Those three steps are essential, they must all be done and in that precise order. In a future post, I'll give a more concrete example of how to apply these three steps. But for now, understand that if you're doing TDD, you cannot write code unless a test is failing.

The Benefits

The benefits of TDD are all tied to those three easy steps. The obvious benefits is that by following all those steps, the near entirety of your code is covered by your tests.

Also, by writing the tests first, you're forcing yourself to write code with easy and simple APIs. Lets face it, you're gonna be the one calling your code, might as well make it easy to use.

Another key benefits of writing test is that you are in fact writting an example of how to use your code. In a project where everything is properly tested, if you wish to learn how to use a class, you simply need to locate the tests for this class and you'll have a very complete example.

Now, the biggest advantage of unit testing is easy refactoring. When working of code that is not automatically tested, developpers are understandably frighten of huge refactorings. I myself worked in projects where features were abandon because it was too likely implementing it would break something. If everything is tested, you can change whatever you want without worrying about regressions.

A Real World Example

A testimony to easy refacoring with TDD is my last change to GreenPepper Ruby. We were using the standard Ruby XML library REXML for all our DOM parsing. This turned out to be a bad decision for several reason. REXML is sloooow, poorly documented and the API is simply awful. A much better choice was libxml. We didn't originally go with libxml because the OS X version was broken at the time. Recently the libxml team released the 1.0 version that fixed OS X. I decided it would be a good time to jump ship before the cost of changing library was even greater.

So I went in and change every class that used REXML. GreenPepper uses DOM extensively, so it was a huge change, several class had to be heavilly modified. It took me less than 5 hours to completly replace the parser.

I am 100% confident I did not break anything in the code. Why? Because EVERYTHING is tested and every test still passes!

There is no way in hell I would have dare change that parser if it wasn't for TDD.

The Bottom Line

TDD makes you more confident your software works at any given time. You can refactor without fear, thus creating much better code. If you plan on writing software that will be maintainable, you absolutely need unit testing and the best way to achieve that is thought TDD.

You should do TDD.

The benefits of stateless objects

For my first technical post, I'm gonna talk about a too common bad practice in programming: stateful objects. This is not a simple error only novice programmers do, it's a very common error even amongst professional programmers.

Consider the following example:

class Stateful
   def calculate(x)
       @result = x * 2
   end

   def display
       puts "The value is: " + @result.to_s
   end
end

s = Stateful.new
s.calculate(10)
s.display

In this case, the user of the class needs to call the calculate method before the display method. This implies a knowledge of the inner working of the class by its client. This is bad. If you make the API of your class impossible to misuse, then nobody is going to misuse it. This includes you!

This is a simple example and one might think that the usage of the class is pretty obvious. But in medium size software, there are often hundreds or thousands of these nasty stateful classes. Most of them have no need for a state. This increases the complexity of the code and makes collaboration between developers harder.

A better implementation would be:

class Stateless
   def calculate(x)
       x * 2
   end

   def display(x)
       puts "The value is: " + x.to_s
   end
end

s = Stateless.new
x = s.calculate 10
s.display x

There is now no possibility of misusing this class.

Of course, stateful object have their use too! But you should only add a state to your application when you have to.