[MUSIC]

Hi I'm Jason the Ruby teacher here at Treehouse.

In this workshop we're going to take a walkthrough of a Ruby on Rails

application.

Now when you work with a Ruby on Rails application there's

a few different directories that Rails sets up for you.

Now depending on how you're coding and

needing to get familiar with the Rails application, different reports go where?

Now we're gonna go through and

see what each different part of a Rails application does.

So here I have a Rails application.

Now what I'm using right now is the ODOT application and

there will be a link to that down in the video notes here.

You can follow along with this project if you want to, or

just download the files to follow along.

Now, this would be the same if we generated a new Rails application,

however, there is existing code, so we're using this for demonstration purposes.

So what you'll notice if we look at the root of

a Rails folder we have a few different files on the left-hand side here.

We have an Gitignore file which stores

all of the files that will be ignored or kept out of version control in Git.

This is gonna be everything in the DB directory, all of the log files,

which we'll get to in a few minutes here, any temp files, and

this config/secrets.yml file.

This is going to be part of the default Gitignore

that's inside of a Rails application.

It's also ignoring DS_Store files, which Mac OS 10 uses to keep track

of the view settings of a particular folder when you're launching Finder.

Now if you want other files kept out of version control you can

add them to this Gitignore file and the path is relative.

Let's go ahead and close that.

The next thing you will notice is a .rspec file.

This is only going to exist if you're using RSpec in your project and

this specifies the default options that RSpec is going to use.

In this case, we're always going to be running RSpec with color turned on.

Next is something called config.ru.

Now this is something that is used by a library that Rails uses called Rack.

And it, as the file says, is used to start the application

Rack provides a common way that Ruby servers can interface with web servers,

and the config.ru, which stands for rack up, tells these servers how to operate.

Now if we had more applications, we could add them to this file, and run them and

even mount them at different points.

But, we're not going to get into that.

The next file that you'll see here is called the Gemfile and

this lists all of the different libraries that you're using in

the application and they are separated out by environment.

The Gemfile is all that you really need,

the gemfile.lock is generated after you update your Gemfile.

You won't be editing this, this is handled by Bundler, and generated automatically.

It specifies the different dependencies and versions of things in the application.

Next is the Rakefile.

This is a standard file that pretty much loads the application and

the application's rake tasks.

The rake tasks are held inside the Lib and Tasks directory.

Now Lib we'll be getting to in a little bit,

but the Tasks directory is where different Rakefiles will be stored.

Now when you're creating a Rakefile in your application a rake

task is something that's going to be done repetitively and

you want it done inside of your applications environment.

For example,

maybe you have a piece of code that automatically bills users each night.

Well you would create a rake task to

bill all of the different users that would go inside of the Tasks directory.

Maybe inside of a file called billing.rake.

And finally, it is the README.rdoc which will

describe and document everything in your application.

And they give you some sensible defaults here about things you might want to put

inside of a readme RDoc.

In this case it's the Ruby version, system dependencies, and so forth.

So that's everything that's at the root of a Rails application.

Next up, we're just gonna go from top to bottom, here.

The App directory is where you're gonna be spending most of your time,

when you're creating and working with a Ruby on Rails application.

The Assets directory is gonna hold your different images,

JavaScripts, and style sheets.

And if you are using the Rails Asset Pipeline, you can specify how all of these

get generated, and worked with in your application.

Right here we have an application.js file,

and we require different files inside of it.

And then using the Rails Asset Pipeline, all of these different files will be

concatenated and minified when you deploy the application.

You don't have to do that,

you can do fine-tuned configuration of these files if you want to.

Next is the Stylesheets directory and that has the same ability,

different requires for concatenating and minifying your style sheets

and this all changes and can be reloaded in development mode.

We're using SCSS and SASS in this application, so

these will be pre-compiled and added to the list of tasks.

In development, production, more tasks such as minification can occur.

Next, is the Controllers directory.

Controllers are going to be part of a Rails application,

they all go in here for the most part.

The only exception to having controllers inside of the app Controllers directory,

would be if you had a Rails engine,

or a gem that came with an engine, you might have more controllers in there.

But for the most part they all live in here.

So a controller, all controllers

inherit from the application controller using class inheritates.

You'll notice the application controller also inherits from a controller and

that is the application controller base controller.

So here's the application controller and

then we have all of these different controllers in our application.

As you add to that, they will show up in here.

Now a controller in a Rails application handles talking to the model and

assigning variables to the view.

Generally it is not going to be too complicated inside of a controller

hopefully doing just a few things inside of a controller action.

As an example right here,

our new action is setting a user instance variable to a new user object.

The Helpers directory contains helpers for each individual controller.

A helper will give you different methods to use inside of your controller.

We didn't use a ton of them in this application.

As we're clicking through you can see not much has really gone on here.

We do have something in the application helper

which is going to be available to all of our different views.

Now, the main purpose of a helper is to programmatically

include code that you wouldn't want to inside of your views.

Now, here's an example, this new_item_link method that we have inside of this

application helper changes depending on where you are in the application.

So, here is our application file and we have different

headers that wind up getting displayed whether you're logged in or logged out.

If we looked into our logged in header this is where we have the new item link.

Now, this application will show you to do lists, and to do items so, depending on

where we are, if we're inside of just the root we would create a new to do list but,

if we're inside of a to do list then we want to create a new to do item.

Now, rather than putting all of that logic on the page inside of the layout,

we do it inside of a helper.

Next up you'll see the Mailers directory.

Now mailers, as you might expect from the name,

keep track of the different mailers in your application.

They work with the same Views directory that we'll get to in just a second.

But notifiers, just like controllers, have a layout associated.

So here the password_reset method goes with the password reset notifier view.

You might be a little bit confused by the password resets directory.

That goes with the controller.

The notifier has this pasword_reset action and

individual layout that goes with the notifier action.

Next is the Models directory.

Now the Models directory contains all of the code for your models which

generally will coincide with items inside of the database.

So we have a users table which works with a users model and

we have user logic inside of the model.

Now, the model's directory doesn't need to contain only

database-backed active record models.

Depending on the needs of your application,

you can put regular Ruby classes inside of the models directory.

And finally, we caught a little glimpse of it before but

we have this views directory which will contain your different layouts.

Here's the application layout.

This is going to be the default layout.

You can also have layouts for each controller.

Now, each controller also gets it own layout directory.

So here, let's see we have this password_resets_controller.

Here is the new action.

This would coincide with the new HTML template.

Now you can see this has an html.erb extension.

That tells you what kind of layout it is.

It could also be js.erb xml, it depends on the file type.

This is generating HTML, so it is an html.erb template.

Next up, we have the bin directory.

This contains binaries for your Rails application.

Now when you see a Ruby application that has a Gemfile.

The Gemfile specifies what libraries are used in the application.

But you might have different libraries installed on your system.

So a Rails application will create

different versions of these binaries that use only this Gemfile.

Now you could execute this commands

in the context of the Gemfile by using the command bundle exec.

But if you use one of the binaries inside of this folder, you don't have to do that.

You can just say bin/rails and it will execute in the context of the Gemfile.

And when you install a Gem in your application,

all you need to do is type bundle bin or binstub and

the name of the Gem and it will put it inside this bin directory.

In previous versions of Rails,

the bin directory was not checked into source control.

But in the latest versions, it is.

Next up we have the config directory,

which as you might expect from the name stores application configuration.

Most application configuration is done in application.rb.

This is a Rails 4 plus application.

Prior to Rails 4 or potentially even Rails 3,

this was all done in configs/environment.rb.

And that has moved to configs/application.rb.

Now this is where default application configuration is gonna be done.

A Rails application starts out in development mode.

And you can see that there is a development environment

inside of this environments directory.

Each time you have an environment,

you can override application configuration in the specific environment.

Now once you install different plugins or gems in your application,

they may have options to create initializers.

Rails ships with a few defaults, we have backtrace silencers.

Which lets you remove output from Rails when there are error messages or

things in log files.

Cookie serializers inflections, this is going to let you change how

Rails pluralizes different items, as well as sessions storage.

We're using the cookie session store, you could change this to a database store,

whatever you want to.

So these are the default initializers.

Some gems may add their own.

The locales directory is where translation is going to be stored.

So if you were translating something,

this is the en.yml file which stands for English.

And that can be changed for each different language that you want to support.

At the root, you give it a key and then the translation key, so if we say hello.

We're translating in our views,

the hello key which would come out to be Hello world.

So you can add different languages here and

that would be how you internationalize a Rails application.

The rest is the application configuration, database configuration,

environment configuration generally you don't touch.

And the routes file.

The routes.rb file specifies each individual route in this application.

So we can see we get the home page, we have the login page and

that goes to the new user sessions controller here.

So we can specify different routes.

But that's a little bit beyond the scope of this workshop here.

We'll just leave it at this is where all of your routes are configured.

It's in one file, which makes it very,

very easy to see in one spot what's happening in your routes.

Here is the secrets file.

This gives you different application secrets for each environment.

In Rails 4 plus applications to 4.2, you need this secret_key_base key.

It should be generated by default.

Now this secrets.yml file is kept out of version control, because you don't want

these secrets inside of version control where anybody can see them.

They're supposed to be secret.

Next up, we have the db directory which contains your database information.

There's really only a couple of files that you'll find in here.

Schema.rb, which can be the ActiveRecord Schema version.

And this will tell you how to recreate your database based on the current schema.

Seeds file let you create seed data for an application.

This is gonna be application data that occurs for the first run,

maybe you have an administrator that needs to be in the system,

where they change their password immediately.

Let's say you have a subscription application,

different plans could be in here as seed data.

By default if you’re using SQLite 3 as your database development production and

test SQLite 3 databases will be created inside of the db directory.

And the migrate directory contains different migration files.

That are time stamped and tell you what exactly this file did.

So we created the Contacts table in this migration.

There's nothing here.

This one removed and added columns to users, the password_reset_token.

So anyway, migrate directory keeps track of database changes.

It's different from the schema.rb which will contain the most up-to-date

version of your database.

After the db directory, we have the lib directory.

Now we saw that there's tasks and a .keep file here, .keep is empty.

This just tells get to index the directory.

Get won't index empty directories,

so an empty file is created just to tell get to keep it.

Same thing for assets, the lib assets directory can be

maybe assets such as JavaScripts that you don't have control of.

This could be library versions like jQuery or specific libraries that you

wanna keep in place or libraries that you haven't written for your application.

Now, the lib directory can also contain library code that you wrote yourself for

your app, but maybe doesn't belong as a controller, model or helper.

In this case, I've added a FormBuilder to the lib directory,

which is going to help build foundation forms.

Now this could also be small lib files,

maybe you have something that generates different URL slugs for you.

The lib directory would be a perfect place to store that.

Next is the log directory, which keeps track of the different log files for

the environments that you've run.

The log directory is kept inside of version control, but

these different log files are kept out of it by default in the gitignore.

If you have something else,

maybe your using a queuing system, the que log would go inside of here as well.

The public directory contains files that are not processed by Rails.

So by default, it comes with these different files 404, 422 and 500.

This is gonna be your not found and error pages.

There's also a robots.txt file.

Notice that by default, all traffic is allowed.

You may want to uncomment this during development of the application for

different SEO purposes.

Also, the applications icon is loaded in here by default.

Next we have the spec directory.

This is where the different test files go.

I'm using Rspec in this application.

This directory name could also be test if you use test unit or

mini test which come with Rails.

The temp directory contains cache, session information and sockets.

And that's pretty much it,

anything that can be short lived goes inside of the temp directory.

You don't need to worry about it to much.

And the vendor assets directory, another place to keep

different assets like JavaScripts, maybe again that you don't own.

And same thing with style sheets.

Another use for the vendor directory, some people will choose to bundle their

application libraries specified in the Gemfile inside of the vendor directory.

And that can be done.

You just give it a path when you bundle the application.

So this is the layout of a typical Ruby on Rails application and

what each directory does.