RAREblog

a pre-alpha version of the Pi (reproduced with permission) A few days ago someone pointed out that it was eight years since Eben Upton's first blog post on the Raspberry Pi website. The site had actually been live for a while (from 6 May 2011), with just enough information to get me and others excited about the potential of the Pi. The website explained that the goal was to produce a low-cost Linux-capabable ARM-based board for educational purposes. That was interesting, but not world-shaking. There were already a few hobbyist SBCs (Single Board Computers), but they weren't cheap. I think the BeagleBoard was over a hundred pounds, and  you needed some specialised hardware to level-shift the 1.8V GPIO pins to a useful voltage. So how much was the Pi going to cost? According to the website The expected price is $25 for a fully-configured system. Back then, that was almost unbelievable. Indeed, to many, it was unbelievable. The early days of the Pi were dogged

I'm working on a micro:bit project book at the moment, and the current chapter covers a Quiz runner application. It needs multiple micro:bits. For testing I need at least three, one for the Quiz runner and one for each of two competing teams. Although the micro:bits have different roles, they are all running the same software. The Quiz runner identifies her micro:bit by pressing button A; her micro:bit then sends a radio invitation for the other micro:bits to check in, team by team. From then on each micro:bit knows its role and can behave appropriately.   Mu and PyCharm   I normally use Nicholas Tollervey's excellent mu editor for MicroPython development, but the Quiz runner program is more complex than most. I am using Git to commit versions as the development progresses. Mu's minimalist design makes it very easy to learn. To keep it simple it has no integration with version control applications like Git, so I am using JetBrains' PyCharm . A few wee

Regular Expressions are powerful but they can be hard to tame. There’s an old programmer’s joke: A programmer has a problem, and she decides to use regular expressions. Now she has two problems. Unless you use regular expressions regularly (sorry for the awful pun!), they can be Hard to read Hard to write Hard to debug reggie makes regular expressions readable and easy to use. I've used regular expressions for a number of projects over the years, but the idea for reggie came about a decade ago. I was working on a project where we had to parse CDRs (Call Detail Records). These are text files that Telecommunication Service Providers use to identify calls and other services billable to their customers. The CDRs we received were CSV files with a complex format and we decided to use regexes (Regular Expressions) to verify and interpret them. We liked regexes, but they were less popular with our business analysts. The BAs were happy with our Java code, but they