Follow-up to yesterday’s post: Adam Fusco and I had a bit of a test of this over at social.lol. Turns out when you send a private message, the reply defaults to being private as well. This also applies to replies of replies. Private messages can’t be boosted either. Good to know.

I came this close to sending the Mastodon equivalent of a DM today. That it works by simply setting the visibility of a toot made me wonder if the recipient would need to explicitly do likewise on the reply. This uncertainty turned to concern, and I end up not sending anything.

Dealing with tables in Obsidian reminds me that as much as I think I like working with tables in markdown, the truth is that I really don’t.

Wonder if it would be easier with that alternative markdown table format that the Linux community uses. One where rows are laid out over multiple lines - where each line is a separate column - instead of horizontally with the pipe character.

Looking at the pitches for a hackathon being planned at work, I’m coming to realise I get excited about pretty boring things. New mobile apps? Using graph databases? Building search indices? Nah, a simple web-app for dealing with pull requests is what I’d rather work on.

It’s strange that the blog posts I enjoy reading from others are the same sort of blog posts I feel weird about writing myself. Classic example are posts about software I’m interest in. I love reading blog posts about releases of software I enjoy using — or even something I don’t use myself, but enjoy reading about. And yet, when it comes time for me to write a similar post about the software I’m working on, it always feels like I’m doing something dirty, like “promoting” or “marketing” it.

We use a lot of Jsonnet a work. We use it to generate Cloud Formation templates, Kubernetes YAML files, and application configuration from a single source file.

Jsonnet is effectively a templating language for structured data. It looks a lot like Json (which is by design since it’s meant to be a drop-in replacement) but includes a few quality of life improvements, such as comments and letting you include the last comma in a list; something that a strict Json parser will never let you do:

[
    { some: "value" },
    { another: "value" },  // Perfectively valid
]

Generally, it works pretty well, except for one sneaky “feature” that has caught me off guard a few times.

If you have an object next to another object, and the two objects do not have a comma separating them, like so:

[
    { some: "value" }
    { another: "value" }
]

Jsonnet will merge it into a single object:

[
    { some: "value", another: "value" }
]

This is a documented feature, but as someone who is used to dealing with Json and it’s strict parsing rules around commas, it seems to me like a bit of a gotcha. It might be obvious in this example but for larger files, a missing comma like this is less likely to be intentional, and more likely to be an accident.

Consider this: you’ve got a long list of large objects spanning tens of lines and you need to add a new object to the end:

[
    {
        "product": "apples",
        "price": 100,
        "tax": 20,
        "shipment": "basic"
    },

    // ... skip 23 other items here

    {
        "product": "yachts",
        "price": 50000,
        "tax": 20,
        "shipment": "expensive"
    }

    // Add price of zebras here
 ]

Given our evolved need to save energy, you’re more likely to copy the object for yachts instead of typing out the object for zebras in full. Note that the object for yachts doesn’t have a trailing comma since we’ve been trained to follow the strict rules of Json parsers. So you copy yachts and paste it on the line below. Now both the original and pasted objects for yachts have no comma, but you don’t notice that because you’re focused on changing the pasted-in object to be one about zebras.

Then, when it comes time to evaluate your config template, you’re down one item. Thinking that you’ve missed something trivial, like saving the file or something, you expect the missing object to be the zebras. But it’s not the zebras, it’s actually the yachts that are absent.

Eventually you find the missing comma, but you’re a little annoyed that a language that lets you include commas on the last item can ensnare you like this. Sure the feature is documented, but are you really going to read the manual when you’re doing something as trivial as adding new objects to a list? Not helping matters is there’s actually an explicit operator to merge two objects together (the + operator). There wouldn’t be a need for another one that does the same thing, right?

So, language designers, please consider things like this the next time you design a domain-specific language. Especially one based on an existing language with stricter syntax rules than the ones that you enforce. People come to rely on these rules to help them catch mistakes like this.

Here’s the best part about waking up early on a weekend. You’re coffeed and breakfasted at an early enough hour that when it’s time to start your day, nothing else is opened. This means there’s a couple of hours where you’re forced to amuse yourself by, say, working on projects.

I might plan another redesign of how I keep little bits of tech knowledge that I occasionally need to refer back to.

I’ve been posting them here as blog posts, but I don’t love this way of doing things. It’s always a little hard to recall them and sometimes what I learn is in itself a small part of something larger, and there’s always that decision about whether to put it in it’s own blog post. But I think the biggest issue is that, although I talk about technology here, it’s not really a tech blog per si. So seeing bits of tech know-how interspersed with what I usually post here is a little strange, or at least it does to me.

Several months ago I tried keeping this knowledge in a wiki. But because I never finished setting up the wiki software — making sure backups are working, for example — I never got to the point where I was comfortable putting in stuff that I know won’t be lost. For this reason, I never kept the wiki up to date which, in turn, made it useless as a knowledge base. I eventually scrapped it and moved most of that knowledge here.

I’m going to try the wiki-styled approach again as it seems like a better way to organise and present this knowledge. The difference this time is that I won’t be running wiki software. I’d like to keep the cost and maintenance of this system as low as possible while still being confident that what I write there won’t be lost. Stories about how I found a piece of knowledge (if any) will still be posted here, as it seems like a better venue for that (including how I found the knowledge along with the knowledge itself was another thing I was falling out of love with).

As to how this wiki-style approach would work, I’m not quite yet. I think what I’ll try first is to move it all into into a series of markdown files managed by Git. This can be hosted with GitHub and published online using Hugo and GitHub Pages. I’ll start with a single “source” repository with only the markdown files. The “published” version will probably go into another repository, just to keep all the Hugo stuff away from the content. Setting up publishing to GitHub Pages may take a bit of time, but I think it’s something that I’ll want pretty soon, as I get a lot of utility referencing this with a browser.

An alternative is using an Obsidian and their web publishing feature. That would mean less work to do up-front but their web publishing add-on is pretty expensive, so I rather avoid this until I know that the Git approach won’t work.

In any case, I’ll let you know how it all goes.