Experience with GSoC-2016

Project Overview

Systers has many volunteers that offer their skills, time and commitment to accomplish their vision- Women in Computing. The community has implemented a Volunteer Management System to manage their volunteer contact information, track hours and events they worked, and provide reporting functionality at the least.

Django 1.3 introduced class-based views and also added a range of generic class-based views. From then, function-based views have been marked as deprecated. Most of the function-based views in the Systers VMS portal violates DRY.  Class-based generic views helps to streamline common use cases, saving development time and effort.

Accomplishments

• Migration of all applications in VMS from FBV to CBV

Challenges

• Cope up with the timeline which broke in between
• Correcting test case failures for each application

Take Aways

• Working with wonderful mentors
• Understanding Python-Django deeply
• Working in a great community

Experience with GSoC-2016

Being an organization that motivates women into computing, Systers- Anita Borg Institute was a great exposure for learning. The community always encourages new ideas and suggestions from everyone.

My journey with Systers was an awesome experience. Though I couldn't do to their expectation level, I enjoyed the work with them. I started contributing to Systers by small bug fixes and enhancements. I had a good bond with the community. Since I was familiar with Python-Django framework, it was easy for me to understand the code base. Understanding the code, I proposed the migration of Volunteer Management System(VMS) from function based views to class based views.

During GSoC period

The work was divided into modules - migration of each app. We were two girls working on VMS. Myself concentrated on migration while the other girl was on testing. We had weekly meeting with the mentors and weekly report submission. All the completed task and roadblocks are discussed in the meeting. The meetings were so systematic and the discussions were fruitful.

In between, I had a break in timeline due to unexpected change of locations. There was a long lag in the timeline because of improper planning. I had to leave some enhancements undone due to  time constraints. The complete migration of VMS is completed by deadline with the constant support of mentors. I owe them a lot for the continuous support.

Why Systers and VMS

I see that women, who are into technical field is few, and Systers provide a great platform for women in computing.

The community has always been so active with instant replies on Slack channel and showed keen interest in solving issues. So when I thought of doing a GSoC project with Systers, it just felt right.

Having worked in Python-Django projects, I found it easy to understand the VMS code. Small bug fixes I did in VMS, helped me to work in VMS more easily. I will definitely continue working with the community and contribute my maximum for the betterment of VMS.

My learning

More than technical stuff, my experience with the community is my learning. Talking to mentors, fighting with the timeline, writing blog posts, evaluations, goodies etc. It helped a lot to improve myself.

The frequent roadblock I came across is test case failures. I had a troublesome time solving the issues. All together it was a nice time working with the team.

My suggestion for VMS

The user interface can be made better using attractive themes and templates. It should be little more user friendly such that a new user should be able to navigate easily without any confusions.

To next year mentees

• My failures are my lessons. As I said I had a bad time following the timeline due to some unexpected things happened. Plan your time effectively such that no unexpected changes affect the flow of your work.
• Use mailing list effectively
• Talk to your mentors regularly. They can help you a lot in many ways.
• Document your things in parallel with your work
• Update the weekly reports without fail

About mentors

Just a single word about them - Awesome

Thank you Tapasweni Pathak and Nida Shar for your constant support and encouragement.

References of work

Wiki Page

Vote of thanks

GSoC 2016 was a great experience and learning. My project was migration of Volunteer Management System from existing Function based views to Class based views. Considering various advantages of shifting to CBV, I proposed the migration for all the apps in VMS to be a Google Summer of Code 2016 project.

In this post, I would like to tell about my motivation for doing GSoC with Systers, and how I got in with the team!

To start with, I thank the FOSS club of our University,  FOSS@Amrita, which helped me all the way from day one. It is a student community at Amrita University that encourage, support and mentor students to improve their technical and social skills through contributing to Open Source. We had 10 selects from our college for GSoC 2016, which shows the strength and determination of our team. As a result, Amrita University, Amritapuri Campus was ranked tenth in the total number of GSoC selections for this round, and the whole credit goes to the team.

In the club, we not-only sit and code, but take part in various activities like hosting conferences, conducting workshops for school and college students, hackathons and all kind of stuff. The exposures and opportunities that one can get here is unlimited. I cannot end this post without mentioning some names who supported and motivated me throughout the project.

Tony Thomas who was a trigger and a reason for me to start with Python-Django.

Tapasweni Pathak, Nida Sahar- wonderful mentors I could ever get

and some of the club mentors and well wishers, like:

Br. Biju Kumar, who gave me my first python-django project and a lab to work upon

Mr. Vipin Pavithran, who guides the FOSS club students with Mr. Bithin Alangot

Though I couldn’t perform as expected due to unexpected change of locations, they really supported me knowing my situation. They were so understanding and supportive. I thank everyone for the guidance and support they have given.

Two views inside one

It was some thing new for me- implementing two views inside one. In the administrator app in VMS, I used two views for report generation: one to display the form and other one to list the volunteer details. The following is the sample code that use single view that calls another two views.

class ShowReportListView(LoginRequiredMixin, ListView):
    template_name = "administrator/report.html"    
    organization_list = get_organizations_ordered_by_name()
    event_list = get_events_ordered_by_name()
    job_list = get_jobs_ordered_by_title()

    def post(self, request, *args, **kwargs):
        report_list = get_administrator_report(
            self.request.POST['first_name'],
            self.request.POST['last_name'],
            self.request.POST['organization'],
            self.request.POST['event_name'],
            self.request.POST['job_name'],
            self.request.POST['start_date'],
            self.request.POST['end_date'],
        )
        organization = self.request.POST['organization']
        event_name = self.request.POST['event_name']
        total_hours = calculate_total_report_hours(report_list)
        return render(request, 'administrator/report.html',
                      {'report_list': report_list, 
                      'total_hours': total_hours, 
                      'notification': True,
                      'organization_list': self.organization_list,                         
                      'selected_organization': organization,
                      'event_list': self.event_list,                                      
                      'selected_event': event_name, 
                      'job_list': self.job_list})

class GenerateReportView(LoginRequiredMixin, View):

    def get(self, request, *args, **kwargs):
        view = ShowFormView.as_view()
        return view(request, *args,**kwargs)

    def post(self, request, *args, **kwargs):
        view = ShowReportListView.as_view()

GenerateReportView calls ShowFormView that displays the form and ShowReportListView that list the volunteers.

Django's authentication system

Django's authentication system can serve the most common needs like handling wide range of tasks, implementation of passwords and permissions etc.

My second module of the GSoC project is the migration of authentication app to class based views. Authentication app used function based view for login and logout process earlier which was bit lengthy. The following was the function based view used for authentication purpose earlier.

auhentication/views.py

from authentication.forms import AuthenticationForm
from django.contrib.auth import authenticate, login, logout
from django.contrib.auth.decorators import login_required, user_passes_test
from django.core.urlresolvers import reverse
from django.http import HttpResponse, HttpResponseRedirect
from django.shortcuts import render

def index(request):
    return HttpResponse("Hello world")
    
def login_process(request):

    if request.method == 'POST':

        authentication_form = AuthenticationForm(request.POST)

        if authentication_form.is_valid():
            username = request.POST.get('username')
            password = request.POST.get('password')

            user = authenticate(username=username, password=password)

            if user:
                if user.is_active:
                    login(request, user)
                    return HttpResponseRedirect(reverse('home:index'))
                else:
                    return HttpResponse("Your account is disabled.")
            else:
                return render(request, 'authentication/login.html', {'authentication_form' : authentication_form, 'is_invalid_credentials' : True,})
        else:
            return render(request, 'authentication/login.html', {'authentication_form' : authentication_form,})
    else:
        return render(request, 'authentication/login.html', {'is_invalid_credentials' : False,})

@login_requireddef logout_process(request):

    logout(request)
    return HttpResponseRedirect(reverse('home:index')

authentication/urls.py

from django.conf.urls import patterns, url
from authentication import views

urlpatterns = patterns('',
    url(r'^$', views.index, name='index'),
    url(r'^login/$', views.login_process, name='login_process'),
    url(r'^logout/$', views.logout_process, name='logout_process'),
)

It can be written in a simpler way using Django's built in auth views. The rewritten code for authentication is as follows.

Create a views.py in vms

vms/views.py

from django.shortcuts import redirect
from django.views.generic.edit import FormView
from django.core.mail import send_mail
from django.core.mail.message import BadHeaderError
from django.http.response import HttpResponse

from vms import settings

def anonymous_required(func):
    def as_view(request, *args, **kwargs):
        redirect_to = kwargs.get('next', settings.LOGIN_REDIRECT_URL )
        if request.user.is_authenticated():
            return redirect(redirect_to)
        response = func(request, *args, **kwargs)
        return response
    return as_view

anonymous_required is the conventional decorator that allows the programmer to restrict access to some views only to logged in users

vms/urls.py

from django.conf.urls import patterns, include, url
from django.contrib import admin
from django.views.generic import TemplateView
#from importlib._bootstrap import _NamespaceLoaderfrom vms.views import anonymous_required
from django.contrib.auth.decorators import login_required
import registration.views as views
from django.contrib.auth import views as auth_views

#admin.autodiscover()
urlpatterns = patterns('',
    url(r'^portal', TemplateView.as_view(template_name='home/home.html'),name='home'),
    url(r'^login/$',
        anonymous_required(auth_views.login),
        {'template_name': 'authentication/login.html'},
        name='login_process'),
    url(r'^user/logout/$',
        auth_views.logout,
        {'template_name': 'home/home.html'},
        name='logout_process'),
)


Assuming that you are done setting up built-in Django user authentication, add this in your settings.py. NOTE: 'home' here is the URL of the homepage. It will redirect the user to homepage once he is logged in. It is up to you what to replace it with.


vms/settings.py

LOGIN_URL = reverse_lazy('auth:user_login')
LOGIN_REDIRECT_URL = 'home'

Migrating Volunteer Management System to Class based views- [GSoC-16 Project]

Volunteer Management System
Systers has many volunteers that offer their skills, time and commitment to accomplish their vision- Women in Computing. The community has implemented a Volunteer Management System to manage their volunteer contact information, track hours and events they worked, and provide reporting functionality at the least.
Django 1.3 introduced class-based views and also added a range of generic class-based views. From then, function-based views have been marked as deprecated. Most of the function-based views in the Systers VMS portal violates DRY.  Class-based generic views helps to streamline common use cases, saving development time and effort.

Migrating FBV to CBV

A view is a callable which takes a request and returns a response. This can be more than just a function in Django. Class-based views allows to structure our views and reuse code by harnessing inheritance and mixins.

One of the advantages of CBV is Inheritance. For instance, large projects like VMS has a lot of redundant code due the repetition of similar views. By migrating to CBV, views could be inherited and thus avoid code redundancy.

Few advantages, which VMS can achieve by migrating to Django’s class based views are :

1. Django offers various generic views like CreateView, UpdateView, FormView, ListView and DetailView to handle views easily. For eg: Allow users to Create, Update and Delete events and shifts of volunteers with or without authorization, without violating DRY.

2. Better code readability, reducing the number of lines of code, easing the code review process.
3. Replacing the decorators by mixins instead, makes them more flexible, extensible and DRYer, just like the move from FBVs to CBVs.  
4. Better handling of form data, which is handled in a traditional way in FBVs.
5. Better support from the Django development community as the recent developments are CBV based.