Here are some of the software projects I’ve worked on over the years. Some are open-sourced and some are closed, some I got paid for and some were for giggles, but each has a special place in my heart.
Ada Internship Placer
As the last part of their education, each Ada student completes a 5-month internship with one of our sponsoring companies. In order to determine who should go where, each student interviews with 6 different companies and both students and companies give us feedback. Then we build a placement, taking in mind both the individual student’s strengths and needs and the interview results. In the past building this placement was an arduous task, involving a lot of spreadsheets and copy-pasting.
The Ada Internship Placer aims to solve this problem in two ways. First, it provides an ideal numeric solution based on the interview results and the students’ preferences. Second, it provides a drag-and-drop interface to allow the instructional team to easily fine-tune the results. This application has substantially reduced the time and effort required to build a placement, and allowed us to consider changes in a much more fluid and intuitive way.
The Internship Placer is a Ruby on Rails application with a Backbone user interface, deployed on Heroku. I used the Hungarian Algorithm to compute the placement – the implementation is well commented and qualifies as good reading if you’re into mathy things.
Isilon – Userspace NSM Server
The Network Status Monitor (NSM) protocol is part of the Network File System (NFS) protocol suite, commonly used for file sharing in *nix environments like Linux and OSX. The NFS protocol allows clients to “lock” files, preventing other clients from modifying the file while it’s in use. For performance reasons locks are usually kept in memory by the server, but this means that if the server crashes all the locks will be lost. NSM requires the server to persist information about which clients have locks at any given time, so that after it recovers from a crash it can let clients know so they can reclaim their locks. For a monolithic server this is relatively straightforward – just write a list of clients to disk.
In Isilon’s distributed filesystem, things start to get a little tricky. Knowledge of locks is distributed across the cluster, and a lock-loss event can happen without the node that the client is talking to ever going down. IP addresses are rebalanced regularly, so the node that the client was talking to when it took the lock might not be the one it’s talking to when the lock disappears. And Isilon’s NFS server is written in userspace, which means it doesn’t have easy access to the filesystem data maintained by the kernel.
NSM was a delightfully challenging project that really allowed me to flex my skills as a developer. I built it in C on top of Likewise, a framework that provides (among other things) essential data structure support and a beautiful asynchronous promise library.
Isilon – PAPI Build System Rewrite
At Isilon, the Platform API (PAPI for short) is an HTTP server that handles all configuration management for the cluster. Since almost every engineering project has a PAPI module the system quickly grew enormous, with custom controllers linking against practically every library on the system. At the time I took it on it was a flat directory containing 400+ C++ files that took more than 20 minutes to recompile on a developer workstation. Add in the fact that every team needed to touch PAPI whenever their configuration changed, and that Isilon is a C shop and writing C++ when you don’t know it well involves a lot of trial an error, and Isilon was spending tens to hundreds of developer hours per week just compiling PAPI. It was a clear opportunity to save time and money, reduce bugs through a tight feedback cycle, and to decrease developer frustration.
So one Christmas when I was stuck in the office because I had blown all my PTO hiking over the summer, I decided to take PAPI on. I split the library into 20 or so individual modules, as tightly segmented as I could make them given the dependencies between them. And then I spent an unreasonable amount of time babysitting the build, first getting it to come together on my workstation and then on the build servers. I have delightful memories of sitting in an empty office late at night with my feet on the desk, blasting rock music and surfing the web as I waited for my next build to fail. Once the work was done and merged I an email to eng-all asking them to pull down the change immediately, and then spent the next 3 months fixing merge conflicts for the stragglers who hadn’t kept themselves up to date.
It was one of those weird adventurous projects that’s super satisfying to look back on, but which was thoroughly miserable at the time. It was all worth it though – I dropped the time for a rebuild from more than 20 minutes to less than 1. More importantly, for months afterward engineers I only vaguely knew would stop me in the hall and say things like “You’re Dan Roberts, the guy who fixed the PAPI build? Thank you, thank you, thank you”. It’s really hard to beat feedback like that.
Torchbearer Character Sheet
Torchbearer is a brutally difficult role-playing game developed by Burning Wheel. One of the things that makes it so overwhelming is the complex way your character’s status (angry, exhausted, sick, etc) interacts with dice rolling. This is all just number crunching, which makes it a great candidate for a digital character sheet.
This project is a mobile-oriented website written in React + Redux, with deployment using TravisCI and GitHub Pages. I have grand plans to add in some other technologies as features develop, but that’s all “someday” work.