Anyone can learn Ruby on Rails! But does everyone understand it? Ruby on Rails is extremely powerful regardless of what anyone says. It removes many complexities to building an application and allows one to focus on the more significant pieces. Rails really does make life much simpler, but to a point where you may not even understand what’s taken place under the hood. Let’s look at a couple examples:
HTML Form
<form action="/login" accept-charset="UTF-8" method="post">
<input name="utf8" type="hidden" value="✓">
<input type="hidden" name="authenticity_token" value="4fFh7...">
<label for="sessions_email_address">Email address</label>
<input type="text" name="sessions[email_address]">
<br>
<label for="sessions_password">Password</label>
<input type="password" name="sessions[password]">
<br>
<input type="submit" name="commit" value="Click to login">
</form>Rails’ Action View Form Helper
<%= form_for :sessions, url: '/login' do |f| %>
<%= f.label :email_address %>
<%= f.text_field :email_address %>
<br>
<%= f.label :password %>
<%= f.password_field :password %>
<br>
<%= f.submit "Click to login" %>
<% end %>
Comparison:
- 9 lines vs 7 lines (excluding breaks) — less typing which minimizes human error, like typos
- Cleaner code — much easier to comprehend at a quick glance
These are snippets taken from a recent project I worked on with a partner — removed some bits for a clearer and cleaner representation. In Rails we can simply pop that in, and it will generate that HTML for you! So why would one not be able to understand what’s happening behind the scenes in this scenario? Glad you asked!
RESTful Routes
Before I throw some more code into your face, allow me to introduce RESTful routes. REST stands for “Representational State Transfer,” and that means absolutely nothing to someone without a technical background — such as I was when I first came across it — but essentially it defines a standard for URLs (AKA URIs).
Thus, a RESTful route would be something like:
Believe it or not, but there was a time when URLs weren’t as pretty!
The intent was to keep the URL, but Medium automatically changes it and formats it nicely into a block link image — try hovering over it and you’ll see what I mean. Anyways, I digress.
HTTP Verbs and Requests
HTTP, in a very simplistic explanation, is a way computers communicate with each other for specific tasks like requesting data or updating some information on your profile on a social media website. For more info, click here.
Rails Routes
Well, where exactly is this headed? In Rails, you can insert a snippet like the following:
resources :photos17 characters in Rails ultimately gives you the following:
get 'photos' => 'photos#index'
get 'photos/new' => 'photos#new'
post 'photos' => 'photos#create'
get 'photos/:id' => 'photos#show'
get 'photos/:id/edit' => 'photos#edit'
patch 'photos/:id' => 'photos#update'
delete 'photos/:id' => photos#destroy
This effectively gives you the following four URLs:
- www.facebook.com/photos
- www.facebook.com/photos/new
- www.facebook.com/photos/136
- www.facebook.com/photos/136/edit
In Sinatra, a DSL language, it is basically the same thing as the latter above with the exception that the code referring to the actions taken on those respective web pages are separated in Rails according to the MVC model.
get 'photos' do
...
end get 'photos/new' do
...
end post 'photos' do
...
end etc.
You can probably now see the power of ‘resources’ in Rails! However you should use it only if you will be utilizing all the generated routes. Another option is to limit using the only option:
resources :photos, only: [:new, :create, :show]
_______________________________________________get 'photos/new' => 'photos#new'
post 'photos' => 'photos#create'
get 'photos/:id' => 'photos#show'
If you don’t explicitly mention and restrict resources, you will be providing unnecessary routes on your web application.
ORM
Object Relational Mapping is a concept, a design pattern used for structuring and organizing our programs. It provides a standard for the program to follow allowing ease of understanding and significantly reduces repetition — keeping our code DRY is very important, and we’re all lazy anyways.
You can build ORM in regular Ruby, but you can also use Active Record’s magic!
Ruby
class Song
attr_accessor :name, :album
@@all = [] def initialize(name, album)
@name = name
@album = album
@@all << self
end def self.all
@@all
endend
Active Record*
class Song < ActiveRecord::Base
end*it is normal for Song to inherit from ApplicationRecord which inherits from ActiveRecord::Base
Simply by inheriting from Active Record, you are given the manually written methods in the Ruby example above, and to many more! If you had a large program with many classes, this is cumbersome, tedious and repetitious — so why not use a tool to help ease that pain!
TL;DR
Ruby on Rails is a web framework that can get you up and running in no time. It does this with easy-to-follow procedures, bucket-loads of abstraction, and decent documentation. But with abstraction comes complexities and complications. Let’s say you decide to build a web application. Let’s say you get it working in a few days. Then let’s say it breaks and stops functioning for some odd reason. How are you going to fix it? You can scour the net for answers, especially browsing StackOverflow. You may or may not find your answer. Ideally, you want to understand your own application so you can fix it, improve it, and customize it to your liking with minimal stress. It’s like a mechanic — you must understand the parts and how they interact with one another in order to remedy issues, and improve efficiencies.
