Michael Kovacs' photos More of Michael Kovacs' photos
Recommend Me Cable Car Software logo

Tuesday, August 02, 2005

Ruby on rails nearly derailed on OSX

With all of the fanfare around this super duper ruby on rails framework I've been reading so much about I thought it would be cool to learn something completely out of the realm of the java world. Most time I have little patience for new software packages. If the software can't install and be configured fairly easily out of the box then I know that invariably there's going to be problems while using the software in the long run so I usually dump it and am not much for giving things a second chance. Ruby on rails nearly caused me to give up because of some issues surrounding OSX 10.4 but after early struggles, putting it aside for a week, installing a new version, things worked great.

I went to http://download.rubyonrails.com/ where I followed the instructions:

Here’s how you install Rails using Ruby Gems:

Get hold of RubyGems 0.8.10 (or higher)
gem install rails --include-dependencies
rails /complete/path/to/new/railsapp

I didn't actually perform that last step after installing. I waited until I read the tutorial over at

There he tells you how to get things installed, rails, mysql.
Now that everything's installed I'm ready to create my first application. To do that you invoke a script to generate an application template. I move to my home directory and invoke:
"rails cookbook".

This provides you with a directory containing your skeleton app including a script you can use to start a mini webserver.
Setting my current dir to where my "cookbook" app was generated I start the mini webserver like so:
"ruby script\server"

Then I hit the local URL/port that the server is running on:
success! I've just done the same thing I've done a million times with apache :-)

So when I created my cookbook/app dir an entire sub directory hierarchy was created. Some of
the more important ones are:
  • The controllers subdirectory. Where Rails looks to find controller classes. A controller handles a web request from the user.
  • The views subdirectory holds the display templates to fill in with data from our application, convert to HTML, and return to the user's browser.
  • The models subdirectory holds the classes that model and wrap the data stored in our application's database. In most frameworks, this part of the application can grow pretty messy, tedious, verbose, and error-prone. Rails makes it dead simple!
  • The helpers subdirectory holds any helper classes used to assist the model, view, and controller classes. This helps to keep the the model, view, and controller code small, focused, and uncluttered.

  • So now that I've got the lay of the land I'm ready to make some magic happen. The next step in the tutorial is to create a controller. I do that with the command:
    "ruby script\generate controller MyTest"

    That yields me the file my_test_controller.rb in the cookbook/app/controllers dir. I modify the contents to do something interesting, well kinda.

    class MyTestController < ApplicationController
    def index
    render_text "Hello, World"

    def foo
    render_text "Take it!"

    So now if I hit I get a page that says "Hello, World". The MyTest URL pattern maps to the controller class and by default calls the "index" method in my controller class.
    If I hit I get a page that says "Take it!"

    This seems quite productive. Within 5 minutes of install I have a webapp that I'm adding custom code to and iterating really quickly. Granted it's not doing much but hey how long does "Hello, World" take in other examples?

    Next step: Creating a database for the cookbook app.
    I fired up my evaluation version of navicat for managing MySQL instances and proceeded to create a cookbook database and recipes table. Adding a title, description, date, and instructions column to the table.

    After defining my table I'm ready to make this table available to my cookbook application. I generate a model class to represent the recipes table as follows:

    "ruby script\generate model Recipe"

    That produces:

    class Recipe < ActiveRecord::Base

    Not much to that huh? Turns out the O/R mapping framework in rails called ActiveRecord will dynamically populate your class with properties based on the database table implicitly associated with the class by name, Recipe->recipes.
    Next I need to generate the controller for accessing the recipe object instances as follows:

    "ruby script\generate controller Recipe"

    That produces an empty class but then I add a bit of scaffolding code that results in the following:

    class RecipeController < ApplicationController
    scaffold :recipe

    This scaffold code is what provides the default CRUD operations for database tables. This is another area where rails does the heavy lifting for you to get something going.

    Now that I'm done creating my model and controller I test my code by trying to create a new recipe with:

    There you see HTML widgets for each of the columns in the database table, rendered appropriately for the data type of each column.

    This is very powerful and yet as some of the folks in J2EE land have pointed out, very dangerous or fragile.

    There's more to go in my exploration of ruby on rails but this is just a quick rundown of my experiences with it right out of the box. One thing that I didn't like is the lack of a tag library mechanism. It seems that the ruby on rails folks encourage the use of scriplet code embedded in HTML pages, yuck. There's a java.net project underway to borrow/steal from ruby on rails call Trails. I haven't had a chance to look yet but plan on seeing what's offered there. I've read some positive comments around the javaworld about the project so I'm anticipating good things. I have to admit I'm a bit dubious about how large Ruby can become simply because of the amount of investment that needs to occur into things like VM performance, language enhancements, frameworks for various application types, and platforms. Looking at how far Java has come in 10 years you'd better have a pretty compelling reason to re-create alot of the same solutions around an entirely new language.

    This page is powered by Blogger. Isn't yours?