At the Forge - Ruby on Rails

Explore a Web development framework that comes with its own Web server, magically keeps track of details for you and integrates new code without restarting.

Ruby, an interpreted programming language that looks and feels like a
cross between Smalltalk and Perl, has been around for about ten years.
Ruby has been gaining in popularity over the last few years, partly
because of the release of English-language books and documentation. In
addition, programmers have become more interested in finding an
alternative to Perl and Python for their general-purpose programming
needs.

Ruby's popularity might have continued to grow slowly were it not for
Ruby on Rails, a Web development framework that has become the focus
of enormous attention. Everyone in the Web development world seems to
be talking about Rails; magazine articles, blog postings, conference
tracks and even some new books all are dedicated to Rails. Rails is
supposed to be elegant, easy to use and easy to modify. Even developers
with no previous Ruby experience are switching to Rails.

Does Rails live up to the hype surrounding it? To a large degree, I
believe the answer is “yes”—it has a relatively shallow
learning curve, it connects easily and quickly to
relational databases and it makes the creation of many
small- and medium-sized sites faster and easier than I
would have expected. But, of course, no framework is
perfect, particularly one that was released publicly
only one year ago. It remains to be seen if Rails
can hold up against more established technologies on
several different fronts.

This month, we begin to look at several aspects of Ruby on Rails,
so you can decide for yourself if my assessment is accurate. We
begin by installing and configuring a basic Rails application.
Over the next few installments of At the Forge, we will extend our
application in several different ways, considering the ways in which
Rails allows us to create and modify our applications.

Installing Rails

The first step in creating a Rails application is to install Ruby and
then Rails itself. Most modern Linux distributions come with Ruby,
although only the latest released version as of this writing (1.8.2)
works with the most recent version of Rails (0.12.1). New versions of
Rails have been coming out frequently, which means that one or both of
these versions might have changed by the time you read this.

Assuming you have installed Ruby, you next need to
install Gems. It provides access to the Ruby Gems library, which is
something of a cross between SourceForge and Perl's CPAN (see the on-line Resources).
Download and unpack the most recent .tar.gz file:

tar -zxvf rubygems-0.8.10.tar.gz

Enter the directory as the root user and type:

ruby setup.rb all

This installs the entire Gems package. Among other things, this
installs the gem program in /usr/bin. You then can install Rails,
which is distributed via Gems, with the following command:

gem install --remote rails

As with such systems as CPAN and Debian's apt, the gem program is
smart enough to identify and download any dependencies it might
encounter. By default, you need to explicitly answer “y” when asked
if you are interested in installing any dependencies. Because Rails
depends on a number of other packages, you should be sure to answer
“y” when prompted.

When you are returned to the shell prompt, you can assume that Rails
has been installed. However, this is not quite enough.
If you are
interested in working with a relational database, you also need
to install a database interface library. Because I work with
PostgreSQL, I installed the pure Ruby client, called postgres-pr:

gem install --remote postgres-pr

Somewhat confusingly, there also is a set of PostgreSQL client
libraries (called postgresql) that can be used with Ruby. However,
it seems as though most Rails developers are working with the postgres-pr
library, at least for now.

Creating an Application

Once Rails is installed, we can create a simple “Hello,
world” program. To do this, we use the
rails command, which is
installed in /usr/bin/ by default. Because our example application is
a Weblog, we call the application blog. For reference, the name
of the application doesn't have to be linked to the name of the URL
under which it will appear. Type:

rails blog

Running this produces a fair amount of output, listing the files that
have been created on our filesystem. When we give only a single name, blog,
the application is created inside of a directory with that name. We can
keep all of our applications inside of a single container directory,
such as ~/Rails, with:

mkdir ~/Rails
rails ~/Rails/blog

If we look inside of the newly created application directory, we
see a number of directories and files. The script directory
contains administrative programs, written in Ruby, of course. The
public directory contains static HTML files, as well as images,
stylesheets, JavaScript code and templates that you may use in your
application.

The directory you are mostly likely to work with is app,
which contains the application itself. The app directory contains
subdirectories named models, views and controllers. This design
reflects the fact that Rails uses the MVC (model/view/controller)
style widely used in many modern desktop and Web applications.

In an MVC architecture, we divide our work into three
parts—the controller, which acts like a switchboard, invoking the
appropriate model and view; the model, which contains the data and
some of the logic; and the view, which displays information to the
user. If you have ever built a database-backed site with PHP and
Smarty templates or with Zope and its Page Templates or even with Java
and JavaServer Pages (JSPs), you already are familiar with at least
some of these ideas. Rails simply makes them more explicit with its
prenamed directory structure.

Although it can't do much, we now can start our empty Rails application
with:

cd ~/Rails/blog
ruby script/server

This starts the WEBrick HTTP server on port 3000. To access this
fairly empty Rails site, we point our browsers to an
appropriate IP address or hostname. In my particular case, I started
Rails on my test server, whose IP address is 192.168.2.3. I thus
point my Web browser to http://192.168.2.3:3000/. And sure enough, there
I see a “Welcome on board” message, indicating I
have set up Rails correctly.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.