Bullies & Critics

Bullies & Critics

There was a bit of a fracas in one of the technical communities I inhabit, to do with heightened sensitivities around racial awareness. In that community, the majority of communication centres on technical issues. But people who give technical opinions also have views about real-world matters.

An issue flared up over the wording of a message which accompanied a change to some documentation. (And, to a lesser extent, over the change itself). What followed was surprising and a little shocking. Not that there were such diverse opinions on the matter: that's expected in a community with a variety of people. Rather, the way in which some of the opinions were expressed. The way in which they weren't expressed as opinions at all, but as incontrovertible facts, any opposition to which was evidence of some kind of hatred.

It was very troubling on a number of levels -- and continues to be so, despite the sincere efforts of community leaders to turn things around. The situation very quickly reached a point where even pouring oil on troubled waters simply ignited further fires. A call for a moratorium was respected and things went quiet for a while.

Naturally, when this happens, you see faults in the opposing rhetoric more than in your own. (My shorthand for this is that: no-one uses the word "ideology" of their own position). It seemed to me that one side of the debate was unwilling to hear the other position. But that one-sided deafness was opposing the view which I myself held. So I wasn't sure I was able to disentangle my partisan feelings from a disinterested analysis of the rhetoric.

Then I came across this article: https://heterodoxacademy.org/blog/viewpoint-diversity-critics-bullies/. The author describes a useful schema to help distinguish the genuine attempts by which even diametrically opposed viewpoints can engage in good faith ("the Critics") from attempts simply to shut down the opposing argument ("the Bullies"). You can read it for yourself to understand what the author's getting at, but I'd like to pick up a few of the points he makes.

I'll lead with his final point: that this is not to do with the good of the cause. Those advocating for either side believe in their cause; and they sincerely consider that the other side is wrong-headed or misguided. So even if the "Bullies" in some situation all belong to one side of debate, that doesn't mean ipso facto that that position is wrong.

Another thing to highlight is that there's nothing wrong with being forceful in your advocacy. As someone who's managed several technical mailing lists and forums over the years, I believe that people can be a little too quick to reach for the "Code of Conduct" complaint button when a contributor is making an argument forcefully or robustly. One can have every respect for one's opponent while attacking their position vigorously and perhaps bluntly.

Now you have to judge the situation: there's a difference between a robust debate in person between two people who already know or can readily assess each other and an online debate where you probably don't know the other people and where you may not be able to judge their cultural sensibilities well. There's a good case for saying that you should err on the side of caution when expressing yourself online. But that doesn't mean that you should never speak out bluntly in defence of a position.

"A critic permits you to make your case in the terms you believe appropriate".

This is an interesting one and resonates with to the scholastic tradition of Mediaeval University life. There, students went up against each other or against a Master to debate matters respectfully but forcefully. You were expected to meet your opponent's strongest argument on its own ground. The skill wasn't in turning things around so you had the upper ground; rather, it was in demonstrating that your position was strong enough that even taking your opponent at their highest, your argument still won through.

Of course, this can founder when the vocabulary in use by each side has diverged more or less significantly. For example, each side might use the word "racist" but might understand something quite different by it. So there may be a need to employ alternative forms of expression to clarify what is being said. But this should never be done for tactical advantage, only to set out more clearly the terms of the debate.

"A critic is willing to be challenged as well as to challenge".

Each of us, at least in an area where we feel passionately, self-evidently believes that they are in the right. The natural reaction to any challenge is to marshal one's counter-arguments. But this is the point: that we should be countering the arguments put forward by our opponent. Treating them with respect, considering them as valid arguments, and putting forward our responses. This can be difficult if we believe that the opposing position is missing the point, or that the question is genuinely misguided. But, absent blatant trollery, we have a duty to address the question at face value.

Anyone who's taught youngsters coding -- or, really, taught anything -- will have been on the receiving end of questions which are clearly sincere, but which demonstrate that the person asking has definitely got the wrong end of the stick. I was once trying to explain how characters are encoded to store in a file, for simplicity sticking to ASCII. And one of the young coders asked me how it was that "W" and "I" took the same space on the disk when one was so clearly bigger than the other! I'd obviously failed to distinguish in my explanation between the abstract notion of a character and the glyph on the screen, which is what the coder sees. But it's an example of a (non-controversial) question which is perfectly reasonable but which is based on a faulty premise.

For me, one of the most dispiriting things about modern political debate (at least in the UK) is precisely the inability of senior politicians to respond well to challenge. The televised debates which occur close to a General Election are soul-destroying exercises in self-marketing and deflection of criticism. It would be the greatest breath of fresh air if a party leader took a question seriously and addressed it honestly by explaining, for example, why they felt that Education needed more time and money than helping first-time house buyers because... whatever.

"A bully believes that dissent from his or her opinions is evidence of ... stupidity".

This is one of the most regrettable deficiencies in the negative approach to advocacy: that the opposing position can have nothing to say of value. That one's position is so completely unassailable that the only explanation for the existence of another viewpoint is stupidity or mental illness. Of course, people can ask questions which reveal a genuine lack of knowledge or which rehash arguments which you consider to have been refuted long ago. But even here, you can be guilty of begging the question: considering as closed the very issue which your opponent is raising. If they are bringing up a point which you consider to have been dealt with elsewhere, then point them towards some resource where that was addressed.

There's more there, and I recommend you to go and read the original article. Finally I'd like to quote one line which I think sums the matter up: "A critic—even a forceful one—does business in the proper currency of intellectual discourse: presenting evidence, providing reasons, making arguments; a bully questions people’s motives and calls them names."

Teaching with Mu

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.

/images/coding-1033276_no_faces.thumbnail.jpg

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

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

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

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

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

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).

/images/MVIMG_20180201_182700.thumbnail.jpg

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.

/images/tom-dojo.thumbnail.jpg

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).

/images/MVIMG_20180201_213344.thumbnail.jpg

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

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.

Back to BAML for the September Dojo

/images/baml.thumbnail.jpg

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.

/images/IMG_20170907_195037.thumbnail.jpg

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.

/images/IMG_20170907_195045.thumbnail.jpg

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.

/images/IMG_20170907_195104.thumbnail.jpg

Helping educators

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.