A Tale of One Mans Struggle. My Final Project
School is out and I spent the last three days on the road driving from Atlanta to Los Angeles, a 2000 mile drive though icy, treacherous roads, where patrol officers lurk in the bushes looking for their next prey. Ok, maybe I embellished that a little, but I’m not too far off. I’m currently visiting my family before I make my way to San Francisco to start my job hunt so I thought this would be the perfect time to reflect on how I completed my final project (calorietracker.org).
The first thing I had to decide was whether I wanted a partner, to be in a group or to do it solo. I really took some time, pondered each scenario and the most likely outcomes and what I came to realize is that I would never feel confident about my abilities unless I struggled hopelessly on my own, no matter how painful that would be. I needed the satisfaction of saying I finished a major project from concept to production.
With that out of the way I could now focus on what I wanted to create and what technologies I would use. Since all of my previous full stack projects used some mix of python and postgreSQL, I really wanted to use the MEAN stack this time. Even though we didn’t spend nearly as much time with node.js and mongoDB, I felt confident that I had the tools necessary to complete a fitness related app. For my first most viable product I would create a calorie tracker and if I had time my second MVP would include something that tracked actual workouts.
The important things are that I wanted the user to be able to search through an api of thousands of foods, collect the data the user asked for and display it on a page specific to that day. From there the user could edit the food and the total of all foods and their macronutrients would be displayed at the bottom of a table. The user would also have the option of creating their own custom food if they were unhappy with the selection from the api. These custom foods could then be seen and accessed anytime by typing that food name the custom food input box. In order to do this I knew I would need to create a Log collection that included a log array of all the foods the user entered for the day. The Log would need a date field to distinguish one log from another. I would also need to create a SavedFoods collection, which contained an array of foods the user manually created. Since there would only need to be one of these collections, it would have to be created when the users account was created.
Looking at what I needed to do from a high level seemed reasonably simple. I figured I’d get all the backend and angular logic done in the first week and I could spend a couple more days with the styling and getting it set up on apache. That of course wasn’t the case, and since a large portion of our allotted time was during Christmas break without our instructor, I spent a lot of time on Stack Overflow, even though I was yelling out “TOBY!!!” the entire time.
Console.log(“AHHHHH”);, console.log(“WHHYYYYY?!!!”);, console.log(“It will be ok”);. I believe that was about half my code in a nutshell. My initial thought was to just create new food documents every time a user requested it. That idea quickly went south as multiple foods with the same name would all be deleted with one click. It also created a lot of duplication in the database. I decided to go with the update/upsert solution and would include a Quantity key for Food that multiplied the macronutrients. One major issue I encountered was deleting and updating foods for a specific log day. Using update/upsert fixed the delete and the duplication problem but now I had another. In my Food schema I did not include anything to differentiate a food on one day from a food on another day, which meant that if I had a food with the same name, it would get updated and change the food values from a previous day. I needed to add a Date key in the Food schema and change my Log schemas log value from a string to an object with the food name and date. That way, when I create a log any food inside that log will have the same date as log. Of course another problem arose because creating a new Date creates a date that is specific down to the second. I only wanted the day and apparently there is no way (at least none that I know) to change this in the database, so I had to convert everything using .toDateString() every time.
I encountered many of these types of obstacles, but the more I worked on it the more I felt confident about figuring out a solution. I think letting too much time lapse between working is the worst because there was a couple days during Christmas where I took a break and coming back to it felt foreign all over again. It’s similar to that cold, stiff feeling after not exercising for a week.
In all, I’m happy with the results. There are a couple things I need to fix and I can always build upon the project, but what I got out of it the most was the learning experience. And by doing it alone I got to avoid the dreaded git merge conflicts. I call that a win!