My Second Project: Sinatra Web App

Compared to my first ever project, I went into this second one with an ounce more of confidence. Not with an ego that I knew exactly what I was doing and it was all a piece of cake (spoiler alert: I didn’t and it wasn’t!) but with the confidence in myself that I believed I could figure it out.

Building upon our recent Ruby knowledge, for our second Flatiron School project, we are tasked with creating web app utilizing Sinatra, which is a pre-written collection of methods that we can utilize in Ruby to abstract some of the concepts we’ve learn so far. More specifically, we are to create a CRUD (Create, Read, Update, Delete), MVC (Model, View, Controller) app using Sinatra.

The project app was supposed to be a custom app that is created to track something important to you. I’ve been training for a half marathon race recently, so the first thing that came to mind when I began reading the project requirements was to create a way to track runs! It seemed simple enough in theory, but things never are quite as easy as you want them to be.

I had a lot going on between life and work, so I did not get to start my project ahead of time, or even on the first day as I had intended! 😅 As soon as I had a good chunk of time to devote to starting, I put my head down, reviewed RESTFUL routes a lot, utilized the Corneal gem to get a barebones Sinatra app file structure, and spent the next 2 days grinding toward a functioning app that hit all of the project requirements! I could always make it look better after it was functional!

One of the biggest issues I ran into during my project build was making it to where the current logged in user of my app ONLY saw the runs that they created, not another users. This would also limit the user to only editing and deleting runs that belonged to them. I struggled with this issue for many hours, Googling to no avail for my specific issue. At my wit’s end, I finally had the bright idea to utilize one of the most basic and first things we learn in the curriculum: the Pry gem.

I’ll admit that I’m stubborn, and tend to avoid using Pry as often as I probably should, although with no real reason!! Throwing a binding.pry into my route for posting the new runs allowed me to see the values of my created runs table. I discovered that I was creating new runs without actually assigning them a user_id value that corresponded to the current user’s ID! *facepalm* It was a simple enough fix, adding in @run.user_id = session[:user_id] to the route after creating the run and before saving it to the database. This ensured that each run created would get the current user’s ID and I could limit the user that sees it by only calling on the runs of the current user to be shown in the view! This was an integral part of my app, and I’m glad I finally pushed through the problem.

Another fun challenge I had in this project was less about Ruby code per se, but was in figuring out how to auto-display every created run’s average pace per mile! Utilizing ERB tags ( <% %> ), you can write ruby code that won’t show on your view pages, which is very important in allowing you to display things properly.

The average pace of a run is the duration of the run divided by its distance. A user is submitting their run details in hours, minutes, and seconds, but you can’t cleanly just divide something like 1 hour 13 minutes and 44 seconds by 6 miles. To end up with a usable average pace value, I converted the input duration values into seconds and added them together for the total seconds of a run. You can then determine the seconds per mile by dividing that by the distance, and determine the minutes per mile by diving that seconds value by 60. You must then get the remainder of seconds that didn’t make a whole number minute and you have your average pace, which is the minutes per mile and the seconds remainder. A fun thinking challenge that I believe is crucial to have on any run tracking application!!

Overall, I did feel better about building this project and always learn a lot by throwing myself in and having to learn by doing and struggling through working out the errors and bugs! Getting started from nothing is the most daunting part, but slowly working toward the end result a little at a time makes a seemingly impossible task possible. Looking forward to my project review and the next module as I nail down my learning to code routine and fit it into my daily schedule!