After that last guide you should have a decent idea on how the routes are mapped to actions in the controller. We have taken a look at the view files, but we aren’t going to delve too deeply on those right now because there is complete section on the views later in the course. What you should clearly understand about the view file is there is a direct mapping to it’s action. Let’s open the views/blog directory

Names are Vital

As I mentioned before, the naming of views is vital. Rails works on a strong convention side. In fact, there is a term for it called "convention over configuration”. This conventionality in Rails means there are a number of settings and other items that run in the background that simply process. They do this so you do not have to manually set up the configuration options.

For example, built in to the Rails code is the process where it will look at the name of the index action and recognize it is in our blogs controller. The process then automatically knows that it has to go to views/blogs directory, look for the index.html.erb file and that it needs to pass the value of @blog variable to be available in that view.

Let's rename the index.html.erb file to something else like ‘indexasdf.html.erb' (if you right click on the file name in sublime it will give you the option to rename the file). Back in the terminal restart the rails server and refresh the browser. This will throw an error, like this:

The error says that the BlogsController#index is missing a template. What this error indicates is that it looked for a file called index.html.erb and couldn't find it. Let's revert back to the original file name, and everything will work fine.

I wanted to show you this so you understand the importance of the mapping system and why the naming convention is vital.

Layouts

The other subdirectory in the views file is layouts. We will go into detail about how to work with the main layout file as well as how to create multilpe layout files and how you can use them based on what type of page is being viewed . For now, go to views/layouts and you'll see a file called application.html.erb. This is the funnel that all of the view items are getting passed through. You will note on line 12 a special word called yield. Each view we have such as blog new or blog edit are being called and rendered in the yield section of this file. We have an entire section dedicated to layouts, so we'll discuss this in further detail then.

Bin

The next folder in the file system is named bin. This is one folder that I don't think you'll possibly ever use in your career. I don't ever remember the last time I had to make any changes in there. Just know, this is where the binaries are stored.

Config

Next is the config directory, and you will be working quite a bit in this one.

Environments

The environments directory contains all the setting specific to your environments. There are three files, one each for the development, production and test environments respectively. The developers of Rails wanted to keep these environments separate so you could have different settings depending on if you were in your test environment instead of development.

If you are new to environments, just remember that your development environment is where you write your code and make all your changes. It is usually what you are using locally. When we push our application up to a server, as we will do later on in the course, we will then be in production mode. This is when your product is live, so this will have a different list of settings for example, how it processes caching and and how it compresses javascript. You don't have to know all the contents of these files, but just know that there are different settings based on which environment your app is running in.

While we won’t be getting into it in this course, there is also a testing environment that you can use to run all your tests in.

Initializers

Moving down the file system you will find your initializers directory. Initializers are code files that will run before your application begins running.

A real world example would be that you need to connect to an API, such as the Google Maps API, but your api needs to be running before your app starts up. You can setup that connection right here in the initializers. These file will run before the application starts, so all the connections will be set.

There are all kinds of things you can set in your initializers. One of those are your assets. You can customize the assets.rb files so you have the ability to store videos, and other similar processes.

Another interesting file you can customize is inflections.rb. Rails has a cool way of working with plural and singular words. Now, if you remember we ran our generator we created something called a “blog" (notice we did not make it plural), but Rails has generated a file called blogs_controller.rb. The ability to take the singular form of a word and create these plural items is done through this process of inflections. For this reason I usually like to keep very simple words for my generators, models and controllers. However if Rails is not recognizing something as singular or plural, or it is setting it up wrong and you need to override it, you can do that here in theinflections.rb file.

This file has rules for overriding certain words like ox, person, fish, sheep and things like that. I’ve only used this file a handful of times in my career, but it is there if you need to use it.

There are some other files as well, like mime_types.rb which has rich text available.

New to Rails 5 is new_framework_defaults.rb which has some settings like preserving time zone.

Sessions_store.rb is where all your cookies are. This is a basic configuration and you could override it and have make something more robust, such as keeping your cookies in a Redis database. We will cover Redis later in the course, but we will not be overriding this file. For 99% of cases this cookie store works perfectly fine.

Application.rb

Moving down the file system you will see locales folder and inside you'll find a file called application.rb. This is the main application file. If you're coming from other programming languages and are used to seeing a main function, then this file is similar to that.

Your application.rb file is where all the magic happens. This is where your app starts and loads up. You require rails and you have several rails frameworks that are built into the system. You can also add any kind of custom builds you need to this file. You can think of application.rb as the master of all the initializer files as it is the first to run. We will get into this later on in the course as we customize a few things for our application.

Secrets

Another file that we're going to look at is secrets.yml. This is a cool file as it allows you to securely store your secret keys. You could also store API keys here as well as anything that you need to keep secure. This file will not be pushed to your repositories such as github or another version control system. Only you and the local copy of your application will be able to access this file.

Database

The last file we will discuss from our config directory is database.yml. This is where you set your database, create a username and password for your database, and name all your tables.

Imagine you forgot to add the database flag when you created your app. You can see this file lists adapter (line 18), followed by the database we are using (postgresql). This is where you could set the correct database you wanted to use. If you have been following along with me, you shouldn’t have to make any change to this file throughout this course. However, if you have made any mistakes you can correct them here.

DB

Next, our db folder contains our migration, schema and seeds files. The seeds.rb file is where we'll give create sample data to test our system on the browser.

Lib

lib is where we put custom rake tasks and any custom algorithms we don’t want to have in the application itself.

Log

log is where our error messages will be stored.

As for the other directories, you won't have to deal with them for this application, and rarely in other applications. A lot of these folders found the bottom of your file tree were used in previous versions of Rails, but are not used now even though we keep them here.
So, that is your comprehensive dive into the file system. We have walked through how the scaffold generated all that functionality for us. You should have a better idea of the flow and processes and how they work in Rails 5.