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 is then impossible.)
What I really want is two things:
Feedobject where I can write
feed.someSyncThing = whateverwith type safety and without defining
someSyncThingas a property or part of a database schema.
Feedobject 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.)
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.
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.
Nikhil Sonnad, in Everything bad about Facebook is bad for the same reason:
...the imperative to "connect people" lacks the one ingredient essential for being a good citizen: Treating individual human beings as sacrosanct. To Facebook, the world is not made up of individuals, but of connections between them. The billions of Facebook accounts belong not to "people" but to "users," collections of data points connected to other collections of data points on a vast Social Network, to be targeted and monetized by computer programs.
There are certain things you do not in good conscience do to humans. To data, you can do whatever you like.
Last night I deleted all my tweets going back to the beginning of Twitter time. (Except for a mysterious 49 tweets that apparently can't be accessed?)
And I tried to make my profile info very clear about me not being there any more. Removed avatar and background image. Changed bio to "Finished with Twitter." Changed display name to the name of this blog.
* * *
My problem with Twitter remains the same: centralized social networking concentrates way too much power in one place.
Twitter is awful in other ways, sure, not just for that reason. (The issues with Nazis and harassment and abuse. The way it treats third-party Twitter developers.)
And Facebook, too, is awful in its own ways.
But, even if it were well-run, centralized social networking is still a deeply bad and unhealthy idea. Josh Marshall writes that we should be concerned about
...ceding so much of the public square to private platforms which really aren't about free speech in any way and don't have free speech in any way. They're all ordered by algorithms designed to maintain time on site and service ad sales. In no sense are they open or free.
Twitter is not the public square. It just wants you to think it is. The web itself is the public square.
* * *
It's not like I'm short on ways to read and write and connect: email, RSS, text messages, podcasts, Slack, the chat app my company uses, GitHub, my blog, my microblog. Plus real life!
* * *
I get it, though, when people think they need Twitter for exposure and marketing. In fact, I help with social media at my job — and I'm a professional, and I try to do the best job I can and get even better at it.
But I don't need Twitter for me. For a long time there's been just one thing I'd like to convince Twitter users of: that centralized social networking is harmful to society and to individuals.
I can make that point on Twitter — but it's hollow there, since the medium really is the message. Better to make that point by not using Twitter at all.
A line in Frank Chimero's article Everything Easy Is Hard Again, published a couple months ago, has stuck with me:
That breaks my heart, because so much of my start on the web came from being able to see and easily make sense of any site I'd visit. I had view source, but each year that goes by, it becomes less and less helpful as a way to investigate other people's work.
One of the ironies of this is that HTML5 makes it easier than ever to make readable, simple HTML. I especially like two things:
article, and similar now.
So I adopted the semantic HTML5 tags, simplified a few things, and now the source is as easy to read as any HTML I've ever written.
Lesson learned: the discoverable and understandable web is still do-able — it's there waiting to be discovered. It just needs some commitment from the people who make websites.
Jason Kottke reminds us that blogging is most certainly not dead, and that there are great blogs out there.
My only objection is the use of the word "dead" to apply to things that aren't alive. Even when you're saying that something is not dead.
I've done it myself. It's shorthand, yes, but it's a broad binary take when something more nuanced and true would be warranted.
On the blues harp:
A diatonic harmonica is designed to ease playing in one diatonic scale...
Blues harp subverts the intention of this design with what is "perhaps the most striking example in all music of a thoroughly idiomatic technique that flatly contradicts everything that the instrument was designed for."
What I'd rather do: run that little web server on the actual server, and do the static-site generation there. That way I can post from my iPhone and iPad, not just from my Mac.
But... here's where web deployment gets tricky. I'm on an inexpensive shared host plan at DreamHost. The machine is running an older version of Ruby that's incompatible with my scripts.
That is, if I could figure out how to use this stuff and get it installed on the server. Looks like something I could spend weeks doing (remember that my hobby coding is limited to nights and weekends).
Alternately, I could get an inexpensive VPS from one of the various providers and set things up there. That might be easier — maybe I could skip RVM and Bundler and just install the things I want to use in the old-fashioned way.
But then I have to deal with a bunch of other things myself, including setting up Apache or Nginx. All the things DreamHost does for me automatically I'll have to handle myself. That doesn't sound like fun at all.
I totally don't know what to do. It's not my plan to become a Ruby deployment expert or to be on the hook for running a server all the time. I've done way too much of that kind of thing for one lifetime already, and I've mostly been glad to be out of it.
What surprises me is that in 2018 it still requires so much work just to get a CGI script running on a server. It should be easier.
There's an unofficial Seattle Xcoders this Thursday at the Cyclops in Belltown. I plan to get there around 6 pm.
We're always in back, next to the bar but technically in the restaurant section. Anyone is welcome — you don't have to be a coder! We regularly have designers, testers, support people, product managers, and so on.
Heck, even if you're a fan, you should come. Should be a beautiful night to hang out with some fine folks.
The latest episode of The Omni Show is a special episode — we talk about OmniFocus 3 and flexible inspectors, enhanced repeating tasks, batch editing, and the interleaved Forecast view.
Regular interview shows are our bread and butter, but these roundtables are fun to do too. (And I can't wait for The Omni Show Live next door to WWDC!)
Say you write an iOS app, and now you want to write the Mac version.
Assuming there's a data model, maybe a database, some networking code, that kind of thing, then you can use that exact same code in your Mac app, quite likely without any changes whatsoever.
That leaves the 20% or whatever that's user interface. AppKit is not the same as UIKit, but it's recognizable. Same patterns and concepts, and often similar names (UITableView/NSTableView).
Given that you've done the hard thing — learning UIKit, Xcode, and Swift and/or Objective-C — taking the next step and learning AppKit seems like a very small thing. You've climbed the mountain already, after all.
You might complain that AppKit has some weird stuff. True. Some of it, though, isn't truly weird — it's just weird to you if you've never dealt with things like a menubar and multiple, live-resizable windows.
People coming from AppKit to UIKit (few people these days; many people 10 years ago) might also complain about safe content area insets (or whatever the thing is these days) and size classes and all manner of strange stuff they like not having to deal with in Mac apps. UIKit's weird too, to some people.
Ten years ago I thought that all the new iOS developers would translate to lots more Mac developers. That that didn't happen is a huge surprise to me. Because if you're an iOS developer you're practically a Mac developer already.
(And — little-known secret — the economics of Mac apps appear to be more favorable than for iOS apps.)
It's not finished yet — it doesn't even build.
It's hierarchical key-value storage. No schemas. Tables can contain tables, with no limit.
This implementation is the lowest level: the part that gets, sets, and deletes data from the database.
It's application-agnostic, at this level — it doesn't know about all of Frontier's data types, for instance. A level on top of this will be needed for new-Frontier.
I'm not actually writing a new database — I'm using SQLite. And that's because I've been using SQLite for 15 years, and I love it and know it well, and I know how incredibly stable it is. I'm not willing to write my own thing, and I'm not willing to use a thing less mature and rock-solid than SQLite.
How it works:
The schema is pretty simple. There are tables and values.
Every table has an
id. Every table (except the root table) has a
parent_id that points to its parent table.
And every value has an
odb_table_id that points to its parent table.
This way it's easy to get a table's children: it takes just two
(Both tables and values also have a
name, since this is key-value storage.)
Tables and values will be cached in memory, so not every call will require a database read.
(Before you suggest I use something other than SQLite, know that I won't change my mind on this.)
(Also, again: it's not done yet. Doesn't even build.)
I'm using schema-less storage for feeds in Evergreen. (Articles and article status, on the other hand, are stored using a schema, in SQLite.)
Currently I'm writing a big binary plist with all the feed data, and it has to be rewritten every time a feed property changes. The writes are coalesced — but still, this isn't great.
I'm using schema-less storage in part because of syncing systems: I don't know, and can't guess, what I'll need to store. Different systems will have different requirements.
Also: I may add features later that require additional feed properties. I don't know what those are.
I realized that what I really want for this is a feature from Frontier: hierarchical key-value storage.
Each system will gets its own database on the client. For each, I'll create an odb table called
feeds. Each feed will have its own subtable. The key will be its id (which may or may not be its URL, depending on the syncing system).
And inside each subtable I can put whatever I want, at any time, without having to change any schemas or implementations.
For the On My Mac account — not synced; reads feeds directly — we keep track of Etag headers in order to support conditional GET. So, for example, I'd want to get, set, and delete
But with most syncing systems we get the feed content from the system itself — not by directly reading the feed. There might be some other data from the service to store:
feeds.[feedID].syncToken, for instance.
I wouldn't wait for "Marzipan" or XKit or whatever it is.
We don't know what it is. But my guess — based on my 38 years of writing code for Apple computers — is that it's something you can use along with UIKit and AppKit, and not a wholesale replacement.
Maybe it's a declarative API that helps make some things easier, and maybe you can make a cross-platform button more easily. Maybe your table view code could be the same on iOS and macOS. Great!
But don't expect Macs to turn into large iPads all of a sudden. Macs are gonna Mac. Apps are going to have multiple resizable windows and a menubar. Targets will still be sized and designed for mice and trackpads.
In other words, if you want to write a Mac app, you're still going to have to deal with the things that are inherently different about Mac apps, regardless of the specific API.
Let's say this thing ships in the fall of 2019, over a year from now. If past is a guide, we might imagine it would be fun to play with, but not more useful than, say, the original version of Swift. (Swift didn't get really good for writing apps until Swift 3.)
So it might be 2020 before it's something that accelerates Mac development in any real way.
You could write a few Mac apps between now and then.
* * *
I realize that documentation on writing Mac apps is hard to find these days. Books on the subject are rare, and any book you find may be out of date.
One of the reasons I made Evergreen open source is so that people who want to write a Mac app have some examples.
And I just learned that there's a big list of open source Mac apps. This is way more than than was available when I started writing apps for OS X.
I don't have time to write a book on Mac app development. I wish I did. I might make the time to do a small article now and then, using Evergreen as example. Maybe.
But it's not my job (as I have to keep reminding myself). It's Apple's job to document and evangelize the Mac platform.
(As an additional part of that, I'd like to see Apple update the Mac App Store, and maybe also deal with some of the issues with sandboxing. It would signal that the company cares about Mac apps. I know it does care, but a more public demonstration would be welcome.)
With the recent talk about Electron and "Marzipan" — or maybe Amber or something, according to Mark Gurman — I'm reminded of a thing I think about kind of often: that making iOS and macOS apps is way harder than it needs to be.
For most apps (except games, I suppose), a huge percentage of the code might as well be written in a scripting language. We absolutely do not need to be writing everything in Swift, Objective-C, C++, or C.
"But Brent," you say, "what about performance?"
Consider the case where you set up an animation and then run the animation. The system does that animation. Or consider Core Data — your choice of language doesn't affect how fast it can read from SQLite. Or think of networking — it's bound by the connection, not the speed of your code. Or think of pushing a view controller onto the current navigation view controller. Or setting up view constraints. And so on.
All this code might as well be Ruby — or, preferably, a scripting language designed for app making. (I would have liked an Objective-C-without-the-C.)
And the thing that would make it all so worthwhile is editing the code while the app is running. You could go all day without an explicit build step!
Sure, some of your code would still have to be written in Swift or whatever. The part that really does have to be fast. I'm a performance junkie myself, so I get this. (Evergreen's RSS parser is fast, and I wouldn't switch it to a scripting language.)
But most of most apps (again, probably besides games, about which I know nothing) could be written using a scripting language.
PS Yes, I'm quite aware that we used to have Fix & Continue. And WebScript.
Some of the press coverage about The Developers Union uses words like "angry" and "fed up." These aren't accurate characterizations at all. Nobody's mad here!
But here's the deal: Apple controls the App Store and its economics. The system could be set up better to support high-quality apps, by indies, that last for years.
Apple doesn't have to, of course. But we can ask! It's totally okay to ask, so we are.
We think that an important first step would be a standardized, App-Store-supported way of offering free trials. (And where, once purchased, Family Sharing works.)
Trial versions have worked great for years for indie Mac developers, before the App Store, and we think it would benefit indies on the iOS and Mac App Stores.
And the platform would get better — and more sustainable — apps. Everyone wins!
If you agree, you can sign up. Add your name. Add your app.
I realize you might be worried about doing a thing that could upset powerful people inside Apple. I strongly doubt that that worry is actually well-founded — but, then again, that's part of why this is a big list.
* * *
I should note that I'm not doing this as part of Omni. I'm not even doing it for my side projects — they're all free, and it's quite possible that none of them will ever appear on any App Store at all.
Instead, I'm thinking of my friends, of developers I admire, of up-and-coming developers I haven't even heard of yet. I — quite selfishly! — want them to thrive. I want to see what great stuff they could make. I want everybody to have the opportunity I've had.
I've been lucky, and I've done well — and my experience should not be rare.
Lately I've been trying to learn to play delta blues. I'm not ever going to play like Robert Johnson — nobody ever will — but I'd like to learn it as well as I can. Well enough so that, if you like the blues, and you heard me at a coffee shop, you'd enjoy it.
(Not that I'm going to start playing at coffee shops.)
I've been playing guitar for 38 years, and I've known the 12-bar blues progression and the blues scale for almost as long. But I always figured that learning to play like this would be way beyond my abilities.
* * *
The first thing to notice is that, in the hands of someone like Robert Johnson, it sounds like two guitars playing.
Roughly speaking: the thumb is doing a regular shuffle beat, often with two strings, while the other fingers are doing fills and melodies. At the same damn time.
I'm a life-long strummer and power-chord player. Flat pick. Rhythm guitarist. I've never had to develop this kind of coordination. It's difficult.
The second thing to notice is that every single pitch your guitar can make is on the table. Sure, there's a progression and a scale — but players regularly use notes outside the standard blues scale, and they hit pitches, by bending strings, that are between the notes.
And throw a slide in — which I'm learning to do — and it's just nuts.
This music is incredibly complicated compared to the pop rock I've always played.
* * *
But I am learning it. Slowly. It's going to take a few years before it sounds effortless. Right now I sound like a person trying really hard.
The thing is this, though, and this has wider application: for some reason, when I was a teenager, I told myself that I didn't have the talent to play anything more complex than basic rhythm guitar.
I learned the cowboy chords, barre chords, power chords, notes in first position — and convinced myself I didn't have the ability to learn fingerpicking or delta blues or anything that would make me a musician as opposed to just someone with a relaxing hobby.
I honestly don't know why I thought that! I mean, I learned all this stuff, and figured I couldn't keep learning at some point?
But here I am, now, learning it. It's hard, but I'm learning.
* * *
Maybe I was confused by the word "talent." I didn't think I had that thing — where is it? I can't see it — and I figured that, without it, I had hit my wall.
But... I've always been good at rhythm. It comes so easy that I thought everybody had that ability. And then I've seen other guitarists struggle at rhythm bits that take me no time to learn.
I'm also very good at remembering songs. It's like I have a karaoke machine in my head. This comes with little effort at all — once I learn a song (sometimes just by hearing it) then, usually, I know it forever.
At least the chords. At least enough to be able to play it by the campfire. (Or at a piano, because that's a thing I do too. Though I play piano like a rhythm guitarist. :)
Maybe these are some small musical talents that I actually do have?
But: hearing pitches and intervals and understanding melody is much harder for me, and that's just come with a ton of practice. Mostly by listening, trying to recreate what I hear, and trying to figure out why it works.
* * *
I think I'm making a point about impostor syndrome. I told myself I couldn't learn to play guitar at a deeper level — at the level of real musicians — and here I am at age 50 wondering why I told myself that, because here I am doing it.
Why did I wait so long?
And, sure, maybe I do have some small amount of musical talent, but whatever. If I hadn't, I probably wouldn't have been interested at all.
So maybe it's a good bet that if you're interesting in a thing, you may already have some talent for it. And maybe, just maybe, interest and talent are really synonyms, or close to it.
* * *
PS I started playing with a thumbpick to get that bass shuffle sounding good.
I've heard more than once that at WWDC we'll learn about how we can run iOS apps on Macs.
I'm worried, of course, that this will lead to the further degradation of the Mac UI, and even less incentive for developers to write Mac apps.
I'm agin' it. But, also, I don't know if it's true and I don't know any details — so maybe it would be awesome? We'll see.
Or not see. Could be totally made up. Could just be speculation run wild.
PS "Agin'" is short for "against," not "aging." Okay?
Now that I've switched over to marketing, people — co-workers, even! — keep asking me what I actually do all day.
Fair question. Since I'll probably get asked the same thing in San Jose next week, I figured I'd write it up.
Our team could be a small software company on its own — we have engineers, testers, designers, and a person who makes movies. Everything I do is part of working with that team.
If you think I'm being paid to be a blogger and podcaster, you're not too far off the mark, but that description misses some things.
Note: again, though, it's a team effort. Some things go through extensive feedback and editing before being finished.
And some things — like the product pages — will evolve a bunch during design and production. As it takes shape we can see where the writing needs to change.
And some things I write — especially anything that ends up in an app — will probably get revised by other people before it ships.
I do some things besides writing. I edit customer stories for Inside OmniFocus. I work with people who write to Omni's marketing email address.
And even the writing isn't just writing — I help figure out what to write, and when, and how to talk about things.
So there you have it. I'm part of a team, and my particular role is the words. And there are a lot of words.
PS See How We Do The Omni Show for what all goes into making the podcast.
The United States of America was the easy-to-choose target for the fascists.
It was the richest and most powerful country in the history of countries. How could any fascist not want to take it over?
It was the work of several decades.
They built up a giant military/industrial partnership — mixing government and unaccountable corporations with secrets — with almost no resistance.
Sure, they faced some setbacks from time to time: the end of apartheid in former slave states, for instance. But they fought back by privatizing the prisons, instituting mass incarceration, and militarizing the police force — and ensuring that it remained a tool of white supremacy.
They stoked fear of communism, as if adding just a penny of tax meant imminent Sovietization; as if labor unions were anti-American insurgents; as if a social safety net would make Jesus cry. As if "equal opportunity" meant Fidel Castro walking into your house with a machine gun.
They gutted the education system and fought knowledge with mass disinformation. They made sure that corporations could and would hook Americans on opioids and blather and outrage.
While some of us did learn that the beauty of America is our constant striving to better understand our founding creed — and finally live up to it — they made sure that half of us believed in America as a land and as a race.
And now that they've won — they've gotten their orange leader with the red cap, they've gotten their system of cruelty — they're carving it all up for themselves. They're cutting it all up with jigsaws and burning what they can't use right now.
There were, and still are, leaders who could fight back, but who just plain refused.
If we're lucky enough one day to have a true history, those people will go down as among our greatest traitors. Every day I long for that day.
I can write just about anything I want to on my blog for the simple reason that it doesn't matter.
Times change. Fascists learn. There's no pressing need to cut off any websites.
* * *
Fascists don't leave so many fingerprints these days.
Example: there's no actual agreement anywhere that makes Twitter a de facto arm of the Trump Executive Branch and all its unofficial partners — but it is.
Twitter bans the people who report abuse and it retains the Nazis and Russians. It amplifies the distractions and fills the pipe with lies and outrage. (And gives us special emoji as rewards.)
The truth can't be found in the ever-thickening fog.
Though Twitter has been used for good, I'm more and more convinced that giving it anything just feeds it. If the medium is the message, then the message is lies, lulz, and bullshit, no matter what you put in.
* * *
That's not to say that fascists won't ever take our freedoms away. The fascists grow stronger and bolder, and those who would check their power chicken-out.
But it won't usually be laws, or even executive orders, that take away freedoms. Think of the NFL, which — utterly disgracefully — now mandates against kneeling.
Samantha Bee survives on TV this year — but will she survive next year?
* * *
What if agents in the Secret Service or FBI begin quietly talking to bloggers or tweeters who express an anti-Trump point of view? No law needed. No take-down notice. It's just agents doing their jobs.
Would you keep blogging after having a quiet meeting with a couple armed men who — politely and calmly — explain that they're just checking to make sure you're not a threat to national security?
Would you even tell anyone about the meeting?
This hasn't happened to you. Okay. (Or to me.)
But how would you know if this is already happening to other people? If a friend told you a rumor that it was happening, what would you think? Is it plausible from the team that already works so hard to discredit the free press? If you thought it might be true, would it change how and what you write?
Consider that there wouldn't have to be any order or directive at all from the White House to the Secret Service or FBI. The White House wouldn't even have to know about it.
This is one way fascism works. It leaves no marks. It doesn't even have to lift a finger sometimes.
They don't have to do this at all, in other words. They just have to get to the point where you wouldn't put it past them. At that point they can let our imaginations and rumors do the rest — and people will surrender their voice.
For the record — and this is super-important — I do not believe this is happening. This is merely illustration, and I'm not that paranoid, and you shouldn't be either.
Some time last year I decided to retire from doing prepared talks at conferences.
I've been doing them for 15 years, and I've enjoyed some of them. Eventually I started playing with the form, and that was kind of fun.
The best talks I ever did usually had some story-telling parts, and those turned out to be the parts that people liked most. The only problem with that is that my stories usually didn't have anything to do with the conference. I just like telling stories. Stories about raccoons and squirrels. :)
Preparing a talk is a lot of work, and my standards for my talks kept going up, which meant ever more preparation, and more stress — and since I didn't love it, I decided to stop.
I don't mind being in front of an audience, though — I'll emcee, appear on a panel, moderate a panel, or play in a Breakpoints Jam.
But the actual talks from me are over.
Here's the thing, though: this means one less middle-aged white man taking up a slot. This is a good thing. If you were thinking of asking me to do a prepared talk at your conference, instead ask someone who doesn't look like me.
And if you're having trouble finding someone, just ask me and I'll help.
Om Malik on blogging:
They are incomplete and by nature more mysterious, more episodic, and thus more interesting. Blogs are meant not to leave you with everything. The whole idea is to think to deliberate, and to come back again and again, to finish what was started a long time ago. But there is no end, just a pause, for a voice to start, talking again.
I love that.
I never became the Hemingway or Fitzgerald type of writer that I wanted to be when I was young. No short stories, no novel, no cover of Life magazine.
But I have written a blog for almost 19 years — and that's something. It's still a new medium, and it's new to have blogs hitting (and even passing) the 20-years-mark.
Here's a provisional thought (all thoughts on a blog are provisional) — to read a good blog is to watch a writer get a little bit better, day after day, at writing the truth.
When I was a kid we spent more time with my Mom's family than with my Dad's, but we still spent lots of holidays with my Dad's family.
My Dad is the oldest of four siblings. The youngest, his brother, is only 10 years older than me. I remember my uncle and his sisters when they were teenagers.
The thing about the family was that everyone was constantly joking and laughing. I loved this.
I wanted to join in, so I did, from an early age. And sometimes I even got laughs! But most of the time I didn't.
One day my uncle — who must have been about 20 then — gave me some advice about it. He said, "Hey, you don't have to say everything you think of. Just the ones that are actually funny."
Okay, I thought, so now it wasn't enough to be fast enough to think of something that might be funny — I had to also evaluate it for likeliness? All in the space between sentences? And make it seem natural? Who can think that fast?
I think what he was doing was trying to get me to be less annoying. But I took it as earnest advice. And, well, I remember thinking, after a while, that it worked.
* * *
My uncle, Peter Simmons, became an actor and writer. He lives these days in Minneapolis, and he surely remembers none of this conversation.
* * *
My uncle had a dog named Whisky who was born the same spring when I was born. I called him Uncle Whisky, and I believed, until I was about 10, that of course dogs can be uncles too. Perfectly natural.
* * *
Whisky — sometimes called Wick for short — enjoyed hors d'oeuvres in the afternoon. There was always chips and that sour cream and onion dip. When you picked up a bad chip, you gave it to the dog. Those were called Wicker Chips.
To this day when I get a bad chip I mentally set it aside for Whisky, who was a good dog and a great uncle.
* * *
I'm a terrible introvert. The other introverts around me seem extremely outgoing. I marvel at them.
But I had this weird family training, and so I can, for instance, go around a room at a conference with a microphone and talk to every single person, put them at ease, quickly think of things to say, make it seem natural — and even be a little funny.
Not only that — I enjoy it!
And I can do a podcast. And I can point to the latest episode with Aaron Cherof as one of the better episodes. I suspect Aaron may have had a family kind of like mine.
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.
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.
C C C C
F F C C
G F C C
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:
I I I I
IV IV I I
V IV I I
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:
I I I I
Oh baby, don't you want to go
IV IV I I
Oh baby, don't you want to go
V IV I I
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
step on my blue suede
You can do anything, but
lay off of my blue suede
(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.)
(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.
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.)
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.
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.
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. :)