Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
In this workshop, you'll explore the layout of a Ruby on Rails application. You'll learn where all of the different parts of a Rails application are stored and what goes where.
You can download the Odot Rails application code here.
[MUSIC]
0:00
Hi I'm Jason the Ruby
teacher here at Treehouse.
0:04
In this workshop we're going to take
a walkthrough of a Ruby on Rails
0:08
application.
0:12
Now when you work with a Ruby
on Rails application there's
0:13
a few different directories
that Rails sets up for you.
0:16
Now depending on how you're coding and
0:20
needing to get familiar with the Rails
application, different reports go where?
0:22
Now we're gonna go through and
0:25
see what each different part
of a Rails application does.
0:27
So here I have a Rails application.
0:32
Now what I'm using right now
is the ODOT application and
0:35
there will be a link to that
down in the video notes here.
0:39
You can follow along with this
project if you want to, or
0:43
just download the files to follow along.
0:45
Now, this would be the same if we
generated a new Rails application,
0:49
however, there is existing code, so we're
using this for demonstration purposes.
0:53
So what you'll notice if
we look at the root of
0:59
a Rails folder we have a few different
files on the left-hand side here.
1:02
We have an Gitignore file which stores
1:07
all of the files that will be ignored or
kept out of version control in Git.
1:11
This is gonna be everything in the DB
directory, all of the log files,
1:16
which we'll get to in a few minutes here,
any temp files, and
1:21
this config/secrets.yml file.
1:24
This is going to be part
of the default Gitignore
1:28
that's inside of a Rails application.
1:32
It's also ignoring DS_Store files,
which Mac OS 10 uses to keep track
1:35
of the view settings of a particular
folder when you're launching Finder.
1:39
Now if you want other files kept
out of version control you can
1:43
add them to this Gitignore file and
the path is relative.
1:47
Let's go ahead and close that.
1:53
The next thing you will
notice is a .rspec file.
1:55
This is only going to exist if you're
using RSpec in your project and
1:58
this specifies the default options
that RSpec is going to use.
2:03
In this case, we're always going to be
running RSpec with color turned on.
2:07
Next is something called config.ru.
2:13
Now this is something that is used by
a library that Rails uses called Rack.
2:16
And it, as the file says,
is used to start the application
2:23
Rack provides a common way that Ruby
servers can interface with web servers,
2:28
and the config.ru, which stands for rack
up, tells these servers how to operate.
2:34
Now if we had more applications, we could
add them to this file, and run them and
2:40
even mount them at different points.
2:45
But, we're not going to get into that.
2:47
The next file that you'll see
here is called the Gemfile and
2:50
this lists all of the different
libraries that you're using in
2:53
the application and
they are separated out by environment.
2:58
The Gemfile is all that you really need,
3:03
the gemfile.lock is generated
after you update your Gemfile.
3:07
You won't be editing this, this is handled
by Bundler, and generated automatically.
3:11
It specifies the different dependencies
and versions of things in the application.
3:17
Next is the Rakefile.
3:23
This is a standard file that pretty
much loads the application and
3:25
the application's rake tasks.
3:29
The rake tasks are held inside the Lib and
Tasks directory.
3:31
Now Lib we'll be getting
to in a little bit,
3:37
but the Tasks directory is where
different Rakefiles will be stored.
3:41
Now when you're creating a Rakefile
in your application a rake
3:45
task is something that's going
to be done repetitively and
3:48
you want it done inside of
your applications environment.
3:52
For example,
3:55
maybe you have a piece of code that
automatically bills users each night.
3:56
Well you would create a rake task to
4:02
bill all of the different users that
would go inside of the Tasks directory.
4:05
Maybe inside of a file
called billing.rake.
4:10
And finally,
it is the README.rdoc which will
4:15
describe and
document everything in your application.
4:20
And they give you some sensible defaults
here about things you might want to put
4:25
inside of a readme RDoc.
4:28
In this case it's the Ruby version,
system dependencies, and so forth.
4:31
So that's everything that's at
the root of a Rails application.
4:36
Next up, we're just gonna go
from top to bottom, here.
4:42
The App directory is where you're
gonna be spending most of your time,
4:44
when you're creating and
working with a Ruby on Rails application.
4:48
The Assets directory is gonna
hold your different images,
4:52
JavaScripts, and style sheets.
4:55
And if you are using the Rails Asset
Pipeline, you can specify how all of these
4:57
get generated, and
worked with in your application.
5:02
Right here we have an application.js file,
5:06
and we require different
files inside of it.
5:10
And then using the Rails Asset Pipeline,
all of these different files will be
5:14
concatenated and
minified when you deploy the application.
5:18
You don't have to do that,
5:22
you can do fine-tuned configuration
of these files if you want to.
5:23
Next is the Stylesheets directory and
that has the same ability,
5:27
different requires for concatenating and
minifying your style sheets
5:33
and this all changes and
can be reloaded in development mode.
5:39
We're using SCSS and
SASS in this application, so
5:44
these will be pre-compiled and
added to the list of tasks.
5:48
In development, production,
more tasks such as minification can occur.
5:54
Next, is the Controllers directory.
6:02
Controllers are going to be
part of a Rails application,
6:05
they all go in here for the most part.
6:09
The only exception to having controllers
inside of the app Controllers directory,
6:12
would be if you had a Rails engine,
6:17
or a gem that came with an engine,
you might have more controllers in there.
6:20
But for
the most part they all live in here.
6:24
So a controller, all controllers
6:27
inherit from the application
controller using class inheritates.
6:29
You'll notice the application controller
also inherits from a controller and
6:34
that is the application
controller base controller.
6:38
So here's the application controller and
6:44
then we have all of these different
controllers in our application.
6:46
As you add to that,
they will show up in here.
6:50
Now a controller in a Rails application
handles talking to the model and
6:54
assigning variables to the view.
6:59
Generally it is not going to be too
complicated inside of a controller
7:01
hopefully doing just a few things
inside of a controller action.
7:06
As an example right here,
7:10
our new action is setting a user
instance variable to a new user object.
7:12
The Helpers directory contains helpers for
each individual controller.
7:20
A helper will give you different methods
to use inside of your controller.
7:26
We didn't use a ton of
them in this application.
7:31
As we're clicking through you can see
not much has really gone on here.
7:34
We do have something in
the application helper
7:38
which is going to be available
to all of our different views.
7:40
Now, the main purpose of
a helper is to programmatically
7:45
include code that you wouldn't
want to inside of your views.
7:50
Now, here's an example, this new_item_link
method that we have inside of this
7:56
application helper changes depending
on where you are in the application.
8:01
So, here is our application file and
we have different
8:08
headers that wind up getting displayed
whether you're logged in or logged out.
8:13
If we looked into our logged in header
this is where we have the new item link.
8:20
Now, this application will show you to do
lists, and to do items so, depending on
8:24
where we are, if we're inside of just the
root we would create a new to do list but,
8:30
if we're inside of a to do list then
we want to create a new to do item.
8:35
Now, rather than putting all of that
logic on the page inside of the layout,
8:39
we do it inside of a helper.
8:44
Next up you'll see the Mailers directory.
8:51
Now mailers,
as you might expect from the name,
8:53
keep track of the different
mailers in your application.
8:56
They work with the same Views directory
that we'll get to in just a second.
8:59
But notifiers, just like controllers,
have a layout associated.
9:04
So here the password_reset method goes
with the password reset notifier view.
9:09
You might be a little bit confused
by the password resets directory.
9:15
That goes with the controller.
9:19
The notifier has this
pasword_reset action and
9:21
individual layout that goes
with the notifier action.
9:25
Next is the Models directory.
9:33
Now the Models directory contains all
of the code for your models which
9:36
generally will coincide with
items inside of the database.
9:41
So we have a users table which
works with a users model and
9:46
we have user logic inside of the model.
9:51
Now, the model's directory
doesn't need to contain only
9:55
database-backed active record models.
10:00
Depending on the needs
of your application,
10:03
you can put regular Ruby classes
inside of the models directory.
10:07
And finally, we caught a little
glimpse of it before but
10:12
we have this views directory which
will contain your different layouts.
10:15
Here's the application layout.
10:18
This is going to be the default layout.
10:19
You can also have layouts for
each controller.
10:21
Now, each controller also
gets it own layout directory.
10:25
So here, let's see we have this
password_resets_controller.
10:32
Here is the new action.
10:37
This would coincide with
the new HTML template.
10:38
Now you can see this has
an html.erb extension.
10:45
That tells you what kind of layout it is.
10:49
It could also be js.erb xml,
it depends on the file type.
10:51
This is generating HTML, so
it is an html.erb template.
10:57
Next up, we have the bin directory.
11:06
This contains binaries for
your Rails application.
11:09
Now when you see a Ruby
application that has a Gemfile.
11:13
The Gemfile specifies what libraries
are used in the application.
11:17
But you might have different
libraries installed on your system.
11:22
So a Rails application will create
11:26
different versions of these binaries
that use only this Gemfile.
11:31
Now you could execute this commands
11:36
in the context of the Gemfile by
using the command bundle exec.
11:40
But if you use one of the binaries inside
of this folder, you don't have to do that.
11:44
You can just say bin/rails and it will
execute in the context of the Gemfile.
11:49
And when you install a Gem
in your application,
11:56
all you need to do is type bundle bin or
binstub and
11:59
the name of the Gem and
it will put it inside this bin directory.
12:03
In previous versions of Rails,
12:09
the bin directory was not
checked into source control.
12:10
But in the latest versions, it is.
12:13
Next up we have the config directory,
12:17
which as you might expect from the name
stores application configuration.
12:19
Most application configuration
is done in application.rb.
12:24
This is a Rails 4 plus application.
12:28
Prior to Rails 4 or
potentially even Rails 3,
12:33
this was all done in
configs/environment.rb.
12:36
And that has moved to
configs/application.rb.
12:40
Now this is where default application
configuration is gonna be done.
12:45
A Rails application starts
out in development mode.
12:50
And you can see that there
is a development environment
12:52
inside of this environments directory.
12:55
Each time you have an environment,
12:58
you can override application configuration
in the specific environment.
13:00
Now once you install different plugins or
gems in your application,
13:06
they may have options
to create initializers.
13:11
Rails ships with a few defaults,
we have backtrace silencers.
13:15
Which lets you remove output from
Rails when there are error messages or
13:20
things in log files.
13:24
Cookie serializers inflections,
this is going to let you change how
13:26
Rails pluralizes different items,
as well as sessions storage.
13:30
We're using the cookie session store,
you could change this to a database store,
13:35
whatever you want to.
13:40
So these are the default initializers.
13:42
Some gems may add their own.
13:43
The locales directory is where
translation is going to be stored.
13:47
So if you were translating something,
13:51
this is the en.yml file which stands for
English.
13:53
And that can be changed for each different
language that you want to support.
13:58
At the root, you give it a key and then
the translation key, so if we say hello.
14:03
We're translating in our views,
14:08
the hello key which would
come out to be Hello world.
14:10
So you can add different
languages here and
14:16
that would be how you
internationalize a Rails application.
14:17
The rest is the application configuration,
database configuration,
14:22
environment configuration
generally you don't touch.
14:27
And the routes file.
14:30
The routes.rb file specifies each
individual route in this application.
14:32
So we can see we get the home page,
we have the login page and
14:40
that goes to the new user
sessions controller here.
14:44
So we can specify different routes.
14:50
But that's a little bit beyond
the scope of this workshop here.
14:51
We'll just leave it at this is where
all of your routes are configured.
14:56
It's in one file, which makes it very,
14:59
very easy to see in one spot
what's happening in your routes.
15:02
Here is the secrets file.
15:08
This gives you different application
secrets for each environment.
15:10
In Rails 4 plus applications to 4.2,
you need this secret_key_base key.
15:15
It should be generated by default.
15:23
Now this secrets.yml file is kept out of
version control, because you don't want
15:25
these secrets inside of version
control where anybody can see them.
15:30
They're supposed to be secret.
15:34
Next up, we have the db directory which
contains your database information.
15:38
There's really only a couple of
files that you'll find in here.
15:43
Schema.rb, which can be
the ActiveRecord Schema version.
15:45
And this will tell you how to recreate
your database based on the current schema.
15:52
Seeds file let you create seed data for
an application.
16:01
This is gonna be application data
that occurs for the first run,
16:04
maybe you have an administrator
that needs to be in the system,
16:08
where they change their
password immediately.
16:13
Let's say you have
a subscription application,
16:15
different plans could be
in here as seed data.
16:18
By default if you’re using SQLite 3 as
your database development production and
16:21
test SQLite 3 databases will be
created inside of the db directory.
16:27
And the migrate directory contains
different migration files.
16:32
That are time stamped and
tell you what exactly this file did.
16:36
So we created the Contacts
table in this migration.
16:42
There's nothing here.
16:47
This one removed and added columns
to users, the password_reset_token.
16:49
So anyway, migrate directory
keeps track of database changes.
16:55
It's different from the schema.rb
which will contain the most up-to-date
16:59
version of your database.
17:03
After the db directory,
we have the lib directory.
17:08
Now we saw that there's tasks and
a .keep file here, .keep is empty.
17:11
This just tells get to
index the directory.
17:16
Get won't index empty directories,
17:19
so an empty file is created
just to tell get to keep it.
17:21
Same thing for assets,
the lib assets directory can be
17:26
maybe assets such as JavaScripts
that you don't have control of.
17:31
This could be library versions like
jQuery or specific libraries that you
17:35
wanna keep in place or libraries that you
haven't written for your application.
17:40
Now, the lib directory can also contain
library code that you wrote yourself for
17:45
your app, but maybe doesn't belong
as a controller, model or helper.
17:51
In this case, I've added
a FormBuilder to the lib directory,
17:59
which is going to help
build foundation forms.
18:05
Now this could also be small lib files,
18:08
maybe you have something that
generates different URL slugs for you.
18:11
The lib directory would be
a perfect place to store that.
18:16
Next is the log directory, which keeps
track of the different log files for
18:21
the environments that you've run.
18:25
The log directory is kept
inside of version control, but
18:28
these different log files are kept out
of it by default in the gitignore.
18:31
If you have something else,
18:36
maybe your using a queuing system, the que
log would go inside of here as well.
18:38
The public directory contains files
that are not processed by Rails.
18:44
So by default, it comes with these
different files 404, 422 and 500.
18:49
This is gonna be your not found and
error pages.
18:56
There's also a robots.txt file.
18:59
Notice that by default,
all traffic is allowed.
19:03
You may want to uncomment this during
development of the application for
19:07
different SEO purposes.
19:11
Also, the applications icon
is loaded in here by default.
19:13
Next we have the spec directory.
19:20
This is where the different test files go.
19:21
I'm using Rspec in this application.
19:24
This directory name could also
be test if you use test unit or
19:26
mini test which come with Rails.
19:30
The temp directory contains cache,
session information and sockets.
19:33
And that's pretty much it,
19:38
anything that can be short lived
goes inside of the temp directory.
19:40
You don't need to worry about it to much.
19:44
And the vendor assets directory,
another place to keep
19:47
different assets like JavaScripts,
maybe again that you don't own.
19:52
And same thing with style sheets.
19:56
Another use for the vendor directory,
some people will choose to bundle their
19:58
application libraries specified in the
Gemfile inside of the vendor directory.
20:04
And that can be done.
20:10
You just give it a path when
you bundle the application.
20:11
So this is the layout of a typical
Ruby on Rails application and
20:16
what each directory does.
20:20
You need to sign up for Treehouse in order to download course files.
Sign up