Understanding Your Rails Directory

Andrew Schittone
Jul 25, 2017 · 6 min read

My experience so far at Flatiron School has been great, after just three weeks into the course, we’re already moving on to learning Rails, which is very exciting- for me at least. I’ve heard so much about Rails and how it’s an excellent way to go, in terms of building web apps, which is why I’m excited to jump in and learn how to use it. At this point in the program, I finally feel that I’m getting closer to becoming an actual developer, since so many other developers use Rails, and a lot of major sites are built on this framework as well.

On a side note, I definitely understand the importance of learning Sinatra before jumping into Rails- I’m glad we took that route. I think it’s crucial to understand the basics of setting up routes, and the whole Model View Controller (MVC) structure that Rails follows closely. Rails does so much for you that it’s easy to take it all for granted- so I definitely think we all appreciate it more after using Sinatra.

The first thing that stood out to me about Rails is that it sets up your entire directory when generating a new app with the “rails new” command. Most of the labs that we’ve been doing already have a directory and environment set up- so we can just focus on solving the problems that are given to us. Since Rails sets all of this up for you automatically as well, I think it’s important that we take a step back and learn what’s going on in the files that we’re not so familiar with, when you open up your Rails app. It’s very possible to just move forward with creating your database/migrations, and just worry about the MVC portion of Rails- but I think we should also understand what’s going on with the entire directory- before we develop bad habits as we continue to learn.

So let’s jump in and take a look at the directory that Rails sets up for us, after running “rails new” (keep in mind that when you run this command in the terminal to set up a new app, you’ll see a huge list of all the files/directories that are being created as well):

As bootcamp students, at this point since we’ve been following the MVC convention for some time, we’re all used to seeing and operating in a certain set of files and folders that Rails sets up for us automatically. These include the following:

  • app- contains the model, view, and controller files, along with CSS, Javascript files and images related to the front end of the program. All app specific code is located in this folder.
  • config- where the database connection exists, and other files related to how the application behaves.
  • db- all files that are related to the database are located in this folder, including the schema file and migrations as well.
  • Rakefile- this file allows rake tasks to be available throughout the entire application.
  • Gemfile and Gemfile.lock- the gemfile is where gem dependencies are defined. When bundle install is ran, the dependencies are locked in, in gemfile.lock.

These are the main folders that we’ve been used to seeing and working in so far (mainly the app folder since that’s where we do most of our specific coding for labs). However, there are some other files/folders that I noticed Rails sets up for you automatically, that we really haven’t paid attention to before:

  • app/helpers- this is where you can locate all of your helper functions for view files. Rails allows you to create your own functions in a controller specific helper file, it’s automatically generated when you use rails generate, to create a controller file.
  • app/mailers- this folder contains functions related to email for the application. Mailers are similar to controllers, they will have corresponding view files stored in the views directory.
  • bin- this folder has actually been in pretty much all of the labs we’ve been working on so far, however I have noticed some changes since we’ve been using rails. This folder stores binstubs for us, which allow us to use commands such as rake, rails, and bundle ,etc, without changing directories. One of the new ones that stood out to me, which I had no clue about, is spring. Spring is what keeps your rails application running in the background so you don’t need to boot it back up every time you change your code.

There was also several files/folders included in config, that we aren’t familiar with at this point, since we’ve just jumped into rails:

  • Config/initializers- contains all files that are ran at initialization. These files are all called in the environment.rb file also located in conifg.
  • Config/locales- this folder deals with Internationalization, and holds YAML files for whatever languages you want to use for your app.
  • Config/secrets.yml- this file contains the secret_key_base for your environments, Rails generates the keys for you automatically. This file can also be used to store external API keys as well.
  • config/application.rb- the configuration for the entire app can be found in this file. This includes configuration for the languages you’re using on the site and timezone as well. There’re many other configurations included as well in this file.
  • config/boot.rb- the responsability of this file is to boot up your rails application. This file actually verifies that there is a Gemfile located in the directory, and stores a path to it in a variable. It’ll also build the gems located in the Gemfile using Bundler.

These are some of the folders that I really didn’t understand at all, and why Rails even created them for us. I also found it pretty cool that a .git folder is automatically generated when a rails app is first created. This automatically sets up a local git repository for us. Pretty cool. While we’re discussing Rails, there are also a few other commands that I‘d like to point out, that I think will definitely be useful moving forward working with this framework:

rails console — sandbox- this command is perfect if you want to play around or test your code in the rails console, but you don’t want any of the changes that you make to save to your database.

rails destroy (rails d)- this is basically the opposite of the rails generator or rails g commands. It’ll basically figure out what was generated with rails g, and delete it.

bundle check- this will check if the dependencies in your GemFile have been satisfied.

As you can imagine, there are many more files and folders that are automatically set up by Rails, that weren’t covered above. I mainly wanted to go over the areas that we haven’t really covered as coding bootcamp students, so we understand why these certain files/folders are included in our Rails apps moving forward. If you’d like to review a complete guide to a standard Rails directory, check out the link below. Please see the additional link below as well for more info on basic rails commands.

Sources:

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade