Is it the first to this community or already the discussion started.
sorry if posted it again.
This is for people who has not seen this…
Rails’ Ridiculous Restrictions, a Rant
I recently finished using Ruby on Rails to write a simple bug tracking
application. I thought I’d take this new RAD environment for a spin,
having heard all the hype.
It kind of blew.
Don’t get me wrong: I have to admit, it was a fun experience. There’s a
thriving community around Rails, and I get more email in an hour on from
the Rails mailing list than on all five of my Perl lists in a day.
Rails doesn’t do anything any other framework hasn’t done. BUT, I admit
it integrates all the bits and pieces bloody well and sprinkles the
whole thing with some smart marketing. A light webserver, ORM,
templating language, code generator and pre-built templates are nothing
new, but a killer viral 5-minute video demo of all those things working
together brilliantly IS.
But Rails also annoyed me. A lot. The developers have taken a brilliant
idea – brilliant – such an incredibly short distance. Insert sports
metaphor here.
Rails lived up to most of the hype, but who wants to hear about that?
As an entitled American who contributed not one line of code to Rails
and has used it for all of one project, I am of course brilliantly
qualified to bitch about it.
Here’s what SUCKED about using Rails:
- IT TAKES THE RELATIONAL OUT OF RELATIONAL DATABASE MANAGEMENT SYSTEM
Basically, Rails groks tables and columns well, but relations are second
class citizens.
This is so stupid. Rails is smart enough to look at my database’s
entrails and build accessors, craft templates and generate controllers
to handle the whole thing. I can Create, Edit, Update and Delete without
writing any code.
As long as I don’t leave the table. DO NOT LEAVE THE TABLE!
In fact, don’t even glance outside the table, like to get some labels
for some ids in a popupmenu.
If Rails is already taking a latex glove to my db schema, how about
feeling up those foreign key constraints I set up? Kind of a good hint
about how to arrange has_many and belongs_to associations, ain’t it?
OK, forget foreign keys. Let’s pretend I’m too amped on Mtn Dew to care
about imposing data intergrity at the data level.
There’s still no excuse. Because Rails insists I name my foreign key
columns table_id if I want to live the good life. When I do so, I
shouldn’t have to declar has_many and belongs_to.
Perl’s Class::DBI::Loader is smart enough to autodetect relationships,
and has been for some time. There’s no reason Rails can’t do this as
well.
This isn’t some minor feature. Any halfway decent data model is going to
have tables that RELATE to one another. That’s why we keep them in
Postgres or Oracle or Mysql or SQLite instead of a flat file.
It gets really really old retyping the same type of popup onto a
template and a has_many for every belongs_to and a belongs_to for every
has_many.
Rails should be able to do this. After all, it makes three-way outer
joins look effortless with the :include attribute to Class.find. Not
even Class::DBI is there yet.
Ideally:
-Rails detects relationships from foreign keys or column names.
-Rails automatically sets up has_many and belongs_to associations at the
model level.
-Rails creates some extra @instance_variables at the controller level to
pull data from other tables in.
-Rails uses popup menus at the scaffolded view and generated view level
to select foreign data. For example, user_id becomes a popup menu of
users, resolution_id becomes a popup menu of bug resolutions.
- RAILS DOESN’T PLAY WELL. WITH ANYONE. NOT EVEN ITSELF.
The cool thing about the Rails demo is the guy, I think it’s that
Scandinavian guy who invented Rails, is sort of playing. He says “woops”
about every three seconds. He changes things in a text editor and BOOM
– the application changes.
But do you remember that moment in the demo when the play turns ugly
with a big ole error page? It’s when he tried to update his db schema or
model or something. It doesn’t work because he has to reboot the
webserver before those changes take effect. Which he says and moves on
quickly.
Well, it turns out that webserver rebooting requirement really sucks
when you’re trying to, um, Rapidly Application Develop.
Now, I understand why this restriction exists. If Rails has to look at
your schema on every request, you’re going to take a performance hit.
But having to reboot the webserver makes Rails feel like a step backward
from even CGI Perl in terms of speed. At least in that environment you
can just reload the script to see if your changes worked.
Why can’t Rails adopt the smart middle ground? The webserver does not
need rebooting, until you set a :fast flag somewhere, in which case
Rails caches the schema info.
Since Rails already differentiates development from production, this
should be pretty painless to implement.
—>Rails also doesn’t play well because it will overwrite your code.
Here’s the scenario: you started a project in scaffolding mode because
you were learning Rails and this is Rails’ coolest and easiest mode.
You made some slight modifications to the models and controllers as you
associate your models with one another.
Then you discovered you wanted to depart slightly from the scaffolding.
So you backed out and figured out how to ruby script/generate scaffold
Thing. Except – Woops! – this overwrites your old code, your models
and controllers.
In the case of controllers, you may be safe because the scaffold
generator will use the plural form. But your model is probably toast.
Rails allegedly will ask permission first but, um, it didn’t.
The solution is to stop playing and start over at the beginning and DO
THINGS RIGHT THIS TIME, DAMMIT! Here is an actual entry from the Rails
FAQ:
"Q012:That stinks… I want the scaffold code without starting over!
Too bad. Start a new rails project, run scaffold, then manually add the
missing stuff to your new project from your old project with copy and
paste."
Are we having fun yet?
—>This “back to square one” technique returns again and again in using
Rails. When I installed the login-engine plugin for Rails – which is
really cool, by the way, even Perl’s CPAN does not have libraries
operating at this high a level yet – there was no documentation on how
to make it work with my existing user table. Fine. I let it build its
own table, made a new user and logged in.
But then when I went to install user-engine, which adds access controls
on top of login-engine, it again did not want to integrate my existing
data. The user I had created 5 minutes earlier in login-engine was
useless. I had to let user-engine autogenerate a new user named “admin”
with an insecure default password.
- YOU CAN’T READ THE FACKING MANUAL BECAUSE THERE IS NO FACKING MANUAL.
Rails has no manual.
Let me repeat that: Rails has no manual.
If you haven’t used Rails, you may not believe me. Well, go visit the
Rails documentation page:
Hmmm … We have APIs, Tutorials, HowTos, Snippets, but no manuals.
There’s a section called “manuals” but that’s documentation for side
projects, like a standalone utility called SwitchTower, or how to
upgrade rails, or “Routing,” whatever that is (odd place for a
networking primer).
You do have “API,” at api.rubyonrails.com, which is a nice reference.
Actually, no, it’s a baffling, messy, ugly, confusing jumble of
documents with a fairly useless introduction. Once you figure out that
all key classes are annoyingly prefixed with the word “Action” and that
the base classes are actually named Class::Base instead of just Class,
you can pretty much usually find what you want if you know what you’re
looking for.
But this is a terrible way to learn the framework.
Which brings us to the section “Books.” Ah, the REAL manual.
Let’s set aside that it feels a little slimy to start in on a “free”
application framework and a very slick “free” video demo and read a
bunch of free O’Reilly tutorials only to find out, when it gets down to
brass tacks, you’re going to have to shell out $35 for a linear,
rational, comprehensive overview of the language.
Ya, let’s set that aside. Fine. Harumph, but fine.
What gets me is I am just not going to pay to read 570 PAGES about a
framework! I’d actually pay twice as much if they could boil this sucker
down to 200 pages or less!
If I am going to waste time, I might as well go online, where the
information is free and up to date.
If you want to sell me a book on a rapid development framework, keep it
tight! The whole point of my paying for the book is that my time is
valuable. And the whole point of you, framework developer, writing the
book is that you can most elegantly and efficiently summarize the
framework because, well, you know the whole story!
- RAILS ATE MY DATA, OR AT LEAST STOOD IDLY BY WHILE MY DATA WAS EATEN
Rails knows which column is varchar(40) and which is int(11), but don’t
expect it to do anything with that information other than maybe size the
text fields in your scaffolded HTML form.
If you plop 80 chars of data into a 40 char field, Rails goes ahead and
passes it along to the database this way. A certain extremely popular
“database” will silently amputate data in this situation. Rails inserts
the data and raises no error.
This is especially silly since a> Rails already incorporates methods to
validate input for particular columns and b> Rails is already recording
column types.
- THE FIRST RULE OF RAILS IS: DO NOT TALK ABOUT RAILS’ RULES!
Rails has lots of important rules that you need to follow if you want
things to work easily and to really flex the power of the framework.
But all the demos I saw, including the Onlamp.com tutorial, were so busy
hyping how easy Rails is that they glossed over the rules, even though
they are pretty simple.
The trouble with that approach is that people end up trying the
framework, and use techniques from elsewhere that can really gum up the
rails works. Like naming database tables in singular form (ala Philip
Greenspun) or naming a foreign key “user” instead of “user_id” (ala
Class::DBI). And then they become unnecessarily frustrated with the
framework.
Rails needs to put a set of simple rules in a place where most newbs
will see it. Things like:
-name your tables in the plural
-foreign keys should always be named like so: tableNameInSingularForm_id
So: user_id (foreign key) → users (table)
-models are named singular
-controllers are plural, at least in some cases
-many-to-many jump tables should be named:
alphabeticallyFirstTablePlural_alphabeticallySecondTablePlural
So: axes_users
-columns in many-to-many jump tables should be named like other foreign
keys
So: axe_id and user_id
-columns named created_on and updated_on will automatically be populated
correctly
- THERE’S MORE THAN ONE PLACE TO SAY IT
You want to setup some kind of configuration for some particular rails
package. You:
A. modify your existing code, which will use the package
B. modify code in the package itself
C. specify when you install or bootstrap the package via ruby script/*
and the command line
D. modify -APPBASE-/config/environment.rb
E. modify -APPBASE-/app/controller/application.rb
F. modify -APPBASE-/config/environments/-ENVIRONMENT-.rb
I had one engine that needed four of those.
Anyway, those are all the headaches I can remember. I’m pretty sure I’ve
forgotten a few, but oh well.
I only say all this because Rails is the first framework worth
criticizing.
Oh, not really. Who am I kidding? I say this because I like to complain.
But hopefully more people will start learning Rails, if only so they go
back to their home platform all charged up to do it one better.
a Hack
Wednesday, February 15, 2006
thanx
g.balaji