one

TimeBridge and Behavioral Change

2010-07-12T09:03:00.002-06:00

Users rarely, if ever, change behavior. It takes unprecedented genius or beneficial workflow changes to get us to change our ways. We're lazy... bottom line.

A service called TimeBridge/meetwith.me changed my behavior. I use it religiously now. What's surprising to me is that the service touches the "third rail" of scheduling/calendar products which are notoriously messy and hard to get anything right with. TimeBridge says they "make it easy for others to schedule meetings with you" and incredibly, they deliver on that promise, when hundreds before them have failed miserably. How did they do it?

Setup for you is pretty easy. The site's not perfect, and there were bugs in app/screen flow, but it amounts to wiring their app up with your calendar app (Google Calendar for me). You'll be using a calendar app that either "works" or "doesn't." If you fall into the latter category, cut bait and pretent TimeBridge doesn't exist.
Setup for people trying to schedule time with you is... well... there really isn't any, and this is the critical piece. There have been plenty of apps promising to make scheduling easy, but they've all required everyone in the workflow to go through a mess of setup. Guess, what, someone scheduling time with me has never heard of TimeBridge, and certainly isn't going to go through any setup with it in order to schedule time with me. So, they've solved this by not requiring any setup for the ppl trying to get on your schedule.

Some of the flows are buggy or a little unclear, so there's lots of room for refinement, but the use case that matters is absolutely nailed. Well done guys. I'm impressed.

Ignite Boulder: Morning After

2010-06-25T08:37:00.003-06:00

Last night's Ignite Boulder was one of the better ones. It was the first held at Chautauqua's auditorium which is a great venue; though the audio was a bit off for the sparks (music sounded solid). I hope Andrew sticks with Chautauqua as a venue going forward (at least in the nice Spring/Summer months), it was nice to chill at the park before/after the event.

With increased popularity, the content feels like its starting to water down a bit. I want the edge back! Where's the heckling anymore?!? I do my part, but more often than not the ppl around me don't get it. The perils of mass mediaization; I wonder if you can ever get away from it en masse. If anyone can figure out the mix it's Andrew though.

A few of the talks struck me as particularly bad, and a few as particularly good. Some thoughts on the good ones.

Josh Fraser's talk on fear

Reminded me of Bowling for Columbine. We live in a culture of fear, and it's sad. Statistically everything's always going to be alright, yet we live with irrational fears that dramatically affect our behaviors. Why we do this is always a good question, and Josh got the numbers out there in front of us to laugh at. Nicely done.

Ryan's talk on selfishness

Should you be selfless or selfish? I've always lived my life as a selfish bastard, so I felt a little vindicated w/ this talk. Ryan's one of those rarities in life. Incredible ability to put the core of his being out there in front of everyone, and not in a lame way, rather in a way you connect with; he has true creative genius. Favorite line of the night [paraphrase/butcher]: "while trying to be selfless in trying to be what the one I love[d] wanted, I turned into something she didn't love at all because I lost my selfishness."

Ceci Ervin's talk on a trip to Poland for a surgical procedure to help/cure MS (which she has).

I'm not a sympathy vote kinda guy (back to that selfish thing), but she presented her quest in such a way that the faith and bravery simply tore through the screen and into the audience. Unbelievable journey with a happy ending. This kind of insight always makes me feel weak and useless, which then drives me to be more. Thanks for the perspective Ceci.

Can Google's Native Client SDK Fix The Web?

2010-06-13T19:47:00.005-06:00

Modern life owes much to the Internet. Many proverbial thanks are due to the inventors at CERN (incl. Tim Burner's Lee) and to Netscape (Jim Clark; the money. Founding engineers; the know-how) for making it accessible to all of us. A recent visit to Google's Boulder, CO office brought back that aching question for me though; is this all the Internet has to offer?

What if it never happened?

Would traditional client-server computing have been able to push network infrastructure (modems, hard-wire networks, wireless-networks, fiber, satellite) as far as the graphical browser has? If we had given it the years that the Internet's had, would we have skipped over and evolved past all the advertising, porn, and shopping that has become our network? I have to wonder if we have simply over-sold/hyped ourselves over the past decade, and subsequently distracted ourselves from the end-goal; better overall human computer interaction. The web is a complete UI/UX disaster, and has severely stunted HCI (Human Computer Interaction) efforts that can only come to fruition with deep driver/hardware bindings (e.g. Oblong - a firm you've never heard of that has the potential to change everything). We're still wallowing around inside web pages, building applications that have awful authentication/authorization models (how many usernames and passwords do you have?), and HTML5 is our latest savior?!? Please.

Getting Serious (again)

My recent conversation in the Google cafeteria challenged some base assumptions that I, and most of my colleagues, make; namely that web-apps are "it." That lunch discussion is well represented in a talk two of the key engineers gave at Google I/O 2010; Programming the web with Native Client SDK". When we were talking, what was initially described to me was something I could neatly, and conveniently, fit into today's browser plugin APIs. "Why not just use NPAPI; why re-invent the wheel?" I asked. I got a response that only someone with the know-how, and the resources could give; "because this [web as we know it] can't be it." I left skeptical, but it's been a month or so, and I'm there.

We'd be nowhere without the tubes that have been built. From a gazzillion miles of various types of cable/wire being laid all over the world, to IP/HTTP ubiquity. However, consider them a simple, yet crucial, layer in the client-server software model stack. Sure it's taken us 15 years to build it, but what if you chalk it up as "done." What's the next layer in the cake diagram that you'd pursue?

If we'd had this layer complete 15 years ago, the kings of client-server software at the time (Microsoft and IBM) could have started building highly distributed applications then, as opposed to trying to do so now (IBM quite successfully in more of an industry consultancy role, and MSFT arguably flat out failing at it). With Native Client, Google is trying to answer the question of what should software look like now that the connectivity layer is "done?" It's a cool question if you think about it and are able to extract yourself for a moment from our day-to-day web-app construction, and browser engineering realities; we have a hard time seeing the forrest from the trees.

It has a very long way to go, but a new way of executing "native" code through our "tubes" could open the door to a new generation of software. One that can harness the power of our hardware and the most important part of the Internet, namely the "tubes." While a train-wreck, recall the confines Microsoft tried to break out of with Microsoft Bob; knocking down the four walls of the traditional rectangle window managers that none of us exists without. Imagine networked software that can talk to your hardware to obtain identity information (something that requires a hardware component; you). These are things that we shouldn't be dreaming about, they should just be.

While Google's Native Client SDK goals seem audacious, they are also admirable, and if there's one company out there right now that has the power to pull something like this off, Google's it. Good luck.

Development Process

2010-06-07T22:23:00.004-06:00

Tonight I was asked some high-level questions about development process. I wound up responding w/ enough material that I thought I'd share the thoughts here for broader consumption.

Hey guys,
Please feel free to ignore this email but I'd extremely appreciate some advice if you have a couple of minutes. I am trying to compare best practices for teams over 10 programmers to determine what software development methodology has been the most productive for your company but at the same most fun for your team. If you have time I'd appreciate answers to the following:

1) Software Development Process used (i.e. Scrum, XP, custom)

"agile" (no scrum)... weekly iterations/sprints (no standup). have driven/done xp (pair programming mix) as well; I'd only go this (xp/pairing) route again if I were in a more supportive ecosystem (e.g. SF).

2) Do you track # of hours programmers work in a project?

never. bad idea IMO.

3) Do you have a QA team, if so how many?

no. though I've considered one or two QA folks... it'd definitely be nice to objectively do white/black box testing outside of dev. we're pretty close to TDD, so we've convinced ourselves we "don't need it." I go back and forth.

4) How often is your release cycle?

we deliver code to production once a week.

5) Who is allowed to deploy code into production?

we rotate who does the deploy (everyone on the team, including me, is capable of doing it). we run a shared responsibilty/exposure shop in order to reduce/eliminate the "john's the only one who knows that code/process" scenarios. my general philosophy here is if you're not hiring engineers that you don't trust well enough to do a deploy... you're liking hiring the wrong folks.

6) What project management tools do you use?

http://pivotaltracker.com . in the spirit of agile... we're very light on process/tools. never document something in more than one place (e.g. in the "story"), and even then be light.

7) How accurate are your release predictions?

eh. having tried (as mgr and individual contributor) everything under the sun... I no longer believe numbers folks toss out ("we're 90% on time" etc). I've found everyone's (mine included) numbers are BS, and if you dig into what actually transpired after the release... enough corners were cut, enough brilliant engineering ideas employed, and enough requirements were relaxed during the release cycle, that you never end up with what you started with anyway, so the A to B comparison and judgement of "on-time" is never valid. your mileage will vary though. it all comes down to the "unit"... the "team"... their cohesiveness, experience working together and trustworthiness amongst eachother. that said, if you handed me a green teem of folks that never worked together, I'd drive it agile-style with one to two week iterations/sprits (and production deploy) cycles with goal-level commitments (e.g. team committing to having x y and z done by date 'a'... and working as hard as they can to meet that commitment).

I'm Done Recycling...

2010-05-23T15:24:00.002-06:00

... at cafe's at least; sorry. I thought this get here, but after years of recycling I'm fed up. At home I can control the separation between compost, mixed materials, and trash/landfill. But... cafe's had made it impossible to recycle or compost anymore. Some provide compostable straws/lids/cups/napkins, but some don't; telling the difference between the two is all but impossible. The end result... I don't spend the extra 30 seconds it takes to figure it all out.

To further complicate things, everyone has their own cute recycle station with paragraphs describing what to put in which of the, at least three, bins. Guess what, I just hunt for the trash/landfill bin so I don't have to hurt my little brain by figuring out what is in my hand, and which bin it should go in.

I started recycling and composting long before it became popular/trendy, and have voted for every legislative measure to promote recycling over the past couple of decades I've been able to vote over. However, I hate to say it, the regulations around what can go where have turned me off. Humans are generally lazy and dumb. American's (of which I am one) like to throw unbelievable amounts of things away. Combine the two with today's recycling measures and I predict we're taking a step backward.

Once fairly clean recycle streams are now polluted with materials that don't mix and the energy it takes to clean the stream counters the benefits of recycling at all. Here's a decent writeup on the stream problem, and plenty have been written about Boulder County as well.

We need to mandate the production of compostable materials (cups, straws, bowls, forks, spoons, knives, etc) so, as consumers, we don't have to think about what we're about to "throw away." This should all be easy.

Take 2: Amazon S3 file deletion FAIL

2010-05-09T20:25:00.002-06:00

The S3 bucket key deletion saga continues. I had two Ec2 XL instances running 24/7 for about a month, running ~150 parallelized DELETE requests on s3 bucket keys (each machine), and dented my S3 usage by only 10%. I spent ~$1,500 (money went to Amazon obviously) on those dedicated XL instances in the process, while only reducing my S3 bill by ~10%, and that doesn't include the operational/engineering overhead to manage the deletion software/machines.

I'm left with only one option to wipe out the data on S3 that I don't need anymore; closing my Amazon account, and opening a new one. While I have high hopes that I'll be able to use the same keys/tokens/secrets in the new account, I'm doubtful. Thus, I'll incur several thousand more dollars re-wiring Gnip's vast network of machines, and RightScale, to work w/ the new account.

Lesson here is that you have to be very conscious when dealing with very large data sets on Amazon's S3.

Twitter's Ad Model; It's All In The Fraud Baby

2010-04-15T07:54:00.004-06:00

It's taken Twitter a long time to get where they are, and knowing some of their backstory has made watching the journey from the outside quite entertaining. A few things haven't changed: Biz pontificates and paints the "Twitter is a triumph of humanity" picture (exceedingly well I might add), Ev leads the flock with jagged thinking & speaking, and Dick is the one saying "no guys, really, we need to focus and make some money, here's how we're going to try to do it; no more goofing off." Ryan Sarver has his head squarely around the outward facing platform implementation and needs; he's an asset. Jason Goldman... I still can't figure him out.

On Making Money
Dick's pitch was pretty good. The idea is that tweets themselves are the commodity. Rather than some new model in the system, e.g. a formal "ad," the Tweet structure as we know and love it today, will be the item that is bought/sold. "Promoted" tweets, as Dick kept referring to them as, will float to the top of distilled tweet pages (like search, or top tweets, or trending topics, etc). The "float" algorithm will be affected by 1) whether or not someone's paid for a tweet to float up and 2) whether or not it resonates with users. #1 is obvious and will result in a marketplace for pricing/bidding/buying/selling (ala Google's ad model). #2 isn't as simple (not that the former is simple to begin with).

Resonating
I argue that the dirty little secret on the network today is that current ad models on the web are a sham; a house of cards. We've all made plenty of money on the backs of click fraud, and it'll eventually collapse. Twitter's trying to "do it right" by influencing a promoted tweet's visibility based on whether or not a promoted tweet resonates with users. Whatever your platform, when money's involved, it gets gamed. Whether it's bots doing re-tweeting, clicking, forwarding, generating, whatever, the bots will do their thing. When bots can't do it, cheap humans will be employed to do the machine's bidding.

"If a promoted tweet doesn't resonate, it will go offline." That statement was spewed, in one form or another, over and over again by the Twitter crew. I love the idea as a user, but if Google had squashed ads that weren't resonating with users, they never would have had a business to begin with (and arguably they wouldn't have one now if they moved to this glorious idea). It's all in the fraud baby.

The chicken and egg problem Twitter faces with an ad model is that you need many producers to build a marketplace, yet you need the marketplace to draw the producers. If you do the righteous thing and only display ads that resonate with users, guess what, you won't have many ads to show. Though users would benefit, ad prices would be so high (both in cost and quality) that not many people will pay for them. As a result, resonance is de-emphasized in order to stoke the overall marketplace.

Traditional Internet ad models are fairly simple pyramids folks... the bottom many subsidize the top. Both in terms of quantity, in order for the marketplace to exist, and the dollars.

The picture Dick painted was a pretty one. As an end-user, the notion of only being exposed to "resonating ads" (errr "promoted tweets") is a treat. I hope Twitter can change Internet ad history and actually pull it off.

Get A Job! At Walmart.

2010-03-20T16:07:00.003-06:00

This post inspired by a conversation I had with my mother this morning.

My mom has been self-employed for decades via a small business she runs. Unfortunately her industry has been all but obliterated by the usual "faster/cheaper" competitive model. She refuses to acknowledge that the American consumer is driven almost exclusively by money. She longs for, as do I, altruistic motives on the consumer's part, and moral high-ground. Specifically she's saddened by the decimation of local (state and smaller) government tax revenues, and the fact that consumers choose cheaper products over her more expensive, higher-quality, products.

The conversation led to "buy local" as the solution to the problem. While I generally agree, and do buy local all the time (spending more than many of my peers do; for better and worse), I realized long ago that a perspective counter to the one I'm surrounded by is significant. Namely, if you want to really affect global change, go work for Walmart.

Activists constantly fight "the man" in the form of Walmart, when in fact what they should do is go work for Walmart, and change things from the inside. Identifying processes that save Walmart money, and implementing them, will have more reach than me diligently buying produce at my local farmer's market ever will. For some perspective, checkout some generally recognized facts about Walmart, the largest company in the world.

When Walmart says "jump" every one of its vendors says "how high." If Walmart said "go green" every one of its vendors would do so overnight. Go figure out how to get Walmart to say "go green" or "create local, high-paying, jobs."

Oh yea, and if you don't like what Walmart does to your local economy, don't shop there.

Amazon S3 file deletion FAIL

2010-03-17T09:11:00.003-06:00

I'm a huge fan of Ec2 and S3 offerings from Amazon; they're the future. However, there's a severe deficiency in the S3 API; when you need to delete billions of files, the API breaks down. While there are batch operations, they don't handle enough keys to be of use when dealing with very large file counts, and enough requests are made over the long duration (days) of running your script, that expected errors wind up crapping out the whole process. Rinse-repeat doesn't work when the mean-time-between-failure is on the order of days.

Yes, I'm running the operations on an Ec2 instance. Yes, I'm using the almighty s3sync.

Amazon, you're printing money with AWS, please open up the deletion API so ppl can better manage their files. The current API's inability to a) delete non-empty buckets, and b) handle larger batch requests, feels a lot like greedy "lock-in."

Fast & Slow

2010-03-07T20:01:00.002-07:00

Pondering the meaning of life while bombing down Poorman the other day on my mountain bike, I realized the two things that have had the most impact on my two my favorite activities (coding and mtn. biking) serve two radically different purposes.

Disk Brakes. I got my first set (Hope manufactured) just last year. I'm a late adopter on the bike equipment front. The slowing/stopping power of these has totally changed how I ride.

Solid State Drives. I've been using these since they came to market. I'm an early adopter on the computer junk. The I/O speed of these things has totally changed how fast I can build & run tests.

It's the little things.

Multi-level Single Table Inheritance (STI) in Rails

2010-02-16T10:22:00.006-07:00

This took me more than one attempt to get right, so I thought I'd blat it out in a blog post in case anyone else has been struggling with it. In the end, the implementation matches your intuition, but getting the sub-classing syntax right took a few tries (undoubtedly due to my relative newness to Rails/Ruby).

Why would you want multi-level STI? When you're using multiple inheritance (class_c inherits from class_b and class_b inherits from class_a) and you want that relationship maintained through ActiveRecord; that's when.

Take the following three classes for example:


/app/model/a/class_a.rb
class A
 def method_a
   "a"
 end
end

/app/model/a/class_b.rb (yes, I mean dir 'a'. class_b.rb is a peer of class_a.rb)
class A::B < A
  def method_b
    "b"
  end
end

class A::B::C < A::B
  def method_c
    "c"
  end
end

Notice the explicit class hierarchy notation. Without this, I can't get the multi-level relationship maintained through STI.

From here, you can merrily create the class through ActiveRecord, assuming you have an existing table for the base class (which includes the 'type' column (where AR stashes the class hierarchy/name information for subsequent instanciations), and use all the methods.


A::B::C.create!
...
c = A.first
c.method_a => 'a'
c.method_b => 'b'
c.method_c => 'c'

Google Chrome for Mac

2010-02-05T21:03:00.002-07:00

I spent the past few days with Google Chrome for Mac as my default browser on my primary machine. I tweeted some notes about the experience if you're interested in the details.

I've reverted my default back to Firefox (3.6) however because of page incompatibility (rendering, JS execution, and lacking plugin support) issues I just don't have time to workaround with a new browser.

What I did like about the experience however were the DNS pre-caching optimizations that Google incorporated, and how child-tabs were handled; nice work!

Building a browser is hard. Good luck Google.

Does Browser HTML5 Support Matter?

2010-01-20T10:07:00.004-07:00

A few weeks ago I watched a saddening interview that a Google guy conducted in NYC; What is a Browser? It was sad because effectively no-one even knows what a browser is. The neat thing about that fact though is that the browser is so ubiquitous that people don't even know it exists.

The other day a co-worker and I were talking about whether or not HTML5 stuff matters anymore. Did Flash get enough market coverage to own "rich" client-side-software forevermore? Will content developers use HTML5 stuff? Are content developers relevant anymore? These are the kinds of questions that came up in the conversation. Here's my perspective.

Flash
It's done a lot for us (thanks Macromedia), but it's still too proprietary and takes too much tooling to do anything interesting with it. Furthermore, video quality (at least what the industry has adopted) is pathetic, and in a world wherein video is becoming more and more relevant (thanks to ease of production of HD content, as well as increasing bandwidth), it's not going to cut it much longer. There's a quarter-ton of Flash content out there though (e.g. YouTube), so, in some capacity, it's here to stay for a long time.

Content Developers
HTML5 exposes some incredible functionality at the JS/HTML/DOM levels. However, while the erosion of the plugin API walls allows for a more fluid/native/stable browsing experience, today's Content Developers aren't going to be able to leverage most of the features directly. Relatively complex programming concepts are making their way up the stack which is great (un-chain the beast!), but the Content Developer brains out there aren't going to map 1-to-1 with the skill-set it takes to harness the beast's strength. New tool chains (ala Macromedia/Adobe app suites) will have to emerge in order to allow today's Content Devs/shops to build using most of the new features.

Put another way, the folks I know leveraging

Gnip's 2009 Rocked My World

2009-12-20T13:33:00.005-07:00

After spending 2008 building a phenomenal development team, early 2009 tested me like I'd never been tested before. Half of my career has been spent building/managing teams, and I thought I had it dialed in. Along the way, feedback from individuals (peers, bosses, employees), raises/bonuses, and promotions reinforced an apparent self delusion. At the end of Q1 I was met with the proverbial dousing of cold water in the face. I was confronted with a "Jud goes or I go" situation. My heart broke (it's better now and stronger than ever). I stayed.

Compromise
Prior to that confrontation, while bouncing issues/ideas back and forth with someone who's experience I highly regard and respect, they suggested that I was "overly principled." It was an interesting choice of words I thought. They felt like a gentle way of saying "you're stubborn" or "you're inflexible"; something like that. I used to think I was flexible on the things I should be flexible on, and passionate about the other set. However the entire scenario caused me to reflect and realize that in fact I was incredibly rigid on a few things I shouldn't have been rigid about. I've since changed my approach entirely when working with people (bosses, employees, peers) to one that starts with openness, and morphs from there. Call me soft, but this approach is baring delicious fruit. Have I sacrificed too much? So far no, but only time will tell, and I'm hopeful that the answer is "no."

Any Monkey Could Play
I used to pride myself exclusively on being able to a) identify great opportunities b) identify, and hire, great talent, and c) rinse-repeat. The theory went that if you only pick winning ideas, and winning people, you will win. My perspective was that if you set that up, then the rest is cake. When churning on this with a friend they suggested "dude, if that's the game, then any monkey could play." With my tail between my legs, I realized the challenge is in recovering from the mistakes (that inevitably get made), adapting to uncontrollable dynamics (even the best laid plans fail), and persevering. Identifying great opportunities and people to work with is only the beginning, and frankly, it's the easy part.

To Thine Own Self Be True
My family will tell you I don't have an empathetic bone in my body, and it's likely because I pour my empathy into my employees. Earlier this year I learned that I was out of balance with this arrangement. My "overly principled" stance led to being "overly emotionally" invested in certain people, approaches and dynamics. I'd always been this way on the job, it had worked exceedingly well. However, when running a business, this isn't priority #1. If you're managing people in a mid-large sized company it probably is priority #1, but when you're trying to start something from the ground up, enough shrapnel flies around that folks are going to get hurt. My takeaway here is that I have to shift my empathy around a bit. This is a tricky balance between doing the Right thing from a human/people standpoint, and doing the right thing for the business. It's a different calculation for each person. I'm adjusting mine.

Back to that Flexibility Point
My partner and I have big egos, yet they come out in wildly different ways. Our initial approach to building the product and company left a palpable struggle over control in the air. The struggle nearly destroyed the company. Him being ultimately responsible, as CEO, things came to the ultimate head and we firmly hit the reset button on the company (we let almost half of the company go, we changed the product direction, and technology stack, entirely). We should have done it earlier. The bravery he showed in making that decision was admirable, and it's a lesson I'll take with me forever. While the words went unspoken, it was time for me to back off of a schlew of points that I'd been firmly holding. The ego struggle had to yield or the company would die. That's behind us now, and neither one of us has to expend energy in that space anymore, and we get to focus our energy on things that matter; like building a phenomenal product that meets our customer's needs.

If you're in an early stage startup...

focus on building the product, not the company. if you succeed, you can focus on the latter. there's a chicken and egg challenge here that's fun to play with.
if you're doing the previous thing, then you can't handle everyone with soft and fuzzy kid gloves. empathize with people, but be clear and concise around what's working and what's not.
be wary of too many cooks in the kitchen. I used to think that I'd rather deal with the challenge of managing multiple egos and blustering, but no more. I'd rather have one rooster on the team. As always this isn't perfectly cut and dry, but...
employees are happy to tell you what's wrong with your company, but will rarely, ever?, tell you what's wrong with you.
trust your gut; always.
do your best, and don't worry about the people around you. a year ago Esquire magazine interviewed Client Eastwood and he spewed this gem "As you get older, you're not afraid of doubt. Doubt isn't running the show. You take out all the self-agonizing."

This whole post feels cliche and as though I should have known all of this; heck I've probably been preaching many of these things. Always funny how life twists and turns.

Work hard.

Chaning My Computer Interface

2009-12-13T16:14:00.004-07:00

For a few weeks now I've been using fingerprint readers to login to my computers. Mostly an experiment to see how good, or bad, the technology has become over the past several years, it's turned into my preference for logging into my machines and accessing sensitive information.

The basic idea was to minimize the number of times per day that I have to type my 13 character password. Across my machines I estimate that I get asked for my password 36 times per day (not including websites, but that's a different post). I now respond to at least 24 of those requests with a finger swipe. The remaining requests still require password typing as those requests are to unlock my Apple keychain which the software I'm using (Upek Protector Suite for Mac) doesn't support yet (other than one-time global unlocking which I don't want to enable).

The reader accuracy is effectively 99%, so recognition, which I thought would be an issue, is a forgone conclusion these days; a non-issue.

I'm left wondering why all machines don't integrate (via mouse, keyboard, or body) fingerprint readers by default. Then again, I'm also the guy wondering why all machines don't come standard with retinal scanners. I know the answer to both wishes, but... dare to dream.

It looks like the Protector Suite software supports windows machines 10x better than it does OSX, but it's enough of a step up in user experience for me that I'm sticking with it.

A notable bug is that manual password override doesn't work when bring the machine out of sleep mode when the USB reader is NOT plugged in. Put another way, you have to always have the reader plugged in when moving in/out of sleep mode. This is a major annoyance when using a laptop as it means you have to drag the thumbdrive sized device along with you. The workaround is to cold-boot the machine and potentially lose data in the process. Upek blames Apple's Snow Leopard release, and is waiting for them to resolve the issue, which I suspect will never happen.

Feature Requests:

Firefox password manager support for Mac.
Background swipe monitoring for fast user switching. If I walk up to my home machine, which has 4 different user accounts on it, and the machine is logged into userA (I'm userB), I want to just swipe my finger and have it automatically switch me to userB.
Individual keychain access request unlock swipe support.
Physical hardware integration with all the hardware I use. iPhones, starting my car, all my machines, etc. The readers have to be all but free to manufacture anymore, so I'd like to see them as ubiquitous as built-in web cams please. Thanks.

My configs:

All machines running Apple OSX Snow Leopard
13" Macbook Pro laptop
21" iMac
13" Macbook laptop
One Upek mini/portable/thumb-drive sized USB reader
One Upek larger desktop based USB reader

IP Address Brokers; Please Stand Up

2009-11-21T08:07:00.004-07:00

I've been trying to formulate some clear thinking for awhile now regarding a major challenge on the network today. It's been brewing for years, and the proliferation of API usage is boiling it over. The power of open discussion is giving the topic some structure and vocabulary, finally, and I'll try to take a step further with this post. Rinse... repeat.

I spoke at Boulder's CTO lunch earlier this week and we got around to talking about the importance of IP addresses/namespaces/blocks in today's API economy. Josh Fraser (attended the lunch as well) does a great job distilling much of the thinking in his recent blog post.

History has taught us that control of information is a powerful economic motivator. Governments and economies rise and fall when regulatory constraints affect how groups of people, or individuals, access to the flow of information/goods. The control may be fueled by greed or survival, but somehow choke points always make their way into the system. APIs in high demand either put business controls on access, or technical controls in place in order to keep backend software running. These controls ultimately boil down to the only entity that is immutable by the time it arrives at a computer system's gateway; the IP address.

IP addresses are discrete and categorized. They are the single unit that can be perfectly controlled at the very edge of your network. Using them, your system can easily determine who to let in, and who to keep out on an individual basis, or by grouping "all requests coming from company X."

The advent of cloud computing allows developers to build applications across large IP address blocks owned by someone else (e.g. Amazon). I blogged about this potential fatal flaw a few months ago. This is a boon for developers, and abusers alike, and it's the latter bucket of individuals that will change the way IP addresses are used for API access. This will be the second coming IP addresses onto the field. The first major control ecosystem for IP addresses came from email and email spam. This new tier will come from APIs, and abuse/spam of them.

For months I'd been trying to figure out how to virtualize the IP address itself. In Ruby land, Heroku has pushed IP address allocation so far up into the stratosphere, that it's the closest thing I've seen to getting the IP address completely out of my way. It's only problem is that I still have to have knowledge of the block of IPs from which it draws.

As a developer I don't want to have to think about the IP address from which my software is making requests. I don't want to know if it's "clean" or "dirty" from the POV of the service I'm trying to access. I just want to access the service, within the bounds of its ToS. However, with cloud computing, I may be being punished because the IP address I'm using may be in a block of addresses that the service provider has "blacklisted" and constrained access to. This is bad and I currently have to spend time thinking about it, and working around it, much like legitimate email senders had to do yesterday. Today however, they can pay an intermediary to ensure the email gets through. I want an intermediary to ensure my API calls will get through.

Industries Born
In the coming months we're going to see router manufacturers make plenty of money providing more configurable IP routing/blocking/management solutions built directly into their firmware. Companies have productized their APIs, and ops teams are going to need easy solutions to managing the IP addresses accessing those APIs.

More significantly, we're going to see IP address brokerages emerge for APIs just as we did for email. Hundreds of millions of dollars are spent each year to ensure email gets through. Email brokerage is a big business, and I'd like to see those firms provide API brokerage as well (hint hint SendGrid).

Isolated Collaboration

2009-11-07T17:19:00.006-07:00

I periodically checkout the Mozilla Add-ons site to see what's new. I just grabbed Reframe-it given that a decentralized client, non-publishing platform specific, commenting model only makes sense. Sadly, no-one's using it; the sites I visited didn't have others commenting on content. This reminded me of the me.dium (now oneriot) sidebar I worked on years ago. Again, another solid decentralized collaborative client (centralized server) product idea, that consumers wouldn't consume. Again, sad.

As consumers why do we continue to do it the wrong way? Relying on publishers to install walled garden user feedback/comment models (IntenseDebate, disquss, etc) is a disaster. When does commenting/discussion break out into its own client/server/protocol (obviously reuse something on that front) so I don't have to rely on the Publisher to have done something w/ their site to support feedback loops. I wonder if Google Wave will gain enough momentum to cause real change here.

The industry is heavily weighted toward open protocols/standards that allow services to cross-communicate (oauth, openid, come to mind). While a good thing, I think we've swung too far to the server-side in this regard. Look at it this way, sans browsers (clients), we've got nothing, yet we're trying to build something (collaboration) based on servers/publishing platforms that have walls between them. That seems horribly broken to me. The model is ripe to have clients (mind you, potentially server-side operated clients... not strictly client-side-software... though in this case I suspect client-side is opportune) act as collaborative agents in order to get a sense of community across the network (not just within various walled gardens) at large.

I don't buy that customers don't want this; lots of people comment on blogs. It falls squarely into the "we don't know what's in our own best interest" bucket. It's going to take a consortium of the major publishing players (from news sites, media companies, blog services) to buy-in to a standard (ha!), or the client (browser) is going to have to force the UI/UX onto us; optional plugins/addons won't cut it.

The network is desperate for a revolution on several fronts. I'm hopeful there's enough steam in the collective invention engine to make some stuff happen. While I've enjoyed living through the advent of the Internet, I don't want it to have been the only major societal shift in my lifetime.

Like Father, Like Son

2009-10-20T22:11:00.003-06:00

Ahhh parenting.

Earlier this evening my wife and I returned from our seven-year-old's first parent-teacher conference as a first grader. We'd done a few when he was in kindergarten, but those don't really count as they're just too young to derive much from the discussion.

This one was hard.

I never fit in growing up. I probably still don't today, but as we grow older there are fewer and fewer clicks for folks to actually fit into, so things tend to find natural balance. At first glance it's looking like my son won't fit the general profile either. I feel bad for my wife as, if these early signs are a harbinger, she's not ready for what lies ahead in the years to come.

You see, I can be a tad pedantic, and my son is trending the same way. I've always been this way, and particularly in the early years, it really gets in the way. When other kids were blissfully unaware of what was going on around them, I was obsessed with my surroundings; people, authority (real & imagined), culture, structure, music, science, how the world works, etc. The challenge is that such an outlook on life doesn't fit the mold, so there is constant tension, confusion, and misunderstanding amongst the players.

The education system deemed me "too serious," "angry," "depressed," "anti-social," and on and on and on. As a result, I was always the odd man out. The models didn't work for me, so I got squeezed out to the sidelines while the majority gleefully marched along.

After some big bumps in the road, I finally figured out the game and realized it was easier to play along with everyone else for a few more years, then I'd be off to college and able to define my world the way I wanted it to be. I'd get to leave the constricted frameworks behind. All of that has worked out pretty well, though there are still plenty of constructs I don't fit in. I've learned how to adapt/adjust however, and life is good.

We talked with the teacher for awhile about some of these notions, and I imagined my parents' first parent-teacher conference with my first grade teacher. I'm sure it went the exact same way. My parents screwed up plenty while rearing me and my brother (we'll obviously do the same with our children), but one thing they did that blows me away to this day is they loved me, believed in me, and fought for me for over a decade of true mayhem.

While I hope we're just in yet another proverbial phase, in case we're not, I look forward to leading my son with the same love, perseverance, dedication and faith that my parents did with me.

To my wife, if we have to walk down this path, while it'll be petrifying, don't worry, I've walked down it, I know which turns to take, and amazing things are at the other end.

To my son (if you ever wind up reading this), I love who you are. I love knowing we see the world through similar eyes. We experience life in the same way, and that bond is truly amazing; we'll share it forever in ways few ever do. Embrace who you are and enjoy it. Being the black-sheep yields greatness. I'll always be by your side.

Nokogiri Performance: xpath vs. tree walking/iterating

2009-10-16T22:43:00.004-06:00

At Gnip we're doing some heavy XML parsing in Ruby and obviously chose Nokogiri as the underlying engine. I started the week doing xpath searches to tease out the elements/attributes from the documents we were parsing, and ended the week iterating over the root's children in order to achieve significant (~3x) performance improvements. While xpath is convenient, as you don't have to pay attention to document structure (assuming you have your head around xpath syntax to begin with), it's horribly expensive in terms of processing time. It's truly searching the document for what you want; expensive!

There's a big difference between using the "search" (e.g. xpath) interface on top of a parsed DOM and running over the entire tree, testing each node for what it is you're looking for. Code gets a little uglier when doing the latter, it's not as elegant/clean, but performance starts kicking in when you do it. Moving from xpath search-style parsing, to tree walking yielded ~3x performance improvement in parsing for me. I suspect that going all the way to either Nokogiri's Reader or SAX interface would yield an additional 10% improvement over that. However, I'm stoping here for now as the readability/complexity detriment in doing a full Reader/SAX stack-maintenance model doesn't feel worth it at the moment. I would like to try pauldix's SAX machine declarative parser (built on Nokogiri) and run some benchmarks, but... another day.

Old:


  doc = Nokogiri::XML.parse(some_xml_string) { |cfg| cfg.noblanks }

  doc.xpath('/xmlns:feed/xmlns:entry').each do |entry|
    at = entry.xpath('xmlns:published').text
    id = entry.xpath('xmlns:id').text
    ...
  end

New:


  doc = Nokogiri::XML.parse(some_xml_string) { |cfg| cfg.noblanks }

  doc.root.children.each do |node|
    if node.name == 'entry'
      node.children.each do |sub_e|
        at = sub_e.inner_text if sub_e.name == 'published'
        id = sub_e.inner_text if sub_e.name == 'id'
      end
    end
    ...
  end

Tahoe Weekend

2009-09-20T08:19:00.004-06:00

I'm wrapping up a perfect mountain biking weekend with some old friends. We've been riding our brains out for three days up in Lake Tahoe. One of the guys used to own his own bike shop, so he became defacto group-support on the trail. What a luxury it is having a mechanic on the rides; the slightest mechanical issue gets resolved in an instant. He also turned out to be a great cook, so instead of constantly eating out, we had fabulous home cooked meals to start and end the days. You rule Buck.

About half of the group consisted of locals (Truckee, Tahoe Donner) that one of my friends befriended when he lived up here for a few years. The local connection is always priceless. The right trails, the right subtleties, the right everything, instead of fumbling around like a pure tourist. One of the group owns a restaurant in Reno ("Beuno Grill"), and his annual community party coincided with our trip so we partied there last night. Great people, great time.

The main rides:

One of my favorite things about riding a hard-tail bike is when I get mixed in with soft-tail riders. There's nothing like being told "you can't do this trail on that" by a softie, and then beating them to the finish. I did get to ride some ultra-plush custom Ventanna full-suspensions though. I have to say, really nice rides, but just too disconnected from the trail. I need to feel what's going on underneath me, not be shielded from it. That makes for a good segue into one of the cool cars that came up.

The car enthusiast in the group brought up his new tricked out BMW M5 (500hp). While a killer ride with amazing power, the entire system is "drive by wire." Driving it was almost confusing as I lacked direct connections to the brakes, gearbox, and throttle. I want to be directly connected to a car with that much power. While BMW had done an incredible job pulling it all together, it was obvious there was a computer between me and the road.

I've been on V-Brakes forever, but after riding some HOPE branded hydraulic disk brakes, I'm going to switch over. The stopping power is incredible, and my forearms could use a break. I'm going to stay hard-tail though; all hard... all the time.

Great weekend. Nice to catchup with old friends. Nice to grind out some epic rides.

TechStars Pain Pattern

2009-09-17T11:26:00.008-06:00

Image courtesy of Colin Sackett | Book design & publishing.

I recognize patterns; large and small; over short periods, and long. Remember those SAT questions to find patterns in obscure information? I owned those. After my 2nd year involved in TechStars, a pattern has squarely emerged. Almost all teams build something quickly based on some LAMP stack derivative. The teams that "succeed" (e.g. find users/usage) always start asking performance related "help" questions.

"The application is slowing down." "The site is slow when we do a campaign." etc.

I wind up digging into a team's stack and inevitably see three things that always account for the bulk, if not being exclusively, "the problem."

Page loads cause complex SQL queries to be run. Don't do that. It's cute and easy when you don't have usage, but it won't work when you get traction. If you did it for expediencies' sake, fine, but plan on undoing it later. DB's can crater any good application. Cache the data your users want so they don't have to hit a DB for it. You can't always tear a DB out of the flow, but try, and try hard.
The server does more processing than it needs to do. Use your users. They have powerful computers and browsers that can execute code very well. Shunt rendering of data/objects down to the browser via JS (or Flash), if this becomes a problem. Do you really need to parse that DOM on the server for every page-load to derive the list of things you want to show the user? No, let client-side JS do the parsing/sorting. This line is always fine however; overburdening the browser doesn't buy you much. Point is, find the balance. Your goal in life should be to serve flat files that require nothing more than Apache connecting an IP socket to a file descriptor to let the OS shuffle bits to and fro. Follow that path and good things will come. Flatten your stuff before a user accesses a page on your service, not when they do.
Don't store images in a database. C'mon, seriously. Worst case store references to said images that live out on a disk (or CDN) somewhere. I'd argue you don't even need to store the references if you get your model right; your app should just be able to derive an image's location based on some pattern. Ahhh, full circle.

On a related note, at a local "CTO lunch" the other day, Todd Vernon recited an old blog post of his called "Scaling Your Startup". A few of some of these principles are reiterated there.

Can't scale? Be Sure To Blame Your Code.

2009-09-11T09:53:00.004-06:00

Web app scale bottlenecks (software & hardware) have leapfrogged themselves a few times over the past 15 years, and I just came across a concise view of how software had to react once hardware/bandwidth reached a new speed/throughput tier back around the year 2000; http://www.kegel.com/c10k.html

The C10k problem, and solutions, document is a fabulous overview of the techniques used to eliminate software servers as a bottleneck. Thus, hardware became the bottleneck again.

If you can't meet your application's user demand it is because you haven't written the correct software to do so. You can try to blame the fact that you don't have enough hardware/bandwidth, but that problem is solved with the flick of a pen (money). Your challenge is solving your software problem. Enough components in the stack (from web servers, to application servers (custom if you have to) and data storage solutions) solve the C10k problem now, that any issues in your application software are likely yours. Find better tools/components, and/or write better code.

If you don't have the money to acquire the hardware you want, you might be working on the wrong thing.

Fatal Flaw in Cloud Based Social Media Apps?

2009-08-24T11:54:00.001-06:00

For the purposes of this post I'm going to define "cloud computing" as a service that allows you to easily run your application on someone elses' infrastructure, and importantly, within their IP address block range.

As "web app" web API usage continues to grow, the significance of the long forgotten IP address as a fundamental application stack component grows along with it.

Public facing web APIs are accessible via publicly facing IP addresses, by applications running on other publicly facing IP addresses. When the demand for a polled web API outstrips supply (artificially imposed or otherwise), engineers throttle access to said API based on the consumer's IP address. The consuming IP address is the only guaranteed uniquely identifiable attribute of a "web app." Therefore, it is the one thing that can guarantee the rate-limiting of a resource.

This was all well and good when standing up your web application in an environment with its own IP address was relatively difficult. However, with the advent of Google App Engine and Amazon Ec2 "clouds," "web app" deployment is trivial. The result is a lot of software utilizing a relatively constrained resource; the IP address.

The overuse and abuse of web APIs is well documented and many services have been brought to their knees as a result. Operations teams have had to fall back on age-old IP address blocking techniques in order to protect themselves. Unfortunately, for cloud computing services, this means their IP address blocks/ranges are often black-listed, which leaves legitimate web applications built on top of them out in the cold.

The historical parallel to this kind of black-holing of IP address ranges goes back to ISPs restricting email from servers which would consistently allow spam through their gateways. Any email provider of size has black-lists of known wrong-doing IP address blocks, to ensure their system's (and their user's) aren't crushed by the onslaught of spam. While a reasonable model for blocking spam, the thought of the same model being used to control web application innovation is frightening.

That said, the market will decide whether or not the IP address will remain the canonical access regulator. In many ways any other version of the future is incomprehensible, but now that the IP address has become such a fundamental part of an application developer's daily life, I have to think a new construct for cross-machine communication will evolve.

Cloud providers can either live with the fact that their IP address blocks are being limited, and have web API leveraging "web app" developers move away from their platforms, or they can work to find a solution. Unfortunately for them, their entire frameworks currently revolve around relatively contiguous IP address blocks, and changing that isn't easy given their operating scale.

As with any constrained resource, developers will work hard to obtain it, and web APIs are no exception.

Dirty Data, Python & Gnip

2009-08-17T09:50:00.005-06:00

I've been tinkering with Python (2.5) over the past few months; both in Google App Engine, and in free-running apps/processes. My initial free-running apps ingested "structured" content from a variety of web APIs, and would crash roughly every 12 hours, and would need to be restarted. Subsequently I took a "short-lived" process approach to managing these apps; cron would monitor them to make sure they were still running, then restart them if they'd died.

More recently I built an app that digested data from a known clean API (Gnip). Digesting data from Gnip ensures consistency in data format and structure. As a result, the Python app has been running for several days without issue. Now, of course the initial app crashing was due to bugs in code I wrote, but bulletproofing against broken/dirty/poorly-encoded/inconsistently-encoded data coming from random web APIs is a pain. Covering every case in modern apps takes a lot of energy. I opted for the "bounce it" strategy rather than to debug the issue (a major time sync due to variability and inconsistency; any engineer's worst nightmare).

The new application has instilled faith in Python as a choice for long-lived app processes, and reinforced how important clean input data is.

Sarcasm and Sentiment Analysis

2009-07-08T07:10:00.002-06:00

Sentiment analysis of digitized content (tweets, email, blog posts, etc) is hard. Sarcasm makes it even harder. Consider how many sarcastic comments are made in our online communications each day. "I love being delayed at the airport." "I can't stand it when everything is going my way." etc. Analyzing text like that has got to throw even the best sentiment analysis engines for a loop, and the false positives start flying.

If you're sarcastic, like me, you've learned to keep your sarcasm to a minimum when you're writing because the context just isn't there for your reader, much less a machine, to understand the subtle shifts in tone or where you're coming from.

I'm looking forward to sentiment deduction getting better, but I'd like to see how the logic evolves to understand age-old sarcasm.

Maybe we will all just stop being sarcastic to support the machines running our lives.