It's pretty cool because:

• It's easier to remember your computer is at computername.local than it is to remember it's at 192.168.1.52.
• While it's possible to set up your router so that your computer is always at the same IP, it's still a little work.

mDNS is implemented in OS X through Apple's Bonjour implementation, and (generally) in Linux through Avahi. When you do this, your device's URL will usually be <devicename>.local.

If you're running a homeserver, you might have multiple services, each running on its own port. And if you've hung out on the web for a bit, you'll be wondering if there's any way to set up subdomains of your lovely mDNS-implemented local URL. If you give it a web search, you'll find some people doing the same, some people telling you to use python libraries for Avahi (which I'm not sure are still maintained), and even some AI slop telling you to change config settings in Avahi which don't exist.

And here's how you actually do it.

Step 0: Prerequisites

This assumes you're running on a Linux distro which usessystemd for service management. You should install avahi using your preferred package manager.

Step 1: Outline the subdomains you want

We're going to be cute for this step: we're going to set up a little file in Avahi's config space for our subdomains. For me, this is /etc/avahi. Your mileage may vary.

Let's set up three subdomains: tv, music, and wiki (again, assuming we're running some services on our home server) - these will go to eg tv.computername.local, music.computername.local and wiki.computername.local. Which will be pretty cool.

In your terminal:

cd /etc/avahi
echo tv\nmusic\nwiki > subdomains

This will create a file subdomains with three lines, each line showing a subdomain. Easy!

Step 2: Build the publication process

To let other devices on our network know about these subdomains, we need Avahi to publish them. The following shell script does this, leaning heavily on u1aryz' how-to-avahi-subdomain script.

#!/usr/bin/env bash
set -euo pipefail

# Default interface
readonly DEFAULT_INTERFACE="wlp0s20u2"

# Where we store aliases
readonly SUBDOMAIN_FILE="/etc/avahi/subdomains"


# Logging functions
log_info() {
  echo -e "[INFO] $*" >&2
}

log_error() {
  echo -e "[ERROR] $*" >&2
}

show_usage() {
  cat >&2 <<-EOF
    Usage: $0 [-i <interface>]

    Options:
      -i <interface>  Network interface to use (default: $DEFAULT_INTERFACE)
      -h              Show this help message
EOF
}

check_requirements() {
  local missing_deps=()
  local required_commands=("avahi-publish" "ip")

  for cmd in "${required_commands[@]}"; do
    if ! command -v "$cmd" &>/dev/null; then
      missing_deps+=("$cmd")
    fi
  done

  if [[ ${ #missing_deps[@]} -gt 0 ]]; then
    log_error "Missing required dependencies: ${missing_deps[*]}"
    exit 1
  fi
}

validate_interface() {
  local interface="$1"

  if ! ip link show "$interface" &>/dev/null; then
    log_error "Network interface '$interface' not found."
    log_error "Available interfaces:"
    ip link show | grep -E '^[0-9]+:' | awk -F': ' '{print "  " $2}' | sed 's/@.*//' >&2
    exit 1
  fi
}

get_interface_addresses() {
  local interface="$1"

  local ipv4_addresses=$(ip -4 -o addr show dev "$interface" scope global | awk '{print $4}' | cut -d/ -f1)

  # Check if we have IPv4 addresses
  if [[ -z "$ipv4_addresses" ]]; then
    log_error "No IPv4 addresses found on interface '$interface'."
    exit 1
  fi

  local ipv6_addresses=$(ip -6 -o addr show dev "$interface" scope global | awk '{print $4}' | cut -d/ -f1)

  # Combine IPv4 and IPv6 addresses
  local all_addresses="$ipv4_addresses"$'\n'"$ipv6_addresses"

  echo "$all_addresses"
}

publish_addresses() {
  local fqdn="$1"
  local addresses="$2"

  log_info "Publishing '$fqdn' with addresses:"

  for addr in $addresses; do
    log_info "  $addr"
    avahi-publish -f -a -R "$fqdn" "$addr" &
  done
}

main() {
  local interface="$DEFAULT_INTERFACE"

  # Parse command line options
  while getopts ":i:h" opt; do
    case "$opt" in
    i) interface="$OPTARG" ;;
    h)
      show_usage
      exit 0
      ;;
     \?)
       log_error "Invalid option -$OPTARG"
       show_usage
       exit 1
       ;;
     :)
       log_error "Option -$OPTARG requires an argument"
       show_usage
       exit 1
       ;;
     esac
   done
   shift $((OPTIND - 1))

   # Validate arguments
   if [[ $# -ne 0 ]]; then
     log_error "No arguments are required."
     show_usage
     exit 1
   fi

   # Check alias file exists
   if [ ! -f $SUBDOMAIN_FILE ]; then
     log_error "File $SUBDOMAIN_FILE does not exist."
     exit 1
   fi

   # Check dependencies
   check_requirements

   # Validate interface
   validate_interface "$interface"

   # Get addresses
   local addresses=$(get_interface_addresses "$interface")

   # Populate
   for subdomain in $(cat $ALIAS_FILE)
   do
     local fqdn="${subdomain}.$(hostname).local"

     # Publish addresses
     publish_addresses "$fqdn" "$addresses"
   done

   # Wait for all background processes
   wait
 }

main

If you've had to change where you keep your subdomain file, change the constant SUBDOMAIN_FILE. Depending on your computer, your wireless interface may also be different from mine - check out how you're connected to the network through ip link show and select the appropriate interface.

As a guided tour of the script:

• Lines 1-85 set up various constants and auxiliary functions.
• Lines 88-118 parse arguments to ensure we're advertising through the right interface.
• Lines 119-123 are simply us checking a subdomain file exists.
• Lines 125-132 involve us ensuring the system has the right things installed, that the interface exists, and collecting our IP address(es) on that interface.
• Lines 134-141 are the loop where we do the work - we use avahi-publish to publish each subdomain, pointing to our IP addresses. These processes are run in the background as child processes to this one.
• On Line 144 we call wait, allowing all background processes to halt before we quit out.

Store this where you will - I've saved mine as /usr/local/bin/avahi-publish-subdomain (and run chmod +x on it to ensure it can be run).

Of course, it sucks having to open up your terminal and run this script just to get the functionality going. Thankfully, we can run it through systemd.

Step 3: Run through systemd

To do this, we'll make a nice simple systemd entry. cd to /etc/systemd/system, and create a file avahi-subdomain.service with the content:

[Unit]
Description=Publish mDNS subdomains under %H.local
Requires=avahi-daemon.service
After=avahi-daemon.service
StartLimitBurst=5
StartLimitIntervalSec=10s

[Service]
Type=simple
ExecStart=/usr/local/bin/avahi-publish-subdomain
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target

You'll notice that this file references our script avahi-publish-subdomain above - point it to wherever your file is.

Now all we need to do it queue it up in systemd:

sudo systemctl enable avahi-publish-subdomain

And you should be good to go!

The last part of winter, and the first part of spring, were entirely taken up by my sudden desire to read The Lord of the Rings, inspired in no small part by this dumb song. Finishing that up, and feeling like a treat, I ended up running through a bunch of recent Hugo Award nominees to finish off the year (with the occasional non-fiction book thrown in for good measure). Embarassingly, back from our summer vacation I've found that I left my Kobo e-reader on a bedside shelf in a bach. So it's paper books for me for the next week until I get it back.

The Lord of the Rings - J. R. R. Tolkein. You don't need a synopsis of this one. I decided to re-read it after two decades (and with my memory warped by the movies), and found myself enjoying a real tome of a novel, familiar enough, but with enough of a twist from the films to make the whole thing refreshing and interesting.

Obviously there are elements that exist in the books and not in the movies - Tom Bombadil, the Scouring of the Shire, etc. - but even the stuff which exists in both is subtley different^[1]. The emphasis on battles, for example, in the movies (which makes complete sense I think - the visual spectacle of some of those battles is one of the defining elements of the last two movies), or the differing characterisation of some of the human characters.

Outside of comparisons with the movies, there's a real voice to Tolkein's work, that I feel echoes his familiarity with the tone and pacing of epic storytelling. It's not always there - a lot of the book feels written in a relatively everyday tone (at least for the time in which it was written), but then something happens - a scene changes, an event occurs, and a literary switch flips. It's not jarring in the least: it feels more like a director employing a particular film technique to signal to the viewer that this is a momentous occasion.

Alien Clay - Adrian Tchaikovsky. I read a couple of Adrian Tchaikovsky books as a result of my summer Hugo-chasing read, but this is the one that stood our the more. A political prisoner is sent to labour on an alien planet, an effective death sentence, but instead uses the opportunity to join up with his former dissident colleagues. As they plan rebellion, the alien planet itself - and its ecology - offer a few surprises of their own.

One definition of science fiction that I've often seen mentioned is that it uses scientific or technological progress as a lens through which we can examine human society. If we go by this metric, I think Alien Clay succeeds - arguably by putting forward such a strong metaphor for human cooperation that even I pick it up on a first read-through. But alongside this, Tchaikovsky does a great job of maintaining both narrative tension and internal consistency to make a satisfying read.

The Notebook - Roland Allen. A rambling journey through the development of the notebook in western civilisation. Early on, the book takes a relatively linear run through the development of paper, books, and the notebook in particular, but once we get into the Renaissance, the story starts diverging. Some interesting tidbits include the development of most western notebooks from Florentine accounting practices, as well as the impact of work books on the development of western art during the Renaissance.

I feel this is a niche read. As someone with a nice stack of (empty and filled) notebooks on my shelf, it appeals to me. If you have a bunch of them, it'll appeal to you. And if not, it probably won't? Idunno, that feels a little like damning with faint praise.

The Ministry of Time - Kaliane Bradley. Part science fiction thriller, part romance, this book follows a young British public servant as she becaomes a companion/monitor for a refugee from the past. The thriller part of this book is completely adequate, but it mainly serves as a vehicle for the collection of misfits the eponymous Ministry has to babysit, as they adapt to the twentieth century and, well, do what people do when left in each other's company for any amount of time.

Wikipedia informs me that Bradley started this novel during COVID-19 lockdown, writing vignettes of the main characters brushing up against the twentieth century. True to form, it's these sections that have the most depth of thought, the most character and charm.

I ended up buying this book as a present for two folks this Christmas. I would have only bought one, except for logistical reasons. The book I would have bought instead of this one would have been...

The Tainted Cup - Robert Jackson Bennett. A dark fantasy Sherlock Holmes, in which a young apprentice is teamed up with an eccentric investigator to uncover a string of strange murders, in a world where monstrous beasts threaten civilisation.

I feel the perfect murder mystery exists as a series of staged mini-mysteries: at each one, you have all the clues you need to solve it, if only you can put them together right, and the revelation leaves you going, "Of course! How could I have missed that?" I feel Bennett manages this extremely well in The Tainted Cup - not only does he manage it, he does so by incorporating the elements of worldbuilding which he's been layering throughout the book since the beginning.

When I put this on the end of my to-read list, it had not yet won the 2025 Hugo Award. Upon finishing it, checking the internet, and finding it had won, I cannot say I'm surprised.

The past six months have been a real dive into genre fiction, to the extent I haven't managed for a few years now, brought on by a few recommendations I've received recently. It's been nice.

The Starless Sea - Erin Morgenstern. Sometimes an author just writes a book that's very clearly a love letter to books, and this is one of them. Morgenstern builds a fantasy world hidden just below ours, like Borges but more romantic, perhaps, full of factions and secret societies and masked balls.

The world-building is wonderous, only enhanced by the fact that the main narrative arc takes place in a ruin of the place, long after all its inhabitants have left. In fact, I can't help but wonder if half the magic of this book is the fact that Morgenstern gives with one hand while taking with the other - showing us what wonders this place used to be, but never actually pointing the camera at the Starless Sea in its heyday.

A book this elaborate needs to be a masterpiece to stick the landing, and this is something I don't think Morgenstern quite handles. The climax and denoument just don't seem to hit quite right.

The Dawnhounds - Sascha Stronach. Obligatory New Zealand author inclusion. Possibly the most New Zealand things about The Dawnhounds was the way I found out about the series - a colleague mentioning that a friend of theirs had published a book.

The Dawnhounds starts off as a murder mystery police procedural set in a weird fantasy mid-future Pacific city, and how you react to that is, I feel, a good determinant of whether or not you'll like the book. The thing quickly switches pace into queer near-future fantasy, and I was saddened by this only because of the potential in the murder mystery space.

The book is weird and queer and revels in both of those areas. There is a sequel and I've yet to see if it continues that through to the second book.

Moominpappa at Sea - Tove Jansson. I read several of Jansson's books as a teenager, but I could swear she'd written more than the nine novels she actually wrote. My mind has whole cloth invented several scenes I could sear happened in Moomin books, which (upon re-reading) I've found never existed - six months ago I'd have bet real money that there was a novel where the Moomins go on a proper holiday to something akin to the Riviera, for example. My own personal false memory.

Regardless, Moominpappa at Sea was actually one of the Moomin books that I skipped over as a child. It's a real pity^[1] because this feels like a real tour de force. The earlier books, while they show some of their essential melancholy, are generally upbeat and cozy. In comparison, this book feels like...not quite a horror novel, but something akin. Each character appears to be battling their own inner demons, somehow isolated from one another just as the characters themselves are isolated from the rest of their world through the sea. Even at the end it feels less like they conquer their issues, and more that they come to terms.

A Deadly Education - Naomi Novik. I got a few recommendations for books recently from a friend, and this was one of them. A Deadly Education grabbed my pretty rapidly thanks to its weird Battle Royale-esque setup coupled with a nice riff on what I've come to refer tongue-in-cheek as the Zauberkindbildungsroman (lit.: "Magical child coming of age story").

I cannot help but shelf this series alongside Lev Grossman's Magicians series in my head. Tone-wise, the two books are quite different, but they both have a number of similarities beyond just their focus on magical high schools, the kind of people these places would produce, and what happens after these folks graduate.

All Systems Red - Martha Wells. Another recommendation to me. I'd previously read (and not particularly enjoyed, I don't think?) some of Wells' fantasy work, so it took a couple of recommendations for me to pick this series up.

All Systems Red is a great conceit well-executed: a security construct, basically a human being modified Robocop style into a mobile sentient weapons platform and leased out as a service, goes rogue, but rather than kill everyone, it just wants to watch TV all day.

As the series continues, Wells executes a competent pivot from gag novel to introspective series about what it means to be human. But I'm not sure that it really quite recaptures the frictionless joy-in-the-conceit of the first book or so.

TaskWarrior is what I'm currently looking at. It's a CLi-based, open source task management tool which portable to basically any operating system, and has a bunch of extensions.

But exporting tasks and projects from one project, and importing them to another, is a big deal. Let's see how hard it can be.

The big picture

The good news is that OmniFocus has a good export system, and TaskWarrior has a good import system.

OmniFocus exports to xml

If you open OmniFocus, you can export your current database to file by selecting File > Export:

This will prompt you to save an .ofocus file somewhere on your computer, but if you happen to inspect it in terminal or even just gently rename it to remove the .ofocus extension, OS X will reveal to you what it really is: a folder.

There's a bunch of stuff in here, but there's always one zip file, named something crazy and random-looking, which is actually a zipped .xml file. And if you unzip and open that...

Not quite complete nonsense - this is actually a file containing every folder, project, context, perspective, and task that currently exists in your OmniFocus database. And this is gold.

TaskWarrior imports from json

You can find the specifics here, but the good news is that even though you could make a program to systematically call TaskWarrior and add task after task, you can also run a bulk import on a JSON file. There are some things we'll need to work around - for example, TaskWarrior doesn't have a good handle on nested tasks, and projects and folders are a much more nebulous concept - but we can indeed work around them.

As we go through the next few steps, I'll be referring back to their JSON spec above to work out how to handle our various task and project properties.

OK, so how do we export this stuff?

The first thing will be to read the XML file. I'm doing this in ruby, my glue language of choice, and in ruby the standard XML parsing gem is nokogiri.

Here's a script to load in contents.xml, check through the top-level elements, and see what they are.

require 'nokogiri'

doc = File.open("contents.xml"){ |f| Nokogiri::XML(f) }

doc.root.children.each do |elem|
  puts elem.name
end

This will provide you with the following element types:

• attachment: A file attachment
• context: A task context
• folder: A project folder
• perspective: A saved perspective
• setting: A document setting
• task: A project or task (OmniFocus treats projects as subsets of tasks)
• task-to-tag: Basically a many-to-many join table between tasks and contexts

We're going to be focusing on the folder and task elements here.

Here's a simple ruby script which iterates through all your tasks, showing each task's name:

require 'nokogiri'

doc = File.open("contents.xml"){ |f| Nokogiri::XML(f) }

doc.search(":root > task").each do |t|
  puts t.at("name").text
end

We're using CSS-style selection in doc.search - Nokogiri also supports XPath, but I'm most familiar with CSS so I'm going to be using that for this example. If you've run this, you should see a big ol' list of task and project names in your console. As I mentioned, OmniFocus makes little structural distinction between projects and tasks, as they both share many properties (name, contexts, due date, repetition rule, etc.). The project-specific properties for a project are stored in the project element underneath the task object. In fact, we can split our tasks into actual tasks and projects pretty handily:

require 'nokogiri'

doc = File.open("contents.xml"){ |f| Nokogiri::XML(f) }

ALL_TASKS_AND_PROJECTS = doc.search(":root > task")
puts "I have #{ALL_TASKS_AND_PROJECTS.length} tasks/projects!"


ALL_TASKS = ALL_TASKS_AND_PROJECTS.select{ |elem| elem.at("project").children.length == 0 }
puts "  #{ALL_TASKS.length} of these are tasks"

ALL_PROJECTS = ALL_TASKS_AND_PROJECTS.select{ |elem| elem.at("project").children.length > 0 }
puts "  #{ALL_PROJECTS.length} of these are projects"

As mentioned, TaskWarrior doesn't really treat projects as first-class citizens, so we want to focus on just exporting tasks. We'll deal with projects as we go. Let's have a first stab at making something resembling TaskWarrior's import JSON format:

require 'nokogiri'
require 'json'

doc = File.open("contents.xml"){ |f| Nokogiri::XML(f) }

ALL_TASKS_AND_PROJECTS = doc.search(":root > task")
ALL_TASKS = ALL_TASKS_AND_PROJECTS.select{ |elem| elem.at("project").children.length == 0 }

taskwarrior_import_array = ALL_TASKS.map{ |elem|
  { 'description' => elem.at("name").text }
}

File.open("import.json", "w"){ |io| io.puts JSON.pretty_generate(taskwarrior_import_array) }

This will generate a JSON array of tasks, all given the correct name. It almost looks like this could be a valid import to TakWarrior - except it's not, of course. Let's check TaskWarrior's documentation on the subject:

At a minimum, a valid task contains:

• uuid
• status
• entry
• description

OK, so as well as a task description (which we've now added), we need a uuid (a unique identifier in a standard form), an entry (the date/time at which the task was created), and a status (active/complete/etc). Let's see what we can do.

Generating a UUID

TaskWarrior's documentation states that:

A UUID is a 32-hex-character lower case string, formatted in this way:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

An example:

296d835e-8f85-4224-8f36-c612cad1b9f8

While OmniFocus does use unique IDs for its tasks, it doesn't use this format. The easiest thing for us to do is to create them whole cloth, one per new task.

It turns out you can really easily create those in ruby using the securerandom package:

require 'securerandom'

SecureRandom.uuid # => A nice UUID

Adding an entry field

TaskWarrior is pretty strict about date/time formats:

Dates are rendered in ISO 8601 combined date and time in UTC format using the template:

YYYYMMDDTHHMMSSZ

An example:

20120110T231200Z

No other formats are supported.

Annoyingly, OmniFocus stores its dates and times in a slightly different format. Here's an example of OmniFocus' added field, which represents when the task was added to the program, and is analagous to TaskWarrior's entry field:

<added>2017-05-15T09:19:04.940Z</added>

You could parse this into a Time object, then output using strftime. Or you could just regex the task into submission:

tw_time = of_time.gsub(/[-:]/, "").gsub(/\..*Z$/, "Z")

Adding status

Ignoring recurring tasks, TaskWarrior recognises four statuses: pending, deleted, completed, and waiting. All our tasks will be considered to be pending for now, just to make things easy.

Handily, pending tasks don't need any more information.

A bare bones legal export

So let's look at the code which will give us the bare minimum setup in TaskWarrior from our OmniFocus data:

require 'nokogiri'
require 'json'
require 'securerandom'

doc = File.open("contents.xml"){ |f| Nokogiri::XML(f) }

ALL_TASKS_AND_PROJECTS = doc.search(":root > task")
ALL_TASKS = ALL_TASKS_AND_PROJECTS.select{ |elem| elem.at("project").children.length == 0 }

taskwarrior_import_array = ALL_TASKS.map{ |elem|
  {
    'description' =>  elem.at("name").text,
    'entry' => elem.at("added").text.gsub(/[-:]/, "").gsub(/\..*Z$/, "Z"),
    'uuid' => SecureRandom.uuid,
    'status' => 'pending'
  }
}

File.open("import.json", "w"){ |io| io.puts JSON.pretty_generate(taskwarrior_import_array) }

Not too shabby, all told - but what about our other fields?

Advanced migration

Nothing under this section is vital, but chances are you'll want to bring one or more of the following data types along with you.

Projects

As mentioned, TaskWarrior treats projects as more of an auxiliary item than a first-class citizen. On the one hand, this means we won't be keeping any cool project-level info like project-wide tags, start dates, or due dates, but it also means that we don't have to try creating a relational database just to port things over.

TaskWarrior allows each task to have a project, which can in turn be nested within one or more project groups. TaskWarrior's projects take the form: Proj1.Proj2.Proj3, where Proj3 is nested inside a parent project Proj2, which is in turn nested inside a parent project Proj1.

In contrast, OmniFocus has a more complex folder-project-task heirarchy. Projects cannot be children of other Projects, but can be children of Folders, which can in turn be children of other Folders. Tasks can be children of Projects, or they can be children of other tasks.

Whew.

If you're using all of the levels of OmniFocus, well, you're gonna have to collapse some of that in TaskWarrior^[1]. The main thing that'll give us headaches is nested tasks. I went through my projects before exporting to TaskWarrior and just ensured that every project was a simple list of tasks with no nesting - if you want to keep your nesting in your exported file, you may need to do some more exploration of the file structure.

OmniFocus generates its task and project heirarchy as follows:

• Every task has a <task> child element with an idref attribute. This attribute corresponds to the id of the task or project that this task is a child of. If this is absent, this task has no parent (ie it's an inbox task).
• Every project has a <project> child element, which in turn has a <folder> child element with an idref attribute. Again, this corresponds to the parent folder (if any).
• Every folder may have a <folder> child element, which (if it does) has an idref attribute. And this corresponds to the parent folder.

Given all that, we can create a kind of "path" for each task by combining these in sequence. We'll be using recursion to ensure this can always trace the task's heirarchy back to the root of our OmniFocus document. We have to tread carefully as it's difficult to tell whether a task is a child of another task, or whether it's a child of a project, without inspecting the parent element.

require 'nokogiri'
require 'json'
require 'securerandom'

doc = File.open("contents.xml"){ |f| Nokogiri::XML(f) }

ALL_TASKS_AND_PROJECTS = doc.search(":root > task")
ALL_TASKS = ALL_TASKS_AND_PROJECTS.select{ |elem| elem.at("project").children.length == 0 }
ALL_FOLDERS = doc.search(":root > folder")

def path_to_folder(f)
  if f.nil?
    return "<ERROR>"
  end
  folder_name = f.at("name").text
  parent_element = f.at("folder")

  if parent_element.nil? || parent_element["idref"].nil?
    # No parent - path is just the folder name
    folder_name
  else
    # Parent - path = parent path + this name
    parent_folder = ALL_FOLDERS.find{ |f| f["id"] == parent_element["idref"] }
    path_to_folder(parent_folder) + "." + folder_name
  end
end

def path_to_taskproject(tp, top = true)
  elem_is_project = tp.at("project").children.length > 0

  elem_name =  tp.at("name").text

  if elem_is_project
    parent_element = tp.at("project folder")

    if parent_element["idref"]
      # Parent folder - path = parent path + this name
      parent_folder = ALL_FOLDERS.find{ |f| f["id"] == parent_element["idref"] }
      path_to_folder(parent_folder) + "." + elem_name
    else
      # No parent - path is just the project name
      elem_name
    end
  else
    # Task - go through <task> element
    parent_element = tp.at("task")
    
    if parent_element["idref"]
      # Has a parent: path = parent path + this name
      parent_taskproject = ALL_TASKS_AND_PROJECTS.find{ |tp| tp["id"] == parent_element["idref"] }
      if top
        path_to_taskproject(parent_taskproject, false)
      else  
        path_to_taskproject(parent_taskproject, false) + "." + elem_name
      end
    else
      # No parent - inbox task!
      nil
    end
  end
end

And we can test this as follows:

sample_task = ALL_TASKS.sort_by{ rand }.first
puts "Path for '#{sample_task.at("name").text}':"
puts path_to_taskproject(sample_task)

At this point, we can add this to our output! The project field is just a string value, after all:

taskwarrior_import_array = ALL_TASKS.map{ |elem|
 {
   'description' =>  elem.at("name").text,
   'entry' => elem.at("added").text.gsub(/[-:]/, "").gsub(/\..*Z$/, "Z"),
   'uuid' => SecureRandom.uuid,
   'project' => path_to_taskproject(elem),
   'status' => 'pending'
 }
}

Contexts

OmniFocus' Contexts map nicely to TaskWarrior's tag attribute. Unlike contexts, tags don't naturally support a heirarchy, and to be honest I suspect trying to implement heirarchical tags would make your filters and reports somewhat unwieldy in TaskWarrior. Heirachical context may be an indicator of some other sorting criterion, which could be a candidate for setting up through User-defined attributes (something I haven't really gotten into yet, but I'm keen to try out?).

I didn't end up bringing my contexts through to TaskWarrior, partly because most of the tasks I'm tracking have one real context (viz: Computer) and partly because I wanted to reset my current context system and remove some needless complexity from my projects.

Given all that, let's look at how we could map contexts to tags, ignoring your context heirarchy for now.

Our first job will be to extract a task's contexts from the OmniFocus xml file. Each task may have a context child element, which links (via idref) to exactly one context - but tasks can have multiple contexts, so this isn't a guarantee we'll catch everything of use. Thus, we must use the one join table OmniFocus encodes into its xml file - the task-to-tag element grouping.

require 'nokogiri'
require 'json'

doc = File.open("contents.xml"){ |f| Nokogiri::XML(f) }

ALL_TASKS_AND_PROJECTS = doc.search(":root > task")
ALL_TASKS = ALL_TASKS_AND_PROJECTS.select{ |elem| elem.at("project").children.length == 0 }

# Contexts
ALL_CONTEXTS = doc.search(":root > context")
CONTEXT_TASK_JOIN = doc.search(":root > task-to-tag")

def context_ids(task_id)
  CONTEXT_TASK_JOIN
    .select{ |ctj| ctj.at("task")["idref"] == task_id }
    .map{ |ctj| ctj.at("context")["idref"] }
end

def context(id)
  ALL_CONTEXTS.find{ |c| c["id"] == id }
end
  
def context_name(id)
  c = context(id)
  return c if c.nil?
  return c.at("name").text
end

def task_contexts(task_id)
  context_ids(task_id).map{ |id| context_name(id) }
end
  
sample_task = ALL_TASKS.first
st_name = sample_task.at("name").text
puts "#{st_name}: #{task_contexts(sample_task["id"]).join(', ')}"

The above snippet pulls out that join table and uses it to identify every link between a task and a context. Then, it looks up that context to get the context's name. We can then add that to our JSON - TaskWarrior expects a task's tag attribute to be an array of string values, so it's not too much of an issue to just add those context labels in there.

What's that? You'd like to keep the context heirarchy? Well, you do you - the following code will do that:

def full_context_name(id)
  c = context(id)
  return c if c.nil?
   
  c_name = c.at("name").text

  c_context = c.at("context")
  if c_context && c_context["idref"]
    return full_context_name(c_context["idref"]) + "." + c_name
  else
    return c_name
  end
end

Recurrence

Recurrence is, as far as I can tell, a bugbear for every single task management application. You want this task to repeat every week on Saturday, huh? What if you haven't completed it by the time next Saturday rolls around? What if you complete it on Friday? Do you want the task to restart the following day? Do you want the task to be due again in a week, or just to reappear on your task list in a week?

OmniFocus does a lot to make task recurrence work exactly how you want. It's a bit complex when you first encounter it, but it'll do whatever you need it to.

TaskWarrior's recurrence rules are a little more basic. This means any fancy recurrences you have set up in OmniFocus, well, won't translate over, and even some basic functionality (like scheduled dates) doesn't work well with recurrence. In fact, at this stage I'd be hesitant to even try providing a migration strategy for recurrence. I'm planning on reviewing my current recurring tasks and either reimplementing them in TaskWarrior, or setting up some sort of calendar reminder system. It's a work in progress.

That became quite a bit longer than expected, mainly due to code snippets and the like. I hope if you've reached this far in the article, it's been of use as you shift into TaskWarrior. Who knows - within a couple of months, I may be looking for alternative task management apps. But in the meantime, I'm hoping to keep this all documented in the garden.

A digital garden, in essence, is a collection of linked pieces of writing. Maggie Appleton's useful summary of the term elaborates:

A garden is a collection of evolving ideas that aren’t strictly organised by their publication date. They’re inherently exploratory – notes are linked through contextual associations. They aren’t refined or complete - notes are published as half-finished thoughts that will grow and evolve over time. They’re less rigid, less performative, and less perfect than the personal websites we’re used to seeing.

It harkens back to the early days of the web when people had fewer notions of how websites “should be.” It’s an ethos that is both classically old and newly imagined.

There's lots of different types of digital garden: one of the things I quite like about the form is that you can impose as much (or as little) structure as you like. Each item in your garden can be carefully categorised by topic, situated amongst others, linked to within an inch of its life to provide a tight webbing of ideas and correlations - or your notes can exist free-form, with nothing but a title and some text to their name, occasionally linked to others in a sparse net.

In fact, this is one of the things that delayed my really putting the garden front-and-centre on here. I wasn't quite sure how I wanted my garden organised, and whenever I did get ideas about organisation, I found that organising the stuff I did have was more effort than it felt it merited.

So now I have what I have: a series of nodes, loosely interlinked, with little metadata or additional structure. It's small now, hopefully growing over time, slowly, but gradually.

It's over here.

The Counte of Monte Christo - Alexandre Dumas. I have a dim childhood memory of, it seems, watching a TV film of this with my parents - mainly I remember Dantès being imprisoned, and taking years to escape, picking up skills along the way. Weirdly I don't remember much else, given how this takes up perhaps a quarter of the novel. Perhaps as a small child I wandered off after this, I have no idea.

As I'm sure I've observed for other pre-20c books, this story really takes its time building up to the finale. I've heard the theory that these books didn't have to compete with TV or radio, so they could spread out at their lesisure, and that definitely feels the case with this. That means that it feels like this book spans the kind of narrative breadth that a modern-day author would split into a trilogy; it also means that the climax of the book has to tread the narrow line between underselling it on the one hand, and melodrama on the other. (Monte Christo decides to pick melodrama, for what it's worth.)

The book is a product of its time – both in how it assumes knowledge of, and interweaves the politics of, post-Napoleonic France, and in its treatment of women and people of colour – but with that in mind it's still an involving and labrynthine tale of slow revenge which casts a long shadow on the genre.

The Art of Fermentation - Sandor Felix Katz. This is, put simply, a book about the many ways humankind has fermented foods. It covers everything from basic vegetable fermentation through country wines, ginger beers, mold-based fermentation (sake, tofu, etc), as well as fermentation of meat and fish. It's one part practical guide, one part attempt to cover the main ways humankind has fermented foods, and one part a collection of the author's own experiences.

The book isn't comprehensive (although this is usually evidenced by the author freely admitting such in the various sections, and providing secondary references for the curious reader), and some of the later book (discussing non-food uses of fermentation) feels quite tacked-on, but it more than makes up for this in its character and enthusiasm. Katz' interest in, and keenness to explore, the world of fermentation is palpable, and it's hard to read without feeling the urge to get up and just start following along in your own kitchen. Even if it's merely the springboard for further reading, I feel it's of immense value.

Father Goriot - Honoré de Balzac. I started reading this after I finished Monte Christo and realised Dumas was basically the only French author I could name. Balzac often seems to appear in the same vein, so I prevailed upon Standard Ebooks to provide me with a copy of his novel Father Goriot.

If you read Wikipedia, it'll tell you that Goriot is part of Balzac's Comédie humaine, or "Human Comedy". Don't be fooled: Goriot is at heart a tragedy, a story about a bunch of young folks who are doing whatever they can to get ahead in a world wracked by social upheaval. It has all the tools available to be an uplifting romance, but these things aren't meant to be. In contrast to Dumas' Monte Christo, this is a more realist tale of the Bourbon Restoration. Edmund Dantès and his contemporaries often feel like archetypes or like ideas made flesh, while Balzac's characters feel more flesh-and-blood, more affected by the forces surrounding them.

I'm intrigued by descriptions of Balzac's Comiédie humaine: an interweaving set of myriad books whose characters may pop up in multiple novels, exploring the facets of Paris and France during the time. It sounds like an immense undertaking and something I'd love to make my way through - but each individual book is so long that I'm really not sure if it's worth doing. Perhaps one of these will just be Balzac.

Cloud Cuckoo Land – Anthony Doerr. A story of five youths, growing up in troubled times, finding solace in an the fragments of ancient Greek writer's comedy, connected by this thin thread and by the occasional chance meeting.

Doerr's structure and writing - the interspersed stories told across time, the use of written materials as a linking structure, the delving into the near future of humanity - remind me strongly of David Mitchell, although I think Doerr's take is slightly more optimistic and humanist than Mitchell's.

One highlight of the book for me was the haunting description of Constantinople in the final days of the Byzantine Empire.

Grass – Sheri S. Tepper. This novel got mentioned somewhere on the internet, I wish I could remember where. Someone was mentioning it in passing, from memory, and I thought it sounded interesting.

Grass is a science fiction story that follows a family sent undercover as diplomats on a fact-finding mission for a global church to an argarian plant in the back of beyond, as an incurable plague starts to sweep through humanity. It reminds me of plenty of other science fiction books I've enjoyed: the sweeping vistas of the titular planet Grass parallel in my mind to the sands of Dune, and the inter-family squabbles that occupy the first half or so of the book also remind me of the same squabbles you see in the first third of Dune. Some other elements (and some of the alien weirdness the family experience on the planet Grass) remind me of Dan Simons' 1989 novel Hyperion, while the relationship between the protagonist and the aliens she encounters feels somewhat akin to some of Le Guin's Ansible series.

Perhaps the highest praise I can give is that it started me reading through the rest of Tepper's bibliography, which is where I find myself now as I round out the year. So far nothing has been quite as good as Grass, but it's early days yet.

This year – the last couple of years, honestly – have been a bit of a posting desert. I'm hoping that over 2025 I can get back to posting more regularly on other subjects, as well as improving some parts of the site which I know are lacking, and perhaps finishing off some incomplete series. Only time will tell.

This marks the first of these posts since I decided to track my reading digitally^[1] (as opposed to an analogue system). Previously I'd keep track of this through my personal notebook, making entries per book and then writing an index in the back of the notebook. This was fine, except that each time I finish a book (which is getting rarer now we've got a kid around to take up all my spare time) I'd be starting a new index. I really need to externalise the index into its own book, which seems like a lot of work.

While a digital book catalogue doesn't feel nearly as romantic or tactile, I hope that it's actually more useful in some imagined future where I need to consult my notes on a given book. That doesn't normally happen - I'm not a practicing academic or anything, and a lot of the time if I'm that interested in what a book had to say I'd much prefer to get it off the shelf and leaf through it, but you never know.

This list is curiously divided in two: I tended to read large, weighty, "high-fibre" books - the kind of thing you feel you should read, it keeps appearing on all these lists - interspersed with re-reads of some of my favourite, comforting books. It makes sense: after digesting something challenging, you want to return to something easy, something you know you'll enjoy. A section of those books appear below.

The Power Broker - Robert Caro. This absolute doorstop of a biography follows the life of New York urban planner and public official Robert Moses, who "built more structures and moved more earth than anyone in human history", as per 99% Invisible's introduction to the book. I read it as part of the 99% Invisible read-along, and once again I must recommend the e-reader as a device which masks the immensity of large books. A 1,200 page biography, in physical form, is daunting (as well as a good work-out for your arms and a handy weapon in case of home invasion). On your e-reader, that just means the progress bar at the bottom of the screen fills at a slow rate.

It's worth situating this book, outside of its context. Again quoting from 99pi:

Outside of New York City, Robert Moses wasn’t exceptionally well known. Inside of New York, he was mostly accepted by the media as simply the man who built all those nice parks. But The Power Broker, which is subtitled Robert Moses and The Fall of New York, changed all that.

Importantly, this book highlighted not just what Moses managed throughout his career, but how he managed it: by conning planning committees into providing funding, running roughshod over communities, bullying his peers and his superiors into his way of working, and focussing myopically on the car as the sole means of transport. It's by no means a one-sided affair - Moses managed to build a lot of impressive infrastructure in his time - but it highlights just how much Moses' methods and overall philosophy overshadow his achievements.

Ironically, despite all the bridges and parks and roads Moses built, this book feels like it cements him most strongly into history. The final chapters of the book show Moses in retirement, already forgotten and increasingly irrelevant to the world he's left behind. Perhaps the most poignant lesson from the book is that even if the entirity of a city's infrastructural system revolves around you, work still won't love you back.

Anyway, yeah, this book won a bunch of prizes and is well worth reading to understand how cities, local government, and infrastructure work.

Fever Crumb - Philip Reeve. I first read the Mortal Engines series in 2020, and I returned to them following Caro because I needed something simple to decompress, and because I'd been reminded of the series through a discussion with a friend. The original tetralogy holds up passing well, but I'll be honest - it didn't blow me away as much as it did the first time. I actually prefer Fever Crumb, Reeve's second trilogy set in the same world, a prequel of sorts that showed the world Mortal Engines grew from. Perhaps it's because the series relies less on the gimmicks of the first, and instead just lets its characters explore the world. While the later plots get to the world-hangs-on-your-decisions scale we saw in the first series, at least for the first two books the scale stays nicely personal.

Magic for Beginners - Kelly Link. Link has written a number of magical realism short story collections, but this is one of my favourites. I feel the stories walk that fine line of surrealism without complete absurdity, of speaking in metaphor without falling all the way into literary abstraction. And also it contains the novella also entitled Magic for Beginners which I'm particularly fond of, and which lives in my mind rent-free.

The Thin Red Line - James Jones. Sometimes you remember a film or a book exists, and that it takes up an oversized amount of space in the general consciousness even though most people couldn't tell you what goes on in the book, and you decide "I guess I should read it to work out what it's all about". That's why I read this book.

The novel - semi-autobiographical, or at least "based on a true story" - follows an inexperienced United States Army company as they land on and battle for the Pacific island of Guadalcanal in the Second World War. We see them lose their innocence and become inured to the tragedy of war and the arbitrary way in which injuries and death stalk them on the battlefield.

I don't tend to read war fiction, so I couldn't tell you how much (if any) of the storytelling in this book breaks new ground in the genre. Even absent any of that context, though, it felt incredibly empathic to the poor grunts involved in the dying portion of the war. We spent some time on the high-level action, sure, but only enough to situate the personal.

The Will of the Empress - Tamora Pierce. It's a wonder that Tamora Pierce has never appeared on one of these lists in the past. Her novels occupy a warm spot in my heart as the childhood series I never read during childhood. When I get sick, I tend to load up one of the may series on my e-reader to tide me over^[2]. And sometimes I'll just go, "It's been about six months since I read one, which shall I read this time?"

Among them all, Pierce's Circle of Magic series (and its sequels) are perhaps my favourite. I have a soft spot for magical Bildungsromans so it's no surprise. The first tetralogy follows four misfit mages as they are rescued from their current lives and brought to the Winding Circle temple in Pierce's medieval/renaissance fantasy world. The four kids, aged around ten, build a strong rapport and face various challenges across the books, each story allowing one of the children to hold the spotlight while the other three support them. The second series, The Circle Opens, takes place around four years later, as the children separately travel the world with their mentors. I think it's not as strong as the first series, but still a great series. And following this are three books, of which I believe The Will of the Empress is the standout. It follows the children, now aged around eighteen, as they deal with how they've all changed while also trying to ensure they solve the problem of the day.

There's a narrative Stockholm Syndrome which happens in long series I think - the more time you spend with characters, the more joy you get from their interactions. This definitely applies here.

I used to use nanoc, a ruby-based SSG for the site, and I've been doing that since, well, it feels like forever. However recently it's been feeling a little long in the tooth, escpecially as I start thinking about building out the garden and running some pre- and post-processing tasks.

Shifting everything to 11ty has been pretty time-consuming - it's been an evening and weekend activity for most of the last month or two - but if you're reading this it means I've now deployed it in place of my old install. Things are still broken - search, writing, probably other things I've just glossed over right now. But I want to ship this now, and then to try to rebuild bits as needed. As with everything, I'll be spending 80% of my effort on the last 20% of the site, working out how I can take the stupid hacks I made to nanoc and ruby and apply them to 11ty and javascript.

I've definitely noticed a significant speed boost when generating the site - I'm not sure what's causing it, as I strongly suspect it's not the switch in languages. Whatever the reason, though, that should make development and testing a lot easier as I slowly implement the old features I want to keep, and add stuff over time.

I have plenty of thoughts about how to improve things - how better to organise the garden, how to bring things into more order - how to make the whole thing more navigable even as I add more. And also, to actually write something again, rather than just fiddle with it. But this first.

I know that at the end of our last Fall of Magic campaign, you told me (paraphrased):

I would like to play this game again, but I don't know I'll be able to because I don't think it'll ever be as good as that game.

I'm writing this because I want to tell you that - as long as you find a group of folk who're on the same wavelength as you - you'll play games as good as that.

There's a few games that I come back to time after time. Some systems, like Apocalypse World and Dungeon World, came along right as I was entering that halcyon time back in University where you could be in three campaigns at once and not even sweat. I played them so much that their systems and mechanics are like second nature to me. I return to them because I want to tell a story, I want to author something for my friends, and my hands have formed calluses around these systems. I know how to turn the rules to do the thing I want, and when and how to ignore them and let them fade to the background.

And then there's games whose core premise is so gripping, so interesting, so worth revisiting, that I'll run them again and again, interacting with them in different ways, letting things rhyme, stealing bits from previous games and incorporating them into the next, and just steeping in them. Games like Society of Dreamers, games like Fall of Magic.

I could tell you about all the things our group has explored - about the golems and their weird trance-link mindlinks; about the culture of the Foxes of Mistwood, how they've been run out of their home and had to set up subcommunities elsewhere, and their shared religions; about the Barley Lord and his annual immolation; about our awkward teenage love triangles aboard the Sea Wing - but these kind of things, momentous or detailed world-building, tend to lose something on retelling.

Instead, I remember some of the diversions we had in our campaign - the fifteen-minute discussion about the statue in the Market Square - and thought you might like to know a similar thing that came up in our game, about how street numbering works in Istallia.

The great city of Istallia can be divided into three major districts, arranged like a set of concentric circles. The largest is the Outer City, sandwiched between the Old and New Walls, the most populous and diverse of the districts. Inside of this is the Inner City, the old city, reformed and re-reformed through the pet projects of a number of successive rulers, and home of the rich and powerful, as well as the esteemed Starfall Academy. And inside that, the Gilded District, the home of the Gilded One themselves.

Istallia has always grown in layers. New growth occurs on the edges, and as the edges creep out, the old boundaries become roads and alleyways. Over time, ambitious rulers will tear up the houses along these desire paths to widen them, properly pave them, and turn them into roads worthy of the name.

The issue with the ring roads (and they are important enough and numerous enough to earn their own moniker) is that it's not just their structure that's ad-hoc. Street numbering along the roads is a topic of discussion, ridicule, and sometimes even pride from residents. As the streets are formed organically and according to demand, the numbering system is usually agreed upon by residents as required - which means the "start" of the street could actually be anywhere along the circumference of the city. In some cases, in the process of paving and widening the ring roads, the authorities will merge several smaller roads, all of which started at different points along the city's boundary, and renumbering from whichever road is the largest and busiest.

Even when the city is given the chance to renumber its roads, though, the numbering system varies from road to road. Street number 1 on one ring road may be halfway across the city from street number 1 on its outer neighbour, and may even flow the opposite way to the one directly inside of it (that is, one ring may go clockwise, and the other anticlockwise). It's a common trope for a tourist to spend an afternoon wandering a ring road with a map, trying to find the house of a friend.

For the residents of Istallia, the inconsistent numbering scheme is just something to be lived with. People learn how each ring road works and unconsciously remember where each road "starts". But as Istallia grew and become more of a destination for tourists over the past century, successive rulers have identified the confusing ring road system as something worthy of reform.

Theron of Istallia was Gilded One - that is, ruler of Istallia, elected by its Council - many decades ago. Of note to us, he completed his full education at Starfall Academy, and this kind of academic rigour, slightly divorced from reality, tinged his decisions as a leader. It was his idea to try to bring some sort of order to the ring road's haphazard numbering system.

How? Theron issued a city-wide decree that outlined strict rules that the roads would follow. Those roads which did not obey would gradually be brought into line, houses renumbered, some torn down - the argument being that a little disruption now would pay dividends forever more.

The first two sections of the decree were somewhat arbitrary but uncontroversial - first, street number 1 for every ring road would be the easternmost property on the road, and second, every ring road's street numbers would increase as the road turned anticlockwise from this origin point. This was the kind of analytical thinking Theron inherited from his lecturers at the Academy.

But the third section was unintuitive, divisive, and eventually caused the scheme to be canned. It was brought in to settle another, related, issue that always came up with the ring roads: as you travelled further out from the centre of the city, the ring roads had to cover more and more distance. As this happened, the number of houses on each road increased, and the highest number on the road increased as well. The inner-most ring roads may only have a few hundred houses on them, but by the time you reached the outskirts of the Outer City, roads would have a thousand or more houses on them.

In an attempt to make navigation easier for tourists, Theron decreed that the highest number for any property on a ring road would be 360, this being the house just south of the easternmost house (which is, of course, numbered 1). The numbers would mimic the degrees in a circle, with house number 90 being the northernmost house on the road, 180 being the westernmost, and 270 the southernmost. In this utopian vision, a visitor to the city could visit the Temple of the Fallow Field at 90 Cedar Road (this being the northernmost property on said ring road), walk one block north, and be guaranteed to find themselves at 90 All Angels' Road, the next road out.

This was no issue for the smaller streets - in fact, many of the innermost ring roads would find themselves skipping house numbers to fit the pattern. The problem was with the larger ring roads that traversed the outer city: to ensure every house got a number, Theron proposed dividing the roads into one-degree "arcs", assigning each arc a number, and then providing each house within the arc with a fraction such that the arc was evenly divided between its occupants.

For residents of the Inner City, the numbering scheme was not too much of a burden - after all, if a couple of the ring roads in the Inner City had houses labelled "156½" or "13¾", what of it? But the districts near the edge of the city - notably, those populated by the poor and the newly-arrived - found it absurd and unworkable. These were the suburbs already marginalised by the ring roads, who'd find that their local streets would be renamed and houses torn down for widening when the Council decided it was time to add another layer to the system. Forcing entire neighbourhoods to renumber - and to add convoluted fractions to each building - was a step too far.

Over the first year of the scheme, the roads of the Inner City were reformed. There was some muttering and fuming as houses were renumbered, as everyone had to update their address books, but the inhabitants of the Inner City were golden at heart - that is, loyal supporters of the city Council and its ruling mandate - and kept their indignation mainly to the occasional angry letter to the editor of the local paper. But the inhabitants of the Outer City watched on nervously as the reforms worked their way further and further out.

The first three ring roads in the Outer City were successfully converted to the new numbering system without too much hassle, but demonstrations attended the next three. Things escalated from this point. City bureaucrats, delivering notices of the changes or attempting to remove and replace signage, were mobbed, their ceremonial hats of office stolen from their heads, their papers snatched from their hands and scattered into the mud of the street. Signs were painted over or torn down. In one notable instance a set of three city blocks was barricaded off from the rest of the city, the residents declaring the space an independent city-state, and chaos reigned until the army was called in to sort things out.

After a month of protests and stalled progress, Theron finally called for a change of tack – rather than push the system through, officials would meet with community leaders to discuss and collectively agree on important decisions regarding the project. Theron was clear in his rhetoric - the ring roads would be renumbered, construction would continue - but it was to be a collaborative effort. It's generally believed that this was the result of pressure from his counsellors, who threatened to depose and replace him if he didn't make some show of listening to the people.

While these communual meetings were widely considered something of a show, rather than a genuine attempt at consensus-building, they were effective at one thing: slowing the project down. By the time Theron was deposed fifteen months later - a common-enough fate for Guilded Ones in Istallia - three more streets had been partially renumbered, each to varying degrees. None had been completed. His successor, running on a platform of cost cuts and small city government, abandoned the project, not even bothering to try reverting Theron's changes.

Istallia's ring roads now follow a strange pattern as you travel out from the city centre. From the Road of All Gods, the innermost ring road in the Inner City, through to the Raven's Avenue in the Outer City, the roads obey Theron's requirements. Raven's Avenue has several buildings with fractions in their addresses, but otherwise the numbers seem very regular. After that, however, things get more complex. The Street of Sails, next out from Raven's Avenue, has no houses numbered 1 through 90 - the renumbering effort hit riots near the docks, where these houses would have been, and thus this quadrant retains its original numbers (with duplicates indicated by, for example, "272 East Street of Sails", for a grain warehouse, and "272 West Street of Sails", for a milliner's shop in the south of town). The Street of the Blessed Siblings, one ring further out again, has three individual arcs whose numbering follows Theron's rule, although the remaining two thirds follows the old scheme. And after that, the ring roads do what they will, their inhabitants negotiating, renumbering, and generally doing whatever is practical to continue living their lives.

The project to renumber Istallia's ring roads was one of many that Theron oversaw as Guilded One, but its impact on the city proper makes it loom large in the memories of Istallians. There are many ways to read this project as a lesson, but many Istallians view it as a demonstration of the hubris of the city's Council and its inability to solve the actual problems facing the city's inhabitants. Equally, you could view it as an argument for incremental change over sweeping reforms. But ultimately, historians argue, the main lesson to be learned here is what happens when one person brings a grand but simplistic vision to bear against a complex system, and refuses to adapt their plan to meet the vagaries of reality.

I've been reading a lot about websites recently. Specifically, I've been reading about what I'm going to call Web Revival -- a general reaction to the sanitised, siloed world of social media and the web as mediated commercial experience. It took me so long working out how I should call this whole movement here because it is, by its nature, fractured, decentralised, and organic.

Web Revival - or indie web, or small web, or what-have-you - is about the individual. It's about having one little website that you build yourself, of making a part of the web conform to you rather than the other way around. It's about hacking together some html and css and being fine with the fact that maybe thirty people will ever see the results.

As is the way, reading a gazillion articles about a thing will usually get you excited in some aspect or other of the thing. Reading a bunch of people's posts about how they experience the internet, and how they author their own custom blogs, makes me think about what the experience of 1klb is like, and what it should be, and how I can get from here to there.

When I started 1klb, I was halfway through a degree in a career I didn't really want, locked in by student debt and sunk-cost fallacy. I knew I needed a way out, but I wasn't ready to just ditch progress and start again down some other path. Blogging was a way of having a web presence - of showing what I was doing in my spare time - of somehow linking skills to my name which weren't just academic papers so I could point to them when confronting a prospective employer in an unknown field and go "I'm worthy of something, pay me money to do a thing?"

I think this comes through in my first few years of posting to here - it's a lot of "let me demonstrate how I can solve a problem" coupled with my attempts to make something lasting or at least something I can put on the internet as evidence of my coding ability. It also comes through in volume: in the first three years I was averaging about 27 posts a year on here, whereas last year I posted here seven times. What can I say? I was a Ph.D. student, in a field I didn't particularly like, with a bunch of spare time on my hands and a low thrum of anxiety to drive me.

At the end of 2014 I got my first real job, and my posting here took a hit. It turns out that having a 9-to-5 job, flat-hunting, and then settling into a new city will severely curtail your spare time for writing - plus, of course, the drive to publish had gone. I had good (well, adequate) employment, I'd switched careers - I'd made it! Technically not true in the short-term, as it'd take my failing out of that job, returning to my country of birth, and switching careers once again to get settled - but close enough. The patchy veracity of the facts doesn't obscure the overall truth.

Since then the blog has been somewhat quiet. I've had about eight posts a year, or two posts every three months. It's a good number to ensure that this place doesn't look completely abandoned, even as it won't win me any awards.

But that's only really half the story, isn't it? Even while web revival and its kin push host your own website, own your content, make a place that's yours on the net - we have to acknowledge the lives lived in other places. And that's what I'll deal with...whenever part two of this is ready to air.