Archive for June 30, 2016

Thursday, June 30, 2016

“I’d Like You to Police Each Other”

Natalie Kerris (former Apple PR executive):

In honor of today’s 9th anniversary of the original iPhone launch: Steve Jobs PISSED OFF moments (1997-2010).

Jason Snell:

Features that classic moment when he asked journalists to stop doing their job. Sorry, Steve, no chance.

The reason there were 500 base stations is that Apple didn’t want to provide Internet for the room. That changed fast.

Last night in the @atpfm chatroom the Tipster said the reason iOS has Ethernet support is because of that demo fail.

See also: Steve Jobs FUNNIEST moments, which I like even better, and Steve Jobs contradicting moments.

Why Google Stores Billions of Lines of Code in a Single Repository

Rachel Potvin and Josh Levenberg:

The Google codebase includes approximately one billion files and has a history of approximately 35 million commits spanning Google’s entire 18-year existence. The repository contains 86TB of data, including approximately two billion lines of code in nine million unique source files.


Managing this scale of repository and activity on it has been an ongoing challenge for Google. Despite several years of experimentation, Google was not able to find a commercially available or open source version-control system to support such scale in a single repository. The Google proprietary system that was built to store, version, and vend this codebase is code-named Piper.


Most developers access Piper through a system called Clients in the Cloud, or CitC, which consists of a cloud-based storage backend and a Linux-only FUSE file system. Developers see their workspaces as directories in the file system, including their changes overlaid on top of the full Piper repository. CitC supports code browsing and normal Unix tools with no need to clone or sync state locally. Developers can browse and edit files anywhere across the Piper repository, and only modified files are stored in their workspace. This structure means CitC workspaces typically consume only a small amount of storage (an average workspace has fewer than 10 files) while presenting a seamless view of the entire Piper codebase to the developer.


Trunk-based development is beneficial in part because it avoids the painful merges that often occur when it is time to reconcile long-lived branches. Development on branches is unusual and not well supported at Google, though branches are typically used for releases. Release branches are cut from a specific revision of the repository. Bug fixes and enhancements that must be added to a release are typically developed on mainline, then cherry-picked into the release branch. […] When new features are developed, both new and old code paths commonly exist simultaneously, controlled through the use of conditional flags. This technique avoids the need for a development branch and makes it easy to turn on and off features through configuration updates rather than full binary releases.

The Android and Chrome teams are separate and use Git.

Seeing Apple Through Color Blind Eyes

Jason Snell:

There are a few video games that I’m unable to play because they require quick sorting of colors that I have difficulty differentiating. Some of them have special modes for people like me; others just never think about it. The developers of Destiny did a lot of work to update the game’s controls and heads-up display in order to make it more usable by people who can’t perceive colors the way most people do.


I can’t really tell the difference between the green and the amber lights at a glance. For a long time, I didn’t even realize the light on the MagSafe connector changed color. (Apple is far from alone here — lots of electronics use subtle color shifts of an LED to indicate things in a way that I simply can’t digest.)

Summer Travel Tech Hacks

David Pogue:

In this video, I’ve distilled all my tricks for painless, speedy plane travel into a brisk, illustrated three minutes. For your reference, here are the sites and apps I’ve come to rely on[…]