GoogleSummerOfCode2009/Ideas

Google Summer of Code 2009: Ideas

  1. Google Summer of Code 2009: Ideas
    1. What is an "Ideas" list?
    2. Ideas
      1. Write useful utility functionality for Agavi applications
      2. AgaviForge, an Agavi application for storing user-contributed libraries
      3. Create the Gopherus, an Agavi mailing list interface
      4. Augment the features of the storage subsystem
      5. Create the Chuckwalla, an Agavi IRC interface
      6. Scaffolding module (with runtime inspection of ORM frameworks, not with …
      7. Improve Agavi Debug Filter
      8. Implement XLIFF and TMX support for translations
      9. Agavi component interface
      10. Optimize the locale data system
      11. Port i18n subsystem to latest Unicode CLDR
      12. Create an Eclipse or NetBeans plug-in
      13. Proof of concept: Port Agavi to Python

Students interested in participating in these projects should have, in general, a very strong grasp of PHP as well as object-oriented concepts and a knowledge of common design patterns (e.g., factories, the Model-View-Controller paradigm), although this is not strictly necessary. We're looking for bright, insightful students who are able to quickly catch on to new concepts as well as apply their own experiences and knowledge to the task at hand. A desire to learn in addition to code (brilliantly) is a necessity.

What is an "Ideas" list?

(From the  Google Summer of Code FAQ:) An "Ideas" list should be a list of suggested student projects. This list is meant to introduce contributors to your project's needs and to provide inspiration to would-be student applicants. It is useful to classify each idea as specifically as possible, e.g. "must know Python" or "easier project; good for a student with more limited experience with C++." If your organization plans to provide an application template, it would be good to include it on your Ideas list.

Keep in mind that your Ideas list should be a starting point for student applications; we've heard from past mentoring organization participants that some of their best student projects are those that greatly expanded on a proposed idea or were blue-sky proposals not mentioned on the Ideas list at all.

Ideas

These ideas are ordered generally by difficulty. Priority (relative to the progress of the Agavi Project) and time requirements are also provided, although it should be stressed that we want to see all of these ideas implemented, so students shouldn't use these as determining factors. We also highly encourage students to come up with ideas of their own and propose them!

Write useful utility functionality for Agavi applications

  • Difficulty: (Varies)
  • Priority: Medium
  • Time requirements: (Varies)
  • Requirements:
    • Knowledge of object-oriented programming
    • Experience with PHP
  • Description: People have asked for a lot of specific functionality to be available in Agavi. This project is a very general one; simply pick a few things that you think the framework could benefit by having and start writing code to support them. This could be in the form of a filter, a module, an extension to the project configuration system, a component (see below), or even a core feature. Figure out what Agavi needs and add it!
  • See also:

AgaviForge, an Agavi application for storing user-contributed libraries

  • Difficulty: Easy
  • Priority: High
  • Time requirements: Medium
  • Requirements:
    • Basic knowledge of object-oriented programming
    • Experience with PHP
    • Understanding of the functionality of a user-centric community
  • Description: This is an excellent introductory-level project. A student interested in learning about or working with the inner workings of a MVC or ORM framework without directly modifying the core would benefit greatly from this idea, which involves creating a complete Web application for other Agavi users to contribute Agavi-compatible libraries and modules. The application will involve a user management system with role-based permissions, a method for uploading created libraries, an auditing process (such as voting), and other basic community features. Could, for instance, use CouchDB as the database to allow transparent versioning. Should not be a fully-blown SourceForge, of course, but rather a repository for smaller components.
  • See also:

Create the Gopherus, an Agavi mailing list interface

  • Difficulty: Easy
  • Priority: Medium to low
  • Time requirements: Medium
  • Requirements:
    • Basic knowledge of object-oriented programming
    • Experience with PHP
    • Basic understanding of e-mail and mailing lists
  • Description: Another great introductory-level project. Agavi uses mailman as its mailing list software; the interface to this system is relatively simplistic. This project involves creating a system (written as an Agavi application) that can search, archive, and tag conversations that take place on mailing lists by implementing a cohesive, easy-to-use interface. One focus of the project should be to make sure that the interface is as flexible as possible (e.g., so that other mailing list software could be used with it in the future). A student working on this project might want to collaborate with the student working on the Chuckwalla (see below) to create the basic interface.
  • See also:

Augment the features of the storage subsystem

  • Difficulty: Relatively easy
  • Priority: Medium to high
  • Time requirements: Medium to low
  • Requirements:
    • Knowledge of PHP
    • At least basic understanding of object-oriented programming
    • Knowledge of some datastores
  • Description: Agavi 1.1 will include a highly flexible storage subsystem that allows users to store and retrieve data from arbitrary sources. This project will involve making the storage subsystem much more complete by adding any necessary internal features and also by adding support for lots and lots of additional storage systems. This might include DBMSes, memcache, APC, Amazon Web services, CouchDB, and basically anything else the student can think of that can store data.
  • See also:

Create the Chuckwalla, an Agavi IRC interface

  • Difficulty: Relatively easy
  • Priority: Medium
  • Time requirements: Medium to high
  • Requirements:
    • Knowledge of PHP
    • Basic knowledge of object-oriented programming
    • Knowledge of or interest in the IRC protocol
  • Description: This is an excellent introductory project for students interested in learning about how MVC architecture can apply to multiple environments. The student will create an IRC bot (using Agavi) that will interact with users on configured IRC channels, as well as provide a Web interface that allows for tagging, searching, and archiving IRC conversations. Some of the base libraries for this have already been written, but the student should feel free to write his or her own as well. A student working on this project might want to collaborate with the student working on the Gopherus (see above) to create the basic interface.
  • See also:

Scaffolding module (with runtime inspection of ORM frameworks, not with generators)

  • Difficulty: Relatively easy
  • Priority: Medium to low
  • Time requirements: Medium to high
  • Requirements:
    • Knowledge of PHP
    • At least basic understanding of object-oriented programming
  • Description: This is a great introductory project for students looking to learn about practical development with MVC and ORM frameworks. The student will build an Agavi module that can execute CRUD operations using a PHP ORM of choice. This project is less complex than the others and requires little or no core modifications to Agavi; a student interested in exploring MVC or ORM frameworks with no prior experience might consider this idea, as it would serve as an excellent introduction to either.
  • See also:

Improve Agavi Debug Filter

  • Difficulty: Easy to medium
  • Priority: Low to medium
  • Time requirements: Low to medium
  • Requirements:
    • Knowledge of object-oriented programming
    • Experience with PHP
    • Good knowledge of client-side scripting (optional)
  • Background: Agavi Debug Tools (ADT) (currently an independent project) includes a debugging filter which gathers debug data from Agavi core during action execution. The filter itself is abstract and the output is rendered by specialized implementations of the filter. Currently two such implementations exist, FirePHP and HTML rendering filters.
  • Description: This project will involve improving ADT debug filter by adding more loggers (i.e., logging more Agavi internals), making the logger more configurable (both design and runtime), improving current rendering methods and possibly even adding new renderers. HTML rendering will be redesigned completely to be done on the client-side so this part of the project requires mastering of client-side scripting. Part of this project is also composing ideas for the future of Agavi's internal logging.
  • See also:

Implement XLIFF and TMX support for translations

Agavi component interface

  • Difficulty: Relatively hard
  • Priority: High
  • Time requirements: High
  • Requirements:
    • Knowledge of object-oriented design
    • Knowledge of general framework design
    • A creative mind
  • Description: This project involves creating a method for packaging independent third-party libraries that are designed to work with Agavi and require hooks into a running Agavi application. Applications should equally be able to interact with the installed library. This project is best suited for a student familiar with object-oriented design and general framework design. There is a great deal of creativity involved in this idea, as the implementation is completely open at the moment and no constraints have been placed on how the libraries should behave. The student will be responsible for designing a system that is flexible, interoperable, and usable.

Optimize the locale data system

  • Difficulty: Hard
  • Priority: Medium
  • Time requirements: Medium to high
  • Requirements:
    • Knowledge of PHP
    • At least basic understanding of object-oriented programming
  • Description: Currently, any locale data from the Unicode CLDR project is compiled just-in-time when the locale is accessed, by using the Agavi configuration system to compile the CLDR data file (in Unicode LDML format, an XML dialect) to PHP. This is problematic in two ways: it abuses the configuration system for something non-configuration related, and it doesn't allow us to split up the locale data into many files, which would enable lazy loading of locale data, potentially offering massive speed-ups. The objective of this project would be to implement such a system, where the CLDR data is moved to somewhere in the etc/ folder (similar to the timezone data), and a Phing task is used to compile the data to PHP files. This would also give noticeable speed boosts for i18n-enabled applications with debug mode enabled.
  • See also:

Port i18n subsystem to latest Unicode CLDR

  • Difficulty: Hard
  • Priority: High
  • Time requirements: Medium to high
  • Requirements:
    • Knowledge of object-oriented programming in PHP
    • Knowledge of design patterns, including MVC
    • Good understanding of software i18n
    • Understanding of CLDR and LDML
  • Description: Right now, we're using CLDR 1.4 data. CLDR 1.5 has changed structures in some aspects, and probably will require certain changes to AgaviTranslationManager, among others. Also, there is the possibility that corner cases of the LDML specification are not yet implemented or not implemented correctly. CLDR 1.7 is scheduled for a summer release, so it might be worth considering going straight for that one instead. Unfortunately, CLDR and LDML have no proper change logs, so it's difficult to spot changes across versions.
  • See also:

Create an Eclipse or NetBeans plug-in

  • Difficulty: Hard
  • Priority: Medium
  • Time requirements: Medium to high
  • Requirements:
    • Knowledge of object-oriented programming in PHP
    • Knowledge of Java and Java programming paradigms
    • Knowledge of design patterns
  • Description: This idea involves creating an Eclipse or NetBeans plug-in to manage Agavi projects. Typical tasks that might be implemented by this include code generation from templates, refactoring (including renaming and deleting), configuration generation, and debugging support. Students interested in this project should already have a strong grasp of Java and PHP and understand basic MVC architecture.
  • See also:

Proof of concept: Port Agavi to Python

  • Difficulty: Hard
  • Priority: Very low
  • Time requirements: High
  • Requirements:
    • Knowledge of object-oriented programming in PHP
    • Knowledge of programming in Python, and how to take advantage of its functional and object-oriented features fully
    • Knowledge of design patterns, including MVC
  • Description: This is a fun project that has the potential to bring the power of Agavi to a completely new audience. It involves porting some of the fundamental components of Agavi to the Python programming language. Specifically, this might include:
    • The execution subsystem (including ExecutionContainers and Filters)
    • The view and rendering subsystem
    • Model handling
    • The storage subsystem

It might further involve rewriting some components of Agavi to be more Pythonic, such as the configuration subsystem and the project configuration system (the set of scripts that generate and modify Agavi projects). The student will have a lot of flexibility in this regard; we're interested in seeing whether Agavi-specific paradigms work well in other programming environments! Note that this project could be applied also to other programming languages, like Ruby or Java, depending on the student's experience and intentions.