|Version 1 (modified by shawnr, 8 years ago) (diff)|
Django Success Story: PBS TeacherLine
The original PBS TeacherLine website was hosted in a Windows IIS environment running Macromedia Cold Fusion. This was problematic in many ways. All other PBS sites are hosted in a relatively traditional LAMP environment, which made it difficult to service the Windows server machines. As the original project developers left, there was nobody on staff with serious Cold Fusion expertise (and not much interest in learning Cold Fusion, which is used nowhere else in the organization). Finally, the Cold Fusion boxes began to deteriorate at an increasingly rapid pace, leading to constant outages and. It didn't help that at some point the Cold Fusion crash recovery and error reporting eventually completely gave out, forcing us to use external monitoring tools to catch the numerous outages.
In addition to the hardware difficulties and outages, the Cold Fusion code was also finicky and difficult to maintain. Again, finding developers with an expertise in Cold Fusion was difficult, which further compounded the code issues. The code running PBS TeacherLine had become so convoluted that it was virtually impossible to add a new feature without rewriting several old features.
At the outset of what we called the PBS TeacherLine Refresh project, we surveyed the landscape for modern, open source development frameworks that would naturally fit into the PBS Interactive systems. Ruby, PHP and Python were identified as the top language options. Ruby was gaining momentum with the Rails framework, but we had nobody on staff who had done more than played with Ruby. PHP is a language commonly used by PBS producers, and we had the staff to support PHP, but it lacked a robust framework for development (we examined CakePHP, Trax, and Zend Framework) and caused too much argument among developers about whether or not it was a "good" language.
Python was a natural choice for us since PBS has been running Zope/Plone apps for several years. We had several developers on staff with Python experience, but many of them had developed a keen awareness of the issues with that framework (this was pre-Zope 3, and PBS still supports both Zope 2 and Zope 3 projects). At OSCON 2006 several PBS developers attended Django sessions and came away with a good feeling. PBS TeacherLine is the first major application developed using Django on pbs.org. The site is hosted on the same servers as all other PBS websites, cohabiting with a variety of languages and configurations. We run Apache with mod_python in a multi-server environment. We utilize a CDN for serving static content and have integrated our site with third-party solutions for streaming video.
Working with Django has been a good experience. We needed a robust, flexible system that would facilitate a group of developers working on the same project. Django makes it very easy to have custom site configurations that accommodate our distributed development builds and migrating builds to different servers for various QA and review-related activities is incredibly easy. In addition, Django compliments the elegance of Python in a way that has reinforced good development habits and allows us to be a flexible group.
The Django Admin has been another great feature of the framework that has paid off for us. Given that some of our projects require PBS staff to build robust datasets, it has been nice to be able to quickly create a set of models and allow content developers to get in and populate the database concurrently with the development of the public views and, in some cases, the final administrative site. In the end, we have only used the Django Admin as a way to jumpstart this development process, and in the production versions of our software we have replaced the stock admin with our own custom administrative tools.
Flexibility of the sort described above is a key value in the Django framework. PBS is not exactly a software shop, so our requirements change often as projects evolve. Django and Python are both very friendly to an iterative development process that sometimes involves radical revision of the code.
We encountered few problems in getting Django to meet our needs. We had to create alternative versions of some components, such as the users and authorization systems, to accommodate our specific needs. However, these changes coexist peacefully with the original Django systems (which we maintain for the limited usage of the Django admin). The Newforms development solved a lot of issues we had at first with the "old" forms, and we are also looking forward to the query restructuring currently underway. We have occasionally had issues working with the queries system, especially with regards to many-to-many relationships. We would love to see support for content types more closely incorporated into the Django queries system. The issue of "beta-ness" has come up a couple of times when discussing Django with our colleagues. The delay of version one has been a point of ridicule for some holdout developers, but the version number has so far not impacted our development. What currently exists in Django generally meets our needs and operates in a reliable way.
We are still in development on several major Django projects. Other groups at PBS have also taken up Django, and there are several new sites that will launch at PBS utilizing the framework. We actively follow Django developments and will continue to do so as we work on new projects.