Pratik joins core, retired members go alumni

We’re shaking up the Rails core group a bit. First, please welcome Pratik Naik as the newest member of the group.

He’s been doing great work all around the framework and has been spearheading both the documentation branch in git and a thorough cleanup of Action View internals. We’re really happy to hand him the commit keys to the repository.

Second, we’ve created the Rails core alumni for all the proud members of the core group who are no longer in the day-to-day improvement of the framework itself. All of the alumni are still busy working in the Ruby on Rails ecosystem, but either have their hands full with their business or has dedicated their open source time to other initiatives.

We’re incredibly grateful for all the works you guys have done for Ruby on Rails over the years. And you’re all welcome back in the active core group any time you decide. Thanks guys!

Finally, this means that the current active core group is about half its former size. We’d like to add a few more to that, so hopefully we can pick a few more people who’ve been doing varied work on the framework for a sustained period of time soon.

Comparing Rails 2.0 to 1.2 for speed and memory

Hongli Lai has compared a dummy scaffold application from Rails 1.2 to Rails 2.0 and found the latter to be 30-50% faster. That’s great to see.

But what I think is even more interesting is the progress we’ve been making on performance optimizations for more substantial applications. Rails 2.0 made a lot of progress for applications with lots of assets and for ones with big routes.rb files. The forthcoming Rails 2.1 will move things forward even further.

UPDATE: Hongli also investigated memory consumption on 1.2 vs 2.0 and found 2.0 to be significantly slimmer. Nice!

Funny or Die handles big load on Rails

Funny Or Die is pulling high G’s scaling their Rails site to handle 9GBps of video and 20MBps of compressed HTML traffic from the stunts of Will Ferrell and others. Their top video has been seen no less than 50 million times. Rock on, guys.

RadRails 1.0 released

Aptana has released RadRails 1.0 with a bunch of cool new features. I really like their debugging and profiling tools that allow you to inspect the call graph and see where the hot spots in your code are. The fact that RadRails is free and open source as well certainly doesn’t hurt.

RailsConf seats filling up

The $100 early-bird discount lasts until April 10th, but it seems like the open seats might not. So if you’re looking to meet up with the rest of the Rails community in Portland, you probably better get your registration in and your travel plans in line. It’s going to be a blast.

Capistrano 2.2.0

Capistrano is a utility for managing remote servers and automating remote tasks. It is popularly used to deploy Rails applications (but can do oh, so much more!). Version 2.2.0 is now available (well, it’s released, anyway, you might need to wait for the file to propagate to the gem mirrors).

gem install capistrano

Version 2.2.0 sports the following changes:

FEATURE: Dynamic role definition. The role() method now accepts a block, which should return either a host name, a Capistrano::ServerDefinition object, an array of host names, or an array of Capistrano::ServerDefinition objects. This can be used to describe the servers in a role at runtime.

role :app do
  hosts = some_method_that_looks_up_the_current_hosts
  hosts[0,3]
end

FEATURE: Alternative server-centric role definitions, using the server() method:

role :app, "server"
role :web, "server"

# the above is the same as this:
server "server", :app, :web

FEATURE: Support for a :max_hosts option in tasks, that restricts the task so that it is only executed in hosts at a time, in chunks. This helps people who use Capistrano with very large numbers of servers, and prevents them running into connection caps and from running out of memory.

task :ping, :max_hosts => 100 do
  # anything here will only run against 100 hosts at a time
end

# alternatively, you can pass :max_hosts to the run command itself for
# finer granularity
task :pong do
  # this will run on ALL hosts at once
  run "something"

  # this will run on no more than 100 hosts at a time
  run "something-else", :max_hosts => 100
end

ENHANCEMENT: Improved Git support!

ENHANCEMENT: Password prompt support in the Mercurial SCM.

ENHANCEMENT: Implement Bzr#next_revision so that pending changes can be reported correctly, and use checkout —lightweight instead of branch.

ENHANCEMENT: Bring back the :p4sync_flags and :p4client_root variables for perforce SCM.

Additionally, there are several minor bugs and typos that have been fixed. You can see the CHANGELOG for all the gory details.

As ever, please report bugs via the Rails trac, at http://dev.rubyonrails.org. And if you aren’t yet subscribed to the Capistrano mailing list, it’s where all the cool cappists hang out.