Done! The backdrops for my Godot game have been made. Finished the desert one last week, and the coast one this evening. I also redid the mountain one, which is a little less interesting than the one I had, but it better matches the others artistically. Now time for the meta elements. 😓
Compared profile websites at work today. I really need to get mine cleaned up. I still have a link to GitHub, despite not using that account for much nowadays.
Trying to develop the habit of using the Micro.blog app for MacOS, so the backup feature will run. I expect the backups of this blog to be large. But 2.59 GB compressed? Wasn’t expecting it to be that large.
How does anyone find anything on the iOS App Store? Made several fruitless attempts at finding Inkwell, and ended up just using the link in the help guide. It’s there if you search for “Ink•well”. Just scroll past the unusually large number of AI tattoo generator apps, which is a thing apparently.
Tried launching one of my apps on MacOS Tahoe, just to see if my icon would get put into squircle jail. Good news: my icon’s a free citizen (it’s the orange one).
You know what this means: I can never, ever, ever touch that Affinity Designer file ever again, lest I break something.
The on-again, off-again Godot project is still going. Most of the levels are done. Now it’s time to finished the backdrops and SFX, add the meta-elements (which I’m not looking forward to), and just spit and polish. Trying Affinity Designer for the backdrops, which feels more right for me.
Some minor teething issues with my new headphones. While trying to turn off noise cancelling I pushed a button which paired it with someone’s device, and started hearing their music. Had to resort to getting the app, which doesn’t thrill me, but it’s better than randomly pressing buttons.
Talked to the agents yesterday and it’s come back with this Android app. Primed the pump, as it were, by bookmarking a few posts in Quick Reads for the commute home. We’ll see if I’ll read them.
A personal playground with image generation models (not related to Google’s Imagen model). Continue
reading →
I think I’m coming round to liking passkeys, but they’ve still got quite a way to go, particularly in their UX. Tried enrolling a passkey for something in Vivaldi for Android. The presented modal was a little unclear as to what device I was actually enrolling. There wasn’t a clear “Passkey” option. Instead, in a menu of four items, I saw NFC card, or USB dongle as the first two. “This device” was the last one.
I tapped it and went through the prompts. It seemed like it produced a passkey, but when I tried to login, it wouldn’t present it as a login option. It offered something like “Use other device” or something, but nothing to suggest that it had a passkey on file.
I did eventually enroll my phone the desktop browser. The QR code exchange worked surprisingly well, but again, it was unclear which option I actually wanted. I think the choice was “Use other device.” Use? What do you mean by “use?” Either “Enroll other device” or “Setup other device” would’ve be clearer.
This could just be a Vivaldi/Chrome issue, but really, it would be nice for browser to refine this a little. The technical aspects of passkeys are amazing. It’s the UX that’s holding it back.
A few updates of some other projects I worked on recently.
Webtools saw some love as I needed some tooling made to make the icon easy to include in the Well Read Flutter project itself. Android expects the logo of a specific size, so I “commissioned” an Android Icon Resizer, which will take one or more PNG files, resize them to what Android expects, and prepare them in a ZIP that could be extracted at the route of the res/mipmap directory. It will also produce a small preview of the icon, rendering it in a circle so you can see how it looks on the device. It’s background savvy, layering the icon over the PNG with “background” in the filename.
My current craving of vibe-coding various tools I need to do my job continues, with an attempt to build a REST/gRPC test client.
This is motivated by my distaste with all the other clients I’ve tried. There’ve been a few, and I’ve been unhappy with each one. For one thing, they seem more heavyweight than my needs. I don’t know if this is just how they’re implemented, or it’s because the realm of HTTP request testing is complicated (It’s probably a bit of both).
Some more work on Weiro. Much of it is pretty mundane, mainly to get it to feature parity with other CMS’s out there. Yes, I know the existence of those other CMS’s make the entire project pointless. Doubly so when you consider that much of what I’m going to talk about was largely done by coding agents. It made me wonder whether it was worth writing this update at all. Well, it’s drafted up already so I may as well finish it off. At least one thing will get finished.
Okay, enough wallowing in my self-doubt. What was added? Well, categories are now a thing. These can be defined in a new categories section and consist of a label, a slug, and a description. Going to /categories/<slug> will list all the posts with that category. Posts can be in zero or more categories, which can be selected from the edit post screen. Pretty simple stuff.
The Categories section, where the user can manage categories.Editing a category.Selecting categories from within the edit post screen.The categories page as it appears on the published site.The single category page.
Another small thing added was pages. This allows the user to define “slash” pages, with the option of appearing in the nav bar, and can also be used to replace the home page, by setting the slug to / (the posts are still available at /posts). I do need to spend some more time figuring out how to organise the nav bar as I would also like to include things like redirects. I thinking of making that an extension of the pages model, but I’m not sure.
List of pages of a site.Editing a page. There’s only a single page type at the moment.
Those two features were mainly done with the help of Claude Code, but I did build some stuff manually. The largest addition was the ability to do some edits on uploaded images. I’ve never been a fan of how Apple produces the shadows around windows: the margins are just too large. So I added a way to do this within Weiro itself.
The edit upload feature.
It’s pretty simple. Just imagine the filter section from any image editor, then remove all the other features of that editor. Yeah, it’s that simple. There’s no cropping, rotating, or anything else of that nature: just a bunch of “processors” that you can add to the image, with the sole one being a drop shadow.
This is actually done server side using a simple file-based approach. When opening an image upload to edit, you spawn a session. Each session has a JSON file maintaining the processors, plus a series of cached image files of all the intermediate steps along the processing chain. When a new processor is added, a hash is computed with the processor’s properties, and if they change, the cached image will be regenerated. The processor includes the hash of the previous step too, so that if processors further up the chain are modified or remove, they will force a recompute of subsequent images. The user is then served the last image in the chain.
This differs from the image processor in Blogging Tools, which performed the transformations within the browser itself. The motivation there was to avoid the need of a slow upload of the image, but it came with the performance cost associated with doing the processing within the browser itself. WASM might be fast, but it’s not that fast[^fast]. Since the upload in Weiro is already uploaded, I figured it would be quicker to just do the image processing server side. My hope is that the computing power the server has access to would offset the time it takes to download the image. So far this seems to be the case.
Finally, I did some minor work around the UI, adding a site chooser and a much needed way to open the published site from the admin section.
So this project is still coming along, surprisingly. It’s probably the furthest I’ve got in a blogging CMS that I actually want to use. I do have a large list of things I want to add to it, and I certainly need to do something with the design of the actual site. It’s all a question of whether I’m interested in spending time on it.
[^fast]: Although to be fair, I think the slow down comes from encoding the processed image as a data URI and setting it as the source of an img tag.
It’s been a week since I learnt about Inkwell’s API and got an agent to start work on an RSS reader. Since then, Well Read has been in a state of flux, as I ask for agents to make changes to the interaction and layout. I think I’ve got it in a pretty good state now, certainly in a state that works well for me.
The earliest screenshots of Well Read, taken on 11 March 2026
The Today and Recent tabs still retain their original behaviour, although the idea of using 6:00 pm of the previous evening as the cutoff for “todays’ posts” was a good one. Being where I’m located in the world, many people I follow publish posts while I’m asleep. I recently added a tab for bookmarks which uses Micro.blog’s bookmarking feature. Any post can be added as a bookmark, and since there’s no real way to get to a post once it drops out of the Recent tab (well, apart from opening it up in Inkwell proper), I have in mind this feature to act as a place to stash posts for later. So I tried making bookmarks as easy to add as possible. Sliding aside the item in the feed list will reveal a bookmark action, as will the overflow menu in the feed viewer.
On my commute. I wanted “Mark all as Read” added to Well Read. Cracked open the coding agent to make the change, push it to Forgejo to build the release, which I side loaded onto my phone. By the time I arrived at my station, it was there. Pretty nice!
When Manton mentioned that Inkwell has an API, I… um… may have vibe-coded an Android client.
It’s called “Well Read”, which is not a great name but better than “Inkwell Client” which was the working title. Much like Inkwell, it follows the river approach to RSS. There’s a Today tab and Recent tab, each showing a portion of the entries in reverse chronological order. Today shows all the posts from today, plus the last 6 hours of yesterday. The motivation here is that this will be the tab you’ll be spending your time, with posts aging out to recent over time. There’s no Fading tab: all posts older than about half a week fall out of the app. And I’m not sure if I’m going to add one. There’s only a few feeds that I want to catch up on if I miss their post, and since I’m using NetNewsWire and Inkwell, I’m pretty sure I’ll catch them later.
A small update on Weiro. I’ve been working on it over the past week, trying to get it in a state that is pleasant to use. I’m been trying to get something halfway usable before doubt scuppers my motivation and this project appears on the growing list of aborted attempts at making a CMS. There’ve been one or two close calls, but it hasn’t caused me to stop yet.
A large part of that was a feature I knew I wanted but was daunting to implement: uploads. The thought of writing the logic to manage large files, make sure EXIF data is stripped, and serve and manage them always seems like a pain. It’s the reason why I’ve abandoned CMS projects in the past. And I want something that support uploads: I’ve tried CMSes that didn’t have them and I never stayed long.
One of the fun aspects of these new code agents is seeing what they’re capable of producing just form the prompt, so called “vibe-coding.” There are some that are definitely all in on the concept: I’m thinking of Steve Yeggie and his Gas Town work. As for myself, I still prefer to be a bit more hands on. But it’s still amusing to see what these agents are capable of just from the prompt.
Dealing with PostgreSQL Docker complaining about “No space left on device” Continue
reading →
Ooh, this is a nice new feature of Pocket Casts: the web player now includes chapter markers in the scrubber. You can mouse over them to get the chapter name, and click them to jump to the chapter.
How is it that people making screenshot mark-up apps still don’t understand that the blend mode for highlights should be multiply, not mix with alpha. A real highlighter would keep the text black, and won’t produce obvious overcoating. This just looks like I’m smearing yellow paint everywhere.
In the spirit of maintaining a document of what I’ve been working on, and being somewhat inspired by Matt Birchler’s posts about his micro apps, I’d thought I’d document on some of the small apps I’ve worked on recently.
The fact of the matter is that I’ve been building quite a few of these apps over the course of the summer, primarily in response to a specific need I have at the time. I haven’t written about them before, mainly because there didn’t feel like there was much to say. Some were vibe coded, and saying that I “made” them didn’t feel correct. Others were made by hand, but they were super simple and there was no real challenge in making them at all. In either case, being able to say “I made it” is difficult as the amount of effort spent in making it is quite low, and that doesn’t make for interesting blog posts. Would a post saying that “I went to work today” be worth reading if that’s what I do every weekday?
More work on assets for my niece’s game. This time I tried something organic: a tree. Not the most difficult organic thing, I agree. Need to build up to the hard things.
