-
Notifications
You must be signed in to change notification settings - Fork 6
2017 Ideas
This page hosts the ideas for Google Summer of Code 2017! You can add your ideas and improve others. If you're a student, perhaps something on this list will interest you!
You can discuss the ideas posted here in our mailing list mailing list. Don't hesitate to send your original ideas as well!
Here's some ideas to get you started:
Currently Rails always lazily compiles your views, so if you have erb or html templates, those don't get turned to Ruby until a request comes in.
When a request comes in, we look for a template to be rendered and then we look to see whether or not a template has been turned into Ruby. If a template isn't compiled, we compile it on the spot. If it is, we cache it and get it from the cache on subsequent requests.
For this to work, though, we have to lock on threaded web servers, like Puma, because it may lead to a race condition. This is also a problem for forking servers, like Unicorn, because we're wasting memory.
We would want to be able to compile the templates in advance, so we don't have to lock the threaded servers on every request. This will also reduce the memory usage on forking servers.
Mentors: Aaron Patterson
Skills: Ruby, Rack
We would like to have a long running Ruby and Rails set of benchmarks. For a very long time Python has had the PyPy Speed Center and recently golang has added its own Go Performance Dashboard.
Writing fast software requires data. We need to know right away when our framework or platform is getting slower or faster. This information can be fed directly to the team informing them of big wins and losses. Often small changes can lead to unexpected gains or losses.
Finding out about regressions months in to the development cycle can often incur a massive cost, fixing bugs early on is cheap. Usually the longer we wait the more expensive it is to fix. We have already launched RubyBench.org but need more time to polish and refine it.
Read Sam Saffron's blog post and vist RubyBench community site for previous discussions.
- Allow certain members to run "git bisect" like operation for a custom benchmark script
- Automatically detect performance regressions in our rails benchmarks and report back to the rails team
- Work on improving micro and macro Rails benchmarks
- Improve RubyBench architecture to allow for very simple backfilling of benchmarks, create an admin UI for RubyBench so we can track how stuff is progressing, what is running and where?
Mentors: Jon Moss, Prathamesh Sonpatki.
Skills: Ruby, Docker, RoR, Linux
Rails' Cookie System is due for a refresh. We'd like to be able to expire cookies and give them a purpose. This way cookies won't last forever and trying to use a cookie for something it wasn't meant for will fail. Here's an example of what we'd like to move towards: https://github.com/rails/globalid/blob/master/lib/global_id/signed_global_id.rb. Take note of the purpose and expires_in features for example.
To better be able to make this integration we need to refactor the cookie internals. Currently it's tough to change the internal cookie format because it's homegrown.
https://github.com/rails/rails/pull/28132 lays the foundation for AEAD cookies that allows us to add purpose and expiry.
This project should also focus on backwards compatibility, no apps should upgrade and find their cookies are unreadable. There's already an example of a legacy cookie format integration in the code.
If there's leftover time we can pick up other low hanging security concerns from this RailsConf talk.
Mentors: Kasper Timm Hansen
Skills: Ruby, HTTP protocols, basic cryptography and some experience with developing Rails applications.
Rails 5 cuts down a big part of our test suite matrix by only supporting Ruby 2.2, 2.3 and 2.4. That sped-up test runs, but we can still make the suite better and faster.
In your proposal give suggestions for how to improve the test suite speed. Areas you can look into include parallelizing the tests, running only tests related to changes as well as general speed improvements.
The goal of the project is to make open source contributions easier. We want Travis to shorten the time it takes to see if something broke in a new Pull Request.
A first step at this has been done during the Google Summer of Code 2015 through the ttnt project but this never got integrated into Rails' repository. Your proposal could include ideas to ease integration and use of this tool.
Example of improvements:
- https://github.com/rails/rails/pull/16985
- https://github.com/travis-ci/travis-ci/issues/2801
- http://tenderlovemaking.com/2015/02/13/predicting-test-failues.html
Mentors: Robin Dupret
Skills: Ruby, Minitest, Travis-ci
If nothing on this list interests you, you can always propose your own. Drop an email to mailing list with your idea and see if any mentors would be interested in sponsoring your project.
Keep in mind that a self-directed project like this has a pretty high bar to clear – you would need to be knowledgeable/experienced enough to find the right project to work on, plus you need to be quite motivated/passionate about your project and take the lead. But if that sounds like you, we would love to have you onboard!