How we started writing Poltrax code?
Writing software is always the fun part, but also the one that takes most of the time. Time. Time that we didn’t have when we got the idea of a GPS tracking startup. Neither us nor any of our colleagues didn’t have much free time required for such a project. But, as it turned out, the reality unexpectedly turned into our favor.
First thing that lead us to where we are now was an event that Michał and our friends were participating. It was in late August, so around 2 months after the initial project idea. We already acquired 10 trackers for testing purposes, did some initial testing and decided to try to create a proof of concept for that event. Though I had some prior experience with the JavaScript Leaflet library it was a challenge to finish it in time, working both the work project and that Poltrax prototype, working daily till late night hours. But I managed to finish in time, it was showing the route, the participants and basic statistics. Everything was working more or less smoothly, showing all of our friends and Michał himself. And, last but not least, Michał was the co-winner of that race :)
Second thing that brought us here was a buyout. That year I was working as a contractor for a well funded English start-up that was a great employer, but I was swamped with work there. Then, in the middle of September, it turned out that the start-up was bought by a much bigger US-based company, resulting in halting almost the entire development work until they decide what to do next. And also the CTO of our team decided to cash out and take a break after an exhausting year, so they really didn’t want to lose anyone else with knowledge of the system and have anyone for maintaining existing infrastructure. So, as a consequence I had less than half of prior work and unexpectedly had some free time to my disposition. So I decided to carry on working on Poltrax code, both on the backend and frontend. Later other people joined our time on a part-time basis to speed up development and adjust it more to the designs that we created for us in the background.
Bricks that create Poltrax environment
Technically, the software of Poltrax consists of three elements. First one is a very simple TCP server. It’s used to directly connect with devices - currently it only receives messages, but has the possibility to also send configuration commands to devices. Then the data goes to the application server written in Ruby on Rails. Backend part provides three crucial functions: saving position based on configuration API for frontend app, an admin panel written using Trestle library (https://github.com/TrestleAdmin/trestle) where all the configuration happens. And as a third component we have a landing page with many map related pages, written in React. Backend and Frontend applications are deployed both on Heroku, while TCP server is hosted on Linode.
Our weekly challenges with sport events
Instead of writing everything that is happening in the application, I’ll write the biggest challenges we are facing and how we handle them currently.
- Performance issues
- User-proof designs (auto refreshing)
- Device issues
- Race specifics
As we have over 500 devices and the event can have twice as many spectators we need to make sure everything works smoothly. With 500 devices logging every minute we have 5 new position requests per second, and as we’re gathering and calculating plenty of statistics this may be a problem if we make the queries not optimized. Also, the responses are often quite heavy - with 500 competitors and routes having up to a few thousand points generating the response may be time consuming. That’s why we’re keeping route points and current participant positions in caches. Of course, participant cache needs to be frequently updated so the spectators have an up-to-date situation, still it’s much more efficient than generating results for each request.
It’s important for map pages to be auto refreshing when the position of a competitor changes. To achieve this we use a mechanism called SSE(Server Side Events). With this every minute (or different value, as this value is configurable per event) a call for new data is being made and competitors' positions change accordingly. Other things that we need to take special care of is making sure that design is intuitive - spectators very often have no or little experience using such systems, so the page needs to be fast, simple and clear. This is especially important in mobile version that holds 80% of traffic.
Device issues do not happen very often but are very hard to deal with, because they usually happen when a competitor is somewhere in the wild and we can’t even get any feedback on what is happening. So we have no idea whether the problem is on the technical side (device not turned off), the GSM part, or even malfunctioning GPS. The main reason is the weak GSM coverage, so the device can’t send new data, but sometimes the card needs to be reset, sometimes a problem can be fixed with device reboot.
Kind of surprisingly for us the biggest challenge turned out to be race specific features. Though there are some races that are a simple line between start and finish, without any additional rules or twerks, there are a large number of events where our system suffers due to race specific conditions and extra rules. Sometimes the problem is with automatic finish detection when the route visits the finish line in the middle of the route. Or we have a route with duplicated fragments, where statistics sometimes go mad. Or the competitors run in circles and it’s hard to distinguish who’s leading and who’s one leap behind. And so on, and so forth, because for organizers’ imagination only sky's the limit.
What are the plans for future development?
There are still many challenges in front of us, making a job easier for us and also for organizers, competitors, spectators, support teams and anyone using our tracking. There are few obstacles we still need to overcome for our product to be the way we want it to be, and we’re working to follow this direction. Currently, we’re working on improving communication between servers and devices, making their connection more persistent which will allow saving power and updating configuration during the events with no additional costs.
Regarding Poltrax:
