for all who can’t wait, you can find gmove here
All of us who do code demos occasionally know that very simple methods, may it be copy and paste, real typing or just presenting finished code, all have their shortcomings. For a code demo to have real value, you should have a story to tell, and let the user see a system evolve by modifying it, empowering him to do the same.
Last time, I had a very simple idea. The idea was: using git and tags for a code demo. Basically you develop your base system to show in any git repository. Them you tag that one version. I use step + stepnum as a convention. So for me that base system I want to present to the audience it step0. Then you develop the story for your demo, from simple changes to the complex one. Each change you want to demonstrate get’s a own tag until finally you finished your story.
# .... hacking on first demo loop start
git add .
git commit -m "initial version"
git tag step0
# .... hack verst improvement
git add .
git commit -m "improvement"
git tag step1
# loop on that untill you finished
git tag #now gives you the list of your tags
On presenting you now have the nice thing that you can just go back to step0 and start showing the system. You can even type the code changes you prepared while you present your changes. If the stuff to type is too much, or you made a mistake just switch to the next tag.
git checkout step0
# present inti system
git checkout step1
# present first improvement
git checkout step2
# and so on....
Now there are some small nifty little things left here. For me f.e. I really like to type some things by hand on a demo, because I really think you get more out of it if you see the crucial things being typed, giving your brain a longer chance to understand those parts. Also some systems like XCode have the bad habit f.e that your storyboard file change in git as soon as you open it.
Now when you checkout a tag you are in detached space. Very roughly that means you are not ment to make changes. But that is actually exactly what I do and probably the system does anyway. If I then checkout the next step git will be angry and react with refusing it. What can you do than. So either you do a
git checkout -- on every file discarding the changes, or simpler, you just stash your changes (and then probably throw them away).
so, you can do a
git checkout step1
git stash clear #or pop if you want to keep that new changes...
that works now, but actually introduces a new problem: you spend quite some time in the console, while actually you wanted to show the audience your system.
For not typing that much I wrote a python script. The actually completely ingenious gmove. Almost to small to make a github repo for that. In default gmove just makes the one above, stashing, checking out, and clearing the stash. usage is:
gmove -t step0
While stashing and clearing your changes with gmove works fine, I tested that, the script is a little bit alpha. Meaning while writing that post I did not test some use cases build into the script. Feel free to fork it on git and send me a pull request by the way. So what I did not try but should work is:
gmove -j -t step0
git stash pop
ok, that would keep your stash intact. You would use that if you found in the demo that you made any new changes not in your original story, and want to keep them and reapply them. just keep in mind that you might have a merge every time you do that. Also I will change gmove in the future to support that in one command I guess (maybe -p).
So, if I have time I will make a screen cast from my last cocoaheads talk, so you can see the tool in action….