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.
