shultz.foo
Big Projects
Some of my best work. If you want to see more of my work, please visit my github.
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
DeVilbiss Healthcare Internship
May 2025 to PresentSoftware Enginnering Intern II
Currently provide support for production line utilities, intrgreate with the company's extensive codebase and SQL database systems, author documentation per internal standards, and contribute to the quality of life enhancements our customers gain with our products!
Log Backup Service
Created the log backup service, a .NET Windows background service which runs on production line PCs and backs up logs from our software into network storage. Also created Logquel, a fully custom SQL-like query language for querying logs in our log repository, to go along with the log backup service.
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.
SKILLS: .NET, MS SQL Server, Git/GitHub, Jira, MS Access, Winforms, Software Testing, Documentation
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