Ruby the Rival: What does Java look like post-Rails?

O’Reilly’s had a chat with four prominent Java developers under the title of “Ruby the Rival”. Half of them has switched a big chunk of their development to Rails.

James Duncan Davidson notes about the maintainability of Rails applications and the size of the apps that can be built with it:

Can a team write a Ruby on Rails app that performs a large number of features, does it well, and is maintainable over time? Yes. No question. After working with Ruby on Rails for a while, I would be confident tackling any size web application problem with it. But, that’s because I’ve spent some time with it and now have seen that it’s possible to write a well-designed application.

Bruce Tate on what increased productivity means for organizations:

What if the productivity numbers are real? What if you really can get a 5x boost? Then, you can do the work of divisions with a department, and the work of departments with a team of two.

Do read the whole thing.

Snakes and Rubies in Chicago on December 3rd

Chicago is turning into the hotbed for web-application framework development with both a majority of the Rails and Django teams in town. So we thought we’d celebrate that with a happy gathering at DePaul University on December 3rd. For chats and talks on web development using Django and Rails.

In town? Checkout the Snakes and Rubies site for preloading questions and event info.

Why engines and components are not evil but distracting

I’ve been following the enthusiasm for engines, components, and bigger plugins from the sidelines for a while now. It’s a subject of very mixed emotions. On the one hand, I’m really glad to see that people get so excited and start dreaming of bigger and better things. That’s passion in the works and its great.

On the other hand, I think these developments are basically another name for high-level components. And you all know how I feel about those. The short summary is that high-level components are a mirage: By the time they become interesting, their fitting will require more work than creating something from scratch.

But I start getting really high eyebrows when I hear of “engines that depend on other engines that can be swapped out with yet another engine”. Even plugin dependencies are dangerously close to something I would consider unfit for Rails. Simply because it encourages a style of development that I find unhealthy.

So this is not a slam against the technical merits or implementation of either engines or anything else in the same boat. It’s a concern that they will distract people, that they will appear as needed, and in turn, that they will take the debacle that was Salted Hash Login to a new standardized level.

Rails is all about making the simple things so easy that you need not abstract them. It’s about making the creation of logins, of access control, of content management, of all these business logic components so very easy that you will treasure the application-specific solutions of your own rather than long for The One True Login System.

So what am I saying? That engines should be stopped? Of course not. But I am saying that Rails will continue to send a signal with what’s included in the core that this is a sideshow project. It satisfies some needs for some people and that’s great. But the goal of Rails is to create a world where they are neither needed or strongly desired. Obviously, we are not quite there yet.

One way of getting there is to do a better job of educating new comers in common patterns. Answer the question “if engines and components are not the way, then show me how!”. So this is a call to all those experts out there. Help us spread the good patterns. Make videos, write tutorials, help newbies on #rubyonrails, answer requests on the mailing list.

And if you have a great idea for an engine, or a high-level component in general, think about this: Is there a way I could abstract a smaller slice of functionality as an independent plugin and then release that alongside a pattern that described how to use it like the component would have done all in software? More often than not, I think you could find this to be true.

Note: James Adam, the creator of the engines approach, has a great post on the mailing list for how he uses engines internally at his company. That’s perfectly cool use. The trouble with high-level components are solely related to making them generic.

Play and help

Michael Buffington has just opened up for general consumption. It’s an open source board game built on Rails. Besides the hosted version, you can download the source and Michael is looking for merry contributors as well. Check it out.

Rails 1.0 RC4 (0.14.3): It's the final countdown!

Comrades, we are so close to the goal that the relieve should be tastable. The mythical 1.0 release is now penned to be the very next release once we rattle out the heinous bugs from this one. So we need every man, woman, and child at work testing the living daylights out of this final release candidate. Upgrade your apps, start new ones, kick the tires, rev the engine, do it all!

So what’s new? What’s in there to make it pay to upgrade today rather than at 1.0? Lots! In a regular universe, this would have counted as more than merely a 0.0.1 increment. We got a ton of stuff especially for Active Record and the Rails infrastructure.

The new commands

  • script/server: Will now use lighttpd/FCGI if both are available on the system. This makes for a considerably faster development experience than WEBrick, but is unfortunately a OS X/nix thing only. Windows users will continue to get a WEBrick-powered server launched.
  • script/plugin: Your gateway to the wonderful world of plugins. Helps you install, manage, and discover new plugins. See script/plugin —help for more.
  • script/about: Gives you the all the versions for Rails and associates. See the sample.

Active Record: find_or_create_by_X, association collection extensions, migrations for all databases

We’ve added a new dynamic finder that allows you to find or create a new record on the basis of attributes passed, such as saying Tag.find_or_create_by_name(“Summer”). It even works on associations, so page.tags.find_or_create_by_name(“Summer”) is kosher too.

Extensions for association collections is a sexy new way of adding methods to the proxies that all access delegate through. Example:

class Account < ActiveRecord::Base
  has_many :people do
    def find_or_create_by_name(name)
      first_name, *last_name = name.split
      last_name = last_name.join " "
      find_or_create_by_first_name_and_last_name(first_name, last_name)
person = Account.find(:first).people.find_or_create_by_name("David Heinemeier Hansson")
person.first_name # => "David"
person.last_name  # => "Heinemeier Hansson"

And finally we’ve really put the spit and polish on the database adapters by adding migration support to all the commercial ones. As well as giving especially the SQL Server one a good loving in general.

Action Pack: Better filter controls, fixed ActiveRecordStore, and redirect_to :back

Action Controller now has skip_before_filter and skip_after_filter to sidestep certain filters set in superclasses that doesn’t apply to the current controller. Such as specifying :authenticate in ApplicationController, but skiping it in the SignupController.

The ActiveRecordStore no longer only saves when changes have occured, so you can again rely on updated_at being incremented at each page view, and thus rely on it for garbage collection.

Finally we now have an easy way of saying “go back to where you came from” with redirect_to :back.

Upgrading from 0.14.x

It has never been so easy to upgrade to the latest and greatest if you’re on 0.14.x series. You get almost all of it for free simply by installing the latest gems and the rest by running these two commands:

rake update_javascripts
rake add_new_scripts

I’ll let you figure out what those do.

Upgrading from 0.13.x (or earlier)

Jeremy Kemper has put together a great guide to upgrading from an earlier version.

What else is new?

As usual, you get the full play-by-play story of the changes by examining the changelogs. Such wonderful bedtime reading.

Liquid templates announced

Liquid is a brand new template engine optimized for xhtml and emails. It features a very clean syntax and speedy execution speeds. The main difference to traditional ERb is that it does not rely on eval. This means that no potentially harmful code is executed when a Liquid template is compiled or rendered.

The chief advantage is that you can let your users change templates without having to worry about your data’s security. The templates only see data which you export to them. In Shopify for example you will be able to edit your shop’s templates and emails directly in the admin interface. The templates are stored in the database and rendered directly from it.

Liquid is packaged as a rails plugin for easy installation. In good rails style there is a small movie available showing how to install and use it.

Inviting Rails extenders to join the rails-core ML

If you’re working on patches for Rails, you should sign up for the rails-core mailing list. It’s much more low-traffic than the regular Rails mailing list and designated exclusively for discussions on extending Rails.

So if you have any questions about a patch you’re working on or have completed, this is the place to join. If you have questions of the usage of Rails, announcements, or any of the other jazz, please do keep it on the regular list.

Komodo 3.5: IDE with support for Ruby on Rails

RadRails is getting company from commercial player ActiveState that has recently shipped Komodo 3.5, their IDE for dynamic languages. Komodo features support for Ruby and Rails and is available on Windows, Linux, and Mac OS X.

Komodo Professional is a $295 buy, Komodo personal is $29.95, and there’s a 21-day trial available.

The release got a bit of play in the press with an InfoWorld article called Ruby IDE is set to shine.

Being a OS X/TextMate user myself, I haven’t had a chance to checkout Komodo. Please do add your experiences in the comments for others to share.