DEV Community


Posted on • Updated on • Originally published at

Learning Rails in 2017

So far this year has been surreal & hectic to say the least, and we're basically halfway through. I started a new job late last year, which I expected to be challenging for plenty of reasons. Arguably the most important one: I was going to support a large codebase built in Ruby (on Rails). In the past, I too have sinned from trash talking programming languages which I knew nothing about (including Ruby). A public apology is written in this blog post, with tips/notes/comments from my personal experience learning this amazing technology.

Two steps forward, never step back

Ruby and Rails are not the shiny new toys out there, not today. Before this gig, I worked for about a year with NodeJS, which I fell in love with. To be honest I didn't expect to start off fresh with a new language & framework. Especially with the direction of recent tech tides, this didn't seem like the obvious direction to follow.

Why do people/companies choose Java or .NET? Broadly because they look for a battle tested, full featured platform with enterprise support. Why choose NodeJS, Go, Elixir, Clojure? (you get the idea) Because I wanna go fast, amongst other reasons of course. But one might argue performance is what most adopters pursue when venturing down that path. Even though they might not need blazing speeds, and more often than not they don't absolutely require that performance gain.

Why Ruby and Rails then? Because why not, but only partially. Platform maturity, developer happiness/productivity and open sourceness (if such a term makes sense) make up a great cocktail. We all want to get things done, right? I'm happy and proud to have added Ruby and Rails to my Tool Belt, which already has and will hopefully continue to help me get things done.

Getting started

If you're looking for a step by step guide on getting started with Ruby on Rails this is where you should go. My perception is that, if you read and code along with the Getting Started tutorial from the official guides you will understand ~50% of what Rails is all about. Another ~30% lives in all the other guides from

Yes, I believe ~80% of what you need to know about Rails is available in a single website! That last ~20% is what the Pareto Principle is all about, you are forced to pour some hard work in to get past that threshold.

For somebody who is just getting started or is planning to, here are some concepts that gave me an "Aha! Moment" (involving both Ruby and Rails):

  • "Not everything is plain Ruby, but everything is an object". It might seem obvious for experienced Ruby devs, but it probably isn't for beginners or coders experienced in old-school static typed languages. For example 1.week.ago is an 'extension' packaged with Rails that you need to explicitly import to use outside a Rails project. And Integers are objects themselves, which is why you were able to call functions on what a Java programmer knows as a primitive data type.
  • You will hear about convention over configuration a lot on introductory tutorials and with a bit of practice you will later interiorize most of them. Some of the ones I struggled with at first were:
    • File names (controllers, models, views, helpers, etc) are commonly snake_cased, but their implementation (class name in the code) is CamelCased. Both of them in singular, since they will represent one object when used (i.e.
    • Model association names are declared in plural form, for example in user.rb you would write has_many :books to associate with book.rb. Unless they are a belongs_to or references association, which makes sense because they refer to a single record. The book model would read belongs_to :user.
    • Forms & routes might seem complex, especially when nesting, like form_for [@article,]. Personally they are still tricky, especially when I want to instantiate a link to a custom route path outside the form. For this I still do a bit of trial and error, or the old trick of copy & paste from StackOverflow.
    • My suggestion again would be to experiment and trace along the getting started guide. You won't confront the convention quirks of Rails until you derail yourself a bit (pun 100% intended).
  • The yield command is analogous to "execute the block received". This took me a few minutes of re-reading different explanations out there. When declaring a function with 2 parameters, it can actually receive 3. That extra (optional) parameter is a "callback-like" block. For example, when you iterate an array with array.each { |i| puts i } the underlying implementation of the array iterates over its elements and "yields" that element to the callback function you sent in. Coming from a NodeJS background, that simplified explanation using the term 'callback' makes sense to me. Also this StackOverflow answer elaborates a bit more if you're curious.


The next step after the official guides for me was to start looking for in-depth takes on certain topics. That type of knowledge only comes from experienced coders. Who has that precious knowledge we seek? Glad you asked, some of my bookmarks are (in no particular order):

  • RubyTapas: Short screencasts with awesome insight on many different subjects. I really like the rake episodes (kind of outside RubyTapas, but same author and overlapping subjects).
  • What you'll find in this website cannot be unseen - "The act of making love, tenderly" ( ͡° ͜ʖ ͡°)
  • Schneems's blog: Performance is a recurring topic in here. Regardless of the platform you code in, who doesn't have a need for speed?
  • The official docs: Learning a new framework means you will google "how does X works", constantly. I'm sorry to say that sometimes API dock didn't had the best up to date info I was looking for. Still helpful though, but I tend to check results first.
  • ConFreaks: Entire RailsConf talks are in there from 2017, 2016 and probably previous ones as well, awesome material. Turbolinks 5: I Can’t Believe It’s Not Native! by Sam Stephenson is definitely the one that struck me the most, personal favorite so far (and this is coming from an iOS dev 😉)
  • Any talk from the late Jim Weirich: That video is amazing, and so are all the other ones that I've seen so far from him. His legacy touched my life too, years after he passed. Thanks a lot Jim.
  • Podcasts of course: I've listened a couple of 5by5 & RubyRogues episodes, interesting indeed.

I would love to hear other interesting sources I'm missing, which I'm sure there are plenty. It's also imperative to mention: At least browsing through the Readme of the gems you commonly use will decrease your 'Rails does a lot of Magic under the hood' perception, significantly.

It's open source people, take advantage of being able to read code from some of the best coders in the business.

Everyday Cheatsheet

Short snippets I lookup quite often because they are useful (and I'm too lazy to memorize them):

rake db:rollback STEP=1
Enter fullscreen mode Exit fullscreen mode
results = ActiveRecord::Base.connection.execute("foo")
Enter fullscreen mode Exit fullscreen mode
STDOUT.reopen IO.popen "tee stdout.log", "a"
STDERR.reopen IO.popen "tee stderr.log", "a"
Enter fullscreen mode Exit fullscreen mode
// From what I hear this comes with a performance penalty due to costly I/O
STDOUT.sync = true
Enter fullscreen mode Exit fullscreen mode


Every language and framework has a learning curve, no exceptions. I did felt that both Ruby and Rails are gentle for newcomers, and if you know JS/Java/Python (as plenty of CS graduates or even high school students sometimes do) you can be up and running quickly.

Turrialba is a website that I built during my learning phase. I rewrote parts of it maybe 3 or 4 times, and I decided to publish it recently. It's a frankenstein experiment and I'm not proud of the UX, but feel free to check it out and hit me up with feedback. Don't be too critical, I'm aware it's rough on the edges. Side Note: The rails app is dockerized and running as a service loosely based on a previous blog post I wrote *self pat on the back*

In my opinion using a framework is the only way to learn a framework. Have fun coding out there with whatever floats your boat these days, Pura Vida!

This post was originally published on

Top comments (10)

niharmore33 profile image
nihar • Edited

The same reasons why it was a framework worth learning in 2004. The more things change, the more they stay the same. While we’ve seen a lot a progress in the JavaScript world, we’ve also seen a regression to the complexity-laden world that Rails offered refuge from in the early days.
Learn Ruby On Rails here:

Back then the complexity merchant of choice was J2EE, but the complaints are uncannily similar to those leveled against JavaScript today. That people spent hours, if not days, just setting up the skeletons. The basic build configurations. Assembling and cherry-picking from lots of little libraries and frameworks to put together their own snowflake house variety.

The core premise of Rails remains in many ways as controversial today as it was when it premiered. That by formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application, we can make dramatic strides of productivity.

It’s somewhat surprising to me that despite the astounding success of Rails, that there haven’t been more competition for this proposition. The vast majority of activity today is for yet another option on the a la carte menu. Yet another build system, yet another view library, yet another ORM. Very little activity in integrated solutions.

I guess the answer is that the foundational proposition of Rails continues to cut against the psychological grain of most programmers. That by reducing choices and accepting community conventions and answers to most of the basic questions in web development, you end up better off. Less unique, less tailored, but in ways that just don’t matter anyway.

Anyway, that’s the big ideological appeal of Rails. I’ve elaborated further on convention over configuration, the a la carte/omakase conflict, the appeal of integrated systems, and other core values of the Rails community in The Rails Doctrine.

After reading that, you’ll probably have a pretty good idea as whether Rails is something for you or not. If you can’t recognize any of the struggles outlined in that document, or you just don’t like the solutions presented to those struggles, the particulars of Rails technology probably doesn’t matter much. If that document resonates, or at least piques your interest, read on.

On top of these ideological choices, we’ve built an incredibly pragmatic and multi-paradigm web framework. When people hear “web framework”, they sometimes thinks that “oh, that’s just some stuff to generate HTML, right?”. And in that definition, some might see it as though Rails competes against something like React. And I suppose it does, but in a very remote way that isn’t very useful to thinking about whether Rails is right for you or not.

As I talked about above, Rails has an incredibly ambitious mission. In the full-stack goal lies a pursuit to deal with just about every piece of code needed to connect databases and no-sql stores to a business domain model written in Ruby to a set of controllers that expose that model via REST and then, yes, finally to HTML. But that last step is a small minority of the code and focus of Rails.

So if you think that client-side MVC, React, Angular, or whatever is The Future, then you’re still squarely in the target audience for using Rails. Because the bits you use to design your HTML/JavaScript-based UI still needs to connect to a back-end domain model that saves stuff to the databases, computes things, enqueues jobs for later processing, sends out emails, triggers push notifications, and all the other stuff that real apps need to do.

And that’s where the meat of Rails sits. In what happens once that POST or PUT or GET is triggered. Now, as I said, Rails is full-stack by default. So of course we also include answers for how to generate and update HTML. We have some phenomenally productive answers in Turbolinks and SJR, but even if that path doesn’t appeal, everything that leads up to generating that JSON is still stuff we’ll have in common.

Anyway. That’s a very long pitch for two basic tenets of Rails appeal in 2017: 1) We have a unique ideological foundation that’s still controversial today and offers the same benefits against the mainstream choices as it did 13 years ago, 2) We have a pragmatic, full-stack answer that could be formulated based on that ideology that still offers amazing productivity from the second you run the rails new command.

Oh, and on top of all that, I’ve saved the cherry for last. You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter. Just look at some code. I dare you not to fall in love.

ben profile image
Ben Halpern

Absolutely 👌

ahyanarizky profile image
Ahyana Rizky Pratama

thanks for the post ! somewhat I also getting in your position, after a year with nodeJS and React now I presented to a project with Rails, looking for clue, and come to this post. Wish me luck with the rails learning curve.

mehdifarsi profile image

Great article !

I used to take the transit every morning to go to work and in the subway or the bus I would read the Ruby Doc.

Just randomly reading about random methods and classes.

This little practice became really powerful when I would go back to my computer and start coding.

This simple routine helped me a lot !

Now — in order to payback to the community — I publicly write on Medium to help people to dive into Ruby & Ruby on Rails.

Feel free to follow me to get my last articles here:

Hope this is helpful :-)

gregorgonzalez profile image
Gregor Gonzalez

Thanks. I always try to learn a new language but don't know where to start. This article will help a lot.

albertdugba profile image

If you're new to ruby on rails and you're looking for place to learn all the ins and outs of it. The look no further than

ben profile image
Ben Halpern

Super great post. We are onboarding a developer who is new to Ruby and Rails at the moment and I'm going to point her here.

andy profile image
Andy Zhao (he/him)

Raise your hand if you also forget how to rollback! ✋