Hi, I'm Nathan

I'm a software generalist at Public Studio in San Francisco with previous experience at Facebook and Dropbox. My primary area of interest is how technology shapes human interactions and amplifies potential. Occasionally I'll use this space to share what's on my mind. If you'd like to know more, here's a very brief about and some tools I work on.

Log

It should be easier to build apps with some sort of distributed datastore. IPFS (ipfs.io) looks promising. One of the anxieties I have about shipping side-projects is the up-keep, I don't really want the responsibility of babysitting a server for a handful of friends using my apps. Maybe what I really want is something like email, or the ability to send a message from one client directly to another, guaranteed. Similar to a push notiication but more reliable.

Visited Noisebridge for the first time a couple days ago. Got a great tour by Steve and hung out at the main table for a couple hours. Lots of ML talk and some links I want to read through:

2017

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. srslywrong.com

Say what you will about Martin Shkreli, this is actually interesting to watch. youtu.be/Or5iwrJez3Q

2016

"Ant societies, organised by distributed algorithms rather than division of labour, have thrived for more than 130 million years." aeon.co/essays/how-ant-s...

"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

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

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.

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.

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:

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.

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.

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.

2015

Cool 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. www.realityeditor.org/

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. www.amazon.com/dp/055338466X

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.

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) {
        this.setState({title: e.target.value})
    }
    onDescriptionChange(e) {
        this.setState({description: e.target.value})
    }
    render() {
        return (
            <form>
                <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} />
            </form>
        )
    }
}

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
        this.setState(change)
      }
    }
  }
}

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 (
            <form>
                <input type="text" ref="title" value={this.valueState('title')} />
                <input type="text" ref="description" valueLink={this.valueState('description')} />
            </form>
        )
    }
}