Rail-s-way to Heaven!
Ruby on Rails (RoR) is a web application framework built in Ruby. It follows the MVC (Model-View-Controller) pattern and it allows users to create database-backed apps.
It is completely open-source. Since the first version in 2005, more than 3000 contributors have worked on improving the framework. If you feel curious about it, check out their source code here: https://github.com/rails/rails
The Rails Way is based on two main concepts:
DRY stands for Don’t Repeat Yourself. The framework is extremely well modularised, which means the level of abstraction is really high. Rails revolves around logic that is separated into different methods, each one with a clear, distinguished responsibility.
Convention over Configuration
Do not you dare telling Rails how you would like to structure your code. Rails does it for you in the way Rails thinks is best.
It does not mean you need to follow this principle or even use this framework, but it can be really helpful to learn best practices and get you going really fast.
Who is using Rails and why?
Some companies that have used the framework at some point are: Github, Airbnb, Shopify, Twitch…
To date, Github continues to use Ruby on Rails, and there are some others well-know companies such as Basecamp, Codecademy, Fiverr or Soundcloud.
Using a framework like Ruby on Rails makes a lot of sense especially for startups. Becase of their nature, they have relatively little time to develop their product, and, again, that is where RoR truly shines, allowing to get more done in less time.
Are you having fun?
Ruby on Rails is optimised to achieve one main goal: Developer’s Happiness.
“I created Rails for me. To make me smile, first and foremost.”
- David Heinemeir Hansson (DHH)
Straight to the point
Using RoR you will have the ability to launch apps really quickly, you do not focus on trivial aspects of your app… but on what is truly important for you instead.
What do we understand for omakase? Imagine you go to a restaurant for the first time with a friend of yours that is a regular customer. Te waiter hands you the menu and there are like 12 different options that appeal you. You would probably consider asking your friend to recommend you something, right?
This is the idea of omakase. We do not need to be experts in web development, when RoR was created, initial decisions were made for us to make our life easier. We just trust the system and its magic.
It’s a kind of magic
Below you can find an example of RoR’s elegance:
class Project < ApplicationRecord
validates_presence_of :name, :description
In just a few lines, we are modelling the behaviour of our Project:
- Each project belongs to a specific user
- Each project can have several contributors
- Each project must have a name and a description
Tough life for creative individuals and apps with specific needs
It all becomes so beautiful and simple if you stick to what Rails expects from you. However, it can become really painful to try and so things differently.
Also, if you have a rather curious mind, due to the high level of abstractions Rails has, it may not be that easy to understand what is going on under the hood.
If you have an architect spirit (the type that enjoys more building his own project than figuring out how to add to a blueprint), you may be better off using a different framework. This also applies for projects that follow a rather unconventional modelling pattern.
Basically, you have two ways of building your app. Here comes the first important decision you need to make: Scaffold or not Scaffold?
Ah! So here is my model, and my routes, and the controller, and the views! What do I do then? Well, you have two options:
- Tell your boss what a genius you are and ask for a pay rise, or…
- Do not use scaffold and build your model from the scratch following Rails conventions and helpers (forms, route paths and model objects are the ones I have used the most, but there are many more available for your to explore).
When to use scaffold
One of my personal projects is a music app that connects to the Spotify API and retrieves information about songs based on the user preferences.
This app has three models so far: Track, Playlist and User (using the Devise gem to handle everything related to the user: registration, authentication, etc.).
In my opinion, it makes sense to use scaffold for the Track and Playlist models as we need a CRUD (Create-Read-Update-Delete) for both of them, and that is something that is given to you by Rails with the generator.
These are the steps you need to follow if you want to benefit from its magic:
Create a rails app:
$ rails new <appname>
Generate the scaffold for your model as follows:
$ rails generate scaffold <model_name_in_singular> <property>:<data_type>
$ rails generate scaffold track title:string album:string artist:string release_year:integer
When not to use scaffold
The next functionality I am going to introduce in my project is the ability for users to like and unlike songs. In this case, I think it does not make much sense to generate a scaffold for this model as the only methods we need is one to like a song and another one to unlike it.
Generating a Like model specifying the relation with the Track (and User, because it is someone who likes a song) model seems enough to me. So, in app/models:
class Like < ApplicationRecord
The next step would be to define the RESTful routes for the Track model in config/routes.rb:
resources :tracks do
post ‘like’ => ‘tracks#like’
delete ‘unlike’ => ‘tracks#unlike’
Finally, we have two options to define the methods like and unlike related to a specific song. So in app/controllers, choose one of the following:
- Create two new methods in the Track controller (my choice)
- Create a new controller for Like
I hope you enjoyed this post about Ruby on Rails and that you feel encouraged to try it yourself and, hopefully, you will get to enjoy its magic as much as I do!
Do not forget to follow me not to miss future posts and, as usual, claps are highly appreciated!