Aiden Gonzalez

A single-node time series database for home server observability, written in Rust. Implements the Prometheus HTTP query API so existing Grafana dashboards work unchanged. Aims for under 100MB resident memory for 10,000 active series, 5,000 samples/sec ingest, p99 query latency under 500ms on 24-hour range queries.

Ingestion is hybrid IPC. Publishers register over a Unix domain socket and receive a shared memory segment. Sample batches travel through a per-publisher SPSC ring buffer and are signaled with DataReady messages on the socket. Writes land in an in-memory head block (immediately queryable) and an async-fsynced WAL in parallel. The head block flushes to an immutable Gorilla-compressed block file with an inverted label index every two hours or at a size threshold. Queries hit an HTTP API that runs the PromQL pipeline (lexer, parser, planner, executor) and merges results from the head block with on-disk blocks (head block wins on overlapping timestamps).

Flush atomicity uses POSIX rename: write to .tmp, fsync, rename to .db, then truncate the WAL. On startup, stray .tmp files from interrupted flushes are discarded, the in-memory block manifest is rebuilt by scanning .db headers, and WAL replay (idempotent via overwrite-by-timestamp) restores the head block.

Cargo workspace of seven crates: ipc, write-path, query-engine, storage, api, arena, and the main binary. Dependencies follow data flow, which keeps the graph acyclic.

Two repos: a Flutter mobile client and a Node.js + PostgreSQL backend. The backend runs on Kubernetes with signed CloudFront URLs for media.

Jasper Ridge sends each client a financial statement package every month and quarter: a cover sheet, then a balance sheet and statement of investments for every fund, merged into a single PDF. I built this engine as a C# ASP.NET API that assembles the package straight from fund accounting data in Snowflake, rendering each statement from HTML templates into print-ready PDFs.

Generation is parallel wherever the work is independent. The queries for balance sheet data, investment data, and footnotes run concurrently, and every fund's statements render in parallel before merging back in order. The statement of investments is composed from small Handlebars templates, grouped four levels deep with subtotals at every level, and footnote references resolved per deal.

The engine is also designed to fail loudly rather than publish a wrong number. Balance sheet and investment totals are reconciled for every fund. Rounding-level differences are absorbed, but a tolerance check fails the whole run when the two data sources genuinely disagree.

Jasper Ridge allocates each fund's income across its investors every period: management fees, carried interest, preferred return, loss deficit roll-forwards, transfers, all interacting. In fund accounting, a number nobody can explain is a liability. This engine (C# .NET backend, React AG Grid frontend) was built so that every number it produces can explain itself.

At the core is an operation tracking framework I designed and built. Calculations never produce bare decimals, they build expression trees. I gave the base Operation node overloaded arithmetic operators, so calculation code reads as ordinary math (balance * rate * days, in decimal, never floating point) while each node records its type, its arguments, and a source label naming where the value came from. Implicit conversions to and from decimal mean existing calculation code works on the trees without modification.

Keeping full derivations attached to every value takes some care to stay cheap. I built in logic to collapse nested adds and multiplies into flat argument lists, swap labeled subtrees for shared references instead of duplicating them, and cache each node's result, recomputing only when an argument's value changes (thread-safe, with cycle detection on references). An Uncalculated sentinel I added throws if a step consumes a value before the step that produces it has run.

The same tree can be rendered in many ways: JSON for the frontend, a plain math string for logs and tests, and live Excel formulas with named ranges, so exported workbooks carry the actual calculation in each cell rather than a pasted result. The engine itself is the composable part: allocation logic lives in discrete steps (each declaring what it computes and what it requires) that are assembled into pipelines for each fund.

For a study on regular expression comprehension tools, I helped develop a web app (React frontend, Python Flask backend) to run participants through the experiment and collect data. The app allowed our 4-person research group to gather enough data to draw conclusions in the paper.

From the paper's abstract: Regular expressions are notoriously hard to intuitively comprehend. Debugging issues with them can also be difficult. Several techniques have been created to help alleviate this issue and make these expressions easier to understand.

Existing techniques include everything from diagrams to equivalent code to natural language descriptions. However, there is not a lot of empirical evidence to show which methods are most effective in aiding regular expression (regex) comprehension.

In our work, we conduct an experiment to study and measure the effectiveness of several different comprehension techniques. By doing so, we are able to provide empirical support for the strongest of these techniques, encouraging its adoption to fight regex-related bugs in software.

To make our contribution, we select three popular and distinct regex comprehension techniques and integrate them into a custom-developed experimental tool. The tool has various measurement techniques to monitor user comprehension of regular expressions. After many trials with a comprehensive sample of developers, comprehension of the different techniques is analyzed, and findings are presented.

A reference CI/CD pipeline I built at Precocity for Kotlin API development. It runs against an example API written previously by a colleague, triggered on changes to a specified folder in the repo.

The pipeline spans 10 stages across 20 jobs: Gradle build and test, code coverage, four parallel static analyses (vulnerabilities, formatting, likely bugs), Docker packaging to two cloud container registries, image vulnerability scanning, deploy to a Google App Engine Flexible test environment, performance and functionality API tests, Google Web Scanner security tests, a Slack-notified gated production deploy, and an automatic dev-to-master merge after a successful prod deploy.

It served as a launching point for subsequent Kotlin API work at the company.

Senior design capstone with a three-person team. Lantern is an open-source accounting MVP for small business owners: link a business bank account through Plaid and the app produces instant views of financial health.

Built on the MERN stack (MongoDB, Express, React, Node). My contributions were the API specification, the backend server, and several frontend features. I also ran the GitHub project (issue triage, PR review, merges) and configured the GitHub Actions CI/CD pipeline so every PR ran tests and lint checks before merge.

A Slack app I built for managing OpenAir timesheets without leaving Slack. Precocity employees connect their account and then log time and update their active timesheet through Slack messages and Block Kit interactive components.

Runs on Google App Engine (Node.js standard environment), organized into four files: main.js routes incoming Slack actions and outgoing responses, openair.js handles the OpenAir XML API, database.js caches session and timesheet data in Firebase Firestore, and messages.js builds the outgoing Slack messages (plain text through interactive Block Kit layouts).

Reception was strong enough internally that coworkers with no prior involvement asked to contribute after their first use.

Final project for an artificial intelligence course at Purdue: a from-scratch PyTorch reimplementation of YOLO (You Only Look Once) real-time object detection.

Tested on still images first, then fed in dashcam footage from my car to see how the network performed on real driving scenes.

BoilerMake hackathon project. TapIn replaces the awkward dance of trading half a dozen social handles when meeting someone new: each user has a QR code that, when scanned, opens a webpage with their chosen social profiles. The person scanning never needs TapIn installed.

Built with a React Native client, Express.js backend, and Firebase. The original concept was NFC tap-to-share, but we hit hardware issues during the hackathon and pivoted to QR codes to land a working demo before the deadline.

Final project for an embedded systems course at Purdue. The setup has two halves: a custom Android app, and a Bluetooth-enabled Arduino driving an LED strip. The app publishes mode changes over BLE, and the board reads them and switches the strip's lighting pattern accordingly.

Honors project for an undergraduate ASIC design lab at Purdue, working with the course instructor, Dr. Mark Johnson, to prototype a new final lab for the course: an AHB-connected 2D convolver module for hardware-accelerated image processing.

Across the semester I scoped the concept with Dr. Johnson, designed the architecture, implemented it in Verilog, and wrote test benches for both the simulated and synthesized versions. The whole thing was packaged with documentation so it could land as the official final lab for the Spring 2022 cohort.

Final project for a microprocessors course at Purdue. Pong, built up on a breadboard around a microcontroller: a two-button matrix for paddle input, seven-segment displays for the scoreboard, and a small SPI-driven color display for the game itself.

Built in the fall of 2019, this was my first experience with OpenCV.

Preprocessing (grayscale, Gaussian blur, adaptive threshold) feeds contour detection to segment characters. A 1-nearest-neighbor classifier matches each cropped glyph against a hand-labeled training set, built interactively by stepping through a training image and pressing the matching key for each detected character. Recognition then reconstructs lines and words: contours sort into lines by Y position, by X within each line, and gaps wider than half the line's maximum intra-line gap mark word boundaries.