-
Notifications
You must be signed in to change notification settings - Fork 5
2015 Ideas
This page hosts the ideas for Google Summer of Code 2015! Add your ideas here, improve others, and if you're a student, perhaps something on this list will interest you!
You can discuss the ideas posted here or new ideas with others in our mailing list
Here's some ideas to get you started:
Some description about what this idea is about, hints about where to start. There should be enough information for a student to know what this is about, start doing their brainstorming/research, and/or getting in touch with the mentor via mailing list to plan the proposal. It should not give everything away or we will just get a lot of low-quality application consisting of "Yep, that's what I will do." ;)
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
This is probably a good upper bound length-wise!
Mentors: Pending
Skills: Ruby, HTTP protocols, ...
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.
Read the Sam Saffron's blog post about this for more details.
We have already launched http://rubybench.org but need more time to polish and refine it.
Mentors: Sam Saffron
Skills: Ruby, Docker, RoR, Linux
Active Support has a file checker that monitors files and directories via tree walk and stat calls. That's used in particular per request to monitor autoload_paths when config.cache_classes if false.
That file checker was an improvement over the previous autoloading strategy, which was to remove all autoloaded constants in each request. But in a medium-sized application this still has a cost that can be removed by using an evented approach.
This project would abstract the file checker to be able to plug backends. It would provide support for Mac OS X and Linux via their respective 3rd party gems that interface to native libraries.
End-users could optionally configure these backends and probably AS would pick the right one automatically without configuration, to easily support teams with different operating systems.
Probably, these new backends would be gems in the Rails organization rather than live in core.
Mentors: Xavier Noria
Skills: Related internal workflows in Rails, native evented file system monitors (inotify, FSEvents) and their Ruby bindings.
Currently, the default Rails stack does not provide much tools for end-to-end testing involving JavaScript. This is an important aspect of testing for almost all modern Rails applications, so we would like to ensure that we provide a good out-of-the-box experience for doing this.
There are plenty of existing projects in the Ruby/Rails ecosystem that provides this functionality, such as capybara-webkit and poltergist. Part of the project would involve improving the integration with these gems.
The other part of the project would involve finding solutions for some of the shortcomings in the default setup (for example, transactional fixtures does not work correctly in most of these test runners, various timing issues, etc).
Mentors: Pending
Skills: Experience building and testing Rails apps with JavaScript, network and multi-threaded programming.
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.
To better be able to make this integration we need to refactor the cookie internals. Give a rough suggestion of how to do this by identifying the current approach's problems and suggestions of how to move forward. The chosen student should also consider upgrade paths. We don't want users to upgrade their applications 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 cutted down a big part of the test suite matrix as we dropped some ruby versions and only support ruby 2.2. That speeded-up tests, however we can make the test suite better and faster.
There are some areas to explore that could improve the speed of tests. Such as parallelize the tests, run only portions of the test suite related to the changes made, and overall speed improvements.
The goal of the project is to make open source contributions easier, so when someone opens a Pull Requests, travis-ci would run faster, and we would know if it broke tests sooner rather than later.
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: Arthur Neves, Josh Kalderimis
Skills: Ruby, Minitest, Travis-ci