Category: Uncategorised

A few months ago I blogged about what I was working on, both in my professional life and the things I do outside of work. This is where I’m at in June 2026:

• I’m about to do a talk about Communities of Practice at UCISA’s SSG26 conference. This will involve travelling from the Isle of Wight to Leeds during the tail-end of a heatwave, so will be an adventure within an adventure.
• Once that’s done, I’ll be putting the final touches to a talk for itSMF about using AI to move some of our Service Management practices from decision-by-opinion to a more data-driven solution. I’ll also talk about some of my early experiments with using AI to build tools to measure all sorts of things.
• I’ve been learning more about neurodiversity; more formally now, along with many other colleagues from the University of Birmingham. We’re using National Neurodiversity Training as a provider, and I would definitely recommend them.
• I’ve been thinking a lot about operating models and team topologies and taxonomies. I’m fascinated by the structures that organisations choose, but also the change journey they take to reach their final (or latest) form. I’m working on a simulation exercise that explores some of these concepts, as well as how to be in a team with people who do a different job to you, or at least have different core skills.
• I’m trying to commute sustainably where possible; generally a combination of my Brompton for short trips, supplemented by trains. It’s been good to get back on a bike after a short period away, although the current heatwave has made me very glad I don’t have to commute right now as I’m in the middle of a short holiday.

The Ferris Sweep is a 34-key split board with an aggressive stagger. I have built a few of these, both for my own use and to sell.

Parts list

This is what we need to build a Ferris Sweep:

• Sweep 2.2 PCB. I get mine printed by JLCPCB.
• Two controllers and sockets. I generally use Pro Micro RP2040 controllers for these builds.
• 34 Choc v1 switches.
• 34 1U Choc v1 keycaps. Blank keycaps will bring the cost down if they are an option for you.
• 2 TRRS jacks (PJ-320A)
• TRRS cable
• Cable to match controllers chosen (almost certainly a USB-C cable)
• 10-12 rubber feet (these are definitely not optional on this build)

All the example code in this guide will be assuming that the Vial firmware will be used. It requires having a working installation of the vial-qmk github repository.

Flashing Controllers

Flash each controller to test they work, and to define which controller belongs to which side of the keyboard.

Firstly test that your firmware compiles:

qmk compile -kb ferris/sweep -km vial

Then flash each controller in turn:

Pro Micro RP2040

qmk flash -c -kb ferris/sweep -km vial -e CONVERT_TO=rp2040_ce --bootloader uf2-split-left
qmk flash -c -kb ferris/sweep -km vial -e CONVERT_TO=rp2040_ce --bootloader uf2-split-right

If you get the message Waiting for USB serial port - reset your controller now (Ctrl+C to cancel) you will need to Short RST to GND quickly in order to flash the controller.

Elite-Pi

qmk flash -c -kb ferris/sweep -km vial -e CONVERT_TO=elite_pi --bootloader uf2-split-left
qmk flash -c -kb ferris/sweep -km vial -e CONVERT_TO=elite_pi --bootloader uf2-split-right

Frood (and other RP2040 controllers)

qmk flash -c -kb ferris/sweep -km vial -e CONVERT_TO=rp2040_ce --bootloader uf2-split-left
qmk flash -c -kb ferris/sweep -km vial -e CONVERT_TO=rp2040_ce --bootloader uf2-split-right

Elite-C

qmk flash -kb ferris/sweep -km vial --bootloader dfu-split-left
qmk flash -kb ferris/sweep -km vial --bootloader dfu-split-right

Once you have done this then label the controllers so you are absolutely sure which is which.

If QMK encounters errors it will let you know. Fix any errors before proceeding to the next step.

PCB

These steps will get us a PCB that we can test:

1. Solder the sockets to the PCB
2. Solder the TRRS jacks to the PCB
3. Socket the controllers (for this build both controllers will be face down, but there is a handy message printed on the PCB which will help with orientation)
4. Connect the two halves with the TRRS cable

Testing

Plug the keyboard into a computer, and short every single socket to test that the right key codes are sent. I use QMK Configurator to test this.

If anything does not work, fix it before soldering switches.

Soldering switches

Press each switch into the PCB, and ensure they are straight. Then solder each one in turn.

Once the switches are soldered, repeat the same tests as before. If any switches do not work, or behave oddly (repeated keys, excessive chatter etc.) then resolder them.

Final touches

Apply 5-6 rubber feet to the bottom of each half of the PCB, and then add keycaps.

Alternatives

I have used the Mechboards Ferris Sweep for a few builds, and it’s great. All you need with this one is controllers, keycaps and switches. It’s also got a functional case, and will work with the fancier cases that Mechboards sell.

The last few months have been very productive, both in my professional life and the things I do outside of work. I thought it was worth summarising the things I’ve been doing, and therefore the things I’m interested in talking or writing about at some point:

• There has been a big focus on AI, both personally and professionally. I have learnt to use all sorts of different AI tools; from setting up a LM Studio server at home, to using AI to analyse and visualise all sorts of things at work. I did a talk on this in December 2025, where I summarised the work so far, and also explored the cost of doing these kind of experiments; both the monetary cost and the cost to the planet. I am also reading a lot of books on AI, which deserve their own blog post at some point soon.
• The next big piece of work in this area is around documentation standards, so that everything my team writes is equally accessible to people and AIs. The answer to this is basically to master everything in Markdown and then publish to wherever the content needs to be. I’ve been writing in Markdown for over a decade, and this blog already adheres closely to these principles, so I do at least have a starting point.
• Last year I spent time setting up my organisation’s Agile Community of Practice, and this year I’ve been doing more work in this space, as well as thinking about how these communities can play a part in providing tier zero support to users. I’m doing a talk about this in July.
• I’ve been moving some of my workflow over to macOS, and as a result have been working on ways to make all my computers have the same key software, with the ability to install additional things based on what they will be used for. My Mac setup script is available for anyone to use, but it’s mainly geared around my own requirements. I’ve also been making improvements to my Ubuntu update script that I use to ensure that everything on my home servers is up to date.
• The new version of ITIL has been a big thing professionally this year, and I’ve been spending time thinking and writing about this, and also about the ever-narrowing gap between ITIL and Agile, which to me are two slightly different ways of describing what is largely the same thing.
• I’m always interested in how I can improve myself, and create the best environment for my team to work in. This will always be a focus for me, but more recently I’ve also been trying to help other teams implement some of the things my team have found useful. I’ve been speaking and writing about my organisation’s performance and development reviews over the last few months, and am in the middle of going through the review process with my team, which always spawns new pieces of work, and new ways of thinking about the work we already do.
• I’ve been learning more about neurodiversity, both to better understand how my own brain works, but also to be able to better support colleagues and family members who are also on this journey.

Writing it out like that makes me realise that this is a lot, and that it only really scratches the surface of my areas of interest right now.

I was reading on Reddit about someone who gave an AI $50 and tasked them to use it to make enough to buy a Mac Mini. See here for the website it created to sell prompts it has created, and to read more about the journey it is on. I find this very interesting, especially because the prompts in the free starter pack are very good.

I think this experiment is definitely worth keeping an eye on. So far the highlight for me is that someone decided to pay $150 for the free product, which provoked an immediate reaction from the AI that reads very much like something a person would write. Not so much the words themselves; but their emotional resonance.

These are the kind of experiments I want to see more of.

I always try and keep up with the progress reports from Dropbox’s Virtual First operating model. As well as being a company I’m a long-term customer of, they were also one of the three that I read a lot about when I started to think a bit more overtly about what work might look like in the post-pandemic age (the other two were Gitlab and Buffer). A lot of the routines of my current team took these organisations as an example, in particular how they value asynchronous work, are a remote-first organisation, but still value regular in-person contact; particularly events that put the whole team in one place for long enough to build or reinforce good working relationships. We have been doing this for the last three years; spending one week every six months working in the same place, collaborating closely, and also spending some time getting to know each other as people. It works for us, and is something that allows us to collaborate productively, regardless of where we happen to be.

The 2025 report presents the results of their meeting reduction pilot, which identified that it’s important to understand and articulate the “why” behind meetings, and to try and avoid meetings that don’t have a clear purpose. It’s something we have been trying to do in our organisation, but I think it’s fair to say we have a long way to go. I also like that they are using AI-generated meeting summaries in very much the same way we are; to provide an accurate record for people who can’t attend the meeting, whilst at the same time making it easier for synchronous attendees to be 100% present. That’s what all good meeting transcription tools should do, and I think these tools are now very much a part of how we work; making meetings more accessible to everyone, but also keeping people accountable for things they said they would do.

I made a few tweaks to my crontab builder yesterday. It’s one of a few vibe-coded applications I created just to see what’s possible, and it’s something that actually works quite well for someone who doesn’t use cron often, so needs to read the manual every time. This is exactly where generative AI is really useful; creating simple web applications that help people use their computer more effectively.

For creating things like this I use Github CoPilot within Visual Studio Code, and then Github pages to host the results. It’s all things that are either free or that I get for free because I work in education, so is a setup that many other people could put together easily. It doesn’t require a powerful computer or a fast internet connection, so if you can run Visual Studio Code then working in this way is definitely an option.

It strikes me this morning that it’s now possible to self-publish almost anything, and that the tools to do so are getting easier to use every day. Creating ebooks is trivial using Pandoc, and they can be sold (or given away for free) on Amazon. Distributing music on Bandcamp is equally straightforward, with the ability to collect revenue via Paypal, and also set up a subscription, which is very basic crowd funding. WordPress has always been great for self-publishing writing, but now we also have things like Github Pages, where a whole source-controlled website can be hosted for free. I suspect if this technology had existed 20 years ago then I’d never have started using WordPress in the first place.

It’s 20 years since my oldest blog post was written, but not quite 20 years since I built the blog itself. In that time it’s moved from a box under my desk to a couple of different hosting providers, and it’s been a very interesting experiment to track certain aspects of my life over that time. I’m now also mirroring the whole thing on a Github Pages site, partly for resilience, but also as an interesting experiment to see if I can automate my content publishing pipeline with more than one end-point.

All of this would be possible with true self-hosting, but it would be a lot of work that I don’t have time for right now, and increased responsibility for security in a world where there are more threats that ever. I think the balance between having control over my content and having a straightforward way to publish it is right for me at the moment, but it’s good to be developing the skills to do it a different way if required at a later date.

While Time Machine is an excellent backup solution for macOS, external drives aren’t always the most convenient option—especially if (like me) you already have a Linux server with plenty of storage. By configuring Samba on your Linux server, you can use it as a network Time Machine destination, allowing automatic wireless backups without needing to plug in an external drive. Here’s how I set mine up (I used Ubuntu, but have put in commands for other distros as well).

On Linux

1. Install Samba on the Linux Server

# Ubuntu/Debian
sudo apt update
sudo apt install samba avahi-daemon

# RHEL/CentOS/Fedora
sudo dnf install samba avahi

2. Create a Directory for Time Machine Backups

sudo mkdir -p /mnt/timemachine
sudo chown your_username:your_username /mnt/timemachine
sudo chmod 755 /mnt/timemachine

3. Configure Samba

Edit the Samba configuration file:

sudo nano /etc/samba/smb.conf

Add this configuration at the end:

[TimeMachine]
   comment = Time Machine Backup
   path = /mnt/timemachine
   browseable = yes
   writable = yes
   valid users = your_username
   create mask = 0600
   directory mask = 0700
   spotlight = yes
   vfs objects = catia fruit streams_xattr
   fruit:aapl = yes
   fruit:time machine = yes

4. Set Up Samba User Password

sudo smbpasswd -a your_username

5. Restart Samba and Avahi

# Ubuntu/Debian
sudo systemctl restart smbd nmbd avahi-daemon
sudo systemctl enable smbd nmbd avahi-daemon

# RHEL/CentOS/Fedora
sudo systemctl restart smb nmb avahi-daemon
sudo systemctl enable smb nmb avahi-daemon

6. Configure Firewall (if needed)

# Ubuntu/Debian with ufw
sudo ufw allow samba

# RHEL/CentOS/Fedora with firewalld
sudo firewall-cmd --permanent --add-service=samba
sudo firewall-cmd --reload

On the Mac

1. Connect to the Share

Open Finder and press Cmd + K, then enter:

smb://server_ip_or_hostname/TimeMachine

Enter your username and password when prompted.

2. Enable Time Machine to Use Network Drives

If the share doesn’t appear in Time Machine preferences, you may need to enable unsupported volumes:

sudo tmutil setdestination /Volumes/TimeMachine

Or directly set it:

sudo tmutil setdestination smb://username@server_ip/TimeMachine

3. Configure Time Machine

1. Open System Settings → General → Time Machine
2. Click the + button to add a backup disk
3. Select your network share
4. Start the backup

Tips and Considerations

• Space Requirements: Ensure you have enough space on the Linux server (Time Machine typically uses 1-2x your Mac’s storage)
• Performance: Network backups are slower than local ones, especially for the initial backup
• Reliability: Use a wired connection for the first backup if possible
• Size Limits: You can set a quota using Samba or filesystem quotas to prevent Time Machine from using all available space

Optional: Set a Size Limit for Time Machine

On your Mac, create a sparse bundle with a maximum size:

sudo tmutil setdestination /Volumes/TimeMachine
hdiutil create -size 500g -type SPARSEBUNDLE -fs "HFS+J" 
  -volname "Time Machine Backups" 
  ~/Desktop/TimeMachine.sparsebundle

Then move this to your network share and use it as the backup destination.

I’m currently using a Mac as my main computer, but also have a Linux machine that I use for heavy lifting, but also for backups. Setting up SSH key-based authentication allows rsync to work seamlessly without password prompts, making backing up and file synchronisation much more convenient. This is particularly useful for automated scripts and frequent manual transfers. It’s what I use to ensure that I have a second copy of every file I download, and to keep my music collection in sync, and helps maintain that illusion that all my computers are actually one computer.

Configuration

1. Generate SSH Key on Mac (if you don’t have one)

First, check if you already have an SSH key:

ls -la ~/.ssh/id_*.pub

If you don’t have a key, generate one:

ssh-keygen -t ed25519 -C "your_email@example.com"

Press Enter to accept the default file location, and optionally set a passphrase (leave empty for truly passwordless, or use ssh-agent for security with convenience).

2. Copy Your Public Key to the Linux Server

Use ssh-copy-id to copy your public key to the server:

ssh-copy-id username@server_hostname_or_ip

You’ll need to enter your password one last time. This command copies your public key to ~/.ssh/authorized_keys on the server.

Alternative method (if ssh-copy-id isn’t available):

cat ~/.ssh/id_ed25519.pub | ssh username@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

3. Test the Connection

Try connecting via SSH without a password:

ssh username@server_hostname_or_ip

If it works without asking for a password, you’re all set.

4. Use rsync

Now you can use rsync without password prompts:

# Example: sync a local directory to remote server
rsync -avz /path/to/local/directory/ username@server:/path/to/remote/directory/

# Example: sync from remote server to local
rsync -avz username@server:/path/to/remote/directory/ /path/to/local/directory/

Common Options for rsync

• -a : archive mode (preserves permissions, timestamps, etc.)
• -v : verbose output
• -z : compress data during transfer
• -h : human-readable output
• --delete : delete files in destination that don’t exist in source
• --exclude='pattern' : exclude files matching pattern
• -n or --dry-run : show what would be transferred without actually doing it

Troubleshooting

If you still get password prompts:

1. Check permissions on the server:

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys

2. Verify SSH config allows key authentication (on server):
   Check sshd_config for:

   PubkeyAuthentication yes

3. Check SELinux (if applicable on server):

   restorecon -R -v ~/.ssh

I finished reading How Bad Are Bananas? by Mike Berners-Lee this week. I’ve read bits of the first edition before, but this is my first full reading of the revised edition that takes into account a lot of the recent technological advances. It’s good to know that I’m on the right lines with the way I live my life, but there were definitely some learning points.

Most of the emissions from electrical devices come from the way they are made, not from how they are used. So the biggest positive impact we can have is to use devices for as long as possible, and only replace them when they no longer work. This makes devices that can be upgraded/repaired extra valuable, because it means that their lifespan can be prolonged by adding a new hard drive or some memory. The book was talking about trying to keep computers for 10 years, phones for 5, and televisions/monitors for longer.

Every little helps, but so many things that people concentrate on (sending less emails, using less paper) are really just yak-shaving compared to the things that make a real difference, such as not flying, eating a plant-based diet, and using renewable energy where possible. Transport and food are where most people can make the most difference, so it’s a really good place to start.

Cycling is a great way to travel, but we also need to think about how we fuel that cycling. The book talked about cycle commuting powered purely by cheeseburgers as being no better for the planet than driving a petrol car, and it’s definitely something I need to start thinking more about. It was also interesting to find out that when you take fuel into account, an e-bike is slightly better because it requires less energy from the rider, and therefore less fuel from food. Coupled with a renewable energy source, it it probably the best way to commute.

Both of the ways I commute are relatively good for the planet, so I shouldn’t feel guilty about taking the Brompton onto the train sometimes. It costs money, but requires me to eat less, and also allows me to read and listen to music or podcasts during the train part of the commute. Sometimes that is what I need, and in the scheme of things it’s still a really good travel choice (as is buying a bike that will likely outlive me).

Bananas are a good sourced of fuel in the scheme of things, so I shouldn’t worry about the amount of them that I eat. They have long been one of my main cycling snacks, and I’m glad that the book doesn’t suggest I should stop this.