So know we know what all that sexy script.aculo.us was been grown for! Thomas Fuchs has unveiled a taste of Fluxiom. It’s an asset manager that looks especially nice for keeping track of stock images, reusable graphics, and everything else that makes a creative firm spin. Very cool looking and decidedly sexy. Oh, and of course all powered by Rails.
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.