Nathan Borror

SRSLY WRONG — Sure, it may be "a podcast about liberalism, marxism, utopianism, anarchism, the personal as political, alleged paradoxes, world peace, common ground, phronesis/praxis, metamodernism" but I've mostly been enjoying the banter of two Canadians.

YOUTUBE, Martin Shkreli — Say what you will about the guy, this is actually interesting to watch.

SAN FRANCISCO — Corona Heights.


Ant societies, organised by distributed algorithms rather than division of labour, have thrived for more than 130 million years. — Aeon

"Humor is the only domain of creative activity where a stimulus on a high level of complexity produces a massive and sharply defined response on the level of physiological reflexes." — Arthur Koestler

MISSION — Heavy rotation in no particular order before going all in on Christmas:

PALO ALTO — McLuhan has me scratching my head this morning. My daily routine usually involves waking up, showering and walking a couple blocks for a coffee. On the way out the door I usually grab a book from whatever pile has accumulated—this morning I reached for The Global Village and started reading chapter 9, a dialogue between him and his co-author Bruce Powers. In my wake of confusion and googling I stumbled on this episode of To The Best of our Knowledge which carried me into work this morning. The problem with McLuhan is he says things that get your wheels turning but doesn't really explain anything so your left attempting to fill in the blanks.

POINT REYES — Seashore.


MISSION — Started re-listening to Bruce Sterling SXSW closing remarks on the drive to work this morning and thought I'd share the known recordings. If there are more please let me know so I can update this list: 2006, 2007, 2011, 2012, 2013, 2014, 2015, 2016.

PALO ALTO — Benjamin Bratton talking about Platforms:

Similarly, it is the legal and practical standard size of the humble paper envelope that makes it possible for it to shuttle messages both discrete and discreet; like the urban grid, the envelope's power is in its dumbness. In the 1970s as the world's cities began to more fully merge into the networked hierarchies of today with the widespread standardization of very-large-scale envelopes, made of steel instead of paper, in the form of fixed proportion and attribute shipping containers. Containerization migrated the packet switching from telecommunications onto the transit of physical objects (or perhaps the other way around). It traded the standardized, linear traffic program of the grounded asphalt grid for another, now smoothed into liquid shipping lanes, pacing big packets of objects back and forth across avenues of oceans. (The Stack, p. 46)

The goal of future wars is already established: control over the network and the flows of information running through its architecture. It seems to me that the quest for global totalitarian power is not behind us but is a true promise of the future. If the network architecture culminates in one global building then there must be one power that controls it. The central political question of our time is the nature of this future power. — Boris Groys

WEB OF APPS — It’s pretty clear mobile applications are the new World Wide Web in terms of usage and growth. Some of the best qualities of the prior web are beginning to find their way into the two most popular runtimes and I’m beginning to wonder if they’re attempting to emulate the prior web’s best qualities to achieve more growth and utility for customers. The prior web benefited from a few key things worth reviewing:

  1. A ubiquitous viewport for accessing destinations.
  2. A way to target and arrive at any destination from any other destination.
  3. A seamless way to progress to new destinations and back regardless of their origin.
  4. A universal addressing mechanism.
  5. A common, easy to develop for runtime with progressive loading.
  6. Search.

Both runtimes appear to be making an effort to live up to these qualities as best they can given business constraints. Android’s system back button has echoed the browser back button stitching together past hops in and through apps. iOS now has a recently added (albeit clumsy) way of navigating back. Both Android and iOS now have mechanisms for deep linking into installed apps which mimic the experience of moving from one context to another while maintaining congruity. This also hints at a sorely lacking universal addressing mechanism. iOS has introduced “On-Demand Resources” and “App Thinning” as an attempt to reduce the overhead involved in installing and launching applications — nowhere near the convenience of loading a web page, yet. Both runtimes make an effort to allow developers participation in system-level search through an opt-in implementation of provided APIs. This unfortunately pales in comparison to the opt-out approach of indexing and searching on the web. Recently a rumor cropped up about Google investigating Swift as an optional programming language for Android. This would only slightly improve the abysmal situation of a common language we enjoyed on the prior web. We used to moan about browser incompatibilities and now the effort involved in learning a completely different language and set of APIs is so daunting we don’t even bother.

I suspect things will continue to improve, even the when they involve both runtimes coming together and hashing out differences. Right now we live in a bifurcated web of applications. Information is trapped in compiled applications across two runtimes, not because it’s what developers intended but because the systems designed to execute them wasn’t thought of as an open system.

PALO ALTO — From Jonah Lehrer's Imagine:

The vertical culture of the Boston tech sector existed in stark contrast to the horizontal interactions of Silicon Valley. Because the California firms were small and fledgling, they often had to collaborate on projects and share engineers. This led to the formation of cross-cutting relationships, so that it wasn’t uncommon for a scientist at Cisco to be friends with someone at Oracle, or for a co-founder of Intel to offer management advice to a young executive at Apple. Furthermore, these networks often led to high employee turnover, as people jumped from project to project. In the 1980s, the average tenure at a Silicon Valley company was less than two years. (It also helped that non-compete clauses were almost never enforced in California, thus freeing engineers and executives to quickly reenter the job market and work for competitors.) This meant that the industrial system of the San Jose area wasn’t organized around individual firms. Instead, the region was defined by its professional networks, by groups of engineers trading knowledge with each other.

These casual exchanges—the errant conversations that take place in coffee houses and bars—are an essential engine of innovation. While Jane Jacobs might have frowned upon the sprawl of these California suburbs, the engineers have managed to create their own version of Greenwich Village. They don't bump into one another on the crowded sidewalk or gossip on the stoop of a brownstone. Instead, they meet over beers at the Wagon Wheel, or trade secrets at the Roadhouse. It's not the ballet of Hudson Street, but it's still a dance, and it's the dance that matters.

PALO ALTO — This month's issue of New Philopher has an article by Oliver Burckeman titled A Frictionless Existance:

The implicit promise of efficiency enhancing technologies is that they'll speed our progress toward a future time when the chores are all handled, and we can really start to live. But that time never comes. Instead, one day, you could find yourself living the perfect tech-smoothed life: alone at home, eating takeout food you obtained without speaking to anyone else, watching streaming movies to avoid the ‘pain’ of meeting friends at the cinema… and wondering when exactly it was, in your frictionless existence, that the point of being alive slide entirely out of view.

Burckeman makes it sound like it’s all or nothing—give in to efficiencies and you’ll lead a lonely depressing life. Far from the truth. I haven’t touched a light switch at home in months and it hasn’t made me more depressed about my existence. It’s true, technology will allot us more time, it’s up to us to use it wisely.

MISSION, San Francisco — API link dump:

PALO ALTOCool demo, not convinced AR is the right direction here. Framing objects with your phone's camera while trying to interact with the screen is pretty awkward but I really like the idea of tying together disparate I/O.

280 NORTH, California — Listening to Stephen Hawking and Leonard Mlodinow's The Grand Design:

Economics is also an effective theory, based on the notion of free will plus the assumption that people evaluate their possible alternative courses of action and choose the best. That effective theory is only moderately succcessful in predicting behavior because, as we all know, decisions are often not rational, or are based on a defective analysis of the consequences of the choice. That is why the world is in such a mess.

BELLTOWN, Seattle — Finally got my copy of The Go Programming Language today:

Simplicity requires more work at the beginning of a project to reduce an idea to its essence and more discipline over the lifetime of a project to distinguish good changes from bad or pernicious ones. With sufficient effort, a good change can be accommodated without compromising what Fred Brooks called the ‘‘conceptual integrity’’ of the design but a bad change cannot, and a pernicious change trades simplicity for its shallow cousin, convenience. Only through simplicity of design can a system remain stable, secure, and coherent as it grows.

UNIVERSITY DISTRICT, Seattle — Two-Way bindings between form fields and component state in React provokes too much code. Thankfully React has an addon called ReactLink but it's a mixin which doesn't work with ES6 class syntax so I wrote a quick alternative. First lets look at how you'd typically handle this:

import React from 'react'

class MyForm extends React.Component {
    state = {title: "", description: ""}

    onTitleChange(e) {

    onDescriptionChange(e) {

    render() {
        return (
                <input type="text" ref="title" onChange={this.onTitleChange.bind(this)} value={this.state.title} />
                <input type="text" ref="description" onChange={this.onDescriptionChange.bind(this)} value={this.state.description} />

Pretty straightfoward, each time an input changes it triggers an onChange event to update state. This can get out of hand pretty quickly as the number of input fields increases. Alternativly we could have a base class that bundles up all the change logic:

import React from 'react'

export default class ReactForm extends React.Component {
  valueState(value) {
    return {
      value: this.state[value],
      requestChange: (newValue) => {
        let change = {}
        change[value] = newValue

I'm using similar naming conventions ReactLink uses, but here I've defined a function valueState that we'll use in the updated example below to pass into the valueLink React property on each input. This lets us get rid of all those onChange methods:

import ReactForm from 'form'

class MyForm extends ReactForm {
    state = {title: "", description: ""}

    render() {
        return (
                <input type="text" ref="title" value={this.valueState('title')} />
                <input type="text" ref="description" valueLink={this.valueState('description')} />

PUBLIC STUDIO, San Francisco — For a while now I've foolishly been writing the following code to update state in React components: = "bar"

For simple stuff this works fine, as soon as you want to use componentDidUpdate(prevProps, prevState) you're completely hosed because you've basically manipulated the prevState instead of passing in a new state. If I had read the docs for setState I would have realized it does a shallow merge when you:

this.setState({foo: "bar"})

The more you know.

Palo Alto — Reading more Bostrom:

In general terms, a system's collective intelligence is limited by the abilities of its member minds, the overheads in communicating relevant information between them, and the various distortions and inefficiencies that pervade human organizations. If communication overheads are reduced, then larger and more densely connected organizations become feasible. The same could happen if fixes are found for some of the bureaucratic deformations that warp organizational life—wasteful status games, mission creep, concealment or falsification of information, and other agency problems.

New tools such as Slack and Quip are probably proving big gains for small to medium-sized team's collective intelligence. You could look back and argue Open Source at large wouldn't be where it is without mailing lists and IRC. Today it seems we're trying to take all we've learned growing up with a more efficient medium and thrusting it torwards the world at large. "Here! This worked great for us over the years, look what we've accomplished!"

Palo Alto — Around Spring of last year I started using Go for all server-side projects. While at Dropbox as a designer I was building prototypes using Go to demonstrate new products and to support native prototypes so people could actually use the idea rather than hear folks talk about it. Not much has changed in a year, haven't touched Python once and I've still neglected to read Effective Go. I will, however, pick up this new book :) The community and its values have been really enjoyable.

The Go project includes the language itself, its tools and standard libraries, and last but not least, a cultural agend a of radical simplicity.

Palo Alto — Smart people talking simulation and other things of interest. Related:

The simulacrum is never that which conceals the truth—it is the truth which conceals that which there is none. The simulacrum is true. — Ecclesiastes

Protocol Buffers

MISSION, San Francisco — I've been playing around with protocol buffers lately as an alternative to passing JSON between clients and servers. Below is an example for getting things up and running between a simple client written in Swift and a server written in Go. You can google the benefits.

First you'll need Homebrew to make installing everything easier. Then you'll need Go and the latest version of protobuf (version 3).

$ brew install go
$ brew install --devel protobuf

Swift isn't supported by the main protobuf project so we need to install a plugin (I'm also switching to the Swift 2.0 branch, this probably won't be necessary in the future):

$ git clone
$ cd protobuf-swift
$ git checkout -b ProtoBuf3.0-Swift2.0 origin/ProtoBuf3.0-Swift2.0
$ ./

Before we start writing our server lets define the messages we'll be passing between our client/server. Save the following to a file called hello.proto:

syntax = "proto3";

message HelloRequest {
  string name = 1;

message HelloReply {
  string response = 1;

Using this file we can compile our protocol buffers. This will generate code for Go and Swift:

$ protoc hello.proto --go_out=.
$ protoc hello.proto --swift_out=.

Now we have two files to use in their respective projects, hello.pb.go for the server and Hello.proto.swift for the client.

Lets put them to work by creating a simple websocket relationship. I'm going to use Starscream for the Swift client and this Go websocket library.

For the server create a main.go file add the following:

package main

import (

func handler(ws *websocket.Conn) {
    for {
        // Read the incoming bytes
        received := make([]byte, 1024)
        n, _ := ws.Read(received)

        // Deserialize the incoming request into a HelloRequest
        // object which we originally defined in our hello.proto.
        req := &hello.HelloRequest{}
        if err := proto.Unmarshal(received[:n], req); err != nil {
            log.Fatal("Unmarshaling error: ", err)

        // Create a HelloReply and serialize it so we can send
        // it back to the client.
        reply := &hello.HelloReply{Response: "Hello, " + req.Name}
        data, err := proto.Marshal(reply)
        if err != nil {
            log.Fatal("Marshaling error: ", err)

        // Send the reply to the client.

func main() {
    http.Handle("/", websocket.Handler(handler))
    log.Fatal(http.ListenAndServe(":8080", nil))

Run the following commands to get the server running:

$ go get
$ go build && ./main

For our Swift client we're just going to have a single UIViewController with a button in the top right, when it's pressed it sends a single message to our server.

import UIKit

class ViewController: UIViewController {

  var socket: WebSocket?

  override func viewDidLoad() {

    let add = UIBarButtonItem(barButtonSystemItem: .Add, target: self, action: "send")
    self.navigationItem.setRightBarButtonItem(add, animated: false)

    self.socket = WebSocket(url: NSURL(string: "ws://localhost:8080")!)
    self.socket?.onConnect = {
      print("Websocket: Connected.")
    self.socket?.onDisconnect = { error in
      print("Websocket: Disconnected (\(error)) Reconnecting...")
    self.socket?.onText = { text in
      do {
        let reply = try HelloReply.parseFromData(text.dataUsingEncoding(NSUTF8StringEncoding)!)
        print("Server: \(reply.response)")
      } catch {

  func send() {
    let builder = HelloRequest.Builder() = "Bob"

    do {
      let req = try
    } catch {

Make sure your client project has Starscream, the Swift Protocol Buffers framework installed and the Hello.proto.swift file we generated earlier. Build/Run and you should be able to tap the plus button in the top right to send a message to the server and receive a reply.

If you make changes to hello.proto just rebuild the Swift and Go equivalents.

PALO ALTO — If you're running Go 1.5 you can try out the new gomobile package. Seems like a promising way to share code across Android and iOS.

LOS ALTOS — For the past week I've found myself deep in a rabbit hole of Erlang, Elixir and distributed systems. My mind is beginning to hurt and I need to build something fast to climb out of this. If you're interested here's what I read/watched along the tumble:

Palo Alto — Elixir 1.1.0 is out and the peanut gallery seems pleased. Elixir is probably gonna be a big deal. It doesnt have the backing of a large company but that's probably fine for now.

Palo Alto — RSS is seeing an unexpected resurgence. Apple is using it for its new News app and Facebook is using it for Instant Articles. I've also noticed the once popular Net News Wire on the front page of the Mac App Store. Making me a little nostalgic...

Mission, San Francisco — Digging up old Dave Winer podcasts for kicks. In this one he talks about the introduction of OpenID and how new platforms almost never come out of consortiums. Fast-forward a few months and listen to him talk about Twitter, fun platform while it lasted but a disaster when the business got real. Now Slack.

Mission, San Francisco — If you haven't heard of In Our Time from the BBC then I suggest checking it out. I spent a good chunk of this past weekend listening to episodes on Karl Popper, Nihilism, Karl Marx and Schopenhaur.

Mission, San Francisco — HyperCard was before my time as an Apple user but probably pretty fun. The closest I got to something like it was Frontpage and Macromedia Director. A couple start-ups seem interested in reviving the idea: Byte and Universe. It's not clear what kind of value they deliver outside of being a purely expressive and fun space—consuming 'bytes' is pretty wild and not much fun after about 2 minutes. Can't stop thinking about this space tho...

Mission, San Francisco — Every wanna rename a bunch of files?

$ for file in *.html; do mv "$file" "${file%.html}.md"; done

Mission, San Francisco — If I were entering a Design program again given today's available tools I'd chase Industrial Design—no contest. Maybe Computer Animation as a minor to have a backup but ID for sure. If you wanna make objects, now is probably the most exciting time. My biggest issue with learning 3d animation in the early 2000s was not being able to tighten the try/fail loop. Software was really slow and you had to use a desktop (although I tended to use a Powerbook G3 with patience). The iPad Pro is going to change this for both CAD and modeling. And I suspect 3d printers are already being used in ID schools but I'm not sure—the resolution has improved a lot.

Palo Alto — The streams of data race:

Name Watchers Stars Forks
React Native 1,181 17,568 2,357
ReactiveCocoa 711 10,118 1,673
ReactKit 58 943 36
Few.swift 32 582 15
RxSwift 78 1,052 70

RED ROCK, Mountain View — Put together a little server that responds with the same index.html file for all paths without file extensions. Works great for situations where you just want a single file to launch a React Router component.

package main

import (

func DirHandler(dir string) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        basename := filepath.Base(r.URL.Path)
        extension := filepath.Ext(basename)
        fullPath := dir + r.URL.Path

        // Serve anything with an extension
        if extension != "" {
            http.ServeFile(w, r, fullPath)

        // Route anything without an extension to index.html
        index := dir + "/index.html"
        http.ServeFile(w, r, index)

func main() {
    http.Handle("/", server.DirHandler(os.Getenv("GOPATH")+"/www"))
    log.Fatal(http.ListenAndServe(":8080", nil))

MISSION, San Francisco — If you have Safari 9 try the new "Responsive Design Mode" by hitting Command+Option+R. Clicking the device icons more than once gives you different orientations and multitasking sizes 😎

Mission, San Francisco — List of companies lending an intelligent hand:

Home, Palo Alto — Reading about The Florida Effect has prompted me to reconsider how I start my mornings.

Green Apple Books, San Francisco — Picked up a copy of Ray Bradbury’s Zen in the Art of Writing and found this in the preface:

“Every morning I jump out of bed and step on a landmine. The landmine is me. After the explosion, I spend the rest of the day putting the pieces together.”

Home, Palo Alto — Playing around with Functional View Controllers thanks to this great talk by Chris Eidhof. Takes a while to start thinking like a functional programmer but lots of fun to go down a new path for a change. This book really helps.