notes.husk.org

From the V&A's upcoming exhibition on Lost Music Venues,

A photograph by René Burri of a replica of the Fat Man atomic bomb at Alamogordo White Sands missile range, New Mexico. 1992.

Coyote diets in different parts of San Francisco, all of which are heavily anthropogenic - meaning, they're eating human leftovers, basically.

Or: Playing Nicely With Others

A couple of weeks ago, a new project on GitHub was mentioned on the Infrastructure Club Slack: WhatCable, with the word "YES" being followed by a bunch of discussion. It solves a problem that many of us have: knowing what a USB C cable can do.

USB C is the ubiquitous connector, which is great, but the actual cables can support anything from USB 2 speeds (480 megabits per second) up to Thunderbolt 5 (one direction can go up to 120 gigabits per second), and power from just 5 watts up to 240. In other words, one cable will charge the beefiest gaming laptop and copy data to your external SSD in seconds; another will not stop the battery from draining and take hours to back up.

WhatCable lives in the menu bar (or Dock, as a standard app), and tells you what cables and devices are plugged into your computer; how fast they are; and how much charge is passing through them. It's focused, and useful.

I had a quick look at the project, and realised that pressing ⌘, opened a blank window, rather than the settings pane (which could be accessed from an icon). A quick look at the list of issues showed a few more Mac native expectations were missing, so I thought I'd ask Gemini to look. (Why not Claude? I'm cheap, basically. Gemini isn't as good, but it's free, and the usage limit is generous enough.)

One huge help is that Swift apps have a command line only build process. This was news to me, but it's great - I've never got to grips with XCode (or, to be honest, any other IDE) - so it opens up the world of Swift (and hence macOS, iOS, and so on) development. Being able to kick off tests, and both debug and production builds, from Terminal - or coding agents - is great.

That meant I could, with help, prepare branches for the command key shortcut, and another for various menu and shortcut changes; build and test locally; and then push and create pull requests with some confidence, despite my lack of experience.

I also made changes to read the data for M1 and M2 Macs, since that's what I had. Returning a day later, there was an alternative implementation in another PR; a quick check and Gemini comparison of the code made it clear that the other change worked, and was better architected, so I made sure to close my PR and say the other would be a better candidate.

In the end, my preferences and "Macishness" changes did get merged, although from edited code rather than as simple merges. (In retrospect, I should have asked the coding assistant for reviews, to improve the PRs. Something to remember for next time.)

One of the main features I wanted for the ffffound archive serving site was automated tagging, because it was missing entirely on that site (as it is on Pinterest and others that followed it). That's great for simplicity in saving, but it's not so good for discovering what's in there.

Tumblr does have tagging, so it's tempting to think this isn't as important for the likes archive. It's true that tags are possible, but not everyone uses them, and what the reblogger (or creator) tags something could be very different from the tags I'd choose. So I set out to apply a similar process.

This time, I decided to use a local model instead of Gemini. It was almost embarrassingly easy; install Ollama, download gemma:26b, and point at it via a REST API. The only trick was to make it callable from other machines required starting with a OLLAMA_HOST environment variable to get it to listen on 0.0.0.0 rather than localhost.

One drawback of this is that it's slow - it's taking up to a minute per post. On the other hand, it's free. Since the images aren't going anywhere, I'm happy to let this process be a trickle. Initially I concentrated on images without any post tags, and I've left the prompt fairly open, but I think I need to revisit that - there are too many overlapping tags (Gemma is much happier to use the word "monochrome" in preference to "black and white", which is the reverse of the standard in post tags) - but that can come as a later refinement, along with extending tags where they don't exist.

Otherwise, I've made some progress with deploying the Tumblr version of the site, adding faceting for the various Tumblr-specific user info (like creators, curators, and sources), as well as some visual tweaks.

Maybe this time next week I'll have a repo I can open, along with a URL you can visit. For now, a screenshot.

A couple of years ago, I wrote some code to display my archive of images from ffffound, an image bookmarking site, with the ability to filter by date and generated tags. That's not the only place where I have a huge archive of images, though - among them, there's also Tumblr.

Of course, Tumblr has fairly decent archives and tag navigation pages, so it's not a problem for my main blog. What it is lacking, however, is any sort of similar interface for likes - the FAQ page says so explicitly.

Likes can be viewed in a list or grid format on the web, but cannot be sorted or filtered

Luckily, there is an API, and it does expose likes. I use a Python package called tumblr-backup to back up this site, and it has an option to copy likes the same way. So, instead of only being able to look at likes on the Tumblr dashboard, twenty at a time, I now have a directory full of about sixteen thousand posts - in JSON - and their associated media.

This is, of course, roughly where I started with my archive from ffffound. Around the same time that I wrote up image tagging, I was already extending the web app to serve Tumblr images. As personal projects often do, it sat for months with very occasional pushes, until the last couple of weeks have seen some solid work to extend it.

Although the underlying problem is similar - I want to be able to navigate by date and tags - there are also lot of differences. Obviously, Tumblr likes aren't all images; there are multiple post types, so I opted to ignore the others. That said, the New Post Format sends everything as a text post, and the client has to determine from the content whether it's really an image. (At the moment, I'm cheating a little and looking for figure tags.)

Another issue is that Tumblr supports multiple images; text (and tags) on posts; and, with NPF, those can be interleaved. Initially, I just pulled out the first image for both the grid view and the details, which gave me a good idea of what I was looking at, but the recent coding burst added much better details page display. If a post has multiple images in a block, they're displayed as a JS powered slideshow. For legacy posts, they're followed by a caption; for NPF, the entire post body (which may include further image blocks) is shown.

The concept of reblogging means that Tumblr posts also have more, and richer, metadata than ffffound did - and certainly much more than my scrape managed. That includes the user whose post I liked; the user they reblogged; the user who posted the root post of the reblog chain; and the source site from which the post was saved. Although I already had "site" support as a filter for ffffound, this gave me up to four facets to filter on.

All in all, I feel like I've got a nice little app here. I can view likes back to December 2011. (I'm pretty sure it was a feature before that, but maybe the API can't surface them?) I can see who I've liked most frequently, and the ultimate source of those posts. I can see all the Flickr images that I ended up finding on Tumblr instead. I'm sure there's much more in those 10,000 odd image posts to dig up - and probably find I've found over and over again.