zerosleeps

This blog post from the GOV.UK Design System team has been doing the rounds this week. I’ve been aware of this department of the UK government for a while, but having read through some of their well researched and reasoned recommendations I must say I’m a big fan of their work.

The industry I work in - Australian education - sorely needs to wake up to a lot of this. Unfortunately education providers are required to collect a lot of questionable data for statutory reporting purposes, and often in a very rigid format. It’s a system which was designed about 30 years ago by people who had no idea that not everyone has a name, and not every address has 4 lines and a postcode, to name but a couple of my irritations.

Here are a couple of my favourites from the GOV.UK Design System team.

Gender or sex:

You should only ask users about gender or sex if you genuinely cannot provide your service without this information.

Compare this with the latest requirements from the Australian Government, which doesn’t even provide “declined to answer” or “we don’t ask our students for this data” option.

Passwords:

Overly strict or confusing constraints can make it harder for people to create memorable passwords.

And:

You should only force a password change if you suspect an account may be compromised.

Names:

Use single or multiple fields depending on your user’s needs. Not everyone’s name fits the first-name, last-name format. Using multiple name fields mean there’s more risk that a person’s name will not fit the format you’ve chosen and that it is entered incorrectly.

You’d think this would all be common sense, no?

Patrick Smith at askthepilot.com on MH370:

Consider this: We’ve all watched airplanes high in the sky. A plane flying 12,000 feet above you (that’s the average depth of the Indian Ocean) appears as just the smallest gray speck, its profile visible but indistinct. Now, imagine you’re looking down at that same plane. Except, you’re looking down not through clear sky, but through 12,000 feet of murky seawater. Indeed, for most of that depth you’re staring into aphotic blackness. And the airplane you’re looking for is, in all likelihood, no longer in the shape of an airplane; it’s in thousands of fragments scattered across miles of rugged seabed.

Reading log summary for 2021: 30 books completed, down on 39 from 2020. I abandoned an additional four.

4×2-stars, 11×3-stars, and 9×4-stars.

Six 5-stars, but spread across just four books as I read Andy Weir’s “The Martian” and “Project Hail Mary” twice in 2021.

Well I’ve done it. I’ve converted my personal financial transactions to Beancount plain-text accounting format.

Before I dumped my old MacBook I exported everything from Banktivity to a QIF file. Boy what a pain that file format is to work with. I tried parsing it using Python a few different times, but I eventually resorted to just using Sublime Text and some regular expressions. It’s one of those one-off tasks so there was no point sweating over anything more robust or reusable.

Interestingly, during about my 3rd attempt at scripting the conversion, I installed a trial version of the latest release of Banktivity to see if maybe chucking money at the problem was in fact the best solution. First thing it asked for? The credentials for an online Banktivity account. I couldn’t see any way around the creation of an online account, so that made my easy decision every easier. You blew it, IGG Software.

I made an aside about my dislike of autoloading in Rails a few weeks ago. As is almost always the case, other folk are far more eloquent at explaining these things than I am, so here’s a person called Eric Bower on the matter:

Since there are no import statements at the top of the file, it was a guessing game to figure out where source code was located. Is SomeClass a class we created in one of our repos? Is it a third-party class? I have no clue just by looking at how the class is being used.