Bratwurst on Rails at RailsConf Europe

The Berlin Ruby User Group is throwing a pre-RailsConf party under the banner of Bratwurst on Rails.

The Ruby User Group Berlin is one of the biggest in Germany and therefore we’re pleased to organize an event on the night before the RailsConf Europe. In the tradition of last year’s “Pizza on Rails” the event is called “Bratwurst On Rails.”

The event is an opportunity to socialize and meet the conference participants in a relaxed atmosphere, and to make your name or brand known amongst them. Tighten your knots with the community by becoming a sponsor.

The venue will be in the heart of Berlin, close to the conference venue. Entry will be free, as will the food. (If you’re interested in sponsoring, have a look at our sponsoring packages and feel free to contact the organisation board via sponsoring@bratwurst-on-rails.com).

Capistrano 2.0 Preview 3

Alright, we’re nearing the finish line! Capistrano 2.0 Preview Release #3 is now available.

Capistrano is a utility for automating the execution of tasks on one or more remote machines. You can read all about it at www.capify.org.

To install Preview #3, you’ll need to grab it from the Rails beta gem server:

gem install -s http://gems.rubyonrails.org capistrano

Accompanying PR3 is a new page of documentation on the capify.org site: Capistrano Basics. This walks you through the major features of Capistrano, but does not touch on deployment. This makes it a great introduction for those wanting to use Capistrano in non-deployment scenarios.

Preview #3 includes the following changes and enchancements:

Feature: Mercurial and CVS are now supported out of the box. Just set your :scm variable to :mercurial or :cvs, like so:

set :scm, :mercurial
# or
set :scm, :cvs

Thanks to Tobias Luetke and Matthew Elder for the Mercurial module, and Brian Phillips for the CVS module.

Feature: There is now a :default_environment variable, which is a hash that can be used to set environment variables that should be present for all commands that are executed. For instance:

default_environment["PATH"] =
  "/bin:/usr/bin:/usr/local/bin:/home/jamis/bin"

Feature: All commands are now explicitly invoked via “sh”, which means that even if your default user shell is non-POSIX (e.g., tcsh, csh, etc.), you can use Capistrano just fine. Note that if you were using tcsh or csh syntax in your Capistrano scripts, you now need to set the :default_shell variable to use your (non-POSIX) shell of choice:

set :default_shell, "/usr/bin/tcsh"

Feature: You can declare empty roles, and Capistrano won’t complain. This is useful for predeclaring roles that need to exist (because task definitions depend on them), but which might not have any servers in them (depending on runtime conditions).

Feature: A username and port specified with the server definition (e.g., “fred@some.server.com:1234”) now take precedence over the :username and :port settings in the ssh_options hash, rather than the other way around. This lets you set a general default via ssh_options, and override on a per-server basis in the server definitions themselves.

There are several other minor changes and fixes as well; you can read the CHANGELOG for all the gory details.

The Summer of Hack, 2007

The hackfest is back! In sleek new form, the ’fest runs monthly, starting now.

Without further ado: it’s on. Two weeks to go. Sprint!

Thanks to Working With Rails for making this an integral part of their site; thanks to O’Reilly for signing on as the first sponsor (first prize is a free pass to RailsConf Europe); and thanks to you for contributing the patches and bugfixes that keep Rails at the top of its game.

Go, go!

#rails-contrib and rubyonrails-stacks

RailsConf gave birth to a number of new outlets for sub-communities within the Rails family:

#rails-contrib is a new IRC channel on freenode for contributors to Rails. The Rails core team will hang out there to answer questions, discuss patches, and generally interact with anyone doing implementation work for the Rails framework. It's not meant for general chatter, though. Or for how to use the framework. It's strictly for implementational issues and the contributors working on those.

rubyonrails-stacks is a new forum to discuss how we can get standardized set of images going for Rails that can be deployed on any Xen host or even EC2. I posted a welcome with more details on the forum.

Taking expirations out of caching

It’s been said that the two last hard problems in programming are naming things and expiring caches. The first is going to be hard to sidestep entirely, but what if we could the second? Tobi arrived at a eureka moment for just that using Memcached and various kinds of caching. Instead of manually expiring things, just ask for a specific version, and let the caching engine take care of dumping that which isn’t used any more.

Read more on The Secret to Memcached.

Capistrano 2.0 Preview 2

The upcoming Capistrano 2.0 release continues to evolve! Remote administration of single servers and server clusters has never been easier. With Capistrano, you can:

  • Deploy web applications with a single command
  • Keep software in sync across multiple machines
  • Install entire servers with just a few keystrokes
  • Impress the ladies with your leet sysadmin skills

Ok, well, maybe not that last, unless she’s a really special lady. But the rest certainly apply.

Capistrano 2.0 Preview Release 2 is now available (version 1.99.1). You can only grab it from the Rails beta gem server:

gem install -s http://gems.rubyonrails.com capistrano

NOTE that Capistrano 2.0 is not 100% backwards-compatible with Capistrano 1.x recipes. For more information on upgrading, check out http://www.capify.org/upgrade.

To install the preview release, you’ll need to make sure you’ve already got the following gems installed, too, which Capistrano depends on (and which can be found in the main Rubygems repository):

  • net-ssh
  • net-sftp
  • highline

Download it, install it, try it out. Kick the tires. Report what doesn’t work. We’re getting close to a general release!

SO. Now that all of that is out of the way, let’s talk about what’s new in PR2. First, the bug fixes:

  • The “copy” deployment strategy now checks out the local copy to a temporary directory, rather than using the current working directory. This makes it possible to use with some picky SCM’s that don’t like checkouts being made into an existing checkout.
  • The “deploy:check” task was broken for some deployment strategies. It should work now for all of the pre-packaged strategies.
  • The “shell” task should actually work now.
  • The “desc” keyword will apply to the next defined task, regardless of which namespace the task is defined in.
  • Don’t retry failed connections when an explicit :auth_methods list is given via :ssh_options.
  • Fixed a few minor documentation typos.

Next, the new features:

Feature: The “deploy:cold” task will run migrations before starting the app. If it is the first time you’ve deployed your app, chances are the database needs setting up, too!

Feature: The old method of extending tasks (e.g., tasks named “before_deploy” and “after_deploy” extending the “deploy” task) is now discouraged (though not formally deprecated, yet). The new approach uses some new keywords:

before :deploy, :my_custom_task
after “deploy:symlink”, :do_this, :and_do_that

More generally, you can attach tasks of your own creation to arbitrary “events”, using the “on” keyword:

on :before, :my_custom_task, :only => :deploy
on :after, :do_this, :and_do_that, :only => “deploy:symlink”

The :before event gets triggered before any event is invoked, and :after gets called immediately after the event finishes successfully. There are four other events currently supported by Capistrano:

  • :start is triggered when a task is invoked via the command-line
  • :finish is triggered when a task invoked via the command-line finishes successfully
  • :load is triggered after all recipes have loaded, but before any tasks are executed
  • :exit is triggered after all tasks have been executed

You can even define your own events, and then trigger them using the “trigger” method.

Feature: The “deploy:app” namespace has been axed. The tasks that it contained now live in the “deploy” namespace directly. Thus, “deploy:app:start” and “deploy:app:stop” are now “deploy:start” and “deploy:stop”, respectively.

Feature: If your “scm_command” is set to a custom value because your SCM lives in a non-standard location on the remote host, you previously ran into problems if your SCM command did not live at the same location on your local host. Now, if you need different settings for the scm_command depending on whether it is being invoked locally or remotely, you have the option of specifying either one separately:

set :scm_command, “/opt/local/bin/svn”
set :local_scm_command, “/usr/local/bin/svn”

Note that if “scm_command” is set, “local_scm_command” will default to that value, but if “local_scm_command” is set, “scm_command” is unaffected.

Feature: Servers are now uniquely identified by Capistrano based on their full connection information, including hostname, username, and port. (Before, servers were only unique based on the hostname.) This makes it possible to use Capistrano in a NAT’ed environment, where all of your servers are using the same hostname, with different port numbers.

Feature: The “capify” command now understands the “-h” switch, which should make it behave a little more like people expect.

Ruby and Rails continues book bonanza

O’Reilly has analyzed the book sales once again. Here are the juicy bits about Ruby and Rails books:

In the Web design and development area, it’s worth noting that Ruby on Rails has continued its blazing growth, but Ajax books have not. The decline of both PHP and ASP are striking…

…Rails in the bottom middle was a small speck in last year’s first quarter post. Now the size of the box fits the size of its name at least. And its market share is almost equal to SQL and has surpassed VBA, Perl and Python. Python is also experiencing good growth, just not at the blazing velocity of Ruby. I would expect by next year, we will see Ruby have an even larger share/square.

Slingshot goes public

Joyent’s Slingshot technology for creating offline-capable Rails applications has gone public. They’re even doing a competition to celebrate: The best ports of various open source Rails applications can win a 1-year big Accelerator ($1250 value). Now there’s a project you can hack on the plane to Portland in a few weeks ;).