|
|
| (23 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| '''Work in Progress'''
| |
|
| |
| ===Contact Information=== | | ===Contact Information=== |
|
| |
|
| * 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 22: |
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. |
|
| |
| ===Project Proposal===
| |
| ====Details of the proposal====
| |
| I'd like to make '''3 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.
| |
|
| |
| * 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.
| |
|
| |
| Also, if time permits - make some other '''minor changes''' too.
| |
| * 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.
| |
|
| |
| * Integrate with a continuous integration/delivery service such as [https://travis-ci.org/ Travis CI] or [http://wercker.com/ Wercker].
| |
|
| |
| I've worked with Wercker before, and they provide out-of-the-box OpenShift deployment too. Once the tests are rock solid, this will be very helpful. Each time a commit is pushed to any branch, it is sent to Wercker and the tests are run (results are displayed within GitHub itself). There's NO way someone else or we ourselves, could break the application.
| |
|
| |
| * Create a live demo that is in sync with the master branch.
| |
|
| |
| I had a discussion with Sarup about this, and I agree with his idea to first work towards v0.1, and then focus on the live demo. If we do integrate a CI service as mentioned above, this should be extremely easy.
| |
|
| |
| * Make GlitterGallery contributor-friendly from a beginner's point of view.
| |
|
| |
| 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. Also, I'd like to define a concrete development workflow - preferably based on the GitHub flow. This will be helpful for beginners trying to submit a PR, and also prevents other's commits from polluting our codebase.
| |
|
| |
| ====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 (May 19 - June 6)'''
| |
| * Work on authentication methods.
| |
|
| |
| '''Iteration 2 (June 6 - June 24)'''
| |
| * Work on the issue tracker.
| |
|
| |
| '''Iteration 3 (June 24 - July 12)'''
| |
| * Work on the social features.
| |
|
| |
| '''Iteration 4 & 5 (July 12 - August 17)'''
| |
| * Work on the additional changes/improvements that I've mentioned in the project proposal.
| |
|
| |
|
| ===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 Test Driven Development. 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=== |
| ===My Weaknesses===
| | [https://fedoraproject.org/wiki/GSOC_2014/Student_Application_rohitpaulk/GlitterGallery Backend Improvements to Glitter Gallery] |
| * 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.
| |
