This summer Graham Sack, a doctoral student in the English department is teaching an introductory course in Digital Humanities called ''Computational Methods for Literary and Cultural Criticism''. Graham came to CCNMTL inquiring about the usage of a cutting edge approach to teaching programing to novices, a web-based programming environment called IPython Notebook.

For years, I’ve watched our video team do amazing work shooting, editing, and encoding video for the web. I think most production companies would be shocked at how much high quality work our team produces with so few staff, a tight budget, and tighter time constraints.

When I look closely at how they do what they do, I’m impressed and just a little frightened at how many manual steps are involved in getting a video online. Manual steps that take time, attention to detail, expertise, and are ripe for mistakes.

I try to automate everything I touch. I can’t help it. It’s the curse of being a programmer.

At CCNMTL most of our new Python projects are written in Django, but we still support a number of older projects that were written with TurboGears 1.0.4. They've continued to be stable, and we don't do a ton of new development on them, so it hasn't been worthwhile to upgrade them to newer versions of TurboGears.

But we do occasionally make changes to their code, and recently we've begun migrating them to newer servers.  So I recently spent some time updating their deployment processes to CCNMTL's current best practices:

• Installation with pip instead of easy_install
• Fully pinned local source distributions versioned alongside the code
• No Internet access required anywhere in the deployment
• Containment with virtualenv

Earlier this week, I wrote about how to make virtualenv install pip and setuptools from local source distributions, instead of fetching unpinned copies of them from the Internet, which it does (somewhat silently) by default. The approach relied on a somewhat buried feature of virtualenv: looking for appropriate distributions in a virtualenv_support directory before downloading them.

In a future release of virtualenv, this will be easier, and also more apparent.  I submitted patches for two new features which were accepted by virtualenv's maintainers:

• An --extra-search-dir=/path/to/directory command-line argument, which lets you put pip/setuptools/distribute distributions wherever you want on the filesystem.
• A --never-download flag, which will cause virtualenv.py to fail during installation if local distributions aren't found, instead of downloading packages from the Internet; useful if you want to be alerted early and loudly if your deployments have inadvertent Internet dependencies.

Anders has written several times about our deployment strategy for Django apps at CCNMTL. Aside from containment of each project with virtualenv, we also try to make sure that deployments never depend on anything external, and can be done without access to the wider Internet. We do this by an aggressive form of version pinning: in each project's repository, we check in source tarballs of all the project's dependencies, including Django itself. We then have a pip requirements file that points to each of these local files in order. (Here's an example, and the bootstrap script that uses it.)

There are two benefits to this approach. First, it removes our deployments' dependencies on external web services, like PyPI, being online. Second, it ensures that we know exactly what versions we're using of all the Python code in a project's deployment. That makes deployments trivially repeatable, and gives us the ability to roll back a deployment to any earlier version -- so if a new deployment doesn't work properly for some reason, we can re-deploy the last tagged deployment and know that (barring system-level changes) it'll work exactly as expected.

The other week, we made a new deployment to one of our Django projects, and the site stopped working. It turned out that the wrong version of Django was installed somehow: the project was built on Django 1.0, but this broken deployment ended up with Django 1.2 instead. And, oddly, rolling back to the previous deployment didn't fix the problem.

Walking past the round-the-block lines for the iPad 2 prompted me to reflect on the long-term educational significance of the tablet. The futurists who predicted the rise of mobile will most likely claim that these tablets fulfill their vision. Tech pundits insist that this new form-factor goes beyond superficial cosmetics and represents a transformation in computing. What should we make of the hype?

The 2011 Horizon Report predicts both mobile and ebook/ereader adoption within the next year:

"For more involved web browsing, reading, watching videos, or to use any of the tens of thousands of Internet productivity and lifestyle applications, the tablet provides just enough extra space to enable comfortable use over longer periods of time."

At CCNMTL we've begun exploring the deployment of applications on tablets. We recently launched two behavioral interventions that are being used in the field - MySmileBuddy and MedER. These applications are hybrids of data collection and multimedia educational material and are being administered by social workers making housecalls and researchers on-site in the pediatric emergency room.

The other night I was on a panel discussion on Python Deployment at the Django-NYC meetup. The discussion was very good and I think everyone there got a lot out of it (I did). But the format wasn’t really suitable for going into great detail, showing actual code fragments or demos. I’ve written about aspects of our deployment strategy in the past on my personal blog and in comments on other sites, but it’s a continuing work in progress and I’m well overdue for an update. We also have a web-base deployment tool that, while the code has been open and available for a while, we really haven’t officially announced or publicized until now.

There are two angles to Python/Django deployment that I want to discuss. First, there’s deploying Django apps. Then there’s how we use a Django app to deploy Django (and other) apps. They are closely intertwined so I think I can’t really talk about one without talking about the other.

This semester we upgraded our WordPress Multi-User (MU) installation to WordPress3. WordPress runs our EdBlogs course blogging platform, a system we support that is designed for multi-user course blogs. WordPress3 brings the WordPress MU fork back into the fold of the core WordPress distribution and continues the gradual improvement of its technical architecture and design.

We concentrated on revamping our standard themes and worked harder than I anticipated to make sure that the default experience within a newly created blog makes educational sense.

After some prodding from the community, I've finally published Drupal module Multisite Manager 6.x-1.0. I originally developed this module to fill a sweet spot that was missing at CCNMTL two years ago--allowing our Educational Technologists to just click a button to be able to create a new site to prototype content, or experiment with Drupal's features. Drupal is a great platform that makes this possible, but then allows a developer to add features later--significantly, after content and some site architecture has been worked out.

At CCNMTL for small projects, we're using more hosted solutions and specific tools like Wikispaces and Wordpress MU, rather than general CMSs like Drupal and Plone.

Our farm is still on Drupal 5.x, and it seems migration is near impossible due to module dependencies and unclear upgrade paths. Nonetheless, it wasn't clear at the time this would always be the case.

So when Drupal 6.0 came out, I upgraded the code to work for Drupal 6.0. We do not use this code ourselves, so I wasn't very confident about it's usefulness; I left it marked as development branch. This hasn't stopped it from getting about three hundred downloads a week. It seems my concern about bugs was unwarranted in this case.

Even though we don't use it ourselves, at the time, it was still the easiest way to see the differences between Drupal 5 and Drupal 6. Now Drupal 7 is coming, and I can't think of a better way to keep tabs on the community besides just writing some code, and seeing how it does.

We are very excited to announce the release of our latest iteration on a web-based, multimedia, annotation environment - code named: Mondrian Mediathread ( source code ). Mediathread builds on the strengths and experiences of our long history of annotation projects here at CCNMTL.

Mediathread is a collaborative multimedia analysis environment that supports deep critical exploration of primary multimedia source material, i.e. participatory education, research, democracy, and culture. The Mediathread platform supports a robust access control model with multiple analysis spaces and a variety of workflows (solo projects, collaborative projects, versioning, private projects, public projects, etc). The community portal also organizes streams of activity notifications to help the participants track each other's (net)work.

Participants in the analysis space collect multimedia assets from around the web, clip/annotate these assets, organize their clips, and create a multimedia composition where their clips are directly embedded inline in their analysis/argument. The upcoming release supports video clipping (quicktime, flowplayer, and youtube), and drawing on images (using the fabulous OpenLayers viewer).

This semester we partnered with the Earth Institute and launched an environment to support the new international Masters in Development Practice. The environment is intended to support curricular interactions as well as less formal student interactions (i.e. social networking) and our first iteration is built on a combination of Moodle and Elgg.

We are just dipping into Moodle development and ran into a situation where we wanted to customize the video player we were using to display the video. I ended up writing a small moodle filter which automatically processes .mp4 files and outputs the appropriate embed code. The code is now available at on github: moodle-mp4filter.

For thousands of years critical and scholarly discourse around text has revolved around citation and reference. What might this kind of discourse look like around multimedia - html text, images, audio, and video?

This question is a central theme in our technical work here at CCNTML, and a variety of our projects have taken a pass at this question from one angle or another. My colleagues have also taught me the importance of designing these kinds of features in ways that encourage students to critically engage with the source materials they are studying. How can we facilitate the marshaling of multimedia sources as evidence to support an argument or hypothesis?

In March, CCNMTL shipped a laptop to a South African AIDS clinic as a part of a multimedia health-care intervention.

We're not that experienced with desktop application development, so the main discussion was how do we bundle a web application on a stand-alone laptop with no connection to the Internet. The first proposal was to run a virtual machine (Xen or VMware) which would run the web server on the Windows desktop.

I was less sanguine about diagnosing problems with a web server across continents and timezones, and looked for a way to store state information from static web pages. Firefox's DOM Storage was close to a HTML5 standard (now finally implemented in Firefox 3.5), and seemed to work with URLs visited as "file://localhost/C:/..." so this made the following process possible:

1. Put static HTML files on the laptop
2. All state is stored by the browser (in a file called webappsstore.sqlite)
3. All application storage is accessed and modified by javascript (see code)
4. Login state uses sessionStorage which works similarly but disappears after the browser closes (like a session cookie)

Instead of supporting a virtualization and web server stack, all that's left to support is the browser--something very familiar to all computer users by now. It's worked out great.

I should note that our application is not secure from a javascript hacker who has access to the computer--they could access and change all account information on our system. Fortunately, that's not an attack vector we're worried about.

OK, there's a dirty secret behind my not posting about this previously--it no longer works! There's a laptop in a South African clinic that's not getting any Firefox updates, security or otherwise, and that's a very good thing. Now, it seems, all browsers, remove the 'localhost' from file:// URLs. The new HTML5 standard localStorage does not work for local files, and the deprecated globalStorage[hostname] doesn't work without a hostname!

HTML5 taketh away, but it giveth ath well. Instead of relying on file:// URLs, in the future we can label our site as an offline resource and then use the now standardized and implemented localStorage.

The one issue with this future approach is if we need to update the application while it's in the field. We haven't needed to do that on this project, but it's a comfort to know that if they discovered a critical bug, we could email them a single HTML file to replace, and the computer running the application does not need to be connected (to anything other than the USB key the new file is on). I sent our use cases for localStorage over to the HTML5 mailing list, but there's still work on the standards side and for the browser vendors.