The Rails weblog moves to Typo (finally!)

When we originally launched, 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.

And thanks to Jan and the rest of the lighttpd team for creating just a spiffy web server. We’re serving both this blog and the manuals site of lighttpd now.

David Geary demonstrates Rails at Denver Java User Group

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.

Integrating Wee components in Rails applications

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.

Convincing those CxO's to see beyond Struts

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.

And the step from corporations like Bank of America posting job listings with Rails as a “nice to have” to “required” is not that big. And with wins at places like EPSON, it gets even easier.

Comparing J2EE and Rails on developerWorks

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.

EPSON chooses Rails for developer site

Jason Wong of ionami has announced that they’ve just launched for EPSON on a Rails platform:

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.

Podcasting all over the Rails

Scott Barron has taken Ruby on Rails on the air. Listen to the Ruby on Rails Podcast:

On the show we will delve deep into the warped psyches of the members of the Rails core team. We’ll talk about news related to Rails and the web devlopment communities in general. We’ll talk about tips and tricks you can use to to write better Rails applications, and become a better person.

Rails 0.13.1: Faster for all, eager limits, more Ajax

We’ve returned the default MySQL/Ruby bindings to their former glory, made sure development mode on big applications didn’t get penalized on resetting the object space, and cut WEBricks lust to have a new database connection per request. All changes that actually allows Rails 0.13.1 to live up to the promise of better performance for everyone.

Additionally, we’ve made it possible to use :limit and :offset together with eager loading of has_one and belongs_to associations (has_many and has_and_belongs_to_many will still not work due to the nature of how SQL joins work).

And of course there’s a big bag of delicious additions and fixes. Be sure to checkout the changelogs for the full scoop as usual: