Moderate Realism (Posts about Python)

Teaching with Mu

Tim Golden — Sun, 21 Oct 2018 15:44:22 GMT

At the club I help to run I started this week what I hope will be a regular coding session using Python and, of course, the Mu editor. I'm competing directly with the regular football slot, so I'm not expecting to get many lads. Yesterday I had three Year 8s.

They were at different levels of beginnerhood and I had the usual range of problems getting everything up and running, starting from the fact that the room I'd hoped to use was occupied by older boys as an overflow changing room. Anyhow, we had a good session, created a simple fizz-buzz game and spotted a couple of minor bugs in Mu itself. With their parents' permission I hope to get them onto Github so they can follow the progress of "their" bugs.

Really through force of circumstances we ended up doing a sort of paired programming. What you can see in the picture is everyone using the one computer (my laptop). We attached a screen and a keyboard and the lads on my right (your left) are using those, while the other lad is using the laptop itself. I'm glad to say that they quickly got used to the discipline of leaving the keyboard for the pilot only with the various co-pilots just chipping in to spot problems. It ended up being not unlike the Sabotage activity which @teknoteacher advocates.

In spite of the Raspberry Pi on the table, we're not using an RPi. The lad on my left is already a Linux user and the lad on my right was keen to understand how he could use Linux and whether a RPi could replace his somewhat underpowered laptop. Depending on how things look I might start using an RPi next week.

I'd hoped to try out the Kano Pixel Kit which we were given at the recent Mu Moot, but I didn't have enough time to prep up for that, so hopefully next time...

The Mu Editor

Tim Golden — Fri, 19 Oct 2018 08:06:29 GMT

Background

If you follow me on Twitter you'll not be surprised to hear that I'm involved in the development of an editor called Mu. As a matter of fact I've been loosely involved with it more or less from its inception as an offline editor for the Python micro:bit effort.

When I first helped out with a bit of bug-fixing and the like, I was doing so out of a sense of community helpfulness and because of my friendship with Mu's originator and principal developer, Nicholas Tollervey. I didn't have a huge investment in the project myself and I wasn't honestly sure how far it would go.

While I still "Watched" the project (in the Github sense) I had nothing to do with it really until about a year after that first commit when someone raised a bug about a disappearing selection marker when using the keyboard. Now it happens that I know the person who raised the bug for reasons completely unrelated to Python, Mu or anything else. And the simple fact of that coincidence (plus my interest in what looked like an obscure issue) led me to dive in and fix that particular problem.

And I've watched the project get picked up and used by teachers and others who appreciate what it does. As ever with these sort of things, it also helps if you get mentioned by people like the Raspberry Pi Foundation, the micro:bit Foundation, AdaFruit etc.

Last night was the 2nd "Mu Moot" (the 1st was a meetup of developers in the, appropriately punny Mu-seum Tavern). There were overlapping sets of Developers, Users and Educators together at Kano. And that get-together led me to talk a little about Mu and why you would use it.

Why would you choose Mu?

I must be honest: this was my first question as well. There is absolutely no shortage of editors out there of all shapes and sizes. Even though Mu aims squarely at the education market, there are other offerings out there which do the same.

One answer to get out there right away is: you might not. There's no hard-sell: if Mu works for you in your situation, use it; if it doesn't, use something else. In fact, one of the Tutorials is precisely about Moving on from Mu. It's never been an aim of Mu to be an all-embracing editor. In fact, it's been a specific aim not to be an all-embracing editor. It's right there in the first paragraph of the README.

But now, having encountered in person and online, people who have said that Mu helps them, I think I would put forward the following points which seem to be headline reasons:

It's uncluttered
It makes working with the micro:bit easier
It makes working with PyGame/Zero easier
It makes working with Python easier

You can see a pattern emerging there, can't you? Although I wasn't involved, I'm aware that Nicholas has taken a fair amount to time to speak to teachers and other interested people to see what they need from an editor. And the point is that, as developers, we might be surprised at what a teacher considers important. (A "teacher" here will generally refer to a Secondary School teacher in a classroom situation, but could also include out-of-school clubs, Code Clubs or anyone trying to work with beginner coders, young or old).

Mu for teachers

The point is that most teachers don't want to have to deal with the mechanics of installing Python, installing various support libraries, working out where on a filesystem an editor is storing its files, how to run those files and so on. They want to get their pupils writing code which they can run as easily as possible.

Of course, in the abstract sense, we all recognise that there's a learning experience to be had there. Learning how to install Python and what the pitfalls are. Or even learning to build it from source with its dependencies. Learning about pip and about virtual environments. Learning about filesystems and running from the command line.

The trouble is that most teachers are dealing with a class of 30 students who may or may not be even marginally invested in the subject. A dedicated after-school club or lunchtime session could be run for those who are keen to learn. In a lesson situation, the teacher will want to get up and running just as soon as possible.

Batteries Included

I'm not sure who coined the expression but Python has long been described as coming with "Batteries Included". The so-called Standard Library has code to do a lot of different things. Over the years, especially as the package ecosystem around Python has grown a lot, there's been a bit of a shift of emphasis towards preferring 3rd-party packages which can iterate faster and keep up especially with security rather more easily than built-in packages. But Python still comes with an impressive spread of functionality.

If you download one of the Mu installers you also get an array of useful libraries, in addition of course to a full version of Python 3 with all its standard library. Of particular interest are: support for the micro:bit and Adafruit products, plus Pygame Zero. The point isn't that you couldn't get these things otherwise. But that, again, you're saving the teacher the headache of installing those things with their dependencies. (And of possibly having to negotiate the school systems admin).

Not just us?

I've already noted that Mu is trying to meet the needs of an audience of educators, not just (or not even) an audience of developers. And that, insofar as it has managed to do that, it's by dint of actually going out and asking and observing working educators or those (such as the Raspberry Pi and micro:bit foundations) who support them.

But another "not just us" constituency are those for whom English isn't a native language. I can't find the initial Tweet but a few months ago, Nicholas started to call out to people to submit translations of the editor text (the buttons, the help and so on). Glancing down the locale directory in the source, I can see that we currently support: German, Spanish, French, Japanese, Polish, Portuguese, Chinese, Vietnamese and Swedish. And English. There are instructions for how to go about translating and most of those translations have come from -- or been improved by -- people outside the core team. If you feel you could offer a translation, please check the open issues list to see if anyone's already offering, and then try to follow the instructions and ask for help if you need it.

But there's even more beyond the language translations. We're conscious that educators are often dealing with a range of difficulties from visual impairment to dyslexia and other learning difficulties. There are several issues which discuss things like problems with screen-readers or specific fonts & colours for dyslexic coders. To get a real-world trial, Nicholas worked with Ben Mustill-Rose who is severely visually impaired and who attempted to use a screen reader to work with Mu.

In short, as a project, we're keen to support as many people as much as we can while trying to keep to the spirit of a stripped-back editor which gets on with the job and then stays out of the way.

Bells and Whistles? The Rule of Three

Mu has always had this aim of being a simple editor. Uncluttered, just enough buttons to do what's needed in a classroom situation, no multi-level menus, support commonly-needed libraries. But people always want something else, something which isn't supported. The fallback answer is always: if you're looking for an editor to do X plus Y then Mu probably isn't the editor for you.

Ultimately it'll be down to the developers, and to Nicholas in particular to make a call on whether to go ahead with an addition or not. But for a long time, he's had a practical metric: the Rule of Three. If three people independently request a feature or a change, we can consider it a serious prospect.

Of course things are added for other reasons sometimes. Or not added even if three people want them. But having a rule of thumb helps to set the expectations of people wanting to add bells and whistles.

The Future?

At yesterday evening's Mu Moot, Nicholas outlined a sort of short-, medium- and long-term vision for Mu. One concern of his is to raise the "bus factor" of the project, which currently sits just above one. It's not that someone else couldn't take on the technical aspects of Mu; I think anyone of us who have contributed to the codebase could probably do that, albeit with a little support in niche areas. Rather, the whole dynamic of the project is currently driven by Nicholas and if he fell away, the project probably would too.

But we also need to get more people using Mu in order to get the feedback of whether it's genuinely useful for a wide range of people -- primarily educators, but in fact anyone who finds a use for a simple editor with some useful side-functionality, such as talking directly to micro:bits or running Pygame Zero code directly or showing plotted data directly in the editor.

If you want to see what people are doing with Mu, have a look at https://madewith.mu. If you want other people to see what you're doing with Mu (even if it's just "using it in a classroom to get stuff done") then submit your project and/or just ping the team and let us know about it.

The good thing is that people are contributing not just questions & suggestions but also code changes and language translations. Companies like Adafruit and Kano can see the benefit of hooking up the kit they sell with an existing editor which can be easily extended to use it. And there's talk of a web mode using, perhaps Bottle to produce simple web-based projects for A-level students.

And what else?

Well the best comment made last night was from Jon, a teacher at a school in Croydon, who says that his pupils want the Mu logo to be a cow rather than a snake, because you're "Coding with Moo". (Or a kitten, apparently, because then you're "Coding with Mew").

Following up from stepping back

Tim Golden — Mon, 15 Oct 2018 05:02:22 GMT

Thank you to those who responded to my previous post with thanks and words of encouragement. Just to be clear, I'm not stepping back from Python altogether; far from it. I'm simply giving up certain background responsibilities which I've found difficult to sustain. I realise that, by doing so, I've left the others who continue to manage those tasks more burdened than before. So, again, I encourage you to offer to help on whatever basis you think you can manage.

Python has grown. When I entered the community about 20 years ago, it was a moderate-sized mostly technical language community. It's always been growing in popularity, but over the last 10 years it's reached the point where it's used and relied on -- directly or indirectly -- by millions of people around the world. Indirectly by virtue of its use in some very big-name companies. Directly because it's become the go-to language for science and data projects. And it's the text-based programming language most likely to be taught in secondary schools in the UK and maybe elsewhere, especially with the encouragement of the Raspberry Pi foundation and its resources. The audience is huge.

Because of its size and significance, many people assume that there's a commercial organisation running things. Or at least a well set-up NGO or institute or something. But there isn't. There is a series of semi-detached volunteer teams who typically only interact because one or more people on one of the teams are also on one or more of the other teams.

The webmaster@ address is the fallback communication point for the Python community. It handles all sorts of queries. There are general requests for help; requests from official bodies for us to complete some complicated export license document; more questions about the cost of licenses than I care to think about ("No really, it's free; yes you can get a bulk discount of 100% because IT'S FREE"); questions about copyright and logo use; technical questions; questions from school administrators who don't grok the new Python Windows installers; people who've bought a car security system with the brand name "Python". And all those queries are fielded by about three people (now about two people!) working with whatever time they have available.

The Python mailing list (also comp.lang.python newsgroup) is the "official" general-purpose communication channel for questions about Python. But it's a mailing list / newsgroup, both of which are slightly ageing concepts. Its origin as the forum of discussion around a mostly technical audience still informs its general attitude. And, by its nature, it assumes that you're interested in joining a community and not simply asking a drive-by question. There's some experimentation going on at the moment about using a Discourse or a Zulip instance or both, which I think might be a move in the right direction for the wider casual audience.

People raise issues on https://bugs.python.org asking questions about https://pypi.python.org; they write to webmaster querying why they haven't received a confirmation email when they signed up on the https://python.org website; they write to mailto:docs@python.org when downloads aren't available on https://docs.python.org for the latest version of the documentation; and they raise an issue on the website tracker when there's a spelling mistake in the online documentation. And although I've put those examples forward as mistakes, it may not even be obvious to you why those are mistakes. python.org contains quite a few silos.

The easy majority of volunteers behind these various forums are technical people who've stepped up to help. Which is clearly very much to their credit. Back in the day, most people posting through Python forums would also have been those with a technical background who'd chosen to use Python: students, professional programmers &c. So there was an easier meeting of minds when it came to answering questions and giving advice. Nowadays they might be, for example, schoolteachers or data scientists who use Python as a tool (for teaching or analysis) but who have no knowledge of or, really, interest in the underlying mechanics of the language or its community. Or even schoolchildren looking for help with their homework or with a personal project. So there can be a mismatch between the people asking questions and those answering.

On top of all that, we're increasingly in a world where Codes of Conduct are needed, if only as a reference answer to "Who says I can't do that?". But that puts a significant burden on list owners and forum volunteers who, in their spare time and often without much guidance, need to respond authoritatively to complaints and responses.

What am I suggesting? Whatever I suggest runs the risk of sounding like "We really should be doing..." when I've just announced that I'm stepping back from doing things. However, in a spirit of constructive criticism I think I'm suggesting:

That the PSF take an holistic view of the different public-facing python.org properties (including bugs.python.org, pypi.python.org, python.org itself, the more public Mailman2/3 lists on python.org, planet.python.org, webmaster@python.org) with a view to creating a common understanding of the roles and responsibilities of those volunteer teams who manage those resources, including cross-fertilisation of ideas and a common meta-forum for dealing with misdirected enquiries and CoC issues. Perhaps even synthesising a single team to handle requests coming in through all of those and other channels.

Just as I was backing away from my python.org responsibilities, I think there may have been the beginnings of something like this: a meta-list for list admins. If there was, then I think that's a step in the right direction. Without question, there are wider technical issues which could be addressed given time and resources (eg the number of accounts needed to operate on different python.org properties). But I recognise that there are technical and even political challenges to making that work to everyone's satisfaction.

I don't know what's in store for Python in the future. Maybe it will continue to grow and evolve; maybe it will be overtaken by a new kid on the block. I'm not saying that it doesn't matter. But what matters more is what Python can offer now for the many, many people who find it useful, or who merely find themselves using it, and want support from its community.

Stepping back a bit from python.org

Tim Golden — Sun, 14 Oct 2018 16:46:54 GMT

The fact that you hadn't noticed is a testament to the number of people working behind the scenes at various facets of python.org. For some years I've been part of a number of teams who sit behind things like the webmaster@python.org address or planet.python.org. Or the python-list@python.org mailing list (mirrored to the comp.lang.python newsgroup). Plus a bunch of other lists including python-uk, python-win32, python-announce, core-mentorship, python-checkins, speed and a couple I can't even remember right now! Plus I'm an admin on the python.org website.

I took on those roles because I felt they were ways I could contribute to the community without too much commitment of time. Like most people, I have a full-time job (not Python-related) and some serious commitments outside work. And I rarely have the concentrated spell of time available to me which I need to do, say, core development work for Python. But most of those roles only require answering or dealing with the occasional email, sorting out the odd admin task, or approving a github PR. I can do each thing usually within a few minutes of receiving the email, even if I'm at work. So I felt that I could help the Python community without disrupting my life.

And I could. I stepped up to those roles at different times, but I've been helping out in that way for between 3 and about 10 years. As have other people, obviously. Sometimes because I or others have put out a call for help; sometimes, they've just volunteered spontaneously. In most of those roles I've been part of a small team which doesn't require much intervention or coordination.

But recently several things have happened more or less at once: a heavier workload in my dayjob; a move to a greater out-of-work commitment; some complications with one particular of those python.org responsibilities which required a much greater input of time and thought. And I realised: you don't have to do this. I'd done that thing where I felt responsible for helping out a community to such a great extent that I'd over-extended myself.

I'd intended to scale back gradually what I was doing on python.org, but once I started, it became easier to just step back from everything. In all but about two cases I was part of a (small) team so I was able to let them know I was stepping down and leave the situation in good hands. In a couple of cases I had to reach out to someone else who was or had been involved to ask them to take over a certain task.

What surprised me, although it shouldn't have, was the effect on my Inbox. Suddenly, I was getting no emails for hours on end. I actually thought there was a problem with the mailserver at first; it was such an unfamiliar sensation. I think the fact that I found it a relief was a clear sign that I'd made the right choice.

Let me be clear about this: I stepped back because I needed to, not because of any sour grapes or misgivings about python.org activities. Or any personal clashes with anyone. Or any other reason other than: I felt I'd done my stint. Cursum consummavi and all that. As I said at the beginning: the fact that you had no idea I had stepped down, nor that I had even stepped up in the first place is a testament to the unsung work which goes on in every community, the Python community no less than others.

So... first, let me thank every person working behind the scenes in the Python community just to oil the wheels to make everything work which people take for granted. And secondly, let me invite any of you to offer your services on whatever basis suits you to help out in some way.

Potato Prints at the London Python Dojo

Tim Golden — Fri, 08 Jun 2018 12:22:37 GMT

Potato Prints

So I couldn't resist the obvious pun: the London Python Dojo was hosted yesterday at Potato, a Django-based web agency somewhere off Tottenham Court Road. (Which is a bonus for West Londoners like me). And after the initial round of pizza & beer generously provided by our hosts, the choice of activity for the evening was to generate ASCII art from images. And so I feel justified in perpetrating the punny title.

It was a good choice for a challenge. We allow something between an hour and a quarter and an hour and a half to get all the work done. If something's too complex you'll hardly have worked through the documentation before time is up, which can be a bit dispiriting. (This happens when we select tasks like "Use a neural network to generate Trump-like tweets"). Occasionally the task is too easy, but this is better as there's lots of scope for what teachers would call "extension activities" -- ie bells & whistles.

One of the joys of the London Python Dojo is that it's up to each team to interpret the challenge as they wish. Not always but often someone comes up with an off-beat interpretation or solution which adds to the fun. Last night's involved a team who used the potato emoji as their character cell for any faces which OpenCV could recognise in the underlying picture.

Our team had myself & Tom Viner, the evening's cat-herder, plus Jen & Chris, two less-experienced Pythoneers. We split into two, Tom & Chris using Pillow to analyze pictures for brightness, while Jen & I mapped "bright" pixels onto particular ASCII characters on a 64x64 grid structure. You can see the results of our joint efforts on Github: https://github.com/tomviner/ascii-art.

I was pleased to able to use my Dojo Board library again. It does nothing which you couldn't do yourself in a few minutes, but it does make that part of the work a piece of cake. Naturally, I did have to extend it a little to suit our needs -- scratching my own itch while eating my own dogfood!

As always, the atmosphere was good; the hosts were very welcoming and friendly; O'Reilly continue to support us, month after month, with a donated book.

We're on the look-out both for venues to host & sponsor the event, and for people willing to cat-herd for an evening. Please let us know via email or Twitter if you're interested in either of those things.

The Dojo Board

Tim Golden — Fri, 02 Feb 2018 11:08:25 GMT

Trying out my Dojo Board

[Pictures courtesy of Tom Viner]

The February 2018 London Python Dojo was hosted by SohoNet to whom we're grateful not just because they hosted, but because they stepped up at short notice when our original venue had to withdraw. It was nice to see quite a few of the SohoNet team at the Dojo. Of course, this was all courtesy of veteran Dojo cat-herder Tom Viner who works there at the moment and arranged everything on the day and beforehand. (And who also won the month's book from O'Reilly who have donated generously to us every month for the nearly 10 years that we've been running this Dojo).

The atmosphere was great as usual, and it's good to see a nice mixture of old hands, semi-regulars, and newcomers come together. Our Patented Voting Method which, together with the Team Numbering System, surely deserves its own Wikipedia page, raised a few laughs as usual. Plus some confusion - also as usual.

I'd offered to give a Lightning Talk about my Dojo Board framework. And I put an activity on the ideas board to build something (anything!) to make use of it. This activity tied in the voting with "Yet Another Trump Tweeter" [not actually called that] and Tom very kindly applied the cat-herder's tie-breaking prerogative to declare that my Dojo Board would be the activity du soir.

First, a little background about the project. At one time it was reasonably common for people propose a challenge for the Dojo which had a board-game flavour to it: Battleships, Noughts-and-Crosses, Connect4, Boggle, Word Search, all those kind of things. They're well-understood or easily-explained challenges which fit nicely inside our hour-and-a-half of coding format.

The Dojo format is fairly open and if a team wants to focus on the mechanics of a board structure, then that's up to them. But often, they really want to work out the gameplay of noughts-and-crosses or which search algorithm will apply best to Boggle etc. But they get bogged down in agreeing a common structure for the board and how to display it.

So, one Dojo about three years ago, we decided that the challenge of the day would be precisely to create a board framework which could be used in future Dojos. I don't remember the outcome, although I don't think that any of the offerings was compelling, but I got interested in the idea afterwards, hacked on it a bit, dropped it, let it gather dust, picked it up again recently and produced something usable with tests and everything!

It's on Github so you can view it, clone it, fork it, raise Issues, send Pull Requests and so on. The main idea is that it be a useful framework where your challenge is board or tile-based but where you don't care about the board mechanics.

Highlights include:

n-dimensional (anything from 2 upwards)
any or all dimensions can be +inf, that is: they all start from zero but can be infinite to the right.
standard Python indexing for get/set/del: board[0, 0] = 'X'
boards can be sliced from other boards, eg to allow a visible viewport on a wider -- possibly infinite -- landscape
useful functions to find neighbours, detect edges and corners, follow lines
simple text output for 2-d boards

You can see the full README and, of course, read the code.

Last night was the first time it was used in earnest, even by me! I'd put a fair bit of thought into the design, conscious of the kind of requirements which board/tile games bring, but I'd never actually used it. Yesterday's challenge was an open one: use the Board framework to do something. And there was definitely variety between the 5 teams.

One team did a Minesweeper clone; one ambitious team used the infinite dimensions to generate a scrolling(ish) land/sea text map; our team managed a maze solver; someone did Connect4; the other team did Battleships. I was pleased to see that, by and large, the framework was useful and usable. There were a few Issues/PRs raised during the evening, which is good. A couple of people mentioned possible improvements, and I implemented a corner detector when our team needed it! (Open Source itch-scratching at work).

I made a few changes on the way into work this morning based on some of the feedback from yesterday: neighbours can now ignore diagonals; draw now accepts a callback which defaults to str which allows the caller to, eg, hide or obfuscate board elements according to their state (think: Battleships); and iterline can now be limited to a number of steps (this one, again, from the Battleships team).

Some things I plan to include, having seen a few struggles yesterday are (in no particular order):

itercorners
iteredges
iterhorizontals
iterverticals
iterdiagonals

Something which I added relatively late in the day, but which gives a real boost, is the simple text-grid output. It's not rocket science (although it does a little bit of work to get even column sizes) but it's just the kind of thing which you tend to leave to the end in a Dojo and then get flustered trying to work out the order of iteration and the combination of "+"/"-"/"|" characters in the right places.

So I'd also like to implement a .paint method which produces a PNG and, like .draw, uses a callback to request an image for each data item (cached, of course) to draw inside the corresponding cell.

But all that will have to wait because tomorrow I'm helping out again at the Turing House Coder Dojo in Teddington in the afternoon, and then running a robotics workshop for our club's PiWars entry in the evening. So I'll be a bit busy...

PyCon UK 2017

Tim Golden — Mon, 30 Oct 2017 16:15:43 GMT

I recently returned from PyCon UK 2017 which took place in Cardiff from Thursday 26th to Monday 30th October. There were about 900 people throughout the 4 days of the conference including teachers attending a Picademy; young coders attending a Code Club, a Raspberry Jam and a micro:bit show-and-tell; data scientists attending a PyData track; those attending a Django Girls session; and everyone attending the conference proper.

tl;dr I really enjoyed it. I got the right amount out of it without burning out; I had interesting conversations with people; I picked up a couple of useful ideas for work; and I enjoyed helping the teachers, the young coders, and anyone else who asked me for advice or input. On Monday I was happy to be sprinting on my networkzero module with some other conference attendees who'd seen my talk on Saturday and interacting with the education crowd, especially the Mu maintainers and Ben Nuttall.

After last year's PyCon UK, I'd told myself that I'd definitely make an effort to help with the organisation of the Conference in some capacity. But, with one thing and another, I didn't put myself forward until the end of August. Of course, by that time, onboarding a volunteer means a lot of explanatory work on the part of the team so I was gratified when Peter asked me to pick up some of the administration of the Financial Support scheme. I also joined the organisers' Slack and was able to contribute to the discussion around the Lightning Talks bucket scheme (of which more later).

One area I'd particularly wanted to improve was communications before and during the Conference. Communication is hard: no matter how much effort and goodwill, some people miss all the notices & signals you give out and are disappointed or upset. There was an unfortunate storm in a teacup a few weeks before the Conference when someone -- having checked the website -- Tweeted that it was a shame there had no been no Financial Aid scheme. In fact, there was a very generous scheme and we were able to help quite a few people otherwise couldn't have come. But applications had closed and the details of the scheme had been removed from the website. It was all sorted out but it goes to show how easily misunderstandings can arise, even with goodwill.

I volunteered to rework the front page of the PyCon UK website in the days leading up to the Conference to include the practical information which people need when they're planning their trip (or actually at the Conference). In the course of the discussions around this, the idea of a Zen of PyCon UK arose, loosely inspired by the Zen of Python. I put something together which was tweaked by the others. And so it was that I found myself on stage, introducing the "Zen" at the opening session of the Conference [Photo by Mark Hawkins].

You can see the schedule of the conference itself with links to slides where they've been made available. Depending on when you're reading this, you should also be able to see many of the talks on the PyCon UK Youtube channel. What isn't perhaps so obvious is the tremendous amount of work going on behind the scenes before, during and after each day to make all that happen. As Daniele pointed out in his closing address, it was so common to have someone say "I can do that" whenever an issue arose. And aside from those occasional issues, there were just the everyday, ongoing work: Chloe organising the Registration Desk all the time she wasn't chairing a session (or being the Right Sock in Friday's Lightning Talks); Owen managing the Lightning Talks buckets and the Session Chairs; Alex printing out hundreds of copies of the schedule every day; Kirk organising the Board Games evening (and being the Left Sock); Nicholas with help from Tom and myself, organising the Thursday Dojo; volunteers turning up to chair sessions in any of rooms we were using; the micro:bit Foundation teams organising the the micro:bit sessions; the Raspberry Pi Foundation teams organising the teachers' 2-day Picademy event and the Saturday Young Coders' day; Tim organising video & sound recording in every room and training others to do the same; all the work done beforehand by Owen and Kristian to bring the new UK Python Association into being; the professional photographer and stenographers who brought their own expertise; the creche organisers; loads of people whom I've forgotten or didn't even know about because they just did their job and got out of the way. And behind everything, Peter & Daniele keeping everything running smoothly, liaising with the excellent City Hall staff.

The message of the Conference was: enjoy yourself and make sure others enjoy themselves. Be friendly. Be welcoming. Talk to people you don't know. Step into discussions you might otherwise have skirted because you can be sure you won't be excluded. Even the gift to speakers was welcomed: a pair of Python-themed socks. Amusing, practical, and universal: everyone can wear socks.

At some point someone had posted a message of thanks to the organisers. I realise it's somewhat gauche to quote my own reply here, but I'm going to, because I think the point I'm making is important:

No matter how trite it sounds, it would be no use our standing up there and saying "Please be welcoming. Please be respectful" if you all had other ideas. The atmosphere of the Conference is the result of the agreement of everyone that this is how it should be. And that's a great testament to the UK (and wider) Python community. [Tim Golden on Slack]

So many people have said -- on Twitter, on Slack, in person -- that they felt welcomed, that they thought PyCon UK had something special. There were several talks around a growing awareness of Mental Health and the need for a greater inclusivity. I think many people were surprised to hear Chloe -- whose cheerful enthusiasm and occasionally quirky humour were the first thing you encountered at the front desk -- explaining how PyCon UK had changed her life. Arriving at her first PyCon two years ago in Coventry, she was hugely nervous and didn't know how she'd manage to interact with other people. By the end of that conference she was so much more confident that she put herself forward for the organising committee for the next PyCon UK.

Of course there were keynote speakers, talks, workshops, and lightning talks: the bread and butter of the Conference. I picked up useful information for Big Data handling, consuming public transport APIs, making use of Postgresql and other bits and pieces, all of which will be helpful to me at work and elsewhere. Add to all that the "Hallway Track" where you just find yourself in fruitful conversations with people in between times, in the dining hall and so on.

The 5-minute Lightning Talks have always been a popular slot at the end of each day of the conference. This year, rather than just have people sign up on a whiteboard which tends to favour those in the know, we offered a bucket lottery where 5 cards would be pulled out of each of two buckets each lunchtime. One bucket was for first-time speakers, the other for everyone else. This worked well and we had the usual wonderful variety of subjects, including Python as a model sailboat controller, baking brownies, how to give good talks, a guide to saving someone's life, a guide to Mental Health First Aid and many others.

Well this is longer than I'd intended, and there is so much more that could be said, but it's difficult to capture the atmosphere and the enjoyment without having being there. Even now there's still a background buzz around how this year turned out and what we might do even better next year. I understand that there'll be a feedback form fairly soon. Or you can just contact the organisers. Above all, don't shy away from robust criticism. I've been very positive above and I've heard good things from other people. But if something didn't work for you, please say so and explain why.

If you want to see the talks: https://www.youtube.com/channel/UChA9XP_feY1-1oSy2L7acog
If you want to see the pictures: https://www.flickr.com/photos/152472562@N06/
If you want to offer to help next year: http://2017.pyconuk.org/contact/

Back to BAML for the September Dojo

Tim Golden — Sun, 17 Sep 2017 13:30:50 GMT

The first Thursday in September saw us back at one of our long-time hosters: the Bank of America (BAML). This time, in their building near St Paul's. We've been there once before, for a Raspberry Pi-themed Dojo. That time we were in a sort of banqueting hall on the ground floor. This time, we started at the other end, on the rooftop for generous amounts of pizza, beer and other hors d'oeuvres, before moving into a conference room for the meat and drink of the evening: coding.

Gautier and others from BAML had prepared a challenge which involved determining the (human) language of a set of texts, given a training corpus. They'd suggested the possibility of using scikit-learn and the Natural Language Tookit, but left it open to teams to find their own way.

One thing about the London Python Dojo is that we emphasise the need to welcome and encourage newcomers, both newcomers to this particular forum and newcomers to the language itself. Early in the evening, Gautier arranged some reshuffling so that more experienced Pythoneers weren't clustered together, leaving neophytyes to flounder alone. So across the table from me was Nathan, giving a Psychologist her first real taste of Python, she having had no more exposure than reading the tutorial for a while.

I was asked to help two developers who were experienced in other areas but new to Python. We stuttered along for a while trying to understand the Natural Language Processing toolkits at which none of us had any knowledge. But we soon decided to switch to more primitive techniques of frequency-matching. Since both of my other team members were new to the game, it was more a question of walking them through the kind of approach, and getting to a simple point of recognising one language from a well-known marker. But they both managed to get that far.

Thanks, as usual, to BAML for its continued support of the London Python Code Dojo. I'm glad to say that a number of organisations have come forward in answer to my call for support to offer their venues for this year's session of Dojos. But we can always use more: if your company is in a position to offer space for about 30 people and, ideally, beer & pizza for the same number, then please let us know: team@ldnpydojo.org.uk or @ldnpydojo on Twitter.

Helping educators

Tim Golden — Wed, 31 May 2017 10:05:30 GMT

tl;dr If you’re a teacher looking for help with any aspect of IT, there are people willing to help. For free! Drop by the Twickenham Coding Evening [actually in Richmond] on June 21st. You can just turn up and say “who can help me with this…?” or you can stay for a while and see what else is going on.

It’s no great secret that many teachers are overworked and under-supported. It’s also the case, thankfully, that there are many people who are willing and able to try to remedy some of that (mostly the under-support rather than the over-work). But the under-supported and the willing-to-supporters don’t always meet in the middle.

I’ve been a casual lurker on the Computing At School forums for a few months and people occasionally advertise local meetups (called “Hub Meetings”). But they’re, understandably, timed to facilitate teacher attendance, typically at 4pm or a little after. As helpful as I’d like to be, I work full-time in Central London and, even if I stretch my hours a little, I’d struggle to make a meetup anywhere at 4pm. Coming from the other direction, I help to organise the London Python Dojo and we’d welcome teachers to come along and participate. From time to time, we even make the Dojo especially education-oriented. But for a tired & busy teacher, taking out an entire Thursday evening somewhere in Central London for a beer & pizza coding meetup may not have the same appeal that it does for a buzzing techie who’s just finished work somewhere nearby.

Is there a single answer? No, not really: people are different. One person may like diving in to interact with people they’ve never met; another might shy away unless they’re certain of a friendly reception. Another factor is that the majority of techie meetups are male-dominated. They may be as friendly and welcoming as you like, but a lone woman might well feel out of place and/or in the spotlight. And some proportion of teachers are women. I’ve no idea what the ratio is, but it’s got to be different from the 1 in 99 common in tech circles.

Clearly what’s needed is a variety of support channels to meet those various needs and preferences. There’s a bit of soul-searching at the moment on the Cas forums over whether they’re useful or not, but what it comes down to is that some people find them useful and welcoming, while others don’t. That’s going to be true of pretty much any forum (in the broadest sense of that word).

So don’t agonise over whether some initiative is going to prove fruitful or not: just go ahead and organise it, advertise it, make it as friendly and useful as you can. And go from there.

More or less since its inception I’ve been helping at the Twickenham Coding Evening, organised by the dynamic Cat Lamin, originally a teacher, now something else. It’s a completely informal thing, more or less once a month, until now in a room over a pub. It’s just moving venue and the next session is June 21st. It’s basically a bunch of techies offering whatever help they can to any teachers who might drop by. Some of the technical people are also teachers or teacher-support; some, like me, are in industry. Sometimes there are demos of things; but, really, it’s just an open house. It takes place from 6.30pm onwards, notionally finishing around 9pm. There’s no particular structure: just turn up and say hello.

So, if you want specific help with a specific thing, come along and ask: “How do I remote control my robot using Python?” or “Can I do random numbers in Scratch?“. If you’re looking for more general approaches / advice, just ask: “I’ve got a bunch of micro:bits; what can I do with them?” or “I’ve been told I’ve got to teach coding to Year 7s next year; what’s available to help me?“. If you’re looking for hardware ideas or experience with particular pieces of kit: “I’ve got a budget of £10 per kid; what can I get to teach physical computing?” or “Is it worth getting a classroom set of Crumble Bots?“. There are usually people from Code Clubs and people with teaching experience as well as people, like myself, who are full-time coders but with a side-interest in helping education.

You don’t have to stay for any particular amount of time. Just say Hello and start asking for advice — or offering it! if you’re an enquiring teacher who needs help with IT, I look forward to meeting you on June 21st.

School Dojos, Raspberry Jams & Worksheets

Tim Golden — Mon, 14 Nov 2016 14:11:31 GMT

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.