This in-progress Android project started out as an idea put forth by a friend, who wanted an easy-to-use way to look up where the food he eats comes from while shopping at the grocery store. The core application incorporates a barcode scanner and interfaces with a MongoDB database via an API written with restify in node.js.

Though still in the early stages of development, the hope for this project is to expand its database of food products enough so that the app is useful when out shopping in the downtown Toronto area.

This project started out as an updated version of pingtoft's Company of Heroes replay parser that I wrote in PHP for use on COH2.ORG. I recently rewrote it in Rust, an emerging systems programming language with compile-time memory safety guarantees, and released it as an open source library on crates.io. The rewrite leverages Rust's powerful concurrency capabilities and exposes a C-like interface to external callers, making it usable in higher-level languages like Python and Javascript. It parses CoH2 replay files byte-by-byte and pulls as much information as possible. Because the CoH replay format is not open source, I was forced to reverse-engineer much of the replay structure used in this parser by analyzing hex data in multiple replay files by hand.

This code is currently being used in the wild by COH2.ORG to power their replays section. I also have plans to incorporate the library into a node.js-driven web application as a custom module.

Originally written as a proof-of-concept and test application for my vault parser, flank has been extended to provide developer-specific testing information and JSON-formatted output of Company of Heroes 2 replay files. Though mainly used to test and verify the functionality of the vault library, flank can also be used in real-world applications by consuming the JSON it generates. This is the method by which COH2.ORG incorporates vault into their replay parsing workflow.

Written in Rust, flank is a relatively simple command line application that wraps the vault library to provide replay parsing, and formats the output based on flags passed to it when invoked.

A Windows application written in C# and using a C# version of my CoH2 replay parser, this project was envisioned as a rich GUI frontend for my parser code. I started working at IBI a few months after I began coding this, however, and it was never completed.

In the future, I plan on taking the code from this and my other CoH-based projects and combining it all into a multi-purpose web application for gathering, organizing, and displaying Company of Heroes replay data.

This is a simple C# application I wrote to work around a flaw in the Company of Heroes replay versioning system, where replays were only listed in-game if the encoded version matched the game version installed. This was a problem during periods of frequent hotfixing, because some patches would hide replay files that worked perfectly fine.

This application works by modifying the first two bytes of the replay file to encode the game version required to make the replay files show up in the in-game file browser. Since patch frequency in CoH2 has decreased considerably, this functionality is not really needed anymore, and this project is no longer actively maintained.

As the largest unofficial Company of Heroes fansite, COH2.ORG is maintained by a small team of volunteer coders. It is written in PHP using the Yii framework with MySQL, and a frontend powered by jQuery and custom CSS.

As a member of the coding team, I was responsible for the development of a number of backend features. The site's replay section is powered by my replay parser, while the ladder section runs code I wrote to consume a third-party JSON API and display aggregated as well as individualized results. I also assisted with layout and wrote Javascript for a number of widgets, such as the sidebar ladder widget and the event countdown timer. Coordination with team members across timezones and continents was made possible with a combination of subversion, git, and GitLab.

I still contribute to the project occasionally, but other personal and professional projects leave little time for meaningful additions.

In 2013, as a senior at UBC (go Thunderbirds!), I worked together with a small team of students on the design and development of a web application to be used by the BC Cancer Agency for tracking patient inquiries regarding cancer medication and treatment. My responsibilities within the team included requirements illicitation and organization as well as backend development work in C# within an ASP.NET MVC framework, and some frontend layout work with Bootstrap.

This project was my first taste of real software development, and gave me an invaluable look at taking a software project from the requirements phase straight through to delivery. Being responsible for the requirements of the entire project made me acutely aware of the importance of clear, concise communication with clients, and gave me experience that would prove extremely valuable as I went on to start my professional career.

Unfortunately, I no longer have access to the source code for this project, and while parts of it are currently being used by the BC Cancer Agency, none of it is publically accessible. I do, however, have a copy of the Software Requirements Specification document that I was responsible for producing with the assistance of my teammates; it can be viewed at the link to the right.

CRESCENT has been the State of Connecticut's traffic management system of choice for over 10 years, and I began maintaining the code base in September 2013. Since then, I have been responsible for a number of interface and backend changes written in C++ using Microsoft Foundation Classes (MFC). I am also the primary support contact for the project, and regularly interact with the client regarding maintenance and crisis management.

More recently, I have worked on a proof of concept interface redesign, completely rewriting the frontend code using HTML5, CSS3, jQuery, and knockout.js while adapting our server backend to interface with a C# .NET service running Microsoft's SignalR websocket implementation. The goal of this overhaul is to leverage modern web technologies in order to bring the aging CRESCENT user interface into the browser-based world via a quick, responsive single-page web application that works seamlessly with existing legacy C++ interfaces and server infrastructure.

The Dublin Traffic Management System is one of IBI Group's oldest and longest-used systems. As the primary maintainer since 2013, I have been responsible for both the design and development of key new features and functions based on client requirements. I have also resolved a number of longstanding bugs in the system code, using memory management software to identify memory leaks and simplifying application code to make debugging easier.

In my work on this system, I have integrated a number of new external devices and extended the functionality of existing ones. Most recently, I took an existing message sign functionality and repurposed it for use on a similar but largely unrelated subset of display devices used for lane control on bridges and in tunnels. This reuse of existing assets is something I aim to do whenever it is practical and makes sense, since it drastically improves my productivity and leads to greater consistency between code modules and easier maintenance in the future.

Shortly after I started at IBI Group, we were awarded a contract for a traffic management system to be used by Yosemite National Park in California. As the development lead on the project, I was responsible for taking an existing application in use at Glacier National Park in Montana and overhauling it based on Yosemite's unique requirements.

Working with two other developers, I integrated a number of physical devices into the system, including a variety of different vehicle detectors and multiple variable message signs. I also developed a simple campground management web application using ASP.NET and SignalR and oversaw work on other client-requested features that I was not directly responsible for implementing. When core development was completed, I took multiple trips to assist the client with on-site integration and installation, and handled post-launch maintenance both on-site and remotely via GoToMeeting.