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.
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.
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.
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).
This removes discoverability of what could be useful (if small) gems. At the very least, these could be made into full repos on GitHub with READMEs so they're relatively easy to find between GitHub's own search and Google.
I hope this is some sort of staging or testing server?
The idea of repeatedly writing code and rsyncing it up to a production server while adding new features/whatever seems incredibly error prone to me. And that's not even to touch on whether or not there's automated testing (in the form of unit/integration/whatever tests in the code).