Python on the micro:bit — TouchDevelop or the Mu editor?

You may have noticed that the BBC micro:bit has been launched (for the third time, I think). This time, it’s actually being to delivered to schools and teachers have the opportunity to use it with their Year 7s (11-year-olds).

Some of them will be using the Block Editor, a sort of Scratch-alike provided on the official micro:bit TouchDevelop website.

But we hope that many will choose to use MicroPython, the complete re-implementation of Python specially designed to fit onto small boards and embedded systems. A lot of work has gone into making sure it runs well on the micro:bit and has a special “microbit” module from which you can import all the tools you need to access the LEDs, the accelerometer etc. You can read about it on the micro:bit community page on the Python website.

Earlier this week I helped out at a workshop organised at Maidstone Grammar School by CAS South East to introduce some Kent-based teachers to Python on the micro:bit. One issue which arose was whether to use the TouchDevelop Python editor (created by Nicholas Tollervey) or the standalone Mu Editor (created by Nicholas Tollervey). As I spoke to the teachers at that workshop, there was an amount of confusion & misunderstanding so I lay out here what you need to know about each editor.

General

The most important point is that it doesn’t matter. Both editors have the same purpose: to provide a means to run a Python program on the micro:bit. The same code, the same version of Python, the same result on the micro:bit.

The choice will be down to how the points below interact with your preference, your environment, and the restrictions in place in your school. Also the extent to which you want to achieve commonalities with (a) other TouchDevelop languages; or (b) a local solution (eg because you’ve invested in Classroom for Github).

The TouchDevelop Editor

  • The TouchDevelop editor obviously integrates with the TouchDevelop world, saving scripts which can be shared with other TouchDevelop users. It follows the same pattern as the other TouchDevelop languages and therefore benefits from familiarity with those.
  • The TouchDevelop scripts are inaccessible except via TouchDevelop. (Although you can obviously cut-and-paste out of the editor but still…). You can’t, eg, hold them on Github or on your PiNet setup.
  • TouchDevelop requires you to be online. UPDATE: Peli de Halleux points out that it works offline.
  • TouchDevelop runs in the browser so no new software or installation is needed. (I don’t know whether it will run inside the standard browsers on the Raspberry Pi).
  • The process to get your TouchDevelop script onto the Microbit is very slightly more involved than the equivalent Mu process.

The Mu Editor

  • Mu does not require you to be online
  • Mu works like any local editor (I found myself saying “think of notepad”).
  • Mu saves files locally so does not share by default but can make use of whatever your standard filesharing solution is (Google Drive, Github, school fileserver etc).
  • Mu can copy your code directly to the micro:bit to run immediately.
  • Mu requires you to be able to run arbitrary software (albeit without installing) on the classroom machines.
  • Mu allows you to program directly on the Microbit via the REPL. However…
  • … on Windows, use of the REPL requires installation of a driver which may not be possible (at least without some bureaucracy).

Planet Python: an unintended trip down Memory Lane

So… you may have noticed some rather antique posts popping up on Planet Python this morning. This is the result of two things: our clearing out the cache to try to address an issue [*]; and the way in which the feed parser tries to pick up the dates from the feeds it’s scanning.

For now, treat it as a unique chance to view the Python blogosphere through the spectacles of yesteryear! The older posts should just drop down as others are updated, but if they don’t we’ll do a little surgery to the config. In any case we’ll try to do some code housekeeping against any future outbreaks of nostalgia.

[*] … and which didn’t fix the problem!

Planet Python

One of the many pieces of the python.org “family” is a feed aggregator: Planet Python. It’s been running for years either as planetpython.org or planet.python.org (the latter now redirects to the former). Naturally, over the years, some of the blogs it aggregates have disappeared. But it can also happen that the feed URL changes because of a change of blog engine, a new domain, a switch to https etc.

These days, the Planet configuration is maintained on Github and you can either submit a Pull Request or just email the Planet team. We probably add two or three new blogs every month and tweak a couple more (new URLs etc.)

So… please check the Planet config file or look down the left-hand side of Planet Python and, if your blog is listed but is now dead, please send us a PR or an email. Likewise if the blog is still alive but at a different address, please do the same. After a time, we’ll run a cull of Blogs which consistently return 404 and thin our list down.

Of course, please also ping us if you’d like to add your blog. Easiest way is to open an issue or raise a PR which will use Github’s recently-added issue template mechanism to make sure you’ve got everything lined up.

ESP8266 Dojo at Marks & Spencer Digital

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

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

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

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

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

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

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

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

You can see a few photos via our Twitter feed.

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

See you next month.

UK Python Help needed: Volunteers for teacher collaboration

[Reproduced very lightly edited from Nicholas Tollervery’s post to python-uk. Either reply to that thread or ping Nicholas on Twitter]

TL;DR: I need volunteers from around the country to support a twilight
meetup of teachers happening in various parts of the UK. It’s not
difficult and likely to be a lot of fun and will only take a few hours
of your time in the early evening of a single day. I may be able to
cover travel expenses. Please get in touch. More detail below…

Computing at School (see: http://www.computingatschool.org.uk/), a grass
roots movement of computing teachers in the UK would like to run a
series of training courses for “Master Teachers” in MicroPython on the
BBC micro:bit during March. These teachers would go on to act as the
seed / catalyst for other teachers who require Python training during a
series of training events over the summer. Put simply, this is an
exercise in Python evangelism for teachers.

Master teachers are those who have demonstrated a combination of deep
subject knowledge and teaching skill. Put simply, they’re the most
senior teachers you can get. They’re also the leaders in the field and
what they say or do influences many hundreds of their colleagues.

The idea is for the master teachers to get together with Python
developers (that’d be *you*) for a few hours to work through MicroPython
related educational resources. These events would happen at university
based hubs around the country. As a Python developer you’ll *get a BBC
micro:bit* and be expected to offer advice, answer questions and
demonstrate Python as needed. Honestly, it’s not an onerous task and
will only last a few hours in a “twilight” session (i.e. after work).

The locations and proposed dates are as follows:

London: 25th February
Birmingham: 9th March
Nottingham: 15th March
Lancaster: 16th March
Newcastle: 17th March
Hertfordshire: 21st March
Manchester: 23rd March
Southampton: 23rd March

It’s easy for UK Python to be very London-centric. This is an
opportunity for Pythonistas throughout the UK to step up and get involved.

Why should you volunteer a few hours of your time to help teachers? Need
you ask? Your help and influence will ultimately contribute to the
education of the next generation of programmers - your future
colleagues. It’s a way to give back to the community by fostering the
next generation of Pythonistas with the help of the CAS Master Teachers.
It’s also, from a moral point of view, simply a selfless and
unambiguously good thing to do.

If you’re thinking “oh, they won’t want me”, then YOU ARE EXACTLY THE
PERSON WE NEED! Your experience, perspective and knowledge is invaluable
and teachers need to hear from you. Rest assured, this will not be a
difficult or high-pressure activity. In fact, it’s likely to be a lot of
fun.

Remember that awesome person who mentored you and/or gave you a step up?
Now’s your chance to be that person for a group of master teachers.

If this is of interest to you, please get in touch ASAP and I can start
to coordinate things with CAS.

I’m going to put in a grant request to the PSF to see if we can cover
travel costs for developers. But there’s no guarantee this will come about.

Best wishes,

N[icholas Tollervey].

What Windows version am I running?

We’re getting a lot of questions through the Python mailing lists, and especially the Webmaster address on account of the changes to the Windows installer for Python 3.5. And, in particular, because Python 3.5 drops support for Windows XP. (We’ve previously dropped support for Windows 2000 and the 9x/Me tree but none of those had quite the installed userbase of XP).

There are several separate issues we’re seeing, and it’s important to know what version of Windows (and, sometimes, what SP) the user is running. And the user isn’t always clear. So here is the most straightforward way to get the system information from any recent Windows system. It’s not the only way; it’s just that it’s about the most straightforward thing to describe, given that — by definition — we don’t know what system the user is running.

System Screen

You’re looking for the System screen.

Two options which will work pretty much anywhere.

* If your keyboard has a key labelled Pause|Break, use the Windows key like a shift and tap that Pause|Break key.

or

* Right-click on your “My Computer” icon (which might also be called “Computer” or just the name of the computer) and select Properies.

Both of these will bring up one of the screens below, or a close match. Most of the information we need is near the top of the screen. (I’ve clipped several of the sample windows to hide non-essential information).

You can also usually get to this screen via the Control Panel under a label like “System”.

Examples

Windows XP

Windows XP System Info

Windows 7

Windows 7 System Info

Windows 8.1

Windows 8.1 System Info

Windows Server 2003

Windows Server 2003 System Info

Windows Server 2008 R2

Windows Server 2008 R2 System Info

Windows Server 2012 R2

Windows 2012 R2 System Info

Alternatives

And there are two other alternative screens with more or less of the same information:

* winver.exe [Start > Run > winver.exe]

* msinfo32.exe [Start > Run > msinfo32.exe]

Thoughts on PyConUK 2015

I don’t really have a lot to say about this year’s PyConUK. That’s not a bad thing: it just reflects the fact that it ran, for me, along very similar lines to last year’s. As usual I was over the road in the Education Track for most of Friday & Saturday: Friday for teachers, Saturday for kids. And as usual, the first talk I attended in the main conference was the one I myself was giving, on Saturday afternoon after the kids had gone. (And can I publicly thank the organisers for being so accommodating when I needed to shift earlier from my original 5pm slot).

A few things were slightly different: the lunchtimes have been staggered, for example. And it seems to have worked. Despite there being even more people this year than last, the queues were not horrendous, at least not when I was there. And although I had the 12pm slot on my badge, I ended up being there at each of the three slots: 12pm, 12.30pm & 1pm. Perhaps I got lucky: I did see someone tweet that he was off to a restaurant. But no-one [who stayed in the queue] seemed to be too unhappy.

There was also a science track, which [ANECDOTAL DATA ALERT] I don’t think quite got the take-up the organisers were hoping, but I’ve certainly spoken to several people over lunch and dinner who had attended or were going to attend although they hadn’t come along with that in mind. Sarah Mount, the organiser, seems happy enough, so let’s hope it’s been successful enough.

During the year I’ve spent a little more time engaging with teachers courtesy of Cat Lamin’s Coding Evenings in Twickenham. I’ve also become involved with PiNet, hoping to improve the Python elements of that project. On the Friday I ended up helping out in the Code Club sessions in the large front room closest to the building entrance. This meant that I was in a position to greet latecomers, whether developers eager to help or parents & kids eager to learn. Having being a little more involved with the Python-Ed community, I was in a better position to link people up: a father in Horsham who’s keen for his daughter to get involved with a local code club; a 12-year-old interested in security and penetration testing; a Surrey-based father whose two young daughters were both coding.

I thought it was a nice touch to have some of the Kids present a lightning talk session over the main conference. (And thanks to the conference delegates who packed the main hall out and gave the youngsters a great audience). I was particularly impressed by the two lads who decided to live-code their Minecraft demo!

The rest of the conference went by enjoyably if unexceptionally. I enjoyed the Friday night social in the canteen (and the Saturday night sit-down meal was as good as ever). I had a pleasant Sunday night meal with a few others in a Lebanese restaurant close to the hotel I was staying in (formerly housing the Coventry Technical College and now housing the Hotel and a Theatre). And I got some useful sprinting done on Monday, principally working on pgzero. I was refactoring ZRect: the floating-point version of pygame’s uber-flexible Rect class.

I always find it really easy to chat to random folk at PyConUK — something I don’t find that easy elsewhere! Everyone’s happy to talk, and not just about how they use Python (altho’ that’s a handy icebreaker) but about where they come from, in every sense, and what we might have in common.

I think the venue is fine, and the staff are always friendly and helpful, but we really have outgrown it, it seems. There’s talk about Cardiff next year, or maybe back to Birmingham (where we held the first few PyConUK and hosted EuroPython). I don’t mind: I’ll be back.

Coding with youngsters using pgzero on RPi: Part I

An eager young coder on Step 3

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

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

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

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

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

The setup

Hardware

I was keen to use the Raspberry Pi for this.

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

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

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

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

The Software

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

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

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

The Workshop

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

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

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

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

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

Takeaways

What worked?

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

What didn’t work?

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

Conclusion

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

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

re RPi Launch Day post-mortem

There’s an article over on the Raspberry Pi blog which does a very competent job of writing up the actions & reactions necessary to manage their website when the announcement of the Model 2 went live.

I love these sort of post-mortem articles when they’re written by competent professionals (as opposed to clueless PR agents). I enjoyed reading the writeups on the PyCon networking even though an amount of it was beyond me as I’m not a network specialist.

What’s most interesting about the RPi writeup, though, is the author’s responses to the (presumably) well-meaning suggestions for how to improve things. I love how he points out with one suggestion after another that their existing solution is essentially doing what the commenter is proposing, only perhaps without the buzzword attached. Finally, he cracks a little, and plays the Mongo is Webscale card (which I’d forgotten all about).

Go and have a look; it’s a fun read!

Raspberry Pi-themed Dojo at BAML

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

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

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

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

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

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