I’m on the other side of the state to attend Code4Lib this week. This is my third Code4Lib, and it just keeps getting better every year! If you aren’t here, but you’d like to see the talks (starting tomorrow morning, Tuesday), there will be a live stream on the Code4Lib YouTube Channel; there’s even live captioning, this year, which makes me so happy!
My tiny part of helping to put on the conference happened this morning. Eric Phetteplace and I co-taught a 3-hour preconference workshop called “Command Line Bootcamp.” We put all of our materials online, partially because of the way we wanted to run our workshop, but also in the hopes that they would benefit people who 1) wanted to attend the workshop but couldn’t or 2) might stumble across it later (perhaps through a blog post or a tweet or creeping on our GitHubs 😃).
Our workshop materials
Our GitHub repo (that’s mine, but Eric’s works equally well) has information about how to set up the (free!) service we used for the workshop, a link to our slides (for the first part of the workshop), a link to the pre-written questions and answers we had people read aloud (😁), and then three folders with self-directed exercises geared toward archivists, catalogers, and web developers, respectively.
How we ran the workshop
Nitrous
One piece of semi-accidental genius was the use of Nitrous.io for our command line interface. It gives you a command line in the browser, so you don’t have to fiddle with installing software on Windows or knowing the subtle differences in certain commands (I’m looking at you, rename) on Macs. Plus: when people wget the 20MB MARC file, it goes over Nitrous’s network, not the conference’s wifi. Double-plus: everybody has the same username (“nitrous”) and the same directory structure, which makes it easier to get people back on the same page if they end up ahead of or behind the group.
I call it “semi-accidental,” because, although that’s what I used when I did a (shorter, simpler) CLI tutorial for Anchorage Programming Workshop, it has become an even better teaching tool since then. It has some really nice features, like a command prompt that tells you what folder you’re working in, colored highlighting of folders vs. files when you use ls, red highlighting of the pattern grep matched on, and other friendly interface quirks. (I’m not sure how much of this is standard zsh and how much is Nitrous-specific, because I usually just use bash. Either way…)
A++, would definitely use again.
We were ready for someone not to have done the preparation and made an account (I had login information for five spare accounts written on index cards), but every. single. participant. had done so! I was so impressed!
Sticky notes
We borrowed Software Carpentry’s idea of using sticky notes for easy two-option polls and passive “please come help me”/”I can help” signals during the self-directed exercises. This went pretty well, though the setup of the room made it a little hard for us to see the sticky notes on people’s computers. (Either that, or I’m just very short. 😃) Honestly, though, it was fine, because most people just raised hands for Eric and me to come over, or asked one another. It didn’t seem like anyone sat there, confused, for any length of time.
Just in case we had colorblind participants, I went through ahead of time and wrote “orange” on all of the orange sticky notes and “green” on the green ones. It was worth doing, even if nobody ended up needing the extra cue, because accessibility-by-default is one of the values Code4Lib strives to uphold.
Cephalonian method
Early in the workshop, right after our reminder that there’s a code of conduct and our quick look at the agenda, we went into a live question-and-answer period, where people read questions and answers off of some slips of paper we’d had them pick up with their sticky notes, as they came in. This technique is referred to as the Cephalonian method, and I am so glad Eric suggested it! (Seriously, that part was all him. I think I did one run-through of the questions and made one edit, but that was it.)
The goal of the Cephalonian method is to get attendees more comfortable asking and answering questions. It’s a good trick, and it seemed to go over well, especially because we had the morning slot and needed to wake people up a bit. I think it really did warm the room up for asking (and answering each other’s) questions.
I admit, I wasn’t entirely sure about the Cephalonian questions thing, at first, but I’m a convert. I’ll definitely adapt it for use in future workshops.
Self-directed exercises
We were very aware that the level of tech, computer, and command line comfort between participants would vary wildly—and that having someone stand at the front of the room and read off commands for three hours would be incredibly boring for the more advanced folks and would limit the learning of the newer folks. People would fall behind, or they wouldn’t really internalize what was happening. Plus, you really need some trial and error when you’re learning to do things on the command line (or pretty much anywhere else, I guess).
So we agreed early on that we would only cover the very minimum of necessary commands in a traditional lecture format, and then we would set participants loose to work at their own pace.
To make the workshop as useful as possible for as many people as possible, we thought about who would be the most likely folks in libraryland (and archivesland) to attend. Catalogers came to mind, of course. And web developers. And we knew from past conferences that archivists are well-represented in our midst, as well.
So we thought through what folks from those three groups would most want to know (as best we could guess at it) and what we could realistically help them learn in an hour.
And then we wrote out lessons, one for each group. I wrote the archivist one, and Eric wrote the cataloger and web developer ones. (I also did most of the slides, just, so you know I’m not a complete slacker. 😃) We worked through each other’s lessons and offered suggestions and ideas, and I think all three of them came out pretty useful. I think they reinforce the commands from the lecture portion, and I hope they explain enough to make the new commands they introduce make sense.
It was a lot more work, creating the self-directed exercises, than it would have been to present an equal amount of information in a lecture format—and the exercises probably come out to about three hours’ worth of content for new folks—so I won’t promise that all of my future workshops will work the same way. But it’s a format I like, as a student/participant, and it seemed popular with our attendees, too.
Putting links everywhere
As requested, we (Eric) put a link to the pre-workshop homework, getting Nitrous set up, on the conference website. We (he) also emailed the participants ahead of time, with that link.
We then made bit.ly links to the slides and to the repo, which we put into the slides (and into the repo). I printed them out in a large font, but forgot to bring tape to affix the signs to the wall, so that was somewhat less valuable than it could have been.
I’ve had so many workshops—preconferences, especially—where I had trouble finding the materials later. We didn’t want to be that preconference. (Which is part of the reason I’m rushing to blog this while the conference is still happening, honestly. That, and my feet hurt from all the standing and walking and yesterday’s driving, so it’s a good excuse to sit in my room with my feet up. 😃)
Gotta get those links out there!
GitHub
This might be the most controversial of our choices, but using GitHub allowed us to have a single location for all of our files—from the MARC file needed for the cataloging exercise to the junk filename generator script for the archiving exercise—plus all of our instructions and links and everything participants would need. The first thing we had them do, during the workshop, was wget the whole thing into Nitrous.
It also made development of the workshop really easy; we added one another’s repositories as remotes and were therefore able to keep it all synchronized really easily.
Plus, one of our attendees submitted a pull request during the workshop!
Of course, some people aren’t comfortable with GitHub (the LAMtech field is broad and deep), so within each exercise’s folder, there’s a README that just contains a link to the instructions for that exercise. (One of my pet peeves: poorly thought out GitHub repos for tutorials. Always give people a starting point!)
Google Drive
Our very earliest planning, including the workshop proposal, was done via a Google doc. From there, we branched out into another doc for the Cephalonian questions, the GitHub repo, and slides in Google Drive.
Maybe we could have been fancy(?) and kept the slides in GitHub, too, by using reveal.js, or something; but we didn’t. (The overhead of getting started with reveal.js has not yet ever been worth it, to me. There are so many other, easier ways to make slides.)
I’m not sure that the disconnect between the slides in Drive and the other materials in GitHub caused any problems for the workshop participants, but I’m not sure they didn’t, either. Hopefully all those links, everywhere, helped mitigate it, if so.
So…
I hope some people who didn’t attend the workshop will work through what we’ve put up.
And I hope some people who did attend will do more exercises, beyond what they got done during the session.
Be First to Comment