Post mortem

The first 30 minutes or so of yesterday’s Apple event were, for those of us viewing it remotely, a psychedelic mix of color bars, sudden jumps forward and backward in time, and simultaneous Mandarin translation. I was so distracted by the video stream’s bizarre behavior I didn’t get a chance to tweet about Phil Schiller’s shirt-tuckedness. Fortunately, Jason Snell, Serenity Caldwell, and Dan Moren were live-blogging at the Macworld site so we could keep up until the stream settled down. I’m sure the higher-ups at IDG will reward them handsomely for the vital service they provided.

The iPhone 6 and 6 Plus were about what we expected. Bigger screens, better cameras, (somewhat) faster processors. The shift in storage sizes from 16/32/64 to 16/64/128 was a little weird, and those who were expecting sapphire screens were probably disappointed (they shouldn’t be—Gorilla Glass is amazing stuff). Overall, a solid upgrade, and they’ll sell like crazy as they always do.

One thing I’m looking forward to is seeing how sales of the 6 and 6 Plus compare. Not that I care about sales per se, I just like seeing the failed predictions of tech journalists who think they have their fingers on the pulse of the market. Last year, many pundits confidently predicted that the 5C would be the big seller based on nothing more than a kind of sneering view of “normal people” who—unlike the pundits themselves—don’t understand the hardware well enough to get the best. This year, the early predictions are that the 6 will be the big seller because it’s for normal people. We’ll see.

The Apple Watch is an impressive piece of technology and looks to be very well thought out. But Ben Thompson is exactly right when he says the presentation didn’t do a particularly good job of explaining why we should go out and get one. He contrasts yesterday’s event with the introductions of the iPod, the iPhone, and the iPad. I didn’t see the iPod event, but I can tell you I wanted both the iPhone and the iPad after seeing their introductions. Not so with the watch. Initial impressions can change—I never did get an iPad—but right now I see myself admiring Apple Watches, not buying one.

To me, the most impressive part of the event was the most unlikely one: the introduction of Apple Pay. This is not because of my fascination with Eddy Cue,

Four Eddys

but because he had a good story and he told it well.

I’m not a security expert, but the stuff about generating one-time payment codes and not storing the card numbers themselves sounded like good ideas to me. Particularly effective were the slides that said

I may be especially receptive to this pitch because of what’s happened to my wife and me this year. At the beginning of the year, we were issued new credit cards because of the Target breach. We went through the long process of changing our card information at all of our online and automatic payment accounts. A few months later, Chase caught a fraudulent use of our new card number, and we had to go through the process again. The recent news about a breach at Home Depot has me expecting another go-round. That’ll be three new cards issued in one year. We haven’t lost any money in these incidents, but we’ve lost time.

I know that Apple Pay won’t prevent this from happening again. Still, the more we’re able to use it, the less exposure our card number gets, and that can only be good. It’s an unexpected plus for the new iPhones.

Update 9/11/14
Unsurprisingly, Myke Hurley was also interested in Apple Pay. He’s talked about the contactless payment systems used in Europe in the past and discusses Apple Pay in that context in the most recent episode of Connected.


Chock amok

During this calm before the upcoming Apple storm, we should all take time to read and contemplate the 30+ years of command line wisdom summarized in this recent post by Craig Hockenberry. I started using some of his tips right away; others will have to marinate for a while until I’m ready to chew on them.

Craig’s tips cover a broad range of topics and include discussion of

So far, my favorite tip has been the addition of these two lines to my .bashrc file to search backward and forward through my command history using the up and down arrow keys:

bind '"\e[A":history-search-backward'
bind '"\e[B":history-search-forward'

Bash normally uses ↑ and ↓ to move backward and forward in the command history one command at a time. But if you have the beginning of a command typed, these bindings cause ↑ and ↓ to move back and forth through only those commands that start the same way. Very clever and very useful. For years, I’ve been using ⌃R and ⌃S to search backward and forward through the command history, but this is much simpler.

The section of Craig’s post I need to study further covers the md* commands that leverage Spotlight and the metadata it uses. I’ve used mdls to get the duration of audio files, but there’s so much more I could do with it and mdfind.

I think the best way to thank Craig is to write up our own tips. Here are a couple of mine:

I look forward to seeing Terminal tricks from all of you.


  1. For reasons lost in time, don’t have a .profile file. I keep my bash settings in .bashrc and have a .bash_profile file that sources it. Something to do with login and non-login shells, as I recall. 


YAMF

You didn’t really think I’d be able to resist writing a post on the Standard Common Markdown clusterfuck, did you? Even though Joe Rosensteel already said a lot of what I was going to say, even though I suggested on Twitter

Existential crisis averted. Also, I can blog about something else tonight.
blog.codinghorror.com/standard-markd…

Dr. Drang (@drdrang) Sep 4 2014 6:48 PM

that I’d give it a pass, I just can’t. In the words of John Lee Hooker: it’s in me, and it’s got to come out.

I started writing in Markdown in 2004, back when John Gruber was still making changes to the Markdown.pl code and was still accepting suggestions for features and bug fixes. It was the newcomer in the plain text markup field, and I took a risk in adopting it instead of the more established forms like Setext, reStructured Text, Textile, and Pod. But, as I said in this post, I chose Markdown because

Fundamentally, Markdown was tolerant and inclusive. At the risk of some ambiguity, it let you write pretty much the way you’d write a nicely formatted plain text email and turned it into HTML for you. It was both easy to write and easy to read in source form. The readability of Markdown was key. If a normal person could read your Markdown source and understand its structure, chances are Markdown.pl could, too.

The ambiguities I mentioned didn’t exist within Markdown.pl, of course. It did what it did the same way every time, as did the other Markdown implementations. But they didn’t all do exactly the same thing, especially when it came to tricky combinations of blank lines and indentation. This bothered a lot of people, most prominently John MacFarlane, who undertook a study of Markdown’s nooks and crannies to find its inconsistencies. He did this to help him write his wonderful Pandoc and PEG-Markdown programs, but I suspect he had a secondary motivation as well. A philosopher who works in logic would naturally rebel against the messiness of Markdown.

Those of us who read MacFarlane’s messages on the Markdown mailing list didn’t need Jeff Atwood to tell us who the primary author of the Standard Markdown spec was. It has MacFarlane’s fingerprints all over it. It’s impressive work, but I have to say I find much of it unnecessary in practice.

Take a look at the ambiguities shown in Section 1.2 of the spec and the lists shown in Section 5.2. Many of these constructions are inherently ambiguous, by which I mean a normal human being would have difficulty interpreting the author’s intent. In my view, Markdown was never meant for these situations, and it’s perfectly fine for different implementations to output different HTML. These inherently ambiguous constructions aren’t readable and therefore aren’t really Markdown. If they produce unpredictable output, so be it—they are garbage input.

(That said, there are some constructions that are unambiguous to any reasonable reader but can produce surprising HTML. The presence or absence of a blank line between list items is an unfortunate example. But you soon learn to deal with it.)

As I read through the spec, I was surprised to see no support for tables, footnotes, or definition lists—common extensions to the feature in Markdown.pl. At first, I thought Standard Markdown truly was just trying to clean up Markdown.pl’s messes. But then I saw the section on fenced code blocks and I realized I’d been duped. Joe Rosensteel put it best:

In the “Standard Markdown” spec, they include GitHub Flavored Markdown’s “fenced code blocks”. Oh! Well, would you look at that! It’s a feature that serves the needs of one of the “Standard Markdown” contributors. It has nothing to do with the original specification of Markdown. This isn’t solely about removing ambiguity, of course, it’s about making the Markdown someone wants in to the correct Markdown.

In other words, Standard Markdown isn’t a solidly built Core Markdown. Nor is it a Comprehensive Markdown with a bunch of helpful features that ol’ bastard Gruber refused to add. What it is is Yet Another Markdown Flavor, with a feature set tied to the needs of Meteor, Reddit, Stack Exchange, and GitHub. There’s nothing wrong with that, but it isn’t setting a Standard. It’s what everyone else does—some better, some worse. And in John MacFarlane’s case, he’s done it better at least three times.

I’ve been writing in Markdown for ten years and have used several implementations. Gruber’s 4,000-word syntax documentation has never led me astray, perhaps because I’ve paid attention to the opening paragraphs:

Markdown is intended to be as easy-to-read and easy-to-write as is feasible.

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters — including Setext, atx, Textile, reStructuredText, Grutatext, and EtText — the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

I’ve almost never run into the problems that YAMF, with its 15,000-word spec, was designed to solve. And because it’s missing extensions I use every day, YAMF can’t process the blog posts and reports I’ve written over the past decade, nor will it handle what I intend to write in the future. Putting aside the politics of the situation, it just won’t work for me.


iPhones

The consensus is that Apple’s going to announce two new, larger iPhones: one at 4.7″ and the other at 5.5″. The iPhone 5s, with its puny 4″ screen, will drop in price and get on the two-year conveyor belt to retirement. If that’s true, it means Apple is abandoning the “compact” smartphone, leaving that market to Samsung and HTC with their Minis.1 I think that’s a mistake, and I wonder if that’s really what Apple plans to do.

I’ve said before that although I’m the perfect target for a larger phone, many people prefer and are better served by the current iPhone size. Women’s clothes, in particular, are typically not designed for carrying large phones, which is why I see lots of women carrying their phones in their back pockets—they just don’t have any other place for them.

This is the point where men often say “But they have purses!” Very observant. You might also have noticed that women don’t carry their purses as they move around their homes or workplaces. But they still want to keep their phones with them.

Tim Cook famously said that he was not going to leave a price umbrella in the tablet market. Shortly thereafter, the iPad mini appeared. I find it hard to believe he wants Apple to leave a screen size umbrella in the phone market, especially since Apple is currently the dominant player in smaller sized phones.

On the other hand, I’ve seen no leaks concerning a new 4″ iPhone. Surely if one were in the pipeline we’d have seen something about it by now. So if there’s no new 4″ iPhone, doesn’t that mean Apple’s giving up on that size? Maybe not.

In moving to a 64-bit processor last year, Apple made a jump in technical specifications that Samsung and HTC still haven’t caught up with. Maybe Apple believes that this head start, combined with a decreasing demand for smaller phones, will allow it to shift to a two-year update cycle for smaller iPhones. In which case, we won’t see a new 4″ phone this year, but we will see one in 2015.

Are you sure Apple won’t use a two-year update cycle because they never have before? Don’t be. First, “Apple always/Apple never” arguments are just plain silly—Apple does what it thinks is best and doesn’t care if it breaks some perceived tradition. Second, the iPod nano and iPod Touch haven’t had a significant update in two years and they both used to be on a one-year update cycle. Times change.

I’m perfectly willing to believe that I’m all wet on this and that Apple’s review of trends has told them that there’ll be no market for smaller phones in a couple of years. If that’s the case, they’ll play out the string with the 5s and that’ll be that.


  1. Which are still bigger than the iPhone 5s, but only by a little.