Personal digital infrastructure I've been performing some long overdue computer maintenance activities:

• I've had a server with Linode forever and been very happy. But I recently noticed it would periodically go inaccessible, perhaps after some idleness. Perhaps it had something to do with their acquisition. So I decided to switch providers.
• Back in 2009 when I created my website I built it in Rails (backed by files rather than a database) Last week I replaced all that with raw html, generated with a tiny Lua script. It's nice to be able to unsubscribe from some mailing lists of vulnerability notifications.
• I've been backing up my local laptop to my server, but that was causing me to overflow my disk. Cloud servers are a relatively expensive way to get storage. So I decoupled those concerns and now back up my laptop to rsync.net.

All in all, I'm much happier with my server. It's leaner, runs less stuff, and it'll be easier to move next time. With the way we've been seeing services degrade lately, I think it's useful to be thoughtful about how we cobble together our personal digital infrastructure, architect it to be nimble and easy to move around. If you keep options open you'll be less likely to need to use them.

permalink

After 10+ years on Rails, I've finally gotten around to switching my website to static files.

Hopefully there's no discernable difference from the outside :crossed_fingers:

permalink

What it's like to program my Freewheeling Apps

(audio/video; 20 minutes)

permalink

The most common footgun I run into with Lua isn't the 1-indexing. It's the wildcard nature of '-'.

Today's head-scratcher:

> ('00-43'):match('^(%d%d)-(%d%d)')
00	43
> ('00-43'):match('^%d%d-(%d%d)')
nil

I should just always escape it ('%-') as a matter of course.

permalink

A pattern of merge bugs in Freewheeling Apps

My Freewheeling Apps kinda abuse git, and I've been watching for problems to arise from this friction.

Most software tries to keep branches short-lived. Merging is the point of a branch. My apps are long-lived forks that never merge, only occasionally cherry-pick.

Today I noticed a pattern: a file has been deleted in a fork and reintroduced in a later fork. Changes to it won't make it over that chasm without manual help.

How big is this problem? I wrote a quick and dirty visualizer which highlights chasms as the black lines. The short lines are false positives, so it's not a big problem. Yet.

How I built this:

• topologically sort my forks (columns) so parents come before descendants, children stay close to parents
• hash files in each fork so filenames show up in the same row
• zoom my terminal way out
• highlight long runs of spaces

permalink

Image maps are pretty cool.

After I posted my talk yesterday, Konrad Hinsen suggested appending a list of links to all the forks I mentioned. Searching around, I found a neat service called image-map.net which made my image of forks clickable with relatively low effort.

Check it out.

The only drawback: link coordinates are not normalized. So if you resize your the links all break.

permalink

Another day, another copy-paste of a website to a less barbaric reading experience.

permalink

Befunge, but readable

Once more at this. This time after seeing Hexagony.

One problem I have with Befunge (not the one you're thinking of, ha) and other fungeoids is that you have a bunch of static information about a program visible in 2D on screen, but a key piece -- the stack -- is invisible. The question I keep returning to is how one might go about making the stack (or any other run-time state used by the program) visible without just bolting it on on the side. This time around, I got hooked on the following metaphor. Imagine a spaceship that contains some data, sets out on a voyage across an infinite 2D plane, and performs various operations depending on the objects it collides with.

Example 1: The space ship contains a row of boxes. Colliding with a number pushes a box on to the nose, colliding with an operator operates on the 1 or 2 front-most boxes in the front. This is a way to display a stack, but a stack in isolation doesn't seem to scale well to larger programs.

Example 2: The spaceship contains a number. Colliding with the BF-inspired primitives + and - causes the number to be incremented and decremented, respectively. Now build addition out of it. Zooming into a number n shows it to be a loop of n iterations. When the spaceship collides with n it loops through n times, and the number inside it has n added to it. At a high zoom, you see the spaceship loop n times before exiting the "solar system". At a low zoom you see the spaceship exit instantaneously with n added to its value. Now you can imagine a reduce operation as a series of solar systems that the spaceship visits one by one.

Example 3: The spaceship contains a binary heap to insert and delete elements from depending on objects it collides with. Zooming into any single collision reveals the tree structure to be the "space" that a smaller spaceship containing a single number bounces among.

Two properties that seem important from these examples:

• A hierarchical nature where space and spaceship are duals, and zooming in and out causes them to turn into each other.
• Rendering the state of a spaceship needs to be extensible (like in my old Pong demo). We need to leave Befunge's ASCII behind.

At the largest scale, state machines feel like a really powerful way to represent the state within a spaceship. I often find them to be the outermost architecture of a large program. But to actually find the state machine I have to flail around for a long time. If we could use some visual paradigm at the largest scales but zoom into text as needed, programs might be much more comprehensible.

permalink

Some distilled reference documentation on my Freewheeling Apps (a way of building low-maintenance Situated Software for small groups)

In a bare-bones template repo (~500 LoC).

In a more elaborate template with testable primitives and an editor widget.

Open it on a browser tab when you clone and start editing using driver.love. There are a few examples in the Readme to spark ideas. Works on any Windows and Unix.

permalink

Update on my live-editing environment. It's still extremely easy (1% for me, 10% for others?) to crash the driver, so I've been trying to track down thoses corner cases. Realization: my memory of such crashes and instinct for situations causing crashes is extremely unreliable. Possibly the app's error behavior is changing under me during seemingly unrelated changes. I've been spinning my wheels on this for a couple of weeks. Hopefully it'll clarify over time. I might need a more elaborate set of tests that involve configuring a client app just so.

permalink