Today kicks off Hōonkō in most Jōdo Shinshū Buddhist communities, celebrating the tradition’s founder. It seems to stand in opposition to the theory that early winter and near-longest-night holidays make for large raucous gatherings with plenty of food to metaphorically fight back the darkness and cold.

A portrait of Shinran Shōnin

Either way, let’s move on to software.

Ham Newsletter

GitHub - jcolag/ham-newsletterScripts to assemble my monthly newsletter. Contribute to jcolag/ham-newsletter development by creating an account on GitHub.

The newsletter for December went out on New Year’s Eve, and the following Tuesday. While putting it together, I noticed a new problem: My scripts hadn’t picked up any new bookmarks since August.

Investigating, I discovered that this—unsurprisingly, in retrospect—resulted from the change to using the Snap packaging for Firefox. It maintains its configuration and history in a different location, which my script didn’t know about.

Since I didn’t feel like researching a way to automatically discover the bookmark storage for the current default browser, I took the more expedient route of turning the location into a configuration option. Maybe one day, I’ll go back and improve that, but it works for now. And if you’ve missed seeing the pages that I’ve bookmarked, I have a bumper-crop of them in a newsletter supplement to keep you occupied.

I also optimized the month calculation—the awkward two-step, where I jump back a month, if I run the script early in the month, to generate the content for the previous month—outside the script’s main loop. It should never run twice, so I don’t know how it got inside the loop in the first place.

Boring CSS

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

Quick confession: I don’t care for CSS frameworks. Don’t get me wrong, here. I acknowledge their utility. However, I don’t like how they make everything a CSS class, even things that already existed as standard HTML elements. If I need to write something like <button class="framework-button"></button>, that feels more like self-service vendor lock-in than the framework helping me.

In addition, I’ve started thinking increasingly about laying out web pages specifically for readability.

As a result of those two feelings, I’ve started tinkering with a more straightforward approach to CSS, suitable at least for prototyping. I haven’t committed—or written—most of what I want, but I have a vision of providing a set of CSS files to mix and match, to create at least a passable user experience, without putting in much work.

This will probably come in three pieces, with options for some pieces.

  • Some styles that I currently consider mostly universal, such as focusing the page to a narrow column for more effective reading, and providing plenty of empty space.
  • Standard and tested color palettes, such as Solarized or Nord, pre-configured for the page. The palettes should use media queries to automatically implement light- and dark-modes.
  • A subset of design languages, such as Material Design or Carbon.

In particular, I want every style in the design language adaptation to target a specific kind of HTML element, so that the styling happens with no work on the developer’s part. In other words, I want to use these files to kick off a new project, where I say “this app should adhere to Material Design, but use a Solarized theme,” and not need to think about CSS past that point, if I don’t want to.

This will require sacrifices, since the majority of a typical modern design language applies to things other than standard HTML controls, such as fonts, icons, and controls beyond the HTML standard. But I suspect that, for a lot of straightforward work, I’ll feel more content with a “good enough” design that I only needed to implement once.

Morning Dashboard

GitHub - jcolag/dashA morning "dashboard" generator. Contribute to jcolag/dash development by creating an account on GitHub.

Early in the week, the Morning Dashboard program started throwing a long series of warnings, all the following message.

Using TZID without Luxon available is unsupported. Returned times are in UTC, not the requested time zone.

It’d repeat that a few dozen times before finishing the task. It made some sense for the code to have so many issues with time zones, given how many maybe-suspect time calculations the program makes. At least, it makes sense in theory. In practice, it makes no sense, since none of this code has changed since November, so it apparently decided to bide its time through December, to surprise me in the new year.

Searching around for the error message didn’t turn up much insight, but I did detect an occasional undercurrent that the problem no longer exists in whatever underlying library has this problem, so I updated all the JavaScript libraries, while I had to give it my attention.

I suppose that I could’ve replaced those hundred-fifty words with “I updated some libraries.” Oh, well, at least people looking for the error have more direct advice than I got…

Next

Boring CSS seems like the shiniest thing in front of my face, at the moment, so it’ll probably get the most attention. I’d like to have at least have a few interesting color palettes and one design language implemented, before I move on.

Credits: The header image is Shinran Shonin by an unknown thirteenth century artist, long in the public domain.