Project Setup & the Current Rails Baseline

Website Rebuild with Ruby on Rails

Chapter 1 · Project Setup & the Current Rails Baseline

This is the fourth and final course in the Website Rebuild series, alongside the already-complete Next.js, Django, and Laravel rebuilds. Rails is famous for one specific idea — convention over configuration — and it's worth being honest from the very first chapter about what that phrase actually means once Laravel is already sitting in the comparison, rather than treating it as a clean, unique selling point.

Generating the Application

gem install rails
rails new website-rebuild-with-rails --database=mysql
cd website-rebuild-with-rails
bundle install

--database=mysql adds the mysql2 gem and pre-fills config/database.yml for MySQL, matching the site's own real production database rather than defaulting to Rails' own out-of-the-box SQLite. rails new generates a full directory structure in one step — app/models, app/controllers, app/views, config/routes.rb, db/ — all present before a single line of application code exists.

Convention Over Configuration — the Honest Version

Rails coined this phrase, and it's a real, defining design choice: a model class named Page maps to a pages table with zero configuration, timestamp columns are managed automatically, and a single line in routes.rb can generate a full set of RESTful routes. But Laravel Rebuild's own chapters already showed Eloquent doing several of these exact same things — automatic pluralized table names, no redeclaring columns in the model, its own one-line Route::resource(). That's not a coincidence.

Laravel's own acknowledged debt to Rails

Laravel was explicitly designed drawing on Rails' own ideas — the two frameworks are close philosophical cousins, sharing far more DNA with each other than either shares with Django's more explicit style or with Next.js/Prisma's fully separate schema DSL. Framing this chapter as "Rails infers, Laravel configures" would be inaccurate; the real, honest distinction has to be found somewhere more specific than the phrase "convention over configuration" itself.

What's Actually Rails-Specific: Ruby's Own Open Classes

# ActiveSupport extends Ruby's own core classes directly
3.days.ago
"CamelCase".underscore    # => "camel_case"
"page".pluralize          # => "pages"

3.days.ago isn't a helper function wrapping the number 3 — it's a real method call on Ruby's own Integer class, added directly to the language itself by ActiveSupport. Ruby permits this style, called monkey-patching or reopening a class, as an ordinary, idiomatic part of the language. Neither Python nor PHP's own ecosystems lean on this technique the way Rails does: Python's own community explicitly discourages patching built-in types (part of the same "explicit is better than implicit" philosophy visible in Django's own more spelled-out models), and PHP doesn't offer an equally natural mechanism for extending its built-in scalar types at all. This — not table-name inference, which Laravel already shares — is the genuinely distinguishing trait worth naming here.

Four Frameworks, Compared Honestly

	Next.js	Django	Laravel	Rails
Model-to-table mapping	Explicit — a separate `schema.prisma` DSL	Explicit — fields declared in the model class	Inferred — no field redeclaration	Inferred — no field redeclaration
URL-to-handler wiring	Implicit — folder structure alone	Explicit — `urlpatterns`	Explicit — `routes/web.php`	Explicit — `routes.rb`
Core-language extension	Not idiomatic in JS/TS	Discouraged in Python	Not natural in PHP	Idiomatic — ActiveSupport monkey-patches core classes

Not a uniquely Rails advantage

Laravel and Rails are genuinely the closest pair in this comparison on data-layer conventions specifically. The real fourth-way split shows up elsewhere in this course — Chapter 5's asset-bundling philosophy and Chapter 9's authentication chapter both land on genuinely distinct positions, not shared ones.

Hands-On Exercises

Exercise 1

Explain the real, historical relationship between Rails' convention-over-configuration philosophy and Laravel's own design, and name two specific conventions the two frameworks genuinely share.

📄 View solution

Exercise 2

Explain what 3.days.ago actually is — not what it does, but what kind of language operation it represents — and explain why this specific technique isn't something Django's or Laravel's own ecosystems lean on the same way.

📄 View solution

Exercise 3

Explain why rails new was run with --database=mysql for this specific rebuild rather than Rails' own SQLite default.

📄 View solution

Chapter 1 Quick Reference

rails new --database=mysql — generates the full application structure with MySQL pre-configured
Convention over configuration — Rails coined it, but Laravel shares much of it (pluralized table names, no field redeclaration, one-line resourceful routing)
Genuine Rails-specific trait — Ruby's own open classes, leaned on pervasively by ActiveSupport (3.days.ago, .pluralize, .underscore)
Honesty check — the real four-way split shows up in later chapters (asset bundling, authentication), not in the data layer, where Laravel is genuinely closest to Rails
Next chapter: Designing a Flexible URL & Content Model