Okay. This isn’t really for dummies. Instead, it is my experience of getting up to speed with Ruby on Rails, and trying to translate the experience to a slightly broader audience.

Much of the web development that I’ve done over the past several years has been with Drupal. I like Drupal. It is a great platform for content management. It is nicely extensible. However, it is, after all, primarily a content management system.

Yesterday, I was speaking with a client who has an interesting project. He wanted to know what I thought the best platform for it would be. I, of course, suggested that it could probably be done fairly nicely in Drupal, but it would require a lot of custom development, and because of this, it would make sense to explore other possible platforms. We talked a little bit about Ruby on Rails as possible platform.

Years ago, long before I did any work in Drupal or PHP, I explored Ruby as a programming language. I didn’t bother going back and trying to refresh my Ruby programming. I figured I could probably remember enough to get by.

If you want a starting point with Ruby, check out An Introduction to Ruby. They suggest,

Indeed, if you decide to leap right into Rails development without first mastering Ruby, you may find that you end up with an application that you don’t even understand. Moreover, Rails can be a good deal trickier to install than Ruby alone

Well, after playing around for a while, I’m not sure I believe them. When I help people set up websites with Drupal, I usually only give them the simplest explanation of what Drupal is, and rarely get into any discussion about PHP. I know that Drupal and Ruby on Rails are different, but I think the same applies for a lot of people starting off with Ruby on Rails.

The first step is getting Ruby on Rails installed. I have a Linux box running Ubuntu available, it was pretty straight forward. I simply ran

$ sudo apt-get install ruby rubygems irb ri rdoc ruby1.8-dev build-essential
$ sudo gem install rails --include-dependencies

With that, I had a working Ruby on Rails installation to start messing around with. Now I realize that having a running Linux server and being able to dig up the magical incantation to install Ruby on Rails probably rules out the ‘for dummies’ phrase. But don’t worry. There is a way to get around this. I’ll come back to it later.

The default Ruby on Rails installation uses its own webserver called WEBrick. There are additional steps to use an Apache webserver. I have Apache up and running on my Linux server, and poked around with that for a little bit, but in the end decided simply stay with the WEBrick server.

I started looking around for a good tutorial and all of them always started talking about the “Model View Controller” framework. It is a great framework for system architects but for someone trying to set up a slightly nicer webpage it can be confusing. So, let me try a different way of explaining the “Model View Controller” framework for non system administrators.

The view is what your see. It is the webpage. Nice simple, straight forward. All of the webpages are controlled by a controller. You create a controller and its views using the script/generate command, e.g.

script/generate controller welcome index

That creates a controller named ‘welcome’ and a view named ‘index’. Since I was using WEBrick as my webserver, and it was listening on port 3000, the address of the website was http://localhost:3000/welcome/index The generalized format for pages are http://server/controller/view There are ways of tweaking this using ‘routes’ to rewrite web addresses, but that is one of the more obtuse areas and worth skipping for the time being.

Within the file structure for the Ruby on Rails application is an app/view directory. In that directory, there is a subdirectory for each controller, and within each controller subdirectory is a .rhtml file that is the view. So, the view file for the welcome/index page can be found at app/view/welcome/index.rhtml It is really a simple html page, and you can use all the HTML commands you want in it.

In addition, you can add your own Ruby on Rails commands put in between <%= and a %>

This is where the controller comes into play. The controllers are stored in a directory, app/controllers in the format controllername_controller.rb For example, the welcome controller described above would be found at app/controllers/welcome_controller.rb

The .rb extension tells you that this is a Ruby file. This is where your Ruby programming comes in. However, the framework is so rich that you can make all kinds of tweaks without really getting in depth into Ruby.

Ruby is a powerful object orient language will all kinds of wonderful ideas like classes and methods. If your not into object oriented programming, you’ll miss a lot of the power of Ruby on Rails, but you can still do a lot.

Each controller file starts with a class line, and then defines a method for each view. There is and ‘end’ line for each method and an ‘end’ line for the class.

e.g.

class WelcomeController < ApplicationController

def index
end
end

For practical purposes, the class line simply identifies the controller and the ‘def’ line defines each method and there is a method for each view. So, in the example above, the method ‘index’ would get all the Ruby programming that you want to pass on to the view.

In the starting tutorial for Ruby on Rails, they give the example of setting the variable @greeting to the string 'Hello world':
@greeting = 'Hello world'

Setting this variable would happen in the def index block
e.g.

class WelcomeController < ApplicationController

def index
@greeting = 'Hello world'
end
end

Then, the variable could be displayed in the view by putting it within the Ruby escape characters <%= and a %>

e.g. The app/view/welcome/index.rhtml file might have the line
<%= @greeting %>

So, that gives us what I hope is a clearer understanding of controllers and views. The model is the data model; the way the database is described. It starts getting a little more complicated, so instead of going into details here, I’ll simply suggest that you check out the Ruby on Rails tutorial that delves into that part.

Before I wrap this up, I want to mention one other thing that is particularly important, and that is the whole idea of layouts. They are something like themes in Drupal or skins in some other system. You can create whatever layouts you want in the app/views/layouts directory. As an example, one system had a standard.rhtml file in that directory, which is where all the meta tags, and other key data was stored.

Within the controller file, you can add a line
layout "layoutname"
e.g.
layout "standard"
to bring in the standard.rhtml layout.

If you add the line to the app/controllers/application.rb file instead of an individual controller file, you can make it apply to all your controllers. This is due to a wonderful idea called inheritance in object oriented programming that you might want to learn more about, someday.

Now, let me get back to the issue I raised at the top. If you don’t have the Linux server sitting in your family room, or enough experience to go out and install Ruby on Rails on it, what are you going to do?

Well, my hosting service is Site5. They provide pretty powerful webhosting for as little as $5 a month. They describe how to get Ruby on Rails running on their shared hosts here and another person describes how move a locally developed application over to Site5 here.

I went in and started playing with Ruby on Rails on Site5 setting up first test application here. It looks pretty promising.

I imagine other hosting services make it as easy as Site5 to get going with Ruby on Rails, but since I’m currently on Site5, and I get paid a referral fee for anyone that signs up, I figured, I’d plug their service. I know this has been a long and complicated post, but I hope it helps make Ruby on Rails a bit easier to understand. Later, I hope to write about how Ruby and Rails and Drupal might be able to interact, as well as about my efforts to use OpenID with Ruby on Rails.