14
.
11
.
2023
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 Linkedin

READ ALSO

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
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

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Backend
Frontend
Hotwire

EURUKO 2023 - here's what you've missed

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

Easy introduction to Connection Pool in ruby

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

When crazy ideas bring great time or how we organized our first Conference!

04
.
12
.
2023
Alexander Repnikov
Ruby on Rails
Conferences
Visuality

Stacey Matrix & Takeaways - why does your IT project suck?

14
.
11
.
2023
Wiktor De Witte
Project Management
Business

A simple guide to pessimistic locking in Rails

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

Poltrax design - story of POLTRAX (part 3)

04
.
12
.
2023
Mateusz Wodyk
Startups
Business
Design

Writing Chrome Extensions Is (probably) Easier Than You Think

14
.
11
.
2023
Antoni Smoliński
Tutorial
Frontend
Backend

Bounded Context - DDD in Ruby on Rails

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

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

29
.
11
.
2023
Stanisław Zawadzki
Ruby on Rails
Startups
Business
Backend

Ruby Meetups in 2022 - Summary

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Visuality
Conferences

Repository - DDD in Ruby on Rails

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Example Application - DDD in Ruby on Rails

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

How to launch a successful startup - story of POLTRAX (part 1)

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Startups
Business

How to use different git emails for different projects

14
.
11
.
2023
Michał Łęcicki
Backend
Tutorial