Jeffrey A. Dettmann

We were moving from a vendor's system of scheduling tutors to an internal tool. This system was used by applications in two separate branches of the organization.

I built a reverse proxy for the service and had all client's applications point to it instead of the vendor service. Then, I began converting the calls so that the proxy would write to both scheduling services while reading from the vendor service. By implementing this process, I could synchronize the data in both scheduling services without any downtime.

After the full data synchronization, I reconfigured the service to read from the service and convert the results to match the API of the vendor service. At this point, the development teams from both departments were able to integrate with the new service when they wanted while maintaining full uptime and data integrity.

Our app users were encountering a degraded experience, and I tracked down the cause: increased latency in the logging of a vendor's back-end service. Through historical data found in MongoDB, I discovered that logins took less than ten seconds on average before the degradation, and afterward, they took more than 20 seconds.

Faced with the data, the vendor agreed that the problem was on their end and rebooted their servers, which temporarily addressed the issue. I set up a script to monitor the average login latency of the service, and thereby we noticed degradation before users started complaining and would then ask the vendor to reboot.

One of our apps presented users with activities designed to improve their performance on specific tasks. Users were allowed to skip an activity if they did not want to do it, and if they skipped three in a row, they left that set of exercises altogether.

I developed a visualization of the skipping patterns that showed how the method of selecting the next activity exacerbated user frustration and increased the likelihood of skipping out of the section altogether. My work led to a correction in the algorithm that selected activities for users.

Our organization was moving from a vendor tool to an in-house device with a different data model. I built a service that allowed users to convert their data into discrete units from one model to another. The service first ran heuristics on the existing data to show how cleanly the conversion would go, allowing owners of the data to choose which parts of the conversion to do first.

For the most part, the migration was seamless, but on occasion, the converted data would need to be manually validated and potentially altered to continue desired behavior. This process was completely reversible, so if the conversion went too far, the owners could go back to using the old system while determining their best path forward.

One of our tools ran batch jobs based on a set of conditions. The successful completion of a job could kick off another job, while its failure could trigger a different job altogether.

The data model for these job networks was a collection of nodes and edges that were bound together by a common naming standard. So one record would say: "A triggers B on success," and another record would say: "B triggers C on success." The system would know by the names A, B, and C that they were all part of the same job network.

My task was to take these collections of nodes and edges and render a directed graph in SVG so that users could easily visualize the dependencies of their job network.