SlideShare mind-melds with PowerPoint

We just released something really cool! It’s a.plugin for PowerPoint that lets you do pretty much anything that you can do on the website … from within PowerPoint.
As Keanu would say, whoa. Using PowerPoint to browse a site for sharing PowerPoint. Very meta.
We call it the “SlideShare Ribbon”. The best part IMHO is that you can search for PowerPoint files and download them directly from slideshare into PowerPoint. Also, uploading is really convenient, so if you’re working on a presentation, once it’s ready you just click one button and it will upload in the background.
The best BEST part, though, is something we really should have built into SlideShare (don’t worry, it’s coming soon). It’s a console that shows you how many views, comments, and favorites each of your presentations has received. If you’re using SlideShare to market your business, this is a really handy way to see, in one screen, exactly how many people you’ve been able to reach.
Major props to the Microsoft crew over in Seattle … they were incredibly helpful to us over the course of this project.

Google hates apple

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!

Google WebSite Optimizer

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.

Rails being single-threaded causes scalability problems

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!

SF Ruby meetup tonight at SlideShare

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.

When S3 goes down, the internet goes down!

We’re now in hour 4 of an S3 outage that is effecting the entire startup ecosystem. SlideShare is down, as is MuxTape, SmugMug, and almost every other site you can think of. Fingers crossed that they resolve this soon! Here’s the current status from AWS:

9:05 AM PDT We are currently experiencing elevated error rates with S3. We are investigating.
9:26 AM PDT We’re investigating an issue affecting requests. We’ll continue to post updates here.
9:48 AM PDT Just wanted to provide an update that we are currently pursuing several paths of corrective action.
10:12 AM PDT We are continuing to pursue corrective action.
10:32 AM PDT A quick update that we believe this is an issue with the communication between several Amazon S3 internal components. We do not have an ETA at this time but will continue to keep you updated.
11:01 AM PDT We’re currently in the process of testing a potential solution.
11:22 AM PDT Testing is still in progress. We’re working very hard to restore service to our customers.
11:45 AM PDT We are still in the process of testing a series of configuration changes aimed at bringing the service back online.
12:05 PM PDT We have now restored communication between a small subset of hosts. We are working on restoring internal communication across the rest of the fleet. Once communication is fully restored, then we will work to restore request processing.
12:25 PM PDT We have restored communication between additional hosts and are continuing this work across the rest of the fleet. Thank you for your continued patience.