{"@attributes":{"version":"2.0"},"channel":{"title":{},"description":"Bit pusher at Spotify. Previously Interactive News at the New York Times, \nU.S. Digital Service, and Code for America.\n","link":"https:\/\/bensmithgall.com","item":[{"title":"Visualizing a generalized maximum-weight-matching graph algorithm","category":{},"description":"

I have a small side project I\u2019ve been tinkering with over the past few years: a chess tournament\nmanagement application. It\u2019s been nice as a sort of open-ended exploration sandbox for all sorts\nof different things, like learning Phoenix<\/a>, and getting to\nimplement the rules of chess<\/a>.<\/p>\n\n

The core of the application involves tournament matchmaking. I\u2019ve added support for various \ntournament formats over the years, but I started with the most common chess format: swiss<\/a>.\nThe application for matchmaking in Swiss tournaments can be understood best as a form of a\nmaximum-weighted matching<\/a> problem. The players form a graph (often bipartite, but\nnot necessarily!), and we use the state of the tournament to determine the weight of the edges \nbetween them. Internally, the application assigns weights<\/a> based on rules from\nthe USCF rulebook.<\/p>\n\n

For a very long time, the application used a very-slightly modified version of Joris van Rantwijk\u2019s\nimplementation<\/a>. Elixir makes it pretty easy to shell out calls to other languages and get\nthe results back, and I just used this. The algorithm itself is quite complicated and I always had\ntrouble reading and deeply comprehending it. Joris has a great writeup<\/a> of how it works.<\/p>\n\n

I had tried a couple of times to port the algorithm directly from Python to Elixir. I tried by hand\nand wasn\u2019t 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.<\/p>\n\n

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

So for this, I wanted to go a bit further into the verification and validation. The algorithm is\nvery complicated with many moving pieces. I had a lot of trouble deeply understanding it. So I put\ntogether this visualization<\/a> with Claude.<\/p>\n\n

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

\"A<\/p>\n\n

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

\"Detailed<\/p>\n\n

Because it\u2019s built directly into the application, one other nice thing is the visualization also\nserves as a nice debugging tool: I added some code to deserialize graphs out of the URL state, which\nlets me walk through how the pairing works for basically any tournament:<\/p>\n\n

\"An<\/p>\n\n

Clauding<\/h2>\n\n

I\u2019m not going to talk too much about the rise of Anthropic\u2019s flagship model for generating code as\nthere is a ton of pre-existing writing about its capabilities. For me, if you can gain this level of\ncoding capability, the main interesting question is around what do you do<\/em> with the time that you\nhave gained? I think that using \u201cagentic LLMs\u201d (something like Claude code) are a bit of a manic\ntechnology: they produce lines that often compile and work very quickly! So what to do about this? I\nsee basically two paths: spend tokens to make things quickly (aka slop), or spend tokens on deep\nverification and learning.<\/p>\n\n

A lot has been written about building novel systems without really having an understanding about how\nthey work, and whether or not that\u2019s actually a good thing. Perhaps you can build giant towers of\nabstraction<\/a>, but that isn\u2019t necessarily<\/em> required from the tools. I think that instead\ngoing in this direction of using the capability for improving what existings or learning more deeply\nis much more interesting. Of course, in a personal project it\u2019s much easier to take this time; I am\nmore incentivized to build these sorts of tools for learning and understanding: the process of\nbuilding out the visualization did help me more deeply understand the algorithm.<\/p>\n\n

Working at the edge of my own understanding with LLMs is also quite strange; it\u2019s easier to pilot\nClaude through familiar domains and problems. Looking at its output is helpful but because those\nproblems have a familiar shape it\u2019s more akin to working with a colleague. In this scenario, though,\nI knew that the output was correct (one of the original implementation details was building out a\nbig validation suite that tested tens of thousands of graphs against the reference implementation)\nbut didn\u2019t really know why. The process of building this visual artifact helped me to understand why\nin a way that I don\u2019t think would have been possible previously.<\/p>\n\n","pubDate":"Tue, 10 Mar 2026","link":"https:\/\/bensmithgall.com\/\/blog\/claude-blossom-viz","guid":"https:\/\/bensmithgall.com\/\/blog\/claude-blossom-viz"},{"title":"Making a big button to answer FaceTime calls","category":{},"description":"

A family member of mine struggles to accept FaceTime calls from the computer. \nImagine if you had limited mobility or physical dexterity and wanted to answer a\nFaceTime call on a Mac. You need to be able to physically move a mouse or\ntrackpad cursor over to a (pretty small) \u201cAccept\u201d button and click on it. I\nmean, just look at the tiny size of this thing:<\/p>\n\n

\"A<\/p>\n\n

I took this screencap directly from Apple!<\/a><\/p>\n\n

What if instead you could just mash a giant physical button? Here\u2019s one sort-of\nridiculous way of making this work.<\/p>\n\n

Step 1: Automate the click<\/h1>\n\n

Something I didn\u2019t know but probably should have is that MacOS comes with an\napplication called \u201cShortcuts\u201d<\/a>, a pretty powerful automation tool.\nYou can wire it up to do all sorts of different things with different MacOS\napplications with its somewhat convoluted if-this-then-that interface. You can\ncontrol a lot of the built-in applications with Shortcuts with varying levels of\nbuilt-in control. The Notes app, for example, supports Shortcuts for all sorts\nof things like Append to a Note<\/code> or Move a Note to a Folder<\/code>. FaceTime,\nhowever, only supports making outbound calls via Shortcuts. This could be\nuseful, but we\u2019re trying to get to the opposite: answering a call.<\/p>\n\n

However, Shortcuts can also be used to trigger arbitrary AppleScript commands.\nAppleScript<\/a> is a language included on MacOS that provides a way\nof automating tasks. It has a sort of goofy english-esque syntax that you use to\nboss your computer around. Here\u2019s the sample from the documentation that counts\nup the number of files in the Applications<\/code> directory:<\/p>\n\n

tell application \"Finder\"\n    if folder \"Applications\" of startup disk exists then\n        return count files in folder \"Applications\" of startup disk\n    else\n        return 0\n    end if\nend tell\n<\/code><\/pre><\/div><\/div>\n\n
Some MacOS applications have pretty nice integrations with AppleScript, but the\nproject seems to have largely been abandoned in favor of things like Automator\nand Shortcuts. Wikipedia<\/a> has a nice history. In any case,\nFacetime does not have nice integrations with AppleScript, so we have to abandon\nthat and just attempt to automate clicking on buttons on the display instead.\nWithout further ado, here\u2019s an AppleScript to click on that tiny Accept<\/code>\nbutton:<\/p>\n\n
tell application \"Shortcuts\"\n  tell application \"System Events\"\n    delay 0.1\n    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\"\n    if acceptButton exists then\n      click acceptButton\n      delay 2\n      repeat while exists (window 1 of process \"FaceTime\")\n        delay 30\n      end repeat\n    end if\n  end tell\nend tell\n<\/code><\/pre><\/div><\/div>\n\n
What in the world does this do? Well:<\/p>\n\n
    \n  
  1. tell application \"System Events\"<\/code> scopes our commands to the \u201cSystem Events\u201d\napplication, a place where non-GUI functions can be executed (like entering a\nkeystroke, etc)<\/li>\n  
  2. delay 0.1<\/code> waits for 100ms to give FaceTime time to render the button<\/li>\n  
  3. \n    
    The next big giant block finds the Accept<\/code> button. It lives in a big element\nhierarchy:\nNotificationCenter > window > group > scroll area > UI element > button<\/code>.\nThe way I figured this out was by using the XCode Accessability\nInspector<\/a> and working backwards through the display hierarchy:<\/p>\n\n    
    \"The<\/p>\n\n    
    One big caveat here is that this definitely not future-proof. This element\nhierarchy worked for Sonoma, but inspecting it again for Sequoia shows some\npretty large differences in the layout. In this case, the people I am\nbuilding the button for aren\u2019t planning on upgrading, but it is something to\nkeep in mind.<\/p>\n  <\/li>\n  
  4. The rest is just waiting for the button to exist, clicking on it, and then\nkeeping the script running for as long as FaceTime is open. For some reason I\nhad to do that or FaceTime would just close randomly which was very\nfrustrating.<\/li>\n  
  5. We also wrap up the whole thing up in a tell application \"Shortcuts\"<\/code> to try\nand scope down what applications we allow to control our computer via\nAccessibility settings.<\/li>\n<\/ol>\n\n
    So now that we have our AppleScript, we can bind it into our Shortcuts\napplication and give it a keyboard shortcut<\/a>! I chose\n\u2318\u2303\u23258 basically at random.<\/p>\n\n
    Step 2: Automate the keyboard command<\/h1>\n\n
    Now that we have a (terrible) way of clicking on a tiny button by instead\npressing a ton of keys together at the same time, let\u2019s automate the pressing of\nthe keys!<\/p>\n\n
    You can use a microcontroller to emulate a USB keyboard and have it send the\nkeys in question based on a relevant signal. Since I knew basically nothing\nabout hardware going into this mess, I used an Arduino Micro<\/a>, though\nyou could probably do the same thing with something a bit smaller and cheaper.<\/p>\n\n
    One nice thing about using Arduino is that there are good instructions and\nguides for getting started and writing your first Arduino sketches. The Arduino\nwebsite has some good tutorials<\/a>. Here\u2019s what I came up with\nfor sending keystrokes programatically to a computer:<\/p>\n\n
    #include<\/span> <Keyboard.h><\/span>\n<\/span>int<\/span> btnPin<\/span> =<\/span> 2<\/span>;<\/span>\n\nbool<\/span> currentlyPlaying<\/span> =<\/span> false<\/span>;<\/span>\n\nvoid<\/span> setup<\/span>()<\/span> {<\/span>\n  pinMode<\/span>(<\/span>btnPin<\/span>,<\/span> INPUT_PULLUP<\/span>);<\/span>\n  Keyboard<\/span>.<\/span>begin<\/span>();<\/span>\n}<\/span>\n\nvoid<\/span> loop<\/span>()<\/span> {<\/span>\n  if<\/span> (<\/span>digitalRead<\/span>(<\/span>btnPin<\/span>)<\/span> ==<\/span> HIGH<\/span>)<\/span> {<\/span>\n    currentlyPlaying<\/span> =<\/span> false<\/span>;<\/span>\n  }<\/span>\n\n  if<\/span> (<\/span>digitalRead<\/span>(<\/span>btnPin<\/span>)<\/span> ==<\/span> LOW<\/span> &&<\/span> !<\/span>currentlyPlaying<\/span>)<\/span> {<\/span>\n    currentlyPlaying<\/span> =<\/span> true<\/span>;<\/span>\n    Keyboard<\/span>.<\/span>press<\/span>(<\/span>KEY_LEFT_GUI<\/span>);<\/span>\n    Keyboard<\/span>.<\/span>press<\/span>(<\/span>KEY_LEFT_ALT<\/span>);<\/span>\n    Keyboard<\/span>.<\/span>press<\/span>(<\/span>KEY_LEFT_CTRL<\/span>);<\/span>\n    Keyboard<\/span>.<\/span>press<\/span>(<\/span>'8'<\/span>);<\/span>\n    Keyboard<\/span>.<\/span>releaseAll<\/span>();<\/span>\n  }<\/span>\n\n  delay<\/span>(<\/span>500<\/span>);<\/span>\n}<\/span>\n<\/code><\/pre><\/div><\/div>\n\n
    Basically, we:<\/p>\n\n
      \n  
    1. Set up the Keyboard library<\/a><\/li>\n  
    2. Wait for a signal to come in on pin 2<\/li>\n  
    3. Press all of the keys needed at the same time<\/li>\n  
    4. Stop once the button is released.<\/li>\n<\/ol>\n\n
      With this, you can automatically send whatever combination of keys to the\ncomputer whenever you get a signal on a given pin.<\/p>\n\n
      Step 3: Make a big button<\/h1>\n\n
      Now that we\u2019ve carefully set up all the pieces of our machine, we can bring them\ntogether using a giant button. I got one of these<\/a>. It makes an\nextremely satisfying \u201cchunk\u201d sound when pressed. The next step was to wire\neverything up. Here\u2019s a small diagram of how this button works:<\/p>\n\n
      \"A<\/p>\n\n
      Essentially, we want to run a wire from the \u201cpush to make\u201d into the Arduino at\npin 2, and then a wire from the arduino ground pin to the \u201ccommon\u201d terminal on\nthe button. Here\u2019s what that looks like all wired up (sorry for the extremely\nblurry photo):<\/p>\n\n
      \"Wired<\/p>\n\n
      One note here is that the button itself has an LED on it, so if you were\ninterested you could also wire in some LED stuff but I just didn\u2019t in the end.<\/p>\n\n
      I was also very lucky to get a beautiful wooden enclosure built and stained by\nmy wonderful and talented father.<\/p>\n\n
      \"The<\/p>\n\n
      And here it is all finished:<\/p>\n\n
      \"Da<\/p>\n\n
      Recap<\/h1>\n\n
      So, what happens when you push this button?<\/p>\n\n
        \n  
      1. The digitalRead<\/code> signal fires on the Arduino, sending \u2318\u2303\u23258\nas a keyboard signal.<\/li>\n  
      2. That keyboard combination starts a MacOS \u201cShortcut\u201d which triggers an\nAppleScript<\/li>\n  
      3. The AppleScript searches for the \u201cAccept\u201d button on an inbound FaceTime call\nand clicks on it.<\/li>\n  
      4. You talk on FaceTime.<\/li>\n<\/ol>\n\n
        Is it brittle? Yes. Is it hacky? Yes. Does it work? Yes.<\/p>\n\n","pubDate":"Wed, 26 Mar 2025","link":"https:\/\/bensmithgall.com\/\/blog\/a-big-button","guid":"https:\/\/bensmithgall.com\/\/blog\/a-big-button"},{"title":"Self-hosting Obsidian LiveSync on Kubernetes with Tailscale","category":{},"description":"
        Recently, I\u2019ve been using Obsidian<\/a> for note taking. It\u2019s fast, has a bunch of\nnice features, a decent vim mode, and rich support for community plugins. I also\nreally like the \u201cfile over app\u201d philosophy that the current CEO has written\nabout<\/a>.<\/p>\n\n
        I also have been running Kubernetes on a cluster of RaspberryPi computers in my\nhouse that I have been using for all sorts of odds and ends. It hosts my chess\ntournament website<\/a> that I have written<\/a> about<\/a>\npreviously<\/a>. I also use it as a sync server for the incredible\natuin<\/a>, host a handful of internal-to-the-house apps, and\nsome other things. The cluster runs k3s<\/a> and uses four Pi\ncomputers that I have accumulated over the years, going as far back as model 2B.<\/p>\n\n
        One thing I like quite a bit about it is that nothing is exposed to the public\ninternet, except the aforementioned tournament website, which is hidden behind a\nCloudflare tunnel<\/a>. Instead, I use a combination of external-mdns<\/a> and\nTailscale<\/a> to make things accessible outside the\ncluster as needed.<\/p>\n\n
        Obsidian has a plugin for self-hosted LiveSync<\/a>, which I really\nappreciate. I like to host these things myself when possible, especially when\nthe cost of failure is low, like it is here. I had some \u201cfun\u201d getting this set\nup with my setup and wanted to write about wiring pieces together.<\/p>\n\n
        CouchDB<\/h1>\n\n
        I know absolutely nothing about CouchDB. In fact, I hadn\u2019t heard of it before\nlearning that the plugin in based on it, but I did learn that it is written in\nErlang, which is great. So to start off, I had to get CouchDB running in\nkubernetes.<\/p>\n\n
        CouchDB has a helm chart<\/a>, but I opted to write my own deployment\ninstead. In general, I prefer to have my own yaml lying around so I can put it\nin source control and make tweaks later.<\/p>\n\n
        In any case, the deployment is pretty straightforward. However, there are a\ncouple of gotchas when setting this up from scratch, especially since the\ndocumentation is quite sparse.<\/p>\n\n
        First, you need to have an admin user and password ready to go via environment\nvariables. I created them as a kubernetes secret and referenced them via\nsecretKeyRef<\/code>.<\/p>\n\n
        Second, after everything has started, you need to go into the running pod and\nmanually create the required databases. This is discussed in the setup\ndocumentation<\/a>, but there are a few additional caveats:<\/p>\n\n
          \n  
        1. The curl commands in the setup documentation will not work as written because\nCouchDB will only allow you to run them if you are an administrator. You need to\nsign your requests. I used the _session<\/code> auth method<\/a> and managed to\ncreate the required databases.<\/li>\n  
        2. Setting up CouchDB to operate as a single-node installation isn\u2019t as\nstraightforward as I had hoped. The recommended way<\/a> to do it\nis to publish your own Docker image that has a local.ini<\/code> file bundled inside\nof it, with the single_node=true<\/code> flag set in the CouchDB property. This is\nprobably the best way to do it, but I just configured a service and local mdns<\/code>\ningress and used the management GUI to do it manually.<\/li>\n<\/ol>\n\n
          Tailscale<\/h1>\n\n
          Now that we\u2019ve got CouchDB set up, we need to have some way to communicate with\nit from Obsidian. One thing that is quite important is that we are able to do so\nvia https; without it, I wouldn\u2019t be able to sync to and from my phone.\nTailscale<\/a> is an amazing piece of technology. It wraps\naround WireGuard<\/a> and can make a mesh network out\nof any number of devices. My pi cluster, computer, and phone are all part of the\nsame Tailscale mesh network, so I can do all sorts of cool stuff like send\nfiles between devices<\/a> or ssh from anywhere<\/a> without\nhaving machines exposed to the public internet.<\/p>\n\n
          One relatively recent feature added to Tailscale was the kubernetes\noperator<\/a>. This does a couple of nice things for us, like being able to\nexpose a service directly as a \u201cmachine\u201d in your Tailscale mesh network (aka\ntailnet), or even an entire subnet router. I have found that selectively\nexposing services has been the most straightforward since it can be done just\nwith annotations<\/a>.<\/p>\n\n
          Unlike with CouchDB, I used the helm chart for this one. The kubernetes setup is\nquite complicated with a lot of moving parts (service accounts, roles and\nrolebindings, custom resource definitions, etc.). I had tried using the raw yaml\ndirectly for awhile, but it\u2019s still somewhat early and things have moved around\na bit since I started trying it out.<\/p>\n\n
          In any case, the documentation for the simple case is pretty straightforward\nfrom Tailscale\u2019s website. There are some additional steps<\/a> needed in\norder to get HTTPS set up for a tailnet. The main thing for us is that in order\nto use HTTPS, we have to know the full tailnet name<\/a>.  This is\nimportant when actually setting up the LiveSync, since the tailscale cert<\/code>\ncommand will automatically generate a certificate with the full name and https\nrequests will work as expected.<\/p>\n\n
          Additionally, annotating a kubernetes service wasn\u2019t sufficient to generate a\ncertificate. In order to get HTTPS traffic working, I had to use a dedicated\ningress, as is outlined in Tailscale documentation<\/a>. I also had to\nmanually ssh into the pod running tailscale for the given ingress and run\ntailscale cert<\/code> manually in order to generate a certificate. My guess is that I\nhad spent too much time mucking around, and something had gone sideways.<\/p>\n\n
          Obsidian LiveSync<\/h1>\n\n
          At this point, there\u2019s a CouchDB instance running in our cluster that is\naccessible over HTTPS to all nodes in our tailnet, so we are ready to set up the\nLiveSync plugin. One really nice thing about the plugin is that once you connect\nit to the CouchDB instance, it can automatically configure the database to have\nthe appropriate configuration and CORS settings etc.<\/p>\n\n
          At this point, everything should be set up and sync can be enabled. The URI will\nbe the full name given to our CouchDB ingress. There\u2019s a couple of other really\nthings about this setup:<\/p>\n\n