Posts tagged with "web"

Late on last week I was doing a PR review at work and noticed that, for some odd reason, the author of the PR seemed to have absolutely nuked all of the indentation in the code. While not a problem given the nature of the files I was reviewing, I wasn't happy with their apparent disregard for style and good practice, and was about to leave a remark and a request for changes. But something seemed off. So I did a refresh of the page and... everything fell into place.

Weird.

Since then I've seen the issue on multiple machines. To be fair, each time it's been in Safari, and each time I've been busy with something else so haven't had the chance to really dive into it. But given it's suddenly cropped up, at the same time, on multiple machines, with nothing else changing, it feels like something on the GitHub side of things.

Perhaps I'm letting a bit of bias creep in here, but I feel like this sort of thing is happening more and more on GitHub. It's not that long back since social previews suddenly broke, for example. It's hard to shake the idea that changes are being made without regard to comprehensive testing, and likely without regard to how things connect.

Now, at this point, it would be easy to reach for the "well they're obviously using agents to do most of the work" argument -- and I'm sure plenty of people would -- but that doesn't quite fit with my experience. Having experimented with such tools for a good chunk of this year now, both for personal and, more recently, professional projects, I've generally found that such tooling easily helps with catching such issues.

Plenty of times now, when using something like Antigravity or Claude Code to work on some code, I've found that with reasonable care (you know: the sort of care you'd put into your work anyway) you can quickly and easily uncover connections and knock-on effects you might not have immediately noticed. Moreover, if LLMs are useful for anything when it comes to coding, it's for writing tests¹. With that in mind you should be able to reasonably expect the number of silly bugs to go down.

Unless, of course, there's no human in the loop anywhere, or the human in the loop lacks adequate training and experience, or, I guess, they simply lack the ability to give a shit.

I wonder when this particular issue will get fixed? I should probably go and see if it's reported in the GitHub forums anywhere. I know for sure that there's little point in actually reporting it as a bug; my experiences with that in the past haven't been great, and the GitHub subreddit has seen enough stories of people getting nowhere.

Five days after I first noticed it, the ability to upload a social preview for a repository has been fixed.

So now I can finally update the preview for Rogallo again.

From what I can see it took a couple or so threads in the community forums to get this issue noticed, and at least one person in those threads said how they'd initially raised a ticket to report it as a bug and had been brushed off and told to go to the community, as if it was something they were doing wrong rather than reporting a genuine issue.

This has been my experience in the past at least once. I forget the actual issue now, but I remember stumbling into a problem, being a good user and reporting the bug, along with details on how to reproduce, etc., and having the ticket closed and being brushed off with some vague and unhelpful reply. My recollection is that I then found a thread or two where others were talking about the problem. Eventually it was acknowledged and fixed.

It's hard not to feel like such an approach is a deliberate policy. It feels like their front-line support is now a shield that deflects problems to a place where community triage takes place.

Earlier today, now that Rogallo has matured a fair bit, I thought I'd update the banner image and, in doing so, refresh the "social preview" for the repository. This is easy enough, and something I've done plenty of times with plenty of projects. You just go into the general settings and upload a new image.

So, I faffed in Pixelmator Pro for a short while, got the new banner going, and then uploaded it. Weirdly, it didn't preview. I was just left with a blank rectangle.

I tried a couple more times... nothing. I then tested the repository itself with an online "social card" checking tool and, unsurprisingly, an image was set but it was a broken image.

Initially, I was entertaining the idea that I'd somehow done something silly, but really it's something hard to get wrong. A little bit of searching shows that it's not just me, with not one but two reports showing up.

It's things like this that bother me most when using GitHub (or any other large service). Sure, the big outages are bad, but with them you know they're being actively worked on, they're something that's going to be getting constant attention until they're resolved. Moreover, those sorts of issues generally suggest a scale problem¹. These little bugs, though, suggest a lack of attention to detail, a lack of proper testing, a lack of care about the product as a whole.

It's not even the first time in the last couple of weeks that I've run into something like this. The other day I wanted to convert an issue into a discussion -- a feature I've used so many times before. This time... nope. Just didn't work. I forget exactly at what point it failed; I think the dialog popped up and then disappeared. Whatever the now-forgotten detail of the failure, the issue was that a long-standing, reliable feature just stopped working.

Again: big outages can be annoying, but in those cases I tend to just go off and do something else, either at my keyboard or, shockingly, away from it. By the time I get back into the office it'll be sorted. These little things... who knows when they'll be fixed?

Perhaps this bit-rot is a result of the panicked fixes to those big-bang problems?

If you've ever visited my main web site you might have stumbled on Grid Bike. This was a game that teenage me wrote on my VIC-20. I was bold enough to submit it to Personal Computer News, and ended up having it published in the December 21st 1983 edition.

I still have my copy of that magazine. I've also kept a copy of scans of that page on most versions of my website. What I haven't done, since the early 1980s, is play the game.

I suppose, at some point, I could have grabbed a VIC-20 emulator and typed it in. Or, if I didn't want to type it in (and I don't), I suppose I could have tried to OCR it and get it into an emulator¹. But of course I never did.

Then, a week or so back, I got to thinking: if I threw the two images at an agent, asked it to OCR the code, and then build me a web-based version of the game... could it manage it?

So, on a whim, yesterday evening, sat on a bed in a hotel in Whitby, I threw a prompt at Antigravity:

In this directory you will find grid-bike-page-1.jpg and grid-bike-page-2.jpg -- these are two scans from a magazine from the early 1980s, that contain a game I wrote for the VIC-20. I want you to OCR the images to pull out the code, understand the code, and then create a faithful recreation of the game as a standalone webpage, with the game written in JavaScript, so that I can play the game once again.

Initially it wanted to install PIL globally and kick off the work that way; I wasn't allowing that so I had to tell it to use uv instead and make a virtual environment in which to work. After that it didn't take too long to OCR the code, comprehend it, and write the website. The first version ended up looking far better than I was expecting.

What followed was about an hour of refinement as I got it to fix some visual problems (the characters it used for the lines didn't quite line up on the corners, for example), some audio problems (trying to get it to recreate the sound of the bike I had going on the VIC proved tricky, and it's still not how I remember it), and also a handful of playability issues when it came to mobile devices.

Eventually though it got to a point where, without question, I had a version of the original game, as I played it on my VIC, running in my browser -- both on desktop and on my iPhone.

I suspect it still needs some more refinement. The placement and layout of the opening text isn't quite right, I don't think, and the audio could still be better. Also, I'm finding the sound toggle button doesn't quite work as I think it should (depending on when you turn it off, it seems like it might or might not actually turn off the sound). I'm also not convinced the "Keyboard Controls" panel is as readable as it could be.

Without question though, it's playable and it's my original game, brought back off the page.

If you fancy having a muck about yourself, it's at grid-bike.davep.dev.

I've just released BlogMore v2.28.0. This release has some small improvements to the JSON-LD structured data that was added in the last release, and also adds support for actually showing author names on posts.

On the latter point first: I only ever really created BlogMore for myself, thinking that perhaps some other folk might use it at some point. All along, though, I had it in mind that it would only ever be used to create a site where there was a single author. Despite this, though, I'd added support for setting the author per-post, and this was reflected in the RSS and Atom feeds.

But I'd never added support for showing the author in posts.

So this release adds that feature. I've tried to add full control, with settings that let you turn on/off showing the author blog-wide, as well as providing control per-post. Also, as well as setting the default author for a blog, and being able to set the author for a specific post, you can do the same for an author's URL (setting it blog-wide and per post).

Obviously, when the author is shown, if a URL can be worked out (the one local to the post is chosen first, then the blog-wide default if one isn't set for the post), the author's name links to their URL.

The JSON-LD changes are a couple of small improvements to the content. The author data adds a url property (following the same rules mentioned above) and the image property for a post will fall back to the site logo (if one is set) when there is no cover.

Much like the last two releases of BlogMore, this is another that has ended up being on the theme of improving or adorning the generated HTML.

One change in the last release resulted in another HTML validator warning, and so that's cleaned up here (the removal of the h2 elements from the sidebar meant it no longer made sense for it to be a section, so I've turned it into a div).

On top of that, I've also decided to dip my toe into adding more "microformat" type things to the generated code. This release adds things like JSON-LD structured data and Microformats2 semantic markup, where appropriate. I've also updated all of the "socials" links that appear in the sidebar to ensure they're marked up as rel="me".

Given that this is a bit of an experiment, expect to see some tweaks and changes as I roll this out on this blog and then check and test the result. This is a useful learning exercise for me.

The previous release of BlogMore had some work that improved the HTML, ensuring that the HTML validator was happy with the generated code. Yesterday evening I ran it over more of the pages, and found a couple more things that made sense to address.

So v2.26.0 takes this a little further and tries to clean more things up. Changes include:

• The comment email invitation box is now created with a div rather than a section, resolving a validation error about there being no h2 or similar inside the section (because we don't need any kind of heading in there).
• Cleaned up an error relating to the misuse of an aria-label in the graph page.
• Cleaned up an error relating to the misuse of an aria-label in the stats page.
• Removed the h2 elements from the sidebar, making them into divs with the same style. This leaves headings as something that will only appear in the main body of any page or post.
• Added some heading-demoting to the rendering of posts so that the heading structure of any given post is retained when it's part of any of the archive-style pages (date archives, category archives, tag archives, etc).

While not all of the above were being reported as validation errors, all of them should result in HTML that better fits what I'd want in the first place.

The job is finally done. After considering moving all the images in the blog over to WebP, and then finally getting the migration under way, I'm all done.

As I mentioned before: I've done this by hand, one post at a time, also adding missing covers as I go. The process went faster than I anticipated and I found that adding linting support to BlogMore really helped with this process. Each time I made a batch of changes I could run the linter to make sure I'd not broken any image links.

As for the result: I've brought the total size of images on the blog down from around 56MB to about 32MB, give or take (keep in mind the latter figure also includes all the WebP images I've added while blogging since I started this process). While I don't really have to worry so much about the storage costs of these images (I'm using GitHub Pages after all), overall, over time, there should be savings in the time it takes for readers to load any given page.

The new linting tool I've added to BlogMore has paid off already. While it is the case that it helped me find a couple of broken links and one or two other things to tidy, as I was working on the feature; by the time I released it, my blog was lint-free.

But last night I did a little more work on the slow migration of images over to WebP. As I've mentioned before: this is a process I'm doing by hand, one post at a time, for a couple of different reasons. The thing is, I'm in a part of my blog now where I was often posting about updates to projects I was working on (Tinboard being a good example), and the cover for all of the posts would be the same. To save having multiple copies of the cover image, all subsequent posts would point back to the first cover image¹.

So what was happening was, I'd have a cover image that got transitioned from PNG to WebP, and then the covers of a number of posts, later in time, would be broken. While I would get to them eventually, if I'd called it a day there and rebuilt my blog, those would have been published broken.

Using blogmore lint while making those changes yesterday evening alerted me to this right away.

I've finally made a proper start on the planned migration to webp for images. I did consider writing a tool that would go through and migrate the files, and update the Markdown, all in one go, but something about that makes me kind of nervous. While it wouldn't be a destructive approach (the whole blog is under version control after all), I just have this niggling feeling that I'd miss something and it would sit broken, unnoticed, for ages.

So instead I've decided to take a one-post-at-a-time approach, making the migration by hand. As well as having the benefit of letting me go slowly and check my work as I go, I can also do some tidying up of old posts. So while I do this I'm also going to tidy up obviously broken links when I notice them, and also remove embedded tweets (swapping to the simple blockquote version).

Another thing I'm doing is adding cover images where possible. I'd been running this blog for a long time before I started to use cover (it might be that I didn't start until I moved to Pelican). Since then I've tried to use it any time there's an appropriate image in a post. More recently, I added cover images to the graph view so they're even more useful now. Back-adding a cover to older posts will make them more appealing to discover in the graph because those older notes will acquire attention-grabbing thumbnails too.

One thing I wanted to do was have an easy way to keep track of where I'm up to in the migration. It's going to be a steady process that's going to take a few days, doing a few posts at a time. So to aid this I've added this to the Makefile of the blog:

cd content/extras/attachments
find -E ./ -iregex '.*\.(png|jpg|jpeg)$' | cut -d'/' -f2,3,4 | sort -u

With this I get a handy list of dates of posts that still have unconverted PNG or JPEG files.

Of course, for a wee while, this will not get to an empty list because I want to make sure some of the more recent posts still have their older images available as they might be in feeds out there. More recently I've only been using webp for images, so once the webp-using posts fill the main RSS and Atom feeds I can clean out the last of the bulkier images.