inessential by Brent Simmons

July 2018

The Old Reader blog — Thanks, Google!:

It’s now clear that the demise of the Google Reader was first really loud warning that you can’t rely on a publicly traded, profit-driven Silicon Valley tech company to deliver content. There is no way that story ends well. They will feed you sponsored crap, undermine your democracy, or pull the rug out from under your feet entirely.

Nick Heer on The Bullshit Web:

The vast majority of these resources are not directly related to the information on the page, and I’m including advertising. Many of the scripts that were loaded are purely for surveillance purposes: self-hosted analytics, of which there are several examples; various third-party analytics firms like Salesforce, Chartbeat, and Optimizely; and social network sharing widgets. They churn through CPU cycles and cause my six-year-old computer to cry out in pain and fury. I’m not asking much of it; I have opened a text-based document on the web.

Evergreen Diary #10: Syncing, Feed Data, and Swift 4.2

It’s difficult to write a future-proof schema for Evergreen’s Feed object because the needs of syncing systems — and other future features — may require me to add properties I don’t know about yet.

And: different syncing systems might need different properties, and I don’t really want to create an uber-schema which is the union of all of these. (And I don’t want to create a Feed protocol, because Set<Feed> is then impossible.)

What I really want is two things:

  • A Feed object where I can write feed.someSyncThing and feed.someSyncThing = whatever with type safety and without defining someSyncThing as a property or part of a database schema.
  • A Feed object where getting and setting these things gets and sets from a database. Persistence needs to be automatic.

In other words: I want arbitrary dot-syntax gets and sets, and I want automatic database-backed persistence.

Let me tackle these in reverse order.


I spent the first seven years of my career programming in UserLand Frontier, which includes a database that can be thought of as a giant nested dictionary. Dictionaries contain key-value pairs — and any value could be another dictionary, right?

It was the same in Frontier, except we called them tables. Tables could contain tables. There was no schema: any table could contain key-value pairs.

Persistence was exactly as easy as that: you could get and set values and tables, delete things, etc., and the whole giant nested dictionary was stored on disk as a database.

This is exactly the kind of thing I want backing my Feed objects. I want a Frontier-like database with a table called feeds, and a subtable for each individual feed (keyed by feed ID). The table (remember it’s like a dictionary) for each feed contains exactly what it needs — including any arbitrary future stuff I haven’t needed or though of yet — and nothing else. No database migrations ever. Just room to grow.

Well — I’ve been working on this for a while, and it’s not quite done, but it’s close. See ODB, which is part of my RSDatabase framework.

Great! So that’s half the job.

But what about the dot-syntax part? Swift is all about type safety, and being able to refer to object.anything seems un-Swift-like, no? I mean, that’s like a dynamic thing, right? Isn’t that more suited for those free-range kids who write in Ruby and Python?


My ODB code was far enough along that I started to actually revise my Feed object to use it and to handle arbitrary key-value pairs. I started by implementing a subscript method, so I could write code like feed[Key.etagHeader] = whatever — but I just didn’t like the look of it.

I really wanted dot-syntax, so I could write feed.etagHeader = whatever instead. Something — I forget what — made me vaguely wonder: wasn’t there something about this recently?

There was! Check out User-defined “Dynamic Member Lookup” Types, which was implemented in Swift 4.2 — which I’m using — and which makes me extraordinarily happy.

The gist is this: you can add a @dynamicMemberLookup attribute on a type, and then use dot-syntax to refer to any arbitrary data, and then implement a special subscript(dynamicMember: String) method (or multiple methods for different types) that gets and sets that data.

This is perfect. It means my Feed object can be as dynamic as its storage — without losing any syntactic niceness or type safety.

I realize that this new feature was written with the idea of working better with languages like Ruby and Python.

But I’ve long maintained that there are cases where dynamic solutions are appropriate even in Mac and iOS app code, even in code written in Swift.

Given the truth — that different Feed objects used with different syncing systems will need to store different data — it just makes sense to make Feed schema-less. And the combination of my ODB code and Swift 4.2’s dynamic member lookup feature means I can.

(Note: I haven’t finished my updated Feed code to check it in yet. I’ll update this post with a link once it’s up.)

I don’t remember the opening day of the App Store as well as I remember the July 4th before as I was frantically finishing up NetNewsWire 1.0 for iPhone — so I could get it submitted in time.

As people were coming to my house for a big family barbecue. As I was stuck inside on a nice day.

As I did get it finished, and then we had a great barbecue, and then on App Store day one it was all worth it. :)

Twelve-bar Blues

Without the twelve-bar blues progression there would have been no rock-n-roll. Without rock — the music of rebellion and of fun — every decade from the 1950s on would have been very different.

On the theory that knowing something about how music works helps your appreciation — after all, musicians themselves understand music, and this enhances and does not dim their love — I figured I’d explain twelve-bar blues to people who don’t know about it.

Three Groups of Four

There are many variations, but the basic progression looks like the below. We’ll use the key of C to illustrate. Each note here represents a chord played for four beats.


Instead of specifying the key, you could use Roman numerals. The root chord — the one matching the key (C in this case) — is I. If you count C-D-E-F, then F is IV. And C-D-E-F-G makes G number V. So you have:


In the key of E these would be E, A, and B, for example. Same pattern, any key.


In a very traditional blues, you sing the first line, then repeat it — maybe slightly differently, because the chords are slightly different, and because some variation is good — and then sing a line that rhymes with that first line. Something like this:

Oh baby, don’t you want to go

Oh baby, don’t you want to go

Back to the land of California, to my sweet home Chicago

(This is from “Sweet Home Chicago” by Robert Johnson.)

But it’s not always that way. Consider the lyrics to “Blue Suede Shoes” by Carl Perkins:

One for the money
Two for the show
Three to get ready
Now go, cat, go — but

don’t you
step on my blue suede
(no singing)

You can do anything, but
lay off of my blue suede
(no singing)

(Also note that “Blue Suede Shoes” uses V V to start off the third line instead of V IV. There are no rules other than sounding good.)

Electronic Blues with a Backbeat

(I’m simplifying a lot here, obviously, but I think the below is correct as far as it goes.)

The earliest blues was played in the South on acoustic guitars. And then two things happened: the African-American Great Migration, and the invention of the electric guitar. And then you had urban blues — in Chicago, Memphis, and elsewhere.

Rock music started as just another form of the blues. It’s impossible to say where electronic blues turns into rock. But one thing was especially prominent in rock music: the backbeat.

Blues and rock both have four beats to each measure. The accented beat is not the first beat, or first and third — it’s the second and fourth: beat BEAT beat BEAT.

It’s where you clap along. It gives rock music its drive. It moves you to dance — where, for instance, the acoustic version of “Sweet Home Chicago” probably doesn’t.

Another Difference

The early greats of rock in the ’50s were — not surprisingly, given where the music came from — African-Americans: Chuck Berry, Little Richard, Bo Diddley, Fats Domino, and plenty more. (Chuck Berry is the singular indispensible rock-n-roller.)

There were white artists too: Elvis Presley, Carl Perkins, Bill Haley and His Comets, Buddy Holly (the first nerd rocker), and so on. And this was a pretty big difference from the blues.

Great music should be shared and played by whoever feels it and can do it. Great music can bring people together — and rock music helped bring down segregation. At first, at least.

But what happened next is the tragedy of rock: by the late ’60s, just a little while later, an African-American playing rock was an anomaly. There was Jimi Hendrix — and who else? The list is short.

People other than me have written about this at length. But the upshot was that decisions were made to separate the music racially into Rhythm & Blues (R&B) and rock categories, and rock was largely white. (Yes, this isn’t a complex and nuanced telling of the story — but it’s enough for this blog post.)

Never mind that every white rocker was playing, essentially, a form of the blues. The Beatles, Rolling Stones, Yardbirds, the Animals, Creedence Clearwater Revival — they were all blues bands of a sort.

These Days

You don’t hear twelve-bar blues in rock so much these days. In fact, you may not hear that much rock-n-roll at all, depending on your taste.

But it’s worth knowing something about this music, about how it works and where it came from. And the good it did, and does, and the tragedy. All of it.

We can’t change the past, but we can understand what happened and remember it. And maybe we can notice when we’re about to make similar mistakes, and not make them.