shultz.foo
Software Engineer, DevOps
jshultz.biz@outlook.com
AI
2026-10-16It's the worst time, ever, to be graduating with a degree in CS. But, it may be the best time in history to be getting into tech.
Hello World
2026-03-31Every pompous portfolio website has to have its genesis.
Articles
XR Laboratory, Multi-View Camera Cluster (Directed Study)
May 2026 to PresentFor Pitt-Johnstown
Currently laying the backbone for Pitt-Johnstown's Extended-Reality laboratory.
I'm currently working with Dr. Ohl to develop a low-cost multi-view camera system for what will one day be UPJ's very own XR lab.
I've engineered a network cluster on a managed VLAN switch with isolated components. A dual-homed controller node acts as a gateway, provides DHCP and NAT to camera nodes.
I've also automated with Ansible. The entire depolyment solution is containerized.
I'm now working to develop a python library to facilitate synchronized image capture across nodes.
(Updated Oct 2026)
SKILLS: Linux, Ansible, Networking, Docker, OpenCV, Python
DeVilbiss Healthcare Internship
May 2025 to August 2025, May 2026 to August 2026Software Enginnering Intern I, II
Collaborated with a team of software engineers to support the needs of the production of medical devices.
Log Backup Service
Developed the Log Backup Service: a .NET Windows Background Service which runs on each production-line PC and uploads logs to a central location. The tool compresses logs by day into an archive as well as parses them and stores key lines in SQL server where they can be searched on.
Logs are very important at DeVilbiss as they serve as a history of the production line. They record more than just software function; they record instrument readings, operators, and key times. When something goes wrong on the production line, the first step is to check the logs.
The issue was, to check the logs, the software engineers had to physically access the production line machine and leaf through folders over hundreds of thousands of lines to find what they were looking for.
Additionally, there was no redundancy in place. A machine going down meant that the logs contained within were lost.
The Log Backup Service solves this by parsing and backing up logs at a scheduled time daily. The service parses each log line and checks for warning, errors, instrument readings, and even the beggining/ends of subprocesses within the software. The "important" lines are then stored in SQL server where they can be keyword searched.
The actual log files themselves are compressed into an archive by day and uploaded to a shared file storage location.
Essentially, with this system, the SwEs are able to perform a keyword search for information they care about, and then they can access the compressed archive containing the rest of the log file to get the rest of the information. When I left at the end of the summer of '26 there was talk about creating a web app to facilitate this process.
Unified Sound Tester
Developed the Unified Sound Tester, an application used daily on the production line to verify whether each unit meets acceptable volume standards during operation. Prior to this project, the sound-testing process relied on three separate applications. The goal was to consolidate them into a single, streamlined tool to increase production efficiency, reduce redundancy, extend long-term maintainability, improve scalability, and enhance operator experience.
Oxygen Analyzer Saturation Testing
I conducted R&D testing that proved waiting three minutes for our oxygen analyzers to become saturated was unnecessary. Was able to reduce the three minute delay down to a minute and a half, essentially saving the company a minute and a half per unit produced.
SKILLS: .NET, MS SQL Server, .NET MAUI, Full-Stack dev, QA, Git/GitHub, Jira, MS Access, Winforms, Software Testing, Documentation
Helpdesk Shift at Blackington
March 2026 to April 2026For Pitt-Johnstown (CS1762 Web Programming)
My friends and I built a browser-based Five Nights at Freddy's fan game along with a deployable Node.js backend to serve it.
The server is written in TypeScript and connects to MongoDB, providing user accounts, JWT-based authentication and authorization, and a REST HTTP API.
The Node.js application serves the game directly to the browser, giving players a charming FNAF experience backed by a full account and persistence layer.
At one point the project was deployed behind an Nginx reverse proxy with TLS encryption.
The really interesting part of the project is that we used no front-end libraries. Poor Danny sculpted a pseudo-rendering engine from scratch in TypeScript just to make the game work. I was more involved with architecting the game engine itself and the server components.
SKILLS: Front-End and Back-End Web Dev, Node.js, TypeScript, REST APIs, MongoDB, HTML, CSS, JavaScript, Nginx
I build this website using Next.js, containerized it, and set up an auto-deploy pipeline with GitHub actions.
Web Dev
I decoupled everything, so all the articles on the homepage and the projects on this page are all read from markdown files, parsed, and dynamically displayed here. To add onto this all I have to do is drop in a new markdown file!
As far as the web dev part of this project goes, it was fun to use React. I think react makes a little more logical sense than template engines, the reusability/componenets of React feels similar to using regular functions. Next.js had a lot of conveniences that I liked. Not sure it would be my first pick for building a web app for industry, though.
DevOps
By far the more interesting part of the project, I full containerized the project and set up a GitHub actions workflow to auto-deploy the my VPS on push/merge to main.
Using docker, I was able to get the project size down from 2.34 GB to just 288 MB!
The auto-deploy workflow operates as follows:
- Build the dev image for linting/testing
- Build the prod image and push to docker hub
- SSH into my server and restart a systemd service, which will pull the latest image.
I always wanted a website with my name on it. Before this I had a little GitHub pages site that I spent a lot of time on. Honestly, I'll probably revisit that one day. Since this site is nearly just static pages I could probably implement something similar with GitHub pages and not have to pay hosting fees.
But, this was still a great exercise in React, the web servers, Docker, and GitHub actions.
SKILLS: Front-End Web Dev, Next.js, React, TypeScript, HTML, CSS, Nginx, Docker, GitHub Actions, DevOps, Linux
Seth Baker and I designed and implemented a custom interpreted programming language, constructing the entire interpretation pipeline from the ground up.
The project involved building four core components that work together to transform source code into executable output:
Lexer — Tokenizes raw source code into meaningful symbols Parser — Performs syntactic analysis and constructs an abstract syntax tree from the token stream Analyzer — Performs semantic analysis and validates program structure Evaluator — Executes the analyzed code and produces results
Seth wrote the Lexer, I wrote the parser, and Dr. Ohl gave us the bones of the Analyzer and Evaluator which we both worked on together to make a little language.
This end-to-end implementation gave us deep insight into how programming languages work under the hood, from the first character read to the final output displayed.
I like Rust quite a bit. I know a LOT of people who don't, including Seth (lol). But, if I had to choose a language to write performant code, it would be Rust.
When I took Programming Languages in college I felt like a sucker. I thought to myself, "I'll never use this! Why am I wasting my time?" but this project genuinely is one of the most important things I ever did in college. Understanding how a programming language works is something I have used every single day since this class. It has helped me with not only debugging but picking up new languages quickly. Believe it or not, a lot of documentation asssumes you know these concepts!
SKILLS: Rust, Programming language design, GitHub
GAPVAX Internship
June 2024 to November 2024Engineering Intern
The Section 4 Template Generator--or "Manual Generator" as everyone else calls it--is a tool I built to streamline the creation of owner's manuals for GapVax trucks. I used OLE automation to control an instance of Adobe Acrobat within Microsoft Excel, using Excel workbooks to handle user input and Acrobat to edit and save PDFs.
GapVax designs and builds highly customized vacuum trucks, and each one ships with a detailed owner's manual. In them, section 4 "Operation" covers how to use every piece of equipment on the truck, but because no two trucks are exactly alike, each truck requires a unique section 4 that needs to be created by hand.
While that level of customization showcases GapVax's quality, it makes manual creation slow and labor-intensive. By the time I joined, production had scaled dramatically, and the old approach to Section 4 had become a serious bottleneck.
When using the tool I developed, the user is presented with a list of optional equipment features for a specific truck model. They can then select the desired features from the customer's order, and the program generates a customized section 4 template of documentation based on those selections. While some adjustments may still be necessary before the final document is ready to be included with the final manual for the truck, the tool significantly reduces the manual effort by automatically assembling the relevant content starting points for the chosen options—essentially handling the tedious "gluing together" of documentation for optional equipment features. This is where the bloated name "Section 4 Template Generator" comes from.
Using Excel as an app platform may sound strange; I thought so too. But leadership had good reasons: they needed something requiring minimal maintenance after I left, easy to distribute without an installer, and familiar to non-technical staff. Excel checked all three.
I split the app into multiple front ends and a single back end. Each front end is a standalone workbook containing only UI — buttons and configuration for a given truck model. Users copy the UI workbooks wherever they like and can move, duplicate, or share it freely without breaking anything, because all the logic lives in a separate backend workbook that runs invisibly in the background. Each front end makes a single call to the backend's API, which works with any correctly formatted frontend.
Adding new truck models requires no coding. Just duplicate an existing front end, configure it for the new model, and it works. Content options can be added directly in the workbook by inserting rows or using the wizard I built.
The biggest challenge was the scripting language itself. Visual Basic for Applications technically supports classes but lacks inheritance, polymorphism, and proper exception handling (yes, I had to use OnError GoTo). Despite that, I implemented the MVP pattern and a clean front/back end split. This was my first industry project--freshman summer--so following sound engineering principles took lots of research. I came away with a genuine appreciation for why OOP exists, plus practical experience in requirements gathering, designing for non-technical users, backend architecture, and, in general, I learned how to read documentation and forums to find solutions to my problems.
SKILLS: Visual Basic, UI/UX design, Requirement gathering, Rapid prototyping, Backend design, Creative problem solving, Microsoft Excel scripting