And I don't mean biting flies.

I'm a little reluctant to relate this, because I worry that it feeds into Jack's anxiety about Tinderbox. I shouldn't, I know. It's not Tinderbox, it's me!

Anyway, went to post this morning's moon and I got an AppleScript error. That hasn't happened in a long time. Checking, I discovered that the marmot hadn't created the May 2024 archive.

One of the wonderful things about Tinderbox is that pretty much everything is easily exposed and accessible to the user. My new month edict was refusing to run, and it wasn't clear why. The same code is running in Captain's Log and the Blog Test Platform, which I dusted off to help troubleshoot this problem, and they both had a May 2024 container.

So I exposed all the attributes I was using in the edict to see what their values were, and I immediately saw a problem. The edict begins by checking to make sure that we're still in the same year, so it doesn't, for example, create May 2025 in the 2024 container. So it looks at the date the 2024 container was created, which should have been, you know, 2024.

But it wasn't! It was 2023! Which was before I began to seriously work on automating all of this. I'm certain that I manually created the 2024 container at exactly 11:56 a.m. on Sunday, December 31, 2023, because that's when Tinderbox recorded it. So the first test in the edict was failing right out of the gate!

But I thought it worked at the beginning of April? I can't answer that, because there's no way it could have. The edict relies on $Created for the test, and that's a read-only value, so it simply couldn't work. And I couldn't manually coerce it to be something like 1/1/2024 either.

So, for at least the remainder of 2024, I've created another date-type attribute, ArchiveYear, which is set to 2024 and changed the edict to use that for the test and voila! May 2024 appeared.

But it has prompted me to look at the Archive containers in Captain's Log and Blog Test Platform as well. Their 2024 containers each created May 2024 correctly, but that's only because their 2024 containers were created in 2024, although manually, not by the Archive edict, because that hasn't needed to run yet. And looking at each of them, those edicts are wrong. I still want to rely on the intrinsic values, because they're appropriate for this purpose and there's no real value in creating a new attribute to do the same thing. I'm only doing it for what will be the remainder of 2024 because it's a simple way to patch this bug.

So I'll fix those in a minute, and then I'll wait for the next bug to reveal itself.

I will say, this is a lot easier than working on a water softener.

Originally posted at Nice Marmot 08:51 Wednesday, 1 May 2024