Ruby on Rails 2.0 – A First Look

Ruby on Rails 2.0 is quite a change from the previous version 1.2. You may not like the “breaking” changes that were made, but at least it has the major advantage of not dragging all that backwards compatibility baggage with it.
This is a major version release. The developers seem to take notice of the user community, especially when it comes to dropping the less useful features. Just as components drifted away into oblivion, dynamic scaffolding has followed the same path. Scaffolding is still around, it's just that it now consists of generated code. Most of the changes are noted in “Rails 2.0 It's Done!
Much of the fundamental framework still remains as it was, with both major and minor improvements in the robustness of the code. Ruby on Rails is now a very mature, solid framework, with a massive following and good support – especially from the excellently documented source code.

Fast Prototyping

More than anything else, Rails provides for very fast prototyping. It really can take just a few hours to get a basic application up and running. While developing the WebAlbum application for my programming course, it took just a couple of hours to get the basic user / album / picture / image associations sorted out, including cascaded deletes, starting from a clean sheet of paper.
I actually spent three times more effort getting the passwords encrypted, and the ImageMagick library to produce the thumbnails, than I did preparing the data model.
Even if you can't, or won't, use Rails in your production environment, it's still worth investigating as a prototyping tool. Once the basic model has been ironed out, and all the difficult problems addressed, then you can transpose that model onto your preferred development environment, knowing that the model works.
Being able to convert ideas into working code in such a short time frame also allows you to be a little less cautious in the choice of a solution. If it takes two hours to build a “proof of concept” application, instead of two days, then you're more likely to try out different approaches, rather than sticking to some “traditional” solution.

Documentation

I spent much of my time with Dave Thomas' “Agile Web Development with Rails” open on my lap, but the second edition is now in need of an update, so I spent more time with the API documentation, and the Wiki. The HowTos Wiki page has some good tips, and the code snippets can be a source of good ideas too.
As I said before, scaffolding has changed, so the books and most of the tutorials are behind the times. The scaffolding scripts more or less explain themselves, just type
rails -–help
before you generate your application (that's how I found out you can set the DBMS, and freeze Rails all in one step).
Once you've got your application, move to the application folder, then type
ruby script/generate -–help
to see what generators are available, each of which supplies further information, by typing, say
ruby script/generate scaffolding -–help
which gives information straight from the horse's mouth, as it were.
The API documentation is very complete (another sign of maturity for an open source project), but it's a shame there's no search facility. You can try guessing the function name – which worked for me about half the time – but some things just aren't that simple. There is a mirrored copy of the API documentation with search at http://www.railsbrain.com, otherwise it's back to Googling “ruby on rails apiwhatever”.
Filtering responses in the controller was one problem that took me a while to track down, because I was looking for filter_something, but the methods are actually before_filter, after_filter, or around_filter. Sigh.

Generators and Templates

The current state of the generators, or rather the code that is generated is pretty spartan, but it does the job - very much in style with Rails itself. I'm not totally convinced that this always helps, though. Although I like the very few lines of code, or HTML produced, there isn't always a hint as to what else you could add. On the one hand you have the routes.rb file, which has commented examples which you can change very easily:
ActionController::Routing::Routes.draw do |map|
  # The priority is based upon order of creation: first created -> highest priority.

  # Sample of regular route:
  #   map.connect 'products/:id', :controller => 'catalog', :action => 'view'
  # Keep in mind you can assign values other than :controller and :action

  # Sample of named route:
  #   map.purchase 'products/:id/purchase', :controller => 'catalog', :action => 'purchase'
  # This route can be invoked with purchase_url(:id => product.id)

  # Sample resource route (maps HTTP verbs to controller actions automatically):
  #   map.resources :products

  # Sample resource route with options:
  #   map.resources :products, :member => { :short => :get, :toggle => :post }, :collection => { :sold => :get }

  # Sample resource route with sub-resources:
  #   map.resources :products, :has_many => [ :comments, :sales ], :has_one => :seller

  # Sample resource route within a namespace:
  #   map.namespace :admin do |admin|
  #     # Directs /admin/products/* to Admin::ProductsController (app/controllers/admin/products_controller.rb)
  #     admin.resources :products
  #   end

  # You can have the root of your site routed with map.root -- just remember to delete public/index.html.
  # map.root :controller => "welcome"

  # See how all your routes lay out with "rake routes"

  # Install the default routes as the lowest priority.
  map.connect ':controller/:action/:id'
  map.connect ':controller/:action/:id.:format'
end
With that amount of commenting, you'll rarely need to look up the documentation. At the other extreme you get the basic model class:
class User < ActiveRecord::Base
end
Hardly giving away trade secrets there. Yet we'll almost certainly need to add association and validation code.
Fortunately, the generator templates are on hand, and it's not such a daunting task to modify them for yourself. I've written a companion tutorial discussing this technique.

Overall Impressions

What is there not to like? Ruby is a clean and powerful language. Rails is a clean implementation of a complex problem. There are concerns raised about performance and scalability, but frankly, if and when such problems arise, there are solutions available. Hardware is, and even with Rails helping you, will always remain cheaper than software development.
Even though the Rails philosophy is convention over configuration, it is also a very configurable framework. The WebAlbum exercise required just two lines of configuration code, and not even one line of SQL. Admittedly it is a simple application, but Rails will let you specify almost any URL you like, and let you make all the SQL queries you want, if that's what you need to do.
If you're new to both Ruby and Rails the learning curve is steep. Start with Ruby, use it to create build scripts, or write a command line program. I used the colophon I use to build my sites as an exercise.
Once you've got Ruby under your belt, Rails won't be such a surprise. I have found that the learning curve is gradual. The most important thing to keep in mind is that “it has probably already been done”. Take time to check out the documentation – there's probably already a method that does just what you're looking for. Better to spend an hour researching, and ten minutes implementing, than the other way round.

Contacts

Syger can be contacted for consultancy work on any of the topics mentioned in this article, by sending an email to info@syger.it.

Valid CSS

Valid XHTML 1.0

Valid Atom 1.0