Here 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.