Skidding On Rails
Posted at October 10, 2005 01:35 AM - Category: Coding
So, I've been looking around for some sort of employee time tracking system to use at ASO. And naturally, everything out there just seems to suck. My options are either ugly Windows apps or ugly web-based apps. Neither of which offer anything excellent and all of which are overpriced.
So, I looked at making my own. Given that I've been itching to really sit down with Rails and give it a full-blown try, I chose it as my framework for the app. I've already read through and understand a good amount of Ruby syntax, Rails' API, and how everything works together. When you're running a hosting service that supports Rails, you sort of have to. I'm definitely no expert, but I'm not supposed to fumbling around either.
However, I was fumbling around with Rails. I hit an initial snag that obviously wasn't anything to do with Rails (the Ruby-MySQL interface I had installed wasn't able to login to the server and needed two commands to fix). But after that, I didn't really feel like I was getting any benefit from using this framework. Ruby is a terrific language, so I don't feel like it was a syntactical issue. Rails claims less code and increased productivity. Instead, I felt as though I was getting no benefit whatsoever, on top of having to maintain the knowledge of a separate language and API.
Of course the big question is: why? Why was I not feeling any improvement or benefit? Where did the magic go? I've since realized what it is: Rails forces a design model on you. The one sort of model that Rails uses as a base is MVC, and that's a very good thing, but it then combines in CRUD on top of that. So, what happens is you are sort of forced into thinking about your application in the way Rails thinks. You must think of your application in terms of objects and data models, controllers and views, etc. And for many, that can work out quite well with the application they are designing, but I also feel it restricts how you have to think about your application.
The time tracking software I started doesn't really follow the CRUD model too well. You're not deleting anything or doing any creation except for logging. It's basically just R and U. It also didn't jive too well with the MVC model, as I need to do some lower-level SQL to accomplish a good 3NF database layout. Thinking about showing an employee status page had to make me convolute the Rails model to fit what I was doing. So, Rails implicitly imposed a design model on my application and that hurt my ability to design my software, thereby reducing my productivity as I tried to force things to work.
Now, I know what you're probably thinking is "You're just not thinking about it the right way. I'm sure there's a clever solution." And that would be nice, but it's not really the intent of Rails. It's meant to be easy-to-use with "more joy", but instead I became frustrated with it. My only option was to really just strip Rails down to a simpler controller-view model, which removes almost all of its proposed benefits.
Your next question should then be "What else is there to use, then?". Well, as I've written about before, I've already got the stripped-down form of Rails in PHP form (which I've improved on since that post). I don't have a full API, but I also don't really need it. What I've got is really just a layer over an object in PHP. You can execute a function and define a view template without having to write up extra code on top of that. It may not get the "joy" Rails claims, but it does get the "less code" part.
Now, don't get me wrong, Rails can be a real time-saver and beneficial framework, but I don't see it as being the swiss army knife that a lot of people think it is. I just worry that people read all the marketing and promotion surrounding it, take it as being true, and get stuck using something that may not be the best tool for their job. For me, Rails isn't it.
