technoweenie

Someone came up with a design. Someone else implemented the backend. We iterated on it for a bit and shipped it internally. Then we figured out the CDN situation, setup logging and metrics, and shipped it genpop today.

Those are all good options, but you still need some kind of poll API. What happens if your PSHB endpoint is down for a bit? What if your streaming HTTP connection disconnects?

They're the same headers the Twitter API uses: https://dev.twitter.com/docs/rate-limiting/1.1

"General population"

The only postgres we use is from internal Heroku apps. We use Mongo in a few places too.

I have the source code, yes :)

Mostly because of legacy reasons, at this point.

You're fired too.

Take a look at https://github.com/nesquena/query_reviewer (if you're using MySQL).

Rack Bug? https://github.com/brynary/rack-bug

Check out Coda Hale's talk: "The Programming Ape". Well worth a watch, but jump to 24:15 or so if you want.

http://vimeo.com/40988625

I'm prodding the Enterprise team to blog about this :)

We don't do "company hack days". If you feel like hacking on something, hack on it.

We do have days where multiple people will be waiting in line waiting for their chance to deploy their tweak.

That particular day consisted of staff deploys on multiple in-progress branches, some performance tuning, bug fixes, etc. Nothing crazy.

I'm also quite sure the number counts deploys across all of our applications. For instance, deploying a change to github-services counts as two, since I have to deploy changes to GitHub.com also.

We do use Rollout (https://github.com/jamesgolick/rollout) once in awhile. Most of the time, we like having the history of flipped feature flags in the Git code though.

Heaven (our deployment tool) does deploy GitHub.com directly from the file servers. But, most of our infrastructure directly relies on GitHub too (such as the Merge API from the blog post, service hooks, and a bunch of OAuth minapps).

Every commit is reviewed by at least 1 person. Depending on the feature, several people may chime in. I find that reviewing smaller diffs is much easier. We also use Team Mentions (@github/api, for example) liberally to get more eyeballs.

We also have regular audits with external security firms.

Data migrations are done carefully with the Large Hadron Migrator Ruby gem: https://github.com/soundcloud/large-hadron-migrator. Facebook has a similar tool: https://www.facebook.com/note.php?note_id=430801045932

The merge API takes branches: http://developer.github.com/v3/repos/merging/

Dogfooding aside, the vast majority of the time is spent running tests and actually deploying the code. The time to hit the API to merge the commit is negligible in comparison.

Also, Janky and Heaven are both tiny apps that don't necessarily have access to the file servers.

Just curious, what were the experiences? Hell, send them to support@github.com if you don't want to reply publicly :)

For people that have never setup SSH, HTTPS auth is very simple. The latest Git supports credential cachers so you don't have to type the password in each time. I also personally love that the same GitHub URL works in the browser and through the Git CLI.

If you click the "SSH" button on GitHub repositories, it'll remember your preference.

It is a renamed "watch."

It was a tricky migration to make. We felt the warning would have just caused more confusion, and that it was best to get everyone upgraded at the same time.

Stars isn't a new feature, just a renamed one.

Your stuff isn't auto-starred anymore. We kept the existing stars (old watched repositories) though.

We couldn't have stars (which is literally a renamed watch button) without the new watch feature.

It was an April Fools joke in 2008. The feature became a reality in 2010, and has seen some major updates since then.'

https://github.com/blog/31

It's the number of occurrences of a language in all public repositories. Most web applications on GitHub have some javascript, for instance.

We include only public repositories in those stats. I ran the numbers across the site, and the rankings don't change much. Javascript and ruby are still at the top, but Objective-C and Coffeescript are 10 and 11.

He made the same comments when he first moved some projects to GitHub. I believe the kernel.org servers were having issues at the time. In response to these comments, we pushed out several changes nearly immediately, including a completely redesigned Pull Request email notification.

We're always listening for feedback and are working on improving the experience for everyone. It's too bad that useful bits of feedback like this turn into another drama episode though.