Youssef Elshafei

TradeWatch watches live market data and tries to notice when something is behaving strangely compared to how it normally does. Prices and trades stream in continuously, so the system has to keep up in real time rather than analyzing things after the fact.

Under the hood, market data flows through Kafka to two separate processes that both read the same stream: one stores every trade exactly as it came in, and the other builds it into one minute, five minute, hourly, and daily candles. Kafka only guarantees a message will arrive at least once, so both processes are written so that receiving the same trade twice never corrupts the data.

Rather than jumping straight into building trading strategies, most of the work so far has gone into making sure the plumbing underneath is actually trustworthy: the pipeline, the database writes, the CI checks. Right now the project is on phase 3 of 12, and there is no strategy engine or machine learning yet, on purpose. A trading strategy built on top of a shaky pipeline is worse than no strategy at all. The anomaly detector, once it's live, will only ever flag activity that looks unusual for that specific stock compared to its own history. It is not trying to catch fraud or market manipulation, and the project is careful not 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.