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.

It's a fairly recent addition to git (January 2012). You need at least version 1.7.9 to use credential caching. [1]

[1]: http://git-blame.blogspot.com/2012/01/git-179.html

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.

You might be interested in https://github.com/paperlesspost/graphiti

It's somewhat based on some of the stuff Github uses internall for graph generation (so the README says).

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.

Except the part where people who received the original email have 100% control over whether or not they do tell other people about it.

> PLEASE DO NOT REPUBLISH THIS INFORMATION!

From the linked email.

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).

That's what the bookmark system is there for.

It's not a matter of SQL vs. NoSQL. They are complementary.

The fact of the matter is, there are some components of systems for which Redis, Riak, etc may be better suited than SQL in the long term. Starting out, keeping everything in SQL provides less friction, but as time goes on it may be necessary to scale the component separately from typical relational data storage, and that's the point at which these switches are evaluated. These companies would be replacing SQL only in these components — not across the board.

The myth of a silver bullet datastore solution is just that: a myth. Different data stores have different strengths and weaknesses and it becomes necessary to mix and match at scale.

To quote Benjamin Black: "Scale is pain, princess. Anyone who tells you different is selling something."

DP4 was also likely tagged at least a month before its release to developers.

Their DP releases aren't current. They're older, generally more stable snapshots.

EDIT: This means that they've been improving stability long since the last DP, and have been using the bug reports and crash reports from the DPs to diagnose and fix problems as well.

"Over the next couple of years a lot of developers are going to make good money moving companies off of Node.js and MongoDB." - http://twitter.com/#!/b6n/status/73535660467818496

It was forked because while performance improvements are great to have, API breakage with no replacement for long-standing APIs is not.

At the end of the day, people need a working environment and not everyone has the time of day to be updating every library out there that used a previously stable RubyGems API to use the new "better" ones (though I've yet to see a case where the API changes were little more than renaming a class and adding a couple class methods).

Given that, I'd definitely recommend you check out Rump: https://github.com/railsmachine/rump

It'll let you manage your servers in a headless manner, using simple version control via git to manage your puppet configuration.

[Disclaimer: I work for Rails Machine.]

You may be interested in checking out Rump: https://github.com/railsmachine/rump

[Disclaimer: I work for Rails Machine.]

It's essentially a headless puppet that centers around a workflow of testing changes from an individual checkout of the puppet code on a target server, testing no-op applies of the manifests, and applying the manifest until you're happy enough to commit, push, and roll-out.

This won't help with your second annoyance, sadly, but it should definitely help with the first in quickly pinpointing these sorts of issues without having a messy commit history.

That is frustrating. :(

What release are you using and on what OS?

I'm running '11.0.672.2 dev' on OS X and don't see such an option.

I would venture to say it does.

You can't really fault Github for individual teams not opting to host their code in more than one spot online, even if Github doesn't offer the capability for users to use their own domain name for seamless switching of git hosts.

Does Github encourage keeping everything centered at Github? Perhaps implicitly. But they certainly don't lock anyone's data in, so blaming them for their customers opting to NOT put their code anywhere besides Github seems unfair.