1285 lines
47 KiB
YAML
1285 lines
47 KiB
YAML
Skills:
|
|
Languages:
|
|
- Java
|
|
- C# (Boo, VB6, VB.NET)
|
|
- C
|
|
- JavaScript
|
|
- TypeScript
|
|
- Nim
|
|
- HTML5
|
|
- CSS3
|
|
- Erlang
|
|
- PHP
|
|
- XML (XSD, XPath)
|
|
- SOAP
|
|
- LaTeX
|
|
- Perl
|
|
- Ruby
|
|
- Bash Script
|
|
- Lisp
|
|
|
|
|
|
Jobs:
|
|
|
|
Freescale Semiconductor:
|
|
|
|
Positions:
|
|
June 2004 \- Oct 2004: Summer Intern / Contractor
|
|
|
|
Description: >
|
|
Notable accomplishments included:
|
|
- developing hardware diagnostics scripts
|
|
- schematic capture using Mentor Design Architect
|
|
- assisting lab technicians in circuit assembly
|
|
|
|
Tools \& Technologies:
|
|
- Perl
|
|
- Mentor Design Architect
|
|
|
|
Colleagues \& References:
|
|
- Michael Geroge
|
|
|
|
Gemalto:
|
|
|
|
Positions:
|
|
June 2005 \- August 2005: Summer Intern
|
|
September 2005 \- August 2010: Developer (Solutions and Special Projects)'
|
|
|
|
Description:
|
|
Responsible for finding solutions to new problems, developing custom
|
|
solutions for customer problems, and providing tools and support to other
|
|
development teams.
|
|
|
|
Projects:
|
|
|
|
Custom Card Procurement Service:
|
|
|
|
Short Description:
|
|
Designed a generic SOAP-based web service framework for secure
|
|
machine-to-machine procurement of smartcard-based credit cards.
|
|
Created custom services using this framework for multiple customers.
|
|
|
|
Description:
|
|
We desired to offer a machine-to-machine service that our customers
|
|
could integrate into their customer-service terminals. In their
|
|
applications the customer service agents could capture cardholder
|
|
details and submit an order for replacement cards. Using the web
|
|
services I created these orders would be directly routed to one of
|
|
our many manufacturing centers around the globe and a new card
|
|
created and shipped directly from the manufacturing center to the
|
|
cardholder. This allowed our customers to provide 24-hour turn-around
|
|
to their card holders with shipping anywhere in the world.
|
|
|
|
Using this service, a cardholder traveling for business who left or
|
|
lost their card on one leg of their trip could have a new card
|
|
printed and waiting for them at their destination.
|
|
|
|
Among the requirements was compliance with the WS-Interoperability
|
|
and WS-Security extensions to the SOAP standard. I worked alongside
|
|
customer engineers to document and define the service API, as well as
|
|
help them integrate our service into their applications.
|
|
|
|
During development of this framework and the related services I had
|
|
the opportunity to contribute a small amount of code to the Apache
|
|
Axis2 project addressing defects I encountered.
|
|
|
|
Tools \& Technologies:
|
|
- Java
|
|
- JCA
|
|
- SQL
|
|
- Apache Ant
|
|
- Apache Axis2
|
|
- Glassfish
|
|
- HSQLDB
|
|
- PKI
|
|
- SOAP
|
|
- WS-Security
|
|
- WS-Interoperability
|
|
- Mercurial
|
|
|
|
Responsibilities:
|
|
- Architecture
|
|
- Database Administration
|
|
- Backend Implementation
|
|
- Documentation
|
|
- Customer Engineering Support
|
|
|
|
Tags:
|
|
- Open-source contribution
|
|
|
|
Generic Report Generation Tool:
|
|
|
|
Short Description: Custom, in-house application used to define and
|
|
generate a wide range of reports required during the manufacturing
|
|
process, built around the JasperReports reporting engine (then only a
|
|
few years old).
|
|
|
|
Description:
|
|
In the process of supporting existing manufacturing centers, and
|
|
standing-up a new service bureau we found the need to have a single
|
|
solution for defining and generating reports. Ideally this solution
|
|
would be simple for our manufacturing centers to use, easy to
|
|
automate and embed into production processes, support reports in
|
|
multiple formats (PDF, XML, XLSX, etc.), and provide a relatively
|
|
simple interface for defining new reports. After researching
|
|
available options, we decided to build our own application around the
|
|
(then-young) JasperReports reporting engine.
|
|
|
|
I worked with my direct manager to architect the application, and was
|
|
the sole contributor to it's implementation. In addition to the
|
|
implementation of the GRGT application, I was responsible for
|
|
creating or converting the reports required to support existing
|
|
manufacturing processes. Finally I was responsible for internal
|
|
evangelism for the tool, training on-site personell in the daily use
|
|
of the tool and in the creation of reports, and production support.
|
|
|
|
Tools \& Technologies:
|
|
- Java
|
|
- Java Swing
|
|
- JDBC
|
|
- JasperReports
|
|
- Apache Ant
|
|
- SQL
|
|
- Database Administration
|
|
- Mercurial
|
|
|
|
U.S. E-Passport solution for the Government Printing Office (GPO):
|
|
|
|
Short Description:
|
|
Gemalto has been a primary supplier to the GPO since the inception of
|
|
the U.S. E-Passport. I was part of the initial team creating the
|
|
E-Passport technology as well as extending and customizing our usual
|
|
manufacturing process for the GPO's unique needs.
|
|
|
|
Description:
|
|
The manufacture of the E-Passport was a multi-stage process. Initial
|
|
manufacture and application programming was performed at Gemalto's
|
|
manufacturing facilities but final programming, personalization, and
|
|
manufacture were performed on-site at GPO facilities. To facilitate
|
|
this, Gemalto provided software and support for the GPO to complete
|
|
the final steps of manufacture and personalization.
|
|
|
|
I was responsible for designing the database schema required to store
|
|
the intermediate data about the manufacture process for each card,
|
|
providing production support for the database in manufacturing, and
|
|
creating high-performance tools and processes for extracting the data
|
|
from the manufacturing database into secured data files in the format
|
|
specified by the GPO for the purposes of auditing and import into
|
|
their manufacturing databases.
|
|
|
|
Tools \& Technologies:
|
|
- Java
|
|
- Java Swing
|
|
- JCA
|
|
- JDBC
|
|
- Oracle Database
|
|
- SQL
|
|
- Apache Ant
|
|
- Mercurial
|
|
|
|
Responsiblities:
|
|
- Database Administration
|
|
- Backend Implementation
|
|
- Performance Optimization
|
|
|
|
Cryptographic Service Implementation:
|
|
|
|
Short Description:
|
|
Built a service exposing cryptographic operations of a new hardware
|
|
security module securely via our proprietary protocol for
|
|
interoperation with our existing manufacturing engine.
|
|
|
|
Description:
|
|
We were exploring the use of the Luna PCM 2.2 hardware security
|
|
module by SafeNet for use in our development environments and
|
|
potential use in our manufacturing environments. In order to expose
|
|
the HSM's cryptographic services to our personalization engine
|
|
(Samarcande), we needed to create an interface to the HSM.
|
|
|
|
Tools \& Technologies:
|
|
- Java
|
|
- JCA
|
|
- JNDI
|
|
- BouncyCastle
|
|
- HSM SDK
|
|
- PKCS#11
|
|
- Mercurial
|
|
|
|
In-house Operations \& Tool Development:
|
|
Short Description:
|
|
As a member of the Solutions & Special Projects team I was personally
|
|
responsible for the operational infrastructure used in development by
|
|
our Banking and Telecommunications Personalization teams for North
|
|
America, and created several in-house development tools used by the
|
|
same.
|
|
|
|
Description:
|
|
In addition to the individual, special projects listed, the Solutions
|
|
and Special Projects team focused on supporting the Banking and
|
|
Telecommmunications Personalization teams for North America. In this
|
|
capacity, we created and maintained the in-house development
|
|
environments used by these teams. This included servers dedicated to
|
|
running Oracle databases, cryptographic servers containing hardware
|
|
security modules, and other more general-purpose servers required to
|
|
support the local development efforts and coordinate delivery of
|
|
software to manufacturing centers.
|
|
|
|
In addition to the operational responsibilities, I created a number
|
|
of custom, in-house tools for use by the developers in our
|
|
Personalization teams, including utilities for managing plugins to
|
|
our proprietary manufacturing engine, utilities for manipulating test
|
|
data with cryptographic primatives, debug tools exposing standard
|
|
cryptographic primatives used in our in-house standard library, and
|
|
other general utilities specific to the handling the common data
|
|
formats and workflows of our developers.
|
|
|
|
Tools \& Technologies:
|
|
- Visual Basic 6
|
|
- C/C++
|
|
- Java
|
|
- Java Swing
|
|
- JCA
|
|
- JDBC
|
|
- Oracle Database
|
|
- Apache Tomcat
|
|
- Apache httpd
|
|
- Red Hat Enterprise Linux
|
|
- Windows Server 2003
|
|
- Windows Servier 2008
|
|
- ISO 7816 (Smart Cards)
|
|
- ISO 14443 (Contactless IC Cards)
|
|
- EMV payment standard
|
|
- Mercurial
|
|
- Subversion
|
|
|
|
Responsibilities:
|
|
- Native Application Development
|
|
- Operations
|
|
|
|
Colleagues \& References:
|
|
- Mridul Sharma
|
|
- Shirley (Kusumawati) Lay
|
|
- Tze Yang Ng
|
|
- Richard Dollet
|
|
- William Tran
|
|
- Francois Radet
|
|
- Raghav Sundaravaradan
|
|
|
|
Tools \& Technologies:
|
|
- Windows
|
|
- Ubuntu Linux
|
|
|
|
QuantumDigital Inc.:
|
|
|
|
Positions:
|
|
August 2010 \- February 2012: Systems Developer
|
|
|
|
Description:
|
|
Responsible for supporting the legacy order and fullfilment systems and
|
|
migrating these systems to modern technology. Launched the company's
|
|
first mobile app.
|
|
|
|
Projects:
|
|
|
|
FoxPro to Java Bridge:
|
|
|
|
Short Description: Dynamic, runtime interface layer to expose FoxPro
|
|
tables to Java programs via JNI.
|
|
|
|
Tools \& Technologies:
|
|
- FoxPro
|
|
- Java
|
|
- JNI
|
|
|
|
Quantum Post Cards:
|
|
|
|
Short Description:
|
|
The starting point for QuantumDigital's migration from their legacy
|
|
FoxPro-based web application to a new web application written in PHP,
|
|
based on Magento.
|
|
|
|
Description:
|
|
QuantumDigital's primary backend was a monolithic FoxPro application
|
|
written almost two decades prior, leveraging a framework called West
|
|
Wind Web Connection. Over time the company had worked toward
|
|
modernizing some of the periphery business logic as well as setting
|
|
up database replication from their primary FoxPro tables into a MS
|
|
SQL instance.
|
|
|
|
Quantum Post Cards was the first large-scale migration of core
|
|
functionality away from Visual FoxPro towards PHP. As a systems
|
|
developer I participated in the architectural and design decisions
|
|
leading up to the new effort as well as the core implementation of
|
|
the new system.
|
|
|
|
Tools \& Technologies:
|
|
- PHP
|
|
- Magento
|
|
- MS SQL Server
|
|
- XHTML
|
|
- CSS2
|
|
- JavaScript
|
|
- JQuery
|
|
|
|
QCards Mobile App:
|
|
|
|
Short Description:
|
|
Developed the company's first mobile application enabling realtors to
|
|
create custom ad campaigns and postcards in the field using their
|
|
smartphones.
|
|
|
|
Description:
|
|
QCards was an effort to build a mobile app that would enable realtors
|
|
to create direct mail marketing campaigns from their phones while on
|
|
location at homes they represented. QCards allowed the realtor to
|
|
capture images of properties, set those images within a standardized
|
|
postcard template, define marketing campaign parameters using
|
|
existing business logic within Quantum's larger product offerings,
|
|
and submit an order.
|
|
|
|
In this role I was resonsible, with one coworker, for the
|
|
implmentation and testing of the mobile application. We initially
|
|
targeted iOS, then Android. In addition to the mobile development,
|
|
this required building out APIs in FoxPro to expose core business
|
|
functionality from the legacy codebase to the mobile application, as
|
|
well as implementing all of the associated logic for user
|
|
authentication, session management, etc.
|
|
|
|
Tools \& Technologies:
|
|
- Appcelerator Titanium SDK
|
|
- JavaScript
|
|
- jQuery
|
|
- iOS SDK
|
|
- Objective-C
|
|
- Android SDK
|
|
- Java
|
|
- Visual FoxPro
|
|
|
|
Colleagues \& References:
|
|
- Rory Derrick
|
|
- Dude Spellings
|
|
- Chris Anderson
|
|
|
|
HID Global:
|
|
|
|
Positions:
|
|
February 2012 \- September 2013: Staff Engineer
|
|
|
|
Description:
|
|
I was part of the team responsible for all software controlling and
|
|
supporting the production process, ranging from low-level machine control
|
|
and automation to server-oriented architecture that supplied production
|
|
software services such as key management, cryptographic services, and
|
|
configuration management.
|
|
|
|
I was brought onto this team at it's inception to help build out the
|
|
foundational infrastructure and software that would become the base of
|
|
HID's new approach to manufacturing control.
|
|
|
|
Projects:
|
|
|
|
Common Machine Control Framework:
|
|
|
|
Short Description:
|
|
Responsible for architecting and implemting a common framework for
|
|
production control. The goal was to create a modular platform that
|
|
could be used to marry common business and production logic with
|
|
machine-specific control and automation.
|
|
|
|
Description: >
|
|
HID had a wide range of different machines used in their production
|
|
processes and control software varied from machine to machine without
|
|
a unified approach. Control software being written in a variety of
|
|
languages (including C/C++, VisualBasic 6, and LabVIEW, among
|
|
others) made centralized support challenging and hampered efforts to
|
|
create a standardized process.
|
|
|
|
Our goal was to unify all of the machine control, creating a platform
|
|
that would allow us to create and leverage standardized modules for
|
|
common functionality such as:
|
|
- card programming
|
|
- access to standard services like cryptographic processing, key
|
|
management, order configuration, etc.
|
|
- physical personalization (printed graphics, etching, coating,
|
|
etc.)
|
|
|
|
To this end I designed and architected the common machine control
|
|
framework that provided a common base bridging machine-specific
|
|
control logic with the common modular library being written to
|
|
provide the standardized functionality of our platform.
|
|
|
|
As part of this architecture, the common framework provided a bridge
|
|
layer via C/C++ to allow communcation with machine control modules,
|
|
an embedded rich user interface layer built on HTML, CSS, and
|
|
JavaScript, and a plug-in architecture to simplify the inclusion of
|
|
standardized modules and services provided by the broader production
|
|
environment. The primary language of the framework itself was C#.
|
|
|
|
Tools \& Technologies:
|
|
- C#
|
|
- C/C++
|
|
- .NET
|
|
- HTML
|
|
- CSS
|
|
- JavaScript
|
|
- Backbone.js
|
|
|
|
Emperor Card Personalization Control:
|
|
|
|
Short Description:
|
|
Responsible for the initial implementation of the machine control
|
|
software for HID's new, custom-developed card personalization
|
|
machines from Emperor Tech. This was the first green-field
|
|
implementation using our new common machine control framework. This
|
|
required working with the Chinese vendor's technical staff to
|
|
properly implement the driver allowing HID's control software to
|
|
control the individual component elements of the hardware (motors,
|
|
vacuum grippers, etc.).
|
|
|
|
Description: >
|
|
HID partnered with Emperor Technologies in Chine to create a
|
|
purpose-built card personalization machine aimed at small-to-medium
|
|
production runs. The machine ran cards in batches of 50-100 (don't
|
|
remember exactly how many) and was intended to support rapid
|
|
transitioning from one order to the next, allowing manufacturing
|
|
personell to quickly run through a series of orders with minimal
|
|
re-configuration of the machine required.
|
|
|
|
Being a new machine, new control software was required. Emperor
|
|
Technologies supplied a low-level drive package that provided direct
|
|
access to the machine hardware. HID needed to create the software
|
|
that actually exercised the machine, coordinating all of the
|
|
individual hardware mechanisms (actuating motors, card grippers,
|
|
etc.) and providing the platform for the appropriate card programming
|
|
for each order.
|
|
|
|
I was the sole developer responsible for the end-to-end
|
|
implementation of the machine control software for the Emperor line
|
|
of production machines, leveraging the common machine control
|
|
framework. This was a particularly fun project as it required a truly
|
|
multi-threaded approach with soft real-time requirements. The Emperor
|
|
production machine has seven stations which operate and are
|
|
controlled in parallel, performing simultaneous actions:
|
|
- feed card in
|
|
- generic programming (application/batch-specific)
|
|
- card printing
|
|
- UV coating
|
|
- flip
|
|
- personalization programming (card-holder-specific)
|
|
- feed card to output
|
|
|
|
Our target goal was to produce one card per second, meaning each
|
|
station had to perform its function in less than a second. The
|
|
machine control software has to coordinate the actions (physical and
|
|
logical) of all stations, as well as track the progress and results
|
|
for each card throughout the process. In some cases we supported
|
|
double-sided printing and UV coating, meaning we had to coordinate
|
|
cards travelling in reverse direction as well as forward, to
|
|
accomodate moving back through the printing and coating stages after
|
|
being flipped.
|
|
|
|
Tools \& Technologies:
|
|
- C#
|
|
- .NET
|
|
- C/C++
|
|
- HTML
|
|
- JavaScript
|
|
- Backbone.js
|
|
- CSS
|
|
- Git
|
|
|
|
Common Card Programming Library:
|
|
|
|
Short Description:
|
|
In line with our goal of standardizing the manufacturing process, our
|
|
team was creating a standard library of functionality specific to
|
|
programming ISO 7816 and ISO 14443 cards, built around the .NET
|
|
platform, and targeting specifically the Boo language as a DSL for
|
|
smart card programming. As part of this effort I was responsible for
|
|
the implementation of standard operations involving card
|
|
communication and cryptographic operations.
|
|
|
|
Description:
|
|
ISO 7816 and ISO 14443 define the communication protocols used by
|
|
smart cards and readers. We built a standard library of functionality
|
|
to provided higher-level abstractions on top of the low-level
|
|
communication primitives defined in the ISO specs. In addition to
|
|
low-level bit manipulation-style logic used to create the protocol
|
|
data units (PDUs), we provided implementations of the common
|
|
cryptogrphic operations used in the communication protocol to
|
|
simplify the creation of card programming logic. We also included
|
|
bindings to our common environment configuration to expose, for
|
|
example, centralized HSM services, configuration management, and
|
|
end-to-end reporting to the runtime environment of our manufacturing
|
|
operations.
|
|
|
|
We exposed this standard library via a domain-specific language built
|
|
on top of the Boo language in the .NET ecosystem. This allowed us to
|
|
write code that adhered closely to the structure of the psuedo-code
|
|
one would write to perform the required operations when programming
|
|
or interacting with a smart card.
|
|
|
|
As part of the team which owned this standard library I was
|
|
personally responsible for implementing portions of the functionality
|
|
described above, particularly the authentication and handshake
|
|
mechanisms which allowed the reader and card to establish a secure
|
|
session, as defined in the ISO 7816 and ISO 14443 specifications.
|
|
|
|
Tools \& Technologies:
|
|
- Assymetric Cryptography
|
|
- Symmetric Cryptography
|
|
- C#
|
|
- Boo
|
|
- .NET
|
|
- ISO 7816
|
|
- ISO 14443
|
|
- Git
|
|
|
|
Card Programming \- Application and Personalization:
|
|
|
|
Short Description:
|
|
In addition to being responsible for the machine control software,
|
|
our team was responsible for the programming of the cards themselves,
|
|
both the code loaded as applications onto the cards themselves as
|
|
well as the code responsible for programming the cards with that
|
|
application code and configuring the card data for it's individual
|
|
owner.
|
|
|
|
Description: >
|
|
Personalization of smart cards typically involves two steps: the more
|
|
general application programming, and the card-holder specific
|
|
personalization. The application programming involves writing the
|
|
logic that will live in the card and perform the core card functions.
|
|
Card-holder specific personalization is the process of loading
|
|
personal identifying information into the application memory and
|
|
card-specific cryptographic key material, as well as potentiall
|
|
printing customer data onto the face or back of the card.
|
|
|
|
ISO 7816 and ISO 14443 define the communication protocols spoken by
|
|
the cards which must be used when programming in both steps.
|
|
|
|
Tools \& Technologies:
|
|
- ISO 7816
|
|
- ISO 14443
|
|
- Boo Language
|
|
- .NET
|
|
- C#
|
|
- Git
|
|
|
|
Colleagues \& References:
|
|
- Richard Dollet
|
|
|
|
3M (contracted with Maxis Group):
|
|
Positions:
|
|
October 2013 \- October 2015: Software Engineer VI
|
|
|
|
Projects:
|
|
|
|
Next-generation Tolling Platform:
|
|
|
|
Short Description:
|
|
The next-generation tolling platform was a paradigm shift for 3M's
|
|
tolling business, moving away from devloping single-purpose solutions
|
|
towards a cloud-based, tolling-as-a-service model. I had a wide range
|
|
of responsibilities on this project, owning the architecture and
|
|
implementation of functionality across the entire stack from database
|
|
to front-end, serving as the team lead for the front-end developers,
|
|
and providing internal operational support for our development tools
|
|
and environment.
|
|
|
|
Description: >
|
|
The next-generation tolling platform was an initiative at 3M to
|
|
develop a cloud-native, multi-tenant, extensible software platform
|
|
pairing with newly developed tolling hardware. It was our goal to
|
|
create a system that could be used to support new RFPs and tolling
|
|
projects globally, moving away from a model where custom software was
|
|
required to be developed for each project with individual data
|
|
centers and operational environments. The desired end state would
|
|
require design and architecture of the physical systems but could
|
|
integrate directly into 3M's existing tolling platform.
|
|
|
|
I joined the team near to the beginning of the project. Our initial
|
|
task was to describe the system in detail sufficient for inclusion in
|
|
3M's response to a current RFP for the state of Georgia's State Road
|
|
and Tollway Authority, which was to be our pilot project. Following
|
|
several weeks of technical writing and documentation, we began the
|
|
architecture and implementation of the platform.
|
|
|
|
My responsibilities on this project included:
|
|
- UI/UX team leadership. I providing the bulk of the front-end
|
|
implementation as well as directing and mentoring our two other
|
|
front-end developers.
|
|
- UI/UX design. I was the primary designer.
|
|
- DevOps. I managed the team's internal git server, our internal
|
|
maven and npm repositories, and the team's development environment
|
|
in AWS.
|
|
- Release management. I was responsible for defining our versioning
|
|
schema as well as building, versioning, and publishing our release
|
|
packages.
|
|
- Ownership of several of the core micro-serves, from architecture to
|
|
implementation. Specifically, I was responsible for the whole of
|
|
the Vehicle List Service (VLS), the Batch Processing Service (BPS),
|
|
and parts of both the Image Processing Service (IPS) and Lane Data
|
|
Administration Service (LDAS). This includes everything from the
|
|
REST API layer down to the database.
|
|
- Oversight and coordination of our offshore quality assurance team.
|
|
- Working with Georgia SRTA management and operations personell to
|
|
gather requirements for the initial product design and feedback on
|
|
iterations of the product as we were building it.
|
|
|
|
The core architecture was one of micro-services, where each component
|
|
service of the tolling software infrastructure would be broken out
|
|
into it's own horizontally-scalable service. Some examples:
|
|
|
|
- Vehicle List Service (VLS): This service was responsible for
|
|
managing the list of known vehicles and their associated data.
|
|
Key functions included the need to batch-import lists of tens
|
|
of millions of vehicles daily, the ability to quickly and
|
|
efficiently serve information about specific vehicle queries, and
|
|
the ability to publish updates to physical tolling endpoints.
|
|
|
|
- Image Processing Service (IPS): The IPS was a core component of
|
|
the overall solution which provided both automated and manual
|
|
review of toll point imagery. IPS provided a rich user interface
|
|
with purpose-built workflows for image review personell
|
|
responsible for identifying license plate and ownership
|
|
information in images where the automated system was unable to
|
|
identify the vehicle. IPS supported advanced queueing mechanisms
|
|
to support call-center-like operations, providing the ability to
|
|
evaluate the accuracy and efficiency of individual reviewers, the
|
|
ability to send sets of difficult images to multiple reviewers,
|
|
and the ability to tag and filter images according ti ad-hoc
|
|
metadata created by the reviewers. Using this, reviewers could
|
|
build up a set of images correlated to the same vehicle over
|
|
time.
|
|
|
|
- Lane Data Administration Service (LDAS): The LDAS was another
|
|
core component of the overall solution, tasked with aggregating
|
|
and organizing data provided by the individual toll points into a
|
|
coherent view of the system as a whole. In addition, it managed
|
|
the low-level communication with the toll point infrastructure.
|
|
|
|
LDAS had a sophisticated user interface that allowed tolling
|
|
operators to follow the aggregate flow of traffic through the
|
|
tollway in soft real time, including anomaly detection to alert
|
|
operations of exceptional conditions (wrong-way traffic, for
|
|
example). This interface also provided operators the ability to
|
|
manage the toll point infrastructure.
|
|
|
|
- Transaction Control Service (TCS): The TCS served as the single
|
|
source of truth for all transaction data. Transaction data was
|
|
the most important type of data managed by the system.
|
|
Originating from the LDAS, transaction data passed through most
|
|
of the other services in the solution, being enriched by data and
|
|
information provided by each service in turn. TCS was the
|
|
high-performance system of record for all transaction data.
|
|
|
|
- Batch Processing Service (BPS):
|
|
|
|
- File Store Service (FSS): This served as a distributed store of
|
|
arbitrary file data. This was built on many of the same
|
|
principles as AWS S3, and served as an abstraction on top of
|
|
multiple underlying storage systems (physical disk, AWS S3, and
|
|
database-backed blob storage).
|
|
|
|
- Naming Service: provided service discovery and canonical name
|
|
lookup.
|
|
|
|
Tools \& Technologies:
|
|
- AWS
|
|
- AWS EC2
|
|
- Apache Tomcat
|
|
- Backbone.js
|
|
- Bash
|
|
- CSS
|
|
- CentOS Linux
|
|
- Drools
|
|
- Elasticsearch
|
|
- Git
|
|
- HTML
|
|
- Hazelcast
|
|
- Hibernate
|
|
- J2EE
|
|
- JPA
|
|
- Java
|
|
- JavaScript
|
|
- LevelDB
|
|
- Oracle Database
|
|
- SQL
|
|
- XML
|
|
- XPath
|
|
- XSLT
|
|
- jQuery
|
|
|
|
Responsibilities:
|
|
- Architecture
|
|
- DevOps
|
|
- Full-stack Implementation
|
|
- Mentorship
|
|
- Requirements Gathering & Analysis
|
|
- Technical Leadership
|
|
- UI/UX Design
|
|
|
|
Internal Time-Reporting Tool:
|
|
|
|
Short Description:
|
|
As part of their effort to create a center of software excellence, 3M
|
|
designed their own time reporting tool that was then used across the
|
|
Motor Vehicle Systems and Solutions. For a few months I was given
|
|
technical ownership of the time reporting tool. In addition to
|
|
on-going maintenance and support, I refactored the application at a
|
|
foundational level, extending it to work transparently for multiple
|
|
divisions (originally there was no concept of work groups or
|
|
divisions). This enabled 3M to pusue cost-savings across multiple
|
|
division by replacing externally licensed software with this
|
|
internal tool.
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- ASP.NET
|
|
- CSS
|
|
- HTML
|
|
- JavaScript
|
|
- MS SQL Server
|
|
- SQL
|
|
- jQuery
|
|
|
|
Parking Software (ScanNet):
|
|
|
|
Short Description:
|
|
One of the projects that 3M inherited when it acquired Federal Signal
|
|
was their legacy parking lot management software, ScanNet. This was a
|
|
mature product more than 20 years old, made up of embedded control
|
|
software, server-side backend processing, and user-facing intrefaces,
|
|
with large-scale existing deployments at facilities rancing from
|
|
shopping centers to airports including a number of clients who were
|
|
still actively rolling out new deployments. As a part of those new
|
|
deployments there was functionality promised to clients that had not
|
|
yet been implemented. In addition to maintainence and support the
|
|
dev manager, my teammate, and I were responsible for addressing the
|
|
feature gaps between existing functionality and the promised
|
|
functionality. This allowed 3M to realize the revenue from contracts
|
|
that were contingent on delivery of promised functionality.
|
|
|
|
Tools \& Technologies:
|
|
- .NET
|
|
- C#
|
|
- C/C++
|
|
- MSBuild
|
|
- Power Builder
|
|
- Visual Basic 6
|
|
- x86 Assembly
|
|
|
|
Colleagues \& References:
|
|
- Ben Benson
|
|
- David Ferreira
|
|
- Anthony Barahona
|
|
- Glenn Dawson
|
|
|
|
Edgecase:
|
|
Positions:
|
|
November 2015 \& April 2017: Senior Software Engineer
|
|
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- AWS CloudFront
|
|
- AWS ElasticBeanstalk
|
|
- AWS RDS
|
|
- AWS Redshift
|
|
- AngularJS
|
|
- CSS3
|
|
- Elasticsearch
|
|
- Git
|
|
- HTML5
|
|
- JavaScript
|
|
- Node.js
|
|
- PostgreSQL
|
|
- Ruby
|
|
- Ubuntu Linux
|
|
- express.js
|
|
- macOS
|
|
- node.js
|
|
|
|
Colleagues \& References:
|
|
- Derrick Geeting
|
|
- Cameron Cooper
|
|
- Angell Tsang
|
|
- Jeffrey Dorrycott
|
|
- Ryan Moore
|
|
- Lee Goolsbee
|
|
- Michael Tran
|
|
|
|
SailPoint Inc:
|
|
Positions:
|
|
May 2017 \- March 2018: Senior Software Engineer
|
|
|
|
Tools \& Technologies:
|
|
- AWS DynamoDB
|
|
- AWS Kinesis
|
|
- AWS RDS
|
|
- Apache Flink
|
|
- CentOS Linux
|
|
- Docker
|
|
- Docker Compose
|
|
- Elasticsearch
|
|
- JAX-RS
|
|
- Java
|
|
- JavaScript
|
|
- MySQL
|
|
- SQL
|
|
|
|
Colleagues \& References:
|
|
- Joe DeVries
|
|
- Kameron Sween
|
|
- Trey Perry
|
|
- Rhutwij Tulankar
|
|
|
|
Fairway Technologies (now part of Accenture):
|
|
Positions:
|
|
April 2018 \- January 2020: Principal Consultant
|
|
January 2020 \- present: Assoc. Engineering Manager
|
|
|
|
Projects:
|
|
|
|
Cloudvirga:
|
|
Short Description:
|
|
Fairway partnered with Cloudvirga to deliver the next generation of
|
|
the their digital mortgage platform core product offering, built as
|
|
an Angular 6 application on top of their existing API backend. Given
|
|
the size of the team and account, we appointed two principal
|
|
engineers to lead this effort, myself and a colleague. While my
|
|
colleague was responsible for client-facing leadership and
|
|
communication, I was responsible for technical direction,
|
|
architecture, and leadership internally. In addition to my
|
|
responsibilities as the internal lead, I worked to build a close
|
|
relationship with the client's development team, working through the
|
|
challenges of growing their existing API approach to support the new
|
|
functionality designed for this next iteration of their product.
|
|
|
|
Description:
|
|
Tools \& Technologies:
|
|
- .NET
|
|
- AWS CloudFront
|
|
- AWS IAM
|
|
- AWS Route53
|
|
- AWS S3
|
|
- Angular
|
|
- C#
|
|
- CSS
|
|
- Elasticsearch
|
|
- HTML5
|
|
- JavaScript
|
|
- MS SQL Server
|
|
- SQL
|
|
- TypeScript
|
|
|
|
Responsibilities:
|
|
- Architecture
|
|
- Cloud Architecture
|
|
- DevOps
|
|
- Engineering Management
|
|
- Frontend Implementation
|
|
- Requirements Gathering & Analysis
|
|
- Team Composition
|
|
|
|
Cloudvirga ARRIVE:
|
|
Short Description:
|
|
After the initial effort to deliver their next-generation product,
|
|
Cloudvirga engaged the same team to help accelerate the development of
|
|
critical features in their existing product offering in order to meet
|
|
aggressive deadlines communicated to their clients. At this point I
|
|
was asked to become the overall delivery lead for the project. In
|
|
this capacity I worked closely with Cloudvirga's engineering
|
|
management to prioritize work and get it into the hands of our team.
|
|
We successfully delivered several major features ahead of schedule
|
|
allowing Cloudvirga to regain confidence with their clients who had
|
|
expressed concern at the anticipated schedule delay.
|
|
|
|
Description:
|
|
- Complex ASP.NET application straddling front and back.
|
|
- Complex existing backend database schema.
|
|
- Complex versioning schema as CV maintained multiple independant
|
|
branches of the code white-labeled for different clients with
|
|
differing feature sets.
|
|
- Aggressive timelines. Jumped immediately into fire-fighting
|
|
situations with CV engineering, helping them close several
|
|
high-visibility and high-priority defects the first week of
|
|
engagement. Continued to pick up new feature requirements, ramp up
|
|
on this complex environment and complete the first major feature
|
|
delivery inside of a month.
|
|
|
|
Tools \& Technologies:
|
|
- .NET
|
|
- C#
|
|
- ASP.NET
|
|
- jQuery
|
|
- HTML
|
|
- CSS
|
|
- SQL
|
|
- MS SQL Server
|
|
|
|
Responsibilities:
|
|
- Client Communications
|
|
- Delivery Lead
|
|
- Engineering Management
|
|
- Full-stack implementation
|
|
- Project Estimation (cost and timeline)
|
|
- Requirements Gathering & Analysis
|
|
|
|
Grant Country Principal Utility District:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- Excel Power Query
|
|
- MS SQL Server
|
|
- PowerBI
|
|
- Microsoft Dynamics Great Plains
|
|
- Safe Software FME
|
|
|
|
Responsibilities:
|
|
- Database Architecture
|
|
- Requirements Gathering & Analysis
|
|
- Project Estimation (cost and timeline)
|
|
- Delivery Lead
|
|
- Reporting and Analysis
|
|
|
|
Smarter Balanced Tools for Teachers:
|
|
Short Description:
|
|
Tools for Teachers was
|
|
|
|
Description:
|
|
Smarter Balanced Assessment Consortium (SBAC) had a successful
|
|
history of partnering with Fairway Technologies for development and
|
|
delivery of technology surrounding their core assessment products.
|
|
|
|
Tools \& Technologies:
|
|
- AWS CloudFront
|
|
- AWS IAM
|
|
- AWS S3
|
|
- AWS CodeBuild
|
|
- AWS Route53
|
|
- Terraform
|
|
- Angular
|
|
- TypeScript
|
|
- HTML5
|
|
- CSS3
|
|
- SCSS
|
|
- REST API
|
|
- API Platform
|
|
- PHP
|
|
|
|
Responsibilities:
|
|
- Frontend Implementation
|
|
- Cloud Architecture
|
|
- DevOps
|
|
- Delivery Lead
|
|
- Requirements Gathering & Analysis
|
|
- Project Estimation (cost and timeline)
|
|
- Engineering Management
|
|
- Project Staffing
|
|
- Project Management
|
|
|
|
Chevron IAM Migration:
|
|
Short Description:
|
|
|
|
Description:
|
|
- Chevron wanted to migrate from Ping Federate onto Microsoft Azure
|
|
Enterprise Applications for SSO.
|
|
- Established a standard process and trained additional team members
|
|
in it's use.
|
|
- Migrated hundreds of applications within a six month period
|
|
(beating the deadline by three months).
|
|
- Worked with internal Chevron application owners (often
|
|
non-technical) and vendor support to perform the migration.
|
|
|
|
Tools \& Technologies:
|
|
- Azure Enterprise Applications
|
|
- PingFederate federation server
|
|
|
|
Responsibilities:
|
|
- Customer Service
|
|
- Requirements Gathering & Analysis
|
|
- Vendor Management
|
|
- IAM Consulting
|
|
- IT Operations
|
|
|
|
Tegra118 Unified Wealth Platform:
|
|
Short Description:
|
|
The Unified Wealth Platform (UWP) was a web-based software offering
|
|
for financial adviser and brokerages that allowed them to trade and
|
|
manage their customer's financial investments. Tegra was on their
|
|
second re-write of the front-end portions of the product when I
|
|
was brought in as the delivery lead for the project. It was again in
|
|
danger of failing due to unclear requirements, lack of architecture
|
|
and planning, undocumented APIs and system behavior,
|
|
overly-complicated backend systems, and unrealistic customer-facing
|
|
deadlines.
|
|
|
|
Through concerted effort, we were able to clarify the
|
|
requirements and align testing efforts to the documented
|
|
requirements, we were able to document large portions of the API,
|
|
adding strong typing to assist in correctness, and we put into place
|
|
fundamental architectural thinking. Along the way we navigated
|
|
competing stakeholder priorities, serious COVID disruptions, and
|
|
continual environmental disruptions. At the same time I had to build
|
|
a new team from the ground up as the client objected to plans of my
|
|
predecessor, requiring us to go back to the drawing board with regard
|
|
to staffing.
|
|
|
|
In the end we were able to work with the client stakeholders through
|
|
necessary schedule adjustments and coach their leadership through the
|
|
trade-offs that we were forced to make given the schedule. We
|
|
successfully transitioned the project from a waterfall-style,
|
|
plan-every-day release schedule and deliverables with predefined
|
|
release dates and scope to a more Agile method of rolling releases on
|
|
a regular cadence. Despite the unrealistic internal deadlines, we
|
|
were able to find a path to deliver almost all of the originally
|
|
promised functionality to the customer within the original customer
|
|
timeline, or with slight delays (on the order of weeks).
|
|
|
|
The successful delivery of this project was a direct result of the
|
|
continual, extraordinary effort put in by the team, and my efforts to
|
|
provide clarity and direction across all aspects of the product
|
|
development.
|
|
|
|
|
|
Description:
|
|
Tegra's main product has a heritage reaching back over forty years,
|
|
with the core of their product offering still running APL code on IBM
|
|
AIX mainframes. Over time they have built up layers on top of this
|
|
core and today offer their product as a SaaS-like web application
|
|
called the Unified Wealth Platform (UWP). A previous vendor built the
|
|
1.0 version of the UWP, the latest version of their offering packaged
|
|
as a web application. Unfortunately Tegra found that version to
|
|
be very difficult to maintain and extend, and they decided to rebuild
|
|
the application with new designs, updated requirements, and explicit
|
|
quality targets. Their hope is to have a foundation on which they can
|
|
continue to build into the future.
|
|
|
|
Due to tight timelines and scope miscommunications, the project was
|
|
almost dead before it could get off the ground. Tegra initially
|
|
scoped the project as a rapid prototyping effort, making clickable
|
|
demoes of mockups in progress to allow business to iterate quickly on
|
|
different ideas. All of the architectural choices reflected this
|
|
preference for rapid turnaround and iteration (for example,
|
|
purposefully forgoing common UI components in favor of copy/paste and
|
|
tweak). At this point Tegra still expected to be able to refactor
|
|
their existing 1.0 codebase to match the designs and prototypes being
|
|
created.
|
|
|
|
In time it became apparant that they would not be able to use the 1.0
|
|
codebase as a foundation for the new designs. Hard delivery deadlines
|
|
had already been communicated to Tegra's customers. Due to this time
|
|
pressure, the decision was made to take the prototype codebase and
|
|
flesh it out into a propoer 2.0 release of the UWP.
|
|
|
|
The original team staffed did not have anyone with experience running
|
|
a large-scale, end-to-end product delivery effort like this and the
|
|
team quickly found themselves behind schedule and over-committed.
|
|
|
|
Tools \& Technologies:
|
|
- Angular 10
|
|
- Azure DevOps
|
|
- Figma
|
|
|
|
Responsibilities:
|
|
- Engineering Management
|
|
- Delivery Lead
|
|
- Frontend Implementation
|
|
- DevOps
|
|
- Requirement Gathering & Analysis
|
|
- Project Estimation
|
|
- Project Staffing
|
|
- Project Management
|
|
- Scrum Master
|
|
- Architecture
|
|
- Technical Writing
|
|
|
|
Colleagues \& References:
|
|
- Steve Mock
|
|
- Noah Heldman
|
|
- Ben Heebner
|
|
- Cullan Bittner
|
|
- Landon Lunsford
|
|
- Aaron Sleeper
|
|
- Ernie Munoz-Diaz
|
|
- Jeff Treuting
|
|
- Natasha Lopez
|
|
- Ryan Anderson
|
|
- Brandon Savage
|
|
- Shreedam Parikh
|
|
- Amy Thierry
|
|
- Nohemi Acosta
|
|
- Walton Yeung
|
|
- Jeff Getzin
|
|
- Shankar Ramachandran
|
|
- Jessica Müller
|
|
- Ashish Nageet
|
|
- Chia-Yen Wu
|
|
- Prashanti Dasari
|
|
- Jacob Sonsteng
|
|
|
|
Other Projects:
|
|
UPCI Wall of Honor:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- AWS Lambda
|
|
- AWS DynamoDB
|
|
- AWS CloudFront
|
|
- AWS S3
|
|
- AWS CodeBuild
|
|
- AWS API Gateway
|
|
- AWS VPC
|
|
- Vue.js
|
|
- HTML5
|
|
- CSS3
|
|
- SCSS
|
|
- TypeScript
|
|
- REST API
|
|
- Bash
|
|
- Make
|
|
- Git
|
|
- REST API
|
|
- Terraform
|
|
- Okta IAM
|
|
- Figma
|
|
|
|
Responsibilities:
|
|
- Graphic Design
|
|
- UI/UX Design
|
|
- Full-stack Implementation
|
|
- Cloud Architecture
|
|
- DevOps
|
|
- Database Administration
|
|
- Delivery Lead
|
|
- Project Management
|
|
- Requirements Gathering & Analysis
|
|
- Contract Negotiation
|
|
- Customer Service
|
|
- End-user Training
|
|
- Project Estimation (cost and timeline)
|
|
- Client Communications
|
|
|
|
StrawBoss Continuous Integration Server:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- Nim
|
|
- Jester
|
|
- Docker
|
|
- Linux
|
|
- systemd
|
|
- REST API
|
|
- Bash
|
|
- Make
|
|
|
|
VBS Suite:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- Erlang
|
|
- JavaScript
|
|
- Backbone.js
|
|
- Mnesia
|
|
- HTML5
|
|
- CSS3
|
|
- SCSS
|
|
- JavaScript
|
|
- Backbone.js
|
|
- REST API
|
|
- Bash
|
|
- Make
|
|
- Git
|
|
|
|
New Life Songs Database:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- Groovy
|
|
- JavaScript
|
|
- AWS ElasticBeanstalk
|
|
- HTML5
|
|
- CSS3
|
|
- SCSS
|
|
- JavaScript
|
|
- REST API
|
|
- Git
|
|
- Bash
|
|
- Make
|
|
- Figma
|
|
|
|
Responsibilities:
|
|
- UI/UX and Design
|
|
- Architecture
|
|
- Full-stack Implementation
|
|
- DevOps
|
|
- Database Administration
|
|
|
|
SermonLink.net:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- Groovy
|
|
- JavaScript
|
|
- Backbone.js
|
|
- HTML
|
|
- CSS3
|
|
- SCSS
|
|
- REST API
|
|
- PostgreSQL
|
|
- Git
|
|
- Bash
|
|
- Make
|
|
- Figma
|
|
|
|
Responsibilities:
|
|
- UI/UX and Design
|
|
- Architecture
|
|
- Full-stack Implementation
|
|
- DevOps
|
|
- Database Administration
|
|
|
|
Personal Measure:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|
|
- Nim
|
|
- Jester
|
|
- Vue.js
|
|
- TypeScript
|
|
- HTML5
|
|
- CSS3
|
|
- SCSS
|
|
- REST API
|
|
- PostgreSQL
|
|
- Git
|
|
- Bash
|
|
- Make
|
|
- Figma
|
|
|
|
Live Budget:
|
|
Short Description:
|
|
|
|
Description:
|
|
|
|
Tools \& Technologies:
|