When you’re starting to use a new framework, error messages can be hard, even impossible, to decipher. We’ve included occasional notes in the book about particular errors you might see, but it seems very normal for different people to encounter different errors as they work through examples. Sometimes it’s the result of skipping a step or entering code just a little differently than it was in the book. It’s probably not the result of a problem in Rails itself, even if the error message seems to come from deep in the framework. That isn’t likely an error in the framework, but much more likely a problem the framework is having in figuring out how to deal with the unexpected code it just encountered.
If you find yourself stuck, here are a few things you should check:
You can check by entering
ruby -v. All of the
examples in this book were written with Ruby 1.8.6. Older versions of Ruby may cause
problems for Rails, and the 1.9 versions add features, but may create new issues as
well. Chapter 1 explores how to install Ruby, but
you may need to find documentation specific to your specific operating system and
You can check by running
rails -v. While you
should be able to use the examples here with any version of Rails
2.x, the examples, including the ones you can download from the
book’s site, were built on Rails 2.1.0. If you’re running a different
version, especially an earlier version, you may encounter problems. (While a few of
the examples here may run on versions of Rails older than 2.0, most of them will
encounter major problems quickly.)
Linux and Mac OS X both use a forward slash,
as a directory separator, whereas Windows uses a backslash,
\. This book uses the forward slash, but if you’re in Windows, you
may need to use the backslash.
By default, Rails expects you to have SQLite up and running, though some installations use MySQL or other databases. If you’re getting errors that have “sql” in them somewhere, it’s probably the database. For simple applications that aren’t calling a database, check the instructions at the end of Chapter 1 for telling Rails not to look for a database. For more complex applications where your application expects a database, check that the database is installed and running, that the settings in database.yml are correct, and that the permissions, if any, are set correctly.
Most of the time, assembling a Rails application, even a simple one, requires modifying multiple files—at least a view and a controller. If you’ve only built a controller, you’re missing a key piece you need to see your results; if you’ve only built a view, you need a controller to call it. As you build more and more complex applications, you’ll need to make sure you’ve considered routing, models, and maybe even configuration and plug-ins. What looks like a simple call in one part of the application may depend on pieces elsewhere.
Eventually, you’ll know what kinds of problems specific missing pieces cause, but at least at first, try to make sure you’ve entered complete examples before running them.
It’s also possible to have files present but with the wrong permissions set. If you know a file is there, but Rails can’t seem to get to it, check to make sure that permissions are set correctly.
Rails depends on naming conventions to establish connections between data and code
without you having to specify them explicitly. This works wonderfully, until you have
a typo somewhere obscure. Rails also relies on a number of Ruby conventions for
variables, prefacing instance variables with
:. These special characters make a big
difference, so make sure they’re correct.
If you get syntax errors, or sometimes even if you get a
nil object error, you may have an extra space, missing bracket, or
similar issue. Ruby syntax is extremely flexible, so you can usually ignore the
discipline of brackets, parentheses, or spaces—but sometimes it really does matter.
Yes, this sounds weird. When you're developing real programs, it makes sense to
leave the server running to check back and forth with your changes. If you're testing
out a lot of small application examples quickly, though, you may have problems.
Definitely leave the server running while you're working within a given example, but
stop it when you change chapters or set off to create a new application with the
Obviously, we’re working hard to ensure that all of the code in this book runs smoothly the first time, but it’s possible that an error crept through. You’ll want to check the errata, described in the next section, and download sample code, which will be updated for errata.
It’s tempting to try Googling errors to find a quick fix. Unfortunately, the issues just described are more likely to be the problem than something else that has clear documentation. The Rails API documentation might be helpful at times, especially if you’re experimenting with extending an example. There shouldn’t be much out there, though, beyond the book example files themselves that you can download to fix an example.