Youssef Elshafei

TradeWatch watches live market data and notices when a stock starts behaving unusually compared to its own recent history. Around that sits a full paper-trading platform: write a trading strategy, backtest it against stored history, then run it against the live feed with simulated money, all from one React dashboard.

Under the hood, market data flows into Kafka and fans out to independent processes that each read the same stream at their own pace. One stores every trade, one builds one minute candles and rolls them up to five minute, hourly and daily ones, one pushes live prices to the browser, one runs the paper-trading strategies, and one scores every closed candle for unusual activity and hands anything it flags to an alert service. Kafka only promises that a message arrives at least once, so every one of those writes is idempotent: receiving the same trade twice never changes the result.

Most of the effort went into making that plumbing trustworthy before building on top of it, which is why the project was built in phases with the pipeline, storage and CI first and strategies and detection after. Ten of the twelve phases are done; what remains is end-to-end failure-recovery testing and cloud deployment. The anomaly detector only ever flags activity that is unusual for a specific stock compared to its own history. It does not try to catch fraud or market manipulation, and the project is careful never to claim that it does.

Triage Flow is a tool for hospital style intake that tries to get people seen faster without cutting corners on safety. When someone comes in, an AI assistant listens to their description of what's wrong and turns it into a structured summary: symptoms, urgency, and any red flags a nurse should know about right away.

The tricky part is that language models don't always get things right, and a queue deciding who gets seen next is not a place to guess. So the AI's output is never used directly. It gets validated on the server first, and a staff member always reviews and finalizes the actual urgency level before a patient's spot in the queue is set. The AI proposes, a person decides. Patients can watch their position and estimated wait update live as the queue moves, which was the part everyone actually wanted in the first place: less mystery about how long the wait really is.

BridgeAid started from a simple frustration: during a wildfire, flood, or storm, the hardest part often isn't the disaster itself, it's not knowing what's actually happening nearby versus what's just a rumor. The platform lets people report incidents, request help, and see a live map of what's been verified in their area.

Because anyone can submit a report, the reports themselves get cross checked against other nearby reports and public datasets before they're allowed onto the map, so a single bad or panicked report can't spread. Volunteers can sign up by category (food, shelter, general disaster relief) and mark themselves active or on standby. There's also a recovery dashboard that shows incident counts locally and globally, though it's worth being upfront that the recovery numbers there are a simulated visualization, not a live feed of real recovery data.

The scope stays to things that could realistically be built and verified: reporting, requests, and volunteer coordination. It stops short of handling actual aid transactions or payments, since that's a different, much higher stakes problem than the one this project set out to solve.

Most of the time, figuring out what's wrong with a network means switching between three or four different tools, each with its own output format and no shared context between them. WireFish puts the basics (host scanning, traceroute, and bandwidth monitoring) into one command line tool that speaks a consistent language.

Getting traceroute and host scanning to work properly meant building raw ICMP packets by hand, including the checksum, and reading responses straight off a raw socket, since there's no friendly library standing in between to hide that complexity. It was built that way on purpose, in C, alongside three teammates, because the point of the project was actually understanding what happens at the network layer, not just calling a function that already does it.

This one was a McMaster course assignment worked on with three teammates: take an existing Java based Catan simulator and add undo and redo, plus a simple AI opponent that could actually make reasonable decisions on its own.

The catch was that the assignment wasn't really graded on whether the AI won games, it was graded on whether these features could be added cleanly, using proper design patterns, without tearing apart code that already worked. So undo and redo went in through the Command pattern, and the AI's decision making replaced a single messy function with a clear structure: a Template Method for the turn sequence and a Visitor for scoring possible moves. None of the original game logic classes had to be touched.