Shanti’s Dispatches

There’s an awesome rails scalability case study up at HighScalability.com:

In a short three months Friends for Sale (think Hot-or-Not with a market economy) grew to become a top 10 Facebook application handling 200 gorgeous requests per second and a stunning 300 million page views a month. They did all this using Ruby on Rails, two part time developers, a cluster of a dozen machines, and a fairly standard architecture. How did Friends for Sale scale to sell all those beautiful people? And how much do you think your friends are worth on the open market?

Friends for Sale App on Facebook. I hope there’s still room in the marketplace of ideas for new breakout Facebook apps. I’ll be trying my hand at some soon.

Amazon S3 is dirt cheap and infinitely scalable. Every month I’m paranoid this willspike up to hundreds and thousands of dollars, but instead it only steadily rises just $1-2 each month:

I’m using Amazon S3 for:
* daily/weekly/monthly backups for 10+ sites (ranging from big to tiny)
* serving photo galleries for a site that does ~ 10k daily uniques
*sometimes used to serve static assets like “style.css”, “prototype.js”, etc

It can be especially handy as a rails static asset host:

An asset host is another server, somewhere on the internet, where you store your static files. These can be javascripts scripts, CSS stylesheets, images, static html files and anything else that doesn’t change often. Basically, anything that lives in your public directory.

So, why would you want to use an asset host? It turns out that many browsers limit the number of simultaneous connections to a host. For Internet Explorer, that number is two. If you are serving a lot of small images, or you haven’t bothered to bundle your scripts or stylesheets, this can be a real bottleneck.

Read more about setting up static asset hosts in Rails here.

I’ve come across many coders who have not properly planned their Greatist Hits of programming, per se.

Sit across from a group of coders at your average meetup, and ask them if they write tests first for their fun “side project”:

Dev #1: Well, y’know, I kind of just develop the code (without tests) as I go.
Dev #2: If I had more time, y’know… I’d write tests, and stuff.

This mirrors my own tinkerings. I’m not saying there’s anything wrong with Test-Driven Development or that it’s in any way inferior to Cowboy Method (TM).

I’m just saying… a lot of hackers… hackers in the wild, do not tend to follow TDD when tinkering on their own fun projects.

I would add tests… but I might change this later, and then I’d have to change the tests, too.

Ah screw it. I’ll just code it up and get the darn thing working first…

A lot of these projects end up being the del.icio.uses, YouTubes and Scribds of the world.