Financial services firm desire Ruby on Rails skills

Cincom Smalltalk has long touted the Kapital system at JP Morgan (PDF) as an example of what an edge in productivity can mean for profits in financial services. So, it’s not entirely surprising to see MSCI Barra from Berkley, California look for a senior software developer and desire that the candidate has Ruby on Rails skills for use with their investment systems. I believe we may just have an E for Enterprise here.

Where are the hours wrestling with JavaScript in venkmann?

Jaikoo is longing to feel like a man again. And nothing like doing long hours debugging impossible JavaScript has that feel of a hard day’s work:

In fact its so easy I feel totally un-masculine right now. Dag nammit, where are the hours wrestling with JavaScript in venkmann? Where’s the fun without the pain? I mean the real pain!!! GRRR!!! Come on Rails!! Make me feel like a man again!!! Stop making it so easy for gawd sakes, throw some XML in there or something, make it more cryptic;). So this is me, feeling like a total girly boy right now, signing off from the frilly land of Rails. starts manicuring nails

Make it as easy as not to.

The Rails weblog moves to Typo (finally!)

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.

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.