Introduction

I have been experimenting with Deep Learning models in PyTorch for a couple of weeks now. PyTorch is an open source python package that provides Tensor computation (similar to numpy) with GPU support. The dataset used for this particular blog post does no justice to the real-life usage of PyTorch for image classification. However, it serves as a general idea of how Transfer Learning can be used for more complicated image classification. Transfer learning, in a nutshell, is reusing a model developed for some other classification task, for your classification purposes. The dataset was created by scraping images from google image search.

Creating the dataset

For our dataset, we need images of birds, planes, and Superman. We will be using the icrawler package to download the images from google image search.

We repeat the same for birds and Superman. Once all the files have been downloaded, we will restructure the folders to contain our training, testing and validating samples. I am allocating 70% for training, 20% for validating and 10% for testing.

Loading the data

PyTorch uses generators to read the data. Since datasets are usually large, it makes sense to not load everything in memory. Let's import useful libraries that we will be using for classification.

Now that we have imported useful libraries, we need to augment and normalize the images. Torchvision transforms is used to augment the training data with random scaling, rotations, mirroring and cropping. We do not need to rotate or flip our testing and validating sets. The data for each set will also be loaded with Torchivision's DataLoader and ImageFolder.

Let us visualize a few training images to understand the data augmentation.

Loading a pre-trained model

We will be using Densenet for our purposes.

The pre-trained model's classifier takes 1920 features as input. We need to be consistent with that. However, the output feature for our case is 3 (bird, plane, and Superman).

Now, let's create our classifier and replace the model's classifier.

We are using ReLU activation function with random dropouts with a probability of 20% in the hidden layers. For the output layer, we are using LogSoftmax.

Training Criterion, Optimizer, and Decay

Model Training and Testing

Let us calculate the accuracy of the model without training it first.

The accuracy is pretty low at this time, which is expected. The cuda parameter here is the boolean object passed for the availability of GPU hardware in the machine.

Let us train the model.

Since GPU is supported, the training took around 10 mins. The validation accuracy is almost 99%. Let us check the accuracy over training data again.

Image Preprocessing

We declare a few functions to preprocess images and pass on the trained model.

Predicting by passing an image

Since our model is ready and we have built functions that allows us to visualize, let us try it out on one of the sample images.

So, that is it.

It's a Bird... It's a Plane... It's Superman

Hello World,

When Tootle started, there were four of us. At the time, we were working on EdCrayon (Three60’s Education and Classroom Management System). The development of EdCrayon was pretty much complete and one of the better schools in town had been implementing it for a year. We were busy with building fewer last minute requirements such as Nepalese school standard digital report cards and student ranking systems. After those were done and the academic session ended, we were preparing for the next academic session and we were also in talks with several schools for implementation of EdCrayon.

EdCrayon

However, because of earthquake of 2015, the school that were lined up decided to back out and use their EdCrayon allocated resources on repairing the infrastructure damages. We would come to work and not feel productive at all. Due to the sheer boredom at work, we started researching on several ideas including location based services. One of the very first ideas was to create an app that would allow users to track location of Sajha buses on Google Maps so that they could plan on leaving offices/homes by referencing estimated time of arrival provided by the app. Even though Sajha buses were comparatively convenient, the problem was that people had to wait for the buses, generally up to half an hour,  since bus stops arrival timings were more or less random.  We developed the prototype for a Sajha bus route but since Sajha bus did not show any interest we decided to move on to other ideas.

Sabaiko Sajha (Prototype)

Meanwhile, I was researching on asynchronous API calls for a pet project of mine. I had been trying to figure out the best way to sync client’s on-device offline database and off-device master database. In this process, one of the first things that I did was to look into creating my own implementation by syncing Android SQLite database with MySQL database. Up until this point, when ever client sync was required, I would simply clear out the content adapter’s list, remove all elements, get all elements from master server and refill the adapter. This allowed for easy implementation. However, even if nothing was changed in the client database, whenever the client hit the sync button or pulled to refresh, the process would get repeated. Basically the question I was trying to answer was,
“Is it faster and less expensive to individually assess for updates by comparing updated_date and id or to simply truncate and refill?” During the research for this, I stumbled upon newer technologies that would allow setting up changes listeners on client’s devices to refresh the changed list without having to trigger an action to sync the data. Using this finding and our research from location based services, we felt comfortable tackling the idea for a ride sharing application from a technological perspective, and Tootle was born.

Tootle was not Tootle from the very beginning. We continued our research on appropriate Business Models, Brand Positioning, Business Strategy, and Marketing and Delivery. Based on the changes in how we were going to position our brand in the market, we changed the product name from CabIO (digital cabs), KAR.ma (share your ride for karma), Bzuli (environmentally conscious ride sharing) and finally to Tootle (a fun way to travel without restricting the service to electric vehicles and only four wheeled vehicles). In the meantime, based on the Business Models and Brand Positioning, several elements of the app were also changed.

Bzuli and CabIO (Prototypes)

Although the concept of ride sharing is not new, and several companies such as Uber, Lyft, Ola and Go-Jek have implemented it tremendously well, Tootle is different mainly due to three core elements. First of all, we let our partners decide if they want to take a ride, i.e, we introduced the idea of casual Tootle partners. For example, a partner A can decide to give rides throughout the day and make this his/her full time job or simply give rides that matches his/her travel itinerary. The technology is adjusted in such a way that a tootle ride requests are sent to several partners within a vicinity rather than just one partner. Unlike aforementioned companies, there are no penalties involved for not taking a ride. Secondly, albeit not completely by choice, we have realized that frugality invites creativity. At every step of technology development, we have had to strategize inexpensive yet effective ways to solve problems. Although we are still purely in development phase as of today, I believe we can really take pride in what we have accomplished given the resources. This is also reflective in the product. We were forced to think about minimizing data consumption (given the high data cost in Nepal) and poor internet infrastructure. Currently, on average, a particular ride for a partner in terms of data exhausts 1 MB while him/her being able to log in, select appropriate ride, complete the ride and get paid, while the backend collects ride information such as timestamps for actions and exact route followed. This costs him/her 50 Paisa which is approximately $0.005. Finally, last but not the least, the major difference comes in the form of technology adaptation, contextualization and more importantly, communication. Kathmandu is traditionally more or less a close-knit community where people prefer talking to people to garner a sense of confirmation and safely. Therefore, it was crucial to build a simple and clean UI that gets the job done and focus massively on developing technologies that provided real time ride statistics to our team at call center so that they could assist people giving and taking Tootle rides. Similarly, since digitization of payment was essential but Nepal is not ready for secure and realtime credit card transaction, apart from local third party digital wallet integration we also have QR top-ups. To summarize, although from the surface, Tootle is a ride sharing application like Uber, it has established its own identity via contextualization of the requirements of Nepali needs. This is apparent throughout the technology.

Tootle Today

From our experience, we have realized that market drives technology and not the other way around. We have also realized that although technology is merely a facilitator, it can do wonders to solve problems and invoke habit changes if done correctly.  Now, we have a multidisciplinary team of 15 striving to make Tootle technologies and services better each passing day with the goal of doing it correctly.

A place of worship and serenity.

Link to Tootle Website

Tootle is a ride sharing service that matches bike riders and commuters. While the concept is not new, there are several contextualization factors that makes it unique. As research and development engineer and lead software developer, this was my biggest challenge to date and I learnt a lot of things. However, since we worked in a very small team, I occasionally came across problems related to branding, client relationship, marketing and overall B2C business model. This blog post will dive into those learnings rather than focus on technological implementations. To summarize the entire post, it is about my journey from a single dimensional software developer to a software developer who also understands project management, human resources, market, competition, branding and plethora of other factors that a software developer whose long term goal is to become a tech entrepreneur needs in their arsenal.  

Start small, www.rome.com was not built in a day

This is trivial for most people, but not for me. There were times I was so focused on completing a task that I lost the bigger picture. Breaking down a task into smaller subtasks and solving them as soundly as possible is the key. Also, when you push yourself too hard, you miss small details that might have huge consequences in the future. Think scalability while solving little problems. Like Will Smith said, "You don't set out to build a wall. You don't say 'I'm going to build the biggest, baddest, greatest wall that's ever been built.' You don't start there. You say, 'I'm going to lay this brick as perfectly as a brick can be laid. You do that every single day. And soon you have a wall." Also, Hofstadter's law will come along to shatter all your to-do plans for the day. It's just the way it is. Deal with it.

Development and design is an iterative, never ending process. It is not a sprint but a marathon.

Seeking perfectionism hurts. First of all, there is no perfect code or design. There might be something that looks, feels and works great today, but it is never going to be perfect. You will always have to come back to that line of code, redesign that slider that looked great once upon a time and continuously update based on user feedback. Coding is a little of writing code and a lot of maintaining it. You are never really done. Project preplanning and risk management might help with not having to go back to drawing board again and again, but development and design is very much an agile process.  

Hire people who love what they do and love learning

Coworkers become your second family. During the course of Tootle development, I actually spent more time with my coworkers than my family.  Fortunately, everyone involved with Tootle are very passionate, hard-working and motivated people who never shy from learning. Also, certain characteristics such as being ardent, an embodiment and advocate of the product, and hardworking are more important than being skillful. I was also on the hiring team and I made sure to look for these characteristics. After all, Leicester City won 2015-2016 Barclays Premier League primarily because of their team spirit.

Prioritize what is important

There will be a lot of bugs. Code related stuff aside, there will also be several things that need attention. However, time is limited. At times you could be in front of your computer debugging for hours and hours, but still the issue tracker list and crash reporting list will be full. Therefore it is necessary to prioritize based on impact level. Assessing impact of a particular task can be difficult. However, if you have an awesome team, it is just a matter of discussing from a business and technical point of view. Also distinguishing between bugs, enhancement, improvement proposal and task is very important.

Communication solves 95% of all problems

Communication is the key. Often during the day, talk to coworkers about the problems that you are having. First of all, when you explain the problem to someone, you understand the problem better yourself. Secondly, you are also in sync with what problems everyone else is facing. Similarly, simply talking about work related problems, expressing how you feel about deadlines, doing risk analysis together, discussing business strategy together, communicating dissatisfactions etc. will help solve a lot of problems earlier. So, constantly take a break, look outside the window, get a glass of water and simply talk.

Stress can be a catalyst if applied properly

This project was very much stressful. Retrospectively, it was supposed to be too because of its complexity. One of the things I really struggled with is handling stress. I have gotten better over the course of this project. However, I am still working on learning to change stress to a catalyst. I hope to become Arsene Wenger someday (giggles). However, I have learnt that if things don't work tonight, you simply have to sleep over it. The freshness of morning solves a lot of problems.

You could also just watch SRK dance in Hosh na khud kahi josh.... 

Go running in the morning, be healthy

This one is self-explanatory. Run to remain stress free and healthy. I stopped running for a while because I was lazy. But, I was also lazy because I was not running.

Competition is good

While reading The Personal MBA by Josh Kaufman, I realized that having market competition is actually advantageous. This concept was really counterintuitive to me previously. Competition is good because it implies higher probability of fulfillment of something known as the Iron Law of Market. It basically means that like you, other people have also seen the availability of the market you are targeting. Similarly, there is a lot to learn from your competition. Learning and applying the principles of game theory helps a lot too. 

Awesome tech implementation is second to client's requirement

You could spend weeks and months on awesome, flawless and amazing features that your clients don't really care about or half an hour on simple features that makes all the difference to them. For example, adding a bitcoin as payment system would be cool, but allowing a female client to select a female driver makes the product secure and also adds marketing and advertising weight.  

Beta tests are really really really important

You could sit hours upon hours, days upon days trying to find and fix all the problems. But, finding problems is more difficult once you know your product inside out. You are in a controlled office environment with fast internet, limited real test devices and a clear understanding of product workings. There is no way for you to find all the problems. The solution is to find real users to test, use and provide feedbacks. Canary tests and beta tests are therefore very important. 

Just because you like it, does not mean users are going to like it also

You might absolutely love your product. However, it does not mean every user will like it also. Be prepared to get bad ratings. Also, they are not wrong to dislike something you adore so much. 

Previous projects and keeping up to date with latest technologies help a lot

I really believe this one is a biggie. Regardless of whether or not a product succeeds, it is always a stepping stone for future products. This product would not have been possible or would have been terribly difficult without Edcrayon, Edquake, and dozens of other location related prototype. When prototyping, research on newer stacks and practices.  

In the end, revenue matters the most

In the words of Josh Kaufman,
Do not be a mercenary since dedication in craft, patience to find right market to be dedicated towards and consistency is required to eventually make money.

Also, do not be a crusader since you need money to pay the bills.

Wish us good luck with our tootle journey.