A high-performance C++ system built for a fictional client, Nexus Logistics, to centralise inventory and order processing across 5 warehouses that had previously each run their own inconsistent management system. The design follows a producer-consumer model: five warehouse threads load orders into a shared queue, then a user-selected number of worker threads (1-32) drain and fulfil them concurrently against a central inventory.

My contribution

I led the project and was responsible for the high-level system design: the overall producer-consumer architecture and how the OrderPool, InventorySystem and thread pipeline fit together. I then built the entire CLI: the full 9-option menu, every product/search/sort sub-menu, and the input-validation layer (safe int/double readers that recover cleanly from bad input instead of leaving cin in a broken state). Together these cover all the user-facing flow that sits on top of the class hierarchy the rest of the team designed.

I also took the AnalyticsManager through a full overhaul, from a handful of basic totals into a proper reporting engine: 18 metrics across global and per-warehouse scope (revenue, lost revenue, best-selling item, and category/type breakdowns of revenue, quantity, failure rate and average price), each exportable to its own CSV for Excel/Power BI, all runnable from a dedicated Analytics sub-menu I added to the CLI.

System highlights

• An abstract Product base class with Taxable, Discounted and Standard subclasses, using virtual functions so pricing logic resolves correctly through a shared_ptr<Product> at runtime.
• Thread safety via a coarse-grained inventory mutex, a mutex + condition variable on the order queue (so workers sleep instead of busy-waiting), and std::atomic<int> for lock-free order-ID generation.
• A bonus Qt6 GUI (dashboard, inventory, analytics, orders) layered on top of the CLI backend through an adapter, so both interfaces share the same core logic.
• Verified deadlock-free under test: final stock totals matched expected values exactly across every run at up to 32 concurrent workers.

Measured performance

Processing 1,300 orders across a 999-product, 11-category catalogue scaled from ~20,000 ms on a single thread down to ~650 ms at 32 threads (a ~30× speedup) before plateauing as inventory-mutex contention became the bottleneck.

A full-stack database application modelling the day-to-day operations of a travelling amusement park (customer admissions and loyalty cards, employee rostering, ride/show/stall management, maintenance logging and financial transactions), all served through a role-based Java Swing front end over MySQL.

My contribution

I planned the business scenario that the whole database was modelled from: working out how a travelling carnival's customer admissions, loyalty smart cards, employee roles, attractions and financial transactions actually relate to one another, before any table existed. That scenario became the spec the EERD and schema were built against.

I then built the entire Java Swing front end and its visual design. Login is a custom-painted screen I wrote directly on Graphics2D: a drifting starfield of 180 twinkling stars, 18 looping carnival “sparks”, and a slowly shifting dual-tone gradient behind a rounded glass card, all hand-animated on a Swing Timer, no game engine or extra library involved. On top of that I built the generic EntityConfig-driven CRUD engine that every other screen is built from, the role-based routing between the four account types, the four-step Sales pipeline, and the Reports screen.

System highlights

• 22 tables, 3 views, 2 stored procedures and a full set of triggers, seeded with sample data and four dedicated MySQL accounts (admin, sales, maintenance, guest) that each open a different role-specific screen.
• A generic CRUD engine: every entity is declared once as metadata (table, fields, dropdowns, foreign-key bindings, subtype rules) and a single EntityCrudPanel builds the form, grid and SQL for all 21 entities: adding a new entity is a metadata entry, not a new screen.
• A four-step Sales pipeline (identify customer → log admission → issue an access pass → summary) where the admission and pass insert as one atomic transaction, so a half-completed sale is never left behind.
• Five concurrent SwingWorker-backed reports joining three or more tables each (revenue by location, ride maintenance cost, stall stock, staff distribution and top customer spend), so the UI never blocks while they run.

All queries are parameterised throughout, and MySQL's own per-role privileges provide a second line of defence: even a bug in the Swing client can't issue a statement the account isn't allowed to run.

A head-to-head comparison of three generations of NLP text classifiers (a traditional statistical model, a recurrent deep-learning model, and a pre-trained transformer) on the same binary sentiment task: predicting whether a Steam game review is Recommended or Not Recommended.

My contribution

I led the project and, in addition to training our BERT model, built the entire data pipeline that fed all three models (extraction, cleaning, balancing and splitting) as a standalone notebook the rest of the team's model notebooks all pointed at, so every model trained and tested on identical data.

Extraction: Steam's API caps each request at 100 reviews and paginates with a cursor rather than an offset, so I wrote a loop that walks that cursor per game across 100 selected App IDs, targeting 500 positive and 500 negative reviews each. I collected by class as I went, not after the fact, because some games skew heavily positive and pulling reviews blind would have starved the negative class. Requests are rate-limited with time.sleep() to avoid throttling, and every write checks Steam's own review ID before saving, so re-running the script after a timeout or crash never reintroduces a duplicate.

Cleaning: the raw pull (~94,900 reviews) needed several passes before it was trustworthy training data: stripping reviews mangled by Steam's profanity filter (which replaces swearing with a symbol that corrupts the surrounding text on read), removing links and spam patterns that carry no sentiment signal, running langdetect per review because Steam's own language tag reflects the client's UI language rather than the review text (this alone cut 21,950 reviews), stripping emojis the tokenisers can't meaningfully use, and de-duplicating by exact text (~18,000 reviews) so the same review couldn't land in both the train and test split and inflate accuracy.

Balancing & splitting: the cleaned data was balanced to an even 60,000 reviews (30k positive / 30k negative) and split 70:30 with stratification, so class balance held in both the training and test sets.

For my own model, I fine-tuned BERT (bert-base-uncased) with AdamW, a linear warmup schedule and gradient clipping on a 6GB GTX 1060, and restored the best-validation-loss checkpoint to counter overfitting after epoch 1.

Results

• BERT: 88.73% accuracy, 89.22% F1, the best of the three, at the cost of ~80 minutes' training time versus 35 seconds for the LSTM and 0.03 seconds for Naive Bayes.
• Naive Bayes (84.11% accuracy) and BiLSTM (84.05%) landed almost identically despite very different architectures: Steam reviews are short (median 10 tokens) and lexically driven, which limits how much sequential context modelling actually helps.
• BERT's ~4.6-point F1 lead over both baselines came from its pre-trained contextual representations, which handle negation and phrasing-driven sentiment that a bag-of-words or from-scratch embedding can't.

A local player for FLAC libraries, inspired by the old Samsung TouchWiz Music Square, except instead of relying on genre tags or an online lookup, it plots every track by actually analysing the audio itself. Everything runs locally: no files, tags or audio ever leave the machine.

How the mood coordinates work

For each track, librosa extracts tempo, loudness (RMS), onset rate, spectral centroid, and a tonality “mode score” from a chroma vector compared against major/minor key profiles. These five raw features are then z-scored across the whole library (so “loud” or “bright” is always relative to your own collection) and combined into two weighted axes: arousal (tempo-led) for the x-position and valence (tonality-led) for the y-position, each compressed to -1..+1 with a tanh squash.

Interface

• Click anywhere on the square to drop a probe and build a mix from the nearest-sounding tracks, or drag to sweep a path through a sequence of moods.
• Tracks render as their own album art clipped to a circle; the whole UI takes its colour from whatever's playing, sampling the art down to a tiny canvas and deriving a background wash and accent palette from it, Material-You style.
• A Flask server streams the audio and serves the analysis; the frontend is vanilla JS and Canvas, with art double-cached (server-side and via the browser's Cache Storage API) so reloads are instant.

The analyzer is resumable and parallelised: it samples ~60 seconds per track from ~30% in, skips already-scored files on re-runs, and falls back to a slower crash-isolated mode if a corrupt file would otherwise take down the whole batch.

The site you're looking at right now. A single-page Jekyll portfolio with sliding panels for About Me, Projects and a full Detailed CV, all themed and colour-matched to my actual CV rather than a generic template look.

What it's built on

Rather than starting from a blank page, I built this on top of two open-source Jekyll templates and reworked both substantially:

• The overall one-page shell (the sliding panel system, video background and layout grid) started from jekyll-uno by Josh Gerdes, as extended into jekyll-uno-timeline by Thomas Zühlke, both MIT-licensed. Almost none of the original styling remains; the panel system, project carousel, colour theming and CV integration are my own additions on top of that base.
• The Detailed CV page is built on the Orbit resume/CV template by Xiaoying Riley (themes.3rdwavemedia.com, Creative Commons Attribution 3.0), restructured into the sidebar-plus-main layout you see and recoloured to match my actual paper CV, then embedded into the main site as its own popup panel.
• Icons throughout are Font Awesome Free. The site is built with Jekyll and hosted on GitHub Pages.

What I actually built

• A shared sliding-panel system (About Me, Projects grid, and every individual project) with consistent open/close animation, keyboard (Escape) handling, and swipe support on mobile.
• The CV page: a from-scratch sidebar-plus-main layout matched to my real CV's colours, with per-project accent colours picked directly from each project's artwork rather than a fixed palette.
• The Detailed CV popup embeds the standalone CV page in an iframe so it stays a real, linkable page on its own while still opening in-place like every other panel.
• All the copy, project write-ups and colour decisions on the site are mine, iterated over several rounds to fix layout bugs, improve contrast, and keep the design consistent as content was added.