The Struts/Hibernate vs Rails comparison from a while back is the latest fresh stuff at Slashdot. This marks the 8th Slashdotting of Rails. Coming up on the big 10 soon ;)
Make it as easy as not to.
When we originally launched rubyonrails.org, none of the Rails-based blogging engines were really up to the task of running the show. But with the appearance of Typo and it’s massive uptake and rapid improvement, we have a very viable solution now. So goodbye, WordPress! You served us in a crunch, but I’m also very pleased to see you go.
The switch means that we’ll actually be able to keep comments open without the blogging engine mysteriously shutting them off. And that we’ll hopefully be even better equipped to combat spam.
Thanks once more to Tobias Luekte for blessing the world of Rails blogging with Typo.
David Geary did a cool demonstration of Rails yesterday at the Denver Java User Group by getting a member of the audience, unfamiliar with Rails, to do the demo for them:
In the end, Kirk pulled off the demo without a hitch. That says something about Kirk, but it speaks volumes about Rails. After he left the podium, I added some users to the db and refreshed the app and there, magically, were the new rows in the database. Then I tweaked the pagination parameter for the controller that controls page size from 10 to 5, saved the file and refreshed the browser. I asked the audience if they noticed how long that deployment took. Then I changed the prameter to 3 and then to 2 and reran the demo each time. Each time, the number of contacts displayed updated according to the pagination parameter and each time the redeploy time was, well zero. That got people’s attention.
Change’n’refresh is an intensely addictive form of working, no doubt.
We’re trying to get a sense of who and where people are doing commercial work with Rails. So is the framework paying at least a substantial part of your bills? Put your name on the list.
Duane Johnson has a great how-to on productizing your application. Which basically means that you have a core application that you need to tailor ever so slightly for each customer. How do you do that and still ensure high reuse? Well, that’s just what Duane’s approach explains.
Michael Neumann has released a new version of Wee, which allows for integration of its components with Rails applications. He wrote up a small tutorial on how to do it with the release notes. Wee is a component-centrific framework inspired by Seaside from Smalltalk. Looks mighty interesting, thanks for integrating, Michael.
Matt Raible hopes to become a Ruby on Rails developer, but has doubts on how exactly he’s going to convince CxO’s to see beyond Struts. Matt recognizes that it’s not about technology any more, but rather appearance. On the once golden “but will it scale?”, Matt writes:
The one thing that I see time and time again is that Java developers don’t seem to realize that some of the highest traffic sites on the net are using LAMP stacks similar to what Rails advocates. IMHO, I don’t think “Rails can’t scale” is a valid argument. In fact, I don’t know if there’s any argument or way to put down Rails anymore.
So it’s not about scaling. Rather, Matt sees the problem as an appearance of being unable to hire:
Try convincing a Fortune 500 company to program in Rails vs. Struts and they’ll probably choose Struts because there are thousands of Struts Developers. Is this a good decision on their part? I don’t think so. I think it’s more important to hire smart people that can learn a technology, rather than hiring those that know a technology. Of course, if someone knows a technology really well, there’s probably no harm in hiring them.
Considering the nice flow of job applications we’ve been posting on this weblog and the growing number that has been appearing at places like craigslist, I’m pretty sure this is a mirage. I haven’t heard of anyone getting into Rails development that hasn’t been able to hire.
Aaron Rustad, Technical Architect for Anassina, has written Ruby on Rails and J2EE: Is there room for both? for IBM’s developerWorks. It compares Rails with Struts and show the power of convention over configuration by listing code for similar actions. In summary, Aaron concludes:
So, should you consider Rails for your next Web application? Well, why shouldn’t you? It’s a well-written stack of components that work well with each other and are based upon industry accepted enterprise patterns. The Ruby language allows for fast development and adds to the framework by generating much of the application plumbing. Those who are familiar with MVC and ORM frameworks available in the Java world will have no difficulty wrapping their minds around Rails.
That’s a big part of the reason why Ruby on Rails is enjoying rapid uptake and grabbing mind share left and right. It’s the same ideas! There’s no paradigm revolution in terms of the core patterns and approaches that drives the framework. It’s all about taking familiar concepts and bringing them into a context of convention over configuration, tight integration across a full stack, and of course Ruby.
ionami has been working with EPSON for over 3 years. While we created the original EPSON Developers site in Java, they were surprisingly open to a switch. We sold them on maintainability, speed, and the lower overall cost. We took the opportunity to do a redesign, and move the original, public site to Rails for ease of management.
That’s great news! Landing EPSON with Rails development is definitely a great step in that elusive “corporate” direction. At the same time, ionami has announced they’re going to do all future developments using Ruby on Rails. They’re officially a “Rails Shop” now.