Stephan Kaes, our resident performance expert, has released a new version of RailsBench. He then created new Rails 1.2 vs Rails 1.1 benchmarks, discovering that things aren’t as bad as they seem. Of course, those numbers won’t mean a whole lot until you read the full report
While Rails Edge continues to move forward at a rapid clip, we’ve still had the time to make sure that Rails 1.2.x stays in the game. This release irons out the few wrinkles there was between Ruby 1.8.6 and Rails 1.2.2. So now you can enjoy the latest Ruby with the latest Rails.
Besides the 1.8.6 compatibility, we’ve included a few minor fixes. Nothing major. This should be a drop-in replacement for Rails 1.2.2.
As always, you can upgrade with gems or use the latest svn tag (rel_1-2-3). Enjoy!
Until now, the task of locating and loading plugins into your app was handled by a handful of private methods on the
Rails::Initializer. These methods were fairly large, coarse grained, and as a result hard to hook into without resorting
to fragile cut and paste if you wanted to customize how your plugins are loaded.
New in Edge Rails, changeset 6277 replaces this smattering of methods with two new internal classes, Rails::Plugin::Locater and Rails::Plugin::Loader. If you need to hook into how plugins are loaded, you can define a subclass of Rails::Plugin::Loader, then register your custom class to be the class that handles plugin loading using the new plugin_loader configuration option in your config/environement.rb:
Rails::Initializer.run do |config| # Config settings... config.plugin_loader = PluginLoaderWithDependencies end
To those monkey patching the plugin loading subsystem in Rails, this introduces substantial changes to the way that plugins are located and loaded. In the short term this might mean that your customizations to the internals will very likely break, but the good news is that in the long term the new implementation will be far easier to customize.
For those adventurous early adopters living on the Rails Edge, please give your apps a test run to ensure these changes
don’t break anything for you. As always, bug reports and patches are welcome: http://dev.rubyonrails.org/.
Computerworld is pinning Rails as the #1 technology to know in 2007. As the only piece of software among group of hardware including NAND drives and new CPUs. About Rails they write:
Equal parts design philosophy and development environment, Rails offers developers a few key code-level advantages when constructing database-backed Web applications. One of the central tenets emphasizes using less code for application development by avoiding redundancy and following Rails conventions. This means increased performance and, ideally, decreased development times.
Here it is, another Capistrano release, and less than a month since the last one! Miracles truly never cease.
Capistrano, for those embarrassingly late to the party, is a utility for executing commands in parallel on multiple remote servers. It is useful for lots of things, including automating deployment of Rails applications.
Version 1.4.1, available just as soon as the mirrors get updated, is a pretty minor update, but has one new feature:
- You can now pass :env to ‘run’ (and friends), in order to specify environment variables that should be set for that command. For example:
There is also one deprecation: if you are using UPPERCASE variables in your Capistrano recipes, you’ll being seeing warnings now. Support for variables that start with uppercase letters will be removed altogether in Capistrano 2.0. If you want uppercase identifiers, you should use Ruby constants.
The two fixes in this release:
- Actor#get will not close the SFTP channel when it finishes. This makes it possible to do multiple SFTP gets and puts in a single session.
- The subversion adapter now passes the “no-auth-cache” option, so that if you configure an explicit subversion username for deployment other than your dev username, those deployment auth tokens won’t clobber your development tokens.
So, go get it, “gem install capistrano.” Or download it directly from RubyForge. And at the risk of promising too much, too early: I expect this to be the last 1.x release of Capistrano, barring any critical problems that may arise with 1.4.1. Come on, cap2!
All 1200 seats for RailsConf 2007 are now gone. See you all in three months in Portland!
Oh, there’s also a waiting list, if more seats should open up due to cancelations or whatever.
RailsConf has been racing towards a sell-out and is now almost there. We’re down to our last 100-something seats out of the 1200 being offered. So if you’re still waiting for boss approval on the expenditure or want to see how close you can get to having seat #1200, I’d start thinking about chickening out and secure that seat.
We’re going to have a party come May.
Andre Lewis is rolling out a duo of resources for those of you creating mashups and Google Maps-based applications.
Also related to mapping, Andre recently released GeoKit. GeoKit provides a bundle of tools to make maps-based applications easier:
- Distance calculations in miles or kilometers:
distance = first_location.distance_to(second_location, :units => :miles)
- ActiveRecord distance-based finders:
Store.find(:all, :origin=>[37.792,-122.393], :conditions=>'distance < 10')
- . . . and directly from an address:
Store.find_closest(:origin=>'100 Spear St, San Francisco, CA')
- Geocoding from Google, Yahoo, Geocoder.us, and Geocoder.ca geocoding services. It provides a uniform response structure from all the geocoders, and also has a configurable fail-over mechanism in case one geocoder fails.
- IP-based location lookup. Provide an IP address, and get a city name and latitude/longitude in return.
The Revolution Health team has been blogging their progress over at Revolution On Rails. InfoQ recently conducted an interview with the developers that discusses, among other things, their PluGems (it’s a plugin! it’s a gem!!) approach to sharing code across the multiple applications that make up Revolution Health.
RailsConf has sold close to three quarters of the available seats for the May 17-20 show at an amazing rate. It’s only been a week since we opened for registrations. So it’s naturally wonderful to see that level of excitement even as our venue this year can accommodate a ton more people than last year. This certainly looks like it’ll be another sold out RailsConf shortly.
And hot on the heels of RailsConf in Portland, we’ve just opened up the Request for Proposals for RailsConf Europe, which will take place in Berlin between September 17-19. Last year RailsConf EU was a bit more of a sleeper hit than the Chicago show, but turned out absolutely fantastic with loads of exclusive and all-new content. With Berlin being a significantly cheaper city than London and part of mainland Europe, we’ll no doubt have an even greater show.
So get your proposals ready for RailsConf Europe. And if you haven’t already, snatch one of the last seats for RailsConf in Portland.