Introduction
As I write this new introduction in the spring of 2010, the official release of Rails 3.0 is looming, and what a big change it represents. The “Merb-ification” of Rails is almost complete! The new Rails is quite different from its predecessors in that its underlying architecture is more modular and elegant while increasing sheer performance significantly. The changes to Active Record are dramatic, with Arel’s query method chaining replacing hashed find parameters that we were all used to.
There is a lot to love about Rails 3, and I do think that eventually most of the community will make the change. In most cases, I have not bothered to cover 2.x ways of doing things in Rails if they are significantly different from the Rails 3 way—hence the title change. I felt that naming the book “The Rails Way (Second Edition)” would be accurate, but possibly misleading. This new edition is a fully new book for a fully new framework. Practically every line of the book has been painstakingly revised and edited, with some fairly large chunks of the original book not making the new cut. It’s taken well over a year, including six months of working every night to get this book done!
Even though Rails 3 is less opinionated than early versions, in that it allows for easy reconfiguration of Rails assumptions, this book is more opinionated than ever. The vast majority of Rails developers use RSpec, and I believe that is primarily because it is a superior choice to Test::Unit. Therefore, this book does not cover Test::Unit. I firmly believe that Haml is vastly, profoundly, better than ERb for view templating, so the book uses Haml exclusively.
0.1 About This Book
This book is not a tutorial or basic introduction to Ruby or Rails. It is meant as a day-to-day reference for the full-time Rails developer. The more confident reader might be able to get started in Rails using just this book, extensive online resources, and his or her wits, but there are other publications that are more introductory in nature and might be a wee bit more appropriate for beginners.
Every contributor to this book works with Rails on a full-time basis. We do not spend our days writing books or training other people, although that is certainly something that we enjoy doing on the side.
This book was originally conceived for myself, because I hate having to use online documentation, especially API docs, which need to be consulted over and over again. Since the API documentation is liberally licensed (just like the rest of Rails), there are a few sections of the book that reproduce parts of the API documentation. In practically all cases, the API documentation has been expanded and/or corrected, supplemented with additional examples and commentary drawn from practical experience.
Hopefully you are like me—I really like books that I can keep next to my keyboard, scribble notes in, and fill with bookmarks and dog-ears. When I’m coding, I want to be able to quickly refer to both API documentation, in-depth explanations, and relevant examples.
0.1.1 Book Structure
I attempted to give the material a natural structure while meeting the goal of being the best-possible Rails reference book. To that end, careful attention has been given to presenting holistic explanations of each subsystem of Rails, including detailed API information where appropriate. Every chapter is slightly different in scope, and I suspect that Rails is now too big a topic to cover the whole thing in depth in just one book.
Believe me, it has not been easy coming up with a structure that makes perfect sense for everyone. Particularly, I have noted surprise in some readers when they notice that Active Record is not covered first. Rails is foremost a web framework and, at least to me, the controller and routing implementation is the most unique, powerful, and effective feature, with Active Record following a close second.
0.1.2 Sample Code and Listings
The domains chosen for the code samples should be familiar to almost all professional developers. They include time and expense tracking, auctions, regional data management, and blogging applications. I don’t spend pages explaining the subtler nuances of the business logic for the samples or justify design decisions that don’t have a direct relationship to the topic at hand. Following in the footsteps of my series colleague Hal Fulton and The Ruby Way, most of the snippets are not full code listings—only the relevant code is shown. Ellipses (...) denote parts of the code that have been eliminated for clarity.
Whenever a code listing is large and significant, and I suspect that you might want to use it verbatim in your own code, I supply a listing heading. There are not too many of those. The whole set of code listings will not add up to a complete working system, nor are there 30 pages of sample application code in an appendix. The code listings should serve as inspiration for your production-ready work, but keep in mind that they often lack touches necessary in real-world work. For example, examples of controller code are often missing pagination and access control logic, because it would detract from the point being expressed.
Some of the source code for my examples can be found at http://github.com/obie/tr3w_time_and_expenses. Note that it is not a working nor complete application. It just made sense at times to keep the code in the context of an application and hopefully you might draw some inspiration from browsing it.
0.1.3 Concerning Third-Party RubyGems and Plugins
Whenever you find yourself writing code that feels like plumbing, by which I mean completely unrelated to the business domain of your application, you’re probably doing too much work. I hope that you have this book at your side when you encounter that feeling. There is almost always some new part of the Rails API or a third-party RubyGem for doing exactly what you are trying to do.
As a matter of fact, part of what sets this book apart is that I never hesitate in calling out the availability of third-party code, and I even document the RubyGems and plugins that I feel are most crucial for effective Rails work. In cases where third-party code is better than the built-in Rails functionality, we don’t cover the built-in Rails functionality (pagination is a good example).
An average developer might see his or her productivity double with Rails, but I’ve seen serious Rails developers achieve gains that are much, much higher. That’s because we follow the Don’t Repeat Yourself (DRY) principle religiously, of which Don’t Reinvent The Wheel (DRTW) is a close corollary. Reimplementing something when an existing implementation is good enough is an unnecessary waste of time that nevertheless can be very tempting, since it’s such a joy to program in Ruby.
Ruby on Rails is actually a vast ecosystem of core code, official plugins, and third-party plugins. That ecosystem has been exploding rapidly and provides all the raw technology you need to build even the most complicated enterprise-class web applications. My goal is to equip you with enough knowledge that you’ll be able to avoid continuously reinventing the wheel.
0.2 Recommended Reading and Resources
Readers may find it useful to read this book while referring to some of the excellent reference titles listed in this section.
Most Ruby programmers always have their copy of the “Pickaxe” book nearby, Programming Ruby (ISBN: 0-9745140-5-5), because it is a good language reference. Readers interested in really understanding all of the nuances of Ruby programming should acquire The Ruby Way, Second Edition (ISBN: 0-6723288-4-4).
I highly recommend Peepcode Screencasts, in-depth video presentations on a variety of Rails subjects by the inimitable Geoffrey Grosenbach, available at http://peepcode.com
Ryan Bates does an excellent job explaining nuances of Rails development in his long-running series of free webcasts available at http://railscasts.com/
Last, but not least, this book’s companion website at http://tr3w.com is the first place to look for reporting issues and finding additional resources, as they become available.
Regarding David Heinemeier Hansson, a.k.a. DHH
I had the pleasure of establishing a friendship with David Heinemeier Hansson, creator of Rails, in early 2005, before Rails hit the mainstream and he became an International Web 2.0 Superstar. My friendship with David is a big factor in why I’m writing this book today. David’s opinions and public statements shape the Rails world, which means he gets quoted a lot when we discuss the nature of Rails and how to use it effectively.
David has told me on a couple of occasions that he hates the “DHH” moniker that people tend to use instead of his long and difficult-to-spell full name. For that reason, in this book I try to always refer to him as “David” instead of the ever-tempting “DHH.” When you encounter references to “David” without further qualification, I’m referring to the one-and-only David Heinemeier Hansson.
There are a number of notable people from the Rails world that are also referred to on a first-name basis in this book. Those include:
• YehudaKatz
• JamisBuck
• XavierNoria
0.3 Goals
As already stated, I hope to make this your primary working reference for Ruby on Rails. I don’t really expect too many people to read it through end to end unless they’re expanding their basic knowledge of the Rails framework. Whatever the case may be, over time I hope this book gives you as an application developer/programmer greater confidence in making design and implementation decisions while working on your day-to-day tasks. After spending time with this book, your understanding of the fundamental concepts of Rails coupled with hands-on experience should leave you feeling comfortable working on real-world Rails projects, with real-world demands.
If you are in an architectural or development lead role, this book is not targeted to you, but should make you feel more comfortable discussing the pros and cons of Ruby on Rails adoption and ways to extend Rails to meet the particular needs of the project under your direction.
Finally, if you are a development manager, you should find the practical perspective of the book and our coverage of testing and tools especially interesting, and hopefully get some insight into why your developers are so excited about Ruby and Rails.
0.4 Prerequisites
The reader is assumed to have the following knowledge:
• Basic Ruby syntax and language constructs such as blocks
• Solid grasp of object-oriented principles and design patterns
• Basic understanding of relational databases and SQL
• Familiarity with how Rails applications are laid out and function
• Basic understanding of network protocols such as HTTP and SMTP
• Basic understanding of XML documents and web services
• Familiarity with transactional concepts such as ACID properties
As noted in the section “Book Structure,” this book does not progress from easy material in the front to harder material in the back. Some chapters do start out with fundamental, almost introductory material and push on to more advanced coverage. There are definitely sections of the text that experienced Rails developer will gloss over. However, I believe that there is new knowledge and inspiration in every chapter, for all skill levels.