Hi friends,

It’s been a while since my last update back in March! I hope you’ve been well.

Here’s what I’ve been up to:

I decided not to build a workshop in the woods. Developing Subform and growing it as a business is my primary focus right now, and it’d suffer if I were managing subcontractors and swinging a hammer. Beyond that, I also realized that, as much I would enjoy designing and building a workshop, I would not enjoy 2 hours of daily driving to/from Portland to use it. (Nor would I be happy living out in the country full time.)

In fact, I want to spend more time in larger cities, which is why I’ve moved to Melbourne, Australia. My girlfriend Nicki and I arrived a month ago, and we’ll be here through at least March 2018. So if you live down under (or are just swinging through), drop me a line and we can grab a coffee.

As for technical / design topics, here’s what I’ve been thinking about lately:

Design critique I wrote about a Volvo V60. It’s not so much about the car as it is an exercise in asking questions about design tradeoffs and looking at something without considering aesthetics. (If you know of any blogs or books that write in this style, please tell me! Every time I search for “industrial design blog”, I just find washed out gray-on-white text with high res photos of Apple stuff that looks “modern” and “sleek”.)

TLA+ I’ve been watching Lamport’s awesome TLA+ video introduction. TLA+ is well known in distributed systems world, but its core idea — helping you think in terms of states — is useful in all kinds of problems. I highly recommend checking out the videos and trying to write a few specs. (Just have a few drinks until the syntax doesn’t bother you anymore.)

State space exploration TLA+ got me thinking about other ways to explore a program’s state space.

TLA+‘s “model checking” approach exhaustively checks all possible states. This is great, but limits TLA+ to very small problems — which is why TLA+ only checks abstract specifications rather than executable code, which has far too many possible states to explore.

Property-based testing approaches (like Clojure spec / test.check) use generators to create random inputs, which you hope will sufficiently explore the program’s state space.

A related exploration method is “fuzzing”. American Fuzzy Lop is a neat tool that also generates random inputs, but is a bit more clever — it monitors the program execution so that it can preferentially generate inputs that execute new code paths. The idea is that this will more evenly explore the state space of the program, whereas blind random inputs might get stuck in a corner.

However, at the end of the day both generators and fuzzing tools still rely on randomly “discovering” the sides of each conditional branch — so if your code looks like:

(cond x
  (< x 10) :small
  (< x 12345) :medium
  (> x 12345) :large)

it’s very unlikely that a random input will find the problem at (= x 12345).

However, there’s an interesting research area that tries to work around this limitation, “concolic testing”. (The name coming from “concrete” + “symbolic”.)

The idea is to monitor program execution to detect conditionals (the “concrete” part), then use a constraint solver (the “symbolic” part) to find the specific inputs that would lead to all the branches being taken. In the example above, inputs could be 1, 11, 12345, and 123456, to run each branch.

This talk provides a good overview from a researcher in the Erlang community.

Anyway, that’s what I’m thinking about at the moment.

I’m experimenting with tools to explore the state space of user interfaces, and will likely have a detailed writeup of that in the next few months.

As always, I’d love to hear your questions, thoughts, and pointers, so feel free to just reply to this email.

Best,

Kevin