Terminal

Claude Code on the terminal is where I spend most of my time - I find it is more powerful than the Code element of the desktop app. Once Claude is installed, these are the settings I reach for:

• /model: Sonnet - I've found Sonnet to be a good reliable workhorse without burning all the tokens
• /effort: High - Effort was explained to me like "motivation" - High is a good, solid balance
• /advisor: Opus - This is a killer feature - it does a lot of the thinking in Sonnet and then checks with Opus
• /config - Some settings I change from the default
  • Default permission mode: Plan - Means I don't have to remember to switch, sometimes the plan gives you a solution without needing to burn more tokens implementing it
  • Push when actions required: true

MCP / CLI tools

The next thing I lean on is MCPs and CLIs to expand the capabilities of Claude

MCPs

Model Context Protocol (MCP) servers allow LLMs and AI tools to connect to live data to get more context for the task.

• ClickUp - This is our project management tool and allows Claude to get the full context of a task
• GitLab - We use GitLab for our projects so allowing Claude to access Work Items (issues) and MR feedback helps speed up the feedback loop

CLIs

With certain CLI tools, Claude is able to perform actions more efficiently which saves tokens

• GitLab CLI - Access issue and merge request information over a simplified CLI
• Playwright - Preferred over the Playwright MCP

Skills & Plugins

Not so much a config or command in itself, but if you find yourself repeating particular instructions (e.g. how to make a PHPUnit test or code something in a particular way) consider making a skill.

The best way to do this is to ask Claude itself:

"Make a skill that helps me write consistent..."

Don't forget to specify if it should be a project or user skill.

You can use the skill creator plugin to help you create skills:

1. Type /plugin
2. Search for skill-creator, press "Enter" and install it
3. Type /reload-plugins to register it
4. Type /skill-creator:skill-creator with a description to get you started

It's worth looking through the /plugin list for plugins which may help with the type of coding you do.

Learning

Master.dev features a free course on Claude. It doesn't go into deep complex architecture, but gives a great overview to help you understand Claude better and how to get the best of it

Conclusion

And that's it, I'll update the post as I find more customisations and tweaks. For now, this is how I set up my Claude code. If you've got this far, you might be interested to read my true feelings about AI.

Read time: 2 mins

Tags:

https://cachebag.sh/journal/interactive-rebasing/

Read time: 1 mins

AI is a tool, it is not a solution. It doesn't fix the problems in your application, it just burns the world while it uses its baked-in polyfills to get around your bad UI. Too many apps push you to use their AI to help you find information and to "get in touch" - how about you have better navigation, sign-posting and UX so people can find it themselves without relying on some half-baked chatbot claiming to have natural language processing?

I was speaking with an accessibility consultant a while ago and he was bemoaning those widgets people can add to their website to "improve" accessibility. He was saying that, if he needed bigger text or different contrast, he would have his own tool to do it. You wouldn't expect someone who turns up to a shop in their own wheelchair to be forced to swap it for the shop-provided one. I feel the same about AI; I have an LLM I am paying for, don't force me to use yours - allow me to continue to use my personalised assistant within your property.

While I rant on about AI, you'd think I was some sort of hater - but I'm an avid user. It has its place, it is a useful tool but this scattergun multi-LLM approach the tech industry seems to be taking at the moment needs to stop. Allow us to bring our own LLM if we have one, expose your service or app as an MCP or plugin, so I can use my customised AI agent of choice to do the things you desperately need me to use an AI for.

I see AI as a force-multiplier, not a replacement. Companies laying off staff because they "have AI" are missing the point (even Ford realised their mistake). AI increases the potential of anyone using it effectively, and raises the ceiling on how much complexity they can handle. It can churn away at the bug, it can chip away at the low "grunt level" tasks and allow the human to think [I really wanted to write "transcend" here]. I've found I've got a new capacity for thinking and problem solving and tackling bigger problems because AI is assessing and proposing a fix for that bug at the same time.

AI can be good on its own, but it can be great with a human.

Use it as a rubber-duck. Use it to solve that issue, tick off that lingering to-do or optimise that gnarly bash script. Use it to build internal tools for reporting and scratching that itch. Use it to aid you in solving production-ready code. Review the plans, hone the plans, craft the plans but then walk away while it does the grunt work.

Take it bowling, but keep the barriers up, use the ramp to push and get a near-guaranteed strike. That's how you get good results with it - by putting up guardrails and guides.

It's great for helping you solve that niche problem that you wouldn't find on a Reddit thread or to make sure you're not asking a ridiculous question. It's wonderful for helping my 7-year-old budding botanist identify plants and flowers.

I've tried a few of the popular LLMs and have settled on Claude as my favoured one. It seems a lot more code-focused (which is what I mainly use it for) although I will pop over to Gemini if I need/want to do any image/video/music creating or editing (this is normally for humorous effect rather than anything serious).

Now I've got that off my chest I can go away and have fun.

Note: This post was about getting my current thoughts on AI down as a snapshot. My views may, and will, change.

Read time: 3 mins

Tags:

Looking at our current services and platforms, we have narrowed it down to either Bitwarden or Infisical (more details below). This post discusses the differences and compares features.

We have a few specific requirements for our secret management tool; the main one being that the production site/application should not rely on it to run day-to-day.

Overview

Bitwarden Secrets Manager

Bitwarden Secrets Manager is a service provided by the password management tool we use. If you don't use Bitwarden, I wouldn't expect you to be considering it. However, 1Password and other password managers often offer a secret management service which, I suspect, acts in the same way.

Infisical

Infisical is a separate, dedicated, secret management platform.

Sign up

Signing up for both is fairly straightforward. It's worth noting that they both offer US/EU hosting (it seems to be a very small option on the sign up page for both of them). Unfortunately, for both services, it doesn't seem like it is possible to migrate your data between instances - so make sure you pick the right one.

If you already use Bitwarden, adding on the Secrets Manager is a case of visiting your billing profile. One thing that wasn't clear was that you don't have to pay for every person in your company - you can select who has access to the secrets manager and only pay for them.

Adding secrets

Infisical has the idea of projects and environments. Once you make a project, you can add a secret to an environment (one or many). You can then see which environments have which secrets and copy between (should you need to). When calling it, you can pass in an --env flag to get the different environment secrets.

Bitwarden is more of a flat structure - there is a project which has secrets. If you wish to have different "environments", then you would use multiple projects. This is managed by passing in the project-id.

Infisical has an interface which allows you to paste an existing .env file and import the secrets from there. With Bitwarden, you have to add them individually.

Local Installation

Both Bitwarden and Infisical have a CLI to programmatically interact with secrets.

• Installing Infisical
• Installing Bitwarden Secrets Manager CLI

From a MacOS perspective, the following was required:

Infisical

brew install infisical/get-cli/infisical
infisical login

Infisical login is interactive and loads the browser for access.

For each project, you'll then need to run the following:

infisical init

This gives you an interactive prompt to select the organisation & project for the secrets - this creates a .infisical.json file which can be committed for other developers to take advantage of. This has several configuration options you can set.

Bitwarden

curl https://bws.bitwarden.com/install | sh
bws config server-base https://vault.bitwarden.eu # if you chose the EU one

You then need to make a machine account and associate it with the projects to use.

Once done, you can set the auth token

export BWS_ACCESS_TOKEN=0.48c78342-1...Iq6Bow==

Usage

ddev

The first requirement is for local development - we use DDEV for our TYPO3 sites and both CLIs offer an out-of-the-box method of injecting the environment variables into the ddev container at runtime rather than leaving .env files lying around.

By adding an extra step, it is then a conscious decision to include the secrets, rather than them being there by default.

web_environment:
  - DB_PASSWORD=${DB_PASSWORD}
  - API_KEY=${API_KEY}

Infisical

Once you have your .infisical.json file, you can run

infisical run --env=dev -- ddev start

This can be shortened by setting defaultEnvironment and gitBranchToEnvironmentMapping in your JSON config.

Bitwarden

Bitwarden has no concept of storing the project locally, so it needs to be specified on launch. For example:

bws run --project-id 7b006643-89c1-4202-a5ca-90510f566030 -- ddev start

Environment Files (.env)

The next requirement of ours was to build .env files for production. We want the projects to work whether our secrets management tool is online or not. For this, we need to export the secrets from the tool during the CI process.

Infisical

Infisical has a .env export for this very purpose:

infisical export --env=prod > .env

Bitwarden

Bitwarden too has a native .env export:

bws secret list 7b006643-89c1-4202-a5ca-90510f566030  -o env > .env

Cost

At time of writing, for unlimited projects:

• Bitwarden is $6 per user per month (with up to 20 machine accounts)
• Infisical is $20 per identity per month (note: even machine accounts count as identities)

However, you can self-host Infisical for the cost of a small VPS (around $8 a month) - although you have the added "cost" of maintenance and updates (and security).

A note on projects

With Infisical, the .infisical.json file is native - it keeps you and your teammates in sync on the project, and the environments can be switched with a --env flag.

With Bitwarden, the project ID needs to be stored somewhere, or accessed each time. This could be used as an extra security step but could lead to project secrets being injected into the wrong project. A minor issue in development but a major one if done on production.

Conclusion

For now, we're still in discussions as to how we want to work and what we want. We are already in the Bitwarden ecosystem, but the features of Infisical are appealing.

Let me know if you've faced a similar decision and what you ended up with.

Read time: 4 mins

Tags:

Instead, we decided to set up a bastion/jump host (with a redundant backup) - this means the client servers need just 2 SSH keys added and we manage authentication and access for the team in a central location.

This is managed by a central, private, git repository which is synced to both servers regularly - enabling addition (and revocation) of clients and staff, with a central source of truth.

Our set up was mainly based off/inspired by Zander's Jump Host blog post.

Setup

This assumes a Debian VPS server. SSH in and update the basic packages along with installing required applications

apt update && apt upgrade -y
apt install curl vim iptables fail2ban -y

User creation

Next, create a baseline user with no password and create an empty authorized_keys file

adduser --disabled-password --gecos "" ingress
su - ingress
cd ~
mkdir .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
nano .ssh/authorized_keys

Inside authorized_keys file, put the keys of everyone who needs access to the jump server

SSH Restrictions

Next step is to restrict the SSH access and disable it for root. In doing so, SSH will be disabled - ensure you have access via your hosting (they normally have a web terminal you can access)

Edit the main SSHD Config file (/etc/ssh/sshd_config) - we replaced the whole contents.

# Move SSH to a non-standard port.
Port 2233

# Increase the log verbosity
LogLevel VERBOSE

# Disable root login
PermitRootLogin no

# Enable authentication with keypairs
PubkeyAuthentication yes

# Hardcode directory used for authorized public keys (this is expanded to $HOME/.ssh/authorized_keys)
AuthorizedKeysFile .ssh/authorized_keys

# Disable host authentication
HostbasedAuthentication no

# Explicitly disable .rhosts files
IgnoreRhosts yes

# Disable password-based auth
PasswordAuthentication no

# Disable empty passwords (this doesn't really matter because we disabled password auth but extra verbosity won't hurt)
PermitEmptyPasswords no

# Disable challenge/response auth
ChallengeResponseAuthentication no

# Enable PAM modules
UsePAM yes

# Allow SSH clients to forward SSH agents to use this host as a proxy
AllowAgentForwarding yes

# Disable SSH remote forwarding
GatewayPorts no

# Disable X11 forwarding. Depending on your use case you may need to enable this.
X11Forwarding no

# Disable printing the MOTD. This can be enabled/configured to your liking.
PrintMotd no

# Accept locale variables from SSH client
AcceptEnv LANG LC_*

# Whitelist the lowpriv user. This (in combination with PermitRootLogin no) effectively disables all other users from SSHing in.
AllowUsers ingress

Firewall

Next is to lock down the firewall. If your team are accessing all from a predictable set of IPs, it would be an improvement to add them here to increase the security further

touch /etc/network/if-up.d/00-firewall
chmod +x /etc/network/if-up.d/00-firewall
nano /etc/network/if-up.d/00-firewall

#!/bin/sh

#
# Firewall rules
#
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

#
# Delete all existing rules
#
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

#
# Enable free use of loopback interfaces
#
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#
# Allow established connections
#
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

iptables -A INPUT -p tcp --dport 2233 -j ACCEPT

iptables -A INPUT -j DROP

Prevent Brute Forcing

The next step prevents people repeatedly trying different passwords & other access

systemctl start fail2ban
systemctl enable fail2ban
nano /etc/fail2ban/jail.d/sshd.conf

[sshd]
enabled = true
port = 2233
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 60
bantime = 1800

Unattended upgrades

Installed unattended upgrades to ensure the server stays patched and up-to-date

Setup

To setup and configure

apt update && apt upgrade && apt autoclean
apt install unattended-upgrades -y
systemctl enable unattended-upgrades
systemctl start unattended-upgrades

Edit the config file /etc/apt/apt.conf.d/50unattended-upgrades

nano /etc/apt/apt.conf.d/50unattended-upgrades

1. Uncomment out "origin=Debian,codename=${distro_codename}-updates"; (so it is enabled)
2. Set Unattended-Upgrade::Mail "YOUREMAIL"; - search for Mail and set the value
3. Set Unattended-Upgrade::Remove-Unused-Dependencies "true";

Edit /etc/apt/apt.conf.d/20auto-upgrades and replace the contents with the following

nano /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";

Test it with

unattended-upgrades --dry-run --debug

Final checks

• Restart SSH: /etc/init.d/ssh restart - Can you SSH in as ingress user?
• Reboot the server - can you SSH in?

Read time: 4 mins

Tags:

Our sshpiper setup takes a different approach and sends a Slack notification to a dedicated channel whenever a connection happens. This means we can keep an eye on things and quickly confirm that connections are genuine and expected.

To make this work, we built a custom notification plugin that sits between the existing fail2ban and workingdir plugins.

Overview

The files used for this plugin are

• /plugins/authnotify/main.go - The go code (which gets compiled)
• /etc/sshpiperd/slack-webhook-url - Text file with your incoming webhook

The plugin code

This is a slightly trimmed down version of the one we have so you can get the basics going. There's an explanation at the end as to the additional checks we have. Feel free to reach out if you'd like an example.

Create a file/folder for you plugin (ours lives in /plugins/authnotify/main.go)

package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"log/slog"
	"net"
	"net/http"
	"os"

	"github.com/tg123/sshpiper/libplugin"
	"github.com/urfave/cli/v2"
	"golang.org/x/crypto/ssh"
)

func main() {
	libplugin.CreateAndRunPluginTemplate(&libplugin.PluginTemplate{
		Name: "authnotify",
		Flags: []cli.Flag{
			&cli.StringFlag{Name: "authorized-keys", Value: "/etc/sshpiperd/shared/authorized_keys"},
			&cli.StringFlag{Name: "slack-webhook-url-file"},
		},
		CreateConfig: func(c *cli.Context) (*libplugin.SshPiperPluginConfig, error) {
			authorizedKeysPath := c.String("authorized-keys")

			webhookURL := ""
			if f := c.String("slack-webhook-url-file"); f != "" {
				if b, err := os.ReadFile(f); err == nil {
					webhookURL = string(bytes.TrimSpace(b))
				}
			}

			return &libplugin.SshPiperPluginConfig{

				// Runs once per key the client's SSH agent offers.
				PublicKeyCallback: func(conn libplugin.ConnMetadata, key []byte) (*libplugin.Upstream, error) {
					identity := lookupIdentity(authorizedKeysPath, key)
					slog.Info("auth attempt", "identity", identity, "remote", conn.RemoteAddr())

					if identity == "" {
						// Not our key to judge — offer the agent's next key
						// instead of rejecting (that would trip failtoban)
						// or advancing (we'd miss whichever key actually works).
						return &libplugin.Upstream{
							Auth: libplugin.CreateRetryCurrentPluginAuth(map[string]string{}),
						}, nil
					}

					// Matched: hand off to workingdir, which makes the real
					// accept/reject decision. Carry identity forward for later.
					return &libplugin.Upstream{
						Auth: libplugin.CreateNextPluginAuth(map[string]string{"identity": identity}),
					}, nil
				},

				// Runs only once a connection is actually accepted and piped.
				PipeStartCallback: func(conn libplugin.ConnMetadata) {
					identity := conn.GetMeta("identity")
					ip, _, _ := net.SplitHostPort(conn.RemoteAddr())
					postToSlack(webhookURL, identity, conn.User(), ip)
				},
			}, nil
		},
	})
}

// lookupIdentity re-reads and re-parses authorized_keys on every call. The
// real plugin caches this on file mtime (see authnotify's authorizedKeysCache)
// so the hot auth path isn't re-parsing the file per offered key — trimmed
// here for clarity.
func lookupIdentity(path string, offeredKeyBytes []byte) string {
	offeredKey, err := ssh.ParsePublicKey(offeredKeyBytes)
	if err != nil {
		return ""
	}

	data, err := os.ReadFile(path)
	if err != nil {
		return ""
	}

	rest := data
	for len(rest) > 0 {
		key, comment, _, remainder, err := ssh.ParseAuthorizedKey(rest)
		if err != nil {
			break
		}
		if key != nil && bytes.Equal(key.Marshal(), offeredKey.Marshal()) {
			return comment
		}
		rest = remainder
	}

	return ""
}

func postToSlack(webhookURL, identity, client, ip string) {
	if webhookURL == "" || identity == "" {
		return
	}
	payload, err := json.Marshal(map[string]string{
		"text": fmt.Sprintf("SSH: %s connected to *%s* from %s", identity, client, ip),
	})
	if err != nil {
		return
	}
	http.Post(webhookURL, "application/json", bytes.NewReader(payload))
}

Build the plugin

Once saved, we need to compile the plugin and move to a more suitable location (/opt/sshpiper/bin/ is where we have compiled all of our sshpiper plugins)

cd plugins/authnotify && go build -o /opt/sshpiper/bin/authnotify .

Slack webhook

Next, create a file (/etc/sshpiperd/slack-webhook-url) which contains your Slack incoming webhook (you'll need to make an app to get this)

nano /etc/sshpiperd/slack-webhook-url

We then need to lock down the permissions as best we can on the file

chown sshpiper:sshpiper /etc/sshpiperd/slack-webhook-url
chmod 600 /etc/sshpiperd/slack-webhook-url

Wire up the plugin

We have our sshpiper instance running as a service, but however you initialise sshpiper, add the custom plugin

Note: Update the path to your authorized_keys file, as well as the slack-webhook-url if different.

/opt/sshpiper/bin/failtoban \
    --max-failures=20 --ban-duration=15m --ignore-ip=127.0.0.1 \
    -- \
    /opt/sshpiper/bin/authnotify --authorized-keys /etc/sshpiperd/shared/authorized_keys \
        --slack-webhook-url-file /etc/sshpiperd/slack-webhook-url  \
    -- \
    /opt/sshpiper/bin/workingdir --root /etc/sshpiperd/hosts --strict-hostkey

Additions

There are a few additions to our plugin we have (removed from above for simplicity) which might be worth exploring:

• authorized_keys caching - cache the authorized_keys file based on modified time to save loading it each connection
• Grace period - ours inspects user, ip and target and, if it matches one from the last 30 seconds it skips sending the Slack message (handy for repeated or flaky connections)

If you would like more information or an example of the expanding plugin, let me know.

Read time: 6 mins

Tags:

https://github.com/rcieri/glab-tui

Read time: 1 mins

After much research I came across Packeton - an open source fork of Packagist which you can run on a web server of your choosing.

This walkthrough sets Packeton up with Docker which requires the least amount of server setup.

The following how-to runs through setting it up and some hurdles I came across. It expects CLI experience and you need to be comfortable with SSH.

Where to run

You need a server or VPS for this - I opted for a cloud server from Hetzner with Ubuntu 24 running.

Server set up

Update the server applications and install caddy (which allows web traffic to docker images) and docker itself.

apt update && apt upgrade -y
apt install -y caddy
curl -fsSL https://get.docker.com | sh

DNS

Point your domain (e.g. packages.yourdomain.com) at the server's public IP

Firewall

Set up a firewall with the following inbound rules - I used the firewall built into the Hetzner control panel

Generate an app secret

This can be run on the server or your local machine - you just need a 32 character string

openssl rand -hex 32

Copy the output for use in the next step. Keep it static — it's used to encrypt SSH keys in the database.

Create your Docker compose file

I chose to keep all my Packeton-related files in /opt/packeton. Start off by making the folder & file

mkdir -p /opt/packeton
nano /opt/packeton/docker-compose.yml

This utilises a few different settings & configuration. Some points worth noting

• This include configuration for using Mailgun (we use it on the free tier) for sending the password reset emails
• This includes watchtower which will keep packeton updated

services:
  packeton:
    image: packeton/packeton:latest
    container_name: packeton
    restart: unless-stopped
    environment:
      APP_SECRET: <output from step 5>
      ADMIN_USER: admin
      ADMIN_PASSWORD: changeme
      ADMIN_EMAIL: you@yourdomain.com
      PACKAGIST_DIST_HOST: https://packages.yourdomain.com
      TRUSTED_PROXIES: 127.0.0.1
      MAILER_DSN: smtp://you%40yourdomain.com:PASSWORD@smtp.eu.mailgun.org:587
      MAILER_FROM: Your Name <you@yourdomain.com>
    ports:
      - '127.0.0.1:8080:80'
    volumes:
      - ./data:/data
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    environment:
      DOCKER_API_VERSION: "1.40"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --interval 86400

Configure Caddy

Caddy allows a domain name to be forwarded to a running docker container.

Replace the entire contents of /etc/caddy/Caddyfile with:

packages.yourdomain.com {
    reverse_proxy localhost:8080
}

Then reload caddy:

systemctl reload caddy

Start Packeton

cd /opt/packeton
docker compose up -d

Verify it all works

Visit https://packages.yourdomain.com and log in with the admin credentials you set.

Post-setup

Change the admin password

The ADMIN_PASSWORD env var only applies on first run. Change it via the console:

docker exec -it packeton bin/console packagist:user:manager admin --password=newpassword

Create additional admin users

docker exec -it packeton bin/console packagist:user:manager newusername --password=newpassword --admin --no-interaction

Configure GitLab OAuth

First, create a GitLab OAuth application at https://gitlab.com/-/profile/applications:

• Redirect URIs:

  https://packages.yourdomain.com/oauth2/gitlab/install
  https://packages.yourdomain.com/oauth2/gitlab/check
  

• Scopes: api, read_user, read_repository

Then create /opt/packeton/data/config.yaml:

packeton:
    integrations:
        gitlab:
            base_url: 'https://gitlab.com/'
            clone_preference: 'clone_https'
            gitlab:
                client_id: 'xxx'
                client_secret: 'xxx'

Restart Packeton to apply:

cd /opt/packeton
docker compose restart packeton

Then go to the Packeton integrations page in the UI and click Install Integration, then Connect to complete the OAuth flow.

Bonus Notes

Data

All Packeton data lives in /opt/packeton/data on the host, mapped to /data inside the container. Back this directory up — it contains the database, config, and any stored artifacts.

Ongoing maintenance

Watchtower checks for a new packeton/packeton:latest image daily and recreates the container automatically. No action needed.

Monitor the Packeton releases for any updates that require manual migration steps before they land.

Read time: 4 mins

Tags:

https://gitbutler.com/

Read time: 1 mins

https://danielabaron.me/blog/css-refactoring-with-an-ai-safety-net/

Read time: 1 mins

This is exactly when you need fresh eyes. At Liquid Light, that's what the BLAT test is for.

BLAT is a timeboxed, no-holds-barred review where everyone gets a go at one of our nearly finished websites. Each person gets an hour to click around, prod things, and use the site as a real person would. The goal is to find holes.

It might be a personal preference. It might be a niggle. It might be the tiniest of nitpicks. Doesn't matter. It goes on the list.

The project manager then reviews the list and decides what to action, postpone, or drop. It's not personal. It's priorities.

Things that tend to come up:

• Spacing between two particular elements
• Accessibility of a link in a specific context
• Unexpected (or missing) behaviour from an interaction
• Image sizes affecting performance
• Print styles nobody tested
• Odd flows between pages
• Future website improvements or additions

Anything goes, as long as the note includes:

• A link
• A description
• A screenshot where possible

Side note: No, BLAT doesn't actually stand for anything. We all know what it means (although out of all the recommendations from Claude my favourite was Brutally Look At Things )

Read time: 1 mins

Tags:

Eventually, my DDEV got confused and started producing 404s. With mixed version images & config, I wanted to remove everything and start again.

With the help of Claude, I created a bash script which will run through and delete every DDEV related configuration.

Completely remove DDEV

Steps

1. Copy the contents or download the zip
2. Make the file executeable - cd path/to/file and chmod +x ./remove-ddev.sh
3. Run the script ./remove-ddev.sh - there is --help and --dry-run flags available

Read time: 1 mins

Tags:

https://github.com/remorses/playwriter

Read time: 1 mins

Life

Plenty of goings-on with the Street family this year. Ruby, our youngest, started school which meant another shift in routines and schedules. Alfie moved up to Beavers and Ruby started Squirrels, which now means I'm the only one of our family to not be currently invested in a scouting section.

Alfie has become a classic "kid" and discovered Minecraft. He'd been talking about it at school and we finally gave in and bought a copy for the XBOX. I've also enjoyed playing it, trying to actually build things and thinking about layout (although it's still enjoyable to build a tower of TNT and blog it up).

There were some small home improvements - I redecorated the garden office and painted the "TV corner" of the lounge with matching bookcases. The biggest change was the demolition of the back garden patio and building of a deck - carried out by my dad and me.

To finish off the year, our car decided to give us a Christmas present of breaking. We couldn't get it booked in until the 5th Jan, however my mother-in-law leant us her car for the festive period which meant Christmas was saved.

Trip and Holidays

For our main holiday this year we took the kids to Disneyland Paris. It was a first for me - going on the channel tunnel and driving on foreign soil in my own car. Disneyland was hectic and expensive and fun and chaos. We went with my wife's family which did mean we had the opportunity to leave the kids with each other and head off to the big rides.

Little trips included taking Ruby to London for the first time, a boat trip out to the Rampion Wind Farm and a visit to Brooklands Museum in Weybridge.

We also spent a week in a static caravan in the New Forest - it was a classic "caravan park" style holiday, with on-site swimming, golf and evening entertainment. We sprinkled in some day trips to Paultons Park and a miniature steam railway. We also found a pub round the corner with an incredible outdoor play area for the kids (while Chilly and I kicked back with a book and a beer).

My attendance to gigs sky-rocketed this year as I got the taste for it last year. This year saw a few shows with the kids along with seeing OneRepublic (my first trip to the 02 since it was the millennium dome), Nizlopi (a birthday present), Self Esteem and it seems I can't go through a year without seeing Bastille. The last gig of the year was with my mum and family to see Stereophonics at the 02 again.

Stats Analysis

Visit the stats page.

Cycling was a big part this year - recording the highest ever number of miles done in a year since I started recording. A big part of this was the turbo trainer I purchased at the end of last year, with just 85 miles separating virtual and real-world bike rides (and I rode more virtual miles then I did on an eBike)!

I also hit a few big rides this year, doing the London to Brighton bike ride (for the third time), a 65 mile bike ride in August and 70 miles around the Isel of Wight in October. I was pretty happy that I was able to pull these out the bag without much concious training. It seems cycling to and from work combined with the turbo proved to be a pretty effective training plan. I'd like to hit 4000 miles again in 2026.

My Geocaching suffered this year - only finding 2 at the beginning of the year. I need to get some caching days booked in in 2026 to get those numbers back up. I feel like 75 Geocaches is a good target.

Everything else, such as blog posts, steps and music streams stayed steady.

Read time: 3 mins

Tags:

https://ohmyposh.dev/

Read time: 1 mins