GSoC'16 overview

summerofcode.withgoogle.com/archive/2016/projects/4901518415233024

It's been an entire month after GSoC'16 ended. I provided a GitHub link of my contributions as the final submission link. I didn't write a blog post covering my contributions. This post covers my work done during the GSoC period. It contains links to some of my posts at blog.fossasia.org. I mainly worked with the APIs and the Permissions system.

# APIs

Swagger

blog.fossasia.org/swagger

A part of the project was creating Swagger specification for our APIs. Our application was written in Flask and APIs were supposed to be written in Flask-RESTplus. The best part about RESTplus was its integration with Swagger. You could document your API Views and it would generate the specification. RESTplus provides Pluggable Resource views that can be extended for GET, POST, PUT and DELETE request handlers. It also provides decorators for documenting other details about the Resource, like response models and possible error responses.

API Error Response Models

blog.fossasia.org/errors-and-error-handlers-for-rest-api

During the initial GSoC period we spent some time on discussing how the APIs should be structured. Here's an Issue#336 of the same. Later that period I defined error response models for the APIs. Implementing them was quite easy with RESTplus.

ETag based caching for GET APIs

blog.fossasia.org/etag-based-caching-for-get-apis

This post includes implementing ETag based caching and how clients can cache responses based on the ETags.

# Permissions System

Roles and Permissions

blog.fossasia.org/organizer-server-permissions-system

Apart from the APIs I also worked a lot on the Servers Permission System. It included defining System Roles and Event Roles that could be assigned to users. The blog post covers these roles and their permissions in detail.

Shell Hacks

blog.fossasia.org/shell-hacks

A small post about some hacks I took up to increase productivity when using shell.

Permission Decorators for APIs

blog.fossasia.org/permission-decorators

If you have defined the APIs nicely, then implementing permissions becomes really easy. As I told before, Flask RESTplus provides a Resource class that has get(), post(), put(), delete() methods to deal with the different request methods. We had DAOs (Data Access Objects) defined for our database models that had create(), update() like methods defined for them. Every Resource was bound to a DAO, and fulfilling an HTTP request meant using a DAO method according to the request method.

To implement permissions, I created decorators over the DAO methods create(), read(), etc. The post is about the same.

# Real-Time user notifications

Setting up Nginx and Gunicorn for using Sockets

blog.fossasia.org/setting-up-nginx-gunicorn-and-flask-socketio

This post is about setting up environment for creating Real-Time user notifications.

Flask-SocketIO

blog.fossasia.org/flask-socketio-notifications

Implementing User notifications through WebSockets using Flask-SocketIO.

# Others

Apart from these I also worked on Tickets, mainly UI and form handling.

Multiple Tickets: UI

blog.fossasia.org/multiple-tickets-user-interface

Multiple Tickets: Backend

blog.fossasia.org/multiple-tickets-back-end

AJAX image upload

blog.fossasia.org/ajax-image-upload-at-wizard

User Notifications: DB model

blog.fossasia.org/user-notifications

GSOC 2016

I came to know about Google Summer Of Code last year. For the uninitiated, it's an annual program organized by Google to promote Open Source. Organizations that want to be a part of GSOC send proposal requests to Google, who selects potential organizations and puts out a list. Students apply by sending proposals on Open Source project ideas to these accepted organizations. An idea can either come from the student himself or by selecting one from the ideas list provided by the organization. There is a limit on the number of proposals by a student.

I wasn't able to apply last year, more or less because of my limited knowledge about Open Source. I had just started to learn git then and worked only on small web based projects. Over the year I learnt a lot. Before OSS development I had more interest in competitive programming. Couldn't continue it, after a while it really becomes monotonous, especially if you don't move over from solving basic mathematical problems to problems that require knowledge about specific concepts, like dynamic programming, graph based algorithms, etc. Knowing these concepts requires going through a lot of theory, which wasn't exactly what I like. I had more interest in web development, and had worked with the XAMPP stack. With a little knowledge about Git and GitHub I started off with Open Source.

By the end of the year, I had taken up Python as my go-to programming language and even taught myself Django. The GSOC program and timeline were announced in October, but I didn't select what organizations to work with until after December. Even then I started contributing code only after January end. By February, I had made up my mind to go with two organizations. One was CloudCV and the other was FOSSASIA.

CloudCV mainly deals with providing cloud as a service for Computer Vision. It makes it easier for researchers to, for example run their computer vision algorithm on the CloudCV platform so they don't have to setup infrastructure. They do this by providing APIs for developers to work with. So it was more about working with image processing softwares than web development. Their website was on Django. FOSSASIA on the other hand, dealt with organizing technology summits and talks promoting FOSS. It is the largest Open Source organization in Asia. Projects at FOSSASIA were mostly web based. I started contributing to both of them. By the start of March I was pretty sure I was going with FOSSASIA, being a web developer I was able to contribute more.

FOSSASIA had multiple projects under it. The one that interested me the most was the Open Event Organizer Server. FOSSASIA organizes many events each year. The server provides an interface for the organizers to enter data about the sessions and speakers for the event, and provides API endpoints to read that data. These APIs are consumed by the Open Event Web App and Android Client to display data to the users. The server's written in Python and runs on Flask. As the student application deadline came closer I started focusing more on the organizer server.

With the deadline a week away, I had prepared two proposal ideas. One was a web app with focus on Event Sessions. Here's an overview, copied straight off from my proposal:

The idea is to direct more focus towards Open Event Sessions. The current applications (both OE web app and OE android app) that handle display of Event data lack interactivity and options to share Sessions. Users cannot review sessions, sessions listed are not shareable, there is no mechanism to rate them on the basis of their performance. Moreover, sending proposals for sessions requires users to log in to the administrator site (OE Organizer Server) and then send proposals. My proposal is to create a Flask application alongside the Organization Server that lets users sign in with Social Media platforms. This will enable them to send Session Proposals and write Reviews. At the end I’ll create API endpoints to create/update/delete Session Proposals and Reviews. These APIs can then be used to provide the same functionality to Android app.

My second proposal was to improve the current server app and create API endpoints to write data to the server. This included providing bug fixes and tests for the existing server. Creating write APIs meant making the server to accept POST/PUT/DELETE requests. I had more expectations from the first proposal. I had put up a lot of time in creating that proposal, describing how the entire app would work. The second one got selected though (Not that I'm complaining, just that I saw more potential in the first one.).

The work has already begun. I've started providing bug fixes and improvements to the server. The server would be going through major changes this summer.

I'm happy I didn't select a front-end project to go with. I had worked on a lot of front-end projects the previous year and wanted a switch to back-end.

MALVO for Colosseum'16

This year has been pretty busy for now. I had been wanting to create a new platform for Lord of the Code, a college programming competition. It's held each year on Colosseum, our technical fest. The competition includes two rounds. Round one consists of MCQ challenges where each team is served with 50 questions on the language of their choice (C or Java). The finalists of the first round enter second round to solve programming challenges. There are ten questions to be solved in 2 hours of time. The job to create such a platform doesn't really look big until you begin and somehow enter the mid phase.

I had to build the entire site from scratch. For my platform I had to build both the front-end and back-end. I decided to go with Semantic-UI on front and with Django at back-end. Also I had a different idea for the implementation.

The MCQs round being the first round always had a lot of participants. It consisted of 50 MCQs that had to be solved within one hour. The MCQs on their site were served one for every request. So if you solved MCQ one (/mcq/1) you would then be directed to MCQ two (/mcq/2), and this goes on for other 48 MCQs. The server had to bear a lot of load. My idea was to send the MCQs at the client all at once. The team would then solve all the problems and upload all the answers once. Basically a single page application. The second round had fewer teams than the first one, so challenges were served at requests (/challege/<no>), no new stuff there. Plus it would have been more complex for an SPA because of the varying number of input test cases and therefore varying form fields.

I wanted the site to be neat. Semantic-UI looked great when I implemented it in templates. I also put up markdown support for question text and syntax highlighting for code (Yup! previous site didn't have syntax highlighting for code). MD support was provided by Showdownjs and highlighting by HighlightJS. Both are awesome libraries.

On a side note, I did not know you could download a custom package for HighlightJS depending on your language choices. Since the only two languages we were concerned with were C and Java, I didn't have to download the entire default HighlightJS library. I could download a custom package that supports only C and Java. Noice!

This project was pretty big, considering I had to create all models/views/templates from scratch. It was the biggest project by me in terms of lines of code (>6000), and I was happy that I completed it before the event date. Unfortunately, the organizers didn't use it for the MCQ round and decided to go with the older platform.

The Older software has been in use for more than three years.

They let me setup the site for the second round though. It worked great and didn't have any issues. Although watching it work as expected in the MCQ round would have been great. Anyways, I'll be setting up the site for the next competition, Code Connoisseur'16, which will be in August I think. I might even join the society and be a part of the organizing team. Why I didn't join it before? that would start another story.

Here's the source for the project: malvo. I'll be creating a Docker image so deployment becomes easier. But that's for some other day... probably.

Some edits were made to the post...

:VimKnight

Ah, you think vimL is your ally?
You merely adopted vim. I was born in it, molded by it.
Didn't see fancy IDE until I was already a ninja, by then
it was nothing to me but INSERT mode.