+++*

Symbolic Forest

A homage to loading screens.

Blog : Post Category : Meta : Page 1

Another anniversary

A more recent one this time

A few weeks ago, I noted it was sixteen years since I first started writing this blog. Well, today, it’s a whole year since I relaunched it, as something of a lockdown exercise. It had taken most of my spare time in the summer, to go through all of the old posts, edit them, redesign the sight, and get the whole production pipeline up and running.

Since then there have been a hundred and forty-two posts, including this one; about mountains, beaches, trains, castles, cemeteries, trains, Lego, trains, computing, and trains. Have many people read them? No, probably not. That’s not really the point, though: not whether people read them, but whether I enjoy writing them. I have. So doing it has been worth it.

Despite it being the pandemic years, still, a lot has happened and a lot has changed over the past year. There will, I am sure, be more changes over the next year too. We won’t know, until they happen.

Taken by the flood

An impressive onrush of current

Last January, I wrote about how I keep track of ideas for topics to write about. I said, when I have an idea, I create a “ticket” a bit like a “bug ticket” in a software development process, to keep track of it. What I didn’t say, though, is something that applies to writing ideas just as much as to bugs: it’s important to be descriptive. Things you think, now, are always going to be seared in your mind, will be over and gone in a few hours. Unfortunately, when I create a “writing ticket”, I will often only write down a few words and rely on my memory to know what the post was actually going to be about. When I come back to it later: baffled.

Take, for example, an idea I also wrote down back in January, a few weeks before writing that post. “Post about the fast-flowing waters of Stockholm.” Post what about them, exactly? I have no idea.

It’s true that the centre of Stockholm does have impressive fast-flowing water, a rushing, churning torrent that pours constantly in two streams, either side of Helgeandsholmen, the island taken up almost entirely by the Swedish parliament building. When I visited Stockholm, I walked through the old town and down to visit the museum of medieval Stockholm which lies underground, beneath the gardens in front of the parliament. When I reached the narrow channel of water separating the parliament building from Stockholm Palace, I was shocked and amazed by the speed and power of the water. It flowed from east to west in a solid, smooth-surfaced grey-green mass, as if it had an enormous weight behind it. It felt dangerous, unstoppable, and irresistable.

I already knew that Stockholm, and the Baltic in general, doesn’t really believe very much in having tides. Stockholm’s harbour is technically seawater, but there are many kilometres of archipelago between the city and the open sea, and to get to open ocean you have to go all the way around past Copenhagen and the tip of Jutland. Because of that, the Baltic isn’t particularly salty and doesn’t have very dramatic tides. This couldn’t, then, be a tidal flow. It took maps to show what it was.

OpenStreetMap map of Stockholm

The above extract from OpenStreetMap is © OpenStreetMap contributors and is licensed as CC BY-SA.

You can see how Stockholm is built around a relatively narrow point in the archipelago. What you can’t really see at this scale, though, is that all the channels of water to the right of the city centre are the main archipelago, leading out to see, but the channels of water to the left of the city centre are all part of Mälaren, a freshwater lake some 120km long and with an area of over a thousand square kilometres. Most significantly, its average altitude is about 70cm above sea level. That slight-sounding difference adds up to roughly 800 billion litres of water above sea level, all trying to flow downhill and restricted to the two channels, Norrström and Stallkanalen, the second narrow, the first wide, around Helgeandsholmen. Norrström, in particular, is a constant rush of choppy white water.

Norrström

Why only those two channels? Although you can’t really see from the map, the other paths of blue that look like channels of open water, around Stadsholmen and Södermalm, were long ago canalised, blocked off with large locks. The two northernmost channels are the only free-flowing ones.

So, you might be wondering, what was the point of this post? Was there going to be some deeper meaning I had uncovered, some great symbolism or relevance to my everyday life? Frankly, it’s entirely possible, but I have no memory at all of what I was thinking when I wrote that note originally.

Right now, it’s tempting to say that sometimes, instead of trying to understand life and everything around you, instead of trying to predict what will happen and what the best course of action to take will be, it’s better just to sit back and ride the rollercoaster, and tht the sight of the massive onrush of water through the centre of Stockholm made me think of just jumping in a small boat and shooting the rapids without worrying about what happens next. Equally, I might have been thinking of how you can find such a powerful force of nature right in the heart of somewhere as civilised as a modern European capital city. For that matter, it could have been a contrast between how placid, still and mirrorlike the waters of Mälaren a few hundred metres away outside Stockholm City Hall are, compared with the loud, rushing, foaming rapids we’re talking about here.

A few hundred metres away all is peaceful

To be honest, I really don’t know. I know which of those thoughts seems most apt right now, but it might not even have occurred to me in January. At least, now I’ve written this, I can close that ticket happy in the knowledge that something fitting, in one sense, has been written under that heading. Now I’ve done that, I can flow onwards to the sea.

Little and often

Or, how often should a blog update, and does it really matter?

It’s almost the end of August, already.

If you ever scan your eyes down the list of links to the various archive pages on this blog—somewhere over on the right on desktop, right down the bottom on mobile, at least with the current design—you’ll see there were only five posts published here this month. Over the last three months in fact, there has been a bit of a drop-off in posting, compared to the other months since the blog was relaunched.

There are reasons for that, which I’m not going to go into here but which mostly involve having other outlets for my writing. Some of it might be published one day, and some won’t be, but that isn’t really the point of this post. The thing I wanted to talk about today is: does it really matter?

This initially popped into my mind at work a few months back, when I was preparing to interview a potential job candidate. Naturally beforehand I did all the usual background research on the candidate in question, looking at what social media profiles they had listed on their CV, hunting down some of the ones they hadn’t listed, and reading all the other links they’d put on their CV. The person in question included a link to a blog. When I followed it up, I found I really enjoyed the articles I found there (all of them tech-related in some way), but there were only a handful. This candidate had started a blog up in lockdown, had updated it a couple of times, and then nothing more. It was still sitting there on their CV, even thought it seemed to be getting a little bit cobwebby.

But does that matter? Well, frankly, it shouldn’t. If you’re interviewing a candidate for a job, you’re interviewing them, not their sticking power at a spare-time project. This blog, on the other hand, is never getting near anyone who might want to employ me, so it doesn’t matter at all if I go a little quiet for a few months, a few years, or even forever. It’s sad, a little, to see someone has started a project only to see it sputter out barely before it has started, but I should try to avoid letting it colour my opinion of them, particularly my opinion of them in a different context.

This site has been a little quiet, but it’s not as if I ever posted in any way consistently to begin with. It comes and goes according to my whims and inspiration, and whether or not I remember to write my ideas down. As I write it largely (but not entirely) for my own amusement, it shouldn’t really matter too much. I do gather information on how many people read this stuff, but I rarely actually look at that information. If I write anything for you specifically to read, I’ll tell you, but otherwise these words are just being thrown out into the electronic void. Some day, there might be an echo back, but I don’t really expect one.

A birthday

The years march on

This blog is now a whole sixteen years old. At least, it’s now sixteen years from the date of the first official post. Looking at the calendar for that year, the site was put live on a Saturday, the day after someone had driven into the side of my car. Well, at least I had some content to post about. Since then there’s been over a thousand posts in total, I think, if you include all of the complete-nonsense ones that have been edited out in the interim.

Of course, there have been a few hiatuses over the course of the last sixteen years, some of which were longer than others. The site only really came back from its longest hiatus as a lockdown project, last summer, but it’s provided something of an outlet for me ever since. Whether it will still be going in another sixteen years’ time is, of course, a complete unknown, but we can only move in that direction and find out, can’t we.

A clean break

Well, not really

Back in the mists of time (well, January), I posted about the mechanism I use to keep track of ideas I’ve had for posts to write about, so I make sure that if I’m in the middle of something else and think “that would be a good blog post topic,” it doesn’t just get forgotten and allowed to wither.

I realised, looking the other day down the list of “tickets” for post topics to write about, that practically all of the things I actively want to write about are ideas I’ve come up with in the past couple of months, since moving house. There are plenty of things I wrote down before moving, but none of them really spark anything inside me at the moment, as something I want to put down and get out there. Some of them I do at least understand; others are a little bit more mystifying. When I put down a few words such as “Post about the fast-flowing water in Stockholm,” what did I really mean and what exactly was I going to say?

Moving house, it seems, has subconsciously been a much bigger upheaval than I realised it would be. A much bigger and cleaner break from the past than I was expecting. I can understand no longer having the energy to write posts about Bristolian local history; but all of those had been cleaned off the backlog already in any case. Somewhere in my head, all of the ideas I came up with before moving are now in a dusty mental box marked “do not need to unpack”.

Nevertheless, although I had a bit of a lull, there are now plenty of ideas to come. At some point, too, I’ll get back on to the old ones, maybe even finish writing that modern version of The Box Of Delights that I started to make a rough stab at. There is a lot more to say, even if as yet I don’t know exactly what all of it will be.

Cross-pollination

Or, some ideas for tracking ideas

A few days ago, I mentioned in passing that there I have lots of ideas for topics to write about on here, and the backlog of ideas is slowly building up. What I didn’t say was: how I track the backlog and remember all those ideas; instead, I thought to myself, that would make an interesting post for another day. “Backlog” isn’t meant to be derogatory, by the way. I see it as a good healthy thing, that I have lots of ideas that I haven’t as yet have had the time or energy or inclination to turn into words yet. Better that than a dearth of things I want to talk about, after all; that’s what would make this site slowly dry up and wither.

The Plain People Of The Internet: That and there not being any readers.

I don’t mind too much if there aren’t any readers. If I cared about readers I’d be cross-promoting this everywhere, doing complex deals and joint projects and promoting myself as the exciting new face of self-published diarising. I don’t, though, because the point of this is the writing, not the reading. But that’s by-the-by too really.

It’s very easy to get into the situation where ideas do just flit away on the wind as soon as they come along, and the spark of inspiration never gets turned into a post on here. Write your ideas down, is the standard piece of advice, but that means having something to write with, something to write on, and somewhere to collate and collect all of your scribbled notes. Working in software development, though, there are a few closely-related solved problems, so when I restarted this blog last summer I decided I was going to use the skills and tools I know from the day job to help me plan and track my writing on here. There are two key related tools that I’ve been using to help, which any software people reading this really should know about: version control and issue tracking.* If you are a software person, and you think the next paragraph is teaching you to suck eggs a little bit, then just remember that there are always people in the world who don’t know this stuff. Nobody is born with an innate knowledge of project management.

Version control is, very simply, the idea of keeping an archive of your working files that preserves their state over time, at least at the intervals you choose. It has a long history; the concept has been around probably longer than computers themselves. The leading system for it at the moment is called “git”, and was created by Linus Torvalds in order to help with development of his “Linux” operating system.** It effectively takes snapshots of all the files in a given folder at a point in time, and you can reset your “working copy” of the files to any snapshot whenever you want to. Moreover, each snapshot (or “commit” in the jargon) has a record of its parentage, and this ties commits together in a way that makes the folder’s history more than just one-dimensional. The chain of commits starting at a particular recent one and reaching back through the sequence of ancestral commits is called a “branch”; your archive can contain any number of named branches in parallel, and you can switch between branches whenever you want too. Not all developers really understand how to use branches properly, but if you do, they are a very powerful tool to help you organise disparate strands of work.

Git was originally designed to be a highly decentralised system without any single copy of the archive holding the privileged position of being the main primary copy. Most developers, however, don’t actually use it like that. A number of companies and organisations have sprung up to offer Git hosting services, and most development teams use one of these hosting services to host the primary copy of their Git data and use it as a centralised exchange point to share their code. That isn’t an issue for me writing this website, but these hosting services also offer additional services which are very useful: particularly, in the context of this post, ticketing systems. These are basically databases that let you create a “ticket”, generally some sort of work item such as a bug, a new feature or a task to be completed, and then let you track the progress of each one. The really fancy systems are so customisable you can completely shoot yourself in the foot designing over-complicated workflows, building reports, and adding custom data fields to each type of ticket, but I don’t care about any of that. The important thing here is that I can create a ticket, and I can access the “create ticket” function from anywhere through my phone. Whenever an idea for a new post comes along, I can immediately create a ticket with a brief description or title in it; then when I sit down to write something, I have a whole list of ideas I’ve had on the screen in front of me. Nothing gets forgotten, and all the ideas are there for me to come back to eventually, unless I didn’t put in enough of a description for it to make any sense.

When I start work on a post, I do exactly what I’d do when working on a piece of code. I read the ticket and click the button to flag it as in progress. I go to Git, make sure I’m at the tip of the “main” branch (as this reflects what’s currently on the website), and create a new branch with the ticket number in its name. I go into the site’s content code and create the new post, and when I’m happy with what I’ve written I create a commit with the new article in. Then, my Git hosting site has tools to help me check over what I’ve just done before folding those changes into the “main” branch. If I really wanted to, I could set up “continuous integration” code that would automatically push those changes out to the website as soon as they are folded into the main branch; although I’d use that for a software project, for this site I prefer to keep that process manual. When the changes have been made and the whole thing has been published, I mark the ticket as “closed”, and it disappears from my ticket backlog.

This sort of system isn’t for everyone, and it might not work for you, but I find it invaluable to keep track of what I’ve been thinking and what I’ve been planning. I find it’s fairly lightweight—it helps that I need to be comfortable with the tools anyway—but I understand not everyone is likely to agree. The hardest part, at least at first, is the discipline. Thinking to myself “better create a ticket for that” when an idea pops into my head, rather than just letting the idea float away again. Then again, that discipline is just as important if you rely on writing all your ideas down on paper; and the benefit of the technology is being able to easily file them all once you’ve done that. If anyone reading this is a non-tech person who has adopted these type of tools for non-tech activities like writing or indeed anything else, I’d love to know, and I’d love to know how much of a success it has been for you. For me, this is one big thing that helps me write, because it turns a lot of the administrative aspect of the writing process into something that is purely mechanical. For you, it might be different—but I’d love to know what you think.

* To be honest, there are a few software dev workshops that don’t use one or the other of those tools, even though they almost certainly should. They’re not new, and they make your life a lot easier. Even in top global businesses there are teams here and there who refuse to use version control, or more commonly, don’t really understand how to use it properly. It would be unprofessional of me to name and shame, but all I’ll say is, you would be surprised.

** This is not the place for a debate over whether Linux is an operating system or not.

A writing dilemma

Or, where to go from here

Happy Boxing Day and all that!

Regular readers will have noticed I’ve been writing a modern day retelling of The Box Of Delights over the past few weeks. If you’ve noticed that, you’ll also have noticed I haven’t got anywhere near the end of what is supposed to be a seasonal story—I mean, we haven’t even come across the titular box yet.

Bearing that in mind, and bearing in mind my probable low speed of writing, the question is: what do I do now?

  • Keep writing and publishing it here as I write, even if that means the Christmas conclusion is published in August.
  • Keep writing and drafting and publish it here next December.
  • Stop writing it, it’s not very good anyway.

Answers on a postcard to the usual address, etc. And, indeed, feel free to send in any other questions.

Right, now I shall go back to building one of the things I received to play with—feel free to guess what it might be! Merry Christmas!

Christmas present

The changing mood and the changing season

Or, something of a lull, and the strange ways in which memory works

This blog has been relatively quiet this week. Clearly, finally completing that in-depth work-related post about inclusion and diversity on Monday must have taken it out of me. There are a number of things waiting in the to-be-written queue, but all of them are the sort of posts that deserve effort and energy and research putting into them, and this week has been too tiring a week for that sort of thing.

I like to think of myself as not a superstitious person, but the truth is that there are an awful lot of Dear Diary things I could have posted but didn’t because, frankly, if I do then it might jinx them and it might not happen. There are some things that have been lurking on my horizon for a few months now, but I don’t want to think about them too much in case one thing goes wrong and everything collapses. A couple of weeks ago it all looked to be going badly; this week it’s been going better, but I still don’t want to put too much effort into hoping everything will work out in the end in case that is all effort wasted.

The Children turned seven recently, which inevitably leads into thoughts of “this time seven years ago I was doing X” variety. At least, it does if you’re me: I think I picked the tendency up from my father, who would do it at the slightest potential reason. It’s strange to think that The Children were not always exactly as they are now. I don’t know how your memory works, but when I think back to my memories of people I knew long ago my brain tends to fill the image with them as they are now, not as they actually were then, which is very confusing when I think about things that happened, say, at school. It’s almost disconcerting to see things like school group photos and think “we all looked like children!” and similarly it’s strange to look at photos of The Children as babies and see that, yes, they actually looked like babies and not the children they are now. No doubt when they’re adults I will look back on how they were now and be surprised they looked like children.

A couple of weeks ago I posted about the season changing. Enough leaves have dropped from the trees now that if I look carefully I can see trains passing the end of the street again, rather than just foliage. The skies are dark at night, and on clear nights filled and sparkling with autumn constellations. I go outside, look up at Vega, at Mars, at the cross of Cygnus, and wonder what will happen when we have turned around some more.

We can rebuild it! We have the technology! (part four)

Or, finishing off the odds and ends

Settling down to see what else I should write in the series of posts about how I rebuilt this website, I realised that the main issues now have already been covered. The previous posts in this series have discussed the following:

And throughout the last two, we touched on some other important software engineering topics, such as refactoring your code so that you Don’t Repeat Yourself, and optimising your code when it’s clear that (and where) it is needed.

There are a few other topics to touch on, but I wasn’t sure they warranted a full post each, so this post is on a couple of those issues, and any other odds and ends that spring to mind whilst I am writing it.

Firstly, the old blog was not at all responsive: in web front-end terms, that means it didn’t mould itself to fit the needs of the users and their devices. Rather, it expected the world to all use a monitor the same size as mine, and if they didn’t, then tough. When I wrote the last designs the majority of the traffic the site was receiving was from people on regular computers; nowadays, that has changed completely.

However, the reason that this isn’t a particularly exciting topic to write about is that I didn’t learn any new skills or dive into interesting new programming techniques. I went the straightforward route, installed Bootstrap 4.5, and went from there. Now, I should say, using Bootstrap doesn’t magically mean your site will become responsive overnight; in fact, it’s very straightforward to accidentally write an entirely non-responsive website. Responsiveness needs carefully planning. However, with that careful planning, and some careful use of the Bootstrap CSS layout classes, I achieved the following aims:

  • The source code is laid out so that the main content of the page always comes before the sidebars in the code, wherever the sidebars are actually displayed. This didn’t matter so much on this blog, but on the Garden Blog, which on desktop screens has sidebars on both sides of the page, it does need to be specifically coded. Bootstrap’s layout classes, though, allow you to separate the order in which columns appear on a page from the order in which they appear in the code.
  • More importantly, the sidebars move about depending on page width. If you view this site on a desktop screen it has a menu sidebar over on the right. On a narrow mobile screen, the sidebar content is down below at the bottom of the page.
  • The font resizes based on screen size for easier reading on small screens. You can’t do this with Bootstrap itself; this required @media selectors in the CSS code with breakpoints chosen to match the Bootstrap ones (which, fortunately, are clearly documented).
  • Content images (as opposed to what you could call “structural images”) have max-width: 100%; set. Without this, if the image is bigger than the computed pixel size of the content column, your mobile browser will likely rescale things to get the whole image on screen, so the content column (and the text in it) will become too narrow to read.

On the last point, manual intervention is still required on a couple of types of content. Embedded YouTube videos like in this post need to have the embed code manually edited, and very long lines of text without spaces need to have soft hyphens or zero-width spaces inserted, in order to stop the same thing happening. The latter usually occurs in example code, where zero-width spaces are more appropriate than soft hyphens. All in all though, I’ve managed to produce something that is suitably responsive 95% of the time.

The other point that is worth writing about is the build process of the site. As Wintersmith is a static site generator, every change to the site needs the static files to be built and deployed. The files from the previous version need to be deleted (in case any stale ones, that have disappeared completely from the latest iteration of the output, are still lying about) and then Wintersmith is run to generate the new version. You could do this very simply with a one-liner: rm -rf ../../build/* && wintersmith build if you’re using Bash, for example. However, this site actually consists of three separate Wintersmith sites in parallel. The delete step might only have to be done once, but doing the build step three separate times is a pain. Moreover, what if you only want to delete and rebuild one of the three?

As Wintersmith is a JavaScript program, and uses npm (the Node Package Manager) for managing its dependencies, it turns out that there’s an easy solution to this. Every npm package or package-consumer uses a package.json file to control how npm works; and each package.json file can include a scripts section containing arbitrary commands to run. So, in the package.json file for this blog, I inserted the following:

"scripts": {
  "clean": "node ../shared/js/unlink.js ../../build/blog",
  "build": "wintersmith build"
}

You might be wondering what unlink.js is. I said before that “if you’re using Bash” you could use rm -rf ../../build. However, I develop on a Windows machine, and for this site I use VS Code to do most of the writing. Sometimes therefore I want to build the site using PowerShell, because that’s the default VS Code terminal. Sometimes, though, I’ll be using GitBash, because that’s convenient for my source control commands. One day I might want to develop on a Linux machine. One of the big changes between these different environments is how you delete things: del or Remove-Item in PowerShell; rm in Bash and friends. unlink.js is a small script that reproduces some of the functionality of rm using the JavaScript del package, so that I have a command that will work in the same way across any environment.

So, this means that in the main blog’s folder I can type npm run clean && npm run build and it will do just the same thing as the one-liner command above (although note that the clean step only deletes the main blog’s files). In the other Wintersmith site folders, we have a very similar thing. Then, in the folder above, we have a package.json file which contains clean and build commands for each subsite, and a top-level command that runs each of the others in succession.

"scripts": {
  "clean:main": "cd main && npm run clean",
  "clean:misc": "cd misc && npm run clean",
  "clean:garden": "cd garden && npm run clean",
  "clean": "npm run clean:misc && npm run clean:main && npm run clean:garden",
  "build:main": "cd main && npm run build",
  "build:misc": "cd misc && npm run build",
  "build:garden": "cd garden && npm run build",
  "build": "npm run build:misc && npm run build:main && npm run build:garden"
}

And there you have it. By typing npm run clean && npm run build at the top level, it will recurse into each subsite and clean and build all of them. By typing the same command one folder down, it will clean and build that site alone, leaving the others untouched.

When that’s done, all I have to do is upload the changed files; and I have a tool to do that efficiently. Maybe I’ll go through that another day. I also haven’t really touched on my source-control and change management process; and all I have to say there is, it doesn’t matter what process you use, but you will find things a lot more straightforward if you find a process you like and stick to it. Even if you’re just a lone developer, using a sensible source control workflow and release process makes life much easier and makes you less likely to make mistakes; you don’t need anything as rigid as a big commercial organisation, but just having a set process for storing your changes and releasing them to the public means that you are less likely to slip up and make mistakes. This is probably something else I’ll expand into an essay at some point.

Is the site perfect now? No, of course not. There are always more changes to be made, and more features to add; I haven’t even touched on the things I decided not to do right now but might bring in one day. Thoe changes are for the future, though. Right now, for a small spare-time project, I’m quite pleased with what we have.

Readers' Letters

Or, some of your questions answered

Time to answer some of the questions that have been sent in over the month or so since I revived this site.

Occasional reader Harold from Winchester read yesterday’s post about the Battle of Hastings and wrote:

Didn’t you write about that before?

Well, yes, it turns out that exactly ten years ago today I also wrote a “what might have happened if the outcome of the Battle of Hastings was different” post, including the same story of how the outcome was nearly different, and the side comments on how the battle has always been treated in English historiography. I suppose, if anything, it’s interesting to read the two side by side and see if my opinions have changed much over the past ten years, or if my writing style has evolved in the meantime too. Let me know if you think it’s better or worse than it used to be.

Regular reader Sarah from Ipswich writes:

Can I come with you on one of your trips to Wales?

Frankly, I wish I was going to Wales in the near future. All the nearby bits of Wales are closed to visitors at the moment, though. At some point I need to get myself back up to North-West Wales and visit the trains again, of course. Hopefully that will happen, even if it doesn’t now happen this year. As for the nearer bits of Wales: well, we’ll have to see how things progress I suppose.

And finally, long time reader E Shrdlu of Clacton writes:

Now you’ve brought this website back from the dead, are you still going to keep up the same running jokes and bring back all those series of posts you used to do years and years ago, like reviewing books you hadn’t finished?

Back in the mists of time I did indeed write reviews of books I hadn’t finished reading. I suppose you could call it a deconstruction of sorts, or an exercise in honesty, because they were at least all (I think) books I had tried to read, and failed to finish. Investigating why I failed to finish a particular book is interesting in itself, and admitting I didn’t finish it is more honest than just writing a review and saying “this is a bad book”. Moreover, if you read through those posts, you’ll see there were a broad range of different reasons for not finishing each book. One of them ended up being found by its author, who I had carefully not accused of plagiarism because I knew he was a former top barrister with lots more money than me.

I have to admit, I’m in the middle of drafting the next Books I Haven’t Read article. It’s probably going to be quite a long article, because it’s about quite a long book. I’ve also made sure it’s by a safely-dead author, so I can freely express my opinions about their poor understanding of archaeology or their failed attempt at polyamory. Feel free to guess who, and what, it’s going to be about; it’s a complex book, a complex topic, and it’s probably going to take me a while to finish it.