Involves: Python, Node.JS, Blockly
NyokaTofali is my fork of the EduBlocks project, which seeks to ease the transition from using MIT Scratch's block interface to writing Python code. EduBlocks was published online at exactly the same time that I was searching for a way to accomplish this myself, so thankfully I was spared the time and effort needed to integrate Google's Blockly with a web-based editor. Building off EduBlocks as a foundation, I fixed some problems with the codebase, cleaned up some code, added some new blocks, and changed the name to NyokaTofali ("snake block" in Swahili). The source code is publicly available here.
In addition, I split the front and back ends of the system apart. This allows the front-end, which is occasionally updated with new blocks, to be hosted on a central network location so that updates don't need to be performed on every client. The back-end, which rarely if ever changes, runs separately on each client, and thus can be used to interact with local client applications such as Minecraft.
I have designed and developed a decentralized network consensus protocol for use in cryptographic certification and revocation of documents by higher-education institutions. Each institution maintains its own hashchain and its own peer relationships with other institutions. As each institution certifies and revokes documents, such as diplomas and transcripts, its peers double-check the institution's actions before giving their sign-offs. Institutions maintain replicas of their peers' hashchains as well.
CertChain demonstrates that expensive, centralized signature services such as Adobe's AATL aren't needed in a network of institutions with preexisting peer relationships. I have written a proof-of-concept implementation of CertChain, consisting of a Django web application and a Rust network daemon, the source code for which is located here. One cool part about the implementation is that, thanks to emscripten's ability to compile C++ to JS, cryptographic signatures can be verified directly in the user's browser rather than on the server. I have also formalized the protocol in a TLA+ specification located here. Professor Dan Boneh provided insightful advice and feedback on the development of this system. I have written an (unpublished) paper about CertChain, which you can read here. The following screenshots were taken with a running local network of four institutions:
From November 2014 to February 2015, I developed the initial version of MyLocker, a new service offered by Stanford University to students and alumni, allowing them to retrieve and send their electronically signed diplomas and certificates from a central location. When the Registrar's Office expressed a need for such a service, Senior Director of Student, HR, and Middleware Systems Sameer Marella produced the design and vision behind MyLocker, which I implemented in collaboration with all aforementioned and related parties. MyLocker is a Django application that uses Box as a file storage layer; this design effectively decouples the management of documents from the application itself, and obviates the need to store sensitive files on the MyLocker application servers.
In less than 90 days, Administrative Systems and the Registrar's Office conceived, implemented, and released the first version of MyLocker to the university community, an uncommon project lifecycle in a world where software is more often promised than it is delivered.
From February 2015 to February 2016, I managed a team of off-site developers for continued updates and enhancements to MyLocker. I reviewed all code and was responsible for deploying the developers' changes to production.
Involves: Java, ANTLR, PeopleSoft, SQL, Oracle, AWS
From July 2013 to April 2015, I worked to create an open source runtime for PeopleSoft called OpenPeopleSoft. A typical PeopleSoft application is usually composed of several different types of assets, but the most common and traditional of these are PeopleSoft components. Components are run by the Component Processor, a proprietary runtime embedded within PeopleTools. OpenPplSoft aims to be a faster, more flexible, clean room implementation of the Component Processor.
My primary goal with OpenPplSoft was to have fun, learn, and challenge myself to see how much of the Component Processor I could reverse engineer. Other projects and goals took me away from OpenPeopleSoft in mid-2015, and more work is needed for it to run entire components. This ended up becoming a huge, ~15,000 LOC project written mainly in Java. I've had the most fun writing the PeopleCode interpreter; the main interpreter file is located here and the underlying ANTLR grammar is located here. The entire source code repository is located here.
From October 2011 to July 2013, I designed, developed, and licensed the front and back ends of the first version of the Enterrupt enrollment system. Enterrupt 1.0 was designed to operate with one foot in the proverbial cloud and the other embedded in a licensing institution's PeopleSoft database. The front-end lived on a cluster of AWS and Linode servers, while the back-end consisted of a group of PeopleCode programs and a Java serialization library that resided on PeopleTools app servers.
This project led me to most every corner of PeopleSoft: the web server, the app server, PeopleCode, and even COBOL. I also gained some business experience during the negotation of a license agreement with the University of Virginia. Unfortunately, we were unable to scale the PeopleSoft application server to handle the traffic required for migration to production, so Enterrupt 1.0 did not get to see the light of day.
From September 2011 to April 2012, I worked in a consulting capacity with developers and administrators at Stanford University, specifically Administrative Systems and the Registrar's Office, to develop a web-based performance review application called SimpleEval. SimpleEval provides a cleaner, more efficient way to create and manage performance reviews than the delivered ePerformance UX in PeopleSoft.
I was responsible for all front-end development. Stanford employees implemented back-end functions in PeopleTools, which are exposed as web services to SimpleEval. SimpleEval was a challenge in that it required a comprehensive understanding of who can see what data at which points of the performance review lifecycle. The application is used by about 1,000 Stanford employees during each performance evaluation season.
From April 2011 to August 2011, I worked in a consulting capacity with developers and administrators at Stanford University, specifically Administrative Systems and the Registrar's Office, to develop a web-based enrollment application called SimpleEnroll. SimpleEnroll provides a cleaner, more efficient way to find and enroll in classes than the delivered PeopleSoft UX.
I was responsible for all front-end development. Stanford employees implemented back-end functions in PeopleTools, which are exposed as web services to SimpleEnroll. SimpleEnroll has been used widely by Stanford students since its August 1st, 2011 go-live date.
From May 2010 to November 2010, I worked with a graduate research team at UVA that was investigating concentration levels of various pharmaceuticals in wastewater treatment plants around Virginia. Their efforts had spanned several years; I joined them as they were wrapping up and looking for someone to make their findings publicly accessible in the form of a website, located at http://faculty.virginia.edu/vpharmacalc.
I was tasked with designing and developing the website, in addition to implementing the predictive algorithms that were devised by the team. With provided datasets, I developed the geospatial queries required to resolve a user's zip code to the wastewater treatment plant serving their home. Here are a few screenshots of VPharma-Calc:
Involves: .NET, VBA, ArcGIS
From June 2009 to March 2010, I worked on a team comprised of several Avineon developers to create a more efficient way for NAVFIG personnel to manipulate geospatial data in a legacy Access database (NAVTERPS) using their existing ArcGIS front-end (AVNAVTERPS). The effort required us to develop VBA functions within ArcGIS that could call out to a shared library capable of running existing VBA functions embedded in the database.
I was tasked with developing the shared library (named TERPSLinker). I worked closely with Joe Veneziano, who wrote the code within ArcGIS that called out to TERPSLinker. This project was one of my favorites because I got to work within a complex domain and create a working Windows installer for TERPSLinker. The first screenshot below shows NAVTERPS in its 1GB, legendary glory; the others show Joe's code running in ArcGIS using data retrieved via TERPSLinker:
Involves: Java, JSP, GeoServer, OpenLayers, PostgreSQL
From June 2008 to May 2009, I worked on a team comprised of several Avineon developers to create a JSP console and a set of geospatial data parsers for FNMOC. The console allows users to view and manipulate geospatial data involving weather observations and alerts; data is pulled from a GeoServer instance and manipulated in the console using OpenLayers. A collection of parsers written in Java and supervised by a scheduler are responsible for keeping the geospatial data up-to-date by querying the appropriate NWS and US Navy Metcast servers.
My contributions focused on developing a few of the parsers and integrating various OpenLayers capabilities into the JSP console; here are a few screenshots of the latter: