RoR sucks, and heres why

M. Edward (Ed) Borasky wrote:

I suspect the reason a
lot of web apps are written in PHP is because the PHP folks have tuned
their code.

That’s completely wrong. I doubt that you can find any interpreter that
is slower than PHP. The reasons why PHP is used have nothing to do with
performance. Still, like Rails, PHP is “fast enough” for most people,
and, more important, it scales well.

Marcel Molina Jr. wrote:

documentation of the internals. Again, patches welcome. Documentation patches
don’t require tests :wink:

Au contraire – documentation requires testing. I would encourage as
much automation as possible in generating documentation as a result.
RDoc seems to me to be a nice compromise between documentation written
independently of the code and a full “literate programming” approach,
where you write the documentation and embed the code in it. If I were
starting something like Rails from scratch, I’d probably design around a
literate programming approach, though – it’s worked very well in a
number of other projects.

  1. Implementing new features takes priority over fixing bugs.

Rails has been in growth mode for a while. With the release of 1.0 we have
said, “This has enough features.” The 1.0 branch will only receive bug fixes
now. Rails hasn’t stopped its development but non of the core team has an
interest in making it huge and bloated

Thank you! Amen! etc.

can be compared to those same frameworks as well. Ruby 2, out there in the
distance, will likely make that a non issue. Rails is most of the time fast
enough. There are real world apps with lots of traffic backing that claim.

  1. As a working performance engineer, “most of the time fast enough” is
    to me at best an excuse and at worst denial. Given Java’s notorious
    performance issues, it’s always been a big surprise to me how much it’s
    been used for “enterprise web applications”. THAI (throw hardware at it)
    is not a viable option in the harsh realities of the world. Java’s come
    a long way since Java 1, and it still hasn’t overcome the stigma of
    its poor early performance relative to C and C++. I suspect the reason a
    lot of web apps are written in PHP is because the PHP folks have tuned
    their code.

In any event, improving the performance of the Rails internals should be
a high priority. You can’t do anything about the database or the web
server or the browser, but then neither can Perl, C, C++, PHP, Java or
Python. I’m glad someone of Stefan K.’ caliber is working on it, and
I’m glad the core team is integrating his work.

I’d recommend implementing the TPC-W benchmark in Rails and seeing how
you compare with other frameworks, given identical hardware, OS, web
server and database configurations. There’s also an open-source
equivalent, although it doesn’t have the clout in the marketplace that
TPC does. Customers and users keep score.

  1. Waiting till Ruby 2.0 is also not a viable option. I don’t know what
    the schedule is for YARV, but it seems to be the best bet for speeding
    up Ruby itself. From what I’ve seen of the Ruby language, there’s no
    reason in the world Ruby can’t be speed-competitive with any other
    “interpreted” scripting language. I went by the YARV web site a few days
    ago and it looks like they could use some help – considering the value
    it promises, it seems like they have an awfully small team.


M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

Its so easy to do SQL that you never realize how many data accesses you
are
doing until you do a tail -f on the development.log.
Innocous statements like User.find or User.find_all ("name=“x”) are so
easy
to code using ActiveRecord but one hardly realizes that it could
generate so
many SQL queries!!

Jeremy E. wrote:

In the interests of starting a more serious discussion of problems with
Rails:

The only thing that really bothers me about Rails: I have to use a
seperate set of FastCGI servers for every application. It isn’t possible
to take 2 applications, e.g. RForum and Typo, and make them run on the
same server, because their class names collide. This probably isn’t of
great concert for applications like Backpack that are created from
scratch, but it is for many smaller websites.

To a few people…

Jeremy E.:

Is there a timeline for how long the 1.0 branch will be maintained?

Until 1.1 is out in the wild and proven stable.

Ed:

I’d recommend implementing the TPC-W benchmark in Rails…

Please Do Investigate ™. This seems like something most any
programmer working in Rails could do. It doesn’t require deep
knowledge of the internals. At least not for the first version. Once
you do have that first version up, post a link here on the mailing
list to the code and others will help you improve it until it reflects
the best Rails can do.

THEN we can start taking about possibly taking some action on
potential trouble spots.

THAI (throw hardware at it) is not a viable option in the harsh realities of the world

When the core team talk about how Rails is fast enough and that you
should THAI then its because it’s fast enough for us and because we
do throw hardware at it.

I fully recognize that there are situations and organizations where
the economics of that doesn’t fit. That’s the best motivation in the
world to start getting your hands dirty and doing something about it.

Rails is a collection of solutions from people who had the problems.

To Vivek:

Its so easy to do SQL that you never realize how many data accesses you are
doing until you do a tail -f on the development.log.
Innocous statements like User.find or User.find_all ("name=“x”) are so easy
to code using ActiveRecord but one hardly realizes that it could generate so
many SQL queries!!

Hu? Both of those examples you mention causes exactly 1 query each.
How would writing that by hand make it any less?

Also, “until you do a tail”. Here’s a recommendation: ALWAYS run a
tail during development. It’ll teach you a lot about how Active Record
works and will drip in surprises instead of saving it all for a big
bang in the end.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework

Yes,I do a tail now. What I meant was that rails reduces the efforts
drastically when it comes to working with SQL, that one never realizes how
much of DB access one is doing.I actually entirely bypassed learning SQL! A
book I bought to learn SQL is gathering dust:-)

I’d recommend giving it a read ever still. I have yet to complete a
single Rails project that didn’t require a drop down to find_by_sql at
some point or another. For either performance, statistics, or really
hairy joins.

You can start by watching along in the log and see what methods
generate what SQL statements. That’s a great way to pick up simple SQL
while still moving forward.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework

Hu? Both of those examples you mention causes exactly 1 query each.
How would writing that by hand make it any less?

Also, “until you do a tail”. Here’s a recommendation: ALWAYS run a
tail during development. It’ll teach you a lot about how Active Record
works and will drip in surprises instead of saving it all for a big
bang in the end.

Yes,I do a tail now. What I meant was that rails reduces the efforts
drastically when it comes to working with SQL, that one never realizes
how
much of DB access one is doing.I actually entirely bypassed learning
SQL! A
book I bought to learn SQL is gathering dust:-)

On Sat, Jan 07, 2006 at 05:03:05PM -0600, Marcel Molina Jr. wrote:

  1. There are a lot of bugs.

Undeniably, there are many pending bug reports. There is a distinction,
though, between there being many tickets and many egregious bugs. Rails is
always going to have bugs. A lot of bugs, though, are edge cases or otherwise
not a priority so simply going off the number of pending bug reports is not
the whole picture. Regardless, if you are so inclined go through and
identify, say, the 10 most critical bugs as you see it and post their ticket
numbers to the core mailing list making a case. Help prioritizing bug reports
would be appreciated.

One other thing. Anyone is welcome to go through the bug list and turn a
bug
report into a PATCH ticket. In fact, you are not just welcome to, you
are
encouraged to.

marcel

Yes,I do a tail now. What I meant was that rails reduces the efforts
drastically when it comes to working with SQL, that one never realizes how
much of DB access one is doing.I actually entirely bypassed learning SQL!
A book I bought to learn SQL is gathering dust:-)

Hi Vivek

the point you raise is valid with pretty much all the ORM you’ll be able
to
find (including Hibernate/NHibernate on J2EE/.NET, or ActiveRecord for
Rails). These tools helps you in term of productivity and in ease of
development in general, yet you have to be careful as the abstraction
can
(not always, but still can) have a cost.

Learning SQL and looking for bottlenecks at the db queries level will
prove
useful anyway!

cheers

Thibaut

Marcel,

Thank you for responding. I apologize if my list sounded a bit
bitter. It’s probably the result of spending many hours learning and
modifying the Rails internals and submitting a patch (with tests) only
to have it not applied (but not rejected either).

Rails would likely benefit from some more
documentation of the internals. Again, patches welcome. Documentation
patches
don’t require tests :wink:

I’ll try to work on some documentation patches for the internals.

The relatively high barrier of entry to patch submissions is also largely the
reason why you like Rails so much.

Agreed. More often than not the added features are useful to me.

Rails has been in growth mode for a while. With the release of 1.0 we have
said, “This has enough features.” The 1.0 branch will only receive bug
fixes
now.

That’s good to hear. Is there a timeline for how long the 1.0 branch
will be maintained?

Regardless, if you are so inclined go through and
identify, say, the 10 most critical bugs as you see it and post their
ticket
numbers to the core mailing list making a case. Help prioritizing bug
reports
would be appreciated.

I’ll try to make time to do so.

Rails is most of the time fast
enough. There are real world apps with lots of traffic backing that
claim.

True. This is certainly less of an issue than the issues mentioned
above (though faster is always better :slight_smile: ).

What is the problem with this? You want intension revealing method names.
Your text editor should alleviate the hassle of typing the whole thing
out.

It’s mainly an issue when I feel better, shorter names could have been
chosen (e.g. options_from_collection_for_select =>
collection_select_options). The typing isn’t so much the problem as
reading code. Longer method names take more effort to mentally parse.
Honestly, this is a pretty small issue, which is why it was the last
one on the list.

Thanks for the list. It’s very useful to have people who like Rails pointing
out what they don’t like rather than people who’ve already made up their
mind
to hate it looker for things to throw rocks at. So I do really
appreciate
your candor. I’m all for people willing to help.

I’ll try to see if I can do more than just provoke discussion. Thank
you for your thoughtful response and level-headedness.

Marcel Molina Jr. wrote:

On Sat, Jan 07, 2006 at 05:03:05PM -0600, Marcel Molina Jr. wrote:

  1. There are a lot of bugs.

Undeniably, there are many pending bug reports. There is a distinction,
though, between there being many tickets and many egregious bugs. Rails is
always going to have bugs. A lot of bugs, though, are edge cases or otherwise
not a priority so simply going off the number of pending bug reports is not
the whole picture. Regardless, if you are so inclined go through and
identify, say, the 10 most critical bugs as you see it and post their ticket
numbers to the core mailing list making a case. Help prioritizing bug reports
would be appreciated.

One other thing. Anyone is welcome to go through the bug list and turn a
bug
report into a PATCH ticket. In fact, you are not just welcome to, you
are
encouraged to.

Unfortunately many patches seem to sit in the tracker for ages, and when
someone from the core team finally takes some time to look at them some
are already outdated. It would increase the motivation for potential
patch submitters a lot if patches were processed more quickly. If
they’re not good enough, just reject them, but having them sit in the
tracker without anyone caring can be frustrating.

On Fri, Jan 13, 2006 at 02:22:31PM -0500, Wilson B. wrote:

identify, say, the 10 most critical bugs as you see it and post their ticket
someone from the core team finally takes some time to look at them some
to continually maintain patches against trunk, particularly when they
Is there something else I should be doing?
We’ve actually talked about this in core and as I remember it agreed
that we
wanted to provide this as a customization. I’ve only scanned over the
patch
but it looks good. It’s the appropriate implementation and its tested.
Thanks. Will look at it closely soon and likely apply it. Sorry for the
hold
up. You’ve done everything just fine.

Thanks again,
marcel

  1. Raw image upload
    I’m uploading a raw image into a blob column and noticed that unless
    I overwrote the model attribute writer that Rails would try to load a
    ruby object for the image. So in the model I did this:

    def picture=(picture_field)
    write_attribute(:picture, picture_field.read)
    end

and things work fine … except if the user fails to select an image
to upload, in which cases I get an error:

undefined method `read' for "":String

Any ideas for avoiding this error message in these cases? It seems
like some kind of conditional wrapped around the write_attribute
command should work … or maybe there’s a better way to upload a
raw image.

  1. Conditional render
    I’d like to do something like:
    <%= render(:partial => “login” :unless_controller =>
    “new”) %>

What’s the syntax? … or should I be using a different logical
structure, like a controller?

Thanks,
russ

On 1/10/06, Andreas S. [email protected] wrote:

numbers to the core mailing list making a case. Help prioritizing bug reports
are already outdated. It would increase the motivation for potential
patch submitters a lot if patches were processed more quickly. If
they’re not good enough, just reject them, but having them sit in the
tracker without anyone caring can be frustrating.

Indeed. I know there are many patches in the tracker, but it would be
nice to get a yes/no as quickly as possible.
Also, is the “patch bump” procedure talked about anywhere?
I don’t want to bother the core list every week, but I also don’t want
to continually maintain patches against trunk, particularly when they
are simple.
As an example, I think this is a pretty good patch, but I don’t want
to be defending it two months from now as new fixtures are added to
the trunk test suite.
http://dev.rubyonrails.org/ticket/3402

The actual functionality change is stable, but when you’re submitting
patches to the db_structure scripts… that could get irritating to
maintain.

Is there something else I should be doing?

The stuff between the <%= %> is plain old Ruby. I would do this:

<%= render(:partial => “login”) unless_controller == “new” -%>

(The hyphen near the end suppresses the new line if the expression is
blank.
Or something like that.)

Jim


  1. Conditional render
    I’d like to do something like:
    <%= render(:partial => “login” :unless_controller => “new”)
    %>

What’s the syntax? … or should I be using a different logical
structure,
like a controller?

Thanks,
russ

Sorry that should have been
<%= render(:partial => “login”) unless controller == “new” -%>


From: [email protected]
[mailto:[email protected]] On Behalf Of Jim Hughes
Sent: Friday, January 13, 2006 4:16 PM
To: [email protected]
Subject: RE: [Rails] a few intro questions

The stuff between the <%= %> is plain old Ruby. I would do this:

<%= render(:partial => “login”) unless_controller == “new” -%>

(The hyphen near the end suppresses the new line if the expression is
blank.
Or something like that.)

Jim


  1. Conditional render
    I’d like to do something like:
    <%= render(:partial => “login” :unless_controller => “new”)
    %>

What’s the syntax? … or should I be using a different logical
structure,
like a controller?

Thanks,
russ

Sorry that should have been
<%= render(:partial => “login”) unless controller == “new” -%>

Thanks Jim. Unfortunately, “controller” doesn’t call up the name of
the controller, but neither does controller_name , at least not
within the view.

I’m working in a layout and just want to call a partial from within
the layout as long as the initiating controller is not of a given
name, “new”.

I’m assuming this is straightforward.

Thanks,
russ

On Jan 13, 2006, at 5:35 PM, Russ McBride wrote:

name, “new”.

I’m assuming this is straightforward.

Thanks,
russ


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Use controller.controller_name or controller.action_name

Cheers-
-Ezra Z.
WebMaster
Yakima Herald-Republic Newspaper
[email protected]
509-577-7732

“Guest” ([email protected]),

If you don’t like the questions people are posting here, please stop
reading. This is a voluntary community of people helping each other.
If
someone posts a question that everyone thinks is a waste of time, then
no
one will respond. Don’t ruin the friendly, helpful atmosphere here with
your negative, content-free posts.

Sorry to all for dragging this out, but that type of post really bothers
me.

Eden

RFM, pal!

Russ McBride wrote:

Sorry that should have been
<%= render(:partial => “login”) unless controller == “new” -%>

Thanks Jim. Unfortunately, “controller” doesn’t call up the name of
the controller, but neither does controller_name , at least not
within the view.

I’m working in a layout and just want to call a partial from within
the layout as long as the initiating controller is not of a given
name, “new”.

I’m assuming this is straightforward.

Thanks,
russ

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs