Google summer of code - Bundler Index
66 views
Skip to first unread message
Felipe Tanus
Mar 10, 2015, 5:11:17 PM3/10/15
to ruby-b...@googlegroups.com
Hi there,
I'll be applying to GSOC following the bundler index project idea. This e-mail is a short intro from myself and what I'll be proposing. The main idea behind sending one e-mail instead of only applying in the day is because here you can ask whatever you want and also I can gather ideas/feedback to the project.
About me: I'm Brazilian, currently doing a masters on ufrgs which some say is one of the best university on Brazil. Here universities are a bit different: you have 4.5 years of undergrad course, 2 years of master and 4 for a phd. I participated on gsoc 2010, 11 and 12, all evaluated as a success. 2012 was my last year as undergrad, so I couldn't participate any longer, but now I'm back to masters. I'm working 2h a day right now, but by the time that gsoc start, I'll be not working any longer working.
I'm the right person to work on this project because every time my pythonic girlfriend works with ruby she tells me bundler is slow. I tired of complains, so I decided to apply to this idea.
Related links:
About the project: I read the blog posts and took a look in the existing code. I understood the problem and how the fix will work. I have little knowledge of how bundler/rubygems works internaly. So, let me start with a question: Should the new index code be included on bundler API or use a new web app for it? Here is an image with both suggestions (and how I pictured it working right now - if is not the case, please let me know!)
I assume that having the index in a separated webapp is better because then we can scale it by moving to other server or something. So, the mainlines of my proposal in chronological order of implementation are:
1) Write tests for what exists on bundler/new-index gem, and hopefully find a bug or two.
2) write a new gem new-index-client, which will abstract the calls to this new api. This will be included in bundler later.
3) Create a simple web application (maybe using puma, like bundler-api?) that interfaces the new-index. (OR: merge the new index on bundler api)
4) Add the new-index-client on bundler, and make it use the new index
5) Add http byte range support to the calls, as suggested by indirect@github
Do you guys think I should add/remove/change something? It is feasible in the development time (3 months)? I'm all ears!
Regards,
Felipe
I'll be applying to GSOC following the bundler index project idea. This e-mail is a short intro from myself and what I'll be proposing. The main idea behind sending one e-mail instead of only applying in the day is because here you can ask whatever you want and also I can gather ideas/feedback to the project.
About me: I'm Brazilian, currently doing a masters on ufrgs which some say is one of the best university on Brazil. Here universities are a bit different: you have 4.5 years of undergrad course, 2 years of master and 4 for a phd. I participated on gsoc 2010, 11 and 12, all evaluated as a success. 2012 was my last year as undergrad, so I couldn't participate any longer, but now I'm back to masters. I'm working 2h a day right now, but by the time that gsoc start, I'll be not working any longer working.
I'm the right person to work on this project because every time my pythonic girlfriend works with ruby she tells me bundler is slow. I tired of complains, so I decided to apply to this idea.
Related links:
About the project: I read the blog posts and took a look in the existing code. I understood the problem and how the fix will work. I have little knowledge of how bundler/rubygems works internaly. So, let me start with a question: Should the new index code be included on bundler API or use a new web app for it? Here is an image with both suggestions (and how I pictured it working right now - if is not the case, please let me know!)
I assume that having the index in a separated webapp is better because then we can scale it by moving to other server or something. So, the mainlines of my proposal in chronological order of implementation are:
1) Write tests for what exists on bundler/new-index gem, and hopefully find a bug or two.
2) write a new gem new-index-client, which will abstract the calls to this new api. This will be included in bundler later.
3) Create a simple web application (maybe using puma, like bundler-api?) that interfaces the new-index. (OR: merge the new index on bundler api)
4) Add the new-index-client on bundler, and make it use the new index
5) Add http byte range support to the calls, as suggested by indirect@github
Do you guys think I should add/remove/change something? It is feasible in the development time (3 months)? I'm all ears!
Regards,
Felipe
Reply all
Reply to author
Forward
0 new messages