Skip to content

Case study

EGT Digital X-Ride Miner

A miner that collects rounds from a live betting page and a separate viewer that filters and aggregates them, both shipped as executables to a non-technical operator.

Overview

Two programs, not one. A miner that sits on a live betting page and records every round to a spreadsheet, and a separate viewer that reads that file back, filters it by a start and end time down to the second, and aggregates it per player.

Both shipped as compiled Windows executables to someone who does not use a terminal, which shaped almost every decision in the project.

Complexities tackled

A number split across two HTML elements. Amounts above 999 were being recorded as 1, 2 or 3. The page renders the thousands separator as a separate element, so the extractor was reading only the leading digits and discarding the rest. The client was certain the file format was to blame and asked twice to go back to the previous format. It was not the format, and saying so rather than complying was the difference between fixing it and shipping the same bug in a different container.

A failure that looked like success. An encoding error on an unexpected character was aborting the write loop. The tool carried on displaying that it was collecting, and silently stopped saving anything. Because the bad input could not be reproduced locally, the fix was in two parts: make the loop survive the error and resume on the next round, and log the offending fields to a file so the actual data causing it could be identified rather than guessed at. Instrumenting beats theorising when you cannot reproduce.

Every build stopped working on the same day. They had been compiled as development builds, which expire. Nobody notices this while iterating daily; the client notices it immediately. Reshipped as a distribution build, and the point was checked explicitly with the client rather than left as an assumption.

Diagnosing a fault that was not in the software. After the client changed machine and country, the data appeared corrupted. It was Windows regional settings changing the expected delimiter, so the same correct file parsed differently. That was called correctly on the first look, the client was walked through the import settings, and when that did not stick the honest recommendation was to use a different viewer rather than to keep changing the file. The client eventually confirmed it independently.

Being explicit about what could not be tested. Access was to a demo instance producing two rounds at a time, so a realistic test run lasted minutes and could not exercise the cases that a live site produces in an hour. That is why regressions reached the client, and it was said plainly at the time rather than offered afterwards as an excuse.

A dependency choice with a tradeoff, explained. The browser driver is fetched at run time to match whatever browser version is installed, rather than bundled. Bundling would remove a download and add several megabytes, and would break silently the next time the browser updated. The client asked what happens if the download URL ever disappears, which is the right question, and got the reasoning rather than a reassurance.

Support after the money stopped. The contract was closed and then three more weeks of debugging followed, unpaid, including a further release. A tool that runs unattended is only useful if someone will still answer when it stops.

Stack

Python with Selenium and Playwright driving the live page, packaged as standalone Windows executables, writing to CSV for fast incremental appends on a file that grows to millions of rows.

Client feedback

Verbatim from the public review left on the completed contract. Clients are not named because the contract record does not carry names.

Very good and very fast!
5.0 / 5.0 · Upwork ·

Working on something similar?

Tell me what you are building and what is in the way. I will tell you honestly whether I am the right person for it.

Start a conversation

Last updated: