Archive for Dojo

School Dojos, Raspberry Jams & Worksheets

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 “” 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.

NetworkZero at the London Python Dojo

The London Python Dojo was hosted yesterday by Hired, an unashamedly promotional move by the job search marketplace firm. Their offices are in Southwark, not far from Borough or London Bridge, a welcome change from the Old Street area where we’re often hosted.

After the usual beer & pizza, kindly provided by our hosts, we had a fairly quick round of voting which ended up with most people wanting to try out my Network Zero package, advertised and just pipped to the post at the previous Dojo. I gave a quick demo and explanation, pointed to the github repo and the readthedocs page and let people loose.

Amusingly, our hosts — not being a tech startup which most of our hosts are — didn’t really have an easy way for guests to access WiFi. They did offer us an ethernet cable. So, in a network-centred Dojo, we had a combination of link-local connections, tethered phones, and a wired internet connection shared via a OS/X hotspot. Apart from anything else, it really showed up some of the shortcomings of the NetworkZero approach, especially in the area of the UDP broadcasts supporting the advertise/discover mechanism.

Fortunately, everyone got something working after a bit of experimentation and several people provided PRs, raised issues, or just told me of difficulties they were having. Thanks especially to Sandy for bringing his undoubted networking expertise to bear on the innards of the project.

I had held off uploading anything to PyPI until after this event in case any obvious instability or major flaw were to show up. But this caused some surprise when people couldn’t simply pip install networkzero. (Fortunately it’s very easy to clone the repo and pip install -e .). I’ll be reviewing the issues & PRs and then, hopefully, publishing to PyPI.

I now want to put the code in front of teachers to get their feedback on its usefulness and usability.

Thanks, of course, to our hosts — Hired — and to O’Reilly who continue to support us with a book to give away at the end of the Dojo.

ESP8266 Dojo at Marks & Spencer Digital

I don’t usually reference chip names in my post titles, but this neat little chip was very much at the heart of yesterday’s London Python Dojo at Marks & Spencer Digital near Paddington.

For those who don’t know, Damien George, creator of MicroPython recently launched a Kickstarter to help development of MicroPython, specifically targetting the ESP8266. He was good enough to bring along a handful of boards with this chipset with a view to our hacking on them with Micropython. He explained to us something of the background of MicroPython (which is now his full-time job, hence the Kickstarter) and of the chip which seems to have a hit a sweetspot of power and price and is hugely popular among hobbyists far removed from its origins in a Chinese technology factory.

To honour Gautier’s turn as cat-herder, we’d been having a bit of Franglais badinage on the organisers’ mailing list. But then Nicholas, who’d arranged for us to use M&S, went one step further and our pre-meetup refreshments took the shape of wine, cheese & baguettes. (And some suitably French musique!).

Inevitably, when it came down to getting up-and-running in our different teams, there was a fair scramble as most people had to come up from scratch to getting a board flashed and then working with some kind of peripheral. Damien had helpfully set things up so a simple “import mswifi” would attach to the necessary WiFi, but after that we were on our own. We had two small teams with only one board but we did have a neopixel strip, so we set to doing something with that.

One stumbling block was that all of Damien’s demonstrations (via Serial-over-USB) had been on a Linux box and we had a mixture of Linux, Mac & Windows. There was an amount of faffing about to recognise and connect to the device on various boxes, but we ended up using a Linux box which led us to the next problem: everything has to happen in the interactive REPL, short of a complete reflash. So Tom was shuttling text to and from an editor and the embedded REPL via picocom. All this is happening quite quickly, and with little or no documentation on the (quite extensive) facilities which MicroPython brings on the device. So you become both pragmatic and inventive in your workarounds.

Finally we got a simple example where a Heroku-based Flask app allowed someone to set up an array of RGB colour values while the ESP8266 device would poll that website periodically, decode the JSON, and change the pixel array accordingly. It was rough and ready, but it worked.

Other teams did similar-ish things: one was trying to use an add-on screen to render the well-known Star Wars ASCII Art telnet feed. Another team had a small fan controlled by the device and managed, like ours, by a text file on a web server which was updated by Carles via an SSH session on his phone!

A number of us had ordered devices (at short notice) for the event, but most hadn’t received them in time not least because the same distributors are currently flooded with orders for the brand new Raspberry Pi 3. Hopefully, when they do arrive we’ll be able to get MicroPython working on them without difficulty.

You can see a few photos via our Twitter feed.

Thanks again to M&S Digital and Nicholas for hosting and for the French food, for O’Reilly for continuing to supply us with books as giveaways, and to Gautier for keeping everything on an even keel. And especial thanks to Carles who stuck with me when I thought I’d lost my Oyster card.

See you next month.

Coding with youngsters using pgzero on RPi: Part I

An eager young coder on Step 3

Some of you will know that several-times pyweek winner Daniel Pope has put together a simple framework called pgzero to sit on top of pygame. It’s Python 3 only and is especially aimed at educational use, and we spent the last London Python Dojo coming up with examples which used it.

Its main selling point is that it supplies behind the scenes some of the boilerplate code you’d otherwise have to write to get pygame up and running in a game loop. The simplest valid pgzero game is an empty .py file! From this, pgzero will produce a blank window of the default size, which will exit if you press Ctrl-Q. Adding a few “magic” constants will get you a window of a certain width & height, with a title and its own icon. After that, just define draw() and update() and add on_<event> handlers. And you have the makings of a game. There’s a built-in Actor class which essentially acts as a sprite, and easy-to-use image & sound loading. Plus some other goodies we didn’t use.

My team was responsible for the Breakout clone at the Dojo and I took it away and demonstrated it at the next evening’s Twickenham Coding evening, a friendly meetup in a room over a pub attended by teachers, code club leaders and educators. Altho’ we’d developed on my Windows laptop, I’d already planned to use the Raspberry Pi, about which more later, and I was very pleased when it ran on the Pi without a glitch at the Twickenham meetup. The message from the teachers I showed it to (mostly at the upper-Primary range) was: still too much code. But I got some useful feedback and set to work to adapt it.

My plan was to use pgzero and the Breakout game as the basis for a short series of workshops at the boys’ club I help to run in west London. But the lads aren’t into coding as such, and I knew from past experience that they could easily lose heart and get distracted if they didn’t instantaneously produce a Call of Duty lookalike. So I aimed for two things: cutting down the code complexity so there were as few concepts as possible to get across; and breaking it up into chunks which I could present one at a time, each building on the code from the previous chunk.

The result, for the impatient, is in the piece-by-piece branch. But first, there are some yaks we need to shave.

The setup


I was keen to use the Raspberry Pi for this.

  1. It’s cheap and so the club can afford to buy several of them; and one or two of the lads have their own
  2. It’s quite different from the (often literally) black box computers they’ll generally use so they don’t immediately see it as a mere entertainment source (ie they’re more likely to enter into a spirit of producing rather than only consuming)
  3. In later sessions I hope to introduce some simple electronics via the CamJam EduKit and similar things where the RPi excels
  4. It’s a Raspberry Pi! Everyone’s talking about them. Parents are keen on them. It creates a buzz around the activity which would be lacking if I’d used some other, equally capable, platform

We already had one RPi, an original Model B; someone tweeted that RS had Model B+ going at £16 each which is well within the budget I’d set for a couple more. Fortunately we have a number of monitors (VGA), which would otherwise have been beyond us to buy. The excellent PiHut also had the necessary accoutrements at affordable prices.

As everything was taking place in our club building, which isn’t networked, I used a spare laptop setup with lubuntu to run dnsmasq for a very easy local DHCP / DNS solution. The Pis were all wired to a simple 10/100 switch.

Expecting about 6 people, I’d planned to run in a classroom mode, with my laptop able to view individual screens if anyone needed help. I’d also thought of having my screen “broadcast” to theirs. I was a little surprised that there doesn’t seem to be a definitive way of doing this. iTalc2 looked promising, but needed a fair bit of setup. There are several commercial solutions, so presumably schools are able to budget for this kind of thing. In the end, I installed x11vnc on each of the RPis. But with only 4 boys in the end, and another tech-savvy leader, it was more sensible to physically wander around to help. I do plan to look into the reverse: broadcasting my screen. We don’t have any kind of projector at the moment, and in any case I’ve never found that a satisfactory solution for showing code.

The Software

The focus of the first sessions was the use of pgzero to produce the simple Breakout clone mentioned above. But first I had to bring the complexity of the code right down, taking advantage of the fact that pgzero hides away some of the messier boilerplate. These were first-time programmers and I would be throwing a lot of new concepts at them in a fairly short space of time. (Fortunately they’re all in Years 8 to 10 at school so I didn’t have to explain too much about coordinate systems and vectors).

Responding to an issue on the pgzero tracker, I’ve submitted a PR for a pure Python implementation of the pygame Rect class. The ostensible need was to allow for floating-point size and position changes. But a secondary effect, of more immediate use to me, was the possibility of adding arbitrary attributes to a Rect instance, such as colour and direction.

So the boys were working off my fork of the pgzero repo, installed via “pip install -e .” to track the development version. They were also unwittingly working off the piece-by-piece branch of my fork of the breakout code, although I was feeding it to them a piece at a time. I’d made use of the pgzero Rect to be able to add colour and direction as attributes, which did away with the awkward global variables of the original codebase. The result, though I say it myself, is about as stripped back as you can get while still actually doing something. The global blocks setup is a little clumsy, but the alternatives I tried were no better.

The Workshop

I’d set up our own Raspberry Pis and for the one lad who brought his own I did the necessary config while they were playing football outside. I persauded them all to close down Minecraft (”Look! It’s got Minecraft!”) and Mathematica (it’s got a shiny red icon, just asking to be pressed…).

I got them all to open a terminal window and cd to ~/work/breakout where I’d cloned and then started a new branch with no files. They ran IDLE3 and started a new file called “” (or “” or “” depending on the skill of the typist). I got them to run pgzrun against their new file and use Ctrl-Q to exit the resulting window. So far, so good.

From this point on, I fed them one step at a time on paper from the piece-by-piece branch. I’d considered other options: projecting the code, having them “git checkout” to the right tag, even reading it out or live-coding it myself. But this seemed the most trouble-free option and, basically, it worked.

After they’d got each update working, I highlighted a few new or repeated features. (”That’s a name; you defined that earlier”, “That’s a function; you run all that code in one go by using the function name”) etc. One of our other club leaders, Albert, is also a professional coder (PHP) and was very able to help so between us we kept the pace going despite the variations in typing ability.

At the end of the first session they’d reached step 6 out of 12.


What worked?

  • The pacing was basically about right. One of the steps had a little too much code in it, but I needed to have a change of some sort at the end of each step, and there really wasn’t anything I could do about it
  • I was very pleased the way in which the boys worked out the obvious typing bugs; they very quickly spotted when uppercase/lowercase was wrong or when they’d misspelt a name. I very rarely had to point out anything obvious.
  • Step 4 (when the bat responds to the on-mouse-move event) was the winner. Simple as it was, the boys loved the interaction. When someone got it slightly wrong (bat.centrex = y) causing the bat to move horizontally as the mouse moved vertically, they all wanted to try it. When I suggested they swap both coordinates (bat.centrey = x; bat.centrex =y) they’d have stayed there for ages.
  • I encouraged them to change things (the screen size, the colours etc.) and I was pleased that one lad, after I’d explained how names work, changed his “bat” and “ball” names to something else — altho’ this caused problems later when I was helping him debug as I couldn’t tell which object was which!
  • Although I’d had planned for a two-hour session, the 90 minutes we ended up with was about right

What didn’t work?

  • I should have brought step 4 in a little earlier, perhaps creating the bat before the ball and then letting it move
  • Several times I had to draw things up on the whiteboard to illustrate the coordinate system etc. This probably would have worked better with a screen broadcast from an IDLE session.
  • I had intended to have them try things out in IDLE, starting from a “from pgzero.builtins import *”. This didn’t really happen, although I did get them to do some experiments with the modulo operator when explaining the colour looping for the blocks.


Overall, I was very happy with the way it worked. I had four non-programmers dive in and basically enjoy themselves. I’m hoping to use the next session to finish the game and get them to play around with bells-and-whistles (make it go faster, have a bat on each side-wall etc.). After that I hope to connect up some simple LED / buzzers to react to the game.

FWIW I’d love to do a networked version where the ball disappears off one screen and appears on the next. Each person’s ball could be colour-coded and a ball will only destroy blocks of its own colour, so you have to use balls from your neighbour’s games to finish your own. Or something. I love the idea of the social aspect that would introduce, as well as the fact that someone could have two or even more balls in play on their own screen.

Raspberry Pi-themed Dojo at BAML

Yesterday Bank of America once again hosted the London Python Code Dojo, this time at their St Paul’s offices. I don’t know what the normal use is for the room we were in, but it felt like a cross between a banqueting hall and something from Khazad-dûm. Very grand and with nice AV facilities: one big screen, several smaller screens and microphones. As is customary, the hosts provided beer & pizza, but as usual with BAML, in a somewhat classier mode, with slices and plates and a variety of drinks served by staff. All very much appreciated.

They’d also done all the setup, so we had 8 or 10 Raspberry Pi rigs with screens and enough keyboards and so on to go round. The networking took some doing and ended up being a cat’s cradle of very long ethernet cables all routing — I understand — through one all-the-data-you-can-eat phone connection! Which worked fine.

Al Broomhead and Tina Zhang gave a joint lightning talk on a couple of projects they’d been involved in on a recent Hack Day. Ben Nuttall from the Raspberry Pi Foundation had been good enough to come and join us and gave an overview of some of the resources they already have to help people use the RPi and to encourage any contributions the evening might bring forth.

Slightly differently from our usual approach, we had several different projects going during the evening. The idea was to come up with something which showcased the Raspberry Pi in some way. In the end, we had: a very simple approach to a door-challenge mechanism; a on-screen 7-segment display; an automated light which reacted to the hue of a chosen image; a text-adventure interface to Minecraft (”go forward; dig 5″); a morse-code reader using a Pibrella; and a couple of things which I’ve forgotten (sorry; someone ping me a reminder…).

At the end, of course, we had a name-draw for the book donated as usual by O’Reilly. And thanks go to BAML for their continued sponsorship of the Dojo. And to the BAML guys (and I think it was all guys) in particular for all the prep and tidy-up work to get the kit in place for us.

It was nice to see new people as well as the familiar faces. If anyone who was there wants to contribute their code or ideas to the Raspberry Pi Foundation, get in touch with Ben Nuttall. You can see a few photos via the @ldnpydojo twitter account. If any more show up we’ll try to retweet them.