Rolling with Ruby on Rails Revisited

by Bill Walton and Curt Hibbs

Editor's Note: Be sure to check out Rolling with Ruby on Rails Revisited, Part Two, as well as Bill Walton's monthly series, Cookin' With Ruby on Rails. Please note that this tutorial is intended for use with Rails 1.2.6. It has not yet been updated to support Rails 2.x.

Maybe you've heard about Ruby on Rails, the super productive new way to develop web applications, and you'd like to give it a try, but you don't know anything about Ruby or Rails.

That's how the original version of Rolling with Ruby on Rails, published almost two years ago now, began. And it was true. Ruby on Rails (Rails for short) was super productive and it was super fun, too! A community of contributors grew up around it to make it even more productive and more fun! Rails has been growing fast. It has capabilities that you have to see to believe!!! That's what we're here for.

Like the original version, this tutorial will show you how to develop a web-based, database-driven application using Ruby on Rails. Also like the original, it will not teach you how to program in Ruby. On the other hand, if you already know another object-oriented programming language, you should have no problem following along (and at the end you can find links on learning Ruby and lots more).

Before you roll up your sleeves, I want to answer a couple of burning questions.

What is Ruby?

Ruby is a pure object-oriented programming language with a super-clean syntax that makes programming elegant and fun. Ruby successfully combines Smalltalk's conceptual elegance, Python's ease of use and learning, and Perl's pragmatism. Ruby originated in Japan in the early 1990s. It has become popular worldwide in the past few years as more English-language books and documentation have become available (and its popularity has really taken off since the introduction of Rails!).

What is Rails?

Rails is an open source Ruby framework for developing web-based, database-driven applications. What's special about that? There are dozens of frameworks out there, and most of them have been around much longer than Rails. Why should you care about yet another framework?

What would you think if I told you that you can develop a web application at least ten times faster with Rails than you can with a typical Java framework? You can--without making any sacrifices in the quality of your application! How is this possible?

Part of the answer lies in the Ruby programming language. Rails takes full advantage of Ruby. The rest of the answer is in two of Rails' guiding principles: less software and convention over configuration.

Less software means you write fewer lines of code to implement your application. Keeping your code small means faster development and fewer bugs, which makes your code easier to understand, maintain, and enhance. Very shortly, you will see how Rails cuts your code burden.

Convention over configuration means an end to verbose XML configuration files--there aren't any in Rails! Instead of configuration files, a Rails application uses a few simple programming conventions that allow it to figure out everything through reflection and discovery. Your application code and your running database already contain everything that Rails needs to know!

Seeing is Believing

Developers are used to hearing excessive hype accompanying something new. We know. We're developers, too, and we can easily imagine that skeptical look on your face. Super productive. Yeah, right!

We're not asking you to accept it on blind faith. We'll show you how to prove it to yourself.

When you've finished this tutorial, we think you'll be both motivated and ready to learn to "ride the Rails" to similar results yourself. This updated version of the tutorial will produce an application that looks like and has exactly the same features as the original, so we decided to approach it a bit differently. Rather than pretend that we're making this up for the first time, let's pretend that the boss walks into our office just before lunch and says...

Boss: Hey, CB (that's us). I'm in kind of a jam. I really need your help. I'm supposed to do a little dog-and-pony show for my boss tomorrow morning. I've been working up a little app for him on the side. It's kind of a big deal to him and I think he's going to invite some other folks to the demo tomorrow. Maybe his boss. Problem is, I've been using an outside consultant for this, and he must have won the lottery last night. He didn't come in this morning, hasn't responded to my emails, and he's not answering his cell phone. And on top of that, the app stopped working about an hour ago for some unknown reason and I can't even find the source code. CB, this is not the story I want to walk into my boss' office with tomorrow morning. Word around the water cooler is that you've been trying to get some new development tool approved. You say it lets you produce code like ten times faster than the tools we're using now?

CB: Yep. It's called Ruby on Rails, and it's at least 10x. But I haven't had any success with the Ops guys. Can't even get 'em to take a look at it. They're just not enthused about putting anything new into their mix right now.

Boss: CB, I really need to get the situation with this app fixed by tomorrow morning. If you can do that, you can use any tool you want. Just give me a web-based, database-driven app that looks like and acts like the one my boss has already seen. I know that's a lot. I'm probably asking you to work late. Tomorrow morning's really got to be pushing it. I tell you what. If you'll agree to give it a shot, I'll make a phone call, see if I can maybe break the ice for you with the Ops guys.

CB: (sensing an opportunity...) Tell you what, boss. It's almost lunch. If you go get us some pizza, and let me show you how productive Rails can make us, I think we can have you fixed up before lunch is over.

Boss: No way! By the time lunch is over? You are ON, CB.

CB: No sweat, boss. You go get the pizza. I'll get Rails installed. The Ops guys wouldn't let me download the Rails software through the firewall so I brought in a CD this morning. I'll be ready by the time you get back.

Boss: You're going to get a new development environment set up and ready by the time I get back? And then, while we eat, you're going to reproduce an app that I've had a consultant working on for... oh, never mind. I'm not going there. CB, don't get offended but, man, that's pretty tough to believe. I sure hope you're right, though.

So the story begins. The boss has gone to get pizza and we need to get Rails installed in a hurry.

Installing and Configuring Rails

In the original version of this tutorial, Curt showed how to install and configure Rails on a Microsoft Windows platform. In preparation for this update, we discussed how to handle the topic this time. We could do the same thing again, but there've been some complaints about favoring one environment (especially Windows!) over others. Alternately, we could show you how to install and configure Rails on all of them--Windows, Mac, and Linux--but that would take up a bunch of space. Alternately, we could take advantage of the fact that, since the original tutorial, new tools have emerged for each of these environments that make installation and configuration a snap. We could just point you to those resources. Because this last option both gets us off the favoritism hook and requires less effort... well, we're just doing "the simplest thing that could possibly work."

For Windows, use Instant Rails.

For Mac OS X, use Locomotive.

For Linux, try the Rails LiveCD.

Any one of these will have you ready to start developing your first Rails app in less time than it takes to get a pizza delivered.

Pizza's Here!

Boss: OK, CB. Here's the pizza. Now I know I agreed to let you show me how cool your new tool is, but I don't need to understand all the "how's that work?" stuff in detail, so I brought Paul with me, too. I don't mind it if you two dig into the details a little if you don't mind treating it as a sidebar. That OK with you?

CB: Sure, boss. Hi, Paul. Let me just grab a piece of that pie and we'll get started! You said you wanted this to look like the app you've been working on. But you said the app is down now. What do you have for me to work from?

Boss: I found this shot of the main screen (Figure 1) on the consultant's desk.

screen show of original app
Figure 1. Our goal!

Basically, the app's supposed to do three things:

  • Display a list of all recipes.
  • Create new recipes and edit existing recipes.
  • Assign a recipe to a category (like "dessert" or "soup").

Here's a note I found on his desk with the details of how the app works.

Required features

  • Title - Same on all pages.
  • Heading - Same on all pages.
  • Table
    • Recipe - Clicking on the link takes us to a page showing a non-editable view of the recipe. The page has links to edit and save the recipe and to return to the listing page.
    • (delete) - Clicking on the link deletes the recipe from the database and from the page.
    • Category - Clicking on the link causes the page to be refreshed with only recipes in that category included.
    • Date - The date should be assigned by the system when a recipe is created or edited.
  • Footer - Appears on all pages. NOTE: On the Category pages, the link on the left will be "Create new category." It should behave similarly to the "Create new recipe" link. The rest of the footer is the same on all pages.
    • Create new recipe - Clicking on the link takes us to a form to enter the recipe's name, description, and instructions, and to select a category to which to assign the recipe.
    • Show all recipes - Clicking on the link displays all recipes. This is used to restore the display after the list has been filtered by clicking on one of the Category links.
    • Show all categories - Clicking on the link takes us to a list view for categories with links on the page to edit and delete existing Category entries. (Footer has the "Create new category" link.)

That's all we have to go on.

Pages: 1, 2

Next Pagearrow