defunkt

If you use your own server make sure you set the Access-Control-Allow-Origin header:

https://github.com/defunkt/dotjs/blob/master/bin/djsd#L26

(Also, Ruby comes with OS X (just like Python) so it seemed a sane choice.)

That's all true, but dotjs is only for Google Chrome on OS X.

Google Chrome on OS X has no such filesystem-based model for managing scripts.

Chrome extensions can't access the local filesystem so we have to start a tiny webserver in the background.

If someone knows a way around this limitation, or a simpler webserver to require / embed, I would be thrilled. But so far this is the best I've found.

Try https://github.com/glenbot/dotjs/tree/ubuntu-support-merged

GitHub now owns the octocat art.

Sorry about that. It should show up in 'germany' and some others now, like 'rails' in the first search field and 'europe' in the second (location).

I want to do all of this stuff. Great post.

GitHub's similar functionality is open source:

https://github.com/pjhyett/github-services/blob/master/servi...

If each Unicorn worker listened on a different port, we'd have to use one of nginx's load balancing strategies (unless I'm misreading your comment).

We have not had success with them in the past which is why we employed HAProxy with mongrel.

Unicorn is not for slow clients or static assets. That's what nginx is for. See http://unicorn.bogomips.org/PHILOSOPHY.html for info on Unicorn and slow clients.

nginx also has features like ESI, serving from memcached, and rate limiting which Unicorn does not (and doesn't need).

Also it doubles as documentation for the members of our team who aren't familiar with this part of the system :)

nginx relies heavily on system calls at the expense of portability.

Counter example: nginx, which uses fork(), and seems to smoke Apache while offering features like binary reloading without dropping connections (not sure if Apache supports this but I seem to remember no - please correct me if I'm wrong).

Portability is not always necessary - when talking about fork() and friends you're talking about trade offs.

When I'm only ever deploying to Unix environments, I accept the lack of portability in exchange for features I value.

It's not just the GIL. Check out Joe Damato and Aman Gupta's awesome presentation from this year's Hoedown for more info on concurrency in Ruby:

http://timetobleed.com/ruby-hoedown-slides/

But if you're already taking that memory hit with separate processes, ala mongrel cluster, fork() still provides a number of juicy advantages (which the article explains).

Posterous supports Gist:

http://blog.posterous.com/posterous-now-supports-traileraddi...

We have mentioned Anchor:

http://twitter.com/github/status/4433287458

We'll talk about them more in the future, too.

Definitely needed fast synchronous requests. I know you can fake this in RabbitMQ but am not sure why we didn't go with it... guess you'll have to wait for Tom's presentation :)

You could use BERT with amqp, as it's just a data format (like JSON). Ernie and BERT-RPC are libraries which build on that.

We were constrained by network our file system and could not add more machines. We needed an RPC solution to shard the data and move away from our network file system.

delayed_job, Amazon SQS, etc are not RPC systems. You can't block waiting on a response like you can with messaging systems.

For instance, delayed_job makes an RPC call that asks "how much disk space is this repository using?" It waits until it gets a response from an Ernie handler then continues with its background job.

You can do ACL with a DVCS by way of a pre-receive hook. It's just a matter of time before tools make this dead-simple.

Yeah you guys crashed it :P

I'm workin' on bringing it back up.

Yeah, it does.

Sounds like we should change this:

  Hurl makes HTTP requests.
  Enter a URL, set some headers, then view the response.
  Perfect for APIs.

To something like this:

  Hurl makes HTTP requests.
  Enter a URL, set some headers, get a response, then share it with others.
  Perfect for demoing and debugging APIs.

We plan to open source Hurl so you can run it somewhere if you want (for auth reasons).

I commented about this further down but the main idea is you can share Hurls which others can modify and play with, e.g. http://hurl.me/ufsmb1

HTTPClient is great and was a big influence on Hurl (for instance we auto-complete headers just like HTTPClient does).

Thanks for the comments everyone! The main idea here is that you can share Hurl URLs which others can modify and play with.

For example I can give you this URL: http://hurl.me/ufsmb1

And you can change 'json' to 'xml' to see what changes.

Hurl was inspired by sharing curl input and output over pastebins. We should probably make this more clear.

Coming soon.