Monday, October 03, 2005

Convention over configuration...but of course!

I have been reading and working out examples in the book Agile Web Development with Rails, written by Dave Thomas and David Heinemeier Hansson. I discovered rails about 6 months ago and started reading about it. I was fascinated by the simplicity and the ease of development that it offered in quickly putting together a fully functional web application. Needless to say, in just over a year after its creation, it has captured the hearts and minds of programmers and web designers alike.

There are many facets to rails that make it worthy of being the one of the foremost choices in developing web applications, like clear separation of model view controller functionality and in-built testing support - besides the inherent advantage of having a dynamic language like Ruby at its core. However, there is one more rarely-exploited paradigm that it uses that really struck a chord with me - the fact that it stresses "convention over configuration". Rails does not have XML files for specifying the configuration aspects of the application. It assumes certain values and uses those to power the rest of the application.

What does this exactly mean? It means that configuration information is already predetermined by rails and it urges the programmer to name objects a certain way and put files and resources in specific predetermined directories. One would think that this is very restrictive, but the fact is that it doesnt seem restrictive at all when most of it is done by the framework itself! It creates the directories, creates the templates for the files, so that what falls on the shoulders of the programmer is the actual business logic. It is like it says, "Dont worry about maintaining configuration info, I will lay it out and make sure its all in place. You just worry about implementing the requirements in code."
Imagine what this means in terms of application maintenance. A new programmer entrusted with making changes to a rails application coded by another developer already knows where everything is, and how the basic components are named. No flailing around trying to make sense of variable and object names!

It definitely is worthwhile trying out and working on a framework that works on the "convention over configuration" principle. This may not be for all, but is perfect for a framework if it has to be true to its promise of blazing speed in putting together a working application. And Rails does a great job there, no question.