zerosleeps

Most of the discussion on Hacker News about this article by Eduardo Bellani is about the use of natural keys when designing databases.

I also disagree with the use of natural keys. The real world is messy and it changes all the time, including and especially the things that you’d think would never change. Education (and I’m sure all industries) is obsessed with giving things codes that mean something, and as a result the software I develop against uses natural keys almost exclusively.

It’s a pain in the arse.

This is one of those self-propelling death spiral things. People want codes to mean something because nobody’s ever shown them the alternative: design objects with attributes that describe the object and nobody will give a shit what primary key the database uses. But if the enterprise software you’ve bought doesn’t allow that (and perhaps even encourages some kind of coding convention) then nobody will ever see the alternative which puts us back at the start of the cycle.

I am very excited about this. The opening paragraphs of MDN’s documentation are perfect: they explain the problem, state how JavaScript ended up where it is, and outline the solution before launching in to the details.

Dates and times are hard.

This article about systemd timers made it to the front page of Hacker News today. I always get a little bit upset when I see documentation or advice that talks about defining a cron job, as if cron is the only way of scheduling tasks. Cron served us well, but if you know what cron and systemd are you should read the documentation for systemd timer units.

This:

OnCalendar=Thursday 18:00 Australia/Melbourne

Is so much nicer than:

0 7 * * 4

Now I will conceded that as with most of the components of systemd, the manuals don’t make it very easy to discover all the magical things you can do with unit files, but the few minutes I took several years ago doing just this have saved me way more time since then.

Bonus tips: systemd-analyze calendar is a cute little tool to know about too:

$ systemd-analyze calendar "Thursday 18:00 Australia/Melbourne"
  Original form: Thursday 18:00 Australia/Melbourne
Normalized form: Thu *-*-* 18:00:00 Australia/Melbourne
    Next elapse: Thu 2025-03-20 07:00:00 UTC           
       From now: 6 days left

Plus! systemctl list-timers gives you a nice list of loaded timers with human-readable “last run” and “time to next run”, and systemctl status timername.timer works as you’d expect as well, including a tail of the output of the last run. You get all of that for free because the timers trigger regular systemd units, which in turn means (by default) output gets sent to the systemd journal. It also means you can manually trigger the same unit at any time and know it will behave the same whether run by a timer or not.

Way better than cron. Fight me.

Giles Thomas with some thoughts on writing blog posts they’d wish they’d found.

I try to do this myself, and from a peek at my post history it looks like maybe every third-or-fourth post covers either something I just know I’ll need to refer to in the future and might also be useful to other people, or it’s about some problem that nobody else seems to have written about.

As an example of the former, I have already referred to this post about rebooting an Apple Siri Remote myself about half-a-dozen times since creating it in January. I roll my eyes every time.

And for the latter, well consider this: I don’t track traffic to zerosleeps.com beyond what my web server sends to systemd’s journal, which in turn only keeps those logs for it’s default retention period, but every time I have a look it’s the same 3 posts that show up at the top:

• Dead (but not dead) Ubiquiti UniFi Security Gateway, documenting a problem that presumably lots of people have but is poorly covered elsewhere
• More myki confusion, which doesn’t have much actionable information but obviously resonates with the folk of/visitors to Melbourne
• Sublime Text timestamp snippet, which contains very outdated code and has been superseded by this information

Adrian Holovaty, one of the co-creators of Django:

Every web page on our site is served by Django — in other words, there’s no single-page-app stuff. I’ve always found the idea of single-page apps to be “against the grain”: it goes against how web browsers are optimized, and it goes against how HTTP/HTML were designed.

And:

I think an entire generation of web developers has been misled into assuming JS frameworks are table stakes for building high-quality web apps — and that is 100% wrong.