wfarr

The status site now handles both HTTP and HTTPS gracefully.

The status site now supports SSL and auto-redirects regular HTTP traffic to HTTPs.

Yes.

In fact, all HTTP access redirects to HTTPS for just about everything. And most modern browsers (recent versions of Chrome and Safari) that have accessed a website over HTTPS once happen to _prefer_ HTTPS by default for that site.

> github's "copy url" bit!

That's entirely a limitation imposed by JavaScript not supporting keyboard access. We'd rather not rely on Flash, but we have to in this case.

> They are shipping a completely outdated GCC

They are shipping a heavily modified GCC that originally was forked in 2008. The version of GCC they ship is entirely based on LLVM via Clang and is intended to be a hold-over for everything to transition to Clang over LLVM.

Never on iOS though. Most of the features Google added to the Android version of Maps never made it to iOS, for whatever reason (be it Apple not allowing it or Google decided they didn't want to).

At the time of the outage, the status site was seeing upwards of 30,000/req minute.

AS we scaled up dynos, we would see temporary performance improvements until the status site would stop responding again. In the short term, this led to us massively increasing dynos as quickly as we could as it appeared that CPU burn was a significant cause of the slowness (at the time). This was in part caused by all the dynos repeatedly crashing. That's how we ended up going from 8 previously to 90.

Once the database problem for the status site was identified and resolved, we began scaling down dynos to a smaller number.

Is that even relevant when Apple is taking home the biggest slice of the profit pie?

Not to mention, the glaring problem people like to ignore when discussing this is the motherboard in the MBP is only going to support so much memory anyway (would not be surprised if it could only support 16gb), so talking about not being able to upgrade it to 32/64/whatever is common then is kind of moot.

Having worked with some quite large Mongo setups, I think you'll find the administration of Mongo ends up being significantly more than a single upfront cost.

Dealing with sharding + replica sets is an administrative nightmare with Mongo.

Certainly a LOT of it is rspec 2.8.

But there was a definite increase with Rails 2.3 as well. :)

Seeing about 25% speedup here with just the Rails 3.2 RC1.

Combined with rspec-rails 2.8.0.rc2 (which includes some Rails 3.2-related changes), I saw my test suite go from ~2.5s (Rails 3.2.0.rc1 w/ rspec 2.7.x) to ~0.43s (Rails 3.2.0.rc1 w/ rspec 2.8.0.rc2).

Ruby 1.9.3p0 across the board.