When I first got into Ruby and Rails development, I was impressed about how everything worked. A few lines of code and so much got done. At that time, if I was reading a book or blog post that said: “just do X and Y will automagically work”. I would gladly accept those instructions.
However, after a while, I wanted to understand how it really worked from the inside, so I started reading the source code from different plugins, including Rails itself. Accusing magic to be the reason for that 200 lines of code to “just work” didn’t feel right anymore.
Turns out, I was not the only one with this feeling. I have been into a few big conferences this year and asked people outside the Rails community what they think about it. And, for my surprise, some of them mentioned that “there is too much magic going on”.
We have been victims of myths before, as the famous “Rails can’t scale” one, and we strongly fought back. But what about the “there is too much magic going on”? Is it myth? Who is there to blame?
Yes, it is a myth and we (the Rails community) are the ones to blame for spreading it.
I have already seen people explaining how “has_many :comments” works as magic: “it magically guesses the columns from your database”. Well, a more appropriate description for that would be “Convention over Configuration”. Rails uses a set of conventions so it can properly build your associations without you having to specify all tables and columns.
Heck, I also did my part in the past. There was a time that Inherited Resources’ README was filled by words like “magic” and “automagically”. Just recently, I replaced all this occurencies with more detailed explanations of how it really works.
The question is: isn’t it about time for us to start fighting against the “magic” myth?
When I improved Inherited Resources’ README, the benefits were clear in my head. People using Inherited Resources would write better code and be more productive because they understood it better. And, as consequence, they would be able to troubleshoot issues easily or even contribute back. This is clearly a win-win situation.
At the beginning of this year (or more specifically February, 2010) I started to put a lot of effort in writing and understanding Rails 3 architecture. Or as some people would (wrongly) say: I started to unveil the magic. After some time, it was clear that I could write better and faster code and that a lot of people could benefit from this knowledge as well.
Now, 10 months later, I am happy to say that the beta version of my book Crafting Rails Applications is out to spread what I have learned about Rails and its applications. Rails is a framework that allows us to write web applications and an advanced Rails book should consequently be about crafting them.
Crafting Rails Applications guides you through seven different tutorials, each of them using test-driven development to build a new Rails extension or application that solves common problems through the new Rails 3 APIs. You will understand how the Rails rendering stack works and customize it to read templates from the database while you learn how to mimic Active Record behavior, like validations, in any other object. You will find out how to write faster, leaner controllers, and you’ll learn how to mix Sinatra applications into your Rails apps, so you can choose the most appropriate tool for the job. In addition, you will improve your productivity by customizing generators and responders.
From the book cover:
Rails 3 is a huge step forward. You can now easily extend the framework, change its behavior, and replace whole components to bend it to your will, all without messy hacks. This pioneering book is the first resource that deep dives into the new Rails 3 APIs and shows you how use them to write better web applications and make your day-to-day work with Rails more productive.
My goal is that Crafting Rails Applications increases the Rails community thirst for knowledge, that “magic” is no longer enough to describe any part of Rails or its ecosystem.