Stay Hungry

thelaurenproject:

And Lo, it was at 10:10am on 11/10/11 that Lauren found herself on the 10th floor of a building marked 110 in New York City (10010). It was noted that this was, like, so totally binary, and the brogrammers of Shelby.tv smiled upon her and saw that this was good. 

Hiring is straightforward; you need to find a great person who is passionate about building your company, fairly smart, and meshes well with the team (then let them loose!).  But hiring is difficult; finding these people (at the right time) is not often easy.

It took me 6 years to hire Mark Johnson.  While that’s a bit of hyperbole, I have known since graduating with Mark as Computer Engineers from Brown in 2005 that I wanted to build a startup with him.  He’s a phenomenal engineer.  Nobody pushed me harder in college.  And looking back, I’m still impressed at so much of what we built.

But we built that stuff for our professors.  Now we get to build for ourselves, and I couldn’t be more excited.

The Shelby team was already fucking awesome - returning from 10 days off the grid in Cyprus gave me even better perspective on that.  And now we get to add Mark to the formula (VMWare had him pushing too many pencils).  There’s so much more I could say, but I think this picture of Mark at our brand new west coast engineering campus says it best:

We launched a pretty big UI update today and people seemed to generally enjoy it.  But we also launched a little gem that probably went under the radar: full screen mode (without Flash!).  If you’re running Safari 5.1 (on Mac OS X Lion) the “expand” button in our player controls will bring you into true full screen mode with our full UI.

This functionality is supported in Lion via WebKit (the rendering engine behind Safari and Chrome).  Although Chrome doesn’t yet support full screen, once it gets up to speed with Safari, you guys will get true full screen mode too.  In fact, any browser on any operating system that supports the new HTML5 full screen spec will get the same fancy treatment from Shelby.

How do we do it?  Pretty simple; here’s the actual code running in production:

$(“#app-holder”)[0].webkitRequestFullScreen();

document.webkitCancelFullScreen();

If you’re on an iPad, that’s cool too.  You have to click the full screen button on the video element and our full UI won’t be there (due to limitations in the YouTube API and mobile Safari, respectively) but you’ll get big beautiful full screen video (despite Apple trying to hold HTML5 down!).  And I almost forgot, AirPlay just works*.

*actually, YouTube HTML5 video AirPlay has been broken for a couple of weeks now.  They broke it, not me.  So once YouTube and Apple get that straightened out, AirPlay will be back.

Who has time to blog?  With all the code that needs to be written, engineers that need to be hired, servers that need to be cared for and email that’s piling up, I often fall behind on my blogging.  But not today!  We just raising $1.5MM so I have all the time in the world to fuck around…

That’s absurd, obviously.  And as Reece points out, this round is but a stepping stone; not a measure of success.  As his cofounder, and independent thinker in general, I’m in complete agreement.  But as his best friend, and generally a douchebag, it’s my duty to undermine just about everything he does.

Momentum

Startups are great because your momentum is so obvious.  Everyone has a big impact on the company, and we can all see how our push on the flywheel keeps it cranking.  This round was another push, a great one.  And while Reece rests for a year or so, until he has to raise money again (i.e. do his job), the dev team will make that wheel fly.

Morale

If Reece tells you he doesn’t like being the center of attention, you can be sure he’s doing so atop a soap box, in the middle of a crowded room, yelling at the top of his lungs.  The rest of us like it too (even the cyborg from the future, @mkrecny).  And although we didn’t raise Color money, it was pretty fun to be the cool kids on the web for a few minutes yesterday.

Do you want to live forever?

I do, but probably won’t.  So I try to remember to take opportunities to celebrate the small wins.  It’s a good thing.  It doesn’t mean you sit back and relax, but it’s good to step away, high five everyone in your zip code, then get after it, hungry for the next win.

Champagne

Wizard Sticks is a drinking game where you duct tape each can of beer you finish to the previous cans you’ve finished, end-to-end, thus creating your wizard stick.  HackStar and good friend Rebecca Zhou recommended we play that game with champagne bottles.  Sounds like an engineering problem fit for a duct tape promo spot!  But stick-in-the-mud Reece said you cant haz shampane :-[

Stay Hungry, Stay Foolish

In many ways it was easier to run a bootstrapped company.  This cash brings pressure.  But it’s a great kind of pressure, the kind that makes this team perform better.  I had a dream last night where Long Island was sinking into the ocean, and I had to rescue my family.  That’s the kind of adrenaline-pumping ass-kicking pressure I feel.  I dominated in my dream, going so far as to take a boat to Falmouth, MA and rescue Reece from his parents basement.  Now I’ll do the same with Shelby.

Expect everything.  Earn everything.  ;-]

p.s. With $1.5MM, at 4 dollar bills/s, you could make it rain for over 4 days.  You would also need a Defibrillator™(Jager-bomb + 5 hour energy) or two.

Recommendation Fail

There’s been a lot of noise about recommendations and relevance as of late.  Recommendation-fail happens in two major ways.  Your “Filter Bubble” - pioneered and explained well by Eli Pariser (founder moveon.org) in his TED talk - is algorithmically created by the services you use, tailoring what you see and preventing you from even knowing what you’re missing.  But your Filter Bubble only let’s through what it naively deems “relevant” without promoting different, challenging or uncomfortable ideas.

The second big recommendation-fail is social recommendations.  This is the kind of failure that keeps happening again and again, as they intuitively make sense.  But there is a fundamental issue with many social recommendations: we’re not necessarily all that similar to our social network-friends.  There’s a good, deeper discussion on quora but suffice it to say, your taste graph probably doesn’t look much like your social graph.

Illustrations of each come to mind in the music sphere: Pandora and Turntable.fm.  Pandora, which just IPO’d to a chorus of scrutiny, sets out explicitly to create a Filter Bubble.  It does a great job, but sometimes it’s too good and I have to put it significant effort to change it up.  Turntable.fm, on the other hand, leans towards social recommendations.  Sure, I can hang out in a random room, but it’s more fun with my friends, and their musical taste is very much unlike mine.  The DJ’ing aspect helps a bit when people try to keep a good trend/theme going.

Better Recommendations

Mixing the two approaches (algorithmic relevance & social recommendation) can provide a huge improvement, but it’s incomplete.  How do you provide significant variety of content and serendipitous recommendations with these givens?  Add a Noise Dial.  Don’t take away social recommendations, they’re useful (I can’t think of many TV shows I currently watch that weren’t first recommended by a friend).  And don’t make the algorithms too “smart” (aka sterile).  

Give your user a Noise Dial (balancing transparency with added complexity), whereby they can expand the horizon of algorithmic recommendations, and the tools to maintain that expanded horizon (i.e. one-way follow, like Twitter).  Their expanded social graph then serves as the base for the next iteration of recommendations.  This produces an exploratory feedback loop where the user naturally acts as their own damper, accomplishing our goals without the recommendations becoming annoying and/or irrelevant.

—

p.s. We’re building a Noise Dial into the core of Shelby.tv’s collaborative filter.  And our noise dial goes to 11.

We’ve built Shelby with a distributed architecture (the subject of another post) with a highly parallelized social stream processing infrastructure (another post as well).  To accomplish this we’re using the Beanstalk message queue (not using Amazon SQS as we’re not running on EC2) to allow the disparate components of the system to communicate.

Beanstalk handles publishers and consumers via sockets and has had no trouble taking a pounding from actual multithreaded usage (i.e. multi-core CPU coupled with language and OS support).  Unfortunately, I couldn’t find a Ruby client designed for a truly multithreaded environment.  The best and most popular client I found is beanstalk-client.  While that client is thread safe, the implementation will hang if used naively.  Indeed, there is one very important aspect of Beanstalk itself that should be made perfectly clear: you must reserve and delete a job using the same connection.  You cannot call reserve() on a client before somehow releasing the job previously returned by that client.  This can get messy when multithreaded, so I forked that client…

The recently open-sourced OvertimeMedia/beanstalk-client-ruby includes a Beanstalk::ThreadedPool class which creates a managed set of Beanstalk clients.  A proper Thread would reserve a Beanstalk client with ThreadedPool.reserve_connections() (which will block if no connections are currently available) then call reserve() on that client.  This connection will not be released back to the pool of available connections until it deletes/releases/buries the job it reserved from Beanstalk.  This is conveniently wrapped into the job itself.  

For example, if you have a threaded work queue and want to process up to 100 Beanstalk jobs at a time…

@beanstalk_pool = Beanstalk::ThreadedPool.new('localhost', 100, 'tubename')
while(true)
  job = @beanstalk_pool.reserve_connection.reserve
  @work_queue.process_in_new_thread(job) { |job| work_on(job); job.delete(); }
end

I’ve not implemented the full Beanstalk API with my multithreaded fork as I’m not using the full API.  I selfishly only built out the parts I’m using.  But this fork has been running the Shelby alpha for two weeks and processed millions of jobs without issue.  Please let me know what you think of the client if you use it.  I’d love to improve it and help any others who are using it.

p.s. It’s tough to take time out to write up these posts when you could be writing some bad ass multithreaded code ;-]