School Dojos, Raspberry Jams & Worksheets

Source

Useful links:

I’ve been glad to help out recently at a couple of events aimed at getting youngsters coding. The recently-instituted Turing House Dojo took place a couple of weekends ago at the recently-instituted secondary school of the same name in Teddington. And the 2nd Wimbledon Raspberry Jam took place yesterday in Wimbledon Library, courtesy of Albert Hickey and Cat Lamin, supported by Wimbletech.

(The Wimbledon one was a bit odd for me as I was born less than half a mile away and went to school to Wimbledon College. I used to go and work in the reference library after school when I was in the VIth form — and the reference library is now a big open space where we had show-and-tell events running yesterday. The workshop I was giving was in the former children’s library).

Each of the two events had a good showing of youngsters and parents. If I had to guess, the modal age was probably 10 or 11 for both events although with a fair spread younger and older. At the Teddington event, all bar one of the attendees in my group had a parent by their side; at Wimbledon, about half. (I don’t think it was required for Teddington that the parent participate as such, although they do have to be present on site; I think it just worked out that way).

The Teddington Dojo was basically a couple of hours of youngsters in different groups (Basic Python; Intermediate Python; Scratch; Arduino) going through mini-projects or worksheets. The Wimbledon Jam was a more varied affair: 1.30pm to 4pm with half-hour talks in one room, 45-minute workshops in another room, and a large central space with show-and-tell projects including robots, robot football, Flotilla, green-screen and others, all using Raspberry Pi in various ways.

At Wimbledon I helped out in a talk by Nic Hughes (”I’m a parent; get me out of here!”) and then floated for a bit until my own workshop was due. I had decided to use the Breakout clone (renamed “Wall Ball”) which I’ve written about before as the basis for the Intermediate Python activity. I wasn’t banking on too much Intermediate-ness; I was only going to assume that those attending had at least used Python. And even that wasn’t always the case…

I used the same worksheets at the two events, but I learnt a few lessons from the earlier Teddington event. So in the intervening week I tweaked the worksheets for the most urgent elements. As an aide-memoire for myself and in case anyone’s interested in the particular challenges, these are some of the things I picked up and — in some cases — addressed:

  • No matter how much time you allow for set-up, you’ll need more.

    I’d deliberately kept dependencies down: Raspberry Pis come with sufficiently recent versions of Python, PyGame and PyGame Zero that I didn’t need network access to install things. All I needed was: a browser to show the docs (of which, more later), a terminal window, and IDLE or some other editor. Even so, doing all that on 15 Pi’s, even if everything were to work, even with other people helping, can take quite some time. And everything didn’t always work…

  • No-one reads instructions in a workshop

    [This isn’t quite true unfortunately; the secondary rule is that people only read instructions when you’ve made a mistake in them and they don’t work properly].

    The version of the worksheets I used at the Teddington Dojo had an initial step which was intended to show just how much work the PyGame Zero loop is doing on your behalf, to the extent that your “blank file of code” is equivalent to this “15 lines of code” file if you were using native PyGame. Unfortunately, almost everyone didn’t read the explanatory text and simply jumped to typing in the 15 lines of PyGame code.

    For the Wimbledon Jam I just removed the example code to a section at the end which gave some information about PyGame Zero with a link for those who were interested enough.

  • Using the local network for documentation should be a good idea, but can easily be brittle before or during the workshop

    The worksheets are Sphinx-based, available on Read the Docs, and built locally on my laptop, which is connected to the local network. At the Teddington Dojo, the network segment they’d helpfully set up for us was so locked down that trying to access one address from another on the same, restricted, subnet was a no-no. Fortunately, the tech support firm who were also sponsoring the event with kit had a man on site who fixed us up. Even then there were some inexplicable routing glitches. At Wimbledon, using a repurposed TalkTalk router, the Pi’s seemed to be in contention with each other, meaning that none of them brought up the necessary webpage in the vital moments before the workshop. Eventually they started getting over each other and the page popped up successfully.

    To minimise further issues, I had built a singlehtml version of the page (although I would have preferred to use the step-by-step html version). As a fallback, I had the singlehtml version on a memory stick which we copied from for the most stubborn of the Pi’s at Wimbledon.

  • It’s best to walk through the very initial steps with everyone, out loud

    The first steps involve making sure IDLE and a terminal window are up and then creating an empty file in IDLE and using pgzrun to execute it under PyGame Zero. With the network problems, we’d not had time to go round getting IDLE/Terminal up and running before kids started to arrive. With hindsight, we had enough helpers for me to give the instructions out loud and get everyone running with the basics before leaving them to their own devices. At Wimbledon we only had 45 minutes so we didn’t want people to “waste” time bringing up the tools.

  • People will cut-and-paste, no matter what you say

    Although it’s part of the “How to use these worksheets” section (which I didn’t expect anyone to read) I didn’t announce up-front: “Don’t cut-and-paste”. I did remember to say that the purpose of the workshop was not to get them running a game, but for them to understand how the game ran and to make it their own. But several of them had cut-and-pasted wholesale before I realised what was going on.

    I was helping at a workshop in PyCon UK where the organiser had generated PDF with the code as images so you couldn’t cut-and-paste. I did consider this or some similar trick, but I’d worked quite hard to get the highlighting working, of which more below, and I didn’t want to jeopardise that.

  • Call the file the participant’s name

    This was always in the worksheet as I had experience from elsewhere: tell the youngsters to call their game “tim.py” or whatever. This is especially because, at the end, a number of them want to take the code home but haven’t brought a memory stick to copy it to. So I ask them to add their parent’s email address to the file and then copy the file with its name to a memory stick from which I can email after.

  • Highlight the code which is changing

    This is where I put the most work in. The worksheets are essentially a series of steps each with a section which shows the code, a section which explains the code, and a section which suggests changes you could make, sometimes with a hint as to how to go about it.

    Behind the scenes, these were using the Sphinx literalinclude directive to drop actual code files into the Sphinx doc which allowed me to test that the code was working and allowed for easy comparison of code versions. However, this means that the same code was appearing at each step, only more of it. Some participants made the mistake of typing (or cut-and-pasting) the entirety of the new code after their existing code. (Which will actually work a lot of the time but is very confusing to debug!).

    So I developed a simple Sphinx extension called literaldiff, cloned from the built-in literalinclude, but which added diff highlighting. (The built-in literalinclude has a diff option, but that generates a unified diff which is not an easy thing for beginners to read!). The literaldiff directive means I can simply give the new code, specify its “parent”, and see the new code formatted as usual via Pygments, but with the changed lines highlighted in yellow.

    The problem is that Pygments (which Sphinx hands off to for formatting) only has one highlighting mode, so I had no easy option for highlighting the few situations in which I was removing code. I resorted to a fairly hacky solution which involved prepending comment text saying “#DELETE –>” and hoping that it was obvious enough what was happening.

In both events, the parents and youngsters taking part were enthusastic and receptive. Some more than others, naturally. The 2-hour format of the Teddington Dojo meant that younger kids were flagging towards the end. The Wimbledon Jam had only 45 minutes plus a little overrun and all but the youngest got through to step 2 (moving the bat). Several finished the worksheet altogether and had moved on to the extension sections at the end, which was the idea.

I still have work to do with the worksheet format, but after two events, I’m fairly happy that it’s mostly workable and I hope to take it to other Jams / Dojos and make it available via readthedocs for other people to use.