Fulcrum Dynamic

Client

Our client for this project was an image licensing service with a large image library. 

Problem

The client wanted to provide their users with a reverse image search, allowing them to use one image to search for other similar ones. That way if users already had an image they wanted to use or an image that resembled what they wanted, they could simply upload the image to the search, and find similar entries in the image database, ready to be licensed and used.

Solution

We built a new microservice to serve to interact with the TinEye API and optimized the ElasticSearch features and added a form to drag and drop images in the search bar.

You upload the image on the form. That gets sent to a microservice wrapping TinEye which is responsible for processing the image.

We have indexed the image database in TinEye, so it can have something to search for. TinEye will return a JSON result set, which we then passed to ElasticSearch to be filtered some more.

We built a service to send images from the client’s image database to TinEye to be indexed. We built a UI for the image search to allow easy drag-and-drop upload of image samples and clean presentation of results. We integrated with their existing search functionality, built on top of ElasticSearch, including filters by color, size, format, age, etc., and text-based searching. So a user could search by image and apply additional filters to further narrow their search.

Client

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of proppant, crude, and other materials to and from trucks, railcars, silos, and other containers. 

Problem

Their system tracks inventory in real-time, automatically requesting more proppant from a company-owned loading facility, delivered by company-owned trucks. With this system in place, our client is able to take full responsibility for the provision of proppant at the well site. However, with this responsibility comes liability. The logistics company contracts with its clients to guarantee the availability of proppant at the well site, similar to a Service Level Agreement for a mission-critical IT service or system. Drilling an oil well requires the coordination of multiple teams of people from different companies on-site, operating millions of dollars worth of equipment. If the logistics company’s equipment malfunctions or they fail to deliver enough sand in time, the logistics company must compensate their client for the lost productivity of their people and equipment on site.

Solution

The bulk sand operators on site were already using ruggedized Android tablets to access equipment maintenance schedules, the company time clock app, and other resources, so we built a mobile app that could be deployed to these existing devices.

We provide a flexible UI that looks great on phones, tablets, and desktops. Our framework allows us to build a single application code base that can be deployed to nearly any platform: including Windows, Mac, and Linux desktop applications; Android and iOS mobile applications; and of course web browsers as a Single Page App (SPA) or Progressive Web App (PWA). And we use a cloud-hosted NoSQL database to provide a flexible back-end data store in the cloud.

Client

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

The client has a proprietary cloud-based operations management application they use to track all material and asset movements at each of their facilities.  A key part of this process requires capturing bill of lading signatures from truck drivers before they leave the facility. Different facilities require different configurations, based on available equipment, facilities, and staffing.  Some facilities use desktop PCs with a USB signature pad, while others use a ruggedized mobile device with a touchscreen.  Still, others use custom-built kiosks with larger touchscreens.  No matter the hardware used, signatures need to be captured and stored in a consistent format and must be easily retrieved later for auditing and verification purposes.

Solution

Using an open source jQuery signature plugin, and the proprietary SDK from the device manufacturer, we built a single, reusable component that allows signatures to be captured via any method: signature pad, touch screen, mouse drawing, and saved to the app’s datastore as a PNG file.

If the signature pad is installed, impressions are captured in real-time and rendered on the screen.  If the signature pad is not installed, the system will fall back gracefully.  A message informing the user on how to install the signature pad can be displayed.  Meanwhile, the other signature methods are still available.

Driver signatures are captured in the web app, along with the other truck data. This box supports both physical signature pads like the one pictured about as well as signing with a mouse or touch screen.

Client

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

The scales have a series of pressure-sensitive load cells, which are all connected to a metal box, called an “Indicator” which is located in the small office where the terminal operator sits, at a computer.

The client wanted to be able to have that scale value feed directly into their custom terminal management system, so the operator doesn’t have to manually type the number in, and risk incorrect entry. This application, by the way, is a web-based cloud application, not something running locally on the PC.

Solution

We ended up building a Node.JS service, which would open a socket to the scale indicator, and read the raw data stream. We built separate profiles for the different formats used by different scale vendors, so the service could interpret them. We also added logic to ignore variations caused by wind, and cut down network chatter. Then we deployed this service on a little headless appliance PC at each terminal.

Initially, the service simply provided a REST API to allow us to request scale weights on demand, but this required port forwarding at each location, which was not always possible, and when it was, made setup more complicated. Later, we reworked it so the service would push the weight data up to the cloud whenever there was a change.

Client

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers. 

Problem

The most significant feature request was an easier way to modify bills of lading after the fact, as well as tracking those modifications. The bill of lading contains a large assortment of data about the load: customer, service company, product, tare, gross weights, purchase order number, driver name, signature, etc.

Solution

We used these capabilities to automatically update the gross tare and net weights based on the total of the drafts, keeping the net weight matched to the sum of the drafts. We built a integration to allow Chosen.JS’s searchable select boxes to interact with Angular scope variables. Any time a value was updated in a drop-down menu (Customer, Order, Job, Product) we could automatically trigger updates elsewhere in the form. When a change in value caused the available options in another select box to be modified, we would pull an updated option list from the API via AJAX.

Client

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

The client’s business is not based on the products they handle, but on the handling itself. As such, they bill their clients based on the weight transported, with rates varying based on location, customer, mode of transport, material type, container type (silo, hopper, warehouse, etc.), and various other factors. Some of these rates are set on a sliding scale based on volume. Some include minimum volumes that must be achieved within a certain time frame.

Calculating exactly what each customer owes them at the end of the month is an extremely complex task. Data on every truck to visit each facility was being exported into a spreadsheet, and the accounting department would add all the various calculations, manually entering the more complex variations. But as the business grew, this became too time-consuming, and they simply could not keep up.

Solution

We built them a system where they could enter all the complex details of the billing agreement for each contract. Then we built a report generation system where they could grab all the transactions for each customer, have the fees automatically calculated, and quickly review them. Once reviewed, they would click a button and all the transactions would be exported to their accounting software, and an invoice would be generated. Later, as the client’s business grew, we modified the export to send the transactions to an enterprise ERP system instead.

Client

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

The silos were designed to be managed using a piece of industrial automation software called a SCADA (short for “supervisory control and data acquisition”). This significant investment in mechanical equipment and software promised to increase throughput for the terminal. However, since the SCADA was provided by their client, the transload company had no control over the software and limited access to its data.

Solution

The SCADA system implemented at this site had limited integration capabilities. However, it was configured to write out a log of trucks unloaded and railcars loaded to a local MySQL database, in two separate tables. The system also had the ability to consume an XML feed of incoming trucks.

We had previously built the client a custom microservice service in NodeJS. It ran on an appliance installed at each of their facilities, and collected data from truck scales, interfacing with the terminal management application in the cloud through a REST API.

We modified this service, adding a microservice to provide the XML feed the SCADA required, pulling data from the terminal management application. We also added a service that would repeatedly poll the SCADA database for new and updated records in the relevant tables. Any new loads would be translated to the format required by the terminal management system’s REST API, and forwarded to that system, as close to real-time as possible.

Client – StepStone Realty

StepStone Realty has built a successful business around creative real estate. They provide a number of services to help their investor agents close deals more effectively, from short sale processing to mentoring to training. StepStone prides itself on the flexibility it can offer to its agents, compared to more traditional real estate firms.

Problem

However, one consequence of all this flexibility and variety of services is a rather complex fee structure.  Some closings include multiple levels of referral fees, while others have fees for extra processing services or discounts based on sales volume.

Some of the fees and commissions are flat amounts, while others are percentage commissions.  Sometimes the commission converts to a flat fee after a certain threshold is met.  Some fees differ based on prior sales volume.  Suffice it to say, the calculations are somewhat complex.

The StepStone team was calculating all this manually, but the process was time-consuming and error-prone, and most importantly, as the company grew, the manual calculations wouldn’t scale.

Solution

We built them a form that allows them to enter the key details about each closing (property, agent, sale price, date completed, services used, etc.), and store the details, allowing them to be linked to the agent data already stored in their database.

We converted all the rules for their fee structure to a set of functions within the app, which could take the provided data, look up previous sales, and calculate all the other related fees.  Once this logic was in place, we were also able to provide a preview functionality, where the user could see how the fees would calculate out based on the selected options, and determine if changes needed to be made before saving the entry.

Client

Our client is a Real Estate Company based in Austin, Texas.  They have built a successful business around creative real estate.  They provide a number of services to help their investor agents close deals more effectively, from short sale processing, to mentoring.  They pride themselves on the flexibility they can offer to their agents, unlike more traditional real estate firms.

Problem

Our client was already using Kashoo but was manually copying data from one system to the other, wasting a lot of time in the process.  We provided the tools to let them automate imports and exports between the two systems. They had been using an extensive custom internal back-office application written on the LAMP stack which needed to be integrated with Kashoo Simple Cloud Accounting.  LAMP stands for Linux, Apache, MySQL, and PHP. Together, they provide a proven set of software for delivering high-performance web applications, and Kashoo enables you to achieve the customization you need with detailed reporting, a simple user interface, and all the functionality of an accountant without the complications from the actual accounting process. Take it as a way to simplify your accounting needs. They were hoping to transition from something complicated into something simpler to handle their accounting needs.

Solution

We provided a library to make it easy to talk to the Kashoo API.  This allowed them to build functionality into their custom back-office management system to send and receive sales data between their accounting system (Kashoo), and the back-office system.