Court3nay has created support for named references in test fixtures in Rails:

I’ve written some fun code to ease the pain of associating between
fixtures.  ’Tis tested and documented!  Essentially it allows you to
replace this syntax

  user_id: 5

with this:

  user: :joe

as long as you have users.yml with

joe:

This is a big time save for anyone creating Rails tests that use associations.

Aaron Hopkins is a software engineer at Google who has a very interesting set of simulations and analysis of improving page load time.

Two of the results in particular arenoteworthy:

By default, IE allows only two outstanding connections per hostname when talking to HTTP/1.1 servers or eight-ish outstanding connections total. Firefox has similar limits. Using up to four hostnames instead of one will give you more connections. (IP addresses don’t matter; the hostnames can all point to the same IP.

If your users regularly load a dozen or more uncached or uncachable objects per page, consider evenly spreading those objects over four hostnames. This usually means your users can have 4x as many outstanding connections to you. Without HTTP pipelining, this results in their average latency dropping to about 1/4 of what it was before.

Most DSL or cable Internet connections have asymmetric bandwidth, at rates like 1.5Mbit down/128Kbit up, 6Mbit down/512Kbit up, etc. Ratios of download to upload bandwidth are commonly in the 5:1 to 20:1 range. This means that for your users, a request takes the same amount of time to send as it takes to receive an object of 5 to 20 times the request size. Requests are commonly around 500 bytes, so this should significantly impact objects that are smaller than maybe 2.5k to 10k. This means that serving small objects might mean the page load is bottlenecked on the users’ upload bandwidth, as strange as that may sound.

I also liked this tip:

Regularly use your site from a realistic net connection. Convincing the web developers on my project to use a “slow proxy” that simulates bad DSL in New Zealand (768Kbit down, 128Kbit up, 250ms RTT, 1% packet loss) rather than the gig ethernet a few milliseconds from the servers in the U.S. was a huge win. We found and fixed a number of usability and functional problems very quickly.

The full article is definitely worth reading.  Note that these results are based on simulations; it would be good to see real world measurements for various sites.

As I’ve said, these graphs are based on a simulation and don’t account for a number of real-world factors. But I’ve unscientifically verified the results with real browsers on real net and believe them to be a useful gauge. I’d like to find the time and resources to reproduce these using real data collected from real browsers over a range of object sizes, access speeds, and latencies.

We’re lucky to have beautifully poured lattes in Seattle; Tonx’s Latte Art Set on Flickr has some exceptional efforts.  Makes me want a coffee!