A searchable report of the active catalogue.
Make catalogue information easier to inspect.
Where this work fits
The schedule said what should play. Reporting needed to know what did play, including when a device lost its connection or a prayer interrupted a track. Sending each record immediately was not always possible.
I built reporting that connected active tracks with their station and catalogue information. Scheduled preparation kept the report available for filtered, paginated queries and export without rebuilding the entire view for every request.
Understand what the measurement counts
The denominator matters.
Different questions deserve different measures.
40 applications submitted in total.
This total counts submissions. It does not tell us how many people started an application and finished it.
Keep the record until delivery succeeds.
Removing a record when sending started could lose it on failure. I retained unsent records on the device and removed the sent batch after success. Monitoring had a related timing problem: it needed to allow for delayed evidence before treating an expected event as missing.
The skills behind the work
- SQL
- Query and update relational data, with clear rules about which records a result represents.
- Caching
- Reuse prepared information while making sure outdated values can be refreshed.
- Query filtering
- Narrow records to the information a person is trying to find.
Unsent playback records could survive a restart and travel when connectivity returned. Monitoring made missed activity easier to investigate, with alert outcomes recorded separately from the detection itself.