At the Forge - Ruby on Rails
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.
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.
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:
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
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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Humble Hacker?
- The US Government and Open-Source Software
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide