one

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.

Speed Date with Google App Engine

2009-07-02T14:41:00.002-06:00

I assumed that in the months since the announcement of Google App Engine, that its glaring HTTP client deficiencies would have been resolved. Nope.

Any modern platform needs a robust HTTP client (timeout controls, full method support, custom headers, compression support, authentication support, and redirect handling). Unfortunately, GAE's urlfetch client (which the standard Python HTTP clients all funnel down to) doesn't let you tweak various headers (including Referer). Nor can you customize the connection timeouts. Both of these tweaks are tools of the modern day web services programming trade. Subsequently, I have to cast GAE to the tinker toy pile with the rest of today's high-level web apps. A quick look at the app repository proves this out sadly.

On the other hand, take a look at what's been built on Amazon's AWS. Goes to show what you can do when you have an open platform.

That said, GAE does show promise for hosting simple user facing web applications, or offline data crunching/hosting apps (ala google.com) with quick user facing response times and little reliance on the outside web.

TechStars Boulder 2009: Half-Time Report

2009-06-26T19:57:00.005-06:00

The other night I attended the first "pitch practice" for this year's set of TechStars Boulder companies. Watching the evolution is always fascinating. So far, my first impressions are holding strong. Those who I suspected would struggle, are struggling. Those who I expected would be knocking it out of the park are doing so.

Comparing and contrasting the 2009 crew to the 2008 crew, I find that this year's companies are, on the whole, more mature than last year's. More companies this year have their products further down the path of where I think they will ultimately end up, than last year. It's been nice to work with teams that are more crystallized in their thinking and implementations. Of course, there's always the crew that bounces back and forth for awhile until they hone things to the point they can walk down a straight line.

For those doing user facing products, the focus on the concepts that will "hook" a user is much better than last year. Too many priorities tend to doom a team, and recognition of this is coming fast. That said, there's a big difference between knowing which features to drop and actually dropping them; it can be hard to let go.

For those doing more infrastructure intense products, the technical skills brought to bare, and understanding of the issues at hand, is much more advanced than last year. The infrastructure plays have a special place in my heart so it's been fun to work with folks doing more backend stuff.

Of course, there's a star burning hotter than the others. This team has taken a problem that billions of dollars have been thrown at, to little avail, and turned it upside down. As a result, they have a phenomenal product that is going to do things for an industry that has been begging for it for decades. Brilliant, and totally cool. I can't say who it is, but it will be apparent when the season's over.

Some technical patterns/themes that pervade almost every team this year:
- Polling. Mashing APIs together is the norm now, and the access paradigm overly leveraged is polling. Conveniently my company Gnip (http://gnip.com) is trying to make this easier.
- Queuing. Polling's ugly sibling. More teams are challenged with queuing needs in their application which bumps complexity up a notch. The simplest advice is best here. Queuing Theory 101: if the average inbound rate of items is greater than the system's ability to digest them; you're screwed, rethink the model.
- Data Storage. "How am I going to store all that data in an access efficient manner?" The inbred offspring of Polling and Queuing, data storage challenges are real for a few of the companies. For the others, the age old simple relational DB model will foot the bill.

One thing that will never cease to amaze me is the energy, passion, and commitment that radiates from the teams. Amazing.

Boulder is lucky to have this program, and I'm lucky to be a part of it.

Faithfully Breaking Rules

2009-06-18T20:38:00.003-06:00

Spending a week on a 15k person island (Martha's Vineyard) with family has made me think about breaking the rules in more ways than one. Reading the local paper this morning reminded me of how important it can be to break the rules. One of the bakeries in Oak Bluffs opens their back alley door at 10:30pm every night to sell doughnuts as they're coming off the line; all night until 7am. I'm sure they're breaking numerous zoning and health code rules in the process, but needless to say with a population of this size, everyone loves it, and no-one cares; no harm no foul.

The "family" aspect of this vacation has me bending/breaking, and enforcing, numerous parenting rules as well. Ice cream everyday? No problem. Licorice before breakfast? Sure.

Reading about President Obama's Finance industry reworking got me thinking about "bigger" rules that affect our everyday lives, indirectly and directly. That turned me to one of my favorite, and brutally simple, rules that we, internationally and cross-culturally, effectively never break: "stay on your side of the road when driving."

Think about it. Everyday millions of people drive two-thousand pound chunks of metal at high-speeds in opposite directions, with nothing more than a couple of feet between them as they pass eachother. There is some base rule that taps into our mortality that truly prevents us from breaking this rule. We have faith that complete strangers will adhere to the rule as well. We hand our lives over to other drivers everyday. I always like coming back to that one as it's an interesting exercise regarding faith in others.

Photo by: William C. Beall of Washington Daily News

"Mommamacations" & Perfect Software

2009-06-01T08:25:00.006-06:00

My 6.5 year old son and I built a Lego Mindstorm vehicle yesterday. After constructing it, we wrote the software for it. After watching version 1.0 of our software run for about 5 seconds, we noticed a bug so we iterated, fixed the bug, and ran v2 of the software. After about 30 seconds we noticed another issue with the number of degrees the vehicle was turning when it confronted an obstacle. We tuned the software to increase the angle to 90 degrees, compiled, pushed code to the vehicle, and ran it.

This version, v3, of the software ran for awhile. It ran at home, at his grandparents house, and again this morning. It ran well, for a long time. However, a few minutes ago we found yet another refinement we could make to the turning angle to make it get out of a jam even faster, and I said "aha, I found another modification we can make!" My son replied, "let's make all of the mommamacations [sic] this time." He wanted to write the software once, without bugs, perfectly.

I went on to explain how it takes time to understand how software is going to work in the real-world and how you can't account for all of the variables and scenarios up front. As a result, you build, test, and refine; you iterate. You can't write it once and have it work perfectly forever.

He didn't fully grok it, but its starting to sink in. It was a neat interaction with my boy around what my world is all about. Ha! My daughter just yelled out "am I doing ballet today?" Gotta run.

Google I/O: My Impressions

2009-05-31T19:16:00.005-06:00

Photo from Matthias Schicker's post.

I attended last week's Google I/O 2009 conference in San Francisco. Here's what struck me.

HTML 5
Some friends and I debated what the punchline of the show was over dinner one night, but for me, it was HTML 5; the browser. The entire introduction sequence was about JavaScript execution, rendering speeds, & HTML 5 standards. The five minute automated intro demo before the keynote demonstrated web browser functionality, literally, using a web browser for everything. This theme was downright entertaining. HTML 5 is the distillation of everything we've wanted/needed in the browser over the past decade. What's particularly funny about HTML 5, and in Google's all-hands-on-deck push for its implementation across the board, is that, without exception, all the relevant portions were knocked together (in prototype form at a minimum) a decade ago between Netscape/Mozilla, IE, and Opera. The entire two days felt like a browser resurgence.

What I liked about this was that Google had the gumption, and obviously the money, to make something old, new again. If you ever spent time working on one of the major browsers, you too see the world through HTTP/URL/JavaScript lenses. Those technologies unlock everything. It was cool and fun to be part of a conference dedicated to these concepts.

Wave
I left about of a third of the way through the Wave introduction. Again, 10-year old communication/message-threading concepts being demonstrated in front of a technical audience of four-thousand. My initial reaction was, yawn. I've always loved the notion of treating messaging more centralized (in a logical sense) both from a backend protocol/storage standpoint, as well as from a UI perspective. Naturally flowing between an asynchronous email conversation, and a synchronous IM conversation, will be a beautiful thing when we finally get there. However, it felt awkward having one of Google's top three themes be Wave.

Architecturally Wave appears to be able to get us there, however standing up Wave providers en-masse will take a long time (consider how long it took for SMTP/POP/IMAP to proliferate).

I'm particularly excited about Wave's leverage of XMPP (with extensions) as the connection/protocol model, though; feels very fitting. Furthermore, Cisco's acquisition of Jabber last year is feeling like a sweet decision right about now. Imagine Cisco's XMPP routers hardened for Wave Providers; nice dovetail.

Android
Google handed out four thousand Android/HTC mobile's in hopes of spurring Android development. I've gone so far as to pull down the SDK and do some dev "how-to" reading, but I've gotten distracted and have moved on. There are three fatal flaws with Android and the HTC device.

The soft-keyboard is too small which makes it very hard to type. This is purely a function of the device/form-factor which can/will change over time.
No iTunes/iPod. There's a media player, but my world is painted in iTunes (for better or worse) and it's already a sync'ing nightmare so I'm not about to add another framework into the mix. My "phone" and music/video are on one device (iPhone) and I can never go back to multi devices. If anything, the iPhone has replaced my laptop as well on an occasional business trip.
The browser is all but useless. This shocked me, but the UI metaphors (which I'm sure some of which Apple has patented) on the iPhone Safari browser are so well done, that anything less on such a small form factor is a huge step backward.

Joseph Smarr on "The Social Web"
Smarr's always good to watch/hear. He understands the high-level yet always has his hands dirty with the actual hand's on implementation. He underscored how much things have changed with respect to OpenID and OAuth adoption over the past 12 months. Very true, and great to see. He mentioned Gnip, and Plaxo's integration points with it, which was much appreciated; thanks Joseph!

"Spelly"
One of the tracks was about "Spelly"; notably the server-side spell checker used in the Wave demos. What was so cool about this spell checker is that it was backed not by a dictionary, but the statistical probability (language independent) of a word being spelled correctly based on its position relative to the surrounding words. For example "Let's met tomorrow" slammed against the corpus of indexed web documents illustrates that the vast majority of the time words starting with 'm', between "Let's" and "tomorrow" are spelled "meet", not "met." So cool!

App Engine + Java
Google's hamstrung Java to about the same degree they did Python in App Engine. If you're a high-level Java hacker you might have fun, otherwise this was a solid miss (at least for now).

Boulder & California

2009-05-17T11:32:00.005-06:00

While playing with my daughter this morning she pulled out the key-chain pictured here. I noticed that the "Boulder" sticker was sitting on top of another. I peeled it back and found "California" underneath. Growing up in Boulder, spending four years in Silicon Valley, then moving back to Boulder to help build and grow our software/technology sector, caused me to view the picture through several lenses.

California is passe and products/companies/people are re-branding themselves as Boulder which is trendy.
The key-chain manufacturer decided to put California stickers on the keychains as they came off the line, then localize the keychains on-demand and in smaller batches when needed, in order to save cost.
Some of Boulder's entrepreneurship is really California underneath.
Some of California's entrepreneurship is really Boulder underneath.
The Californication of Boulder is real.
The migration of Californian's to Boulder continues.

A few friends of mine have written some interesting pieces on Boulder along these lines.

Micah - I am Boulder, Hear me Roar
Andrew Hyde - http://andrewhyde.net/
may others that I don't have time to track down given my kids are unattended in the front yard doing a lemonade stand.

While I'm here, I'll plug what's turned into a phenomenal entrepreneurship and technology incubator; TechStars.

Pair Programming & "top notch programmers"

2009-05-14T14:25:00.005-06:00

Gnip is hiring again so the flood of recommendations/resumes/suggestions has begun. Gnip's a pair programming shop which means there are two developers for every CPU in the office, and two developers sit side by side, day in and day out. Pair programming isn't for everyone, and many simply aren't cut out for it. When hiring for a pairing position, digesting recommendations of "rockstar" or "top notch programmers" as friends/colleagues forward resumes along is often like trying to fit a square peg into a round hole. As an aside, checkout my previous posting on rejection and our hiring process.

The majority of developers come from non-pairing backgrounds, and therefore the good candidates have learned how to build amazing code alone. They've built a reputation for being a rock star while sitting at a desk by themselves', knocking out software. It's hard rejecting incredible engineering talent because an individual doesn't play well in a pairing environment, but it's something we have to do at Gnip.

If you know a killer developer who you're thinking of pointing at Gnip, please consider their pair programming passion/tendencies before sending them our way. If neither exist, they're just not going to fit into our culture and process regardless of how talented they are.

State of Boulder Dinning

2009-04-22T04:05:00.003-06:00

Boulder's at an interesting juncture when it comes to it's restaurant offerings. If you adhere to the notion that opening a restaurant takes at least 12 months of planning, our new crop of joints are the brainchildren of plans concocted prior to the economic disaster that unwound over the past year. What follows is some speculation around the new spots in town, and some perspective on some of the staples.

The New Guys
Two major components have shifted since the inception of Happy Noodle House, Terra, Full Belly, and Arugula; the small/mid-tier banks that lend to small businesses (e.g. these restaurants) have stopped lending, and diners aren't as fast and loose as they were a year ago.

Happy Noodle House
I'm loving Happy Noodle House these days, though the nearly 100% "community table" (aka "European seating") is taking some community adjustment (both on the part of the staff, as well as the customers). Their price point, quality, location, the fact that they're fully operational, and connection to Dave Query (nearly bulletproof), have me bullish on their longevity.

Terra
I'm highly skeptical of Terra's plan. The location is choice, the chef's got promise, but the build out is expensive, and the price point is likely to be mid-to-upper tier as well. They'll get pit against the ever successful Kitchen which ought to be an interesting battle. I don't think Boulder can support two "Kitchens" effectively adjacent to one another. That said, Kitchen's offering became overly consistent a couple of years ago for me. Every time I go, I know what my food's going to taste like, which leads me to believe the consistency in low-level flavors (be it the olive oil or butter used in *everything*) which contributed to their success, is making the experience too predictable anymore. Terra may be able to siphon off bored Kitchen customers.

Full Belly + Arugula
As for Full Belly and Arugula, they're so far off the beaten path for me (my tiny world is confined to downtown) that I still haven't eaten at either. Assuming they're both delicious, Laudisio proved the location doesn't work, especially with two upstarts being adjacent. One will fail, the other will limp along.

Jax Fishouse
As for Jax Fishhouse. I'm stoked for Hosea for the Top Chef win. We've religiously gone to Jax every Thursday night for over a decade, but... the Top Chef status stuff has since ruined the experience for us. Dishes are bigger (see my post on trying to get dishes to be smaller), crowds (tourists) swamp the joint now, and the soul in the food is gone. We've stopped going, and will pick it back up in 6-12 months, when hype has died down, to see if things get back to normal.

Frasca
Frasca gets its own section. The food remains impeccable and the staff remains committed and top notch. The location remains unfortunate. I'm hopeful they find a new location soon. I'm bearish on the 9th & Pearl development actually happening which would leave them at 18th & Pearl for the foreseeable future. I can live with that however. I go to Frasca to be surrounded by people (staff & patrons) who care about food and wine, and to have the best of both served by professionals.

Brasserie Ten-Ten
This is the ringer in the bunch. They've nailed it! Brunch, lunch, dinner, happy hour... you name it. The restaurant acclimates to the time of day, and day of the week, incredibly well. Food is consistent and flavorful, and the wine list is broad and deep. A few years ago Ten-Ten was highly suspect to me, but now I can bank on it anytime for a good experience. The build-out is quality as well.

There you have it. My insomnia fueled blog post on my view of restaurants in Boulder at the moment.

Twitter: Niche Advertising That Actually Works

2009-03-27T10:54:00.003-06:00

Advertising is all about getting information about a company/product/service in front of a demographically appropriate audience to tease them into spending money on said product/service.

When everyone used to spend most of their time in front of a live broadcast television, television ads were used to convey a product/service to general consumers. Then the internet and Tivo hit; destroying the Television ad market. Internet ads are all but useless now as well (Google will one day have to own up to the click-fraud reality that underpins its financials). So, I'm left adrift in a free-market economy without a way for advertisers to reach me. Bummer.

Twitter is changing this. The companies/products/services I care about have figured out how to get to me, via Twitter.

Twitter provides a broadcast system system that smart businesses are using to reach out to relevant people. I don't have to waste time consuming ads I don't care about. Instead I get to selectively choose which businesses I want to hear from when some new product/service/discount/sale becomes available. Finally, the consumer is in control, and the advertiser doesn't have to mess with subscription lists (email/snail-mail/phone numbers) to reach me. All I have to do is "follow"/listen to the "channels" I want, and if I end up not liking the company doing the advertising, I can turn them off.

Feels darn close to a perfect advertisement communication system to me.

For example, local companies I "follow" who tell me about real-time services they provide are listed below. They get advertisements in-front of me, when I want them, and I make real-time purchasing decisions as a result.

https://twitter.com/TeeandCakes (just bought doughnuts from there because they tweeted that they had arrived)
http://twitter.com/twospoonssoups (not eating there today because the soup I love isn't avail today)
http://twitter.com/spudbros
http://twitter.com/larkburger (they're not in my daily walk/flow, but now I get good reminders of them and can decide to head over there when in the mood)

More advertisements via Twitter/broadcast please.