Pages

Stepping through a Code Demo

One challenge to delivering coding presentations is the trade-off between:

Showing actual real code that developers can get their head around

VS

The time it costs to actually write it in front of them (debugging missing commas included).

Here are some of the ways I’ve seen to side step this issue in previous coding presentations I’ve attended:

Start with the full app. Study relevant sections.

Start with the full app, but mostly commented out. Uncomment section by section.

Start with a blank app and a notepad document with all the code you’ll eventually want. Copy and paste code section by section.

Start with the full app and use Unit Tests to step into relevant code.

Here is one more that I will be trying out:

Utilize revision control software to have each state of the code base represented by a different commit. Then step through the commits.

If executed well, I really like this last one. It avoids having too much information. Especially if content is new, it can disrupt the noise to signal ratio if attendees are thrown into a world with too much code. It also helps reduce copy and paste errors that might occur and the overall time it takes to update the code base. The beautiful thing is that each state of the code base has a known success. There is never the possibility that you have forgotten to uncomment that one critical line.

You can easily step back through the entire code base to rehearse. What’s more - so can participants when they get home. When have you ever left a coding presentation having been able to re-create every single step performed by the presenter?

Stepping Through Commits

Since this option definitely has the highest startup cost, I’ll detail some of the items along my learning curve.

I’ll preface this by saying that I’m using GitHub as my RCS of choice.

Also, I’ve never stepped through each revision in an entire codebase before!

It’s not something that is covered by most of the use cases for revision control. Of course, it’s a perfectly acceptable use, just not one that you’re likely to need when developing software.

The easiest way to change your working copy to a specific version is to use:

Or we can step back through previous commits by using HEAD~n where n is the number of commits we want to step back

The problem is what we want to do is step forward through revisions. While the ~1 selects the parent of the current revision, there is no native function to select its child.

Note: This is partly because of the way that a Directed Acyclic Graph (DAG) works. Each commit knows who it’s parent is, but not which children might be attached to it.
For example, [B] knows it was branched off [A], but does not know who it’s child is (in fact has two children!)

Part of this complexity can be avoided as I’m looking to have a relatively straight forward linear revision history.

In case you’re new to Git/Shell, let’s break this down a little.

The inner expression git rev-list will show a list of revisions. By specifying any two revision id’s joined by two periods, we’ll get a list of all the SHAs in between them.

So, for the following revision history:

HEAD
↓
A -- B -- C -- D -- E (master)

The command:

git rev-list HEAD..master

Will Return (with the most recent first):

E
D
C

Then by using the pipe operator in powershell, we can grab the last value by piping in | tail -n 1

So this command:

git rev-list HEAD..master | tail -n 1

Will just return the commit we want:

C

In order to make this into a one liner, we’ll need to wrap the query so we can pass the output into our checkout command. We can use the $( ) SubExpression operator to return a vector value, giving us the original equation.

Adding an Alias

If we’re using this a lot, it might look prettier to alias the query.
We can add a new command called child-sha to our local config file like this: