Let's rebuild our record store application using Rails. First, we'll run the following command to install the Rails gem onto our machines:
$ gem install rails -v 5.2.0
Then, we'll run this next command to create a new Rails application:
$ rails new rails_record_store -d postgresql -T
This will create a new Rails app called
-d postgresql portion tells Rails to use Postgres for the database, and
-T instructs it not to install its testing tools. (By default, it uses a library called
test-unit, whereas we use RSpec.)
When naming your own projects, make sure to use a unique name that won't be used for classes in your project. Because Rails and ActiveRecord automatically generate classes and methods for us based on the names we use in our project, we need to be very careful about naming. If your project has the same name as one of your classes, you might run into errors.
To make this the default configuration, create a file called .railsrc in your home directory (using the text editor of your choice) and add the line
-d postgresql -T, like this:
-d postgresql -T
When we run
$ rails new your_app_name in the future, it will use this configuration by default. This is how the Epicodus computers are set up.
After running the
$ rails new rails_record_store -d postgresql -T command, Rails will create a folder called rails_record_store with a skeleton of all the folders and files required for our new app.
cd into our new rails_record_store folder and open the project in our text editor. We'll quickly go through the directories and new files here. Before we do, a quick note: we will mostly work with the app, config, and db directories. Specifically, we'll spend the vast majority of our time working with the app folder. If all these directories seem overwhelming, keep that in mind.
Let's take a look at our new directories:
app: We will do most of our work in the app directory. This directory holds many subdirectories. We will cover only the subdirectories we plan to use at Epicodus:
bin: This holds a link to the Rails server and a few other common commands. We won't touch this folder.
config: Just like in Sinatra, we use config/database.yml to store our database configuration. The pre-populated configuration looks a little different from what you're used to, but in fact, will achieve the same results. There are also other configuration files here, but we won't use them much.
db: This folder will hold migrations (more on this later) and our database schema. It also holds a seeds.rb file that we can use to put default values in your database.
lib: We won't use the lib folder much. We can store custom Rake tasks here.
log: Our web server will store its logs here.
public: Static files for error messages go here.
tmp: This is where the web server's temporary files go.
vendor: Gems can be installed here in some cases (but not any cases we'll deal with).
When we generate a new Rails application, it will automatically generate a Gemfile for you. Here's what it will look like assuming that we're using Epicodus computers (Ruby version 2.4.1 and Rails version 5.2.0):
Note that the Gemfile includes several commented-out gems as well as comments about gem functionality. Some developers don't like the clutter of these additional comments and remove them. There are even custom Rake tasks to automatically remove comments from the Gemfile.
We'll also update the Gemfile to add additional gems. First, let's add jQuery to our application:
gem 'jquery-rails' group :development, :test do
Note the gem should be added in the top section of our Gemfile because we want it for all environments, including production. In the snippet above, we show it as being just above the beginning of the block for
Next, we'll add some gems to
group :development, :test do:
group :development, :test do gem 'byebug', platforms: [:mri, :mingw, :x64_mingw] gem 'rspec-rails' gem 'launchy' gem 'pry' end group :development do ...
We've added three new gems to our test environment. Rails automatically includes
byebug is similar to
pry and allows you to add breakpoints in your code with either the
byebug command. It's the Rails-approved way of debugging because it has more functionality than
pry should get the job done for any debugging you need to do in a Rails application, but you're also encouraged to explore
byebug further on your own. Its basic functionality is very similar to
$ bundle install to get our Gemfile.lock file and bundle all of our gems.
If you need to supply a password to access your Postgres server, like some Windows users do, you'll have to edit the
config/database.yml, by adding new
password keys. The following code snippet shows the new keys, but with the many comments from Rails omitted.
... development: <<: *default database: rails_record_store_development password: epicodus # new code! ... test: <<: *default database: rails_record_store_test password: epicodus # new code! ...
Note that there's also a section for production, but we won't be using it.
As we know, it's not secure to put passwords directly into our application's source code. To resolve this issue, we'll use the dotenv gem, just like we did with Sinatra. However, the configurations will be slightly different.
First, we'll add the
dotenv-rails gem to the
group :development, :test of our
group :development, :test do # See https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem gem "debug", platforms: %i[ mri mingw x64_mingw ] gem 'byebug', platforms: [:mri, :mingw, :x64_mingw] gem 'rspec-rails' gem 'launchy' gem 'pry' gem 'dotenv-rails' end
bundle your code!
.env to your
.gitignore to your Git history.
Then, create the
.env file and add your environment variable:
config/database.yml, update the
password value to
<%= ENV["DATABASE_PASS"] %>, like so:
development: <<: *default database: rails_record_store_development password: <%= ENV["DATABASE_PASS"] %> ... test: <<: *default database: rails_record_store_test password: <%= ENV["DATABASE_PASS"] %>
Let's set up RSpec as well:
$ bundle exec rails generate rspec:install
While this command usually works even without
bundle exec, it's a best practice to append
bundle exec to ensure that RSpec looks for the correct version of the gem specified in your local Rails project instead of looking at globally installed gems.
This creates our familiar spec folder, a rails_helper.rb, and a spec_helper.rb.
Our Rails projects are going to rely on structure and convention. We cannot even start our server and view the default entry page until the database is set up. In the next lesson, we will use built-in Rake tasks to create our database quickly!
Lesson 3 of 34
Last updated August 7, 2022