Archive for May 14, 2015

Thursday, May 14, 2015 [Tweets] [Favorites]

Validate Project Settings: Never

Jeff Johnson:

Xcode likes to “helpfully” suggest changes to your project’s build settings. And this doesn’t happen just once. New versions of Xcode come up with even more “helpful” suggestions. So, get used to seeing the warning icon when you open your project. I mean projects. My company’s main source repository contains almost 90 Xcode projects. Each of which will show a warning icon when you open it with a new version of Xcode.

[…]

My genius idea, if I may say so myself, thank you, was to manually edit the project file and replace the LastUpgradeCheck value with 9999.

Unfortunately, this was not a complete solution. I discovered that Xcode checks not only the project but also the schemes. So you also have to manually edit the .xcscheme files for your project(s). The relevant key in those files is LastUpgradeVersion, which can also be set to 9999.

Daniel Jalkut (tweet):

The problem is a well-managed project might include settings that match Apple’s recommendations but rather than being set explicitly on a project or target node, are instead inherited from a project or target base .xcconfig file. In this scenario, Xcode repeatedly nags about updating the project or target even though the desired setting already shines through.

The problem with allowing Xcode to simply set the desired settings on the project or target is it shuts down the ability to accurately control build settings from the centralized location in the .xcconfig file.

Indeed, I’ve found Xcode’s suggestions to be more hindrance than help. They’ve broken my projects by overwriting settings with incorrect values and also, like Jalkut says, messed up inheritance, which led to problems later. But I do like to see what Xcode is suggesting, and, unlike Johnson, I don’t have very many projects. So these days I let Xcode change what it wants to and then (usually) Git-revert all the changed lines in the project file except for the LastUpgradeCheck.

Update (2015-05-14): Daniel Jalkut:

I also added a test for unwanted build settings to my integration tests, and am thinking of adding a commit hook to reject them.

I made an effort to codify settings by whether they should or shouldn’t, or “not sure.”

Dropbox’s Firefly Full-Text Search Engine

Samir Goel et al.:

As a result, we chose a sharding function based on “namespace”. A namespace is a widely used concept in our production systems. Internally, we represent a user’s Dropbox as a collection of namespaces. Each namespace consists of files and directories, along with a directory structure, and is mounted at a certain directory path within a user’s Dropbox. In the simplest case, a user’s Dropbox consists of just one namespace mounted at “/”, which is called the “Root” namespace.

[…]

This is still inefficient, as a shard typically contains a large number of namespaces (in the millions), while a user typically has access to a handful of namespaces. To make the query processing even faster, we prefix each token in the search index with the ID of its namespace: {namespace-id:token => list of document IDs}. This corresponding list of documents contains only those that contain the token and are also present in the namespace. This allows us to focus our processing on the subset of the search index that is relevant to the set of namespaces that belong to the user. For example, if a user with access to the namespace with id ns1 issues the query “san francisco”, we process it by intersecting the list of document IDs for tokens: "ns1:san" and "ns1:francisco".

An @import-ant Change in Xcode

Craig Hockenberry:

Buried deep within the Xcode 6.3 release notes there is a true gem that can relieve this daily frustration.

LLDB’s parser for Objective-C can now go through any module used in your app and determine the types used for all functions and methods it defines. If you’re using UIKit in your app, you can do this:

(lldb) expr @import UIKit

Verizon-AOL

Ben Thompson:

Verizon, meanwhile, knows a lot about its users:

  • By virtue of being a paid service, Verizon knows users’ names, addresses, and even social security numbers (gotta run those credit checks!)
  • Because they are a phone carrier, Verizon knows your location, something that is useful not just for serving ads but also for ascertaining whether or not they were effective (seeing a McDonald’s ad and visiting the Golden Arches soon after is a powerful signal)
  • Because they are the ISP for your mobile phone (and for many customers, their home as well), Verizon doesn’t need a cookie or device identifier: they can set a “super-cookie” on their servers to track everything you do on the Internet, and that’s exactly what they’ve done

This is why the deal makes so much sense: AOL provides the technology to target individuals instead of content, and Verizon the ability to track those individuals — at least the over 100 million customers they already have — at arguably a deeper level than anyone else in digital advertising (for non-Verizon customers, AOL’s ad platform is still useful, albeit not as targeted; rates would be commensurately lower). The talk of this mashup joining Facebook and Google to form a “Big 3” of digital advertising is not unrealistic.

Jason Karaian (via John Gruber):

With its stock inflated by dot-com mania, AOL was worth $224 billion in today’s money back in 2000, just before it launched an audacious, expensive, and ill-fated bid to combine with Time Warner.

Nothing about AOL today is on the same scale as back then. In a neat bit of symmetry, the $4.4 billion price tag that Verizon is paying to buy the whole of AOL today is the exact same amount as the company’s dial-up subscription revenue in the year 2000.

William Zinsser, RIP

Douglas Martin:

William Zinsser, a writer, editor and teacher whose book “On Writing Well” sold more than 1.5 million copies by employing his own literary craftsmanship to urge clarity, simplicity, brevity and humanity, died on Tuesday at his home in Manhattan. He was 92.

[…]

Mr. Zinsser went beyond [Strunk and White’s] admonitions on writerly dos and don’ts; he used his professional experience to immerse readers in the tribulations of authorship, even subconscious ones.

Zinsser’s book is one of my two favorites about writing. I’d recommend On Writing Well for the bigger picture and Style: Toward Clarity and Grace for the more nitty gritty.

Update (2015-05-17): On Writing Well is available at the Internet Archive (via Hacker News).

John Gruber:

I could not recommend that book any more highly. Everyone could benefit from reading it — and, every few years, re-reading it. A classic for the ages.