Sinatra Fitness App (UPDATE)
This is a supplement to a previous post about Fitness Tracker Sinatra app I built.
What's the Update?
Upon submission of my project, I decided to do some styling to make the app a little easier on the eyes. However, I discovered a litany of underlying bugs that proved too detrimental to ignore. I'm writing this post to touch on what happened, what I did to fix things and why I made the changes I made.
What went wrong?
I discovered two monumental bugs.
(1) Because an Excercise
belongs_to a Routine, there's a one-to-one relationship and, coupled with the fact that each Exercise was unique by name, Exercises could inadvertenly be "taken" from one User if another User created (or added) an Exercise of the same name
(2) A join-table,
RoutineExercise, was created to allow for an Exercise to be able to point to many routines (using a
has_many through: relationship). However, this was cause a bug where a newly created (or added) Exercise would display twice because it was tethered to two classes.
After much thought and deliberation, I decided to simplify the model structure and do away with the
Routine model altogether. This meant that a
has_many Exercises and an
Why All the Changes?
At first, I felt a little embarrassed about having to sort of scrap my original idea and work with a simpler one. But then I realized that the point of the project was learning about Sinatra and how you can build a simple web app with it, utilizing sessions, user auth and the seven RESTful routes.
The tough lesson I learned from this project was that it is really important to build out that minimum viable product as fast and well as possible before delving into extra features. For my sake as a developer who wants to strike out in the industry, I needed to mature professionally and this project felt like sort of a wake up call.
Thankfully, the refactoring process was simple and seamless. Feel free to fork and clone the repo and check out the site!