Lowering Capistrano concurrency March 5th
If you happen to run into problems when deploying code from your GitHub repository to a larger number of machines in parallel (the dreaded ssh_exchange_identification: Connection closed by remote host error) you may want to look into Capistrano’s :max_hosts option to limit the operation at hand to a given number of machines at once.
This is all nice and dandy, unless you find out that there is no way to change that option for an existing task, for example from Capistrano’s default library of recipes. To solve this (and make my deploys to the 12 machines in a cluster I manage more reliable) I simply duplicated the update_code task to my application’s local config/deploy.rb:
namespace :deploy do
task :update_code, :except => { :no_release => true }, :max_hosts => 4 do
on_rollback { run "rm -rf #{release_path}; true" }
strategy.deploy!
finalize_update
end
end
That way, the update_code task is split into 3 batches of 4 hosts and checkouts/code updates from the GitHub repository (which is probably just rate limited to not be slammed with requests all at once) work nicely again.
Since this task is fairly compact, I didn’t do any further research. Is there a better way? Let me know in the comments.
freshmeat 3 beta registration open January 21st
During the past several months, freshmeat.net has been rewritten in Rails. Greg Newman has been responsible for the design part of the make over. Here is the article on freshmeat announcing the rewrite.

As with every major rewrite, lots of bits and pieces are being touched and rethought. To make sure we didn’t get something awfully wrong, we’re giving the new code a beta run for its money. You can register for a beta invite today. We’ll start sending out invites later this week.
I will post links to forums, chat, and bug reporter once the first invites are out. You can also follow freshmeat on twitter.
