Ruby on Rails

I recently started reading a Ruby on Rails* book by the author of Rails himself. My friend and I decided this was the way to go for our web site. We've heard about the insane productivity using Rails; that's pretty much made the decision for us.

The book is relatively good as far as software technology books go. It's not incredible, but I would recommend you get it because the of who wrote it. What I really want to talk about briefly is the Rails framework.

Rails is one of those technologies that comes along and really advances our understanding of technology. It fundamentally alters the way web development is done and permanently increases productivity. It's true that many or all of these technologies are already out there. All of the latest hot Java technologies perform many of the same functions as Rails. But Rails integrates all of these ideas into one seamless framework. It was designed from the start with these ideas in mind. Java has been incrementally adding them into the (very large) frameworks and APIs already out there. But I would rather read one book on Rails than five on Java.

I believe the real progress in software isn't the army of web programmers solving nearly the same problems over and over again. It comes from the guy who sits down one day and really tries to understand the process. And then he takes that analysis and uses it to develop something revolutionary -- something that stops a million people from reinventing the wheel every day.

This is something that's extremely difficult to do. An inexperienced developer could never do it. You have to see many of the same types of problems many times before you can hope to generalize them. It requires a truly deep analysis of the common problems (and even just to understand what the problems are).

Then there is experimentation. Many successful software projects start as experiments. Unfortunately it's very difficult to know what's going to work, but over time the successful architectures begin to stand out. The trouble is, most companies don't want you to do experimentation. They want the problem solved as quickly as possible. It would be a lot faster to learn and use the latest Java technologies to build your web site than designing an experimental framework and using it to build your site. And of course, many experiments fail.

So it takes a very smart, motivated, experienced developer with free time on his hands to develop such a thing. But we all benefit. We benefit not only from the new technology but from the new understanding that comes with it. We see how we've been doing things the hard way all this time.

All right, what does Rails offer? One of its main selling points is the Model-View-Controller (MVC) design. The framework forces you to separate the view from the business objects and the control logic. It's not even optional; right from the start the code is in separate files, modules, and directories. This has been common practice on more traditional development like GUI applications. But it's new to web programming.

Rails uses convention over configuration. I didn't understand that either when I first heard it. Configuration is straight forward. We've all seen long XML configuration files. Convention says that we're going to take an educated guess about how the server will be set up. But Rails doesn't go and make lots of special files. Much of the options are put right in the code. If you don't like Rails' guess, just change the code. By placing the work in code, the technology is less limiting in case you need to do something it was intended to do. (And that's something that comes up on every project.) I do believe there are some negatives to this as well, but I can't think of any now.

Rails is a very proactive framework. It doesn't just set up the bare minimum you need to get started on a project. It generates stub code. But it goes even beyond that. It really actually starts writing some of the application for you. How many times have you found yourself saying, oh if I can just get these next few features done, that's 60% of the work? Rails starts at that point. If it makes a bad assumption, just change it. It's a lot easier to delete functionality than develop it. How many times have you copied example code off the Internet to get you started? With Rails, that's where you start, but without the overly specific (to the wrong application) code.

Unit testing is built in. In fact, it starts out with some very basic fixtures. It isolates modules for you. I would probably say it has a built in testing framework built around Ruby's unit test modules.

Rails is built on Ruby, a very effective language, quickly gaining popularity. It has support for very new technologies such as AJAX. It allows its users to develop their own custom generators, the utility that generates stub code. It handles database connectivity and even the SQL queries without input from you.

*In association with Amazon