Foreword to the Rails 7 Edition

• One of the secrets of Rails is something that its creator, David Heinemeier Hansson, calls conceptual compression. A careful building and layering of abstractions let you quickly start a task. Then, if and when you need to go deeper and take more control of a particular aspect of Rails, you can. You’ll see this in every facet of Rails. For example, ActiveRecord—Rails’ database layer—helps you quickly get data in and out of databases yet allows you to drop down to SQL when needed.

Introduction

• But Rails takes MVC further: when you develop in Rails, you start with a working application, each piece of code has its place, and all the pieces of your application interact in a standard way.
• It also allows us to perform tasks that would normally be done in external configuration files inside the codebase instead.
• Every piece of knowledge in a system should be expressed in one place.
• Developers coming to Rails find something else too. Rails doesn’t merely play catch-up with the de facto web standards: it helps define them.
• Rails was extracted from a real-world, commercial application. It turns out that the best way to create a framework is to find the central themes in a specific application and then package them in a generic foundation of code. When you’re developing your Rails application, you’re starting with half of a really good application already in place.
• Over the years since Rails was introduced, the term agile has gone from being relatively unknown to being overhyped, to being treated as a formal set of practices, to receiving a well-deserved amount of pushback against formal practices that were never meant to be treated as gospel, to a return back to the original principles.
• Agile Manifesto Values:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
• Rails is all about individuals and interactions. It involves no heavy toolsets, no complex configurations, and no elaborate processes, just small groups of developers, their favorite editors, and chunks of Ruby code. This leads to transparency; what the developers do is reflected immediately in what the customer sees. It’s an intrinsically interactive process.
• The Rails development process isn’t driven by documents. You won’t find 500-page specifications at the heart of a Rails project. Instead, you’ll find a group of users and developers jointly exploring their need and the possible ways of answering that need. You’ll find solutions that change as both the developers and the users become more experienced with the problems they’re trying to solve. You’ll find a framework that delivers working software early in the development cycle. This software might be rough around the edges, but it lets the users start to get a glimpse of what you’ll be delivering.
• In this way, Rails encourages customer collaboration. When customers see how quickly a Rails project can respond to change, they start to trust that the team can deliver what’s required, not just what’s been requested. Con- frontations are replaced by “What if?” sessions.
• The agile way of working that Rails encourages is tied to the idea of being able to respond to change. The strong, almost obsessive, way that Rails honors the DRY principle means that changes to Rails applications impact a lot less code than the same changes would in other frameworks. And since Rails applications are written in Ruby, where concepts can be expressed accurately and concisely, changes tend to be localized and easy to write. The deep emphasis on both unit and system testing, along with support for test fixtures and stubs during testing, gives developers the safety net they need when making those changes. With a good set of tests in place, changes are less nerve-racking.
• The Rails team has chosen not to include plenty of features—such as user authentication—in the Rails framework itself. That doesn’t mean that these features aren’t important, but it generally does mean that no single solution is the obvious default for Rails users.

Chapter 1: Installing Rails

• If you want to connect to a database other than SQLite 3, Rails also works with DB2, MySQL, Oracle Database, Postgres, Firebird, and SQL Server. For all but SQLite 3, you’ll need to install a database driver—a library that Rails can use to connect to and use with your database engine. This section contains links to instructions to get that done.

Chapter 2: Instant Gratification

• As you can see from the bin/ prefix, this is running the rails command from the bin directory. This command is a wrapper, or binstub, for the Rails executable. It serves two purposes: it ensures that you’re running with the correct version of every dependency, and it speeds up the startup times of Rails commands by preloading your application.
• The localhost part of the address means that the Puma web server will only accept requests that originate from your machine.