What is a development environment?

The kitchen before the restaurant

You just got hired as a chef at a new restaurant. Day one, you walk in and the kitchen is completely empty: no stove, no knives, no fridge, no ingredients. You cannot cook a single dish until that kitchen is set up.

Building software works the same way. Before you write a single line of Ruby code, before you run rails server, before you see your app in a browser: you need a development environment. This is the kitchen where all your coding happens.

Skipping the setup means hitting cryptic errors later. Getting it right means your tools work together smoothly every single day.

What a development environment contains

A development environment is the complete set of tools installed and configured on your computer so you can write, run, test, and debug code. For a Rails developer on macOS, these are the essential pieces:

+-------------------------------------------+
|         YOUR DEVELOPMENT ENVIRONMENT      |
|                                           |
|  +-------------+  +-------------------+   |
|  | Code Editor |  | Terminal / Shell  |   |
|  | (VS Code)   |  | (Terminal + Zsh)  |   |
|  +-------------+  +-------------------+   |
|                                           |
|  +-------------+  +-------------------+   |
|  | Language    |  | Package Manager   |   |
|  | Runtime     |  | (Homebrew)        |   |
|  | (Ruby)      |  +-------------------+   |
|  +-------------+                          |
|                   +-------------------+   |
|  +-------------+  | Version Manager   |   |
|  | Database    |  | (rbenv)           |   |
|  | (PostgreSQL)|  +-------------------+   |
|  +-------------+                          |
|                   +-------------------+   |
|  +-------------+  | Web Framework     |   |
|  | Git (VCS)   |  | (Rails)           |   |
|  +-------------+  +-------------------+   |
+-------------------------------------------+

Each piece has a specific job:

Why macOS is the industry standard for Rails

Open your Terminal right now and type:

uname -s

You will see:

Darwin

That single word reveals something important. Darwin is the name of the macOS kernel, and it is built on top of BSD Unix. This means macOS is a Unix-based operating system at its core.

Why does this matter for Rails? Because production servers (the computers that run your app for real users) almost always run Linux, which is also Unix-based. The commands, file paths, permissions, and process management you learn on macOS transfer directly to production.

  macOS (your laptop)          Linux (production server)
  +------------------+         +------------------+
  | Darwin Kernel    |         | Linux Kernel     |
  | (BSD Unix base)  |         | (Unix-like)      |
  +------------------+         +------------------+
  | Same commands:   |         | Same commands:   |
  | ls, cd, grep,    |         | ls, cd, grep,    |
  | chmod, ps, kill  |         | chmod, ps, kill  |
  +------------------+         +------------------+

On Windows, these commands do not exist natively. Windows developers use WSL (Windows Subsystem for Linux), which runs a real Linux kernel in a lightweight virtual machine, to get the same experience macOS provides out of the box.

This Unix foundation also means macOS has a proper file permission system (chmod, chown), process management (ps, kill), and a Unix shell (Zsh). These are not extras: Rails depends on them. When an app's bin/dev runs several processes (a Rails server plus a CSS watcher, say), it uses a tool called Foreman that spawns Unix processes. When you deploy, your server uses the same process model.

The difference between system tools and developer tools

macOS ships with some developer tools pre-installed, but they are often outdated or limited:

/usr/bin/ruby --version

ruby 2.6.10p210 (2022-04-12 revision 67958)

That system Ruby is years behind the current version. It exists so macOS internal scripts can run, not for you to build applications with. The same applies to system Git, system Python, and others.

Your development environment replaces these with current versions you control:

# After setting up your dev environment:
which ruby
# /Users/yourname/.rbenv/shims/ruby

ruby --version
# ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25]

Notice the path difference. System Ruby lives in /usr/bin/ruby (owned by Apple). Your Ruby lives in your home directory (owned by you). This separation is critical: you never want to modify system tools, and you always want full control over your development tools.

How the pieces connect in a Rails workflow

Here is what happens when you run rails new my_app after your environment is set up:

1. Shell (Zsh) receives your command
2. Shell finds the rails executable through rbenv shims
3. rbenv activates the correct Ruby version
4. Ruby runs the Rails gem code
5. Rails generates project files and runs bundle install
6. Bundler downloads gems (Ruby libraries) from the internet
7. Rails writes config/database.yml (SQLite by default; PostgreSQL if you pass --database=postgresql)
8. You open the project in VS Code
9. You run bin/dev in the Terminal, which starts the Rails server
10. Your browser shows the running application

Every single tool in your development environment participated. If any one of them is missing or misconfigured, the chain breaks.

Common mistakes

"I will just use system Ruby": System Ruby is locked to an old version and requires sudo to install gems. This leads to permission errors and version conflicts. Always use a version manager.

"I will set everything up later when I need it": Environment issues compound. Installing PostgreSQL after you have already started a project means reconfiguring database connections, dealing with incompatible native extensions, and losing time.

"My friend uses Linux, so the setup is the same": The concepts are identical, but the commands differ. Homebrew is macOS-specific. Linux uses apt, yum, or pacman. File paths differ too (/opt/homebrew on macOS vs /usr on Linux).

The connection to Rails

Rails is opinionated: it assumes your environment is set up a certain way. The Gemfile assumes you have Bundler. config/database.yml assumes your database server is running (PostgreSQL, in this course). bin/dev installs Foreman itself when the app needs it. rails server assumes Ruby is in your PATH.

Every lesson in this course installs and configures one piece of that environment. By the final lesson, you will run rails new and everything will work because every dependency is in place.

This is not busywork. Senior developers maintain their environments carefully. When something breaks in production, the first question is always: "Can you reproduce it locally?" That requires a properly configured development environment.

Summary