Just Say "No" to Rails...
Not that I'm considering starting a trend here, with this post that could be considered a flaming of the Web 2.0 poster child, but having spent the last few months frustrated and now back at square one, it should be clear my warnings are in your best interests.
Oh Rails, where to begin.
Why don't we start with the coy marketing. What better a demo than to have your prospects actually use your tool, and convince themselves that they are empowered. I should tell my boys in Sales Engineering at RedDot to work this into the standard demo - it's absolutely brilliant, along with the rest of the compelling story painted by the boys at 37signals (no need to trackback).
So, after the seasoned Java developer swallows his pride and scaffolds out a recipe or two in Rails, the suspicion begins to grow into a semi-solid confidence that "this could work, its got potential." I only wish it would stop there, but it doesn't, and most developers, as they should, begin their first forray into this new technology.
To make a long story short, I've just backtracked while leading a start-up project with 3 seasoned Java developers who were all similarly turned on by Rail's appeal. What's not to like? You have several engineering best practices baked in, and some lightning fast efficiency boosters, who wouldn't go for that instead of setting up scripts to distance yourself from configuration quagmires in Hibernate, or whatever mile-high J2EE software stack you've got cluged together, eh?
I'll tell you what's not to like:
- Nothing is well documented.
- Nothing. I'm serious. I know, becuase I built a Rails server on Linux from scratch, not using InstantRails like you did when building the Cookbook sample.
- Capistrano is a joke. Again, maybe I'm missing some treasure trove of documentation, but even so, there are no best practices in place, that's for sure. Even if there is a convention, great, where is it?
- All but the most trivial associations require laborious hardcoding and retrofitting to get the level of detail and elegance you'd expect in Java. Point blank: ActiveRecord is NOT complete, nor robust. This is a known shortcoming to the Rails-cognescenti
- Good luck performance tuning, beyond using the right SCGI processor / Web Server combo (Apache/FastCGI).
- I don't know if any of you have ever heard of Eclipse (grin) but forget any of the efficiencies you would expect when using RadRails, the Eclipse clone for Ruby. Not even close. Can we say Ctl-Space does nothing? Ouch. Scaffolding is great, but mama don't take my IDE away. That's zero-sum.
- In my humble opinion, the authors did a guerilla-worthy job targeting non-technical web folk: designers, UI engineers and lightweight programmers who are NOT Java zealots. For all but the most trivial applications, you will run into issues long term issues that are often gamebreakers.
- Couple this lay audience with the fact that Rails has so many classical architectural patterns baked in by convention, they created the impression that Rails was going to turn little old me, a graphic designer, into a veteran, MVC-smokin' software engineer! Keep smoking. Just don't jump out of any windows, Superman. Um-kay?
- That sense of empowerment is a dangeours thing, becuase it breeds fanatacism. And fanaticism leads to evangelism. Ask Rackspace. So now, every Harry who can complete the incredibly straightforward Cookbook sample is now a Rails pundit with 3 years of hands-on experience, spewing Rails mantras all over the internet clutching for a piece of the blogosphere, cautious as land developers in Vegas.
- Let's not forget that the developers of Rails had the luxury of lifting best practices from software engineering, in terms of deployment, MVC and scaffolding, from other known frameworks AND at the same time was not limited by the conflicts of supporting multiple codebases. Anyone who has configured a deep framework has had that Devil on his shoulder telling him or her that they could have just built a stack from the ground up in less time. That's a luxury the Rails group had: they controlled the entire stack: MVC, OR mapping, application deployment... literally the entire shebang! This is the kingping for pulling of "convention" becuase you can't enforce conventions when wrangling someone elses off the shelf code.
- Rails is a great, great tool for rapid prototyping. Bulid it in Rails, get VC, and then deploy using Java, just like my startup did (OK, sans the VC part). I'm a huge fan of build to throw away, and lessons learnt are lessons leveraged when you do it right. Rails to me is the first measurement in the carpenter's law.
- The concept of convention is long overdue. SAP relies on convention in it's development paradigm. An architect spends a long time making a decision from atop the mountain, it is written in stone as the best practice, and then the product is tailored around these best practices. Dogmatic? Potentially. But then again, how many people do you see starting their own public transit companies because they dislike the route? They don't, becuase the systems in place are reliable, dependable and follow a convention, wether or not it is the best, that's life. But as a corallary, you try letting all the passengers decide what the best route to lay the tracks are.