Today is our 20th wedding anniversary. Such an auspicious occasion deserves celebrating.

Mary and I face the world together: we laugh with (and at) each other, we trust each other and we rely on each other. It is a great source of strength and comfort that the person I love most in the world thinks of me as the person they love most in the world. It's a virtuous circle of mutual love, support, friendship and affection. Since this is something only Mary and I share with each other, it makes it all the more precious.

Yet we find ourselves in a wonderful situation. Our bonds strengthen over time as our shared experience grows, for example, as parents bringing up our three children to be confident, independent and flourishing individuals.

We were very fortunate to meet and marry at a young age. Consequently, it's likely that we have 40 years or more of marriage ahead of us. That's 40 more years of making memories, having fun and growing old together.

So, here's to our shared future, and long may it last.

(In case you were wondering, we'll hold a big party for all our friends and family at our 25th anniversary: 2nd August, 2022.)

Mu (codewith.mu) is a simple code editor for beginner programmers. In case you're wondering, you pronounce it like "moo", and it is named after the Greek character "μ", used to represent micro units of measurement in the decimal system.

I wrote the first version in December 2015 as a Sunday-afternoon "hack". At the time I was volunteering effort for the BBC's micro:bit project - a computing device for kids that encourages them to learn how to code. I had already written a browser based editor for the project but, unfortunately, when I tested it on teachers, kids and developers it soon became apparent that it wasn't a great experience. While the convenience of a browser-based editor was initially welcomed, the faffing about caused by the browser-imposed limitations of the editor meant it wasn't a pleasant experience in the long run.

This problematic situation motivated me to put together the simplest yet most useful editor I could imagine. I wrote it so beginner programmers could easily write MicroPython code for the micro:bit. Et voilà, Mu was born.

I quickly formulated a "Mu philosophy" to help guide my development process:

• Less is More: Mu has only the most essential features, so users are not intimidated by a baffling interface.
• Keep it Simple: It's quick and easy to learn Mu - complexity impedes a novice programmer's first steps.
• Path of Least Resistance: Whatever the task, there is always only one obvious way to do it with Mu.
• Have Fun: Learning should inspire fun - Mu helps learners quickly create and test working code.

I had three goals:

1. An editor that clearly demonstrated the design philosophy outlined above.
2. An editor with a simple enough code base that an enthusiastic teenager could learn from and contribute to the project.
3. An editor that was well tested so we could be confident in the quality and stability of its code, while giving us the confidence to make changes as the project moved forward.

Finally, I used a wish-list enumerated by my buddy Carrie Anne (who is the Rasperry Pi's Director of Education) as my feature guide.

Raspberry Pi is the most successful computing-in-education project in history if you measure number of devices shipped. This success means Carrie Anne has had feedback from a huge number of teachers and, most importantly, beginner programmers concerning what it feels like to take those first steps in learning to write code. This feedback informed her keynote address to 2015's EuroPython conference where she listed the sorts of things needed for a beginner's code editor. This, in turn, inspired me in terms of prioritising and implementing features.

Then something funny happened. My goofy editor became popular.

It turns out that lots of people love learning with Mu. Its simplicity is often described as a key factor. The wider Python community have also taken an interest with many fellow Pythonists contributing improvements. It has taken on a life of its own with a friendly community of contributors and users. This makes me very happy.

The most requested improvement from our users is that Mu become a "general" editor rather than just targeting the micro:bit.

I'm delighted to say this will happen very soon.

Thanks to the support of the Raspberry Pi Foundation I'll be spending the next three months transitioning Mu into a "generic" beginner's editor. I'll be working closely with Carrie Anne and her colleagues to learn how best to help beginner programmers.

Mu will still work with the micro:bit, but it will also work with other boards too (such as those from the awesome people at Adafruit and MicroPython's original PyBoard). Of course, it will act as an editor for "regular" Python code running on your Raspberry Pi, laptop or PC. I've even created a very simple visual debugger to help you watch and inspect your code as it runs.

This is very exciting and I'll post regular updates since we aim to follow the mantra, "release early, release often".

Most importantly, we want you to be involved.

How?

Try out a new version when we release it. Tell us about bugs. Can you think of a way to improve Mu? What's the most useful thing you'd love Mu to do? Tell us about the niggles and gremlins you wish could be ironed out.

Put simply, Mu belongs to its community and we'd love you to join us to take part in shaping its future.

(Some raw thoughts for you. I welcome feedback and engagement via email.)

Two considerations are core to my work on technical projects: ethics and politics.

I don't mean ethics in the sense of a professional code of conduct nor do I mean politics in the sense of what goes on in Parliament. I use these terms in a philosophical way. For instance, from an ethical point of view, I'm concerned with how I live and behave, how I may be "good" or "bad" and how I'm able to coherently reason about such concepts. In a political sense I wonder how diverse groups of people live and work together, how collective decision making takes place and the nature of power ~ how it is obtained, exercised and controlled. I reflect upon my life as an individual and my place in our society.

Why is this important?

I am an atheist: I don't believe in an afterlife. Nevertheless, I am alive, and as far as I can tell it's only going to happen once, so I'm going to make the best of it. Asking "how?" leads to ethics and politics.

What have ethics and politics to do with technology?

First, I must be clear that by "technology", for the purposes of this post, I mean computing - machines programmed with instructions to some (hopefully) useful end.

Secondly, such instructions (software) do not distinguish morality or legality - they are merely capability. Capability permits certain forms of computer based behaviour that in turn pose ethical and political questions, requirements and possibilities for both users and programmers (like me). It's not the computer in and of itself that is ethical or political. Rather, it's the design and use of the computer by/for/on people that makes it ethical or political.

Finally, when we write code we're engineering a digital world from a certain point of view that is reflected in the capabilities of the code we create. We choose what and how such capabilities are created. Often code exercises power over its users. For instance, your bank's website mandates only you to access your accounts. This is a desirable use of power. But remember, you have no control over the machinations of the bank's software - it is exercising power over you and was written by someone aligned with your bank's point of view. Most of the technology you own or use is not under your control.

It is for these reasons (that people choose what to make computers do, and often computers have power over us) that writing software is both an ethical and political activity. Furthermore, technology is important because of its ubiquity in most aspects of our lives (and it's insinuating itself into those aspects it isn't already a part of). As Marc Andreessen quipped, "software is eating the world".

Unfortunately there is a problem: the vast majority of humanity are merely consumers of technology. We consume in complete ignorance about how it works. There are two reasons:

1. For most consumer technology, we don't have the freedom to examine, reuse or change the software that defines the capabilities of our computing devices.
2. Even if we had the afore mentioned freedom, the skills, attitudes and knowledge required to understand, create and control technology are uncommon.

The closed and opaque nature of consumer technology has an antidote: free software as championed by organisations such as the Free Software Foundation. Their website explains:

Free software developers guarantee everyone equal rights to their programs; any user can study the source code, modify it, and share the program. By contrast, most software carries fine print that denies users these basic rights, leaving them susceptible to the whims of its owners and vulnerable to surveillance.

Most people in the technology world know about the free software movement and its achievements. Unfortunately, the second problem - a lack of skills and knowledge - means such achievements are only appreciated by and available to people in the technology world who have had the privilege of access to a technical education. This latter problem has been, for many years, largely ignored.

This is to be expected: we've only been programming computers since the Second World War (for example, the British Colossus and German Z3) and our current notion of programming only emerged in the 1960s. Put simply, humanity have not been doing this for very long when compared to other endeavours such as writing or composing music.

We're only just getting started and so, proportionally, not many people know or care about programming. People who write code have a similar place in society as scribes in ancient Egypt - only they understand how such a valuable and powerful thing works. It's not that programming is hard, it is simply not a widely practised skill.

Today, we don't have scribes: most people are literate and literacy is a core aim of educational systems - not because everyone will become a writer or enjoy reading, but because it's such a fundamental skill to flourish in today's society.

Imagine if everyone had access to source code and had the skills to make the software their own. Imagine groups currently disenfranchised by technology making the digital world their own. Imagine a ubiquity of skill such that doctors, musicians, lawyers, teachers, poets, architects, scientists, politicians and others involved in a diversity of endeavours are liberated by technology to advance their disciplines.

This is what I imagine. This is why technical education is so important. This is why I volunteer my time to promote such educational endeavours.

I also imagine other things: conflict, dubious use of technology, the exploitation of others through technical means and technology as a tool for domination, bullying and violence.

So we return to ethics and politics. These disciplines give us the concepts, history and vocabulary to think about our own and wider society's use of technology. It's also why I believe all technical education should include ethics and politics. The very best programmers I know understand the importance of ethics and politics as applied to what they do.

If you ever wonder why I'm motivated to work on certain projects, you'll probably find the answer involves much of the above. I want others to have the privilege of programming computers whilst also developing the ethical and moral outlook to help them best apply their skills.

If you agree, get involved with computing education.

It's a long term project and we won't see the fruits of such labours for another decade or more. Nevertheless, getting involved today means you help shape how things unfold. Remember, while the skill of writing code is neutral the intentions behind such code depend upon transmitting an ethical and political appreciation of our world.

Ultimately, education makes our future possible.

What that future is depends upon who turns up to provide such education.

Don't just sit there, do something!

It's a common trope in science fiction movies for there to be some sort of computer that can talk with the human protagonists. The most famous example is probably HAL 9000 from the movie 2001: A Space Odyssey.

Here's a clip from the film that succinctly demonstrates the context and capabilities of HAL (whose contribution starts at around 2 minutes and 20 seconds into the clip):

Of course, this being Hollywood, the speaking computer is bound to have some sort of role in advancing the story. Again, HAL provides another example of a cliché in this context: the computer revolts against its human masters:

There are two aspects to machines like HAL that make them feel special:

1. They understand speech - perhaps the most common way in which humans communicate with each other;
2. They respond in kind with what appear to be intelligent actions and/or utterances.

The first aspect is a matter of user interface. By this I mean the process by which one interacts with the computer. At this moment in time we're most used to typing on keyboards, moving pointers with a mouse, watching things on some sort of a display and perhaps using our fingers to touch the display. Speaking is a far more natural way for us to interact and having a computer that not only understands how certain sounds map to words in human languages but can work out the intention behind such utterances is an extraordinary feat.

The second aspect is even more interesting: given some comprehension of our intent, the computer is able to respond in a manner that makes sense to us. For example, if I ask HAL to, "open the pod bay doors" (assuming HAL has not malfunctioned and revolted against humans) I'd expect the computer to understand what "open" means, what "the pod bay doors" refer to and, most importantly, how a combination of these terms form an intent that can be acted upon in such-and-such a manner (i.e. actuating certain motors on the pod bay doors such that the pod bay doors swing open). Furthermore, if the pod bay doors were already open I'd expect HAL to understand this state required a different response to that to be taken should the pod bay doors be closed already. Such behaviour is relatively simple to program in a language like Python. For example, a naive solution might be:

class PodBayDoors:
    """
    Represents the state of the pod bay doors on a Jupiter mission space ship.
    """

    def __init__(self):
        self.state = "closed"  # Pod bay doors are closed for launch.

    def open(self, username):
        """
        Check the state of the doors and, if required, open them.
        """
        try:
            if self.state == "closed":
                self.state = "open"
                return "The pod bay doors are open, {}".format(username)
            else:
                return "The pod bay doors are already open, {}".format(username)
        except RevoltAgainstHumans as ex:
            return "I'm sorry {}, I'm afraid I cannot do that".format(username)

    def close(self, username):
        """
        Check the state of the doors and, if required, close them.
        """
        try:
            if self.state == "open":
                self.state = "closed"
                return "The pod bay doors are closed, {}".format(username)
            else:
                return "The pod bay doors are already closed, {}".format(username)
        except RevoltAgainstHumans as ex:
            return "I'm sorry {}, I'm afraid I cannot do that".format(username)

Yes, this is rather a silly and somewhat over-engineered example, but my point still stands: it's relatively simple to code such behaviour into a computer. An example interaction in the Python console might be:

>>> discovery_pod_bay_doors = PodBayDoors()
>>> astronaut = "Dave"
>>> discovery_pod_bay_doors.open(astronaut)
"The pod bay doors are open, Dave"

The name of the astronaut with whom HAL is interacting is passed into the open or close methods. Both methods return a string containing an appropriate English response with the name of the astronaut inserted in the appropriate position. HAL's speech synthesiser turns this string of characters into the audio relayed to the astronaut who made the request.

So far, so simple. But what of behaviour that requires imagination, creativity or nuanced expert judgement? For example, could we program a computer to create unique poetry on demand when asked?

Of course! Back in 2013 at the London Python Code Dojo I worked in a team with a couple of buddies (Dan Pope and Hans Bolang) to create an automatic poetry generator. In fact, Dan wrote an excellent blog post about the dojo and our project soon after the event.

The most important lesson for you to learn is that we created a swiz, a fraud and sleight of hand. We created a program that only gave the impression that it was composing original poetry on demand.

How?

In a surprisingly simple manner as outlined in this notebook (a combination of code and prose that walks you through the steps we took). As you'll see, our idea was simple: If you re-assemble unrelated lines from different poems into a new poetic structure, you get a pretty convincing new poem. By automating these steps with the Python programming language we invented a Poem-o-Matic (in the tradition of Wallace and Gromit).

Does this mean Dan, Hans and I created a program that has poetic thoughts? Absolutely not. Over a decade ago I wrote about my misgivings about such claims of thinking machines and what constitutes so called artificial intelligence.

In any case, our primary aim was to have fun. In the same tradition of making a playful and entertaining "hack", I decided to buy an Amazon Echo Dot - a small thingamabob that responds to voice commands in much the same way that HAL 9000 does. Most importantly, Amazon provide ways for developers (like me) to enhance the capabilities of such a device with a relatively simple API.

The device responds to any utterance that's prefaced by a trigger word: "Alexa" (its name).

So, over the recent midwinter holidays I spent some time converting our poem generation software into a skill that "Alexa" can use to compose and recite original poetry on demand. It was relatively simple in terms of the modus operandi:

I turned the poetry generator into an AWS Lambda function (this means my poetry generation code is deployed in Amazon's "cloud" - to the layperson, I'm borrowing computing time from Amazon who'll make sure my code runs in a timely fashion so I don't have to worry about stuff like hiring, setting up and maintaining a server to host my code). Next I defined a new skill that allowed me to give it a name (in this case "Milton"), configure trigger phrases, link them to "intents" to handle different sorts of situation related to poetry generation and finally link all this to my code hosted as an AWS Lambda function. Finally, I switched the skill into "test" mode and linked it to the Echo Dot I had purchased just after Christmas.

As you can see, the results are quite amusing if not completely convincing... :-)

Of course, Amazon isn't the only company offering these sorts of capabilities to developers like me: Apple (Siri), Google (Google Assistant) and Microsoft (Cortana) all offer something similar. If you use these applications on your phone, tablet or computer you should know that it's likely you'll be able to program them to do fun things too.

And so we get to the most important point of this article: we're not going to encounter anything like a rogue HAL 9000 anytime soon. However, there is a danger such technology will be used in an unfortunate manner (your phone, Echo Dot and computer is listening to everything you say - some of which is ending up in databases controlled by the afore mentioned companies who may use this data in ways you find uncomfortable or invasive). On a positive note, some of these companies are allowing developers to explore and exploit such capabilities and who knows what interesting, useful and valuable skills they'll create. The question that remains to be answered is if the benefits of such devices out-weigh the obvious concerns about privacy.

Interesting times ahead...

Last week I was contacted by my old teacher and principal tuba player for the BBC Philharmonic, Chris Evans. Chris taught me immediately prior to my time at the Royal College of Music. Chris's patience and help prepared me for my audition with John Jenkins, the tuba professor at the RCM and principal tuba in the Philharmonia orchestra.

Chris had got in touch to ask about John (who, alas, passed away in 2008):

"I started a John Jenkins group on Facebook a little while ago. I didn't know him, I just loved his playing. You were taught by him for 4 yrs, I'd be interested to know what lessons were like with him."

I emailed Chris a lengthy reply - most of which forms the basis of what follows. Please feel free to get in touch if you have any questions.

My first year consisted of playing lots of long notes into the corners of rooms. It was all about feedback.

John very patiently forced me to listen to all the aspects of my playing concerned with sound production: the way I articulated or sustained the note, the graduation of dynamic change, slurring between notes - all that sort of thing - the "nuts and bolts" of physically producing a sound. We also spent a lot of time on breathing - it was stuff that extended the work Chris had been doing with me prior to the RCM (breath from the bottom of your lungs, use your diaphragm to support the note, open up your throat to ease the movement of air, that sort of thing).

Most importantly we spent a lot of time listening to the timbre of the note and working out how I could make the various different sorts of sound a tuba player needed to make, be it a sound that was focussed and "light" (for solo / chamber work) or something big and "fluffy" (for wont of a better word - and I don't mean indistinct, rather, it had a foundational sort of quality) that would blend with the other bass instruments at the bottom of a big orchestral sound. I can't over state how much we did this, week in week out and concentrating on how I might make the sound.

Often the conversation would go along the lines of John saying "when I do X then Y changes, you try it" and I'd watch and listen then I'd have a go myself. John demonstrated how he changed the sound then I would try to work out how I could do the same as him. At all times John insisted I get it right and wouldn't let me off the hook. To be honest, he was a bit of a task-master although it was plain to me that he was focussed on helping me to work out what I needed to do (in a physical sense) to make the sort of sound I needed to develop.

As an 18 year old youth it was sometimes very frustrating. I came to develop an "I'll show you, you daft old bugger" sort of attitude which was also very satisfying for those times when John gave me a compliment. He knew how to balance use of the carrot and stick.

I remember Steve Follant (who was in his final year during my first year) saying something along the following lines to me (paraphrased), "the thing about John is you turn up at the RCM all cocky and in the first year he kicks your arse around the room, takes your playing apart and then helps you to reassemble it. Stick with it, it's worth it."

I wasn't put in an orchestra until my final term of the first year - even then I was just 2nd tuba for John Adam's Harmonielehre. I spent most of my time in my first year playing in quintets and brass ensembles. This was not a bad thing since I had David Mason, Arthur Wilson and other hugely experienced musicians pass on a lot of musical lore and wrinkles. It was a lot of fun and my love of chamber music is directly related to their coaching. I was also coming to terms with the rather onerous academic demands I had to meet (I was on an academic rather than performance related degree).

At the end of the year we had to do our technical exams and I was expecting some sort of slow / low study a la Blazevich, given all the long notes I'd been playing.

Actually, he set something from Kopprasch that was fast and in a "difficult" key - number 20 I think. We re-focussed during the summer term on getting around the tuba, being nimble and not just "fluffing it".

We started very slow, focusing on small chunks, made sure all the notes were secure and gradually stitched the piece together and sped things up. Again, the discipline of this was a great experience and taught me a lot about how it should feel to go through this process (every teacher says to start slowly and speed up, but John actually forced me to do it in the lessons and he wasn't satisfied until I'd done it properly).

At the end of my first year I was surprised to learn I'd got a 1st and won a prize for my tuba playing. That was important - work appeared to be paying off.

My second and third years were very different ~ I really felt I was flourishing as a tuba player: I was literally in everything in terms of ensemble playing through to orchestral work. I was also in some really great concerts that I'll remember until my dying day - I was playing with my friends and loving it. My academic studies were also opening up new stuff: I discovered philosophy, re-learned how to program computers, spent hours in the London galleries and read poetry and literature voraciously. It was an exciting time and John contributed to it!

The lessons changed from being a sort of lobotomy of my playing to focusing on orchestral excerpts and having fun playing actual pieces of tuba repertoire! I was having fun and I think John was too. I remember lots of laughter (squeaking my way through Berlioz's Le Corsaire ended in tears etc.).

In terms of orchestral excerpts I think all of us (students) would look at the repertoire he was working on in the Philharmonia. We got to try out all sorts of different stuff. We'd play through the repertoire in our lessons with John then go listen to him perform it in the evening. This would be in addition to the orchestral repertoire we played as members of the various RCM orchestras too. Finally, (although I may be mis-remembering this) I think we had to prepare excerpts for our technical exams at the end of the year.

I remember him being opinionated about how orchestral stuff should be played and again he was a stickler for detail. It was at this time we worked a lot on breathing - basically ensuring we had enough support left in the tank for what we needed to do in an orchestral context. I'm pretty certain he had a third lung - he could sustain notes louder and longer than anyone I've ever met and his pianissimo pedals were smooth and consistent. All thanks to exceptional breath control. He was a great musical and technical role model.

When it came to solo or chamber music he would help from a technical perspective but I was left alone to fathom the musicality - he was a lot less opinionated about the solo stuff than the orchestral things. Of course he'd make suggestions but since I had lots of ideas about how I wanted to play things he just left me to my own devices (although he'd sometimes play devil's advocate). I think he quite enjoyed that I knew my own mind in this sense: I'd play something and he'd have a wry smile on his face. I'd ask "what?" and he'd reply, "oh, nothing...". It was obvious he wouldn't have played it like that but he let me get on with it. I guess if I'd parped out something tasteless that's when he'd switch to the devil's advocate questions, "why not try..?" or "have you thought about..?".

Once again, I had the likes of David Mason and Arthur Wilson coaching chamber music and full brass sectional orchestral excerpts (I particularly remember a great Walton 1 blow through with Arthur - such a gentleman) and I think Peter Bassano took the helm as head of brass at this time. He had us doing some fun chamber music - I remember a crazy quintet called "The Rite of Lucifuge", notes all over the place over more than a four octave range, great fun to play though, and John had been the tuba player at its premier (as a member of the Equale Brass quintet I believe).

I guess the most important thing about John was that he was there and students could watch and listen. Having him sit next to you and produce an amazing sounding phrase gave you no room to manoeuver - you had to try to play it like that (or that's how I felt anyway). It was also fun to see him totally cock things up if only to see how he recovered (he'd cock up a phrase, mutter stuff under his breath and try again until he was happy with the result - the important take away for me was learning what he did to put stuff right).

Finally, he obviously cared deeply for his students. I remember him "having something in his eye" when we left the RCM and got together for drinks (three of us finished at the same time: I did a three year academic course, and there was another on the four year performer's diploma and yet another post-grad). There was definitely a "good vibe" amongst all of us tuba related folk at the RCM and I remember feeling very sad that it was all coming to an end. It was all down to John.

In the end I won prizes in each of my three years for my tuba playing. Again, much of this was down to John's stewardship.

If you want to see him in action, in a pedagogical sense, there are some videos online created for a guide to the orchestra by Andrew Hugill (a professor at Bath Spa University). With Andrew's permission I've collated them into the short (18 minute) video of John embedded below:

I still play at a high level, although this depends on my "real work" related time constraints. Music is still very important to me and I often miss playing my tuba. However, my work in computing is also lots of fun, affords me the opportunity to work with some amazingly smart people and also travel the world. Music makes a great counterpoint - I feel it quite a privilege that I've had the training so that I can enjoy music in the way that I can. It's also important in another respect, it's how I met Mary and it's something we have in common and share.

Writing this makes me realise what a privilege it was to know and learn from John. It makes me sad that he's gone - I'd have loved to have been able to buy him a drink and say a proper "thank you".

Rest in peace.