Dave McClure, Ted Rheingold, Jeff Veen, Andrew Chen, and many more cool startup folk will be speaking at the Startonomics conference, on October 2nd. I'm burnt-out on conferences, but this looks really good. See ya there, readers!

OK, the demos of chrome look pretty cool. But why aren't they releasing a version for the mac?

Hmm ... is it possibly the same reason that Google STILL (after 3 years) hasn't released a Gtalk client for the mac? Does Google see Apple as it's biggest potential competitor for the operating system throne?

I'm betting that Chrome for the mac will be a long time in coming, if it ever ships at all. Hoping to be proved wrong though!

I'm testing out google website optimizer on this blog ... hence the funny avatar photos on the top right.

The idea of website optimizer is pretty simple:
1) Configure a couple of alternatives to the current page (in this case, two alternate images)
2) Specify a conversion goal (in this case a click to my bio page)
3) Let google randomly replace the original html with the specified alternatives

So far the cartoon of me is in the lead, followed by the picture of me pointing at a giant projection of the google maps interface. The black-and-white photo of me in a suit is not popular at all.

This may seem like a trivial exercise (do I really care how many people read my bio?), but if you imagine doing this on a page that fulfills real business goals (like a checkout process) you start to see the possibilities.

So anyone who works with Rails even a little bit knows that it is single-threaded. A given mongrel can only process one http request at a time. The solution is to run a large number (or "pack") of mongrels, and load-balance your incoming requests across the pack of mongrels.

This works fine (it's what every even moderately big rails site does), but it has one serious problem. If one of your pages are slow, then requests will "back up" behind the mongrel that is processing the slow request. You'd think you can solve the problem using load balancing (we use the NGINX fair plugin in order to get the smartest load balancing possible). But there's a point where better load balancing simply won't solve your problems. For example, let's say my average request takes 250ms to respond. If I'm serving a request that is going to take a whopping 5 seconds to respond, there's no way for the load balancer to know that something is fishy for at least 250ms. This guarantees that a certain number of requests are going to "back up" behind the slow request.

It's all well and good to say you should profile your code and fix pages that are slow. But for a big web app like SlideShare, there are LOTS of pages. We work hard on making the important pages fast, but we don't necessarily always have the time to profile every page. And if we do happen to have some slow pages, those pages don't just respond slowly: they cause OTHER pages (the ones that are "backed up" behind the slow request) to respond slowly as well. So even an OCCASIONAL slow page will cause a reasonably large number of slow responses.

The solution that we're currently working on is to route our "important" pages to different mongrels than our less important / slower pages. This should make it so that a slow page doesn't cause other (fast) pages to slow down as well. But this is extra complexity in our system, and is a bit tricky to do for pages that don't have an easy-to-recognize url "signature".

I'm a bit surprised I don't hear more chatter about this problem: it seems to me like the single biggest bottleneck to building a huge rails site. What are other big Rails sites doing to deal with this problem? Is there an easy solution that I've missed? As always, feel free to post suggestions in the comments!

Tonight there's a Ruby meetup at the SF offices of SlideShare. There's pizza and beer, and plenty of parking in the scary-looking-but safe alley behind our office! Here's the list of presenters:

Raul Parolari will touch on metaprogramming details - "class_inheritable_accessor: unknown heroes of Rails startup".

Class variables and class instance variables have pros and cons (that programmers have discussed for ever since the beginning of time). Sometimes we would wish for a variable that had their qualities, but not their defects; wishful thinking, right? not in the Rails world! where they exist baptized as 'class_inheritable_accessor' (which by the way plays an important role at startup). This short talk discusses the 3 types of variables, and how the new one works (yes, another metaprogramming Ruby trick, at the service of the "Rails magic").

Bala Paranj will talk about Design Patterns in Ruby

Paul Graham said "When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough? often that I'm generating by hand the expansions of some macro that I need to write."

In this presentation we will see how some of the GOF patterns can be implemented using powerful features of Ruby in a simpler fashion.