</th>	Episode</th>	Title</th>	Rating</th></tr></thead>
1</td>	S05 E06</td>	Back to Reality</a></td>	9.2</td></tr>
2</td>	S05 E04</td>	Quarantine</a></td>	8.9</td></tr>
3</td>	S03 E03</td>	Polymorph</a></td>	8.8</td></tr>
4</td>	S02 E05</td>	Queeg</a></td>	8.7</td></tr>
-</td>	S06 E02</td>	Legion</a></td>	8.7</td></tr>
6</td>	S04 E05</td>	Dimension Jump</a></td>	8.6</td></tr>
-</td>	S06 E03</td>	Gunmen of the Apocalypse</a></td>	8.6</td></tr>
8</td>	S03 E01</td>	Backwards</a></td>	8.5</td></tr>
-</td>	S04 E03</td>	Justice</a></td>	8.5</td></tr>
10</td>	S02 E02</td>	Better than Life</a></td>	8.4</td></tr>
-</td>	S03 E02</td>	Marooned</a></td>	8.4</td></tr>
-</td>	S04 E04</td>	White Hole</a></td>	8.4</td></tr>
-</td>	S12 E06</td>	Skipper</a></td>	8.4</td></tr> </tbody></table> ^{1</sup> The Roman numerals aren’t my affectation, they’ve long been used to number Red Dwarf series.</p> </div> ^{2</sup> This is the first visualisation I’ve published here using Observable Plot</a>, a JavaScript library for visualising tabular data. Usually I make my charts in R and ggplot2</a>, but this time I thought I’d try something different. Both have their pros and cons, but I think Observable Plot is more suitable to this kind of one-off Web-based vector visualisation.</p> </div> ^{3</sup> The ratings were collected on the 30th of August 2023. Who knows how they’ve changed since. I mean, you can’t predict the future, can you? Can you, Cassandra?</p> </div>} How to use JSDoc to add type contraints to generic function arguments 2023-03-23T00:00:00+00:00 The other day, while working on a Typescript/Javascript codebase, I found myself writing a function that took a single argument. That argument might be one of two types, and the function would return an array of the same type. For example, if the function was passed a string, it would return an array of strings. But if the function was passed a number, it would return an array of numbers. I had most of the function written; all that was missing was the type information.</p> Adding the necessary types would have been no problem in Typescript, where a sprinkling of generics</a> would provide the information needed. If we name the function foo</code> and simplify the code it contained, we end up with something like this:</p> type</span> Result</span><</span>T</span>></span></span> =</span> T</span> extends</span> string</span> ?</span> string</span>[</span>]</span></span> :</span> number</span>[</span>]</span></span></span>;</span> </span> </span>function</span> foo</span></span><</span>T</span> extends</span> string</span> \|</span> number</span>></span></span>(</span>bar</span>:</span> T</span></span>)</span></span>:</span> Result</span><</span></span>T</span></span>></span></span> </span>{</span> </span></span></span> if</span> (</span>typeof</span> bar</span> ===</span> "</span>string"</span></span>)</span> {</span> </span></span></span></span> return</span> [</span>"</span>a"</span></span>,</span> "</span>b"</span></span>]</span></span> as</span> Result</span><</span></span>T</span></span>></span></span>;</span> </span></span></span></span> }</span></span> else</span> {</span> </span></span></span></span> return</span> [</span>1</span>,</span> 2</span>]</span></span> as</span> Result</span><</span></span>T</span></span>></span></span>;</span> </span></span></span></span> }</span></span> </span></span></span>}</span></span></span> </span></code></pre> With this code, when I pass a string Typescript would know the result is guaranteed to be an array of strings. And when I pass a number, Typescript would know the result would be an array of numbers.</p> const</span> result1</span></span> </span>=</span> foo</span></span>(</span>"</span>Hello!"</span></span>)</span></span>;</span> //</span></span> result1 is a string[]</span> </span>const</span> result2</span></span> </span>=</span> foo</span></span>(</span>1</span>)</span></span>;</span> //</span></span> result2 is a number[]</span> </span></code></pre> The problem I had was that the function was in a Javascript</em> file, not a Typescript</em> file, and so I needed to type the function using Typescript’s flavour of JSDoc</a>. While this syntax has a lot in common with Typescript, it’s all added above the function in a comment rather than being inline. How exactly should I structure that comment?</p> I completely failed to find the answer online and instead worked it out by trial and error. Delightfully, the answer ended up being more succinct than the Typescript version:</p> /*</span> </span></span> @</span>template</span> {string \| number} T </span></span> * </span></span> * @</span>param</span> {</span></span>T</span>}</span></span> bar</span> </span></span> * @</span>returns</span> {</span></span>T extends string ? string[] : number[]</span>}</span></span> </span></span> */</span></span> </span>function</span> foo</span></span>(</span>bar</span>)</span></span> {</span> </span></span></span> if</span> (</span>typeof</span> bar</span> ===</span> "</span>string"</span></span>)</span> {</span> </span></span></span></span> return</span> [</span>"</span>a"</span></span>,</span> "</span>b"</span></span>]</span></span>;</span> </span></span></span></span> }</span></span> else</span> {</span> </span></span></span></span> return</span> [</span>1</span>,</span> 2</span>]</span></span>;</span> </span></span></span></span> }</span></span> </span></span></span>}</span></span></span> </span></code></pre> The constraint on the Typescript function — <T extends string \| number></code> — was replaced by using a @template</code></a> tag, the bar</code> argument was typed using @param</code></a>, and the return type was just declared directly rather than needing to use a defined type. That in turn removed the need to coerce the return values (return ... as Result<T></code>). All in all, quite an elegant solution.</p> How to search a GitHub repo using regular expressions or case-sensitive matching 2023-03-18T00:00:00+00:00 Here’s a little hack I’ve discovered. You’ll need to be logged in to GitHub for this to work, but it’s possible to search a repo using case-sensitive string matching — or even a regular expression — from GitHub’s website.</p> Here’s a hypothetical (and slightly contrived) example: let’s say you’re browsing through a repo online at https://github.com/example/foo</code>. There’s a class called Bar</code>, and somewhere in the repo an array of Bar</code> is instantiated. You can’t remember if that array is called bar</code> or bars</code>. The Bar</code> class is used throughout the code so there are a lot of results if you simply search for ‘bar’. You need case-sensitive regex search, but GitHub’s search doesn’t support that.</p> What you can do, though, is press .</code> (aka full-stop or period) while https://github.com/example/foo</code> is open in your browser. If you’re logged in this will actually open https://github.dev/example/foo</code> — that is, github.dev</code> not github.com</code> — and set up Visual Studio Code in your browser. Once that’s ready you can open up VS Code’s search sidebar</a>, turn on case-sensitive matching and regexes, and type bars?</code> into the search box. And voilà</em>, only code that matches bar</code> or bars</code> (in lowercase) will appear in the results.</p> Update, 20th September 2023</h3> A few months after I posted this, in May 2023, GitHub updated their code search</a> so you can search using a regex directly on github.com. Here’s the brief documentation</a>. So there’s no need for this hack any more — using the example above you can simply search your repo for /bars?/</code>.</p> One glitch in their current implementation is that regexes are only</em> supported in the code search, so you’ll get zero matching results for issues, PRs, wiki pages, etc.</p>}}

Flother

How to get quick access to dictionary definitions using Spotlight on MacOS

2025-08-26T00:00:00+00:00

It’s 2014 and I want to check the spelling of a word. I’m on my MacBook, so I can simply hit Command</kbd>-Space</kbd> and search for the word with Spotlight. Because I’ve configured dictionary definitions to appear at the top of Spotlight results (using the UI shown here</a>), the word appears right at the top of the list. I love computers!

It’s 2015 and Apple have released El Capitan (aka OS X 10.11). I want to check the spelling of a word. I’m on my MacBook, so I hit Command</kbd>-Space</kbd> and search for the word with Spotlight. Unfortunately, I’m no longer allowed to configure the order of Spotlight search results, so instead I scroll through results for web pages, documents, photos, emails, system preferences, and more, before finally finding the dictionary definition. I hate computers!

It’s 2025 and I’m still annoyed that Apple won’t let me put dictionary definitions at the top of Spotlight search results anymore. It’s been a decade and I miss it every day. Finally, 3,650 days later, I looked for a solution.

And found one! It’s not quite as simple as it used to be, but there are a couple of keyboard shortcuts that make Spotlight search results marginally less frustrating:

Command</kbd>-L</kbd>: Jump straight to the dictionary definition in the results list</li>

Command</kbd>-D</kbd>: Launch the Dictionary app with the definition open immediately</li> </ul>
Apple maintains documentation on Spotlight keyboard shortcuts on Mac</a> but, naturally, neither of these shortcuts are listed there. They are listed in an answer to this SuperUser thread</a>, and the source for that, a Reddit post</a> by a now-deleted user, lists another undocumented shortcut: Command</kbd>-B</kbd> to search for the term in your browser. There’s at least one other longstanding undocumented shortcut too: Command</kbd>-I</kbd> to show the Get Info dialogue for files and folders (I discovered this in this OSXDaily post from 2012</a>).
The broader issue here is symptomatic of modern Apple: removing power-user features in favour of what they think most people want, then hiding the remaining functionality behind undocumented keyboard shortcuts. But at least I can get fast access to dictionary definitions. For now.

PS. The SuperUser thread also mentions a solution to reorder Spotlight results by editing a .plist</code> file. I tried this but couldn’t get it to work. So keyboard shortcuts it is.

How to automatically format acronyms according to The Economist’s style guide in Typst 2025-05-29T00:00:00+00:00 I love Typst</a>. It’s a markup-based typesetting system that has the readability of Markdown with the power of LaTeX. I enjoy writing in it, and its PDF output is excellent. For my academic writing, Typst has replaced a homemade system of Markdown, Pandoc, and LaTeX that always felt clunky and brittle. When I’m writing in Typst I try to follow The Economist’s style guide. It’s a well-regarded set of rules that can help produce readable prose in a formal style. One thing the style guide insists on, for example, is for acronyms to be typeset in small caps — so HTML becomes ʜᴛᴍʟ and NATO becomes ɴᴀᴛᴏ. This creates a more refined appearance on the page, preventing acronyms from appearing prominent in body text. However, there are two important exceptions: chemical formulae like H_{2O shouldn’t use small caps (probably because chemical notation is a precise symbolic language), and acronyms in headings should remain in full capitals (probably to maintain proper hierarchy, but also because it looks odd).} The challenge was implementing these rules in Typst without littering documents with #smallcaps</code> function calls everywhere. Nobody wants to write #smallcaps[HTML]</code> repeatedly throughout a document — it makes a document hard to write and its source hard to read. The solution involves using Typst’s state management</a> and show rules</a> to create an automatic formatting system. A boolean state called acOK</code> tracks whether acronyms should be converted to small caps. By default, it’s enabled, but it gets temporarily disabled within headings and can be manually disabled using a noac()</code> wrapper function for chemical formulae. The magic happens with a regex pattern that matches words made up of a capital letter followed by one or more capital letters and digits (\b[A-Z][A-Z\d]+\b</code>). When this pattern is found in a document, Typst checks the current state and either applies small caps formatting or leaves the text unchanged. #let acOK = state("acOK", true) #let noac(content) = { acOK.update(false) content acOK.update(true) } #show heading: it => { acOK.update(false) it acOK.update(true) } #show regex("\b[A-Z][A-Z\d]+\b"): acronym => context [#if acOK.get() {smallcaps(acronym, all: true)} else {acronym}] </code></pre> This combination of Typst features lets me write clean, readable documents while automatically applying The Economist’s style rules — I can focus on writing rather than formatting. Acronyms in body text are typeset in small caps, headings remain unaffected, and chemical formulae can be wrapped in noac()</code> when needed. It’s a perfect example of the power of the Typst language: beautiful output from readable sources. Example</h3> Here’s a complete example document: #set page(paper: "a6") #let acOK = state("acOK", true) #show " — ": [\u{202F}#sym.dash.em\u{202F}] #let noac(content) = { acOK.update(false) content acOK.update(true) } #show heading: it => { acOK.update(false) it acOK.update(true) } #show regex("\b[A-Z\d]{2,}\b"): acronym => context [#if acOK.get() {smallcaps(acronym, all: true)} else {acronym}] = What is HTML? HTML is one of the three basic building block of all web pages, the others being CSS and JavaScript. On an analogue clock, the number 4 is often written as #noac("IIII") rather than #noac("IV"). </code></pre> And its output: </figure> How to customise the styling of em-dashes in Typst 2025-03-01T00:00:00+00:00 Typst</a> is a modern, markup-based typesetting system designed as a successor to LaTeX. If you need to produce PDFs — particularly for academic or technical writing — then it’s an invaluable tool. Writing in Typst is much like writing in Markdown: you write primarily in plain-text, adding lightweight markup only when you need it — _italics_, *bold text*, that sort of thing. It stays out of your way when you just want to write. I am, however, quite particular about formatting. Take em-dashes, for example. I prefer them flanked by narrow non-breaking spaces. Narrow, so they don’t butt up directly against surrounding words, yet aren’t surrounded by oceans of whitespace. Non-breaking, so they don’t end up orphaned at the end of a line. The problem? Typing this needs markup, which takes me out of the flow of writing. To produce the following sentence: The food — which was delicious — reminded me of Morocco </blockquote> I’d need to write each em-dash as: \u{202F}#sym.dash.em\u{202F} </code></pre> Which is unreadable, tedious, and prone to mistakes. What I really want is to write it in a way that allows me to keep typing without thinking about typesetting. Typst has a shortcut for an em-dash (three hyphens, ---</code>). I want to type that but get my surrounding narrow-width non-breaking spaces too. I want to type this: The food --- which was delicious --- reminded me of Morocco </code></pre> And have it render as: The food\u{202F}#sym.dash.em\u{202F}which was delicious\u{202F}#sym.dash.em\u{202F}reminded me of Morocco </code></pre> Yesterday, I had a eureka moment: I realised I can use Typst’s show rules</a> to do exactly that. Below is a show rule with a text selector, " — "</code> (space, em-dash, space), that replaces that text with an em-dash surrounded by narrow non-breaking spaces: #show " — ": [\u{202F}#sym.dash.em\u{202F}] </code></pre> The trick is that the text selector, " — "</code>, should match the rendered text (an em-dash character) and not the written text (---</code>). Typst’s show rules are incredibly powerful. With show regex("...")</code> I should also be able to render acronyms and initialisms in small-caps without having to wrap each instance in smallcaps()</code>. That’s next on my to-do list. [Edit: done!</a>] How Leicester City failed to reach 100 points 2024-06-05T00:00:00+00:00 It was a season of emotional highs and baffling lows for Leicester City Football Club. From the heartbreak of Premier League relegation to the euphoria of clinching the Championship title, the Foxes’ 2023/24 campaign had it all. While their charge for the title seemed destined to break records, an unexpected slump dashed those dreams, leaving them nine points shy of the all-time Championship high. As Leicester City fans celebrate promotion and a fresh managerial search begins, let’s explore how close — and how far — they came to making history. At one stage, it appeared Leicester City would march effortlessly to the title</a>, poised to shatter the points record in the process. But a poor run of form saw them finish with 97 points, far short of Reading’s 2005/06 record of 106 points. Five teams have won the Championship1</a> with more than 100 points: record-holders Reading, Sunderland in 1998/99 (105 pts), Newcastle United in 2009/10 (102 pts), Leicester City themselves in 2013/14 (102 pts), and Fulham in 2000/01 (101 pts). Comparing this season’s Foxes to these teams, it becomes clear where Leicester fell short. [You’ll need to enable JavaScript to view this data visualisation.] </div> Leicester City were neck-and-neck with Reading for the first two-thirds of the season. But things started to go wrong on matchday 33, when they hit a rough patch, losing four of their next six games. In their final 14 games they managed just 19 points — a meagre 1.36 points per game. In contrast, Reading maintained an average of 1.93 points per game. Although they won the league, the Foxes’ season fizzled out, culminating in the departure of manager Enzo Maresca</a> after just twelve months, as he took the job at Chelsea (lol</a>). In fact, if we look at how many points Leicester City won per game, using a five-game rolling average, we can see they had more than one dip along the way. [You’ll need to enable JavaScript to view this data visualisation.] </div> Title-winning form was 2.1 points per game (equal to 97 points over 46 games). Using the five-game rolling average, Leicester droped below this level three times, in October, December, and February. Playoff form was 1.6 points per game (equal to sixth-placed Norwich’s 73 points), and Leicester dropped below this level in November and February. Worst of all, Leicester even fell into relegation form (1.1 points per game, equal to 22nd-placed Birmingham City’s 50 points) in March. They eventually recovered, but it was too late to break the 100-point barrier. Despite all that, City finish champions and will be back in the Premier League next season. Yes, alright, so the search is on for a new manager, and a points deduction is likely, but the promised land of the Premier League awaits. Roll on 2024/25. ^{1 I’m using ‘Championship’ as shorthand for the second tier of English football that’s existed since the 1992/93 season. Since then it’s consistently had 24 teams and a win has counted for three points. (Honestly, the English football divisions have nonsense names only a marketing guru could love. The top tier is the Premier League, below that is the Championship, and then comes the third tier known, inexplicably, as League One.) </div>} Election fever in Iceland: a presidential race too close to call 2024-05-24T00:00:00+00:00 On 1 June Icelanders will go to the polls to elect their next president. The contest feels fresh but familiar at the same time: while the incumbent, Guðni Th, said in January he wouldn’t stand for a third term, most of the candidates are household names. Katrín Jakobsdóttir was, until a few weeks ago, prime minister; Jón Gnarr is a former mayor of Reykjavik; Ástþór Magnússon is attempting to take office at the fifth attempt. Several polling companies are tracking the contest: Maskína, Prósent, and Gallup are releasing opinion polls roughly once a week. But while they may know how to conduct a poll, the pollsters (and journalists) are generally poor at presenting the data. Some examples: obnoxious animations</a>, a lack of interest in communicating standard error</a>, unreadable charts</a>, terrible x-axes</a>, throwing too much information in</a>, and only showing the latest data</a>. That was all the excuse I needed to track the contest myself. My goals were to use all the polling data to visualise the trends over time, and to understand how close the race really is. </figure> Baldur was the early favourite, commanding 35% support in late March, but his support steadily declined once other candidates entered the fray. Halla Hrund, initially polling in the single digits, surged to 30% in early May, but has faded since. Halla T, who began May with just 5% support, has seen her numbers quadruple and has jumped into second place. Katrín, meanwhile, has seen a drop in her support overall but looks to be the frontrunner in a close race. The semi-transparent areas around the chart’s lines show how uncertain we are about the data. The central line confidently states that Katrín is at 25%, but the area around it shows us that really — given the spread and sparsity of the polling data — she could be as high as 32% or as low as 17%. That’s the difference between winning and being an also-ran. In order to see how close the race is right now, we should take a look at the latest polling averages. </figure> It’s fair to say Katrín has a substantial lead. But the range of uncertainty around her support should give her pause for concern. Halla T, Baldur, and Halla Hrund are virtually neck-and-neck, and all close enough to Katrín to make this a four-way race. With just a week to go then, the only prediction I would make it that the outcome is unpredictable. It may all come down to Halla T’s recent surge in support. Can she catch Katrín? We’ll find out in a few short days. Update, 31 May 2024</h3> The charts above are a snapshot of the race as it was on 24 May, but of course polls have continued to be published since. Here are updated charts with the latest polling data on the eve of the election. The race has got even tighter! It’s a three-way race now: Halla T has just pipped Katrín to first place, but it’s neck-and-neck. Halla Hrund is still just about keeping up with them. </figure> </figure> Update, 4 June 2024</h3> Well, the results are in and it was a resounding win for Halla Tómasdóttir. She collected over 34% of the vote — nine percentage points ahead of second place — and she surpassed the expectations of opinion polls, even those published closest to the vote. Alastair Campbell</a> likes to call opinion polls ‘the junk food of journalism’, but I think they had a spectacular and direct effect on this election. Halla T won this election in large part because of the opinion polls. People love to back a winner, and on top of that there was a substantial group that didn’t want Katrín to be president</a>. That meant that when the polls showed Halla T to be on an upward trend and the candidate best-placed to beat Katrín, people decided to back her instead of their preferred candidate (largely, by the looks of things, Halla Hrund and Baldur). I don’t think Halla T’s surge would have been possible without the opinion polls. So, although they got it wrong, I think the opinion polls were decisive in this election. </figure> How to use DuckDB’s ST_Read function to read and convert zipped shapefiles 2024-04-04T00:00:00+00:00 DuckDB</a> is a (relatively) new RDBMS designed for in-process analytical queries, but really it’s useful for all kinds of things. As a database it’s most similar to SQLite, but DuckDB’s killer feature for me is that it comes with a spatial extension</a>. That makes it really approachable for geospatial data processing — think PostgreSQL + PostGIS but without the hassle of running a server. DuckDB’s spatial extension provides an ST_Read</code> function</a> that lets you read spatial data from various file formats as if they were database tables. All that’s need to query a GeoJSON file named source.geojson</code> is: INSTALL spatial; -- You only need to install it once. LOAD spatial; -- But you need to load it each session. SELECT * FROM ST_Read('source.geojson'); </code></pre> Under the hood, ST_Read</code> uses GDAL</a>, which means DuckDB supports a huge number of vector file formats</a>. It also means that DuckDB supports GDAL’s more esoteric features, such as virtual file systems</a>. The /vsizip/</code></a> prefix, for example, lets you SELECT</code> from a file within a ZIP file, decompressing it on-the-fly. Shapefiles are often distributed as ZIP files (because a ‘shapefile’ is usually several files), and it can be annoying to need two steps to get to the file. But using /vsizip/</code> lets you query geospatial data directly from a ZIP file. Here’s how you could query a shapefile named bar.shp</code> within a ZIP file named foo.zip</code>, removing any features that don’t cover a point in Australia: SELECT * FROM ST_Read('/vsizip/foo.zip/bar.shp') WHERE ST_Covers(geom, ST_Point(128.28, -21.69)); </code></pre> DuckDB’s spatial extension includes a COPY</code> function</a> to export geospatial tables to different formats. This works on ST_Read</code> virtual tables, which means you can convert a zipped shapefile to, for example, a GeoJSON file in a single query: COPY ⟨ SELECT * FROM ST_Read('/vsizip/foo.zip/bar.shp') ⟩ TO 'some_file.geojson' WITH (FORMAT GDAL, DRIVER 'GeoJSON'); </code></pre> And of course the SELECT</code> sub-query can be as complicated as you need it to be, filtering out data as you go. What audio formats are supported by Raylib? 2023-09-20T00:00:00+00:00 A couple of weeks ago a friend</a> convinced me, without much difficulty as it happens, that making games in Go</a> and Raylib</a> is an enjoyable way to spend your free time. I started off by recreating that stalwart of the 1970s, Pong</a>. Raylib’s documentation is as minimal as it gets. There’s a dense cheatsheet</a> and a suggestion that if you want to learn you should read the code</a>. And so, when I wanted to add some sound to the game, these were the first places I went to find out which audio formats are supported. The cheatsheet wasn’t much use: it simply tells you that you can load sound from a file using LoadSound</code>, or load wave data from LoadSoundFromWave</code>. So off to GitHub I went. From there it was pretty easy to discover what’s available. In src/config.h</code> there are some configuration flags</a> that hint at the supported audio formats: Waveform Audio File Format</a> (.wav</code>)</li> Ogg Vorbis</a> (.ogg</code>)</li> MP3</a></li> Quite OK Audio</a> (.qoa</code>)</li> XM</a> (.xm</code>)</li> MOD music</a> (.mod</code>)</li> Free Lossless Audio Codec</a> (FLAC, .flac</code>)</li> </ul> Raylib supports the first six by default, but support for FLAC isn’t included unless you compile it in yourself. If you want it, you’ll need a customised build with the SUPPORT_FILEFORMAT_FLAC</code> flag turned on. Try to play a FLAC file without it and Raylib will log an error: WARNING: WAVE: Data format not supported </code></pre> Of course, after all that I discovered that this is briefly documented in the FAQ</a> and in the raudio</code> module README</a>. Today I learnt that if someone promises minimal documentation, you shouldn’t take their word for it. When was Red Dwarf at its best? 2023-08-31T00:00:00+00:00 The cult BBC sitcom Red Dwarf</a> played a large part in my teenage years. I watched every episode over and over on VHS, quoted the best lines, read the books. But the long gap between series VI (1993) and series VII (1997) meant that eventually I ended up moving on to other obsessions. Recently I discovered that, although I gave up on it after series VI, they carried on and made a lot more episodes. All the way up to series XIII1</a> in fact. Turns out I’ve only seen around half of Red Dwarf, which was all the excuse I needed to a) wallow in nostalgia and watch the old episodes, and b) catch up with the new. The first six series were as good as I remembered: dated, but still good fun. The seventh series seemed like a stark drop in quality though. And that made me wonder, was it just the nostalgia that made the early episodes the best? Did everyone feel the same as me? Would it get better after the series VII lull? Time to make some data viz2</a>, lickety-split. [You’ll need to enable JavaScript to view this data visualisation.]</div> IMDb</a> has crowd-sourced ratings for each episode. In the chart above you can see the ratings grouped by series, along with the mean average rating for each series and Red Dwarf as a whole3</a>. It seems the users of IMDb agree with me: the ratings suggest that after finding its feet in series I, Red Dwarf hits its long and consistent peak in series II-VI. Series VII sees the start of a decline that hits its nadir in ‘Back to Earth’ (aka series IX). After that series X regains some of the show’s mojo, and then fades slightly over time — although not before hitting the high of series XII episode 6, ‘Skipper’, IMDb’s joint-tenth favourite episode. And the highest rated episode? That would be series V’s ‘Back to Reality’ from 1992 (although personally I have a soft spot for series I’s ‘Me²’, which really lays bare Rimmer’s self-hatred). So it seems that the crowd-sourced story is that Red Dwarf was indeed at its peak in the late 80s and early 90s and, apart from the odd episode here and there, hasn’t reached that high again. But then perhaps we’re all just sentimental and longing for days past, our memories muddied by nostalgia. I haven’t yet watched any of series IX–XIII, so I’ll try and keep an open mind. Top ten episodes of Red Dwarf (according to IMDb)</h2> </th> Episode</th> Title</th> Rating</th></tr></thead> 1</td> S05 E06</td> Back to Reality</a></td> 9.2</td></tr> 2</td> S05 E04</td> Quarantine</a></td> 8.9</td></tr> 3</td> S03 E03</td> Polymorph</a></td> 8.8</td></tr> 4</td> S02 E05</td> Queeg</a></td> 8.7</td></tr> -</td> S06 E02</td> Legion</a></td> 8.7</td></tr> 6</td> S04 E05</td> Dimension Jump</a></td> 8.6</td></tr> -</td> S06 E03</td> Gunmen of the Apocalypse</a></td> 8.6</td></tr> 8</td> S03 E01</td> Backwards</a></td> 8.5</td></tr> -</td> S04 E03</td> Justice</a></td> 8.5</td></tr> 10</td> S02 E02</td> Better than Life</a></td> 8.4</td></tr> -</td> S03 E02</td> Marooned</a></td> 8.4</td></tr> -</td> S04 E04</td> White Hole</a></td> 8.4</td></tr> -</td> S12 E06</td> Skipper</a></td> 8.4</td></tr> </tbody></table> ^{1 The Roman numerals aren’t my affectation, they’ve long been used to number Red Dwarf series. </div> ^{2 This is the first visualisation I’ve published here using Observable Plot</a>, a JavaScript library for visualising tabular data. Usually I make my charts in R and ggplot2</a>, but this time I thought I’d try something different. Both have their pros and cons, but I think Observable Plot is more suitable to this kind of one-off Web-based vector visualisation. </div> ^{3 The ratings were collected on the 30th of August 2023. Who knows how they’ve changed since. I mean, you can’t predict the future, can you? Can you, Cassandra? </div>} How to use JSDoc to add type contraints to generic function arguments 2023-03-23T00:00:00+00:00 The other day, while working on a Typescript/Javascript codebase, I found myself writing a function that took a single argument. That argument might be one of two types, and the function would return an array of the same type. For example, if the function was passed a string, it would return an array of strings. But if the function was passed a number, it would return an array of numbers. I had most of the function written; all that was missing was the type information. Adding the necessary types would have been no problem in Typescript, where a sprinkling of generics</a> would provide the information needed. If we name the function foo</code> and simplify the code it contained, we end up with something like this: type Result<T> = T extends string ? string[] : number[]; function foo<T extends string | number>(bar: T): Result<T> { if (typeof bar === "string") { return ["a", "b"] as Result<T>; } else { return [1, 2] as Result<T>; } } </code></pre> With this code, when I pass a string Typescript would know the result is guaranteed to be an array of strings. And when I pass a number, Typescript would know the result would be an array of numbers. const result1 = foo("Hello!"); // result1 is a string[] const result2 = foo(1); // result2 is a number[] </code></pre> The problem I had was that the function was in a Javascript file, not a Typescript file, and so I needed to type the function using Typescript’s flavour of JSDoc</a>. While this syntax has a lot in common with Typescript, it’s all added above the function in a comment rather than being inline. How exactly should I structure that comment? I completely failed to find the answer online and instead worked it out by trial and error. Delightfully, the answer ended up being more succinct than the Typescript version: /** * @template {string | number} T * * @param {T} bar * @returns {T extends string ? string[] : number[]} */ function foo(bar) { if (typeof bar === "string") { return ["a", "b"]; } else { return [1, 2]; } } </code></pre> The constraint on the Typescript function — <T extends string | number></code> — was replaced by using a @template</code></a> tag, the bar</code> argument was typed using @param</code></a>, and the return type was just declared directly rather than needing to use a defined type. That in turn removed the need to coerce the return values (return ... as Result<T></code>). All in all, quite an elegant solution. How to search a GitHub repo using regular expressions or case-sensitive matching 2023-03-18T00:00:00+00:00 Here’s a little hack I’ve discovered. You’ll need to be logged in to GitHub for this to work, but it’s possible to search a repo using case-sensitive string matching — or even a regular expression — from GitHub’s website. Here’s a hypothetical (and slightly contrived) example: let’s say you’re browsing through a repo online at https://github.com/example/foo</code>. There’s a class called Bar</code>, and somewhere in the repo an array of Bar</code> is instantiated. You can’t remember if that array is called bar</code> or bars</code>. The Bar</code> class is used throughout the code so there are a lot of results if you simply search for ‘bar’. You need case-sensitive regex search, but GitHub’s search doesn’t support that. What you can do, though, is press .</code> (aka full-stop or period) while https://github.com/example/foo</code> is open in your browser. If you’re logged in this will actually open https://github.dev/example/foo</code> — that is, github.dev</code> not github.com</code> — and set up Visual Studio Code in your browser. Once that’s ready you can open up VS Code’s search sidebar</a>, turn on case-sensitive matching and regexes, and type bars?</code> into the search box. And voilà, only code that matches bar</code> or bars</code> (in lowercase) will appear in the results. Update, 20th September 2023</h3> A few months after I posted this, in May 2023, GitHub updated their code search</a> so you can search using a regex directly on github.com. Here’s the brief documentation</a>. So there’s no need for this hack any more — using the example above you can simply search your repo for /bars?/</code>. One glitch in their current implementation is that regexes are only supported in the code search, so you’ll get zero matching results for issues, PRs, wiki pages, etc.}}

Flother

How to get quick access to dictionary definitions using Spotlight on MacOS

How to automatically format acronyms according to The Economist’s style guide in Typst

How to customise the styling of em-dashes in Typst

How Leicester City failed to reach 100 points

Election fever in Iceland: a presidential race too close to call

Update, 4 June 2024</h3> Well, the results are in and it was a resounding win for Halla Tómasdóttir. She collected over 34% of the vote — nine percentage points ahead of second place — and she surpassed the expectations of opinion polls, even those published closest to the vote.</p>

How to use DuckDB’s ST_Read function to read and convert zipped shapefiles

What audio formats are supported by Raylib?

When was Red Dwarf at its best?

How to use JSDoc to add type contraints to generic function arguments

How to search a GitHub repo using regular expressions or case-sensitive matching