Ruby on Rails.

Ruby on Rails is a server-side web framework written in Ruby. It organizes an app with the Model-View-Controller (MVC) pattern, which has three parts.

• The model holds the data and business logic, and talks to the database through Active Record.
• The view is the presentation layer, usually HTML built from Embedded Ruby (ERB) templates.
• The controller receives each request, asks the models for data and picks the view.

Rails also follows convention over configuration, so common tasks need little setup. Don't Repeat Yourself (DRY) keeps each piece of logic in one place, which makes code easier to maintain.

rails new generates the same directory structure for every app, so developers know where code lives. The key folders are:

• app/ holds the application code, with subfolders for models, views and controllers. helpers and assets have their own subfolders there too.
• config/ holds the configuration, such as routes and database settings.
• db/ holds the database schema, the migrations and the seed data.
• lib/ holds your own modules and libraries.
• public/ holds static files that the web server serves directly.
• test/ or spec/ holds the tests.
• vendor/ holds third-party code.
• Gemfile lists the gem dependencies.

A symbol is an immutable name that Ruby stores only once, while a string is mutable text, and each "name" literal creates a new object. So every :name in a program is the same object.

That makes symbols a good fit for hash keys and other identifiers:

• They save memory, because every use of a key shares one object.
• Comparing two symbols only checks that they are the same object, which is faster than comparing strings character by character.
• They cannot change, so a key cannot be modified by accident.

# Symbol - same object_id
:name.object_id == :name.object_id  # true

# String - different objects
"name".object_id == "name".object_id  # false

Rails uses symbols for option keys, like validates :email, presence: true. Request params accept both kinds of key, so params[:id] and params["id"] return the same value.

Convention over Configuration means Rails assumes what you want from standard names and places, so you write configuration only when you break a convention. Some of those conventions:

• The model User maps to the database table users.
• The controller UsersController handles the /users routes.
• Every primary key is named id.
• A foreign key is the singular table name plus _id, like user_id.

Following them means less code to write, and every Rails project looks familiar to a new developer.

A migration is a Ruby class that changes the database schema one step at a time, so the schema evolves in a consistent way. You describe the change in a Ruby domain-specific language (DSL) instead of SQL. A migration written only in this DSL works on any database Rails supports.

• Each file name starts with a timestamp, and Rails records the ones it ran in the schema_migrations table. That gives the schema version control.
• Teammates get new migrations with the code and run bin/rails db:migrate to catch up.
• Rollback with bin/rails db:rollback reverts the last migration. Rails can reverse a change method by itself when every command in it is reversible, like create_table or add_column. Raw SQL and other irreversible steps need separate up and down methods.

class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :email
      t.timestamps
    end
  end
end

Each run updates db/schema.rb, the schema snapshot used to build a fresh database.

find and find_by return a single record, while where returns a collection of every match, even when nothing matches.

• find searches by primary key and raises ActiveRecord::RecordNotFound if the record is missing.
• find_by takes any conditions and returns the first match, or nil if there is none. Its bang version, find_by!, raises instead.
• where returns an ActiveRecord::Relation. The query does not run until you use the records, so you can chain more conditions first. When nothing matches, you get an empty relation, not nil.

User.find(1)                    # Raises error if not found
User.find_by(email: "a@b.com")  # Returns nil if not found
User.where(active: true)        # Returns Relation (chainable)

Use find when the record must exist, find_by when it may not, and where when you need a set of records.

render builds the response from a template within the current request, while redirect_to tells the browser to send a new request to another URL.

• render :new shows the new template without running the new action. Instance variables from the current action, like @user with its errors, stay available to the view.
• redirect_to @user sends a 302 response with the new URL. The browser then requests that page, so the target action runs from the start and the old instance variables are gone.

def create
  @user = User.new(user_params)
  if @user.save
    redirect_to @user  # New request to show action
  else
    render :new, status: :unprocessable_entity  # Renders new template with @user errors
  end
end

That gives the usual pattern for forms. After a successful save, redirect, so refreshing the page does not submit the form again. After a failed save, render the form again with status 422. Turbo, the JavaScript library new Rails apps include since Rails 7, only shows a form response that redirects or carries an error status.

rails console opens an interactive Ruby session with the app loaded, and its options decide which data you touch and whether changes stay.

• rails console, or rails c, starts the standard console in the development environment.
• rails console --sandbox starts sandbox mode, which wraps the session in a database transaction and rolls back every change when you exit.
• rails console -e production loads the production environment, so your commands act on live data.
• rails dbconsole, or rails db, opens the database client, such as psql, with the app's connection settings.

# Sandbox mode - all changes rolled back
rails console --sandbox

# Production console
RAILS_ENV=production rails console

Use sandbox mode to try a risky query safely, and take extra care in a production console, where every change is real.

Rails runs an app in one named environment at a time, chosen by the RAILS_ENV variable, and loads that environment's settings on boot. Three come by default:

• development reloads code after every change, shows detailed error pages and includes debugging tools like the web console.
• test runs the test suite against its own database, loads fixtures and rolls back each test's changes.
• production is tuned for performance. It loads all code once at boot, turns on caching and hides error details from users, so teams add error monitoring there.

# Check current environment
Rails.env.development?  # true/false
Rails.env  # "development"

# Environment-specific code
if Rails.env.production?
  # Production-only code
end

Each environment has its own file in config/environments/ and its own section in config/database.yml. To add a custom environment such as staging, you create both yourself.

# Custom environments
RAILS_ENV=staging rails server