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.

To do list

I find it really hard to keep my focus on one thing for very long. There are so many stuff to do. I guess its a trademark problem with any software developer. Anyways I have decided to give another shot to organize myself, create my own personal project plan. I found voo2do to be good place to start. This site allows you to create project, tasks with time line and organize them. One of the cool feature of voo2do is , you can add new tasks just by sending a email.

Now I need to out-source all my tasks :)