Laughing Meme

Stumbling onto this Fab.com 2011 retrospective, reminded me of something that’s been puzzling me. While I knew a bunch of great folks going to work for Fab.com, including Lori Dorn and Beth Ferreira, I didn’t know any of their geeks. Which is odd in a small tech scene like New York.

Turns out the geeks are True Sparrow Systems, they appear to be a boutique Rails shop, they’re based in Pune, India, and described as co-founders. And Jason Goldberg did his last company, socialmedian, with them as well.

Mystery solved.

Last March Jasmine started talking to me about Pinterest in terms that made me pay attention. Since then I’ve been keeping an eye on it. A few weeks ago I decided to “cheat” my way into participation by writing a quick script to sync my Etsy favorites to a board.

Per request, I just pushed my PHP library for the unofficial Pinterest API up to Github. It’s a simple thing, more suitable for forking then using as is, and with some serious gaps where I simply haven’t had the time to find (assuming they exist) API methods for simulating the “pinmarklet” (as opposed to uploading), and for backing up pins.

https://github.com/kellan/pinterest.api.php

• inexplicabl.es
• invisibleciti.es
• otherwher.es
• sometim.es (I was convinced to keep this one)
• somewher.es
• unmentionabl.es

Will you do something cool with it? Are we friends? They’re your for the asking.

Also there really ought to be a site that facilitates offering up domain names you aren’t using to friends with a bit more structure then Twitter/blogging.

I don’t much like using sites that don’t offer APIs. (this is one of the reasons I don’t use Quora anymore, they’ve had plenty of time to offer an API in good faith)

But I do like playing with new sites and that means playing with sites that haven’t opened up an API, yet. It’s funny I keep getting into conversations with folks about, “We’re not sure how to open an API” or “We’ve got an API, but we think we need to rebuild it (and/or outsource maintenance of it to a 3rd party) before we make it public.” For those folks, please see flamework-api, an implementation of the Flickr “API framework” for how easy it can be, and then get over your timidity! But my favorite variant on this is, “Well we have an API for the iPhone app, but it isn’t ready yet for public.” Because that means there is an API, and you can use it.

Some quick notes on reverse engineering an API from an iPhone (mostly because I had to scrape all this back out of my lizard brain this week, and while it’s straightforward, there are a few step)

1. Grab a proxy, I use Charles, but Burp works just as well and is free.
2. On a wifi network, fire up the proxy and enable SSL proxying.
3. Connect to a secure site with a browser via the proxy. (Charles will setup proxying for Firefox automatically)
4. Using Firefox, drill into Page Info > Security > View Certificate > Details and export the CA certificate, which will be the intermediate proxy’s root cert. (e.g. with Charles it will be CharlesProxySSLProxying.cer) (YMMV with different proxies, and different browsers)
5. Upload the root cert somewhere you can hit with mobile Safari from your phone
6. Browse there with your phone, and add the cert.
7. Throw your phone into “Airplane Mode”, re-enable wifi, connect to the same network your proxy is running on, in the “Choose a Network” menu, drill down and setup Manual proxying pointing at your laptops IP address, and port 8888 if you’re running Charles or 8080 if you’re running Burp (or whatever else your proxy is running at)
8. Fire up the iPhone app with the API you’re interested in, and sit back and watch the bits flow.

(Reading over this again this morning I noticed I just assumed SSL, my data points suggest that’s a reasonable assumption both as SSL is easy, and as FBOAuth becomes more common, but obviously if the API you’re looking at isn’t running over SSL, skip steps 2-7.)

It wasn’t really until we were leaving London last week that I figured out that I should have installed the London Cycle app, a 3rd party app that scrapes up-to-the-minute information about availability of Barclays bikes (aka “Boris bikes”), and provides maps and routing.

Nearly every Londoner (or sometimes Londoner) we met had it installed, but none of the varied insipid “top 25 iPhone apps for London” style SEO bait blog posts mentioned anything like it.

So I’m curious, what applications do you know to navigate your city and get the most out of it? They don’t have to be city specific, I’m just curious what the apps you whip out when exploring, or getting to work, or meeting friends. What’s useful? (and where do you live)

We’re reaching a point where the our cityscapes are almost intractable without augmentation and I know that keying up proper augmentations will become a key piece of my next round of urban travel.

In New York I tend to use only a small set of city specific software (much to my chagrin), and mostly rely on big generic apps (in which NYC tends to be well represented)

To navigate New York I use:

• GoogleMaps
• Yelp
• Foursquare
• TreesNY
• CityTransit
• ExitStrategy
• Ride the City

I’m excited about anything that makes reading more social. I’m also excited about anything that makes the data I collect on my Kindle more accessible. (it’s a surprisingly locked down platform)

And kindle.amazon.com is a nice step forward. But it’s clear that Amazon does not build social software for a living because there are a handful of things they’re doing shockingly wrong, and the one that’s bugging me this morning is:

You never ever ever broadcast deletes, or privacy changes that move from more public to more private. You never send people an email “By the way Kellan stopped following you, because you suck” and you never broadcast in an activity stream, “Kellan’s tweet, ‘I’m so drunk I’m skipping work tomorrow’, has been deleted.”

This second example is what the Kindle site is doing when they broadcast that you’ve stopped sharing notes from a book or deleted it from your book list. That’s so broken it’s almost breath taking.

update: see also, for something else not quite right. People are hard, let’s go shopping.

About a year ago I did some deep diving into kindle.amazon.com trying to find a good programatic way to extract my data. It was a nightmare of client side JS templates, and general hatred of everything that was good about the Web.

In the last few months the Kindle site has gotten better. It uses real HTML, and has a semi-functioning concept of profiles, and contacts. But it still isn’t really what I want. But I’m busier then I was a year ago, and even given relatively sane HTML, I don’t feel like writing a scraper for something that ought to have an API.

But Fred’s post from this morning on “Sharing My Kindle Highlights” got me thinking that maybe I had been thinking about it wrong. Maybe I don’t need programmatic access to all of them, maybe I just wanted a bookmarklet to post selected hilights to Tumblr.

And I’ve got some bookmarklet code lying around, so I beat on it a bit, and was able to whip out Booknotes, alpha, a bookmarklet for posting from your Kindle hilights page to Tumblr.

I’m pulling the ASIN out of the “Read more at location X” links, and feeding that into the “Product Advertising API”, so while I’m only posting the title, link, and authors at the moment (because I couldn’t figure out how to pass rich markup to Tumblr’s share widget), there is a ton more metadata (like book covers) that could be included.

At the moment it’s only been tested on Chrome latest and on OS X Lion for a handful of my own highlights as building has already taken 200% of the 2 hours I allotted myself. (though part of that was getting XCode and Brew and a text editor installed on the new laptop)

So yeah, Booknotes, alpha.

Just a quick follow up. Got a ton of good feedback on last weekends “Slow News” post, in the comments on that post, and over at G+.

Some of my favorite comments where from Mike Migurski. Apparently his Google Plus account has been deleted. To say this tarnishes G+ for me is putting it mildly.

But to summarize the feedback which hasn’t been expunged, folks recommended:

• the New Yorker
• the Economist
• the Christian Science Monitor

as organizations who preform some of the slow news function.

We get the Economist, but I find it more useful for it’s brief overviews then it’s in-depth articles. (I generally find their bias is directly proportional to the length of the articles), and for some reason I’ve never been engaged by the New Yorker, I’m tempted to try it again but their digital pricing is a turn off.

Additionally I found Jerome’s point that a crowd funded news organization is particularly susceptible to being captured by lobbyist and special interests interesting. I’m not convinced that this is different then the situation we currently have with our media, but it does point to a membership organization as a model rather then a pure Kickstarter model.

Last weekend everywhere I went people wanted to talk about the tragedy in Norway. I didn’t know much about it, just the bones of the story, but I found, as I always do, our fascination with it, perverse, and a bit grotesque.

I liked to think that in the best possible world, broadcasting the blow by blow coverage of distant tragedy connects us all with our shared humanity. But mostly it just seems ghoulish, and to borrow an old slogan, it’s like voting — it just encourages the bastards.

What I really want is someone doing in-depth, well researched and written coverage of news events 1-4 weeks after the event. When all the details are known, and sifted, and analyzed.

Not all stories lend themselves to this. That our government is derelict in its duty and will be defaulting this week isn’t a story that can wait weeks. But even a few days to pull together a decent body of reporting/facts/graphs/analysis rather than rehashed he-said-she-said-chest-beating-editorial would be nice.

Thinking a Kickstarter-esque funding model would work really well — pledge your interest in an ongoing story in real time giving the news organization a heads up that they should be paying attention and starting to research, if enough folks show interest, the story gets written. Won’t cover all types of reporting, but it certainly would be a hell of lot better then 90% of what we’ve got. (and give me a page where I can advertise my interests as a dodge to having to talk about the ridiculous pop news hype cycle, “Yeah, I’ve pledged to read about that in another 2 weeks, check out my Slow News page, let’s discuss it in depth, then, shall we?”)

Also Greg Knauss wants something similar, while Jessamyn is interested in “same time last year” coverage.

Nils made public the Flickr PuSH (Pubsubhubbub) APIs a few weeks back. And it being a lazy Sunday morning, I thought I finally get around to consuming them.

You can (and probably should) go read the Pubsubhubbub protocol, but it’s written in standardese, and Flickr’s endpoints are a simpler degenerate case, so here’s the idea:

• it’s web hooks
• get an authorized token from the Flickr API like you always do
• make a subscribe API call
• have an callback that can echo back the challenge code every 24 hours
• and Flickr will push you bits of Atom feeds in real time.

Get an Auth Token

We could use the Flickr OAuth support, but FlickrAuth is simpler to demonstrate.

You can do this step anyway you want, but I’d grab flickr.simple, paste your key and secret into scripts/auth.php, and run it from the command line, at which point it will walk you thru an interactive prompt to get a token.

And just to state the obvious, you need a token because these feeds are personalized: photos or favorites from your contacts, photos of people you know, your photos, and your faves.

An Endpoint

Your endpoint does double duty. It handles subscription requests, and processes pushes. Let’s write the subscription handler.

<?php
    # file: callback.php

    # handle subscription requests 

    if ($_REQUEST['challenge']) {
        if ($_REQUEST['verify_token'] == 'MY VERIFY TOKEN') {
            echo $_REQUEST['challenge'];
        }
    } else {
        echo "Ok";
    }

The verify_token is an arbitrary string you pass in that Flickr will pass back to you. Among other things it makes securing your subscription handler against XSS a bit more straightforward. (just don’t use “MY VERIFY TOKEN” ok?)

The challenge is a string that Flickr will generate and send to you to make sure you’re actually interested in having a bunch of photos pushed to you. You’re only responsibility in subscribing is to echo it back. This will happen when you first subscribe, and then again every time your subscription lease is up, which is by default once a day.

Subscribing to a feed

Is just a call to flickr.push.subscribe. Here’s how to do that, using flickr.simple

include ‘flickr.simple.php’;

<?php
    # file: subscribe.php

    include 'flickr.simple.php';

    $key = 'your-key-from-step-1';
    $secret = 'your-secret-from-step-1';
    $token = 'your-token-from-step-1';

    $flickr = new Flickr($key, $secret);

    $rsp = $flickr->call_method('flickr.push.subscribe', array(
        'auth_token' => $token,
        'topic' => 'contacts_faves',
        'callback' => 'http://laughingmeme.org/code/monopiledonutfender.php',
        'verify' => 'async',
        'verify_token' => 'MY VERIFY TOKEN',
    ));

    var_dump($rsp);

Here we are subscribing to the favorites from your contacts stream. You can get a list of available streams with a call to flickr.push.getTopics, which you could write a script to call, but I’d probably just call it in the API Explorer and get the list:

<topics>
    <topic name="contacts_photos" />
    <topic name="contacts_faves" />
    <topic name="photos_of_contacts" />
    <topic name="photos_of_me" />
    <topic name="my_photos" />
    <topic name="my_faves" />
</topics>

Note: you’re going to need a different endpoint for each different topic. I just add ?contacts_photos=1 or ?photos_of_me=1 to my callback URLs to distinguish them.

Subscribing: Putting it all together

Upload callback.php somewhere publicly addressable, point the callback arg in subscribe to that URL, make sure your verify_token is the same in both scripts, and then run subscribe.php

To check that it worked, get a list of your subscriptions with

<?php

    include 'flickr.simple.php';

    $key = 'your-key';
    $secret = 'your-secret';
    $token = 'your-token';

    $flickr = new Flickr($key, $secret);

    $rsp = $flickr->call_method('flickr.push.getSubscriptions', array(
    'auth_token' => $token,
    ));

    var_dump($rsp);

If you see subscriptions that are still pending with non-zero verify attempts you did something wrong. Go have your morning coffee and try again. (<== this worked for me, your mileage may vary)

Processing

So assuming that all worked, Flickr is now bombarding your callback.php periodically with Atom blobs containing the information you requested. In practice I’m sticking the blobs into Redis in a list, and treating it as a queue to split processing from callback.php (this all runs on a tiny Linode VM and tying up Apache process is a bad idea), but for the sake of demonstration we can assume that if we weren’t passed a challenge then this is a payload and we’ll add the processing right to callback.php.

There are of course many ways to parse Atom (much like there are many ways to call the Flickr API), but unsurprisingly I’d use Magpie, and in particular I’d grab rss_parse.inc, which, while not having been touched in 7 years but still works.

<?php
    # file: callback.php

    # handle subscription requests 

    if ($_REQUEST['challenge']) {
        if ($_REQUEST['verify_token'] == 'MY VERIFY TOKEN') {
            echo $_REQUEST['challenge'];
        }
    } else {
        echo "Ok";
        require 'rss_parse.inc';
        $xml = file_get_contents("php://input");
        $feed = new MagpieRSS($xml, 'UTF-8', 'UTF-8');

        # do logic on feed here!

The interesting bit

Of course the interesting bits all come after “do logic on feed here!”. This is where you build your feel newsfeed for Flickr, your replacement for photos from your contacts, your anteater. That bit is up to you. (though given an infinite supply of lazy Sunday mornings, maybe I’ll post a follow up)

At Web 2.0 Expo

I’m really looking forward to seeing Nis talk about the architecture that supports these feeds this fall at Web 2.0 Expo NYC, Flickr PuSH: Real-time Updates on the Cheap for Fun and Profit

I see Twitter getting beaten up a lot for not deleting the spammers faster. Etsy gets beaten up for not deleting the “resellers” faster. Flickr used to get yelled at for not catching the photo stealers or porn spammers faster.

“It’s so fucking easy, they’re right over there, here, let me show them to you, what’s your problem?”

This comes from not understanding the cost benefit ratio of false positives in identifying abuse of a social site at scale.

Imagine you’ve got a near perfect model for detecting spammers on Twitter. Say, Joe’s perfectly reasonable model of “20+ tweets that matched ‘^@[\w]+ http://’”. Joe is (presumably hyperbolically) claiming 99% accuracy for his model. And for the moment we’ll imagine he is right. Even at 99% accuracy, that means this algorithm is going to be incorrectly flagging roughly 2 million tweets per day as spam that are actually perfectly legitimate.

If you’ve never run a social software site (which Joe of course has, but for the folks who haven’t) let me tell you: these kinds of false positives are expensive.

They’re really expensive. They burn your most precious resources when running a startup: good will, and time. Your support staff has to address the issues (while people are yelling at them), your engineers are in the database mucking about with columns, until they finally break down about build an unbanning tool which inevitably doesn’t scale to really massive attacks, or new interesting attack vectors, which means you’re either back monkeying with the live databases or you’ve now got a team of engineers dedicated just to building tools to remediate false positives. And now you’re burning engineer cycles, engineering motivation (cleaning up mistakes sucks), staff satisfaction AND community good will. That’s the definition of expensive.

And this is all a TON of work.

And while this is all going down you’ve got another part of your company dedicated to making creating new accounts AS EASY AS HUMANLY POSSIBLE. Which means when you do find and nuke a real spammer, they’re back in minutes. So now you’re waging asymmetric warfare AGAINST YOURSELF.

Fine, fine, fine whatever. You’ll build a better model. You know, this is a social site, we’ll use social signals. People can click and say “This is spam” and then when, I don’t know, 10 people say a tweet is spam, we’ll delete it and ban that account. But you know, people are fuckwits, and people are confused, and people are unpredictable and the scope of human activity at scale is amazingly wide and vast and deep, so a simple additive, easy to explain, fundamentally fair model isn’t going to work. (protip: if you’re site is growing quickly, make sure to use variables for those threshold numbers, otherwise you might DOS yourself)

But you’re smart, so now you’ve got a machine learning model, that’s feeding social signals into a real time engine, that’s bubbling up the top 0.01% of suspicious cases (and btw if you’ve gotten this far, you’re really really good, and you’re probably wasting your time on whatever silly sheep poking/nerd herding site you’re working on, so call me, I’ve got something more meaningful for you to do), and in at least Twitter’s case we’re now talking about a mere 200,000 potential spam tweets to be manually reviewed daily.

How many people do you need to review 200k spam tweets per day? How many desks do they need? Are you doing to do that in house or are you going to outsource it? And if you outsource it, how are you going to explain the cultural peculiarities of your community, because while your product might have gone global, you’re still your own funky nation of behavior, and some things that look strange (say, retweeting every mention of your own name) are actual part of your community norm.

And if you don’t explain those peculiarities, how long do you think it is until this small army you’ve assembled to review 200k tweets a day, gets tired, makes a mistake and accidentally deletes one of your social network hub early adopter types (because the sad truth is early adopters are outliers in the data, and they look funny).

And what do you think the operational cost of making that mistake is? (see also: fakesters)

Also, whats your data recovery strategy look like on a per account basis?

There are solutions. Some of them are straightforward. Many of them aren’t. None of them are as easy as you think they are unless you’ve been there. And I’m happy to talk to you about them over a beer, but just posting them on a blog, well that would be telling other people’s secrets. And they already have a really hard job.

A much more cogent blog post by Bruce Schneier from 2006, on Data Mining for Terrorists really drills into this problem from a theoretical model. (where “for Terrorists” is to be taken in the “finding Terrorists” sense and not in the “for Dummies” sense) (update: via rafe a good BBC article on base rate fallacy)

The topic has been on my mind lately, as Twitter recently banned my account by accident, along with a number of other very early accounts, but never acknowledged it. And at Etsy last week we had an adaptive process go rogue and ban a tiny number of early adopters, an issue we posted about on our status blog, and in the forums. In both cases there was a full recovery of all the account data and state.

Photo by: Superchou

If a service shares data transparently with you, there’s a good chance you’re the customer, otherwise you’re probably the product.

Just another reason I’ve always been impressed by the Etsy tradition of Weather Reports, and why I’m psyched about the Shop Stats (screenshot) launch yesterday.

(see also “If you are not paying for it, you’re not the customer; you’re the product being sold.”)

If you’re thinking about launching an application that centers around group forming as a filtering mechanism, a couple of quick feature requests:

• “Smart Sets” ala iTunes are unlikely to work because human features are less well understood then pop’s features, and will lead to frustration and abandonment, so don’t do that.

However …

• most entities we refer to as human have a single geographic location at any given point in time. This is a useful, and well understood feature. Cityli.st was a project I start to exploit this fact that automatically maintained and updated Twitter lists based on a person’s location. (turns out Twitter lists don’t work very well, nor are they particularly useful.) Please dear god, build this into G+ already, especially if you’re going to have checkins.

• update asymmetry is a fact of life. Some folks update multiple times a day, some folks update very few minutes, some folks drop 1000+ photos in a single upload session once every 6 months. Automatic grouping by rolling average of update frequency would be extremely useful.

• shibboleths (aka something you have or something you know). A group of everyone who hit this onetime URL. A group of everyone who can take a photo the Empire State Building from where they’re currently standing.

• time is another interesting human constant. People I’ve recently contacted, people I haven’t contacted in years, and people who I was at the same concert/bar/office with are all useful slices.

Thanks.

Photo by maryclaireroman

William Morris was an important figure in my house growing up. Mostly because he was one of my grandmother’s muses (growing up as she did in Southern California surrounded by the work he inspired in the California Craftsmen, e.g. the sublime Gamble House). And we had the best picture books of his works lying around the house. (the fact that he was also a socialist and anarchist as well as a successful aesthetic theoretician and artist helped later)

Which is all apropos of very little except my thinking about why I’m so sympathetic to the design philosophy of what I call “flourishes.” Flourishes, as I think of them, are the elements you add to a design not because they are necessary or straightforward, but because they’re often hard and interesting, and their inclusion speaks of a better world than the one we live in. That’s core to my personal definition of craftsmanship.

Which again is apropos of nearly nothing, except it’s on my mind as I think about this blog post, which is mostly about dates and Flickr. (and to a lesser extent craftsmanship)

I like shoeboxes

I think dates are important. I think history is important too. I’m a self described calendar dork. And I fret about the warm bath of now-ness we seem to be currently living in; real time a synonym for ephemerality and disposability. If there is anything this culture needs less of, it is disposability. I some times claim this will be the great era of forgetting, an entire generations learnings/thoughts/beliefs as if writ in water. Which is suppose why I twitched a bit about Jason’s perfectly valid critique of the current state of sociality on Flickr, namely that it’s stagnated.

So I wanted to talk a bit about the date handling flourishes in Flickr. (I worked on nearly none of this, and much of it was already in place by the time I joined.)

Upload dates vs Taken dates

The date you uploaded a photo to Flickr is stored in epoch seconds, and can’t be earlier then the date you joined Flickr.

The date your photos was taken is stored in a MySQL datetime technically giving you the ability to label your photo as being taken solidly 800+ years before anything most of us would describe as the invention of photography. Which is a little silly. But I do love this photo of the Blue grotto, Capri Island, Italy taken in 1890. (in fact you can see all your favorite photos taken before 1900, I have four)

Fundamentally this split between system activity time, and human editable creation date models a world where the people who use your software do something other than use your software. You have to decide how you feel about admitting that possibility.

Circa dates, and date granularity

If you visit most photo pages the date does the semi-standard human friendly date thing aka if the photo was taken recently it will say “taken 18 minutes ago”, otherwise it will say “taken on August 10, 2008″.

But if you visited that Blue Grotto photo you’ll notice the date is listed as “This photo was taken some time in 1890.” That’s date granularity. Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa.

What’s circa? Circa is a flourish. Circa is the sort of feature you only get when you care about the craftsmanship. You can checkout the George Eastman House archives, circa 1860. Those photos were all taken in 1860 plus or minus 5 years.

Computers demand exactitudes by default, but it’s a laziness of which we are collectively guiltily that we’ve traded a few programmer and compute cycles for a rich and nuanced societal understanding of time.

Archives

It should probably go without saying, but if you want to understand the story arch of someone’s life (not just the this week’s episode), having access to browsable archives is pretty key. The photos from friend page probably is the most neglected page based on it’s level importance, but the archive pages are the most neglected page on Flickr. Still they do the job.

(there’s a comparable page for places places, instead of dates, that never quite got launched, but you can sort of fake it with the personal map page)

Also, you know, just being able to jump back to a arbitrary page in history in the stream.

Date ranges on sets

This is another flourish feature. One of my favorite.

Last Summer, Jazz and I made a 2400 mile loop up through Nova Scotia. On that page in a small grey font you’ll see a note telling you the photos are “from between 04 Jul 2010 & 12 Jul 2010.” That tells a story. Immediate nostalgia. For me at least. Probably doesn’t do much for you. But that right there is my second favorite feature on Flickr. (the “You + X” pages, being my first, or really just this page of Jazz and me )

However on a more substantial set, like Steve Ford’s First Cups set, with 2036 pictures of his first cup of coffee each day for 6 years, the between dates allow you to jump around within the set and provide quick orientation.

This is a time linear navigation model, but date way markers are at least surfaced. (also this is in many ways a post-facto rationalization of the fact that sets weren’t originally paginated)

Trending Tags

This is most hidden, and probably most experimental (that actually got launched). If you go to the global map, and click the House icon, you’ll be presented with a map of geolocalized trending topics (today’s include “folklife” in Seattle, and “marchadaliberdade” in Sao Paulo, BR).

Search + Dates

Just having real search is considering something of a craftsman’s flourish these days, but assuming we’re executing at a level of competence that allows for search, adding dates as first class selectors to your search make it possible to have a page like all the photos from your contacts taken between 1980-1990.

In conclusion

No conclusion. Just some design notes, in case you get inspired, you know, for next time.

(nota bene: depending on how active you are on Flickr many of these search links might come up blank for you, I tend to use Flickr’s ability to scope searches to only things that are personally relevant to me, my favorites, my contacts, my photos, etc, your view of these links will be scoped to your personal world view. Whether or not I should be able to share my personalized view of the world publicly ala Twitter’s recently revived “With Friends” feature was heavily debated, but eventually was sacrificed on the altar of performance concerns in a system with rich privacy settings)

Yes, you did. But I’ll mostly forgive it when you un-suspend my account.

For the record, I was attempting to re-follow Albert Wenger (that subscription seemingly having been lost somewhere along the way) when they suspend my account. Apparently that was suspicious.

Wondering if I’ve got the lowest account number to be suspended or is this a common thing?

Note to self: we need to get back to working on decentralized communication technologies.

update: I’m back! Dunstan also got suspend, which makes it seem likely it was a bug affecting low numbered accounts.

Love this quote from Borthwick regarding news.me and shipping:

“I ran a new product development group within a large company and I would like to dispel the simplistic myth that big companies don’t innovate. There is innovation occurring at many big companies. The thing that big companies really struggle to do is to ship.” – John Borthwick – news.me

People ask me why I focus so relentlessly on shipping as opposed to the rest of the software development life cycle. In part because it’s hard. It’s often the hard problem. And it gets harder the longer you do it, aka it gets harder the more important the thing you’ve built is.

I was honored to speak as part of the rapid fire keynotes Thursday morning at Where 2.0 (4/21), and gave a brief (even briefer then originally planned) talk on “The Brooklyn Problem”.

The slides:

The video:

Folks have told me they enjoyed the talk, and found it inspiring and informative, which is immensely gratifying.

I was personally frustrated with myself as I wasn’t as prepared as I like to be, and I made a number of last minute cuts from the talk that made it feel more disjointed then I liked.

This can be summarized in the #protip: When the organizers give you a chance at a dry run to get to know the stage and the equipment, do it!

Additionally I didn’t get to talk about the work of Aaron Beppu who recently joined our search team tackling relevance ranking, did the bulk of the backend work on this project as his bootcamp project, and whose final implementation is significantly more complex and interesting, or Fred Blau, who is currently working on our internationalization effort, but who rewrote our auto-complete implementation to use sequence ids instead of timing for a much smoother interface.

In the golden foothills overlooking the bay, on the deck of a geodesic dome, sitting under the canopy of live oaks, listening to folks sing and play guitar and tell the stories of the San Onofre surf club (from way before the nuclear power plant was installed in 1968), these are my roots.