LinLog

This week I started dabbling in Ruby on Rails. After reading Scott Hanselman's and Mike Gunderloy's coverage of RailsConf, I almost felt like I had to. So far, I'm impressed.

For anyone who hasn't been paying attention, Ruby on Rails is the current "big thing" in developing web applications. Ruby is a dynamic, object-oriented programming language from Japan. So far, it seems to read like the bastard child of Python and Perl. But in a good way, if that's possible. Rails is an MVC web application framework for Ruby. Through the magic of Rails, you can literally create a working, if extremely basic, database application in less than 10 minutes. No joke.

I haven't had much time to play with RoR yet, but it seems really, really nice. It basically takes all the pain out of building data-driven web applications. Rather than spend your time messing around with database access - buidling the plumbing, designing insert/edit screens, and so forth - rails lets you automatically generate all that stuff. For example, in the tutorials, they just have you create a new Rails application, create a new MySQL database and table, and run a couple of commands. Then you can fire up a web browser and add records to the database. All without writing a single line of code!

The thing that's really nice about RoR is that it encourages good system design. The default Rails application has a proper model/view/controller architecture, includes testing infrastructure, and other good stuff. In other words, it gives you a good starting point. Contrast this with Visual Basic. Bask in the VB 6 days you used to see tutorials on data-bound controls that showed you how to build database applications without writing a single line of code. All you had to do was drag and drop a bunch of controls in the VB designer and voilà - instant application. The only problem was that VB 6 seemed to actively encourage writing really crappy code. For instance, it generated brain-dead default names for all those drag-and-drop controls - why name a control DataSource1 and force the user to change it when you can just prompt him] for th econtrol name? It also made no attempt separate the interface, data access layer, and business logic. In fact, doing that made the magical drag-and-drop features less helpful. And unit testing? Was that even possible in VB 6?

My only complaint about RoR so far is that there doesn't seem to be a lot in the way of documentation yet. Sure, there's the API reference, but not much in an instructional vein. And so far, I'm unimpressed with the two tutorials I've looked at. But I suppose I can let that slide. After all, RoR is quite new - building up a good documentation base takes time. Of course, by the time we get some good tutorials, I won't need them, so what do I case?