This page is an overview of the work I’ve posted to GitHub.  The nature of my day-to-day work prevents me from making much of my works public, but I’d like to do so where I can, and can narrate through that work, how it works, what it demonstrates, and what I’ve learned from it here.


Choosing to buy and read Josh Bloch’s Effective Java 3rd Edition was amongst the most enlightening “you may think you know how to write good software, but there is so much more to it” experiences I’ve had.  Part of this is learning how to make more effective use of Java standard libraries which had been grossly underutilized in the legacy code I’d been working on at my day job — most obviously the Collections API — as well as the concept of Immutability and how/when/why it can be a good thing.

This interest in writing better software led to me discovering several of Google’s open-sourced projects, including Guava and AutoValue, and ways they’d be useful in code I wrote myself.  Eventually I found myself looking towards Gson or Jackson as ways to handle parsing of program configuration options, chose Gson based on the project requirements at the time, and discovered a problem: Gson would need a custom deserializer or TypeAdapter to handle some of the immutable collection types I’d grown to like so much from Guava.  And while there were a handful of people who’d already written solutions, none was suitable enough as-is to use on my project, and none was especially well-suited to me contributing to instead of starting my own.

What Gson-utils does:

  • Builds on work started in Google’s Caliper project
  • Fixes the bugs I’ve found so far and adds the features curiously missing
  • Removes a couple dependencies I haven’t seen as especially necessary
  • Provides a simple API for callers to be able to serialize & deserialize more complicated data than they would’ve been able to do without it

In doing so, it includes or demonstrates:

  • Non-chaotic workflow with per-issue branches and merges to a protected Master branch (though this can admittedly look a bit silly/extraneous at times for single-commit branches in single-developer work.)
  • Actually caring about writing method comments and usage info for the benefit of less-familiar users of the API
  • Usage and understanding of generics and type safety
  • A couple of the early cases of me self-teaching and using newer Java language features such as lambda expressions or method references
  • The first project for which I taught myself how to use Maven for builds (I do plan on teaching myself Gradle next)


Georgia Tech’s CS 3630 course (which I now see is taught by a different professor, and may include slightly different content) was one of my more interesting computer science courses; the reasons I remember best for this were its heavy focus on group work on a semester-long project in multiple stages, and for teaching me that how efficient, effective, but still modular & adaptable image processing algorithms can be written by considering the problem’s separate layers:

  1. Optics
  2. Image acquisition
  3. Image enhancement/processing
  4. Image segmentation
  5. Image description (feature extraction)
  6. Recognition/estimation, including uncertainty handling

Of those group assignments, several revolved around writing software in a language of our choice to interface over WiFi with a (now apparently discontinued) webcam-equipped, 3-omniwheel robot called the WoWee Rovio.  I’ve already written about the experience here, in this older post.

What 3630-sp09-rovio does:

  • Interface over WiFi and a proprietary (and at times mis-documented) API
  • Take input from the robot’s sensors (including object recognition via webcam) to estimate current vs. desired position
  • Sends commands back to the robot to have it navigate the space
  • (more detail available at earlier post)

What it demonstrates, including what it does poorly/what can be learned from:

  • Successful group work with immovable deadlines
  • First examples ever of me making use of version tracking (in that case SVN on Google Code, eventually exported to GitHub) for working on a team project
  • Limited understanding at the time of how best to make use of branching & merging (am glad Git Flow and similar workflows are more commonly taught & used now)
  • Arguably too much writing my own solutions rather than successfully finding, integrating, and using already-written 3rd party libraries, which may have been able to achieve certain portions of the work equally well or better