Simon Willison’s Weblog

Items tagged rails in 2010

Filters: Year: 2010 × rails ×


How long would it take an average programmer to do a Ruby on Rails Reddit clone prototype?

Just FYI, Reddit is an open source Python project: http://code.reddit.com/

[... 34 words]

What are the tradeoffs (e.g. development speed, performance, scalability) between using various php frameworks, ruby/rails, or python/django?  Is there any reason to choose one overwhelmingly over another?

At this point, I’d argue that the decision between them comes down to programming language rather than framework—the frameworks have mostly converged on a very similar set of features.

[... 145 words]

Why is Diaspora built on Ruby on Rails instead of Node.js?

Because Node.js had almost no visibility at all six months ago when Diaspora started. Also, Node.js has only very recently stopped breaking API backwards compatibility on a regular basis. Plus the Ruby library ecosystem is much, much larger than the Node.js ecosystem.

[... 81 words]

Hookbox (via) For most web projects, I believe implementing any real-time comet features on a separate stack from the rest of the application makes sense—keep using Rails, Django or PHP for the bulk of the application logic, and offload any WebSocket or Comet requests to a separate stack built on top of something like Node.js, Twisted, EventMachine or Jetty. Hookbox is the best example of that philosophy I’ve yet seen—it’s a Comet server that makes WebHook requests back to your regular application stack to check if a user has permission to publish or subscribe to a given channel. “The key insight is that all application development with hookbox happens either in JavaScript or in the native language of the web application itself”. # 29th July 2010, 9:48 am

Node.js, redis, and resque (via) Paul Gross has been experimenting with Node.js proxies for allowing web applications to be upgraded without missing any requests. Here he places all incoming HTTP requests in a redis queue, then has his backend Rails servers consume requests from the queue and push the responses back on to a queue for Node to deliver. When the backend application is upgraded, requests remain in the queue and users see a few seconds of delay before their request is handled. It’s not production ready yet (POST requests aren’t handled, for example) but it’s a very interesting approach. # 28th February 2010, 11:02 pm