An opinionated article about where to put efforts when you want to learn Rails. When you have prior experience...

· Ruby  · 7 min read

How to learn Rails when you already have some XP

An opinionated article about where to put efforts when you want to learn Rails. When you have prior experience...

Ruby is not complicated

Ruby has both OOP and functional abilities. The only "tricky" part are blocks (see below). My advice here is to buy a book, or buy a course. The one of Nicole and Mike is excellent (please note : I don't have any link with them outside being an happy customer;), the only thing I might add here is to practice daily, either by coding some daily exercises, either by entering in a "interactive ruby console", copy/paste some example, and see what happens. Docs are good when you have a question, but not when it's time to learn.

The only tricky part of Ruby is this one : you can't directly use functions as first-class citizens, instead you have to rely on "blocks", "procs", or "lambda". Google them around.

Everything else should look familiar if you already studied other languages.

Rails is easy, but thick

Once you feel comfortable with the Ruby syntax, it's time to learn Rails. This time, you have a free (official guide), however, once again, my advice is to combine this guide with a paid book or Rails course. I will same you times of hours and headaches.

Note that all courses are as good as the time you are willing to spend on it. Make sure you have some free time in the next couple of weeks, because you will have to train every day, in order to grasp concepts. This is not something special to Rails though. The same applies when you learn guitar or Japanese (Sorry for Japanese readers here;). This will not apply to your entire career of course, but my 2 pennies here is to really dedicate a lot of time and energy at the beginning of the learning process.

Take special time to understand...

The request cycle

Take time to understand how the request flows in your application. It explains how the controller works. Each HTTP happens in an independent context. Once you grab this, you're good enough with Rails... unless...

ActiveSupport

ActiveSupport augments Ruby with intuitive, utility functions. These functions will avoid you to solve classical problems that others developers have already encountered. Sebastien just launched a new course about it, I interviewed him recently.

Lodash, Moment

This is a little bit off-topic, since both are JS libraries, but since Rails is a full-stack framework, it's hard to bypass the frontend part. Lodash and Moment are both utilities functions of the JavaScript world. Moment has only a focus on Date, whereas Lodash is more general purpose. I find them very underrated. People prefer to talk about the last new shiny JS framework. Anyway, we're here to talk about Rails :)

Service Objects

There is a debate in the community about "where to put code that is related to your business". An intuitive way is to put them inside the controller, but this is not advised. The official Rails team put this code inside the Model (through Concerns), whereas a majority of Ruby dev do not like this practice.

Instead, they use Service Objects. I find this notion a little bit mundane, since they only are (very often) plain old ruby objects - you will often find the acronym PORO. Google them around, there are tons of articles about this. You will even find some plugins (named gems) to tackle this problem, but try to stick with PORO as long as possible.

Testing

If you already have some testing experience before, the same principles apply here. "Make some unit tests", "please code tests that run fast", etc, etc.

However, there is a debate in the community about how to test it the right way. Each subtopic of the "testing topic" is itself subject to endless debates. For example, some like to initialize the context with "fixtures", whereas others like "factories" - I personally avoid both.

My advice here is to always test a Rails app, at least at the highest possible level (functional or E2E testing), or you won't be able to upgrade your Rails, Ruby, and dependencies. For the short term it means not having access to nice features, over the long term it means security risks.

Deploying

Deploy with Heroku as long as it doesn't cost much (you can even start deploying apps with 0$). There are tons of alternatives now, but my advice is to stick with the most well-known and well-established product. Then switch once you have more traffic.

Create tiny, but production-ready app

I think it's hard to keep motivation high if you don't have some kind of short-term reward. Successful daily programming exercises can be one of them. Another is to launch a tiny, but real-world, production-ready app. Think about a news aggregator. Apart from listing links (and maybe some nice CSS styles), having something (really useful to others) build by yourself may not be too complicated.

Create YOUR side-project app

I can not emphasize enough on this point. Even when I'm working, I have time to :

  • study each dependencies deeply,
  • pay technical debt as soon as possible,
  • have 100% testing code coverage,
  • and so on.

In a real-world, production app, you barely have time to do anything properly, nicely, and elegantly because of the time constraint.

Having a side-project allows you to do things properly, which result in great satisfaction - for yourself, and soon for your boss and your teammates in your real-world project.

Use and abuse of the "rails new" command

Testing a new gem, grabbing a new concept, debugging and isolating a problem, going back to basics. Each time I encounter one of these problems - and that's quite often - I use the "rails new" command.

It creates a fresh new app, with standard gems, and green context (new, empty, un-conflicting database and tables).

Don't be afraid of using it as often as needed. It won't bite. And the reward is huge. I was happy to discover that experienced Rails devs do that too.

Start with a minimalist Rails app

Rails is quite old now (I mean : for the web industry). Which means you have a lot of new and old plugins each time you run the "rails new" command. Which is completely understandable for anyone who knows Rails from the beginning, but really hard to understand for a newcomer. So my advice is to always use the "rails new" command with the "--minimal" flag. It will install only the bare minimal plugins (known as gems) to have a Rails app that works.

Take time to study each gems

One mistake I made was to just install Rails and code features, without taking time to study each default installed gem.

Deal and study compromises

Nothing related to Rails here. You will find options and compromises all along your journey with Rails. I rarely find a "good" option, only one that is "not too bad".

Once you definitely know Rails

Well, this should be an empty section, because there is no "after you know Rails". You never "know" Rails. Even after 5 years I feel very junior about Rails, actually the more I discover, the more I feel there is actually even more to discover. Thus I feel even more junior.

To conclude, here is a list of blog/people I follow :

Share:
Back to Blog

Related Posts

View All Posts »
Ruby constants

Ruby constants

Constant are not so often used in Ruby, however, it's always good to know how they work when the need arises. Constants are simply variables that are not meant to be changed.

How to create tons of Rails apps

How to create tons of Rails apps

Yes, I already now about the rails new command. But what if you want better defaults, like an existing controller, an existing view, or another way to to launch the Procfile?

Rails new options

Rails new options

Let's see the official way to create Rails application, as well as the minimalistic option.

Ruby Enumerator, the what, the why, the how

Ruby Enumerator, the what, the why, the how

Before we start using Enumerators, we need to understand the concept of Enumeration and the tools Ruby gives us for Enumeration. Also, we will be assuming that you are comfortable with blocks in Ruby.