Intro to Ruby on Rails

Analogy categoryAnalogies

Ruby on Rails is a full-stack web application framework written in Ruby, created by David Heinemeier Hansson in 2004. Rails popularized two ideas that still shape modern web development: convention over configuration and don't repeat yourself (DRY). Instead of forcing developers to make dozens of upfront decisions about file layout, naming, and database mapping, Rails supplies sensible defaults, so a table named orders automatically maps to a model class Order, and a controller action index automatically looks for a view named index.html.erb. This lets teams focus on business logic instead of plumbing, and it is why Rails remains a common choice for startups and internal tools that need to ship features quickly.

🏏

Cricket analogy: Rails' convention over configuration is like a franchise auto-assigning a player to their natural batting position based on their name in the roster, rather than making the captain decide field placements from scratch every match.

The MVC architecture

Rails organizes application code using the Model-View-Controller pattern. Models, built on ActiveRecord, encapsulate business logic and talk to the database. Views render HTML (or JSON) responses, typically using embedded Ruby (ERB) templates. Controllers sit between the two: they receive an HTTP request from the router, invoke model methods to fetch or mutate data, and select a view (or redirect) to produce the response. This separation keeps concerns isolated — a controller action like def show; @post = Post.find(params[:id]); end should contain almost no rendering logic, while the view file focuses purely on markup.

🏏

Cricket analogy: Rails' MVC split is like a match where the umpire (controller) receives the appeal, consults the scorer (model) for the actual data, and then signals the decision to the big screen (view), each role staying in its lane.

Routing and RESTful resources

The config/routes.rb file maps incoming URLs to controller actions. Rails encourages RESTful design through the resources helper, which generates seven conventional routes (index, show, new, create, edit, update, destroy) for a single line of configuration. This single convention removes an enormous amount of boilerplate that other frameworks require developers to write by hand, and it establishes a predictable URL structure across the entire application — /posts for the collection, /posts/:id for a single resource, and so on.

🏏

Cricket analogy: The resources helper generating seven routes from one line is like a cricket board's fixture generator auto-scheduling a full home-and-away season from a single team list, instead of manually drafting every match date.

ruby

# config/routes.rb
Rails.application.routes.draw do
  resources :posts do
    resources :comments, only: [:create, :destroy]
  end
  root "posts#index"
end

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  before_action :set_post, only: [:show, :edit, :update, :destroy]

  def index
    @posts = Post.published.order(created_at: :desc)
  end

  def show
  end

  def create
    @post = Post.new(post_params)
    if @post.save
      redirect_to @post, notice: "Post created successfully."
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def set_post
    @post = Post.find(params[:id])
  end

  def post_params
    params.require(:post).permit(:title, :body, :published)
  end
end

Generators and the Rails ecosystem

Rails ships with generators that scaffold common code: rails generate model Post title:string body:text creates a migration, a model, and test stubs in one command. Beyond the core framework, Rails apps typically pull in gems from Bundler for authentication (Devise), background jobs (Sidekiq or Active Job), and asset pipelines (Propshaft or Sprockets). Rails 7 introduced Hotwire (Turbo and Stimulus) as the default approach for building fast, mostly-server-rendered interactive UIs without writing a large client-side JavaScript framework.

🏏

Cricket analogy: Rails generators scaffolding a model in one command is like a cricket academy issuing a full training kit, kit bag, and drill sheet the moment a new recruit signs up, instead of assembling gear piece by piece.

Compared to Django (Python), Rails and Django share nearly identical philosophies — both favor MVC (or MVT in Django's terminology), an ORM, and generators — but Rails leans further into 'magic' conventions like automatic pluralization of model names, whereas Django asks you to declare more explicitly, such as URL patterns in a dedicated urls.py per app.

Mass-assignment vulnerabilities were once a serious Rails security issue before 'strong parameters' became mandatory. Never bypass params.require(...).permit(...) with params.permit! in production controllers — it allows any client-supplied attribute, including things like admin: true, to be written to the database.

Rails follows convention over configuration, reducing boilerplate by assuming sensible defaults for naming and file structure.
The MVC pattern separates data (ActiveRecord models), presentation (ERB views), and request handling (controllers).
The resources routing helper generates seven RESTful routes from a single declaration.
Generators like rails generate model and rails generate controller scaffold boilerplate quickly.
Strong parameters via permit/require protect against mass-assignment vulnerabilities.
Rails 7 defaults to Hotwire (Turbo + Stimulus) for interactivity instead of a heavy client-side JS framework.

Practice what you learned

1. What design philosophy is Rails most associated with, alongside DRY?

2. In Rails MVC, which layer is responsible for talking directly to the database?

3. What does `resources :posts` generate in routes.rb?

4. Why are 'strong parameters' required in Rails controllers?

5. What is Hotwire, as used by default in Rails 7+?

Was this page helpful?

RSpec Testing Basics

ActiveRecord Basics

Related Study Notes in Programming

Browse all study notes

Programming

Apache Spark Study Notes

Programming · 30 topics

Programming

Apache Flink Study Notes

Programming · 30 topics

Programming

Hadoop Study Notes

Programming · 30 topics

Programming

Snowflake Study Notes

Programming · 30 topics

Programming

Apache Airflow Study Notes

Programming · 30 topics

Programming

dbt (Data Build Tool) Study Notes

Programming · 30 topics

Topics covered

#Ruby#RubyStudyNotes#Programming#IntroToRubyOnRails#Rails#MVC#Architecture#Routing#StudyNotes#SkillVeris

Intro to Ruby on Rails