Scripting: a very good sheet with a hole in itScripting: a very good sheet with a hole in it

IT Manager: What’s this “Ruby on Rails” I keep hearing so much about? Will it help with our 3-month-late portal project?

Enterprise Architect: It is all hype. The Ruby on the Rails does not have the transactional integrity needed for the enterprise. J2EE is much more robust.

[Two months pass.]

IT Manager: Great job, people. Only five months late for a slow, buggy app. Learn Rails or you’re all fired.

Enterprise Architect: This is exactly as I was going to suggest. We need to move forward and deploy SOA across the enterprise. Only today morning I was researching this.

[Rimshot—curtain falls.]

Over the past few months we’ve seen enterprise blowhards finally abandon the J2EE positions they’d dug themselves into so many years ago. (Incredibly, some of the same people leading the defection helped deliver that ugly baby.) The gap in time, simplicity, and cost between scripted and BluePrints style apps can no longer be ignored simply by covering your ears and repeating “stateless session bean.”

Most Java programmers (and those parasites who only lecture them) lend half their brains to best-practices thinking. When Microsoft roundly humiliated the BluePrints pet store, the common retort was that the .NET approach was anti-pattern, and therefore illegitimate. Practically any technique can fall out of fashion and be condemned as “anti-pattern,” even a tenet of object-oriented programming like factoring common logic into base classes.

The genius of Rails is that it flaunts the best practices it chooses to follow, while camoflauging the ones it tramples upon:

Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control [sic] pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database…

This is the familiar Model 2 design, the “MVC variant” that has smalltalk programmers spinning in their object-oriented graves. For JSP programmers, it’s about as controversial as getting a Dell.

But Rails is sneaky. Its analogue for POJOs are neither plain nor old; they extend from an ActiveRecord base class that… [insert Jaws theme] talks to the database! In Java this is the deadliest of sins. And yet former J2EE-lovers have no problem doing it with Rails. Why?

Ego is one big reason. After dogmatically insisting on certain rules, it’s easier to pretend that Ruby is different in a way that makes those rules unnecessary than it is to admit you were wrong and change course with Java. It’s also easier to go with the pack than against it, and the Rails pack says DB in the base is okay; that particular hell hasn’t frozen over (yet) in Java EE.

Personally, I’d have no problem with even a Java ActiveRecord. It’s a rather obvious solution to the problem of persistence, once you get the “rules” out of your head. But I think Hibernate Annotations is an even better solution, not because it follows any particular rules but because it’s more powerful without being more complicated.

And there are a few other good things about Java. We all know that Wicket beats the pants off any other Web UI framework, including ActionController/View. And sometimes, compiling programs is a pretty good thing. Finally, don’t forget that you know Java much better than you know Ruby.

So try to figure out if your attraction to Rails is more about jettisoning unnecessary and constrictive rules than anything in Ruby itself (like syntax). If that’s the case, you’d do better to skip right to programming more freely in Java. Creative programming is not something to be ashamed of!

Memo to Rails

Those enterprise people you’re courting and starting to win over, just watch your back. They are toxic—that’s all I’m saying. Sure, they’re all curious and nice at first, but once they get their tentacles in, it’s nothing but “this isn’t good programming practice” and “that should be declaratively configured elsewhere.” You’ll see.

Actually, you know what? You can have them. Yeah, that’s right, take those friggin’ diagram-pushers. We can move a lot faster in Java once they’re gone.

Sincerely, Databinder

Codercomments

’…can no longer be ignored simply by covering your ears and repeating “stateless session bean” …’

LOL!

Got the hiccups? Try some “Stateless Session Bean Soup”:http://databinder.net/recipe/app/show/id/64.

Add a comment