Configure a project - Ruby on Rails Tutorial

- [Instructor] In this movie we'll learn to perform the basic configurations that a Rails project needs at the start. The very first configuration that you should perform is you should set up your application to use the correct RubyGems that it needs. We've seen this Gemfile before. This is where you configure the RubyGems your application needs, and, of course, the most important one being Rails, and telling it which version of Rails that it needs. If you wanna add additional functionality to your application you would do it by defining new RubyGems here. And as soon as you've defined them, and you're ready to use them you must come over to the command line, and from the root of your project type bundle space install and hit Return. Now if you remember, when I first created my Rails application, Rails ran bundle install for me, and it went out and it got the code it needed, got everything installed so that our application would be ready to go. That's a helpful thing that it does at the start. But if we make changes to this file, we must run it again. It needs to go through and sync things up and make sure that it's got all the parts that it needs to run. So we'll need to run bundle install anytime we make changes to Gemfile. If we don't make changes to it, there's no reason to run it. That's all it really does is just update our bundle of RubyGems that we're using. You'll also notice that it says Using rails 5.0.0. When we first did it the original time it said Installing rails 5.0.0. This let's me know that this gem is already installed. It didn't have to go find it. It's using an existing version. All of this is handled by a piece of technology called Bundler. The bundle command is part of the Bundler gem. If you want to look up more information about additional options and the full syntax of how it works you can look up the Bundler RubyGem and find out more. So that's the first place that we go for configuration, is determining what RubyGems get loaded. The second is in the config directory, and there are a few key files here that matter more than others. The first I wanna call out is the application.rb file. This is our General Application Configuration. Configurations which apply to the application throughout. Most of the time though you're not going to add code to this file, and the reason why is noted here. Application configuration should go into files in the config/initializers directory. All .rb files in that directory are automatically loaded. If we look there's another directory here called initializers and inside there are a bunch of .rb files. If we click on one for example, let's see if I can find on that has content in it. Here we have Rails.application.config.action_controller. forgery_protection_origin_check equals true. Alright, that's a configuration that has been turned on and configured in this file. So, anything in initialzers will be run in initialzer application with the right configurations. There's also another note on that application.rb file, which is that settings in config environments take precedence over those specified here. If you'll notice there's another directory here called environments and inside it are three different files development, production, and test. And those are the three default environments that Ruby on Rails gives you. You can create your own environments if you want to have more. You could have a staging environment or a QA environment, but by default there's three environments, and it makes sense that we would use those three. Development is the environment that we use when we're developing. When we're bringing up our code, we're testing it out, we wanna have certain a configuration options in that case. For example, we might be using a local email server or we might have our log level set to give us more information in our logs. Then we have our production environment. That's when we actually deploy our code. Again, we might have a different email server set for that. We might want to have a different log level. Maybe we only wanna log the errors in production, we don't wanna log everything. We can set each one of those to be a different value. And then last we have test, and that's for when we're writing software test using test unit or RSpec or something else, and we would write our test on our test directory, but we would have a different environment set up for those. So, by default, Rails has these three environments. Development, production, and test. So always keep that in mind. And then for each one of these we can define different configuration options. Now there's really only one thing that we have to configure in order to get our Rails application off the ground, and that is the database. It used to be that you didn't have to have the database set up before you could launch an initial Rails application. But that's not the case at the moment. We need to have a Rails database set up and configured so that our Rails application can find it even though it doesn't have any data in it yet. So let's set out to do that now. I'm gonna go over to my command line, and I'm gonna log into mysql. I'm gonna log in as my root user, u space root, and then dash p for my password option. I'll type in my secret password. And now I'm logged into mysql. From there I'm going to create the databases that I need. So the first command I need is a mysql command called CREATE space DATABASE space and then the name of the database that I want to create. Since my application is called simple cms, it's going to be pre-configured to use that as the base of the database name. Simple_cms_development, again, that's that development database that we're gonna be using. So we put a semicolon at the end and hit Return. It now creates the database for us. We also wanna create another database, which is going to be simple_cms_test. We want to have separate databases for development and for writing test code. That way we don't interfere with the two. Our test code can change things in the database as it's testing. We don't have to worry that it's messing up what we're seeing in development. Now we're not gonna create a production database as well. If we were on a production server and we were actually gonna deploy it then of course we would wanna have the production database set up there. Now that we have our two databases, we could certainly just use our root user to connect to them, but that's not a great security practice. It's much better for us to define a new user that our Rails application can use to connect. So, let's create a new user. We're gonna do that using GRANT space ALL space PRIVILEGES, make sure you spell privileges correctly, space ON and then the name of the database. So the first one is simple_cms_development and then a period and an asterisk telling it that it should be all tables on that database. That's a wild card saying all tables on this database should be given access to and then in single quotes we'll write the name of the user. It can be absolutely any name that you want. I'm gonna call it rails_user, so the rails_user, and then close those single quotes, put an at sign and then in single quotes write localhost, again single quotes. That's going to tell it that it'll be a locally connecting user, not someone connecting from another IP address somewhere else and then a space and IDENTIFIED BY and then in single quotes the password that we want to use. I'm just gonna use secretpassword. Not a very good password. You should choose something better than that. But that will at least allow me to type a password here that you can see and we can all remember. Then I'll hit Return. It'll now grant those privileges so that rails_user can now connect to all the tables on the simple_cms_development database. And then I'm just gonna go up and change that line. Oops, let me just copy, grant all tables on, but this time we're gonna use simple_cms_test period, asterisk, space and let's take all of this again. There we go. So now I've done the exact same thing, but for my test database. So I have a user, the user's able to connect to both these databases. Now all we need to do is tell our Rails application about it. So, I'll exit out of mysql. Let's come back over to our Rails application. And the place that we do that is in this database.yml file. This is the file that configures our database. This database file is in the yaml format. That's Y-A-M-L, it's short for yaml ain't mark up language, and really it's just a very simple way of formatting text files with indentions and colons. So we have default colon, and then this default setting is gonna get used by development. You'll see it pulls it in right here and we can override any of those settings we want here. Here we have simple_cms-development, simple_cms_test. See how those defaults kicked in. That's Rails sensible defaults picking the name of the database for us based on what it expects it to be. And the user name for those we're gonna change to be rails_user and the password I'll make secretpassword. Alright so that's what it's gonna use for both of those. Once we have those installed, now our development and our test database can log in to mysql. Let's save it. And the way that we can find out if our configuration worked is to come over to the command line and from here let's type in a Rails command, rails space db:schema:dump. Now what this does is it says go out to the database and get all of the definitions for the database. Everything that describes what the database looks like and dump it to a text file. Now there's nothing there right now. It's not going to actually dump anything, but the fact that it's able to successfully connect and dump nothing is meaningful to us. It tells us that we were able to make a database connection. So, if we come back and we look now. If we look inside our db directory, we'll actually see a new schema file that it created. And there's nothing in there, it's empty, but it was able to connect to the database successfully. If you got an error, then you need to make sure that your database is running, that mysqul is running, that you've created those databases, and that you've granted privileges to the right user with the correct password and then provided those to the configuration. If all those things are true you should be able to connect to the database just like this. Okay now that we understand more about how we go about configuring a Rails project and we've configured it with the database, the information that we need, now we're ready to actually access the project via a web browser.