Benchmarkable is a module that allows a class to mention which instance methods to benchmark, and then allows retrieving the benchmark report in csv format from the class's instances. The csv includes the method invocation timestamp, some context description (if provided), the method name along with arguments passed for the invocation, and the number of seconds the method took to execute.

For example:

This is the lighting talk I gave at Agile Mumbai 2010 inspired by my earlier thoughts on individual practices in team setting:

Over the years, as programmers we pick up many programming habits: stuff we're comfortable applying at an individual level because it works for us. But put in an Agile setting with pair rotation, collective ownership, etc, some of these habits break down or need more careful application.

I attended Agile Mumbai 2010 on 16 and 17 Jan. I gave a 3-minute lightning talk and also made it till the final round of "Programming with the Stars". I also enjoyed what the keynote speakers had to say and did a good amount of networking with fellow enthusiasts.

Overall I think the event has grown over the years. I was part of Agile Mumbai 2008 where I co-presented a workshop on refactoring, and being part of the event again this year, I've noticed improvements. Having international speakers definitely upped the quality of ideas and thoughts shared, and the attendees also seemed interested in stepping beyond the initial adoption curve.

This is a proud moment for Indian Ruby enthusiasts: India will be hosting its first RubyConf in 2010.

Check out more details at http://www.rubyconfindia.org

Speaker confirmations have begun and a good number of sessions are getting listed. Ahem, one of them happen to be mine: I'm happy to have my proposal "Ruby OOP: Objects over Classes" accepted.

(A special thanks to Sidu from ThoughtWorks Bangalore for getting this event going.)

As part of a session I presented at Ruby FunDay in ThoughtWorks Pune, I tried TDDing a simple rock-paper-scissors game. The frameworks I compared were rspec, expectations, and good ol' test/unit.

I'm hosting the code at bitbucket for reference sake: http://bitbucket.org/amanking/ruby-test-framework-comparison

Refactoring is a practice that ThoughtWorks developers apply in their work everyday. One of the most common (and arguably, most useful) refactoring is "Rename": basically renaming a variable, a method, a class or any such code artifact to express intent more clearly, according to its evolving responsibility.

In most cases, renaming is pretty trivial, especially with the use of modern IDEs. However, renaming an ActiveRecord model in a Ruby on Rails application can turn into an extremely non-trivial task, mostly because of "convention over configuration" (not that I'm saying anything against it). Here are the things you may need to rename along with your ActiveRecord model:

It may not be obvious, and in most cases, it may not matter but sometimes it is helpful to know that GROUP BY in MySQL does implicit ordering according to the grouped columns.

Let's take an example. Suppose we have a table like so:

mysql> SELECT * FROM users;
+----+--------+------+
| id | name   | age  |
+----+--------+------+
|  1 | donald |   27 | 
|  2 | mickey |   20 |

ThoughtWorks recently introduced "Adaptive ALM", a suite of 3 products that facilitate application lifecycle management. ALM sounds like a traditional management term but we do it differently in ThoughtWorks, making it very flexible and effective for everyone in the team (not just managers).

I've used Mingle in all of the ThoughtWorks projects I've been on, and can assure anyone that it has worked well for us. It makes life easy for a distributed team, or even for a collocated one actually (having an online story card is helpful when you lose your physical ones).

On 19 June 2009, ThoughtWorks successfully hosted Pune's first Ignite event.

Ignite is a platform where people from different walks of life can address a diverse crowd for just 5 minutes each, talking about something that they are passionate about and wished that society at large was listening.

Ignite Pune started as an idea pushed by Rajiv from ThoughtWorks' Bangalore office. He had helped coordinate such an event in Bangalore and thought that it was high time our Pune office did something similar too.

Some time back (around the 2nd week of May '09) I deployed my Jirb Online web application on Google App Engine for Java (GAE/J): http://jirbonline.appspot.com

It was not as straightforward as I'd hoped but was an interesting experience that gave me some insights into dealing with GAE/J and JRuby. This is how I went about it:

Created my GAE/J account

I registered for the GAE account and got an invite for trying out GAE/J. I registered using the mobile phone option: you get a code via sms that you need to complete the process. The Vodafone network in India failed to deliver Google's sms to me but IDEA worked. I got myself: http://jirbonline.appspot.com

There are certain programming practices that work when done at an individual level but need careful application (and probably ceremony) when working in a team.

For example, pulling out small domain classes for things like Money, Range, Link, etc is a good idea. I'm used to doing that in my day-to-day programming... problem is that my team mates have the same good habits. So after a while, you may run into more than one class representing the same thing. If a concept is tied to your project's domain, it is very likely to have an impact on various features (user stories), and hence, different team members may end up having to implement that same concept. If folks do not realize that a class for the concept is already implemented, they may accidentally add more copies of the class. In my current project, we had Link, ServiceLink, and Url almost doing the same thing until we noticed the duplication and made all consumers use just Link.

After writing about the Singleton class in Ruby, it is time to write about the Metaclass.

Note that some people use "metaclass" to mean a normal singleton class (aka eigenclass) but that is incorrect. The Ruby metaclass is a special type of singleton class, one for a Ruby class object (hence the term "metaclass", I guess).

Recapping what we know about the singleton class, in the following example we can guess where the definition of the method find_by_name goes:

A long while back for a Geek Night at ThoughtWorks Pune, I had come up with a JRuby sample web application that simulated jirb.

jirb is the interactive JRuby console that allows playing around with JRuby code in a quick interpreted environment. Plus, since it's JRuby it allows you to interact with Java code too.

Over time I simplified the web application, removing the unnecessary use of an MVC framework (Struts2), going for direct integration of JavaScript and Java code via the DWR AJAX library. The Java objects in turn talk to the JRuby runtime to execute the Ruby scriptlets being sent from the browser.

In the April 2009 edition of the Golden Gate Ruby Conference, Matt Aimonetti gave a talk on CouchDB. The summary provided at the website seems interesting and even useful. Apparently, to prevent any risk of his talk seeming dry, Matt contrasted using CouchDB to performing like a porn star (his slides can be found here).

On Saturday, 4 April 2009, we are hosting another Geek Night at ThoughtWorks Pune office. We're hoping it'll be a fun event for all technology enthusiasts!

More details here: http://www.thoughtworker.com/events/pune-geeknight