Five different ways to test equality

It's bit confusing when it comes to test equality of objects in Ruby. It has five different ways to do it and each one has a different purpose and context in which it should be used.

equal? returns true if receiver and the parameter object have same object_id. Object ids are unique and its not shared among the objects. This method should not be overridden

== returns true if the receiver and parameter object has same values. This is most intuitive and should be overridden in your sub-classes

eq? Like == it compares objects but is more strict about type. Only reason this exists is to compare Hash keys

=== This is used for Switch Case statement. It compares target in case statement with each selectors. You can override it to control the way case statements are matched inside the switch block

=~ Pattern matching (Side note: In Erlang = does the pattern matching)

== and =~ does have a negated version and since ruby is a great language if you implement == you != for free, isn't that great.

Next time when you have to equate objects you know which one to use

Ruby open classes

This issue have been flamed in many blogs and Java programmers are not very comfortable with open classes that includes me. But its really powerful there is not doubt about it, like Neal ford said how many times did we created StringUtils class in our java project. But I guess re-opened classes should be organized in some way where everyone knows where to find it. When I say "1.hour.from_now" example in the rails book for the first time. I was really shocked, does it makes sense to have hour method in Fixnum and to add more confusion if you open irb and look at fixnum methods you will not see it at all.

One of the thing that Java programmers should get over is you cannot know a class in Ruby completely. In Java we could say that I know the String class, I know how many methods are there and what are those methods etc but in the world of open classes you never know. There is no replacement of communications, in ruby world its more important talk about your work with other teammates and unit testing of course.

netbeans ruby support

If you are used to eclipse or intellij, you know how hard is to live without auto-completion, debugging and refactoring. Textmate is cool and simple but netbeans ruby support is probably best right now. It actually uses string pattern matching to list out all the options and its pretty fast. To download ruby only version go to link

eval vs define_method

There are many ways you could dynamically define methods and eval should be your last option. I really don't care how many variations of eval ruby provides but don't use it. Writing code inside string cannot help anyone not even you.
Please remember "with more power comes more responsibility".
define_method is much cleaner way of defining methods in meta world and gives much more readability.

Starbucks does not use two-phase commit

As a consultant I do fly a lot. Its sucks to do that but at the same time I do get time to read through some of my pending list of books. Right now I am reading "Best of software writing 1" by Joel Spolsky . Anyways, the "Starbucks does not use two-phase commit" is an awesome article. In the synchronous world where most of us leave in, its fascinating how effective asynchronous solutions could be.

Based on my previous experience I could say that messaging solutions is not straightforward to implement especially if you haven't done it before. Its a exotic world of xml messages, its has its own patterns and challenges.

Software rewrite and big bang theory

Managing multiple version of any product is tough and intricate and if the product is poorly written, you have a mess in your hand. Refactor or rewrite is a debate we participate in all the time. Let’s not go into that again right now. Let’s pretend that we have decided to rewrite our product….hoooray. But rewriting the whole product in a one bang is not only ill-advised but a project doomed to be failure.

So what should we do then? Take small steps. If you have a big, unmanageable product in your hand, figure out the core/important services/components that need to be rewritten (maybe in different technology). Integrate those components with your existing product as soon as possible and release it. If you have many existing clients, releasing quite often could be an issue. Maybe hosting your new solution as a service (SaaS) with data centers might solve that problem. This could also be very lucrative to customers because they don’t have worry about any infrastructure/administration issues any more. This might cost you more money but you know what! you will always have a working software.

Sometimes you cannot avoid having multiple version of same product, especially when you are transitioning from old messing mud ball architecture to something more manageable. But rewriting in one big bang is an illusion which results in a 200 member team project with no end date (I am serious).

Duck Typing

I was reading a blog by Bill Venners about duck typing and kind of liked the following extract

...Don't check whether it IS-a duck: check whether it QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on exactly what subset of duck-like behaviour you need...

Its funny how we advocate the same thing in Java in spite of being statically typed , when we talk about programming to interface not to implementation. As long as it QUACKS, WALKS like a duck, we shouldn't care about its type.