Herbie Marais

I developed a complete system to integrate data flow between the storefront of a well known eCommerce platform with the warehousing and fulfillment system of my client.

The architecture was designed to be extensible and maintainable by any future developer my client could potentially employ and included the following workflows.

Order Import/Submission
- The storefront would submit orders in cXML form to an API I created. The API would then validate and process the order into the format required by my client's warehousing and fulfillment system.

Inventory updates
- The warehousing/fulfillment system periodically, or by user instruction, updates inventory levels from my client's system into into the storefront's back-end using their SOAP web services.

Shipment notifications
- The warehousing/fulfillment system notifies my integration system by means of a file drop that an order has been shipped. My system the collects the required information and submits it via XML post to

This system was written in C# using the following tools/frameworks
- Dapper.NET
- Entity Framework
- WebAPI2 + Swagger
- Quartz
- Windows Services
- IIS
- SQL Server
- SOAP
- cXML
- REST

I developed a data transformation system that would take an XLSX spreadsheet uploaded by the user and do the following:

- Validate the data
- Look up various data, like product keys and employee numbers
- Audit logging
- Output a CSV file with the data transformed from the user's XLSX format into the format required by the client's shipping/fulfillment system.

This is a set of services that will eventually replace a component that was originally written in C++. The legacy component has almost no separation of concern and has grown into a single monolithic component that is the backbone of our business.

I designed the new data processing services to be modular and scalable, so that they can be deployed in a heavily load balanced environment. Efficiency and horizontal scalability were non-negotiable during the design.

The services use message-queuing to send messages between on another but great care was taken not to be bound to a specific queuing tech.

The goal of these services is to be able to handle the data coming in from more than 500,000 tracking devices, at frequencies greater than 1 message every five seconds from each devices. Even though the system is designed to run in a heavily load balanced environment, we have a mandate to keep the operating cost of the system as low as possible. To achieve this, I had to come up with a design that promotes modularity without sacrificing performance.

A core component at MiX Telematics that sets them apart from their competitors is what they call "unit configuration." In short, the onboard computers (OBC) execute a proprietary scripting language. For efficiency, the scripts are compiled into a binary format synonymous to machine code i.t.o. conventional programming languages.

This allows them to make the OBC do new things without firmware changes, they simply need to upload a new binary to the OBC.

Because of the dynamic nature of the business and the rate at which very diverse features are added, making code changes/deployments to the user interface every time a new feature is made available is out of the question.

To overcome this the new behavior is broken up into rules in the database.These rules are then consumed by an "engine" that renders a user-friendly web interface unique to that device/feature. The customer can then customize the behavior. Once the customer has saved the changes, a compilation service is invoked offline that will generate the configuration script and compile it into the binary format for the OBC. This allows for the rapid deployment of new features because it only requires that the new rule sets be added to the database.

At Triple Point Technologies, I was the lead designer/developer for the new framework that was to carry the next generation of systems in the company. The framework was designed so that it had absolutely no dependency on the business code that the company deals with. It made sure that all third-party technologies, like logging, message queuing, and data access (NHibernate) are properly abstracted, not only to ensure that we don't get tied to a technology that might reach end-of-life, but also to make it easier for a developer that is not familiar with the tech to use it.

At Saflec Systems, I wrote modules to integrate with various third-party biometric devices. The most significant of which was an extension that integrated the HandPunch (http://www.handpunch.com/) into our access control system. This involved marshaling their undamaged C binaries into our C# software. I also bypassed some of the calls in their SDK and reverse-engineered the protocol by sniffing the packets on the TCP link between the device and the software in order to get better performance.

As part of my honors degree at the University of Johannesburg, I created my own hand geometry identification/verification device/software.

I built an enclosure that created a controlled environment where the software uses a simple webcam to take multiple pictures of the subject's hand.

I then created my own algorithms to process these images into a template that can be matched against previously stored templates.

Using a very accurate scoring system, the best match is then pulled from the database and the subject is identified by only the shape of his/her hand.

What makes this solution so unique is the fact that the hand is held in free air, so there is no contact with the device. This is an existing limitation of most biometric devices, is that they require physical contact with the scanning device, and creates hygienic concerns.

The source code of this project belongs to the university, but I can make some of the documentation available upon request.