I wrote a plugin for zoia in Code4Lib IRC. Here’s how.

A happy story in two parts.

Part the first: How I wrote it

I decided to find some extra guts today and write a plugin for zoia. (If you’re not familiar with the code4lib irc channel, zoia is this charismatic bot who responds to a variety of commands with helpful, or ‘helpful’, things. @forecast gets you an (opinionated) weather report, for example.)

It turns out writing a plugin is not (or need not be) very complicated. But figuring out how was hard, because I couldn’t find a description of the process anywhere. Let’s fix that. Here’s what I did. (With big thanks to Misty De Meo, who told me how to do some of these steps and applied needed permissions. Thanks!)

(Assumes basic Python ability — mostly modifying existing files — and basic github — you’ve authenticated an account and know how to pull/push.)

  • Skim the github repository for zoia’s plugins. Figure out how plugins work. OK, so they all have __init__.py, config.py, and plugin.py. Cool. I have no idea what most of the commands or imported libraries mean, but it turns out all of the __init__.py and config.py files are almost exactly the same, so I don’t actually have to know what they mean; I just have to swap in the name of my plugin as needed.
  • Spend some quality time with plugin.py examples. Compared the plugin.py files for a few plugins I’ve seen used on channel (that is, I know what they’re supposed to do). Noticed that they all have a similar structure — import the same few things (plus sometimes more as needed), define a class, define a function inside that class which has the same name as the command will have in channel and generally takes the same arguments, et cetera. Some of the plugins elaborate this core structure a lot because they do a ton of things, but they all have the same basic structure.
  • Actually write my plugin.py. So I copied the bits the other ones all shared and wrote my unique logic (and help text!) into the one place that differs substantially (the function(s) inside the class). At this point I had __init__.py, config.py, and plugin.py in a new directory together.
  • Test, step one: install supybot. I used these instructions. The installation process walks you through the configuration options, and the defaults are sensible. Set yourself up as the owner and use some throwaway irc channel for testing purposes. Make sure runbot/plugins contains the directory with your plugin. (Or figure out how to configure it to look somewhere else, but I never did that.)
  • Test, step two: mess with bot in your throwaway channel. Authenticate to bot (/msg <botname> identify <user> <pass>). (Optional, nonrecommended extra step: Blow away bot and reinstall it because you didn’t bother giving the owner a password and it turns out /msg <botname> identify <user> doesn’t work and you don’t know how to just change that one configuration option (the password is hashed in the config file — good bot!) so demolition is easier. Restart bot and authenticate.) @load yourcommand. Attempt to run your command. Discover it doesn’t work, because some of those args you didn’t include in your function because you didn’t see why they were relevant turn out to matter. For something. Add more bits from working plugin.py files. Debug your logic. You know. Hit it with rocks until it works.
  • Get write permissions to the code4lib github repo. Ask someone nicely.
  • git push the new plugin directory.
  • load @fixit — this needs to be done by someone with zoia owner bits, which isn’t me; another ask-nicely problem.
  • Cackle with glee. Show off new functionality in channel.

Somewhere after installing supybot I discovered it comes with a supybot-plugin-create wizard which automates a lot of this (except, I presume, the bits with your custom logic), so if you’re starting from scratch you might want to start with installing supybot and see how much of the heavy lifting the wizard does for you. Then again, the reading-a-git-repo way is more educational.

Part the second: The funnest part

The funnest part was that I showed it to people on channel, and a couple people tried it, and then immediately they started remixing it with other bot commands — because you can nest them, you see! Inside of two minutes I saw people do @scalia [fixit], @who should [fixit]?, @who should [canuck [fixit]], and @tweet [fixit].

(@scalia puts air quotes around a randomly chosen word in a way that somehow manages to be bitingly sarcastic. @canuck, of course, appends “, eh”.)

In other words, I built a thing and people immediately built things on top of it and made it their thing.

You see? The funnest part.

after @bohyunkim: talking across boundaries and the meaning of “coder”

Bohyun Kim has a great post (and read the comments too), Why not grow coders from the inside of libraries? Interesting questions on why we’re not doing that and how our institutions could better support that sort of development.

The question that came up for me, though, reading through comments, was a question of vocabulary. Her post has attracted comments from both librarians and IT types — which is part of what makes it so worth reading — and I have the impression that these groups are using words like “coder” to mean different things, which is impeding conversation.

From where I stand, there’s a continuum of tech skills that goes something like this:
0. Little or none.
1. Comfortable front-end user: can find stuff in databases, set up a Facebook page or WordPress blog, et cetera.
2. Comfortable back-end user: know their way around a command line and a config file; think that angle brackets and octothorpes are perfectly reasonable things to encounter in a file.
3. Quick-and-dirty hacker: have dabbled in at least one programming language (HTML is not a programming language), can make a few dozen or maybe a few hundred lines of code do something useful, can mess around with an API.
4. Protodeveloper: can usefully contribute small things to large projects.
5. Engineer: can usefully contribute large things to large projects. (Of course there’s a continuum here from junior engineer through guru, too, but that continuum is not important for my purposes.)

I think when we talk about coders in libraryland, we typically mean #3 (sometimes #2, if we find tech intimidating, or #4, if the context is open source, but #3 will usually do). I think when IT or CS people talk about coders, they mean #4 at minimum and often #5. Some of the comments on Bohyun’s post are from computer types who are taking her to task over, e.g., oversimplifying the work that they do, and I think underlying this is a different use of terminology. If I may put some words in her mouth (and please, Bohyun, correct me if I shouldn’t!), when she says “I don’t think that coding is too complicated or too much to learn for any librarian regardless of their background”, I think she’s talking about level 3, and some commenters are upset because they think she just said level 5 is easy.

(I think, of course, they’re both right. Level 3 is straightforward enough as long as you have relatively logical habits of mind and — critically — are not afraid. Level 5, just like high-level proficiency at any complex task, takes years, and you need both hard work and talent to get past its lower end, too.)

I think it would be great if libraries had more of the 5s, but it’s not,on a large scale, realistic. (The starting salary for MIT bachelor’s graduates is $67,270 [pdf]. And your library pays what? I rest my case.) But I think far more widespread level 2 and 3 knowledge, and the occasional 4, is critical. It would empower us to make our libraries work the way we want them to in so many ways (a variety of patron interactions, staff workflows, reporting…). It would empower us to be far more critical consumers, and users, of news about technical advances. And it would empower us to generate far higher-quality demand of our ILS and other technical vendors, by understanding (even if we can’t implement it ourselves) what’s truly hard, innovative, cutting-edge…or easy, sub-baseline, last decade’s technology.

Oh — and it would empower us not to be completely marginalized in the public conversation about information. You know, the ones that the people who understand how to (technologically) manipulate it took over years ago.