I maintain a few home lab servers to host a variety of public and private services I find to be useful in my daily life. Running my own infrastructure has taught me a lot about Linux and maintaining reliable systems. I leverage NixOS to keep all my systems consistent and maintainable.

Current Services:

• Nextcloud
  • Self Hosted Productivity Apps
  • Calendar
  • To-do Lists
  • Cross device file sync
  • Phone Backups
• Immich
  • Photo backup
• Home Assistant
  • Local control over IOT products
• Forgejo
  • A Private Git Server
  • Hosts the source code for this website and my DevOps configurations
• Grafana and Telemetry Stack
  • Collects and Visualizes an array of metrics and logs that help me get an idea of what my server are up to
• Nfty
  • Self Hosted Push Notification Broker
  • Used for server status notification and events like disk failures
• Authellia
  • An SSO service to streamline auth for all my self-hosted services
• And more!

During my participation in the MATE Underwater Robotics Competition, I led my team’s software development and electronics. I implemented a range of features including the kinematics, state estimation, low latency video streaming, and control systems for leveling and depth hold. I also developed a flexible data synchronization system for communication between the ROV and control station with the goal of making networking related programming errors as difficult as possible.

Weighing in at 20k lines of Rust code, this project was the first large codebase I’ve developed from scratch. I learned how to plan out and iterate on the architecture of a complicated project, optimizing for both reliability and maintainability (through 3 architectural redesigns), and gained the experience of debugging and maintaining my software in the time sensitive environment of a competition.

For a more in-depth write up on the novel aspects of this project, see my related research paper.

Link to Publication PDF Download

A simple cli tool to scrape assignments descriptions and due dates from the Canvas LMS API and add them all to my task warrior and caldav todo lists.

As part of competing in the MATE ROV Competition, my team needed a cost effective and compact way to control the DC motors that powered our ROV’s claws.

I designed and programmed these custom PCBs to do just that and developed a user space driver to allow our ROV’s software stack robocode to control these boards.

I started developing this project since I wanted a way to practice for the SAT with instant feedback and virtually infinite questions. Many of the preexisting study tools either make you take a whole test before providing feedback or require you to answer 5 or so similar questions before displaying feedback.

Since I found both of these cases to be anti-features, I decided to scraped the official set of practice questions college board provides to students and make my own practice app. College board provides a web tool for generating a pdf with a set of practice questions, I noticed that the pdf conversion was preformed client side, and was so slow that exporting the entire dataset would be virtually impossible. So instead, I tracked down the API that returns the list of available practice questions, and the API that returns each question in JSON format. Then, I made a bash script to scrape the whole dataset using curl, and started to pick a tech stack to work in.

I decided to use a web stack for this project since the question data I had used inline HTML and MathML. My app gives the user instant feedback after answering each question, rendering the hints and feedback information included in the question data set I scraped. It tracks your long term performance, and includes gamification elements such as a correct answer streak.

I decided not to open source this project due to copyright concerns with the question material.

I developed a program to enumerate and rank valid class schedules. This project ended up being an exercise in code performance optimization. I was able to obtain a speed up of over 10,000x over my original naive implementation by optimizing for cache locality and reducing unnecessary computation rather than changing the fundamental algorithm or adding multithreading.

This project implements a backtracking algorithm that recursively tries every combination of class sections, and early returning from a candidate if a time conflict has been identified.

In my original implementation, the data structure representing a class section was very large since it encompassed all information I scraped about that class. It was also passed and returned by value causing numerous unnecessary copies of the large class info data structures. Additionally, the way class start and end times were stored made them inefficient to compare, and they happened to be behind as many as 4 pointer indirections. These issues resulted in the program being incredibly memory bound.

I fixed the class time representation by pre-generating compact schedule representations for each class that store the start and end times as 16 bit numbers representing the number of minutes since the start of the week. I also introduced a bit set for the days each class is held on, allowing it to skip comparing classes that occur on disjoint sets of days. To avoid the unnecessary copying of class metadata, I moved to storing this metadata behind pointers. Finally, instead of generating a merged schedule representation each time a new class was considered, I switched to representing the current schedule as a list of pointers to those pre-generated compact repersentations, where each element corresponded to a different class being considered.

These performance optimizations, and numerous others of less significance, improved the runtime duration from potentially over a minute in the original implementation to the order of milliseconds with the improved implementation.

This is small video game I worked on for the HackCMU Hackathon. Its goal is to teach the basics of web assembly in the style of a turtle game. The player must write web assembly code to help a robot reach its destination waypoint.

The game incorporated WASM function calling and definition, loops, variables, and arithmetic. It is implemented using the Bevy game engine, and the WASM runtime used is called Wasmtime. We chose the Rust programming language for this project since it has good WASM support, allowing us to easily run user provided WASM code and compile the game itself to WASM for a web demo.

In high school, I was the Software Lead on my FRC team, The Dirty Mechanics. While I was on the team, I ended up rewriting most of our software to follow WPILib’s best practices, and to better leverage FRC’s ecosystem of libraries. These changes made the codebase much more approachable, especially for my teammates without a strong preexisting programming background.

I also spent a lot of time working on our team’s autonomous capabilities. I added the ability to fuse vision data from multiple cameras to our code, introduced support for both Choreo and PathPlanner, and standardized a pattern of programmatically generated autonomous trajectories. We found programmatic path generation for autonomous to be the most effective since it allowed us to leverage the path finding based commands from teleop.

Minestom is an open source clean room implementation of the Minecraft server protocol. You can think of it as a game engine but for Minecraft. It is beneficial to highly custom Minecraft server projects where many of the vanilla game mechanics are a burden to the development of novel in-game experiences.

I worked on profiling and optimizing its networking code allowing Minestom to achieve orders of magnitude higher player counts and substantially reduced CPU usage compared to the official server software or even its performance optimized derivatives. For example, Minestom can sustain on the order of thousands of connected players in the same world where traditional approaches often fail to handle more than 200 concurrent players. Larger Minecraft server networks work by using proxies to bridging many individual Minecraft servers together, each hosting distinct worlds players can switch between.

I also worked on Minestom’s terrain generation API, command API, chunk loading API, version updates, connection rate limiting, general debugging, and its animated logo. I contributed its initial implementation of Mojang’s authentication protocol, necessary to correctly displaying in game player skins and validate account ownership. I also implemented the original conversion script to convert from Minecraft’s “anvil” world format, to Minestom original world format. Although, nowadays Minestom just uses the standard Minecraft world format directly.

This is a stress testing tool I developed while working on the Minestom project. It is designed to test how the performance of a Minecraft server scales as the player count increases.

This is a somewhat challenging problem since Minecraft clients inherently scale worse than Minecraft servers do. For example, a client can’t tell which packets are need to be processed until it decompressed them and finishes parsing their packet header, a relatively cheap operation that becomes expansive when scales to millions of packets per second. On the other hand, a server implementation can safely write a player movement packet to a binary buffer, and batch send that same packet to every nearby player at low overhead. When you consider that most packets scale quadratically with player count, this becomes a challenging engineering problem.

I approached this by going to the bottom of abstraction, building the project on top of the low level networking library mio which is basically a cross platform abstraction over epoll style APIs. We leverage the full available host concurrency by spinning up an independent instance of the bot on as many threads as the host has cpu cores. This approach allows us to remove the need for any locking or communication between threads, dramatically reducing overhead. As for packet parsing, I needed to use one of the fastest implementations of zlib libdeflate, and we use a statically known list of known important packets and only parse packets that are in that list. The way this is implemented allows it to get compiled to a jump table. Then when we find a packet we need to parse, we only read the fields that are relevant for the purpose of the bot and throw away anything else. These techniques combined with the performance characteristics of the Rust programming are roughly enough to keep up with Minestom until on the order of about 10,000 bots.

Write-up comming soon!