Visualizing a generalized maximum-weight-matching graph algorithm

Tue, 10 Mar 2026

I have a small side project I’ve been tinkering with over the past few years: a chess tournament management application. It’s been nice as a sort of open-ended exploration sandbox for all sorts of different things, like learning Phoenix, and getting to implement the rules of chess.

The core of the application involves tournament matchmaking. I’ve added support for various tournament formats over the years, but I started with the most common chess format: swiss. The application for matchmaking in Swiss tournaments can be understood best as a form of a maximum-weighted matching problem. The players form a graph (often bipartite, but not necessarily!), and we use the state of the tournament to determine the weight of the edges between them. Internally, the application assigns weights based on rules from the USCF rulebook.

For a very long time, the application used a very-slightly modified version of Joris van Rantwijk’s implementation. Elixir makes it pretty easy to shell out calls to other languages and get the results back, and I just used this. The algorithm itself is quite complicated and I always had trouble reading and deeply comprehending it. Joris has a great writeup of how it works.

I had tried a couple of times to port the algorithm directly from Python to Elixir. I tried by hand and wasn’t able to make much progress. I also tried using LLMs to help with this transformation, but I had never been able to make much headway.

However, with the release of Opus 4.5 and Opus 4.6, I decided to give it another go. I asked Claude to read and build a spec and implementation plan to move things over, and it pretty much just worked. This was the first time an LLM was able to really tackle this problem in a serious way.

So for this, I wanted to go a bit further into the verification and validation. The algorithm is very complicated with many moving pieces. I had a lot of trouble deeply understanding it. So I put together this visualization with Claude.

Working with Claude on this was interesting. It can produce visual and written artifacts very quickly, but the comprehensibility of those artifacts is wildly hit-or-miss. Working from the original spec documents and the writeup had steered Claude into a spot where the words produced assumed a pretty deep familiarity with linear programming and some algorithm-specific jargon. Given that the goal was to produce something somewhat comprehensible, this didn’t really work out. I was trying to thread a needle here: existing explanatory resources I had found (like from wolfram or TUM in munich) operated at either too high or too low of a level; I wanted something that was a lot more explicit, but still approachable. For the top-level algorithmic explanation, I had to throw away basically everything it wrote. After a lot of turns, though, I got something I was pretty happy with:

This visualization is backed by a Phoenix LiveView that uses the actual implementation that runs in the application with some additional observability attached. This allows for a lot of control over what data is visualized, including specific details about internals of the algorithm:

Because it’s built directly into the application, one other nice thing is the visualization also serves as a nice debugging tool: I added some code to deserialize graphs out of the URL state, which lets me walk through how the pairing works for basically any tournament:

Clauding

I’m not going to talk too much about the rise of Anthropic’s flagship model for generating code as there is a ton of pre-existing writing about its capabilities. For me, if you can gain this level of coding capability, the main interesting question is around what do you do with the time that you have gained? I think that using “agentic LLMs” (something like Claude code) are a bit of a manic technology: they produce lines that often compile and work very quickly! So what to do about this? I see basically two paths: spend tokens to make things quickly (aka slop), or spend tokens on deep verification and learning.

A lot has been written about building novel systems without really having an understanding about how they work, and whether or not that’s actually a good thing. Perhaps you can build giant towers of abstraction, but that isn’t necessarily required from the tools. I think that instead going in this direction of using the capability for improving what existings or learning more deeply is much more interesting. Of course, in a personal project it’s much easier to take this time; I am more incentivized to build these sorts of tools for learning and understanding: the process of building out the visualization did help me more deeply understand the algorithm.

Working at the edge of my own understanding with LLMs is also quite strange; it’s easier to pilot Claude through familiar domains and problems. Looking at its output is helpful but because those problems have a familiar shape it’s more akin to working with a colleague. In this scenario, though, I knew that the output was correct (one of the original implementation details was building out a big validation suite that tested tens of thousands of graphs against the reference implementation) but didn’t really know why. The process of building this visual artifact helped me to understand why in a way that I don’t think would have been possible previously.

Making a big button to answer FaceTime calls

Wed, 26 Mar 2025

A family member of mine struggles to accept FaceTime calls from the computer. Imagine if you had limited mobility or physical dexterity and wanted to answer a FaceTime call on a Mac. You need to be able to physically move a mouse or trackpad cursor over to a (pretty small) “Accept” button and click on it. I mean, just look at the tiny size of this thing:

I took this screencap directly from Apple!

What if instead you could just mash a giant physical button? Here’s one sort-of ridiculous way of making this work.

Step 1: Automate the click

Something I didn’t know but probably should have is that MacOS comes with an application called “Shortcuts”, a pretty powerful automation tool. You can wire it up to do all sorts of different things with different MacOS applications with its somewhat convoluted if-this-then-that interface. You can control a lot of the built-in applications with Shortcuts with varying levels of built-in control. The Notes app, for example, supports Shortcuts for all sorts of things like Append to a Note or Move a Note to a Folder. FaceTime, however, only supports making outbound calls via Shortcuts. This could be useful, but we’re trying to get to the opposite: answering a call.

However, Shortcuts can also be used to trigger arbitrary AppleScript commands. AppleScript is a language included on MacOS that provides a way of automating tasks. It has a sort of goofy english-esque syntax that you use to boss your computer around. Here’s the sample from the documentation that counts up the number of files in the Applications directory:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

Some MacOS applications have pretty nice integrations with AppleScript, but the project seems to have largely been abandoned in favor of things like Automator and Shortcuts. Wikipedia has a nice history. In any case, Facetime does not have nice integrations with AppleScript, so we have to abandon that and just attempt to automate clicking on buttons on the display instead. Without further ado, here’s an AppleScript to click on that tiny Accept button:

tell application "Shortcuts"
  tell application "System Events"
    delay 0.1
    set acceptButton to a reference to button "Accept" of group 1 of UI element 1 of scroll area 1 of group 1 of window 1 of application process "NotificationCenter"
    if acceptButton exists then
      click acceptButton
      delay 2
      repeat while exists (window 1 of process "FaceTime")
        delay 30
      end repeat
    end if
  end tell
end tell

What in the world does this do? Well:

tell application "System Events" scopes our commands to the “System Events” application, a place where non-GUI functions can be executed (like entering a keystroke, etc)
delay 0.1 waits for 100ms to give FaceTime time to render the button
The next big giant block finds the Accept button. It lives in a big element hierarchy: NotificationCenter > window > group > scroll area > UI element > button. The way I figured this out was by using the XCode Accessability Inspector and working backwards through the display hierarchy:

One big caveat here is that this definitely not future-proof. This element hierarchy worked for Sonoma, but inspecting it again for Sequoia shows some pretty large differences in the layout. In this case, the people I am building the button for aren’t planning on upgrading, but it is something to keep in mind.
The rest is just waiting for the button to exist, clicking on it, and then keeping the script running for as long as FaceTime is open. For some reason I had to do that or FaceTime would just close randomly which was very frustrating.
We also wrap up the whole thing up in a tell application "Shortcuts" to try and scope down what applications we allow to control our computer via Accessibility settings.

So now that we have our AppleScript, we can bind it into our Shortcuts application and give it a keyboard shortcut! I chose ⌘⌃⌥8 basically at random.

Step 2: Automate the keyboard command

Now that we have a (terrible) way of clicking on a tiny button by instead pressing a ton of keys together at the same time, let’s automate the pressing of the keys!

You can use a microcontroller to emulate a USB keyboard and have it send the keys in question based on a relevant signal. Since I knew basically nothing about hardware going into this mess, I used an Arduino Micro, though you could probably do the same thing with something a bit smaller and cheaper.

One nice thing about using Arduino is that there are good instructions and guides for getting started and writing your first Arduino sketches. The Arduino website has some good tutorials. Here’s what I came up with for sending keystrokes programatically to a computer:

#include <Keyboard.h>
int btnPin = 2;

bool currentlyPlaying = false;

void setup() {
  pinMode(btnPin, INPUT_PULLUP);
  Keyboard.begin();
}

void loop() {
  if (digitalRead(btnPin) == HIGH) {
    currentlyPlaying = false;
  }

  if (digitalRead(btnPin) == LOW && !currentlyPlaying) {
    currentlyPlaying = true;
    Keyboard.press(KEY_LEFT_GUI);
    Keyboard.press(KEY_LEFT_ALT);
    Keyboard.press(KEY_LEFT_CTRL);
    Keyboard.press('8');
    Keyboard.releaseAll();
  }

  delay(500);
}

Basically, we:

Set up the Keyboard library
Wait for a signal to come in on pin 2
Press all of the keys needed at the same time
Stop once the button is released.

With this, you can automatically send whatever combination of keys to the computer whenever you get a signal on a given pin.

Step 3: Make a big button

Now that we’ve carefully set up all the pieces of our machine, we can bring them together using a giant button. I got one of these. It makes an extremely satisfying “chunk” sound when pressed. The next step was to wire everything up. Here’s a small diagram of how this button works:

Essentially, we want to run a wire from the “push to make” into the Arduino at pin 2, and then a wire from the arduino ground pin to the “common” terminal on the button. Here’s what that looks like all wired up (sorry for the extremely blurry photo):

One note here is that the button itself has an LED on it, so if you were interested you could also wire in some LED stuff but I just didn’t in the end.

I was also very lucky to get a beautiful wooden enclosure built and stained by my wonderful and talented father.

And here it is all finished:

Recap

So, what happens when you push this button?

The digitalRead signal fires on the Arduino, sending ⌘⌃⌥8 as a keyboard signal.
That keyboard combination starts a MacOS “Shortcut” which triggers an AppleScript
The AppleScript searches for the “Accept” button on an inbound FaceTime call and clicks on it.
You talk on FaceTime.

Is it brittle? Yes. Is it hacky? Yes. Does it work? Yes.

Self-hosting Obsidian LiveSync on Kubernetes with Tailscale

Mon, 17 Jun 2024

Recently, I’ve been using Obsidian for note taking. It’s fast, has a bunch of nice features, a decent vim mode, and rich support for community plugins. I also really like the “file over app” philosophy that the current CEO has written about.

I also have been running Kubernetes on a cluster of RaspberryPi computers in my house that I have been using for all sorts of odds and ends. It hosts my chess tournament website that I have written about previously. I also use it as a sync server for the incredible atuin, host a handful of internal-to-the-house apps, and some other things. The cluster runs k3s and uses four Pi computers that I have accumulated over the years, going as far back as model 2B.

One thing I like quite a bit about it is that nothing is exposed to the public internet, except the aforementioned tournament website, which is hidden behind a Cloudflare tunnel. Instead, I use a combination of external-mdns and Tailscale to make things accessible outside the cluster as needed.

Obsidian has a plugin for self-hosted LiveSync, which I really appreciate. I like to host these things myself when possible, especially when the cost of failure is low, like it is here. I had some “fun” getting this set up with my setup and wanted to write about wiring pieces together.

CouchDB

I know absolutely nothing about CouchDB. In fact, I hadn’t heard of it before learning that the plugin in based on it, but I did learn that it is written in Erlang, which is great. So to start off, I had to get CouchDB running in kubernetes.

CouchDB has a helm chart, but I opted to write my own deployment instead. In general, I prefer to have my own yaml lying around so I can put it in source control and make tweaks later.

In any case, the deployment is pretty straightforward. However, there are a couple of gotchas when setting this up from scratch, especially since the documentation is quite sparse.

First, you need to have an admin user and password ready to go via environment variables. I created them as a kubernetes secret and referenced them via secretKeyRef.

Second, after everything has started, you need to go into the running pod and manually create the required databases. This is discussed in the setup documentation, but there are a few additional caveats:

The curl commands in the setup documentation will not work as written because CouchDB will only allow you to run them if you are an administrator. You need to sign your requests. I used the _session auth method and managed to create the required databases.
Setting up CouchDB to operate as a single-node installation isn’t as straightforward as I had hoped. The recommended way to do it is to publish your own Docker image that has a local.ini file bundled inside of it, with the single_node=true flag set in the CouchDB property. This is probably the best way to do it, but I just configured a service and local mdns ingress and used the management GUI to do it manually.

Tailscale

Now that we’ve got CouchDB set up, we need to have some way to communicate with it from Obsidian. One thing that is quite important is that we are able to do so via https; without it, I wouldn’t be able to sync to and from my phone. Tailscale is an amazing piece of technology. It wraps around WireGuard and can make a mesh network out of any number of devices. My pi cluster, computer, and phone are all part of the same Tailscale mesh network, so I can do all sorts of cool stuff like send files between devices or ssh from anywhere without having machines exposed to the public internet.

One relatively recent feature added to Tailscale was the kubernetes operator. This does a couple of nice things for us, like being able to expose a service directly as a “machine” in your Tailscale mesh network (aka tailnet), or even an entire subnet router. I have found that selectively exposing services has been the most straightforward since it can be done just with annotations.

Unlike with CouchDB, I used the helm chart for this one. The kubernetes setup is quite complicated with a lot of moving parts (service accounts, roles and rolebindings, custom resource definitions, etc.). I had tried using the raw yaml directly for awhile, but it’s still somewhat early and things have moved around a bit since I started trying it out.

In any case, the documentation for the simple case is pretty straightforward from Tailscale’s website. There are some additional steps needed in order to get HTTPS set up for a tailnet. The main thing for us is that in order to use HTTPS, we have to know the full tailnet name. This is important when actually setting up the LiveSync, since the tailscale cert command will automatically generate a certificate with the full name and https requests will work as expected.

Additionally, annotating a kubernetes service wasn’t sufficient to generate a certificate. In order to get HTTPS traffic working, I had to use a dedicated ingress, as is outlined in Tailscale documentation. I also had to manually ssh into the pod running tailscale for the given ingress and run tailscale cert manually in order to generate a certificate. My guess is that I had spent too much time mucking around, and something had gone sideways.

Obsidian LiveSync

At this point, there’s a CouchDB instance running in our cluster that is accessible over HTTPS to all nodes in our tailnet, so we are ready to set up the LiveSync plugin. One really nice thing about the plugin is that once you connect it to the CouchDB instance, it can automatically configure the database to have the appropriate configuration and CORS settings etc.

At this point, everything should be set up and sync can be enabled. The URI will be the full name given to our CouchDB ingress. There’s a couple of other really things about this setup:

Each vault goes to its own CouchDB database, which means that it is possible to sync multiple vaults simultaneously through the same instance
“File over app” mentality means that the files are distributed onto each device without being dependent on the database directly. If something goes sideways with CouchDB, it just be deleted and rebuilt from the Obsidian vault directly.

Building a chess application with Phoenix LiveView (Part 2)

Wed, 05 Jun 2024

Now that we have a working API to create and validate moves on a chess board, we can go ahead and turn that into a little chess application using Phoenix LiveView. In this part, we’ll get pieces onto a representation of the board and enable moving them via phx-click events. From there (and possibly in future posts) we can explore other features, like displaying the game’s moves, piece drag and drop, implementing a live game server, or even generating an engine to play against.

Quick note: syntax highlighting is a bit broken for HEEx templates, so I’ve disabled it for now. I have a proposed fix but it may take some time to trickle all the way down to Jekyll and into the blog.

1: The board

Before anything else, we’ll need an empty board state. Tailwind and CSS grid make this pretty straightforward:

defmodule ElchesserWeb.LiveBoard do
  use ElchesserWeb, :live_view

  def render(assigns) do
    ~H"""
    <div class="w-[388px] m-auto left-0 right-0">
      <div class="border border-2 border-zinc-700 grid grid-rows-8 grid-cols-8">
        <%= for rank <- Elchesser.ranks() |> Enum.reverse() do %>
          <%= for file <- Elchesser.files() do %>
            <div class={["w-12 h-12", background(file, rank)]}></div>
          <% end %>
        <% end %>
      </div>
    </div>
    """
  end

  defp background(file, rank) when rem(file + rank, 2) != 0, do: "bg-boardwhite"
  defp background(_, _), do: "bg-boardblack"

end

The main interesting thing going on here is bg-boardwhite and bg-boardblack in the background function. Tailwind allows for custom colors to be added to the theme, so we can go ahead and pick some out so that we can be sure to have some visual consistency (I am using #f2f5f3 for boardwhite and #71828f for boardblack):

2. The pieces

Now, we’ll need to put some pieces on the board. To start, we’ll need some SVG shapes for the pieces. These pieces from Wikipedia by Colin Burnett are very well-known and have a friendly license, so those are good to start.

Making them accessible as icons

A fresh install of Phoenix 1.7+ comes with a handy CoreComponents module, which includes a bunch of nice functional components for getting started. We can use the icon/1 function as inspiration. Let’s take a look at how that works:

  @doc """
  Renders a [Hero Icon](https://heroicons.com).

  Hero icons come in three styles – outline, solid, and mini.
  By default, the outline style is used, but solid an mini may
  be applied by using the `-solid` and `-mini` suffix.

  You can customize the size and colors of the icons by setting
  width, height, and background color classes.

  Icons are extracted from your `assets/vendor/heroicons` directory and bundled
  within your compiled app.css by the plugin in your `assets/tailwind.config.js`.

  ## Examples

      <.icon name="hero-x-mark-solid" />
      <.icon name="hero-arrow-path" class="ml-1 w-3 h-3 animate-spin" />
  """
  def icon(%{name: "hero-" <> _} = assigns) do
    ~H"""
    <span class={[@name, @class]} />
    """
  end

When examining one of the icons in the browser, we see that the hero- classes are registered in tailwind as an svg mask:

// tailwind.config.js
module.exports = {
  // ...
  plugins: [
    // ...
    // Embeds Hero Icons (https://heroicons.com) into your app.css bundle
    // See your `CoreComponents.icon/1` for more information.
    //
    plugin(function ({ matchComponents, theme }) {
      let iconsDir = path.join(__dirname, "./vendor/heroicons/optimized");
      let values = {};
      let icons = [
        ["", "/24/outline"],
        ["-solid", "/24/solid"],
        ["-mini", "/20/solid"],
      ];
      icons.forEach(([suffix, dir]) => {
        fs.readdirSync(path.join(iconsDir, dir)).map((file) => {
          let name = path.basename(file, ".svg") + suffix;
          values[name] = { name, fullPath: path.join(iconsDir, dir, file) };
        });
      });
      matchComponents(
        {
          hero: ({ name, fullPath }) => {
            let content = fs
              .readFileSync(fullPath)
              .toString()
              .replace(/\r?\n|\r/g, "");
            return {
              [`--hero-${name}`]: `url('data:image/svg+xml;utf8,${content}')`,
              "-webkit-mask": `var(--hero-${name})`,
              mask: `var(--hero-${name})`,
              "background-color": "currentColor",
              "vertical-align": "middle",
              display: "inline-block",
              width: theme("spacing.5"),
              height: theme("spacing.5"),
            };
          },
        },
        { values },
      );
    }),
  // ...
  ]
}

So, when you include a <.icon name="hero-arrow-path"/> component, it generates a <span></span> tag that has a mask made up of the contents of the file located at ./vendor/heroicons/optimized/24/outline/arrow-path.svg.

We can use this same exact technique to generate similar <span></span> tags that have the contents of our piece SVGs. First, we need to add a new plugin to our tailwind configuration (this plugin assumes that our piece svgs are stored in assets/pieces):

// tailwind.config.js
module.exports = {
  // ...
  plugins: [
    plugin(function ({ matchComponents, theme }) {
      let piecesDir = path.join(__dirname, "./pieces");
      let values = {};

      let colors = ["white", "black"];

      colors.forEach((color) => {
        fs.readdirSync(path.join(piecesDir, color)).map((file) => {
          let name = `${color}-${path.basename(file, ".svg")}`;
          values[name] = { name, fullPath: path.join(piecesDir, color, file) };
        });
      });

      matchComponents(
        {
          piece: ({ fullPath }) => {
            let content = fs
              .readFileSync(fullPath)
              .toString()
              .replace(/\r?\n|\r/g, "");

            return {
              "background-image": `url('data:image/svg+xml;base64,${Buffer.from(
                content,
              ).toString("base64")}')`,
              display: "inline-block",
              width: theme("spacing.5"),
              height: theme("spacing.5"),
              "background-size": "contain",
            };
          },
        },
        { values },
      );
    }),
  ],
}

This will slurp in all of the pieces under pieces/white and pieces/black and generate mappings for them. Note that we use background-image along with the base64 encoding for these.

From here, we can add a new piece/1 function to our live board:

  attr(:piece, :atom)

  def piece(assigns) do
    ~H"""
    <span class={[piece_name(@piece), @class]} />
    """
  end

  def piece_name(:P), do: "piece-white-pawn"
  def piece_name(:p), do: "piece-black-pawn"
  def piece_name(:N), do: "piece-white-knight"
  def piece_name(:n), do: "piece-black-knight"
  def piece_name(:B), do: "piece-white-bishop"
  def piece_name(:b), do: "piece-black-bishop"
  def piece_name(:R), do: "piece-white-rook"
  def piece_name(:r), do: "piece-black-rook"
  def piece_name(:Q), do: "piece-white-queen"
  def piece_name(:q), do: "piece-black-queen"
  def piece_name(:K), do: "piece-white-king"
  def piece_name(:k), do: "piece-black-king"
  def piece_name(nil), do: ""

Now, we should be able to load in the pieces onto our board based on our game:

defmodule ElchesserWeb.LiveBoard do
  use ElchesserWeb, :live_view

  alias Elchesser.Game

  def mount(_, _, socket) do
    {:ok, socket |> assign(game: Game.new())}
  end

  attr(:game, Game)

  def render(assigns) do
    ~H"""
    <div class="w-[388px] m-auto left-0 right-0">
      <div class="border border-2 border-zinc-700 grid grid-rows-8 grid-cols-8">
        <%= for rank <- Elchesser.ranks() |> Enum.reverse() do %>
          <%= for file <- Elchesser.files() do %>
            <.square square={Game.get_square(@game, {file, rank})}>
          <% end %>
        <% end %>
      </div>
    </div>
    """
  end

  attr(:square, :map)

  def square(assigns) do
    ~H"""
    <div class={["w-12 h-12 text-center", background(@square.file, @square.rank)]}>
      <.square_contents piece={@square.piece} />
    </div>
    """
  end

  attr(:piece, :atom)

  def square_contents(%{piece: nil} = assigns), do: ~H""

  def square_contents(assigns) do
    ~H"""
    <.piece piece={@piece} class="w-[45px] h-[45px] mt-[1.5px]" />
    """
  end

  defp background(file, rank) when rem(file + rank, 2) != 0, do: "bg-boardwhite"
  defp background(_, _), do: "bg-boardblack"
end

There’s a few changes here to highlight. First, we added a mount/3 call. This is the entrypoint to our live view, and we use it to initialize our new game. Second, we broke out the square into a function component. This will become more important later when we add click handlers to the square itself. Finally, we include a square_contents/1 function component to include what should go into the square itself. All this together looks like this:

3. Selecting a piece to move

Now we can really take advantage of Phoenix LiveView by tracking clicks on squares and changing our board state. The first thing to do is to add click tracking on the squares themselves:

  attr(:square, Square)
  attr(:click_type, :atom, values: [:select, :move])

  def square(assigns) do
    ~H"""
    <div
      class={["w-12 h-12 text-center", background(@square.file, @square.rank)]}
      phx-click="square-click"
      phx-value-file={@square.file}
      phx-value-rank={@square.rank}
      phx-value-type={@click_type}
    >
      <.square_contents piece={@square.piece} />
    </div>
    """
  end

When clicked, each square will now send an event up to our live view server with the name square-click and data in the form of something like %{"file" => "a", "rank" => "1", "type" => "select"} (for more, see phx-click documentation). Now, we need to set up an event handler for this event. Since we aren’t going to be implementing drag-and-drop functionality in this post, we’ll want to have two separate handlers: one for selecting a piece, and one for actually moving it.

When we select a piece, we’ll want to get all legal moves for that piece and highlight them on the board. Then, when we move the piece, we’ll need to update the board state as expected and remove the highlights.

Let’s start with piece selection:

  def handle_event("square-click", %{"file" => f, "rank" => r, "type" => "select"}, socket) do
    loc = {String.to_integer(f), String.to_integer(r)}
    {:noreply, socket |> on_select_click(loc)}
  end

  defp on_select_click(socket, loc) do
    square = Game.get_square(socket.assigns.game, loc)

    socket
    |> assign(
      move_map:
        Square.legal_moves(loc, socket.assigns.game)
        |> Enum.reduce(%{}, fn move, acc -> Map.put(acc, move.to, move) end)
    )
    |> assign(click_type: :move)
    |> assign(
      active_square:
        if(Piece.color_match?(square.piece, socket.assigns.game.active), do: square, else: nil)
    )
  end

Now we need to update our board state based based on the new active_square and move_map attributes that we’ve calculated from our click:

  attr(:game, Elchesser.Game)
  attr(:click_type, :atom, values: [:select, :move])
  attr(:active_square, Elchesser.Square, default: nil)

  def render(assigns) do
    ~H"""
    <div class="w-[388px] m-auto left-0 right-0">
      <div class="border border-2 border-zinc-700 grid grid-rows-8 grid-cols-8">
        <%= for rank <- Elchesser.ranks() |> Enum.reverse() do %>
          <%= for file <- Elchesser.files() do %>
            <.square
              square={Elchesser.Game.get_square(@game, {file, rank})}
              click_type={@click_type}
              highlight={Map.has_key?(@move_map, {file, rank})}
              active={not is_nil(@active_square) && @active_square.loc == {file, rank}}
            />
          <% end %>
        <% end %>
      </div>
    </div>
    """
  end

Now, we can re-style our squares after a piece gets selected. First, let’s highlight our active square and forward the highlight attribute down to the square_contents/1 component.

  attr(:square, Square)
  attr(:click_type, :atom, values: [:select, :move])
  attr(:highlight, :boolean, default: false)
  attr(:active, :boolean, default: false)

  def board_square(assigns) do
    ~H"""
    <div
      class={[
        "w-12 h-12 text-center",
        background(@square.file, @square.rank),
        @active && "bg-purple-200/60"
      ]}
      phx-click="square-click"
      phx-value-file={@square.file}
      phx-value-rank={@square.rank}
      phx-value-type={@click_type}
    >
      <.square_contents piece={@square.piece} highlight={@highlight} />
    </div>
    """
  end

Next, let’s highlight squares in our move_map. We’ll need to handle cases when the target square is empty, and when it already has a piece:

  attr(:piece, :atom)
  attr(:highlight, :boolean, default: false)

  # Yes piece, no highlight
  def square_contents(%{piece: _, highlight: false} = assigns) do
    ~H"""
    <.piece piece={@piece} class="w-[45px] h-[45px] mt-[1.5px]" />
    """
  end

  # No piece, yes highlight
  def square_contents(%{piece: nil, highlight: true} = assigns) do
    ~H"""
    <span class="w-[45px] h-[45px] mt-[1.5px] inline-block rounded-full border-2 border-zinc-600" />
    """
  end

  # Yes piece, yes highlight
  def square_contents(%{piece: _, highlight: true} = assigns) do
    ~H"""
    <div class="relative">
      <span class="absolute w-[45px] h-[45px] mt-[1.5px] inline-block rounded-full border-2 border-zinc-600" />
      <.piece piece={@piece} class="w-[45px] h-[45px] mt-[1.5px]" />
    </div>
    """
  end

  # No piece, no highlight
  def square_contents(%{piece: nil} = assigns), do: ~H""

With all of this, clicking on a square that has a piece with legal moves should highlight those moves on our board:

4. Making moves

Finally, we can implement making moves on our chess board. In part one, we wrote a Game.move/2 function which returns {:ok, game}, or {:error, reason}. We can use the results of this function to update our board. We’ll use the following logic:

Valid moves should update the board state properly
If we try to move a piece onto a square that is occupied by a friendly piece, we should instead select that new piece
Otherwise, we should clear out our “selected” state and put the board back to normal

Fortunately, pattern matching makes this fairly straightforward:

  def handle_event("square-click", %{"file" => f, "rank" => r, "type" => "move"}, socket) do
    loc = {String.to_integer(f), String.to_integer(r)}

    socket =
      case Game.move(socket.assigns.game, Map.get(socket.assigns.move_map, loc)) do
        {:ok, game} ->
          socket
          |> assign(game: game)
          |> on_move_click()

        {:error, err} when err in [:invalid_to_color, :invalid_from_color, :no_move_provided] ->
          on_select_click(socket, loc)

        {:error, _} ->
          on_move_click(socket)
      end

    {:noreply, socket}
  end

  defp on_move_click(socket) do
    socket
    |> assign(move_map: %{})
    |> assign(click_type: :select)
    |> assign(active_square: nil)
  end

And that should do it! Now we have a fully working game of chess implemented with Elixir and playable via LiveView.

From here there are a lot of things that can be done, like hooking up a GenServer to actually play games, adding additional features to our board like drag and drop to move, showing the game history, and more.

Building a chess application with Phoenix LiveView (Part 1)

Fri, 31 May 2024

Recently I have been doing some more explorations of Elixir and Phoenix. After watching this great video about hand-implementing a chess engine, I got inspired to try and write my own implementations for the rules of chess and my own Chessboard layout for the web with Phoenix LiveView. I want to note that I’m not a great chess programmer or Elixir expert at this point. For expert takes on things, you might try the Chess programming wiki, or the Elixir forums. I wanted to share my progress with that here in an occasionally recurring series as I add more bits and pieces to this implementation, such as writing my own (comparatively weak) engine, or adding live play functionality. But before we get to any of that interesting stuff, we first need to get a mostly working model for the rules of chess. There are a few existing libraries (most notably chex), but I still wanted to roll my own for easier integration with LiveView. You can play around with the progress of this here.

1. Representing the game

The first need we need is a game state, and we can reach naturally for the Elixir struct to encode our information. The Game struct needs to keep track of a number of things that represent the game state which we will get to, but the most important is the current board state.

One notable thing about Elixir is that its List implementations are in fact linked lists, as opposed to arrays. This means that random access is effectively O(n) as opposed to O(1) that you might find in other languages. There are some good reasons for this in the language, but it does mean that some standard things about board state (like representing the board as a 64-length array) is not really optimal for our case.

Instead, I opted to use an elixir Map of the form %{{number(), number()} => Square.t()}. This means that each key is the location of each square, represented as a tuple of file, rank, and each value is represented as a Square struct.

The `Square` struct

Each Square contains not only the piece sitting on it (or nil) but also another struct called Sees, which contains all the other squares that can be “seen” from this square, keyed by the direction (along with knight moves and combination of all of them):

defmodule Elswisser.Square.Sees do
  defstruct up: [],
            down: [],
            left: [],
            right: [],
            up_right: [],
            up_left: [],
            down_left: [],
            down_right: [],
            knight: [],
            all: MapSet.new()
end

defmodule Elchesser.Square do
  alias Elchesser.Square.Sees

  defstruct file: nil,
            rank: nil,
            loc: {},
            piece: nil,
            sees: %Sees{}
end

Additionally, I implemented the Inspect protocol for the square for debugging purposes to draw the square on the board along with all the squares that it sees. Using unicode pipe characters allows us to draw a nice representation of each square in the terminal. For example:

e4 - ' '
  ┌───┬───┬───┬───┬───┬───┬───┬───┐
8 │ ✕ │   │   │   │ ✕ │   │   │   │
  ├───┼───┼───┼───┼───┼───┼───┼───┤
7 │   │ ✕ │   │   │ ✕ │   │   │ ✕ │
  ├───┼───┼───┼───┼───┼───┼───┼───┤
6 │   │   │ ✕ │ ✕ │ ✕ │ ✕ │ ✕ │   │
  ├───┼───┼───┼───┼───┼───┼───┼───┤
5 │   │   │ ✕ │ ✕ │ ✕ │ ✕ │ ✕ │   │
  ├───┼───┼───┼───┼───┼───┼───┼───┤
4 │ ✕ │ ✕ │ ✕ │ ✕ │ ◯ │ ✕ │ ✕ │ ✕ │
  ├───┼───┼───┼───┼───┼───┼───┼───┤
3 │   │   │ ✕ │ ✕ │ ✕ │ ✕ │ ✕ │   │
  ├───┼───┼───┼───┼───┼───┼───┼───┤
2 │   │   │ ✕ │ ✕ │ ✕ │ ✕ │ ✕ │   │
  ├───┼───┼───┼───┼───┼───┼───┼───┤
1 │   │ ✕ │   │   │ ✕ │   │   │ ✕ │
  └───┴───┴───┴───┴───┴───┴───┴───┘
    a   b   c   d   e   f   g   h

The `Move` struct

Along with Square, another key component is the Move. This struct contains relevant information needed for computing and encoding an individual chess move. Most importantly, it contains from and to board locations, the piece being moved, and additional information to be figured out later (like castling, promotions, etc.):

defmodule Elchesser.Move do
  defstruct from: {},
            to: {},
            piece: nil,
            capture: nil,
            promotion: nil,
            castle: false,
            checking: nil
end

2. Representing pieces

Now that we have the outlines our game board, move, and square structs, we can get started with actually implementing pieces. For each piece, we need a way to get all of squares that the given piece can move to based on where it is right now. There are really four different types of pieces to consider. Rooks, bishops, and queens can be implemented the same way. Knights are similar to those but have different move patterns. Then there are pawns and kings.

First, we can outline a @behaviour that each piece will follow:

defmodule Elchesser.Piece do
  alias Elchesser.{Square, Game, Move}

  @doc """
  Generates psuedo-legal moves for a given piece type.
  """
  @callback moves(Square.t(), Game.t()) :: [Move.t()]
  @callback attacks(Square.t(), Game.t()) :: [Move.t()]
end

Rooks, bishops, queens

All three of these pieces move in effectively the same way: they slide along whatever directions they are allowed to move until they bump into the edge of the board, an opposing piece, or a friendly piece. For this, we can take advantage of the relevant pre-computed sees fields:

  @spec move_range(%Square{}, %Game{}, Square.Sees.t()) :: [Move.t()]
  def move_range(%Square{} = square, %Game{} = game, direction) do
    get_in(square.sees, [Access.key!(direction)])
    |> Enum.reduce_while([], fn {file, rank}, acc ->
      s = Game.get_square(game, {file, rank})

      case friendly?(square.piece, s.piece) do
        true -> {:halt, acc}
        false -> {:halt, [Move.from(square, {s.file, s.rank}, capture: true) | acc]}
        nil -> {:cont, [Move.from(square, {s.file, s.rank}) | acc]}
      end
    end)
    |> Enum.reverse()
  end

From here, implemeting each of the sliding pieces becomes fairly straightforward. For example, with a bishop:

defmodule Elchesser.Piece.Bishop do
  alias Elchesser.{Square, Game, Piece}

  @behaviour Piece

  @impl true
  def moves(%Square{} = square, %Game{} = game) do
    for d <- [:up_right, :up_left, :down_left, :down_right], reduce: [] do
      acc -> [Square.move_range(square, game, d) | acc]
    end
    |> List.flatten()
  end

  @impl true
  def attacks(square, game), do: moves(square, game)
end

Rooks and queens follow the some logic with different directions. Because these pieces also attack all the squares they can move to, attacks and moves are the same.

Knights

Knights are similar to sliding pieces, but they can “jump” over pieces as well. So instead of scanning along a direction, we check all of the knight sees squares from our struct, and use that to generate moves and attacks:

defmodule Elchesser.Piece.Knight do
  alias Elchesser.{Square, Game, Piece, Move}

  @behaviour Piece

  @impl true
  def moves(%Square{} = square, %Game{} = game) do
    Enum.reduce(square.sees.knight, [], fn {file, rank}, acc ->
      s = Map.get(game.board, {file, rank})

      case Piece.friendly?(square.piece, s.piece) do
        true -> acc
        false -> [Move.from(square, {s.file, s.rank}, capture: true) | acc]
        nil -> [Move.from(square, {s.file, s.rank}) | acc]
      end
    end)
  end

  @impl true
  def attacks(square, game), do: moves(square, game)
end

Pawns

Pawns are more difficult than the pieces that have been implemented so far for a few reasons:

They can move two squares from their starting position and one square otherwise.
They attack diagonally instead of straight ahead.
They have to respect the rules of en passant.
They can promote to another piece if they reach the back rank.

Elixir’s function head pattern matching makes this easier to handle. We can start by generating the squares that the pawns attack (we use the :P atom to represent white pawns and :p to represent black pawns to be consistent with FEN notation):

defmodule Elchesser.Piece.Pawn do
  alias Elchesser.{Square, Game, Move, Piece}

  @behaviour Piece
  def moves(_, _), do: []

  @impl true
  def attacks(%Square{} = square, _), do: attacks(square) |> Enum.map(&Move.from(square, &1))

  defp attacks(%Square{piece: :P, rank: rank, file: file}) do
    [{file + 1, rank + 1}, {file - 1, rank + 1}]
    |> Enum.filter(&Square.valid?/1)
  end

  defp attacks(%Square{piece: :p, file: file, rank: rank}) do
    [{file + 1, rank - 1}, {file - 1, rank - 1}]
    |> Enum.filter(&Square.valid?/1)
  end
end

Now, we need to make moves. Depending on where the pawn is on the board, we can use a number of candidate moves and then whittle them down based on various conditions. We can use pattern matching once again to generate candidate moves, along with a flag for whether or not the pawn should be promoted:

defmodule Elchesser.Piece.Pawn do
  # ... 
  @impl true
  def moves(%Square{piece: :P, rank: 2, file: file} = square, %Game{} = game),
    do: moves(square, game, [{file, 3}, {file, 4}], false)

  def moves(%Square{piece: :P, rank: rank, file: file} = square, %Game{} = game),
    do: moves(square, game, [{file, rank + 1}], rank + 1 == 8)

  def moves(%Square{piece: :p, rank: 7, file: file} = square, %Game{} = game),
    do: moves(square, game, [{file, 6}, {file, 5}], false)

  def moves(%Square{piece: :p, rank: rank, file: file} = square, %Game{} = game),
    do: moves(square, game, [{file, rank - 1}], rank - 1 == 1)
  # ... 
end

Then, once we have the candidate moves, we can whittle them down based on the rules described above:

defmodule Elchesser.Piece.Pawn do
  # ...
  defp moves(square, game, candidates, promotion) do
    m =
      candidates
      # moves are only valid if the candidate square is empty
      |> Enum.filter(fn candidate -> Game.get_square(game, candidate) |> Square.empty?() end)
      |> Enum.map(fn {file, rank} ->
        Move.from(square, {file, rank}, promotion: promote(promotion, square.piece))
      end)

    a =
      attacks(square)
      # attacks are only valid if the candidate square is occupied by an enemy
      # piece or the current en passant square of the given game state
      |> Enum.filter(fn s ->
        sq = Game.get_square(game, s)
        Piece.enemy?(square.piece, sq.piece) || en_passant?(sq, game)
      end)
      |> Enum.map(fn s ->
        sq = Game.get_square(game, s)
        ep? = en_passant?(sq, game)

        capture =
          cond do
            ep? and square.piece == :P -> :p
            ep? and square.piece == :p -> :P
            true -> sq.piece
          end

        Move.from(square, s, capture: capture, promotion: promote(promotion, square.piece))
      end)

    Enum.concat(m, a)
  end
  # ...

  defp en_passant?(%Square{} = square, %Game{} = game) do
    Square.empty?(square) && Square.eq?(square, game.en_passant)
  end
end

This does rely on the en passant information stored in the game state. That will be discussed in much more detail in part three when we update the game state after making moves.

Kings

Kings are even more complex than pawns:

Kings can possibly castle either kingside or queenside depending on the state of the game.
Kings cannot move into check.

Both of these rely on game state, which again will be discussed a bit later. To start, we can generate a list of all possible squares that the king can attack. kings can move one square in any direction, so an Elixir for comprehension is a good fit for candidate move generation. From there, we can apply similar logic to our previous piece moves to check for friendly pieices, captures, etc:

defmodule Elchesser.Piece.King do
  # ...
  def attacks(%Square{file: file, rank: rank}) do
    for(f <- -1..1, r <- -1..1, not (f == 0 and r == 0), do: {file + f, rank + r})
    |> Enum.filter(&Square.valid?/1)
    |> Enum.reduce([], fn {file, rank}, acc ->
      s = Map.get(game.board, {file, rank})

      case Piece.friendly?(square.piece, s.piece) do
        true -> acc
        false -> [Move.from(square, {s.file, s.rank}, capture: true) | acc]
        nil -> [Move.from(square, {s.file, s.rank}) | acc]
      end
    end)
  end
  # ...
end 

From there, we need to add kingside and queenside castling (in the event that castling is legal from the given position), and then remove any moves that might put the king in check.

First, castling. There are three conditions that have to be met in order for the king to be able to castle in a given direction:

It must be legal according the game state (i.e. the king or relevant rook must not have moved)
All squares between the king and relevant rook must be empty
No squares between the king and relevant rook can be attacked by an enemy piece (the king cannot move through or into check)

In order to do this, we’ll need to have a way to check if a given square is being attacked. To do this, we can figure out where all the pieces are for a given color, and then figure out which squares those pieces attack.

First, let’s figure out where all the pieces for a given color are located:

defmodule Elchesser.Board do
  def white_occupied(%Game{board: board}) do
    Map.filter(board, fn {_, square} -> Square.white?(square) end)
    |> Map.values()
  end

  def black_occupied(%Game{board: board}) do
    Map.filter(board, fn {_, square} -> Square.black?(square) end)
    |> Map.values()
  end
end

Then, let’s get all the unique locations attacked by those pieces:

defmodule Elchesser.Board do
  def white_attacks(%Game{} = game) do
    white_occupied(game)
    |> Enum.map(&Square.attacks(&1, game))
    |> List.flatten()
    |> Enum.uniq()
    |> Enum.map(& &1.to)
  end

  def black_attacks(%Game{} = game) do
    black_occupied(game)
    |> Enum.map(&Square.attacks(&1, game))
    |> List.flatten()
    |> Enum.uniq()
    |> Enum.map(& &1.to)
  end
end

Then, using this information, we can evaluate the legality of all of our castling rules. This snippet is for castling kingside for the white king, but can be extended to go queenside, and for the black king:

defmodule Elchesser.Piece.King do
  # ...
  # handle the case where castling is illegal by the game rules
  defp maybe_castle_kingside(%Square{piece: piece}, %Game{castling: c}, _)
       when not is_map_key(c.map, piece),
       do: []

  # check that castling is legal for the given position
  defp maybe_castle_kingside(%Square{piece: :K} = square, %Game{} = game, attacks) do
    through_squares = [{?f, 1}, {?g, 1}] |> Enum.map(&Game.get_square(game, &1))

    if can_castle?(through_squares, attacks),
      do: [Move.from(square, {?g, 1}, castle: true)],
      else: []
  end
  # ...
  
  # Going kingside has the same through and attacked squares, but when castling
  # queenside, the b-file can be attacked, so we have the two function heads.
  defp can_castle?(through_squares, attacks),
    do: can_castle?(through_squares, through_squares, attacks)

  defp can_castle?(empty_through, attack_through, attacks) do
    empty? = Enum.all?(empty_through, &Square.empty?/1)

    attacked? =
      attacks |> Enum.map(&Square.from/1) |> Enum.any?(&(&1 in attack_through))

    empty? and not attacked?
  end
end

Now we can put all this together:

defmodule Elchesser.Piece.King do
  # ...
  # Note this is the private method shared between the black and white kings.
  # The difference would be which set of attacks are fed into the function
  defp moves(%Square{} = square, %Game{} = game, %MapSet{} = attacks) do
    # starting with all the attacked squares
    attacks(square, game) 
    # add kingside castling if it's legal
    |> Enum.concat(maybe_castle_kingside(square, game, attacks)) 
    # add queenside castling if it's legal
    |> Enum.concat(maybe_castle_queenside(square, game, attacks))
    # filter out all moves where the given square is attacked by an enemy piece
    |> Enum.reject(&MapSet.member?(attacks, &1.to))
  end
  # ...
end 

3. Making moves

Finally, we have a working implementations of all the pieces. We need to be able to make moves on the board and have them update our game’s internal state. The internal state has to keep track of a lot of different things. The main ones come from FEN notation: board state, active color, castling rights, en passant, and the halfmove and fullmove clocks. Since Elixir is an immutable language, making a move will return a new game struct with all the fields updated.

Validating moves

The first part of making a move is ensuring that the proposed move is valid. A move cannot originate from an empty square, and players cannot move out of order. Pieces must respect the general rules of the game. We can re-use some of our previously implemented code to make all of this happen. Square.legal_locs/2 is the same as Square.legal_moves/2 implemented in the above section with kings, just with the move mapped to the .to fields in the move struct.

In order to write these validators, I took advantage of Elixir’s beautiful with/1 method. Each validator flows down and returns either a boolean, or an error atom. This gets fed into a little convenience or_/1 method which returns either :ok, or {:error, reason}. This allows for a nice little block of readable validations:

defmodule Elchesser.Game
  # ...
  defp ensure_valid_move(%Game{} = game, %Move{} = move) do
    with from <- Game.get_square(game, move.from),
         to <- Game.get_square(game, move.to),
         :ok <- not Square.empty?(from) |> or_(:empty_square),
         :ok <- (game.active == Board.color_at(game, from)) |> or_(:invalid_from_color),
         :ok <- (game.active != Board.color_at(game, to)) |> or_(:invalid_to_color),
         :ok <- (move.to in Square.legal_locs(from, game)) |> or_(:invalid_move) do
      :ok
    end
  end
  # ...
  @spec or_(boolean(), atom()) :: :ok | {:error, atom()}
  defp or_(true, _), do: :ok
  defp or_(false, reason), do: {:error, reason}
  # ...
end

As an aside, this is the kind of thing that really makes Elixir a joy to work with compared to other languages.

Making moves in the board

Now that we have ensured that our moves our valid, we can update our board state. Making a move has a few possible steps:

The origin piece has to be picked up
The piece has to be moved to its destination, optionally castling
If the move is a castle, we have to make sure the king and the rook are moved.
If the move is a promotion, the pawn needs to be replaced with the promotion piece.

Note that this is a pseudo-legal move; we are relying on our move validator in step one above to make sure that the move is legal before making it to this step. with/1 makes this a snap as well:

defmodule Elchesser.Board do
  # ...
  @spec move(Elchesser.Game.t(), Elchesser.Move.t()) ::
          {:ok, {Move.t(), Game.t()}} | {:error, atom()}
  def move(%Game{} = game, %Move{} = move) do
    with {:ok, {piece, game}} <- move_from(game, move.from),
         {:ok, {capture, game}} <- move_to(game, move.to, piece),
         {:ok, game} <- castle(game, move),
         {:ok, game} <- promote(game, move) do
      check = Game.Check.opponent_in_check?(game)

      move = %{
        move
        | checking: if(check == true, do: :check, else: nil),
          capture: capture,
          piece: piece
      }

      move = %{move | san: Move.san(move)}

      {:ok, {move, game}}
    end
  end
  # ...
end

Moving pieces with `move_from/2` and `move_to/3`

When doing the actual moves themselves, we can take advantage of the nice Map.get_and_update/3. move_from/2 updates the board at the given square and ensures that a piece is present there, failing with the :empty_square atom if not.

def move_from(%Game{board: board} = game, loc) do
  case Map.get_and_update(board, loc, fn current ->
          {current, %Square{current | piece: nil}}
        end) do
    {%Square{piece: nil}, _} -> {:error, :empty_square}
    {%Square{piece: p}, board} -> {:ok, {p, %Game{game | board: board}}}
  end
end

move_to/3 does basically the same thing in reverse, just making sure that we aren’t putting our piece on a square that’s already occupied by a friendly piece.

def move_to(%Game{board: board} = game, loc, piece) do
  {%Square{piece: capture}, board} =
    Map.get_and_update(board, loc, fn current ->
      {current, %Square{current | piece: piece}}
    end)

  cond do
    Piece.friendly?(piece, capture) -> {:error, :invalid_to_color}
    true -> {:ok, {capture, %Game{game | board: board}}}
  end
end

Castling

For castling, we can enumerate all possible cases (there are only four):

def castle(game, %Move{castle: false}), do: {:ok, game}

def castle(%Game{} = game, %Move{to: to}) do
  move =
    case to do
      {?g, 1} -> Move.from({?h, 1, :R}, {?f, 1})
      {?g, 8} -> Move.from({?h, 8, :r}, {?f, 8})
      {?c, 1} -> Move.from({?a, 1, :R}, {?d, 1})
      {?c, 8} -> Move.from({?a, 8, :r}, {?d, 8})
    end

  with {:ok, {_, game}} <- move(game, move) do
    {:ok, game}
  end
end

Promotion

Promotion works very similarly to move_to/3. We use Map.get_and_update/3 to update the pawn in place:

def promote(game, %Move{promotion: nil}), do: {:ok, game}

def promote(%Game{board: board} = game, %Move{to: to, promotion: promotion}) do
  with {_, board} <-
          Map.get_and_update(board, to, fn current ->
            {current, %Square{current | piece: promotion}}
          end) do
    {:ok, %Game{game | board: board}}
  end
end

Updating game state

Now that we have valid moves and a way to update our board state, we can finally update the game state:

defmodule Elchesser.Game do
  # ...
  def move(%Game{} = game, %Move{} = move) do
    with :ok <- ensure_valid_move(game, move),
         {:ok, {move, game}} <- Board.move(game, move) do
      game =
        game
        |> flip_color()
        |> set_in_check()
        |> add_move(move)
        |> add_fen()
        |> add_capture(move.capture)
        |> set_castling_rights(move)
        |> set_en_passant(move)
        |> set_half_move_count(move)
        |> set_full_move_count()

      {:ok, game}
    end
  # ...
end

There isn’t a ton of very interesting stuff here, just a lot of housekeeping. But, now with this, we should finally have a way of playing a game of chess in our program:

game = Game.new()

{:ok, game} = Game.move(game, Move.from({?e, 2, :P}, {?e, 4}))
{:ok, game} = Game.move(game, Move.from({?e, 7, :p}, {?e, 5}))
{:ok, game} = Game.move(game, Move.from({?d, 2, :P}, {?d, 4}))
{:ok, game} = Game.move(game, Move.from({?e, 5, :p}, {?d, 4}))

Now that we have this, we can get to the interesting part: hooking it into a Phoenix LiveView.

Auto-focus after adding a new row in an editable data table

Thu, 11 Apr 2024

I have been messing around a bit with NextJS for a little side project. The main interface in the project have been editable data tables (or, <td> elements with <input> slapped in the middle). For whatever reason, I ended up using the tanstack/react-table library as the core building block.

After using these tables for a few weeks, I wanted to make a small change: after adding a new role to a given table, I wanted to focus on the first column of the newly created row.

The first two parts of this post go over some Tanstack table basics: setting up editable table cells and adding/removing rows. If you want to skip right on over to the focusing bit, you can find that in Step 3 below. The full working example is available in this repository.

Let’s start with something that looks very similar to the basic tanstack table:

import * as React from "react";
import {
  createColumnHelper,
  flexRender,
  getCoreRowModel,
  useReactTable,
} from "@tanstack/react-table";

const helper = createColumnHelper();

const columns = [
  helper.accessor("one", { header: "Column One" }),
  helper.accessor("two", { header: "Column Two" }),
  helper.accessor("three", { header: "Column Three" }),
];

const defaultData = [
  { one: "ONE", two: "TWO", three: "THREE" },
  { one: "one", two: "two", three: "three" },
];

function App() {
  const [data, setData] = React.useState(defaultData);

  const table = useReactTable({
    data,
    columns,
    getCoreRowModel: getCoreRowModel(),
  });

  return (
    <div className="border m-2 rounded-md relative">
      <table className="w-full overflow-auto">
        <thead className="border-b-2">
          {table.getHeaderGroups().map((group) => (
            <tr key={group.id}>
              {group.headers.map((header) => (
                <th key={header.id} className="py-2 border-1 first:border-0">
                  {flexRender(
                    header.column.columnDef.header,
                    header.getContext()
                  )}
                </th>
              ))}
            </tr>
          ))}
        </thead>
        <tbody>
          {table.getRowModel().rows.map((row) => (
            <tr key={row.id} className="mt-4">
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id} className="p-2 border-1 first:border-0">
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

export default App;

Aside from a small difference in the data model and the inclusion of Tailwind, this is very similar to the example.

Step 1: making the inputs editable

Tanstack allows you to pass a cell when defining your columns, which lets us have control over how a given cell is rendered (docs). This lets us write a custom component for handling cell inputs. This component takes in props defined by Tanstack itself.

Here’s something to get started with:

function EditableCellInput({ getValue, row, column, table }) {
  const [value, setValue] = React.useState(getValue());

  return (
    <input
      className="table-cell w-full px-2 py-1"
      value={value}
      onChange={(e) => setValue(e.target.value)}
      onBlur={() => table.options.meta.updateRow(row.index, column.id, value)}
    />
  );
}

This is mostly normal React form state management. The only interesting thing to comment on is the onBlur handler, which hooks back into the overall Tanstack table. Tanstack has a notion of a “table meta” which lets you attach arbitrary bits and pieces to your table definition and then access them later. We can add this into our useReactTable definition from the top:

const table = useReactTable({
  data,
  columns,
  getCoreRowModel: getCoreRowModel(),
  meta: {
    updateRow: (rowIdx, columnId, value) => {
      setData((data) =>
        data.map((row, idx) =>
          idx === rowIdx ? { ...row, [columnId]: value } : row
        )
      );
    },
  },
});

At this point, we need to modify our column definitions to have them render the new custom cell component. Note that this component is actually the result of that flexRender() call, which means that the result will appear inside of the <td>:

const columns = [
  helper.accessor("one", { header: "Column One", cell: EditableCellInput }),
  helper.accessor("two", { header: "Column Two", cell: EditableCellInput }),
  helper.accessor("three", { header: "Column Three", cell: EditableCellInput }),
];

Here’s what we should end up with:

Step 2: adding and removing rows

Adding new row

Now we need to be able to add and remove rows from our table. To add a new row, we’ll want to add a table footer which includes a button to add a row, along with a new table meta method to push that new row into the bottom of our state.

First, let’s add the footer:

function App() {
  // ...
  return (
    // ...
    <tfoot className="border-t">
      <tr>
        <th colSpan={table.getCenterLeafColumns().length}>
          <div className="float-right mr-4 my-2">
            <button
              className="text-sm font-light"
              onClick={table.options.meta.addRow}
            >
              Add New +
            </button>
          </div>
        </th>
      </tr>
    </tfoot>
    // ...
  );
}

Now, let’s add the addRow function to our table definition:

const table = useReactTable({
  // ...
  meta: {
    addRow: () => {
      setData((data) => [...data, { one: "", two: "", three: "" }]);
    },
    updateRow: (rowIdx, columnId, value) => {...},
  },
})

This function updates the internal table’s data state to include a new row of all blanks.

Removing a row

In order to remove a row, we will add a display column which will serve as a button that, when clicked, will trigger a new removeRow method from the table meta, similar to addRow above.

First, let’s add a component to serve as the remove button:

function RemoveButton({ row, table }) {
  return (
    <button
      className="font-mono font-semibold text-red-600 text-xs align-middle"
      onClick={() => table.options.meta.removeRow(row.index)}
    >
      x
    </button>
  );
}

Just like the EditableCellInput, this table will receive props from tanstack directly, allowing us to reference the table and row object.

Next, let’s use that component to add a new display column:

const columns = [
  helper.accessor("one", { header: "Column One", cell: EditableCellInput }),
  helper.accessor("two", { header: "Column Two", cell: EditableCellInput }),
  helper.accessor("three", { header: "Column Three", cell: EditableCellInput }),
  helper.display({ id: "remove", cell: RemoveButton }),
];

Finally, let’s add in the new method to the table meta:

const table = useReactTable({
  // ...
  meta: {
    addRow: () => {...},
    updateRow: (rowIdx, columnId, value) => {...},
    removeRow: (rowIdx) => {
      setData((data) => data.filter((_, idx) => idx !== rowIdx));
    },
  },
})

Here’s a gif of everything so far:

Step 3: auto-focus new rows when added

Finally, we get to the whole point of this post.

Refs

Refs are mutable properties that get attached to components but don’t cause re-renders when they are changed. According to the documentation:

When you want a component to “remember” some information, but you don’t want that information to trigger new renders, you can use a ref.

Managing something like focus is not directly in the purview of React. Instead, React gives us escape hatches which we can use to tie non-React parts of the browser ecosystem into the React environment. For our purposes, we will use a ref. The first example in the React documentation shows almost precisely what we want to do: click a button to focus an input:

import { useRef } from "react";

export default function Form() {
  const inputRef = useRef(null);

  function handleClick() {
    inputRef.current.focus();
  }

  return (
    <>
      <input ref={inputRef} />
      <button onClick={handleClick}>Focus the input</button>
    </>
  );
}

However, our use case is more complicated: ref is generated via the useRef hook, and hooks are only allowed to be called once per component. Our state, however, is an array of objects. React’s documentation is quite clear here:

… Hooks must only be called at the top-level of your component. You can’t call useRef in a loop, in a condition, or inside a map() call.

React has a way around this limitation.

Ref callbacks

The ref attribute on a component can take a callback function which takes as an argument the DOM node that is attached to the component at hand. The React documentation has a handy example of using a ref callback to handle lists by maintaining a separate Map.

We can use a similar basic concept, but we have a few additional complications. First, we’ll need to have our ref be computed when we draw our table. We can manage this in the same way as described in the React documentation: we can use a Map<string, HTMLElement> as the type of the value inside of our ref, and then update it using a ref callback.

function App() {
  const ref = React.useRef(new Map());
  // ...

  return (
    // ...
    <tbody>
      {table.getRowModel().rows.map((row, rowIdx) => (
        <tr key={row.id} className="mt-4">
          {row.getVisibleCells().map((cell, cellIdx) => (
            <td key={cell.id} className="p-2 border-l first:border-0">
              {flexRender(cell.column.columnDef.cell, {
                ...cell.getContext(),
                cellRef: (node) => {
                  const map = ref.current;
                  if (node) {
                    map.set(`${rowIdx}-${cellIdx}`, node);
                  } else {
                    map.delete(`${rowIdx}-${cellIdx}`);
                  }
                },
              })}
            </td>
          ))}
        </tr>
      ))}
    </tbody>
    // ...
  );
}

There are a few changes here worth discussing. First, we establish our new ref with the useRef hook, and initialize it’s .current value to an empty Map. One thing to note is that when calling .get() on a map, keys are compared using ===, so we aren’t able to use an array as our key type, because [0, 0] !== [0, 0]. This is in contract to a language like Python, where we could use a tuple.

In any case, we next change how the inner contents of a cell are rendered. Remember in part one we used flexRender()? Here, we do the same but instead of just passing in the cell’s context to our component, we also pass a new cellRef prop. This prop has the shape of a ref callback function. Now we have to change our EditableCellInput to know how to handle it:

function EditableCellInput({ getValue, row, column, table, cellRef }) {
  // ...
  return (
    <input
      ref={cellRef}
      // ...
    />
  );
}

Now, whenever we render the table, any EditableCellInput cells that get rendered will have their attached <input /> elements show up as values in our ref variable, and we can get them at-will via a Map.get. There are two last things we need to do: actually focus the element, and make sure to only focus it when appropriate.

Focusing as a side-effect

Now that we have our big ref map, we need to focus the appropriate element after our table renders. This focus is a possible side effect of rendering the table, based on how the underlying data changed. In order to link these sorts of side effects with underlying state changes, React offers us the opportunity to use effects in the aptly named useEffect hook.

function App() {
  // ...
  React.useEffect(() => {
    const node = ref.current.get(`${data.length - 1}-0`);
    if (node) node.focus();
  }, [data]);

  // ...
}

Unfortunately, this implementation has a really annoying bug. The effect will fire whenever any re-render happens. This means that when a cell is blurred, the first column of the last row will always be auto-focused, meaning no other cells will ever be able to be edited!

To deal with this, we’ll need a way to have the .focus() called conditionally. We can manage this with a small additional piece of state:

function App() {
  const [shouldFocus, setShouldFocus] = React.useState(false);

  // ...

  React.useEffect(() => {
    if (!shouldFocus) return;

    const node = ref.current.get(`${data.length - 1}-0`);
    if (node) node.focus();
  }, [data, shouldFocus]);

  // ...

  const table = useReactTable({
    data,
    columns,
    getCoreRowModel: getCoreRowModel(),
    meta: {
      addRow: () => {
        setShouldFocus(true)
        setData((data) => [...data, { one: "", two: "", three: "" }]);
      },
      updateRow: (rowIdx, columnId, value) => {
        setShouldFocus(false);
        setData((data) =>
          data.map((row, idx) =>
            idx === rowIdx ? { ...row, [columnId]: value } : row,
          ),
        );
      },
      removeRow: (rowIdx) => {
        setShouldFocus(false)
        setData((data) => data.filter((_, idx) => idx !== rowIdx));
      },
    },
  })

  return (
    // ...
  )
}

That should do it. Now, when we click the “Add Data” button on our data table, we should automatically focus onto the newly created row:

The full working example is available in this repository.

Hamburger navigation with Phoenix Framework

Sun, 10 Sep 2023

Long time, no blog! Anyways, I’ve been messing around with Elixir and Phoenix for a side project around managing some chess tournaments. Since I plan on occasionally managing the application from my phone, I needed a way to handle collapsing navigation at a different viewport. I ended up using the classic hamburger menu implemented using Phoenix 1.7’s new components.

I have been enjoying working with Elixir and Phoenix, though is quite a different way of thinking about problems and how to organize code, and I am certainly no expert, but I liked this approach.

Here’s a short gif of the component dropped on top of a freshly generated Phoenix application (generated via mix phx.new --no-ecto hamburger):

And here is the full component’s code:

defmodule HamburgerWeb.Topnav do
  import HamburgerWeb.CoreComponents, only: [icon: 1]
  use Phoenix.Component
  alias Phoenix.LiveView.JS

  def nav(assigns) do
    ~H"""
    <header class="px-4 z-40 sticky bg-white">
      <div class="flex items-center justify-between border-b border-gray-200 text-sm py-3 z-40">
        <p class="bg-brand/5 text-brand rounded-xl px-2 font-medium leading-6">
          Hamburger
        </p>
        <.hamburger_button />
        <.top_nav_content />
      </div>
      <.open_hamburger />
    </header>
    """
  end

  defp top_nav_content(assigns) do
    ~H"""
    <div class="hidden md:flex md:items-center md:gap-4 font-semibold leading-6">
      <a href="/" class="hover:text-zinc-500">
        Home
      </a>
    </div>
    """
  end

  defp hamburger_button(assigns) do
    ~H"""
    <div class="md:hidden">
      <button phx-click={show_hamburger()}>
        <.icon name="hero-ellipsis-vertical-mini" />
      </button>
    </div>
    """
  end

  defp open_hamburger(assigns) do
    ~H"""
    <div id="hamburger-container" class="hidden relative z-50">
      <div id="hamburger-backdrop" class="fixed inset-0 bg-zinc-50/90 transition-opacity"></div>
      <nav
        id="hamburger-content"
        class="fixed top-0 left-0 bottom-0 flex flex-col grow justify-between w-3/4 max-w-sm py-6 bg-white border-r overflow-y-auto"
      >
        <div>
          <div class="flex items-center mb-4 place-content-between mx-4 border-b-zinc-200">
            <div class="flex items-center gap-4">
              <p class="bg-brand/5 text-brand rounded-xl px-2 font-medium leading-6">
                Hamburger
              </p>
            </div>
            <button class="navbar-close" phx-click={hide_hamburger()}>
              <.icon name="hero-x-mark-mini" />
            </button>
          </div>
          <div>
            <ul></ul>
            <li class="block px-6 py-2 text-sm font-semibold hover:bg-gray-200" phx-click="/">
              <a href="/">Home</a>
            </li>
          </div>
        </div>
      </nav>
    </div>
    """
  end

  defp show_hamburger(js \\ %JS{}) do
    js
    |> JS.show(
      to: "#hamburger-content",
      transition:
        {"transition-all transform ease-in-out duration-300", "-translate-x-3/4", "translate-x-0"},
      time: 300,
      display: "flex"
    )
    |> JS.show(
      to: "#hamburger-backdrop",
      transition:
        {"transition-all transform ease-in-out duration-300", "opacity-0", "opacity-100"}
    )
    |> JS.show(
      to: "#hamburger-container",
      time: 300
    )
    |> JS.add_class("overflow-hidden", to: "body")
  end

  defp hide_hamburger(js \\ %JS{}) do
    js
    |> JS.hide(
      to: "#hamburger-backdrop",
      transition: {"transition-all transform ease-in duration-200", "opacity-100", "opacity-0"}
    )
    |> JS.hide(
      to: "#hamburger-content",
      transition:
        {"transition-all transform ease-in duration-200", "translate-x-0", "-translate-x-3/4"}
    )
    |> JS.hide(to: "#hamburger-container", transition: {"block", "block", "hidden"})
    |> JS.remove_class("overflow-hidden", to: "body")
  end
end

Here’s how it works in a bit more detail: In the top navigation, there are three separate sections:

The “Logo” section, which always appears.
The top navigation, which will appear in viewports greater than whatever the md: breakpoint is set as (for more, see Tailwind media query documentation). Phoenix 1.7 ships with Tailwind by default.
The hamburger button, which is display: hidden at larger viewports and visible at smaller ones.

The hamburger button has a phx-click listener on it. This is a nice addition in Phoenix to allow for server-generated files to have some basic client-side capabilities. When the button is clicked, the show_hamburger/1 method is called. This method dispatches a handful of JS.show/1 events to the different parts of the side navigation. The side navigation portion of the hamburger menu is also made up of three components, each of which gets a different show transition applied to them:

The actual content of the sidenav, which slides in from the left via an ease-in-out transition. The actual transition slides by translating the element from offscreen by the inverse of its width to 0, meaning that it will slide in to the right until the final left edge of the element is at position 0.
A background which gets dropped over the rest of the page. This transitions from opacity-0 (totally invisible) to opacity-100 (totally visible).
A wrapper element which initially starts out as hidden. This immediately becomes visible to allow the children elements (outlined above) to transition into view.

The contents also contain a little x icon, which triggers hiding the contents by basically replaying the steps in reverse.

That’s the main portion of this component. It’s pretty straightforward to extend this by dropping additional pieces into slots.

Some mocking tricks with jest

Mon, 06 Jul 2020

Mock only one method in a module

Sometimes I find myself only wanting to mock one method in a built-in module (something like fs or path), and want the default behavior for everything else, maybe because a library has some on-import thing it’s doing with those built-ins. I can’t use spyOn because I want to have direct control over the mock:

const mockJoin = jest.fn();
function mockPath() {
  const original = require.requireActual("path");
  return { ...original, join: mockJoin };
}

jest.mock("path", () => mockPath());

This uses a combination of Jest’s hoisting for things that are named ^mock.+$ and factory import functions (I can’t find the explicit examples in the docs, but I get yelled at by the CLI when things are not named in this way).

Mocking axios

This one is pretty straightforward but is something that I come back with some regularity. There’s moxios, but I have found it to be sort of slow and usually pretty serious overkill for what I want to do. Using something a bit simpler like this has been successful for me:

import axios from "axios";
jest.mock("axios");

const axiosMock = axios as jest.Mocked<typeof axios>;
axiosMock.request.mockImplementation(() => {
  return Promise.resolve({
    data: "<html></html>",
    headers: { "content-type": "text/html" },
  });
});

Mocks and streams

When working with streams (most specifically something like fs.createWriteStream or @google-cloud/storage), it’s nice to have a real stream to use when testing.

Read streams

Read streams are relatively straightforward to use. For example, a GCS File could be mocked as follows:

const { Readable } = require("stream");

const mockReadStream = jest.fn().mockImplementation(() => {
  const readable = new Readable();
  readable.push("hello");
  readable.push("world");
  readable.push(null);

  return readable;
});

const mockFile = jest.fn().mockImplementation(() => {
  return {
    createReadStream: mockReadStream,
  };
});

module.exports = { mockReadStream };

Then in a test, when the stream is consumed the output should be “hello world”.

Write streams

Write streams are a little bit more complex to create and use.

const { Writable } = require("stream");

class WriteMemory extends Writable {
  constructor() {
    super();
    this.buffer = "";
  }

  _write(chunk, _, next) {
    this.buffer += chunk;
    next();
  }

  reset() {
    this.buffer = "";
  }
}

const MockWriteStream = new WriteMemory();

const mockCreateWriteStream = jest.fn().mockImplementation(() => {
  MockWriteStream.reset();
  return MockWriteStream;
});

const mockFile = jest.fn().mockImplementation(() => {
  return {
    createWriteStream: mockCreateWriteStream,
  };
});

module.exports = { MockWriteStream };

Then in the tests, after calling functions that stream into the createWriteStream, the contents should be available on MockWriteStream.buffer for assertions.

Through streams

Here’s a test on a class that does line-by-line JSON serialization (take an object and transform it into the JSON representation of that object while inserting the correct opening and closing characters):

test("properly outputs JSON", (done) => {
  expect.assertions(1);
  const serializer = new JSONLineSerializer();

  const items = [{ a: 1, b: 2, c: { d: 3 } }];

  let result = "";
  Readable.from(items).pipe(serializer);
  serializer.on("data", (data) => (result += data));
  serializer.on("end", () => {
    expect(JSON.parse(result)).toEqual(items);
    done();
  });
});

A few notes about this one: it’s conceptually similar to the read stream example from above, but it uses an explicit callback to understand when the stream has been consumed (see here for information about jest callbacks and here) for information about stream events.

2019 and 2020

Thu, 02 Jan 2020

This is yet another look forward and look back end-of-year post. My 2019 goals didn’t really go as planned; I ended up taking a new job about halfway through the year at the New York Times, where I’ve worked on a number of different things, including some campaign finance stories, work on a large leaked location dataset, elections coverage, and tooling to better connect with Times readers. I also continued writing tiny reviews of all the books I read this past year. My favorites were Kim Stanley Robinson’s Mars trilogy, Nixonland, and Umberto Eco’s tremendous Name of the Rose.

2019 Goals

Write and play more music: Completed

I wrote and released a bit more soundtrack music, but also something ambient and unrelated to the game that I’m pretty proud of.

Improved general fitness: Sort of completed

In the end, I ended up going back to the 5/3/1 split because I couldn’t really figure out anything else to do. I like 5/3/1; it’s simple, and I am still making progress towards higher weights. I spent most of the year working back towards where I was at the end of 2018 since I had taken nearly two months off, but by the end of the year I had set a new PR with a 475lb deadlift.

Work more on my Spanish: Not completed

This was a complete failure this year. At the beginning of the year I had bought translations of a few chapter books (notably, the first two of the Series of Unfortunate Events books translated into Spanish), but I stopped working through them about halfway through the year, right around when I started my new job. I would say that my Spanish proficiency has basically remained the same this year, but I want to try to work on it more. I’m not sure the best way to improve on where I am now.

Read and do the exercises from The Structure and Interpretation of Computer Programs: Not completed

I didn’t even start this.

2020 Goals

Less TV

I read this criticism towards the end of the year and it really resonated with me, so I’m going to make a concerted effort this year to try to watch less television. Specifically, I want to cut out “filler” TV.

Deadlift 500

I got pretty close by the end of this past year, but I am going to deload 10% at the start of 2020 and work up towards the big 500. I should hit it towards the middle of the year. At that point, I may want to recalibrate and move towards something else.

Survive the primary season

I’m working on covering the election for the Times this year. They say its a marathon, not a sprint!

Play the Mozart Piano Sonata No. 16 in C Major (1st mvmt)

This is a very well-known piece for early intermediate students, and I think I should be able to manage to get through it this year.

Keep reviewing books

I’ve really enjoyed doing that, and it has been nice to watch the big list of books grow over time.

The Sprawl Trilogy

Sat, 28 Dec 2019

I was inspired to re-read Neuromancer after reading this absolutely bonkers profile of Gibson in the New Yorker a few weeks ago. I was reading it while this series about surveillance that I helped work on came out, which made me think about the incongruities between the cyberpunk world imagined by Gibson here and by Neil Stephenson in Snow Crash.

Gibson anticipates this complete collapse of privacy: the story in Neuromancer kicks off when Molly is easily able to find Case. They retreat into a back room in the “Sprawl” to discuss Armitage in the room with the best privacy that she can afford.

There are ways, though, in which the worlds of Neuromancer and Snow Crash are very different from where we find ourselves now. Aside from the obvious dystopian elements, I think the biggest differences are in the ways that cyberspace manifests itself. For both Gibson and Stephenson, both writing long before the real rise of the World Wide Web, entering cyberspace is a physical and visceral experience. Case “jacks into the matrix” through a “cranial jack.” Hiro Protagnoist’s digital realm is avatar-centric, in the model that would eventually be realized in games like Second Life. In both of these cases, the act of going online involves a physical separation between the operator and their physical “meat space.” In Neuromancer, Case physically jacks in and attaches ‘trodes’ to himself and surfs around the ice, which is represented by colorful blocks in a separate world.

In the real world, though, this infrastructure is much more banal. Our phones are constantly pinging servers, cell towers, Bluetooth beacons, and WiFi routers, but we never see or sense that. We don’t jack into the Matrix or attach electrodes to our faces to go online. With the possible exception of some fully immersive VR, we maintain our normal senses. It’s impossible for us to know that things are being lost or taken from us when we go online. Even the downsides that are outlined in these pieces about private surveillance are physically removed from us: how can we understand ourselves as rows in a database table? All of these systems are completely hidden from us; we can’t see or understand their effects. In the world of Neuromancer, Case experiences brain-death a handful of times: there are real risks associated with being a console cowboy: the AI Wintermute fries his brain to the point of death.

This is a major point raised by the piece: why is it legal for companies to collect this data? Why are there no laws regulating them or protecting people? I think a large part of it is this gap between these worlds that were imagined from 20 years ago and how they ended up panning out. Though the internet truly has penetrated into every corner of life (see, for example this tremendously reported piece about all the ways Amazon is a part of daily life in Baltimore), we don’t really feel or understand it in the same way that we might if things were closer to the worlds of Neuromancer or Snow Crash.

In any case Neuromancer is a fun book, and still applicable to our world despite its differences. I’m looking forward to reading Gibson’s newest series after reading that profile of him, and seeing how he has shaped the world around us still.

After finishing Neuromancer, I took the time over the break to re-read the two other books in the so-called Sprawl Trilogy, Count Zero and Mona Lisa Overdrive. There are interesting bits cast throughout these books. One of the most interesting concepts in Count Zero is the notion that extreme wealth is has its own sovereignty and even confers its own citizenship to the small army of lawyers and managers who look after it. This is another point where Gibson seems to anticipate or even bring around reality: Josef Virek attempts to escape death; his consciousness is uploaded into a giant set of vats in Sweden, and he has many corporeal forms in the “simstim” VR-like entertainment. This doesn’t match fully but surely rhymes with the way that Google’s executives are looking to “cure death” as they age.