GSoC Chronicles — Only Time will Tell

The first phase of Google Summer of Code, i.e. the community bonding period started off with discussion with my mentor(Amit Kumar) on the changes that had to be made to my proposal — things that had to be added, things that had to be removed and the things that had to be changed, both in terms of time and the exact goals to be achieved.

You can find the original version of my proposal here. The detailed plan, especially changes and the relevant discussion on why we thought that these were necessary are highlighted below.

Majorly, we finalized on four important things in addition to the original proposal.

Firstly, the objectives of the first couple of weeks needed to be clearly stated and agreed upon. We decided on the following three key points:

1. Initializing Logger: We decided on creating a custom logger in order to implement logging for the entire project to facilitate better debugging. This would be done by creating a logging module in the repository with a custom logger class that will inherit from python’s inbuilt logger and override its methods like debug, info, warn, error and others as required. Further, objects of this class can then be called in different places and making use of the extra customization that inheriting the logging module provides we can customize under which circumstance to display what message.
2. Make the existing code PEP-8 compliant: We decided to use flake8 to enforce style consistency across the project. In addition to the default lint checks that come along with it which include the PyCodeStyle project, PyFlakes project, and McCabe complexity check, I have decided to also use pep-8 naming as an added extension to this in order to check for naming conventions.
3. Unit Testing: Test cases need to be written for as many modules as possible. As of now, the tests are absolutely essential for three files, models.py, main_api.py, and views.py. It is worth noting that the way the code is structured, writing test cases for views.py completely covers the code in main_api.py since all methods inside main_api.py have been called inside views.py.
4. With test cases written and a pep-8 compliant codebase, we will be able to put tools like Travis and Coveralls to use and avoid manual testing that was otherwise wasting a lot of developer time.
5. Refactoring Code: This is a broad thing and we agreed to do this as and when the need arises throughout the next 12 weeks. However, some issues that were already on our radar needed to be addressed. One such issue was the separation of deep learning model calls from Django, This will not just increase the modularity of code but will also help make testing the code easier. Another issue was making the code as consistent as possible, especially in terms of the output that it was returning. As of now, it returns a string to the user for some APIs and dictionaries in other cases. We decided that dictionaries are going to be the default return type and in case of errors or exceptions the dictionary will have Error as a key with the error message as the value. Further, error handling has to be made more extensive than what it currently is by adding try-catch blocks in various places, catching more specific exceptions and handling them properly. Also, all constants in the coreapi module need to be moved into a separate constant.py file.

Secondly, it was decided that the work on training the deep learning models and deploying them will be done asynchronously as opposed to what I have mentioned in my timeline. This makes a lot of sense as I will have a lot of free time in hand while training the models and this free time can be better utilized towards achieving other goals such as deploying the already existing models. So, the basic idea is that when I will be deploying the model for Scene Text Detection, then I will be training the model for Scene Text Recognition. Similarly, when I will be deploying the model for Scene Text Recognition, then I will be training the model for object detection. And so on.

Finally, we realized that the above strategy can buy us some extra time and we may be able to achieve three extended goals for this summer:

1. Deploying what we have done so far at the end of GSoC online and testing it on production for speed, scale, and accuracy.
2. Another brilliant idea that came up while brainstorming was that for every use case we can train two models, a lightweight model focusing on speed to be used for CPUs with less computing power in addition to the already existing full model which would focus on accuracy.
3. Converting the repository to a pip package and shipping it as python3 pip module. Since the last step of my idea is containerizing the entire application. This, will eventually pave the way and make it quite easy to ship the repository as a pip module as well.

These are definitely beyond the scope of the current proposal but something I will definitely try to achieve in the coming few weeks. We realize that these three things might seem a bit far fetched for now, given that the project is still in its infancy. But it is also worth highlighting that Amit and I are pretty much committed to making this project successful and would definitely not hesitate in going the extra mile to make it a big hit.

Oh! And also with the help of one of my friends Deepak, we have the first version of PMR’s logo.

Please be gentle. It’s still in the idea phase and will keep on evolving.

How will this logo and this project eventually pan out — Only Time will Tell:)