Recent Posts

Prompted in part by the changes I made yesterday, I've made another small release of BlogMore today. The stuff to do with human.json made mention of having a /ai page, something I remember as being part of the slash pages moment. While I've never leaned into it myself, I do consider it a fun idea and, given the current experiment, I did think it made sense to have a /ai page for this blog, at least¹.

Yesterday's changes, to allow modifying the path used for pages, and also to apply the clean_urls setting to them too, meant it was easily doable now. But I also got to thinking that someone might not want the page to appear in the sidebar; perhaps they just want the page there but not obviously linked to.

So with today's release I've added an optional pages: configuration setting. If it's omitted, BlogMore works as it always did (listing every page in the sidebar). If it's included, only the pages in the given list appear in the sidebar.

Personally I think I'd prefer to have the /ai page visible in the sidebar, and that's what I've gone with. But if anyone wants the option of having better control over this, it's there now.

While I was tinkering on sidebar things I also added a setting for overriding the title of the links list. Again, I think Links works fine for my purposes, for this particular blog, but I can see the need to want to customise it.

It feels like this blog has turned into the BlogMore blog at the moment, and to be fair part of the idea of BlogMore was to encourage me to blog more again. So I guess it's worked?

Anyway, another wee update with a couple of additions. The first is a follow-up to some work I did a little earlier last week that meant that the user can configure how paths for posts are created. This takes the same idea and applies it to pages too, adding a page_path setting. Pages now also make use of the recently-added clean_urls setting so you can use "clean URLs" for pages too.

Another change I've added has been, in part, prompted by a thing I've seen going around the socials the past couple of days: human.json. I did initially think about adding some special support for it¹ -- allowing declaring the values in the BlogMore configuration file -- but then I decided it made more sense to just include the human.json file in the extras directory and allow for adding a header.

Now... adding custom headers can be done with BlogMore's templates, but that felt a bit heavyweight for just one simple header, so instead I've added a head configuration option that lets you inject some simple tags into every page's head.

This is good for fans of humans.txt too; something I sense could have been quickly and easily extended to serve the purposes of what human.json does, but I guess we have to reinvent wheels every so often, and using a machine-readable file format is so much more... human.

Somehow minor version numbers are tracking the day of the month at the moment, and that isn't on purpose, but here we are on March 14th with BlogMore v1.14.0¹.

This release has a couple of changes: one is directly practical and the other a little more experimental/hopeful.

For starters, I've added a minify_html option. Having added minification for CSS and JavaScript files, it made sense to finally do this for all the HTML that's output too. So, if minify_html is set to true in the configuration file, or --minify-html is passed on the command line, any generated HTML file will be squished down as much as possible to reduce its overall byte size.

Every little helps, right?

The second change comes from a request that I don't directly know how to handle, so this is an experiment with allowing for it. The request was for "themes". Now, from the start, I created BlogMore such that the templates can be overridden and that custom stylesheets can be used, but the idea of "themes" suggests something more formal. Allowing for this and planning for this isn't straightforward because, honestly, I'm no web developer and no designer.

So what I have done is try and ensure that the templates and stylesheet are as sensible as possible and then also expand the documentation to try and make it possible for someone to step in and write their own theme.

I've also tried to ensure that there are adequate instructions for agents in the codebase such that no breaking change will be made in the templates and styling, without this being obvious. The plan here is to keep the core of the theme support as stable as possible and to adequately alert people to any breaking change (and, ideally, to never make any breaking change).

On top of all of that, I've got Copilot to also make three example themes. None are that radical, and I might see if I can coax it into making one or two more that are a bit wilder, but they should at least be helpful for someone with skills who feels more adventurous than me (or they might at least work as examples for an agent so that more themes can be AI-generated).

I wasn't intending to make any changes to BlogMore today, but as luck would have it @andyc had a feature request which made sense and seemed easy enough to prompt for, so I did.

So the change is this: if you happen to configure BlogMore such that the post URLs end up being something that ends in index.html, if you turn on clean_urls, all emitted URLs will leave off the index.html. The result of this is that a URL that would look like:

https://blog.example.com/posts/my-first-post/index.html

can then always look like:

https://blog.example.com/posts/my-first-post/

In other words: it gives you a way to have clean URLs.

This is carried through all generated pages and the sitemap too.

It's not something I'd personally use for this blog (because it's been around long enough and has a specific URL layout that I want to keep working) but I can see it being useful for any future project, and of course I can see it being useful for anyone else wanting to use BlogMore.

Another wee change is to make sure that the rebuild-on-change feature of the local test server always loads any new values set in the configuration file. While it was reacting to some properties changing, it wasn't reacting to all; so I asked Copilot to check all the values and make sure all are handled.

Another day, another tweak to BlogMore. This bump adds a couple of features relating to headings. The main change being that I've added support for custom IDs for links. To borrow from the docs:

If you need a specific id — for example because the auto-generated one is too long, or because you want a stable id that won't change if you reword the heading — you can set it explicitly by appending {#your-id} to the end of the heading line:

### My Great Heading {#custom-id}

This produces:

<h3 id="custom-id">My Great Heading</h3>

The custom id overrides the auto-generated one. Headings without a {#…} suffix keep their auto-generated IDs as usual.

Headings, of course, have a default "slugged" ID if a custom one isn't provided.

The other main change is that it's now easier for a reader to discover a link to a heading should they want to link someone to a specific part of a post or page. Again, to borrow from the docs:

To make it easy for readers to share a link to a specific section, BlogMore renders a small ¶ symbol at the end of every heading. The symbol is invisible by default and appears when the reader moves the mouse over the heading. Clicking the symbol navigates the browser to that heading's URL fragment, where the address can be copied from the browser's location bar.

The anchor appears and disappears with a smooth fade and does not affect the layout of the page in any way.

Another small change I added was to the "Generated by BlogMore" text that appears at the bottom of every generated page. I always think it's nice if some tool lets you turn that sort of thing off, and I'd not paid attention to that yet. So as of v1.12.0 you can add this to the configuration file:

with_advert: false

and you then don't have to have that at the bottom of each page.

Credit BlogMore if you want, but you don't have to.

I was going to call this one "Yet more BlogMore" but I think, even after two posts with that naming scheme, the "...more BlogMore" thing has had its day. But here I am: another day, another wee change to the blogging engine I'm building as an experiment with developing using AI.

Just a couple of simple changes in this release. The first comes from the fact that I was updating my blog to include more of the "socials" icons (the ones you'll see towards the bottom of the sidebar if you're on a wide enough display, or in the collapsible header if not) and when I deployed some were missing. Which, after a moment of puzzling, made sense.

See: I made a change a while back such that I stopped using the full FontAwesome stylesheet, and instead only used a specially-built subset. This is handy in that it really reduces how much data goes into a page. But the downside, of course, is the browser will cache this file; so if you then add more "brands" to the list their icons will be missing until the cached version of the old generation of the CSS file goes stale.

So in this release I've added a generation-based cache buster; it's just the simple ?v=thing approach but it should work fine for what I need here.

The other change is I've added the generated FontAwesome CSS file to the list of files that get optionally minified at generation time. While it's not a massive change in terms of the total amount of data that gets pulled down, every little helps.

I feel like, at this point, I've managed to add everything I could possibly want from this little static site generator; yet somehow each day I have a new idea and off I go again.

It'll be finished soon. I'm sure.

While the additions have, for sure, slowed down, I'm still tinkering away with BlogMore. Recent changes stem from the fact that someone else has been mad enough to want to experiment with rebuilding their blog with it too, which, if I'm honest, is massively helpful with the ongoing GitHub Copilot experiment. Somehow it feels a little different, ganging up with the agent to implement changes for someone else's benefit.

Recent changes include:

• Tweaking the size and layout of the "social" icons that appear in the sidebar (this one was for my benefit)
• Making it possible to customise the title for the socials section in the sidebar (also for my benefit)
• Providing control over the path used for posts -- this one was a request that made a ton of sense, it's at this point it stops being a tool for me and starts being a more general tool

Next up is the first breaking change where I'm going to remove a feature. This came from my very initial experiment last month, where I was concentrating purely on building a tool for my blog and my blog alone. I'd made it such that the /attachments directory in the content directory had special status, and it would be copied over to the output directory in full. Oddly, however, this never made it into the documentation.

Meanwhile, the /extras directory also had special status with its content, full hierarchy included, being copied over but moved up one level in the output. So, for example, extras/humans.txt became /humans.txt in the resulting site, etc.

Presumably, at this point, you can see where this is going. Why the heck did I have a special attachments folder being copied over, when a folder of any name could live below extras and also get copied over?

So, now, my blog, which uses /attachments for all inline images and covers, has been updated so that the attachments live under extras and it all works as it did before; no special messing with a special folder name.

Given all this, the next release of BlogMore will remove treating /attachments as a special case, making it less hard-coded for my habits and more of a general tool that could be useful for others.

Mildly related to this: I did a lunchtime talk at work today, having turned Five days with Copilot into a 20-25 minute presentation. It was fun to do. I've not written or given a talk or presentation in a long time -- probably the last time was when I helped run Newton's Astronomical Society in the early 2000s -- so the preparation for this was a little daunting to start with.

While doing this, not wanting to break a long streak of never having used PowerPoint, I discovered and gave sli.dev a go. Writing a single Markdown file to power the talk was exactly my kind of approach. I don't have any experience with any other such tools, but if you're ever looking for something like this I recommend giving it a try.

I'm also open to suggestions of other options, given I might end up doing this some more.

Just recently I saw a post go past on Mastodon, complaining about the author's perception that there was a breakdown of trust in the FOSS world, in respect to the use of AI to work on FOSS projects, or at least the willingness to accept AI-assisted contributions. The post also highlighted the author's reliance on FOSS projects and how they're driven by ethical and financial motivations (some emphasis was placed on how they had no money to spend on these things so it wasn't even necessarily a choice to FOSS up their environment).

This was, of course, in response to the current fuss about how Vim is being developed these days.

I don't want to comment on the Vim stuff -- I've got no dog in that fight -- but something about the post I mention above got me thinking, and troubled me.

Back when I first ran into the concept of Free Software, before the concept of Open Source had ever been thought of, I can remember reading stuff opposed to the idea that mostly worked along the lines of "you get what you pay for" -- the implication being that Free Software would be bad software. I think it's fair to say that history has now shown that this isn't the case.

But... I think it's fair to say that you do get what you pay for, but in a different sense.

If your computing environment is fully reliant on the time, money and effort of others; reliant on people who are willing to give all of that without the realistic expectation of any contribution back from you; I feel it's safe to say that you are getting a bloody good deal. To then question the motivations and abilities of those people, because they are exploring and embracing other methods of working, is at best a bad-faith argument and at worst betrays a deep sense of entitlement.

What I also found wild was, the post went on to document the author's concerns that they now have to worry about the ability of FOSS project maintainers to detect bad contributions. This for me suggests a lack of understanding of how non-trivial FOSS projects have worked ever since it was a thing.

I mean, sure, there are some projects that are incredibly useful and which have a solo developer working away (sometimes because nobody else wants to contribute, but also sometimes because that solo developer doesn't play well with others -- you pick which scenario you think is more healthy), but for the most part the "important" projects have multitudes working on them, with contributions coming from many people of varying levels of ability. The point here being that, all along, you've been relying on the discernment and mentoring abilities of those maintainers.

To suggest they're suddenly unworthy of your trust because they might be "using the AIs" is... well, it feels driven by dogma and it reads like a disingenuous take.

Don't get me wrong though: you are right to be suspicious, you are right to want to question the trust you place in those who donate so much to you; almost always this is made explicit in the licence they extended to you in the first place. But to suggest that suddenly they're unworthy of your trust because they're donating so much value to you in a way you don't approve of...

...well, perhaps it's time for you to pay it back?

Yesterday, while looking at starting to post to my photoblog again, I noticed I'd missed a trick when I added the first and second sets of photos when I created seen-by.davep.dev: I'd left off any cover frontmatter from all of the posts!

While I doubt it's super important -- I can't imagine people will be sharing photos from the blog after all, especially not older ones -- it felt like I'd failed to use a useful feature that I'd made sure BlogMore had.

This was obviously easy to fix. I could just write a tool that would go through all of the Markdown files, find the image that is being displayed in the post, pull out the path to the file, and add a cover to the frontmatter. Not exactly the hardest thing to write, but kind of boring for a one-off fix.

So this felt like another good time to get Copilot to do the hard work. Liking this plan, I wrote an issue for the prompt and set it to work.

The result was unexpected, and in retrospect this is how I should have approached it in the first place; Copilot wrote the script, then ran it, and then submitted the PR including the script and all of the changes after running it! It's like it was super eager to do the fix so went ahead and just did it.

This, for me, highlights a trick/approach I'm still not fully mindful of: where I might once have written some throwaway code to do a job, run the code, and then made use of the result, when it comes to using an agent I always have the option of saying what I want done to the content of the repository and just let it do it.

When I'm next faced with a problem like this, I think this is the approach I'll take: rather than ask it to write the tool to do the work, I'll just say what the work is I want done and let it go about it. This feels like where an agent should shine and where it's really useful.

Meanwhile I can get on with the fun stuff.

Following on from the rescue of my photoblog, followed by the rescue of the original incarnation, I've been thinking that I should get into the habit of posting the odd image here and there again, when the desire takes me.

The problem is the workflow. The point and purpose of the last two incarnations was that I just had to take image, manipulate image, post image and then lots of other things would happen. As I've mentioned in the posts linked to here, and others here on this blog, it's much harder these days to achieve that seamless and frictionless workflow we used to enjoy during the rise and the peak of "Web 2.0".

So yesterday I decided on an approach that, while it's neither seamless nor frictionless (yet), it feels like it will work. So here's the plan:

• Take photo
• Manipulate photo¹
• In Apple Photos add a description to the image
• Export JPEG file to a Photoblog Inbox folder in iCloud Drive
• Later, when I'm at my desk, import the image into the photoblog
• Publish the updated blog

So, yeah, more manual steps are required, at least for the moment. I suspect though that if this works well I might be able to increase the automation involved and do it in such a way that I'm in control of the steps and services (or at least I'll be able to do it in a way that I can swap out a step should whatever service being be lost).

As an aside, for anyone who might have been following along with my experiments with GitHub Copilot: the import tool I link to above was written from a prompt. This, for me, feels like the ideal use for such a tool. Writing that script was going to be a chore, I wanted to get on with the bigger picture thing, so asking Copilot to write it while I attended to other things felt sensible and useful.

I'll likely tidy up the code soon, but for now what was produced works and it let me try all of this out in the time I had available on an otherwise busy Sunday afternoon.