Learn Rails the Hard Way

Apologies to Zed Shaw, of course.

Learn Rails the Hard Way, in 10 steps

  1. Travel back in time to 1998, and build a mysql-backed CMS in php, because that was pretty much all there was.
  2. Take a bunch of CS courses, fixate on the concept of a REPL. Think to yourself, a video game is just a really fast REPL with fancy graphics.
  3. Learn Vim because it's cool, and because M-x tetris is distasteful.
  4. Learn struts for a job and feel the agony of what it's like to drown in a sea of meaningless xml files just to get a web page to display.
  5. Work for Ask.com and know the true horror that using xml for dispatch can bring: cower before the homebrewed struts-alike called Tako. Tako means octopus in Japanese, the naming was obviously a reference to the tentacles of Cthulu.
  6. Pick up the life-preserver that is Pragmatic Rails and learn Rails 1.2 because it's still 2007. You're time traveling, remember? Build a toy app that scratches an itch, learn to be smug about how fast you built it. Be slightly baffled that some constructs that work in Rails don't work in straight Ruby.
  7. Take a job that uses Python, deploy Pylons because of how pleasantly Rails-y it is. Read the source and find that it's basically a straight port of Rails. Continue to be smug.
  8. On a whim, take netcat and observe simple http traffic. Idly wonder what it would be like to have a web browser feed directly into a REPL... oh.
  9. Teach a class on Rails, even though you haven't touched it in five years.
  10. Advocate learning Sinatra, Flask, and Noir instead.

Learning to use Rails is almost as much learning what you're not using instead. It's hard to appreciate the utility of Rails without having a broader survey of what your options are. Indeed, if you lack the context to know why Rails was revolutionary in the first place, many of its features may seem esoteric and inconsistent. I've met many developers for whom Rails was a black box, and many of their problems were solved by trial and error. This is a bad sign.

"A fad is created when adoption exceeds education." Someone much smarter said that, and I can't remember who it was for the life of me. Rails was/is/will become a fad (time traveling!), and I worry that the quality of Rails developers (on average, obviously there are plenty of good ones) is declining as we move forward. I see people writing code that reminds me of the cut-and-paste web developers of the late 90s, and that's not good.

Many apps these days are little more than hastily-glued together gems, letting Rails and Devise automate everything else. I appreciate that there is a large body of knowledge involved in making that happen, and you might need to be a Rails expert to do that. I'm not so sure that means you're also a programming expert.

Don't get me wrong. Rails is wonderful. It has done amazing things for the current state of technology and the Rails team continues to innovate constantly. But if you're going to be a Rails developer then really learn it, what it does for you, and more importantly, what it hides from you. Be a developer first, then a web developer, then a Rails developer. When you finally understand Rails, you'll also understand why you don't need it. And by then, you might not even want it anymore.