You didn’t have to configure anything to get a basic Rails application up and running. In Rails, this concept is known as convention over configuration. As long as you follow the Rails conventions, everything should just work.

Rails makes many choices for you when you create an application. Those choices include which web server and database server to run in development mode and which JavaScript library and testing library your application will use. Even the names of your application’s database tables and models are chosen automatically based on convention. You can certainly break convention and change those settings if you’d like, but then you’ll have to configure some things for yourself.

The other key principle in Rails is don’t repeat yourself, often abbreviated DRY. In Rails, you avoid duplicating knowledge within your application. Specifying the same information in more than one place can lead to errors when you change one instance and not the other.

You’ll see several examples of the DRY principle as we work our way through the Rails architecture and directory structure. There is a single, specific place for each part of a Rails application. Things that can be inferred from another source, such as the names of columns in a database table, don’t need to be specified anywhere.

The model represents your application’s data and the rules for manipulating that data. The application’s data is sometimes referred to as the application’s state. The rules for manipulating this data are also known as business logic. All changes to your application’s state must pass through the model layer.

Rails models contain code for data validation and associations between models. Most of the code you write will be inside of a Rails model, unless it is directly involved with the user’s view of the data.

The view is the user interface for your application. Because we are building web applications, the view will consist mainly of HTML. Rails uses a template system called Embedded Ruby (ERB) by default.

Embedded Ruby allows you to include Ruby code for accessing data within an HTML template. When the user requests a page, the Ruby code in the template is evaluated by the server, and the resulting HTML page is sent to the user.

The ability to embed Ruby code inside a view can sometimes lead programmers to include too much code inside a view. Doing this is problematic because if you add another view, then that code will need to be duplicated. Code used only by the view can be moved to a helper, which is a method meant specifically for use in the view. In general, a view should never contain code more complex than a simple conditional statement.

The controller is like the glue that holds together the model and the view. The controller is responsible for accepting a request from the user, gathering the necessary data from the model, and rendering the correct view. This sounds like a lot of work, but thanks to the conventions used in Rails applications, the process happens almost automatically.

In Rails, the controller is simply a Ruby class with methods that correspond to the various actions in your application. For example, in your blog application, you have a method named show for displaying a blog post and a method named new for adding a new post.

The app directory is where you’ll spend most of your time while building your application. It contains subdirectories for each part of the MVC architecture discussed previously, as well as assets, helpers, and mailers.

The assets directory holds the images, JavaScript files, and CSS style-sheets used by your application. The helpers directory contains Ruby files with methods used by your views. The mailers directory is for Ruby classes used to send email.

The bin directory holds simple Ruby scripts for accessing the bundle, rails, and rake command-line programs used while building your application. These scripts ensure that the three programs run in the context of the current Rails application. You can have multiple versions of these programs installed at the same time, which can lead to errors if you don’t use the scripts in bin to access them.

Rails makes heavy use of convention over configuration, but sometimes configuration is unavoidable. In those cases, look to the config directory.

The environments subdirectory contains configuration files for the three different environments created automatically by Rails. An environment is a collection of settings used for a specific purpose such as development or testing. These settings are stored in development.rb (used while developing your application), test.rb (used while running automated tests), and production.rb (used after your application is deployed and running in production).

The file application.rb contains the settings for all environments. Information in one of the specific environment files just mentioned will, however, take precedence over settings here.

The file database.yml holds database configuration for each of the three environments. Rails creates a SQLite database, by default, when you run rails new, so the default settings in database.yml are for that SQLite database. This database is a single file that you will use during development. You usually want to specify a different database server to use in production.

The file routes.rb maps the web address entered by the user to a specific controller and action in your application. As you add resources and actions to your application, you need to update this file to reflect the changes. I cover resource-based routing during the discussion of controllers in Chapter 4.

The db directory initially contains only a single file called seeds.rb. Use this file to create your application’s default data. For example, in an application with user accounts, you may want to include a special “admin” user here.

As you build your application, you will create database migrations, Ruby scripts that create and modify the tables in your database. A directory named migrate is created to hold these database migration files. The file schema.rb, which shows the current state of your application’s database, is created as well. If you use the default SQLite database in your application, the database itself is also placed in this folder.

The lib directory is the place to put any reusable library code you write. This directory is initially empty except for two subdirectories: assets and tasks. Assets are images, CSS stylesheets, and JavaScript files. Tasks are Ruby scripts used to automate actions such as managing your application’s database, clearing log and temporary files, and running tests. These tasks are executed using the rake command.

As your application runs, data is written to a file in the log directory. When you run your code in the development environment, this file is named development.log. Separate files will be created for the test and production environments.

Files in the public directory are sent to users as if the files were in the root directory of your application. For example, three files in this directory are for error messages—404.html, 422.html, and 500.html. You can see one of these files in your browser by adding its name to your address bar. If you visit http://localhost:3000/404.html, for example, you should see the default “page does not exist” error page.

This directory also holds a default favicon.ico, the image that appears in the address bar of most browsers, and a robots.txt file that controls how search engines index your application. You can modify all of these files for your application. You’ll probably want to customize the error pages with your own branding and add a custom favicon for your site.

The test directory contains subdirectories with automated tests for each part of your application. It also holds the script test_helper.rb, which loads the test environment settings in config/environments/test.rb and adds helper methods used in your tests.

Some Rails developers practice test-driven development (TDD). In TDD, you first write an automated test describing a new feature; then you add just enough code to make the test pass; and finally you refactor, or restructure, the code as needed to improve readability and reduce complexity.

The tmp directory contains ephemeral files. Here, you find cached copies of your application’s assets, process id files (pids) for running programs (such as your web server), user sessions, and files representing sockets being used by your application.

Finally, the vendor directory holds assets needed by third-party gems that you add to your application. Its purpose is similar to the lib directory, except it is used by libraries that you did not write yourself.

The gem command installs Ruby gems. The Rails framework is actually distributed as a collection of gem files.

Your newly created Rails application is made up of over 40 gems. Maintaining the correct versions of these gems and dependencies between them can get complicated. For this reason, you rarely use the gem command directly; instead, you usually rely on a tool called Bundler to manage gems and keep your dependencies up to date. You interact with Bundler using the bundle command.

The bundle command is used to install and update the gems needed by your application. It installs gems by reading the Gemfile that was automatically created by the rails new command in the root directory of your Rails application. It stores the version numbers of gems you’re using and their dependencies in the file Gemfile.lock.

The bundle list command displays the names and versions of all gems currently being used by your application:

$ bin/bundle list

As mentioned earlier, we are using the copy of bundle inside the bin directory.

The rake command is an automated build tool used to run tasks related to your application. (If you are familiar with the make command, rake is the Ruby version.) Enter this command to obtain a list of the available tasks for your application:

$ bin/rake --tasks

This command prints a list of tasks your application can use along with a short description of each to your terminal. Some gems add tasks to your application, and you can also add your own tasks by writing Ruby scripts and saving them in the lib/tasks directory.

You used the rails command earlier to create an application and start the server. You can also use this command to generate new code and launch the console. Enter the rails command by itself to list the available options:

$ bin/rails

In addition to the new command that you used to build your application and the server command that starts a web server, Rails also provides several other helpful commands. These include the generate command (generates new code), the console command (starts an interactive Ruby console with your Rails application preloaded), and the dbconsole command (starts a command-line interface for the currently configured database).

Now that you’ve seen some Rails command-line tools, let’s use a few of them to add some functionality to the blog application we created.