Andreas Schwarz has set up RForum to play gateway to both Ruby and Rails. So you can create an account on ruby-forum.com and be able to post to the mailing lists through that interface. Very nifty. RForum is also an open source Rails app.
Rick Bradley has kindly shared the evaluation document that was part of the decision for picking Rails over Java for the rewrite of CenterNet. Their enterprise health care system. On top of that, Rick has started a blog to follow the project through. Right on.
Thibiant is a e-commerce site for a renowned spa in Beverly Hills, which caters to the rich and famous stars of Hollywood. And now, those very same stars will be shopping through Rails. Sergio Bayona and team from Space Dog House is behind it.
So if you’re programming Rails it’s almost like you can say that you’ve touched someone famous now!
O’Reilly’s ONJava.com 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.
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.
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.
Luke Burton has a cool article on how to integrate Virtual Earth and Ruby on Rails. It’s surprisingly easy and relies only on libraries shipping in the box.
Michael Buffington has just opened up llor.nu 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.
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
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)
end
end
end
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 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.