I don’t think there’s going to be an SDK for AirTags, and they seem to be designed to be found by a single person, but the same technology could be used to precisely locate myself indoors (if AirTags were installed to create a mesh).

This is supposedly what iBeacon’s do, but I’ve heard from people trying to deploy them that the technology doesn’t work very well. I don’t really know anything about this at all, but here’s a contrary view from someone who knows beacon tech better:

We don’t believe that these tags will replace the current generation of BLE beacons for a few reasons:

・ These UWB Tags will require a new (circa 2020) Apple or Samsung
・They will not be compatible with most of the existing gateways
・ These tags will most likely initially only work with the proprietary applications on Apple or Samsung Phones
・ Apple and Samsung UWB seem to be geared towards finding lost items, not providing all of the other sensor data that current BLE beacons do
・ BLE Beacons will be much, much cheaper than these UWB Tags will be

And, this is probably true today with AirTags as they are. But, this article also says that Google is dropping support for BLE beacons, so there is some problem here.

Bicycle is an open-source framework that I’ve been working on with a couple of friends. One way to think about it is to compare it to a spreadsheet.

In a spreadsheet, we are building a directed, acyclical graph of cells, where cells are nodes and each formula in the cell defines the edges and direction.

If A1=B1+C1, then both B1 and C1 point to A1. The graph cannot contain cycles, so, in a spreadsheet, you can’t then say that B1=A1-C1 even though that is true, because it would cause a cycle in the graph.

Bicycle defines a data-structure and algorithm that gives meaning to a graph of formulas that does contain cycles where dependencies between nodes can be bidirectional (hence, Bicycle).

In Bicycle, you can define both of the formulas above and also complete the network with A1=C1-B1. In more complex networks, an individual field may have several different formulas, using different dependencies that can set its value.

Once you define a network, you can seed it with values. These are kept outside of the formula data-structure in a kind of priority queue. The highest priority values are seeded first, and each value is only accepted into the network if the network can remain consistent.

Meaning, I could define A1 as 2, B1 as 3, but if I then say C1 is 7, I have created an inconsistency. When you attach this to a UI, you would want the oldest value to be discarded.

We are also providing some help building SwiftUI based UIs with it. The network is meant to be hosted in an @ObservableObject and we provide a TextField Initializer that will bind to fields in it. Here’s a demo of a network that can convert between yards, feet, and inches.

Try to imagine replicating that in Excel. You’d have to pick one of the fields to be user-provided and put formulas in the other two. In Bicycle, you can provide as many formulas as you want (as long as they are consistent with each other) and seed-values are used as long as they are consistent.

It’s in very early stages and the API will probably change a lot, but if you want to take a look, see SwiftBicycle in GitHub.

We can apply principles of visual design to designing audio. In visual design, we can manipulate “visual variables” to get different communication effects. The variables are are:

• Size
• Value/Brightness
• Hue/Color
• Orientation/Rotation
• Texture
• Shape
• Position

Continuing along with sonifications, here are some analogous audio variables:

• Frequency / pitch
• Beat
• Amplitude / volume
• Envelope / Waveform: e.g. a beep vs. a buzz
• Source Location

We have different ways of perceiving visual variables. For example, for some of them, we have an order—size goes from small to big, but shapes are not ordered.

We also have different ideas about how many variations we can tell apart on the same canvas. We can distinguish between a huge number of shapes, but probably only a few levels of brightness.

These kinds of perception apply to audio variables as well. Waveform seems to be related to shape in that there can be many types (instruments), but they are not really ordered.

Amplitude is similarly related to size, pitch is like brightness, and source location is like position.

Using what we know about combining and contrasting visual variables is probably a good start for doing the same with audio.

A few days ago a proposed a short-list of great software works. A couple of them are associated with the great works of software writing, and so I started to think about what the top five pieces of great software writing were.

This was a lot harder for me to narrow down, so in the end, I decided to make it personal. What had influenced me the most? This means I have to leave off The Art of Computer Programming, which is undoubtedly a great work, because I haven’t read it.

These works were chosen because they shape how I think about programming anything. They are language and framework independent. I chose three that are more about process and three that were more technical.

This is in the order I read the books or papers.

Process

• Peopleware [amazon affiliate link] by DeMarco and Lister
• eXtreme Programming [amazon affiliate link] by Beck and Andres
• Joel on Software blog

Technical/Coding

• Design Patterns [amazon affiliate link] by Gamma, et al (The gang of four)
• A behavioral notion of subtyping (Liskov Substitutability) by Liskov and Wing
• Purely functional data structures by Chris Okasaki

For me, these are works that still affect how I program today. My main lessons:

From Peopleware, that the biggest factors in programming productivity were access to quiet and long blocks of time, and that this explained correlations of productivity within a workplace.

From eXtreme Programming, unit testing, continuous integration, pair programming, small releases, and refactoring which are all part of how I have worked from the day I finished reading it.

From Joel on Software, don’t rewrite software, UI design for programmers, tons of software business. Also, one of the main reasons I applied to (and worked for) Trello.

From Design Patterns, that it’s useful to look for common solutions and give them a good name and description (not the specific patterns, although I obviously had learned from them).

From A behavioral notion of subtyping, I learned about how to progress software. I think about substitutability for almost every line of code I write inside of deployed software. I wrote about this in my blog post on Substitutable Versioning.

From Purely functional data structures, I learned that functional programming was technically possible. I had read about FP (and even wrote about it) in college (~1990), but at the time, it wasn’t conceivable to me that this could work—granted, I was just a student. After clojure came out, and introduced me to Okasaki’s work, I was convinced that FP had a place in my toolset. I wrote about that revelation back in 2008 in my 20 days of clojure series, where I tried to learn clojure quickly because I was helping to host a Rich Hickey talk.

Some notable things that I read but didn’t include are Decline and Fall of the American Programmer (this was interesting but turned out to be mostly wrong), Writing Solid Code, and Code Complete (great, but read it too late in my career to be influential).