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
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.
- 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.
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.
–
M. Edward (Ed) Borasky
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?
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.
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:
- 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
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 
).
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:
- 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
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.
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
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
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.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs