Rails Application Walkthrough

[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