I recently picked up the widely hyped Xteink X4 e-reader, in one of those moments where I can happily justify purchasing more tech in pursuit of improving my life.
Of course I immediately installed the open-source Crosspoint Reader firmware on the device, which led to a novel realisation. (heh)
It's hard to avoid the refrain that AI is out for our jobs. That all developers will be replaced by LLMs and we'll all have to brush up on our prompt engineering or just become gardeners (tempting, to be honest...).
But developers don't just write code, we also know how everything actually works. Which systems are held together with wishes and crossed fingers. We're deeply embedded in how companies operate, and more often than not, we're what's keeping the lights on.
The king of LLM blogging, Simon Willison, has a great overview on using LLMs to write code.
Using LLMs to write code is difficult and unintuitive. It takes significant effort to figure out the sharp and soft edges of using them in this way, and there’s precious little guidance to help people figure out how best to apply them.
Even if you’re not sold on how LLMs can boost your development, I’d highly recommend that learning to manipulate them to your benefit is a skill worth learning.
We are being boiled like frogs. It happened gradually, one algorithmic tweak at a time. What started as a way to connect with friends has become a system that gives the corporations that run social media control over what we consume and the ability to subtly shape how we think.
Frenck (lead engineer of Home Assistant) breaks down the state of his smart home. While you might assume the lead engineer of a home automation platform has everything figured out, it’s fun to hear that’s far from the truth.
…my dashboards are so bad that if I turn on the “Coffee machine” switch, it actually powers on my 3D Printer. 🤦♂️
I keep seeing examples of this - lead developers and experts in their field often don’t have the perfect environment - they are focused on the things they want to do and often the pursuit of the ideal environment falls by the wayside.
This is something I often need to remind myself about when I go on a yak shaving adventure tweaking my editor setup or finding the perfect tool for a job.
I love reading technical deep-dives in to system design and scaling. This post from Jaz (infrastructure at Bluesky) is a great read on how they balanced user needs with performance by finding where they could be ‘imperfect’.
By specifying the limits of reasonable user behavior and embracing imperfection for users who go beyond it, we can continue to provide service that meets the expectations of users without sacrificing scalability of the system.
There’s always sacrifices to be made in system design - I like the idea of defining a ‘reasonable limit’ for any one user and building optimisations around that limit.
If you have more than 1 server and a need to deploy multiple applications 'somewhere' on that cluster without having to micromanage - don't reinvent the wheel, just use Kubernetes. It's the industry standard for a reason, and you're not going to have a hard time finding help when you need it.
However, it's easy to forget that there's a class of service/business where this doesn't make sense. Many small businesses (if they're not using a PaaS like Fly), don't have the resources to run a Kubernetes cluster and 95% of the time, just need an app to run on a single VPS.
Andy Hawthorne writes a lovely summary of why it’s worth blogging:
When you write, you think better. When you think better, you create better.
I’ve just added Simon Willison’s link blog pattern to this site, hoping it will encourage me to write more, even if it’s just fleeting thoughts on a link like this one.
I've been playing with Fly.io a lot recently (see my series on deploying Wagtail to Fly.io).
One of the neat things that has come out of Fly is a renewed interest across the dev world in SQLite - an embedded database that doesn't need any special servers or delicate configuration.
Some part of this interest comes from the thought that if you had an SQLite database that sat right next to your application, in the same VM, with no network latency, that's probably going to be pretty quick and pretty easy to deploy.
I've been playing with Fly.io quite a bit recently.
Yes I'm drawn to the exciting tech, the fascinating blog posts, the attractive pricing and generous free tier (for now...), but more importantly, Fly are one of the few new breed 'PaaS' tools that realise what Heroku got right with its excellent developer experience, and are on a fast-track to replicating and eventually exceeding what Heroku offers.
While Fly is quickly establishing itself as my go-to hosting platform for personal/hobby projects (even before the "sunsetting" of Heroku's free tier), Wagtail has been my go-to platform for almost all the sites I build for quite a while.
To kick everything off, you'll need a Wagtail site configured in a local development environment. The Wagtail Getting Started guide is a great place to start.
Alternatively, grab a checkout of bakerydemo, or find your own existing project.
We'll start by getting your application in to a state where it is easily configurable with environment variables.
For Fly to know how to run our application, we need to package it up in a way that it understands. We need to tell it things like:
Fly currently supports 3 ways of doing this; Dockerfiles, Buildpacks and Nixpacks. The latter two are a great way to get started if you're not familiar with Docker - they provide a pre-built way for the platform to build and run your application without the developer having to do much extra work.
Our Wagtail app needs to serve two different 'categories' of files:
We'll use a couple of very useful Django packages to handle these.
With all that prep work done we can finally do what we said we'd do at the start - deploy a site to Fly.io.
To start, we'll need to install the Fly command line tool, flyctl. Follow steps 1-3 over on the Fly.io docs and then come back. I'll wait.
(alternate title: Overcomplicating Things That Aren't That Important)
Being annoyed with Zoom's lack of smart-background blurring on Linux led me down a rabbit-hole out of which I have only just emerged, covered in who-knows-what and left with a sense that I should probably have left the poor rabbits alone.
Do you want to make this questionably improved transformation to your cheap webcam:
I use the wonderful Home Assistant on our home network for a variety of weird and wonderful automations and as a nice dashboard to all the devices in our home.
Nothing on my home network can be reached from the outside world without a VPN. Unfortunately, that presents a few issues with Home Assistant:
So far, I've been living with these problems. Exposing my entire HA instance to the world isn't something I'm comfortable with.
It is 2021, a blog can't exist without an "I trained an AI" post like these trailblazers:
So here we are.
Email is annoying. Doubly so when you're a contractor and have a separate inbox for every client. Having to keep 4 Gmail tabs open to keep track of incoming requests feels like a waste of brain power and space.
If there's something you'd like me to write about, feel free to reach out!
Contact Me