|
|
| (12 intermediate revisions by the same user not shown) |
| Line 2: |
Line 2: |
|
| |
|
| * Name: Rohit Paul Kuruvilla | | * Name: Rohit Paul Kuruvilla |
| * Email Address: rohitpaulk AT fedoraproject DOT org | | * Email Address: rohitpaulk AT fedoraproject DOT org , rohitkuruvilla AT yahoo DOT co DOT in |
| * Telephone: +91-9501499829 | | * Telephone: +91-9501499829 |
| * GitHub: https://github.com/rohitpaulk | | * GitHub: https://github.com/rohitpaulk |
| Line 20: |
Line 20: |
| ===Will you continue contributing/ supporting the Fedora project after the GSoC 2014 program?=== | | ===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. | | 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?=== | | ===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'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 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'm a firm believer in 100% test coverage. I learnt this the hard way when working on a project. |
| * 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'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 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. | | * I play well with other people and enjoy what I do. |
| | | ===Link to proposal=== |
| ===Project Proposal===
| | [https://fedoraproject.org/wiki/GSOC_2014/Student_Application_rohitpaulk/GlitterGallery Backend Improvements to Glitter Gallery] |
| ====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 [https://github.com/mojombo/grit Grit] to [https://github.com/libgit2/rugged 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 [https://travis-ci.org/ Travis CI] or [http://wercker.com/ 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 [https://github.com/plataformatec/devise Devise] gem, and the corresponding omniauth gems for [https://github.com/intridea/omniauth-openid OpenID], [https://github.com/mkdynamic/omniauth-facebook Facebook], [https://github.com/zquestz/omniauth-google-oauth2 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 [https://github.com/mojombo/grit Grit] gem with [https://github.com/libgit2/rugged 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, description, status, and will belong to both a project and a user)
| |
| * Create an index controller and view for a project's issues, and controllers to show, edit and delete a single issue.
| |
| * Allow issues to be created from comments. This can be implemented with a "Mark as Issue" option in a comment form.
| |
| | |
| '''Iteration 4 - Social Features (July 12 - July 30)'''
| |
| * Add the option for a project to be made public.
| |
| * Add a stars attribute to a project, and display alongside the project.
| |
| * Create a public gallery page, and allow the user to sort projects according to various factors such as the number of stars, Last updated time, and creation date.
| |
| | |
| '''Iteration 5 - Improving Contributor Experience (July 30 - August 17)'''
| |
| * Integrate with a continuous integration/delivery service such as [https://travis-ci.org/ Travis CI] or [http://wercker.com/ Wercker] and setup GitHub hooks that notify the author of a commit if the build fails due to their commit.
| |
| * Define a development workflow, and add documentation for the same in the wiki.
| |
| * Populate the wiki with information and references for beginners.
| |
| * Add wiki pages that explain the purpose, implementation and usage of all existing features.
| |
| | |
| ===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 [http://rohitpaulk.wordpress.com/2013/06/02/domain-lead-generator-intro/ 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 [http://textrent.in website] for a small textbook-rental service that me and my roommate run in our college, and then created one other [http://rechargery.com 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.
| |
