Projects

Problem

Alert fatigue is real. The standard approach to log-based incident monitoring, firing an alert for every ERROR-level event, floods the issue queue with noise faster than any team can meaningfully respond. The result is that engineers start ignoring alerts, the very outcome monitoring is supposed to prevent. I wanted a system that watches Loki log streams continuously and opens a GitLab issue only when something genuinely warrants human attention, not when a log line merely contains the word "error."

Approach

Log Patrol runs on a configurable patrol loop and applies three complementary layers of analysis to incoming log streams:

1. Fast-path deterministic rules catch explicit, unambiguous error-level events immediately. No ML overhead, no inference latency. These are direct pattern matches that should always produce an issue.
2. Drain3 log template mining runs on the slow-path to surface rare or suspicious patterns that don't match known error signatures. Drain3 clusters log messages into templates, which makes it possible to detect novel failure modes without hardcoding every possible error string.
3. LLM sentiment gate: before opening or updating any GitLab issue, a locally-hosted Ollama model evaluates the candidate finding and decides whether it's genuinely incident-worthy. This gate exists specifically to filter the cases where Drain3 flags something structurally unusual but contextually benign.

Findings are fingerprinted across patrol runs so the same underlying problem doesn't generate duplicate issues. Patrol state persists in SQLite. Stale issues that stop recurring are automatically closed. The entire system deploys via Docker Compose with a full smoke test harness.

Outcome

A monitoring system that operates in the background without generating noise. When it opens a GitLab issue, it's because all three layers agreed something warranted attention. The LLM gate, in particular, catches the "technically an anomaly, contextually fine" cases that would otherwise produce false positives. The project is fully typed (mypy strict), linted (pylint, pydocstyle Google convention), and tested (pytest with smoke test suite).

Problem

Running a homelab is easy. Running one with production discipline is the actual challenge: auditable changes, encrypted secrets, automated certificate management, and GitOps-driven deployments all have to work together. I wanted infrastructure that operated exactly as I'd expect from a commercial production environment: every change tracked, every secret managed, every deployment reproducible from the Git repository alone.

Approach

TuxHPC.net runs across eight physical Dell servers: three PowerEdge R610 control plane nodes and five PowerEdge R730xd worker nodes, all running Ubuntu 22.04 Server. The entire cluster state lives in a Git repository. Flux watches the repository and continuously reconciles the live cluster against it. A git push is a deployment.

Key architectural decisions:

• SOPS + Age encryption for all secrets. API keys, TLS credentials, and tokens are encrypted before they touch the repository. No plaintext secrets, ever.
• Terraform provisions Cloudflare DNS records needed before cluster bootstrap. external-dns then manages all subsequent DNS records automatically from Kubernetes ingress annotations. Adding an ingress is all it takes to register the DNS entry.
• cert-manager handles automated TLS certificate issuance and renewal via Cloudflare DNS challenge. No manual certificate work.
• Renovatebot opens automated PRs when Helm charts, container images, Flux components, or Terraform providers have updates. Merged PRs are applied to the cluster automatically. Dependency management is a background process, not a task.
• A GitHub webhook triggers Flux sync on push, so cluster updates are near-instant rather than waiting for the default poll interval.

Outcome

A running production cluster serving real services at TuxHPC.net. Every operational decision is auditable through Git history. The full infrastructure lifecycle, from bare-metal OS provisioning and networking through secrets management, GitOps, and continuous delivery, is documented in code. This is the project I point to when someone wants to understand my comfort level with production infrastructure.

Problem

GT5-Unofficial is a massive Minecraft modpack with hundreds of thousands of lines of code, and it hard-codes a Fortune III cap on ore drops across three separate ore adapter classes. The cap is embedded in compiled bytecode with no config file to change and no API to override. The goal was to remove the cap and add configurable per-dimension ore vein overrides across approximately 43 known game dimensions, without touching the upstream source.

Approach

I used SpongeMixin, a bytecode injection framework for Minecraft, to intercept the three ore adapter classes (GTOreAdapter, BWOreAdapter, GTPPOreAdapter) at class-load time and replace the cap formula with an uncapped implementation when FortuneItem mode is active.

The most deliberate design decision was testability. I extracted FortuneDropCalculator.java, the core drop formula logic, into a class with zero Minecraft dependencies. This made it independently unit-testable with JUnit 5 without spinning up a full game server. The Minecraft integration tests handle the mixin injection validation; the unit tests handle the formula correctness. Two separate concerns, two separate test strategies.

The dimension override system pre-populates configuration placeholders for all ~43 known ore-bearing dimensions. An in-game GUI (accessible from the Mods screen) supports live config edits without server restart. Server admins can also use /fortunateone reload. Release automation runs entirely through GitHub Actions: build-and-test.yml on every PR, release-tags.yml on tag push, with JitPack publishing the artifact.

Outcome

A mod that works transparently inside an enormous, unfamiliar codebase without source modifications, with a full CI pipeline and unit-testable core logic. This project is the best example I have of working inside complex third-party codebases, a skill that transfers directly to any professional engineering context where you inherit code you didn't write.

Overview

A focused, polished web application for Pokémon type effectiveness lookup. Real-time autocomplete search, accurate dual-type damage calculations, and color-coded results across all 9 Pokémon generations. The type system changes meaningfully across generations, and handling this correctly required per-generation data modules (pokemonRBGY.ts through pokemonSV.ts) rather than a single flat table.

Core calculation logic lives in pokemonData.ts, fully separated from the Vue component layer. The app ships as a Docker image (ghcr.io/tuxprogrammer/poke-assist:latest). A single docker run serves it. Scope is deliberately contained: this is a tool that does one thing correctly and stops there.