For the past few weeks, I took a break from Rails to work exclusively in the Go language on a recent project at work. Although I've enjoyed programming in Go, I've really missed working with Ruby, especially Rails.
Now that I am back to the comforts of Rails, I've had the nagging feeling that I still don't really know Rails as much as I'd like to. And that's how it goes with most skills. It's easy to get comfortable and coast on what you know, based on what you've learned so far, which is enough to get things done without getting into trouble. However, that prevents you from going deeper into that skill, to not only learn it, but master it.
In addition, I've always believed that we can always improve, grow, and extract more out of our education. After learning and writing everyday for two years, I've realized that any topic, no matter how basic, can be made much more interesting if you dig deep enough. Sometimes, when you look at things again with a fresh pair of eyes, you end up learning stuff you never knew before.
So I decided to make the best of this opportunity and start to learn Rails from the first principles, to gain a better understanding and appreciation of the fundamentals of Rails.
Once that was decided, the next question was: where should I begin? What should I learn first?
Now this is not the first time I've stumbled across this question. For the past year, in my spare time, I've been teaching Ruby on Rails to a few students and developers wanting to switch technology stacks, and one of the questions I always used to have before working with any new student was where should we begin learning Rails.
Should we learn controllers first, or explore models, or go with a specific Rails framework, like ActiveRecord or ActiveSupport?
However, as I've gained more experience in teaching by working with more students, I've realized that the Rails Router is the best place to begin learning any web application framework, whether it's Ruby on Rails, Laravel, or even ASP.NET MVC.
Just think about it: What's the essential function of a web application framework?
It's to take an incoming HTTP request and deliver HTTP responses.
Even before the framework enters the picture, we need to think about where exactly the incoming HTTP request should go. That means we have to define the application's routes first.
Routes are the interaction points to your application through which the external world (browser, API client, etc.) interacts with your application.
Whenever you visit a Rails application (or any website) in the browser, the server first identifies the route based on the URL, and then invokes the correct code to build the response. Without routes, you have no ability to interact with the web application.
Hence, I started my Rails re-learning journey with a deep dive into the routing system. For the past few days, I've been trying to learn everything I could about the Rails router. I took a lot of notes, and decided to compile them together with the past articles on this blog, and published a ~12,000 word handbook on the router.
Check it out:
I published it using the new Writebook publishing platform from 37signals, and have to say, I've really enjoyed the whole writing and publishing experience. So much so that I plan to write and publish more books soon.
Each chapter in the book takes a specific concept, and tries to explain it in simple words, as writing and explaining to others is the best way I've found to learn things. Not only we'll learn how it works, but also how it's implemented, by reading the Rails source code.
If you're new to Rails, or like me, interested in learning the fundamentals of Rails with a fresh pair of eyes and with the mindset of a beginner, I hope this small handbook will teach you a thing or two that you didn't know before, giving you a much better and deeper understanding and appreciation of the Rails Router.
Happy reading!
As always, if you have any questions or feedback, didn't understand something, or found a mistake, please leave a comment below or send me an email. I reply to all emails I get from developers, and I look forward to hearing from you.
If you'd like to receive future articles directly in your email, please subscribe to my blog. Your email is respected, never shared, rented, sold or spammed. If you're already a subscriber, thank you.
