A write-up looking at the statistics on why (or why don't) hosts of the Olympics do well based on the athletes participating and medals won.

This post from Candost reflects on traits of a good software engineer. It's very well thought out.

Not sure why I'm surprised but there are many web formats in which to write recipes. There's a microformat, why wouldn't there be? There's another format that Google prefers and Robb takes stab at designing his own.

Alex writes about creating HTML files in folders to browse files in various ways.

This allowed me to radically simplify the folder structure, and stop chasing the perfect hierarchy. In these mini-websites, I use very basic folders – files are either grouped by year or by first letter of their filename. I only look at the folders when I’m adding new files, and never for browsing. When I’m looking for files, I always use the website. The website can use keyword tags to let me find files in multiple ways, and abstract away the details of the underlying folders.

Why HTML?

I’m deliberately going low-scale, low-tech. There’s no web server, no build system, no dependencies, and no JavaScript frameworks. I’m writing everything by hand, which is very manageable for small projects. Each website is a few hundred lines of code at most.

It reminded me of a time when I had to present a project I'd worked on as part of a job interview. I created a number of linked HTML files that walked through various parts of the code. It had the benefit that if a question was asked I could directly open up the relevant file and dive into the code. The interviewers didn't seem impressed but I ended up getting the job, so I guess it worked.

Mark Wagenbuur, from Bicycle Dutch, writes about forever ongoing discussions about building bridges over the IJ, a river that now has seven ferry lines taking passengers back and forth. A quote from the blog:

In the 2015 version, I reported that there were six ferry lines, and now there are seven. The most important one of those, behind Central Station, is the F3 Buiksloterweg ferry. The earliest mention of this ferry dates back to the year 1308, but it is probably much older. Two ships operate on this line during the day, which means a ferry crosses the river every six minutes. During rush hour, a third ferry is added, reducing the waiting time to four minutes. At the busiest times, there is even a fourth ferry in operation.

I was reminded for an incident in January this year when the Metro M52 was closed towards Amsterdam Noord because of a flooding in a tunnel at Sixhavenweg. This was paired with the F3 Buiksloterweg ferries being taken out of service because the platform used to cross when docked had collapsed, the ferries ran to IJplein instead. To make matters works, a number of ferries from the 60 series were taken out of service because of technical problems resulted in cancelling the F9 route between Sporenburg and Zeeburgereiland.

Ruben writes about keeping himself hydrated throughout the day and the ambiguity about how much water is actually required by your body. The thought about tracking water consumption through a database had just entered by mind only to be replaced instantaneously by the simplicity of a spreadsheet. In the very next paragraph Ruben writes:

So I did what every self-respecting computer engineer did: I built a database table to track my water intake! Then realised this was a bit of a pain, and made a spreadsheet instead.

Simon Willison shares his experience serving on the board of the Python Software Foundation over the last two years and some of the responsibilities that entails.

The Python Software Foundation supports the development of Python and the community by allocating their donations towards running infrastructure other activities. However, they are not directly related to developing Python which is handled by the core team ran by the Python Steering Council. Infrastructure includes running PyPi and Python.org and activities most notably include organising PyCon. Simon also mentions an activity I hadn't considered before and that's acting as a fiscal sponsor to other python-related communities.

Simon's write-up is dense with information and definitely worth the read if this is interesting to you. This has also prompted a write-up by Makoto Nozaki on serving on the board of The Perl Foundation.

Dom Corriveau runs his blog of an old Pixel 5, they also mention kaimac.org who I previously read about running their website of an ESP32, and compose.party which was new to be me and is also a website that is run on solar power and off a phone. Lots of interesting links to read through from the blog post along with instructions to replicate.

Discovered via 82MHz' Linkdump.

As annoying as cookie banners are I like seeing them because they give me the choice to deny being tracked but also because I get to see all the vendors a company would have otherwise sold my data too. The longer the list the further I tend to stay away from site unless absolutely necessary. The linked write-up on Bite Code! is a neat summary on why the banners don't have to be as bothersome as they typically are especially because we could have had a standard Do Not Track HTTP header!

There has been for years a proposal for a standard, designed in 2009 (!), still available in all the popular web browsers (except safari) that can make for a seamless experience: the DNT header.

Almost no website have implemented it, because companies WANT to nag you, hopping to trick you into being tracked. They know nobody would click yes on those settings.

So now it's deprecated.

Companies are making your life hard by choice. They got told by the EU they could not be secret abusers anymore, so now they decided to be irritating on top.

I'm not sure any re-org I've been subjected to has led to anything useful but wasted time, confusion and the de-prioritisation of work already done which leads to more wasted time. One aspect of the wasted time comes from the need to explain or maybe even justify the work done by the team having active documentation on the team’s tenants, work and roadmap is one way that helps. Logan's recent blog titled Mean Time To Reorg; Writing as Resilience provides some good examples of this in action.

As a tech lead of a project, these reorgs led to frequent changes in management reporting lines. The twice-annual reporting line change drew my time away from the team and project, and was spent on understanding the positions and intent of the new management structure, and briefing them on the work we did and why it was valuable. [...] Folks new to the project who only did surface level due diligence would misunderstand the details rather than fail to grok them in the first place. When a new hire joins the company there’s an expectation of some number of months before they develop expertise in all of the in-house systems. When there’s a reorg there’s an expectation that the new manager of an area is effective overnight.

I learned that in order to preserve my time for the team and project I needed to improve the speed at which new people (particularly management) onboarded [...] I did this through writing and documentation. We had in-depth docs for users of our product. [...] Over time I learned that essentially writing context and documentation about the roadmap greatly benefited the onboarding of new managers, engineers in the area, and curious customers.

Our car-centric cities and towns rob people of their independence. People who would otherwise be perfectly capable of going out on their own to meet friends, or grocery shop, or go to the library are prevented from doing so because they can’t drive. Maybe they’re too young to drive, as I was at 14; or maybe they’ve gotten old enough that it’s no longer safe for them to drive; or perhaps they have a disability that prevents them from driving. Sometimes people can’t drive simply because they can’t afford a car, because these things are really expensive.

From Evan Sheehan.

John Eldredge, creator of the Winamp Skin Museum, goes about digging in some skins and makes a few interesting discoveries.

Discovered via Tom Scott's Newsletter.

CommonMark is the Markdown specification created by John MacFarlane, Jeff Atwood and others, to encompass the various flavours of Markdown that was adopted by different software over the years. GitHub adopted CommonMark along with it's extension for Markdown called GitHub Flavored Markdown (GFM) sometimes around 2016-2017. I've complained about how different platforms deveate from the standard. This GitHub Engineering post shows how good of a job the CommonMark contributors did to represent common usage of Markdown with only 1% deveating from GitHub's previous Markdown parser.

We [GitHub] actually enabled CommonMark for all new user comments in the website several months ago, with barely anybody noticing — this is a testament to the CommonMark team’s fantastic job at formally specifying the Markdown language in a way that is representative of its real world usage.

All in all, less than 1% of the input documents were modified by the normalization process, matching our [GitHub's] expectations and again proving that the CommonMark spec really represents the real-world usage of the language.

From Matthew Graybosch via People and Blogs

I still have a website on matthewgraybosch.com, but its mainly a substitute for having a LinkedIn account because LinkedIn has always been the Ashley Madison of job hunting, only more cultish. I mean, have you seen the people posting there? Its like the Stepford Wives got equally robotic husbands and they all got corporate jobs.

Yes, yes and a 100 times yes. No social media outlet is more artificial than LinkedIn.

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."— Edsger Dijkstra

Derek Kedziora made a some good comments on Eugene Yans post titled "Simplicity is An Advantage but Sadly Complexity Sells Better".

Removing unnecessary complexity is a thankless job.

By using satellite images from Google in QGIS and marking areas of potentially good Christmas trees then exporting that layer and joining it with the National Forest Motor Vehicle User Map in Wherobots Cloud using Spatial SQL @lyonwj was able to map the areas with accessible roads.

Theres a lot of interesting bits to unpack there, but my main takeaway was the use of spatial SQL, it certainly beats relying on osmium tags-filters and manually editing GeoJSON files.

Stephen Wolfram, mathematician, computer scientists and CEO of Wolfram Research, describes all the incremental improvements made in different parts of his life in the pursuit of productivity. It's an article I've read and come back to three different times now, and with each I've taken some new bits and pieces that I could use myself.

The reasoning behind pull out shelves:

One of my theories of personal organization is that any flat surface represents a potential "stagnation point" that will tend to accumulate piles of stuff—and the best way to avoid such piles is just to avoid having permanent flat surfaces.

Collecting personal analytics of physical and digital text:

I have systems that keep all sorts of data, including every keystroke I type, every step I take and what my computer screen looks like every minute (sadly, the movie of this is very dull). I also have a whole variety of medical and environmental sensors, as well as data from devices and systems that I interact with.

Archival and searchability:

At the top of my personal homepage is a search box. Type in something like "rhinoceros elephant" and I'll immediately find every email I've sent or received in the past 30 years in which that's appeared, as well as every file on my machine, and every paper document in my archives