Primary Unit

RSS Whitespace and Hugo

Sat, 24 Dec 2022 13:09:00 +0000

One thing I noticed about yesterday’s post was that the code formatting in the RSS feed was off. This was due to building the site with Hugo’s --minify option, which “reached into” the <description> item for the post and squished the whitespace without regard to whether it was in a <pre> block.

This was a simple fix: in Hugo’s settings there are a bunch of options for minify, one of which is disableXML. Add that to your config file, rebuild, and you’re done:

[minify]
disableXML = true

Sunrise and Sunset Database

Fri, 23 Dec 2022 20:00:00 +0000

A while ago, I was having trouble with the automatic light-dark theme switching on my laptop, as macOS tries to wait until an opportune moment when the computer is idle to make the change. That’s fair enough, as it does involve a moment when the system is not responsive. I was finding that if I kept working it would often be quite a while after sunset that the switch occurred.

Keyboard Maestro can set the system light-dark theme, so I thought I’d rig it up to periodically check whether sunrise or sunset had occurred, and then force the change rather than being polite. There’s a trade off but overall I prefer the automatic switching to take place closer to the sunrise or sunset time rather than the system waiting in an attempt not to inconvenience me briefly.

It relies on a local SQLite database of sunrise and sunset times for my home, but when I first rigged it up, I “only” put in the times for 2021 and 2022. It’s now time to fill the database for the coming years, so what better time to have a peek at how it works?

You can find the git repository here.

First off, we need a data source. I didn’t include a scraper in repo originally, partly out of politeness, but partly also because I hoped to change the data source.

In the UK, HM Nautical Almanac Office (NAO) publishes various rise, set and twilight times (for other celestial objects as well as the sun). After a few false starts trying to find a big list of daily rise and set times for a long period at a time, you’ll come across the WebSurf 2.0 application, which reassuringly has .cgi in the URL (and, naturally, you would hope is entirely written in Perl).

But after clicking your way through, you’ll end up with a big plain-text listing with no markup (here, snipped horizontally and vertically):

    2023 Sunrise and Sunset times


         January       February

       Rise   Set     Rise   Set
       h  m   h  m    h  m   h  m
  1   08 06  16 02   07 39  16 50
  2   08 06  16 03   07 38  16 51
  3   08 06  16 04   07 36  16 53
  4   08 06  16 05   07 35  16 55
  5   08 06  16 07   07 33  16 57

Now while this is not impossible to deal with, and I of course hear Jerusalem when thinking about the public servants who went through the trouble of making this data available, at the end of the day I am, in the words of the Tories, a shirker rather than a striver. So let’s find an easier way! (Also one that works for people outside Britain.)

Thankfully, ~~whattimeisitrightnow.com~~ timeanddate.com has us covered. Search for your preferred location and go to the “Sun and Moon” ▸ “Sunrise & Sunset” view. You’ll end up with something like timeanddate.com/sun/uk/london.

That will show you the rise and set times for the current month, but if you play with the dropdown above the table, you may notice that picking a different month or year is as simple as adding parameters to the URL, like so:

"https://www.timeanddate.com/sun/uk/london?month=${month}&year=${year}"

Thankfully, too, this data is in the HTML that gets served up, with no JavaScript-dependent front-end framework or scraper-blocker in the way. That leads us naturally onto this simple shell script:

seq 2023 2030 | while read year; do
    seq 1 12 | while read month; do
        curl --silent \
            "https://www.timeanddate.com/sun/uk/london?month=${month}&year=${year}" \
            > "sunrise-${year}-${month}.html"
    done
done

This just dumps each month from 2023 through 2030 into an individual HTML file in the current directory. From there we turn to process_html_tables.py. This is pretty straightforward and broken up into nice small parts, so you can read that at your leisure. It leans on Pandas to parse the HTML tables from the downloaded files and Pendulum to correctly handle dates with timezones, but there’s not much too it. Do check that you’re using the right timezone, though.

Running that Python file will process all the scraped HTML files in the folder, and print an array of JSON objects, each containing a date, sunrise datetime and sunset datetime. This is an intermediate step that isn’t strictly necessary, but you might want that data available in a plain-text file.

But it also means it’s trivial to create a SQLite database file with sqlite-utils:

python3 process_html_tables.py | sqlite-utils insert sunrise-sunset.db london -

That will create the “london” (in this case) table for you, but there’s also an SQL file to create both the table for the sunrise and sunset times and also one to log successful checks (create-tables.sql):

CREATE TABLE london (
    date text primary key,
    sunrise text not null,
    sunset text not null
);
CREATE TABLE successful_checks (
    date text not null references london(date),
    kind text not null,
    primary key (kind, date),
    check (kind in ('sunrise', 'sunset'))
);

This second table exists so that you can have, say, Keyboard Maestro automatically switch between light and dark modes, but also not have it override any manual change you make after that within the check period (for instance, if it’s a cloudy day and you want to keep dark mode on, so you manually re-enable it).

Here’s check-sunrise.sql (check-sunset.sql is similar):

select
    time('now') >= time(sunrise) as "sun has risen"
from
    london
where
    date = date('now')
    and not exists (
        select
            date
        from
            successful_checks
        where
            kind = 'sunrise'
            and date = date('now')
    )
;

Note that it only returns true (well, 1) if there hasn’t already been a successful (ie one causing a change) sunrise check today.

A fair question is: “Why keep checking if you’ve already passed sunrise or sunset?” And the answer is: mostly so I don’t have to worry about the procedure for disabling and enabling the relevant Keyboard Maestro macros. Instead, I can have the macro run at a set interval between the earliest and latest sunrise/sunset times, and be confident it won’t change anything if it’s already run successfully. Here’s the sunrise macro itself:

As a convenience, there’s an SQL script in the repo to find when these times are from the database file.

One other convenience is a LaunchBar action that shows duration between the current time and today’s sunrise and sunset:

You’ll have to create the actual action yourself through LaunchBar’s Action Editor, but the file launchbar-sunrise-sunset.sh can be pasted in to the default shell script in a new action, with of course the database file path and table names adjusted.

Typinator is on sale

Fri, 09 Dec 2022 11:37:57 +0000

Long time! Lots to talk about, some point soon.

In the mean time, Typinator is currently on sale (along with all ergonis software), at 30% off, to celebrate the snazzy new ergonis website.

I’ve much more to say about Typinator, but in short: I was a TextExpander user for a long time, but grew hesitant to use it because it was slow and awkward.

Typinator is not! It’s fast and flexible. I switched in March 2021 and I use it a lot more than I did TextExpander, and creating new snippets is straightforward and pleasant. The snippet search is also really fast and responsive.

The snippet language differs from TextExpander’s, but it’s easy to get used to.

Do give it a try!

Populating the books list with AWK

Thu, 20 Jan 2022 20:40:28 +0000

I read 48 books last year, which is a lot for me. At least part of that, I think, was to keep my mind in gear in a fairly healthy way, when I didn’t feel like engaging with the world (poor mental health — thanks once-in-a-century pandemic!)

What I did not do, though, is keep the list of books up to date, not since spring 2020.

Since I’ve been playing around with AWK a little, and had a big TSV file containing the details for each of the books, I thought I’d pair the two to fill out the missing files.

I use Hugo to generate this site, and each book is represented by a markdown file containing a metadata block with (at least) the title, author’s name, and the date on which I finished reading it. For example:

---
title: "Empire of Pain"
author: "Patrick Radden Keefe"
finish-date: 2022-01-01
---

_Short review to come!_

AWK is great for processing lines of text, but it’s missing some of the library functions you’d like for working with the filesystem. The book files are stored in this directory structure, where the markdown files are under each year folder:

content/books
├── 2019
├── 2020
├── 2021
└── 2022

Those year folders might not exist (did not for 2021 and 2022). I could have just created them by hand, but then we’d miss out on some yak-shaving.

The path to the markdown file is constructed using the book’s title (for the markdown filename itself) and finish date (for the year directory). We can wrap the dirname Unix utility:

1function dirname(path) {
2    cmd = "dirname " path
3    cmd |& getline result
4    close(cmd)
5    return result
6}

The funny |& operator on line 3 executes the command in cmd and then getline stores the first line of the output (there’s just one for dirname) in result. We call close on the command string to release the associated file descriptor.

Let’s wrap our wrapper in a function that just makes sure the directory exists, using mkdir -p, to make our lives easier:

 8function ensure_dir(path) {
 9    system("mkdir -p " dirname(path))  
10}

Now we can think about the filename itself. It doesn’t have to be anything particular, but I like to keep mine really-simple-like-this.md. We’re using the title of the books as the filenames, so the key is just to strip out non-word characters:

12function safe_name(string) {
13    return remove_non_word_characters( remove_apostrophes( tolower( string ) ) )
14}
15
16function remove_apostrophes(string) {
17    return gensub(/['’]/, "", "g", string)
18}
19
20function remove_non_word_characters(string) {
21    return gensub(/\W+/, "-", "g", string)
22}

The remove_apostrophes function is not strictly necessary but ensures titles such as Hitler’s Army don’t become hitler-s-army when they go through remove_non_word_characters.

With that setup done, we can move on to the meat of the file, the lone pattern-action statement:

24/^(2020-(0[6-9]|1[0-2])|202[12])/ {
25    path_template = "content/books/%s/%s.md"
26    year = substr($1, 0, 4)
27    title_for_path = safe_name($2)
28    path = sprintf(path_template, year, title_for_path)
29
30    content_template = ( \
31        "---\n" \
32        "title: \"%s\"\n" \
33        "author: \"%s\"\n" \
34        "finish-date: %s\n" \
35        "---\n" \
36        "\n" \
37        "_Short review to come!_")
38    content = sprintf(content_template, $2, $3, $1)
39
40    ensure_dir(path)
41    print content > path
42}

We match lines that start with dates representing June 2020 (the last update being in May 2020) through 2022. Next, we pull out the year from the date (field 1), and munge the book title (field 2), before formatting them into the path template with the built-in sprintf function.

The content_template is just the markdown you saw earlier in the post, again formatted using sprintf and this time involving the author name (field 3).

We ensure the directory exists for the target markdown file, and just print the formatted template via redirection into the file.

So, would I use AWK over Python for things like this in the future? Maybe. The disadvantage with AWK is that it’s missing built-in tools for working with the system, and the work done above would be easier with, say, Python’s pathlib module. Or, then again, I could have just done mkdir 2021 2022 — but I wanted to get a feel for calling tools from AWK.

I think this tool is perhaps just on the edge where it could go either way. Python has more tools available, but AWK is so focussed on text processing that it does some of that boring work you’d have to do manually in Python.

It was fun, and I look forward to using AWK for more in the future. (I’ve bought the book second-hand.)

Ejecting all disks

Sun, 09 Jan 2022 20:48:27 +0000

David Sparks posted this week about ejecting disks using AppleScript and Keyboard Maestro. I’m grateful to David for posting about this — it’s something I’ve needed for a while but hadn’t got around to doing. Currently I plug my laptop into several external drives when I’m sat at my desk, and have to eject them before taking it somewhere more relaxed.

But David’s script didn’t quite work for me in that a blunt eject the disks command to the Finder will attempt to eject all the disks that are considered “ejectable”. For me, this includes APFS snapshots that aren’t obviously visible in the user interface, where trying to eject them pops up a dialog referencing “Macintosh HD – Data@snap…”.

My alternative is to filter out any drives that contain “Macintosh HD” in their displayed name:

tell application "Finder"
    eject (every disk where "Macintosh HD" is not in its displayed name)
end tell

Note that it’s important to use the displayed name property as the APFS snapshots have UUIDs as their name property.

I’ve also stripped out David’s error handling, as I find that if there’s an error ejecting the disk it’s usually communicated by the Finder itself rather than via an error code visible to AppleScript.

This doesn’t tackle the problem of the Finder refusing to eject a drive containing opened files, even if those files are opened by (from the user’s perspective) unimportant background commands. I spent a chunk of the morning mulling this over (and looking at lsof’s inscrutable man page!), and think I might try to run the output of lsof -F through AWK to enable a prompt-to-terminate interface. This is particularly important for me as I keep my music and photo libraries on an external drive; the photo library in particular is often opened by background system tasks, I think as iCloud syncs across new photos from my phone.

How to wrap bc to do calculations

Tue, 23 Feb 2021 18:14:00 +0000

I find bc trips me up when I try to calculations at the shell, so I wrapped it.

There are two hazards for me:

Failure to handle expressions without a final newline.
Integer division.

Final newline missing

No 1 often occurs when I produce a list of numbers in BBEdit, usually extracted and transformed via regexes.

For example, we get a PDF receipt from Sainbury’s for our online shopping, and to work out my share I like to edit the text from pdftotext in BBEdit, then run the line totals through a pipeline to calculate the total.

That used to look like this:

$ pbpaste | paste -s -d '+' - | bc
609

pbpaste pastes the macOS system clipboard, paste joins those lines with +, and bc (should!) print the total.

Except this happens if you’re missing a final newline:

$ pbpaste | paste -s -d '+' - | bc
(standard_in) 1: parse error

Integer division

And secondly, with the default settings, bc does integer division:

$ bc <<< 9/2
4

Which can be fixed by setting scale

$ bc <<< 'scale=2; 9/2'
4.50

(<<< starts a “here-string”, which you can learn more about at man -P "less -p '<<<'" zshmisc, which will take you directly to the right part of the zshmisc man page. Search the bash man page if you’re using bash, but it’s significantly more terse than the zsh explanation.)

Wrapping `bc`

So I wrote a simple wrapper script, calc:

#!/usr/local/bin/zsh
set -euo pipefail

# Read expression from $1 or stdin.
if [ $# -ge 1 ]; then
    expression=$1
else
    read expression || true  # Force successful exit
fi

# Default scale to 3 (.123) if $2 is not given.
bc <<< "scale=${2:-3}; $expression"

The conditional in the middle just handles being called in a pipe, with the expression coming on standard input, or having the expression provided as the first argument. The || true is necessary after read as read only exits with a success code if it encounters EOF, and since I have -e set in the file, that would cause the whole script to exit.

I set the scale to 3 by default (showing 3 decimal places), but you can configure that with the second argument.

Using a here-string for bc’s input means that it should work whether or not there is a final newline.

The use of read also allows the use of calc by itself to print the result of one expression, for example:

$ calc
(2 + 2) / (10 / 2)↩
.800

Wrapping summation

I use the “sum this list of numbers” pipeline fairly often, and it’s easy to pull out into its own command. I’m just using an alias, which I’ve added to my .zshrc:

alias ∑="paste -s -d '+' - | calc"

sum is already taken, so ∑ seemed appropriate. On macOS you can type it with ⌥w.

So my pipeline from before just becomes pbpaste | ∑.

Give Python’s static typing a go

Wed, 08 Jul 2020 06:00:00 +0100

While my go-to language is still Python, at university I’ve also used Java and C#. I have to say, there was a huge amount to like — much to my surprise initially!

Previously I’d kind of written off Java as being a boring language for boring businesspeople. There are certainly elements of that (package com.robjwells.MyPackage; in src/main/java/com/robjwells/MyPackage.java) but there’s a lot to like. Streams are great, lambdas are great, the standard library is great (though not without its rough edges, such as the repeated attempts at date and time), and the tooling is great (I have actually come round to really like IntelliJ IDEA — certainly buying a full licence when my academic licence expires). Plus, it’s really coming along at a clip now with the shorter release cycle.

And C# was an even more pleasant surprise. It’s easy to get the impression that it’s “Microsoft’s Java”, but that’s really selling it short. LINQ is a joy that makes comprehensions in Python (of which I am a huge fan!) seem… just a bit clunky. But C# is full of features, not just LINQ, that make working in it a real pleasure. (I will say, though, that at least on the Mac Rider is a far superior editor than Visual Studio.)

All of this is to say, in a round-about way, that those weird verbose enterprise-y languages have a lot going for them — even in the still small-scale things that I’m working on where without this exposure I would just use Python.

Now, I still am using Python, but there are things that I miss. Chief among them in Python is having the type system actively help me out. Gary Bernhardt writes a bit about this in the context of Ruby and TypeScript. (Be warned there are trivial examples ahead.)

Now, I’m using VSCode so actually the editor will step in and help you even if you do nothing to aid it. For instance, in the following situation:

# untyped.py v1
def ultimate_answer():
    return 42

def main():
    u = ultimate_answer()

VSCode (using the Python extension) will correctly infer that the type of u is int. So let’s do something with that:

# untyped.py v2
def ultimate_answer():
    return 42

def do_something(n):
    return n - 11

def main():
    u = do_something(ultimate_answer())

VSCode still correctly infers u to be an int. Great! But let’s be clear: this is VSCode doing the work so that it can offer you handy things like code completion.

What happens if we have a change in requirements and we change our API… only we don’t catch everything so we end up with the following:

# untyped.py v3
def ultimate_answer():
    return "42"

def do_something(n):
    return n - 11

def main():
    u = do_something(ultimate_answer())

At this point, VSCode gives up: u is an int or it’s a str. In fact it’s neither, because do_something() raises a TypeError so u is never assigned. This is “obvious” to a human reading the code, in this simple example, but it’s easy to imagine a complex system where the types get out of line but the definitions are far apart from each other and the eventual call site.

There are type checkers for Python, the main one being mypy (which is great!). Can mypy help us here?

$ mypy untyped.py
Success: no issues found in 1 source file

Oh, success! Great.

$ python3 untyped.py
Traceback (most recent call last):
  File "untyped.py", line 10, in <module>
    main()
  File "untyped.py", line 8, in main
    u = do_something(ultimate_answer())
  File "untyped.py", line 5, in do_something
    return n - 11
TypeError: unsupported operand type(s) for -: 'str' and 'int'

Ah, no, no magic was performed and we still have a TypeError. It’s worth pointing out here that mypy is all about gradual typing — adding type annotations to your programs as and when. If there are no annotations, there are no checks performed. It’s not clairvoyant.

If we switch back to VSCode, what if we try Microsoft’s shiny new Pylance extension? In the basic type-checking mode it reports that the type of u is unknown which … is a step in the right direction? But no warnings.

If we ratchet up the type-checking mode to strict it reports, with a bunch of red error squiggles, that the return type of do_something() is unknown and the type of u is unknown. We get a similar result if we pass the --strict flag to mypy, which essentially tells the type checker “forget about this gradual business” and attempts to check the whole file. This effectively fails, because we’ve done nothing to help it. Let’s do that now.

In fact, very little is needed before Pylance starts to push you in the right direction, only this:

# typed.py v1 excerpt
def do_something(n: int):
    return n - 11

After which we’re rewarded with red squiggles underneath the call to ultimate_answer() that provides the argument inline to do_something(). The message we get is interesting because it reveals something about the knowledge of the type-checker:

Argument of type "Literal['42']" cannot be assigned to
parameter "n" of type "int" in function "do_something"
  "Literal['42']" is incompatible with "int"

We haven’t typed ultimate_answer(), but it knows that “42” can’t be treated as an int. Mypy needs a little more help to get there:

# typed.py v2 excerpt
def ultimate_answer() -> str:
    return "42"

def do_something(n: int):
    return n - 11

So, at this point we’ve said that ultimate_answer() returns a string and that do_something() takes an integer. What does mypy think?

> $ mypy typed.py
Success: no issues found in 1 source file

> $ mypy --strict typed.py
[…snip…]
typed.py:8: error: Argument 1 to "do_something" has
    incompatible type "str"; expected "int"
[…snip…]

This is an interesting situation because “normal” mode mypy reports that this is fine, no problems here. Strict mode complains — among other things — that the types don’t match. Finally, this is what we want.

But why doesn’t “normal” mode mypy not see the problem? I think this is to do with what is considered a “typed context”. By using --strict we force everything to be a typed context, so we get a lot more warnings and errors from mypy. But without this, main() is not a typed context — it has no typed arguments, and no explicit return type, so “normal” mode mypy just skips over it.

The strength of gradual typing is that if you don’t want to or aren’t ready to add type information, you don’t. But even in this toy example, the standard Python type-checker under its default settings does not pick up this “obvious” (to us!) type error. In Dustin Ingram’s Pycon talk about static typing he says you should use static typing everywhere — for a few reasons, but here we can see that failing to do so leaves a clear error undetected..

It doesn’t take much to rectify that for mypy, just a return type on main(), yielding the following:

# typed.py v3
def ultimate_answer() -> str:
    return "42"

def do_something(n: int):
    return n - 11

def main() -> None:
    u = do_something(ultimate_answer())

And now mypy typed.py gives the same error that strict mode did for the previous example. Adding the explicit return type to main() is honestly pretty useless, but now it opens up the definition of main() to be type checked, at which point the error is spotted.

I wrote the title of this blog post before I really knew where I was going (I have a Beeminder deadline to hit!) so at this point it feels to me like I haven’t quite delivered on (why you should) “Give Python’s static typing a go”. Really we’re at “If you decide to use Python’s static typing you need to go all-in.” Which actually is something I do believe! I think the strictest settings are the most useful, but leaving something untyped leaves a hole for type errors to sneak through.

But it is useful in itself. It’s unfamiliar and, honestly, a bit clunky in Python. (The dance for declaring a TypeVar for a generic function taking some type T is … Not Good and looks worse once you run your code through a formatter, with it then two lines away.)

But thinking about types is thinking about design, and thinking about the contract that you’re willing to offer to the outside world. I’ve found that in Java and C# sometimes I’m ready to bound straight into defining a function … only to stop after realising that I haven’t really clarified what expectations I have of the outside world (parameter types) and what expectations the outside world has of me (return type).

Here’s a dead-obvious example from a simple exercise on Exercism (sorry for any spoilers but I should hope this one is straightforward to anyone with any knowledge of the datetime module!):

from datetime import datetime, timedelta

GIGASECOND = timedelta(seconds=1_000_000_000)


def add(moment: datetime) -> datetime:
    return moment + GIGASECOND

Now, add() is a bad name in general but fine in this confined case, but it’s the simple addition of the datetime annotations that make it clear what we’re handling here. You give a datetime, receive a datetime. Nothing fancy, but compare with the following signature:

def add(moment): ...

It’s concise, sure, but is the cost in understanding worth it? Explicitly annotating the types forces you to consider what the interface is and, in return, tools like mypy will give you a hand in finding bugs.

Anyway, give Dustin Ingram’s talk a watch (check out those t-shirts!) as it’s informative, straightforward and short. Do check out the mypy documentation, as there’s plenty of descriptive information in there beyond the interface to the command line tool and the typing module. Jukka Lehtosalo and David Fisher spoke in some detail at Pycon 2017 about mypy, and I highly recommend Jukka’s article on the Dropbox tech blog that looks at the history and practical aspects of mypy.

It’s clear also that this is the direction of travel for Python — there is a lot on the horizon that will make life easier (see the list of PEPs), and I’m particularly looking forward to seeing what becomes of PEP 622 as at the moment it looks like it will bring with it sum types, even if it is a year or two off at this point.

Scheduling posts in Hugo

Sat, 06 Jun 2020 06:00:00 +0100

My enthusiasm for writing posts here tends to come in reasonably short bursts, usually over a weekend, so I’ve taken to scheduling the two or three posts I might write over the following weeks.

It’s reasonably straightforward to schedule publication with Hugo by using the publishDate attribute in your post frontmatter. For instance, this is the frontmatter for this post right now:

title: "Scheduling posts in Hugo"
date: 2020-05-24T09:25:44+01:00
publishDate: 2020-06-06T06:00:00+01:00
draft: true

The date attribute is filled in by Hugo when I create the post bundle skeleton. I tend to leave this as a marker for when I started writing a post (though I have changed it for posts that I start, leave for a while, and finish later).

The publishDate attribute controls when the post is actually published. Hugo by default doesn’t build posts with this set in the future.

One important change that I made from the defaults, though, is to define the handling of dates in my site-wide config file (config.toml) like so:

[frontmatter]
date = ["publishDate", "date", ":default"]

What this means is that Hugo will prefer the publishDate as the date of the post, before falling back to the date attribute, and then resuming its default lookup, which is listed in the Hugo documentation. (At the moment, the only other thing in the default lookup order is the file modification time, but mostly I include “:default” to be safe if this changes in the future.)

Otherwise, you might end up with a situation where you write “Post Future”, set a publish date in the future, then write “Post Now” and publish immediately, and when “Post Future” is published it will be shown as being published earlier than “Post Now” because its date is earlier. Changing the date lookup order in the config will preserve your deliberate schedule.

(Thanks to “n m” on StackOverflow who got me started with this answer.)

Obviously, just having a bunch of files with the dates set properly doesn’t mean your post will actually be published automatically at the right time. I have a script on my server that cron runs every 15 minutes that pulls from the GitHub repository and rebuilds the site.

This set-up is made easy thanks to Hugo being a single binary, so it’s simple to install on the server, whereas before I would generally build the site locally and upload it to my server with rsync.

Hugo can list posts that are scheduled in the future:

$ hugo list future
content/posts/2020/05/24/scheduling-posts-in-hugo/index.md,2020-06-06T06:00:00+01:00
content/posts/2020/05/24/keyboard-maestro-macro-to-insert-images-into-blog-posts/index.md,2020-05-30T06:00:00+01:00

This is a bit noisy, so here’s a sed one-liner to improve things slightly:

$ hugo list future | sed -E 's/^.+\/([^\/]+)\/index.md,(.+)/\2 - \1/'
2020-06-06T06:00:00+01:00 - scheduling-posts-in-hugo
2020-05-30T06:00:00+01:00 - keyboard-maestro-macro-to-insert-images-into-blog-posts

(This assumes that you’re using page bundles.)

I actually now have a Beeminder goal to ensure that I write a post a month — well, I was being lenient with myself so it’s every 31 days. It’s also set for a maximum 31 safe days, so I feel that scheduling once a week is enough to tamp down any short-term blog-mania while also not gaming the Beeminder goal too much by scheduling posts at 31-day intervals. (Perhaps this is a sign though that I can set the goal to have a shorter period, but at the moment I have enough commitments that I don’t feel comfortable doing so.)

Keyboard Maestro macro to insert images into blog posts

Sat, 30 May 2020 06:00:00 +0100

Here’s a quick Keyboard Maestro macro to make it easier to insert images into blog posts, or any other markdown or HTML document really. The details of the macro are set up to create a Hugo figure shortcode, but the Hugo-specific bits are just scaffolding and could be swapped out for whatever you need.

You can download the macro file here, but the whole thing ended up being a bit long so I’m not going to include the usual image of the whole macro (which is 1,965 pixels tall). Let’s step through it.

The first stage of the macro, prompting for the image file and then loading it onto a named clipboard.

After selecting the image, we need to load it onto a named clipboard because Keyboard Maestro’s image actions generally work on the contents of a clipboard.

Next we extract needed properties from the image into Keyboard Maestro variables.

Then we need to prompt the user to confirm the attributes of the figure.

The prompt set-up.

And the prompt itself.

Any of these can be empty, so after assembling the shortcode text blank attributes are removed:

And then lastly the figure shortcode text is inserted by pasting, which is handy because it end up on the clipboard if anything goes wrong — like it did when I changed the focus when inserting the previous screenshot!

The Atom: A Love Affair

Sun, 24 May 2020 08:15:00 +0100

I watched The Atom: A Love Affair last night, a new documentary about the history of nuclear power, and it’s really great. It charts the ups and downs of nuclear power, its promoters and opponents, and looks at where we are today. I think its great strength is that it sets out the surrounding context. It doesn’t take a side but gives a fair accounting (which I think leads to a clear conclusion, though I would, wouldn’t I?).

You can stream it online at Curzon Home Cinema, and I highly recommend it.

There’s a Q&A session held after the film’s premiere, and more info on the Facebook page. There’s also an episode of Radio 3’s Sound of Cinema with the film’s composer Paul Honey.