Training teachers in coding at Truro School

I’m part of a UK Department of Education funded project to join up 10 primary schools in Cornwall and get them programming. The teachers are very important people in this equation, so our first activity was a training day for them. The idea of this was to get them familiar with using the Raspberry Pi and try out some programming, while at the same time allowing me to gather some research on feasible projects that can result in long term benefits for the schools involved.

We gave Sonic Pi and our Minecraft Python architecture coding a go, and I also briefly demoed the weavecoding project via flotsam – as one of our eventual aims is to produce teaching materials for this too. I’ll start with some of the broader things we discussed, see below for more specific observations for these programming systems.

Unaddressed needs of teachers

Despite a big push in coding in schools, there are still plenty of areas where support is lacking or even misguided. The focus on hardware platforms (Raspberry Pi, BBC’s Micro Bit) is not so relevant as schools have plenty of existing hardware, also the mass of community open source activity needs a lot of work to translate for classroom use. A further problem is that a lot of existing initiatives tend to be high visibility but too short term in their scope. Codeclub is a notable exception in this area. Technology also tends to get considered as a distinct subject – whereas it needs to be linked with other topics (i.e. teaching local history by making computer games about it) in order to make sense.


Long term thinking

Events for teaching a small proportion of children programming has short term benefit unless it is to enable the children to teach each other. This turns out to be successful in after school code clubs, so is it possible to design events and workshops with this aim specifically in mind?

Teachers need access to people who work with technology when they need it, but how can this be done – a local support network perhaps, we also discussed hacklabs for teachers where they can drop in and get advice. Hacklabs could provide teachers with feedback on their ideas, perhaps some small one on one training to help realise them – as well as perhaps building hardware or software specifically according to their needs. The funding for this is an open question at the moment.

One of the issues reported by the teachers is that it takes a lot of effort to get students to a certain tipping point with technical ability, after which they shoot ahead and quickly overtake the teacher. I’m not sure if this is seen as a problem in itself, but it does seem like there needs to be a situation designed where this can easily feed back into the collective knowledge of the group.

Classroom materials are worth their weight in gold, like the ones supplied with Sonic Pi or those provided by Code Club – and they take a long time to check and get right. The problem is that it’s actually hard to get funding to make these, relative to teaching hours. Releasing all teaching materials as creative commons to pool resources nationally (and beyond) is key. One thing that came out clearly with the worksheets we used for both Sonic Pi and the ones we wrote for Minecraft coding was that they are not really very well suited for primary school use. We seem to tend to write documentation that focuses on example recipes to follow rather than encouraging exploration – this was a surprise to me. The teachers were more keen on simple lists of commands (and liked the dropdown menus in Sonic Pi for example) which were then left for the children to discover how they fit together, and less wordy explanations.


Hardware problems

Many schools have already moved away from desktop PCs, whether using laptops or (shudder) tablets exclusively. The Raspberry Pi has considerable extra hardware needs – we discussed whether recycling hardware being thrown out from local businesses was one option to help with this.

We came to the conclusion that one promising area to look at is robotics, making use of the Pi’s easily accessible hardware interface. The problem then is where to get the required motors and other hardware from – one potential resource are the forgotten boxes of lego, electronics and bits and pieces gathering dust in school storage. Again the challenge is how to make effective use of this rather than spending money on new kit.

Systems we tested

We tried following some worksheets for two coding projects on the Raspberry Pi, the aims were twofold – to get some initial experience with them as well as getting feedback for how we can improve them from the teachers point of view.

Sonic Pi

This was the first time I’ve used the new version of Sonic Pi in a class room. We used the version that comes pre-installed on the ‘2015-02-16-raspbian-wheezy’ release. I’m not very familiar with Ruby, the language it uses but I’d had a bit of a play with it in the days prior and had a bit of feedback from Sam Aaron on some specifics too.

One of the big questions I had was whether typing skills would be an issue with the primary age group. They are used to using drag-drop programming languages like Scratch and Espresso but would this translate to using the keyboard? The teachers thought that Sonic Pi’s minimal syntax would be really good with their children – the syntax highlighting (using colour and little lines to denote indentation) would be important to make it easier for them. One problem we noticed is that the syntax colouring might be able to go a little further – it could, for example be more context sensitive – e.g. the difference between a symbol that is user defined and one that is part of the system would be better to differentiate for explanation.

They considered the documentation, both ‘online’ as part of the interface and the wording of the tutorials was probably too prescriptive and in-depth (which to be fair is written for older children). More importantly the teachers loved the musical aspect, and immediately got into creating their own tunes (all mixing with the amen break :) Initially the concept of MIDI notes was a confusion – “why is 60 middle C?”. A popular request was for some pre-written examples of familiar tunes to fiddle with.

The interface including visible debugging/errors was very popular, as it seems a lot of existing commercial software they use in classrooms does not to this well. Being able to ‘hear’ bugs was also important. It was also good to explain Sonic Pi in terms of musical livecoding and Supercollider, as this culture gives it a kind of extra spice which is exactly what we need when ‘coding’ can so easily slip into being about boring product-centric thinking.



To contast Sonic Pi, in the afternoon we switched to the Minecraft world and the system we developed for teaching teenagers programming with Python. I’ve recently been using this for one-on-one teaching with an 8 year old, so I wanted to find out if they thought it would be useful in the classroom for this age group.

This setup relies on an IDE (we use Geany) which communicates with Minecraft via network messages running in a different window. The multiple windows and strange ‘always on top’ OpenGL rendering of the Raspberry Pi GPU makes this a fiddly business until you get the hang of it, but the upside is that this is the same approach as programming in the games industry – and kids like it when you tell them this. However it would be wonderful to be able to ‘dock’ minecraft in a Python IDE in a friendly way and have some of the features of Sonic Pi.

The projects we made with this system are again pre-created recipes without much information on things like how to get the coordinates right rather than just following the instructions. One of the teachers found out that you can use the player’s position to figure out what the coordinates should be, we need to include these kinds of hints and think a bit more broadly how to describe the creative process.

On thing I picked up from the teachers was that they had high expectations of the scale of what would be needed to capture interest for the children – for example that we’d need to write programs to create entire cities and a worry that the amount of code needed for a simple house seemed so much. However, what I’ve noticed when using this for teaching younger children – is that we’ve sometimes spent an entire hour on a single line of code. For example creating a block, changing it’s position and size in 3 dimensions and then trying changing the block type – seeing how water or lava acts in different circumstances. The strength of Minecraft is that it contains a lot of complexity which is already understood by children who play it, so they don’t really need to be convinced so much as given space to explore possibilities.

Yeastogram workshop

Last week we had our first biohacking workshop at foam kernow with the London Biohackspace. We had a great turnout and an interesting mix of people. Amber has written a more complete overview of the event.


For more information on yeastograms and how to make your own there is more info here. One of the things we helped with was the construction of a high power UV LED array needed to expose the cultures to radiation. We used 19 LEDs from here powered in 3 chains of 5 and one of 4 at 20V drawing 1.2A. After battling Ohms law for a while we found this site to be immensely useful. We also spent a lot of time on the LED heat sinks and cooling with an old PC fan – but the only problem we had was with the limiting resistors which overheated resulting in a last minute shopping trip to get some 10W rated bigguns. After that everything ran warm rather than hot and could be left overnight. One very important thing to mention with the UV light is to get proper eye protection when working with this, and not just dodgy sunglasses.




Screenless music livecoding

Programming music with flotsam – for the first time, it’s truly screen-less livecoding. All the synthesis is done on the Raspberry Pi too (raspbian release in the works). One of the surprising things I find with tangible programming is the enforced scarcity of tokens, having to move them around provides a situation that is good to play around with, in contrast to being able to simply type more stuff into a text document.

The programming language is pretty simple and similar to the yarn sequence language from the weavecoding project. The board layout consist of 4 rows of 8 possible tokens. Each row represents a single l-system rule:

Rule A: o o o o o o o o
Rule B: o o o o o o o o
Rule C: o o o o o o o o
Rule D: o o o o o o o o

The tokens themselves consist of 13 possible values:

a,b,c,d : The 'note on' triggers for 4 synth patches
. : Rest one beat
+,- : Change current pitch
<,> : Change current synth patch set
A,B,C,D : 'Jump to' rule (can be self-referential)
No-token: Ends the current rule

The setup currently runs to a maximum depth of 8 generations – so a rule referring to itself expands 8 times. A single rule ‘A’ such as ‘+ b A - c A ‘ expands to this sequence (the first 100 symbols of it anyway):


I’m still working on how best to encode musical structures this way, as it needs a bit more expression – something to try is running them in parallel so you can have different sequences at the same time. With a bit more tweaking (and with upcoming hardware improvements) the eventual plan is to use this on some kid’s programming teaching projects.

Organisation hacking (part 2)

Time for the next installment in my attempt to document the sometimes opaque world of setting up a company, based on experiences founding Foam Kernow. As before ‘I Am Not A Lawyer’, as they say – so no substitute for proper legal advice here, and any corrections would be most welcome. See part 1 about the motivations for non-profit vs shareholder companies.

Company formation

Companies in the UK are founded with two documents, the ‘articles of association’ and a ‘memorandum of association’.

The articles of association broadly has two purposes. One is to state why the company has been brought into existence. The other is to strictly define the decision making process for those involved. You don’t generally need to write these documents from scratch, as we are provided with ‘model articles’ from which we can base new companies easily.

The company’s objects

A non-profit needs to describe it’s purpose via ‘objects’. This is important because, as explained in part one, a non-profit is strictly controlled in terms of access to its money. The objects describe what the company assets (e.g. cash) can legitimately be used for. You can’t found a non-profit for running e.g. a school and use it later for selling cars.

In contrast the objects for a company with shareholders is to provide a return on the investment for those shareholders, no more and no less. As such, for-profits do not need to provide any objects.

Articles of association are on the public record (you can pay Companies House £1 to send them to you). Naturally I’ve uploaded Foam Kernow’s articles on github :) These are based on the UK’s model articles – the main addition are the objects, which are a distilled version from Foam Brussels’ charter:

The objects for which the Company is established are to:

1.11 promote art, science and education by identifying and strengthening the areas that connect them;

1.12 embrace cultural change;

1.13 foster interdependence;

1.14 cultivate the beginner’s mind;

1.15 respecting and sharing sources;

1.16 empower participants to translate an idea into practice;

1.17 foster open source culture; and

1.18 embrace creative conflict.

So in a nutshell, the objects provide a publicly stated purpose and philosophy, such as this, for everybody involved.

Object 1.11 (the numbering scheme irks me as a programmer) was added in order to underscore the arts/sciences purpose of foam. This meant we could apply for an exemption to drop ‘limited’ from the end of the name, in order to highlight our independent research focus.

Memorandum of Association

The memorandum is an agreement between the individuals founding the organisation – the share of capital (in a for-profit) or the share of liability (in a non-profit), the names and addresses – and eye colour, interestingly of all involved.


The standard corporate structure in a company limited by guarantee is a democratic one consisting of two levels. ‘Directors’ of a company take day to day decisions and responsibility while ‘Members’ of the company have voting powers on important decisions and have the ability to remove or add new directors. This structure is very flexible, neither directors nor members need to be employed by the company, and alternatively it’s also possible for a company to only have a single director/member who is also employed on the payroll. This is how foam kernow started, and bizarrely I had to supply minutes to Companies House for a meeting with myself to appoint a new director.

There is quite a lot of confusing terminology around all this, for example an ‘executive’ director is one that is employed by the company (also known as a CEO) while a ‘non-executive’ is one that is otherwise external to the company.

As an aside, some companies are wholly owned by their employees, where all people on the payroll are made members and given votes automatically – however this is not the norm.