About Me

My photo
I am a Software Architect and Developer based in Bangalore, India. I have experience in building (scalable) applications using Java, JSP, JSF, JBoss Drools, Spring Framework, Hibernate, Ajax, JavaScript, MySQL, NoSQL (HBase, Project Voldemort). I am also a fan of Ruby on Rails, and have done some experimental work with it.

Friday, July 31, 2009

At last, I have become productive in using RAILS.

I started working on a RAILS project to solve a problem at work. I was finding it difficult to manage tracking of defects. So, I started putting together a small tool that can help me share information on bugs within the team so that team members can pick up bugs to fix, and everyone is at same page when it comes to status.

My this little adventure with RAILS is shaping into something interesting. At present, I have made this application Open source on Google Code. My friend, Anish, and I are trying to make it a general purpose application. We are still a long way to go, but its a start!

To justify the blog title, I was able to put together a basic "Task board" in a matter of just 2 hours. At present, I am just punching the code without worrying much about automated test cases. Cucubmer, WebRat, RSpec are in my TODO list. My initial goal is to attain some mastery in doing basic RAILS right!.

I am following Elisabeth Hendrikson's suggestion on how to do TDD on a new technology. She suggests that one should build a throw-away app first to get a good hang of a new technology before one can do TDD right in that technology.

Here is her answer to my query on how to do TDD on a new technology:
Elisabeth responds:
Yes, I ran into this problem recently in my own work when using a new library. The recipe for TDDing something in a new technology where you’re still trying to figure out how the technology works is to spike, learn, shred, and then TDD it right. That means you start by hacking together something that works well enough so you can learn how the technology works. Then you shred that initial solution, ripping (or commenting) out all that hacked together code. And start over test-first. Does it take longer? Sure. But the result is more maintainable, testable software with fewer bugs, and also much deeper learning.