Just started a new project! We are building an application that helps runners and friends unite. Through our site they can organize group runs and subsequently view data about the individuals on those runs by using and connecting their Fitbit, Nike+, RunTracker, DailyMile, MapMyFitness (to name a few we are thinking of) to our site. So, we will be integrating with those APIs to make that work. It feels like this is a legit product that people would want to use. I like the fact that we are focusing on running rather than trying to make it a broader, less focused, health and fitness app. I have heard that building apps that have all of the bells and whistles, and try and solve every problem are often less successful than those that specialize in solving one or maybe two problems.
Regarding the teamwork component of this project, I think we have kicked off a good dynamic that will help us get work done efficiently and have fun while doing so. Thus, far we have split into two pairs, one pair focusing on front-end prototyping and the other on integrating with the RunTracker API (we will integrate with the aforementioned list of APIs after we get one successfully up and running). This group dynamic is good for now, but I know that I need to learn the API integration stuff, so it would be great to rotate the focus areas throughout the next two weeks. A few other organizational tactics my group has put in place include doing group code reviews of each pull request (to keep any of us from just flying through the changes that someone made without really knowing what they changed), daily stand ups before each work session (to keep us on the same page and give us a chance to demo our work/make sure that we can truly explain our code & design decisions), and track-bugs/back-end stuff of GitHub, rather than Pivotal Tracker. I believe that all of these are positive practices that will enhance our group experience and our final product.comments powered by Disqus