Foreword

A long time ago, I was an intern at a technology company. We had “deploy week,” meaning that after deploying, we took an entire week to fight fires. Moving our code to the production environment would inevitably cause unexpected changes. One day, I read a blog post titled “Unit Testing with Ruby on Rails,” and my life was forever changed. I excitedly went and told my team that we could write code to check whether our code worked before deploying, but they weren’t particularly interested. A few months later, when a friend asked me to be the CTO of his startup, I said, “Only if I can do it in Ruby on Rails.”

My story was fairly typical for that period. I didn’t know anything about Ruby, but I had to write my application in Rails. I figured out enough Ruby to fake it and cobbled together an application in record time. There was just one problem: I didn’t really understand how it actually worked. This is the deal everyone makes with Rails at the start. You can’t think about the details too much because you’re flying to the sky like a rocket.

This book, however, isn’t about that. When I read The Rails Way for the first time, I felt like I truly understood Rails for the first time. All those details I didn’t fully understand were now able to be grokked. Every time someone said, “Rails is magic,” I would smile to myself. If Rails was magic, I had peered behind the curtain. One day, I decided that I should write some documentation to help dispel those kinds of comments. One commit became two; two became twenty. Eventually, I was a large contributor in my own right. Such a long way for someone who had just a few short years earlier never heard of a unit test!

As Rails has changed, so has The Rails Way. In fact, one criticism you could make of this book is that it’s not actually “the Rails way”; after all, it teaches you HAML instead of ERb! I think that this criticism misses the mark. After all, it’s not 2005 anymore. To see what I mean, go read the two forewords from the previous edition. They appear right after this one ... I’ll wait.

Done? David’s foreword was quite accurate for both Rails 2 and The Rails Way. At that time, Rails was very much “not as a blank slate equally tolerant of every kind of expression.” Rails was built for what I call the “Omakase Stack”: you have no choice, you get exactly what Chef David wants to serve you.¹

1. Omakase is a Japanese term used at sushi restaurants to leave the selection to the chef. To learn more about the Omakase stack, read http://words.steveklabnik.com/rails-has-two-default-stacks

Yehuda’s foreword was also quite accurate—but for Rails 3 and The Rails™ 3 Way. “We brought this philosophy to every area of Rails 3: flexibility without compromise.” With Rails 3, you get the Omakase stack by default, but you are free to swap out components: if you don’t like sushi, you can substitute some sashimi.

There was a lot of wailing and gnashing of teeth during the development of Rails 3. Jeremy Ashkenas called it “by far the worst misfortune to ever happen to Rails.” Rails 3 was an investment in the future of Rails, and investments can take a while to pay off. At the release of Rails 3, it seemed like we had waited more than a year for no new features. Rails was a little better but mostly the same. The real benefit was where it couldn’t be seen: in the refactoring work. Rails 1 was “red-green.” Rails 2 was “red-green.” Rails 3 was “refactor.” It took a little while for gem authors to take advantage of this flexibility, but eventually, they did.

And that brings us to Rails 4 and The Rails™ 4 Way. This book still explains quite a bit about how Rails works at a low level but also gives you an alternate vision from the Omakase Stack, based on the experience and talent of Hashrocket. In many ways, The Rails™ 4 Way, Agile Web Development with Rails, and Rails 4 in Action are all “the Rails way.” Contemporary Rails developers get the best of both worlds: They can take advantage of the rapid development of convention over configuration, but if they choose to follow a different convention, they can. And we have many sets of conventions to choose from. It’s no longer “David’s way or the highway,” though David’s way is obviously the default, as it should be.

It has been an amazing few years for Rails, and it has been a pleasure to take a part in its development. I hope that this book will give you the same level of insight and clarity into Rails as it did for me, years ago, while also sparking your imagination for what Rails will undoubtedly become in the future.

—Steve Klabnik