Rails - Mar 2006 - comments for joel about rails in software discussion

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:





1. 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.






2. 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.





3. 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:

http://rubyonrails.org/docs

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!



4. 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.






5. 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



6. 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

-- 
Posted via http://www.ruby-forum.com/.