If you were to plot my interest in Ruby on Rails on a graph, it’d resemble a turtle shell. When I first heard about RoR, I was mostly anti-framework. I didn’t like (and still don’t) the idea of blackbox development. It’s fine for simple CRUD applications (and for complex ones too I suppose), but for anything outside the box it usually ends up in a struggle.
Despite this opinion, I eventually let down my guard and began reading up on RoR. It was difficult to separate the fanboyism from actual reviews; it seemed that all Rails users were fanboys! (I’m generalizing here for the sake of communicating a point.) Maybe the RoR team had actually found the perfect balance between convenience and flexibility?
After a few reads at B&N and some playing around locally, I decided to give it a try on a new project at work. Here’s my experience:
- Install Rails: Easy.
- Complete useless Rails scaffold demo: Easy.
- Get Rails to communicate with PostgreSQL db: Easy.
- Get Rails to communicate with the correct schema on the PostgreSQL db: Tricky. Rails was only able to see schemas owned by the “public” postgres user for some reason. I also had to include an obscure directive in the db config file.
- Get Rails to play nicely with existing schema: Very difficult, not worth the trouble.
That’s how far my RoR experiment went. To paraphrase a user from the freenode IRC channel, Rails isn’t meant to be “bolted on” an existing project. It needs to be there from the start, else it’s a headache to even get to the point where you can leverage the features of Rails.
This “greed” factor reminded me of Apple. And then it hit me: Rails fans are the developer version of Apple elitists:
“Oh, you’re having trouble with your PC? Well, my computer just works! It’s a Mac!”
“Oh, you’re having issues with development? Well, my framework just works! It’s Ruby on Rails!”
Of course it works. It works because the framework owns everything in your application.
