Techmion Logistics: Advanced Logistics Management Application for a Shipping Company

Techmion Logistics was the first-ever large-scale project I worked on. Till now, I have worked only on small-scale projects. I had never used any framework before this; I never had to. But, with this new project, I would be a fool to not leverage the heavenly powers of an MVC (model–view–controller) framework. So, I choose Laravel – a free, open-source PHP web framework, intended for the development of web applications following the MVC architectural pattern.

Now, let us dive into the project.

1. The Problem

Our team was approached by a Shipping Company with a request. They mentioned that they were already using a Logistics Management System for their day to day activities. According to our potential client the software served its purpose. But , it was slow. Not just slow it was quite buggy too. And with this statement, the only thought that came to my mind was – which software isn’t?

“Truth be told software’s can be buggy. They can be slow too. But, buggy and slow software lose money. They defeat the very purpose they were built for – to save money.”

A shipping company at its very core is a business. Businesses have one big responsibility and that is to earn money! A slow and buggy software was leaking time. And with time they lost money. Tiny trickles of time, over time, became an ocean. They wanted a plumber for their problem and therefore we were summoned with a request.

1.1 The Request

The company had one simple request – build us a software which will be indistinguishable in appearance, yet superior in functionality. The request was quite justified. They had trained their staff members over the years to use the software. Now, they cannot train them again with new software and forfeit their valuable time. We understood their predicament. We understood their request. We said yes! Yes, we will build you a software which will be indistinguishable in appearance, yet superior in functionality.

2. Developer Assignment

Now the problem was shared and the request was made. It was time for the company to assign a developer to this project. Do an in-depth analysis and decide whether to pursue the project or not.

Our company is a startup and with any startup, every member gets a lion share of work. We have one title but multiple roles. So, I was both the CTO and the self-proclaimed Lead Developer of the company. I liked the project and I was looking for something challenging. So, I volunteered to take up the project. And thus, I got assigned to it.

3. The Project

Since I volunteered to do the project. It was now my responsibility to make it work. The very first thing I did was that I made a visit to the client. This was the visit where the client will meet the person assigned to the project. He will share his requirements to the developer (me) and the developer will clear any doubts; should they arise.

So, now the client started explaining his exact requirements and I listened to it like a 90’s TV show detective. I took out my diary and started scribbling every bit of information I thought was valuable. Everything boiled down to one simple requirement (no more a request) – build the software such that it will be indistinguishable in appearance, yet superior in functionality.

Now, to do this I needed to know how the company operates. How their current software looks and function! What is missing? What could improve? Surely, this was not bad software, it just needed proper support. Frequent breakdowns were its major concern.

Till now I had never worked on a large scale project. I had my reservations. If I fail; our company’s name could be tarnished. What if I fail? Won’t that be devastating! My degree of an engineer will lose its worth. I will be a failure. My only solace in this inferno of self-doubt was this – only those who dared to get lost were truly found. I needed to be found. I need to do exactly what I expect of others and hence I shall do it. And most important; If I succeed, won’t that be glorious for our company?

4. Planning

Every big project needs to be studied and planned ahead. Going into the dark without a torch is not an act of bravery, instead of an act of foolishness. Projects are the same. Planning ahead saves time and guarantees success. Hence, I started planning.

4.1. Case Study

I started studying their old software by grouping each individual feature(component) and started making small diagrams of their data flow structure. I would break big features into subgroups with each component doing one essential function. Eventually, within a week, I could narrow down each individual component. With each component in place, I could visualise how the database would look like. Every step needed to be carefully accessed.

I also made special notes of the features which were slow. Slow features are red flags. Each red flag is coupled with a question “why” and a solution “what if”. Why was it slow? And what if I try this to make it faster? Special care was required to identify and eliminate red flags in the new software.

4.2. Database

A project can only succeed if the plan was solid. With features identified, I quickly moved onto designing the database. Initially, the database was a mess, but with 3-4 revisions it started making sense. It was time to update the client on our progress and get some feedback. We (Me and our C.F.O. Vedant Kumar) visited our client again. Every feature was discussed in-depth. With realtime inputs by our client, I could identify which features were the most essential, where delays couldn’t be tolerated. Based on the discussion, the design of the database was modified to make it flexible. Making a database flexible for scalability can be a tedious task. I definitely wanted to avoid this. But, I thank my stars every day that I didn’t. A well planned and flexible database is a boon when it comes to implementing new features and services. I understood its importance much later in the project when I had to build additional features.

Since I was yet to decide on a framework for my project the entire database was built using PHPMyAdmin. If I had chosen Laravel sooner I would have definitely gone with Eloquent ORM. It would have saved me a ton of time. A good lesson for me. With the database in place, I could practically visualise the project in my head. I could close my eyes and see each tiny component doing its part, achieving the ultimate goal of driving the big machine forward.

4.3. Process Flow

I had the database ready. I had an idea of how its individual components will be running. I could even visualise them as part of a big machine. I just wasn’t sure about the correct process flow. The best way to understand it is to act as an employee of the shipping company. When a new customer comes, what is the list of things the employee does? In what order? And most important; using which component? I spoke to the client again and they were happy enough to explain the entirety of it. I also learnt about the process flow of their transportation and various other important features relevant to their office work.

Again, like a good detective, I took notes. Later, I took my marker and connected each and every component with directional arrows like in a flowchart. Everything made sense now. I had the “big picture”. I had separate process flows for customers, employees, owners and transportation. Finally, the time came for me to develop this software.

5. Development

With a plan in place, I was now confident that I could do this project. Not just complete it but actually making it a better version of its predecessor. Planning helps to keep the “big picture” within my sight. As long as I don’t lose it, I will be fine.

5.1. Hello World

Development can never start without the good old “Hello World”. I went through the official Laravel documentation and started the server for the very first time. It was a good start. At least, now I knew that my machine will support Laravel.

My next aim was to integrate a theme in a modular approach. Integrating themes in a modular approach is basically dividing up its individual component into sections. Sections could be reused easily and helps in saving time. The modular approach also helps my views (the part which the user see) to have a readymade palate for additional customisations. I integrated one of the most trusted themes in the market – AdminLTE. A great tutorial by Aigars Silkalns titled “Integrate AdminLTE with Laravel 5” helped me to achieve the same. Please note that this is a time-consuming process and I no longer use this approach. Instead, I use this great package developed by jeroennotenEasy AdminLTE integration with Laravel.

Integration of theme was done and in the process, I also learnt about routes. Now, the next challenge was to build a login system. Laravel already came with an authentication feature but I needed a method which could support role-based authentication. Roles help me segregate different features for different locations. The main location became the super admin and other location became normal admins. Normal admins have access to specific functions relevant to their work while super admin has access to everything. I was initially worried about the complexity and security of the feature; if I had to build it. Furthermore, the time required to ultimately make it work. Thankfully, I didn’t have to build it myself. The beauty of using any framework is that we don’t need to re-invent the wheel again and again. I found the perfect package. Laravel Multi Auth built by Bitfumes. It’s a great tool with reliable documentation and frequent updates. My current go-to package for integrating role-based authentication in any and every application.

Between serving my first “Hello World” to integrating “Laravel Multi Auth” my actual hello world was complete. I was finally ready to start coding.

5.2. Coding

I initially planned to write about the entire coding process. How I metaphorically dug my own grave and how I climbed out of it. Well, in all honesty, Google searches leading me to Stack Overflow, Laracast and various other forums and blogs helped me to fix the bugs; bugs which I manufactured myself.

I also felt that it won’t be appealing to the readers without any technical background. Therefore, I will keep this highly technical session for some other time. For now, I will just share a pictorial representation of my coding process.

via GIPHY

6. Going Live

Starting from the very first meeting with the client to the product delivery it took me approximate 45 days to complete the whole project. I designed some use cases and tested the software for next 15 days. Fixed all the bugs I encountered and introduced queues for notifications, to make the software faster.

Later on, I asked our client to test it out themselves. The company was fairly satisfied with the software and asked us to wait. Exactly 2 months later the green signal came to make the project live. Our CFO Vedant Kumar quickly integrated the company’s existing customer datasets into the new software. And within 24 hours the project was live. The customer dataset was full of duplicates and irregularities. My teammate took great care to fix them. But there was this big elephant in the room which needed to be addressed. The filtered customer list was 8000+ strong. Now imagine loading 8000+ customers when you only need 2 for the booking process. Simply put, the application will be slow as a snail. The application will defeat the very purpose for which it was built – to save time. After shamelessly avoiding the issue for two whole days, I came to my senses and introduced live search feature and let me tell you this- the snail became the cheetah.

During the first month, I got regular calls notifying me about the bugs. Mostly minor bugs. I also received lots of feature requests. The bugs were fixed in realtime and the features were being built on priority. During bug fixes, I introduced logging. A feature which should have been present from the very beginning. A log is basically a whisper by the application to the developer. Log tells the developer what it is doing and what errors it has succumbed to. It is basically the black box for developers.

Finally, I introduced another feature which simply backs up the database everyday at 1:30 AM to a backup server. I hope to write a tutorial soon for the same.

7. Conclusion

Although, I would have loved to state that I built the most perfect back-end and the front-end part was a breeze. In reality, it wasn’t the case we had to visit our client multiple times to discuss and re-evaluate the features. Multiple discussions were important. It helped shape the product. It moulded itself to the requirements of our client.

From planning to development, there were multiple meetings and demos; to make sure that we and our client were on the same page. I often took some creative liberties to add some more features which would speed up their process flow. The project went through many revisions but the end goal was constant – “build a software which will be indistinguishable in appearance, yet superior in functionality”. Our company could deliver it. It was glorious. Frankly, It wouldn’t have been possible without the support of my team members CFO Vedant Kumar and Chairman Abul Karim. This project helped me to grow both as a person and as a developer.

In the end, we could deliver a project which saved our clients time. And this time ,over time, became an ocean.

To know more about Techmion Logistics Click Here! For a FREE Demo Click Here!