Summer of Code 2011 Project Ideas

This is an incomplete list of what various Perl project could see students doing for this year's summer of code.

If you're a student looking for a project and you don't find anything interesting to you and appropriate for your skills, be creative! Project ideas not on this page are very welcome and even encouraged.

The Perl core

use #p5p on irc.perl.org to discuss ideas with the prospective mentors

MOP(let) for core

Work on implementing a small Meta Object Protocol (MOP) for the Perl core - this would include introspection for classes, methods, and attributes. This probably also means implementing "class", "method", and "has" keywords. The MOP should simply store names and a hash ref of "additional info". This means that something like Moose could ask for an attr's name & hashref and then use that info to generate accessors and such.

This feature does not require incorporating accessor generation into the core, it's just about declaration.

Optional bonus feature: role declaration? method modifiers?

Possible mentors: Stevan Little (for design), insert core hacker here (for implementation)

Revive MAD

MAD, which stands for Miscellaneous Attribute Decoration, is a a tool to that can be used to turn Perl code into something easier to process than raw perl source code. Possible applications of it include a Perl 5 to Perl 6 translator, syntax highlighters, or converters for old dialects of Perl into newer ones without changing the behaviour of the code.

Unfortunately, MAD is currently broken. This happens regularly when some of the perl internals change and the MAD code isn't updated accordingly, mostly due to the MAD test suite not being run when running the regular perl test suite.

Properly integrating MAD into the core, my moving it from the mad/ subdirectory to lib/, and having it's test suite ran by default would fix that issue, and is part of this project.

In addition, MAD currently outputs XML and, even worse, outputs invalid XML in some cases. Using XML for MAD is problematic as there's no XML parser in the core perl distribution. Changing MAD's output format to JSON, and making the output actually valid is also part of this project.

Improve interoperability with external libraries

Improving extendability of Perl with C and C++ libraries Perl's standard mechanism for creating extensions written in C or C++, is called XS for "eXternal Subroutine". In a nutshell, the author writes some interface code in a dialect of C with additional directives. A preprocessor that also handles Perl <-> C type conversions then generates much of the C code necessary to hook into the Perl virtual machine. Unfortunately, the implementation of the preprocessor has not aged as well as the general idea. Specifically the way that authors specify how Perl data structures should be converted to C data structures (the "typemap") is rather clumsy. The task would be to design and implement a better type mapping system for use in Perl/XS. This task requires at least a good knowledge of Perl and C. Zalando Gutschein

Possible mentors: Steffen Mueller, Florian Ragwitz

Standardize core documentation tools

The standard documentation format in Perl is Pod, and it's used extensively by both the core Perl distribution and by code on the CPAN. There are two standard tools for working with Pod: Pod::Parser and Pod::Simple. Pod::Simple was written in 2002, as a reaction to the primal horror that Pod::Parser's code inspired in maintenance programmers. Despite the clear victory of Pod::Simple as the tool of choice, a number of tools in the core Perl distribution still rely on Pod::Parser. Updating them to use Pod::Simple will allow Pod::Parser to be, once and for all, deprecated and consigned to the abyss.

Possible mentor: Ricardo Signes

Documentation Re-org

Work on the hierarchical reorganization proposed by brian d foy. This includes:

• moving and renaming all the core docs into categories like "language", "tutorial", "reference", "embedding/XS", "platforms" ** should some documents be available in multiple categories (many things are arguably reference & language docs, or reference & embedding, for example)
• adjusting core tools to find them under their new names
• providing backwards compat/deprecation for old names
• making sure manpage generation still works - pod/core/syntax becomes perlcoresyntax.man?

Possible mentors: brian d foy, Dave Rolsky

Fix bugs in, or add features to, the Perl core

There's a large list of TODO entries in the perltodo documentation, although not all will be suitable as projects. They are grouped roughly in estimated order of difficulty, starting with tasks that only require Perl knowledge ahead of those which require more skills such as familiarity with C, or familiarity with C and XS. Pick one or more related items, and chat to #p5p about how you're going to resolve them. Remember that you need to complete the project successfully in 3 months if you are to receive the full payment, so proposing a project that would also require you to learn new skills from scratch is going to seriously hamper your chances of success.

Classify core libraries in preparation for cruft-purging

The core Perl distribution ships with a large collection of modules for performing common (and not so common) programming tasks. Some of these, like strict or B provide stable access to important language features. Others, like HTTP::Tiny, are used by the core CPAN tools to install third-party distributions. There is a third category, too: code that is just bundled for historical reasons, because it seemed useful at the time. For example, File::CheckTree. The code in the core should be sorted out so that unneeded distributions can be deprecated and later purged. Any "may be purged" distribution should be verified as removable: the whole core should build and test with that code removed.

Make perl faster

There are several more possibilities not listed in perltodo: Improve B::CC, fix and improve Jit, restructure the core to help [llvm] to do linker optimizations, implement core optimizations for typed arrays and hashes.

Possible mentor: Reini Urban

Toolchain Projects

CPAN Testers 2.0 client

Create a proper CPAN Testers 2.0 client. This would entail, at minimum, the following:

• extracting the functionality of CPAN::Reporter and relevant parts of CPANPLUS into a new, unified client
• providing new, pluggable transport options to replace Test::Reporter, which is too email-focused to be useful going forward. At a minimum, this must support HTTP(S) transport and raw socket transport (per Test::Reporter::Transport::Socket
• submitting reports as structured data, using the various components available in CPAN::Testers::Report instead of only plain text
• using CPAN::Testers::Config to standardize configuration, and creating a CLI user-interface for configuration www.sparcoin.de

Possible mentors: dagolden, bingos

DBIx::Class and related toolchain (irc.perl.org#dbix-class)

DBIC test suite reorganization

Currently the DBIx::Class test suite stands at more than 250 files with over 23,000 individual tests. However most of these run against the test-bundled DBD::SQLite. Moreover the tests that do run on other RDBMS share a lot of identical code which is currently copy pasted from test to test.

The proposed task is to introduce a "schema iterator" facility, which can re-run a set of tests under multiple $schema's based on the current DSNs available in the environment. As a side effect the test files can be reorganized in a more coherent t/ hierarchy. The task does not include fixing all bugs that will pop out upon completion of this project :)

DBIC documentation overhaul

The massive amount of improvements over the past couple of years left the core documentation lagging behind. Many new features were documented only in the reference pods, without updates to the CookBook, FAQ and other manual sections. Moreover the CookBook itself is becoming large and unwieldy and could use a major overhaul.

The proposed task is to reorganize the CookBook similar to how the Moose project has organized theirs, and to touch up some of the more arcane sections of the core docs (e.g. ::Relationship / ::Relationship::Base ).

The task will require (re)acquainting with the more advanced features of DBIx::Class and working with the project core devs to establish a set of current best practices for reference in Introductory documents. www.sparcoin.de

DBIx::Class::Schema::Loader Projects

DBIx::Introspector

Extract the database introspection bits from the DBIx::Class::Schema::Loader::DBI subclasses (and ::DBI itself) and create a new CPAN module, I was thinking DBIx::Introspector, but whichever name you like is fine with me. This module would then be very helpful for the work on SQL::Abstract 2 and other Perl ORMs like Fey and Rose, or for any other reason where introspecting a database would be helpful.

View Support

Schema::Loader does not yet do proper introspection of views, Results for views are generated just like for tables. Ideally, it would extract the view SQL and create proper DBIx::Class::ResultSource::View Results. Some sort of SQL introspection for the purpose of matching the keys (primary, unique) of the source table and definining them for the view would also be nice, as a bonus feature!

SQL::Abstract::Tree rewrite

Rewrite SQLA::Tree to emit/consume ASTs as per the SQLA specification. This will serve as a springboard for Data::Query implementation. The end goal is to allow for more robust and accurate SDQ/DDL parsing and interpretation.

SDL Perl / Perl Gaming - http://sdl.perl.org

You can find a list of SDL Perl project ideas here. They include things such as

• Game Engine
• Cross thread queuing for SDL_perl
• Game Physics
• and more!

use #sdl on irc.perl.org to discuss ideas with mentors.

Catalyst - http://www.catalystframework.org/

use #catalyst-dev on irc.perl.org to discuss ideas with the prospective mentors, like t0m, konobi, kd, rafl and dhoss.

• Rework component setup code to be based on Bread::Board and allow for more customisation

• Split between application instance and request context to improve reusability

• Refactor how configuration loading is done. Currently it requires the full application to be loaded, which makes it impossible to use the normal configuration tools in, for example, scripts that are supposed to spin up an application.

• Catalyst::(Action|Controller)::REST help. This module is very useful but rather unwieldy at times, especially when combined with ::DispatchType::Chained. Would be nice to see a sane API come of it that allows either a transparent layer for REST API calls or a cleanly injectable API.

Moose - http://www.iinteractive.com/moose/

use #moose-dev on irc.perl.org to discuss ideas with the prospective mentors, like Sartak, t0m, and rafl

• Make perl's overloading introspectable and modifiable using the meta object protocol. Prior art for this exists in MooseX::Role::WithOverloading, which could be ported to use the meta api for overloading, once it exists.

• Work on moving parts of the meta object protocol from perl- to c-space to improve Moose performance during both compile- and runtime. A prototype for this already exists in the Moose-XS branch.

• Work on metaclass serialisation in MooseX-Antlers. This also has a big potential for making Moose faster, by not having to compute or even load metaclasses most of the time.

• Improve MooseX::Declare and MooseX::Method::Signatures. Performance could be greatly improved by adding the possibility to inline type constraint checks to Moose and MooseX::Types::Structured. There's also many missing features and minor bugs and edge cases that need to be addressed. Get in touch with #moose-dev for the details.

KiokuDB - http://www.iinteractive.com/kiokudb/

use #kiokudb on irc.perl.org for discussion

• Implement an asyncronous interface
• Improve performance
• Pick anything from http://github.com/nothingmuch/KiokuDB/blob/master/TODO

Plack - http://plackperl.org/

use #plack on irc.perl.org for discussion

• Build a middleware that implements Edge Side Includes (ESI). That involves both a parser+interpreter for the ESI language, as well as a caching middleware. Prior art for the caching part of the problem already exists at http://github.com/rafl/plack-middleware-cache/

Mojo/Mojolicious - http://mojolicious.org/

use #mojo on irc.perl.org to discuss ideas with the author sri or other people out there

• Performance tuning the http/websocket implementation.
• Adding tests for things going wrong and adding nice error messages.
• Improving the reference documentation with small tutorials similar to Mojo::Template and Mojo::IOLoop.

Reflex and/or POE (Perl Object Environment) - http://poe.perl.org/

(Suggested mentor: Rocco Caputo, possibly others, and the communities involved are very helpful.)

• Reflex is a modern reactive library for Perl. It uses POE for asynchronous eventiness and Moose for a de facto standard OO.

  • The project needs more hands to work out the design and work on the implementation. A lot of this work might be incidental development as part of a larger project.
  • Check out the project roadmap for inspiration.
  • Use #reflex on irc.perl.org #reflex to discuss ideas with developers and the community.

• Refactor POE::Loop into a stand-alone, sessionless callback API that Reflex and other projects can use directly.

  • Something along the lines of on_input($handle, \&do_something) would be nice. Reflex and other projects would benefit greatly.
  • Use #poe on irc.perl.org to discuss ideas with developers and the community.

• SDL bindings for POE. POE developers have been approached to integrate SDL's main loop with POE. We could use a dedicated pair of hands for that. Find us in irc.perl.org #poe.

BioPerl - http://bio.perl.org

• Project List: A well-written goldmine of info for possible BioPerl projects.

Tk

• Enhance (fix?)so that it can properly display Arabic (right-to-left, with character joining and shaping)

• Statistics::RI - create a DBI-like interface to R as a replacement for Statistics::R

Perl toolchain modules

• CPAN/OS package interaction

• Improve the existing Qt4 bindings at http://code.google.com/p/perlqt4/ and make them releaseable.

• Update Symbian Perl, and possibly provide interfaces to Symbian OS features (download movies) - http://sourceforge.net/projects/symbianperl/

Padre, the Perl IDE http://padre.perlide.org/

We created a page with a number of project ideas on our own wiki. Please see them here

Bricolage, a Perl-based enterprise-class content management system http://www.bricolagecms.org

Big projects

These are projects that require a solid understanding of Perl and the other technologies mentioned, and a commitment to seeing them through. Each has a dedicated mentor to provide guidance and support to one or more students working to complete the project.

• Full text searching. Either via Solr (Mentor: Alex Krohn) or tsearch2 (Mentor: David Wheeler). Preferably, both would be implemented.

• More AJAXification of the Bricolage UI: useful keyboard shortcuts, integrated spell-check, and the like. The sky’s the limit on the ideas that could be applied here (Mentor: Matt Rolf)

• Document conversion: enable story creation by uploading a specific document type, e.g.: Open Office document, Word document, etc. (Mentor: Alex Krohn & Phillip Smith)

• Add a REST interface / API to Bricolage (Mentor: David Wheeler)

• Modernize/Simplify the Bricolage install process via a Module::Build-based installer. (Mentor: David Wheeler)

• Modify version storage to store deltas instead of complete copies. (Mentor: David Wheeler)

Medium projects

Medium-sized project are excellent for students with a intermediate understanding of the described technology (AJAX, Perl, Javascript, ASP, SQLlite, Firebird, etc.) and a willingness to learn.

• Port Bricolage from mod_perl to Plack/PSGI

• Add support for Javascript templating. Other possible templating additions are Mason 2, EmbPerl, XSLT, JSP, ASP.NET, ERb, and Cheetah. If the templating system isn’t written in Perl, you’ll be able to borrow from the work done on PHP Sandwich the project started to allow PHP templating in Bricolage. (Mentor: David Wheeler)

• Workspace improvements as described here and here (Mentor: Matt Rolf)

• Addition of event-triggered callbacks (Mentor: David Wheeler)

• Improvements to Bricolage's SOAP interface with the objective of providing access to objects, contributors, and more search parameters. (Mentor: Greg Heo)

• Creation of an API "mover" or action to allow Bricolage to more easily publish to other systems that have Web / REST APIs. (Mentor: Phillip Smith)

• Port Bricolage to SQLite and Firebird. (Mentor: David Wheeler)

Dancer

possible projects for Dancer:

• local::lib support, so a complete application could be packaged with all the dependancies
• the scaffolindg script should support upgrading from an old Dancer to new one
• redesign the way we handle multiple Dancer applications inside a single app.psgi
• streaming support (there is already an issue and some discussions about this feature
• rewrite dancer's script to provide an API for plugins to extends the default behavior

possible mentors: franck, sawyer

Rakudo Perl 6

Multiple Dispatch Optimization in Rakudo

The Rakudo Perl 6 compiler has implemented multiple dispatch for a while. This is a mechanism by which we pick a routine to call based on the types of the arguments it is being invoked with. By the Perl 6 specification, in any given lexical scope the set of multi dispatch candidates is statically known. One opportunity that arises from this is to try and statically decide some multi-dispatches at compile time. It won't always be possible - for example, we may have no clue about the argument types - but when it is possible there could be some great performance wins.

This task will probably need some initial refactorings to make implementation of the optimization easier, followed by the core work of actually implementing it. An adventurous student could then go on to explore some further optimizations that then become possible after this, such as inlining. Other static analysis could also follow on from the work, such as statically determining and telling the user at compile time that there's no way any of the available multi-dispatch candidates will match.

Suggested mentor: Jonathan Worthington

Pod parser for Rakudo

Perl 6 has a built-in documentation format named 'Pod'. Rakudo currently only recognizes the begin and end of such Pod sections, and ignores them otherwise.

A student could write a parser for Pod (or a subset of Pod), and make the parse tree available both for accessing it from withing Perl 6 objects and for redering it in other formats (plain text, html, latex, markdown, ...)

See the Pod specification in S26

Possible mentors: Moritz Lenz, Carl Masak

XML parser binding

Make a binding from Perl 6 to an XML parsing library. Make it possible to call out to the library, and to have it return with a data structure representing the parsed XML.

One possible possibility here is to have the returned data structure be in its native C form, i.e. not necessarily wrapped in Perl 6 objects. Making use of jnthn's work on representations, it would still be possible to interact with the data structure, treating it as real Perl 6 objects with attributes, methods etc. This would create a best-of-two-worlds situation, giving us the speed of C and the convenience of Perl 6.

OTRS

OPAR-Kwalitee: Show in website and new Perl::Critic policies

Currently there is just a small set of Perl::Critic policies. This set should be enhanced. Therefor one can add new policies.

This involves to study the OTRS code and define rules of "how to program in OTRS style".

The results of the package analysis should be shown on the website.

Suggested Mentor: Renée Bäcker

Visual CI map

The CMDB allows currently no overall view of alls CIs and relations you may know from a network plan. It would be nice having this implemented in OTRS ITSM. For this purpose existing tools like graphviz.org ma be used.

Suggested Mentor: Renée Bäcker

Save E-Mails as Draft

Currently it's very risky to interrupt one's work in OTRS. E-Mails not sent are easily getting lost because there's no option to save them. Therefore it needs an option to set emails to draft:

In AgentTicketCompose - next to the "send" button, there's another button "draft". The new article is stored in the data base as if it was sent, just marked as a draft. Possible states for the ticket are: new, open, pending.

New articles (like notes or other emails) can be added to the ticket as usual. The new articles are stacked behind the draft in correct order.

Drafts not sent are accessible through the navigation bar, like locked or watched tickets.

A saved draft can either be deleted (which simply removes the entry from the db) or sent. The later case deletes the 'draft' maker in the data base and resets the time stamps to current, so the former draft becomes a standard email article at the current position in the ticket.

Optional: Every queue gets access right options called 'supervise' and 'trainee' f.e.. Trainees cannot but set emails to draft. Supervisors can access and send draft tickets of all agents. This would be a really helpful feature to train new agents.

Suggested Mentor: Renée Bäcker

Semantic Web with Perl

Use #perlrdf on irc.perl.org to discuss ideas.

Larger standards-oriented projects:

• R2RML store for RDF::Trine.

Smaller coding-oriented projects:

• Use existing CPAN modules to create a comprehensive Linked Data server with derefenceable 303-URIs, dumps, SPARQL endpoint, sitemap, voiD, etc. It should also support caching and be deployable in a high-volume environment.

Miscellaneous

• A Dependency Injection container - alternative to Bread::Board. Check all the design possibilities. Maybe a more lightweight approach, or something with scopes?
  (Suggested Mentor - Maybe Stevan? He should know what alternative design paths he did not follow when writing B:B).

OpenWebMail

Create or update a translation

• Category: Translation
• Difficulty: Easy
• Duration: 2 hours to 2 days
• Mentor: openwebmail@acatysmoof.com

OpenWebMail translation is handled through PO files. PO files are very easy to work with by using the POEdit software. By following our simple instructions anyone can create a translation, or update an existing translation with very little technical know-how.

New Icon Sets

• Category: User Interface
• Difficulty: Medium
• Duration: 4 days
• Mentor: openwebmail@acatysmoof.com

We're always interested in new icon sets. You can start with the example iconset and change the icons in a paint program like Adobe Photoshop to make your own set. Adaptations of existing open source iconsets are also welcome. Images in the iconsets can be jpg, gif, or png files. You can visit our test installation to see how and where the icons are used in the interface.

HTML update

• Category: User Interface
• Difficulty: Hard
• Duration: 5 days
• Mentor: openwebmail@acatysmoof.com

Our system now supports complete separation of logic and presentation, so our layouts need updating. Our HTML is still using table based layouts. A student familiar with HTML can take our table based classic layout set with HTML::Template markup and create a new div based layout. Try one or several different areas of our interface, such as the calendar or the webdisk.

The student working on this juicer project will be provided with an area where they can upload their juicer layout for testing.

Juicer Resources

juicer reviews masticating juicer reviews Twin gear juicer reviews centrifugal juicer best citrus juicer super angel 5500 review Omega 8006 review Omega vrt350hd review Breville Masticating Juicer Juicer Blender Combo Best Stainless Steel Juicer