Did you notice how little Ruby you had to know in order to develop cool Rails web apps? Even so, knowing a bit more Ruby can sometimes be useful. Here are some sample bits of Ruby you might want to experiment with. Just type them in and see what happens...

a=File.readlines("filename.txt")

"=" * 50

a.sort

"to be or not to be".split

"Bass ackwards".reverse!

o.class

"Bass ackwards".reverse

(3.14).round

/Waldo/ =~ s

Math.sqrt(16)

/^d{5}$/ =~ "90210"

File.delete("filename.txt")

"12345".to_i

Time.now

"3.1415".to_f

Time.now.year

a.to_s

alias my_method

[1, 2, 3, 4, 5].inspect

Dir.entries("directoryName")

{:a=>1, :b=>"c"}.inspect

Automated testing is one of the most important parts of software development, and yet until now, we haven’t mentioned it. So why not? Testing a piece of software relies on a thorough understanding of the tools you are using, and designing tests can be far more difficult (and enjoyable) than writing the code itself. That’s why this book has concentrated on giving you the skills to understand how Rails works and thinks. Only once you understand that can you start to think about how you will test applications.

But that doesn’t mean that you do testing long after you have finished writing a system. Far from it. The best tests are written before you write your main code.

Rails comes with a ton of testing support, far more than almost any other framework. Every application contains a set of test scripts (in the test directory), and every time you generate scaffolding, Rails also generates a set of standard tests for you. So, if you go into the folder where you wrote the scaffolded tickets application in Chapter 1 and type:

Rails will run a whole suite of tests for you. Does that mean that you never need to write your own? Actually, no. A lot of your time as a Rails developer will be spent writing and maintaining tests.

There are three main types of test:

Your application won’t stay in development all its life, and at some point, you’ll need to send it live. So what do you do then? It’s not a good idea if your application has code in it that specifies the location of the database and so on. After all, you don’t want the live and test versions of the code to do different things. You just want them to use different databases.

That why Rails lets you specify environments. An environment sets the location and type of your database as well as a few other settings, such as how log messages will be recorded.

By default, an application is set up to use three different environments:

But how do you switch between environments?

When you start the server, Rails looks for an environment variable called RAILS_ENV. This will tell it which environment to run. If you want to switch from the development enviroment to the production environment, you need to set the RAILS_ENV variable:

If you look at the config/database.yml file, you will find the database details for each environment.

For example, your original SQLite production environment might be set like this:

But if you wanted to change the production environment to use an Oracle database, it would probably look something like this:

Or, if you want the live environment to use a MySQL database hosted on the same machine as Rails, you would change it to:

We’ve heard a lot in this book about REST. How Rails uses REST. How REST design is the new guiding principle of Rails. How if you use REST, your teeth will be brighter, your life will be happier, and all will be goodness and sunshine with the world.

Let’s start with the basics. REST stands for Representational State Transfer, and it’s a way of structuring how people work with computer systems. Obviously, the most important computer system around is the World Wide Web, and it’s significant that the guy who came up with REST—Roy Fielding—was also one of the authors of the HTTP spec.

So why does it matter that the HTTP guy is also the REST guy? Well, because RESTful design really means designing your applications to work the way the web was originally meant to look.

Imagine there was a web application that allowed somebody to sell spare parts for rockets:

They might create a system that displays a rocket component like this:

http://www.boosters-r-us.com/airframes/472

The web site is about rocket components and this is a URL that can be used as the name of the component.

But look at what happens when someone updates the details of the component, like—say—its price. The web form in the system submits the details to this URL:

http://www.boosters-r-us.com/airframes/472/update

The trouble with this is it’s not RESTful. Why? Well URLs in a RESTful system are supposed to be names of resources. And this second URL doesn’t represent a thing it represents an action.

HTTP verbs are the only verbs you need

But how do we get around this problem? The third principle of REST says that there should a well defined list of actions available. A RESTful application uses HTTP methods to define the activity and leaves the URL to name the resource:

Rails is changing all the time, but how will you stay up with all the latest and greatest features that have been added? One way is to run on the Edge.

Rails make it really easy to run on the very latest build of Rails (called Edge Rails) by downloading and installing the latest version of the framework directly into your application.

Now in some other application frameworks, changing to the latest version of the framework would be incredible difficult. You would have go to a web browser. Download the files. Read the latest install instructions. Play with paths Set up the configuration so that it matches your system. And so on. It would be so complicated that very few people would bother.

But lots of people run on Edge Rails. Why? Well it’s not just because they want to use the latest features. Rails is in furious development all the time, and you may find that even a small upgrade might break some piece of your application. So to make sure that their apps will keep working as Rails evolves, they don’t wait for weeks or months to upgrade, some of them update to the Edge every day.

But how do you install Edge Rails in your application? It’s simple. You do this:

That single command is all you need. The rake tool will connect to the Rails development servers and download the latest version of the rails scripts and install them in the vendor/plugins directory of your application. Every time you start the Rails server, the code in the vendor directory is used before going to the main Rails install on the machine. That means that Edge Rails will be used for that single application.

Life can be pretty hairy on the Edge. But sometimes it’s better to find version compatibility issues, one at a time...

Even though Rails allows you to create fully-functional web applications fast and safely, there’s no doubt that to really master Rails can take a really long time. There’s simply so much of it.

This means you need a pretty good reference. And the best references are online. Rails is changing all the time. Every day new things are checked into the Rails source code, and the only way to keep up with it is to go online. Here are some great web sites to get you started:

ri <something>

gem server

http://localhost:8808/

Of course, here at Head First Labs, we’re book people. And it’s doesn’t matter how great the online material is, there’s nothing to beat having an actual real book with pages and everything to help you absorb the material. Now that you’ve got to the end of this book, and your brain is feeling fit and full of new Ruby on Rails expertise, you might want to take the chance to try out these other tripendicular tomes:

The Ruby Way

We love this book at Head First. It’s a big, meaty work, but it’s beautifully written by Hal Fulton. This is a book that will take you on a deep journey into the Ruby language. The great thing is that it doesn’t just give you the details of the language, but it also explains the philosophy behind the language design. Many of the things that make Rails so great come directly from Ruby. And many of those things are mentioned in this book.

Agile Web Development with Rails

This is a great book to take you further into Rails development. An interesting thing about it is that it is written like a development project. So a few months before a new version is released, a beta version is released online for people to try out and comment on.

Rails Cookbook

Once you get up and running with Rails, you will probably need to solve the same kinds of problems that many, many other people have had to deal with before you. Fear not! Rails Cookbook gives a you a delicious set of pre-written pieces of code to get you through your difficulties.

Now, as well as books on Ruby and Rails, you might find it useful to read up on the related topics. And what’s the best way to bootstrap your brain in a new subject? With Head First books, of course!

Head First Ajax

Rails comes with a ton of built in support for Ajax development, but to really make the most out of it, you need to get to grips with how Ajax really works. And what better way than with Head First Ajax?

Head First JavaScript

Ajax is built on JavaScript, and if you know in detail how to hack JavaScript, you’ll really make your application sing. Head First JavaScript is a great way into the language.

Head First Software Development

In this book, you’ve learned about how to program in the Ruby on Rails framework. If you want to move from programming to development, then pick up this book. It will teach you how the real pros do it, from how to run the planning in your project, to automated testing and continuous integration.

You’ve got Chapter 10 under your belt, and now you’ve added some real world things you need to think about.

We’re sad to see you leave, but there’s nothing like taking what you’ve learned and putting it to use. You’re just beginning your Rails journey, and we’ve put you in the driving seat. We’re dying to hear how things go, so drop us a line at the Head First Labs web site, www.headfirstlabs.com, and let us know how Rails is paying off for YOU!