Examples of Bob's Work
Interviewing is a difficult experience. The employer is trying to see if the person will fit into many different aspects of the job, and the potential employee is trying to put their best foot forward while not overstepping their bounds. Because this is a balancing act - played out in a very limited time, employers often let the person know of a corporate web site where they can learn more about the company and come to the interview prepared with some interesting questions. The reverse would be nice as well - have a place where the employer can look at examples of the work a person has done to get a feel for their technical range and ability.
This page attempts to condense over 25 years of experience into a short summary of important projects that Bob has worked on. It's not complete, and tends to focus on the projects Bob has a significant role in, as opposed to those projects where he was simply on the periphery.
PostGrid is a service that offers the ability to accept PDFs, HTML, templates and physically print and email the documents to recipients. As a bridge to the legal legacy world of printed documents, it’s very helpful - but the straight REST endpoints makes for difficult integrations. They also have an Address lookup, verification, and autocomplete service, again with just REST endpoints. This client makes it very easy for Node/JS developers to work in a familiar system, while leveraging all the powerful features.
Creditsafe is a corporate credit and financial reporting service that covers most of the globe. As a resource for FinTech companies, it’s very helpful - but the straight REST endpoints makes for difficult integrations. This client makes it very easy for Node/JS developers to work in a familiar system, while leveraging all the powerful features
Notarize.com is an online notarization service, as well as an eSigning authority. With the legal documents in the Construction Industry’s accounts payable/accounts receivable chain, this is essential for quick, fluid, movement of documents - but the straight REST endpoints makes for difficult integrations. This client makes it very easy for Node/JS developers to work in a familiar system, while leveraging all the powerful features
New regulations around the disclosure of the final closing documents required an online tool to capture and edit the closing costs from the Title Company, and Trident was created to be a TRID-compliant closing document collaboration system between company agents and lender agents.
Required for Trident, Polaris was created as a versioned, immutable data warehouse of all versions of all loans for Guaranteed Rate. Getting this data out of Ellie Mae's Encompass enabled business services to be written outside of the Encompass ecosystem, and in Clojure-based RESTful services.
In order to support completely automated Application Packets for online-entered mortgage applications, Underdog was created to marshal all the state, and local fees, all processing fees, and then create the payload to have the Application Package sent to the borrower(s) in their preferred format (esign, overnight, etc.)
Dark Magic is an extraction and abstraction of the demand adjustment and caching that originally existed in Quantum Lead. As that project grew, and the adjustments and demand calculations grew ever more complex and time-consuming, it was decided that creating it as a separate project made the most sense. The new technical direction - clojure, was chosen for this project and several new technologies grew up around this project.
Quantum Lead is a sales and planning tool to present the best prospects to the sales reps within Groupon so that every call they make is the most profitable they can make. This includes a large matching engine of merchants and customer demand to rank the merchants in terms of their potential benefit from running a deal with Groupon.
DataBusII is really the next generation ticker plant for the organization. With additional data from OPRA, and the added weekly expirations, the amount of data coming from the exchanges was just too much for the existing design and implementation to handle. The new system uses boost's asynchronous I/O library as well as a thoughtful design to lockless data structures and atomic operations. The goal is simple: no dropped packets!
PricingServerII is really the next generation pricing server (greeks) for the organization. With additional data from the exchanges, the amount of data coming was just too much to for the existing design and implementation to handle. The new system uses embedded DataBusII ticker plants and a thoughtful design to lockless data structures and atomic operations. The goal is to provide fast clients with as much data as they can take, and slow clients get the latest data and not backup the server.
Falcon is the historical, intraday ticking, web-based visualization of the firm's P/L and risk metrics used by portfolio managers and the Global Risk Management group at CTC. It's making extensive use of the Google Visualization gadgets with a Tomcat-based back-end utilizing an H2 in-memory database to answer the requests for the time-series data from the AJAX clients.
MarketMash is the center-state non-historical risk/decision support tool that is delivered to most trader's desks around the world in O'Connor. It brings together the fast-tick market data with prices, positions, risk, option greeks, MTM, P/L - all in one very flexible tool that allows for the generation of grouped reports, aggregated values, and graphs. The non-fast-tick components of MarketMash are obtained through InfoShop while the fast-tick data is obtained from the MarketMash Server. A reporting package was selected prior to Bob's arrival at O'Connor and forms the basis of the display system of the MarketMash Middle-Tier.
The MarketMash Server is a group of tightly-coupled C++ applications running on a group of five quad-Opteron boxes running 64-bit RedHat Enterprise Linux 3. There is one installation for production in Chicago and another for disaster/recovery in London. It has a price feed service - both polling and streaming for optimally managing the current state of over 400,000 instruments including price, position, greeks and associated instrument data. The server has a group of machines whose sole purpose is the calculation of these greeks, and the server's kernel sits in the middle, taking trades from the straight-through processing system, updating positions, updating prices from the price feed, sending out calculations for new greeks, and sending all this information to it's clients - the MarketMash Middle-Tiers and Factory.
Each MarketMash Middle-Tier is a collection of Java processes that run on quad-Opteron Linux boxes running RedHat Enterprise Linux 3 that are not strictly clustered but rather communicate by means of a proprietary connection scheme of JMS pub/sub queues to move the data around. It is written entirely in Java. It was the first production use of Linux machines in UBS, and as such, has often been used to test new Linux server hardware as a benchmark of the hardware's capabilities. There is an installation in Chicago (three machines), another in London (two machiens) and the third in Hong Kong (one machine). With these, MarketMash is running 24x5 except for a 30 min restart of the MarketMash Server in the Chicago evening to reset start-of-day numbers to the coming day.
The Factory is the second-generation 'core' of the MarketMash Middle-Tier created with an eye towards replacing the third-party reporting framework with a more flexible one while consolidating O'Connor's market-based IP and data into a core service that many more applications and services can use. The Factory has all the collection and aggregation functions that the MarketMash Middle-Tier has, but in addition adds calculated fields, access to this data from Excel/VB/etc. through a COM interface, Java through an RMI interface, and plugins that allow users to write simple call backs that can then process data for each update as the engine within the Factory computes each update.
InfoShop is a high-level collector/organizer/aggregator/distributor for non-fast-tick data that needs to be brought into a single location so that it can be easily merged with the fast-tick data in either the MarketMash Middle-Tier or The Factory. The function of this collector/distributor are to bring together many different sources of data - flat files, database queries, dynamic results obtained from CORBA calls, proprietary analytics created by the research group for the Analytic Engine, all into a clearly organized, pub/sub-based distribution scheme.
InfoShop is written in Java running currently on a quad-dual-core-opteron running RedHat Enterprise Linux 3. It uses the Sun ONE Message Queue (imq) for both query/response and pub/sub functionality, as well as CORBA, JDBC, XML parsing, flat files, etc. to collect and process the data properly.
While the price data from the MarketMash Server's ticker plant includes basic price data, there was a need in O'Connor for a more generalized source of market data. More detailed data, historical data, known data from trusted sources. This includes data from Bloomberg, Reuters, UBS historical price warehouses, and the same price ticker plant as the MarketMash Server. These data sources needed to be normalized so that a single interface could get at any one of these data sources without different symbology, calling methods, data interpretation, etc. Out of this need, the MarketData Server was created. It offers up an in-memory cache of historical data for selected fields from selected sources and can go to the original source to complete any request that it doesn't have data for at the time of the request.
Reuters is the primary real-time price feed for UBS, and while the MarketData Server can access it directly, it does not intend to be a vendor of ticking prices. That was to be the goal of an internal UBS project called PriceMachine 2, or just PM2. The problem with PM2 is that it's an interface on Reuters and not a real, solid source of prices at any time of the day. Therefore, the CacheStation was written to cache the prices, add in computed fields, and vend this data to Java and C++ clients as easily as possible. Currently, all in-house applications that need pricing within UBS O'Connor go to the CacheStation for their real-time price needs.
InfoShop needs to collect such things as basket prices and performance index calculations many times an hour throughout the trading day. These calculations are on groups that are defined in some database, or flat file, and they are the bread and butter calculations - no one-of-a-kind requests, and are carried out on a quad-i686 running RedHat Enterprise Linux 3 in Chicago.
One of the longest projects Bob has been working on dates back to the days when an IBM PC was a hot machine. In 1982 Bob and his officemate Jim decided to work on the idea of solving the daily CryptoQuip puzzles in the school newspaper. Jim had been using grep and /usr/dict/words from the school's computers to work on each word in the puzzle, but they decided that the better way to solve the problem was to attack the entire phrase by finding similar matches to the decryption keys in all the words. So Bob started on his version in Turbo Pascal for his IBM PC, and Jim did a C program on the school's DEC VAX.
Several generations of this code have come and gone, and Bob's most recent incarnation is available as an Xcode 10 Objective-C project, as well as a Swift 4.2 project, a Ruby version also exists, as does a Clojure version. All these versions implement the same attack on the solution, and have been used to compare the code size, execution speed, and code-readability of the different implementations.
Another long-running project that Bob has been working on dates back to the NeXT Turbo Color Slab running NeXTSTEP 3.3, and a fun implementation of the solution to Poisson's Equation for the potential in a 2D field. The idea was to take various structures (lines, points, rectangles, etc.) that were charge sheets, conductors, or dielectrics, and then simulate the region quickly and efficiently with tools like cLAPACK. Then the results would be displayed, and saved to a file for plotting.
Potentials builds with macOS 10.14 and Xcode 10.2, and has seen some recent improvements to the display of the results.
BKit is a set of highly reusable Java classes that Bob has used in several projects and found to be quite useful and stable. Such reusable libraries of components aren't anything new, but Bob has put several years of experience into these objects - first in Objective-C and now in Java. They have more than proven themselves.
The reason for this project's inclusion on the short list is that it highlights his design skills as well as his ability to write well documented, robust, reliable, reusable code.
Given the BKit has been such a useful collection of classes, it was somewhat inevitable that when Bob had to write some servers in C++ most of the important classes were migrated to C++ and became CKit. While there's not a 1:1 correlation between a BKit object and something in CKit, everything that is high-level is reproduced, and where necessary, the CKit library adds things that are simply not needed in Java. A simple variant class is needed to hold any type of data in CKit, for instance, where Java has it's Object. The code is viewable online
The reason for this project's inclusion on the short list is that it shows that development need not be an either-or proposition. BKit and CKit have the ability to serialize their objects on the wire so that a service or client in one can easily communicate with another. Too often these days it seems that everyone is looking for a Java developer, or a C++ developer, when they ought to be looking for a good developer.
When Bob started working in low-latency systems, and by low-latency we're talking milliseconds not nanoseconds, there came a need for a library of atomic datatypes and lockless data structures to make the building of such systems simple, easy, and high-performance. So that after Bob had completed his first cut of these components, he started a second generation version, and that became DKit.
This library, hosted on GitHub, is something that Bob is going to keep building on and using as it dovetails nicely with boost, as well as providing some of the essential building blocks for market data and analytic systems.
Bob's Ph.D. thesis was based half on the design, development, and production of a bias-tunable GaAs monolithic microwave generator, and the other half on the simulation of the device to verify that the observations were indeed based on the physics of the material, and not an artifact of the measurement technique.
So, in the late 1980s, Bob developed shark, a two-dimensional plus transient FET-structure simulator that was capable of handling most III-V and IV semiconductor materials and matching insulators, along with the physical structure being fabricated in the lab. What resulted was a code that was accurate, but took so long on even the fastest of the school's computers (a Cyber 205 supercomputer) that the verification was not considered feasible.
But time marches on, and Bob has breathed life into the phoenix that was his thesis and it lives, oddly enough, on a Mac.
OneCard was an interesting project that Bob did in 1999 for the Commerical Card Services group in BankOne. He was responsible for all the back-end services - database, MQSeries to the credit card processing house, production servers, disaster/recovery plans, etc. While most of this code is exceptionally business-specific, and therefore not very reusable, it also represents Bob's single most significant body of work in Java. There are currently more than 225,000 lines of Java code in this class set alone. More, if you count the SQL scripts to generate the database schema.
The reason for this project's inclusion is as much that it incorporates database, MQSeries and Java, but also that it took Bob just 8 months to create all this code, and debug it. That comes out to over 1300 lines of debugged, commented, code a day. That's significant.
DealTracker is another business-specific, back-end processing set of Java classes, and while there isn't the volume of code as compared to OneCard, the time Bob spent on DealTracker was measured in days, not months. Probably the most significant point is that after coming off OneCard, Bob was able to leverage much of the work done on BKit and OneCard to make DealTracker a success in a very short time.
For quite a long time, Bob's friend, and co-worker at BankOne - Joel has brought him interesting ideas for projects outside of his regular work. One of them was an image-based cellular analysis web site to be used by doctors and lab technicians to identify cancerous cells that have reacted with certain reagents and stains to mark their identity.
What's important about this project is the fact that samples can be defined, slides uploaded, processed in real-time, with their results displayed to the user. This is the core of what Bob has done for this project. What makes it exceptional in our mind is both the quality of the results and the speed at which they are delivered. This is truly exceptional work.
Bob is a big fan of SubEthaEdit on Mac OS X. While it might not be the only editor he uses, it's certainly a nice one that allows for custom languange modes that are OS X 'bundles' with syntax highlighting rules, additional scripts, etc. that make working with a particular language in SubEthaEdit much nicer. A few of the optional language modes were nice starts, but Bob did a little more customization on them - fixing formatting of numbers, cleaned up problems in the syntax highlighting, etc. You can get a look at them and download them off this page.