Presenting Clojure with a Gitorial

March 2nd, 2009

GitHub Mascot on whiteHere are the slides to the Clojure presentation I gave last week for the OrlandoJUG. Initially I was planning giving a comprehensive overview of the language, but the content ended up being long and mostly rehashed information already available online. Such a presentation would have also probably been too much to take in for one sitting.

Instead, I came up with an experimental tutorial-style format. The core of the presentation was explaining a gradually built Clojure library with TDD. The experimental part was that this presentation was captured in the Git revision control system. Every commit has a commit message that explains the “next slide” of the presentation. People can then view diffs between commits to quickly see what changed.

GitHub was used as the presentation medium. First you go to the library page, then click the commits tab, and finally click the “Older” link at the bottom to get to the first revision. For each revision you can click the title to see the commit message, and see a nice colored diff of the changes. For small commits the diff is enough and you can explain what happened right there. For larger changes it’s easier to click the filename in the diff to get the new file by itself, including syntax highlighting.

Because the “presentation” is on GitHub, people can view it when they get home again even if they don’t know how to use Git. However, one really powerful feature is exclusive to Git users. Once the repository has been downloaded, you are able to check out any particular revision. Because the library has passing tests at every commit (unless otherwise noted), you are able to create a branch and play with the code with the backing of tests.

Some other nice perks are that Git allows commit message and revision history editing. This allows you to write a “shitty first draft” quickly and not worry about getting the presentation-intended commit history perfect the first time around. Another cool thing is that presentations like this can be collaboratively improved through GitHub forks and merges.

The end result is a toy library accessible through a webservice, logging api hits in a separate thread, producing and consuming JSON, and integration tested through localhost over HTTP. Note that only the later commits have long messages with better explanations more suitable to a web audience. This is because I didn’t really know what I was on to at the beginning of the “Gitorial experiment”, and was planning on doing most of the explaining “on stage”.

This whole thing reminds me of the whole “unintended innovation” thing that keeps happening with Twitter (or even on GitHub itself with things like Reg’s Homoiconic blog). One could even imagine gradually built public Gitorials where the GitHub RSS feed is announced early for people to subscribe to. After that an Internet-full of people could “watch” the presentaiton unfold day by day in their feed reader.

Anyway, I talked to some people in the audience later and have only had positive feedback on the presentation format thus far. I loved it personally and plan to make more presentations in this style in the future.

8 Responses to “Presenting Clojure with a Gitorial”

  1. Vincent Murphy Says:

    Nice idea.

    It would be easier to follow the commits on github if they had Next/Prev links. Having to go back to the commit history every time sucks.

  2. Vincent Murphy Says:

    To partially answer my own comment: the ‘parent’ links work as Prev links, but there doesn’t seem to be a ‘Next’ link.

  3. Phil Says:

    Cool!

    I’m doing something similar with Mire, but with branches for each step instead of commits since each step is much coarser-grained (and not performed live). And most of the explanation is in the Clojure PeepCode instead of in the Mire repo itself.

    http://github.com/technomancy/mire

  4. larrytheliquid Says:

    Hey Phil. I actually thought about PeepCode when coming up with the concept. PeepCode podcasts typically come with a directory that includes two versions of the code… a beginning version and a final finished version. Of course that leaves a lot out, and capturing everything within Git is much more helpful… glad you’re doing that with mire.

  5. larrytheliquid Says:

    Vincent: Yeah a next link in the commit history would be nice. I mentioned it to Chris Wanstrath and he said determining what is “next” in Git is more complicated than it looks, but they are working on it.

  6. Rick Bradley Says:

    Very cool stuff. I did something similar when I was doing a Ruby Hoedown talk [0] last fall on reworking Flog. I ended up making regular old slides [1] from the github diffs and including github commit hashes, etc., in the talk. The downside was that the scope of the github changes was larger than could fit in an hour so I had to only hit the highlights (and left the repo [2] for folks who were really curious). You’ve definitely taken it a step further and cut out the middleman.

    Seems like it would be interesting to be able to not just say “Next” and “Previous” as synonyms for “parent” and “obvious first child”, but to be able to point them further along in the commit history to skip necessary but tedious changesets. Maybe it would be possible to just do this with some sort of linkage in the commit message. Perhaps someone could write a “choose your own adventure” book purely from commit message linkage to commits containing text and images :-)

    [0] http://rubyhoedown2008.confreaks.com/11-rick-bradley-flog-test-new.html
    [1] http://github.com/rick/hoedown-2008/tree
    [2] http://github.com/flogic/flame/tree/master

  7. larrytheliquid Says:

    Rick: Nice. Putting the “next” commit hash in the message is a neat though. When I used SVN + Trac you could mention r1234 in a bug report. That would automatically create an html link to go to revision 1234 in Trac.

    Taking this to GitHub, maybe you could do something like #b65318821d0019d3088bc2728333995bafaf1452. Here the hash symbol (#) could be used as the special identifier. GitHub could then parse for that to automatically generate links when displaying commit messages.

  8. TK Says:

    I’m a little late to the party, but I’m taking a different means of navigating the changes:
    git clone
    cd buzzer
    gitk &
    git co
    git co -b local
    and working my way up

Leave a Reply