User Tools

Site Tools


jadcargas:jadcargas

Jad Cargas

Jad Cargas is a logistic, transportation and storage company. The internal policy of the company states that they should not trust 3rd party systems for their business but develop internal solutions to keep their strategies in secret and thus having competitive advantages over the other companies in the same market.

I was hired in March 2010 to integrate the team of internal developers to maintain current systems, change the legacy and develop new ones. I left the company July 2013.

Used technologies:

Projects

The team was a small one, and we had many systems to take care. Eventually we worked together in some of them but most part of the time we used to work by ourselves.

Transportation Tracking / Pricing System

This one was a legacy system written in PHP4. I needed to fix some bugs and develop new features in order to make the data available to other systems that would take it's place in the future.

I reproduced the exact same environment of the production server using Vagrant with Virtualbox. I've downloaded a Ubuntu 08.10 image and installed it in a new virtual machine (aka VM). On that VM I've downloaded PHP 4.3 source code, I've installed the dependencies (like mysql-dev, lib-jpeg, gd, iconv), then I compiled the PHP 4.3 source code. I also have installed MySQL, sendmail and memcached.

Once I had the same old environment in a virtual machine I could start learning how that software used to work and I could start fixing the reported bugs.

The bugs were completely related to internal rules, that were not very well described anywhere, but the users had noticed about some non conforms like: ”When I'm setting some volume as delivered for some silver client after the due time the discount should be 5% when this client had transported more than the minimum amount of the month rather than 3% as the software is currently doing

I interviewed some users in order to understand better the whole problem and see if the complaint were clear enough and if that was the problem or just some effect of another one. It worked, so in the following future complaints I used the same approach.

They had 4 types of clients, and the code was full of “ifs” to apply the specific rules of each type of client. In order to be able to apply the correct rule for those silver clients I've refactored that specific part of the code creating on class for each kind of client, CommonClient, BronzeClient, SilverClient and GoldClient all of them inheriting from the ClientType abstract class, which had the common methods for all of them.

Using that approach I reduced a lot the number of “ifs” and made very much cleaner the logic applied for each type of client. There were no automated tests at all for that system, and since that one wasn't my main task I kept that way.

These is one example of bugfix I've done to that system.

A new feature that I have implemented was a webservice that allowed other systems to have access to some data in some specific structure, different than the database and another one to trigger some actions using the legacy system.

I used the SOAP protocol on the last one and a simple json structure on the first one. Both required authentication and the token for the authenticated requests.

Package Monitoring System

This one was my main project while I worked for Jad Cargas. The clients of Jad Cargas for that project were the biggest banks in Brazil. The banks need to transport bounced checks from one bank branch to another in order to make them available to their customers.

So, there is a daily massive transportation of packs and packs of bounced checks. The Idea of this system is the monitoring/tracking and guarantee of the content of those packs.

I've been with the client on meetings, analyzing the requisites, creating the mock-ups, presenting proposal solutions and then developed the system.

How the process works?
  1. The driver goes with his assistants to get the packages at some bank branch;
  2. They take each pack of bounced checks and put a seal with a barcode;
  3. Using a barcode reader mobile device they read each barcode into the system with the collected status;
  4. When they arrived at the airport they read again with a dispatched status;
  5. The other driver gets the packages at the other airport and reads the barcodes with the delivering status;
  6. When the packages are delivered they read again as delivered status.
  7. The clients are able to keep track of their packages on a web interface almost in real time;
Infrastructure

The infra structure was already there, it was an internal data center, I just picked up the available options.

  • Specific handhelds with Windows Mobile or Windows CE with a SIM card for internet
  • Web server hardware - Intel Xeon 4GB ram with SATA hard drives in RAID 1
  • Database server hardware - Intel Dual Xeon 8GB ram with SATA hard drives in RAID 1
The system

Mobile app version 1

Since the company already had some handhelds with windows mobile, and they are quite expensive, the company wanted to use them and the chosen technology was .NET Compact Framework and I used C# as the language. For the local database I used Microsoft SQL Server Compact 3.5 for Windows Mobile.

I designed, developed and maintained the app. The developed features were:

  • Logon module for authentication on remote servers.
  • ACL rules for allowing users/drivers to see specific info about the clients were they should work with
  • Barcode format validation.
  • Expected volumes validation and alerts for the user
  • Offline storage for the moments when the user has no internet signal
  • Synchronization module, responsible for sending the data about the packs to the remote server.

Mobile app version 2

As the implementation got started and the adoption of the software was growing among the clients the cost of buying many handhelds wasn't affordable, thus a new strategic decision was made. Lets create some android version of the windows mobile app.

I designed, tested, reviewed the code the Android app, but I didn't developed it. It had the same functionality of the windows mobile version and I guided the developer under my supervision on how to proceed and what to do to achieve our needs.

The biggest difference between the two mobile apps, Windows Mobile and Android, was the synchronization system.

The Android version used a local database implementation of Apache CouchDB which is well known for it's synchronization feature with other Couch DB instances, thus that responsibility of syncing the data between the mobile device and the servers was passed to Couch DB, allowing the developers to focus on other important tasks.

But our main database wasn't Couch DB, so I needed to create a daemon application to create the sync between that Couch DB and the main database on MySQL. It may seems to be just one more point of failure to the process but it was a great solution at the end because managing the syncing between the app running on androids and our servers wasn't a trivial task, so we relied on a very powerful tool that was already doing that kind of job, Couch DB.

Web Application

The web applications were developed using TDD and/or BDD approaches.

For testing I used the gems Test Unit, RSpec and Cucumber.

For versioning control I started following the team approach by using SVN but after certain time I convinced them to switch to Git.

I built the staging and the production environment as follows:

I designed, developed and maintained the app. The developed features were:

  • Logon module to authenticate the mobile app's users.
  • We had a separated module for logon and ACL on web apps, I used that one.
  • Barcode reading (some places the users don't need to use the mobile app, they use the web interface instead)
  • Barcode format validation.
  • Expected volumes validation and alerts for the user
  • Synchronization module, responsible for receiving the data about the packs from the mobile app.
  • Several reports about the collected data being able to export in csv, xlsx and pdf formats.

The code documentation was created using RDoc the common ruby pattern.

The software documentation for the user was created for more complicated tasks using a wiki system.

jadcargas/jadcargas.txt · Last modified: 2016/03/01 19:10 (external edit)