Kheagen Haskins

1. Managed IT services provider

   Full-stack developer · May 2025 to present

   I designed and built the company's reporting engine. It runs in production and covers every device the company manages, from laptops and servers to printers and switches. I also run it. Scheduled tasks sync every source every four hours and restart the report server if it stops, and a runbook I wrote covers each deployment.

   Design decisions

   24

   Each one is recorded in an architecture decision record, and each one is mine. Three of them are still proposals.

   Lines of code

   84,000

   • Java 73,000
   • SQL 5,000
   • Other 6,000

   The count leaves out blank lines and comments. Half of the Java is tests.

   Time for 100 reports

   20 min

   • Engine 20 min
   • Old tool over 1 h

   Measured before any work on the engine's speed.

   One half of the engine syncs data from nine vendor systems into one database. The other half reads that data back out and turns it into configurable reports.

   1. 9 data sources Ticketing, monitoring, security, backups, training

      I built the API layers that read the company's ticketing, monitoring, security, backup and training systems over REST, GraphQL and JSON-RPC, and its data warehouse over JDBC.

   2. 1 database SQL Server, synced on a schedule

      I designed the schema and administer the SQL Server database.

   3. Domain model Tickets, hardware, backups, patches

      I designed the layer the reports read through. Each area of the business has its own interface, which returns typed records and keeps its SQL out of sight.

   4. Client reports PDF and Excel, one per client, monthly

      I design the PDF and Excel reports, laying the PDFs out in HTML and CSS. I also built the web page that configures each report.

   Why the company built its own engine

   The company used to build its reports with a vendor's reporting tool. The vendor then released a new analytics product, which offered new data but very little of what the old reports used. The old tool stayed the only way to reach the data the old reports used, even though the vendor had stopped maintaining it. It was full of bugs, and it depended on an API the vendor had deprecated. Our own engine copies that data into a database the company controls, so it can shape its reports however it wants.

   How I review my code

   As the company's only developer, I have always been the one Java engineer on the job. In place of peer review, I run layered AI audits, each covering one concern: correctness, conventions, documentation or test coverage. I repeat them until the findings turn trivial. They catch real mistakes, but a senior engineer sees what they miss, which is why working with experienced developers is a large part of what I want next.

   Service desk administration

   Alongside the engine, I am the system administrator for the company's service desk system. I configure its ticket types and workflows, and take on the occasional ticket that needs a developer. One was a one-off request to migrate a client's WordPress site. While upgrading it to a current version of PHP, I found unfamiliar files and altered settings across the site. It had gone unpatched for a long time and had been compromised, so I cleaned it out before the migration went ahead.

These are the hardest problems I have solved in the reporting engine. I worked out how each of them should work myself. My starting point was the old reports, and sometimes the API behind their data.

1. Syncing from a data warehouse that charges per query

   The hardest source to sync was a Snowflake data warehouse, reached through a JDBC driver that sends each query over HTTPS. Loading its tables into an empty database was quick to build. Keeping them up to date afterwards was the real work, and each fix exposed the next problem.

   Average update sync

   180 s

   Across all nine sources. A routine update moves less data than a first load, but runs far more logic.

   1. Testing without live calls Every query spent paid credits

      Every query spent paid credits, so I could not test against the real source. I cached one real pull as test data, then built a fake server that serves it and misbehaves on demand, by going silent or changing its schema.

   2. Schema changes The vendor changed it without notice

      The vendor changed its schema without notice. Before the sync fetches anything, it now checks that it can map every column it will write, and it reports a mismatch as a schema failure.

   3. Slow or hung A slow response looked like a dead one

      Syncs began to hang, and nothing could tell a slow response from a dead one. I moved to paging, and found the page size the source could serve reliably. Paging then raised the questions every sync has to answer, such as what to roll back when the sixth page fails, and what to do with half a page.

   4. Measuring Some tables took ten times longer

      I built diagnostic tables into the database that record each sync's errors and the time taken for every source and table. A day or two of production data showed some tables taking ten times longer than others, so those tables now sync on their own schedule.

   5. Finding changed rows Whole-table compares failed at 4 million rows

      Comparing whole tables fell over at four million rows, where one table took an hour to sync. A MERGE statement was faster but still slow. Where a table has change-tracking columns, the sync now pulls only the rows that changed since its last run, in pages sorted on the table's key. A table without them is read whole, and the largest of those are read at most once a day.

   6. History A late request for every record's past

      A late request asked for the history of every record, so I added slowly changing dimension (SCD) tracking to the warehouse's customer, site and device tables, and to seven tables from a second source. It keeps each past version of a record alongside the current one. Each table has its own tracking policy for now, and I am working towards a general set of rules that new tables can follow.

   • Snowflake
   • JDBC
   • Paging
   • Incremental sync
   • Slowly changing dimensions

2. Collecting tickets from the service desk

   The service desk's REST API returns tickets one client and one page at a time, so collecting every ticket took hundreds of requests in a row. Its Report API runs a SQL query against the service desk's own database and returns the result as JSON. I moved ticket collection onto a single query through it. Each new kind of data now needs only a SQL file and a mapping from its columns to a Java record.

   Collecting 840 tickets

   2.8 s

   • SQL 2.8 s
   • REST 8.8 min

   186 times faster, as measured and recorded in the decision record that made the switch.

   • SQL
   • REST
   • Performance

3. Separating the reports from the schema

   My first classes copied their tables, so a changed table meant a redesigned class. Every piece of code that used the class then changed with it. I split the data layer into thirteen areas that match what the reports cover, such as tickets, hardware, backups and patches. Each area is an interface that returns typed records, and its SQL and implementation stay hidden behind it. A change to the database is now made behind those interfaces, where the reports never see it.

   • Domain modelling
   • Data access layer

4. Branded charts in PDF reports

   The reports needed charts in the company's branding. The engine draws each chart as SVG from a client's data. The cover page, stat cards and score boxes are designed SVG files with slots the engine fills, so marketing can redesign them without touching the code.

   • SVG
   • Templating

• Java

  • Java 25
  • Framework-free
  • JPMS modules
  • Records and sealed types
  • Virtual threads
  • JUnit 5
  • Mockito

  Hover to read how I use itTap to read how I use it

  Java

  The engine is a set of libraries that its apps call, rather than a framework that calls them. It is built on the standard Java APIs and a few small, focused libraries, and I wire it together by hand with plain constructor calls. A stack trace therefore follows my own code from the call to the failure.

  The sync's classes receive their dependencies through their constructors, typed as interfaces, so tests pass in their own doubles. The modules seal their internals under JPMS, the Java module system, so one module reaches another only through what that module exports.

• Data

  • SQL Server
  • Data warehousing
  • JDBC
  • HikariCP

  Hover to read how I use itTap to read how I use it

  Data

  I wrote the code that generates the sync's SQL from the schema and protects it from SQL injection. Where a source reports what changed, the sync loads only new and changed rows. A stalled query is retried on a fresh connection, and a table that fails catches up on the next run.

• APIs

  • REST
  • GraphQL
  • JSON-RPC
  • OAuth 2.0

  Hover to read how I use itTap to read how I use it

  APIs

  Each vendor connection keeps to that vendor's rate limits and retries failed calls with growing delays. Login tokens refresh safely while many calls run at once.

• Reports and apps

  • OpenHTMLToPDF
  • Apache POI
  • JavaFX
  • Undertow
  • jpackage

  Hover to read how I use itTap to read how I use it

  Reports and apps

  The engine produces Excel workbooks and PDF reports with charts. Its apps run on Windows as standalone programs that bundle their own Java runtime.

• Tooling

  • Rust
  • Python
  • Maven
  • JaCoCo
  • Checkstyle
  • PMD
  • Spotless
  • Docker
  • Git

  Hover to read how I use itTap to read how I use it

  Tooling

  I write command-line tools in Rust for the jobs around a build that are slow by hand or easy to get wrong. The reporting engine uses five of them. They build and seed its test database, update the version tags in its Javadoc, turn its SVG icons into Windows icons, and restart Docker when Windows sleep breaks it. The fifth counts lines of code, leaving out comments and blank lines, and it produced the line count above.

  Every Maven module takes its dependency versions from one shared bill of materials (BOM). A module's build fails when its test coverage drops below a set minimum, and Checkstyle, PMD and Spotless check the code's style. SQL Server runs in Docker for development and testing.

1. 2020 to present

   Self-taught programming

   Certificates

   I learnt to program through my teaching, my development work and my own projects. I also relearnt maths on Brilliant so that I could use it as a tool. Each project led into the next.

   1. Noise generator Draws natural-looking textures and terrain from maths
   2. Maths The maths behind the noise
   3. ECS architecture The way data is laid out drives the design

2. August 2024 to April 2025

   Professional Java

   Full-time independent study

   After leaving teaching, I spent most of a year learning Java as industry uses it rather than as a school syllabus teaches it. I learnt Git, and worked through Codecademy's courses on Java and on the Spring framework.

3. 2016 to 2018

   Bachelor of Arts

   I completed a three-year BA at Varsity College Sandton (now Emeris), majoring in Psychology and Communication Science.

4. 2014

   Matric

   I earned my National Senior Certificate at Maragon Private Schools (now Crawford Ruimsig).