Learning Rails: Live Edition

If You Have Problems Making Examples Work

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:

What version of Ruby are you running?

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 environment.

What version of Rails are you running?

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.)

Are you calling the program the right way?

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.

Is the database connected?

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.

Are all of the pieces there?

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.

Is everything named 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 @ or symbols with :. These special characters make a big difference, so make sure they’re correct.

Is the Ruby syntax right?

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.

Are you running the right program?

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 rails command.

Did the authors just plain screw up?

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.