Interactive Fiction, Declarative Domain Specific Languages, and Web Frameworks: Introduction

This is the first part--just the introduction, really--to what I intend to be a small series.

I've liked interactive fiction pretty well since I was a child. If "interactive fiction" doesn't mean anything to you, you might be familiar with the old Infocom games of the 1980s: Zork, Planetfall, The Hitchhiker's Guide to the Galaxy, Leather Goddesses of Phobos, and so on. That's interactive fiction.

Even though interactive fiction hasn't had much of a commercial impact since the 1980s, the genre has been alive and well, and actually doing amazing things, ever since. Shareware and freeware drive it now.

If you're willing to give it a try, Emily Short is considered one of the current masters. Galatea, for instance, might be an eye-opener: free, only 10 minutes long to play, and not a puzzle per se, but pretty amazing. Give it a try. You also might enjoy checking out the experience of blueful. I intend to try out Lost Pig with my five year old, playing it with him. There are also plenty of long fantasy, sci-fi and mystery games out there to be found, still usually free; and free software to play the games for Windows, Mac, Linux, Palm, iPhone (search the Appstore for Frotz), and plenty of others. This is really cool stuff.

So how do you write interactive fiction? Well, that's cool too. What's going on there right now fascinates me, both because it inspires me to want to give it a try, and because it has a different perspective on similar issues that I've been observing with web frameworks.

Later in this series: Inform 7 versus TADS, domain specific languages and design, pondering declarative goal-directed programming for web applications, RoR and Hobo, and various other things that I will make up as I go along.

Buildbot and Amazon Web Services Elastic Compute Cloud ("AWS EC2")

If you might care about Buildbot, you probably already know about it: "a system to automate the compile/test cycle required by most software projects to validate code changes," as the site puts it. It's written in Python with the Twisted framework.

At Canonical, I've been doing some work with it, and, lately, on it. My first accepted git branch added some bzr helpers. That was cool, but small. The one that was accepted this week is a bit more interesting, I think.

I've made it possible to hook up one or more on-demand, or "latent" slaves to the buildbot master. In the current single concrete implementation of the abstract class, for example, a latent slave always claims to be connected and ready to perform builds, even though it does not really have a remote connection to a machine ready to do work. But when a latent slave gets a build request, it instantiates an Amazon Web Services ("AWS") Elastic Compute Cloud ("EC2") virtual machine, using the image (and therefore operating system) of your choice to run the tests. It uses the nice AWS Python library, boto, to make the magic happen.

Implementing the same thing for other similar cloud computing services should be pretty easy. The buildslave.py module now has an AbstractLatentBuildSlave class. All you have to do to is subclass that and implement one method to start a virtual machine, and one to stop it. It's described in the pertinent section of the documentation.

I figure the new feature is probably only interesting for a relatively small subset of buildbot users. But it's still pretty cool, and a significantly different variation on what was there before. This is supposed to be released in 0.7.10, which is slated to be RSN, as I understand it.

If you are curious enough about it to want to poke around, the git master branch is here. You can find the EC2 latent slave in buildbot/ec2buildslave.py. The documentation also has extensive additions to try to help you get started.

Looks like I'll be doing a bit more buildbot work in February. Cool.

Catch-up

I feel like I've been playing a whole lot of catch-up lately.

Mark Ramm's September '08 blog posts about how Django could learn from Zope 2's mistakes made one point (actually from the second post) that struck home strongly: more innovation happens elsewhere than within one given community.  You have to pay attention to it and be a part of it.

I have been a part of some cool, and uniquely valuable, stuff working on and with Zope 3.  I've also tried to keep abreast of new technologies, studying Dojo, and Programming Collective Intelligence, and SproutCore, and Objective C, and so on.  Notice that another web framework is not in that list.  Maybe that's because I was working for a company, Zope Corporation, in which working with other frameworks was not really an option (not that I minded, mind you; I like Zope 3).

But employer policies and positions are not really a good excuse.  I should have been actively studying the other web frameworks anyway.

Now that I'm in a work environment with more opportunity for cross-pollination (working for Canonical) I feel like I'm trying to swim out of a backwater to catch up with the rest of the web developer world.  It's daunting and stimulating.  Ideally I can find a way to integrate the best of my past with what the rest of the world is doing.  I've been a part of some innovation too, and I believe some chunk of it is worth bringing forward.  But I need to catch up.

I've been saving up my notes on REST while I read Leonard Richardson's excellent O'Reilly book about it, hopefully for a series of posts.  It also is an interesting, if somewhat dated, view into the world of Ruby on Rails.  In the alt-Zope world, I've been looking into what Tres Seaver, Chris McDonough and friends have been doing with repoze, especially repoze.bfg.  (I've already been somewhat familiar with Grok, but that's so close to Zope 3 that studying it really doesn't go too far in the way of cross-pollination.)  Obviously I need to spend some quality time with Django (I've done just a bit so far) and I'm impressed enough with Mark Ramm's presentations that I figure I ought to spend some time with TurboGears.

Like I said, daunting. And stimulating.

But meanwhile...I've also been looking at what interactive fiction has been up to since the last time I looked!  And that's what I intend to blog about next: the declarative domain specific language in Inform 7, and maybe how it relates to this crazy web developer biz.

Learning How to Blog

It's been awhile--over two years--since I blogged. The reasons are simple: I'm busy with work and family, and perhaps I associated blogging too much with professional or scholarly publishing. The second point had two corollaries: my posts were often too big, both in terms of engaging readers and finding time to write; and I felt insecure and shy about saying much. I'm still busy, and I still want my posts to have some value, but I'm hoping I can get back to blogging. Why?

• I have stuff to say!
• I'm working from home now for a distributed company (Canonical), so blogging is a way to share (non-proprietary) ideas in the company.
• Twitter and Facebook have shown me lately the value of making connections with distributed friends and acquaintances.
• It's a reason, and a way, to work out ideas gradually.
• I now understand blogging as being (at least potentially) more social--more of a conversation than the higher stakes of a formal presentation or publication.
• Assuming I don't perform the blogging equivalent of stripping in front of a religious monument, it is conceivably good publicity, if that ever helps. Or, maybe, there's no such thing as bad press? In any case, my boss wants me to take a more public position in the open-source community, in part because I'm driving some of the open-sourcing work for my team. (BTW, I may be going to PyCon! See anybody I know there?)

What do I have to say? Well, off the top of my head:

• I'm working with the primary author of the O'Reilly REST book, and I have some nascent thoughts about REST and what I'm learning from him that I'd like to work out.
• I presented a speech at a company conference this past October about my take on why and for whom the Zope interface and component libraries might matter. It would be nice to make that a bit more general and share it.
• As I said, I'm working from home now, and I really enjoy it. One reason I enjoy it is the processes that my company, and my project, have for helping a distributed team work together. I'd like to share them, because I think the whole experience is great.
• I've done some more open-source work lately, ranging from adding the capability for buildbot to launch AWS-EC2-based build slaves on demand, through adding support for the bzr revision control system to buildbot, through adding cookie helpers to testbrowser, to packaging and releasing some software developed by other folks in my company. I'd like to talk about them a bit.

So, there's plenty of reasons to blog. How can I make my blogging experience better? What can I learn from the last time I tried this?

• As I said before, treat this as a conversation. I usually don't have time to prepare something that approaches being authoritative, so admit it, move on, and be ready to listen.
• That said, remember ye olde paper-writing days from school: outlines RULE. Write an outline, at least an informal one, first.
• If the outline starts to look big, do it in broad-brush and DIVIDE IT UP across several posts! The outline will help keep the posts make sense together, and focusing on one or two bullet points per post will keep the blog entries shorter and less imposing for readers, and will be a smaller, easier-to-schedule block of time for me to write.
• Let my light(ness) shine! I have occasionally been reasonably amusing in my life, and, as a reader, I find that posts with a bit of lightness and levity are easier for me to read. Being lighthearted probably puts me in a better frame of mind when I write, too. "A spoonful of sugar helps the medicine go down"?

So, that's the current theory, anyway, for teaching myself how to blog. Let's see how it goes.