Introduction: Coding live is awesome, but difficult
Perhaps the most powerful way to show off anything, is to use it live in front of your audience – programming tools, languages and libraries are no exception. You’re showing off a “Hello, world!”-like example with some new framework, and someone in the audience asks a “what if you change this to that?”-question? No problem – just change the code, and show what happens! There’s no way to do that in the code sample you’ve pasted onto your slide deck…
On the other hand, perhaps the worst kind of interruption in your presentation is when something doesn’t work. Of course you tested it thoroughly ten minutes before you started presenting, but Murphy’s Law will bite you anyway – coding live is no exception. In fact, coding live might be one of the most difficult presentation techniques available to us; you can bet your neighbour’s cat that everyone in your audience will spot the typo before you do. That’s why putting the code on a slide is so reassuring; you know you’ve already checked it for typos.
But as it turns out, there is a way to both have the cake and eat it.
What you want to accomplish, is basically to write code live, in a real environment where you can run the code, change it on-demand from your audience and run it again – all in a way that allows you to re-use already tested samples, down to the last semicolon, to avoid wasting time looking for typos and focusing on the real features. Jumping between samples should be just as easy as jumping between slides, while staying interactive.
Re-stating the problem, you want to be able to bring up code samples and versions of code on-demand, inside your real environment. Sounds familiar, no?
Jumping between versions of code is just what git does best. Let’s make use of it!
1. Write the demo code, and decide how you want to structure the presentation of it.
2. Manipulate your git tree to give you a straight path through the demo (somewhat equivalent of “preparing your slides” – one slide becomes one commit). How you get there is not so important – personally, I’ve found interactive rebases to be a helpful tool.
3. Add a couple of git tags to the start and end of your demo, e.g. demo-start and demo-end, to make it easier for you to make sure that you’re in the right place when you start your presentation.
You should now have a git log that looks something like this:
4. As the final ingredient in our recipe for a successful live demo, run the following command:
git config --global alias.next '!git checkout `git rev-list HEAD..demo-end | tail -1`'
What does this do? Let’s examine it in pieces, starting on the inside and working ourselves out:
- The innermost command is git rev-list HEAD..demo-end which shows us the list of commit hashes between the current commit (HEAD) and the tag demo-end which we created above, in reverse chronological order. This is then piped to tail -1 so we get only the last hash in the list, which is the next hash between HEAD and demo-end.
- Next, we wrap that in backticks, and check out the output, i.e. the next commit in the history. In practice, what we’ve done is to run git checkout HEAD^ only backwards.
- git config --global alias.next <...> configures an alias in git, so you can use git next to run whatever code you gave in the alias. If aliases are unfamiliar to you, you might want to read this guide. That guide also explains in detail what the exclamation mark at the beginning of the alias does, but for now it’s sufficient to know that it makes the alias run the command through the shell from the root of the current repo, instead of through git from the current folder.
Your demo, revisited
Now, instead of opening your slide deck and showing code samples, you’re ready for some interactive demo-ing, but without the typos! To start, rungit checkout demo-start
and start running the sample, explaining whatever you do to the audience. When you’re ready to “move to the next slide”, just run git next to advance through the git history until you get to the demo-end tag.
Update: you can have it both ways!
A couple of people have commented (huzzah! I love feedback!) and asked for a similar alias for going backwards in the presentation. This is a lot easier in git, so there’s no need to go through the hassle of reading the list of revisions between two commits – just create the following alias:git config --global alias.prev 'checkout HEAD^'
Now, git prev will take you to the previous “slide”.