generic.cx posts

depend-encies

2017-05-16T00:00:00Z

I've been playing with firebase recently. Firebase is a fun system, it's like hosted couchdb but without the views and like appengine but with more batteries included. Its api is interesting because one of its big selling points is its realtime database.

For a todomvc-like application, this is the sort of thing your write:

firebase crud events

firebase.database.ref(`todos/${uid}`).on('child_added', snapshot => {
  // add new child todo snapshot to your local ui
}).on('child_deleted', snapshot => {
  // delete snapshot in your local ui
}).on('child_changed', snapshot => {
  // update your local version of todo with new snapshot
})

here, the data at todos/${uid} contains a list of todo items, when one is added, a child_added event is fired on the database ref and a callback is invoked with the new item. when one is deleted, the child_deleted event is triggered and when one changes, child_changed is triggered so you can update it locally. This is a pretty solid set of events and you can probably see how you might integrate it into a redux-ey webapp.

at first glance, you might do something like this:

using componentDidMount

import React from 'react';
import {connect} from 'react-redux';
import firebase from 'firebase'

import * as todoActions from './todo-actions';

class TodoList extends React.Component {
  dbRef = null;

  render() {
    return <ul>
      { this.props.todos.map(
        todo => <li key={todo.id}>{todo.text}</li>
      ) }
    </ul>
  };

  componentDidMount() {
    this.dbRef = firebase.database.ref(`todos/${this.props.uid}`);

    this.dbRef.on('child_added', snapshot => {
        todoActions.addTodo(snapshot.val(), snapshot.key)
      }).on('child_deleted', snapshot => {
        todoActions.deleteTodo(snapshot.val(), snapshot.key)
      }).on('child_changed', snapshot => {
        todoActions.updateTodo(snapshot.val(), snapshot.key)
      });
  };

  componentWillUnmount() {
    this.dbRef.off();
  }
}

const mapStateToProps = state => {
  uid: state.user.uid,
  todos: state.todos, // populated by todoActions
};

export default connect(
  mapStateToProps,
  todoActions
)(TodoList);

here todoActions are standard CRUD-y redux actions. it's not even important what they actually look like because they are pretty boring in the grand scheme of things.

What is interesting is the componentDidMount call in the component. This is the standard approach that the react docs suggest for dealing with external xhr dependencies and firebase fits the bill here.

firebase and redux

What sets firebase apart from other systems (and even stock rest+redux) is that the firebase client manages local data even dealing with synchronizing it to the remote server. That is, when you "change data on firebase" the client code optimistically syncs your changes locally on the client and immediately calls child_added, child_changed, or whatever.

As a user of firebase, you are totally insulated from this, however, because the firebase client library takes care to always emit the correct events to your appropriate database ref regardless of your connection status, it's only up to you to determine if you want to make your users aware of long-running queries.

This is pretty neat, but also...why even use redux when i have this nifty clientside api at my disposal? And you wouldn't be alone in asking this question because there are two somewhat competing libraries trying to bridge this gap—react-redux-firebase and redux-react-firebase.

Both use the model of redux's connect higher order component approach to provide firebase data to feed data to a component like so:

react-redux-firebase example code

import React from 'react';
import {firebaseConnect, dataToJS} from 'react-redux-firebase';
import flow from 'lodash/flow';

class TodoList extends React.Component {
  render() {
    return <ul>
      { this.props.todos.map(
        todo => <li key={todo.id}>{todo.text}</li>
      ) }
    </ul>
  };
}

export default flow([
  firebaseConnect(({user}) => ['todos/${user.uid}']),

  connect(({firebase}, {user}) => {
    todos: dataToJs(firebase, `todos/${user.uid}`)
  })
])(TodoList)

in both react-redux-firebase and redux-react-firebase, the component mounts and firebaseConnect takes care of synchronizing the firebase state with redux, as a result, your firebase data is never really part of your redux store even though it is accessible to your components via connect.

And this is a pretty conceptually sane implementation, but, on some level, it is a bit weird that we're hijacking react-redux's connect this way given that firebase in this case is essentially a parallel redux store with its own thing going on.

soooo, why redux?

A big selling point of firebase is its moderately low-latency subscription-based datastore with robust client libraries supporting flaky network states. I read those words and all I can think is "exactly what benefit does redux provide?

Stepping back, most apis are not subscription-based and most do not include a clientside api that is capable of managing offline application state (ignoring time-travel, elm, etc this is arguably the point of having a client store like redux). But in a firebase app, you can always .push() new data to some database ref and you will always see immediate child_added events,

So what is redux buying you? I think the biggest out-of-the-box benefit from redux is buying into the conceptual wins of using the Actor Model which is basically enforcing rigorous value-boundaries and abstractions for your services. When you're all-in on the Redux Life you could stop using redux proper and still gain benefits from message-passing in your application.

redux also allows you to abstract your backend service until it actually exists—by creating well-structured semantics for clientside data mutations, you can largely insulate yourself from your database unti it either exists or until you migrate to some other platform, service or data model. this is the most compelling reason to stick with redux in spite of the many cool benefits firebase offers.

composed depend-encies

At work, we use redial to deal with our data dependencies. Redial has some other structure, but the idea is that you define some dependencies to execute either synchronously or asynchronously.

Redial is really well suited to satisfying a one-time data dependency although you can trigger events arbitrarily with it or you can just use it to initiate a dependency lifecycle. For instance:

using redial with redux-thunk

import React from 'react';
import firebase from 'firebase';
import {provideHooks} from 'redial';
import * as todoActions from './todo-actions';

// a thunk
const getAndSubscribeToTodos = uid => dispatch => {
  const path = `todos/${uid}`;
  const dbRef = firebase.database.ref(path);

  dbRef.on('child_added', snapshot => {
      dispatch(todoActions.addTodo(snapshot.val(), snapshot.key))
    }).on('child_deleted', snapshot => {
      dispatch(todoActions.deleteTodo(snapshot.val(), snapshot.key))
    }).on('child_changed', snapshot => {
      dispatch(todoActions.updateTodo(snapshot.val(), snapshot.key))
    });

  return new Promise((resolve, reject) => {
    dbRef.once('value', snapshot => {
      resolve(dispatch(todoActions.getAll(snapshot.val())))
    }, err => {
      reject(err)
    });
  });
}
...
return flow([
  provideHooks({
    fetch: ({dispatch, params: {uid}}) => {
      return dispatch(getAndSubscribeToTodos(uid));
    }
  })
])(TodoList)

In the case of redial, the hidden benefit is that you can have easyish serverside rendering because you can block rendering on the fetch hook. That is a legit necessity, but it's still somewhat complex given that firebase is meant to asynchronously populate and update your client with data from their datastore.

But, i mean, whatever—this works too, and it would be reasonable (you could terminate a subscription with a componentWillUnmount somewhere). But when i look at this and the prior approach using react-redux-firebase, i realize that both of them do it by enhancing this component so that a data dependency is directly bound to it.

And why not, right? This is exactly the approach the redux docs suggest for dealing with a subscription. As with redial, this sort of makes sense when you attach high-level dependencies to a route in your application, but as applications grow larger, you more often want to colocate data dependencies with components that need them.

this is basically the rationale behind graphql via apollo/relay, the way they manage data dependencies is by allowing arbitrary child nodes to define their dependencies and then combining the collected graphql queries into a single query that is accessible to components via a method very similar to react-redux's connect HOC.

but while that architecture is thoroughly awesome, it got me thinking: what other things asynchronously update your client datastore? How do we treat them and model their behavior?

Inputs

In a webform, we model form inputs as a set of disconnected inputs to our application loosely bound together by a <form /> element or by a parent component's state. In the case of a redux app, form data is usually managed by the application state because most inputs are controlled

So what defines an input? Values come in, trigger onChange events and you accept their data into your application's state (even if temporarily).

So why not model a firebase subscription as an input?

import React from 'react';
import {connect} from 'react-redux';
import FirebaseInput from './firebase-data';

import {addTodo, removeTodo, changeTodo} from './todo-actions';


class TodoList extends React.Component {
  render() {
    const {uid, todos} = this.props;

    return <ul>
      <FirebaseInput path={`/todos/${uid}`}
        onChildAdded={itemAdded}
        onChildRemoved={itemRemoved}
        onChildChanged={itemChanged}
      />

      { todos.map(
        todo => <li key={todo.id}>{todo.text}</li>
      ) }
    </ul>
  };
}

const mapStateToProps = state => {
  uid: state.user.uid,
  todos: state.todos,
}

const mapDispatchToProps = dispatch => {
  itemAdded: snap => dispatch(addTodo(snap.key, snap.val())),
  itemRemoved: snap => dispatch(removeTodo(snap.key)),
  itemChanged: snap => dispatch(changeTodo(snap.key, snap.val())),
}

export default connect(
  mapStateToProps, mapDispatchToProps
)(TodoList)

At first glance, this plays much more nicely with standard redux: my store only knows about actions + values (not firebase) and I can implement this core clientside data modeling before i add-in firebase by manually dispatching these actions locally.

But also, in stock redux fashion, my component code's knowledge of firebase is limited to two spots.

<FirebaseInput /> knows about a path in the firebase store (which, there is sort of no avoiding this component knowing about firebase).
mapDispatchToProps knows about DataSnapshot and it's arguable whether or not this is a problem, it feels nicely isolated to me.

We could refactor this further using the standard redux container pattern, isolating the

import React from 'react';
import {connect} from 'react-redux';
import FirebaseInput from './firebase-data';

import {addTodo, removeTodo, changeTodo} from './todo-actions';


class TodoContainer extends React.Component {
  render() {
    const {uid, todos} = this.props;
    const {itemAdded, itemRemoved, itemChanged} = this.props;

    return <div>
      <FirebaseInput path={/todos/${uid}}
        onChildAdded={itemAdded} onChildRemoved={itemRemoved}
        onChildChanged={itemChanged}
      />

      <TodoList todos={todos} />
    </div>
  };
}

const mapStateToProps = state => {
  uid: state.user.uid,
  todos: state.todos,
}

const mapDispatchToProps = dispatch => {
  itemAdded: snap => dispatch(addTodo(snap.key, snap.val())),
  itemRemoved: snap => dispatch(removeTodo(snap.key)),
  itemChanged: snap => dispatch(changeTodo(snap.key, snap.val())),
}

export default connect(
  mapStateToProps, mapDispatchToProps
)(TodoContainer)

import React from 'react';

class TodoList extends React.Component {
  render() {
    const {todos} = this.props;

    return <div>
      <ul>
        { todos.map(
          todo => <li key={todo.id}>{todo.text}</li>
        ) }
      </ul>
    </div>
  };
}

in both cases though, the <TodoList /> component is receiving connected data: that is, although the data flow appears to be coming from the <FirebaseInput /> it is always being routed to the redux store in the same way that a form input's data is promoted globally.

abstracting the database ref

So far, we've ignored the firebase dbref concept entirely, but it's the preferred handle to push changes remotely to firebase. So how do we expose the ref to components and handlers that need access to it in order to update the firebase database?

React already provides an analog for this in its own callback ref implementation. Roughly, the idea is that you defne a local class variable and you attach a callback ref function to tho element you want to get a handle on. So let's adapt the idea

using a firebase ref

 class TodoContainer {
+  todoRef = null;

   render() {
     const {uid, todos} = this.props;
     const {itemAdded, itemRemoved, itemChanged} = this.props;

     return <div>
       <FirebaseInput path={/todos/${uid}}
         onChildAdded={itemAdded} onChildRemoved={itemRemoved}
         onChildChanged={itemChanged}
+        dbRef={ref => this.todoRef = ref}
       />

-      <TodoList todos={todos} />
+      <TodoList todos={todos} handleDone={this.toggleDone} />
     </div>
   };

+  toggleDone = id => {
+    if (this.todoRef) {
+      const status = this.todoRef.child(`${id}/done`).val();
+      this.todoRef.child(`${id}/done`).set(!status);
+    }
+  }
 }

In standard react container/presentation fashion, this passes handlers through props that use standard firebase semantics but isolated from the actual implementation of firebase by letting the container manage the ref but hide it from the child component.

handleDone can start as a method that initially dispatches a redux action but can later be upgraded to be a function that directly updates firebase. Because the data <TodoList /> uses still comes from the same location in redux, the cost of migrating data from locally-stored to firebase-managed is pretty minimal.

drawbacks

I think a better mental-model for modeling complex firebase applications in a client application ends up being closer to relay or apollo. And while it's not terribly difficult to imagine firebase adding a graphql adapter to their datastore in much the same way that graphcool or others do, for simple applications this adds a ton of both conceptual and infrastructure-related overhead that you probably don't really need or want to to deal with when getting started with plain out-of-the-box firebase.

Another drawback to this approach is that you need to be aware of duplicated dependencies. Without a mechanism to aggregate firebase subscriptions, it's easy to create multiple FirebaseData inputs in your application that duplicate work or perhaps even clobber each other's data in competing callbacks.

Still, for small applications, modeling asynchronous network data as a plain react component like an <input /> adds a low-cost approach to inject external network dependencies along with a simple migration path from locally-managed data to externally managed data.

unhalf-bricking

2006-10-25T00:00:00Z

this post by ben northrop Reflections of an "old" programmer struck me a bit, mostly because it covers two topics: trying to understand the role of a senior level engineer and a meditation on the cycle of churn in tech.

i can't speak to the first part, even though i've been around a while, i don't know that i can speak to his experience or situation, but i can speak to the feeling of "fatigue" and "boredom".

partly i feel somewhat confident in talking about my experience because

i first stared into the void when i discovered the seemingly endless rat race of MCSE certification. but also
i seem to have made peace with tech churn's place in my life (to some degree).

there are two things i can point to that changed my perspective on churn. the first was my math+cs undergrad degree, the second has been my work on the web, on and off, for the past 15 years or so.

the degree

there's this line in cs education that most people encounter at some point

computer science is neither about computers nor science.

The statement sounded pithy in the first few minutes of 6.001, but 2 years later, knee-deep in an automata class learning about computation, state machines, dumbed down proofs, oracles, and decidability the line resounded in my head.

The other thing which probably hurt me was my school's nearly allergic reaction to talking about and dealing in actual implementations¹. I'm told this has changed, but at the time i think it was perhaps a bit too principled of a stance on doing the right thing. So I, at least, spent a lot of time thinking about good solutions & approaches and less time implementing naive ones that would have worked just fine probably.

This fledgling caution was partly a reaction to seeing the results of bad (sometimes disastrous) theoretical implementations in classes and then reading case studies about even worse practical implementations: you develop a simple of pattern matcher for your hubris and rabbit holes you've seen other projects fall into. You decide not to try your hand at implementing halt(f) anytime soon.

When i tell people why a CS education is valuable, i usually talk about this pattern matching: you develop a good spider sense for counterintuitively bad edge cases, you become highly sensitive to polynomially disastrous performance from ten thousand feet, and you have a good understanding of why architectures were designed the way they were simply by looking at their exposed APIs. You can absolutely learn to spot these things, to understand this behavior outside of school, but it can be easier when pattern matching is your full time job.

ideas

when i applied to design school, i cribbed a line i will paraphrase from ellen lupton:

design is a tool for communicating complex ideas

there was this thing going around twitter this summer where you'd list the first six programming languages you learned as a kind of guilt-free rorschach test. Here was my list

Basic 1989
C 1996
RPL 1997
HTML 1998
CSS 1999
PHP 1999
Java 2000
LPC 2000
SQL 2000
Scheme 2001
C 2001
Common Lisp 2003
Python 2003
ELisp 2005
JavaScript 2005
Ruby 2005
CSS 2005
XSLT 2006
Erlang 2006
Actionscript 2008
Objective C 2009
R 2010
JavaScript 2010
Python 2011
CSS 2011
Swift 2013
ES2015 + Flow² 2015

The thing i think most about when i look at this list is that each of those years, i was applying or re-learning a language but attempting to solve a new flavor of problem with it (or refining some approach in a problem-domain).

if you take a computability class like the one i mentioned earlier, you are taught that the kind of language you need to express all possible computable ideas is pretty straightforward, even if cumbersome. My takeaway was that any syntax beyond that basic turing-machine-language is an ideologically-aligned mechanism for expressing ideas about some problem domain.

People talk about Domain Specific Languages (DSL)s all the time (often dismissively!), but all general purpose languages are domain-specific. Nobody writes C because they are in love with memory management, you write it because it's easy to compile for most general purpose CPUs. Or you write it because you're tired of assembly. You don't write it because you feel like mallocing your way to health. And even if you do, you're probably looking at Rust sitting pretty in the corner of your hard drive over there. All languages, from Postscript (printing) to Lisp (list processing) to Java (platform independent vm) are built around solving some problem.

Sure, the purists say, you could get away with just lisp but there are tons of languages out there, why aren't they all lisps? The answer is simple: lisp is a very nice and expressive round hole, but some problems are quite literally square pegs that have their own DSLs built around them. Sure, recreate its api lisp (or transpile!), but why not use that dsl directly? It was made for a reason and that reason is (almost always) to be expressive and relevant to some problem domain (or, more interestingly, to address the limitations of bygone era's operating system, or hardware limitations, or cultural norms). I'm not saying you should program your next startup in COBOL, write cgi-bins in C, or use the Apache webserver, but have you ever wondered why whole generations of programmers did?

the churn

two parts of ben northrop's post jumped out at me

If I learned nothing else from this point forward, I bet that only about a half of my knowledge could I still use in 2026 (long live SQL!), and the other half would probably be of no use (React Native, perhaps?). Now of course I will be gaining new knowledge to replace the dead stuff, but will it be enough? Will I know more (useful) knowledge in 2026 than I do now?

...

Some of what we learned early in our career is now out-dated. All that time "we" (read: I) spent learning GWT? Lost! Essentially, both forces, knowledge decay and knowledge accumulation rate, begin to work against us.

I think most professional programmers have grappled with these two aspects so i want to address them

what will i retain?

i didn't put jquery on that list, but i think lots of people invested a significant amount of their brain real estate on being productive with jquery. But now "everyone" uses react or angular or vue or at least not jquery and what of all the mental energy you invested solving the web's problems with jquery? is that (like GWT/prototype/mootools/closure/et al) lost?

why is jquery great? because it papers over browser inconsistencies. at some point, though, we mistook it for a dom interface and its own tech stack. that's fine, but during those heady days we learned to harness the web, we finally had robust tools for making xhr calls, we began to harness animation, we learned what ui we actually needed to build to have productive web pages.

At some point, we realized that lots of those things had become standardized across many browsers we actually cared about and for some reason it was as if we needed to cut jquery out of our lives like trans fats or sugar or ecigs. that reaction is odd because it ignores the fact that jquery still has a purpose (albeit a very different one now that we've made a habit of casting aside older browsers)!

still, regardless your feelings about jquery now, you have to admit that during that time, we learned how to make web applications where before we were just struggling to make something jiggle consistently at 13fps during hover events. The lessons learned about toggling ui element styles in response to some user action may be obviated by a more efficient dsl or library (or ux pattern), but it doesn't change that our relationship to solving that problem is now a question of "how do i do this thing nowadays" vs "is it even possible to do this thing?"

i go back to my cs education being a big pattern matching thing: is the fundamental takeaway from a tech experience "wow, i got really good and efficient at using that api" or "i have developed techniques to solve a series of problems." it's fair to have both takeaways, but not at the expense of ignoring the more fundamental "hot damn, i know web kung fu."

all that time lost

i think people underestimate that lots of programming 'churn' is a reaction to the fact that lots of problems we have now, we didn't have ten years ago. Is the point of React Native to develope iphone apps or is it, like jquery, a tool for papering over the fact that it's a tremendous pain in the ass to develop for two mostly different deployment targets at the same time.

Hey, looking at all you folks in the 90s that used Swing/AWT/QT, how did that experience turn out? When i looked at react native, it was tempting to shrug it off for all the same reasons: boring ui, terrible ux, hilarious java-flavored api, etc.

but i also think about all the lessons i learned from exposure to those systems. maybe those lessons make me a cautions RN dev, or maybe they just give me a different perspective. Who knows. I don't think that's a negative, and certainly, i am able to use that perspective to evaluate if RN is the API i would choose to set sail with for my next cross-platform journey.

I find it easy to accidentally conflate "time i spent learning arcane details of this in javascript" with "something important i learned about solving a class of problems." Sometimes they're helpfully related, but other times one is just useless trivia or a detail that is optimized away by a transpiler or minifier (who both know my cargo culting is redundant) or caught by a linter (which is better at remembering thousands of stupid rules than i am) or hopefully code review or eventually in a year or so, the vm.

I try to be hawkish about differentiating trivia from conceptual knowledge because above all i remain haunted by the career path of somebody who needed to take those stupid mcse certifications every year. We're lucky that nobody is asking us to take yearly exams about the inner workings of VMs or apis to have a bullshit stamp we can show off to people. It's easy to conflate Keeping Current And Up To Date with having one of those stamps, but that's trivia, our job remains solving problems.

not having fun anymore

The counterargument to all this is every situation we've been forced or "encouraged" to learn some tech we morally disagree with. It happens all the time, even when it's not foisted on us from up high. Want to learn to use a traditional (oracle/postgres/mysql) database, it's time to make peace with SQL (if you dare). Turn up your nose all you want at javascript, but it's the only game in town for writing clientside webapps (unless you transpile from coffee, elm et al.). or even until recently, if you wanted to write a performant app for ios, you needed have The Talk about manual memory management.

I think it would be unfair of me to discount the fact that sometimes we're put in positions where we spend an outsized amount of time solving problems that aren't actually the ones we were hired to deal with:

You want to write a webapp, but instead you need to know a smattering of linux system administration
You just want an accordion menu, but you need to debug a memory leak in some library you imported
You are trying to do string formatting, but a dependency broke semver out from under you, now you manage a private npm repository and are a wizard at pinning and shrinkwrapping your app.
You invest 40+ hours integrating a complex and poorly crafted library in your codebase, learning its mental model only to realize it's not suitable for production use or that making it usable would require the same amount of time as having written it from the outset.

These are the sorts of "orthogonal concerns" that i hear when people talk about "wasted time" or "experience that doesn't help my career" except that a good percentage of the time that experience is your career.³ And all those experiences, I believe, are valuable data-points that can (and should) trigger your spider-sense in the future when you're stuck with a broken dependency or need to assess how much it will delay a feature.

It's fair to assert that those are the kinds of pedestrian concerns you don't want to deal with in your career. Like i said, this profession is all about solving problems and eventually you either delegate them away, solve them yourself, or delevop some coping strategy for them sharing space with your day to day life. It's fine to feel grumbly about good tech that got the raw end of some deal. Lots of people write their JS as if it were lisp and a ton write it as if it were C++. Everyone takes their experiences with them on new journeys.

who knows where the time goes?⁴

As i've gotten older, i think about how even something as "trivial" as a Javascript Promise solves problems i didn't have when i was learning my first web application with PHP. Wow! Such power! New language features have the capacity to expand our conceptual vocabulary, so in the future we can talk productively about and address problems we didn't have before.

It's fine to love a boring stack, especially if the problems you're solving aren't changing much or if those boring parts of your stack are solving a commodity need.

In general, though, I reject the idea that adopting a new patois is pointless when thinking and learning about new or novel problems. Or that the problem-space has remained static since the 60s (which is reductive). Solving problems is what we do all day long, so it's confounding to hear a drumbeat of folks dismissing out of hand that today's networks and norms around ui have completely changed the way that we approach problems like latency, optimistic updates, partition tolerance, reconciliation, and so forth. In the past, you could make a good case that the audience for these sorts of 'niche' problems was in the tens of people, now they are part and parcel of something as boring as a shared TodoMVC app.

Even if your work never directly interacts with that lower layer, your UI should be aware of its effects. Is that useless knowledge? People used to talk about paradigm shifts. Thinking about a widget's states from being [on, off] to [mounting, no-data, off, loading, on, unmounting] is a legit paradigm shift. Even if the widget doesn't reflect all those states, how do you go back to [on,off] when you know that a component's behavior is dependent on so many more things. We've gone from a world where we could expect computers or buttons to either work or not to a world where our digital data feels more like high-resolution analog input.

This is partly why I remain optimistic about even transitional blips in our knowledge, flashes in the pan whose utility is replaced by standards-track tech. At its best, it gives us new ways to approach old problems and new ways to talk about things we previously ignored. How is that not a net-positive?

at least at my level of education, the only practical place to actually Make Things Go were either on your own time, at MITERS or in your dorm or a club or by taking on undergraduate research jobs. But even then, you would encounter the comic upturned nose to a hack and the accompanying semi-sarcastic rejoinder "what do you mean, no closed form solution!?"↩
These days, i find something like Flow fascinating because it's such a change in mindset from the classic approach of a strictly typed languages: instead of rocking the type-hairshirt from the outset of your next multi-million dollar web-scale paas, you can decide to strategically invest in typing areas of a codebase that are type-sensitive while ignoring the ones that aren't. That's not a "new idea" by a mile, but the approach is refreshingly modern for something which has had historically high startup costs in traditional languages.↩
i made a snide comment about this on twitter because i think most people are pretty blasé about this point: if you take on a dependency, you should be prepared to own it in some capacity (especially if this software is critical to your livelihood). the person i owe this mindset to is, unsurprisingly, craig silverstein, who got me into the habit of forking each dependency and assuming responsibility for merging (and dealing with conflicting) upstream changes.

i mention this because it's vogue to complain about some package that a developer has stopped maintaining and pin the worries (as in mailing list post from the twitter thread) on concerns like "we aren't able to commit to the main repo" or "the package has stopped receiving active maintenance." Two points here: the first problem is a non-problem especially if the community is larger than just the missing developer. Anybody looking for the package will run across the new fork and see its active development history or discover a mailing list post (or stack overflow mention) of the newer package. The second is probably the bigger issue: if there are active patches dowstream just waiting for a maintainer, a hostile fork is already at an advantage over the original project. But if the project is beloved by the community but is receiving no active contributions, what exactly is the problem? Further, if the project has met its stated goals, what responsibility does it have to merge any patches? As anyone that has contributed to a project knows: unsolicited work that doesn't solve an existing pain point often goes unmerged. But also, if nobody's contributing work, who's there to complain about a dying project?

Many people i think lump free/open source software into this bucket of "things i'm glad i didn't write and am glad to take advantage of" without acknowledging just how integral they are to the basic function of their product. It's fine to resent a lib or app for not being a fully fleshed out product but it's irresponsible to ignore the fact that without them, you'd be on the hook for writing that same code yourself. This the argument for open source as critical infrastructure. When the access road needs maintenance, do you pay to have it repaved in the interim, or close up shop?↩
the title of this blog post was originally this heading, but it felt too big and too weighty. instead, i replaced it with unhalfbricking, which is the name of a Fairport Convention album (they also have a song called Who Knows Where The Time Goes). It's good! I would reccomend it heartily!

↩

the death of paper prototypes

2024-05-11T15:24:32Z

some have said that paper prototypes are a waste of time.

what i have observed is that paper prototyping is extremely useful when you haven't decided how you want things to work. that is, if you are having the discussion "wouldn't it be great if we could 'fling' this doo-dad in order to dismiss it?" and then a minute later you have a piece of paper that you can literally fling across another piece of paper or perhaps, an actual ipad.

in about a minute, you can do "wacky" things like prototype something akin to "what if you crumpled the item with a pinch gesture when you were done with it?" or "what if you swiped successive items, like sheets of paper, you know, like from that production company back in the 80s at the end of all the tv shows." and then you do it and you say something like "oh, yeah, ok let's not do that"

and then later that afternoon, once you've settled the "dispute" then you can spend the next few hours prototyping the hell out of whatever it is you thought was a good idea. that's when you bust out the quartz composer/html/js/react/cloud/mp3 ripping/mesh network/interface builder/drone snack delivery/framer/etc.

and if that feels right, then you can go ahead and implement that in your web app or mobile app or whatever given the constraints of your api/scheduling/nosqlbane/datastore/frameworks/etc.

the danger, the thing you're fighting, is that you spend, up-front, a day or two or ten realizing what could legitimately have been discovered by a piece of paper sitting atop your ipad. it has taken me a comical amount of programming to realize when a paper prototype is useful, but i no longer scoff at it "because i can program." Even the decision to mock something out in keynote or qc or whatever is fraught with the decision that you've committed to an aesthetic, to some animation settings, to your app chrome, etc. sometimes those things don't exist and you're trying to debate things way more elemental. in those cases, paper prototyping can save you lots of time.

but again, if you've already decided something is a good idea, then in-app or live prototypes are incredibly valuable for being able to 'tweak the knobs' and 'live with your mistakes' while you find easing curves or animation timings or whatever. if you're flying blind, then you could do a whole lot worse than paper-larping for a few minutes while you decide what your mobile strategy is.

which is to say, if you're at the stage where you're going "head to head with your competitors" then you probably should be doing real prototypes or building real mvcs in whatever system works best. this is effectively the same as what they're saying in the original article: you can't only paper prototype and expect it all to be peaches and cream.

even as i'm writing this i'm getting a huge fred brooks flashback here because the reality is that making good ui is actually quite time consuming even if you have fancy whizbang frameworks. this is why people love framer or qc—they simplify thinking about interaction to the most basic aesthetic choices as relates to some states: this thing fades out while this thing flies in. or these things pop in at staggered delays when you go to the next part of the tutorial.

i'm not trying to knock those tools, but the truly hard ui problems are rarely solved by a single motion sketch in any app. and honestly, even those keynote/qc/framer 'high fidelity mocks' are, to my mind, as disingenuous as polished paper prototypes because most of the time their animations are wildly disconnected from the reality of using the app day to day when you're trying to accomplish anything.

the reality mirrors something closer to the epic 500+ email process thread from the creators of Threes, a thread so epic that it doesn't deserve to be occluded within an html link, i'll just put it here

    http://asherv.com/threes/threemails/

i guess really what i'm saying is that all these things take time and the 'real world' process is long, but that if you're lucky, you get better at spotting which things your can gut check with paper and which things you need to bite the bullet to just see at least once. and then you just iterate until things get better, i guess that's the atwood strategy.

there's a sort of stupid bravado here in the valley where people like to eschew 'trying something dumb' for 'making an mvp' and sometimes it's a good forcing function to get out of a funk but often i see it results in lots of wasted time and pointless code that goes nowhere. maybe i'm getting old or something, though.

obligatory line about it taking a tough man to make a tender chicken

fun with vector fields

2024-05-11T15:24:32Z

A while ago, we needed to send out a notification to all our LearnStorm winners inviting them to the Finals event in Mountain View. It's a big deal! Only 200 Students from all of the bay area got invited to the event.

Because most (if not all) of them were under 13, we couldn't email¹ them so we needed to make something that would catch their eye the next time they visited the website.

And, as with the most fun projects, there was very little time to actually work on this: from start to finish, this was bounded to around three days, so in terms of design, it would need to be nice, but it couldn't be 100% totally new shiny design work: compromises would need to be made.

step one: notifications

You have probably gotten a notification on Khan Academy before, and readily dismissed it like so much purple rain.²

And why not, it's certainly... distinctive, but that purple rectangle is not exactly injecting anybody's retinas with "notification delight," so step one was figuring out how to make the notifications look nicer.

step two: learnstorm?

The next step of research was teasing apart learnstorm's visual style: the slope field motif is the heart of learnstorm's identity.³ In making this notification banner I knew that I wanted echo the identity, but from another angle or perspective. To do that I would need to grok that slope field a little better because already at this point, i knew i wanted to incorporate it into the banner in some way.

But wait a second... math??? we can't even center a div, how can we possibly do anything with slope fields?

Actually, let's step back even further... differential equations? what's a slope field again?

step yak: a math detour

My thinking went: our contest is rooted in differential equations, it'll probably help to revisit them. ⁴

And after a brief while you find that a slope field is basically what it claims to be: the slope of a differential equation calculated at periodic points on a plane. And differential equations only express the feel of an equation, not exactly what it looks like because they're missing several constant values.

So for a plain ol' circle y^2 + x^2 = 1, you'd get y' = -x/y + c (which you could find via implicit differentiation), but again' all that's saying is that the slope for this differential equation at any point is the x value divided by the y value times negative one plus some arbitrary c (which, for us, we'll just pretend is zero). For whatever point, you just enter x and y into that equation and that's the slope.⁵ neat!

But when we attempt to draw this (say on paper or digitally), we don't actually want y', we want whatever direction y' corresponds to so we can point a triangle in that direction. With a simple equation like y' = -x / y , we run into this problem where for zeroey y values we have infinitely positive or negative y' and what do you do with that?

Well, Math to the rescue! Specifically the standard atan2 method which returns the angle in radians (from the origin) for the point at (x,y). It's a special function which calculates the arctangent but is smart enough to compensate for zero denominators in pretty much the same way you would.⁶

Looking at the atan2 implementation, you find that it does the kind of "intuitive limit-ey division" that you're often asked to do in the first weeks of a calc class. Instead of NaN you get ±π/2 and instead of 0 you get 0 or π. It's great! And it's exactly what we need. For a given (x,y) pair, you get a corresponding radian value.

Also, recall, we have a diff eq that is given by y' = -x/y, we can use atan2 to find the slope of each point on the plane.⁷ Ok, we know how we might use this, now we just need to get started actually drawing it.

step two: prototyping

The first step of prototyping this was a small python script that i wrote for PlotDevice⁸

Again, remember that i didn't have too much time to work on this project, I needed to be certain that I could fake out a new spin on learnstorm identity so if I began to run out of time, I could, at the very least, render a cute static image as the background for the banner.

Well, this looks promising! But the day is young: could i... animate this?

Stepping back, let's do a small crit⁹ here: part of what makes the learnstorm identity cool is that you get this round vibe even though everything is stuck on a grid. Breaking the grid in this case would not only require me animating each dart but animating them along circular paths which, i mean, would look awesome but... umm... maybe let's save that for LearnStorm 2016 when we have more time...

Also, let's take this moment to visibly and vocally Pivot.¹⁰ Because i spent the morning trying to figure out how to procedurally draw slope fields, i already have (a sort of) infrastructure for generating slope fields, but the problem is that i want something i can easily animate. Time for a new differential equation!

Maybe we can just make something up, something... real easyish, like...

y' = x + y

and if you plot this out correctly, you end up seeing something like this:

but say you make a mistake¹¹ and remove that super "interesting" atan2 we just learned about, you get something... novel.

What's happening is that if you pick a row or a column, you find that the rotation values are monotonically increasing but at a slightly different starting point and because the atan2 isn't around, the darts just continue rotating and rotating...

Ok, so now we have a moderately intriguing slope field which, let's be honest, is something of an accidental slope field at the moment.

So, back to our project: how do we animate it? Well, the neat thing again is that if you walk along the y axis (or x axis) every dart rotates however much you moved. So let's say you start with that static image above and, for each point, you increase y or x in that y' = x + y by a little without actually moving the point, they all appear to rotate just a little bit more counterclockwise, like so:

Which is great and hypnotic. But how do we incorporate this into the announcement banner?

My first instinct was animated gif: but the gifs ended up being multi-megabyte monstrosities and movies no better. Even the gyfcat embed up a few paragraphs ago is, at worst, 4M and, at best, a 400k webp movie. and the quality... i mean, you have eyes, just look at it... it's let's just say, not the best. Ugh, this is not a very complicated thing! it's just a bunch of triangles rotating round and round and...

wait a minute

Instead of actually rendering some background image and scaling it up, why not do the animation in the browser using a technique you may have heard of called Dynamic HTML.¹²

staggering animations

Here's how I would roughly do it: i would use a single dart image, lay out a bunch of them on a grid and then rotate them with css. At first i thought

I can set each dart's from-rotation and it's to-rotation dynamically!

And i would use css to start each dart's animation at, say, some radian value, setup a keyframe animation to rotate 2π radians over some fixed time scale and then call it a day. Genius!

But because¹³ there's no easy way to create a parameterized css animation with arbitrary start/end points and because it felt wasteful to specify a new animation starting at some radian value going a full 2π for all radian values, i instead opted for a more, shall we say, lo-fi approach.

Instead, each dart would use the exact-same 2π rotation animation, but to stagger the animations, I would set each dart's animation delay to achieve the same effect. Then, I would set this field of spinning darts on a z-index below an actual html notification.

implementing this

My first attempt did something comical: because i had already generated the animation above using plotdevice as part of my testing, i already had a series of timing offsets along with x/y positions so i printed the starting rotation for each dart and saved that as a json array which i loaded directly into a very small react template yielding something approximately like the

...
var dartRot = [0, 0.234, 0.469, ..., a few megabytes more, ...]
...
for (var i=0; i < dartRot.length; i += 1){
  style = { animationDelay: dartRot[i], ..., };
  return <dart style={style} />;
}
...

I iterated over all the values and then used that to set the animation delay. My goodness! how ridiculous! That's basically as bad as writing out all those css animations one-by-one. But i mean, the takeaway was that the idea was not bad even if my initial implementation was.

Instead, I set down the project for the day and it took until the next morning to realize that i could do something much less ridiculous:

...
for (var x=0; x < dartCols; x += 1){
  for (var y=0; y < dartRows; y += 1){
    style = { animationDelay: (x+y), ..., };
    return <dart style={style} />;
  }
}
...

This wasn't even that much more work, i had already done much of it in python, i just needed to translate it! Here's basically a demo of that react implementation.¹⁴

JS Bin on jsbin.com

The nice thing here is that not only is the code not packed with magic arrays, it's also wayyyyyy more obvious what's going on. Even setting the x/y positions (not shown) in the style object is more obvious and the code you end up with allows you to think in terms of a unit grid but render elements by twiddling the knobs of your various scale factors.

Because the animation works by setting an animation delay, it slowly staggers into being. So when the banner appears, everything starts off pointing to one direction only to eventually fall in line at some point along the animation delay.

At Khan Academy, we have a neat tool to let you prototype a react component in the context of the site called the React Sandbox. It works on the local dev server and lets you get a quick jsbin/fiddle environment but with all the goodies you've come to expect on the site. Using it, you get something like this:

The design isn't super mind blowing: it's a spin on the regular learnstorm header, but it's... alive! And, more importantly, it transfers the gravity of the original learnstorm header into celebrating the accomplishments of our regional winners and brings the identity to life even if it doesn't directly animate the circular slope field.

lessons learned

Well, aside from the fact that it's fun to use math to make cool notifications, the main lesson (i think), is that by thinking about prototyping (and parametrizing) early on, you can come up with interesting ways of procedurally generating animations later on even when your environment (like css) is constrained.

Part of this was definitely baked into the early differential equation investigations. Later this was teased out using python and in the end, even though the animation was implemented using react, the various explorations let me realize that this is the sort of thing that you could implement with anything else like d3 or even good ol' jQuery or handlebars.

In the end, somebody who had received the notification by visiting the site would see this (except animating):

If you saw the notification, congrats on participating in learnstorm! It was great fun making something for you :)

let's put it this way, i am not a lawyer, but i do know that COPPA prevents everyone from collecting any personally identifiable information for anyone under 13 (that includes email addresses).↩
... "Purple rain," later the title of a 1984 song, album, and film (and the tour that supported both the album and film), from the artist Prince. Although it is not known if there is actually any connection, both Mikel Toombs of The San Diego Union and Bob Kostanczuk of the Post-Tribune have written that Prince got the title directly from "Ventura Highway". Asked to explain the phrase "purple rain" in "Ventura Highway", Gerry Beckley has responded: "You got me". (via wikipedia)

↩
A refresher: a slope field (naturally) is the slope (and often magnitude) of a differential equation plotted along a grid. You can use slope fields to build intuition about the nature of first order differential equations, their tangent points, and so forth.↩
slope fields make up the lion's share of the early weeks of a diff eq class and are by far the least interesting part: all the applied and domain-specific uses of differential equations end up being wayyyyy more interesting.↩
in a blog post full of detours, i should point out how satisfying it is to end up at an early 'solution' that requires the simplest of computations.↩
because it takes the denominator as an argument, atan2 avoids the standard movie trope of "tricking" the computer by having it try to divide by zero.↩
specifically, you're going to ask for radians = Math.atan2(y, -x)↩
plotdevice is great! it's a python-based drawing application i'm real fond of. Take a look, you might like it! If you like the idea behind processing but you're whatever on java, then you'll probably enjoy it.↩
a crit (not that crit) is a time to look over design work with your peers, evaluate and discuss what's succeeding, what's not (and for both, why), and offer suggestions for how it could communicate what it needs to most efectively.↩
I mean, we're already in the bay area, what sort of blog post from a startup doesn't enthusiastically and vigorously talk and rationalise pivoting as a way of life.↩
who does that? i wouldn't do that. who would do such a thing?↩
"...a more elegant weapon for a more civilized age" -- alec guiness ↩
please, feel free to correct me on hn↩
In this demo, the darts are all displayed inline-block just to avoid having to be distracted by setting position manually↩

why write todo comments?

2024-05-11T15:24:32Z

The other day while listening to edge cases, i was tickled to hear wolf talk about comments and how, as he's aged, he prefers really only two flavors of comments, API Comments/Documentation and here be dragons comments. But sadly, he didn't mention the kind of comments i'm going to talk about here.

To begin, he cites this gem from wikipedia:

Due to time restrictions or enthusiastic programmers who want immediate results for their code, commenting of code often takes a back seat.

At work, we have a slogan "shipping beats perfection"¹ and it is much of the rationale for this other kind of comment, which i will call the unblocking comment.

the unblocking comment

The practice, introduced to us via craig silverstein², (and to be clear, khan academy is not unique here) is to leave comments for the things you recognize are probably out of immediate scope and that you aren't able to get to right now so that you can get on with your original commit (i.e. unblocking yourself).

let me show you a 'for instance' from my super hacky tumblr editor package:

# TODO(marcos): what if this also fails?
if more_info['meta']['status'] == 200:
    post = more_info['response']['posts'][0]
    # TODO(marcos): maybe check a pref for this
    webbrowser.open(post['post_url'])

the two TODO(marcos) comments map to things that i might, at some point get to eventually, but that aren't truly 'blocking' or 'stopships' or whatever. They're basically baby yaks that if i'm not careful, might develop into full grown yaks³ demanding my attention and shears.

or more recently, this past week, while playing with Framer:

// TODO(marcos): use cycle here
var collapsed = true
scrubBG.on(Events.Click, function(){

    if (collapsed) {
        // TODO(marcos): instead of just unclipping the layer
        // animate the text in separately

And, to be clear, the code works! Right now! it's just that if i ever want it to work better or if i return to it, i have already outlined a roadmap for myself (or others) on how to do that. The framer code is by definition a prototype, so let's be honest, who cares if i'm using cycle correctly, but my intuition to Do The Right Thing™⁴ is the sort of yak that might have wasted precious prototyping time.

These todos, in the context of both projects, are the software development equivalent of a "sweep" in gtd⁵. Which is to say, that in writing the todos, i've explained what i need to do (but i can't do right now), and by doing so, i've absolved myself of the guilt of doing it this very minute.

Allow me to repeat: by leaving the todo(), i communicate to others (or future-marcos) my understanding that the problem exists but that rather than investing time in writing possibly unneccessary code, i am moving on. In the present day, it gets me unstuck and moves me forward towards a working implementation that i can nit-pick later.

Again, i'm not promising work on the femtoyak right now, i'm not even committing to it in the future (as my tumblr comments have borne out)—i'm doing two things: publicly acknowledging the issue exists and punting it so that i can get on with my day. Why even put my name on it, you ask? If somebody does get around to it, they know exactly who to ask for more detail! I'm happy to help them!

Most of you are shouting at your monitor saying that this is like time-management 101, but it took my subconsciously creating these todo() comments to get me to truly internalize their real ultimate power.

The novelty here, the point where this ties back to the quote, is that this is actually the opposite of the problem outlined in the wikipedia article. In my vim to get towards a working solution, i'm leaving important implementation and polish related comments for myself (and others) so that i can address it better... but only once i have something that merits fixing.

Just to be clear, though, if you have actual bugs that merit tracking, you really should find a way to get to those in a way that's higher priority than these TODO()s which really are historic context-rich vignettes of the rabbit-holes you've avoided. By all means, continue logging assertions and running unit tests for your bits that need to remain stable!

But... i want to repeat the central 'point' here which is that comments don't have to take a backseat to getting things done. In fact, i hope i've shown that, comments can provide a relatively easy way to get you from "zero to working"⁶ while providing a legitimate roadmap for you to get to something sustainably developed in the future.

dealing with guilt

I've been trying to find a good way to end this essay, some sort of meditation on why something as mundane as a todo comment would even be necessary to write about. It took the span of a few weeks for the podcast gods to answer my call in the form of an episode of ATP, going full-circle.

The episode is interesting because it deals with deeper issues of obligation and guilt in software development and maintenance. It's a highly relatable episode for anyone that has participated in the open source ecosystem. In particular, it pairs well with this 100% insightful essay called Emotional Programming in Open Source by Armin Ronacher. You should definitely read it, but I'm going to pull a whole chunk of it here:

I found it quite hard this year to work on my own projects because the bug trackers were full of things I personally did not really care about. The things I wrote over the last few years all work so well for me, that I don't need to fix problems or add things. When there is something that needs fixing, I will work on it, but otherwise I don't necessarily get the motivation to work on it.

... the whole porting to Python 3 thing has killed so much motivation for working on my project for me. I cannot use Python 3 in practice and having to deal with issues I don't have myself is one of the most frustrating things.

He calls out an important distinction between bugs which are currently breaking a build and in-utero yaks which shouldn't be on your radar just yet. Todos, in contrast, aren't traditional 'bug' reports, they're opportunities; for refactoring, future architecture changes, performance optimizations, etc. Maybe they're nice to haves, maybe you discover they're actual bugs: time will tell.

The effect of writing and revisiting TODO()s is better understanding the dynamic between problems you have right now and issues that are actually non-issues. If a todo lingers for a while, it's probably not an issue you really have and certainly not one that's keeping your project from functioning in the short term. Maybe if you're bored you hit it up. Maybe a contributor decides to attack it.

But the problem that many of us have, is that we know what The Right Thing is but our time and priorities are at odds with that. Does that choice make us worse programmers? Should it hold us up from releasing a project? Would it be better if we just pulled our project? No to all. It's a calculus of writing code, our time available, obligation to our code's users and our own guilt. Those are challenging things to balance!

Developing software in the open is complicated even when when you're bootstrapping it in private. But it gets more difficult if making progress is fraught with guilt and obligation to some all-seeing Van Hœt. So many of these issues, these problems in casual development are complex issues of time management, guilt and obligation. Leaving todos can free you from worry and push you towards fixing issues you care about right now so you can start enjoying the software you make.

thanks

it wouldn't be a real thousand word internet blog post without an artisinal colophon, so thanks for the feedback and comments: @marcia_lee, @andy_matuschak, @kamens, @pgbovine, @dmnd_, and chrisklaiber and @dylanvee.

If you have any thoughts on this and have made it all this way, i'd love to hear from you. Feel free to send me an email.

its background is this other phrase, bias towards action, which, to be honest, i don't think i'd heard until this past week. It is, however, an interesting cousin of the more contentious Worse is Better™[^wib]↩
craig has been responsible for many fantastic process gems, so i feel very lucky to be able to crib this one from him almost entirely wholesale for my own internet fame and glory.↩
, which see ↩
i'm pretty sure spike lee never thought his movie would ever be referenced so often in terms of software engineering discussions↩
A sweep, briefly, is this nifty idea where in order to be able to prioritize all the task you possibly have, you put everything you can think that might be a task into a task list. By moving all those ideas out of your head and into a place you're likely to look at later, you allow your mind to only wander to tasks that are relevant now. gtd® is copyright DavidCo 2001.↩
although philosophically aligned, this is not going to devolve into an essay about minimal/maximal viable products. phew.↩

chaining font descriptors in uikit

2024-05-11T15:24:32Z

A few months ago i decided to try my hand at doing some work in swift but i ended up yak shaving my way into finally understanding what's going on in textkit. One of the neat things i came across was this idea of chaining font descriptors to progressively activate opentype features on a font. Now that we're in full blown hack week at khan academy, i'm taking the time to use this code for a project i'm working on.

This isn't a particularly new idea, but inspired by alamofire's neat post about chaining vis-a-vis http requests and the current 'uproar' about opentype features, i thought i'd write up what i learned then. Plus it's cute because swift™ and also because chaining!

One of the things i was hoping to do was exploit as much of the power of Proxima Nova in an iOS app. Like most modern fonts, proxima includes a bevy of opentype features including true small caps, old style figures, stylistic sets and so forth. You can learn more about proxima or read its overview (pdf) which explains most everything you might want to turn on and off.

The neat thing about chaining font descriptors is that it gives you a very handy way to grab a UIFont that has the opentype features you want available. For instance, a font which has small caps and forced uppercase->small caps (i.e. SMCP & C2SC), you can do something like:

var styledFont: UIFont = UIFont(
        name: "ProximaNova-Regular",
        size: 14.0)!
        .fontWithSMCP()
        .fontWithC2SC()
        .fontWithONUM()

These are three of the most basic (and popular) kinds of opentype features on fonts, namely: Small Caps (SMCP), Caps to Small Caps (C2SC), and Oldstyle Figures (ONUM). I used these 4-letter feature abbreviations because they most closely map onto the features you end up seeing in font brochures and are the exact same features that type designers implement when they're writing up opentype code.

but... how? and what does this mean? Let's find out!

how fonts in ios work

in iOS, there's this idea of a font as a specific instance of a typeface at a specific size. Actually, the photo up above sort of explains the idea perfectly. A font in that case would be "10pt Garamond." If you were instantiating it, you might say

var oldFont: UIFont = UIFont(name:"Garamond", size:10.0)

and for any run of text in iOS, you are allowed to set this UIFont property however you like. If you want to have a run of text with lining figures followed by a run of text with old style figures, you need to do the equivalent of

let liningFont: UIFont = UIFont(name:"Garamond", size:10.0)
let osfFont: UIFont = UIFont(name:"Garamond-scOSF", size:10.0)

and whenever you need to use both of them, what you do is create and attributed string that contains a run of text whose font may be liningFont and then append a second run of text whose font is osfFont. In the abstract, i think this doesn't sounds totally crazy, but it is a bit verbose. the above example reads like this:

var liningRun = NSMutableAttributedString(string: "01234",
    attributes: [NSFontAttributeName: liningFont!])
var osfRun = NSAttributedString(string: "567890",
    attributes: [NSFontAttributeName: osfFont!])
liningRun.appendAttributedString(osfRun)

which results in something like

Attributed strings can set a bunch of attributes: its font (which we've just seen), the kerning or tracking for a region of text, its use of ligatures, its color, or any number of other attributes. The key is that these attributes are settings that you can apply to areas of text. But important to keep in mind is that these settings, while similar to a Font's settings, are different.

In contrast, switching a font's size, small caps, oldstyle figures, stylistic alternates and other opentype features require creating a new font object with those features enabled rather than specifying that feature as an attribute of a region inside an attributed string.

As an aside, i personally think it's weird that something like kerning or use of ligatures is assumed to apply equally to multiple fonts in the same attributed string but something like an opentype feature like old stlyle figures is assumed to be a feature on a font, but that's just the world we live in.

In core text and by proxy, text kit, there are two ways to create a font. The first is by creating a new UIFont with a font name and a font size. The second is by using a UIFontDescriptor.

Font descriptors are an oddly optimistic technology. You basically say something like "i want a font on this device that matches, as closely as possible these properties" and the system is responsible for returning a font which has as many of those attributes as possible. I'll talk later about why i think font descriptors are overly optimistic, but let's get to the codey parts.

futzing with descriptors

the typical approach to muddling around with fonts, in particular, activating opentype features, is something like what you see in the fantastic 2013 wwdc session "using fonts with text kit" session by ned holbrook:

func fontWithONUM(baseFont: UIFont) -> UIFont {
    let oDesc = baseFont.fontDescriptor()
    let features: [NSObject: AnyObject] = [
        UIFontDescriptorFeatureSettingsAttribute: [
            [
                UIFontFeatureTypeIdentifierKey:
                    kNumberCaseType,
                UIFontFeatureSelectorIdentifierKey:
                    kLowerCaseNumbersSelector
            ]
        ]
    ]
    let newDesc = oDesc.fontDescriptorByAddingAttributes(features)
    return UIFont(descriptor: newDesc, size: 0.0)
}

The idea is that you serialize your UIFont instance into a font descriptor, mutate that by adding new features and finally create a brand new Font seeded by that modified descriptor (using 0.0 as the font size preserves the descriptor's font size) Here is how you might make use of this code:

let myFont:UIFont = UIFont(name:"ProximaNova-Regular", size:14.0)!
let myFancyFont:UIFont = fontWithONUM(myFont)

And that's not wrong, per sé, but it's not exactly the nicest syntax for this sorta thing and you can imagine the dreaded lisp-style fingernailcuttings for a partucilurly extravagant font with many features. The point of this blog post, though, is to suggest that PERHAPS there is a nicer looking way of doing this. Let's see it!

chaining like a boss

Instead of passing in a font and getting back another font, why not actually just start by extending UIFont? We can do this by writing basically the EXACT same sort of code

extension UIFont {
    func fontWithFeature(key: AnyObject, value:AnyObject) -> UIFont {
        let originalDesc = self.fontDescriptor()
        let features:[NSObject: AnyObject] = [
            UIFontDescriptorFeatureSettingsAttribute: [
                [
                    UIFontFeatureTypeIdentifierKey: key,
                    UIFontFeatureSelectorIdentifierKey: value
                ]
            ]
        ]
        let newDesc = originalDesc.fontDescriptorByAddingAttributes(features)
        return UIFont(descriptor: newDesc, size: 0.0)
    }
}

Two changes here: first, i'm extending UIFont with this method. This means that any UIFont instance can now call this method to its heart's content.

But also notice that the substantive change that's happened here is that rather than hard-coding the values for UIFontFeatureTypeIdentifierKey and UIFontFeatureSelectorIdentifierKey i instead pass them directly into the method as its only arguments (i no longer have to pass in the font because it's available as self.) So for any UIFont instance, you can now imbue it with any set of features easily.

But instead of dealing with features abstractly, we'd like to at least have a way of talking about them without having to resort to actual key values like savages.

So we do something like this:

extension UIFont {

    // repeated from above
    func fontWithFeature(...) -> UIFont { ... }

    func fontWithSMCP() -> UIFont {
        return self.fontWithFeature(
            kLowerCaseType,
            value: kLowerCaseSmallCapsSelector)
    }

    func fontWithC2SC() -> UIFont {
        return self.fontWithFeature(
            kUpperCaseType,
            value: kLowerCaseSmallCapsSelector)
    }

    func fontWithONUM() -> UIFont {
        return self.fontWithFeature(
            kNumberCaseType,
            value: kLowerCaseNumbersSelector)
    }
}

If you're wondering what other options exist other than kNumberCaseType, you can find other available features by looking at the <ATS/SFNTLayoutTypes.h> header in xcode or, more legibly and with comments, the newly redesigned truetype reference manual. In particular, this wacky naming convention i've chosen for my methods is due to me consciously ignoring the ATS/AAT abstractions (which presumably exist as a result of the churn of font and type layout technologies GX/AAT/TTF/OTF tech during the late 90s and early aughts) in favor of OpentType tags.

Anyhow, with these three methods, you can do something along the lines of writing code like:

let styledFont: UIFont = UIFont(
        name: "ProximaNova-Regular",
        size: 14.0)! // explicitly unwrap since init -> UIFont?
        .fontWithSMCP()
        .fontWithC2SC()
        .fontWithONUM()

and that would give you a font that would turn "A small caps font with 1234567890" into:

gripes

I obliquely mentioned that i have 'mixed' feelings about font descriptors and it's mostly because they're explicitly unreliable and because they assume the existence of exhaustive font families, such that you'd be able to query for a font with some properties like number types or special characters and so forth.

The system is designed to let you ask, but makes no assurances you'll get what you're looking for which can make it difficult to distinguish errors in your own code and errors in the font provided. Case in point rdar://17624040 (closed as dupe of rdar://17624040), a bug in iOS' bundled version of Avenir Next that prevents SMCP and C2SC from activating even though the features are present in the font (or if queried via CTFontCopyFeatures)

Which is sort of disappointing because those sorts of silent errors make it harder to trust that the more ambitious family-querying and filtering qualities of Font Descriptors work at all. That said, this is what you've got to work with.

Since this was mostly an exploration of activating features, i thought i'd add in another method for selectively activating stylistic sets as a bonus for anyone that made it all the way to the end. Enjoy!

/**
pass in a positive integer to activate that stylistic set
or pass a negative integer to deactivate that set.
0 deactivates all features.
 */
func fontWithSS(stylistic_set:Int) -> UIFont {
    // this cheats a bit, assuming the enum values for the
    // stylistic sets stay numbered the same, but... oh well...
    switch stylistic_set {
    case 0:
        let ss = 0
        return self.fontWithFeature(
            kStylisticAlternativesType,
            value: ss)
    case 1...20:
        let ss = stylistic_set * 2
        return self.fontWithFeature(
            kStylisticAlternativesType,
            value: ss)
    case (-20)...(-1):
        let ss = (stylistic_set * -2) + 1
        return self.fontWithFeature(
            kStylisticAlternativesType,
            value: ss)
    default:
        // in the worst case, return the font
        return self
    }
}

epilogue

If you're actually going this route, it might not be totally crazy to actually create your own shell around UIFont rather than extending it. In particular, you'll end up doing something like this if you do end up supporting Dynamic Type with non-helvetica in your app.

Also, i'm totally open to the very likely idea that i have gotten something wrong here. Let me know if i've gotten anything wrong via twitter @nsfmc or via email, which you should be able to find over to the left. hit me up with your feedback, please! thanks for reading!

under the dome

2024-05-11T15:24:32Z

i came to Under the Dome after being disappointed at the second episode of the show, so i started the audiobook and about 50 percent of the way through that, i started reading it proper. It was a true multimedia experience.

First thing though, i went in knowing the rough gist of the ending and I found that this did not ruin much for me. Getting there isn't half the fun in this case, it's all the fun. So if an ending can ruin something you enjoyed the other 99% of, you should sort of understand that the book is less about exploring "what caused the dome to trap this town?" than exploring "what happens after the dome goes down (and how)." Especially since, i think, the book allocates something like ten (disappointing) pages in total to fleshing out the "why" whereas it spends its other 99% dealing with the "what" and the "how."

So after watching and listening and reading, i think it's best to think of this book/story like a TV serial because King is actually really good at writing tv-style drama, down to the sort cheesy dialog, end-of-scene suspense and the instantly recognizable and memorable cast of new england townies. Each chapter has something between fifteen and twenty-five sections that simultaneously revolve around the chapter's major-arc and also serve to slightly advance the main plot. The book is something like twenty-five chapters long, so you can easily imagine treating it like a self-contained season-in-a-book. Or, i mean, a book.

The advantage the book has over the show (or almost any show) is that if you enjoy the first chapters, the writing doesn't really change much and the plotting remains consistent throughout. We don't get superfluous chapters dealing with some minor character's drug problem or 'a day at the hospital'/bottle episode or really any other season-filler-trope. Certainly there are chapters which heavily focus on 'one thing,' but these chapters also make up critical events in the course of the story.

Other reviews here point out how much of the ending is simply glossed over and that's true and distressing because so much of the book loves exploring incredibly brief events and traumas in stunning 120fps at 1080p.

It's implied that this brevity in explanation is due to the human inability to understand a deus-ex-machina and that, like most myths, the explanation is (probably) irrelevant. Should we really consider Zeus' motivations? Do they matter considering he's not usually the focus of any story? Those sorts of question are at the heart of whether or not you'll be bummed by the book's resolution (as it is). Are you more interested in the fate of the good people of Troy or are you more interested in why the gods magically mess with Achilles or Paris when it suits the story.

In contrast to contemporary TV plotting, the book doesn't have much by way of nonlinearity (ala flashforwords or chris nolanisms) and in a way that's great, but you start to think the book would have been better off being entirely bounded from the outset. Instead, it's not clear how long we're going to ride the chester's mill rollercoaster and so it's hard to calibrate our expectations for how meaningful any action is. Except you know that you're rapidly running out of pages. What do you make out of that situation? Suddenly two hundred pages to go, you end up in a horror novel where your sense of doom drives much of the suspense. There's a lot you get to see, but there's a loti> that you don't see and it really gets you thinking. Fifty pages to go and you start to believe anything could happen.

And then it's over.

private use

2024-05-11T15:24:32Z

this isn't an essay, it's more like a journal. i'm putting things in here that i find interesting and i try to string them together. i will probably update this over time, it will change as i learn more but i will try to keep the learning-spirit of it present.

the Private Use Areas are three ranges of code points (U+E000–U+F8FF in the BMP, and planes 15 and 16)

-- Private Use Area (unicode)

I did the math and realized that's 137,469 possible glyphs. That's a lot of glyph.

Here at work, I'd been trying to rationalize our use of various icons and so forth. But how? It's challenging because we have icons that are ka-specific but we also like having things like fontawesome around.

A while back, I made the decision to fork fontawesome so we could add in a few superfluous glyphs. Lots of peolpe do this actually but, maybe i'm missing something because I don't hear very much about it or their experiences forking an open source icon font.

what's the big deal?

The main challenges, as far as i'm concerned, at least as far as this all goes, is that when you're forking a stable project, you're creating some cognitive dissonance for your team who are already used to using the upstream version. Second, you're making a conscious decision to ignore or absorb upstream changes. Third, you may be trying to find a way to keep your project merging safely with the upstream project's.

Iconfonts are a strange beast because (unlike most text faces) they have the capacity to be incredibly modular, but the tooling around them does not encourage it. And you basically have four options: fontlab, fontforge, glyphs, and robofont (to say nothing of fontographer and type tool), all of which natively use a different file format.

and why, again?

At the time i had two goals: add extra glyphs to the font and change fontawesome's [class="icon-*"] selector so that it cost us less per-page-load. It turns out the selector change landed in 4.0, so at least i didn't spend too much time on that. But the issue of adding new glyphs remained legitimate.

The secondary benefit, which i hadn't considered at first, but which now seems quite legitimate, is reducing the glyph count. Of my earliest experiments when beginning this process, was seeing how many font-awesome glyphs we used. Here's some handy shell incantation you can use to figure this out for yourself

ack -ho "(?:[\" ])(icon-[a-z\-]+)" --html | \
sed 's/.\(.*\)/\1/' | \
sort | \
uniq

if you have looked at fontawesome recently, you will find upwards of 350 glyphs in use. do you need all those? clearly services like the (mostly) disemvoweled icnfnt are aware of this disconnect, but naturally a question is how to generate a version of the font with the above information without having to bother with clickity clicking a website.

generating a font

by far the easiest way of going about this is by running the Generate Font action that every font editor has available. but... are there other ways? yes! there are.

for example, if you're using a .ufo-based workflow, then you have at your disposal the afdko which now (natively) generates opentype fonts. If you're building one in release mode, the incantation goes something, for font awesome, like this:

$ makeotf -f FontAwesome.ufo \
-o FontAwesome.otf
-ff fdk/features \
-gf fdk/glyphOrder \
-mf fdk/menuname \
-r

which assumes you have a folder sitting around called fdk which contains opentype-specific features/glyphorder/etc. for reference, adobe publishes a reference implementation for Minion. Miguel Sousa wrote a small thing about how to generate this in a typophile GlyphOrderAndAliasDB thread.

Robofont generates this folder when you run the Generate Font command

if you are using robofont, then the app adds an entry to the font's lib called public.glyphOrder so you could, for example, do something like this:

import robofab.world

def glyphorder(font_path='/path/to/font.ufo', dest='glyphOrder'):
    MAX_POINTS = 1114113
    font = robofab.world.OpenFont(font_path)

    if font.lib.get('public.glyphOrder', None):
        # for a robofont font, you can get
        order = font.lib.get('public.glyphOrder')
    else:
        # otherwise, you can do
        order = font.keys()
        sorted(order, key=lambda g: font[g].unicode or MAX_POINTS)

    with open(dest, 'w') as out:
        for g in order:
            outstr = "%s  %s" % (g, g)
            if font[g].unicode:
                outstr += "  uni%04X" % font[g].unicode
            out.write(outstr+"\n")

Removing glyphs from the glyphOrder file doesn't really change anything and won't remove any of the glyphs from the font. to do that you need the tx tool or you would need to build a new version of the font from the source ufo.

fixing the font version string

For whatever reason, makeotf will generate an obtuse version string. It would be nice to be able to include things like "the git commit that yielded this font" rather than just a version number which may be stale.

To do this, you need ttx from the fonttools package. you can pip install fonttools for that. Having it, you can then run:

$ ttx myfont.otf

this will generate a file called myfont.ttx which is, semi-conveniently, an xml file.

You can then modify it by running a python script like this

"""versionit.py - call like `python versionit.py font.ttx vcs_hash'

it will make a file called font-vcs_hash.ttx
"""
import sys
import os
import xml.etree.ElementTree as ET

def versionit(ttx_file, vcs_hash):
    ttx_root = ET.parse(ttx_file)
    version = ttx_root.find('CFF/CFFFont/version').get('value')

    for name in ttx_root.findall('name/namerecord[@nameID="5"]'):
        name.text = "Version %s; %s" % (version, vcs_hash)

    filename, extension = os.path.splitext(ttx_file)
    ttx_root.write('%s-%s%s' % (filename, vcs_hash, extension),
        xml_declaration=True, encoding='utf-8')

if __name__ == '__main__':
    filename = sys.argv[1]
    vcs_hash = sys.argv[2]
    versionit(filename, vcs_hash)

this is super-basic, but you could extend this however you like, presumably by having it call ttx again on the resultant file and the

the pua

in case it's not obvious, it's quite common to work with the pua, the good folks at SIL document their use of it (mostly so others can understand how they've assigned ideographs and symbols).

Category Theory.

2024-05-11T15:24:32Z

I find myself getting more and more curmudgeonly over time. I bought a receiver for my tv, but i found configuring it to be arduous. I use new software and wonder if i'm missing something by only skimming the menus rather than devoting myself to them.

As an unfashionably nerdy child, i consumed product manuals and software specs with vigor. I was a master VCR programmer. I was an early tech support weenie. The common retort to this is "Young people have energy."

But maybe it wasn't a matter of energy (you're free to disagree) but an easy comfort to relish in Rules; to understand and play out the system someone else had designed for me to live in (absolving myself the responsibility of choice).

There's an interesting article from Harper's Magazine¹ about the concept of a "Democratic Spirit" via the (now prosaic) notion that language is shaped and observed by two camps, Descriptivists and Prescriptivists². You can look anywhere and find these sorts of folks: the kinds that are fascinated with following rules for a system (meet anyone with a vague interest in DnD) and those that are like cultural sponges, remixing style and systems to suit their needs. And it's not a binary-choice either, it's more like a gradient between the two.

Design is an opinionated field, informed by concepts like "systems" and "visual languages" and semiotics. The AIGA describes design as a "creative process that combines art and technology to communicate ideas." and design crits are littered with gems like "it just doesn't speak to me" or "what is this trying to say?" That design is a communicative medium should surprise nobody, least of all designers. It should also be no surprise that there are two camps of designers: the kind that treat design

Folks, myself included, like to make the distinction between "design aesthetic" and "design function" as if they're different things, but from a certain standpoint they're both a kind of vernacular; each is a style and method for making a point. Sometimes 'how you say it' is as important as 'what you say.'

Let's go back to tv receivers & software. When it comes to things like software and hardware, there's this Jakob Nielsen/Don Norman-esque belief that objects should be obvious, clear, reuse metaphors, etc. These are not bad goals at all. Interaction and interface design are important because they aim to create intelligible and reusable mental models for what are often complex ideas.

Over time, these ideas coalesce into a semi-standardized design language. At their outset, though, apps and devices try to find a way to express their newfound utility and differences through icons, metaphors and novel interface elements³. John maeda once noted⁴ that his digital camera's manual was twice as large as the one for his Volvo sedan. Digital camera technology still, to some degree, actively improves "the basics" enough that we still need to deal with these changes. In contrast, cars largely refine existing features nowadays rather than innovating fundamental things like the accelerator. If your car gets an upgrade these days, you don't need to relearn how to use the brakes or accelerator.

The goal of converging standards in ui design is to democratize the components of interfaces. In the development of indexhibit, daniel eatock said that he wanted to create 'archetypal' online portfolios which democratically favored content rather than the design of the portfolio. Back when voicemail wasn't tied to a touchscreen ui, you could mostly count on the 7 key to mean 'delete'. When navigating indexhibit, you know what the portfolio contents are. When using a doorknob, you usually know how it's going to behave.

Standards exist to simplify common things, which is goood, nobody disputes that.

There's a term for a certain flavor of exaggerated gramattical etiquette called "hypercorrection"⁵ where people, afraid of sounding 'stupid' always use "I" instead of "me", despite the word "me" being 'more appropriate' in the context as a grammatical object. Languages and their grammars have lots of rules, mostly so you can make a point as unambiguously as possible to as many people as possible.

In design, as in a grammar, these rules are often byzantine. There are accepted numerical guidelines for justifying text in inDesign on the numeric end and there are flavor-profiles for mixing and matching type on the abstract end. There are rules as to what you can do and what you shouldn't do and what has, historically, looked 'good,' and what "Golden Ratios" and musical scales have been used since time immemorable. These rules are passed down in the best Prescriptive manner by instructors and classmates.

Graphic Design is largely prescriptive. It thrives on correct things and as a result it has its fair share of hypercorrection. Why do so many designs look similar? Why do hierarchies often look the same between websites? Why are standardized grids so common? Part is pragmatism but the other part is often falling back on standards. But when you start falling back on prescriptive rules and pre-fab systems to Design something you are consciously making a choice to make that aspect of your design invisible. This is roughly the same argument for using Standard Written English to make your point.

My impression has been that Fine Artists think this manner of rule-using and setting is laughable since Fine Art thrives on people challenging norms and conventions. As in Fine Art, Design rewards 'successful' challenges to convention. The successes are duplicated, they evolve, they change, they take on a life of their own. They are memes in the highest-brow sense. The others are simply 'wrong' until a subculture fetishizes them and champions them on their own merits⁶.

For an example of this, you can look at David Carson, the poster-child for designers wanting to tout that "design doesn't have to play by the rules." And, since he existed at a time when grunge was very much culturally de stijl, you can witness the accompanying success of his cohort of zuzana and neville and paula and stefan and all the gang who just wanted to eff things up real nice⁷. The exact same people who massimo was very publicly pillorying and, if you've watched Helvetica, you can see him slighting with gusto.

To say that Design, as a field, is conflicted about its place in the Art world is something of an understatement⁸.

The comedy of iOS7 was chiefly the 'designer reaction,' mostly for their bare-fisted prescriptivism (at quantities unseen since the reveal of wolff olins' london 2012 logo⁹). iOS7 was all wrong they said. Helvetica as system font was wrong. The grid was "OK", but its application was wrong. Even the gracious crits toed the party line vis-a-vis type, color, icon design, etc¹⁰.

Then, just as soon as the crits began, the consensus turned again to the fact that iOS7 wasn't complete yet, and finally that we were judging iOS7 prematurely.

But the point is not that iOS's design was divisive (uninteresting) but that the kind of reaction is highly divisive. You see arguments that fall back on prescribed rubric, on taste, on 'correctness' and so forth. The opposing viewpoints have mostly centered around "give it time" and "it's new, let's see what happens."¹¹ Certainly there's probably some hedging going on, but a rationale for reserving judgment that centers on "i don't understand what this means yet" implies a descriptivist's assessment that iOS' success is largely dependent on what everyone else does in relation to it.

Actually, let me return to london 2012 for a second:

The typeface needed to be part of this world, be linear and graphic, not typographic, not have the formal typographic subtleties of the typefaces its been compared to, or their reference points of blackletter or cartoon.

Such comparisons have missed the point and have not considered idea of the identity or the type in context, or context according to its original brief. Or they have just not liked the identity per se, so have expressed a general dislike of all aspects of the identity, not considering the inadequacies or otherwise of the type as a supporting element to the logo.¹²

The overarching critique of the games' identity was formal¹³, but for a system, this is something of a red herring. The above plea is not asking that folks accept the aesthetic choices that produced the logo or font, rather it's begging that people evaluate the type in the context of the logo and the universe it spawned.

And if we tolerate, as a profession, the notion that design is a tool for communication, it is unfortunate that a vocal subset of influential designers expect design to communicate instantly intelligible ideas. Certainly, much of design services simple ideas, but any communication platform will at some stage try to express or present a legitimately new idea. What then?

This isn't an excuse for needless complexity in design. Nobody likes that, but most interaction designs tend to be compromises between convention and the peculiarities of whatever new mental model is being presented¹⁴. The canonical example is File Sync (which is Hard, btw). As of 2005, the best solution was something like Unison. And then dropbox showed up and instead of letting people deal with a complex config file, just gave people a magic folder with blue and green icons to let you know if your files had finished syncing. Sync is still hard, but dropbox acknowledged that most people just don't care as long as you create conflicted versions and give them a few gigs of free storage space.

And some conceptual simplifications are helpful but others are leaky abstractions and as a result, when we begin to critique anything new, we look for the familiar and try to make sense of elements we haven't seen before.

What you get right, nobody mentions it.

What you get wrong, people bitch about.

What is difficult to understand you have to explain to people over and over again¹⁵

In mathematics, Category Theory¹⁶ is a way of Strictly/Formally defining 'things' and mappings or relations between them and how it is possible to combine those relations/mappings. The allure and the beatuy of category theory is that the rules for defining a category are quite straightforward and they allow you to define a rational system from the outset. There can be no ambiguity because in order to get to the point where you're talking about the interactions between mappings and groups, you must necessarily agree with the initial context.

What's appealing is that this system provides you a set of guidelines for understanding how this world works and then lets you figure out how you go about mixing and matching the components in a way that both creates some newish thing also within the bounds of the rules you all agreed to.

The problem with design is that it is not in any way like category theory. The rules are always changing, the way the world deals with design is unbounded and ill-defined. Critics champion random things, rules are broken, people like Wrong Things for reasons that defy logic. And further

But part of this whole vcr love as a child but receiver disappointment as an adult is that I have developed more complex ideas about how receivers could work. A VCR is not a complicated device and, as a six year old, i don't think i had very complex demands of them. But as time goes on, there are more things i expect devices or designs or anything to "get right."

And naturally, in this, prescriptivism is a comfortable stance to take. But you define your own prescriptivism as well, you set down rules for how the world or design or logos should work and those define the edges of what others get right or wrong. I'm not treading new ground here by saying this, we all know this is how taste and subjective opinions play out.

And naturally it's difficult to let go of your own rule-systems: you've invested lots of energy in creating them and there's nothing which objectively proves anyone has it figured out any more than you have.

Here cementing my yuppie bona fides, Tense Present, David Foster Wallace. Haper's Magazine April 2001. I am underselling how great this essay is: it starts by showing the context of the prescriptivist / descriptivist debate and afterwards challenges you to determine which is Right. Fine, but spoilers, the essay then wallops you with a review for a reference guide that does the same thing Wallace does in prose.↩
For the purposes of the article, Descriptivists watch language play itself out and document it as well as they can. Meanwhile, Prescriptivists (as their name implies) prescribe historically correct and proper usage of language.↩
Remember the difference between Winamp and iTunes back in the day (if you remember that far back)?. Winamp was particularly hands-off about your music collection and unskinned, it looked like a piece of component audio hardware. Its main ui element was the playlist editor which gobbled up m3us or whole directory structures. By contrast, iTunes was very much designed to not only play, but collect your music. Playlists were available, but they were secondary to its Library view.↩
This musing appears in his ted talk and also featured prominently in his run-up to his Laws of Simplicity book. And with good reason, it's an astute observation that technological innovation has the capacity to make once-obvious things complicated. Having a tiny screen on the back of your camera is valuable for providing you feedback, but it has the effect of encouraging you to perform your feedback loop as you're taking photos rather than editing your photos much later.↩
garner's modern american usage, Hypercorrection. The problem is not limited to I/me, but also who/whom, and so forth.↩
see for example: pixel art / ascii art / scanner glitches over rococo tapestries / etc↩
or Weingart if you want to go further back.↩
this debate goes pretty much all the way back to the 1920s or so when typographers debated whether or not the title Graphic Designer was an affront towards honest typographers. Is Design layout? Is it Art? Is it Typography? Is it Illustration? These questions (and more) are fodder for most MFA seminars.

Take a second and ask yourself if it's problematic if design aspires to art. For art to be 'successful' do you have to 'get it' the same way you have to 'get' a design? Certainly, design has some leeway to express itself creatively, but is it the same leeway we allow to something like, say, R.Mutt's Fountain)?↩
it's, at this point, not totally beyond the pale to suggest that the logocalypse that was foretold by vocal designers was completely overblown. Why this was an issue at all is ridiculous. Did the logo violate the sanctity of the games any more than the 2000 sydney games or the 2008 beijing games (both of which might as well have been cut from the same cloth)?↩
This is perhaps an unkind assessment of Frank Chimero's honest realization that time smooths over many design wounds but even as rational as his argument was, he couldn't help but get a dig in.↩
om malik's ios7 designer roundup is disturbingly informative.↩
Naturally, Gareth Hague, the designer of Headline 2012, weighed in on the vocal reactions to the 2012 logo. Note, even in this quote and in the rest of his reaction the use of the word 'context.'↩
here i use the word formal as "Relating to the form or structure of something" rather than its more common use as "ceremonial" or "official"↩
This was made apparent to me the first time i used Lightroom and the first time i attempted to use final cut pro. I had zero frame of reference for film and so the whole thing seemed to me needlessly complex. In contrast, when i used lightroom, i immediately understood what they were trying to do, possibly because i had spent plenty of time thinking in "the photo space."

I actually don't know if final cut is considered a Good application, but i do know that i lack a mental frame of reference from which to judge it which makes me think that↩
joe armstrong's Three Laws of Programming Languages re: elixir. It's worth mentioning if it's not obvious that this gem comes from the designer of a Programming Language, a person intimately aware of the limitations of trying to express complex ideas in a strict grammar.↩
another good description with more historical context appears in Spivak's category theory for natural sciences. Here i resist the urge to use the word functor.↩

keys

2024-05-11T15:24:32Z

what's going on

In what is likely to be the ultimate yak, i recently discovered that the vsco keys app was open sourced. I don't think i was ever the app's target demographic, but it's an interesting tool that assigns lightroom actions and presets to keyboard keys so you can speed up your photo editing workflow. It had a webapp that generated keymap configs that you could import back into the main client.

So what? it got open sourced. it was a bigger support drain than it was a profit center, so it's understandable, but when an app goes open, you get to learn all sorts of things about the decisions people made when developing an app. In my case, i have a clear plan: i want to fill the gaps that are currently missing for keys (primarily because it is a fun design challenge) but the process to get there is totally an exercise in archaeology and trying to understand an application i never got to use.

So this is going to be a journal in something like five parts:

The config/savefile format
The webapp that generates keymaps
Designing around my dvorak life
The os x application
The lightroom plugin

Almost every application that deals with keypresses also just assumes that you're using qwerty and not, say, dvorak or colmak. Few apps are good at dealing with this. Starcraft 2, for instance, can detect your keymap and will remap the 'grid' layout so that the labeled 1-4, q-r, a-f, z-v keys do what you expect them to (but they conveniently label them in the ui with their dvorak equivalents). On mac-os, dota2 for instance, gets confused and will still listen for qwer instead of ',.p, which requires you to remap these keys (or always use qwerty at the expense of typing replies slowly).

Because the whole purpose of vsco keys (presumably) is to give spatial regions of your keyboard functional uses, having to dance around qwerty->dvorak remapping needs to be part of the work.

The project itself is fairly contained, too: figuring out the filetype should be fairly straightforward. Generating the config files will probably be the most time-intensive aspect. With any luck, i won't have to deal with the lightroom plugin (whose source, btw, was not provided). That leaves the osx host application which, as time goes on, strikes me as the most fragile. Thankfully, its source is available and needs to be updated to integrate with whatever webapp i end up making.

the savefiles

The project provides some pretty minimal guidance for how to create your own configuration: they have a sampleLayout.keysjson file and two ancillary files, one a json array with keycodes and key labels and another with what appears to be the name of every single lightroom command annotated with ranges and pretty-printed label. Your goal as end-user is to take the two supplementary files and generate new config files with them, by hand, like an animal.

defaults

When you manage to get the app installed, you notice the following preinstalled presets:

These seem like they should be good fodder for figuring out how you might develop a full-featured config file, so i started searching for them and found... nothing? eventually, after searching for a while i decided to search for the word standard and came across something that looked promising initially

but on closer inspection...

marcos@Dalarna in ~
○ hexdump ~/Downloads/VSCOSimple.vkeys
0000000 ae d2 0b e2 d3 66 00 82 52 c9 54 34 8c 11 05 78
0000010 67 1d 60 e6 5e e2 44 fa bf 7c df aa cb ae 8a 3d
0000020 12 c8 96 32 31 20 cb f0 16 28 3c a9 ef e3 0c 5c
0000030 09 ff dc ad 67 01 59 41 9b f7 8d c0 23 cf 31 d3
....

and from here you can see

marcos@Dalarna in ~
○ file ~/Downloads/VSCOSimple.vkeys
/Users/marcos/Downloads/VSCOSimple.vkeys: data

ok, so it's not, sadly, gzipped json, so my next guess is that maybe i'm just looking at a marshalled NSDictionary. but before i decided to investigate that route, i noticed that the app needed to support two separate extensions: vkeys and keysjson and thinking ever farther back, the apps are cross-platform (win/mac), so whatever the format is, it's probably not just a raw NSData dump, it's probably something at least easy to port between platforms.

the next trick was searching for vkeys and seeing what came up and, lo and behold

But... and here's the funny one, you'll notice the KEYFILE_AES_KEY const just hanging out there, but my initial guess was that it was used to verify licenses or valid keyfiles. instead, i find the - (void) importKeyFile method that seems to call - (NSMutableDictionary) decryptAndParseKeyfile that calls, effectively, [[NSData dataWithContentsOfFile:filePath] decrypt]. Also, this may not be obvious, but - (NSData *) decrypt is not standard.

The code for it looks like this, though

NSUInteger dataLength = [self length];
uint8_t *unencryptedData = malloc(dataLength + kCCKeySizeAES128);
size_t unencryptedLength;

CCCryptorStatus status = CCCrypt(
  kCCDecrypt,
  kCCAlgorithmAES128,
  kCCOptionPKCS7Padding,
  KEYFILE_AES_KEY,
  kCCKeySizeAES128,
  NULL,
  [self bytes],
  dataLength,
  unencryptedData,
  dataLength,
  &unencryptedLength);

return [NSData dataWithBytes:unencryptedData
                      length:unencryptedLength];

and if you look close, you realize that KEYFILE_AES_KEY is showing what its purpose actually is.

An aside here: as a kid i always though binary file formats were magic until i realized (much later) that they were often just often just spewed out representations of lists and dictionaries. When i learned that some of them were simply marshalled datatypes i felt like i had just pulled back a curtain.

anyhow, a quick trip to google reveals that this CommonCrypto incantation is a stock AES 128¹ incantation, which means that even though you could could reuse that code to make a cli application², you could also (probably) just feed a vkeys file to openssl and decrypt it there successfully.

this makes sense, too, if you stop and think about the app being cross-platform: if the key files are generated via webapp, that means that the webapp has to be able to output some format that can easily be parsed by c# in windows and objective c on the mac, so the webapp is unlikely to be spewing forth the result of [internalRepresentation writeToUrl: foo atomically: YES]

An aside though: why encrypt the vkeys files? I can sorta understand the copy-protection angle, but from my perspective, being able to view the exported data doesn't help you much (especially given how user-hostile json is for most people, even devs, to edit.)

The other thing to note is that if the app is going to be backwards compatible for older users, when they open source it, they need to disclose that key in order to retain compatibility for users with legitimately generated keymaps. I think they could actually have gotten pretty good mileage out of gzip in this case with a changed the extension assuming that their application would always intercept the file when opening.

Anyhow, so we have these keyfiles, how do we decrypt them? A cursory glance on the internet reveals that the openssl command to decrypt files looks roughly like

openssl enc <cypher> -d -in VSCOSimple.vkeys \
-out VSCOSimple.keysjson -K <encryption key>

looking back at the CommonCrypto incantation, you see that it's AES 128 (and peeking at the commoncrypto docs, you find that the default is AES 128 CBC and that the command to decrypt it specifices a NULL initialization vector (iv).) This is good to know, because the options for cyphers are

Cipher commands (see the `enc' command for more details)
aes-128-cbc    aes-128-ecb    aes-192-cbc    aes-192-ecb    aes-256-cbc
aes-256-ecb    base64         bf             bf-cbc         bf-cfb
bf-ecb         bf-ofb         cast           cast-cbc       cast5-cbc
...

So we can update the command to

openssl enc -aes-128-cbc -d -in VSCOSimple.vkeys \
-out VSCOSimple.keysjson -K <encryption key> -iv 0

Now, if you investigate the arguments to openssl enc you find

-K/-iv         key/iv in hex is the next argument

which means that you need to convert the string key value in the app source code to a hex value. You can do this in ye olde python with this command (it prints the hex of each character in the original key)

python -c "print ''.join(['%x' % ord(x) for x in '4Nfurb94B6iW64QD'])"
344e6675726239344236695736345144

armed with this, you can now fix the incantation

openssl enc -aes-128-cbc -d -in VSCOSimple.vkeys \
-out VSCOSimple.keysjson \
-K 344e6675726239344236695736345144 -iv 0

and easy-peasy-lemon-squeezy, you get

With that, i proceeded to upload them to my fork of the keys project.

That's all for now, but i'll keep updating this when i have time to hack on the project.

which kind of aes, we'll discuss later↩
which, if we're being honest, this is what i did initially just to peek at a more complete file, but i think the openssl approach is more interesting.↩

what you don't know

2024-05-11T15:24:32Z

In may of this year, shortly before giving an acclaimed ted talk elaborating on many of these points, zeynep tufekci wrote the following in the new york times.

If a bridge sways and falls, we can diagnose that as a failure, fault the engineering, and try to do better next time. If Google shows you these 11 results instead of those 11, or if a hiring algorithm puts this person’s résumé at the top of a file and not that one, who is to definitively say what is correct, and what is wrong? Without laws of nature to anchor them, algorithms used in such subjective decision making can never be truly neutral, objective or scientific.

Programmers do not, and often cannot, predict what their complex programs will do. Google’s Internet services are billions of lines of code. Once these algorithms with an enormous number of moving parts are set loose, they then interact with the world, and learn and react. The consequences aren’t easily predictable.

First, i want to break down two issues here:

One is the unintended consequences of designing an algorithm.
The Second, are the unexpected consequences of performing a complex task atop a set of opaque abstractions.

The two seem similar, they're definitely related, but they are different. I'm going to talk about the second because it's more insidious than the first. It is easier to look at an algorithm and see outright bias, it is harder though when the behavior is a side-effect of the unexamined limitations made about the underlying system.

I want to focus on zeynep's google example first because when i was in college, my system design class devoted a section of reading to looking at large scale systems. One of the fun ones at the time (2005) was google's mapreduce: designed both to make parallelism accessible to lowly mortals and simultaneously show off their clever use of commodity hardware, as you can see in the mapreduce paper's abstract:

Programs written in this functional style are automatically parallelized and executed on a large cluster of commodity machines. The run-time system takes care of the details of partitioning the input data, scheduling the program's execution across a set of machines, handling machine failures, and managing the required inter-machine communication. This allows programmers without any experience with parallel and distributed systems to easily utilize the resources of a large distributed system.

Our implementation of MapReduce runs on a large cluster of commodity machines and is highly scalable: a typical MapReduce computation processes many terabytes of data on thousands of machines. Programmers find the system easy to use: hundreds of MapReduce programs have been implemented and upwards of one thousand MapReduce jobs are executed on Google's clusters every day.

Emphasis mine¹ because the whole crux is that mapreduce allows for the peasant ails of commodity machines while doing the best it can to insulate you from catastrophic failure and returning some usable results (and performantly!). Plus, you don't even really need to understand parallelism to make good use of it!

There was a moment while we discussed the paper where we had this cute illustration, i'll do my best to explain it since it's basically a funnel: there was The Cloud™, it represented all possible data on the internet. A subsection of that cloud was the amount of the public-facing internet that google had indexed. A subsection of that cloud was the entirety of the results google knew about for your given query. And finally, a subset of that cloud represented the results of your query that had survived the search job* either due to timeouts/latency/commodity hardware/solar flares/etc².

The point being that for almost all queries, there were an impossibly large number of possible results for the specific thing you were looking for and (improbably) the least novel thing was getting your search results within some window of time³. In a mapreduce world, the system 'deals' with the issue of a result not showing up by returning whatever it has at the end of some timeout. This works because pretty much any internet user, has absolutely no clue how many of the results could be of any actual value (to say nothing of how many results there were to begin with). So what if pages 4-6 of the Total Results don't show up? Do you even go that far? Would you notice? (at the time, and still today, people tend to not look past the first page of results). Even if one or two links are missing, you still get most of the relevant data back (better than nothing).

slowly learning a few things about distributed systems pic.twitter.com/C2gRnHgau4
— Julia Evans (@b0rk) November 1, 2016

When the number of results for your query is in the tens of thousands, does it matter if 4500-4520 are missing (or even just slightly misordered)? You may scoff, but this is a legitimate question! If it matters, much like a tree in the woods, does it matter if you never look at the results (or are statistically unlikely to look at them). Does it matter if the results are correctly ordered the next time you reload the page?

This is not to say that there isn't bias in google's search result algorithm (it thankfully is biased against some kinds of harmful content), but that there is a belief that any result is better than no result. (for something not mission critical, you can argue that focusing on Availability is not at all unreasonable, at least that's my claim)

Facebook's lee byron (in a very interesting post about building a feed) makes the following observation about the benefits of lazy-loading a dataset presented to somebody browsing a feed.

How many followers will the most popular content sources have?

Twitter used to call this the "Bieber problem": when he tweeted, a fan-out operation occurred, placing this new tweet into the feeds of every one of his followers which was a massive job that locked up whole machines. In Twitter's earlier years, a couple quick @justinbieber tweets in a row could "fail whale" the whole service.

The "Bieber problem" is an illustration of a critical decision of the architecture of a feed service: do you build a user's feed at write time or at read time? Twitter's architecture placed tweets into feeds as soon as they were written into the service. By contrast, Facebook's architecture waits for a user to read their feed before actually looking up the latest posts from each followed account.

...

Should the story at the very top of your activity feed be the very most latest thing that happened, or should it be the very most interesting thing that happened? This is more of a product decision than an architectural one, but it has serious implications on your feed architecture.

I would argue that he understates how much archituctural choices can retcon their way into product decisions. If a tweet is deleted from my feed as i'm reading, can i really be all that angry? "Who's right" in that case aligns with the moral quandry of the probabalistically failing google mapreduce server: if @justinbieber deletes a tweet but you're not finished reading it, should you have been entitled to finish it?

A similar bit of architectural-influenced thought recently surfaced in a post from tristan harris, a google design ethicist

For example, imagine you’re out with friends on a Tuesday night and want to keep the conversation going. You open Yelp to find nearby recommendations and see a list of bars. The group turns into a huddle of faces staring down at their phones comparing bars. They scrutinize the photos of each, comparing cocktail drinks. Is this menu still relevant to the original desire of the group?

It’s not that bars aren’t a good choice, it’s that Yelp substituted the group’s original question (“where can we go to keep talking?”) with a different question (“what’s a bar with good photos of cocktails?”) all by shaping the menu.

Moreover, the group falls for the illusion that Yelp’s menu represents a complete set of choices for where to go.

which, emphasis mine. and while i personally feel less morally pigeonholed by my phone (or yelp) (and i believe that tristan believes that people ought to be empowered by theirs) i really don't know that i am legitimately perturbed by yelp's incomplete view of the universe (to be clear, i don't want yelp asking me why i feel compelled to visit a bar right now (and self-improvement aside, i don't know that others would either)).

I'm reminded of this classic 'quote' from magician Teller about magic:

If you are given a choice, you believe you have acted freely. This is one of the darkest of all psychological secrets.

and again from tristan

We don’t miss what we don’t see.

I don't believe that any programmer (or ethicist) at google (and, from the way lee byron writes, those at facebook), would pretend that their algorithms behave 100% predictably at all times (as we nerds would say deterministically) each time they're run. The behavior of a feed or a search result page is, by necessity, the hybrid product of an architectural performance optimization, the whims of the hardware on a given day, solar flares, and hosts of other reasons, many of which are product/business-oriented (or, ways for you to make the service profitable).

Which, again, i want to return to that first excerpt from zeynep's piece:

If Google shows you these 11 results instead of those 11, or if a hiring algorithm puts this person’s résumé at the top of a file and not that one, who is to definitively say what is correct, and what is wrong? Without laws of nature to anchor them, algorithms used in such subjective decision making can never be truly neutral, objective or scientific.

Programmers do not, and often cannot, predict what their complex programs will do.

While i go along with much that zeynep is argues for, trying to compare physical structures to the inner-workings of a database strikes me as completely out of whack. Similar to people who trust that "digital" provides some kind of archival panacea but don't realize that digital data (unless redundantly archived on resiliant physical media) is subject to corruption, bit flips and other sundry damage⁴. Once your datastore spans multiple "availability zones"(continents) and needs to make interesting guarantees about atomicity, consistency and partition tolerance, i argue that you've gone way beyond the complexity of a bridge.

to claim that a system that gracefully tolerates hardware failure exhibits a bias is 100% true, and there are other biasing factors at work in any of these systems (which, see the depressing end of the spectrum). But it also gives the laws of nature an easy pass—what does it mean to have a law of nature anchor a search result? Do we choose a system that behaves predictably at the expense of convenience? Certainly the decision to "show the truth" vs "show a good approxmation" is an ethical one, but how big of one is it? When does data-center latency become ethically fraught? What sorts of disclaimers do services need to furnish us with? What about our friends?

Julia Evans has written a fair bit about distributed systems and what people mean when they talk abou things like http://jvns.ca/blog/2016/10/21/consistency-vs-availability/.

... I know what availability is! It means I don’t get paged because the system is down. Basically it means if you ask, you can always get an answer! I like that. What’s wrong with that?

So! let’s say we have 100 computers in a “cluster”. I think “consistency” kinda means “if you query any computer in the cluster at the same time it will tell you the same thing”. It doesn’t really mean that (that is actually legit impossible because of the speed of light) but let’s go with it.

There was a time when we were lucky enough to interact with services that could plausibly run without concern for CAP and our conception of data-morality was simpler: either the server was down, or it wasn't. A successful query represented the only truth at single point in time. The massively redundant world we live in now is much much more complex. But developers, designers, and project leads are often insulated from this sort of infrastructure and what it means for data being returned from a query. If you lead or design a project, when was the last time you asked about whether a backing api request favored being "consistent" or "available" and what that meant for your product's consumers?

When you ask yelp for a bar and it suggests a park, what sort of moralistic puritanic editorializing is that? also, how do you know it's not? when a hardware failure prevents you from seeing a retweet for a minute (but lets you see the rest of your feed), what kind of bias is that? Why are we so offended (and scandalized!) when we're presented with the equivalent of a gap in memory (or best-available information)? Is it because we don't know the reason behind it? Is it because it exposes the nature of our relationships with these services? When you're shopping around for services do you factor in Consistency vs Availability in your decision?

Some other unstructured thoughts:

My system design class also introduced another article about the Therac 25 that left many in the class somewhat scarred. For many of us, the short-term takeaway was "thank god i don't have to write medical firmware," but you see the moral fallout of the therac if you peek at any code or system for any appreciable length of time.

I see this argument quite often that engineers have it easy because physics and statics can be modeled in a predictable way. When bridges fall due to hardware failure or poor design (or freak accidents!) people can die. When your CRUD application gracefully handles a backend failure and rolls back an optimistic ui update, i don't really know what to tell you. They're not on-par.

I also think it's strange that the counterpoint to dumb ml-algorithms are suggestions which seem to defeat the purpose of the relevant platform (and often with a *very WASP-ey bent!): i want a popular bar (have you tried a park?). I want to see what my friends posted (are you being challenged enough?). I want some search results (who is john galt?).

I'm not going to defend google or facebook, both of whom have had significant issues due to their scale and the tragic effects of systems applied to a heterogeneous world. but it goes without saying that it's problematic to treat their unintended consequences like a therac-25's (which, again to be clear, i am not giving them a pass, please read this troubling article for a counterpoint to my claim) when they are much more like a highly opinionated video store employee that reads you (without asking) and then suggests a movie they're not really that into, but think you'd probably like. Even when google and co. get it wrong, we aren't often talking about damage on par with the effects of shoddy bridge (or car) engineering (although again, that sentencing algorithm and minority-excluding ad dashboard is again the absurdly dark counterpoint).

Facebook influences more people than any country, it has a moral responsibility to be factual and educational. Hasn't risen to it. https://t.co/pMdbLbxhqy
— Stephan Ango (@kepano) October 21, 2016

When the stakes are legitimately low, do we need transparency in how google or facebook make decisions about our newsfeed? that's a very good question! should we have transparency as to why my server is upselling today's special appetizer? should the server tell me that today's french dip soup is the result of some roast beef's last day of usable shelf life? should i ask the record store employee what cultural basis grounds all the recommendations they give me? Should a sales person be required to tell me up-front they work on commission? Or do we regulate some of these things instead: what if in addition to a privacy policy, each website advertised its Consistency or Availability infrastructural choices?

Here's a funny story: the other day i came down with a terrible head cold leaving me comically congested. So i walked to the pharmacy and began to buy a pack of sudafed. However, the Methamphetamine Menace of the early aughts and War on Drugs require that I supply my driver's license when purchasing pseudoephedrine to ensure that i haven't been purchasing untold quantities of pseudoephedrine for my purported walter white side-gig. But i say “began” because the electronic logbook that particular safeway used was offline. Or maybe it wasn't the website, but the network of the safeway pharmacy. Or who knows. At a very tangible level, my sinuses were the victims of a law that, for liability reasons, was implemented by everyone assuming a stable link-layer and an Available web service. Laws are meant to be general-purpose but when they imply a hard dependency on things like a database, what sorts of laws govern its audits and security? Should safweay be accountable to the question of security of their logbooks? (the violations are steep and result in a federal misdemeanor). Given the risks, would you buy sudafed from a pharmacy or state that had a poorly implemented logbook? We talk about transactions being problematic because you could double-charge a consumer, but what about an unthrottled double-entry of a controlled pharmaceutical that triggers an immediate police response?

I'll close this out with a thought on google glass. I still believe that google glass' failure wasn't a foregone conclusion, but it was poorly socialized. There were absolutely no norms around it and so it became odd to see people taking it to the extreme as users and other folks assuming the worst when going about their day. It was too many new things at once. But if you limit the scope, maybe you can have a better go at things.

Spectacles are going to up many people's Snapchat game, but I can't get past the power of capturing moments I never had a chance to capture pic.twitter.com/htjmMAEn8Z
— Sean O'Kane (@sokane1) November 18, 2016

w/r/t services, i am not going to cop-out and say "you don't have to use it," because the choice isn't always ours if we intersect with somebody else's use of some bias-ridden service. How do we resolve being tagged in a service we're not members of? Do we pass it off on the person doing the tagging or do we enforce policies on services? What about when the result isn't just annoyance but actively harmful?

For many of us that have used some form of irc/icq/aim/zephyr/jabber/etc for upwards of 20 years, the norms around slack communication feel oddly formal compared to prior systems which felt truly asynchronous (often responding to a message 12 or 24 hours later). The pitch "slack is the email killer" subconsciously migrates social expectations from email (attentiveness, timely replies) to the norms of irc or im (not all messages need an ACK). That's also under-selling the issue, but it's definitely part of it. Do workplaces that caveat 'important things need to be emailed' experience the same level of slack-anxiety? most workplaces eventually establish norms around communication, but it feels like slack gets left out, which has caused its own set of problems.

One of the hallmarks of bad software is it believes it is something more than a tool you use to accomplish a task. pic.twitter.com/YRarXyNdq1
— Steven Frank (@stevenf) July 28, 2016

i talk about norms because when we go to a restaurant, we know(or have learned) why our server is upselling us. When our friends tell us to skip the bar, we understand the reason behind the diversion. We have built up norms around these sorts of social situations: servers want to sell specials and perform well (and depending on the establishment, pad out their tip), our friends may no longer be drinking, or maybe their throat hurts from shouting at last night's bar or whatever.

So what of the societal norms around the apps we use? We've been around long enough now to see at least one and a half dot-com busts and we've been witnessing the effect of companies who put off monetization for easily five to ten years now (or end their incredible journeys as the result of selling their company to somebody else). Still, each time we act offended when we discover that these free apps are also working to earn their investors and employees a buck. Next time it will be different, though.

As a field, we designers spend a lot of time talking about how to design with empathy and grace. Still, i suspect the problem is mostly that people expect apps to behave like utilities, deterministic and honest in their focused execution. Now, we're discovering there's something strange about our landlord or our electric company talking to (and empathizing with) us like our best friend and then shaking us down for extra money when the conversation takes a turn.

latest @magic growth hack starts by acting like an old friend, ends by asking to "hop on a call for 10 minutes" 😒😬😡 pic.twitter.com/PyQedn5yeh
— Michael Grinich (@grinich) July 18, 2016

although the meaning is now coded, at the time, the whole point of using the phrase "commodity machine" implied "this computer can barely gurantee an SLA" and "lol @ the lavish costs others spend for sparc/dec/ibm/etc servers running commercial bsd/vax/irix/etc." which made the abstract a sort of boastful triumph of architectural cleverness over cost and software over the unreliable nature of cheap hardware.↩
(*map-reduce was, at least then, not actively used for search, but it was a good enough proxy for the behavior of a large fault-tolerant system that favored partial output to no-output)↩
In the world of Databases and Computer Science, this "you get what you get and don't be upset" behavior is usually referred to as Availability and is usually pitted against Consistency, whose behavior is more like "i'll give you the most honest answer i have, but it may take a while (or you may never really get it)". The sophie's choice between the two of them is discussed up in the CAP theorem.↩
and for a multitude of reasons, the physical copy has its own problems.↩

generic.cx posts

depend-encies

firebase and redux

soooo, why redux?

composed depend-encies

Inputs

abstracting the database ref

drawbacks

unhalf-bricking

the degree

ideas

the churn

what will i retain?

all that time lost

not having fun anymore

who knows where the time goes?4

the death of paper prototypes

fun with vector fields

step one: notifications

step two: learnstorm?

step yak: a math detour

step two: prototyping

wait a minute

staggering animations

implementing this

lessons learned

why write todo comments?

the unblocking comment

dealing with guilt

thanks

chaining font descriptors in uikit

how fonts in ios work

futzing with descriptors

chaining like a boss

gripes

epilogue

under the dome

private use

what's the big deal?

and why, again?

generating a font

fixing the font version string

the pua

Category Theory.

keys

what's going on

the savefiles

defaults

what you don't know

who knows where the time goes?⁴