steveklabnik

I invented Hypermedia APIs by accident

Long long ago, I got an internship in college. Back then, I didn't know anything about web development. My college professor said “GET and POST are the same thing, it's just that GET requests show parameters in the URL bar.” But a friend of mine was working at this post-acquisition startup. They still operated as an autonomous unit within the parent company, so they were still pretty fun to work for. People would upload us MP3s and we'd give them a podcast. They'd get a blog, the necessary RSS, we'd help get them listed in iTunes, all that jazz.

Then the iPhone came out, and you could make apps for it.

Bizdev decided that we should sell apps to our clients, who could then sell them to their audience and help finance the show. We'd do all the dev work, we'd all make money, it'd be a good time. So they asked me to write an iPhone app generator. We picked a big feature set, and people could give us some images, pick their individual features, and set some other config options. We'd take that file, and compile in them as defaults. All seemed good.

Then the first app got rejected: it turns out that Apple has some restrictions on the bitrate of MP3s that you could download. I suspected that AT&T wasn't very happy with you using lots of data back then. Anyway, we had to get around this issue: we wanted to serve up quality audio. What to do?

I don't remember who came up with it, but we decided that the first thing the app would do would be to fetch the config file from the server, to see if any of the defaults were changed. It was just XML, so the iPhone could parse it easily, and then change whatever was different. So we'd have something like this:

<?xml version="1.0" encoding="UTF-8"?>

<config>
  <link href="http://example.com/low.rss" rel="podcast_url" />
</config>

I don't remember the exact schema, but you get the idea.

Anyway, so we'd link to the low quality feed while the app was in review, and then later, we'd change the response to this:

<?xml version="1.0" encoding="UTF-8"?>

<config>
  <link href="http://example.com/high.rss" rel="podcast_url" />
</config>

Now the client would fetch the high quality feed. No client code needed to change! We'd managed to sneak around a restriction in the review process.

But why stop here? Once we saw this flexibility, we started taking full advantage. People could set up a bunch of different configuration options, and that would change the UI based on their choices. So, for example, they could choose to be contacted by email, they could put in a website or two, and the page would change. Here's a mockup of the web page:

This would cause our app to serve up the following XML:

<?xml version="1.0" encoding="UTF-8"?>

<config>
  <link href="http://example.com/high.rss" rel="podcast_url" />
  <about>
    <links>
      <link href="http://example.com">Homepage</link>
      <link href="http://example.com/about">About Us</link>
    </links>
    <phone>5558675309</phone>
    <email>foo@example.com</email>
  </about>
</config>

And that would make this appear in the “about” section of the app:

Neat, eh? We'd turn the email into a mailto: link and the phone into a tel: one, as well.

Anyway, maybe later they'd go back and unset their phone number, and the about us link. So then we'd generate this XML:

<?xml version="1.0" encoding="UTF-8"?>

<config>
  <link href="http://example.com/high.rss" rel="podcast_url" />
  <about>
    <links>
      <link href="http://example.com">Homepage</link>
    </links>
    <email>foo@example.com</email>
  </about>
</config>

But check out what the app would do:

Whoah! Isn't that rad? The UI would change based on the config.

Here's what's even rad-er: because the app would read the config on each load, changes would get propagated very quickly. If you took your email away, everyone's apps would no longer have it, as if by magic. Next time they loaded up the app, it just wouldn't be there any more.

Here's what's even rad-er: You wouldn't need to go through the App Store approval process to push this change out to the users. It Just Worked. If you're an app developer, and you've been forced to sit through long waits to push out a release, you know how painful it can be. I don't know how fast it is these days, but back then, it could take a month. With this approach, we could, say, remove a feature, and it'd be gone immediately. No oversight. If we added a new feature, older apps would still work, because they'd just ignore the new part of the config, and people who got the new version would get the newest features.

Years later, after doing tons of research on Hypermedia APIs, I realized that that thing I did long ago was a form of it, and it provided us with a pretty massive benefit. So of course I wasn't the first one to come up with it; my point is that I implemented a system in line with hypermedia principles because it made sense to do so, even though I had no idea that Roy Fielding was a PhD candidate. And I certainly had no way of articulating it as a 'style,' it was just a neat hack.

If you liked this story, you may care to learn about what else I've learned along the way with Hypermedia APIs. I wrote an e-'book' about it called Designing Hypermedia APIs. It's only $20, and you get updates forever! I'm actively working on adding new content, and I'll be doing a total redux in the new year.

Deleuze for Developers: Deterritorialization

If you truly want to understand technology today, then you should at least be familiar with the philosophy of Gilles Deleuze. Unfortunately for technologists, Deleuze is rooted firmly in a philosophical tradition and a writing style that they probably find opaque. In this blog series, I plan on explaining Deleuze’s philosophy in terms that programmers can understand. This is the second in the series. You can find the first here, and the next one here. Enjoy.

Let's re-examine this diagram of the assemblage:

What's up with this line?

Well, just because assemblages are amorphous doesn't mean that there's no way to demarcate what's in the assemblage and what is not. This particular assemblage has a 'territory,' of sorts: everything that's inside the line is part of the territory, and everything that's not is outside. Think of a fort, or a castle:

Or, since we're not just talking about physical spaces, a social circle or group:

Of course, this would extend around all the members of Rails Core, hence it being cut off at the bottom. But the pink line would designate the boundaries of the assemblage that makes up Rails Core.

Deterritorialization

So what happens when these boundaries get crossed? Well, your castle gets invaded. A new member joins the team. New servers are brought online. This process is called 'deterritorialization.' Healing the lines, repairing them, and re-containing the boundary is called 'reterritorialization.' I recently came across a really interesting symbol of deterritorialization: the Open Source logo:

Check it out: visually, this logo communicates the deterritorializing effect of opening up your source code: the private internals have now been exposed internally. The walls have been breeched!

Another example, from building a web service: we start off with just our service:

We have here an application server, a database, and our user's identity. They form the assemblage of our system. Remember, abstract concepts are objects just as code and servers are! Our identity notion is stored within the database, therefore, they're connected.

Next, we decide to implement a 'log in with Twitter' feature.

It's the primary way that our users sign up and use our site. Now, Twitter's assemblage has deterritorialized ours:

We can minimize the effects (or reterritorialize our service) by making sure to have our own concept of identity within the system, and making sure that we have our own notion of identity within the system, and just connecting Twitter's notion of identity to our own:

Now, by containing the Twitter-assemblage entirely within our service, I don't mean that it actually is. Obviously, the Twitter-assemblage is interconnected with a ton of other assemblages that represent other services. But from our perspective, they are now a part of our assemblage. The decisions they make affect us. While our code is separated, we're not totally separate anymore: updates and policies of Twitter have a direct effect on us.

There's also a more sublte, secondary re/de-territorialization going on here: our code from our service. These used to be isomorphic, but now our code has claimed a territory of its own, and is now just one assemblage within our system-assemblage, instead of being our system-assemblage.

A git example

The previous notion of deterritorialization largely relied on the notion of dependencies as the mechanism which we drew our diagrams. But it doesn't have to be that way. Let's take another example: git.

Every GitHub pull request is an act of deterritorialization, and every merge is one of re-territorialization. Consider this small repository, with three commits:

You do a git clone:

Make a new commit, adding a new object into your repo-assemblage:

Then you send me an email, asking me to pull from your repository:

You like the change, so you do a git fetch:

de-territorialized!

Now it makes the local copy:

and your repository has been re-territorialized. These steps happen so quickly that you probably don't even think about them, but conceptually, this is what's happening.

A social example

One last example that's even less related to code: entering a new social group. You're at a conference, and there are four people standing around talking:

They form an assemblage we call a 'conversation.' It's in relation with an object known as “refinements” from Ruby 2.0, which means this assemblage is likely to be particularly vibrant. Heh. Anyway, you decide that your opinion matters, so you de-territorialize the assemblage, and (assuming they don't ignore you) it re-territorializes around you:

Even the language we use here implies something similar: you 'enter the conversation.' Like entering a door, into a space you previously were not.

Conclusion: Diagrams

We can call these drawings 'diagrams' or 'abstract machines.' They can represent these kinds of conceptual relationships in a visual way, which I find really useful for understanding. Programmers call abstract machines 'design patterns.'

Now that you've seen this process that assemblages use to relate to one another, I hope that you find this particular diagram useful. Because of its level of abstraction, it's applicable in a wide variety of situations.

Deleuze for Developers: Assemblages

If you truly want to understand technology today, then you should at least be familiar with the philosophy of Gilles Deleuze. Unfortunately for technologists, Deleuze is rooted firmly in a philosophical tradition and a writing style that they probably find opaque. In this blog series, I plan on explaining Deleuze's philosophy in terms that programmers can understand. This is the first in the series.

Enjoy.

The ancient Greeks thought that atoms were it. ἄτομος, Wikipedia will tell you, comes from 'ἀ'- meaning “not” and 'τέμνω', meaning 'I cut.' Cells are the smallest thing that there is. You can't cut them in half. Everything is composed of a bunch of atoms.

Well, guess what? Modern science has found things smaller than atoms. Dammit! What we do know for sure, though, is that some things are made up of composites of other things. That's for sure. We're still not clear on what that fundamental stuff is, but composites are a pretty safe bet. Even if atoms are made up of other things, we know that other things are made up of a bunch of atoms.

So how can we talk about composites? Well, a programmer's fundamental tool is abstraction. So we can black-box any particular composite and treat it as a whole entity, without worrying about what we've encapsulated inside. That's good, and that's useful, but there's a problem: when you start thinking of a collection of things as just one thing, you miss out on a lot of important details. As we know, all abstractions are leaky, so how does a black box leak?

Let's think about your body: it's a composite, you're made up of (among other things) a whole pile of organs, and one (skin) wrapping the rest of them up in a nice black box. If we had lived a few hundred years ago, thinking of the body as a black box would be a pretty fair metaphor: after all, if you take out someone's heart, they die. The box needs all of its parts inside. Today, though, that's not true: we can do heart transplants. Further, we have artificial hearts. A person with an artificial heart is not the exact same as a person without one, yet they are both still people. Thinking of a body as a totality leaks as an abstraction in modern times.

Let's move away from biology for a bit and into web applications instead. Here's an architecture diagram of a typical web service:

Looks pretty normal, right? Let's modify it a bit:

This is the same web service, right? We've introduced a few database slaves and a reverse proxy, which allowed us to knock out one of our application servers. In a certain sense, this service is equivalent; in another, it's different: It's got another extra component, and one component has developed more complexity. We might need to hire a DBA and someone who's good at writing Varnish configs. Different skills are needed.

So what do we call this thing? An 'assemblage.' It's made up of smaller assemblages as well; after all, our application servers may use the Reactor pattern, the worker model of Unicorn, or the threaded model of the JVM. To quote Levi Bryant, “Assemblages are composed of heterogeneous elements or objects that enter into relations with one another.” In the body metaphor, these are organs, and in the systems diagram, they're the application servers, databases, and job queues. Assemblages are also 'objects' in this context, so you can think of any of those objects as being made up of other ones. But to think of the formations of objects as a total whole or black box is incorrect, or at best, a leaky abstraction.

Let's get at one other excellent example of an assemblage: the internet. Computers connect, disconnect, reconnect. They may be here one moment, gone the next, or stay for an extended period of time. The internet isn't any less an internet when you close your laptop and remove it, nor when you add a new server onto your rack. Yet we still talk about it as though it were a whole. It's not, exactly: it's an assemblage.

Furthermore, there's a reason that Bryant uses the generic 'objects' or 'elements' when talking about assemblages: objects can be 'people' or 'ideas' as well as physical parts. This is where the 'systems' idea of computer science diverges from 'assemblage': depending on how you want to analyze things, your users may be part of an assemblage diagram as well.

So what's the point? Well, this is a basic term that can be used to think about problems. A design pattern of thought. A diagram. In future posts, I'll actually use this pattern to address a particular problem, but you need to understand the pattern before you can understand how it's used.

(and to give you a comparison of complexity of explanation, here's the blog post by Levi Bryant on assemblages where I got that quote from. He quotes Deleuze directly and extensively: http://larvalsubjects.wordpress.com/2009/10/08/deleuze-on-assemblages/ )

The next article in the series is on 'deterritorialization'.

Narratives

Occasionally in this big wide world, things happen. When things happen, we like to tell each other about it. When you take a bunch of connected events and tell someone about it, you've formed a narrative. Narratives are important, because they tell the story! The details of the account that one presents can really shape how others view those events later.

Due to our lived experiences, we often have our own 'internal narratives.' You can think of them as pre-packaged ways that we tend to think about a given series of events. Human brains are wonderful pattern-matching machines, and so we see similarities in situations, and then apply the same narrative.

Recently, I was playing around with Unicode and Ruby, and was trying to make some funny class names. I ended up figuring some stuff out, and tweeted this, which at the time of this writing, it has 157 retweets and 48 favorites:

This is valid Ruby:

class ಠ_ಠ
end

ಠ_ಠ.new

— Steve Klabnik (@steveklabnik) November 17, 2012

This tweet is factually incorrect. Yet, only two people pointed this out to me. Why?

Ruby is kind of a crazy language. That's what I love about it; it's got lots of wacky little corners, nooks, and crannies. I've also been doing Ruby for a long time, and tweet about it often. So here's the internal narrative when you see this tweet:

1. Steve knows a lot about Ruby.
2. Ruby is kinda weird.
3. That's really funny.

This particular situation fits perfectly into this internal narrative. Hence, a retweet. No checking. Just tweeting.

These narratives can play off of each other really easily. Now that we've seen one more way in which Ruby is kinda crazy, we assume that it's even more crazy in the future. This tweet has reinforced our internal narrative about Ruby's wackiness.

So #britruby.

I'm sure you're expecting me to say something specific about this situation, but I'm not going to give you what you want. What I do want to do is analyze the narrative of this situation, and see how it compares to actual events.

Josh Susser tweets this:

Nice speaker lineup for @britruby. Except for the 100% white guys part.

— Josh Susser (@joshsusser) November 17, 2012

and James Rosen tweets this:

By what metric is @britruby “one of Europe’s… most diverse Ruby conferences”? *Every* speaker is a white man.

— James A Rosen (@jamesarosen) November 17, 2012

That's it. If you examine those Twitter pages, you can see some conversation; both were conducted pretty cordially. Then, BritRuby decides to cancel their conference.

Okay. That's the situation. Now let's look at two versions of the narrative. First up, the cancellation announcement. I'm going to excerpt the most important parts, with my commentary afterwards.

We started this conference to build a community within the United Kingdom. Our mission statement was to encourage Ruby developers to unite and create a community, which would allow such to network, exchange ideas and provoke innovation for the future of Ruby. We wanted to encourage jobs and allow companies the opportunity to meet the community and primarily boost the UK developer industry.

We wanted to build a great conference that would help UK Rubyists tremendously.

Our selection process was the content and nothing more. Not the individuals gender, race, age or nationality.

This is trivially disproven, as everyone has biases. But the message is “We only accepted the best speakers, regardless of who they are.”

It’s about community. It’s about helping one another to strive for success and drive budding developers to do the same. We contacted universities in a hope that we would be able to empower young minds and show them what a great language Ruby really is. They are the future.

We are team players.

The Ruby community has been battling with issues of race and gender equality. We at Brit Ruby were well aware of this fundamental and important issue. This was one of the reasons why we encouraged everyone to submit a speaker proposal. Sadly, BritRuby was used as the arena to air these issues on Twitter and this has fundamentally destroyed any chance we had of addressing these issues.

BritRuby was 'used to air these issues,' meaning, 'others had an agenda and took advantage of us to promote it.'

Instead the community should have worked together and allowed us to bring these issues to light at the conference.

These individuals are divisive, and we are inclusive.

How can the community address these issues if every time someone tries they are shot down and accused of such awful things?

The British Ruby team although very small consisted of a diverse mix of nationality and gender.

We cannot be tainted by accusations of monoculture, as we are diverse ourselves.

This was a non-profit conference being run by simple developers.

We were not even trying to make money.

The team has been working so hard in their own time to bring a unique conference to you all. Thank you to those of you that dedicated your time, skills and to their families for putting up with the long hours.

We, nay, you and us together all worked really hard, so you should cut us some slack.

Anyway, so there you go. Same events, different story: We are a collective that was trying to do our best. Outsiders took advantage of us to promote their agenda and divide all of us. Therefore, we're taking our ball and going home.

Here's the funniest thing about the cancellation: They don't give an actual reason. The closest they get is 'was used as an arena to air these issues' but they don't explain why that made them cancel their conference. This narrative attempts to shift the blame from the organizers to the critics. “We wanted to give you this beautiful thing, and we worked hard, but these other people ruined it.”

This particular narrative plays off of a well-known trope when discussing diversity issues: a persecution complex by the majority. Majorities fear losing their power, and often will develop internal narratives that they're the ones being persecuted. Some good examples of this are the Mens Rights movement and the White Power movement. This is a milder form of that same privilege: the power of a single tweet by the 'politically correct' is enough to bring the most powerful of plans grinding to a halt.

Let's examine a few narratives involved in this gist:

And here it is, brought down by careless words.

“These people don't actually care about us or our conference.”

Yes, gender equality and racial equality are important. But the team's motives were to get the best speakers who were able to make it to Manchester.

First of all, “but” is an amazing word. You can't even imagine the things I've heard said after “I'm not racist, but.” This sentence implies two things: an absolution from blame on the part of the conference because hey, they care about equality. Their second statement implies that the best speakers all happened to be white men. The converse of this is that non-whites and/or women are not the best speakers, and the overall message is that including them would degrade the quality of the conference.

Adding a token minority speaker is offensive to that speaker, it says “You're here because you tick a box - not because you're skilled.”

Anyone who seeks out women or minorities is only doing it to 'tick boxes,' because, as we've already established, they clearly are not the best speakers.

Oh, and you're actually the sexist/racist one if you try to encourage them, because it's patronizing.

It doesn't matter who speaks at a conference, as long as they're capable, interesting and relevant. That's what matters: content, not style.

We cannot be at fault because we don't see race or gender. Again, basic psychology trivially disproves this statement.

There are a ton of other micro-narratives that occur in all of these discussions as well. Most of these are a derailing tactic, and straight-up distract from the issue. “Egalitarianism is anti-free speech,” “Feminists and their allies are irrational and hysterical,” “I don't see race or gender,” “If they were calmer about this, it would have worked out,” “This would be better handled in private,” and many, many more. I've seen so many. It's exhausting. These internal narratives get reinforced by a particular interpretation of a given situation, without examining what actually happened.

Yet we still have conferences that are mostly full of white dudes.

I lost a lot of respect for a lot of people today.

Theory and Practice

There is always a tension between Theory and Practice. These two separate realms are connected through a process of abstraction and application. To explain this relationship by way of theory, Theory deterritorializes Practice, and Practice reterritorializes Theory: a Theory which is a becoming-Practice and a Practice which is a becoming-Theory. To explain this relationship by way of practice, Theory is abstracted Practice, and Practice is applied Theory.

There's an age-old problem with this particular relationship: those who specialize in Practice often claim that those who specialize in Theory are detached from the 'real world,' ie, the world of Practice. Those who specialize in Theory often claim that those who specialize in Practice have no fundamental understanding of what they do, and this leads to contradictory, incongruous practices.

There's a third kind of person, though: one that embodies the becoming, the abstraction/application process. These people are a conduit, fundamentally bridging the two worlds. There's a certain art to explaining just the core of Theory in the words of someone who Practices, and there's a certain art to combining the essences of Practices and presenting it to those who Theorize. Building this bridge is an act of creation, of building, an opening of space.

Some people are great at Ivory Tower intellectual stuff, and others just don't really care. It sucks, because those who are doing could be way better at it if they just knew some theory, and those who love to philosophize all day might be more understandable if they'd just actually do something sometimes.

The only way you can get these two camps to talk to each other is to figure out what the theory says that provides value to those who practice. Practice-ers are ruthlessly focused on value, so to get through to them, you have to speak their language. On the flip side, theorists understand that practicers don't care too much about the theory, but love seeing their thoughts to go good use, and can appreciate when practicers stumble across flaws in their thought. So demonstrating how practicers produce contradictions in the theory can be really useful to theorists.

If you're this kind of person, accept that you're in many ways a jack of all trades, but a master of none. Of sorts, anyway. Theorists will sometimes hate you for not grokking every last detail and reference, and practical people will argue that you don't do enough useful things. Don't listen to either of them; you know that you're part of neither camp, so it makes sense that they both find 'flaws.' You're awesome because you know a bit of both, and can facilitate communication which makes both better. A force multiplier.

You have to remember that while you're building things, there's an underlying set of rules that you're implicitly following, but it's more important to act than it is to memorize a bunch of rules, and try to analyze what you're doing according to them. If all you do is think all day, you'll never get anything done. Things may go wrong, but you can always fix it later. Other people can sit around and theorize about what you're doing, leave them to it.

Mental masturbation is fun and all, but when all is said and done, developing a culture of shipping is one of the most important things you can do. Those who can't do, teach. History is written by the victors.

On occasion, you'll run into someone who can actually explain complicated theory stuff to you in an accessible way. If you find someone like this, make sure to hold onto them closely, as they're really rare. But they can help provide you with some insight that will really boost your productivity, without having to invest all the time in figuring out all that wankery that the priests of theory love.

“In theory, there is no difference between theory and practice. But, in practice, there is.” - Yogi Berra

I got hit by a car today.

“Humans are really squishy, messy, complicated, and contradictory. That's what makes life interesting.”

Veggie Grill is damn delicious, but it's hard to talk and eat at the same time. I'm usually trying to shovel my Santa Fe Chickin' sandwich into my face as hard as possible. Today, though, there was a screw-up, and I didn't get my food for a while. So I talked instead.

“Do you know anything about Hegelian dialectics?”

My friends are the best. Most people don't put up with rambling, half-formed ideas, but mine generally entertain them, even though they haven't read the books I'm talking about. I'm really grateful for this, as describing things really helps me sort them out in my head. The blank look and continued chewing meant that this was once again one of those times. Whatever.

“Basically, dialectics are a method of finding the truth in a threefold process: First, a 'thesis' is presented, which makes some sort of statement about the world. Then, the 'antithesis' contradicts it in some fashion. Finally, a 'synthesis' is found which resolves the tension between the two opposing sides. It's a really interesting way of looking at the world; I've found it's way easier to find things that totally contradict each other than I thought. Synthesis is really hard, though. Think about a trial, for example: the story of the plaintiff is told, then the story of the defendant, then the jury figures out what actually happened. There's three sides to every story.”

Last week, I flipped over the handlebars of a bike. I was pumping as hard as I could, trying to make the light before it turned red, and the chain couldn't take the tension any longer. It popped off, went between the back wheel and the frame, and stopped it cold. A few seconds later my eyebrows were scraping across the pavement. Lots of blood, but no serious injuries. I'm going to have a few sweet scars, though…

“Anyway, we were talking about feelings and ways people act before, but it's true of physical bodies as well. Sometimes, accidents happen, and before you can even react, you're dead. Other times, you escape with very little damage. We're simultaneously incredibly vulnerable and almost impervious. Some people get in a bike accident and their life is forever changed. Other times, like me last week, you get away with a few scrapes. Once I fell about 8 feet onto my knees. Landed right on some pavement. I walked away 5 minutes later, didn't even have bruises. I still have no idea what the fuck happened there.

I still haven't found the synthesis yet.”

After lunch, it's time to bike home. It's about 15 miles, which I can do pretty much at the drop of a hat nowadays. I really enjoy biking up Santa Monica Boulevard, but I hate it, too. It's nice and broad, with two lanes, a bunch of green in the middle, and some bike lanes. Of course, it isn't all like this, but much of it is. Especially on a day like today, around noon, it's really pretty in places.

So I'm about 8 miles into my trip, and the next thing I know, I'm on the ground. Here's the basic problem:

Yeah. Bike lanes don't help if someone wants to turn right. When alongside cars, it's very, very important to keep alert for two things: Open doors from parked cars, and drivers who don't use their turn signals. A few weeks ago, I almost got hit by someone in this same exact way, just a few blocks down the street. I was paying close attention, and actually guessed that they were going to turn before they did. Free driver psychoanalysis done here! But more seriously, this was in the middle of the block. This guy saw that there was a space at this parking garage, hit his breaks and turned right without looking.

“YOU STUPID MOTHERFUCKER! WATCH WHERE THE FUCK YOU'RE GOING, YOU'RE GOING TO FUCKING KILL SOMEONE! JESUS!”

I ran a systems diagnostic check, and I was good, but enraged. Some pedestrians were screaming, and one ran over and asked if I was okay. “I said, yes, thank you, at least until this guy fucking kills me or someone else,” got back on my bike, and drove off.

At least my handlebars gave him a big long scratch the whole way up his car. Fucker.

There's also something else interesting in this story as well: Generally, in a car/human interaction, I am the squishy one, and the car is the tank. Yet, in this particular interaction, I basically escaped unscathed, while the car took some damage. Once again, life is surprising, producing an inversion of the expected circumstances.

Anyway, if you drive a car, please, please, please watch what you're doing. Pedestrians and cyclists don't have thousands of pounds of metal surrounding them. Cyclists, please stay safe; it's a jungle out there.

Ultimately, life is made out of these little incidents. Each moment to the next, you have no idea what's going to happen. It's exciting, scary, and sloppy. But that's what makes it interesting. And you also don't know when it's going to end.

I still haven't found that synthesis…

Living with a terrible taste in music

Music has always been very important to me. Throughout most of my life, I've listened to a lot of music, and it's played a huge role in defining my personality at the time I listened to it. In many ways, the history of the music I've listened to is a history of me.

Here's a look at where I've been, and where I'm at now.

Country

My parents essentially listen exclusively to country music, and so it's basically all I listened to for the first decade of my life. And when I say country, I don't mean old stuff, I mean proto-pop country:

Many, many people that I know now are quite surprised by this. Country is one of those genres that brings out a certain revulsion in people. It still comes up from time to time, and my understanding of country brings out a laugh. Once in college, I was in a friend's hometown, the Middle of Nowhere, PA. His brother rolls up in his huge pickup truck, blasting some George Straight. My friend looks at me, and rolls his eyes. With a straight face, I start saying the words as George sings them. The look of shock and confusion on his face was priceless.

In many ways, that's exactly who I was destined to be: just a country boy gettin' down on the farm.

But then, I discovered skateboarding, and punk rock.

Punk

Of course, it wasn't even good punk music, either. See, I had always thought skateboarding was neat, but wasn't never had one because there was nowhere to ride it. I lived on a farm, we didn't have any pavement anywhere. So I forgot about skating. But then I got a call from a friend, he'd just gotten a new video game:

Here's the soundtrack list:

• “Police Truck” by the Dead Kennedys
• “Here and Now” by The Ernies
• “Vilified” by Even Rude
• “Superman” by Goldfinger
• “Jerry Was a Race Car Driver” by Primus
• “Screamer”/“Nothing to Me” by Speedealer
• “Cyco Vision” by Suicidal Tendencies
• “New Girl” by The Suicide Machines
• “Committed” by Unsane
• “Euro-Barge” by The Vandals

Pretty awesome. He also had this new album that came out at the same time…

From there, it was all over. All this edginess combined with my (just budding, of course) testosterone meant I was pretty much set. The funniest part about this period of my life was that I actually wasn't really a particularly rebellious child: I maintained pretty damn good grades, save for a few semesters, I still went to church, and I was generally a good kid. I didn't even smoke pot! Yet even the act of possessing these albums was heinously offensive. I got grounded for half a year for possessing Blink182's “Take off your Pants and Jacket” and Limp Bizkit's “Three Dollar Bill, Y'all$.” This constant conflict over music with my parents dominates my memories at the time. I literally printed out all the lyrics and wrote two pages explaining why I should be allowed to own a copy of the Offspring's “Americana” even though they said 'shit' a few times. Punk, even third generation pop-punk, really spoke to my desire for autonomy and my attempts to be my own person.

Metal

Of course, slippery slopes are everywhere, and so I started searching for harder and harder music. Always the min/maxer, I looked for loopholes in my parent's rules. The biggest hole: anything from the Christian Family Bookstore was fair game. So I scoured it for anything awesome. That's when I found Zao:

Screw punk, metal was way more awesome. I grew my hair out long and learned to headbang.

I don't think I need to explain to you why metal is ridiculous. I mean, come on:

Hardcore

Of course, there has to be a way to reconcile all this, right? Take two steps forward, one step back? Well, that's hardcore.

My fascination with hardcore in late high school and early college was two-fold, like 'hardcore' itself: there's 'hardcore' and then there's 'hardcore punk.' Hardcore punk is a specific sub-genre of punk rock from the 80s, and hardcore is its continuation in the modern day, after that whole emo thing happened.

To recap: hardcore punk:

hardcore:

Uuhhh yeah. Hardcore punk also brought me to straightedge, which leads to silliness like this:

To this day, I still don't regret this tattoo, and anyone that's seen me at a Ruby conference knows that I'm not straightedge anymore. But this music and philosophy defined who I was for about 8 years, which was, at the end of it, about a third of my life. It changed my college experience. I'm (basically) permanently marked by it.

But no, seriously:

Party Rock

Anyway, so nowadays, this is what I listen to:

Here's the thing: once I finally admitted to myself that I enjoy terrible pop music and stopped trying to apologize for my taste, I realized I was way more productive. Upbeat music with a vaguely positive vibe means I get shit done. Way better than the heavy, dreary, angry stuff I listened to in the past. I listen to hours of music a day, and I'd much rather have it be happy…

But that's when I realized I've basically always had bad taste in music.

The thing is, that's totally okay! Music has always provided an interesting backdrop for the rest of my life, and it's fit whatever moment I was living. Writing this post was a blast, because I'd forgotten about half of this stuff, and re-living it is a good time. I can remember debating my friends about the Casualties being street punk or hardcore, if some band had really sold out, or if straightedge still matters now that Ian MacKaye smokes pot.

I wonder what I'll be listening to in five years.

How do you find the time?

I'm often asked the question, “How do you find the time?” Mostly, it's around open source, sometimes it's about books, and occasionally, on other things. I've generally deflected the question with something like “I don't know, man, I just do it.” But that answer isn't very helpful. And I've been wondering if I can do even better. So I've done some reflection this week, and here's how I find the time:

Min/max

I have this personality type that is an asset to any competitive gamer: Dungeons and Dragons nerds call it “min/maxing”. The basic idea is this: you try to minimize the things that are bad, and maximize those that are good. This sounds super obvious, but there are many times when maximizing 'winning' isn't what you're going for. One great example is 'pretending to be a fantasy adventurer.' If you're not shooting for strictly winning, then min/maxing doesn't make any sense. But if you're looking to compete, it's incredibly important.

Speaking of competition, you should really read this book:

“Playing to Win” is an excellent book by one of the best Street Fighter players in the world. It is a must-read for anyone who wishes to compete in any way.

In it, he develops the theory of “Players” and “Scrubs”:

A scrub is a player who is handicapped by self-imposed rules that the game knows nothing about.

A great tell of someone being a scrub is when they mention 'fairness.' A game is an impartial, closed system. There are rules to the system that constrains the players. Simply, the more rules, the harder it is for you to achieve your win condition. If you invent extra rules, you handicap yourself. Games are not 'fair.' Players don't handicap themselves in this way:

A player should use any tournament legal move available to him that maximizes his chances of winning the game.

If a move is legal, then it's fair game. Good games are written in such a way that bad moves don't exist. Use all the tools at your disposal, and use them ruthlessly.

Here's the thing about the scrub mindset: it's easy to do accidentally. Extra rules can be self-imposed, but they can also happen due to a poor analysis of what the rules actually are. For example, the biggest time I scrubbed out in my entire life was a choice that I made almost a decade ago: going to college. Every adult in my life told me that going to college was a good idea. They all said it was needed to get a job as a programmer. I didn't bother to challenge them, and went along with it. Now I have a useless piece of paper and $70,000 in debt. College wasn't all bad, but it certainly wasn't worth the debt. I cherish the friendships I made, but not much else. This mistake was made because of my apathy towards the systems governing my life, and it's one I try not to repeat.

Anyway, these two principles are the backdrop for everything else: properly analyze your situation, maximize the outcomes you want, and minimize the ones you don't.

Work

“So what do you want out of life, Steve?”

“I want to teach, I want to work on open source, and I want to travel.”

“I think we can work something out.”

If you work a 9-5 job, you spend 40 hours a week at work. Let's add a one hour commute in there too, which puts you up to 50 hours. And as Ruby will tell you…

1.9.3-p194 :001 > 24 * 7
 => 168 
1.9.3-p194 :002 > 50 / 168.0
 => 0.297619047619048 

30% of your life. Let's analyze this like a pro gamer, shall we? Here's the situation we're trying to maximize: “I want to live a full life.” In order to maximize this, we need to discover the constraints. The biggest one, of course, is your time on this Earth. For now, at least, we all will die someday. The primary resource that we all have to work with is time. You should guard your time more closely than any other thing you have. You can't ever get it back. Every single thing you do consumes this most precious of resources.

When you enter into an employment agreement, you are literally selling your most precious thing in order to acquire other resources. Don't forget that.

So, 9-5 job. 30% of your life. Is it worth it? Maybe! I can't tell you. But in order to maximize your outcomes, you need proper analysis. Employment is a tricky thing, in that regard. Capitalism forces us to interact with the market in order to gain our subsistence, so we have to enter into this transaction somehow. What to do?

Quick, startup crowd: what's the first rule of pricing? If you say “do it value-based, not cost-based,” then you win a patio11 sticker. You'll never get anywhere selling yourself on an hourly basis, you have to sell yourself on value. That's another topic for another time. Point is, don't just assume the rules: truly analyze your situation.

Anyway, that's neither here nor there. On a day-to-day basis, the only reason that I can do what I do is because Jeff is a stand-up guy, and working with Jumpstart Lab is awesome. We do the best Ruby and Rails classes in the world, and I mean that. I don't want to get into the details of my employment, but basically, teaching classes, contributing to open source, and speaking at conferences are all part of my job. You can see how that directly maps to my statement above.

So, if you appreciate

• My work on Hackety Hack
• My contributions to Rails
• My contributions to Resque
• My public speaking
• All the other Open Source work that I do
• My advocate work for feminism and social justice

then you should consider hiring us over at Jumpstart. If I had to do normal consulting to pay my bills, I would have much less time for all of this stuff.

But I don't work at Jumpstart!

So, you're not me. You work a 9-5 job. So you're screwed, right?

No way! Analyze your situation. Figure out how to maximize it. Before I did software development, I did this. About 30 hours a week while at high school, and 40 hours a week through college. I still managed to put in open source time. How?

The thing is, working on open source is something I truly love to do. For me, it's not 'work.' That does not mean that it's always roses. Sometimes it's hard. Sometimes, it really, really sucks. Hard. However, I truly love it, so I stick it out through the hard times, and it ends up being good again. Once, I suffered a really bad break-up. My mom told me this maxim that her grandmother always told her:

What bone you were meant to have, no dog will drag away.

Grandmas. They're so opaque! The point is, contributions to Open Source is something that's a part of me, no matter what. So I'll always find a way to do it. I don't give up on it easily. When I first took over Shoes, it took me six months to figure out how to compile it. Six months. No compilation. That sucked. But I stuck it out.

Eighty percent of success is showing up.

• Woody Allen

Relationships

Having a full life means interacting with other people. Don't let some productivity fetish negatively affect relationships. I mean that in a broad sense, both romantic and bromantic. ;) Make time for stuff that's not 'ZOMG MUST GET WORK DONE' in your schedule too. I make sure to talk to significant others at least once or twice a day, for example. Assuming they want me to. Tonight, I'm gonna go for a bike ride on the beach. I still play StarCraft from time to time. Every Saturday, my friends and I used to get together in the computer lab and hack.

If you spend all of your time working, and none of your life living, you've failed at life. Open source is fun, but go outside, dammit. Or read a book. Or something. But if you only program computers, you've failed at being a human.

Music

Listen to awesome music while you work. I first discovered this while mowing my parent's' lawn: when I listened to Metallica, that grass got cut way quicker. So, while I work, I listen to shitty pop music. Here's my Pandora station. I find that upbeat, happy music makes me upbeat and happy. I'm over being embarrassed about my love for Ke$ha. I just bob my head and write more code.

Parallelize

I actually cannot be productive without doing six different things at once. This is related to “Structured Procrastination”. I do a little bit of work on a bunch of different things, and cycle between them quickly. One day, it's Rails, another, it's Resque, another is training, then back to Rails, then Hackety…

lift.do

I've been trying out Lift lately, and I really like it. You can build habits with some light social interaction. You might find it useful.

Cut distractions.

That's a bunch of things I do to maximize good outcomes, but what about minimizing bad ones? In the interest of minimalization, I won't dwell on them too much, but here are some things that I've cut down or cut out in some way:

• TV
• Reddit/HN
• Cell phones
• Video Games

I still indulge in some of these from time to time, but I've cut them out of the 'every day' loop. My life is better off for it. Figure out what you don't actually need, and stop it.

;)

Software and Community

“Are you sure you're not vegan? You look like a vegan.”

Chad Fowler made me laugh pretty hard that day. We were in Austin, at a Ruby conference, and getting some very non-vegan food at the excellent Iron Works BBQ. I had only talked to Chad a few times before, and while chowing down on some excellent ribs, we talked about something that we'd discussed in a previous conversation: “the Ruby community.”

I gave a talk at Lone Star Ruby last year about my involvement with Hackety Hack and Shoes, and at the end, discussed some social issues I thought Ruby has:

The fun starts at 27:49. But ultimately, this whole section relies on the idea that in Ruby, we have a cohesive 'community' of people. After I gave my talk, Chad mentioned to me that he didn't like the idea of “the Ruby community.” At the time, I was so starstruck that I said something like “sure, okay, I'll think about that,” not even realizing the irony. So, while trying valiantly to eat barbecue in a not completely messy way, I asked Chad more about his thoughts on this.

If you were wondering, if it's good barbecue, it's impossible to eat it neatly.

I don't remember his exact words, but Chad's point was that if we talk about Ruby like a big cohesive group, we forget about all the people who use it who don't post on blogs, or Twitter, or contribute to GitHub. Those people are people too, but they're effectively outside 'the community,' either by choice or by ignorance.

Kill Your Idols

It seems to me that much of software is driven by fashion, celebrity, and superstition. This shouldn't surprise anyone who's not a software developer, as programmers are just people, and much of the human world is driven by fashion, celebrity, and superstition. Programmers, though, regard themselves as bastions of rationality.

I don’t argue about sports, it’s stupid. I prefer to argue about important things, like whether or not to use semicolons in JavaScript.

— Matthew Nielsen (@xunker) September 15, 2012

Right? This whole idea makes us, or at least me, very uncomfortable. I'm a scientist, dammit! I measure twice, cut once. I use the right tool for the job. I swear, MongoDB, CoffeeScript, and Ember.js fits my use case perfectly!

Ideally, we'd make technical decisions on technical means only. However, we're just humans. I'm not sure it's possible to divorce our decision making from our squishy human tendencies, and after typing that sentence, I'm no longer sure that it's a good idea, either.

Leaders vs. Bosses

Does it follow that I reject all authority? Far from me such a thought. In the matter of boots, I refer to the authority of the bootmaker; concerning houses, canals, or railroads, I consult that of the architect or the engineer. For such or such special knowledge I apply to such or such a savant. But I allow neither the bootmaker nor the architect nor the savant to impose his authority upon me. I listen to them freely and with all the respect merited by their intelligence, their character, their knowledge, reserving always my incontestable right of criticism and censure. I do not content myself with consulting a single authority in any special branch; I consult several; I compare their opinions, and choose that which seems to me the soundest. But I recognise no infallible authority, even in special questions; consequently, whatever respect I may have for the honesty and the sincerity of such or such an individual, I have no absolute faith in any person. Such a faith would be fatal to my reason, to my liberty, and even to the success of my undertakings; it would immediately transform me into a stupid slave, an instrument of the will and interests of others.

• Mikhail Bakunin, “What is Authority,” 1882

There is a difference between a leader and a boss. There's also a difference between a leader and a celebrity. What I'm concerned with is that we occasionally turn leaders into bosses, and we turn celebrities into leaders.

One other Ruby person that straddles this line is Aaron “Tenderlove” Patterson. He is, for good reason, almost universally beloved by Rubyists. He's known to all for two different reasons: as a leader, and as a celebrity. Aaron is the only person on both the core Ruby as well as core Rails teams. He is one of the most technically brilliant people I know.

He also posts amazing pictures of his cat on Tumblr. (The caption is “My new Yoga outfit.”)

Another amazingly technical thing Aaron has done is re-writing the AST -> SQL generation stuff in ActiveRecord, which sped up ActiveRecord by 5x. He deserves every single last bit of his popularity, on both sides. I happen to find the split reasons interesting.

“The community” as useful abstraction

While I think 'the community' may help drive a celebrity culture over a culture of leadership, there's no denying that we do, in fact, have a community. If I had a nickel for every time someone in Ruby did something nice for me just because, I'd have a lot of nickels. I'm writing this post from the couch of a Rubyist who happened to be on the same plane as me to Helsinki, and rather than stay at the airport for 10 hours overnight (checkin isn't for another few hours yet), I crashed here. On my last trip to Germany, Konstantin and Josh from Travis not only gave me their couches to sleep on, but bought me food when I fucked up my debit card situation. One Saturday, Luis Lavena spent 8 hours on a Saturday randomly pairing with me on some Ruby on Windows stuff, and left with an “I'm sorry, but my fiance is bugging me, I told her we'd get dinner an hour ago, I need to leave.” That's crazy, I'm some dude from another hemisphere, hang out with your fiance! Aaron helped me debug an issue in Rails the other day, even though I kept asking him stupid questions. I have tons of stories like this, and so do many other people who participate in open source.

In “Debt: The first 5,000 Years,” Graeber defines “everyday communism” as “any community who follows the maxim 'from each according to their abilities, to each according to their needs.” Of course, communism and community share a root for a reason, and all of these examples above are great descriptions of 'everyday communism.' Not every exchange must go through some sort of monetary exchange. It's often simpler to just do each other favors, and know that it will all work out in the end. That's the basis of a gift economy.

In this way, I think community is a useful abstraction; we just need to make sure that we don't get too caught up in ourselves. Focus on the friendships, helping each other out, and writing great software. Try not to get too trendy. Pay attention to what matters.

In the end, I wouldn't give up the real friendships I've made via the Ruby community for the world.

Protocol and Language

This is the second part of my series on protocol. The first part contained a lot of background information, but now we're ready to get into what Protocol actually is.

I live in a pretty unique place, the Farmhouse. It's a psuedo-public space in which we live, others work, and everybody has a good time. We do have some rules, though:

They're written up on the wall in chalk. Since we have lots of visitors to the house, and these are hard and fast rules, it's important that we communicate them in a clear way. These rules form the protocol of our house. Phrased another way, they're the rules that govern the way that we interact with each other and the house itself while at the house.

Ultimately, this is what protocol is: a language. To Galloway, protocol is a very specific kind of language:

Protocol is a language that regulates flow, directs netspace, codes relationships, and connects life-forms.

Some of these properties are contradictory. Stated more accurately, there exists a tension between opposing forces within protocol itself. Let's expand on these meanings.

'regulates flow'

If you've ever read 1984, you're familiar with linguistic relativity, more commonly known as the Sapir-Whorf hypothesis.

How could you have a slogan like “freedom is slavery” when the concept of freedom has been abolished?

What's truly interesting is that Orwell himself actually advocated for simplifying language in Politics and the English Language, but specifically because he felt more complicated language was obfuscatory, not illuminating.

In any case, language enumerates the possible, and while some languages can have really long words, ultimately, any language will have some things that are not expressible. This often happens with translations.

If you are the proud recipient of a computer science degree, you may have run into the Chomsky hierarchy in your compilers class. If you weren't required to take a compilers class, please call up your alma mater and demand a refund. Here is the hierarchy:

1. unrestricted grammars
2. context-sensitive grammars
3. context-free grammars
4. regular grammars

As you go up the hierarchy, each language type is enclosed by the type above it. All context-sensitive grammars are unrestricted grammars, and all context-free grammars are context-sensitive.

Regular expressions are one area where a language was forced to move up the hierarchy in order to express more things. Strictly speaking, a regular expression cannot match nested parenthesis. If you are interested in the math, the Pumping Lemma demonstrates why. However, this kind of thing is useful, and so extensions were developed that move them up the chain. Now you can write this:

qr/(<(?:[^{<>]++|(?1))*>)/}

Maybe Orwell was on to something.

Others have speculated that linguistic relativity would also apply to software. Two notable examples are Kenneth E. Iverson, who created APL, and Paul Graham, Lisp enthusiast and investor extraordinaire. Iverson wrote a paper titled “Notation as a tool of thought”, which begins:

The importance of nomenclature, notation, and language as tools of thought has long been recognized.

Graham authored an essay called “Beating the Averages” in which describes the 'Blub paradox'. The paradox relies on linguistic relativity:

You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

I don't mean to rain on the relativity parade, but there's one small detail that we haven't considered: Turing completeness. At the end of the day, most programming languages are Turing complete. This means that COBOL can do everything Lisp can, and PHP can do everything that Ruby can.

So are Graham and Iverson wrong?

Turns out there are two variations of linguistic relativity: strong relativity states that language determines thought, and weak relativity that states language influences thought. This was coined later, as it would seem that current research has found little evidence to support strong relativity, but some to support the notion of weak relativity. Graham notes this, and confines the paradox to the realm of weak:

All languages are equally powerful in the sense of being Turing equivalent, but that's not the sense of the word programmers care about. (No one wants to program a Turing machine.)

To put it another way, language features create friction that encourages or discourages certain modes of thinking.

Python and Ruby are two very similar languages, yet they engender very different styles. One area in which this division is sharp is first-class functions. Both languages have them, but Python's are simply expressions rather than fully-featured . Guido van Rossum likes them this way:

But such solutions often lack “Pythonicity” – that elusive trait of a good Python feature. It's impossible to express Pythonicity as a hard constraint. Even the Zen of Python doesn't translate into a simple test of Pythonicity.

Guido specifically wants to limit the scope of language in order to encourage a particular style of thinking about problems: a Pythonic one.

Galloway is very explicit about this regulation.

Protocol is synonymous with possibility. From the perspective of protocol, if you can do it, it can't be bad, because if it were bad, then it would have been outlawed years ago by protocol.

'directs netspace'

After that massive first part, I'm basically going to punt on the second. I don't find it very interesting or worth elaborating on: languages and protocols direct the direction of the Internet. I don't think anyone disputes this.

'codes relationships'

Communication has an intimate connection to relationships. The act of communicating is what creates the relationship in the first place. And language is the encoding of that particular relationship.

In “A user's guide to Capitalism and Schizophrenia: Deviations from Deleuze and Guattari,” Brian Massumi discusses an example of marriage vows:

A particular man and a particular woman say “I do.” Their words undoubtedly have personal meaning for them in their heart of hearts. But their personal intention is not in itself responsible for the magical transformation that has touched their lives. What has brought them to say these words and what makes those words effectively transformative is too big to fit into a single mid. It is a complex interplay of laws, customs, social pressure, and tax law.

Marriage is a social protocol that encodes a particular relationship. Once that relationship has been encoded, it's made legible to others who weren't privy to the details of that relationship. A wedding ring is only one form of relationship encoding; a couple holding hands is a similar example, whose bond is weaker both in symbol as well as in reality.

In the software world, HTTP encodes relationships as well. The client/server relationship is integral to the protocol's design, as Roy Fielding describes in section 3 of his dissertation:

A client is a triggering process; a server is a reactive process. Clients make requests that trigger reactions from servers. Thus, a client initiates activity at times of its choosing; it often then delays until its request has been serviced. On the other hand, a server waits for requests to be made and then reacts to them. A server is usually a non-terminating process and often provides service to more than one client.

He further goes on to describe why this relationship is important:

Separation of concerns is the principle behind the client-server constraints. A proper separation of functionality should simplify the server component in order to improve scalability. This simplification usually takes the form of moving all of the user interface functionality into the client component. The separation also allows the two types of components to evolve independently, provided that the interface doesn't change.

In other words, the protocol encodes the relationship so that others know what a client should do, and what a server should do.

If you remember our good friend Saussure, you'll remember that he made this encoding explicit, and in fact central to language itself. While Saussure's work isn't directly useful to linguists in the present, much of his work is foundational to the ways that we approach language today.

One of the most fundamental concepts in structural linguistics is the 'sign,' and its component parts, the 'signifier' and the 'signified.' The signified is a particular concept, and the signifier is the way the signified is expressed. A sign is a combination of a signifier and a signified. Seems pretty simple, but Saussure also posited that a sign can only gain meaning and value within their relationship to other signs, which means that you cannot consider an idea outside of the way in which the idea is expressed.

The study of signs is called semiotics. In Semiotics, a particular set of conventions used to convey meaning are called codes. Hence 'encoding' can also refer to this kind of code, as well.

Hence, if we combine Fielding, Galloway, and Saussure, the word 'client' is a signifier that holds a relationship to the signified concept 'a triggering process' (among other things), that forms the sign 'client.' This is encoded by the protocol HTTP.

'connects life-forms'

From the Massumi marriage example:

Say “I do,” and your life will never be the same. Your legal, social, and familial status instantly changes, along with your entire sexual, psychological, and financial economy. You have been pronounced man and wife. You may file a joint tax return.

This connection is related to the previous coded relationship. In this case, 'connects' is an active verb rather than a passive noun. It not only creates a connection, but it 'connects'. It not only relates two objects, it is the relation.

We spent most of the last section discussing connections, though, so let's get to the interesting part: life. Galloway is very explicit about the role protocol plays with life:

…protocol is an affective, aesthetic force that has control over “life itself.”

In the Exploit, Galloway discusses the relationship between life and protocol as well:

While the first type of network (Internet protocols) is silicon based and may use biological concepts (intelligent agents, artificial life, genetic algorithms), the second (DNA algorithms) is fully biological and yet recodes itself in computational terms (biology as computation, as opposed to evolution)

The relationship between life and software is an interesting one.

In Conway's game of life, one builds cellular automata and lets them go. There are a few simple rules that govern their reproduction, death, and life. This protocol governs all that happens within the game. Someone playing the game is an impotent god, as there is no room in the protocol for communicating with creations. Likewise, creations have no way of perceiving an 'outside' of the game.

Galloway references this quote by Frederick Cohen from A Short Course on Computer Viruses:

I personally believe that reproducing programs are living beings in the information environment.

Viruses, Conway cells, Sims, and all other kinds of 'artificial life' exist inside of computers. They're native to protocol. But what about actual, real life?

Galloway reaches to Norbert Wiener, a mathematician who was the originator of cybernetics, for this:

if one views the world in terms of information, then there is little instrumental difference between man and machine since both are able to affect dynamic systems via feedback loops. In this way the cybernetic system of man and machine are born. Its virtues are balance, self-regulation, circularity, and control. In a word, protocol.

Deleuze also forms a connection between life and information in “Postscript on the Societies of Control”:

The numerical language of control is made of codes that mark access to information, or reject it. We no longer find ourselves dealing with the mass/individual pair. Individuals have become “dividuals,” and masses, samples, data, markets, or “banks.”

A dividual is a play on the process of individuation. Galloway elaborates:

Deleuze's neologism comes from the word 'individuate.' Dividuation would thus be the opposite: the dissolving of the individual entity into distributed networks of information.

Let's use a personal example to demonstrate life submitting itself to dividuation in order to interface with protocol: me. This is my personal website. In it, my public face on the Internet, I've split myself up into five broad categories, and link out to all of the various sub-components. Examining the last category, you can see how if you just follow me on twitter ;), you will not get the whole picture. You could also check out my code on GitHub, but that wouldn't be me, either. Even the sum of these two components would not tell you everything about me. Yet I can't possibly put me on the network. I must break 'me' into a form that conforms with protocol.

Finally, there's an important relationship with Foucault's concept of 'biopolitics.'

Foucault defines biopolitics as “the endeavor, begun in the eighteenth century, to rationalize the problems presented to governmental practice by the phenomena characteristic of a group of living human beings constituted as a population: health, sanitation, birthrate, longevity, race.”

Obviously, dividuating a population into informational components would be relevant to protocol. And, in fact, life provides a path to resist protocol. Deleuze in his book Foucault (because that's not confusing…):

When power becomes bio-power resistance becomes the power of life, a vital power that cannot be confined within species, environment or the paths of a particular diagram.

Galloway expands:

Is life resistance a way of engaging with distributed forms of protological management? Part III of this book, “Protocol Futures,” answers yes. While the new networked technologies have forced an ever more reticent public to adapt to the control structures of global capital, there has emerged a new set of social practices that inflects or otherwise diverts these protological flows toward the goal of a utopian form of unalienated social life.

To conclude

Protocol has an intimate and complex relationship with language. In many ways, it is a particular language, with all of the expressive power and limiting abilities that that brings.

The implications of this language, though, will have to wait for another time.