{
from the subcontinent

so for the past couple of weeks i’ve been in sunny chennai, india. sunny, as the avg temperature while i’ve been here has been 104°.

i don’t really know where to start. the thing that most recently occurred to me as i was washing my hands was ‘what does it mean to be clean here?’. the water is not drinkable, carrying bacteria which will make me quite ill. when i wash my hands, i transfer them to my hands. someone truly ocd would pull their hair out here.

i haven’t had any regular transportation, since you can’t rent a motorcycle, there’s no way i’m driving a car, and the Madras Club, where i’m staying, is far enough from the nearest taxi stand or auto-gathering corner that walking it is pretty rough. i could call in a car, but after work it’s always dark, so there’s nothing to see really. i can’t go to most nightlife events as i am a single male and won’t be allowed admission, and i neither speak the local language or have anyone to show me around the kinds of places i’m likely to want to frequent.

combine this with an illness that befell me a few days after i arrived and is only letting up now that i’m nearly gone.

i’m not trying to complain, just explain why i haven’t been out to see the country, or driven down to the temples, or anything of the kind. it’s a work trip, and two days off in a row isn’t something that actually happened. i’ve seen quite a lot of the madras club, the lister offices, and the road between the two, but i’ve done little else.

so if there’s a lack of photos, i apologize.

that said, wandering around these places has been interesting. on a couple of days i did quite a bit of walking (dehydrating myself to a dangerous level), and via shopping excursions with vijay, have seen most of the town. i was warned about the culture shock, but i don’t feel it. i think if i knew the language and the map i’d get along just fine.

every weekend when i head downtown, at least one bum asks me for money. didn’t happen here but once, even though i am clearly a rich foreigner. no one has tried to rip me off, or even really hassled me. indians (at least in this part of the country) are by and large non-committal, and they have solved most of their coordination problems.

a prime example: traffic is a joke. there are lanes, stop lights, stop signs, no u-turn signs, streets, and even sides of the road but on one cares. you just go, and somehow it works. bearing in mind most of these folks are on motorcycles, bicycles, and tiny little cars. the traffic is slow-moving, crazily crowded, and hectic, bit it isn’t dangerous. everyone gives everyone else as much space as they can while getting where they’re going—it turns out this isn’t very much space, but it’s enough to make the whole system work.

the roads are shit, and the cars all have little dents, but despite spending probably 20 hours on the road, generally in rush hour and through some really nasty intersections, i didn’t see a single traffic accident. coordination.

we think the government in america is corrupt. HAHA HAHAHA HA HAHA HAHAHA.

the food here is good, if not widely varied. it generally consists of some kind of gravy, and some kind of bread. the contents of the gravy vary widely. the bread, not so much. there are also a few rice dishes. the locals eat with their fingers, and rinse their hands in a bowl afterwards, or visit a small washroom—which generally only contains a sink. see earlier question about clean.

you can’t drink the water. duh. this adds all kinds of other complication: you can’t rinse your toothbrush in the sink. you can’t have drinks with ice. you can’t open your mouth in the shower. be careful when you shave. etc.

i have never felt so privileged to be able to get clean water out of a tap. that one little thing i will likely never take for granted again.

prices for things are mostly the same. gas is around $4/gal. clothes, phone airtime, etc is all the same. food is a little bit cheaper, but the drinks aren’t.

all the women dress the same. this is disconcerting. imagine if every female in lexington always looked like the dress girls, all day, every day. that same look, maybe with a little color variation. either the traditional sari (rare) more more commonly this two-piece dress arrangement i don’t know how to describe, with a scarf pinned to it. i never realized how much i tell people apart by their clothing styles.

(i lie .. i saw a few ladies dressed in western clothes, but there less than two dozen that i saw the entire time i was here, and most of those were at the hotel and were clearly foreigners.)

the software developers here (this is actually a work trip) are either fiercely creative, or are afraid to name a variable without help. this is a problem, and one i’m pretty familiar with. we have both kinds. i’m trying to turn the second kind into the first kind, but it’s not the kind of thing i can affect in two weeks, three weeks, or even a month. it’s cultural, and is quite problematic.

the beach. where to start. far too many clothes, way too much garbage and broken glass. it looks and feels dirty. i didn’t want to get into the water. there is no sailing, or really any recreational beach activities at all that i saw. i don’t see the point in going to the beach if you’re going to go stand around in the swelter. i should’ve taken a trip to the maldives.

if i come back here, i’m going to resolve two problems: 1) i am going to hire a driver. for the entire time i’m here. if i can’t have a driver, i don’t want to come back. 2) i’m going to get out of town on the weekends, and go someplace neat. this means coming when it doesn’t get dark at 5:30pm, and not only having one weekend day, and most of all NOT GETTING SICK. yeah yeah, things i can’t control.

i have some pictures, but not many. i didn’t have time or company enough to go on a walking tour of anything except the path between the office and wherever we were eating lunch. i don’t want to go wandering around on foot much (even though i really really do, i didn’t want to get lost) and there weren’t consecutive days to go outside the city. it was a 15 minute walk to the nearest intersection from the club, and i had no idea what was around. a native guide would’ve been nice. that was generally either vijay or stanley, and i doubt they wanted to give yet another rs employee all of their meager weekend time. i mooched when i could, but didn’t want to impose.

anyhow—so there’s a lot more to yap about. the short summary is that this was a work trip, felt like a work trip, and i didn’t have much fun because of a number of mostly logistical problems, which i will be ready for next time.

{
giving the iPhone a run

Yeah, I am behind the times. But I had to get a new phone anyway so why not treat myself?

{
bad news ..

the manager at rs that i so respected is leaving the company. good for him, sucks for me. he is like the zen master of the intersection of technology and office politics. easily the best manager i’ve ever had.

if you’re reading, you will be missed.

{
home again

the house is a mess. feels good to be back in it, however. tomorrow, or perhaps monday i need to get a couple of new shirts to take with me to chennai.

working on getting the feed reading part of this site working with backgounDRB. since this is hosted at dreamhost, i wonder how i’ll be able to keep things running?

it’s been time to move for a long time, but i’m resisting. maybe after jumble gets rolling.

{
w2e fri session 3: web 2.0 workflow

merging agile and ucd processes

host: kelly goto @ gotomedia

the big ball of mud! questions about what’s working for people. not many people seem to have a process that works.

why does everybody end up in the big ball of mud? time, cost, experience, visibility, complexity, change, scale.

the cure, from the BBOM paper: agile and refactoring.

what we’re doing here? finding a best practices toolkit.

i am running out of battery, and hope that i can get the slides for this.

will post the generalized review of the conf later.

{
w2e friday session 3: the 'how' of oauth

using chuck.e.cheese as a way to describe oauth.

what oauth gives you:

signed http requests.

safe, password-less token exchange.

what’s the process?

three actors—user (not me!), service provider, consumer (the app that’s getting the protected data).

three sets of tokens/credentials: access token – (tickets redeemed for prizes, signed), request token – (tokens, fake quarters, etc.), consumer keys – uniquely identifies an application

therefore, you have three urls: request token issuer (token machine), auth page (confirm access by user), access token exchanger.

as a service provider, you have to decide what urls you are going to use.

now, the meat.

building a consumer. (in ruby!) auth.net website has code for many languages. fiddly part: getting signatures correct.

get a consumer key and secret. we register our app with the service provider (not defined how in the spec—get this from the app).

[code] gem install oath [/code]

some code here.

1  consumer = OAuth::Conser.new("key", "secret", {
2    # options
3  })
4  
5  request_token = consumer.get_request_token

step 2.

1  request_token.authorize_url
2  # => http://mysite.com/authorize?oauth_token=XXXX

keep the following token around: it’ll be used to make subsequent requests. the user has control over the access token—they can go into the service provider and revoke the token, for example.

1  token = request_token.get_access_token
2  # simple, right?

and we’re done with token exchange.

1  token.get('/me')
2  token.post('/topics', {})

now, building a service provider. supporting oath in the server side. (this is the easier side of the coin? but possibly more complex.)

data to store: consumers – the thing using the API (key, secret, callback_url), request token (token, secret, consumer, authorizing_user), access token (token, secret, consumer, user)

authorizing user is hard to get your head around. capture that when the user gives access on the server side.

registering consumers: how you want to issue these is entirely up to you. can be anything—a development signup form, for instance. as long as you can communicate this to the developers, you’re in good shape.

verify using only the consumer credential, that the consumer is good, has registered, has a token.

1  valid = OAuth::Signature.verify(request) do |token, consumer_key|
2    consumer = Consumer.find_by_key(consumer_key)
3    [nil, consumer.secret]
4  end

issue the request token:

1  request_token - consumer.get_new_request_token
2  render "oatuh_token=#request_token.token}" +
3    # ...

ask the user to accept the authorization (psdeudo)

1  if logged_in?
2    ask_to_authorize
3  else
4    save_login_return_path
5    redirect_to login_url
6  end

attach the user record to request token. go back to the consumer.

 1  def authorize_token(request_token)
 2    request_token.user = logged_in_user 
 3    # capture the authorizing user and
 4    # redirect to the callback url somehow.  return the user to their 
      app.
 5    if params[:oatuh_callback]
 6      # go there  could also be some sort of 
 7      # callback url attached to the consumer
 8    else
 9      # do something else
10    end
11  end

validate using request token and consumer

1  OAuth::Signagure.verify(request) do |token, consumer_key|
2   # ..
3  end

issue the access token, and destroy the request token

1  transaction do
2    access_token = request_token.get_access_token
3    request_token.destroy
4    render "oauth_token=#{access_token}" + 
5      # ... 
6  end

validate access token, when a request comes in.

1  OAuth::Signature.verify(request) do |token, consumer_key|
2    # find the access token by the submitted token
3  end

(mmm .. meaty.)

http://icanhaz.com/oauth

?: does oauth have anything to say about token expiration?

isn’t specified. up to you. make sure your http return codes mean something.

?: what about javascript? how do you keep the secret?

doesn’t matter—only validates that you (the developer) have registered. a malicious app would have to get the access token to get any real access.

?: a living example of how the process works?

go use a flickr api application. google authsub. yahoo bbauth. pownce api gallery.

?: ssl as best practice?

ssl really fits in when the developer requests the api key. oauth doesn’t specify how it protects requests. protected from most attacks because nonces sign the requests. doesn’t hurt.

?: discovery? (OAuth Discovery 1.0)

an implementation of xrds, to discover the three urls discussed. helps automated tools about an oauth-enabled service provider. getsatisfaction.com is xrds compliant, ex.

?: role-based permissions?

not specified. your app can do this, but it’s not specified by oauth.

{
w2e fri session 2: mozilla add-ons

presenter: mason @ wesabe

(pretty sparsely populated here)

add-ons, introduce them, where they are, and how they differentiate themselves from add-ons a few years ago.

why would you want to go there? the biz argument.

add-on development, jargon, &c. how to build. setting up a development environment. (lightweight overview)

some resources at http://www.wesabe.com/downloads

http://add-ons.mozilla.org – add-ons extend firefox.

personalize your browsing experience, and differentiates firefox from the crowd.

  • button or menu item
  • toolbar
  • sidebar

aren’t limited to firefox—flock, thunderbird .. built into the platform.

the standard:

  • google
  • yahoo
  • delicious buttons
  • stumbleupon—a good example of a company that raised itself with its addon.

the innovative:

  • google browser sync & gears – deep firefox and web app integration.
  • delicious bookmarks—now fully browser-integrated
  • glubble
  • ebay companion

?:why use an addon?

downloaded apps are a lot of work, with a slow release schedule. add-ons are quick to prototype and build.

  • simple tool set
  • xul
  • javascript

quick and easy to relese

  • mozilla add-on site
  • push new releases and updates

cross-platform support, easy localization

add-on to app independence: migrate via xulrunner. flickr uploadr, ex.

add-on dev 101

xul – xml based user interface language. worst acronym ever. there is no dana only xul. or use xhtml (add the namespace, tweak)

(i realized these notes aren’t incredibly useful to anyone reading them, but they serve as a reminder for me as to what was talked about, and should provide links to learn from.)

xul overlays: files that describe the extra content in the UI. overriding small pieces of a xul file without having to resupply the whole ui, or reusing particular pieces of it. most add-ons employ xul overlays.

chrome – a set if ui elements of an add-on. content is the xul files, javascript, etc. like writing a big fat ajax client. locale for localized information. (this feels like what i’ve already read on the add-on tutorial sites and whatnot.) skin – css, images.

xpi – (zippy) derived from xpinstall. this is the add-on installation file: chrome (generally jar’d), install.rdf, chrome.manifest.

a hello world. (see the downloads. this is a long, slow tutorial.)

it’s important to sign these, preventing man in the middle attack.

development environment—this is a bit tricky.

1) create a profile. use profile manager in firefox. (firefox -profile) create then quit. 2) find extensions dir. 3) create a file matching your ‘id’ in install.rdf and inside, place the absolute path to your dev area. (/Users/ben/projects/whatever) do everything in there.

documentation is thin or poorly written. firebug can inspect xul. don’t release your add-on dumping. hard to debug.

add-on for web app? server side API!

xpcom – what firefox is really built on. you can write using xpcom. look at xbl.

no walled garden: scope your add-on to a single namespace.

...

resources:
  • mdc developer connection
  • xulplanet
  • ted m’s extension wizard – quick start
  • born geek’s tutorial.

review:

very high level, and mostly review.

{
w2e fri session 1: games 2.0

jeremy lieu @ lightspeed venture partners

we’re talking about the future of game development and game types with web 2.0.

panelists:

lots of things have changed in the web—mostly the variability of cost. these changes are tricking to the web industry.

aaa games can cost upwards of $30M. marketing driven by print and media advertising. building is about levels, and monetization is through box sales.

changes parallel the web industry.

small agile teams can get in-browser games out quickly.

(really want this slide .. don’t want to record it here.)

web games are multiplayer—not ai driven. no level design. &c.

some numbers:

halo3 $30M, yielded $700M.

powerchallenge < $8m. 1M players.

friends for sale < $1m. 7m players.

marketing:

$30M marketing dollars, 10M copies sold, 90% through retail.

the rest—facebook.

aaa game sales declines over time.

social games are backward—they grow over time.

one of the critical issues for multiplayer games online is asynchronous play.

online gaming revenue: $3.8B 2006, $5.3B in 2007, more in 2008, and growing.

panelists:

seqi chen (serious business)

johann christiansen (power challenge)

shervin pishevar (social games network)

mark pincus (zynger)

warbook—developed in two months by two people.

there have been improvements in play since launch, since it’s server hosted. just launched a sequel.

johann started in 2001, started text-based, added graphics over time.

how import are graphics, given their expense?

not important in management games.

launching early with a text-based game: profitable from the first year. management games develop a loyal user base.

variablized content?

mark: launched scramble as a live game, competition in real time. maxed out at 20K daily active users. spent three months reworking the game to be asynchronous. several tries before it reached a tipping point. thought asynchronous was a bad idea initially.

they come back to an asynchronous play because it’s your turn. there is a social obligation. the live game, though, represents 1/3 of daily users.

seqi: not turn based, but is asynchronous. (friends for sale). success about creating a game where social relationships are embedded into the game.

there is some value in unstructured asynchronicity.

johann: the social aspects of games are critical.

shervin: (gaming graph v. social graph). the emotional connection between people who know each other is quite valuable.

(think about a word scramble type game with continuous scoring.)

a very high accept rate on invitation is key to viral growth.

ghost racer: example of something too hard, yielding a high dropoff rate. ideally, a game should be easy, spreadable, with incentives for invitation.

six or seven months to 1M daily actives for popular web games. the important metrics are how things are being used. example: buying drinks for someone at the table at texas holdem. 250,000 drinks bought a day, for this little side feature.

(some discussion about funding of ventures.)

?: how to do something additional to viral.

mark: games are not naturally viral. other mechanisms have to be employed, and repeat usage has to be focused on. the ad rates you can buy traffic from are ridiculously low. networks from zynga are open to any new game developers.

shervin: ad-sharing is critical to cross-promotion. gaming bars, who’s playing what. one-click to go play. an independent channel from facebook. combined reach through SGN is 100M users.

seqi: (re crosspromotion) since they have one app, not so much cross-promotion. forced virality v. virality via game mechanic.

?: what are people willing to pay for?

digital goods, personal branding

?: real-money trading? digital goods?

shervin: a discussion on selling warbook gold. freegifts = largest virtual goods e-tailer.

mark: there is a direct line relationship between engagement and monetization.

?: social gaming and mobile phones?

they’re on the way.

?: $ for 1000 players / day? rate?

difficult answer. 4% monetized. few people getting north of 10%.

?: demographic information?

ffs: 60% female. 50% 20-25. 4th largest norway, big in saudi arabia.

power challenge: 90% male, 18-19 avg age.

texttwirl, etc: 60% women

warbook: 70% male

scramble: female and u.s.

texas holdem: make and foreign.

?:how important are incentives, like hint points?

word scavenger hunt.

{
w2e thu session 3, 4: data mining for social networks.

session 3 was on testing web sites, and was largely a review of BDD and rspec. good, not useful.

this talk concerns finding knowledge among social network data—emails/messages, recommendations, tags .. etc.

baysian filtering. once set up with some initial data, it classifies things by preferential frequency.

examples uses: personal ads. built a basic filter so you can detect what city they came from.

interesting breakdown of what people talk about, as separated out by a baysian filter.

distance metrics. could be people, concepts, movies.

preference distances—who is similar to each other? whose tastes are close? therefore, whose recommendations are likely to apply to whom?

(collaborative filtering) weight votes based on preferential distance.

linguistic distance. different are two texts?

valleywag – huffingpost > slashdot – wired. (for instance)

heirarchical clustering. group similar preferences (or whatever), chart in a dendogram. there is a chart with bloggers that’s pretty neat.

decision trees. yes/no characterizations in a graph. can be built automatically from any set of data.

hotornot.com example.

network analysis. PageRank, example. clustering coefficient. (how many of a person’s friends are friends with each other?) generally, social networks are highly clustered.

(network graph created with freebase, board members of major companies.)

(network graph showing twitter. holy cow, tight clustering.)

feature extraction demonstrated via facial recognition. using message boards? still works.

(this is fairly dry and academic.)

the book is ‘programming collective intelligence’.

that’s it for today’s sessions .. now i think i’ll swing by the twitter offices.

{
w2e thu session 2: influence is overrated

coming into this a little bit late.

(with jonah peretti)

we’re talking about viral marketing, and the effects of social influence on people’s choices on the web.

this is mainly based on an experiment with buzzfeed—some users saw the social data, others didn’t. there was a widely different distribution of popularity.

the problem: radical unpredictability.

accidental incfuential hypothesis wiggest that we can’t predict who will make something popular

the music lab experiment suggests we can’t predict what will become popular.

how to succeed anyway?

solution #1 contagious media

forget influentials and make something that people want to share.

make it easy to understand, easy to share, and include a social imperative.

(this moves very fast)

viral math: r > 1

each generation has to increase in repetition; at this point, it becomes viral.

nike ‘sweatshop’ email

he customized a pair of nike’s shoes that were customized with ‘sweatshop’. they mailed to say they couldn’t make the shoe.

he forwarded the email, which led to a viral cascade. it grew out into an activist community and reporters, even though the host wasn’t that into the issue.

example 2: ‘the rejection line’

example 3: blackpeopleloveus.com

hindsight bias—jonah is viewed as an expert in fields he doesn’t really understand, because of the growth of his viral efforts.

key concept: bored at work network— decentralized network that enables media to ‘go viral’ if ordinary people enjoy sharing it.

the problem: most things have a reproduction rate less than 1. contagious media is usually silly or fun. not so for products. the slightest drag or payload will almost certainly result in an R < 1.

solution #2: big seed marketing

sub-viral growth is still growth. small seeds lead to failure. 10 becomes 5 becomes 3, etc.

word of mouth without tipping point

examples: tide cold water challenge.

solution #3: mullet strategy

business up front, party in the back

front of the website is sharp, user-generated stuff in the back. neat front, messy and free backside.

let the good quality stuff bubble up. ex: dig.

contagious media – uses bored at work network.

big seed marketing – good return without tipping point.

mullet strategy – try everything and promote what works.

pimping http://buzzfeed.com – viral and trend detection

?: promotion v. discovery?

allow for discovery.

some pretty straightforward questions ..

?: non-social themes? (ex: recession) can you make anything funny?

almost anything. don’t get distracted from the core mission of the company. how do you tie it into the product? if the tie-in takes the R < 1 do big seed marketing.

?: how do you get the big seed? is there a way to get that going without a massive list?

same way on a smaller scale.

it ended .. abruptly.