Sam Ruby - Agile Web Development with Rails (4th Edition - final)

When Dave asked me to join as a coauthor of the third edition of this book, I was thrilled. After all, it was from the first printing of the first edition of this book that I had learned Rails. Dave and I also have much in common. Although he prefers Emacs and Mac OS X and my preferences tend toward Vim and Ubuntu, we both share a love for the command line and getting our fingers dirty with codestarting with tangible examples before diving into heavy theory.

Since the time the third edition was published (and, in fact, since the first, second, and third editions), much has changed. Rails is in the process of being significantly refactored, mostly internally. A number of features that were used in previous examples have been initially deprecated and subsequently removed. New features have been added, and much experience has been obtained as to what the best practices are for using Rails. Rails now also works on Ruby 1.9, and each of the examples has been tested with Ruby 1.8.7 and Ruby 1.9.2.

Additionally, Rails has exploded from being a popular framework to an active and vibrant ecosystem, complete with many popular plugins and deep integration into third-party tools. In the process, Rails has become mainstream, attracting a more diverse set of developers to the framework.

This has led to a reorganization of the book. Many newcomers to Rails have not had the pleasure of being introduced to Ruby, so this section has been promoted from an appendix to a chapter in Part I. We follow Part I with a step-by-step walk-through of building a real application, which has been updated and streamlined to focus on current best practices.

But the biggest change is in the final part: because it is no longer practical to cover the entire ecosystem of Rails given both its breadth and rate of change, this part is now focused on providing an overall perspective of the landscape, enabling you, the reader, to know what to look for and where to find plugins and related tools to address common needs that go far beyond what the framework itself contains.

In short, this book needed to adapt. Once again.

Youd think that producing a new edition of a book would be easy. After all, you already have all the text. Its just a tweak to some code here and a minor wording change there, and youre done. Youd think....

Its difficult to tell exactly, but our impression is that creating each edition of Agile Web Development with Rails took about as much effort as the first edition. Rails is constantly evolving and, as it does, so has this book. Parts of the Depot application were rewritten several times, and all of the narrative was updated. The emphasis on REST and the avoidance of features as they become deprecated have repeatedly changed the structure of the book as what was once hot became just lukewarm.

So, this book would not exist without a massive amount of help from the Ruby and Rails communities. To start with, we had a number of incredibly helpful formal reviewers of drafts of this book:

Jeremy Anderson, Ken Coar, Jeff Cohen, Joel Clermont, Geoff Drake, Pavan Gorakavi, Michael Jurewitz, Mikel Lindsaar, Paul Rayner, Martijn Reuvers, Doug Rhoten, Gary Sherman, Davanum Srinivas, Stefan Turalski, and Jos Valim

Additionally, each edition of this book has been released as a beta book: early versions were posted as PDFs, and people made comments online. And comment they did: more than 800 suggestions and bug reports were posted for this edition alone. The vast majority ended up being incorporated, making this book immeasurably more useful than it would have been. While thanks go out to all for supporting the beta book program and for contributing so much valuable feedback, a number of contributors went well beyond the call of duty:

Manuel E. Vidaurre Arenas, Seth Arnold, Will Bowlin, Andy Brice, Jason Catena, Victor Marius Costan, David Hadley, Jason Holloway, David Kapp, Trung LE, Kristian Riiber Mandrup, mltsy, Steve Nicholson, Jim Puls, Johnathan Ritzi, Leonel S, Kim Shrier, Don Smith, Joe Straitiff, and Martin Zoller

Finally, the Rails core team has been incredibly helpful, answering questions, checking out code fragments, and fixing bugs. A big thank you to the following:

Scott Barron (htonl), Jamis Buck (minam), Thomas Fuchs (madrobby), Jeremy Kemper (bitsweat), Yehuda Katz (wycats), Michael Koziarski (nzkoz), Marcel Molina Jr, (noradio), Rick Olson (technoweenie), Nicholas Seckar (Ulysses), Sam Stephenson (sam), Tobias Ltke (xal), Jos Valim (josevalim), and Florian Weber (csshsh)

Ruby on Rails is a framework that makes it easier to develop, deploy, and maintain web applications. During the months that followed its initial release, Rails went from being an unknown toy to being a worldwide phenomenon, and more important, it has become the framework of choice for the implementation of a wide range of so-called Web 2.0 applications.

Why is that?

First, a large number of developers were frustrated with the technologies they were using to create web applications. It didnt seem to matter whether they were using Java, PHP, or .NETthere was a growing sense that their job was just too damn hard. And then, suddenly, along came Rails, and Rails was easier.

But easy on its own doesnt cut it. Were talking about professional developers writing real-world websites. They wanted to feel that the applications they were developing would stand the test of timethat they were designed and implemented using modern, professional techniques. So, these developers dug into Rails and discovered it wasnt just a tool for hacking out sites.

For example, all Rails applications are implemented using the Model-View-Controller (MVC) architecture. Java developers are used to frameworks such as Tapestry and Struts, which are based on MVC. But Rails takes MVC further: when you develop in Rails, you start with a working application, theres a place for each piece of code, and all the pieces of your application interact in a standard way.

Professional programmers write tests. And again, Rails delivers. All Rails applications have testing support baked right in. As you add functionality to the code, Rails automatically creates test stubs for that functionality. The framework makes it easy to test applications, and as a result, Rails applications tend to get tested.

Rails applications are written in Ruby, a modern, object-oriented scripting language. Ruby is concise without being unintelligibly terseyou can express ideas naturally and cleanly in Ruby code. This leads to programs that are easy to write and (just as important) are easy to read months later.

Rails takes Ruby to the limit, extending it in novel ways that make a programmers life easier. This makes our programs shorter and more readable. It also allows us to perform tasks that would normally be done in external configuration files inside the codebase instead. This makes it far easier to see whats happening. The following code defines the model class for a project. Dont worry about the details for now. Instead, just think about how much information is being expressed in a few lines of code.