GSOC 2014/Student Application rohitpaulk

Contact Information

• Name: Rohit Paul Kuruvilla
• Email Address: rohitpaulk AT fedoraproject DOT org
• Telephone: +91-9501499829
• GitHub: https://github.com/rohitpaulk
• Blog URL: http://rohitpaulk.wordpress.com
• Freenode IRC Nick: rohitpaulk

Why Fedora

The main reason behind me choosing Fedora, is GlitterGallery (the project I'd like to work on). Also, I'm a fan of free and open source software, and Fedora is an excellent example of the same!

Do you have any past involvement with the Fedora project or with any another open source project as a contributor (if possible please add some references as well)?

• I've been contributing to GlitterGallery. Up till now, my contributions have primarily been cleaning up code, writing tests, fixing small bugs, updating to Rails 4, and enforcing best practices wherever possible. I've also started a branch with a new design, and am collecting feedback on the same.
• I have made minor contributions to the documentation for various open source projects such as Ruby on Rails and ExpressJS.

Did you participate with the past GSoC programs, if so which years, which organizations?

No.

Will you continue contributing/ supporting the Fedora project after the GSoC 2014 program?

Yes. I've been contributing before the GSoC period, and will continue the same during and after.

Why should we choose you over the other applicants?

• I've pushed a few commits to GlitterGallery already, and I'm familiar with the codebase.
• I'm well versed with Git, and understand the power and importance of Version Control.
• I'm a firm believer in 100% test coverage. I learnt this the hard way when working on a project.(More in the About me section)
• I've been working with Ruby on Rails for almost 2 years now. I've watched and understood every single RailsCast on railscasts.com (the free ones).
• I am familiar with front-end development. Very strong in HTML/CSS, not so much in Javascript.
• I play well with other people and enjoy what I do.

Project Proposal

Details of the proposal

I'd like to make 5 major changes/improvements to GlitterGallery. These also serve as the final deliverables at the end of the coding period.

• Support multiple means of authentication (currently only OpenID is supported) as proposed by Emily in Issue #56 (https://github.com/glittergallery/GlitterGallery/issues/56).

I gather from the commit history that devise was used earlier on in the project, but scrapped later (couldn't find a reason anywhere yet). However, I feel that devise can cater to this need pretty well. Also, as Emily mentioned, I'll keep an option for the administrator to change the allowed authentication methods.

• Change from Grit to Rugged.

Grit is no longer actively developed, and although there is no current use case in GlitterGallery where Grit fails, it surely could happen in the future.

• Create an issue tracker. (Something on the lines of Github's issue tracker)

Though the basic idea is the same as GitHub's issue tracker, as Sarup suggested - It'd be good to have the option of creating an issue by just commenting, instead of having to go to an issues page and create one. This could be implemented as a 'mark as issue' checkbox when creating a comment.

• Incorporate social features - including but not limited to - a public project gallery, a stars/rating/voting feature.

Each project will have an option of being made public, and a stars attribute. Public projects will appear in the public gallery, and the stars rating will be displayed along with it. Projects in the public gallery will be sortable by either stars, or creation date.

• Improve the contributor experience.

The current documentation is indeed quite good (Thanks to Sarup Banskota's work) and has everything that a seasoned developer needs, but it can be made more beginner friendly. The first step would be to define a concrete development workflow. I'd also like to integrate with a continuous integration/delivery service such as Travis CI or Wercker and create a live demo that is in sync with the master branch.

Final deliverables of the proposal at the end of the period

Mentioned in project proposal(above).

A rough timeline for your progress

I'm going to split the whole coding period into 5 iterations, roughly 18 days each. Each iteration will again be split into 3 parts.

• 5 days - Implement a basic functional prototype (Need not be user friendly, only criterion is that I can make the feature do what it's supposed to do.)
• 8 days - Write concrete tests, refactor along the way.
• 5 days - Focus on user friendliness. Answer some basic questions such as - "Is the purpose of this feature evident to a new user?"

Before coding period

• Write tests for the existing code (I'm already working on this)
• Refactor along the way
• Fix any small bugs already listed on GitHub, and raise issues for any others that I find.
• Discuss with my mentor(s) about the implementation details and suggested improvements.

Iteration 1 - Authentication Methods (May 19 - June 6)

• Install the Devise gem, and the corresponding omniauth gems for OpenID, Facebook, Google etc.
• If needed, alter the Users model.
• Add corresponding choices in the login page. i.e. "Sign in with Facebook", "Sign in with Google" etc.
• Provide an option for the administrator to choose the allowed authentication strategies.

Iteration 2 - Grit to Rugged (June 6 - June 24)

• Replace the Grit gem with Rugged
• Move over all the existing code to Rugged, and improve upon the code if necessary.
• Confirm 100% test coverage.

Iteration 3 - Issue Tracker (June 24 - July 12)

• Create an Issue model. (An issue will contain a title, a description and will belong to both a project and a user)
• Allow issues to be created from comments. This can be implemented with a "Mark as Issue" option in a comment form.

Iteration 4 - (July 12 - ??? August 17)

• Work on the additional changes/improvements that I've mentioned in the project proposal.

My Weaknesses

• In general, design is not a very strong point of mine. For example, I'm bad at colors. Whenever I've had to work on the front-end of a website, the first thing I'd do is copy a color scheme off some good-looking website. I can recreate something using HTML/CSS/JS with pixel to pixel perfection, but when it comes to making something on my own - it ends up looking a bit 'out-of-place'. I'm more of a front-end developer, than a front-end designer.
• I'm not from a CS background. I have taken a data structures elective at college, but some complex algorithms and implementations just go way over my head. Currently, I don't see the need of anything that complex in GlitterGallery though.
• I'm not an active blogger. Blogging about my GSoC activities would be a perfect way to improve this.

About Me

I'm currently pursuing a bachelor's degree in Mechanical Engineering at IIT Ropar, Punjab, India. My interest in coding and web development started in my second semester.(2 years ago)

I was working as a sales intern for a company that deals in domain names, and my job was pretty repetitive. Everyday, I had to go through 100 pages of google search results, do around 200 WHOIS queries, and then tabulate all that info in an excel sheet, and import into an email application. Two days in, I thought of automating the process. I started learning a bit of web scraping with python, and within a week or two, I had the whole process in a python script. I thought of sharing this with my colleagues, but none of them used Linux and it would be hard to teach them to run scripts and what not. So I created a simple web interface for my 'script' with the Flask framework. People liked it, and this program of mine was used by that company for 3 months until they moved on to a different strategy to find customers. I've blogged about the same on my blog.

Now that I knew a bit of web development, the curiosity kicked in, and I started watching a lot of screencasts and read up about web frameworks. I completed a few courses on Udacity and Coursera. I learnt a bit of front-end development and how to make a website look *cool*. I did a lot experimenting with server side frameworks such as Django, Rails, ExpressJS, Sinatra etc. I started to contribute back to open source projects in the form of documentation, and took part in a few web hacking competitions and hackathons. One of these was a hackathon arranged by Google in our college related to Dart. We (me and a friend) developed a movie recommendation app using angularJS. (We're still polishing the code and will put the app up on GitHub soon)

In my 4th and 5th semesters, I created a website for a small textbook-rental service that me and my roommate run in our college, and then created one other shopping-related website along with a junior of mine. The latter was built with Ruby on Rails. This is when me and him started to understand the benefit of Version control and tests. With version control - we could do the craziest of experiments, and come back to our stable codebase with just one command. With tests - We no longer had to fear breaking a small feature of our app here and there when pushing a commit. We hosted our code on BitBucket just so that we could create issues and pull requests and discuss/comment on each of them.

And... here I am. I would love to be able to say that I made a significant contribution to GlitterGallery over the summer.