At the Flatiron School (FI) we’re required to present at least one technical talk. Not to be outdone by classmates most people go all out with the knowledge they have at the time. My partner and I decided to build a dashboard with the help of DashingIO (http://dashing.io/).
We wanted to build a dashboard that could be accessed by the students individually and on the big screens around the lab area. Dashing IO provided both of these features out of the box.
We wanted to show 1. what new blogs have been posted? 2. is there anything fun to do later? and 3. how am I doing on labs?
The first was accomplished in name, the second was ignored completely, and the third question took most of our limited time. Labs are assignments given by the FI instructors. Each lab is a source of its own anxiety for each student. The one thing students don’t want to be is behind other students on labs. So we thought our dashoard would help them realize they were travelling with the pack instead of trailing it.
I’ll say right now that we learned a lot and didn’t really know what we were undertaking at the time.
Instead of noting what worked, I’d like to point out what we didn’t do right since that’s where most of the really good lessons came from:
We didn’t start with object orientation and we kept pushing forward with procedural code. Reusing any of this code would require a lot of familiartiy with the project, and it’s quite ugly to read. A little OO would have gone a lOOng way.
The major feature of our app is that it shows users where the group is on ‘labs’ or ‘assignments’ on GitHub. Our app updates a graph with forks and pull requests indicating starts and finshes of labs. Our app authenticates as a particular user of the organization that includes all of our assignments: “flatiron-school-labs”. And then it foolishly requests all pulls made to each repository, and then all forks made to each repository. Each of those is a separate request and slows the app as you would expect. We realized too late that making those requests concurrently would have sped things up significantly.
We didn’t cache data or ask the GitHub server if the data had changed? Checking if the current query’s results are the same as the last set of results doesn’t count against our API request limit, and would have been the right thing to do as decent “api citizens.”
And of course instead of checking for pulls and forks every scheduler cycle, we could have just been notified by the GitHubAPI when something changed, via the GitHub Notifications API. Unfortunately we would need to authenticate as a user that was subscribed/watching each repository to be able to do this. As students only partially through the program, subscribing to every repo seemed silly.
We relied too heavily on Dashing IO to handle graph widget creation. Dashing IO relies on D3, and futzing around with the coffeescript examples provided was a huge pain. If we were to do it again, we’d go straight to D3…in fact we’d skip Dashing IO and roll our own layout and javascript featureset.
Here is a link to the video of us demoing the app. Git/IronDash-Demo