Boy Meets Twitter

About two months ago I signed up for a Twitter account, and since then I’ve been (intermittently) fumbling my way through this 140-character universe, trying to get a grip on the thing. It’s been a weird and interesting process and to be honest I’m still not sure what I think of the whole phenomenon. A collection of field-notes, jotted down along the way:

Day 1
There’s definitely a charm to the brevity of Twitter: the limit of 140 characters is a formal constraint to writing similar to, say, haiku. (This is probably a comparison that every English nerd who uses Twitter makes.) Most of the writing I’ve done is decidedly long-form; the idea of a novel is less daunting to me than a short story, so trying to think this way is a nice change of pace.

Day 3
Twitter is all about curation, right? “On the internet, curation is what passes for style.”

Week 2
The fact is, is that Twitter makes me feel decidedly… well, peculiar. I’m obviously (very, very) late to the party when it comes to social media: and it’s a party that seems to have some kind of theme, although for the life of me I can’t figure out what it is. I’ve got the sense of having wandered into a vast space full of people milling around, intently doing something — but I can’t make out the transaction, what’s actually being created, or performed, or exchanged. (I get the distinct sense that I may be overthinking things.)

Week 3
Spending time on Twitter gives me a kind of vertigo. Iain M. Banks’ science fiction novel The Algebraist is largely set on a gas-giant and his descriptions of those constantly-shifting landscapes, in which there are no fixed landmarks or geography, remind me of Twitter. The waves of hashtag-trends, the random voices of retweets, the overlapping conversations between strangers: it’s all transient, slippery, full of unexpected juxtapositions. Twitter feels like the opposite of permanence.

Week 5
Belatedly, something like understanding. Most of the internet (that is, most of the public, human-facing internet — which is a smaller slice of things than we generally imagine) is basically a collection of tools. Google Maps is a tool for visualizing and locating things geographically; Slashdot is a tool for filtering news related to a specific interest group; Facebook is a tool for simulating friendship. All these sites more or less have a purpose built into them — a purpose that can be hacked and abused, but that provides a general framework for the activity that goes on. But Twitter, it seems to me, isn’t like that. Twitter is a medium, not a tool. It’s so open-ended that it’s not “about” anything — in the same way that the internet itself isn’t “about” anything. It just is, make of it what you will.

Final thoughts
I’m still not sure if Twitter is a medium I actually like — I prefer essays to one-liners. But it’s undeniably fascinating. To me, the most interesting aspect of Twitter is that is represents about the most abstract kind of game imaginable. There are minimal rules (140 characters) and a vague sense of “winning” (collecting followers) but apart from that it’s completely open-ended. In fact it might not be a game at all, unless you want it to be. Which is, now that I think of it, uncomfortably like life in general.

Posted in Tech | Leave a comment

The nostalgia trap

The Thousand Autumns of Jacob de ZoetThe Thousand Autumns of Jacob de Zoet by David Mitchell
My rating: 3 of 5 stars

What is it about the nostalgia trap that attracts so many writers?

Like practically everyone (it seems) I’ve been a huge fan of David Mitchell’s work for several years now. In particular I was amazed and humbled by Ghostwritten and Cloud Atlas, which seemed to offer a genuinely fresh take on what a novel can be. Both books functioned as powerful commentaries on the nature of identity and the sweep and strangeness of living in a globalized world — and did these things without falling into the trap of nostalgia, which is the cheapest and easiest of writerly traps.

Unsurprisingly, given Mitchell’s talent, The Thousand Autumns of Jacob de Zoet is beautifully written. The story opens in 1799 on Dejima, a tiny artificial island in Nagasaki harbor where the Dutch East Indies Company has a narrow perch for conducting trade with Shogun-era Japan. In this cramped universe, the Dutch traders scheme, worry, pine for their distant homes, and an unlikely love story develops between the eponymous hero and a Japanese midwife named Orito. Roughly midway through the novel, things take a turn for the strange: plot twists include the machinations of a sinister immortal abbot, a bizarre mountaintop nunnery where ritual baby-harvesting and murder are practiced, a daring midnight rescue-attempt, and the surprise arrival of British warships to challenge the isolated Dutch traders.

The entire book is written in a deft, economical style; each character’s voice is vivid and compelling, and Mitchell’s eye for detail is striking. With apparently effortless strokes he breathes life into the floating island-settlement, and the cast of Dutch traders anchored there like a barnacle on the hull of worryingly foreign Japan, an impossible distance from their homes. Although less formally ambitious than his earlier works (rather than remixing genres as he did in Cloud Atlas, Ghostwritten, etc., here Mitchell stays largely within the confines of traditional historical fiction), much of the novel is a pleasure to read: a smart, involving glimpse of a profoundly different world.

The least successful parts of the book are its action sequences in the second half of the novel. Although not bad per se (Mitchell may not be capable of writing a bad scene), these fail to deliver much punch or suspense, and at times suffer from muddy blocking so it’s unclear how, exactly, the dramatics are unfolding.

Overall though, it’s the conclusion of the Thousand Autumns that gave me the most trouble. In his denouement, Mitchell shifts gears: it’s years later, Jacob de Zoet is back in Europe, and we’re left with a quiet regret-filled meditation on loss, forgetting, and the passage of time. All of this is absolutely, breathtakingly lovely. It’s also the easy way out.

Because here, for once, Mitchell allows himself to wallow (there’s no other word) in the bittersweet soup of nostalgia — which is the opposite of the vivid immediacy that makes the best historical fiction come to life. Where great historical writing breathes life into the past by imbuing it with the uncertainty and newness of the present, nostalgia is a kind of self-congratulatory sugar-coating. It is emotion based on the irrecoverable nature of the past, and the gap between now and then: through the tumult and transformations of time, nostalgia whispers, only the identity of the person remembering what has gone before remains the same. In this way, nostalgia functions as a celebration of selfhood, and allows us to imagine history as a set of external events that, fundamentally, reinforce our unique unchanging continuity. But that, of course, is a fantasy. Our selves change with time, as much as the world does, and the effects of the past continue to linger. As William Faulkner (possibly the greatest of historical novelists) put it, “The past is never dead. It’s not even past.”

Hopefully in his next novel, David Mitchell will remember that the last thing a historical novelist should be doing is making the past feel either distant, or safe.

View all my reviews

Posted in Reviews | Leave a comment

The 30 minute app

One of the more interesting developments in the software landscape these days is the proliferation of public services that offer chunks of a-la-carte application functionality that can, in theory, be plugged together in modular ways to create very lightweight new applications.

This kind of modular approach is a key tenet of component model software development, and to me it also seems to suggest a new way of thinking about apps in general. As the ecosystem of rich, pluggable, prefab APIs and services proliferates, the cost of developing software applications should correspondingly decrease (at least in some cases). Rather than thinking of applications as enduring, long-term products or services, we’ll start to regard a lot of software as an ephemeral, disposable, on-demand tool. I expect we’ll see more and more of these situational apps in years to come.

Or maybe sooner than that.

I’ll be giving a talk at Portland Code Camp this weekend and thought it would be interesting to put together an app for distributing my presentation materials (assuming anyone wants them). And sure, I could just give out my email address — but that seemed less fun.

Instead, I decided to put together an SMS-based system. It would work like this: someone texts their email address to a particular phone number; in response they get a nice message telling them to look at their inbox, and an email to the specified address with the presentation slides attached. Silly? Maybe. But as a litmus test for the idea of snap-together one-time apps? Maybe not too bad.

The result:

  • Time to implement: 28 minutes. (I’ve already spent more time writing this post)
  • Total cost: $20
  • Services used: Twilio, Temboo, Gmail
  • Lines of code: < 50

How it worked:

Step 1: setting up a public phone number to receive SMS messages
The first thing I needed was a public phone number that could receive SMS messages and store them in a way that would be accessible to my app via an API. The SMS-as-service platform I’m most familiar with is Twilio, so I signed up for an account with them. The basic free account gives you an API to do things like make test calls from a browser and send/receive SMS messages in a sandbox environment. However, sandbox SMS messages need to include a special PIN and I wanted a real phone number I could give out so I bought a number using the Twilio website; it’s costing me $1 a month, and receiving an SMS message costs a fraction of a cent. I expect the $20 I put on my Twilio credit will be way more than enough to cover usage.

Step 2: setting up an SMS auto-reply
The next thing I did was configure the response that someone gets when they send an SMS message to my Twilio number. Twilio lets you do this by specifying a URL that their system will query to get the response text (which means you can dynamically generate SMS responses with a PHP script or whatever). In this case, all I wanted to do was return a static piece of text which meant I just needed to create an XML file in the “TwilioML” format (why is it that everyone wants their own ML these days?) and stick it somewhere on the internet. My goal was to have as little infrastructure to worry about as possible for this app — after all, I’m going to be throwing it away — so I just put my file in an Amazon S3 bucket here. (If you look closely at the image above, you’ll see that my SMS url is configured to be “”.) If I was being really scientific about the cost of this app I should include the S3 traffic costs, but since GET operations are $0.01 per 10,000 requests I’m going to just consider it a rounding error.

Step 3: reading incoming SMS messages
The next step was to retrieve the incoming SMS messages stored by Twilio, and pull out the email address (and eventually send out my slide deck). Rather than using the Twilio API directly, my first impulse was to use the Temboo SDK — that way I could get around needing to actually learn the Twilio API (after all, this is a throwaway and I don’t want to spend much time on it): the Temboo SDK is free (for a limited-usage account), is standardized, and includes a choreo to get a list of SMS messages from Twilio.

The Temboo library also has a choreo to send a message via Gmail, so using the SDK would let me easily handle the email part of my app as well:

I grabbed the Python SDK and started coding; the Temboo website gave me an auto-generated code snippet for the GetSMSList choreo, and after plugging in my Account SID and Auth Token from the Twilio site I was easily able to retrieve an XML document from the Twilio site containing all the SMS messages my number had received. Extracting the message body and checking for a valid email address were also quite straightforward.

Then I hit a snag. Make that two snags.

First, the Twilio API doesn’t offer a way of deleting SMS messages. Since my app is going to periodically query Twilio for messages, that means I need a way of tracking which messages I’ve already responded to, so people won’t get another duplicate copy of the slide deck each time the app runs.

Second, even using the Temboo SDK I need someplace to run my Python code. I don’t want to host it on my laptop, which I’ll have with me at Code Camp (I might not have good internet access or the laptop might be asleep) and I really don’t even want it on a hosted server (like where this blog lives) because this is situational code, right? Ideally it should be there when I need it, but otherwise have zero impact on my setup: I’d like it to just work, without needing any kind of maintenance, care, or feeding. Ever, if possible.

Step 4: rethink the approach
So I threw out my Temboo SDK based code, and decided to go another route: a custom Temboo choreo. In addition to the SDK, a less-advertised feature of Temboo is the ability to create your own custom workflows, with a visual programming tool called Twyla (there’s a nearly-hidden download link here on the lower-right of the page). Custom workflows can use any of the SDK Library functions (like the getSMSList and sendEmail choreos mentioned above), but they can also include business logic and customized interactions with HTTP, FTP, DB, and email endpoints. Using Twyla is obviously a steeper learning curve than using the SDK, which just drops into your IDE and language of choice, but a custom choreo had one big advantage: it meant that all my code would live and run on the Temboo servers (where a free Temboo account should easily accomodate the load I expect).

Here’s the custom choreo I put together:

As you can see, choreos are designed to be fairly self-documenting. In this case, my custom workflow starts by running another workflow from the SDK Library, to get the list of SMS messages from Twilio. Them I’m iterating over the messages, and parsing each one. Setting up a custom choreo is essentially a matter of connecting together pre-built steps, and then configuring each step for the specific function you want to perform. Here, for example, is the configuration of the “parse message” step:

…if you’re familiar with XPath, it should be pretty easy to understand what I’m doing here to extract specific fields from the message XML returned by Twilio. (It’s this kind of configuration, by the way, that I’m counting toward the “50 lines of code” mentioned above.)

After parsing each message, the choreo checks to see if the message body is a valid email address (by running another SDK Library choreo), and if so stores the address to prevent duplicate responses, then sends my slide deck to the address via the nifty send-email step.

Step 5: deploy the app
“Deploy” might not actually be the right word here, but I’m not sure what is. Saving the choreo publishes it to the Temboo servers, making it available to run via a REST API or the Twyla tool. In this case though, I wanted my workflow to run automatically so I use the Temboo scheduler function (another hidden-ish feature) to trigger the choreo once a minute.

28 minutes after I started, my Code Camp app was up and running; you can text your email address to 480.420.4531 to see it in action. This solution isn’t particularly scalable — I’d have taken a different approach if I expected thousands of people to request the slide deck (I’ll be happy if I get a dozen requests), but there are a few things I like about it:

  • It’s effectively maintenance free. Unless I run out of Twilio credits (in which case I’ll get an email alert) or cancel my Gmail account (unlikely) it should just keep chugging along indefinitely with no intervention on my part.
  • It’s super-lightweight. There aren’t any changes to my local environment or any servers that I manage.
  • It’s flexible. If I want to update the app for future conference, I can just switch out the slide-deck attachment that I send and tweak the SMS message response XML appropriately.

Proof that throwaway situational apps are possible, and likely to become more common? As for the “possible” part, I’d say definitely yes. It’s worth noting that my app doesn’t have a UI (which can add significantly to development time/complexity) but it represents a meaningful chunk of functionality that was effectively free to build and deploy — in fact, there’s a similar commercial app in beta called contxts (sorry, contxts, if this messes with your business model). As for the second part — whether this kind of lightweight, highly customized, component-based app will become the norm — we’ll have to wait and see.

Posted in Tech | Leave a comment

Who is the man with the moustache?

For a few years now, one of my more random interests has been North Korea. The DPRK is, of course, one of the most isolated nations on earth. The state has almost absolute control of the media; radio and TV sets in North Korea are supplied pre-tuned to government stations and radios must be checked and registered with the police. The average North Korean, I’d guess, has a view of things about as different from ours as it’s possible to be and still, in some sense, live in the industrialized world (unlike, say, the Sentinelese).

So hovering over the gargantuan ruined ziggurat of the Ryugyong hotel in Pyongyang, looking through the satellite eye of the web, to me there’s a sense of being a kind of strange space-invader, a voyeur from another world. Which leads me (sort of), in a roundabout way, to the man with the moustache.

The recently-deceased dictator of the DPRK, Kim Jong-Il, was a man of few words. In fact, it is believed the people he ruled only heard his voice once, in 1992, when he spoke a single sentence into a microphone at a military parade. By comparison, his recently-installed son and heir, Kim Jong-un, is a man of the people. (At 28 years old, he’s also the world’s youngest head of state.) During the recent centenary celebrations for Kim Jong-un’s grandfather, Kim Il-sung (the founding father of the DPRK), KJU gave a public twenty-minute speech. You can watch it here:

I’ve seen it a few times and there’s something compelling, disturbing and dreamlike about it. The sky hung with huge, motionless balloons, the architecturally-planned squadrons of watchers. Most of all though, I’ve become fascinated by the man with the moustache. You can see him at 1:24, on the left side of the screen.

He stands in the front row of some VIP section, his hands clasped in front of him. He’s wearing sunglasses, a dapper suit (possibly with a cravat) and very white gloves. There’s something proprietorial about his stance. He’s a man at ease in his surroundings (in the viewing stand for the great dictator’s speech, in the most secretive nation in the world). One gets the sense this is the kind of thing he might do every weekend. And watching him (a space-invader through the eye of the web) I get a sense of vertigo and a thrill at how the technology of our global age has changed distance — the ways we’re brought near to unexpected points, without explanation, which in turn throws into stark relief all the ways we’re still not close at all. Who is the man with the moustache?

Posted in Sundry | Leave a comment

A Favourite Story of Chad Mulligan’s

“This very distinguished philosophy professor came out on the platform in front of this gang of students and took a bit of chalk and scrawled up a proposition in symbolic logic on the board. He turned to the audience and said, ‘Well now, ladies and gentlemen, I think you’ll agree that that’s obvious?’

“Then he looked at it a bit more and started to scratch his head and after a while he said, ‘Excuse me!’ And he disappeared.

“About half an hour later he came back beaming all over his face and said triumphantly, ‘Yes, I was right — it is obvious!'”

Posted in Sundry | Leave a comment