Flatiron School Part 3: Ruby on Rails

Michael Werling
4 min readMay 16, 2021

During month 3 at the Flatiron School, we learned about this absolutely incredible wed building framework called Ruby on Rails. Much like Sinatra, Ruby on Rails uses ActiveRecord and all of its awesome powers and adds to it with additional functionality. Once I figured out the structure and system, I was able to get the site up and running in no time.

MyTrail Scout Tracking System:

The premise of my new web app is keep everyone in a Scout troop up to date on all of the advancement and camping that is being done across their membership. Each scout can update each others camping record or merit badge record so that it can be recorded on the site for record keeping and it can be shown off for all in the troop to see.

Check out the video below to see more:

Setting Up the App

In my last blog, I talked about how nice it was that we were able to use a Ruby gem called ‘corneal’ to easily set up the full file structure for my last project in Sinatra. Unlike Sinatra, Rails has that functionality built!

Once you have Rails loaded onto your machine (and have the proper SQLite installed), you can enter “rails new project_name” into the terminal and it will go through and create all of the files that you will need to hit the ground running on a full Ruby on Rails app.

A quick look at a few of these files:

  • Gemfile: This file lists all of the ruby software packages that will be used in the application. From creation the Gemfile contains some great packages like ‘bcrypt’ (used for secure password authentication) and bootsnap (used for reducing overall boot times). I had to add a few additional gems that were missing, like ‘omniauth’ (used to login with google and other third party registrations.)
  • app: This is where the main code for the app is stored. This includes the models, controllers, and views that I talked about in last month’s Sinatra blog. Rails automatically sets you up with a generic application_record.rb model, an application_controller.rb controller file, and a few layout view files.
  • config/routes.rb: This is where the routes for the project live. Similar to Sinatra, Rails allows you to assign http routes to different actions on the given controllers. However, Rails allows you to call “resources” in this file and declare all of the necessary routes for your normal actions (index, show, new, ect.)
  • db: This folder includes information on all of the migration that have taken place throughout the app. This folder also contains current schema of your database. You can also seed your database with data using the seed.rb file.

Creating the App

After Rails did its magical creation, the next step was to add different models, views, and controllers for the different aspects in the database. Rails allows you to create all of these at once, by using a simple command called “rails g resource Model_Name”. You can even add different attributes to the end of the command and it will create migration files for you! With this simplicity of Rails, I was off and running. I was able to migrate everything to the database with easy and was off and running.

The next part of the project was similar to the Sinatra project. I was passing different aspects into each view using methods house in each controller. After that, I would edit each view to ensure the user (or Scout) was seeing the right data and each form was submitted successfully. Honestly, I found the helpful structure of Rails to be much more simplified and more efficient than Sinatra.

Issues that Arose

Nested resources- One of the harder aspects of this project that I had to wrap my head around was how to create an ‘index’ view (or even a functioning ‘new’ view) that would change depending on which attribute was being plugged in from the controller.

For example, if a user went the link /scouts/16/scout_badges, they would see a list of all of Tiffany’s Merit badges. But if the user went to /scout_badges, they would see a list of all of the badges in the troop. Working on the code in both the controller and views pages, I was able to solve this issue.

OmniAuth- As I mentioned above, OmniAuth is a gem used to authenticate a user using a third party system (like Google or Facebook). Since this is not something I was familiar with before, I had to review labs and videos to understand how to set it up. As you can see in my video, I was able to set it up successfully after some studying.

Migration Issues- This was more of just needing more practice, but early in the project, I always had to go back and look up how to make a new MVC and migrate properly (“rails g resource.”) After working on the project for a little while and creating a few different resources, I think I was able to get a handle on the process.

For Another Day

I hope to add more attributes so that each Scout can share more information about their camping trips and merit badge experiences. This can include uploading pictures and a blogging function. Additionally html and CSS need to be updated to make it look a little prettier. I think the structure I have in place can become an exciting final product and will continue to work on it as I continue to develop as a Web developer ;-) !!!

--

--