Nov 28

Round 1 with rails

So we finally made it past the planning phase in my aggregate demand project…and we decided to use Ruby on Rails. Ruby gave me quite a pleasant surprise. It is fully object oriented, has closures, has a python-like syntax (actually, its syntax is potentially perl-like, java-like, and practically *-like…it’s so strangely lax), and even continuations. On the other side, I’ve heard that it’s quite slow. In any case, some ruby tutorials and articles later I met rails. In case that you haven’t heard, Ruby on Rails is a web application framework made to rapidly create scalable CRUD apps. And it does it well. Sometimes a bit too well.

I was dying to use rails back in my software engineering course but sadly my teacher forced us to use java. Fast forward one year and here I am, building an enterprise-level app in rails. Installing rails was as easy as an “apt-cache search” and an “apt-get install” in my ubuntu system. I also downloaded the eclipse plugin from aptana but decided to build my first rails application using only my CLI and browser. I’m a total vim-head but most of the time when it comes to building web apps I usually go the eclipse way unless I’m using django. With rails I was pleased to see that it excels in the console environment (unlike java frameworks) and you don’t really need anything else but the framework to get started. Heck, you don’t even need apache installed to test your app, rails has its own development server. I decided that my friends and I could need a web comic publishing app, so that the world can see our glorious moments of lucid stupidity. Ok so I generated my project, created the database and tables, generated the controllers, messed a bit with the views, and arrived to the scaffolding part (this is basically what the rails wiki tutorial covers). Scaffolding is what really astounded me. Adding a simple line such as:

scaffold :modelname

in the controller and bam! The views and actions that were needed to CRUD data from the database were generated. Two links away were the even prettier views generated by the ActiveScaffold plugin. After that I decided to make some database changes. For this kind of thing rails has a wonderful migration system. I first assumed that I would need to modify my database and then my app’s configuration to do this, but I was wrong. You can specify incremental changes to your database via a pseudo-version-management system by doing this:

./script/generate migration name_of_migration

This generates a ruby file with the name of your migration in the db/migrate directory and adds a number at the beginning indicating it’s version (each migration counts as a version). In the ruby file generated, you specify the self.up and self.down methods as things to do to the database when upgrading or downgrading from that particular migration (things to do include creating tables, adding or removing columns, etc). Then you simply do:

rake db:migrate VERSION=N

Where N is the version you want to migrate to (omit this parameter if you want to migrate to the incrementally consecutive migration).
So for starteres rails has a good idea of workflow and an impressive way to deliver it. However, all this code generation requires you to follow some basic standards, some of which I’m not to comfortable with. For example, model names are the singular version of the database table they represent (that’s ok if it’s done in english but how about other languages?). Also, although migrations are cool, I really prefer django’s syncdb because it follows database changes AND makes them if you want to.
All in all it’s really a good framework and I would recommend anyone interested in web dev to give it a spin.
Next I’ll be seeing its authentication package.

No comments

No Comments

Leave a comment

You must be logged in to post a comment.