Data & techie stuff for BAFS 2017
- This topic has 179 replies, 36 voices, and was last updated 8 years, 1 month ago by
.
-
@BobCochran 153030 wrote:
So you have n rides out there and each one has a cell phone and the phone could be running a nice virtual machine in the form of a Docker container. And no I don’t know Docker well. I haven’t studied it closely and most of all played with it the way I should. But anyhow these riders are each running a virtual machine and inside that machine, a Freezing Saddles app is humming away. It’s recording the miles the rider is doing. It’s storing that data away.Meanwhile, Node, or some other ES6/ES7 scripting engine, Express, and MongoDB all containerize well.
Even SQLite containerizes well.
What you’re describing is basically fulfilled by applications like Srava. They are not distributed in the same way that Git is, but the effect is the same: you log your miles, they’re stored away, and you look at your dashboard and you see all your friends’ activities just as soon as they post them. There’s no need to reinvent that system. Sure you could do it without Strava, but Strava does it elegantly. Not to mention the herculean effort to create Android and iPhone ride tracking apps … The problem right now with the traditional Strava API is that it must be polled to learn of new rides. Well, this actually is less true than it used to be; they have added webhooks (http://strava.github.io/api/partner/v3/events/) which allow an application to subscribe to events like “new activity”. If someone (hint, hint
) would like to implement that in Freezing Saddles it would mean real-time updates to our leaderboards. As it is, though, having a few minute delay is not exactly terrible for our purposes. Probably there would be some benefit to a tighter sync on the last day of competition, but with a competition sized at 250 people, we’re able to sync all the riders on a very regular basis. (And Strava increased API limits for our app. The weather data has a more limiting API — 500 reqs / day, which when you consider that participants often ride more than once per day is much closer to maxed out.)There’s really no technology problem with FS, other than a million things we could build but no one with the time to do it. We could, for example, start using the geo indexes — show participants other people that ride similar routes and start at similar times of the day. We could find intersections in routes to find out who crosses paths with regularity and where they cross. You could find areas where most cyclists seem to converge around the sames times and propose new coffee-shop locations. You could find out the best roads to ride when it snows. Or what the trail conditions are based on riders’ routes, speeds, wattage, etc. We could find groups that ride together. Really, the possibilities with the current datasets and possibilities are pretty endless. What great data for dataviz exploration. I’m a bit sad that my work always becomes a frenzy in winter time, as I find the possibilities endless. I probably would make some technology changes if I were really working on the project, but we certainly haven’t run up against any serious technology limitations to date. The constraint is human resources.
On a side note, Docker is interesting technology (I use it every day), but I’m not sure it makes sense in a phone context. You don’t need docker to have sandboxed applications on phones and there’s probably little value to running n instances of a georecording container (app) on a phone. Docker is a great tool for software deployment on server infrastructure, as it simplifies configuration management, empowers developers to work with deployment-like images, and makes provides a nice abstraction for scaling and orchestration frameworks. Those use cases don’t really apply to people’s personal phones, though.
To be honest, I don’t know much about NodeJS, Express, Mongo, etc. I’ve done a fair bit of async programming, though, and so I bring a little bit of skepticism that these are simpler ways to build applications. Async programming — promises/deferreds, callbacks, etc. — is hard. Harder, in my opinion, than managing threads and shared state. But, to be fair, most of the actual “work” being done by an application like FS is I/O work, specifically HTTP and database. And, assuming you have async db drivers (which I’m sure mongodb does since that’s the poster child for use with nodejs), this certainly can be handled well in an async model. But I don’t see any inherent advantage. I’m admittedly not a huge javascript fan; ES6 is better, but I would never look to JS as a server-side language. The state of JS package management is an absolute feed frenzy. Transpilers make debugging even more complicated. And debugging callback hell or Promise chains is absolutely ridiculous. But that’s enough about that!
@hozn 153056 wrote:
Well, this actually is less true than it used to be; they have added webhooks (http://strava.github.io/api/partner/v3/events/) which allow an application to subscribe to events like “new activity”. If someone (hint, hint
) would like to implement that in Freezing Saddles..We could, for example, start using the geo indexes
Hans, thank you for taking the time to discuss this with me. I hear you about webbhooks and geo indexing.
A little earlier you were hinting at a user interface you are interested in. Can you please tell me more about that when you have a moment? I should have asked for details earlier but forgot.
Thanks a ton
Bob
- You must be logged in to reply to this topic.