Getting Started
🚂 Getting Started with Rails
📦 Installing Rails and Creating a New App
$ gem install rails # Rails is itself just a gem -- Ruby Course 2, Chapter 7 $ rails new blog_app $ cd blog_app $ rails server # starts the dev server at http://localhost:3000
rails new blog_app does something Express never does on its own: it generates a complete, working application skeleton — folders, a database configuration, a Gemfile with sensible defaults, and a functioning (if empty) app you can immediately run. Compare this to Express's npm init plus manually installing and wiring together every piece.
📁 The Generated Directory Structure
blog_app/ ├── app/ │ ├── controllers/ │ ├── models/ │ ├── views/ │ └── assets/ ├── config/ │ ├── routes.rb │ └── database.yml ├── db/ │ ├── migrate/ │ └── schema.rb ├── Gemfile └── Gemfile.lock
Every one of these folders already exists, already has a defined purpose, and Rails' generators (previewed at the end of this chapter) know exactly where new code belongs. app/controllers, app/models, and app/views aren't a structure you invent — they're the framework's built-in Model-View-Controller layout, present the moment rails new finishes running.
⚖️ Convention Over Configuration
This is Rails' central idea, and it's worth stating plainly: if you follow Rails' naming conventions, an enormous number of decisions get made for you automatically, with no explicit configuration required.
Naming implies wiring
A controller named PostsController automatically lives at app/controllers/posts_controller.rb, automatically renders views from app/views/posts/, and — once Chapter 2 covers resources :posts — automatically gets a full set of RESTful routes, with zero additional configuration.
Database tables, inferred
A model named Post automatically maps to a database table named posts (pluralized, snake_case) — Active Record (Chapter 5) infers this mapping rather than requiring it to be spelled out anywhere.
🏗️ MVC: Baked In vs Hand-Assembled
Recall Express Course 1's final chapter, which walked through manually organizing a Controller-Service-Model structure: a hand-written src/controllers/, src/services/, src/models/, and src/routes/, each layer wired together explicitly by you, one require and one router mount at a time. Rails' app/controllers, app/models, and app/views aren't something you build — they exist from the first command.
Project Structure: Express vs Rails
| Concern | Express (hand-assembled) | Rails (built in) |
|---|---|---|
| Where does this exist? | You design and create it yourself | Generated automatically by rails new |
| Controllers | src/controllers/ (your convention) | app/controllers/ (Rails' convention) |
| Models / data access | src/models/ (your convention) | app/models/ (Rails' convention, Active Record built in) |
| Business logic layer | src/services/ — Express has no opinion, you invented this layer | No built-in equivalent — Rails traditionally puts logic in models ("fat models"); a services layer is a common addon pattern, not a framework default |
| Route wiring | Manual router.use() mounting per resource | config/routes.rb, often one resources line per resource |
Express's explicitness means every piece of wiring is visible somewhere in your own code — nothing happens that you didn't write. Rails' conventions mean a lot happens that you didn't write, inferred purely from a file's name and location. This is faster once you know the conventions, and genuinely confusing before you do — "magic" is the word often used, sometimes as praise, sometimes as a complaint. Expect an adjustment period where things work and you're not entirely sure why, before the conventions click.
🏭 A First Taste of Generators
$ rails generate controller Welcome index
create app/controllers/welcome_controller.rb
create app/views/welcome/index.html.erb
route get "welcome/index"
rails generate (often shortened to rails g) scaffolds files following Rails' conventions instantly — a controller file, a matching view, and even a route entry, all created and correctly wired together in one command. This is the generator mechanism Chapters 2 through 8 lean on repeatedly for routes, models, and migrations.
📜 Starting a Project: Express vs Rails
Side by Side
| Step | Express | Rails |
|---|---|---|
| Create the project | npm init, then manually install express | rails new blog_app |
| Project structure | You design it (express1-8 walked through one approach) | Generated automatically, following Rails conventions |
| Start the dev server | node server.js (or nodemon) | rails server |
| Scaffold a new resource | Manually create controller/service/model/route files | rails generate controller/model/scaffold |
💻 Coding Challenges
Challenge 1: Tour the Generated App
Run rails new library_app (or read through the structure shown in this chapter if you don't have Rails installed locally) and write one sentence each describing the purpose of app/, config/, db/, and the Gemfile.
Goal: Build a working mental map of where things live before writing any actual Rails code.
Challenge 2: Map Express's Structure Onto Rails
Using the Express project structure from this chapter's comparison table (src/controllers, src/services, src/models, src/routes), write down which Rails folder each one maps to — and explicitly note which one has no direct Rails equivalent, and why.
Goal: Practice translating a structure you already know into Rails' conventions.
Challenge 3: Generate a Controller
Write the exact command to generate a controller called Products with two actions, index and show. List every file (and route entry) you'd expect Rails to create as a result, based on the pattern shown in this chapter's Welcome example.
Goal: Predict a generator's output before running it, based on the naming conventions covered so far.
Nearly every chapter from here on is some version of the same trade: Rails gives up some of Express's explicitness in exchange for dramatically less boilerplate, as long as you're building something that fits its conventions. That's a genuinely different bet than Express's philosophy — neither is simply "better," and this course will keep pointing out exactly where that trade shows up, starting with routing in the next chapter.
🎯 What's Next
Next chapter: Routing — config/routes.rb, and how a single resources :posts line generates all seven RESTful routes Express would otherwise need defined one at a time.