A Beginner’s Guide to Becoming a Ruby on Rails Developer

Masrour Basith
Glossier
Published in
10 min readJul 23, 2021

Maybe you just started programming and are looking for a guide on the language of your choice. Or maybe you just started a new job where the tech stack uses another language you’ve never worked with. No matter what, learning a new language can be scary.

I was in this exact position when I started working at Glossier. As someone who works mostly in Python and Java, I never bothered to explore Ruby as an alternative. So when I found out that a big chunk of Glossier’s systems used Ruby on Rails, I had to play some catch up.

But what was the best way to go about this? There are so many resources out there for pretty much any language you can think of. While that’s great, it can be overwhelming. Where do you even begin? The answer to that question depends on the person. Some of us are visual learners who love YouTube tutorials, while others prefer reading textbooks. It’s hard to differentiate what might be helpful for you versus what might be helpful for someone else.

So I tried multiple approaches in my first month here, and throughout this journey, I managed to curate a specific list of resources and self-commentaries that I thought would be helpful for anyone else in a similar position.

My reasoning is this: If you’re looking to learn a programming language, it may be helpful to follow in someone’s footsteps who may have been in a similar situation such as yours. What this guide offers is a “paved path” that I have experienced not knowing any Ruby at all, to becoming a proficient Ruby on Rails developer.

The intention is that anyone looking to learn Ruby on Rails can follow this same “journey” and become a proficient Rails developer in no time.

Starting with zero Ruby experience

If you want a more detailed introduction to the Ruby programming language, and are a bit newer to programming in general, I suggest that you skim through this Ruby Programming Language — Full Course YouTube video by freeCodeCamp! Keep in mind that while this video is geared toward beginners, there are good bits and pieces if you are a more seasoned programmer to go over, such as “what’s the syntax for building a hash map or a for loop?”

If you feel confident about not needing to sit through a tutorial video, you might find a simple syntax cheat sheet more helpful to learn the bare nuts and bolts of the language. I found the Ruby Syntax Reference Guide to be a great reference. Regardless of your experience, I encourage you to have an open mind and go through both resources.

I want to start coding in Ruby now, but which IDE do I use?

This might be one of the first things you might be asking yourself after reading up on the basics, as it’s only natural to wonder what’s the best tool for the job. There’s no right or wrong answer to this question. If you love working with Vim, then go right ahead! If you prefer something more “modern”, there are also tons of options.

Personally, I have found great success working with VSCode as there are some fantastic plugins for the Ruby ecosystem and for software development in general (they have a great pair programming live share feature!)

A brief introduction to debugging in Ruby (and why it can be your secret weapon!)

Debugging might seem like a topic that we shouldn’t spend too much time on, but there are tools Ruby offers that some people find very helpful, which is why it’s being covered here.

If you ever find yourself stuck trying to figure something out when coding in any language, it’s worth a shot to debug it using your favorite tool. My personal favorite tool in the world of Ruby however is pry. Just insert the line binding.pry into any line of code and run your project to pause code execution on that line to open up a REPL (Read-Eval-Print-Loop) for you to inspect the state of your app! This can be a very powerful tool to see what exactly is happening under the hood, from the state of your variables, to method definitions if you don't like throwing random prints into your code. Whether it's using pry, or the built in debugger in your IDE of choice, learning how to use debuggers can be your secret weapon whenever you're stuck on a problem.

That being said, there are people who would argue that you don’t need this fancy debugger, and they bring up some very good points! Sometimes the fastest way to debug something is to just throw in a puts statement and print out what's going wrong. I highly recommend reading the following articles and see if binding.pry is something you would want to invest time in.

Why Pry is one of the most important tools a junior Rubyist can learn

Powering up your Ruby & Rails development with Pry

Learning Rails

So what are we even talking about when we say “Ruby on Rails”?

Simply put, Ruby on Rails is a framework, or a collection of tools, that let you build web applications. Want to create a website with Ruby? Then Ruby on Rails will be your weapon of choice. In fact, you might have used a few websites that run on Rails! Aside from Glossier, websites like Shopify, Github, and AirBnB have been known to use the framework.

But before we dive into Rails, you might have also heard the phrase MVC. But in case you haven’t, it stands for: Model View Controller, and it’s the backbone of how Rails operates.

First you have models that define entities driven by your business logic. For example, if you're building an e-commerce app like Glossier and want to support people ordering products, you can have a model for your orders, payments, and shipments.

Then you have views , which are the front-end components of your web app. These are the pages you're going to want to show off to your users. Going with our e-commerce example, maybe you'll have an orders view that shows off all the orders you made on your awesome site!

Finally, you have controllers, which are the glue between the front-end and the back-end. Let's say your user clicks on an order on your orders view , which is on the front-end, and now you want to show off that order's contents. The controller is going to take that action/request your user just made, translate what they did to what must happen on the backend, and then return a response to the front end. A response can be an HTML, JSON, XML, or whatever type of object you can think of. In this case, the controller will orchestrate getting the contents of the order via the order model, and then updating the view accordingly.

Lots of frameworks utilize this pattern. But what makes Rails often confusing is the amount of conventions it has.

Wait. What in the world is a convention!?

A convention is a pattern that people will usually follow to do a certain task. Want to add a new column to a table? There’s a convention for that. Need to add a new endpoint for your web app? There’s conventions for that as well.

In fact, one of the major aspects of Rails is the idea of “Convention over configuration”, which encourages using a list of curated coding patterns to maximize productivity. What does that mean? It could mean naming a variable in a certain way to correctly wire a database model and schema. Or it could mean using a specific function to generate all the REST API endpoints you need.

There is definitely a learning curve here. You might be used to configuring everything yourself, so many of these conventions might seem like magic. So the name of the game is finding all these conventions and keeping a mental note of what they do. It’s a lot like learning idioms in a spoken language. If you’re learning English and you hear someone say “It’s raining cats and dogs” for the first time, it’s gonna sound weird. But once you figure out what it means, you’ll learn a useful phrase that you can use later on. Learning Rails conventions is a very similar process.

On a more philosophical note, one way I’ve heard people talk about Rails conventions is that you can think of yourself either walking or taking the train. While walking is pretty slow, you’ll eventually get to where you need to be. However, if you take the train, which is on rails (conventions), development is a lot faster and easier.

Getting started with Rails internals

Now that we’ve established what conventions are, learning Rails’s ORM (Object Relational Mapping) is a good next step! The ORM is essentially how you will be interacting with the backend components of a Rails app. This is also a great way to ease into Rails’s conventions.

Active Record Basics is a good article to skim to start learning about the ORM. Active records are powerful models that are a core part of Rails so it’s very important that you start getting used to using them.

You can also skim through the articles covering migrations and validations to see how Rails handles versioning and data cleaning (though I wouldn’t stress too much about it because it’s pretty straightforward).

What I found to be very important was the article on associations and callbacks. These are two features of Rails you’ll constantly see in our codebases so it’s extremely important to learn them. I constantly find myself going back to these two links for documentation on what each association does and what each callback hooks into in the object lifecycle.

On the topic of Active Record callbacks, it’s a bit misleading in my opinion to only call them “callbacks” in a general sense. To me, Active Record callbacks are object lifecycle hooks that behave like callbacks. For example if you want to validate something before saving an object to your database, you can pass in a validation function into a before_save callback to hook into the part of the object lifecycle right before the object is saved. In simpler terms, you're giving code to a before_save function, much like a general callback, that will hook into the object lifecycle.

You might already notice that all of these topics teach you about Rails’s conventions (especially with active records). The best part is that these references are perfect ways to refresh yourself if you ever forget about a convention. For example, there are a lot of callback types in Rails, and you can always go back to the official callbacks article linked earlier to refresh yourself on which callbacks you can use!

On the front end side of things, it’s also worth while to take a look at layouts and rendering in Rails in order to get a feel for how you’ll be interacting with templates.

To put it all together, Ruby on Rails in 60 Minutes is a great place to test out all the literature you’ve been reading. I highly recommend building the app locally along with the video and playing around with it to get a bare minimum Rails application that you can dive head first into. In particular, it’s important to pay attention to the fact that there’s some magic going on. Some example include, but are not limited to:

  • Accessing data coming into your application by a magic params object.
  • Singular/Plural name usage to define the model/table connection. If we have a Posts table, the model name would just use Post, and Rails is smart enough to link that relationship

Once you understand this, it’s pretty straightforward to build a barebones Rails app and understand the general flow of data! I highly recommend playing around with the app you just built after watching the video for anything you’re curious in.

Testing in Rails:

Chances are that if you jump into a production level Ruby codebase, there will be tests. So to prepare for that, let’s talk a little bit about them.

As a dynamically typed language, Ruby faces an issue where it can be a little tough ensuring that your app is working as intended before runtime. By dynamically typed, I mean that type checking on objects doesn’t happen until runtime. So in theory, because you don’t have to worry about the rigidness of a statically typed language, which might do all this checking before you run your code, your development lifecycle can be faster. Testing in dynamically typed languages can be seen as a helpful way to make sure everything is alright before we put our app out for the world to see.

Here’s an example of a test. If you have a web page with a button, and you just put in a change to the web page such that if you click the button three times, it’ll turn the page blue, a test for that would look something like:

If I click my button on Page X three times:
It should turn the page blue:
#My test code to emulate the scenario goes here
end
end

The good news is that many times if you’re thrown into a Rails application you’ve never seen before, the tests are actually a good way to figure out the internals! Well written tests are able to give pointers to newer developers on how the whole application flows. Good tests can allow for developers to play detective and figure out the mystery of your application by themselves!

Long Live Ruby has a very gentle introduction to RSpec that is worth a read!

Since we’ve spent a good chunk of time on good conventions, why not also check out this guide from BetterSpecs for RSpec conventions while you’re at it? The better your tests are, the easier it’ll be for others to understand your app!

Making sure you have a solid Rails foundation

A fun (well, depending on your definition of “fun”) way to evaluate your Rails competency (and to cover a lot of the smaller things I might not have covered yet) is to read through these interview-esque Rails questions and digest the answers provided. The reason why I find this resource so helpful is that it answers some very common questions a newer Rails developer might ask themselves in the process of learning Rails.

Go forth into the world of Rails!

If you’ve made it here, then congratulations! We covered a lot of foundational work here, so give yourself a pat on the back. In short we went over the following:

  • The basics of the Ruby programming language
  • Testing in Ruby
  • The basics of Ruby on Rails, focusing on conventions and ORMs
  • Testing in Ruby on Rails
  • Quizzing ourselves on our Ruby and Rails knowledge

While we only scratched the surface here, you might hopefully be feeling a lot better about tackling this huge world of Ruby.

I highly encourage that you take all this newfound knowledge with you as you dive deeper into all the Rubyisms and best practices you want. And before you know it, you might even become the Ruby on Rails master you’ve always dreamed of being in no time.

Happy coding!

--

--