I went wearing my Climate Code Foundation badge to Edinburgh to help out at the Software Carpentry Boot Camp hosted by EPCC and PRACE and led by the Software Sustainability Institute’s Mike Jackson and the Space Telescope Science Institute’s Azalee Bostroem.
This post is full of nitty gritty details. I’ll follow up with a higher level view and some distilled feedback.
Being a helper is fun. And also quite hard work; probably not quite as hard as actually giving the course though. The job is to lurk at the edges and then swoop in when someone is in danger of falling behind, and fix their problem regardless of what OS, environment, or editor they may be using. Keeps you on your toes. Co-helper Aleksandra Pawlik’s top tips blog post is spot on.
Here follows a rambling list of observations and thoughts.
If you say boot camp starts at 0930, people turn up between 0830 (me) and 0931 and you actually get down to business at about 0940. Recommendation: tell people to turn up at 0900 for an 0930 start. Entice with biscuits and/or promises of one-on-one installation and editor instruction.
Echoing many other comments from other bootcamps, without a doubt the thing that required most help was software installation. Windows and Mac OS X were significantly worse than Linux here (Cent OS making a special appearance just to make sure that Linux wasn’t entirely plain sailing). Next, eduroam; then probably whitespace (in both shell and Python).
curl is annoying (but it’s used because it’s installed by default on OS X). When trying to download a file from bitbucket, instead of giving some sort of error for a mistyped URL, curl would download the HTML of the error page. I would now recommend that people install wget.
Expecting people to accurately type in a 60 character URL just does not work. Perhaps a shortener would help. And more bundling so we have fewer things to download.
Installing software is still painful. Even when everyone is told that they must have installed software before attending and when I provided a script to test what was installed. To be fair to attendees, they had all acted in good faith and made honest efforts. We computer types are the ones to blame. The “highlight” of that for me had to be setting the system time to 2012-01-01 so that we could install Xcode on a Mac. Things like this are always easier to solve in person, sat next to someone (it’s a mystery to me why they are, but they are). We had tried to fix this on the mailing list a couple of days before the boot camp, with no success, but sat next to the computer in question it was done with a google search in a few minutes.
Up-arrow and tab completion are really useful. And it is really hard to tell when an instructor is using them, because text just magically appears on the command line. I don’t know how hard this would be, but it might be a good idea to try saying out loud every time you pressed up-arrow or Tab. Also, Control-A.
Quitting things. It is surprisingly easy to get stuck in something and not know how to escape. In shell you can accidentally start a command that takes stdin (such as “cat”). You can accidentally open an editor (such as “hg commit”) and not know how to quit; there seems to be an equal chance of it being vi or nano (what no ed?). You can be reading a paged file (“man grep” or “git diff”) and not know how to go back.
The thing about quitting is that there are lots of ways of doing it, and it depends on what you’ve done, which you may not know. Ctrl-C is a good choice, but it doesn’t work from the Python prompt, or a pager (it does something else useful in the case of Python, but it doesn’t quit). Ctrl-D is useful, but doesn’t work in an editor (and you may accidentally quit out of the bash shell that you’re in). At least nano documents that exit is ^X. Which is useful if: a) you read it; and, b) you know that ^X means Ctrl-X. vi does not reveal how to quit itself.
It’s probably useful to have a little “how to quit stuff” card. At least learners can try the different things and see if one works (I had to rescue people out nano, cat, man, awk, vi, and a shell string). Someone I spoke to had developed the coping strategy of closing the entire Terminal window if they got stuck in vi (good for their inventive skills, but a bit horrific).
On a slightly related note, to a first approximation it’s basically impossible for people to tell the difference between the Python, ipython, or shell prompts. Consequently they would type shell command into python, or vice versa, and be mystified as to why it wasn’t working. Probably useful to emphasise the prompt, and the difference between the different ones.
People seemed happy using nano even if they hadn’t used it before (though it is worth noting yet again that people still can’t quit nano, even thought it says how to at the bottom of the screen).
Was really hard to see the difference between purple and black (on screen).
Instructors should make their font really big. I can’t over-emphasise this. About 20 lines for the entire screen seems about right.
German keyboards have Steuerung key (for Ctrl), and they might not have a backquote key. Should probably teach $(stuff) instead of `stuff`.
(when programming in Python) left to their own devices, many people will call a variable that holds a list list, and one that holds a tuple tuple, and one that holds a dict dict. This is very natural, but a bad idea in Python. But it lets you do it anyway. (this was mentioned in the materials, but by then, many people had done it already; fortunately bad things did not happen (because we didn’t teach people that the list function can be used to make lists, and the
dict function can be used to make dicts)). Also, functions to sum lists will inevitably be called sum.
Although matplotlib was advertised as optional, in practice, as soon as it was being demonstrated, everyone wanted to use it, so they began to install it. With varying degrees of success. And of course the whole business of people not being able to follow along if they were installing something. Recommendation: do not have optional things.