Today—and I realize that I probably go to this well every year, because why would I not—the United States marks Martin Luther King, Jr., Day, celebrating the legacy of the civil rights leader.

44th Original MLK Jr. Parade, downtown Houston, 2022

I can’t outdo King, so let’s just move on to software.

Boring CSS

GitHub - jcolag/boring-cssA set of CSS files (for me) to use for prototyping - jcolag/boring-css

I believe that I’ve gotten the various CSS files for Boring CSS fairly close to what we used to call a valid “proof of concept,” but now we call a “minimum viable product,” because capitalists gotta capitalize. Or something. More usefully, the repository now has the base “make things readable” CSS, three color palettes—generic HTML, Solarized, and Nord—and at least a prototype for Material Design as it applies to standard HTML widgets.

The project also now has straightforward documentation, and has seen a bug or two fixed.

Maybe most importantly, you can now try out my little system on GitHub. When you open the linked page, it’ll load without any CSS at all, black text on a white background. You can then turn on the various pieces and see how they change the page. Oh, maybe I can embed it here.

And as a reminder of the project’s context, I don’t expect or want this to become the new trendy CSS framework. Personally, I see it as useful for quick prototypes and other one-off projects, where you might want a surface level of a professional presentation, but don’t need it to withstand much scrutiny. Think of it more on the “oh, I forgot to make the page look like a human made it” side than the “customers will see this” side of the universe of projects.

On the other hand, don’t feel afraid to run with the ideas, here. For example, for demonstrations in a corporate environment, you can often do worse than make things look clean, and change all the colors to fit the marketing department’s brand guidelines, so that project using Boring CSS feel like a part of the company.

Making the Example Page Work

I like the example above, because it dynamically loads and unloads the various CSS files, which works perfectly for the demonstration, even though it sounds miserable for any sort of production work. To make it work, I combined some straightforward guessing with a few Stack Overflow answers, to get this.

function changeCss(cssId, filename) {
  const head = document.getElementsByTagName('head')[0];
  const css = document.getElementById(cssId);
  const link = document.createElement('link');

  if (css) {

  if (filename.indexOf('-') === 0) {

  link.href = filename; = cssId; = 'all';
  link.rel = 'stylesheet';
  link.type = 'text/css';

Before I explain it, let me take a step back to show how a typical page includes a CSS file in the page header.


We have a standard HTML element, that only coincidentally adds a stylesheet. Since it sits in the header, we can manipulate the object model (the “DOM”) to add and remove this sort of thing.

In this case, the JavaScript code does four things, based on the two input parameters.

  1. If a link element with the specified id attribute exists, delete it. This helps us ensure that, for example, we only have one color palette loaded at a time.
  2. Check if we’ll find the desired CSS file. I used a naming convention that allows me to identify a bad CSS filename as one beginning with a dash. If the filename doesn’t make sense, skip the rest of the process.
  3. Create a link element pointing to the desired CSS file, and which has the correct id for that kind of file.
  4. Add the link element as a child to the head element.

Honestly, I didn’t expect that to work, but it caused surprisingly few problems.

Depending on the CSS change requested, the page calls changeCss() through one of three helper functions, each of which knows how to pick its id attribute and how to form the filename.

Like I said, I wouldn’t necessarily recommend doing this for a real-world project, but in the limited case of demonstrating the CSS files, it works like a dream.

My GitHub Profile

GitHub - jcolag/jcolagJohn's GitHub README, since everybody else is making one... - jcolag/jcolag

Two items came up, this week, on my profile.

First, two visualizations that I use had an issue—unsurprisingly, since an independent developer’s toy instance has spread across the Internet to see wide use—dealing with the strain of use. While the solution may ultimately cause new issues further down the line, this issue on GitHub recommended a different URL, which seems to work, at least for now.

And while I had to think about that sort of thing, and as long as my social media presence has drifted towards my abstract profile picture, I decided to finally upload a custom avatar to GitHub. However, I didn’t like how it looked, there, so I made two changes. First, I shifted from the original SVG headshot that I mentioned in November to a more abstract version created by repeatedly simplifying the SVG paths. Second, because I half-consider the randomized “W” design as part of my identity on GitHub, I overlaid the abstract headshot as a layer over the old avatar.

I don’t love the resulting avatar, but it does the job, and gives me something that might remind people of me from other platforms. Either way, you can probably see a hint of it to the upper-right, in the repository preview images.

Entropy Arbitrage

GitHub - jcolag/entropy-arbitrage-codeThe Jekyll blog for - jcolag/entropy-arbitrage-code

In the change in my routine social media posting from Twitter to Mastodon, I needed to overhaul my Friday posts. I made some changes to the format, naturally, changing the icons to indicate Mastodon, and rewriting some boilerplate text.

However, I also improved the random time generator. I’ve discovered after a couple of years that using Linux’s rand function repeatedly in rapid succession doesn’t always get a decent spread of numbers, often repeating numbers in successive trials. In its place, since I need a list of times anyway, I’ve started using seq to produce a sequence of numbers, and then randomly sorting that. Because I also decided to allow a bit more “spread” to my posting times, I finally settled on this.

seq 7 | sort -R | head -5 | paste -sd' '

This creates a list of the whole numbers 1–7, sorts them randomly, takes the first five from the list (for Monday to Friday), and runs them together on one line, so that I can treat them like an array.

And while I already had randomness on the brain, I decided to randomize the caption for my standard days-of-the-week header image for these posts.

Origin Story

Did I ever talk about why I had the randomized posting times?

Long before I started this blog, I decided that I should have some presence on Twitter, beyond only having the account and sending rare “fan mail.” It didn’t have the best reputation, but plenty of people had stories of finding jobs and the like, so it seemed like a reasonable compromise. As you can probably guess, this can happen, because Twitter makes it more straightforward to get into conversations with powerful people than many of the traditional social networks. The networking won’t generally come to you.

In any case, not quite realizing that, I wanted to post regularly, but didn’t want to spend time there. I concocted the scheme of scheduling posts twice per weekday. To make it feel less automated, I randomized the minutes of the hour, limited to the early few minutes. And I picked a couple of minutes after 9:00 AM, because when I started posting, I had a job with a daily 9:00 AM in-person stand-up meeting, so it made some sense to pick a time when colleagues wouldn’t suspect that I used social media on company time.

When I started my social media roundup posts on the blog, the script that generated random times became the script that generated the roundup post. And now, I mostly consider it tradition.


I still have some surprises for Boring CSS, believe it or not, and some changes that I’ve neglected for the blog.

A part of me wants to research Mastodon’s API and add a second-stage to my social media roundup posts—discussed in the previous section—to automatically schedule the posts. Currently, I use FediPlan, which seems to have shaky authentication, and I also need to manually set the release times and so forth. In other words, I have an error-prone process that requires several layers of manual inspection to make sure that I didn’t completely foul things up.

However, if I can make a series of API calls to schedule each toot—complete with content warnings, release time, images, and image descriptions—based on information that I generated or typed into the blog post, that seems like it would dramatically decrease the chances of making a huge error. I know that better authentication exists, for example, because I use toot to announce every blog post, and haven’t needed to re-authenticate since changing laptops…but it doesn’t handle scheduled toots.

Doing that would also convince me to pay more attention to the header images in the articles. I’d need to note their file names in the post, and once I cross that point, it wouldn’t take much more work to check the license for each and decide which I can include in the post. It’d also keep the image descriptions—which I now provide in the toots—with the post.

Credits: The header image is Original MLK parade Houston TX 2022 11722-39 by 2C2K Photgraphy, made available under the terms of the Creative Commons Attribution 2.0 Generic license.