-
Notifications
You must be signed in to change notification settings - Fork 6
2016 Ideas
This page hosts the ideas for Google Summer of Code 2016! 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:
Remember the first time you saw the console and you hit the TAB key to trigger autocompletion? Nope, autocompletion it never worked. We can fix that, by introducing autocompletion and focusing on a better user experience for the Web Console as a whole.
Last year we developed a prototype of a Google Chrome browser extension. This year, we make the Google Chrome one production ready and touch on Firefox and Safari support.
Another idea we can work on is debugging API requests with Web Console. We already can spawn a console anywhere in our Rails application by calling the console method. Can we use the browser extensions to display this console for API requests? How would the UI work?
Mentors: Genadi Samokovarov
Skills: Ruby, JavaScript, UX
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
Back in 2010, when Rails 3.0 one of the key features was for Unobtrusive JavaScript. Up until then you'd have to add event handlers directly on your elements like this:
<a href="/" onClick="confirm('Are you sure?');">Cancel</a>The advent of UJS changed all that - the configuration would be added using the new data-* attributes and then a driver would detect the attributes and automatically set everything up. This resulted in markup like this:
<a href="/" data-confirm="Are you sure?">Cancel</a>At the time browser support for JavaScript was a mess so we decided to implement the behavior by building on the top of libraries that smoothed out those inconsistencies. Adapters were written for the Prototype JS library, which had been the standard JS library for Rails up until that point, and for the new standard jQuery. Everyone was happy for a few years but the proliferation of different ways of bundling and installing assets has introduced complications in terms of managing the release process.
However, the past five years has given time for the browser vendors to sort out their JavaScript support and with the addition of APIs like document.querySelector and xmlHttpRequest to recent versions of Internet Explorer the opportunity exists for the UJS behaviors to be implemented in terms of native JavaScript and eliminate the dependency on jQuery. This would help in a small way to reduce the ever increasing page bloat, remove a gem from the Ruby load path and simplify our release process so we could bundle the library with Rails again like we used to bundle Prototype JS.
Mentors: Andrew White
Skills: JavaScript, HTML, an understanding of how HTTP works
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, Guo Xiang Tan.
Skills: Ruby, Docker, RoR, Linux
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!