Well now that I got your attention.... Why RoR sucks: 1. It''s smarter than me. Just when I think I''ll have to do some mundane thing (like I use to in PHP or ASP), I find out RoR does it already for me. 2. It takes about half or less code to put my stuff together in RoR than it did in PHP, ASP, ASP.NET, etc. It seems so unnatural that I can have a method with only 4 lines of code, and three of those were error handling - YET it does what it should, no fuss, no muss. 3. I use to worry about giving my client an estimate and then running over the alloted hours BIGTIME. Now, RoR has me UNDER the hours consistently. I feel so dirty now still giving my old school estimates that ASP smashed into my head repeatedly knowing I had to hand hold it all the way. 4. I can finally take those jobs that require "the other" databases like Postgresql, MySQL, etc. without rewritting my data layer. 5. RoR took away my connection strings! Now its just too easy :-) 6. RoR makes it easy to run tests across my code, next it will generate docs for me from my code ... oh wait it''s buddy RDoc does that now.... 7. I use to enjoy those frustrating nights banging my head against the wall trying to figure out why my site worked on Windows 2000 but not Windows 2003, now with RoR, my sites "just work". 8. Now when I see a .NET article I cannot seem to stop yawning. How many MSDN magazines now sit beside my desk STILL in their plastic wrappers? 9. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it takes a good 20+ lines AT LEAST. In case someone hasn''t caught on yet (their flame throwers ready at hand) -- RoR doesn''t suck. Just thought I''d add that in in case someone didn''t have a sense of humor :-) - Mark -- Posted via http://www.ruby-forum.com/.
> In case someone hasn''t caught on yet (their flame throwers ready at > hand) -- RoR doesn''t suck. Just thought I''d add that in in case someone > didn''t have a sense of humor :-)10. It made me hate my non-rails job using ASP.Net :) -- rick http://techno-weenie.net
Yeah, I see what you mean. RoR really does kick butt, er, suck. =-D Mark Haliday wrote:> Well now that I got your attention....<SNIP>> In case someone hasn''t caught on yet (their flame throwers ready at > hand) -- RoR doesn''t suck. Just thought I''d add that in in case someone > didn''t have a sense of humor :-) > > - Mark-- Posted via http://www.ruby-forum.com/.
Here, here. =) -c Rick Olson wrote:>>In case someone hasn''t caught on yet (their flame throwers ready at >>hand) -- RoR doesn''t suck. Just thought I''d add that in in case someone >>didn''t have a sense of humor :-) >> >> > >10. It made me hate my non-rails job using ASP.Net :) > >-- >rick >http://techno-weenie.net >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060105/8672562a/attachment.html
Why RoR Sucks (cont.) 1. I spend 2 hours trying to figure out a difficult way to display action logic only to find that RoR already had a 30 sec remedy. 2. The RoR community actually replies to [NOOB] posts. 3. I don''t get to spend 3 months getting my head around a deployment container only to discover that it really is possessed by a whip lashing sadist demon. On 1/5/06, @ wrath. rubyonrails. com <InterHive> wrote:> Here, here. =) > > -c > > > Rick Olson wrote: > > In case someone hasn''t caught on yet (their flame throwers ready at > hand) -- RoR doesn''t suck. Just thought I''d add that in in case someone > didn''t have a sense of humor :-) > > 10. It made me hate my non-rails job using ASP.Net :) > > -- > rick > http://techno-weenie.net > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- ~~~~~~~~~~~~~~~~~~~ D''Andrew "Dave" Thompson http://dathompson.blogspot.com
On Thu, Jan 05, 2006 at 11:06:18AM -0600, Rick Olson wrote: } > In case someone hasn''t caught on yet (their flame throwers ready at } > hand) -- RoR doesn''t suck. Just thought I''d add that in in case someone } > didn''t have a sense of humor :-) } } 10. It made me hate my non-rails job using ASP.Net :) Amusing, but... actually, I''d say both have their place. When it comes to quick and dirty, nothing beats Rails. When it comes to highly complex, data-backed user interface controls, nothing beats ASP.NET (particularly several third-party controls). Everything in between is up for grabs. I would like to emphasize that data-backed, third-party controls are a big deal. It was really great on my last ASP.NET project to be able to buy a tree control that just pretty much worked on the data I was reading from the DB. It saved me at least a week of development time, if not more, and that''s a minor example. That said, I think I enjoy ASP.NET and Rails development pretty equally. The community (mailing list and IRC) for Ruby/Rails is a damn sight better than ASP.NET when you get stuck, though. } rick --Greg
> It saved me at least a week of development time, if not more, and > that''s a minor example.The lure of components is directly proportional with the pain of development. -- David Heinemeier Hansson 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
> Amusing, but... actually, I''d say both have their place. When it comes to > quick and dirty, nothing beats Rails. When it comes to highly complex, > data-backed user interface controls, nothing beats ASP.NET (particularly > several third-party controls). Everything in between is up for grabs. > > I would like to emphasize that data-backed, third-party controls are a big > deal. It was really great on my last ASP.NET project to be able to buy a > tree control that just pretty much worked on the data I was reading from > the DB. It saved me at least a week of development time, if not more, and > that''s a minor example. > > That said, I think I enjoy ASP.NET and Rails development pretty equally. > The community (mailing list and IRC) for Ruby/Rails is a damn sight better > than ASP.NET when you get stuck, though.I don''t count the fact that it requires a 752 page book (see Developing Microsoft ASP.NET Server Controls and Components) to write server controls a plus. Rails isn''t, and will never be a way to drag and drop your way to a beautiful site. So, there is of course plenty of room for other frameworks. All I was saying is that ASP.Net doesn''t make me happy. It gives me a feeling of "holy crap, it actually worked" if anything :) -- rick http://techno-weenie.net
+1 Doing maintenance on an asp.net CRM now feels very painful. Now if rails could get a reporting component like Microsoft Reporting Services that would be amazing... Zack -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Rick Olson Sent: Thursday, January 05, 2006 9:06 AM To: rails@lists.rubyonrails.org Subject: Re: [Rails] RoR sucks, and heres why...> In case someone hasn''t caught on yet (their flame throwers ready at > hand) -- RoR doesn''t suck. Just thought I''d add that in in case someone > didn''t have a sense of humor :-)10. It made me hate my non-rails job using ASP.Net :) -- rick http://techno-weenie.net _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 1/5/06, Rick Olson <technoweenie@gmail.com> wrote:> I don''t count the fact that it requires a 752 page book (see > Developing Microsoft ASP.NET Server Controls and Components) to write > server controls a plus.You don''t have to write the things :P You just have to implement them, like Rails... you don''t have to write it to use it :) And usually the docs for how to use server controls are a lot smaller then 752 pages. But a bit better documented then most open source solutions :P <snip>> All I was saying is that ASP.Net doesn''t make me happy. > It gives me a feeling of "holy crap, it actually worked" if anything > :) >Thats the case in any environment that your not used to :) Writing your first bits in Rails is sure to have given you the same feeling :)
On 1/5/06, Mark Haliday <markhaliday@yahoo.com> wrote:> Well now that I got your attention.... > > Why RoR sucks:> 5. RoR took away my connection strings! Now its just too easy :-)Connectionstrings are so hard :P> 7. I use to enjoy those frustrating nights banging my head against the > wall trying to figure out why my site worked on Windows 2000 but not > Windows 2003, now with RoR, my sites "just work".Now there''s something I won''t see me doing :P> 9. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it takes > a good 20+ lines AT LEAST.www.comfortasp.de 0 lines of code AJAX (or something like it) Seriously though I do agree with the other points :P
On 1/5/06, mischa kroon <mischa.kroon@gmail.com> wrote:> > 9. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it takes > > a good 20+ lines AT LEAST. > > www.comfortasp.de > > 0 lines of code AJAX (or something like it)That page is completely blank in Safari. Sounds like they have some catching up to do. -- sam
On 1/6/06, mischa kroon <mischa.kroon@gmail.com> wrote:> > All I was saying is that ASP.Net doesn''t make me happy. > > It gives me a feeling of "holy crap, it actually worked" if anything > > :) > > Thats the case in any environment that your not used to :) > Writing your first bits in Rails is sure to have given you the same feeling :)Developing my first Rails project (which was also my first real exposure to Ruby) left me with a feeling of pure joy and rekindled my love of programming (which, after a few years as an ASP.NET programmer, was in serious need of revival). That being said, I agree that different projects call for different tools, but I''m yet to find one that calls for ASP.NET over Ruby on Rails. Ben
On 1/5/06, Ben Myles <ben.myles@gmail.com> wrote:> On 1/6/06, mischa kroon <mischa.kroon@gmail.com> wrote: > > > > All I was saying is that ASP.Net doesn''t make me happy. > > > It gives me a feeling of "holy crap, it actually worked" if anything > > > :) > > > > Thats the case in any environment that your not used to :) > > Writing your first bits in Rails is sure to have given you the same feeling :) > > Developing my first Rails project (which was also my first real > exposure to Ruby) left me with a feeling of pure joy and rekindled my > love of programming (which, after a few years as an ASP.NET > programmer, was in serious need of revival). > > That being said, I agree that different projects call for different > tools, but I''m yet to find one that calls for ASP.NET over Ruby on > Rails. > > BenJust out of curiousity, which language did you use under .Net ?
99. That Zed asshole *still* hasn''t released a new version of SCGI. Dammit things have to be released frequently or they will not work well. Where the hell is he? Zed A. Shaw http://www.zedshaw.com/ On Jan 5, 2006, at 12:02 PM, Mark Haliday wrote:> Well now that I got your attention.... > > Why RoR sucks: > 1. It''s smarter than me. Just when I think I''ll have to do some > mundane > thing (like I use to in PHP or ASP), I find out RoR does it already > for > me. > ... > 9. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it > takes > a good 20+ lines AT LEAST.
<em>10. It made me hate my non-rails job using ASP.Net :)</em> I second that! (Only I use PHP, not ASP.) I''ll be the only coder there in about two weeks - I should tell them I''ll quit too unless they go balls to the wall with RoR. =D --- On 1/5/06, Zed Shaw <zedshaw@zedshaw.com> wrote:> > 99. That Zed asshole *still* hasn''t released a new version of SCGI. > Dammit things have to be released frequently or they will not work > well. Where the hell is he? > > Zed A. Shaw > http://www.zedshaw.com/ > > > On Jan 5, 2006, at 12:02 PM, Mark Haliday wrote: > > > Well now that I got your attention.... > > > > Why RoR sucks: > > 1. It''s smarter than me. Just when I think I''ll have to do some > > mundane > > thing (like I use to in PHP or ASP), I find out RoR does it already > > for > > me. > > ... > > 9. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it > > takes > > a good 20+ lines AT LEAST. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060106/e452a080/attachment.html
On Thu, Jan 05, 2006 at 01:19:12PM -0600, Rick Olson wrote:
[...]
} I don''t count the fact that it requires a 752 page book (see
} Developing Microsoft ASP.NET Server Controls and Components) to write
} server controls a plus.
Er, what? It takes a fair amount of work to give your control a fancy
VS.NET designer interface, but it''s absolutely trivial to create a
control
in general. More to the point, I was primarily talking about using, rather
than developing, controls.
} Rails isn''t, and will never be a way to drag and drop your way to a
} beautiful site. So, there is of course plenty of room for other
} frameworks. All I was saying is that ASP.Net doesn''t make me happy.
} It gives me a feeling of "holy crap, it actually worked" if anything
} :)
Heh. Well, I''ve been doing dynamic web development since 1994 (yes,
really). I have used all of the following technologies, roughly in
chronological order:
1) make and cpp to produce static files from dynamic data
2) CGI scripts in C with Remote Database Access (yeah, you''ve never
heard
of it, nor should you have)
3) CGI scripts in C with embedded SQL (ew)
4) CGI scripts in C++ (or maybe it was C) to produce interactive VRML 1.0
5) Client-side Java (it''s dynamic web, kind of, it just isn''t
HTML)
6) JSP + JDBC
7) Struts + JSP + iBatis
8) (modifying other people''s) PHP
9) ASP.NET + ADO.NET (C#)
10) Ruby + RoR
Of these, I''ve managed to actually enjoy numbers 4, 6, 9, and 10.
Having
used all of those, I would avoid to the best of my ability anything other
than ASP.NET and RoR. They were the only two where I didn''t feel like I
had
succeeded in doing something difficult that I wouldn''t want to repeat.
(Well, the Apache2/fcgid/RoR integration kind of felt like that, but it
wasn''t too bad.)
An important advantage of C# (or even VB.NET, when strict) over Ruby is
static type analysis. While duck typing and extraordinary dynamism is a
pleasure to work with, one loses the ability to rely on a compiler to
verify that the objects one is attempting to work with are actually going
to match the use one is putting them to (i.e. conforming to an interface).
I do not claim that C# or ASP.NET are "better" than Ruby or RoR. I
will
claim that there is a place for each, and that one should use the right
tool for the job. (Note that this does not apply to two tools that are for
the same job, such as Java and .NET; C#/.NET really are as good or better
than Java in every way other than platform independence, and the Mono folks
are working on that.)
} rick
--Greg
n+1. Rails makes you less macho. You won''t be able to relate to those surly, curmudgeony, masochistic C, C++, C#, and Java developers who have done many times more heavy lifting by writing far more code; been super anal-retentive in getting definitions and syntax correct; gotten a wide array of technologies to work together; and rolled many of their own reinvented wheels many-a-time. It''s like those people who drive older cars and can - and have - rebuilt their own transmissions, engines, etc. vs. those wimps who spend all their car time actually driving and Getting Stuff Done. n+2. Rails makes you less smart. Unlike those PHP developers who Know Everything and prove it by writing yet another template engine, framework, etc. -- Posted via http://www.ruby-forum.com/.
In the interests of starting a more serious discussion of problems with Rails: 1) The internals are undocumented and sparsely commented, making it difficult to patch when you discover yet another bug. 2) Non-trivial patches only get applied if they affect the core team. 3) Implementing new features takes priority over fixing bugs. 4) There are a lot of bugs. 5) There are numerous cases where Rails will die without any feedback to the administrator or user. 6) It''s slower than other frameworks (if you can''t use caching). 7) It consumes a lot of RAM. 8) def many_method_names_are_really_long_like_this_one; end I like Rails and I think it is the best web framework for my needs, but there are still a lot of problems with it.
On Sat, Jan 07, 2006 at 01:56:44PM -0800, Jeremy Evans wrote:> In the interests of starting a more serious discussion of problems with Rails:As a core member I''ll respond to some of the issues you bring up.> 1) The internals are undocumented and sparsely commented, making it > difficult to patch when you discover yet another bug.When you run up against internal code that is poorly documented or not documented at all and struggle to figure out how it works, documentation patches would be appreciated. We work hard to make the outward facing API always backwards compatible. Documentation is like code. The more you write the more you have to maintain, so we privilege the public API over the private API in this regard, as the internals tend to be refactored more frequently (which requires the overhead of documentation updates). Also, those delving into the internals are likely more able to determine how they work. Point taken though. Rails would likely benefit from some more documentation of the internals. Again, patches welcome. Documentation patches don''t require tests ;)> 2) Non-trivial patches only get applied if they affect the core team.If a patch is non-trivial it needs to be well tested. If it doesn''t apply cleanly the core team doesn''t have the time to make it unless it is really important. If it is well tested then it still takes time to evaluate. That''s how open source works. There are two sides to everything. I take issue with the "only get applied if they affect the core team" part. As a member of the core team who has taken the time to apply, test and commit plenty of code that has nothing to do with me I can''t accept such a broad claim. We try to make an effort to express in ticket comments when a patch is not complete or needs more work. If a patch is of high quality, well tested and appropriate for inclusion in Rails then it is often applied relatively expediently. In the cases where this does not happen I apologize. Gentle pestering on the rails-core list is encouraged. Gentle... You may take issue with what "appropriate for inclusion in Rails" means. Rails came out of David and 37signals'' needs for Basecamp so it has its original motivations springing out of necessity. The core team does have needs in the applications they build. David, for example, had a need for tagging in Sunrise. But he did not add a tagging framework to Rails. Instead, after implementing a tagging system he was happy with, he extracted the higher level database relationship model (the new polymorphic associations) into ActiveRecord. In other words, there is a distinction to be made between people''s needs and thing that are appropriate to the framework. We ultimately are the judge of what the appropriate level is. If it''s at the framework level and is a good fit for Rails, it goes in. Scott Barron, a core team member with the keys to the svn repository, is using the plugin system in Rails for several of his projects. He has needs for his apps but recognizes they don''t fit in on the framework level. The relatively high barrier of entry to patch submissions is also largely the reason why you like Rails so much. We say no before we say yes.> 3) 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 so a lot of the work post 1.0 is going into the tools used in conjunction with Rails and not as much on Rails itself. Either way, new features will be implemented and bugs will be fixed. We could all spend more time fixing bugs but as the considerable test coverage of Rails indicates, its code health is good.> 4) 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.> 6) It''s slower than other frameworks (if you can''t use caching).Rails privileges programmer productivity over execution speed. Always has and will. As does Ruby itself. That aside, the core team is mindful of performance and we are working closely with Stefan Kaes who has taken it upon himself to work exclusively on Rails performance. I personally spent over 20 hours for the 0.13.x release integrating his performance work into Rails. So, Rails is slower than other frameworks. There are other criteria by which it 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.> 8) def many_method_names_are_really_long_like_this_one; endWhat is the problem with this? You *want* intension revealing method names. Your text editor should alleviate the hassle of typing the whole thing out.> I like Rails and I think it is the best web framework for my needs, > but there are still a lot of problems with it.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. marcel -- Marcel Molina Jr. <marcel@vernix.org>
On Sat, Jan 07, 2006 at 05:03:05PM -0600, Marcel Molina Jr. wrote:> > 4) 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 -- Marcel Molina Jr. <marcel@vernix.org>
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 moredocumentation 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 thereason 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 havesaid, "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 andidentify, 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 fastenough. 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 pointingout 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:>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.>>3) 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.>>6) It''s slower than other frameworks (if you can''t use caching). >> >> > >Rails privileges programmer productivity over execution speed. Always has >and will. As does Ruby itself. That aside, the core team is mindful of >performance and we are working closely with Stefan Kaes who has taken it upon >himself to work exclusively on Rails performance. I personally spent over 20 >hours for the 0.13.x release integrating his performance work into Rails. So, >Rails is slower than other frameworks. There are other criteria by which it >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 Kaes'' 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. 2. 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
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. -- Posted via http://www.ruby-forum.com/.
Jeremy Evans 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. -- Posted via http://www.ruby-forum.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!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060109/e93d9432/attachment.html
David Heinemeier Hansson
2006-Jan-09 05:50 UTC
[Rails] Re: Re: RoR sucks, and heres why...
To a few people... Jeremy Evans:> 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 (TM). 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 worldWhen 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 Hansson 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
> > > 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.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:-) --> David Heinemeier Hansson > 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 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060109/ed77ecab/attachment.html
David Heinemeier Hansson
2006-Jan-09 06:54 UTC
[Rails] Re: Re: RoR sucks, and heres why...
> 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 Hansson 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:-) >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 -- [blog] http://www.dotnetguru2.org/tbarrere -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060109/362d84d8/attachment.html
Marcel Molina Jr. wrote:> On Sat, Jan 07, 2006 at 05:03:05PM -0600, Marcel Molina Jr. wrote: >> > 4) 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. -- Posted via http://www.ruby-forum.com/.
On 1/10/06, Andreas S. <f@andreas-s.net> wrote:> Marcel Molina Jr. wrote: > > On Sat, Jan 07, 2006 at 05:03:05PM -0600, Marcel Molina Jr. wrote: > >> > 4) 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. >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?
On Fri, Jan 13, 2006 at 02:22:31PM -0500, Wilson Bilkovich wrote:> On 1/10/06, Andreas S. <f@andreas-s.net> wrote: > > Marcel Molina Jr. wrote: > > > On Sat, Jan 07, 2006 at 05:03:05PM -0600, Marcel Molina Jr. wrote: > > >> > 4) 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. > > > > 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?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 -- Marcel Molina Jr. <marcel@vernix.org>
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.
2) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060113/9388b3aa/attachment.html
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
_____
2) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060113/606f24b2/attachment-0001.html
Sorry that should have been
<%= render(:partial => "login") unless controller ==
"new" -%>
_____
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Jim Hughes
Sent: Friday, January 13, 2006 4:16 PM
To: rails@lists.rubyonrails.org
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
_____
2) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060113/26ba2bfd/attachment.html
>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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060114/8d5f142b/attachment.html
On Jan 13, 2006, at 5:35 PM, 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 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsUse controller.controller_name or controller.action_name Cheers- -Ezra Zygmuntowicz WebMaster Yakima Herald-Republic Newspaper ezra@yakima-herald.com 509-577-7732 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060114/afeb8c7e/attachment.html
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-- Posted via http://www.ruby-forum.com/.
"Guest" (s_odor@hotmail.com), 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 On 1/22/06, Guest <s_odor@hotmail.com> wrote:> > 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 > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060122/c91082ff/attachment.html