29
.
04
.
2024
16
.
01
.
2023
Ruby on Rails
Startups
Business
Backend

The origin of Poltrax development - story of POLTRAX (part 2)

Stanisław Zawadzki
Ruby Developer

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.

panel_admina

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.

Kropki

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.

  1. Performance issues
  2. User-proof designs (auto refreshing)
  3. Device issues
  4. 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.

Sidekiq

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.

Trasa

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:

Stanisław Zawadzki
Ruby Developer

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Ula Sołogub - SQL Injection in Ruby on Rails

The Deadly Sins in RoR security - SQL Injection

14
.
11
.
2023
Urszula Sołogub
Backend
Ruby on Rails
Software
Michal - Highlights from Ruby Unconf 2024

Highlights from Ruby Unconf 2024

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality
Cezary Kłos - Optimizing Cloud Infrastructure by $40 000 Annually

Optimizing Cloud Infrastructure by $40 000 Annually

14
.
11
.
2023
Cezary Kłos
Backend
Ruby on Rails

Smooth Concurrent Updates with Hotwire Stimulus

14
.
11
.
2023
Michał Łęcicki
Hotwire
Ruby on Rails
Software
Tutorial

Freelancers vs Software house

14
.
11
.
2023
Michał Krochecki
Visuality
Business

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial

GraphQL in Ruby on Rails: How to Extend Connections

14
.
11
.
2023
Cezary Kłos
Ruby on Rails
GraphQL
Backend
Tutorial

Tetris on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Backend
Frontend
Hotwire

EURUKO 2023 - here's what you've missed

14
.
11
.
2023
Michał Łęcicki
Ruby
Conferences