Rails Cookbook

Preface

I’ve been a full time web developer since 1998, and have worked with just about every popular web scripting language over the years. During the dot-com boom, I kept busy in web consulting shops, trying to turn various entrepreneurial ideas into profitable web businesses. The boom was a very interesting time; the collective excitement over some of the first popular web applications was infectious. I wrote a lot of code during that time, some of which was a mess, but it was fun, and it was an introduction to a career that I enjoy tremendously.

When the dot-com bubble crashed, the tone of the industry changed dramatically. Web work dried up drastically, and the overall enthusiasm of the industry seemed to sink into recession along with the industry’s economy. I managed to chain together various web programming gigs, but the work was not as interesting as it had been when people had more money to experiment with new ideas.

In 2004, I landed a job as the webmaster at Industrial Light and Magic. At ILM, I worked mostly with Perl and Java, but this was also where I was introduced to Python. Toward the end of my time at ILM, I began to hear about Ruby and a lot of the buzz on the Net about it versus Python—both being very capable and lightweight dynamic languages. While at ILM, I was immersed in the excitement of the visual effects industry and managed to wait out the bad economy until finally landing a software engineering position at O’Reilly Media. It was at O’Reilly that I first found out about Rails.

Around the time I started at O’Reilly, something very significant happened: Google released Google Maps. The economy had been slowly recovering, but it was the release of this one web application that re-ignited my excitement about web applications and their development. What was so interesting about Google Maps was that it wasn’t using any new technology. It was just an incredibly creative use of technologies that had been around for years.

Being able to drag a map around seemed to shatter all previous assumptions about the limitations of web software. After seeing this application, and a number of others that were cropping up at the time, my view of the potential of the Web, as well as my enthusiasm in developing it, was reborn. Now, if I could just have the same feeling about the tools I was using.

That’s when I discovered Rails and simultaneously, Ruby. For me, discovering and learning Rails had a similar effect to Google Maps; it seemed almost too good to be true. Rails handled all of the things that I found most unpleasant about web development automatically or so elegantly that they were no longer painful. The next thing I noticed was how easily new projects were organized according to the MVC design pattern.

I had worked on many MVC projects before, but often they were home-grown and not easily reusable. In some cases, the amount of setup involved made the benefits of using MVC questionable, especially for smaller projects. I’ve often said that the simple act of creating a Rails project felt like there was a room full of experienced software veterans imparting their knowledge about sound application design, ensuring that my project started off in the right direction.

I soon realized that nothing about the Rails framework or the best practices encouraged by the Rails community was particularly new. In fact, most of the techniques and methodologies involved have been around for years. What I found special about Rails was that all of these things had come together, in sort of a perfect storm of best practices. The result was a framework that made web development both enjoyable and rewarding.

With a number of Rails projects behind me, I started doing talks on Rails to various groups around where I live. It was at a local Linux user’s group that I was approached by Mike Hendrickson (the executive editor at O’Reilly) about writing a Rails book. Mike Hendrickson then introduced me to my editor, Mike Loukides, and we decided that I should write the Rails Cookbook. That was the beginning of a long process that has finally resulted in the book you’re now reading.

I like to think of Rails as a successful refactoring of the process of web development that just keeps getting better with time. It is my hope that this book will help you to discover much more about this truly amazing framework.

Who This Book Is For

In preparation for writing this book, I tried to collect a lot of data about what the Rails community needed most in a cookbook. To do this I collected data from the Rails mailing lists as well as from the most active IRC channels. I wasn’t very scientific about how I processed the data, but I did get a feel for what were many of the most commonly asked questions. Based on this, I created an initial outline, and then ran it past as many people as I could find, who reviewed and further edited it.

The outline has evolved since I first presented it to my editor, but it still targets the needs of the bulk of the Rails community. The target reader for this book is someone with web development experience, but perhaps new to Rails, or an intermediate Rails developer.

That said, I believe that much of the information I present is going to be valuable across the board; for example, Rails application deployment is a universal problem that all Rails developers need to solve. In the end, I hope that everyone who reads this book will find it significantly useful.

Other Resources

Web Sites

The key web sites for finding out about Ruby and Rails are http://www.rubyonrails.org, http://www.ruby-lang.org, and http://www.rubygarden.org. But these web sites are far from the whole story. Perhaps more then any other technology, Rails is driven by bloggers. Instead of providing an inevitably incomplete list of Rails blogs, I suggest that you start by reading the main Rails blog (http://weblog.rubyonrails.org) and discover other blogs that it links to.

Books

There are many excellent books on Ruby and Rails with more being added all the time. Here are some that I recommend:

• Ruby for Rails by David A. Black (Manning)

• Programming Ruby by Dave Thomas, et al. (Pragmatic Bookshelf)

• Agile Web Development with Rails by Dave Thomas, et al. (Pragmatic Bookshelf)

• Rails Recipes by Chad Fowler (Pragmatic Bookshelf)

• The Ruby Way by Hal Fulton (Addison-Wesley Professional)

• Ruby on Rails: Up and Running by Bruce A. Tate and Curt Hibbs (O’Reilly)

• Mongrel: Serving, Deploying, and Extending Your Ruby Applications (PDF Shortcut) by Matt Pelletier and Zed Shaw (Addison-Wesley Professional)

Conventions Used in This Book

Unless otherwise noted, the recipes in this book have been created for the release candidate of Rails version 1.2. The final version of Rails 1.2 should be available by the time you have this book. A few recipes require Edge Rails. Installing Edge Rails is covered in Installing and Running Edge Rails.” All recipes assume that you’re using Ruby 1.8.4.

Some code samples have filenames mentioned before the code; the files that accompany the code can be found on the book’s web page at http://www.oreilly.com/catalog/9780596527310.

Font Conventions

The following typographic conventions are used in this book:

Italic

Used for file and directory names, email addresses, and URLs, as well as for new terms where they are defined.

Constant width

Used for code listings and for keywords, variables, functions, command options, database names, parameters, class names, and HTML tags where they appear in the text.

Constant width bold

Used to mark lines of output in code listings and command lines to be typed by the user.

Constant width italic

Used as a general placeholder to indicate items that should be replaced by actual values in your own programs.

Tip

This icon signifies a tip, suggestion, or general note.

Caution

This icon indicates a warning or caution.

Using Code Examples

This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Rails Cookbook by Rob Orsini. Copyright 2007 O’Reilly Media, Inc., 978-0-596-52731-0.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [e-mail].

Safari® Enabled

Note

When you see a Safari® Enabled icon on the cover of your favorite technology book, that means the book is available online through the O’Reilly Network Safari Bookshelf.

Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.

Comments and Questions

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (in the United States or Canada)

707-829-0515 (international/local)

707-829-0104 (fax)

We have a web page for this book where we list errata, examples, or any additional information. You can access this page at:

http://www.oreilly.com/catalog/9780596527310

To comment or ask technical questions about this book, send email to:

[e-mail]

For more information about books, conferences, Resource Centers, and the O’Reilly Network, see the O’Reilly web site at:

http://www.oreilly.com

Acknowledgments

It goes without saying that writing a book is an enormous amount of work—this was definitely true in my case. Thankfully, I received a lot of help from a very talented group of people and I would like to acknowledge them.

The book’s biggest contributor, aside from myself, has been Mike Loukides. Mike’s input was invaluable, whether he was refactoring a confusing paragraph or offering an insight about an idea I hadn’t thought to include, he was there helping every step of the way. The great thing about working with Mike is that he respected my goals for the project and ultimately gave me complete creative freedom over the project. I look forward to our continued friendship and being able to talk with him about our shared interest in music without worrying about the conversation being a side-track of something else.

Fifteen people contributed recipes to the book. I’d like to point out the three that helped me the most during the final stages of the process. Diego Scataglini contributed the most recipes (12 total). More importantly, he produced many of these recipes with very short notice as I pushed to fit in more content before the final deadline. Christian Romney and Ryan Waldron also stepped up to the plate in the final stages and helped fill out and clean up much of the book’s content. During the final days, the three of us collaborated in #rorcb (a.k.a. The War Room), where I was able to delegate a huge amount of work to each of them. Their contribution was outstanding but, most importantly, we had a great time in the process. I’m grateful to everyone who contributed recipes. They include Ben Bleything, Blaine Cook, Ryan Daigle, Bill Froelich, Evan Henshaw-Plath, Rick Olson, Matt Ridenour, Dae San Hwang, Andy Shen, Joe Van Dyk, Nicholas Wieland, and Chris Wong.

More special thanks goes to Coda Hale for doing an excellent pass over the book resulting in several emails full of valuable suggestions. Also thanks to Evan Henshaw-Plath (rabble), Zed Shaw, and Geoffrey Grosenbach (topfunky) for putting up with many late night Rails questions and offering sound advice along the way.

The tool that I settled on for collaborating with reviewers was Beast (an excellent Rails forum written by Josh Goebel and Rick Olson). A number of discussions happened there that definitely improved the book several times over. I’m thankful to all who reviewed my content and posted comments. They include Sam Aaron, Anjan Bacchu, Tony Frey, Matt Grayson, Stephan Kamper, Bin Li, Tom Lianza, Thomas Lockney, Matt McKnight, James Moore, Hartmut Prochaska, Andy Shen, Bill Spornitz, Andrew Turner, Scott Walter, and Nicholas Wieland.

During the initial months of writing I switched between several different writing environments. I finally settled on editing directly in DocBook. Once I accumulated a certain amount of content and needed to perform various transformations, I quickly discovered the limits of my knowledge of XML processing. This is where Keith Fahlgren and Andrew Savikas stepped in with just the right XPath expression or XMLMind macro to get the job done, which let me focus on writing.

Writing a book is like nothing I’ve ever done before. Because of that, I’m thankful that I was able to talk with my friends who have written books about the process. Those friends are Kyle Rankin, Andrew Savikas, and Tony Stubblebine.

Finally, I want to thank my wife for helping make this project possible. She essentially became a single parent for quite a bit longer then she bargained for. I am grateful for her support and encouragement.