Digital Humanities and Hacking, or, Goodbye "Hello World!"

There's been some great talk lately about hacking in the humanities at THATCamps Prime (aka, CHNM) and Victoria. At CHNM, I proposed two directions for humanists talking about code. One direction was to get coders and hackers and humanists together to see what we could learn about how we read and understand code. The other was a hands-on 'lets start learning how to hack' session. Seemed like interest leaned toward the hands-on hacking, especially since Mark Sample was aiming toward a more crit-code kinda session (which didn't make the "official" schedule, but in the hacky spirit of THATCamp happened spontaneously anyway).

At Victoria, I saw from , asking the difference between 'tinkering' and 'hacking', which seemed to reflect some very interesting convo that I wish I had been there for. was basically that, to me, hacking is a bit more methodical -- there's more of a plan and an overall picture in mind of the goals and how to get there. Of course, tinkering can certainly be a part of hacking, especially when one is just beginning, or even when an experienced hacker is learning their way around a new piece of code or application. The interest there about a hacking primer was very exciting to see, and thanks to the twitter-mind, we rediscovered 's awesome Rubyist Historian series.

The big picture I see is that a lot of humanists are wanting to learn how to read and write code, and are looking for helpful entry points. I think that Jason's and my approaches reflect two opposite entry points, analogous to two entry points for language learning. On one hand, learning a new language can start with the smallest little components: here's the alphabet used, here's counting to ten, here's a verb. On the other hand, there's immersion: go to a foreign country for a year. Go. Learn.

Rubyist Historian seems more in line with the 'start with the basics' approach -- a great layout of the basics in Ruby (but which apply in general across lots of languages). I'm taking -- and took when I was learning -- something more like the immersion angle, in part because, like a lot of humanists, I think, my first encounter with code was not with a Hello World application. It was with a full-on big application -- WordPress or Drupal or Omeka or something else -- and I had an itch about it that I needed to scratch.

Unlike the immersion analogy to language-learning, though, I'm much more comfortable with the pedagogical approach of "thinking like a _____", where what's being taught is typical habits of how experienced practitioners think within a domain. That's partly coming from my background teaching composition, where I found the distinction between experienced and inexperienced writers helpful to showing inexperienced writers (my students) some of the habits that experienced writers (me their teacher, and their other professors) use and display. I wouldn't want to assert that speakers of a particular language think in a particular way -- that's a socio-linguistic arena I don't want to walk into. But I'm fairly comfortable making that assertion about hacking (though the same socio-linguistic issues might also be in play).

So, here I want to give a sample of what I see as typical thinking habits of hackers, mostly in hopes of sparking conversation about the idea, and what might be useful in such a primer.

First off, I like to start with Javascript as a language to start hacking in. There are quite good concerns about that choice, since compared to PHP or Ruby or Python there are some ... quirks ... that make it a bit unusual compared to some of those. But for beginning hacking, I'm perfectly happy to do some hand-waving and ignore them. That's probably coming from when I was a math tutor -- you have to decide what nuances of calculus or abstract algebra you need to ignore when you're teaching a high school sophmore how to solve the Pythagorean Theorem. I'm similarly happy to ignore some of those more subtle nuances between languages to get to some practical ends, and because a new hacker probably won't care about those differences anyway. They'll learn about them soon enough as they become more experienced hackers.

Following Tim Sherratt's suggestion, GreaseMonkey is a great place to start because there are plenty of existing userscripts to hack on, and they're often relatively small and manageable. So, like hacking on Drupal or WordPress, you're starting with a complete project, but on a much, much smaller scale. Javascript and GreaseMonkey also offer the advantages of having very little installation and setup needed to get going. Since it all exists in the browser, it's possible to get a hacking environment up and running very quickly.

Here's the habit of thinking I wanted to focus on when it comes to hacking:

1. Where does a piece of data come from?
2. Where does that data show up on the screen?
3. What happens in between those steps?
4. Where can I make it do something different?

The XKCD Titles userscript is a nice place to start, because it's quite small and does one very useful and playful thing: it takes the bonus joke in the image title/tooltip in xkcd and inserts it into the page without needing to mouseover the image. It is itself, without us beginning to hack on it, a great example of that hacking mode of thinking.

1. Where does a piece of data come from? The title attribute on the image
2. Where does that data show up on the screen? The browser's tooltip thingy
3. What happens in between those steps? The browser does it's default thing with title attribute
4. Where can I make it do something different? I can grab the text from the title attribute and insert it elsewhere

 

Here's how it goes. I've inserted comments to try to get some of the thinking process, and basics about code, that I talked about in the session (or should've talked about!)

Now, for a tried and true hacking technique: guess. (This is where tinkering is part of hacking). If I think that img.title really is the text that gets inserted, test that guess by making a small adjustment. So, I'll comment out the original code and replace it with something that'll test it.

An even quicker way to test whether img.title really is the text I want is to shoot some info directly to the screen. In javascript, that can happen with alert(img.title):

Shooting info directly out like that often happens in debugging, but it's also a quick and dirty way to see what's happening at each step of a script. There are more sophisticated ways to do that, but to get started this works well enough.

When I reload the xkcd page, I expect the usual tooltip joke to be replaced by "Did this work?". This is the principle of "When in doubt, try it out!" that's an essential part of hacking to learn how some code works.

In the session, we tinkered a little more with how to insert the text in other places on the page by running through similar steps -- commenting out a line and making a minor tweak to it, using alert to see what's happening at each step, guess, and try it out. Then we moved on to some slightly more complex scripts on the THATCamp campers page.

In this hack-on-a-hack, though, we already see the same habits of hacking. Where does some data come from? Lets throw out some alerts and minor modifications of existing code to figure that out. Where does data get inserted into the page? Something called "insertAfter" looks like a good candidate. What happens in between? Lets again play the game of alerts and minor modifications of code, this time within the insertAfter function. Where can I make it do something different? That's what I learned from alerts, commenting out and tweaking, and "When in doubt, try it out."