- Our web pages and blog posts are Jinja2 templates stored in three GitHub repositories: one for the main web site, one for the Version 4 videos and slides, and one for the Version 3 notes. (We split material between repositories because we didn't want people to have to download the earlier versions in order to write a blog post—they're fairly large. In practice, though, the web site compiler doesn't work if you don't have everything at hand.)
- We use a 950-line Python script to compile those templates into HTML pages. (We'd like to use Pelican, a blog compiler written in Python, but need a few patches to land before we can easily integrate the plugins we need.)
- Our tutorial videos are on YouTube and embedded in our web pages.
- We use Google Analytics to watch web site traffic.
- And Disqus for managing comments.
- And the Open Badges infrastructure for the digital badges we issue. (More about this later.)
- We use EventBrite to handle registration about two thirds of the time; the rest of the time, hosts take care of it themselves (typically with an internal system they're required to use).
- Our site is hosted by Dreamhost. Their service has been increasingly erratic over the past ten months, so we're probably going to move to another hosting service this summer.
- We use Mailman to manage mailing lists, primarily because it's what Dreamhost provides. Unfortunately, what Dreamhost doesn't provide is access to Mailman's command-line API: they host mailing lists on a different set of servers than the ones used for web sites and shell access, so we can't write scripts to synchronize mailing lists with our database. This is another reason to move to another hosting service…
- And speaking of databases, we have yet another version control repository that holds our contact database (as an SQL file we can load into SQLite), notes about bootcamp prospects, and other information that can't be public (because it includes personal email addresses, phone numbers, and so on). Using an SQLite database makes it really easy for us to ask questions like, "Which bootcamp attendees in 2012 became instructors in 2013?", but keeping it up to date is tedious.
- Which reminds me that there are three other repos as well. assets stores all the "extra" public files that don't go into the web site, such as the vector source for our logo and the LaTeX and Markdown versions of our papers. guide holds the source for the instructors' guide that was supposed to be finished five months ago. Like the web site itself, it is written in HTML with Jinja2 templates and compiled using a little Python script. Finally, boot-camps holds actual teaching materials, plus the web pages that instructors create for their bootcamps. This repo is a mess right now, and cleaning it up is one of the major jobs for our summer break.
- And oh yeah, we tweet. When we were using WordPress, tweets were sent automatically when new blog posts appeared; we do that manually now (and sometimes forget). We also sometimes forget to post notices about newly-announced bootcamps.
As you can tell, there are a lot of moving parts. Here are the steps involved in several common activities:
|Write and publish a blog post.||
|Set up a new bootcamp.||
|Wrap up a bootcamp.||
|Add someone to the online study group.||
|Issue someone an instructor's badge.||
There are far too many manual steps in these lists, but I'm not sure what to replace it with. WordPress didn't meet many of our needs, and while customer relationship management packages like SugarCRM would be useful for managing bootcamp prospects and attendees, they don't handle blogging, event Registration, or badging.
It's tempting to build something ourselves, but that way madness lies we don't have the days needed to build, test, deploy, and maintain something. Even if we did, it always seems we'd be better off using them to create new lesson material or actually teach. We can't go on like this, but I honestly don't know what we should do instead.
Originally posted at Software Carpentry.