zerosleeps

Did you notice that the code block in my last post doesn’t have syntax highlighting (here’s what the code block should look like)? Yeah, true to form I haven’t done anything about replacing or upgrading the generator used to create this site.

My Ruby 2.6.9 (de-supported for well over a year now) installation broke and I can’t build it on my arm64 Mac any more. The smallest possible upgrade I could make to get back into supported-Ruby-land was to version 2.7.7. Octopress was able to generate pages on that version, albeit with a tonne of deprecation warnings.

But Pygments 0.6 - which is used to add the code highlighting - refuses to play nicely with Ruby 2.7.7. That version of Pygments is a dependency of Jekyll 2, and I can’t upgrade Jekyll because Octopress 2 depends on Jekyll 2.

Installing Python 2 might help, but Homebrew doesn’t have a Python 2 formula any more. My code blocks use Python 3 syntax anyway.

This is absolutely on me - I’ve let this thing rot for so long that it doesn’t feel like there’s any way back now 😕

My Python solution for Advent of Code 2022 day 1. About 90% of my time was spent working out how nested list comprehension works - it’s always been one of my downfalls in these things!

import unittest
import utils


def part_one(raw_input):
    return max([sum(elf) for elf in parse_raw_input(raw_input)])


def part_two(raw_input):
    return sum(sorted([sum(elf) for elf in parse_raw_input(raw_input)])[-3:])


def parse_raw_input(raw_input):
    return [
        [int(calories) for calories in elf.splitlines()]
        for elf in [elves for elves in raw_input.split("\n\n")]
    ]


class TestExamples(unittest.TestCase):
    def setUp(self):
        self.raw_input = (
            "1000\n2000\n3000\n\n4000\n\n5000\n6000\n\n7000\n8000\n9000\n\n10000"
        )

    def test_part_one(self):
        self.assertEqual(part_one(self.raw_input), 24000)

    def test_part_two(self):
        self.assertEqual(part_two(self.raw_input), 45000)


if __name__ == "__main__":
    raw_input = utils.get_raw_input_as_str("day_01_input.txt")

    print(f"Part one: {part_one(raw_input)}")
    print(f"Part two: {part_two(raw_input)}")

There’s this road junction here in Melbourne where Montague Street crosses Lorimer Street/Convention Centre Place:

It’s a miracle this junction works at all during peak times (zoom out when viewing it on a map to see the whole terrifying thing) but it mostly does, except for one scenario which I wanted to report to VicRoads. The feedback form I found wants words and there’s no way I could explain the issue without pictures, so here I am describing it in full colour for all to see.

When travelling through the junction northbound on State Route 30/55/Montague Street, and sitting at the lights waiting to cross Lorimer Street, there are five lanes. Traffic in the two right-hand lanes must turn right into Convention Centre Place, and the other three lanes continue on the north side of the junction.

So for traffic passing through the junction it’s three lanes in, three lanes out. Here’s how it should work:

But for some reason this is what actually happens:

I try to position myself in the left lane in preparation for the next turn I usually take, and about 75% of the time I use this junction I end up having to take some sort of action to avoid being sideswiped by cars in the middle lane.

I’ve noticed that if traffic is light and does not have to stop at the lights, everyone goes where they’re supposed to. It’s only when traffic is setting off from a red light that this happens. And of course once the first car in the middle lane takes the wrong path, all the cars behind do the same thing.

I suspect it’s because the middle of the junction is also the middle of the “turn” - the middle of the curve the road is taking - and drivers assume the junction is straight-and-true so take the lane directly in front of them.

Road markings are an obvious solution to a layman like me, but that would presumably cause other problems given the markings already on the road surface.

Anyway, I’ll send my feedback off to the relevant authority. What else can I do?

From the Django 4.1 release notes:

In order to aid users with screen readers, and other assistive technology, new <div> based form templates are available from this release. These provide more accessible navigation than the older templates, and are able to correctly group related controls, such as radio-lists, into fieldsets.

The new templates are recommended, and will become the default form rendering style when outputting a form, like {{ form }} in a template, from Django 5.0.

This is excellent news. Django form rendering has annoyed me for years because of the (subjectively) old-fashioned HTML tags and structures it uses by default. It’s always been close to “just working”, but simultaneously useless because the output is cumbersome to tweak, meaning I end up using my own templates anyway.

Fingers crossed these changes make it easier to stick to the defaults.

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?