Useful links:

• Turing House Dojo
• Wimbledon Raspberry Jam on EventBrite
• Wimbledon Rasbperry Jam on Twitter
• Wall Ball worksheets
• Worksheets source on Github
• Me on Github
• Me on Twitter

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.

[UPDATE: People reading this might get the impression that my experience was negative. Really, though, it’s just that, for reasons outside the Conference, I was rushed and not really prepared and so didn’t enjoy things as much as I might have done. In other words, the negative tone is subjective rather than objective!]

If you track back through my write-ups of my previous PyCon UK experiences, you’ll see a bit of a trend: every year I say something like “This year was different”. And so it was this year. But this year it was differently different: it was different for the whole of PyCon UK, not just for me.

PyCon UK was famously the brainchild of John Pinner (RIP) and was organised and run by him and a team of Python enthusiasts from the West Midlands with help from elsewhere. But we had clearly outgrown our Coventry venue: in the last two or three years, the facilities have become increasingly strained.

So this year we were in Cardiff where Daniele Procida and others have successfully organised DjangoCon several times. Specifically we were in the City Hall which gave the conference more capacity and, I’m told, a slightly more responsive building staff over the weekend. I haven’t seen many facts or figures from the organisers, but certainly over 500 people were registered, in contrast to something like 300 for the last couple of years in Coventry. I don’t know if that’s because the size of the venue allowed more tickets to be made available or because Python has had a popularity explosion in the UK. I also don’t know whether it includes the Teachers’ and Children’s tickets, or those for the Open Day. Still: bigger.

I was unable to take any time off work around the conference. We have a highly important deadline fast approaching for a Big Contract and all shore leave was cancelled. I was especially sorry to miss the Education Day for teachers, which I’ve been involved with since its inception 4 or 5 years ago. So when I finally arrived on Saturday morning, I went straight into the Kids’ track which was running a Code Club session on Racing Turtles. I’d heard not long before the Conference that there hadn’t been much take up for the Kids’ Day, so I was very glad to see that the place was packed with children & their parents. Unscientifically, I’d say that most were between 9-12 with a small number above and below those ages. Probably rather more girls than boys.

After the break, there were sessions on Minecraft and micro:bit. I helped with the latter – I’m not a fan of Minecraft! And after lunch was a free-for-all in the Kids’ Track. The idea was to work on anything which had taken your fancy in the morning. I know from previous years that this sometimes works and sometimes doesn’t. (Generally parents of younger kids who are disengaged tend to take them away at this point). But for those old enough, or whose parents are keen enough, it was a great chance to explore possibilities. At different times there were quite a few conference-goers popping and out to offer help, although sometimes it’s not needed as everyone has their head down in a project.

I always enjoy the youngsters at Python. Of course, not every child gets as much out of things as they might do. Some of the worksheets needed a lot of reading and then a lot of typing which was daunting especially to some younger participants. (And laziness is A Thing, of course!). But it’s great when the children get the bit between their teeth and get excited about what they’ve achieved… and that they worked it out themselves, and debugged it themselves. And they’ve got an idea about where to go next.

For various reasons I spent relatively little time at the Conference proper. In particular, I only attended three talks, all of them given by people I knew and containing few surprises. It’s nice to see that several projects which I was slightly connected with early on have grown considerably and definitely merit a newer look: GPIOZero, PyGame Zero and PiNet. Like everyone else, I was impressed by the talk transcribers.The Conference venue was very pleasant and what I saw of Cardiff was welcoming – even though they were milking their connection with Roald Dahl, who’d been born there 100 years before.

People have spoken and tweeted about how welcoming and open PyCon UK was for them, and I’m delighted. For me, the experience was a mixed one, I think for two reasons. One was that I was there for considerably less than 48 hours: I arrived on Saturday morning and left mid-afternoon on Sunday. I had necessarily little time to interact with people and, once I’d helped with the Kids’ Track, I particularly wanted to catch up with Andrew Mulholland of PiNet fame, and to say hello to people I pretty much only see at PyCon UK. Floris wanted to chat about networkzero and, once I’d done all that, it was almost time to go. I had an hour in the glorious Quiet Room (aka Cardiff City Council Chamber) before heading off on a coach to Bristol followed by a 2+hr stand on the train back to London.

The other thing which muted my experience was how much bigger the Conference was this year, how many more people. Obviously, the fact of its being in South Wales will have skewed the catchment area, so to speak. But I was surprised at how few people I knew. Of course, at one level, this is great: the Python community is big and getting bigger; I’m not in an echo chamber where I talk to the same 12 people every year; people from the South & West who couldn’t get to Coventry can get to Cardiff. At the same time, I was irrationally lower in spirits (partly through lack of sleep, no doubt!). Normally I have no difficulty in just stopping by people to say things like “My name’s Tim; what do you use Python for?”. But this year, I just found it harder. So – sorry to people whom I appeared to be ignoring or who found me distracted.

In particular I realised how much I’d missed by not being there the previous two days: it’s a little like starting at a new school when everyone else has already been there a while. There’s nothing I could have done, but I regretted it nonetheless. Hopefully it’ll be better next year.

I look forward to seeing other people’s post-Conference write-ups and photos. I’m especially interested in people who didn’t enjoy things, or at least weren’t bowled over. Not because I’m reaching out for negativity, but because surely some people will have had an indifferent or even a negative experience at some level, and it would be good to understand why.

Well there’s more I could say, but if you’ve even read this far, that’s more than I expected. I hope I’ll see you there next year, and meanwhile enjoy the tweets.

I recently released a Python package called NetworkZero. It makes it easy to add a bit of network sparkle to an existing application or to create a wholly network-based application. There is an emphasis on usability in a classroom or coding dojo where things like network addresses aren’t always easily known or communicated between members of a team.

It’s on PyPI so can be installed by pip: pip install networkzero. The docs are on readthedocs.org and the code is available on Github.

What I’d really like now is feedback from teachers or people who run code clubs or dojos, jams etc. If you can actually install and make use of the code, then great; please let me know if it’s helpful. But before that, I’d like to know whether it *can* be installed, or even before that, whether the documentation makes sense and is useful.

Too often I’ve read the docs for some hopeful-looking module or tool only to end up asking: “But what does it *do*? What problem is it solving? And why should I prefer it over the several other existing tools in the same space?”. I hope that I’ve answered these questions, but of course I know the answers beforehand, so I can’t be sure!

If you encounter specific problems either in the docs or in the code itself, feel free to raise a Github issue. (Or, indeed, a PR). Otherwise, please ping me on Twitter and we can continue by email or other means if a longer discussion seems worthwhile.

Thank you for any feedback you can give, and I hope that NetworkZero can become a useful addition to your toolbox

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.

There’s a small trend in the UK-based education-related Python development world: creating easy-to-use packages and using the suffix “zero” to indicate that they involve “zero” boilerplate or “zero” learning curve… or something. Daniel Pope started it with his PyGame Zero package; Ben Nuttall carried on with GPIO Zero; and I’ve followed up with Network Zero. FWIW I’m fairly sure the Raspberry Pi Zero was named independently but it fits nicely into the extended Zero family. Nicholas Tollervey was even excited enough to create a Github organisation to collate ideas around the “Zero” family. His own Mu editor [*] although lacking the naming convention is, in spirit, an Editor Zero.

We’ve never really talked it out, but I think the common theme is to produce packages especially suitable for classroom & club use, where:

• The *zero package sits on top of an established package (PyGame, GPIO, 0MQ) which more advanced students can drop into once they’ve reached the bounds of the simplified *zero approach.
• The emphasis is on up-and-running use in a classroom or club rather than clever coding techniques. There’s a slight preference for procedural rather than object-based API (although everything in Python is an object but still…)
• Helpful messages: where it’s feasible, error messages should be made relevant to the immediate *zero package rather than reflecting an error several levels deep. This goes a little against a common Python philosophy of letting exceptions bubble to the top unaltered but is more suitable for less experienced coders

My own Network Zero is definitely a work in progress, but I’m burning through all my commuting hours (and a few more besides) to get to a stable API with useful examples, helpful docs and tests which pass on all current Python versions across all three major platforms. Tom Viner has been incredibly helpful in setting up tox and CI via Travis & Appveyor.

If you feel like contributing, the activity is happening over on Github and the built documentation is on readthedocs. I welcome comments and suggestions, always bearing in mind the Design Guidelines.

Any teachers I know are welcome to comment of course, but I’ll be reaching out to them specifically a little later when the codebase has stabilised and some examples and cookbook recipes are up and documented.

Feel free to raise issues on Github as appropriate. If you have more general questions, ping me on Twitter.

[*] I think Nicholas should have embraced the Unicode and named it μ with the next version called ν (with absolutely no apologies for the cross-language pun)