For my final project, I am making a “Very Simple Sign-in Sheet Application” (or V triple-S A for short) for my dance coach’s studio. I’ve broken the project down into 3 week long sprints with the last week for any spillover user stories and debugging moving towards the final presentation date on August 31st so last Friday marked the end of my first sprint. Conclusion? Fairly successful so far. The goal for my first sprint was to create working API endpoints for authentication and sign-in sheet functionality as well as scaffolding a MongoDB using Mongoose and all of these benchmarks were met with the commit last week. Through a process I like to call “consume and assimilate” I have managed to stitch together a fully functional API from three separate Treehouse tutorials, a Scotch.IO guide and several of my old projects. In the mean time, Sean also showed us a great program called Balsamiq for creating mock-ups for your front end user interfaces and I was able to show my coach, the “product owner,” some designs so that I knew what I should be building this week.
So what does that have to do with Alice in Wonderland?
My classmate Fabian “FABproject” Martinez coined the phrase in our cohort “falling down rabbit holes” to refer to focusing so hard on a highly specific problem that you get lost in the Stack Overflow, WC3Schools, Youtube tutorial Wonderland of mostly irrelevant information, and that’s pretty much what happened to me today. Also, my particular rabbit hole has to do with time so, I guess it’s fitting that I followed the white rabbit. You see, in order to create an instance of a sign-in or lesson object, I wanted to create a date object in the local time so that I could later filter the lessons returned using the local time, but no matter what I did MongoDB would save the date object as “Coordinated Universal Time” or UTC for short. I spent hours looking at time related stack overflow posts, documentations and plugins before Sean slapped some sense into me and told me that this “problem” that I had would not even impact my end user. It was only after I stopped focusing on the time problem that I realized that while MongoDB stores all incoming date objects in UTC format, it also automatically converts filter times passed into it from local time into UTC and returns results based on that filter. My end user literally would not be affected at all. *sad trumpet noise* Anyways, I figured why let my research go to waste. The following is a list of some sites and plugins with useful date functions:
- AngularJS Date Filters
I ended up using these to change the incoming UTC time from my database into the local time format for display for my view layer. Very easy to use, and very powerful as it will use the local time of whatever machine is calling the view.
Awesome plugin that extends the functionality of the traditional DateTime data type allowing users to not only format time in ways not possible with just Angular Date Filters, but also to perform basic arithmetic like adding or subtracting days and hours.
- StackOverflow on ISOString DateTime
- MongoDB Date() Documentation
In case you were wondering about how MongoDB stores DateTimes, the documentation is chock full of exactly how much everything is displayed as UTC time all day every day. So there’s that.
It’s really easy to get caught up looking for answers for a problem that seems completely game-breaking at the time, but are actually relatively trivial. When you’ve spent a few hours on the same problem, it doesn’t matter how important you think it is to your overall project, it is time to step back, take stock of the whole situation, and maybe you’ll find that the solution is simpler than you thought. Sometimes those who wander really are lost, so thanks again Sean for pulling me out of the rabbit hole.