Repoze Blog

2010-02-16 00:00:00-05:00

PyCon 2010 talk: Evolving Your Framework Under Fire

Tres will be giving a talk at PyCon 2010 in Atlanta this Saturday at 2:15 PM. The talk, entitled Evolving Your Framework Under Fire covers the evolution of BFG as it was updated and extended to support the needs of KARL, a mission-critical knowledge management system commissioned by the Open Society Institute <http://soros.org/>.

The previous version of KARL was built on top of Plone, with more than four hundred communities and 75,000+ content pages. The application had evolved over several years, and had become increasingly difficult to scale and extend. In addition, OSI was actively recruiting participation in KARL from other, simliar organizations, whose own unique requirements would have to be folded into the mix.

Over the course of six months, a small team built the new version of KARL on top of the BFG framework, which we were simultaneously extending and elaborating to support the needs of KARL. During that period, we made more than forty releases of BFG, as well as releasing new versions of many supporting packages. The 1.0 release of BFG followed shortly on the successful launch of KARL in May, with subsequent versions continuing to be informed by the needs of OSI and the other KARL users.

This talk discusses the process of evolving the BFG framework, with particular emphasis on learning from the changes to the assumptions made by the framework at its inception. We discuss also the tradeoffs in the choice to include features in the framework versus leaving outside, either in the application or in supporting libraries. Finally, the talk proposes some general "lessons learned" which should be useful to Python programmers building any sort of framework.

Talk Outline

  • BFG's original motivation and design.
  • Overview of the requirements for KARL
  • Key changes to the BFG framework during the project:
    • adoption of documentation-driven development
    • replacing a number of the components which BFG initially depended on, with smaller or lighter-weight substitutes;
    • making other "standard" features (persistence / database integration) optional or replaceable;
    • removing performance-heavy "do-what-I-mean" features;
    • forcible converstion of text to unicode at all application boundaries;
    • adoption of a standard of 100% unit test coverage;
    • adding "url routing" as an option to "stock" object traversal.
    • enabling isolation of "customer-specific" policies and features from the core application code.
  • Issues encountered during this process
  • State of BFG at OSI's KARL launch
  • Subsequent evolution of BFG
  • Lessons learned

posted at: 00:00 | permalink