Links

Very thoughtful analysis.

Reading this an hour before Apple’s extremely hyped event, the answers provided to the questions asked in this article are the ones to look for:

What’s notable is the percentage of people who don’t see what makes a smartwatch particularly useful. While MP3 players could be marketed as a replacement for CD players, and smartphones could be sold as better cell phones, smartwatches have nothing to displace. Companies have to persuade people to add a device to their lives. And given that, people aren’t going to buy smartwatches unless they do something that existing devices, like smartphones or fitness trackers, don’t do—or, in any case, unless they do it better.

So far, no smartwatch has accomplished this. Sure, you can put your Galaxy Gear to your ear and make a call, or hold it in the air and take a photo, but you can do all that—and without all the calisthenics—with a smartphone. Pop-up notifications about e-mails, appointments, and missed calls can be useful, but they can also be overwhelming, and many of the existing smartwatches are worse than smartphones at letting you customize the alerts. Fitness features like heart-rate trackers are nice, but specialized fitness devices like the Fitbit already do all that.

The question is whether Apple can introduce a watch that does more.

The larger security problem, it seems, comes from a general misunderstanding about how a smartphone differs from, say, a large online forum. Most discreet people know not to upload nude photos onto the Internet but are unaware that a photograph shared privately, through a text message or e-mail, is hardly private at all. “Storing data on a phone carries an inherent risk,” Felten wrote. “The complexity of the software on our phones, and the network and cloud infrastructure to which they connect, makes it difficult to identify, let alone secure, all of the points of vulnerability. It’s prudent to assume that anything on your phone is potentially at risk.”

I wonder how much of this was caused by the simple fact that iCloud Photo Streams have always had a messy and confusing mental model. If you send a photo to someone directly from the Messages app, for example, by default it saves that image to the photo album. If it’s saved to the photo album, by default it uploads to your Photo Stream. Just like that, the image you meant to send to someone is also both in your camera roll and in iCloud. If you notice that private photo in your photo album and delete it, it’s not deleted from your Photo Stream, too. You have to switch over to that set of photos and also delete it there. It’s a mess.

Of course it’s possible some of these photos were meant to be kept, but I’m sure some, and maybe most, were meant to be ephemeral. I’ve never met a non-techie that understands what Photo Streams are, and it wouldn’t surprise me if that same confusion is why some of these photos were hackable in the first place.

If you’re interested in iOS architecture at all, here’s a slide deck from a presentation by Tumblr on how they built their iOS app.

Skip to the end to see their final implementation of a performRequest method:

Apple is one of the biggest API platforms in the world — every app running on every iPhone and iPad is built using the Silicon Valley giant’s APIs. We can all develop a better API strategy by examining how one of the leading API platforms:

• Uses their own APIs within their own ecosystem;
• Handles changes to these services; and
• Prioritises end user experiences over other concerns.

One representative post:

My fears reached a high point on the eve of Bastille Day, and a day later on the anniversary of the Vel D’Hiv roundup of French Jews by the puppet Vichy government for transport to Auschwitz. On July 12 and 13, during a massive pro-Palestinian demonstration in Paris, several groups spread out to synagogues in the middle of Paris to threaten the Jews inside, while in Aulnay sous Bois, outside the capital, a synagogue was hit with Molotov cocktails. The mobs chanted “Death to the Jews,” and a politician from the Green party said it was “not surprising that synagogues are attacked when they support Israel’s policy.

Reading the somewhat terrifying anecdotes from that blog reminded me of a quote from Christopher Hitchens I read years ago on anti-Semitism:

I think that anti-Jewish prejudice is an unfailing sign of a sick and disordered person … It’s a horrible, conspiratorial, pseudo-intellectual, mean spirited, eventually lethal piece of bigotry.

When I first read that passage, it was the phrase “ultimately lethal” that stuck in my head. It’s troubling because it’s true, and seeing anti-Semitism flare up in pockets of Europe has it sticking in my head again now.

Everyone claims to know the secret to Steve Jobs’s “real genius,” which is reductive and often tedious. There are some interesting stories here, though, about Jobs’s role at Pixar and how different it was from his role at Apple.

I remember this gross event when it happened. The way Woodstock transformed from a counter-culture event in the 60s into a mega-corporate event full of bros and violence set to the tune of shitty music encapsulates my mindset in high school perfectly: an awful mainstream culture that would sooner or later appropriate everything that was authentic and good and transform it into something deeply awful.

Alexandros Salazar puts together an interesting technique for greatly simplifying error propogation through multiple layers of an app. As he summarizes:

The need for error handling during computations is abstracted away. All I need to do is specify what computations I want to apply, and map will take care of propagating any errors.

This approach has the potential to remove a ton of boilerplate from the typical data flow of an application. As Alexandros summarizes, the flow of a typical app starts with retrieving data from an endpoint, then parses it into a JSON object, builds up model objects from that JSON, and gets that data on the screen. Each operation usually includes its own level of error handling. That error handling is almost always just propogation of the error from one layer to the next. Alexandros’s technique can simplify that flow such that at each level, the code is only concerned with handling the success case. The error case is automatically and transparently propogated to the next level. The error must eventually be handled of course, but that can happen only at the top level where the error needs to impact the UI. It cuts out all the code duplication of error propogation typically included.

Eliminating code, especially meaningless boilerplate code, is one of the most fundamental benefits any programming language can bring. Every line of code is somewhere a bug might be hiding. Objective-C requires a ton of code to do even very simple things. Techniques in Swift like this that hold the potential of eliminating huge swaths of useless code is extremely exciting.