technoweenie

FWIW this is not a statement about programming (node.js vs ruby or whatever)

GitHub implements the PSHB subscription API. It's fine, but doesn't really fit in well with the rest of our JSON API. For instance, parameters are sent over as form encoded values like "hub.mode".

http://developer.github.com/v3/repos/hooks/#pubsubhubbub

We also have a regular JSON endpoint for our hooks resource (which is essentially a subscription API).

You don't need a valid email to commit to your repositories, but you do need one to use GitHub notifications. This feature makes it possible to use the web editor with a fake email address instead of your notifications email address.

Yes! Now guess the background of the second image :)

The preferred URL is the one in the browser address bar: "https://github.com/{owner}/{repo}". Works great for pushing and pulling.

May, according to the order page.

https://www.automatic.com/order

Not everything we work on deploys to Linux.

Nope. If you were trying to submit it tomorrow, it'd be rejected though.

And it's back.

We've supported HSTS for for well over a year now.

Video games :) Guild Wars 2 is a MMO that costs a one time fee of $60 (plus optional in game purchases).

I was curious what Tony's graph would look like using a SimpleDelegator as he suggested.

    (using ruby 1.9.3p194)
    Calculating -------------------------------------
             without dci     68507 i/100ms
                with dci     24409 i/100ms
          with delegator     46945 i/100ms
    -------------------------------------------------
             without dci  2240202.4 (±3.2%) i/s -   11235148 in   5.020463s
                with dci   412445.3 (±3.7%) i/s -    2074765 in   5.037113s
          with delegator  1018928.4 (±1.6%) i/s -    5117005 in   5.023310s

RUBY:

    require 'rubygems'
    require 'benchmark/ips'
    require 'delegate'

    class ExampleClass
      def foo; 42; end
    end

    module ExampleMixin
      def foo; 43; end
    end

    class ExampleProvisioner < SimpleDelegator
      def foo; 44; end

    Benchmark.ips do |bm|
      bm.report("without dci") { ExampleClass.new.foo }
      bm.report("with dci") do
        obj = ExampleClass.new
        obj.extend(ExampleMixin)
        obj.foo
      end
      bm.report("with delegator") do
        ExampleProvisioner.new(ExampleClass.new).foo
      end
    end

We encourage all GitHub apps to use proper caching on their end. There's no good reason that a hit on a 3rd party site like Gitrep should relate to one or more GitHub API calls. Use HTTP conditional GETs to retrieve data, and any 304's (cache hits) will not impact your rate limit.

Based on its support of tags/searching, I'd imagine Gitrep is being responsible here though.

That was also a troll/spam bot that had no affiliation to Travis CI. Their GitHub integration has always been classy.

Hey, check the Service Hooks tab of your Repository Settings.

We got a lot of angry feedback about the whitespace bot that was roaming GitHub for a while. We tried to sit back and let people deal with it themselves (e.g. send feedback/patches to the bot owner).

We're not opposed to bots or services. We encourage it, and use one ourselves. The key is making it opt-in so it doesn't bother people that don't want it.

Travis CI is a popular addon, but they don't have a bot that runs tests and tries to get you to setup their service. They just focus on providing a bad ass service that you _want_ to setup.

Edit: You 'opt' in to a bot one of two ways:

1. You add their GitHub Service to your repository (see the Service Hooks tab of your Repository Settings). This is how Travis CI started out.

2. You setup an OAuth token with the service. Travis does this now, and provides a single button to enable CI builds for one of my repositories.

We have GitHub Services: https://github.com/github/github-services. Anyone can submit one. We'll probably accept it as long as the code is decent, is tested and documented, and is for a stable service. If you're running some custom build on a personal hosting account, use the web hooks. You can attach web hooks or services to any of these events: http://developer.github.com/v3/activity/events/types/

A repository named 'mojombo/fakkkkkke', with commits from another user account. Just a standard test repository, nothing amazing. Turns out the user was a family member.

Also, it'd be super awesome if you could report this stuff to us too. Email support@github.com or tweet something mentioning "@github".

HN cred is amazing, but so is GitHub cred :)

https://help.github.com/articles/responsible-disclosure-of-s...

Nope. Just confirmed with mojombo that it's legit. He's just showing GitHub off to family :)

> Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end.

This has never been Rails' focus. Let Rails keep doing what it kicks ass at. Sinatra works great for API endpoints. There's probably an opportunity for an API-focused extension to Sinatra. Of course, Grape works too (https://github.com/intridea/grape).

The nice thing is that all of these are built on Rack now. GitHub.com runs as a Unicorn rack app that mounts over 30 Sinatra apps and a massive Rails app together. I'm not saying this is an optimal solution, it's just where the app is at in its current evolution. But it is very possible :)

Gaug.es uses Mongo. Its data model is pretty simple (just counters), but he has blogged about the approach in detail.

MongoDB Counters: http://railstips.org/blog/archives/2011/06/28/counters-every... http://railstips.org/blog/archives/2011/07/31/counters-every...

Kestrel: http://railstips.org/blog/archives/2012/03/05/misleading-tit...

Gets some decent traffic and works well.

http://twitter.com/jnunemaker/status/282141258816827393

> I drank the HATEOAS Kool-Aid when I first learned about REST too, and then I built a beautiful API that used it. What did the developers ask for? A list of URLs.

Maybe you should've built them a client too? https://www.braintreepayments.com/braintrust/when-rest-isnt-...

I've heard great things from people updating their API clients to use our new hypermedia stuff. So we're pushing forward with our hypermedia experiments at GitHub. People are still free to optimize for speed (reduce the number of HTTP calls in environments where it really matters) or even development speed (hardcoding a few API calls instead of dropping in a full client library) if they like.

$ curl https://api.github.com

We're experimenting with more :)

I love nanoc too, and use it for the GitHub API docs: https://github.com/github/developer.github.com. The fact that it can use ERB templates removes it as a candidate for GitHub Pages, unfortunately. I have a fun rake task to push static HTML to a gh-pages branch: https://github.com/github/developer.github.com/blob/master/R...

Product documentation (wikis) is a very important part of building software. GitHub Pages sure aren't, but they're viewed internally as an addon. There's very little mention of it in the UI.

Using any branch will balloon the size of the repository. It's much better to use something like S3.

Sorry about that. We'll get a fix out there ASAP.

Shipping spirit :) It's definitely nothing planned on our part. We just happened to wrap up some stuff around the same time.

No issue, we just wanted to set something up as opposed to running directly from S3.