Beginner Resources

Just starting out with Ruby or Rails? Take your pick:

• 

  Ruby Programming Language

  Ruby is… A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.

  Read More

• 

  Getting Started with Rails

  Install Rails, create an application, using databases, the principles of MVC and RESTful design – this is an essential resource for getting started with Rails and learning the best practices.

  Read More

• 

  Creating a Weblog in 15 minutes with Rails 2

  In 15 minutes, we go from scratch to complete weblog engine with comments, ajax, an ATOM feed, an XML and JSON API, tests, an administrative interface, and much more! We strongly advise that you sit down before starting this whirlwind tour. Your head may well be spinning at the end. Come along for the Ruby on Rails ride.

  Read More

• 

  From CodeIgniter to Ruby on Rails: A Conversion

  In this tutorial, you will learn the basics of Ruby and Rails through direct comparisons with your existing CodeIgniter and PHP knowledge.

  Read More

• 

  Rails 2 From Scratch series

  PeepCode sell very high-quality, useful screencasts covering most aspects of Rails. This 76 minute screencast teaches you the basics of Rails. If you’ve done PHP, ASP, Perl, or any other type of web development and want to learn Rails, this is the screencast for you.
  Available in two parts, for $9 each. They are definitely worth the price.

  Read More

• 

  Ruby on Rails for Designers

  Take a brief look into the world of Rails with this fantastic tutorial available here at Nettuts.
  Ruby on Rails is an open-source web framework that’s optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.

  Read More

• 

  Learn Ruby on Rails from Scratch: Series

  Ruby on Rails… by now most people have heard the hype about it. It promises more effective code, total object orientation, and true MVC architecture to say the least. As far as my own personal experience, it has been all that and more. The code is beautiful, easy to maintain, and edit. In a recent project I was working on, it took me less than 10 hours to do the application, as compared to at least double that if I was writing in PHP.

  Week 1, Week 2, Week 3, Week 4

• 

  Using Ruby on Rails for Web Development on Mac OS X

  This article introduces you to Ruby on Rails by building a trivial web application step by step. Consider it a ride on the express train‚Äîan overview of what Rails can do, including a look at features new to Rails 1.0. In the end you’ll be better equipped to consider the advantages of powering your web application with Rails.

  It’s slightly dated, but the core techniques are still in use.

  Read More

• 

  REST For Rails 2

  Another screencast from PeepCode, available for $9. This screencast covers the basics of REST and walks through a simple application to show how REST routes work. You’ll learn about the magic that goes on behind the scenes and how you can design a REST application with confidence.

  Read More

• 

  Rails for PHP Developers

  If you’re proficient with PHP, you already have the essential skills needed to build web applications. This site will present an ongoing discussion of techniques for learning Rails and Ruby from a PHP perspective.

  Read More

• 

  TextMate for Rails 2

  Yet another PeepCode screencast, this is an essential if you’re developing Rails applications on a Mac. If you own a copy of TextMate but wish you were more familiar with the most frequently used keyboard shortcuts, this screencast will help orient you with what’s possible.
  As with all PeepCode resources, this is available for $9.

  Read More

Advanced Resources

Already have a good footing with Ruby and Rails? Try these:

• 

  Railscasts

  Every week Ryan Bates will host a new Railscasts episode featuring tips and tricks with Ruby on Rails. These screencasts are short and focus on one technique so you can quickly move on to applying it to your own project. The topics target the intermediate Rails developer, but beginners and experts will get something out of it as well.
  Prefer text tutorials? Check out the next item:

  Read More

• 

  ASCIIcasts

  Railscasts (above) is the #1 resource for quickly learning new Rails tricks. If you prefer text tutorials over video, ASCIIcasts is for you!
  ASCIIcasts are detailed, illustrated text versions of each Railscast, each with a link to the original video.

  Read More

• 

  Rails Forum – Tutorials

  A round-up of short tutorials covering a huge range of Rails techniques, from beginners advice and installation to debugging and tests.

  Read More

• 

  Building a Forum From Scratch with Ruby on Rails

  Today, we will be building a simple forum using Ruby on Rails, and we will be working up from the basics covering things like authentication and more advanced database techniques.

  Read More

• 

  Envy Casts

  Envycasts is the screencasting side of Rails Envy, a partnership between Gregg Pollack and Jason Seifer. However, not all the screencasts you’ll see here are Rails related.
  You’ll find several fantastic video tutorials covering a number of Ruby techniques and best-practices, most available for only $9.

  Read More

• 

  Scaling Rails

  Learn everything you need to know about Scaling your Rails app through 13 informative Screencasts produced by Gregg Pollack with the support of New Relic.

  Read More

• 

  RSpec Series for Rails 2

  This 55 minute screencast is the first of a 3-part series on RSpec. You’ll learn how to install and configure RSpec. We’ll walk through a simple project. Then we’ll install RSpec in a Rails application and start writing examples for a simple model.
  If Test::Unit doesn’t make sense to you, or if you want to write better code, this is the place to start.

  Read More

• 

  Getting Started with RESTful Authentication in Rails

  In this article, we will use restful_authentication to add a user system to a simple Rails application. This is great for those first starting out and need step-by-step directions for using this amazing plugin. At the end of the article, visitors will be able to create an account, reset their password, login, logout, and validate email addresses.

  Read More

• 

  Rails 2.1 PDF

  For over a year, Ryan Daigle has kept you informed on the latest updates to the Rails trunk. In this new 80-page PDF, Ryan discusses over a dozen new features in Rails 2.

  Code snippets and examples show you how to use many new features in Rails 2. A section on deprecated features suggests third-party alternatives.
  Available for $9 from PeepCode.

  Read More

• 

  Ruby on Rails Code Review PDF

  If you’re a beginning Rails developer, this is the book for you! Seventeen chapters show how applications are often written (the wrong way). Then, we show you how it should be done correctly.

  It’s more than just a checklist, it’s a tour of well-built applications that will help you build rock-solid web applications.
  Available for $9 from PeepCode.

  Read More

Ruby Books

Prefer to have a book to-hand when learning? Here’s a collection of some of the best Ruby books around:

• 

  Programming Ruby – the PickAxe

  Affectionately known simply as the ‘PickAxe’ in the Ruby community (due to the PickAxe on the cover), this is almost Ruby’s de-facto official book. A must-have for any serious Rubyist!
  The First Edition of the PickAxe is available for free at Ruby Central.

  Read More

• 

  Why’s (poignant) Guide to Ruby

  Written by Ruby’s very own crazy-genius, why the lucky stiff (or _why), this is a free and very unusual guide to the language. Take a read through the first few pages, and you’ll see why this book is a massive success.

  _why’s entire online presence recently disappeared, suddenly, and so the link below is to a mirror of the book, or you can download the PDF version. The book was originally available here.

  Read More


• 

  The Ruby Programming Language

  Bestselling author David Flanagan teams up with Ruby creator Yukihiro “Matz” Matsumoto and writer/cartoonist/programmer why the lucky stiff to bring you the authoritative guide to Ruby. Covering versions 1.9 and 1.8, this book helps you learn Ruby’s lexical structure, primary expressions, conditionals, syntax, classes, the data it manipulates, and more. For experienced programmers who want to look at this language in depth, this guide is invaluable.

  Read More

• 

  The Ruby Way

  The Ruby Way takes a “how-to” approach to Ruby programming with the bulk of the material consisting of more than 400 examples arranged by topic. Each example answers the question “How do I do this in Ruby?” Working along with the author, you are presented with the task description and a discussion of the technical constraints. This is followed by a step-by-step presentation of one good solution. Along the way, the author provides detailed commentary and explanations to aid your understanding.

  This book is not recommended for beginners to Ruby, however.

  Read More

• 

  Everyday Scripting with Ruby

  Everyday Scripting with Ruby is divided into four parts. In the first, you’ll learn the basics of the Ruby scripting language. In the second, you’ll see how to create scripts in a steady, controlled way using test-driven design. The third part is about finding, understanding, and using the work of others – and about preparing your scripts for others to use. The fourth part, more advanced, is about saving even more time by using application frameworks.

  Read More

Rails Books

• 

  Agile Web Development with Rails

  This is where most Rails developers started, and the book is now in its third edition to cover the ever-changing framework.
  “Rails 2, released in 2008, brings hundreds of improvements, including new support for RESTful applications, new generator options, and so on. And, as importantly, we’ve all learned a lot more about writing Rails applications in the last few years.”

  Read More

• 

  The Rails Way

  Like ‘The Ruby Way’, this is not a book for new-comers to Rails.
  “Using detailed code examples, Obie systematically covers Rails’ key capabilities and subsystems. He presents advanced programming techniques, introduces open source libraries that facilitate easy Rails adoption, and offers important insights into testing and production deployment. Dive deep into the Rails codebase together, discovering why Rails behaves as it does – and how to make it behave the way you want it to.”

  Read More

• 

  Rails for PHP Developers

  This is the perfect book for PHP developers wanting to explore Rails.
  “Rails for PHP Developers kick-starts your Rails experience by guiding you through learning both Ruby and Rails from a PHP developer’s perspective. Written by developers with deep experience using PHP, Ruby, and Rails, this book leverages your existing knowledge of PHP to learn Rails application development quickly and effectively.”

  Read More

• 

  Rails for .NET Developers

  Or perhaps you’re coming from a .NET background? This book has you covered!
  “You’re already a .NET developer; we’ll help you get up and running as a Ruby on Rails developer on any operating system: Windows, Mac, or Linux. We start with a gentle introduction to the object-oriented Ruby language with examples and direct comparisons to C#, so you’ll quickly feel at home writing Ruby code for the first time.”

  Read More

• 

  Rails for Java Developers

  Or maybe you’re a hard-core Java developer seeking asylum with Rails?
  “Written by experienced developers who love both Java and Ruby, this book will show you, via detailed comparisons and commentary, how to translate your hard-earned Java knowledge and skills into the world of Ruby and Rails.”

  Read More

• 

  Advanced Rails

  “This is the book for experienced Rails developers who want to go to the next level with this web development framework, with an in-depth look at techniques for dealing with databases, security, performance, web services and much more. Chapters in this book help you understand not only the tricks and techniques used within the Rails framework itself, but also how make use of ideas borrowed from other programming paradigms.”

  Read More

• 

  Advanced Rails Recipes

  “With the help of a community of Rails chefs in the kitchen, here are 84 new ways to kick your Rails apps up a notch. Advanced Rails Recipes is a collection of practical recipes for spicing up your web application without a lot of prep and cleanup. You’ll learn how the pros have solved the tough problems using the most up-to-date Rails 2 techniques so you can deliver your stunning web app quicker and easier.”

  Read More

• 

  The RSpec Book

  “RSpec, Ruby’s leading Behaviour Driven Development tool, helps you do TDD right by embracing the design and documentation aspects of TDD. It encourages readable, maintainable suites of code examples that not only test your code, they document it as well. The RSpec Book will teach you how to use RSpec, Cucumber, and other Ruby tools to develop truly agile software that gets you to market quickly and maintains its value as evolving market trends drive new requirements.”

  Read More

• 

  Simply Rails 2

  “Simply Rails 2 is an easy-to-follow, practical and fun guide to Ruby on Rails for beginners. It covers all you need to get up and running, from installing Ruby, Rails and SQLite to building and deploying a fully featured web application.”

  Read More

• Follow us on Twitter, or subscribe to the Nettuts+ RSS Feed for more daily web development tuts and articles.

Throughout this tutorial, we’ll create a simple shoutbox application in CodeIgniter, and then port it over to Ruby on Rails. We’ll be comparing the code between the two applications to see where they are similar, and where they differ. Learning Rails is much easier if you are already familiar with an MVC (Model, View, Controller) framework structure.

Do I Need Previous CodeIgniter Experience?

Yes, or experience in PHP and another MVC framework (CakePHP, Zend etc.). Check out some of the other CI tutorials here on Nettuts, including the from scratch video series!

Do I Need Previous Ruby/Rails Experience?

While it would help, no. I’ve done my best to make direct comparisons between Ruby and PHP, and between Rails and CodeIgniter, so by applying your existing knowledge it won’t be too hard.

Hello, CodeIgniter

Begin by downloading the CodeIgniter framework to your local/web server, and set up your database (I named it ci_shoutbox) with the following SQL commands:

CREATE TABLE `shouts` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `email` varchar(255) NOT NULL,
  `message` text NOT NULL,
  PRIMARY KEY (`id`)
);

INSERT INTO `shouts` (`id`,`name`,`email`,`message`)
VALUES
  (1,'Dan Harper','email@example.com','Hello, World!'),
  (2,'Bob','a@a.com','This looks great!'),
  (3,'Dan Harper','email@example.com','Hey, thanks for the comment!');

As usual in CodeIgniter, enter your details into /system/application/config/database.php:

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "root";
$db['default']['password'] = "";
$db['default']['database'] = "ci_shoutbox";

Then config.php:

$config['base_url']	= "http://localhost/shoutbox/";
...
$config['global_xss_filtering'] = TRUE;
...
$config['rewrite_short_tags'] = TRUE;

And autoload.php:

$autoload['libraries'] = array('database', 'form_validation', 'session');
$autoload['helper'] = array('url', 'form');
...
$autoload['model'] = array('shout');

Finally set the default controller inside routes.php:

$route['default_controller'] = "shouts";

Controller & Model

Since this is such a simple application, we only need one controller and one model. Inside /controllers/ create shouts.php:

<?php
class Shouts extends Controller {

  function Shouts() {
    parent::Controller();
  }

}

And the model as /models/shout.php:

<?php
class Shout extends Model {

  function Shout() {
    parent::Model();
  }

}

Retrieving the Shouts

Our front page, the index, outputs the 10 latest shouts from the database. Start by adding the following to the Shouts controller:

function index() {
  $data['shouts'] = $this->shout->all_shouts();
  $this->load->view('shouts/index.php', $data);
}

On line 2, we call the all_shouts() function from the Shout model.
Following this, we load the relevant view file, and pass the $data variable along to it (CodeIgniter will automatically take apart the $data array, so that we can access the shouts simply as $shouts instead of $data['shouts']).

Calling the Database

Let’s create the all_shouts() function in our model now:

function all_shouts() {
  $data = array();
  $this->db->order_by('id', 'DESC');
  $q = $this->db->get('shouts', 10);

  if ($q->num_rows() > 0) {
    foreach ($q->result() as $row) {
      $data[] = $row;
    }
  }

  return $data;
  $q->free_result();
}

This is relatively straight-forward. We retrieve the 10 most recent records from the ’shouts’ table, and output them in descending order. This will build the following SQL command behind-the-scenes:

SELECT * FROM `shouts` ORDER BY `id` DESC LIMIT 10;

If any records were found, they are added to the $data array and returned to the controller.

The View

Inside the /views/ directory, create the following files and folders:

• footer.php
• header.php
• /shouts/
  • index.php

Add the following to /shouts/index.php:

<?php
$this->load->view('/header.php');

if ($shouts) {
  echo '<ul>';
  foreach ($shouts as $shout) {
    $gravatar = 'http://www.gravatar.com/avatar.php?gravatar_id=' . md5(strtolower($shout->email)) . '&size=70';
    ?>

    <li>
      <div class="meta">
        <img src="<?= $gravatar ?>" alt="Gravatar" />
        <p><?= $shout->name ?></p>
      </div>
      <div class="shout">
        <p><?= $shout->message ?></p>
      </div>
    </li>

    <?php
  }
}
else {
  echo '<p class="error">No shouts found!</p>';
}

$this->load->view('/footer.php');

On line 2 we include header.php.
If any shouts were returned from the database, we loop through them using foreach and create a basic list with the author’s Gravatar, their name and the message. If no shouts were found, we display an error message.
Finally, we include the footer.php.

Note that on line 7, we build the Gravatar URL. The URL contains an MD5 hash of the user’s email address. We use PHP’s strtolower() function to ensure the email is all lower-case in case the Gravatar service is case-sensitive.

Continuing on, we need a form at the bottom of the page to add a new shout. Before we include the footer view file, add the following:

echo form_open('shouts/create'); ?>
  <h2>Shout!</h2>

  <div class="fname">
    <label for="name"><p>Name:</p></label>
    <input type="text" name="name" value="<?= set_value('name') ?>" />
    </div>

  <div class="femail">
    <label for="email"><p>Email:</p></label>
    <input type="text" name="email" value="<?= set_value('email') ?>" />
  </div>

  <textarea name="message" rows="5" cols="40"><?= set_value('message') ?></textarea>

  <p><input type="submit" value="Submit" /></p>
  <?php
echo form_close();
$this->load->view('/footer.php');

On line 1 we use the form_open() function from CodeIgniter’s Form helper. This generates a <form> opening tag with the relevant parameters, and will point to shouts/create (the Create function inside the Shouts controller).
The rest is a normal HTML form, except we echo the set_value() function for each ‘value’. We will be adding validation to the form shortly and this ensures that if there are any errors, the submitted data is automatically re-entered into the form.

Finally, we’ll need to create the header & footer. Add the following to /views/header.php:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Shoutbox in CodeIgniter</title>
<link rel="stylesheet" href="<?php echo base_url(); ?>css/style.css" type="text/css" />
</head>
<body>
<div id="container">

  <h1>Shoutbox</h1>
  <h5>
    <a href="http://www.danharper.me" title="Dan Harper">Dan Harper </a> :
    <a href="http://net.tutsplus.com" title="Nettuts - Spoonfed Coding Skills">Nettuts</a>
  </h5>

  <div id="boxtop"></div>
  <div id="content">

See on line 8, when including the stylesheet, we use the base_url() function from CodeIgniter’s URL helper to generate the URL to the root of the site – this will put the stylesheet at http://example.com/css/style.css.

Add the following to /views/footer.php:

  </div><!--/content-->
<div id="boxbot"></div>
</div><!--/container-->
</body>
</html>

Submission & Validation

Since the form directs to a Create function in the Shouts controller, let’s create that now:

function create() {
  $data['shouts'] = $this->shout->all_shouts();

  $this->form_validation->set_rules('name', 'Name', 'required|max_length[255]|htmlspecialchars');
  $this->form_validation->set_rules('email', 'Email', 'valid_email|required|max_length[255]|htmlspecialchars');
  $this->form_validation->set_rules('message', 'Shout', 'required|htmlspecialchars');

  if ($this->form_validation->run() == FALSE) {
    $this->load->view('shouts/index.php', $data);
  }
  else {
    $this->shout->create();
    $this->session->set_flashdata('success', 'Thanks for shouting!');
    redirect('shouts/index');
  }
}

On line 2 we retrieve the shouts (as we did on the index function), as they still need to be shown.
Lines 4-6 are our validation rules. We first pass the input’s ‘name’ from the submitted form to check, followed by a ‘human-readable’ version. The third parameter holds a pipe-separated (’|') list of validation rules.

For example, we set all the fields as ‘required’ as well as run them through ‘htmlspecialchars’ before submission. ‘Name’ and ‘Email’ have a max length set, and the submitted email field must resemble an email address.

If the validation fails, the index view is loaded again; otherwise we run the create() function from the Shout model. On line 13, we set a success message in the flash data which will be displayed on the next executed page.

Before continuing, we must display the error and success messages (see images above) in our view. Add the following directly after we include the header in /views/shouts/index.php:

if ($this->session->flashdata('success')) {
  echo '<p class="success">' . $this->session->flashdata('success') . '</p>';
}

echo validation_errors('<p class="error">', '</p>');

Insert Into Database

Inside the Shout model, enter the following:

function create() {
  $data = array(
    'name'    =>  $this->form_validation->set_value('name'),
    'email'   =>  $this->form_validation->set_value('email'),
    'message' =>  $this->form_validation->set_value('message')
  );
  $this->db->insert('shouts', $data);
}

Very simple, we compile an array containing the submitted data, and insert it into the `shouts` table.

Styling

In the very root directory for your application – in the same directory as CodeIgniter’s /system/ folder, create two new folders: /css/ and /images/.
In the CSS folder, add the following to a file named style.css:

* {
margin: 0;
padding: 0;
}

body {
background: #323f66 top center url("../images/back.png") no-repeat;
color: #ffffff;
font-family: Helvetica, Arial, Verdana, sans-serif;
}

h1 {
font-size: 3.5em;
letter-spacing: -1px;
background: url("../images/shoutbox.png") no-repeat;
width: 303px;
height: 66px;
margin: 0 auto;
text-indent: -9999em;
color: #33ccff;
}

h2 {
font-size: 2em;
letter-spacing: -1px;
background: url("../images/shout.png") no-repeat;
width: 119px;
height: 44px;
text-indent: -9999em;
color: #33ccff;
clear: both;
margin: 15px 0;
}

h5 a:link, h5 a:visited {
color: #ffffff;
text-decoration: none;
}

h5 a:hover, h5 a:active, h5 a:focus {
border-bottom: 1px solid #fff;
}

p {
font-size: 0.9em;
line-height: 1.3em;
font-family: Lucida Sans Unicode, Helvetica, Arial, Verdana, sans-serif;
}

p.error, .errorExplanation li {
background-color: #603131;
border: 1px solid #5c2d2d;
padding: 10px !important;
margin-bottom: 15px;
}

p.success {
background-color: #313d60;
border: 1px solid #2d395c;
padding: 10px;
margin-bottom: 15px;
}

#container {
width: 664px;
margin: 20px auto;
text-align: center;
}

#boxtop {
margin: 30px auto 0px;
background: url("../images/top.png") no-repeat;
width: 663px;
height: 23px;
}

#boxbot {
margin: 0px auto 30px;
background: url("../images/bot.png") no-repeat;
width: 664px;
height: 25px;
}

#content {
margin: 0 auto;
width: 600px;
text-align: left;
background: url("../images/bg.png") repeat-y;
padding: 15px 35px;
overflow: hidden;
}

#content ul {
margin-left: 0;
margin-bottom: 15px;
}

#content ul li {
list-style: none;
clear: both;
padding-top: 30px;
}

#content ul li:first-child {
padding-top:0;
}

.meta {
width: 85px;
text-align: left;
float: left;
min-height: 110px;
font-weight: bold;
}

.meta img {
padding: 5px;
background-color: #313d60;
}

.meta p {
font-size: 0.8em;
}

.shout {
width: 500px;
float: left;
margin-left: 15px;
min-height: 110px;
padding-top: 5px;
}

form {
clear: both;
margin-top: 135px !important;
}

.fname, .femail {
width: 222px;
float: left;
}

form p {
font-weight: bold;
margin-bottom: 3px;
}

form textarea {
width: 365px;
overflow: hidden;
}

form input, form textarea {
background-color: #313d60;
border: 1px solid #2d395c;
color: #ffffff;
padding: 5px;
font-family: Lucida Sans Unicode, Helvetica, Arial, Verdana, sans-serif;
margin-bottom: 10px;
}

And save the following images into the /images/ folder: (the images will be the correct size when saved!)

back.png

bg.png

bot.png

shout.png

shoutbox.png

top.png

To confirm, your directory structure should look like the image below:

And… done! If you think we wrote very little actual back-end code in CI, wait until we get to Rails where all database interaction is automated!

Hello, Rails

For this tutorial, I assume you already have Ruby, Rails and MySQL (or your preferred database engine) installed correctly on your system. If not, see the Rails installation guide and MySQL download page. If you happen to be running Mac OSX Leopard, Ruby and Rails both come pre-installed.

It’s also useful to know how to navigate in your operating system using the command line. For example to change directory, use cd foldername, or cd C:\Users\Dan etc.

Rails provides a number of command-line tools to speed up development of your application. Inside the Terminal (or Command Prompt in Windows), navigate to the folder you wish to store your Rails projects in. Personally I store them in a /rails/ directory in my User area.

The Set Up

Run the following to dump a copy of Rails for your application:

rails -d mysql shoutbox

Here, Rails will install into a /shoutbox/ directory. As MySQL is my preferred database engine, I specify -d mysql. If you prefer to use MySQLlite (the default in Rails), you would simply run rails shoutbox.
Navigate into the shoutbox directory:

cd shoutbox

Now, we’ll generate the Controller and Model:

ruby script/generate controller Shouts

ruby script/generate model Shout

Rails has now generated our ‘Shouts’ controller and ‘Shout’ model. It’s important to know that Rails encourages a strict naming style.
Your controller should be named the plural of whatever it will deal with (eg. Shouts, Users, Listings). A controller typically will only deal with one model, which is named in the singular (eg. Shout, User, Listing). Following this standard will ensure Rails can use all it’s functionality.

Inside your shoutbox directory, open the /config/database.yml file, this stores our database details. Enter your details under the ‘development’ section:

development:
  adapter: mysql
  encoding: utf8
  reconnect: false
  database: shoutbox_development
  pool: 5
  username: root
  password:
  socket: /tmp/mysql.sock

You can see Rails has automatically set the configuration file to be using the MySQL adapter. You will likely only need to alter the username and password.
Don’t worry, you should not have created the shoutbox_development database yet. We’ll create that next.

Next, open the /db/migrate/***_create_shouts.rb file (most versions of Rails will prefix the file name with the date and time):

class CreateShouts < ActiveRecord::Migration
  def self.up
    create_table :shouts do |t|

      t.timestamps
    end
  end

  def self.down
    drop_table :shouts
  end
end

This is a database migration file. Rails use these to help developers keep their databases structured correctly since they can become messy when several developers are altering database tables at the same time.
You will also be able to roll your database back to a previous version if you need to.

In here, we will add our database fields:

class CreateShouts < ActiveRecord::Migration
  def self.up
    create_table :shouts do |t|
      t.string :name
      t.string :email
      t.text :message
      t.timestamps
    end
  end

  def self.down
    drop_table :shouts
  end
end

This may look scary, but it’s very simple! t.string :name creates a ‘name’ field in the database, which will be stored as a string (ie. ‘varchar’). The same goes for the ‘email’ field.
A ‘message’ field is added and stored as text (as it is in SQL).

You will notice Rails automatically included t.timestamps. This includes ‘created_at’ and ‘updated_at’ fields which Rails will automatically fill in when a field is created or updated.
Also, Rails will automatically create an ‘id’ field, so we don’t need to define that ourselves.

This is equivalent to the following SQL command:

CREATE TABLE `shouts` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `email` varchar(255) DEFAULT NULL,
  `message` text,
  `ipaddress` varchar(15) DEFAULT NULL,
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
);

While it can take a little getting-used-to when creating these migrations, they’re much easier to type than SQL!

Finally, run the following two commands in the Terminal to create and set up the database:

rake db:create

rake db:migrate

The first command creates the database, named ’shoutbox_development’. The second runs any out-standing database migrations (in this case, our ***_create_shouts.rb file).

Start the server with and then visit http://localhost:3000 (or whatever port the server says it is running on – in most cases it’s 3000):

ruby script/server

To remove the default welcome page, first remove the file at /public/index.html, then inside /config/routes.rb, insert the following anywhere between the first and last lines:

map.root :controller => "shouts"

You will need to restart the server whenever you make alterations to the controller or to the routes – press Ctrl+C, then re-run ruby script/server.

That concludes the configuration process for Rails. While this whole process may seem complicated right now, you can do it in just a few minutes, and once you get used to it, it’s much quicker than setting up a CodeIgniter project.

Dummy Data

Before display the shouts, we’ll need some data in the database to display. You could create these entries through your preferred database management program, however we’re going to use a great Rails feature instead – the interactive console.

From your application folder in the Terminal, run ruby script/console. This is an interactive Ruby interpreter, which is also hooked up to our Rails application, so we can interact with it!

One very important thing to remember with regard to Rails, is that your model is automatically linked with the corresponding database table. For example, your ‘Shout’ model is linked with the ’shouts’ table in your database – this is a key reason why following Rails’ naming conventions can be very useful!

Run the following ruby code inside the interactive console:

shout = Shout.new(
  :name => 'Dan Harper',
  :email => 'email@example.com',
  :message => 'Hello, World!')

Here, we invoke Rails’ new method on the ‘Shout’ model – this will create a new record in the shouts database table. We also pass a hash containing the data we want to enter.
This is stored in the ’shout’ variable.

Note: A ‘hash’ is what PHP calls an associate array – an array where you can also set your own key.
A rough PHP equivalent of this code would be:

$shout = $this->shout->new(
  'name' => 'Dan Harper',
  'email' => 'email@example.com',
  'message' => 'Hello, World!');

Finally, save this into the database with:

shout.save

If you entered the code correctly, ruby should return ‘true’.
You can now retrieve this from the database with:

shout = Shout.find :last

shout.name

The first command will find the most recent row in the shouts table and store it in the ’shout’ variable. We can find look at a specific item with shout.name which should return whatever you entered as the ‘name’ for the record.

Repeat the Shout.new and Shout.save process a few more times to add more records to the database.

Displaying Shouts

Inside the /app/controllers/shouts_controller.rb file, enter the following between the existing class statement:

def index
  @shouts = Shout.all_shouts
end

We call the all_shouts method from the ‘Shout’ model, and store the result inside the shouts instance variable (as seen by the @).

In CodeIgniter, the equivalent code was:

class Shouts extends Controller {

  function Shouts() {
    parent::Controller();
  }

  function index() {
    $data['shouts'] = $this->shout->all_shouts();
    $this->load->view('shouts/index.php');
  }

}

Some noticeable differences are:

1. Rails uses the ‘<’ symbol in place of ‘extends’ when creating a class;
2. To create a function/method we use def instead of function;
3. Rails doesn’t require a constructor method;
4. Rails automatically loads the view file for the current method. In this case, the view file is located at /app/views/shouts/index.html.erb;
5. It is already noticeable that code is much cleaner in Rails. You don’t need parenthesis (brackets) when defining a funcion/method if it doesn’t contain any parameters, we don’t need to add a semi-colon at the end of each statement and there are no curly brackets in sight!

The Model

Inside /app/models/shout.rb enter the following inside the class to define the all_shouts function:

def self.all_shouts
  Shout.find(:all, :limit => 10,  rder => 'id DESC')
end

Here, we run Rails’ find on the Shout model (ie. the shouts table). We pass a hash telling the method to limit the number of results to 10 in descending order.
This is the equivalent CodeIgniter code:

function all_shouts() {
  $data = array();
  $this->db->order_by('id', 'DESC');
  $q = $this->db->get('shouts', 10);

  if ($q->num_rows() > 0) {
    foreach ($q->result() as $row) {
      $data[] = $row;
    }
  }

  return $data;
  $q->free_result();
}

Yeah… so much simpler!
Also note that in Ruby, if you don’t specifically return something, the last statement is automatically returned. For example, we could have used the following instead (although it would make no difference):

def self.all_shouts
  return Shout.find(:all, :limit => 10,  rder => 'id DESC')
end

The View

In CodeIgniter, we had to manually include header & footer files in each view. Rails takes a slightly different approach. Inside /views/layouts/ create a file named application.html.erb with the following inside:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Shoutbox in Ruby on Rails</title>
<%= stylesheet_link_tag 'style', :media => 'screen' %>
</head>
<body>
<div id="container">

  <h1>Shoutbox</h1>
  <h5>
    <a href="http://www.danharper.me" title="Web Developer">Dan Harper </a> :
    <a href="http://net.tutsplus.com" title="Nettuts - Spoonfed Coding Skills">Nettuts</a>
  </h5>

  <div id="boxtop"></div>
  <div id="content">

    <%= yield %>

  </div><!--/content-->
<div id="boxbot"></div>
</div><!--/container-->
</body>
</html>

This is predominantly a normal HTML layout, combining both our header and footer. On line 7 we include a link to a stylesheet. Rails provides a /public/ folder in which you include images, stylesheet, javascript files and any static HTML files. In this case, the code will output a link to a stylesheet at /public/stylesheets/style.css.

Further down, on line 21 is <%= yield %>. This will insert the main view file for the specific page in this place.

Why .html.erb? All view files in Rails first have the extension for the specific format you want to output as, followed by .erb so the server will interpret the Ruby code inside it.
This means you could also have a .xml.erb file if you want to export in XML for certain pages, etc.

<%= %> Ruby uses <% and %> to wrap any Ruby code to be interpreted, in the same way PHP uses <?php and ?>.
On HTML pages, we use <%= ... %> (note the equals) to ‘print’ code. In PHP we use either <?php echo ... ?> or <?= ... ?> to ‘echo’ code.

Inside /public/stylesheets/ create a file named style.css containing the same CSS we used in the CodeIgniter section.
Also, paste the images from the CodeIgniter section into /public/images/.

If you restart the server now, and reload your browser, you should see a ‘Template is missing’ error page. This is because we haven’t yet created the actual view for the current page.

The ‘Template is missing’ error page tells us what file it was expecting:
“Missing template shouts/index.html.erb in view path app/views”
So let’s create that file now, and enter the following to test it out:

Hello, World!

Reload the page, and you should be greeted with the following (if not, check you have the stylesheet & images in the correct locations):

Looping

You will remember that in CodeIgniter, we used the code below to loop through and display each retrieved shout:

<?php
echo '<ul>';
foreach ($shouts as $shout) {
  $gravatar = 'http://www.gravatar.com/avatar.php?gravatar_id=' . md5(strtolower($shout->email)) . '&size=70';
  ?>

  <li>
    <div class="meta">
      <img src="<?= $gravatar ?>" alt="Gravatar" />
      <p><?= $shout->name ?></p>
    </div>
    <div class="shout">
      <p><?= $shout->message ?></p>
    </div>
  </li>

  <?php
}
echo '</ul>';

The equivalent in Ruby is the following (replace the ‘Hello, World!’ message with this):

<ul>
<% for shout in @shouts

  gravatar = 'http://www.gravatar.com/avatar.php?gravatar_id=' + Digest::MD5.hexdigest(h(shout.email.downcase)) + '&size=70' %>

  <li>
    <div class="meta">
      <img src="<%= gravatar %>" alt="Gravatar" />
      <p><%= shout.name %></p>
    </div>
    <div class="shout">
      <p><%= shout.message %></p>
    </div>
  </li>

<% end %>
</ul>

On line 2 is a normal ‘foreach’-style loop in Ruby. Instead of the foreach ($shouts as $shout) in PHP, we use for shout in @shouts in Ruby.

The loop closes at end on line 16.

On line 4 we build the Gravatar URL in almost the same way as in PHP, with a few exceptions:

1. In PHP, we use the dot character (.) to concatenate statements, Ruby uses the plus character (+), just like in JavaScript;
    
2. Ruby’s version of PHP’s md5() function is Digest::MD5.hexdigest();
    
3. The h() function in Ruby is equivalent to PHP’s htmlspecialchars();
    
4. PHP uses -> to access an object (eg. $shout->email). Ruby uses a dot, (eg. shout.email);
    
5. To ensure the email address is in lower-case, we use strtolower($shout->email) in PHP. In Ruby, everything is an object and so we simply add .downcase to the end of a string or variable – shout.email.downcase. You could also .upcase, .reverse, etc.

Refresh the page in your browser, and you should now see the shoutbox messages!

Submission Form

Continuing on, we need to include the form at the bottom of the page for submitting new shouts. First, take a look at the following line:

<% form_for :shout, :url => { :action => 'create' } do |f| %>
  ... code here ...
<% end %>

This is a block from Rails’ form helper to easily create forms. form_for :shout links the form directly with the Shout model.

:url = { :action = 'create ' } is a hash detailing where the form will direct to when submitted. In this case, the form will go to /shouts/create/ (Shouts controller, Create method). We could have typed: :url = { :controller = 'shouts', :action = 'create }, however the lack of a ‘controller’ key in the hash tells Rails to use the current controller.

Finally, do |f| stores everything before in an f variable. For example, we could create a textbox linked to this using f.text_field

Now we’ve explained that, enter this full form code at the bottom of your index view file:

<% form_for :shout, :url => { :action => 'create' } do |f| %>

  <h2>Shout!</h2>

  <div class="fname">
    <label for="name"><p>Name:</p></label>
    <%= f.text_field :name, :size => 20 %>
  </div>

  <div class="femail">
    <label for="email"><p>Email:</p></label>
    <%= f.text_field :email, :size => 20 %>
  </div>

  <%= f.text_area :message, :rows => 5, :cols => 40 %>

  <p><%= submit_tag 'Submit' %></p>

<% end %>

And compare it with the CodeIgniter PHP version:

echo form_open('shouts/create'); ?>
  <h2>Shout!</h2>

  <div class="fname">
    <label for="name"><p>Name:</p></label>
    <input type="text" name="name" value="<?= set_value('name') ?>" />
  </div>

  <div class="femail">
    <label for="email"><p>Email:</p></label>
    <input type="text" name="email" value="<?= set_value('email') ?>" />
  </div>

  <textarea name="message" rows="5" cols="40"><?= set_value('message') ?></textarea>

  <p><input type="submit" value="Submit" /></p>
  <?php
echo form_close();

We make more use of Rails’ form helper when creating the input fields, textarea and submit button. With f.text_field :name, :size = 20 we are creating a textbox named ‘name’ (matching the column in our database this should insert into). This would output in HTML as:

<input type="text" name="shout[name]" id="shout_name" size="20" />

In the CodeIgniter version of the app, we set each input’s ‘value’ field to <?= set_value('email') ?> so CodeIgniter will automatically re-populate the fields if they fail the validation tests.
In Rails, this is handled automatically since we are using Rails’ form helper to create the inputs.

Refresh the page in your browser, and you should see the form at the bottom:

Submission & Validation

The next step is to insert any submitted data into the database. The form directs to shouts/create, so let’s create the create action now (inside the Controller):

def create
  @shouts = Shout.all_shouts

  @shout = Shout.new(params[:shout])
  if @shout.save
    flash[:notice] = 'Thanks for shouting!'
    redirect_to :action => 'index'
  else
    render :action => 'index'
  end
end

On line 2, we retrieve all our current shouts from the database since they still need to be displayed.

At line 4 we load Rails’ new function on our Shout model. You will remember we used Shout.new when inserting dummy data into the database via the interactive console.
We pass new our submitted data with params[] – this is how Rails accesses POST data.
This is loaded into the @shout instance variable.

When we used the interactive console, we used shout.save to save the data. If it was successful, it returns ‘true’, otherwise ‘false’ is returned. So on line 5 we check whether the shout can be saved into the database, if so, we load a success notice in the session’s ‘flashdata’, and redirect back to the index.
Otherwise, we load index’s view file through the render function.

Validation

You may be wondering where our validation is handled, since we did this in the controller in CodeIgniter. In Rails, we place the rules inside the Model.
When Rails attempts to insert data to the database (eg. with @shout.save), the Model will automatically check the data against our rules before attempting to save it. Thus, if validation fails, then @shout.save will return ‘false’, the view will be re-loaded and the error messages will display.

Inside the Shout model, insert the following before we define self.all_shouts:

validates_presence_of :message
validates_length_of   :name,  :within => 1..255
validates_format_of   :email, :with   => /^[a-z0-9_.-]+@[a-z0-9-]+\.[a-z.]+$/i

In true Ruby style, the validation rules read pretty much like natural English. On line 1 we ensure a ‘message’ exists.

Next we check the length of the ‘name’ field – it must be between 1 and 255 characters in length. 1..255 defines a range. We could define a range of between 10 and 15 with 10..15, for example.

Finally, we check the submitted email is in the format of an email address using a regular expression. Basically, the submitted email must contain five parts:

1. A string containing a combination of letters, numbers, an underscore, full-stop or hyphen;
2. The @ symbol;
3. A string containing a combination of letters, numbers or a hyphen;
4. A dot;
5. A string containing a combination of letters or a hyphen.

And finally…

We now just need to display the error/success messages in the view (see above). Add the following at the top of the index view file:

<%= error_messages_for :shout, :header_message => nil, :message => nil %>
<%= '<p class="success">' + flash[:notice] + '</p>' if flash[:notice] %>

On the first line we render any error messages for the shout form. We set :header_message and :message to nil (Ruby uses ‘nil’, PHP uses ‘null’) to stop the function displaying the normal messages it displays (we just want the error messages).

The second line displays our flash’ed success message. Note the if flash[:notice] at the end of the line. This ensures everything before it will attempt to display if the flash notice exists.
Obviously, we could also have done the following instead; however it would have had the same effect:

<% if flash[:notice] %>
  <%= '<p class="success">' + flash[:notice] + '</p>' %>
<% end %>

That’s It!

Go try it out, it should function exactly as the CodeIgniter version yet in quite a bit less code (which is also much easier to read!)

CodeIgniter:
Controller: 31 lines
Model: 33 lines
View: 69 lines
Total: 133 lines

Ruby on Rails:
Controller: 19 lines
Model: 11 lines
View: 64 lines
Total: 94 lines

While this tutorial may have made the process of developing a Rails application long-winded, take a look back through your code and see how simple it all is!

If this tutorial has sparked your interest in Ruby and Ruby on Rails, I strongly recommend picking up a copy of Rails for PHP Developers, Agile Web Development with Rails and/or Programming Ruby from the Pragmatic Programmers.

Now go! Go explore the world of Rails!

• Follow us on Twitter, or subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

1. Try Ruby!

If you’re going to have to learn a brand new language, why not learn it interactively? The Try Ruby! hands on tutorial is a step-by-step guide that shows you the basics of the Ruby language in 15-minutes. While it’s not strictly a Rails tutorial, it’s best to know the basics of Ruby before you dive right into the Rails framework.

2. Getting Started with Rails

This is the definitive tutorial on Rails. Written by the Rails team themselves, the tutorial shows you how to make a simple blog application. Simple, well documented, and perfect for beginners.

3. Using Ruby on Rails for Web Development on Mac OS X

If you’re a Rails developer, a Mac is an excellent choice for development as Rails comes shipped with Leopard. In fact, installing Rails on a Mac is as simple as typing:

$ gem install rails

and you’re ready to start building apps.

Apple has a lengthy document on the benefits of using a Mac for Rails development, as well as code examples and best use cases. The tutorial is a tad dated, but the guts of the article are timeless with respect to technologies and methods used.

4. UC Berkeley One-Day Rails Course

If you’ve got a whole day set aside to learn Rails, the One-Day Rails course from UC Berkeley is fantastic. The learning course is broken down into 7 one-hour installments, and gives you the basics of Rails.

5. Why’s (Poignant) Guide to Ruby

Again, not a true Rails tutorial, Why’s (Poigant) Guide to Ruby is a fantastic and, ahem… odd way to learn Ruby. In fact, the free guide is so bizarre that I found it more useful than other learning resources because of its wit.

I’ll be straight with you. I want you to cry. To weep. To whimper sweetly. This book is a poignant guide to Ruby. That means code so beautiful that tears are shed. That means gallant tales and somber truths that have you waking up the next morning in the arms of this book. Hugging it tightly to you all the day long. If necessary, fashion a makeshift hip holster for Why’s (Poignant) Guide to Ruby, so you can always have this book’s tender companionship.

Odd? Yes. Effective? Absolutely.

6. Dominating Authlogic

Authlogic is one of Rails most popular authentication systems. Yet because Authlogic is so robust, it can quickly become complex if you’re trying to utilize all the features and add different authentication scenarios.

Railscasts has an excellent screencast on how to manage complex use cases of Authlogic. The screencast runs just over 14 minutes long.

7. Ruby on Rails on Oracle: A Simple Tutorial

Rails is an easy framework to work with, but like any technology it takes time to master.

Oracle has a hands-on tutorial on how to build a simple product catalog with Rails with an Oracle database.

8. Beta Invitations with Rails

If you’re building a web application that you want to marinate in “beta” status for a while, then you’ll probably want to construct some sort of beta invitation system. Railscasts has an excellent 22-minute tutorial on how to set up beta invitations. It’s easier than you might think.

9. Migrations

For Rails newbies, migrations might be difficult to wrap your head around.

Migrations are a convenient way for you to alter your database in a structured and organized manner.

The Rails team has crated a nifty tutorial on everything migrations, like how to create migrations from within your application, and how to use them to their full potential.

10. Rails Routing

Routing is another key aspect of Rails, and the ThinkFresh blog has a thorough tutorial on everything you need to make routes work from within your application. A great starter guide for Rails beginners.

11. Sexy Forms in Rails

If you’re not keen on making every single form by scratch, check out RubyPond’s Sexy Forms in Rails. The tutorial shows how to build forms without having to fill in labels or worrying about formatting.

The tutorial eventually led to FormBuilder, a custom builder for creating accessible forms in Rails.

12. Developing iPhone Apps Using Ruby on Rails

Developing iPhone Apps Using Ruby on Rails is a three-part series by IBM. It covers things like setting up your development environment (the authors use Eclipse with the Aptana plugin), serving mobile content and how to detect iPhone browsers.

13. Monitoring Backgroundrb with God

God, (at least in Ruby terms), is a monitoring framework for Ruby applications. It monitors things like server processes and running tasks, to make sure that your application runs smoothly on your server.

Aside from server monitoring, you can use God to monitor other features of your Ruby apps as well. There’s a pretty heady tutorial on how to monitor the Ruby job processing daemon BackgrounDRb. You can build upon this tutorial to keep tabs on other aspects of your application as well.

14. Rails Security

Ruby on Rails is vulnerable to the same security problems that all other web apps can potentially have. The Rails team has put together a long guide on nearly all aspects of Rails security. Learn about popular injection methods, Rails-specific problems and how to effectively handle sessions.

15. Make Your Own IM Bot In Rails

As the web becomes more connected and in real-time, more applications are starting to utilize IM functionality. Rubypond has a tutorial on how to make an IM bot using Ruby, and then how to interface the bot with Rails.

The tutorial is definitely for those with at least an intermediate understanding of Ruby and Rails.

16. Using Java Libraries in Rails Applications

NetBeans, the popular Java IDE, has a tutorial on how to use the Java API in Rails applications. This is an advanced tutorial, and only for those very familiar with both Java and Rails.

17. Building a Social Networking Site in Rails

As sites become more and more social, the demand for those social features in Rails applications will also go up. Here’s a tutorial on how to build aspects of a social networking site using social networking plugins for Rails. You can pick and choose which features you’d like to add or leave in the tutorial.

18. How to Run a Stealth Rails Application

Aside from being a killer billing solution, Freshbooks is a Rails application that tries to seem like a PHP application. In fact, they say they can pull it off with a single line of code in the routes.rb file:

map.connect ':fake_filename.php', :controller => 'php', :action => 'dispatch'

Surprise!

19. Scaling Rails

With high-profile Rails sites like Twitter taking a toll on scalability last year, the public has consistently asked the question: Will Rails scale?

Scaling Rails is a video series on how to effectively scale your Rails app through 13 screencasts. You’ll learn multiple types of caching and database optimization techniques, as well as how to optimize database structures.

20. Dropping and Sorting with Ajax and Scriptaculous

The name of this tutorial says it all. Learn how to write draggables and sortables with Rails and Ajax. The article has coding examples and can easily be followed by a Rails beginner.

• Follow us on Twitter, or subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

The Basics

This portion of the tutorial is very basic. All we will do is generate a simple application that allows users to create/read/update/destroy a record containing a movie name and rating. I recommend advanced Rails developers skip to the third section which is where the restful_authentication code begins. Note: I did all of this on in OSX on a Mac, but it is not platform specific although you might need to prepend ./ to some of the commands so that Windows knows you are looking in the current directory. If you have any troubles I can help in the comments, or on twitter (@noahhendrix)

Generate the Application

First we need to have rails generate the framework code. This is done by executing “rails MyMovies” in the terminal. “MyMovies” is what I chose to name this application and you are free to use that or anything else. This command creates a lot of files and folders most of which are of no concern to us, but are required for the application to work properly. After this executes will want to change into the newly created MyMovies directory.

rails MyMovies
cd MyMovies

Generate the Movie Model

Now we are going to the power of Rails generators to quickly produce the code and database for our basic application. In the terminal run the command:

script/generate scaffold Movie title:string rating:integer

Here we are telling rails that we want code generated to handle a “Movie” model, which as a string title and integer rating. Notice this will generate some more files, one of which is the database migration. This is where the magic of rails really shows itself, but first we must migrate the database.

rake db:migrate

This command will setup the database and create the table with the appropriate columns. Note: Rails is smart enough to include ID, created_at, and updated_at columns for us. It will also manage these columns so we as developers never need to write code that sets these columns. Now lets look at the fruits of our labor, thats right we have written zero lines of code, but we already have a working application. Start up the server and navigate to http://localhost:3000/movies. In your terminal type:

script/server

Enhancements

You can try to create a movie and rating and see how easily everything works. The rails team really did a great job of allowing developers to quickly push code out with little effort, however that code is only a starting point. It is up to us the developers to make it our own and add the additional features and customizations for users. A good place to start is decide if there are any restrictions we will place on our model. For this example I decided we would require that the user only be able to rate the movie between 1 and 5 stars. Though there are others like making sure they enter a movie title and that the rating is a number. This is how handled in the movie model file.

# app/models/movie.rb

validates_presence_of :title, :rating
validates_numericality_of :rating, :greater_than_or_equal_to => 1, :less_than_or_equal_to => 5

The syntax used in Rails is often verbose, but quite descriptive also. However a positive side effect is we never have to guess what the code we write means. We are telling rails before it saves to the database to verify that both title and rating are set, and as a further restriction rating must be a number between 1 and 5. Notice in the images below we get built in error reporting by default in rails.

User Interface Awareness

Even as developers we are not exempt from considering the interface of applications we develop. Users need to immediately understand the purpose of any information displayed to them. In our application we have them set the rating, but we never say it needs to be an integer between 1 and 5. At first a user might enter a string such as “good”. We could put a label beside the text box that lists our requirements, but we can go a step further and explicitly let them choose between the options we want in a radio button format. Part of the Model View Controller (MVC) methodology of rails tells us that this is a view alteration and it is located within the views directory. First we must remove the line that creates the text box and its label, around line 11 in my code. Look for:

# app/views/movies/edit.html.erb
# app/views/movies/new.html.erb

<%= f.text_field :rating %>

Alright now the new code below must be added to both the new and edit files because both contain forms where the model is modified.

# app/views/movies/edit.html.erb
# app/views/movies/new.html.erb

Rating
<%= f.radio_button  :rating, 1 %> <%= f.label :rating_1, "1" %>
<%= f.radio_button  :rating, 2 %> <%= f.label :rating_2, "2" %>
<%= f.radio_button  :rating, 3 %> <%= f.label :rating_3, "3" %>
<%= f.radio_button  :rating, 4 %> <%= f.label :rating_4, "4" %>
<%= f.radio_button  :rating, 5 %> <%= f.label :rating_5, "5" %>

Alright now lets look at this code closely. First we give the the rating label to tell the user what the radio buttons are for, then we move in the actual buttons. The first parameter for the radio_button method is the model attribute we are working with and the second is the value to send the server on submit. After each button we have a label to tell the user what rating the button corresponds to, the reason we pass in :rating_# is because when rails generates the radio button it gives it an id of attribute_value, so our labels hook into those values. Here is the what the new form looks like with the radio buttons, notice that when you edit a movie Rails automatically selects the radio button that corresponds to the previous rating from the database.

This concludes the first part. In the previous section we got our movie rating application off the ground using the power of Rails generators and some basic view code. In the next section we will make our application a little more visually appealing by adding some graphics and CSS code to spruce up the views.

Styling

Layouts

First we will look at layouts. Not getting into too much detail layouts hold the elements on a page that do not change across the application. For instance header, footer, and navigation typically (and rightfully so) stay consistent across a website. Even though our application is fairly trivial, a layout is important for consistency.

Our goal is to include a logo, background image, and centered container for content on each page. First we need to create our application wide layout page. Rails is kind enough to create a model wide layout file, but this will not apply to the user pages when we get to that part so we need to change it to a global layout. This is easily done by renaming app/views/layouts/movies.html.erb to app/views/layouts/application.html.erb. Now we need to open the file and make a few changes. First lets wrap all of our content in a div called pagewrap. This is nice, because it gives us a bit more control in CSS than we normally get with just body. This can be done by simply including the opening just below the body, and closing it right above the body closing.

# app/views/layouts/application.html.erb
...
<body>

  <div id="pagewrap">

    ...

  </div>

</body>
...

While we are in this file lets go ahead and include a CSS file we will create next. Find the line (9 in my file) that says stylesheet_link_tag ’scaffold’ and append a comma and ’style’ to it so it looks like this:

# app/views/layouts/application.html.erb

<%= stylesheet_link_tag 'scaffold', 'style' %>

This is a helper method provided by rails that creates the <link> tag for us, and links to the style.css file in our stylesheets directory. In public/stylesheets create a file called style.css. Because this is not really a CSS tutorial I will only graze over the declarations.

# public/stylesheets/style.css

html, body {
  background-image: url(/images/bg_body.jpg);
}

#pagewrap {
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;

  margin: 0 auto;
  padding: 10px;
  width: 900px;

  /* logo */
  background: white url(/images/logo.png) no-repeat;
  padding-top: 72px;
}

I am applying a background image to the body tag, so that is will cover the entire page. The pagewrap element we created earlier is given rounded corners (only in Safari and Firefox sorry IE), centered using margin, some padding to push content in, 900px width, and a non-repeating background image that is our logo. The content is pushed down 72px to accommodate the logo, kind of a hack but just an easy way to throw the logo on the page. Unfortunately I can’t distribute the background image or logo because they were created using pieces from a template I bought on ThemeForest.net. But there doesn’t that look so much better now?

Adding Stars

The index page is pretty lame as-is because it simply list the title of the movie and an integer for the rating. Let’s add some CSS magic to make that a little more pretty. First lets update app/views/movies/index.html.erb, by changing the table cell that holds the rating, on line 12. We will wrap the rating in a div with a special class containing the number of stars to show. We also make use of the pluralize helper method in Rails which will output a number passed to it and append a word after the number making it plural if necessary.

# app/views/movies/index.html.erb

<td><div class="star-<%=h movie.rating %> rating"><%=pluralize movie.rating, "Star" %></div></td>

Alright now lets create the CSS code necessary. Note: I did not include the image in the HTML markup so that if a user has CSS disabled they won’t see any stars just something like “3 Stars.”

# public/stylesheets/style.css

.rating {
  background: url(/images/stars.png) no-repeat;
  height: 26px;
  overflow: hidden;
  text-indent: -1000px;
}
.star-5 { width: 115px; }
.star-4 { width: 92px; }
.star-3 { width: 69px; }
.star-2 { width: 46px; }
.star-1 { width: 23px; }

We apply a non-repeating background image of 5 stars to all the rating divs, and then change the width (in 20% increments) to allow hiding of stars. We also push the “# Stars” text off the page with a negative text-indent, since the stars are plain enough language to not require actual words too.

Optional: Removing The Show Page

One last thing I did was remove links to the show page. It seemed a bit redundant to include it since the index page showed all the relevant information. You can do the same by opening app/views/movies/index.html.erb and removing line 13, the link_to the show page. You also need to open app/controllers/movies_controller.rb and update lines 48 and 65 call to redirect_to, make the parameter movies_url instead.

The restful_authentication Plugin

Now that we have made it through the basics, lets add users! The purpose of the first half of this tutorial was to simulate the legacy application you have already created. So from this point on you can easily apply what we learn to any application you create. The great thing about the restful_authentication plugin is that it abstracts the authentication logic away from the other models and makes it fairly quick and painless to implement.

Install restful_authentication

First things first we need to install the restful_authentication plugin, stop the server by pressing CTRL+C, if you have it running. The GitHub page for restful_authentication has instructions on installing, but here is the reader’s digest version:

script/plugin install http://github.com/technoweenie/restful-authentication.git restful_authentication

Passing in the second restful_authentication tells rails we want to rename the plugin folder to that instead of restful-authenticatoin. The reasoning is explained under the header of Installation for those who are interested. Alright now this commands basically goes out to the server and fetches all the restful_authentication files and copies them to your server. It also creates a generator script that we can run to create the necessary controllers, models, and views in our application folder.

script/generate authenticated user sessions --include-activation

Using the authenticated generator we say we want to call the model that handles user information user, and the model that handles the sessions called sessions, easy enough right? But why do we separate these? If you really think about about it registering a user and retrieving their information is similar to authenticating them, but really it is very different too. One is storing long term login information on the user and the other is more temporary and is erased once they logout. So it really makes a lot of sense to split them up in our design. We also pass in the include-activation flag so that it generates the necessary mailers for activating user accounts through email.

Alright that now we have the files in the application folder, but we are not quite done in the terminal. The generator above also created some migrations for us that creates users and sessions tables in our database, but now we need to associate users with their movie records. Let’s use the migrations generator to add a user_id column to the movies table.

script/generate migration add_user_id_to_movie user_id:integer

Rails 2.0 brought some really nifty automation for the migrations generator. Because of the name schema add_user_it_to_movie rails will assume what we mean and create a schema that does just that. So all we are left to do is run

rake db:migrate

and our database is up to date. If you want to see the migrations file it created to get a feel of what we did you can check out app/db/migrate and look for the add_user_id_to_movie.rb file. Ok, we are all done in the terminal for now!

Associating Users and Movies

In order for a user to “own” a movie record we must tell rails that they do. This is down through associations declared in the models. First lets update the user model created by our generator, app/models/user.rb. I usually add the following code right above the first method declaration, activate in this case.

#app/models/user.rb

has_many  :movies

This is pretty straight-forward, we are telling rails that user has many movie records associated with their account. Now lets inform the movie model of the associate in app/models/movie.rb. Add this code right below our validation methods from earlier.

#app/models/movie.rb

belongs_to  :user

Similar to above we just are saying that each individual movie record belongs to a user. Now the beauty of these associations is Rails now assumes our database has a user_id column in the movies table, which we of course already do. That is all the work we have to do no foreign keys, no custom code it is just given to us out of the box more or less.

Routes

This is more of a user experience modification, but something all applications should include. Currently if a user wanted to sign up the url is example.com/users/new or if they wanted to login it is example.com/sessions/new, a bit verbose in my opinion. So we will add some custom routes in config/routes.rb, mine went in around line 8.

# config/routes.rb

map.activate '/activate/:activation_code', :controller => 'users', :action => 'activate'
map.signup '/signup', :controller => 'users', :action => 'new'
map.login '/login', :controller => 'sessions', :action => 'new'
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

As you can see here we are declaring active, signup, login, and logout for their obvious counterparts. This will make our URLs more sensible and easy to remember. Notice that activate requires a string passed in which will be the activation code we send out in emails to users to validate email addresses.

Validating Email Addresses

It is common practice with many websites to require users to validate email addresses by clicking a link in an email sent to the address they provide. In other languages and frameworks this is somewhat difficult, but the restful_authentication plugin and rails mailers makes this advanced functionality very easy. However before we can send out emails we need to tell rails how to authenticate with our SMTP server. Now this varies from host to host, and you will need to contact your host to determine how to fill in these settings. Note: You will need to create the file config/initializers/mail.rb first.

# config/initializers/mail.rb

ActionMailer::Base.delivery_method = :smtp
ActionMailer::Base.smtp_settings = {
	:address => "mail.example-domain.com",
	:port => 25,
	:domain => "www.example-domain.com",
	:authentication => :login,
	:user_name => "user@example-domain.com",
	:password => "secret"
}

While we are setting up defaults we should define the URL of our website we will use in all our emails. You might wonder why we would do this, and reason is to future-proof our application. For instance, while we are developing locally the domain is localhost:3000/, and presumably our production domain is different. If at some point in the future the production URL changes we can update it in one place and not worry about other missing other changes. But where do we site these defaults? Rails created some configuration files that are loaded depending on the environment we are in: development, testing, or production. Starting with development we must modify config/environments/development.rb, at line 19.

# config/environments/development.rb

SITE_URL  = "localhost:3000"

And likewise in config/environments/production.rb at line 30.

# config/environments/production.rb

SITE_URL  = "noahhendrix.com"

Now we need to update the user_mailer model file, app/models/user_mailer.rb, to use our newly create SITE_URL variable. These changes need to be made on lines 6, 13, and 20 remove YOURSITE and replace it with #{SITE_URL}. On line 19 you need to update the email address to your own.

Here is what the email asking them to activate their account looks like.

They also receive an email once the account is activated

Updating our Controllers

The movies controller that rails created for us was helpful before we added a user system, but now we want to only allow users to cretate, read, update, and destroy their own movies and prevent them from seeing other users’ movies. This is done by modifying the movies controller and having it add a user_id column restriction on all queries to the movies table.

We are going to update a bunch of lines and because they are so pretty much the same we won’t go over them individually. Essentially we are telling the controller to restrict all finds to the current_user variable (i.e. add “WHERE user_id = ##” to the database queries). The current_user variable is something restful_authentication gives us to use in our controller for this specific reason. I’ve included the approximate line numbers, but if they are different for you then know that we are only modifying the methods: index, show, edit, create, update, and destroy. Note: the variable Movie is changed to movies because we are accessing it through the user which comes from when we said a user has many movies.

# app/controllers/movies_controller.rb

Line 8: @movies = current_user.movies
Line 20: @movie  = current_user.movies.find(params[:id])
Line 42: @movie  = current_user.movies.find(params[:id])
Line 49: @movie  = current_user.movies.create(params[:movie])
Line 67: @movie  = current_user.movies.find(params[:id])
Line 85: @movie  = current_user.movies.find(params[:id])

While we have this file open at the top (line 2) we need to add a before filter. This tells rails that before it runs any of the methods below it needs to first run a method we provide.

# app/controllers/movies_controller.rb

before_filter :login_required

The method :login_required is provided by the plugin and basically will check if the user is logged in, and if not will redirect them to the login page.

Alright not too bad, right? We have a few last things to clean up before the plugin is fully functioning. In app/controllers/sessions_controller.rb and app/controllers/users_controller.rb there is an include statement that need to be removed, and added to app/controllers/application_controller.rb. This line includes the necessary back end files that the plugin uses to manage the users and sessions. I put mine at line 5.

# app/controllers/application_controller.rb

include AuthenticatedSystem

If you curious where it is pulling this file from, you can find it in lib/authenticated_system.rb.

Adding Password Reset

Updating The Users Controller

We need to add two methods to the users controller, app/controllers/users_controllers.rb, that will take care of the form for users to reset their password. However, before we dive into code lets take a second to discuss our plan. We want to allow a user to click a link that says they forgot their password. They will then be taken to a page asking what email address they used when creating their account, once they submit that we will fire off an email with a link containing a special hash that will they can click. Once they open the link in their email they will have a form to choose a password, and confirm it.

Alright lets look at each function individually starting with forgot.

# app/controllers/users_controller.rb

def forgot
  if request.post?
    user = User.find_by_email(params[:user][:email])

    respond_to do |format|
      if user
        user.create_reset_code
        flash[:notice] = "Reset code sent to #{user.email}"

        format.html { redirect_to login_path }
        format.xml { render  ml => user.email, :status => :created }
      else
        flash[:error] = "#{params[:user][:email]} does not exist in system"

        format.html { redirect_to login_path }
        format.xml { render  ml => user.email, :status => :unprocessable_entity }
      end
    end

  end
end

Here is the action referring to the form where they enter their email address. First we check to see if they have submitted the form via a post request, if not we do nothing because we are waiting for the form to be submitted. Once we have post data we find the users information using the provided email address to make sure they exist. We are using a respond_to format block so that we can respond to both xml and html requests. In this tutorial we won’t use the XML format, but it is good to provide it for web services. Now you will see we have a simple if statement saying if user is not nil (implied) we want to run the method create_reset_code and notify the user via a flash method that they need to check their email for a reset link. If the user doesn’t exist we let them know that as well.

Alright now lets look at the reset action, the one they see after they click the link in their email.

# app/controllers/users_controller.rb

def reset
  @user = User.find_by_reset_code(params[:reset_code]) unless params[:reset_code].nil?
  if request.post?
    if @user.update_attributes(:password => params[:user][:password], :password_confirmation => params[:user][:password_confirmation])
      self.current_user = @user
      @user.delete_reset_code
      flash[:notice] = "Password reset successfully for #{@user.email}"
      redirect_to root_url
    else
      render :action => :reset
    end
  end
end

First we find the users information through the reset code, to make sure that they exist in the database. If there is user data found we log them, and present the form to reset their password. Next we check to see if they are just loading the form or if they have already submitted it. If there is post data we update the password to the one they supplied. We set the current_user to that user, and remove the reset code so no one else can use the link to change their password. We give them a flash notice that confirms the reset. If we can’t update the password we send them back to the password page with errors.

Updating the User Model

Some of this is pretty confusing because we haven’t fully implemented some methods we used such as: create_reset_code, recently_reset?, and delete_reset_code. We will put these in the user model, app/models/user.rb, right above the word protected towards the bottom.

#app/models/user.rb

#reset methods
def create_reset_code
  @reset = true
  self.attributes = {:reset_code => Digest::SHA1.hexdigest( Time.now.to_s.split(//).sort_by {rand}.join )}
  save(false)
end

def recently_reset?
  @reset
end

def delete_reset_code
  self.attributes = {:reset_code => nil}
  save(false)
end

In the create_reset_code function we are setting an instance variable @reset to true so that our application can keep remember that they are have recently reset their password. Then we are setting a reset_code in the database (which we have yet added a column for) to a hash of the current time to make it unique. Then we save that reset_code to the database, the false parameter tells rails to ignore validations which we can do because we set the code ourselves not users.

The recently_reset? method is just so we can check if the @reset variable is true or false. And finally the delete_reset_code does exactly what it’s name infers, remove the reset code from the database.

Creating the Forgot and Reset Views

We’ve talked about the forms the user needs to fill out in order to reset their password, lets go a head and create those. First in the directory app/views/users/ called forgot.html.erb.

# app/views/users/forgot.html.erb

<%= error_messages_for :user %>

<% form_for :user do |f| -%>
  <p>
    Reset Password Request
  </p>

  <p>
    <label for="email">Email</label><br />
    <%= f.text_field :email %>
  </p>

  <p>
    <%= link_to "Cancel", login_path %>
    <%= submit_tag 'Submit' %>
  </p>
<% end -%>

This is a pretty generic form, where we ask the user for their email. Now we need to create the form to reset the password in the same directory as above create a file called reset.html.erb.

# app/views/users/reset.html.erb

<%= error_messages_for :user %>

<% form_for :user do |f| -%>
  <p>
    Pick a new password for <span><%= @user.email %></span>
  </p>

  <p>
    <label for="password">Password</label><br />
    <%= f.password_field :password %>
  </p>

  <p>
    <label for="password">Confirm Password</label><br />
    <%= f.password_field :password_confirmation %>
  </p>

  <p>
    <%= submit_tag 'Reset' %>
  </p>
<% end -%>

Emailing the User A Reset Link

Alright now that we have the forms setup lets modify the user mailer class to send the reset links out. Since we are working with views lets start there. If a traditional view translates roughly to a webpage then a mailer view would translate to an email. Basically this is the basic layout of the email we want to send the user, leaving spots for variables our controller will provide. The file we are going to create is app/views/user_mailer/reset_notification.html.erb, and the insert this code:

# app/views/user_mailer/reset_notification.html.erb

Request to reset password received for <%= @user.login %>

Visit this url to choose a new password:

<%= @url %>
(Your password will remain the same if no action is taken)

This is all pretty generic mark up, notice that we have a space for the url and the users login name. We also tell them that if they do nothing the password will not be changed. Now lets go into app/models/user_mail.rb and create the reset_notification method, this is where our view gets the user login and reset url variables. Insert this code somewhere after the activation method, but above protected.

# app/models/user_mailer.rb

...
def reset_notification(user)
  setup_email(user)
  @subject    += 'Link to reset your password'
  @body[:url]  = "#{SITE_URL}/reset/#{user.reset_code}"
end
...

Here we are doing a few things. First we call the setup_email method that is declared under protected (protected means only this class can call that method), which is some generic email setup things. We append a string to the subject to help the user identify the purpose of the email from the subject. Next we set that URL we talked about earlier notice we are using the #{SITE_URL} variable we set earlier. The reset_code variable comes from the user model that we set earlier using the create_reset_code method, remember that?

One more model that we need to update, app/models/user_observer.rb. Basically this is where we say to send that email if the @reset variable is true. These methods are executed whenever the user is interacted with, in this case after we save it to the database we want to check if they need to get a reset email. After the line that sends the activation email add this code.

# app/models/user_observer.rb

...
UserMailer.deliver_reset_notification(user) if user.recently_reset?
...

Alright lets update one more file before we move into the terminal to add the reset_code column. Remember that URL the user is emailed? Well we need to set that up in the routes file, config/routes.rb. On the line below where we setup the logout route add these two lines:

# config/routes.rb

map.forgot    '/forgot', :controller => 'users', :action => 'forgot'
map.reset     'reset/:reset_code', :controller => 'users', :action => 'reset'

This is just like the above routes, we are mapping friendly URLs to the proper controllers and actions. Alright, lets move into the terminal. So now we are going to use the same migration generator we used for adding user_id to the movies table. So this code will look really familiar.

script/generate migration add_reset_code_to_user reset_code:string

Don’t forget to run

rake db:migrate

to update the database.

Cleaning Up Loose Ends

Setting the Default Root Page

First we need to delete the file public/index.html. This is the page and will override the default controller we will set. Next open config/routes.rb, and uncomment line 46 (the one starting map.root). Change welcome to movie, this tells rails to render the movie controller as our default if someone navigates to localhost:3000/ or the root of our production domain.

Adding Sign Up, Reset, and Logout links

Alright now we get to move to the views. in app/views/sessions/new.html.erb we should remove lines 8 and 11 to allow our users to remember their session so they do not have to re-login each time they visit. On line 11 there is a paragraph tag we need to add sign up and forget passwords links within that element.

# app/views/sessions/new.html/erb

<%= link_to 'Sign Up', :signup %>
<%= link_to 'Forgot Password?', :forgot %>

Users are now able to easily sign up, login, or reset their password but we need to include a logout link once they are logged in so they can end their session. We will do this in the application layout file, app/views/layouts/application.html.erb, so that it appears on all pages. I added mine right above the flash messages, but below the pagewrap div.

# app/views/layouts/application.html.erb
<div class="user">
  <%= link_to "Logout", :logout unless !logged_in? %>
</div>

Notice that we say to include the link unless logged_in? is false, logged_in? is a helper the plugin provides that returns true if the user is logged in and false if they are not, and of course we only want to the link if they are actually logged in.

While we are here lets add another flash message type, alert. This is to display errors to the user passed in from the controllers. Below the existing one add this line.

# app/views/layouts/application.html.erb

<p style="color: red"><%= flash[:alert] %></p>

Preventing Auto-Login on Sign Up

You might have noticed that when you sign up the application logs you in without first requiring the email verfication, although it prevents any subsequent logins. This is something included in the default user controller where if the user passes validation they are logged in by setting current_user to the user model just created. In our application this is a bug because we want the user to first authenticate their email address. We can fix this behavior in app/controllers/users_controller.rb around line 16 we need to remove, or comment out, where it sets current_user = @user.

Also as a helpful hint to users we should modify line 17 where it tells the user they successfully signed up to something that instructs them to check their email.

# app/controllers/users_controller.rb

flash[:notice] = "Thanks for signing up! Please check your email to activate your account."

Alright that is all we need to do for our basic user authentication. I hope this has helped as a step-by-step walkthrough of how to install and use restful_authentication in your rails application. I know that this is very simplistic so post any desired customizations in the comments, or contact me on twitter (@noahhendrix) and I will try to address them. Thanks for reading!

• Follow us on Twitter, or subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

This is the way Ruby on Rails promotes itself – but in my words, it is an incredible framework that can really make your life much easier. You can learn more at their site http://rubyonrails.org

Step 1- Installing Ruby on Rails

Installing Ruby on Rails (also often shortened to RoR) is fairly painless on most systems, but you will need to be comfortable opening up the terminal. The Ruby on Rails download page provides links to get started, and I will reproduce them here to save you a bit of time. Just as a note, these are the places to get Ruby, which is what Rails is programmed in, and we will be installing Rails in a minute. To learn more about the language, review the Ruby site

• Windows: One-Click Ruby Installer (I recommend using 1.8.6-26 Final Release)
• Mac OS X 10.4: Ships with broken Ruby but you can follow the amazing guide by Dan Benjamin
• Mac OS X 10.5: If you install the Developer Tools from Apple you will be set. Try either your installation discs or Apple’s Developer Site and download Xcode
• Linux: While this may vary for each distribution, you will need to install ruby, irb, & rdoc

Now that we’ve downloaded Ruby, make sure you have RubyGems, which is a package manager for Ruby.

To test if you have RubyGems, run the following in terminal:

gem -v

As of this writing, 1.3.2 is the latest version. To update if you don’t have the latest version, run the following, and if you are on a Mac, put sudo in the front.

gem update --system

If you won’t be using RubyGems, follow these steps:

1. Download the latest release of RubyGems here.
2. Extract the package
3. Change into the directory in your terminal (cd is the command)
4. Run this in the terminal: ruby setup.rb (Add sudo in front of the command for Linux & Mac OS X users, you will also need to continue that for all gem install commands)

If you have a Linux system, you should be able to install RubyGems through your package manager, but I prefer the method above. If you have any more problems, check out the installation documentation at the RubyGems site.

Installing Rails

Now that we have the latest version of RubyGems, let’s install Rails:

gem install rails

It will take a few minutes to install Rails and all of its’ dependancies.

Step 2 – Creating an Application

So now that we have Ruby, RubyGems, and Rails installed, let’s create a project! To create a new project, you will use the Rails command to create new projects. We will create a simple project named “blog.” Note: This will create the app folder in the current directory you are in terminal, so make sure you change into the directory you want the app to be stored in.

rails blog

You should see something like this fly by:

Next, open the project in your favorite text editor/IDE. I personally love TextMate, -while only for Mac OS X, there are some great clones which are also available.

Folder Structure

The folder structure of a Ruby on Rails will look similar to the following:

There are three folders any developer or designer will need to work with on a daily basis: the app, config, and public folders. Please review the short explanations for each of the folders:

• app: This is where your application’s logic lives.
  • controllers: This is where Rails looks for the controller classes. In short, these receive the requests.
  • helpers: Helpers live in this directory and assist the controllers, models, and views
  • models: Each of these basically represents a table in the database, so finding information and setting up your application is dead simple
  • views: what the user sees
    • layouts: these are each of the layouts you can define a controller to use. Makes templating very easy.
    • all the other ones: While in our application we currently don’t have any, each of the other folders that will be in this folder represent and relate back to the controllers, and the files that will be in here correspond to the actions in the controller
• config: This folder holds all of your app’s settings. Some specific files:
  • database.yml: This file holds your database settings
  • environment.rb: This file holds the Rails settings for your application
  • environements/: This folder holds the configuration settings for each of the specific environments: development, test, and production
  • routes.rb: This file holds the settings for the URL schema, as well as specific URL and where to send the requests
• db: This folder will end up holding your database (if you use sqllite), your database schema, and all of your database migrations (changes to the structure)
• doc: This folder will hold all of the documentation generated by rake doc:app
• lib: The files in here contain application specific code that doesn’t belong in your controllers.
• log: Rails stores the logs in here, four of them. One for server specific stuff in server.log, and one for each environments.
• public: This folder contains all of the files that will not change as much. Rails looks for files her before trying to go to a controller. Javascripts are stored in the javascripts folder, images in the images folder, and stylesheets in the stylesheets folder. Static files like robots.txt and other html files can also be stored here. Make sure you delete the index.html file because that will show up instead of what you want!
• script: These scripts make your life a whole lot easier. The server script launches the development web server, and generate generates code.
• test: The tests you write and the ones Rails creates for you are all stored here.
• tmp: Rails stores any temporary files here.
• vendor: Here you can install any Rails plugins (or libraries) made by third-parties that do not come default with the Rails distribution.

Step 3 – Getting your Hands Dirty

While the purpose of this tutorial is not to create an application, we will still do a bit of programming. Let’s first create a controller named articles: (Make sure you have changed into the root of the Rails application)

script/generate controller articles

Now open up the file, and you should see this:

class ArticlesController < ApplicationController
end

All this code says is that we are defining a new class called ArticlesController that inherits from another class called ApplicationController. Now, we are going to create an action (referred to as a method strictly speaking in Ruby) name index, so when you go to http://localhost:3000/articles/ you will be shown something. Change your code so it looks like:

class ArticlesController < ApplicationController
	def index
	end
end

So now that we have an action, go to the app/views folder. We are going to create a view so when a user requests that URL, they actually see something. You may have noticed that there is a new folder in here named articles; this folder was created when we generated the controller. So, make a new file in the articles folder named index.html.erb. You may ask about the ending, the html refers to the type of file, and the erb refers to embedded Ruby as the templating engine. I personally prefer rhtml as it is a single ending, but that will be depreciated in Rails 3, which is planned to be released at RailsConf this summer. Put this into your new file:

The time now is <%= Time.now %>

The &lt%= %> tags may intrigue you. This tag is meant so that Ruby ouputs the results of the enclosed Ruby code. So this code will print the Time now. The other tag you will use in Rails is simply <%- -%>. This tag is meant for Ruby code that doesn’t actually output anything, such as when repeating through items in an array.

Now we are going to create a layout to make this text beautiful. So create a file in the views/layouts directory named application.html.erb with the following in it:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title><%= h(@title) %></title>
    <%= stylesheet_link_tag 'application' %>
	<%= javascript_include_tag 'prototype' %>
    <%= yield(:head) %>
  </head>
  <body>
    <div id="container">
      <%- flash.each do |name, msg| -%>
        <%= content_tag :div, msg, :id => "flash_#{name}" %>
      <%- end -%>
      <%= yield %>
    </div>
  </body>
</html>

First, before I explain the code, I do want you to know why we named the file application.html.erb. Rails will automatically load this layout every time unless otherwise specified. If you had named this layout “layout” then you would have had to add layout :layout to the top of the controller. This block of code has some important tidbits that you will want to know for when you are developing layouts.

• <%= stylesheet_link_tag ‘application’ %>: This tag generate the CSS inclusion tag for the CSS file named application.css
• <%= javascript_include_tag ‘prototype’ %>: This tag generates the Javascript inclusion tag for the Prototype javascript library. Prototype is the default javascript library that comes with Rails. You can also put :defaults (not in single quotes) instead of just prototype and Rails will load all of the defaults, :all would load all files in the public/javascripts folder.
• <%- flash.each do |name, msg| -%>: This code and the code in the block means that for every item in the flash array, it will show a message to the the user.
• <%= yield %>: This outputs all of the info from the individual view, and outputs in inside the template and sends this to the user.

Now, let’s create a quick CSS file, named application.css in public/stylesheets, and put the following in it:

body {
  background-color: #111;
  font-family: Verdana, Helvetica, Arial;
  font-size: 14px;
}
#container {
  width: 75%;
  margin: 0 auto;
  background-color: #FFF;
  padding: 10px;
  border: solid 5px #999;
  margin-top: 20px;
}

Now, we have a very simple application for displaying the current time; hopefully, you should be more acquainted with the basics of Rails.

Step 4 – Finishing Up

You might be thinking, “This is cool and all, but how do I see the final product?” There is a terminal command that you need to run while in the base of the Rails application to start the local development server. script/server will start the server, normally on port 3000. Run the command and point your browser to http://127.0.0.1:3000/articles. You should see the following:

To stop the server select the terminal window and Control-C. This will stop the development server. As a note, make sure you never run a production server this way.

There is one last thing that I would like to show you. As I said before, the config/routes.rb file manages where requests go. Open up the file; we are going to make it so when you go to http://127.0.0.1:3000/, you see the same thing as before. Find the line, “# You can have the root of your site routed with map.root — just remember to delete public/index.html.” Under that section, add the following:

map.root :controller => "articles"

Save the file, and make sure you restart the web server. You will always need to restart the server whenever you create a new model, and change some other files that Rails stores in memory to speed up the server. Make sure you delete public/index.html, or just rename it. Now make sure the server is started and go to http://127.0.0.1:3000. You should see the same thing.

Conclusion

So now you should be a little more familiar with Ruby on Rails. I have also linked to some really great sites to refer to when developing with Rails. Have fun coding with Rails!

• Railscasts put on by Ryan Bates is an amazing source of video tutorials, and you can always expect something great.
• The Rails API is a great way to find more information about a subject you may not be entirely sure about.

Follow us on Twitter for more daily web development tuts and articles.

Catching Up

If you haven’t read Parts 1 and 2, it is strongly advised that you review them before continuing on with this tutorial.

• Week One
• Week Two

Adding Interactions Amongst Actions

Now that we’ve learned how to set instance variables to transfer information from the controller to the view, it is time to learn how to transmit data between different actions in a controller. For this tutorial, we’re going to continue using the learn controller. We don’t really need to keep what we did last week, but you can if you feel like it is a good resource.. We’ll start off simple:

Perform Another Action in a different Action

For this example, the heading is more complex than the actual lesson. We are going to simply use what’s in one action and do the same in another. Lets use the knowledge we gained last week about instance variables, and apply it now. First, let’s create a new action called "another_action"; then another action called "text". We are going to then get the action from text and put it in "another_action". We are going to prove this, by referencing an instance variable in the view of "another_action" that was assigned in the "text" controller. Sorry, if that didn’t make sense. If you didn’t get what I just said, look at the following code, which will hopefully help you:

class LearnController < ApplicationController

  def another_action
  	text
  end

  def text
  	@text = 'This text came from another action'
  end
  end

We are then going to create a view called "another_action.html.erb", where we reference the variable text.

<html>
  <head>
  <title>Action Demo</title>
  </head>
<body>

  <%= @text %>
  </body>
  </html>

Explanation

As you can see, we referenced the action "text" simply by putting that inside of "another_action". By doing this, we also passed the definition of "text", which was the instance variable. To further demonstrate this principle, let’s put this in several different situations, all of which work.

Situation 1- Setting An Instance Variable Equal to an Action

class LearnController < ApplicationController

	def another_action
		@text = text
	end

	def text
		misc_text = 'This text really traveled!'
	end
end

Situation 1 Result

Situation 2 – Replace Variable

Now we’re going to get even more complex:

<html>
class LearnController < ApplicationController

	def another_action
		@text = "text you'll never see"
		@text = text
	end

	def text
		wanted_text = overwrite_view
	end

	def overwrite_view
		overwrite_text = 'This text overwrote the original text'
	end
end

Situation 2 Result

This is the order of events that the following code did:

• Gave the instance variable "text" a value of "text you’ll never see"
• Then it re-assigned it to the action "text"
• The variable "text", now has the value of the local variable wanted text.
• The wanted_text variable has a value of the action "overwrite_view"
• Overwrite_view has a local variable with a value of "This text overwrote the original text"
• This carries back to the instance variable of @text.

Situation 3 Carry a Variable

We’ll keep this one simpler:

class LearnController < ApplicationController

	def another_action
		@text = "text you'll never see"
		text
	end

	def text
		@text = 'This text overwrote the original text'
	end
end

Situation 3 Result

Situation 4 Returning Something Specific

class LearnController < ApplicationController

	def another_action
		@text = text
	end

	def text
		first = 'This text should not be passed to @text'
		second = 'This text would be put into the variable on default'
		return first
	end

end

This example is particularly important, as you are now learning a little bit more syntax; the return command. This will tell the action what to return at the end.

Situation 4 Result

Rails Links

Everyone should already know how to create a normal HTML link. (Using <a href="">Text</a>) But there’s also a way to do it with Rails. This method is not Ruby, but rather a part of the framework. That being said, you can only use it in embedded ruby HTML files, not pure rb files. So how do we do it? Here is the code:

<html>
  <head>
  <title>Rails Link Demo</title>
  </head>
<body>

  <%= link_to('Another Action Link', :controller => 'learn', :action => 'another_action')%>
  </body>
  </html>

At first glance, you might wonder why you would ever change the way you write links, especially if the replacement is longer! Well one main reason is readability. You can easily read this and know exactly what it’s going to link to. As for length, the :controller => part is not necessary if you’re linking to an action within the same controller.

With this piece of rails code we are also seeing symbols. The ":controller =>" is a symbol. We’ll talk more about what they do later, but for right now just recognize the colon.

Rendering in Rails

Earlier in this series, we talked a little bit about rails’ sensible defaults. One of the defaults is to generate a view that has the same name as the action in the corresponding view. But what if we wanted to overwrite what rails automatically does? This is actually quite easy, and a very useful technique. When you’re working on a real world project, you can imagine how ‘clunky’ your controller would get if you needed to create a separate view and action in the controller for each page. Rails has a solution though, which is called rendering. Rendering allows you to specify what view to use for each action. Keep in mind though, that like rails links, this is also rails exclusive code and not ruby, and meant only for the controller.

If the above has left you a little confused, let me show you how to do it. This will hopefully clarify it a little bit. For this first example, we’re going to render the action to the view that it would normally render anyway. In other terms, this render code does nothing that wouldn’t happen without it. All it is doing is showing some code that usually is just ‘assumed’.

	def index
		render :action => 'index'
	end
    

Rendering an Action to another View

The last example isn’t really useful since the result is achieved automatically anyway. But what if you had a really advanced view for another action, and you wanted the same view for a different action. It would not only be tedious to create another identical view for each action you create, but it would also be nearly impossible to update! All of that can be fixed though by rendering every similar action to a specific action. Examine the following piece of code which I will explain afterwards, and notice the different parts.

text_controller.rb:

class LearnController < ApplicationController

	def index
		render :action => 'text'
	end

	def text
		@text = '<u>Text</u>'
	end

	def other
		@text = '<b>Other</b>'
		render :action => 'text'
	end

end

text.html.erb:

<html>
  <head>
  <title>Rails Rendering Demo</title>
  </head>

<body>

  <p>Welcome to the <%= @text %> Page</p>


</body>
  </html>

Explanation of Code:

Index Action

You might have noticed that I included an action called "index". This action will be viewed if you go up a directory to "learn". It works like an ordinary index file would. You don’t have to create a specific action for index though. You can use the previously covered topic of inheriting another action as well.

Rendering to the same view

For this example, we only needed one view for all of the actions; and they all produced different pages. To me, this is pretty incredible for the amount of work we put in.

Note: This might seem obvious to some, but beware of double rendering. Double rendering will cause an error because you’re trying to render an action to two different places. Can you be in two places at once? No, and neither can an action. If you want to see what it looks like, just render an action to two different views. The reason it happens as you’re doing more complex projects is because the trail of actions can get pretty complex, and you might accidentally create this error.

Make sure you get the basic concept of rendering, as it will be a very vital technique that you will use often as a rails developer.

Redirecting An Action

Redirecting an Action is similar to rendering an action in the fact that it too is rails code and only used in the controller. Also, it effects the flow of the application. As you might guess from the name, redirecting allows you to… well redirect.

You might be surprised by how many times you use the redirect command. Here are some common uses:

• Creating alias pages
• Performing an action in the controller and then redirecting to a secondary page
• If there is an error, redirect to an error page
• If user is not logged in, send them to a login page

Enough chit chat, let’s get to the code! For this code example, we’re just going to modify the last example’s controller and leave the view the same. As you’ll see, redirecting is very similar in format to rendering:

class LearnController < ApplicationController

	def index
		redirect_to :action => 'text'
	end

	def text
		@text = '<u>Text</u>'
		redirect_to :action => 'other'
	end

	def other
		render :action => 'text'
	end

end

Now go to the index action in your browser. You’ll notice that you end up at the other action in your address bar. Let’s run through this code:

• First, we redirect to the action text. Like linking in rails, you can specify a controller too if you’re redirecting to another controller. You would just put :controller => ‘learn’, before the action.
• The browser now goes to the text action. Here it sets a value for @text. But the browser has no value for @text. This is because redirecting essentially forgets anything you tell it in that action.
• We are now redirected to other. Here we render out to the text view.

Render or Redirect?

While there are some obvious scenarios where you would chose either to render or to redirect; there can be some harder decisions. One important key though is that if you’re submitting data into a database or anything that is changing the application, use a redirect. Otherwise, a refresh could resubmit the data.

Final Thoughts

Hope you guys learned a lot from this week’s tutorial! We covered a lot of important concepts so if you are still confused by anything, re-read it. Next week we’ll probably get into ruby syntax!

As always, feel free to leave questions in the comments. Also, please digg this article if it helped you!

Last Week…

Last week, we got the framework set up, and learned a little bit more about ruby and rails. We then learned how to create a new application and generate a controller.

Ruby Editors

Now that we’re going to get into Rails Syntax, we need a good editor. Since rails is a relatively new framework, it doesn’t have quite the range of syntax supported editors. Luckily, there are still extremely good ones out there. For windows, I personally use E Texteditor. It has great support for ruby, and features automated scripts for many languages. E text editor branched off of the success of the exclusive mac program TextMate. The only downside to both, are that they aren’t free. If you’re looking for something free, you could always go with the reliable Notepad ++.

Getting Things Visible

Creating an Action

As you might remember from last week, we ended by creating a controller which we called learn. This will lead us into today’s tutorial. We are now going to use that controller, and create an action in the controller. We will then also create a corresponding view file. The view is the component of MVC architecture that usually contains all of the HTML, and therefore is an embedded ruby file (rhtml).

Now that we have the learn controller generated, we can view the rb file by going to app/controllers/learn_controller.rb. Right now, you should see the following code already there:

This default code allows this controller to inherit the default application controls.

We now need to define a method, specifically, an action. This action will map out the URL for the view. To define an action named more, we type the following code:

We can pick any name we want. A good strategy when picking the name of the action, is giving it a name that has to do with the content that will be there. You should also pick the name according to the desired URL. The controller and action map out the URL. For example, to get to the "more" page, you would type in, localhost:3000/learn/more. In fact, let’s try it and see what happens:

Oops…as you can see from the helpful error message, we still need to make a view.

Creating a View

Unlike the controller, to create a view we do not need to generate it through the console. Instead, we can simply create a new file. When we generated the controller, learn, you might have seen that a directory (called learn) was created in the app/view folder. We need to create an .rhtml file inside there, and call it the action that we defined in the controller.

A picture’s worth a thousand words, so here you go:

And now, just to test out the page, we’ll add a little HTML and see what happens. I just added a basic required HTML, and then some dummy text and title. You can put anything you’d like here.

Save it, and lets test it out again.

Great it works! Congratulations, you created your first page in Rails. Although it’s not much now, you now have a basic understanding of how to create a basic rails application.

A Note

Ruby on Rails has some paradigms that it follows. For example, normally, when you are building an application in rails, when you generate a controller, you capitalize it and make it singular. Although we didn’t capitalize the current controller we are working with, it is a good habit to get into when you are building real applications. I remember when I was learning Rails for the first time, it frustrated me that all of the tutorials I read, mentioned a paradigm here and there, but never listed all of them in one place. I don’t want to do the same to you! But, if I explained them all now, it wouldn’t sink in as well, as if you knew more about each component. So don’t worry about it too much now, and I’ll explain it later in this series.

Adding Interactivity

Review

Last week, we learned how to embed rails code into an rhtml file. If you remember, a <% -%> is processed code, but doesn’t include anything that will actually be outputted to the user. On the other hand, <%= %> code will be outputted.

Math Time

You can do math easily with ruby. For this example, I created a new action in the learn controller called math. We are going to do some simple math which will be embedded in tags above. Here is what we will type:

<html>
  <head>
  <title>Math Demo</title>
  </head>
<body>
  Will it output 4 +5, or 9?<br /&gt
  <%= 4 +5 %>
  </body>
  </html>

As you can see, it did the math for us:

String Concatenation

You can create a string in ruby by using quotes. You can even combine strings together by concatenating them together. There are several ways to do this. The most logical, is to treat it like math:

<html>
  <head>
  <title>String Demo</title>
  </head>
<body>

  <%= 'This is kind of boring' %><br>
  <%= 'Will I combine' + 'With You?' %>
  </body>
  </html>

When we output this we show how exact ruby is though. Notice there is no space between combine and with. To add a space just add one before the quote at the end of combine or before with.

How Important is the = and – sign?

They are both very important. I mention this again, so you clearly get their purpose. The equal sign determines if the user sees it or not. If we were to revisit that last bit of code and take out the equal sign from both of the snippets, we would just have a blank page. Now, if you are assigning a variable or something that doesn’t physically output anything, then don’t put the = sign,

The – sign is not necessary, but a good habit to get into. If you’re not using the = sign, then put a – sign, when you’re closing the embedded ruby. This eliminates the white space that would otherwise be inserted into the code. This can, in very rare cases, mess up the project.

Variables

We cannot go any further without discussing variables. For those that have no experience with Javascript, or any server side language, you might not know what exactly a variable is. Think of a variable as something that stores a little bit of information. You can then analyze this data and manipulate it by calling it by its name.

Assigning A Local Variable and Displaying It

Assigning a local variable is quite easy. Here is how you would assign it and then display it. You could do this in one line, but I’m showing the difference between embedded processed ruby and embedded and shown ruby (The equal sign thing again ):

<html>
  <head>
  <title>Variable Demo</title>
</head>
<body>

  <% text = 'This is a Variable' -%>
  <i><%= text %></i>
  </body>
  </html>

And here you can see the result:

Assigning An Instance Variable and Displaying It

The problem with local variables, though, is that they’re…local. What if we need to assign a variable in the controller, and display it in the view? That’s where instance variables come in. An instance variable is set apart from a local variable by the @ sign which is put before the name. Please note that both instance and local variables (as well as most other kinds) cannot have capital letters and no spaces.

To demonstrate how we can pass dynamic content between the controller and view, we will first have to insert code into the learn controller. By now I have added more definitions for all of the above demos. Here is the current learn controller. As you can see, I have assigned an instance variable in the variables action. When the user requests that action, Rails looks up the definition, processes it, and sends it to the view (In this case, the value of the variable):

class LearnController < ApplicationController

	def more
	end

	def math
	end

	def strings
	end

	def variables
		@text = 'Why Hello'
	end

end

Now we’re going to reference the variable in the view:

<html>
  <head>
  <title>Variable Demo</title>
</head>
<body>
      <i><%= @text %></i>
  </body>
  </html>

Sure enough, the variable is passed to the view.

Next Week and Final Words

This week we learned about setting up actions in controllers, defining views, local, and instant variables. I hope that you found it all helpful! Next week, will be even more exciting. I plan on finishing up the basics of the interaction of the controller and view. Hopefully we will also have time to learn more rails techniques too! After that, it just gets more exciting! (Ruby syntax, working with databases, scaffoldings, etc.). Anyway, if you have any questions, be sure to let me know; and I’ll be sure to get back to you!

Like always, please Digg this if it helped you!

• Subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

I’ve heard a lot of web developers that know other languages, usually ASP or PHP, that want to learn Ruby on Rails, but just don’t know where to get started. From personal experience, I know it is very different from PHP. Personally, I learned Ruby on Rails less than a year ago, and have had few to no problems with it so far. If you haven’t already, I highly recommend hopping on board with the up and coming web framework, Ruby on Rails!

Mission Statement

In this series of tutorials, I hope to take you from knowing nothing about Ruby on Rails (if that’s true), to being able to write fully featured web applications in it. I remember what it was like to learn it. I couldn’t find any series of tutorials that took you through all of the essentials in plain English and in an order that was benefiticial to me, the learner. Although there are very good resources out there, they need to be combined with others as well. At the bottom of this tutorial, I’m also going to list resources that I have found useful in the past as well.

This series will be similar to the PHP from scratch series, but with Ruby on Rails.There will be one published every week, gradually getting more advanced.

This Tutorial

I warn you, this first tutorial might be a little dry, but it’s necessary for learning RoR (let’s just call it that from now on!). This week, we’re going to cover setting up the framework and web server as well as how the framework works. We’re going to set the necessary foundation for learning RoR. This is where many web developers that want to learn RoR fail.I promise we will be doing much much more exciting things next time!

What is Ruby?

Ruby is the language that the framework rails extends. It is very object orientated. It’s syntax is inspired by Perl’s, and therefore is very similar. It is also similar to Python, Lisp, Dylan, and CLU. To quote Wikipedia:

 "Ruby was conceived on February 24, 1993 by Yukihiro Matsumoto who wished to create a new language that balanced functional programming with imperative programming.According to Matsumoto he ‘wanted a scripting language that was more powerful than Perl, and more object-oriented than Python.That’s why I decided to design my own language’. "

It was most popular in Japan, that is until the framework Rails came out. Ever since, it has continued to grow at a phenomenal rate everywhere.

What is Rails?

Rails is the famous framework that works off of ruby. It’s user base is constantly growing. Developed by David Heinemeier Hansson of 37signals for basecamp, it was released as open source in July 2004. It uses MVC (Model – View – Controller ) architecture. If you want a brush up on MVC, be sure to check out the MVC tutorial. The latest release is 2.1.0. There were some significant changes in the v2. This includes the famous scaffolding feature of v1. It’s changed a little bit in version 2.

Concepts of Ruby on Rails

Ruby on Rails follows several principles to help keep it’s code sleek and clean. You should try to live by these principles while you’re working with RoR to get the most of it. For one, it follows the Agile programming term of DRY (Don’t repeat yourself). Obviously, this means that you only write your code once in a certain consistent place. For example, if you need the code to do a certain thing, then you’ll put it in a certain place every time.

The second concept that RoR follows is CoC (Conventions over Configuration).This pretty much means that ruby assumes a lot, and explains most of the automatic defaults you’ll see ruby generate for us. Instead of you always having to configure everything, in every single project, ruby does it for you automatically.Then, if you want to do something that’s unconventional, you simply override the sensible defaults that RoR already has in place.This generally leads to less code having to be written.

Advantages of Learning Ruby on Rails:

• It is pretty easy to learn compared to other languages
• Completely Object Orientated
• MVC Architecture
• You don’t have to write as much code
• Very extendible
• Open Source
• The community is extremely helpful in answering questions
• Despite being a relatively new framework, it is pretty fully featured, and has very few bugs.

Disadvantages of Ruby:

• Processed different, so the code can be a little bit slower on servers that aren’t really built to handle ruby code

I’ve only heard this claim, but more and more servers are becoming better equipped for Rails as it continues to grow anyway so it’s becoming less and less of a problem.

A Ruby File

A ruby file has the extension of .rb. These files will usually contain no HTML. This is an excerpt of a ruby file (specifically a controller) from a game engine I recently made. As you might be able to see. It pulls data from a database, and lists games according to the variables category and title:

class GameController < ApplicationController

	def game_list		@title = '3'		@category = 'Action'		@games = Game.find(:all, 		:conditions => ["title LIKE ? AND category = ?", '%' + title + '%', category],	  rder => 'title, category ASC',		:limit => 5,  ffset => 0)	end

end

An embedded Ruby File

Like many other web languages, Rails allows you to embed ruby with HTML. Seki Masatoshi wrote a program called ERb, embedded ruby, which scans all .rhtml files (embedded ruby files), until it comes across either <% Ruby Code that is only processed -%> or <%= Ruby Code that is then outputted %>. It then processes the ruby code and fills in the blank if neccesary.

Here is an example of Embedded Ruby:

<% title = "Nettuts" %><% header_text = "Ruby on Rails Tutorial" %><html><head><title><%= title %></title></head><body><h2><%= header_text %></h2><p>This is an example of a .rhtml page. </p></body></html>

This is how the user will get it:

<html>
  <head>
  <title> Nettuts </title>
  </head>
  <body>
  <h2>Ruby on Rails Tutorial</h2>
  <p>This is an example of a .rhtml page. </p>
  </body>
  </html> 

Installing Ruby on Rails For Windows

Windows and OSX users are both very lucky. Both operating systems get an all-in-one installer/manager program that installs ruby, rails, and the server.For windows, you have the option of Instant Rails. Go to http://instantrails.rubyforge.org/wiki/wiki.pl to download it. I personally have used this, and have had no major problems with it.Trust me, it is much easier to do this, then install everything separately.

Click download to get instantrails.

When you click download, you will be redirected to rubyforge.org. There you can choose the latest version. At the time of this writing, 2.0 was the latest. Also at the time of this writing, a lot of popular hosts that supported ruby, only supported 1.8.x version. There are considerable differences between version 1 and 2. So it’s up to you which version you’d like to install. In this tutorial I’ll download version 2.0.

Now that it’s downloaded, extract it to a directory that contains no spaces.

Installing Ruby on Rails For Other OS’s

OSX also has the good fortune of having an all in one Ruby on Rails manager, locomotive. For OSX, and other Operating Systems, you can find a very good resource at Ruby on Rail’s wiki.

Getting Started with the Framework

From now on, I’m going to be using Instant Rails. It isn’t very different from any other set up so if you’re using another technique you should still be able to follow along easily. If you run into any problems, be sure to let me know in the comments and/or check out the resources.

So now that you have all of the files needed in place for your setup. Start it up! For windows, go to the directory you put Instant Rails, and run InstantRails.exe . You probably will get this message, but for your directory, which you can press ‘yes’ for:

Now that Instant Rails is running, you can do several things. Right now, you only need to able to:

- Open a console window

-Create a new project.

- Start the server for a current project

We’ll go through each action separately.

Open up a console window

1) Click on the upper left icon:

2) Go to "Rails Applications" > "Open Ruby Console Window"

3) We now have a console window open. Here you can do many things in ruby like generating new projects, controllers, and other tasks that we’ll cover later. Now we’re going to use this Console Window to create a new application.

Creating A New Application

1) Now we’re going to type in "rails nettuts", where nettuts is the name of your application. Choose the name carefully, as you’ll be using it for the rest of the application. Since we’re not really doing anything particular yet, we’ll just choose nettuts as our name:

2) It will now generate all of the necessary files for the application. These are the files that the framework uses and needs. It will help provide the CoC (Conventions over Configuration).

3)We now have a Ruby on Rails application generated!

Running an Application

1) To run our application, we need to go to Instant Rails and click on the icon again:

2) Then we’ll go to "Rails Applications" > "Manage Rails Applications…"

2) You can see Instant Rails ships with two projets already. The cookbook is a pretty neat demo of what you can do easily with Rails. I highly encourage you to check it out. And then after you learn a little bit more about Rails check out the source code. You’ll be surprised at the simplicity! Anyway, check the box next to nettuts, and click "Start with Mongrel" . Your firewall might object, but allow it. A console window should pop-up with the port number and other useful information:

So in my case (and probably in yours too), we can view our application at port 3000. So just navigate to 127.0.0.1:3000, and you should get this default Rails page (plus the sidebar to the right):

We can now start building our application!

How the Framework Works

MVC Architecture

Rails runs off of MVC Architecture. Basically that means we break up our code into three sections; the model, the view, and the controller. If you’d like to learn more about MVC Architecture be sure to visit the Nettuts MVC introduction tutorial. In this intro to Ruby on Rails, we’ll only cover the basics of the controller:

The Controller

The controller will be the path after the main url. For example, if we have a controller that is named "learn", it would represent yoursite.com/learn or locally 127.0.0.1:3000/learn . Each controller relies on many specific files, therefore to create a controller, you need to generate it via the console. We’re now going to create a new controller, learn:

1) First, we open up a console window via Instant Rails, or which ever setup you’re using.

2)Next we navigate to the current application. Since we are currently one level above our application, we type in "cd nettuts" (change directory to nettuts).

3)Now that we’re in the application, we need to access a script that will generate the controller. If you examine the file structure of the app, you’ll notice that there’s a script folder. And inside the script folder, there is a generate file. We need to target that, and run it.

4) We’ll target it via the console. Notice the other scripts as well, they all have their purpose. Anyway, in windows type in "ruby script/generate controller learn" to generate a controller called learn. If I remember right, you don’t need the ruby in other Operating Systems. The console will now generate some files. Check these out in an explore window if you want. The two most important files here are the controller learn, which was just one of several files created; but notice also that a view called learn was also created. These are the sensible defaults that rails comes with to limit the amount of work involved.

So how does a controller work?

Well let’s take it step by step.

-User requests yoursite.com/learn

-Rails automatically looks in the servers directory for app/learn_controller

-Rails scans the .rb file for an index file’s definition

-Rails does what the definition tells it to do, and eventually creates or redirects to a view.

-This view (learn), is then sent back to the user.

Don’t worry if this isn’t quite making sense. Next tutorial we will go in more depth into controllers. For right now, just be familiar with how to create a controller, and that they exist.

Resources

• 

  Lynda.com : Ruby on Rails Essential Training

  Ruby on Rails aims to make building web applications simpler. In Ruby on Rails Essential Training, expert instructor Kevin Skoglund focuses on the same goal. Kevin explains the complete process–from understanding the fundamental concepts behind any Ruby on Rails project to creating full-featured, easy-to-maintain applications using the Ruby on Rails framework.

  Visit Article

• 

  Tutorial’s Point Ruby on Rails Series

  This is an incredible series of Ruby on Rails tutorial, which covers a lot, but it’s sometimes hard to follow.

  Visit Article

• 

  Ruby on Rails

  This is Rail’s official site. If you want to get excited about Rails, go here! Here you can download the newest version, get the latest news, and find some other resources for learning Rails.

  Visit Article

• 

  Rails Wiki

  This is another great resource. Once you become the next Rails ninja, you might even be compelled to edit some of the information here!

  Visit Article

Be sure to check out as many of these resources before the next tutorial.

Next Week and Final Words

Well, I hope you were able to survive through all of that information. Trust me, you’ll be glad you did. Be sure you get the overall grasp of this tutorial. As we go on, most of your questions will be answered, and you will start feeling more "enlightened", on what Rails is. And I promise next week will be more fun! Next week we will cover a little bit more of the framework, and start getting into ruby syntax, and a little more of what you can do with rails. If this tutorial helped you, please Digg it!

• Subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.