Skip to content

Ideas

guilleiguaran edited this page · 36 revisions

Google Summer of Code 2013

This page hosts the ideas for Google Summer of Code 2013! 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:

REST actions for resource collections

The introduction of REST revolutionised the web development world accustomed to heavyweight protocols like XML-RPC and SOAP. Whilst Ruby on Rails has good support for fetching collections and managing individual members there is no built-in support for the creation, modification and deletion of collections. Therefore it's left up to the application developer to add ad-hoc support using existing APIs.

With the increasing use of Ruby on Rails as a backend to mobile apps, single page JavaScript applications, etc. adding built-in support for bulk operations is an important requirement and Ruby on Rails should include it as part of the resource routing/scaffold generation features.

Mentors: TBC
Skills: Ruby, HTTP protocols - experience with the Rails REST implementation useful, but not required.

Replace HTML sanitization with Loofah

Ruby on Rails relies on the venerable html-scanner library for sanitizing HTML and over the years has been susceptible on more than one occasion to security flaws. To help protect applications it'd be good to switch to the more modern Loofah library which uses the Nokogiri library for parsing rather than regular expressions.

Mentors: Rafael Mendonça França
Skills: Ruby, HTML, JavaScript, Web Security (XSS, etc)

Refactor application configuration and initialization

Currently the configuration of a Ruby on Rails application is not clearly delineated from the application initialization which makes it difficult to work with different environments within each other. For example running rake test boots the application within the test environment, so to test something within the development environment you need to launch a second process. This is partly due to the application being a singleton and partly that the framework configuration are class variables.

It would be good to clean this up so different environments can be used within each other and there is already some ongoing work to remove the limitation of the application being a singleton. Developing this further would help simplify and speed up application testing.

Mentors: TBC
Skills: Ruby and some experience with developing RoR applications.

Split out Action View from Action Pack

Increasingly Ruby on Rails is used as an API-only backend for mobile apps, single page JavaScript applications, etc. To provide an optimised stack for this the Rails::API project was created, however it still includes Action View because it is part of the Action Pack gem. It would be helpful to split out Action View into a separate gem so that it can be left out for API applications and allow it to be used in non-HTTP request context like background jobs.

Mentors: Guillermo Iguaran, Santiago Pastorino
Skills: Ruby and some experience with developing RoR applications.

Refactor Ruby on Rails URL generation and recognition

Ruby on Rails 3.0 introduced a new DSL for defining application routes and as part of that the URL recognition and generation was split off into a separate gem called Rack::Mount with the intention of it being a generic router for Rack-based applications. This never really took off and as part of the 3.2 upgrade Ruby on Rails switched to a new router called Journey which has been re-integrated into the Action Pack framework as part of the upcoming 4.0 release.

As a result of this process there are a lot of abstractions and inefficiencies which can be eliminated now there's no need to maintain generic API for Rack applications. Some specific examples are:

  • The Routing DSL needs to know what keys are in the path so it can build the defaults and requirements hashes used to add a route. It does this by parsing the path but this path is then parsed again when the route is added.

  • The route class doesn't know about controllers and actions so the Routing DSL must normalize all these as part of the process of adding a route. It would be sensible to make the route class more aware of the routing conventions so that at lot of the normalization code can be simplified.

  • Because of the need for a simple API for Rack::Mount the router doesn't know whether a route represents a resource or not. This is useful information which could be used to fix long-standing problems like generating polymorphic urls with singular resources.

  • The internal implementation of the Routing DSL uses an hash to maintain the current scope whilst evaluating the routes.rb file - this makes the DSL code hard to maintain and test. If it's refactored so that classes represent the different types of scope it would simplify the implementation and make it easier to test.

This would be a good project for a student wanting to learn about re-factoring a large, complicated codebase whilst maintaining backward compatibility.

Mentors: Andrew White
Skills: Ruby, HTTP protocols, Web servers and some experience with developing RoR applications.

Add a web-based console

One of the most-compelling features of Ruby on Rails when it was first released was its console that allowed direct interaction with the application. It would be useful to extend this ability to a browser to aid development and testing in situations where direct shell access isn't available. Check the rack-webconsole and rails-web-console as starting points for this project.

Mentors: Guillermo Iguaran
Skills: Ruby, HTTP protocols, HTML, JavaScript and some experience with developing RoR applications.

Conductor: web-based assistant for development

Conductor is a Web-UI for assisting in the development of rails apps. We want to edit code, run tests, run generators, manage databases and gems, show annotations and statistics and read documentation using it. Check the sidebar of conductor in this screenshot to see a quick list of the components that we want to enable.

DHH's conductor gem can be used as starting point for this idea. The idea has been explored also by Akira Matsuda with the hocus_pocus gem.

Mentors: Guillermo Iguaran
Skills: Ruby, HTTP protocols, HTML, JavaScript and some experience with developing RoR applications.

Refactor controller/functional and integration tests

One of the most common misunderstandings amongst new Ruby on Rails developers is the difference between controller/functional tests and integration tests. Functional tests are like unit tests for controllers and don't generate a proper request - they merely mock the request based upon the test arguments. This means that features implemented as Rack middleware generally don't work in functional tests leading to lots of mistaken bug reports.

To ease this confusion it'd be helpful to make functional tests behave like integration tests but to do this would require performance improvements to the integration test code as they are approximately 25% slower than functional tests.

Mentors: Andrew White
Skills: Ruby, Test::Unit/MiniTest and some experience with developing RoR applications.

Add support for view classes

A common complaint of working with Action View is the 'big bag of methods' and the way that instance variables are passed from the controller to the view. One solution to this is to create view classes that can contain logic and data without polluting the global helper namespace. There are no real constraints on any solution other than it needs to work with the traditional method of Ruby on Rails view development.

Sidenote: Cells gem offers similar functionality, so it is worth looking into.

Mentors: Nick Sutterer
Skills: Ruby and some experience with developing RoR applications.

Improve security of ActiveRecord

We are looking permanently for ways to improve the security of ActiveRecord, some examples of ideas that can be implemented to do this are:

  • Typecast ActiveRecord conditions to the type of the column (e.g. Foo.where(:token=>1) => SELECT * FROM foos WHERE token = '1'.)
  • Remove all support for nested hashes in the conditions APIs. (e.g. Foo.where(:bars=>{:foo=>'1'}) raises an ArgumentError)
  • Change the default serializer to use JSON not YAML by default.

Mentors: TBC
Skills: Ruby, SQL, Web Security and some experience with developing RoR applications

Something went wrong with that request. Please try again.