I sure hope so: http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html Seems like it''s getting genuine rebuttals, though. It''s actually kind of amusing.
no, it''s sincere. that''s this totally crazy dude who DHH talks about in his blog. http://www.loudthinking.com/arc/000577.html On 3/28/06, Edward Frederick <epfrederick@gmail.com> wrote:> I sure hope so: > > http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html > > Seems like it''s getting genuine rebuttals, though. It''s actually kind > of amusing. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
btw, I think he''s doing it for the Google Ads revenue. his arguments don''t even make sense. On 3/28/06, Giles Bowkett <gilesb@gmail.com> wrote:> no, it''s sincere. that''s this totally crazy dude who DHH talks about > in his blog. > > http://www.loudthinking.com/arc/000577.html > > On 3/28/06, Edward Frederick <epfrederick@gmail.com> wrote: > > I sure hope so: > > > > http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html > > > > Seems like it''s getting genuine rebuttals, though. It''s actually kind > > of amusing. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
DHH has been writing about this on his blog: Boy, is James McGovern enterprise or what! http://www.loudthinking.com/arc/000577.html Calling bullshit on the Enterprise Astronauts http://www.loudthinking.com/arc/000578.html Amusing... On 3/28/06, Edward Frederick <epfrederick@gmail.com> wrote:> I sure hope so: > > http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html > > Seems like it''s getting genuine rebuttals, though. It''s actually kind > of amusing. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Ben Reubenstein http://www.benr75.com
I''ve been trying to figure out how to retrieve a http head request date using http-access2. I thought this could work: h = HTTPAccess2::Client.new() res = h.head(''http://involution.com'') print response.header[''date''],"\n" However, that seems to be returning Time.now. Any suggestions? FYI, you can view a http request by doing the following: telnet involution.com 80 Trying 69.58.21.60... Connected to involution.com. Escape character is ''^]''. HEAD / HTTP/1.0 HTTP/1.1 200 OK -----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X Server: Apache/2.0.52 (Red Hat) Cache-Control: no-cache Set-Cookie: _session_id=670e36e364a03785011afbfafbc15fde; path=/ Connection: close Content-Type: text/html; charset=UTF-8 I''m looking at trying to find a way to see what time the server thinks it is to do some time zone correction foo. Regards, Tony http://involution.com
I reviewed most of his arguments, and he is dead on. These are exactly the reasons that I cannot recommend Ruby as an architecture language for my company. I love Ruby (so far), but it isn''t ready for prime-time in my day-to-day work environment (large company with over 8,000 users on a real-time business critical system). As I am working with Ruby and Rails, I am discovering both how nice this combination can be and what its shortcomings are. For the most part, these are a matter of maturity, not principle. Given another year or two Ruby could be up to snuff. With that said, I can recommend Ruby "as-is" for "bread and butter" applications and utility scripting, and as a "watch" technology as certain features mature. At the same time, J2EE is showing its age. After ten years of being used to write web apps that babysit RDBMS''s, J2EE is harder to use than ever and slow as molasses at Cold Lake in January. The EJB/DAO design pattern quadruples the programmer''s work with negative payback in performance and reliability. JRuby (Ruby running under a JVM) is actually very interesting to us, but it is about 80 bugs away from being ready for active consideration. JRuby offers the internationalization, threading, and other support that regular Ruby does not yet, because the underlying JVM and Java runtime classes support them. On Tue, 2006-03-28 at 16:04 -0700, Giles Bowkett wrote:> btw, I think he''s doing it for the Google Ads revenue. his arguments > don''t even make sense. > > On 3/28/06, Giles Bowkett <gilesb@gmail.com> wrote: > > no, it''s sincere. that''s this totally crazy dude who DHH talks about > > in his blog. > > > > http://www.loudthinking.com/arc/000577.html > > > > On 3/28/06, Edward Frederick <epfrederick@gmail.com> wrote: > > > I sure hope so: > > > > > > http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html > > > > > > Seems like it''s getting genuine rebuttals, though. It''s actually kind > > > of amusing. > > > _______________________________________________ > > > 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
Considering he is not directing his argument at Rails, I think he is pretty much right. But Rails (or any web development environment) is a completely different ballpark. His verbose argument boils down to the fact that scripting languages are not good for commercial applications, but he fails to mention they are great for web applications. -John -- John Smilanick Computing Staff - Webmaster Kavli Institute for Theoretical Physics University of California, Santa Barbara jsmilani@kitp.ucsb.edu (805) 893-6307 On Mar 28, 2006, at 2:16 PM, Edward Frederick wrote:> I sure hope so: > > http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why- > ruby-isnt.html > > Seems like it''s getting genuine rebuttals, though. It''s actually kind > of amusing. > _______________________________________________ > 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/20060328/8a6ef2ca/attachment.html
Sorry.. But JRuby just mystifies me..... Why would you want to make Ruby slower???? Can you just point out to me how running Ruby in a virtual machine is going to improve anything? Regarding the enterprise support for 8000 users.... I would say that it''s not really a problem for Ruby on Rails. It''s more the headache of the developer of the application rather than problems of the framework builders. It''s true that many things is immature and untested in Ruby when it comes to high user base and things like load balancing is really non-existent. But I frankly don''t want it in there except as an optional gem because I just simply don''t want to know of it''s existence until I need to use it. To sum it up... Yes... Rails is maybe not ready for the enterprise market. But isn''t it really OUR job to make it ready? On 3/28/06, David Johnson <johnson_d@cox.net> wrote:> I reviewed most of his arguments, and he is dead on. These are exactly > the reasons that I cannot recommend Ruby as an architecture language > for my company. I love Ruby (so far), but it isn''t ready for prime-time > in my day-to-day work environment (large company with over 8,000 users > on a real-time business critical system). > > As I am working with Ruby and Rails, I am discovering both how nice this > combination can be and what its shortcomings are. For the most part, > these are a matter of maturity, not principle. Given another year or > two Ruby could be up to snuff. > > With that said, I can recommend Ruby "as-is" for "bread and butter" > applications and utility scripting, and as a "watch" technology as > certain features mature. > > At the same time, J2EE is showing its age. After ten years of being > used to write web apps that babysit RDBMS''s, J2EE is harder to use than > ever and slow as molasses at Cold Lake in January. The EJB/DAO design > pattern quadruples the programmer''s work with negative payback in > performance and reliability. > > JRuby (Ruby running under a JVM) is actually very interesting to us, but > it is about 80 bugs away from being ready for active consideration. > JRuby offers the internationalization, threading, and other support that > regular Ruby does not yet, because the underlying JVM and Java runtime > classes support them. > > On Tue, 2006-03-28 at 16:04 -0700, Giles Bowkett wrote: > > btw, I think he''s doing it for the Google Ads revenue. his arguments > > don''t even make sense. > > > > On 3/28/06, Giles Bowkett <gilesb@gmail.com> wrote: > > > no, it''s sincere. that''s this totally crazy dude who DHH talks about > > > in his blog. > > > > > > http://www.loudthinking.com/arc/000577.html > > > > > > On 3/28/06, Edward Frederick <epfrederick@gmail.com> wrote: > > > > I sure hope so: > > > > > > > > http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html > > > > > > > > Seems like it''s getting genuine rebuttals, though. It''s actually kind > > > > of amusing. > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- -------------- Jon Gretar Borgthorsson
On Mar 28, 2006, at 5:41 PM, David Johnson wrote:> I reviewed most of his arguments, and he is dead on. These are > exactly > the reasons that I cannot recommend Ruby as an architecture language > for my company.Good grief, if you''d read DHH''s post at <http://www.loudthinking.com/ arc/000577.html> you''d see that the guy was initially claiming that Ruby lacked support for regular expressions, instance variables, lack of a packing system, no access control, etc. (and he did make these claims, I read his entry myself before he edited it) and when "bullshit" was called he rewrote them as the soft, amorphous points that you''re now agreeing with. -- Jason Perkins jperkins@sneer.org "The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila."
I didn''t see his original post. His points (current posting) are not about the design of ruby, they are about the maturity of the platform for use in large scale developments. To you they may be amorphous, but to my day to day work they are crippling (except for the powerpoint presentations - I can do without those). Give Ruby a year and it can easily be up to snuff, if the points are addressed instead of shooting the messenger (however obnoxious he may have been). On Tue, 2006-03-28 at 18:21 -0600, Jason Perkins wrote:> On Mar 28, 2006, at 5:41 PM, David Johnson wrote: > > > I reviewed most of his arguments, and he is dead on. These are > > exactly > > the reasons that I cannot recommend Ruby as an architecture language > > for my company. > > Good grief, if you''d read DHH''s post at <http://www.loudthinking.com/ > arc/000577.html> you''d see that the guy was initially claiming that > Ruby lacked support for regular expressions, instance variables, lack > of a packing system, no access control, etc. (and he did make these > claims, I read his entry myself before he edited it) and when > "bullshit" was called he rewrote them as the soft, amorphous points > that you''re now agreeing with. > > -- > Jason Perkins > jperkins@sneer.org > > "The computer allows you to make mistakes > faster than any other invention, with the > possible exception of handguns and tequila." > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Could you be more specific about the points that actually matter to you? I see very little in Rails that makes it less suitable for the typical "enterprise" labelled application than either Java or .NET web application frameworks. Nearly all enterprise applications are in fact depressively simplistic front-ends to poorly designed databases that meet the supposed needs of process designers far better than their end users, and mostly exist only extend the fiefdoms of has-been technology managers and the change management institutions that they serve. We call this politics and accept it as a given, and I am no different - really I don''t care. The spirit of Rails is so opposed to any sort of enterprise development of this description that programming in this language may as well not even be considered the same occupation as programming in a corporate soup of powerpoints, paperwork, buzzwords and vendor partnerships. The battle for the enterprise is not worth winning, why fight it. On 3/28/06, David Johnson <johnson_d@cox.net> wrote:> I didn''t see his original post. > > His points (current posting) are not about the design of ruby, they are > about the maturity of the platform for use in large scale developments. > To you they may be amorphous, but to my day to day work they are > crippling (except for the powerpoint presentations - I can do without > those). > > Give Ruby a year and it can easily be up to snuff, if the points are > addressed instead of shooting the messenger (however obnoxious he may > have been). > > On Tue, 2006-03-28 at 18:21 -0600, Jason Perkins wrote: > > On Mar 28, 2006, at 5:41 PM, David Johnson wrote: > > > > > I reviewed most of his arguments, and he is dead on. These are > > > exactly > > > the reasons that I cannot recommend Ruby as an architecture language > > > for my company. > > > > Good grief, if you''d read DHH''s post at <http://www.loudthinking.com/ > > arc/000577.html> you''d see that the guy was initially claiming that > > Ruby lacked support for regular expressions, instance variables, lack > > of a packing system, no access control, etc. (and he did make these > > claims, I read his entry myself before he edited it) and when > > "bullshit" was called he rewrote them as the soft, amorphous points > > that you''re now agreeing with. > > > > -- > > Jason Perkins > > jperkins@sneer.org > > > > "The computer allows you to make mistakes > > faster than any other invention, with the > > possible exception of handguns and tequila." > > > > > > _______________________________________________ > > 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 >-- Jeremy Huffman http://www.jeremyhuffman.com
On Tue, 2006-03-28 at 23:59 +0000, Jon Gretar Borgthorsson wrote:> Sorry.. But JRuby just mystifies me..... Why would you want to make > Ruby slower???? >If (big if) Ruby follows the pattern of other languages using the JVM, it will compile the source to java byte code (.class file). My own benchmarks have established that a Java hotspot compiler (which recompiles frequently used byte code to native code) will perform within 10% of hand optimized assembly language for the same tasks. I was able to trace the cause for the 10% difference to the stack frame handling, which buys stack safety at the expense of a little performance. If Ruby follows this pattern, the JIT runtime compilers should speed ruby up to at least match Java. If there are performance issues with the byte code being generated by the JRuby compiler then those are best resolved by hitting the keyboard, not the messenger.> Can you just point out to me how running Ruby in a virtual machine is > going to improve anything? >Off the top of my head ... 1. JIT compiler. 2. Unicode support is a huge thing for internationalization. I was surprised that Ruby kept all of the code page garbage of the ''80s, given the maturity of the C libraries supporting the unicode specification and that Ruby''s country of origin uses a non-latin alphabet. 3. With java''s unicode support is also a mature library of character set conversions. 4. Native support for threading is a critical thing if you are to make vertically scalable apps. 5. Instant, painless migration path to allow reuse of existing mature application logic. I am not going to rewrite 2 million lines of my company''s java code in Ruby, but having that pre-existing work available to reuse without change will save me a lot of effort in migration, and make it easier to promote the Ruby platform in the long term.> Regarding the enterprise support for 8000 users.... I would say that > it''s not really a problem for Ruby on Rails. It''s more the headache of > the developer of the application rather than problems of the framework > builders.The platform needs to support a few minimum constructs for that to work. Delphi never made it as an enterprise platform because it did not support the vertical scalability necessary. Vertically scaling a Delphi app required one to throw out hte "Delphi" parts of the environment andbecome an Object Pascal programmer. Java made it at the enterprise level because the JVM handled the baseline requirements for vertical scaling, and the core objects in the java runtime library were built to handle it.> It''s true that many things is immature and untested in Ruby > when it comes to high user base and things like load balancing is > really non-existent. But I frankly don''t want it in there except as an > optional gem because I just simply don''t want to know of it''s > existence until I need to use it.Bingo ... but I need it available before I can even seriously consider it. Unfortunately, that stuff is not "tack on". It impacts the core design of the engine. If the engine doesn''t support it, the language will never perform adequately under pressure. There are areas where Ruby needs to mature to make it a viable _enterprise_ platform. Rails also has some areas it needs to address, but those are not fundamentally issues with Ruby. None of the issues raised are with the fundamental designs of either product. They are issues with their current level of maturity that can be addressed better by hitting the keyboard than slamming the blogger.> To sum it up... Yes... Rails is maybe not ready for the enterprise > market. But isn''t it really OUR job to make it ready?I agree ... but slamming the messenger in a flame war doesn''t resolve the issues. Taking his valid points (who cares about powerpoint presentations) and resolving them would bring Ruby much closer to being a viable enterprise platform.> > On 3/28/06, David Johnson <johnson_d@cox.net> wrote: > > I reviewed most of his arguments, and he is dead on. These are exactly > > the reasons that I cannot recommend Ruby as an architecture language > > for my company. I love Ruby (so far), but it isn''t ready for prime-time > > in my day-to-day work environment (large company with over 8,000 users > > on a real-time business critical system). > > > > As I am working with Ruby and Rails, I am discovering both how nice this > > combination can be and what its shortcomings are. For the most part, > > these are a matter of maturity, not principle. Given another year or > > two Ruby could be up to snuff. > > > > With that said, I can recommend Ruby "as-is" for "bread and butter" > > applications and utility scripting, and as a "watch" technology as > > certain features mature. > > > > At the same time, J2EE is showing its age. After ten years of being > > used to write web apps that babysit RDBMS''s, J2EE is harder to use than > > ever and slow as molasses at Cold Lake in January. The EJB/DAO design > > pattern quadruples the programmer''s work with negative payback in > > performance and reliability. > > > > JRuby (Ruby running under a JVM) is actually very interesting to us, but > > it is about 80 bugs away from being ready for active consideration. > > JRuby offers the internationalization, threading, and other support that > > regular Ruby does not yet, because the underlying JVM and Java runtime > > classes support them. > > > > On Tue, 2006-03-28 at 16:04 -0700, Giles Bowkett wrote: > > > btw, I think he''s doing it for the Google Ads revenue. his arguments > > > don''t even make sense. > > > > > > On 3/28/06, Giles Bowkett <gilesb@gmail.com> wrote: > > > > no, it''s sincere. that''s this totally crazy dude who DHH talks about > > > > in his blog. > > > > > > > > http://www.loudthinking.com/arc/000577.html > > > > > > > > On 3/28/06, Edward Frederick <epfrederick@gmail.com> wrote: > > > > > I sure hope so: > > > > > > > > > > http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html > > > > > > > > > > Seems like it''s getting genuine rebuttals, though. It''s actually kind > > > > > of amusing. > > > > > _______________________________________________ > > > > > 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 > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > -- > -------------- > Jon Gretar Borgthorsson > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
I''ve read the arguments and they range from reasonable to foolish, but the real point is that he''s ''not even wrong'' as the saying goes. I''ve been making my living as an engineering manager working on commercial enterprise Java aplicatations for almost 10 years now. Ruby on Rails is a perfect example of a disruptive innovation - no it''s not as good as java in some ways - time zone support for one - but it''s waaaayyy better than java in other more important ways. This guy''s on his way to being the COBOL programmer of 2010. The idea, btw, that Java programmers/programs are inherently better at architecture, btw, is an urban myth. On 3/28/06, David Johnson <johnson_d@cox.net> wrote:> > I didn''t see his original post. > > His points (current posting) are not about the design of ruby, they are > about the maturity of the platform for use in large scale developments. > To you they may be amorphous, but to my day to day work they are > crippling (except for the powerpoint presentations - I can do without > those). > > Give Ruby a year and it can easily be up to snuff, if the points are > addressed instead of shooting the messenger (however obnoxious he may > have been). > > On Tue, 2006-03-28 at 18:21 -0600, Jason Perkins wrote: > > On Mar 28, 2006, at 5:41 PM, David Johnson wrote: > > > > > I reviewed most of his arguments, and he is dead on. These are > > > exactly > > > the reasons that I cannot recommend Ruby as an architecture language > > > for my company. > > > > Good grief, if you''d read DHH''s post at <http://www.loudthinking.com/ > > arc/000577.html> you''d see that the guy was initially claiming that > > Ruby lacked support for regular expressions, instance variables, lack > > of a packing system, no access control, etc. (and he did make these > > claims, I read his entry myself before he edited it) and when > > "bullshit" was called he rewrote them as the soft, amorphous points > > that you''re now agreeing with. > > > > -- > > Jason Perkins > > jperkins@sneer.org > > > > "The computer allows you to make mistakes > > faster than any other invention, with the > > possible exception of handguns and tequila." > > > > > > _______________________________________________ > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060329/856ef57f/attachment.html
On 29/03/06, Jeremy Huffman <jeremy@jeremyhuffman.com> wrote:> Could you be more specific about the points that actually matter to you? > > I see very little in Rails that makes it less suitable for the typical > "enterprise" labelled application than either Java or .NET web > application frameworks. Nearly all enterprise applications are in fact > depressively simplistic front-ends to poorly designed databases that > meet the supposed needs of process designers far better than their end > users, and mostly exist only extend the fiefdoms of has-been > technology managers and the change management institutions that they > serve.Sure, here''s some that come to mind Support for Oracle; while I haven''t tried using Oracle with Rails personally, there''s enough people having trouble with it to make me suspect that Oracle+Rails might not be a good combination Support for DB2: last time I checked, this was still a problem, but people were working on it. Anyone know what state it''s currently in? Support for stored procedures and views: Rails has adopted a stance that makes stored procs and views (in any DB) difficult to implement. Never mind that Rails'' "sweet spot" says that stored procs and views aren''t necessary; in any business-critical enterprise DB, an app developer will only get access to data via views and stored procs, so needs to be able to work with them. It *can* be done in Rails (at least with Postgres, which I''ve tried), but it''s not trivial. Support for legacy databases: again, Rails can be made to work with non-Rails-conformant table and field names, but it''s painful. Not such a big deal once you get your head around it, but having to do this will start to slice into Rails'' massive reduction in dev time and resources over e.g. J2EE. Lack of support for MQ: this may seem a bit left field, but anyone with experience across a range of enterprise-class IT will be familiar with sites that *mandate* all app-to-DB connectivity must go through MQ. Your app submits its "request" onto a queue, the database reads your request and puts the response on another queue, your app picks up the response from the queue. It''s big and clunky, but it works, is rock solid reliable and you''ll find it just about everywhere an IBM mainframe is in place. Sure, you could (probably) build a MQ interface onto Rails, but it doesn''t exist now. You could use Rails to bolt a Web services layer onto MQ, but now you''ve just increased the scope of what you''re developing quite significantly. Development tools: RADrails is coming along, but it lags behind e.g. Visual Studio by some way at present. If your entire enterprise dev team can be infected with the Rails bug, and is happy to put up with dev tools of a significantly lower standard than what they''re currently using, fine, but most dev shops will have at least one old guy in a cardigan who''s memorised every aspect of Visual Studio and will fight back if you try to take it away from him. Don''t get me wrong - Rails can do lots and lots of good stuff, and its niche is a quite large in the scale of "massive enterprise system" through "Mum''s photo album" development tasks. I really like Rails, use it daily, and am slowly introducing it to places where I work with promising results. Building a prototype for some complex app in Rails in a few hours is an absolutely KILLER way of demonstrating productivity increases, and Rails fits with my subversive persona very nicely. I agree that in 12 months'' time, it''ll be a significantly better fit for many enterprises. However: - not all enterprise apps are simple front ends on top of poorly designed databases - legacy databases and interfaces are all through enterprise IT shops, and you''d better have a way of dealing with them if you''re introducing a bunch of new technology - end-users often have an extremely high degree of input into app design - many/most/all IT managers are constantly bombarded by "the next big thing" from all their vendors, and Rails is just another "next big thing" in their minds and will be treated accordingly - J2EE and .NET actually work quite well in a lot of places, for a lot of apps Interested in others'' thoughts on this - good thread Regards Dave M.
On 3/29/06, David Johnson <johnson_d@cox.net> wrote:> > If (big if) Ruby follows the pattern of other languages using the JVM, > it will compile the source to java byte code (.class file). My own > benchmarks have established that a Java hotspot compiler (which > recompiles frequently used byte code to native code) will perform within > 10% of hand optimized assembly language for the same tasks. I was able > to trace the cause for the 10% difference to the stack frame handling, > which buys stack safety at the expense of a little performance. > > If Ruby follows this pattern, the JIT runtime compilers should speed > ruby up to at least match Java. > > If there are performance issues with the byte code being generated by > the JRuby compiler then those are best resolved by hitting the keyboard, > not the messenger.But having a real ruby compiler (Something I understand is coming built in version 2) is always going to be faster. The problem I have always had with java is that virtual machines will ALWAYS slow things down. It''s just the way it works. Java is indeed faster now when compiled(but with much higher memory use) but that is because of compilation. I would think that a compiled ruby app would be much faster.> > 1. JIT compiler. > > 2. Unicode support is a huge thing for internationalization. I was > surprised that Ruby kept all of the code page garbage of the ''80s, given > the maturity of the C libraries supporting the unicode specification and > that Ruby''s country of origin uses a non-latin alphabet. > > 3. With java''s unicode support is also a mature library of character set > conversions. > > 4. Native support for threading is a critical thing if you are to make > vertically scalable apps. > > 5. Instant, painless migration path to allow reuse of existing mature > application logic. I am not going to rewrite 2 million lines of my > company''s java code in Ruby, but having that pre-existing work available > to reuse without change will save me a lot of effort in migration, and > make it easier to promote the Ruby platform in the long term. >But why oh why Java??? The slowest thing available.... People started developing in Ruby to get away from things like Java.> > The platform needs to support a few minimum constructs for that to work. > Delphi never made it as an enterprise platform because it did not > support the vertical scalability necessary. Vertically scaling a Delphi > app required one to throw out hte "Delphi" parts of the environment > andbecome an Object Pascal programmer. Java made it at the enterprise > level because the JVM handled the baseline requirements for vertical > scaling, and the core objects in the java runtime library were built to > handle it.Yes..... Also one of the reason Java won that battle is because for some reason schools seem to prefer teaching Java. I just don''t understand why some developers incist on using java for desktop applications for example. Being cross platform doesn''t help if the users dislike using the software because it is slow and unresponsive. But your point is true. But it only says why Java won Delphi.> I agree ... but slamming the messenger in a flame war doesn''t resolve > the issues. Taking his valid points (who cares about powerpoint > presentations) and resolving them would bring Ruby much closer to being > a viable enterprise platform.The messenger was not slammed because of the message. He was slammed because: A) Nobody likes people who proclaim themselves industry leaders when ho showed many times that he had marginal programming knowledge B) He didn''t even seem to have looked at Ruby. His message was full of errors and FUD. Even though he tried to hide it later. (ceck out JHH''s post to see what I am talking about) -- -------------- Jon Gretar Borgthorsson
On Wed, 2006-03-29 at 13:54 +1100, David Mitchell wrote:> On 29/03/06, Jeremy Huffman <jeremy@jeremyhuffman.com> wrote: > > Could you be more specific about the points that actually matter to you? > > > > I see very little in Rails that makes it less suitable for the typical > > "enterprise" labelled application than either Java or .NET web > > application frameworks. Nearly all enterprise applications are in fact > > depressively simplistic front-ends to poorly designed databases that > > meet the supposed needs of process designers far better than their end > > users, and mostly exist only extend the fiefdoms of has-been > > technology managers and the change management institutions that they > > serve. > > Sure, here''s some that come to mind > > Support for Oracle; while I haven''t tried using Oracle with Rails > personally, there''s enough people having trouble with it to make me > suspect that Oracle+Rails might not be a good combination > > Support for DB2: last time I checked, this was still a problem, but > people were working on it. Anyone know what state it''s currently in? > > Support for stored procedures and views: Rails has adopted a stance > that makes stored procs and views (in any DB) difficult to implement. > Never mind that Rails'' "sweet spot" says that stored procs and views > aren''t necessary; in any business-critical enterprise DB, an app > developer will only get access to data via views and stored procs, so > needs to be able to work with them. It *can* be done in Rails (at > least with Postgres, which I''ve tried), but it''s not trivial. > > Support for legacy databases: again, Rails can be made to work with > non-Rails-conformant table and field names, but it''s painful. Not > such a big deal once you get your head around it, but having to do > this will start to slice into Rails'' massive reduction in dev time and > resources over e.g. J2EE. > > Lack of support for MQ: this may seem a bit left field, but anyone > with experience across a range of enterprise-class IT will be familiar > with sites that *mandate* all app-to-DB connectivity must go through > MQ. Your app submits its "request" onto a queue, the database reads > your request and puts the response on another queue, your app picks up > the response from the queue. It''s big and clunky, but it works, is > rock solid reliable and you''ll find it just about everywhere an IBM > mainframe is in place. Sure, you could (probably) build a MQ > interface onto Rails, but it doesn''t exist now. You could use Rails > to bolt a Web services layer onto MQ, but now you''ve just increased > the scope of what you''re developing quite significantly. > > Development tools: RADrails is coming along, but it lags behind e.g. > Visual Studio by some way at present. If your entire enterprise dev > team can be infected with the Rails bug, and is happy to put up with > dev tools of a significantly lower standard than what they''re > currently using, fine, but most dev shops will have at least one old > guy in a cardigan who''s memorised every aspect of Visual Studio and > will fight back if you try to take it away from him. > > Don''t get me wrong - Rails can do lots and lots of good stuff, and its > niche is a quite large in the scale of "massive enterprise system" > through "Mum''s photo album" development tasks. I really like Rails, > use it daily, and am slowly introducing it to places where I work with > promising results. Building a prototype for some complex app in Rails > in a few hours is an absolutely KILLER way of demonstrating > productivity increases, and Rails fits with my subversive persona very > nicely. I agree that in 12 months'' time, it''ll be a significantly > better fit for many enterprises. > > However: > - not all enterprise apps are simple front ends on top of poorly > designed databases > - legacy databases and interfaces are all through enterprise IT shops, > and you''d better have a way of dealing with them if you''re introducing > a bunch of new technology > - end-users often have an extremely high degree of input into app design > - many/most/all IT managers are constantly bombarded by "the next big > thing" from all their vendors, and Rails is just another "next big > thing" in their minds and will be treated accordingly > - J2EE and .NET actually work quite well in a lot of places, for a lot of apps > > > Interested in others'' thoughts on this - good thread---- I''ll add my $ .02 - easy/good access to enterprise authentication system and I say this because of the incredible amount of time that I have wasted trying to make rails connect to an LDAP server. Craig
On Tue, 2006-03-28 at 21:03 -0500, Jeremy Huffman wrote:> Could you be more specific about the points that actually matter to > you?1. Native support for threading 2. Standardized support for prepared statements in the RDBMS adapter classes (once I have more Ruby experience I plan to address this one myself) 3. Unicode support 4. Platforms other than Windows and *nix. Z/OS would be a good place. Ruby would be a great competitor for Rexx. 5. Performance boost> > I see very little in Rails that makes it less suitable for the typical > "enterprise" labelled application than either Java or .NET web > application frameworks. Nearly all enterprise applications are in fact > depressively simplistic front-ends to poorly designed databases that > meet the supposed needs of process designers far better than their end > users, and mostly exist only extend the fiefdoms of has-been > technology managers and the change management institutions that they > serve. >:o) Seen some of that. On the other hand, when handling well over 1,000,000 transactions per hour, 24x7 in a highly integrated but heterogeneous environment, where downtime cost is measured in tens of thousands of dollars per minute, most of the work is _not_ going into the front end. Pretty is reserved for the outside world. Internal apps must be fast, correct, and cleanly constructed to not hammer other apps. The front end may be depressingly simple (my opinion of a good web page is pure white with black text in Times New Roman 12 point font, and no other adornment). But the back ends tend to be both very robust and challenging, and not entirely because of old bad designs.> We call this politics and accept it as a given, and I am no different > - really I don''t care. The spirit of Rails is so opposed to any sort > of enterprise development of this description that programming in this > language may as well not even be considered the same occupation as > programming in a corporate soup of powerpoints, paperwork, buzzwords > and vendor partnerships. >That is a poor way to promote the platform, and you are making a common mistake (one that Mr. McGovern did also) of assuming that just because you use a common programming language you are also using the same design methods. He seems to be working under the assumption that all agile development is unplanned in nature, and you seem to have the opinion that communication with one''s peers is a bad thing if you''re programming in Ruby. Ironically, what I see is that you are proving one of his points by restating it from the other perspective. Enterprises do engage in agile development. But part of working in an enterprise environment is the understanding that you are interacting, in real time, with potentially hundreds other programs that are all critical to your own paycheck. Furthermore, since Enron, people go to jail for certain types of failures. I have on more than one occasion asked for "get out of jail free" letters where I was asked to manually correct information that a faulty program or process had entered in a database table. Some of that paperwork is there for good reasons. Discussing changes or additions to processes that will impact your peers in other departments is not a political process. It is a professional courtesy and a technical necessity. You be the one who is woken up at 3:00 AM on Sunday because someone made a change that hammered your program and didn''t tell you! When I was a 1 man IT shop, I could pretty much do what I wanted. In a 2 man IT shop (at my church), we have seen a need for formal change control. In a company with several hundred programmers and technical people, maintaining those channels of communication is a large part of why my company is having record years while our competitors are filing bankruptcy. As far as buzzwords goes, Rails is the embodiment of the buzzword "MVC". It has "AJAX" support. It uses "Adapters" to talk to "RDBMS". It uses "helpers", "containers", "blocks", "hashes", "iterators", and so on.> The battle for the enterprise is not worth winning, why fight it.Because if you can win there, you can win anywhere. In the enterprise, you win by making the best bottom line consistently. You achieve the best bottom line through good communication and technical excellence. Ruby and Rails have a very good foundation, but they need a little more maturity to enter that market and win decisively. J2EE has essentially failed, client/server technologies are largely a fad of the past, and people are unwilling to go back to CICS screens. The spot for Ruby and Rails is open if the platform can provide the technical underpinnings to make it work.
Yes... This and other things other people areare saying here are things I agree with. I personally will not use ruby for enterprise setup any day soon. But don''t compare bugs and little problems with what McGovern is saying. He calls Ruby a trainwreck waiting to happen.> ---- > I''ll add my $ .02 - easy/good access to enterprise authentication system > and I say this because of the incredible amount of time that I have > wasted trying to make rails connect to an LDAP server. > > Craig > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- -------------- Jon Gretar Borgthorsson
Anything can be a trainwreck with a sufficiently-ignorant person at the wheel. "When I die, I want to go quietly in my sleep, like my grandfather, not screaming in terror like his passengers" Dave M. On 29/03/06, Jon Gretar Borgthorsson <jon.borgthorsson@gmail.com> wrote:> Yes... This and other things other people areare saying here are > things I agree with. I personally will not use ruby for enterprise > setup any day soon. > > But don''t compare bugs and little problems with what McGovern is > saying. He calls Ruby a trainwreck waiting to happen. > > > > ---- > > I''ll add my $ .02 - easy/good access to enterprise authentication system > > and I say this because of the incredible amount of time that I have > > wasted trying to make rails connect to an LDAP server. > > > > Craig > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > -- > -------------- > Jon Gretar Borgthorsson > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I just did it with one of these: server_date = `curl -I #{um.htmlurl} 2> /dev/null` print server_date.match(/^Date:.*/), "\n" which appears to work... Tony On 3/28/06, Tony Perrie <tony@involution.com> wrote:> I''ve been trying to figure out how to retrieve a http head request > date using http-access2. > > I thought this could work: > > h = HTTPAccess2::Client.new() > res = h.head(''http://involution.com'') > print response.header[''date''],"\n" > > However, that seems to be returning Time.now. Any suggestions? > > FYI, you can view a http request by doing the following: > > telnet involution.com 80 > Trying 69.58.21.60... > Connected to involution.com. > Escape character is ''^]''. > HEAD / HTTP/1.0 > > HTTP/1.1 200 OK > -----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X > Server: Apache/2.0.52 (Red Hat) > Cache-Control: no-cache > Set-Cookie: _session_id=670e36e364a03785011afbfafbc15fde; path=/ > Connection: close > Content-Type: text/html; charset=UTF-8 > > I''m looking at trying to find a way to see what time the server thinks it > is to do some time zone correction foo. > > Regards, > > Tony > http://involution.com > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Tony, Try this: h = HTTPAccess2::Client.new() res = h.head(''http://involution.com'') res.header[''Date''] => ["Wed, 29 Mar 2006 03:21:30 GMT"] Time.now => Tue Mar 28 21:21:41 Central Standard Time 2006 Hammed On 3/28/06, Tony Perrie <tony@involution.com> wrote:> > I''ve been trying to figure out how to retrieve a http head request > date using http-access2. > > I thought this could work: > > h = HTTPAccess2::Client.new() > res = h.head(''http://involution.com'') > print response.header[''date''],"\n" > > However, that seems to be returning Time.now. Any suggestions? > > FYI, you can view a http request by doing the following: > > telnet involution.com 80 > Trying 69.58.21.60... > Connected to involution.com. > Escape character is ''^]''. > HEAD / HTTP/1.0 > > HTTP/1.1 200 OK > -----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X > Server: Apache/2.0.52 (Red Hat) > Cache-Control: no-cache > Set-Cookie: _session_id=670e36e364a03785011afbfafbc15fde; path=/ > Connection: close > Content-Type: text/html; charset=UTF-8 > > I''m looking at trying to find a way to see what time the server thinks it > is to do some time zone correction foo. > > Regards, > > Tony > http://involution.com > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- ----- Fight back spam! Download the Blue Frog. http://www.bluesecurity.com/register/s?user=c2FobWVkMTQ%3D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060329/bc0c5f73/attachment.html
In the article James McGovern mentioned only ''Ruby'' but never ''Ruby on Rails'' and it was obliquely insulting the way he put the various train-wreck pictures. Some of the things he mentioned are also obviously wrong -- either he never really used it before or it''s a troll? Like that Ruby doesn''t have private, public or protected or it doesn''t have packages. At a glance I don''t think he is really serious. I mean -- how can I take him seriously if he keeps refering to consulting firms as ''insulting'' firms and has apparently not even used Ruby before? Larry White wrote:> I''ve read the arguments and they range from reasonable to foolish, but > the real point is that he''s ''not even wrong'' as the saying goes. > > I''ve been making my living as an engineering manager working on > commercial enterprise Java aplicatations for almost 10 years now. > Ruby on Rails is a perfect example of a disruptive innovation - no > it''s not as good as java in some ways - time zone support for one - > but it''s waaaayyy better than java in other more important ways. This > guy''s on his way to being the COBOL programmer of 2010. > > The idea, btw, that Java programmers/programs are inherently better at > architecture, btw, is an urban myth. > > > On 3/28/06, *David Johnson* < johnson_d@cox.net > <mailto:johnson_d@cox.net>> wrote: > > I didn''t see his original post. > > His points (current posting) are not about the design of ruby, > they are > about the maturity of the platform for use in large scale > developments. > To you they may be amorphous, but to my day to day work they are > crippling (except for the powerpoint presentations - I can do without > those). > > Give Ruby a year and it can easily be up to snuff, if the points are > addressed instead of shooting the messenger (however obnoxious he may > have been). > > On Tue, 2006-03-28 at 18:21 -0600, Jason Perkins wrote: > > On Mar 28, 2006, at 5:41 PM, David Johnson wrote: > > > > > I reviewed most of his arguments, and he is dead on. These are > > > exactly > > > the reasons that I cannot recommend Ruby as an architecture > language > > > for my company. > > > > Good grief, if you''d read DHH''s post at < > http://www.loudthinking.com/ > > arc/000577.html> you''d see that the guy was initially claiming that > > Ruby lacked support for regular expressions, instance variables, > lack > > of a packing system, no access control, etc. (and he did make these > > claims, I read his entry myself before he edited it) and when > > "bullshit" was called he rewrote them as the soft, amorphous points > > that you''re now agreeing with. > > > > -- > > Jason Perkins > > jperkins@sneer.org <mailto:jperkins@sneer.org> > > > > "The computer allows you to make mistakes > > faster than any other invention, with the > > possible exception of handguns and tequila." > > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org <mailto: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 >-- Sau Sheong http://www.saush.com http://read.saush.com http://jaccal.sourceforge.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060329/018b232b/attachment.html
On Wed, 2006-03-29 at 03:01 +0000, Jon Gretar Borgthorsson wrote:> > > > But why oh why Java??? The slowest thing available.... People started > developing in Ruby to get away from things like Java. > >The problem with Java is not the language or the JVM. Both are pretty mundane. The biggest problem with Java is that we have trained a generation of programmers to build EJB''s for everything using the JPetStore example as a pattern. The tool is fundamentally good, but we have failed to train programmers to use the tool properly. Any tool could fall to this fate. Java has succeeded in that it has successfully built a cross-platform virtual machine (that is not tied to the Java language), JIT compilers that allow running code to perform comparably to native compilers for the same task, and a huge library of reusable and reliable code that runs on all of those platforms. Leveraging the JVM automatically gets ruby into any platform supporting a JVM: Z/OS, WAP, AS/400, 6000 series, 9000 series, embedded applications, etc. It automatically buys you the ability to reuse the good things from Java: JDBC, MQ, LDAP, xalan/xerces, unicode, character set conversions. Over night, Ruby could go from being a niche market to a serious contender in the enterprise realm just by running inside of a JVM.
On Wed, 2006-03-29 at 11:24 +0800, Chang Sau Sheong wrote:> In the article James McGovern mentioned only ''Ruby'' but never ''Ruby on > Rails'' and it was obliquely insulting the way he put the various > train-wreck pictures. Some of the things he mentioned are also > obviously wrong -- either he never really used it before or it''s a > troll? Like that Ruby doesn''t have private, public or protected or it > doesn''t have packages.But those things that are obviously right are real issues for the enterprise user, and addressing them will only improve the platform.> > At a glance I don''t think he is really serious. I mean -- how can I > take him seriously if he keeps refering to consulting firms as > ''insulting'' firmsHave you ever had to deal with a consulting firm that didn''t really understand your business before? I believe most enterprise people will understand the reference. Typically, this involves either a firm that has only worked on small systems before (<1000 concurrent users) or has only worked on projects in the financial sector (banks or stock markets).> and has apparently not even used Ruby before?He didn''t do a very thorough analysis. I agree. He also confused the programming language with the programming method. Bad mistake. However, he got enough right that agrees with my observations (and those of others also) that it is worth addressing.
And COBOL and J2EE are trainwrecks that have already happened. The world didn''t end, and there are still more lines of COBOL out there than all other languages put together (because it takes more lines of code to do anything in COBOL). All of McGoverns concrete observations are about platform maturity, not baseline design. They can be addressed by hitting the keyboard. On Wed, 2006-03-29 at 03:10 +0000, Jon Gretar Borgthorsson wrote:> Yes... This and other things other people areare saying here are > things I agree with. I personally will not use ruby for enterprise > setup any day soon. > > But don''t compare bugs and little problems with what McGovern is > saying. He calls Ruby a trainwreck waiting to happen. > >
On Tue, 2006-03-28 at 21:25 -0500, Larry White wrote:> I''ve been making my living as an engineering manager working on > commercial enterprise Java aplicatations for almost 10 years now. > Ruby on Rails is a perfect example of a disruptive innovation - no > it''s not as good as java in some ways - time zone support for one - > but it''s waaaayyy better than java in other more important ways. This > guy''s on his way to being the COBOL programmer of 2010. >My shop still employs more COBOL programmers than any other platform. I guess it means he will be employed. I plan to be retired. :o) Thankfully, I am not limited to only one (or even 10) programming languages.> The idea, btw, that Java programmers/programs are inherently better at > architecture, btw, is an urban myth. >Java programmers, in my experience, tend not to be good at architecture unless they are familiar with at least six or seven other platforms. One only has to look at the EJB/VTO/DAO pattern as it is commonly implemented to see this. You quadruple the lines of code, then add another obscure configuration file, and say it is to make it more manageable?
On Mar 28, 2006, at 9:41 PM, David Johnson wrote:> And COBOL and J2EE are trainwrecks that have already happened. The > world didn''t end, and there are still more lines of COBOL out there > than > all other languages put together (because it takes more lines of > code to > do anything in COBOL). > > All of McGoverns concrete observations are about platform maturity, > not > baseline design. They can be addressed by hitting the keyboard.If that''s your contention, then why are you posting to the Rails mailing list and not the Ruby mailing list? -- Jason Perkins jperkins@sneer.org "The key to performance is elegance, not battalions of special cases." - Jon Bentley and Doug McIlroy
> Enterprises do engage in agile development. But part of working in an > enterprise environment is the understanding that you are interacting, in > real time, with potentially hundreds other programs that are all > critical to your own paycheck.No one can actually manage hundreds of programs. Instead, we have application teams each responsible for more or less a dozen application that consist of a number of programs/interfaces each. We spend dozens of hours discussing the possible ramfications of any change to each and cost the business millions in un-implemented improvements, because we are afraid of both success and failure.> > When I was a 1 man IT shop, I could pretty much do what I wanted. In a > 2 man IT shop (at my church), we have seen a need for formal change > control. In a company with several hundred programmers and technical > people, maintaining those channels of communication is a large part of > why my company is having record years while our competitors are filing > bankruptcy. >Interesting. Have you read about Brook''s Law? Why does effort expand non-linearly as team size increases? My company has more than 20,000 IT employees, about 2500 of which are or have some resemblance to a programmer/developer. I''ve worked here for 8 years and manage a technology team. I''m familiar with our controls, why we have them and why they contribute to the problem more than the solution.> > The battle for the enterprise is not worth winning, why fight it. > > Because if you can win there, you can win anywhere. In the enterprise, > you win by making the best bottom line consistently. You achieve the > best bottom line through good communication and technical excellence.Maybe in some places. Around here you pretty much need good powerpoint.> Ruby and Rails have a very good foundation, but they need a little more > maturity to enter that market and win decisively. J2EE has essentially > failed, client/server technologies are largely a fad of the past, and > people are unwilling to go back to CICS screens. The spot for Ruby and > Rails is open if the platform can provide the technical underpinnings to > make it work.Interesting. Did client/server fail? Not really. Yeah, we had .dll hell but in general people liked those applications much better than anyone ever liked a J2EE app. I have users that still like certain character-based DOS apps and CICS apps better than anything that has supplanted them because they are faster and more efficient than waving a mouse around. Yet J2EE kicked unimaginable butt for years. Why? I''m sure it has nothing to do with bottom lines, good communication or technical excellence. I''m all for communication, and I don''t drink the agile kool-aid either. But I have no respect for the decisions that come out of corporate bodies, and I wouldn''t be swayed by it as a developer looking for the best framework to solve my business problems; I''d apply my knowledge of the feature-set to my problems at hand. -- Jeremy Huffman http://www.jeremyhuffman.com
Indeed, I tried it out, and, indeed, you''re correct. On the positive side, I know every potential way of comparing HTTP date times now... Here was my test: require ''http-access2''require ''date'' h = HTTPAccess2::Client.new() res = h.head(''http://involution.com'') print DateTime.parse(`curl -I http://involution.com 2> /dev/null`).strftime(''%s''),"\n" print DateTime.parse(res.header[''Date''].to_s).strftime(''%s''), "\n" print DateTime.parse(Time.now.to_s).strftime(''%s''), "\n" Output on OS X was: 1143604784 1143604784 1143604787 Thanks, Hammed Tony On 3/28/06, Hammed Malik <hammed@gmail.com> wrote:> Tony, > > Try this: > > > h = HTTPAccess2::Client.new() > res = h.head(''http://involution.com'') > res.header['' Date''] > > => ["Wed, 29 Mar 2006 03:21:30 GMT"] > > Time.now => Tue Mar 28 21:21:41 Central Standard Time 2006 > > Hammed > > > On 3/28/06, Tony Perrie <tony@involution.com> wrote: > > I''ve been trying to figure out how to retrieve a http head request > > date using http-access2. > > > > I thought this could work: > > > > h = HTTPAccess2::Client.new() > > res = h.head(''http://involution.com'' ) > > print response.header[''date''],"\n" > > > > However, that seems to be returning Time.now. Any suggestions? > > > > FYI, you can view a http request by doing the following: > > > > telnet involution.com 80 > > Trying 69.58.21.60... > > Connected to involution.com. > > Escape character is ''^]''. > > HEAD / HTTP/1.0 > > > > HTTP/1.1 200 OK > > -----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X > > Server: Apache/2.0.52 (Red Hat) > > Cache-Control: no-cache > > Set-Cookie: _session_id=670e36e364a03785011afbfafbc15fde; > path=/ > > Connection: close > > Content-Type: text/html; charset=UTF-8 > > > > I''m looking at trying to find a way to see what time the server thinks it > > is to do some time zone correction foo. > > > > Regards, > > > > Tony > > http://involution.com > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > -- > > ----- > Fight back spam! Download the Blue Frog. > http://www.bluesecurity.com/register/s?user=c2FobWVkMTQ%3D > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
On Tue, 2006-03-28 at 21:59 -0600, Jason Perkins wrote:> If that''s your contention, then why are you posting to the Rails > mailing list and not the Ruby mailing list? >Because someone else started this thread and I thought it looked interesting.
On Tue, 2006-03-28 at 23:00 -0500, Jeremy Huffman wrote:> > Enterprises do engage in agile development. But part of working in an > > enterprise environment is the understanding that you are interacting, in > > real time, with potentially hundreds other programs that are all > > critical to your own paycheck. > > No one can actually manage hundreds of programs. Instead, we have > application teams each responsible for more or less a dozen > application that consist of a number of programs/interfaces each. We > spend dozens of hours discussing the possible ramfications of any > change to each and cost the business millions in un-implemented > improvements, because we are afraid of both success and failure.The infamous analysis paralysis syndrome. I''ve seen it first hand, and I sympathize. Fortunately it has been the exception rather than the rule.> > > > When I was a 1 man IT shop, I could pretty much do what I wanted. In a > > 2 man IT shop (at my church), we have seen a need for formal change > > control. In a company with several hundred programmers and technical > > people, maintaining those channels of communication is a large part of > > why my company is having record years while our competitors are filing > > bankruptcy. > > > > Interesting. Have you read about Brook''s Law? Why does effort expand > non-linearly as team size increases? >yes .. that is why individual teams are generally kept to less than six people. The rule of thumb is that after six people the cost of management is more than the cost of the team.> My company has more than 20,000 IT employees, about 2500 of which are > or have some resemblance to a programmer/developer. I''ve worked here > for 8 years and manage a technology team. I''m familiar with our > controls, why we have them and why they contribute to the problem more > than the solution. >Our company is similar sized, but we have about 1/5th the number of IT people, of whom about just under half are programmers and a similar number are technical support people. The remainder are management/team lead types.> > > > The battle for the enterprise is not worth winning, why fight it. > > > > Because if you can win there, you can win anywhere. In the enterprise, > > you win by making the best bottom line consistently. You achieve the > > best bottom line through good communication and technical excellence. > > Maybe in some places. Around here you pretty much need good powerpoint.Ugh ... my condolences.> > > Ruby and Rails have a very good foundation, but they need a little more > > maturity to enter that market and win decisively. J2EE has essentially > > failed, client/server technologies are largely a fad of the past, and > > people are unwilling to go back to CICS screens. The spot for Ruby and > > Rails is open if the platform can provide the technical underpinnings to > > make it work. > > Interesting. Did client/server fail?I don''t see much C/S work happening any more. The job market is pretty slim for C/S apps programmers right now.> Not really. Yeah, we had .dll > hell but in general people liked those applications much better than > anyone ever liked a J2EE app.Me too, but the cost of deploying our suite of C/S apps to thousands of machines across the country was prohibitive. The web environment sacrifices ease of use for cheaper (but not easier) deployment. Rails provides the core for faster development and easier deployment of web apps (better bottom line) if it could fully meet the technical requirements. The formalization of AJAX as a middle ground between C/S and Browsing, and Rails natural support for that platform, really puts Ruby and Rails in the right position to become a serious contender.> I have users that still like certain > character-based DOS apps and CICS apps better than anything that has > supplanted them because they are faster and more efficient than waving > a mouse around.I understand fully. You can whip through 10 CICS screens in the time it takes one web page to render in the browser.> Yet J2EE kicked unimaginable butt for years. Why? I''m > sure it has nothing to do with bottom lines, good communication or > technical excellence. >marketing ... but it has failed to deliver on the hype. It is a good technology, but it has not reduced the bottom line or improved the IT experience. Servlets succeeded, but much of the rest of the J2EE platform failed. For example, EJB''s failure is exemplified by the adoption of the competing "hibernate" technology as the core of EJB 3. The time is right for a competitor to rise up.> I''m all for communication, and I don''t drink the agile kool-aid > either. But I have no respect for the decisions that come out of > corporate bodies, and I wouldn''t be swayed by it as a developer > looking for the best framework to solve my business problems; I''d > apply my knowledge of the feature-set to my problems at hand.Big ten-four.
On Mar 28, 2006, at 10:56 PM, David Johnson wrote:> On Tue, 2006-03-28 at 21:59 -0600, Jason Perkins wrote: >> If that''s your contention, then why are you posting to the Rails >> mailing list and not the Ruby mailing list? >> > Because someone else started this thread and I thought it looked > interesting.Certainly, but I wonder if ideas wouldn''t receive a more thoughtful review on a list that has folks who are more current on YARV development, internationalization, etc. than here. -- Jason Perkins jperkins@sneer.org "The key to performance is elegance, not battalions of special cases." - Jon Bentley and Doug McIlroy
probably ... if this thread is pursued further then maybe it should be moved. I think it may have been played out. I know I am. See y''all tomorrow. David Johnson On Tue, 2006-03-28 at 23:13 -0600, Jason Perkins wrote:> On Mar 28, 2006, at 10:56 PM, David Johnson wrote: > > > On Tue, 2006-03-28 at 21:59 -0600, Jason Perkins wrote: > >> If that''s your contention, then why are you posting to the Rails > >> mailing list and not the Ruby mailing list? > >> > > Because someone else started this thread and I thought it looked > > interesting. > > Certainly, but I wonder if ideas wouldn''t receive a more thoughtful > review on a list that has folks who are more current on YARV > development, internationalization, etc. than here. > > -- > Jason Perkins > jperkins@sneer.org > > "The key to performance is elegance, not > battalions of special cases." > - Jon Bentley and Doug McIlroy > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
David Johnson wrote:> On Wed, 2006-03-29 at 11:24 +0800, Chang Sau Sheong wrote: > >> In the article James McGovern mentioned only ''Ruby'' but never ''Ruby on >> Rails'' and it was obliquely insulting the way he put the various >> train-wreck pictures. Some of the things he mentioned are also >> obviously wrong -- either he never really used it before or it''s a >> troll? Like that Ruby doesn''t have private, public or protected or it >> doesn''t have packages. >> > > But those things that are obviously right are real issues for the > enterprise user, and addressing them will only improve the platform. > >Yup, agreed. Rails is only about a year old? Java was about a year old were still talking excitedly abt the animated Duke. :) Agreed that there are lots of things to improve on Rails still, but still think it''s current a ''good enough'' technology for most small to mid-level (enterprise or not) web applications. I''m talking for people who has experience in developing web applications in the first place, not a total newbie.>> At a glance I don''t think he is really serious. I mean -- how can I >> take him seriously if he keeps refering to consulting firms as >> ''insulting'' firms >> > > Have you ever had to deal with a consulting firm that didn''t really > understand your business before? I believe most enterprise people will > understand the reference. Typically, this involves either a firm that > has only worked on small systems before (<1000 concurrent users) or has > only worked on projects in the financial sector (banks or stock > markets). > >Dealt with consulting firms, consulted on a few occasions (enterprise-level? was dealing with a bank then) as well. Calling names isn''t exactly the best way be taken seriously. But I suppose blogging changes things nowadays :)>> and has apparently not even used Ruby before? >> > > He didn''t do a very thorough analysis. I agree. He also confused the > programming language with the programming method. Bad mistake. > > However, he got enough right that agrees with my observations (and those > of others also) that it is worth addressing. > > >-- Sau Sheong http://www.saush.com http://read.saush.com http://jaccal.sourceforge.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060329/2e4b32dd/attachment.html
What are you talking about? Ruby already runs in a virtual machine: http://www.rubygarden.org/ruby?VirtualMachineOptions Also, a virtual machine does not necessarily have the impact on performance that you think it does (a poorly designed vm does however): http://c.ittoolbox.com/documents/academic-articles/performance-of-java-versus-c-2586 http://www.idiom.com/~zilla/Computer/javaCbenchmark.html http://www.javaworld.com/jw-02-1998/jw-02-jperf.html http://kontrawize.blogs.com/kontrawize/2006/01/i_can_still_rem.html http://kano.net/javabench/ And Ruby can only gain from being able to run in more VMs than the default one, especially if they have the tremendous penetration that the JVM does. b Jon Gretar Borgthorsson wrote:> Sorry.. But JRuby just mystifies me..... Why would you want to make > Ruby slower???? > > Can you just point out to me how running Ruby in a virtual machine is > going to improve anything? > > Regarding the enterprise support for 8000 users.... I would say that > it''s not really a problem for Ruby on Rails. It''s more the headache of > the developer of the application rather than problems of the framework > builders. It''s true that many things is immature and untested in Ruby > when it comes to high user base and things like load balancing is > really non-existent. But I frankly don''t want it in there except as an > optional gem because I just simply don''t want to know of it''s > existence until I need to use it. > > To sum it up... Yes... Rails is maybe not ready for the enterprise > market. But isn''t it really OUR job to make it ready? > > > On 3/28/06, David Johnson <johnson_d@cox.net> wrote: > >>I reviewed most of his arguments, and he is dead on. These are exactly >>the reasons that I cannot recommend Ruby as an architecture language >>for my company. I love Ruby (so far), but it isn''t ready for prime-time >>in my day-to-day work environment (large company with over 8,000 users >>on a real-time business critical system). >> >>As I am working with Ruby and Rails, I am discovering both how nice this >>combination can be and what its shortcomings are. For the most part, >>these are a matter of maturity, not principle. Given another year or >>two Ruby could be up to snuff. >> >>With that said, I can recommend Ruby "as-is" for "bread and butter" >>applications and utility scripting, and as a "watch" technology as >>certain features mature. >> >>At the same time, J2EE is showing its age. After ten years of being >>used to write web apps that babysit RDBMS''s, J2EE is harder to use than >>ever and slow as molasses at Cold Lake in January. The EJB/DAO design >>pattern quadruples the programmer''s work with negative payback in >>performance and reliability. >> >>JRuby (Ruby running under a JVM) is actually very interesting to us, but >>it is about 80 bugs away from being ready for active consideration. >>JRuby offers the internationalization, threading, and other support that >>regular Ruby does not yet, because the underlying JVM and Java runtime >>classes support them. >> >>On Tue, 2006-03-28 at 16:04 -0700, Giles Bowkett wrote: >> >>>btw, I think he''s doing it for the Google Ads revenue. his arguments >>>don''t even make sense. >>> >>>On 3/28/06, Giles Bowkett <gilesb@gmail.com> wrote: >>> >>>>no, it''s sincere. that''s this totally crazy dude who DHH talks about >>>>in his blog. >>>> >>>>http://www.loudthinking.com/arc/000577.html >>>> >>>>On 3/28/06, Edward Frederick <epfrederick@gmail.com> wrote: >>>> >>>>>I sure hope so: >>>>> >>>>>http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html >>>>> >>>>>Seems like it''s getting genuine rebuttals, though. It''s actually kind >>>>>of amusing. >>>>>_______________________________________________ >>>>>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 >> >>_______________________________________________ >>Rails mailing list >>Rails@lists.rubyonrails.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> > > > > -- > -------------- > Jon Gretar Borgthorsson > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Ben Munat wrote:> What are you talking about? Ruby already runs in a virtual machine: > > http://www.rubygarden.org/ruby?VirtualMachineOptionsNot really. As that page points out, the current Ruby implementation creates and interprets a parse tree, rather than having a virtual machine with a defined instruction set. regards Justin
Il giorno 29/mar/06, alle ore 05:05, David Johnson ha scritto:> Ruby and Rails have a very good foundation, but they need a little > more > maturity to enter that market and win decisively. J2EE has > essentially > failed, client/server technologies are largely a fad of the past, and > people are unwilling to go back to CICS screens. The spot for Ruby > and > Rails is open if the platform can provide the technical > underpinnings to > make it work.David, I just wanted to congratulate you for your opinions. Spot-on, equlibrate and hype-free. We need more people like you between the McGoverns and the iconoclasts of this world. I pretty much agree with everything you wrote here, no need to add more, really. Cheers, Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
David Johnson wrote:> I reviewed most of his arguments, and he is dead on. These are exactly > the reasons that I cannot recommend Ruby as an architecture language > for my company. I love Ruby (so far), but it isn''t ready for prime-time > in my day-to-day work environment (large company with over 8,000 users > on a real-time business critical system).> With that said, I can recommend Ruby "as-is" for "bread and butter" > applications and utility scripting, and as a "watch" technology as > certain features mature.Eh. At my company we use Ruby to index, process and store electronic documents in a large database. Near as Monty knows, we have one of the largest (in terms of record count) MySQL installations. This mission critical system has an entire stack written in Ruby (except where certain functions were rewritten in C for speed), including a custom persistence layer that supports multiple RDBMSs. We''ve been running this high throughput system for several years now without a major failure that wasn''t due to hardware or programmer error. When I first came to ruby I was skeptical myself, but its performance has been outstanding, and development has been as enjoyable an experience as I''ve had programming. Maybe Ruby isn''t ready in terms of APIs and third-party libraries, but that will come with time. As for the EJB-style n-tier architecture, I''m not convinced that''s an approach that would really benefit Ruby, or users looking to use Ruby for it. -- Posted via http://www.ruby-forum.com/.
Jon Gretar Borgthorsson
2006-Mar-29 14:29 UTC
[Rails] Re: Is this an elaborate hoax/troll?
But do we want Ruby to be a true enterprise ready application? I''m not sure we would want that. I would prefer Ruby to be the small and nice thing it is now rather than becoming the bloated mess Perl has become. In the same way as I hope Apple never tries to make it into enterprise markets because these are two masters not easily served. Most enterprise software I have tried are great for the enterprise thinking and method of doing things. But they really are awful at the home and small business market where the needs are so drastically different. Even though many will disagree on comparing software to language in this way I really think Ruby should NOT try to replace C or Java or any other languages. Ruby has found it''s market and should stick with it. On 3/29/06, Bry M. <rafuzo@spamcop.net> wrote:> David Johnson wrote: > > I reviewed most of his arguments, and he is dead on. These are exactly > > the reasons that I cannot recommend Ruby as an architecture language > > for my company. I love Ruby (so far), but it isn''t ready for prime-time > > in my day-to-day work environment (large company with over 8,000 users > > on a real-time business critical system). > > > With that said, I can recommend Ruby "as-is" for "bread and butter" > > applications and utility scripting, and as a "watch" technology as > > certain features mature. > > Eh. At my company we use Ruby to index, process and store electronic > documents in a large database. Near as Monty knows, we have one of the > largest (in terms of record count) MySQL installations. This mission > critical system has an entire stack written in Ruby (except where > certain functions were rewritten in C for speed), including a custom > persistence layer that supports multiple RDBMSs. We''ve been running this > high throughput system for several years now without a major failure > that wasn''t due to hardware or programmer error. When I first came to > ruby I was skeptical myself, but its performance has been outstanding, > and development has been as enjoyable an experience as I''ve had > programming. > > Maybe Ruby isn''t ready in terms of APIs and third-party libraries, but > that will come with time. As for the EJB-style n-tier architecture, I''m > not convinced that''s an approach that would really benefit Ruby, or > users looking to use Ruby for it. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- -------------- Jon Gretar Borgthorsson
On Wed, Mar 29, 2006 at 02:25:07PM +0000, Jon Gretar Borgthorsson wrote: } But do we want Ruby to be a true enterprise ready application? } I''m not sure we would want that. I would prefer Ruby to be the small } and nice thing it is now rather than becoming the bloated mess Perl } has become. In the same way as I hope Apple never tries to make it } into enterprise markets because these are two masters not easily } served. } } Most enterprise software I have tried are great for the enterprise } thinking and method of doing things. But they really are awful at the } home and small business market where the needs are so drastically } different. } } Even though many will disagree on comparing software to language in } this way I really think Ruby should NOT try to replace C or Java or } any other languages. Ruby has found it''s market and should stick with } it. The problems that keep Ruby from being "ready for the enterprise" affect more than just enterprise-readiness. Unicode and i18n support is an issue if the target audience for your code don''t all speak the same language (e.g. setting up a genealogy website for your family, which has branches various European countries). Performance, including native threading, is an issue for any software that takes too long to do what it does (e.g. generating thumbnails of all those pictures of your kids on your dual-processor machine). Rails support for stored procedures is harder to argue as a non-enterprise issue, but there are those of us who find it easier (and more efficient) to express data manipulation in SQL than in Ruby, even for our own personal projects. Improved support for DB2 and Oracle absolutely makes sense, since free versions are available for non-commercial use and some of us *like* them. Development tools are an issue for everyone. There is room for improvement in Ruby, and it is worth improving in general, not just in the name of enterprise-readiness. --Greg
Rails doesn''t prevent you from using stored procs. I use them on Postgres and haven''t had any problems. Expecting it to be able to automatically map from a proc to the object layer seems to me to be unreasonable, since procs can do anything and everything and not just CRUD. There are a number of missing ruby features, unicode, i18n, timezone supt, etc. that may prevent it''s immediate use for certain kinds of enterprise apps, but the vast majority of enterprise apps are single-language anyway. Java''s date support was problematic for a long time, as was its threading. Ruby will get there, too. Gregory is right. There''s a danger, I think, in trying to improve Ruby by making it more Java-like. It needs improvements in both performance and in additional functionality, but if you want a Java like language, try Java. On 3/29/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:> > On Wed, Mar 29, 2006 at 02:25:07PM +0000, Jon Gretar Borgthorsson wrote: > } But do we want Ruby to be a true enterprise ready application? > } I''m not sure we would want that. I would prefer Ruby to be the small > } and nice thing it is now rather than becoming the bloated mess Perl > } has become. In the same way as I hope Apple never tries to make it > } into enterprise markets because these are two masters not easily > } served. > } > } Most enterprise software I have tried are great for the enterprise > } thinking and method of doing things. But they really are awful at the > } home and small business market where the needs are so drastically > } different. > } > } Even though many will disagree on comparing software to language in > } this way I really think Ruby should NOT try to replace C or Java or > } any other languages. Ruby has found it''s market and should stick with > } it. > > The problems that keep Ruby from being "ready for the enterprise" affect > more than just enterprise-readiness. Unicode and i18n support is an issue > if the target audience for your code don''t all speak the same language > (e.g. setting up a genealogy website for your family, which has branches > various European countries). Performance, including native threading, is > an > issue for any software that takes too long to do what it does (e.g. > generating thumbnails of all those pictures of your kids on your > dual-processor machine). Rails support for stored procedures is harder to > argue as a non-enterprise issue, but there are those of us who find it > easier (and more efficient) to express data manipulation in SQL than in > Ruby, even for our own personal projects. Improved support for DB2 and > Oracle absolutely makes sense, since free versions are available for > non-commercial use and some of us *like* them. Development tools are an > issue for everyone. > > There is room for improvement in Ruby, and it is worth improving in > general, not just in the name of enterprise-readiness. > > --Greg > > _______________________________________________ > 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/20060329/66a32f1a/attachment.html
Justin Forder wrote:> Ben Munat wrote: > >> What are you talking about? Ruby already runs in a virtual machine: >> >> http://www.rubygarden.org/ruby?VirtualMachineOptions > > > Not really. As that page points out, the current Ruby implementation > creates and interprets a parse tree, rather than having a virtual > machine with a defined instruction set. >Well, it''s still generally called a virtual machine (over and over on that page). And, in relation to the original poster''s point, the interpreted parse tree approach is generally less performant than the bytecode approach. At least I''ve seen some numbers indicating that. However, raw speed comparisons don''t tell the whole story -- as the Java world has been saying for years. I wouldn''t go there other than to state that the anti-VM sentiment is based on urban legends (and the early JVM performance, which sucked). b
>> Support for Oracle; while I haven''t tried using Oracle with Rails >> personally, there''s enough people having trouble with it to make me >> suspect that Oracle+Rails might not be a good combinationI''d be interested in hearing any concerns about using Oracle with Rails. We''ve been using it for production apps for 6+ months, with no issues.
> > The battle for the enterprise is not worth winning, why fight it. > > Because if you can win there, you can win anywhere. In the enterprise, > you win by making the best bottom line consistently. You achieve the > best bottom line through good communication and technical excellence.Not really. The whole philosophy of Rails is based on the idea that what''s best for some gigantic corporation with eight quadrillion employees isn''t what''s best for small businesses. Rails is opinionated software highly optimized for small business. That enterprise "thought leader" is a bit of a crackhead, but there are differences between what extremely large intracorporate applications require and what most systems need. I''d imagine there are probably lots of overarchitected enterprise apps that could run on Rails quite happily, though. -- Giles Bowkett www.gilesgoatboy.org
On 3/28/06, David Johnson <johnson_d@cox.net> wrote:> On Tue, 2006-03-28 at 21:59 -0600, Jason Perkins wrote: > > If that''s your contention, then why are you posting to the Rails > > mailing list and not the Ruby mailing list? > > > Because someone else started this thread and I thought it looked > interesting.you **would** say that! you - you - you JAVA GUY! -- Giles Bowkett www.gilesgoatboy.org
> The messenger was not slammed because of the message. He was slammed because: > A) Nobody likes people who proclaim themselves industry leaders when > ho showed many times that he had marginal programming knowledge > B) He didn''t even seem to have looked at Ruby. His message was full of > errors and FUD. Even though he tried to hide it later. (ceck out JHH''s > post to see what I am talking about) >Yeah--it wasn''t so much the message that led me to believe it was hoax/troll, but some of the (possibly now edited) content. There were some strange stuff in there that made it smell like flamebait (and truth be told, all good trolls invoke insecurity via some level of validity).
On Wed, 2006-03-29 at 15:27 -0700, Giles Bowkett wrote:> On 3/28/06, David Johnson <johnson_d@cox.net> wrote: > > On Tue, 2006-03-28 at 21:59 -0600, Jason Perkins wrote: > > > If that''s your contention, then why are you posting to the Rails > > > mailing list and not the Ruby mailing list? > > > > > Because someone else started this thread and I thought it looked > > interesting. > > you **would** say that! you - you - you JAVA GUY!:o) Except when I''m C, or COBOL, or VB, or XSLT, or Pascal, or Object Pascal (aka Delphi), or Assembly, or NetRexx, or Python, or SQL, or ...
On 3/29/06, Larry White <ljw1001@gmail.com> wrote:> Rails doesn''t prevent you from using stored procs. I use them on Postgres > and haven''t had any problems. Expecting it to be able to automatically map > from a proc to the object layer seems to me to be unreasonable, since procs > can do anything and everything and not just CRUD. >OK, how do you do that? I keep hearing bits and pieces about how it''s "possible" but no code. I want to be able to take user input, send it to a postgres function, and know if it succeeded or failed. If it failed, I would like to be able to get at the error message. I also, in my fantasy dream land, want to take user input, send it to a set returning function, and use the resulting output. AFAICT there are no FAQ, Blog entries, tutorials or anything on this.
On Wed, 2006-03-29 at 15:21 -0700, Giles Bowkett wrote:> > > The battle for the enterprise is not worth winning, why fight it. > > > > Because if you can win there, you can win anywhere. In the enterprise, > > you win by making the best bottom line consistently. You achieve the > > best bottom line through good communication and technical excellence. > > Not really. The whole philosophy of Rails is based on the idea that > what''s best for some gigantic corporation with eight quadrillion > employees isn''t what''s best for small businesses. Rails is opinionated > software highly optimized for small business.But, the Ruby and Rails combination is productive and robust enough that big business is becoming interested in it (hence my own presence on this list, and that of some others in enterprise computing environments).> > That enterprise "thought leader" is a bit of a crackhead, but there > are differences between what extremely large intracorporate > applications require and what most systems need.Even many "bread-and-butter" apps and tools in the enterprise can be handled by Rails today. It just can''t (yet) handle the heavy hitting stuff because of a few implementation issues that will be relatively straightforward (though not necessarily easy) to correct.> I''d imagine there are > probably lots of overarchitected enterprise apps that could run on > Rails quite happily, though.Overarchitected? I''m not sure what you mean. I have seen poorly architected apps, and apps that solved complex problems, but I have never seen something that I could truly call overarchitected. Could you elaborate? I agree that many enterprise apps could be built with a fraction of the lines of code and with better results under rails (than under J2EE), but there are places where ruby (and rails) just misses the target by a small margin, in places that you can''t easily fake out. Threading support is really the core piece that is missing from Ruby that prevents it from cleaning up in the heavyweight division. Rails origins with non-compliant backing stores (MySQL) shows in its use of SQL92 keywords as property names (POSITION is a particular thorn in the flesh for me at this moment). People using SQL92 or later compliant RDBMS'' (postgres, firebird, oracle, DB2) cannot use ActiveRecord''s acts_as_list modifier, for example. These issues are correctable without compromising the viability of Rails for small systems. They are not core design issues, they are maturity issues.> > -- > Giles Bowkett > www.gilesgoatboy.org
All the code was generated so it''s a bit vague and it''s prototype code. You would need to clean it up. Also, I haven''t used this code in a while so no promises. I hope you find it helpful. the short answer is you use the postgresql library http://wiki.rubyonrails.com/rails/pages/PostgreSQL then try something like this: class CountryDao def self.get_connection DAO.get_connection # see below end # this returns a single row: def self.get(user_id, object_id, get_deleted) res = get_connection.exec("select * from get_country(#{user_id}, #{object_id}, #{get_deleted});") if res.num_tuples > 0 country = Country.new() populate(country, res, 0) else raise "not found exception" end res.clear country end # this returns a refcursor def self.get_result_set(query_string) get_connection.exec("BEGIN;") result = get_connection.query(query_string) refcursor_name = result[0].to_s res = get_connection.query("FETCH ALL IN \"#{refcursor_name}\";") get_connection.exec("COMMIT;") res end def self.populate(object, result_set, row_number) object.object_id = result_set.getvalue(row_number ,0) object.updated_by = result_set.getvalue(row_number ,1) object.updated = result_set.getvalue(row_number ,2) object.deleted = result_set.getvalue(row_number ,3) object.parent_id = result_set.getvalue(row_number ,4) object.name = result_set.getvalue(row_number ,5) object.description = result_set.getvalue(row_number ,6) return object end end The DAO class looks like this: require "postgres" class DAO @@conn = PGconn.connect("localhost", 5432, "", "", "Test", "username", "password") def self.get_connection @@conn end end On 3/29/06, Ian Harding <iharding@destinydata.com> wrote:> > On 3/29/06, Larry White <ljw1001@gmail.com> wrote: > > Rails doesn''t prevent you from using stored procs. I use them on > Postgres > > and haven''t had any problems. Expecting it to be able to automatically > map > > from a proc to the object layer seems to me to be unreasonable, since > procs > > can do anything and everything and not just CRUD. > > > > OK, how do you do that? I keep hearing bits and pieces about how it''s > "possible" but no code. > > I want to be able to take user input, send it to a postgres function, > and know if it succeeded or failed. If it failed, I would like to be > able to get at the error message. > > I also, in my fantasy dream land, want to take user input, send it to > a set returning function, and use the resulting output. >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060330/b0a02a56/attachment-0001.html
Hello.> JRuby (Ruby running under a JVM) is actually very interesting to us, but > it is about 80 bugs away from being ready for active consideration. > JRuby offers the internationalization, threading, and other support that > regular Ruby does not yet, because the underlying JVM and Java runtime > classes support them.Allow me to emphasis this. JRuby has the potential to rock Ruby on Rails like RoR rocked Ruby! <http://jruby.sourceforge.net/> To be enterprise-ready means _integration_. Consider the impact of Apache XML stack including Cocoon, JCR, JDBC, JTA, Hibernate and Unicode available to RoR. <http://xml.apache.org/> To be enterprise-ready means _reliable application servers_. Consider RoR on the cluster-ready JBoss microkernel. <http://labs.jboss.com/portal/jbossas/architecture> Only to name a very few :-) Remember that J2EE is not just EJB. <http://en.wikipedia.org/wiki/Java_Platform%2C_Enterprise_Edition> <http://de.wikipedia.org/wiki/Bild:J2ee-overview.png> German: <http://de.wikipedia.org/wiki/J2EE> BTW: You could integrate RoR with J2EE using Hessian. This is the better approach if you need Ruby libraries that depend on native shared libraries. <http://wiki.caucho.com/Hessian_-_Ruby_implementation> <http://jruby.sourceforge.net/docs/faq.shtml> I can''t wait for the second birth of Ruby on Rails. Regards, Gert Thiel
Michael Schuerig
2006-Mar-30 12:49 UTC
[Rails] SQL92 compliance (was: Is this an elaborate hoax/troll?)
On Thursday 30 March 2006 03:35, David Johnson wrote:> Rails origins with non-compliant backing stores (MySQL) shows in its > use of SQL92 keywords as property names (POSITION is a particular > thorn in the flesh for me at this moment). ?People using SQL92 or > later compliant RDBMS'' (postgres, firebird, oracle, DB2) cannot use > ActiveRecord''s acts_as_list modifier, for example.I probably don''t understand your problem, but I have columns named "position" in several of my tables and PostgreSQL (8.0.x) works just fine with this. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
On Thursday 30 March 2006 11:18, Gert Thiel wrote:> JRuby has the potential to rock Ruby on Rails like RoR rocked Ruby!Somehow I don''t see this.> To be enterprise-ready means _integration_. Consider the impact of > Apache XML stack including Cocoon, JCR, JDBC, JTA, Hibernate and > Unicode available to RoR.And that''s so great? If you need all this stuff, why not just use Java/J2EE, maybe with a healthy dose of Spring thrown in, from the start? If you don''t like Java-the-language, well, then go for Groovy.> To be enterprise-ready means _reliable application servers_. Consider > RoR on the cluster-ready JBoss microkernel.I take it that this would require a complete rewrite of Rails. I agree wholeheartedly that interoperability is important. I don''t agree on the assumed means to achieve it. Has the SOA ideal/fad died already? Rails can nicely interoperate on the level of services. There''s really no need to absorb it into Java. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
On Wed, Mar 29, 2006 at 07:35:21PM -0600, David Johnson wrote: } On Wed, 2006-03-29 at 15:21 -0700, Giles Bowkett wrote: [...] } > I''d imagine there are probably lots of overarchitected enterprise apps } > that could run on Rails quite happily, though. } } Overarchitected? I''m not sure what you mean. I have seen poorly } architected apps, and apps that solved complex problems, but I have never } seen something that I could truly call overarchitected. Could you } elaborate? [...] I will give an example of an overarchitected app. This is not a web app, but rather a .NET thick client. The names of the various companies involved are withheld to protect my butt. Basically, the project is in-house, mission-critical software. It is backed by several large databases, and performs a variety of data entry, manipulation, cleaning, crunching, and reporting functions. The basis of this application is the almighty framework. In this application, there are persisted objects which are all represented in a single table with universally relevant information like parent object, plus side join tables for specific types. Loading and saving is handled automagically by the framework. All such objects exist in memory as an instance object which holds onto an ADO.NET typed dataset. All screens (and partial screens) must be implemented as subclasses of a particular framework class, which does framework magic with the persisted objects. Screens are actually shown to the user in nested tabs and stacks and popups and such based on a database representation of how the pieces fit together. For each (partial) screen a user will see, there is an automagically-handled persisted object (AHPO from here on) which specifies which class to load from which DLL, to what type of AHPO it is conceptually attached, its title, etc. Of course, it may be a container screen for other screens, in which case it has no DLL or class itself, just child screens. And you can have another variant that just points to a screen but with slight changes. All this information about screens makes it possible for many controls, based on their names, to automagically bind to the appropriate data value. Constants are held in the database as well. There are these items with a unique number, a short name, a longer name, an ordering value, and several additional fields for extra information. They belong to some primary group of items, but they can belong to more than one group. In the additional groups, the long name (but nothing else) can be overridden. These are used for various automagical dropdowns. When first working with this framework, it seemed like it took care of a whole lot of stuff for you, and the idea of separating out as much functionality as data rather than code was appealing. Eventually, though, it becomes clear that the app spends so much time on framework magic that actual user interaction suffers. The system is painfully slow. It must be deployed on terminal services so that the system running the app can be on a gigabit link to the database server because so much data has to be read by the app to accomplish anything, and so much data gets persisted when the user does anything. This is what it means to be overarchitected. The system is full of beautiful design ideals, but doesn''t actually get the job done well. Their may be development and maintenance gains, but they are hidden by the development costs (new developers require months of ramp-up time, which can also lead to staffing problems) and the cost of lost user productivity as the users wait for the system to respond. --Greg
Michael Schuerig wrote:> And that''s so great? If you need all this stuff, why not just use > Java/J2EE, maybe with a healthy dose of Spring thrown in, from the > start? If you don''t like Java-the-language, well, then go for Groovy.It''s just more powerful than either straight Java or straight Ruby. Groovy is just an attempt to write Ruby-esque code in the JVM. JRuby would likely render it pointless. But actually, Java 6 will probably render both JRuby and Groovy pointless: it will support running several dynamic languages (PHP, Javacript, Ruby, etc.) within the JVM and straight from Java code.>>To be enterprise-ready means _reliable application servers_. Consider >>RoR on the cluster-ready JBoss microkernel. > > > I take it that this would require a complete rewrite of Rails.NO. That would be stupid. The whole goal is to be able to run Ruby code, unmodified, in the JVM.> I agree wholeheartedly that interoperability is important. I don''t agree > on the assumed means to achieve it. Has the SOA ideal/fad died already? > Rails can nicely interoperate on the level of services. There''s really > no need to absorb it into Java.The goal is not to "absorb Ruby into Java". The goal is to allow even closer interoperation than services allow. There is nothing to fear in this and everything to be gained. b
On Thursday 30 March 2006 18:00, Ben Munat wrote:> The goal is not to "absorb Ruby into Java". The goal is to allow even > closer interoperation than services allow. There is nothing to fear > in this and everything to be gained.What I''m wondering about is, whether Rails will survive unscathed all the changes it may have to endure in the name of close interoperation with Java and enterprise readiness. From my point of view, enterprise readiness is not the be-all and end-all of every piece of software. There''s life outside the enterprise. And there''s fully legitimate software development going on outside the enterprise. My impression is that Rails has its focus there and I''d like it to remain there. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
I just stumbled across this thread, and figured I should inject a few opinions. I am one of two active developers on JRuby, where my main charge has been the redesign of the core interpreter and planning for various stages of compilation. I also recently got IRB and Rails'' generate script working, and I''m currently focused on optimizing the interpreter a bit before we present JRuby at JavaOne. I''ll try to address some of the issues people have brought up: 1. Java is slow I had thought this myth was entirely debunked, but as others have commented Java is nothing like slow. In certain scenarios there''s a bit more overhead than on "hand-optimized assembler code" but then you probably aren''t going to hand optimize a million lines of assembly either. Java is actually, in many cases, faster than compiled C code, owing to its ability to optimize and re-optimize code based on usage patterns. There''s never just one way to optimize a code path, and the mixed-mode compilation Java does while running allows it to exceed native code frequently. Take a look at any of the typical language shootouts or performance benchmarks. On equivalent algorithms, Java is extremely fast...in many, many cases far faster than the current Ruby code. The following benchmark shows Java beating Ruby by an order of magnitude in almost every case, though it frequently uses more memory to do it: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15 Even if the benchmark is flawed, it''s hard to argue that an optimized Ruby implementation on the JVM would necessarily be slower. 2. Enterprise is a loaded term that isn''t important I agree. Enterprise has become as meaningless as SOA, Middleware, and their ilk. However, the concepts behind the word (or the concepts I''d like to believe are behind the word) are very important. "Enterprise Java" has come to mean many things to many people. If you equate Enterprise with Enterprise Java Beans, then you''re selling the platform short. EJBs may have been initially compelling, but their verbosity and complexity have doomed them to ridicule. Don''t write off the entire platform, however. The Java Transaction API has made cross-request and even cross-server transactions trivial to handle. Enlisting n remote servers into a larger transaction is handled transparently. The Java Message Service has provided a simple, reliable, cross-platform and cross-server means of handling asynchronous communications. It really "just works" and provides huge benefits for long-running processes and offline transactions. Java Management Extensions, while not officially part of Enterprise Java, provide consistent, uniform remote administration and management capabilities, along with managed, monitored services throughout an application cluster. And while we''re on that topic, clustering, failover, and session replication within typical Enterprise Java clusters "just works" too. I won''t even go into JDBC, perhaps the most impressive cross-platform and cross-database SQL api that exists. I am by day officially a "J2EE Architect", though my eventual role has me mostly escorting other developers through the pain of writing J2EE applications and trying to find better tools, frameworks, and patterns to make that process simpler. I feel all the typical pain of J2EE developers, and I agree there are bad areas...but don''t throw the baby out with the bathwater. 3. Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails The goal of JRuby is to create a fast Ruby interpreter that looks, feels, and acts just like Ruby. We will not require any modifications to Ruby (and in fact we run with Ruby''s own lib/ruby/1.8 libraries), and we only reimplement specific features where the Ruby equivalent doesn''t consider Java''s capabilities or where Ruby implements those features in C. A similar argument goes for Rails: Rails must be able to run without modification under JRuby, albeit behind a "mock CGI" Servlet that can simulate running with fastcgi and friends. What we do hope to provide is a way to access Java''s good features from within Rails. JDBC is an obvious match for ActiveRecord, and JTA can provide transaction support seamlessly. Once inside a J2EE cluster, we can also enable replication and failover for Rails sessions and requests by wiring those subsystems into those provided by the cluster. We can wire JMS into available messaging libraries for Ruby, allowing Rails to submit jobs to any JMS-aware server (which ultimately could mean any messaging server, since most of them support JMS). The list goes on and on. It is true, and must be accepted, that while Ruby the language is a marvelous, beautiful thing, Ruby the platform still has some growing up to do. Unicode support is partial and inconsistent. Support for locale-specific calendars, messages, and behaviors is nowhere near what Java provides. Integration with other languages and other platforms is sketchy at best. Ruby simply lacks many features that would help it gain acceptance as more than "just another scripting language." I''m certain Ruby will get everything it''s missing over time, but by putting Ruby and Rails on the JVM we may be able to have them now. Who knows, perhaps the APIs that develop out of Ruby on the JVM will filter back into the design process for future versions of Ruby. 4. My plan for JRuby (though just one view of where we''re going) I will try to lay out briefly the current plan for JRuby. - We are currently working very hard to get Rails running for a simple case. The generate script already works and generates usable code and configuration. The next step is getting Rails to handle a request. We currently get pretty far into that process before things bomb out, and expect to have it working by the end of this month. - JRuby is, despite Java''s speed, quite slow right now. The original author just did a simple port of Ruby''s C code to what it would look like in Java, and as a result many JVM features that could speed Ruby up were crippled or impossible to utilize. My work recently has been to completely rewrite and rewire the internals of JRuby to enable compilation to Java bytecode, full continuations support, tail-call optimization, and multi-VM (running multiple "Rubies" inside the same JVM). All of these will help improve performance, and we hope to exceed Ruby 1.8 performance at some point. I would welcome any questions or comments. Our main goal with JRuby is to provide a real Ruby environment that happens to be running on the JVM, and to enable Ruby code to integrate with Java code whereever it is useful to do so. We would be as happy as you all if Ruby were to supplant Java as the language-of-choice, and if JRuby helps further that goal...all the better. -- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060330/64b10702/attachment-0001.html
Charles, Informative and exciting post. Thank you for it and for your work on JRuby. I look forward to it. Best regards, Bill ----- Original Message ----- From: Charles O Nutter To: rails@lists.rubyonrails.org Sent: 2006-03-30 12:46 PM Subject: Re: [Rails] Re: Is this an elaborate hoax/troll? I just stumbled across this thread, and figured I should inject a few opinions. I am one of two active developers on JRuby, where my main charge has been the redesign of the core interpreter and planning for various stages of compilation. I also recently got IRB and Rails'' generate script working, and I''m currently focused on optimizing the interpreter a bit before we present JRuby at JavaOne. I''ll try to address some of the issues people have brought up: 1. Java is slow I had thought this myth was entirely debunked, but as others have commented Java is nothing like slow. In certain scenarios there''s a bit more overhead than on "hand-optimized assembler code" but then you probably aren''t going to hand optimize a million lines of assembly either. Java is actually, in many cases, faster than compiled C code, owing to its ability to optimize and re-optimize code based on usage patterns. There''s never just one way to optimize a code path, and the mixed-mode compilation Java does while running allows it to exceed native code frequently. Take a look at any of the typical language shootouts or performance benchmarks. On equivalent algorithms, Java is extremely fast...in many, many cases far faster than the current Ruby code. The following benchmark shows Java beating Ruby by an order of magnitude in almost every case, though it frequently uses more memory to do it: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15 Even if the benchmark is flawed, it''s hard to argue that an optimized Ruby implementation on the JVM would necessarily be slower. 2. Enterprise is a loaded term that isn''t important I agree. Enterprise has become as meaningless as SOA, Middleware, and their ilk. However, the concepts behind the word (or the concepts I''d like to believe are behind the word) are very important. "Enterprise Java" has come to mean many things to many people. If you equate Enterprise with Enterprise Java Beans, then you''re selling the platform short. EJBs may have been initially compelling, but their verbosity and complexity have doomed them to ridicule. Don''t write off the entire platform, however. The Java Transaction API has made cross-request and even cross-server transactions trivial to handle. Enlisting n remote servers into a larger transaction is handled transparently. The Java Message Service has provided a simple, reliable, cross-platform and cross-server means of handling asynchronous communications. It really "just works" and provides huge benefits for long-running processes and offline transactions. Java Management Extensions, while not officially part of Enterprise Java, provide consistent, uniform remote administration and management capabilities, along with managed, monitored services throughout an application cluster. And while we''re on that topic, clustering, failover, and session replication within typical Enterprise Java clusters "just works" too. I won''t even go into JDBC, perhaps the most impressive cross-platform and cross-database SQL api that exists. I am by day officially a "J2EE Architect", though my eventual role has me mostly escorting other developers through the pain of writing J2EE applications and trying to find better tools, frameworks, and patterns to make that process simpler. I feel all the typical pain of J2EE developers, and I agree there are bad areas...but don''t throw the baby out with the bathwater. 3. Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails The goal of JRuby is to create a fast Ruby interpreter that looks, feels, and acts just like Ruby. We will not require any modifications to Ruby (and in fact we run with Ruby''s own lib/ruby/1.8 libraries), and we only reimplement specific features where the Ruby equivalent doesn''t consider Java''s capabilities or where Ruby implements those features in C. A similar argument goes for Rails: Rails must be able to run without modification under JRuby, albeit behind a "mock CGI" Servlet that can simulate running with fastcgi and friends. What we do hope to provide is a way to access Java''s good features from within Rails. JDBC is an obvious match for ActiveRecord, and JTA can provide transaction support seamlessly. Once inside a J2EE cluster, we can also enable replication and failover for Rails sessions and requests by wiring those subsystems into those provided by the cluster. We can wire JMS into available messaging libraries for Ruby, allowing Rails to submit jobs to any JMS-aware server (which ultimately could mean any messaging server, since most of them support JMS). The list goes on and on. It is true, and must be accepted, that while Ruby the language is a marvelous, beautiful thing, Ruby the platform still has some growing up to do. Unicode support is partial and inconsistent. Support for locale-specific calendars, messages, and behaviors is nowhere near what Java provides. Integration with other languages and other platforms is sketchy at best. Ruby simply lacks many features that would help it gain acceptance as more than "just another scripting language." I''m certain Ruby will get everything it''s missing over time, but by putting Ruby and Rails on the JVM we may be able to have them now. Who knows, perhaps the APIs that develop out of Ruby on the JVM will filter back into the design process for future versions of Ruby. 4. My plan for JRuby (though just one view of where we''re going) I will try to lay out briefly the current plan for JRuby. - We are currently working very hard to get Rails running for a simple case. The generate script already works and generates usable code and configuration. The next step is getting Rails to handle a request. We currently get pretty far into that process before things bomb out, and expect to have it working by the end of this month. - JRuby is, despite Java''s speed, quite slow right now. The original author just did a simple port of Ruby''s C code to what it would look like in Java, and as a result many JVM features that could speed Ruby up were crippled or impossible to utilize. My work recently has been to completely rewrite and rewire the internals of JRuby to enable compilation to Java bytecode, full continuations support, tail-call optimization, and multi-VM (running multiple "Rubies" inside the same JVM). All of these will help improve performance, and we hope to exceed Ruby 1.8 performance at some point. I would welcome any questions or comments. Our main goal with JRuby is to provide a real Ruby environment that happens to be running on the JVM, and to enable Ruby code to integrate with Java code whereever it is useful to do so. We would be as happy as you all if Ruby were to supplant Java as the language-of-choice, and if JRuby helps further that goal...all the better. -- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.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/20060330/e06e51e9/attachment.html
fwiw, the Jython effort -- similar to JRuby -- has had a good effect on the Python community, especially in that it forced Guido von Rossum to answer some pretty challenging questions about which features of Python were language features and which were merely features of the interpreter. I code Java at work too, although I''d rather be using Rails, but it''s true to some extent that with Java there is a baby in all that bathwater. I still think James McGovern''s on crack, though. On 3/30/06, Bill Walton <bill.walton@charter.net> wrote:> > Charles, > > Informative and exciting post. Thank you for it and for your work on JRuby. > I look forward to it. > > Best regards, > > Bill > > > ----- Original Message ----- > From: Charles O Nutter > To: rails@lists.rubyonrails.org > Sent: 2006-03-30 12:46 PM > Subject: Re: [Rails] Re: Is this an elaborate hoax/troll? > > I just stumbled across this thread, and figured I should inject a few > opinions. I am one of two active developers on JRuby, where my main charge > has been the redesign of the core interpreter and planning for various > stages of compilation. I also recently got IRB and Rails'' generate script > working, and I''m currently focused on optimizing the interpreter a bit > before we present JRuby at JavaOne. I''ll try to address some of the issues > people have brought up: > > 1. Java is slow > I had thought this myth was entirely debunked, but as others have commented > Java is nothing like slow. In certain scenarios there''s a bit more overhead > than on "hand-optimized assembler code" but then you probably aren''t going > to hand optimize a million lines of assembly either. Java is actually, in > many cases, faster than compiled C code, owing to its ability to optimize > and re-optimize code based on usage patterns. There''s never just one way to > optimize a code path, and the mixed-mode compilation Java does while running > allows it to exceed native code frequently. Take a look at any of the > typical language shootouts or performance benchmarks. On equivalent > algorithms, Java is extremely fast...in many, many cases far faster than the > current Ruby code. > > The following benchmark shows Java beating Ruby by an order of magnitude in > almost every case, though it frequently uses more memory to do it: > > http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15 > > Even if the benchmark is flawed, it''s hard to argue that an optimized Ruby > implementation on the JVM would necessarily be slower. > > 2. Enterprise is a loaded term that isn''t important > > I agree. Enterprise has become as meaningless as SOA, Middleware, and their > ilk. However, the concepts behind the word (or the concepts I''d like to > believe are behind the word) are very important. > > "Enterprise Java" has come to mean many things to many people. If you equate > Enterprise with Enterprise Java Beans, then you''re selling the platform > short. EJBs may have been initially compelling, but their verbosity and > complexity have doomed them to ridicule. Don''t write off the entire > platform, however. The Java Transaction API has made cross-request and even > cross-server transactions trivial to handle. Enlisting n remote servers into > a larger transaction is handled transparently. The Java Message Service has > provided a simple, reliable, cross-platform and cross-server means of > handling asynchronous communications. It really "just works" and provides > huge benefits for long-running processes and offline transactions. Java > Management Extensions, while not officially part of Enterprise Java, provide > consistent, uniform remote administration and management capabilities, along > with managed, monitored services throughout an application cluster. And > while we''re on that topic, clustering, failover, and session replication > within typical Enterprise Java clusters "just works" too. I won''t even go > into JDBC, perhaps the most impressive cross-platform and cross-database SQL > api that exists. > > I am by day officially a "J2EE Architect", though my eventual role has me > mostly escorting other developers through the pain of writing J2EE > applications and trying to find better tools, frameworks, and patterns to > make that process simpler. I feel all the typical pain of J2EE developers, > and I agree there are bad areas...but don''t throw the baby out with the > bathwater. > > 3. Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails > > The goal of JRuby is to create a fast Ruby interpreter that looks, feels, > and acts just like Ruby. We will not require any modifications to Ruby (and > in fact we run with Ruby''s own lib/ruby/1.8 libraries), and we only > reimplement specific features where the Ruby equivalent doesn''t consider > Java''s capabilities or where Ruby implements those features in C. A similar > argument goes for Rails: Rails must be able to run without modification > under JRuby, albeit behind a "mock CGI" Servlet that can simulate running > with fastcgi and friends. > > What we do hope to provide is a way to access Java''s good features from > within Rails. JDBC is an obvious match for ActiveRecord, and JTA can provide > transaction support seamlessly. Once inside a J2EE cluster, we can also > enable replication and failover for Rails sessions and requests by wiring > those subsystems into those provided by the cluster. We can wire JMS into > available messaging libraries for Ruby, allowing Rails to submit jobs to any > JMS-aware server (which ultimately could mean any messaging server, since > most of them support JMS). The list goes on and on. > > It is true, and must be accepted, that while Ruby the language is a > marvelous, beautiful thing, Ruby the platform still has some growing up to > do. Unicode support is partial and inconsistent. Support for locale-specific > calendars, messages, and behaviors is nowhere near what Java provides. > Integration with other languages and other platforms is sketchy at best. > Ruby simply lacks many features that would help it gain acceptance as more > than "just another scripting language." I''m certain Ruby will get everything > it''s missing over time, but by putting Ruby and Rails on the JVM we may be > able to have them now. Who knows, perhaps the APIs that develop out of Ruby > on the JVM will filter back into the design process for future versions of > Ruby. > > 4. My plan for JRuby (though just one view of where we''re going) > > I will try to lay out briefly the current plan for JRuby. > > - We are currently working very hard to get Rails running for a simple case. > The generate script already works and generates usable code and > configuration. The next step is getting Rails to handle a request. We > currently get pretty far into that process before things bomb out, and > expect to have it working by the end of this month. > - JRuby is, despite Java''s speed, quite slow right now. The original author > just did a simple port of Ruby''s C code to what it would look like in Java, > and as a result many JVM features that could speed Ruby up were crippled or > impossible to utilize. My work recently has been to completely rewrite and > rewire the internals of JRuby to enable compilation to Java bytecode, full > continuations support, tail-call optimization, and multi-VM (running > multiple "Rubies" inside the same JVM). All of these will help improve > performance, and we hope to exceed Ruby 1.8 performance at some point. > > I would welcome any questions or comments. Our main goal with JRuby is to > provide a real Ruby environment that happens to be running on the JVM, and > to enable Ruby code to integrate with Java code whereever it is useful to do > so. We would be as happy as you all if Ruby were to supplant Java as the > language-of-choice, and if JRuby helps further that goal...all the better. > > -- > Charles Oliver Nutter @ headius.blogspot.com > JRuby Developer @ jruby.sourceforge.net > Application Architect @ www.ventera.com > > > ________________________________ > > > > _______________________________________________ > 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 > > >-- Giles Bowkett www.gilesgoatboy.org
Stephen Bannasch
2006-Mar-30 19:51 UTC
[Rails] how can action=>render add a ".jnlp" suffix?
I have a builder template that renders a Java webstart jnlp file. Right now I am creating the the jnlp file links like this: link_to ''Run'', :action => ''jnlp'', :id => activity Which creates links like this: http://host.com/controller/jnlp/1 The action looks like this: def jnlp @headers["Content-Type"] = "application/x-java-jnlp-file" @headers["Cache-Control"] = "public" @activity = Activity.find(params[:id]) render :layout => false end Which implicitly calls the Builder view: jnlp.rxml By setting the Content-Type in the http headers most browsers correctly interpret the file "1" as a jnlp file and if Java is installed start the webstart application. However FireFox on MacOS seems to require that the file actually be served with the ".jnlp" filename suffix. So I''d like to instead create links like this: http://host.com/controller/jnlp/1.jnlp The general question is: how can I concatenate a static filename suffix to a link? Thanks! -- - Stephen Bannasch Concord Consortium, http://www.concord.org
Charles O Nutter wrote:> I just stumbled across this thread, and figured I should inject a few > opinions. I am one of two active developers on JRuby, where my main > charge has been the redesign of the core interpreter and planning for > various stages of compilation. I also recently got IRB and Rails'' > generate script working, and I''m currently focused on optimizing the > interpreter a bit before we present JRuby at JavaOne. I''ll try to > address some of the issues people have brought up: > > 1. Java is slow > I had thought this myth was entirely debunked, but as others have > commented Java is nothing like slow. In certain scenarios there''s a bit > more overhead than on "hand-optimized assembler code" but then you > probably aren''t going to hand optimize a million lines of assembly > either. Java is actually, in many cases, faster than compiled C code, > owing to its ability to optimize and re-optimize code based on usage > patterns. There''s never just one way to optimize a code path, and the > mixed-mode compilation Java does while running allows it to exceed > native code frequently. Take a look at any of the typical language > shootouts or performance benchmarks. On equivalent algorithms, Java is > extremely fast...in many, many cases far faster than the current Ruby code. > > The following benchmark shows Java beating Ruby by an order of magnitude > in almost every case, though it frequently uses more memory to do it: > > http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15 > <http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15> > > Even if the benchmark is flawed, it''s hard to argue that an optimized > Ruby implementation on the JVM would necessarily be slower. > > 2. Enterprise is a loaded term that isn''t important > > I agree. Enterprise has become as meaningless as SOA, Middleware, and > their ilk. However, the concepts behind the word (or the concepts I''d > like to believe are behind the word) are very important. > > "Enterprise Java" has come to mean many things to many people. If you > equate Enterprise with Enterprise Java Beans, then you''re selling the > platform short. EJBs may have been initially compelling, but their > verbosity and complexity have doomed them to ridicule. Don''t write off > the entire platform, however. The Java Transaction API has made > cross-request and even cross-server transactions trivial to handle. > Enlisting n remote servers into a larger transaction is handled > transparently. The Java Message Service has provided a simple, reliable, > cross-platform and cross-server means of handling asynchronous > communications. It really "just works" and provides huge benefits for > long-running processes and offline transactions. Java Management > Extensions, while not officially part of Enterprise Java, provide > consistent, uniform remote administration and management capabilities, > along with managed, monitored services throughout an application > cluster. And while we''re on that topic, clustering, failover, and > session replication within typical Enterprise Java clusters "just works" > too. I won''t even go into JDBC, perhaps the most impressive > cross-platform and cross-database SQL api that exists. > > I am by day officially a "J2EE Architect", though my eventual role has > me mostly escorting other developers through the pain of writing J2EE > applications and trying to find better tools, frameworks, and patterns > to make that process simpler. I feel all the typical pain of J2EE > developers, and I agree there are bad areas...but don''t throw the baby > out with the bathwater. > > 3. Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails > > The goal of JRuby is to create a fast Ruby interpreter that looks, > feels, and acts just like Ruby. We will not require any modifications to > Ruby (and in fact we run with Ruby''s own lib/ruby/1.8 libraries), and we > only reimplement specific features where the Ruby equivalent doesn''t > consider Java''s capabilities or where Ruby implements those features in > C. A similar argument goes for Rails: Rails must be able to run without > modification under JRuby, albeit behind a "mock CGI" Servlet that can > simulate running with fastcgi and friends. > > What we do hope to provide is a way to access Java''s good features from > within Rails. JDBC is an obvious match for ActiveRecord, and JTA can > provide transaction support seamlessly. Once inside a J2EE cluster, we > can also enable replication and failover for Rails sessions and requests > by wiring those subsystems into those provided by the cluster. We can > wire JMS into available messaging libraries for Ruby, allowing Rails to > submit jobs to any JMS-aware server (which ultimately could mean any > messaging server, since most of them support JMS). The list goes on and on. > > It is true, and must be accepted, that while Ruby the language is a > marvelous, beautiful thing, Ruby the platform still has some growing up > to do. Unicode support is partial and inconsistent. Support for > locale-specific calendars, messages, and behaviors is nowhere near what > Java provides. Integration with other languages and other platforms is > sketchy at best. Ruby simply lacks many features that would help it gain > acceptance as more than "just another scripting language." I''m certain > Ruby will get everything it''s missing over time, but by putting Ruby and > Rails on the JVM we may be able to have them now. Who knows, perhaps the > APIs that develop out of Ruby on the JVM will filter back into the > design process for future versions of Ruby. > > 4. My plan for JRuby (though just one view of where we''re going) > > I will try to lay out briefly the current plan for JRuby. > > - We are currently working very hard to get Rails running for a simple > case. The generate script already works and generates usable code and > configuration. The next step is getting Rails to handle a request. We > currently get pretty far into that process before things bomb out, and > expect to have it working by the end of this month. > - JRuby is, despite Java''s speed, quite slow right now. The original > author just did a simple port of Ruby''s C code to what it would look > like in Java, and as a result many JVM features that could speed Ruby up > were crippled or impossible to utilize. My work recently has been to > completely rewrite and rewire the internals of JRuby to enable > compilation to Java bytecode, full continuations support, tail-call > optimization, and multi-VM (running multiple "Rubies" inside the same > JVM). All of these will help improve performance, and we hope to exceed > Ruby 1.8 performance at some point. > > I would welcome any questions or comments. Our main goal with JRuby is > to provide a real Ruby environment that happens to be running on the > JVM, and to enable Ruby code to integrate with Java code whereever it is > useful to do so. We would be as happy as you all if Ruby were to > supplant Java as the language-of-choice, and if JRuby helps further that > goal...all the better.Beautifully put. (My day job is a bit like yours.) Regarding your last point, I expect that JRuby will always benefit from giving users the ability to drop down into Java, just as CRuby benefits from allowing users to drop down into C. thanks for your excellent work Justin
I agree with the McGovern thing, btw. At least, I think I do...it was hard to understand what he was trying to say with so many spelling, grammar, and logic mistakes. I blogged a few responses, if anyone''s interested in reading a few more: http://headius.blogspot.com/2006/03/enterprise-sour-grapes.html On 3/30/06, Giles Bowkett <gilesb@gmail.com> wrote:> > fwiw, the Jython effort -- similar to JRuby -- has had a good effect > on the Python community, especially in that it forced Guido von Rossum > to answer some pretty challenging questions about which features of > Python were language features and which were merely features of the > interpreter. > > I code Java at work too, although I''d rather be using Rails, but it''s > true to some extent that with Java there is a baby in all that > bathwater. > > I still think James McGovern''s on crack, though. > > On 3/30/06, Bill Walton <bill.walton@charter.net> wrote: > > > > Charles, > > > > Informative and exciting post. Thank you for it and for your work on > JRuby. > > I look forward to it. > > > > Best regards, > > > > Bill > > > > > > ----- Original Message ----- > > From: Charles O Nutter > > To: rails@lists.rubyonrails.org > > Sent: 2006-03-30 12:46 PM > > Subject: Re: [Rails] Re: Is this an elaborate hoax/troll? > > > > I just stumbled across this thread, and figured I should inject a few > > opinions. I am one of two active developers on JRuby, where my main > charge > > has been the redesign of the core interpreter and planning for various > > stages of compilation. I also recently got IRB and Rails'' generate > script > > working, and I''m currently focused on optimizing the interpreter a bit > > before we present JRuby at JavaOne. I''ll try to address some of the > issues > > people have brought up: > > > > 1. Java is slow > > I had thought this myth was entirely debunked, but as others have > commented > > Java is nothing like slow. In certain scenarios there''s a bit more > overhead > > than on "hand-optimized assembler code" but then you probably aren''t > going > > to hand optimize a million lines of assembly either. Java is actually, > in > > many cases, faster than compiled C code, owing to its ability to > optimize > > and re-optimize code based on usage patterns. There''s never just one way > to > > optimize a code path, and the mixed-mode compilation Java does while > running > > allows it to exceed native code frequently. Take a look at any of the > > typical language shootouts or performance benchmarks. On equivalent > > algorithms, Java is extremely fast...in many, many cases far faster than > the > > current Ruby code. > > > > The following benchmark shows Java beating Ruby by an order of magnitude > in > > almost every case, though it frequently uses more memory to do it: > > > > > http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15 > > > > Even if the benchmark is flawed, it''s hard to argue that an optimized > Ruby > > implementation on the JVM would necessarily be slower. > > > > 2. Enterprise is a loaded term that isn''t important > > > > I agree. Enterprise has become as meaningless as SOA, Middleware, and > their > > ilk. However, the concepts behind the word (or the concepts I''d like to > > believe are behind the word) are very important. > > > > "Enterprise Java" has come to mean many things to many people. If you > equate > > Enterprise with Enterprise Java Beans, then you''re selling the platform > > short. EJBs may have been initially compelling, but their verbosity and > > complexity have doomed them to ridicule. Don''t write off the entire > > platform, however. The Java Transaction API has made cross-request and > even > > cross-server transactions trivial to handle. Enlisting n remote servers > into > > a larger transaction is handled transparently. The Java Message Service > has > > provided a simple, reliable, cross-platform and cross-server means of > > handling asynchronous communications. It really "just works" and > provides > > huge benefits for long-running processes and offline transactions. Java > > Management Extensions, while not officially part of Enterprise Java, > provide > > consistent, uniform remote administration and management capabilities, > along > > with managed, monitored services throughout an application cluster. And > > while we''re on that topic, clustering, failover, and session replication > > within typical Enterprise Java clusters "just works" too. I won''t even > go > > into JDBC, perhaps the most impressive cross-platform and cross-database > SQL > > api that exists. > > > > I am by day officially a "J2EE Architect", though my eventual role has > me > > mostly escorting other developers through the pain of writing J2EE > > applications and trying to find better tools, frameworks, and patterns > to > > make that process simpler. I feel all the typical pain of J2EE > developers, > > and I agree there are bad areas...but don''t throw the baby out with the > > bathwater. > > > > 3. Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails > > > > The goal of JRuby is to create a fast Ruby interpreter that looks, > feels, > > and acts just like Ruby. We will not require any modifications to Ruby > (and > > in fact we run with Ruby''s own lib/ruby/1.8 libraries), and we only > > reimplement specific features where the Ruby equivalent doesn''t consider > > Java''s capabilities or where Ruby implements those features in C. A > similar > > argument goes for Rails: Rails must be able to run without modification > > under JRuby, albeit behind a "mock CGI" Servlet that can simulate > running > > with fastcgi and friends. > > > > What we do hope to provide is a way to access Java''s good features from > > within Rails. JDBC is an obvious match for ActiveRecord, and JTA can > provide > > transaction support seamlessly. Once inside a J2EE cluster, we can also > > enable replication and failover for Rails sessions and requests by > wiring > > those subsystems into those provided by the cluster. We can wire JMS > into > > available messaging libraries for Ruby, allowing Rails to submit jobs to > any > > JMS-aware server (which ultimately could mean any messaging server, > since > > most of them support JMS). The list goes on and on. > > > > It is true, and must be accepted, that while Ruby the language is a > > marvelous, beautiful thing, Ruby the platform still has some growing up > to > > do. Unicode support is partial and inconsistent. Support for > locale-specific > > calendars, messages, and behaviors is nowhere near what Java provides. > > Integration with other languages and other platforms is sketchy at best. > > Ruby simply lacks many features that would help it gain acceptance as > more > > than "just another scripting language." I''m certain Ruby will get > everything > > it''s missing over time, but by putting Ruby and Rails on the JVM we may > be > > able to have them now. Who knows, perhaps the APIs that develop out of > Ruby > > on the JVM will filter back into the design process for future versions > of > > Ruby. > > > > 4. My plan for JRuby (though just one view of where we''re going) > > > > I will try to lay out briefly the current plan for JRuby. > > > > - We are currently working very hard to get Rails running for a simple > case. > > The generate script already works and generates usable code and > > configuration. The next step is getting Rails to handle a request. We > > currently get pretty far into that process before things bomb out, and > > expect to have it working by the end of this month. > > - JRuby is, despite Java''s speed, quite slow right now. The original > author > > just did a simple port of Ruby''s C code to what it would look like in > Java, > > and as a result many JVM features that could speed Ruby up were crippled > or > > impossible to utilize. My work recently has been to completely rewrite > and > > rewire the internals of JRuby to enable compilation to Java bytecode, > full > > continuations support, tail-call optimization, and multi-VM (running > > multiple "Rubies" inside the same JVM). All of these will help improve > > performance, and we hope to exceed Ruby 1.8 performance at some point. > > > > I would welcome any questions or comments. Our main goal with JRuby is > to > > provide a real Ruby environment that happens to be running on the JVM, > and > > to enable Ruby code to integrate with Java code whereever it is useful > to do > > so. We would be as happy as you all if Ruby were to supplant Java as the > > language-of-choice, and if JRuby helps further that goal...all the > better. > > > > -- > > Charles Oliver Nutter @ headius.blogspot.com > > JRuby Developer @ jruby.sourceforge.net > > Application Architect @ www.ventera.com > > > > > > ________________________________ > > > > > > > > _______________________________________________ > > 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 > > > > > > > > > -- > Giles Bowkett > www.gilesgoatboy.org > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060330/e01b0b4e/attachment.html
On 3/30/06, Charles O Nutter <headius@headius.com> wrote:> I just stumbled across this thread, and figured I should inject a few[snip]> > -- > Charles Oliver Nutter @ headius.blogspot.com > JRuby Developer @ jruby.sourceforge.net > Application Architect @ www.ventera.comThanks for this great post, Charles. Thanks especially for dispelling the "java is slow" myth that just will not die, and was getting thrown around a bit earlier. - Rob -- http://www.robsanheim.com/ http://www.ajaxian.com/
Jon Gretar Borgthorsson
2006-Mar-30 22:48 UTC
[Rails] Re: Is this an elaborate hoax/troll?
> > Thanks for this great post, Charles. Thanks especially for dispelling > the "java is slow" myth that just will not die, and was getting thrown > around a bit earlier.I don''t know about the speed in web service application. But most people get the "java is slow" thing from java desktop applications. Which are utterly useless and famous for being unresponsive and I have never seen a good java desktop application. However comparing a compiled java application with an uncompiled ruby application as was pointed out in a chart earlier is strange. It''s strange to say that the solution would be to run ruby in java instead of just making a ruby compiler. I''m just afraid that hereafter there will be 2 version of ruby. One real and one in java. -- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/
I understand that perspective, but our goal is to run Ruby apps as well as Ruby does, without modification. In other words, we want to run whatever the C implementation can, as much as possible. We''re not about to try forking the language or "embracing and extending" it, Microsoft-style. As for the compiler question...the current work being done on a Ruby compiler does not, I''m sorry to say, compile Ruby down to native code. It compiles it into bytecode, just like Java, and the new Ruby VM then executes that bytecode. It promises considerable performance improvements in some areas, but since it will be layer on top of the existing implementation it will only provide limited improvements in others. It''s excellent work, but it''s important that when Rubyists refer to the new "compiler" they understand that it is a bytecode compiler. What, then, is the harm in writing a compiler to turn Ruby into Java bytecodes? The Java VM is well-established and has shown its potential. It performs extremely well, considering object allocation, garbage collection, and native threads are all provided out-of-the-box. It is also very stable, widely-deployed, and supported on many platforms. I think Ruby on the JVM is a sure win, both both the Java and Ruby worlds. Want more justification? There are at least three projects going right now to make Ruby for the .NET CLR...I''d certainly hate to see Microsoft corner the market on VM-based Ruby, how bout you? On 3/30/06, Jon Gretar Borgthorsson <jon.borgthorsson@gmail.com> wrote:> > > > > Thanks for this great post, Charles. Thanks especially for dispelling > > the "java is slow" myth that just will not die, and was getting thrown > > around a bit earlier. > > I don''t know about the speed in web service application. But most > people get the "java is slow" thing from java desktop applications. > Which are utterly useless and famous for being unresponsive and I have > never seen a good java desktop application. > > However comparing a compiled java application with an uncompiled ruby > application as was pointed out in a chart earlier is strange. It''s > strange to say that the solution would be to run ruby in java instead > of just making a ruby compiler. > > I''m just afraid that hereafter there will be 2 version of ruby. One > real and one in java. > > > -- > -------------- > Jon Gretar Borgthorsson > http://www.jongretar.net/ > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060330/8ed65ef7/attachment-0001.html
> > I don''t know about the speed in web service application. But most > people get the "java is slow" thing from java desktop applications. > Which are utterly useless and famous for being unresponsive and I have > never seen a good java desktop application.I consider eclipse as a good java desktop application, nevertheless, starting a JVM is expensive in terms of memory consumption and process cycles. However comparing a compiled java application with an uncompiled ruby> application as was pointed out in a chart earlier is strange. It''s > strange to say that the solution would be to run ruby in java instead > of just making a ruby compiler.Well, for the Ruby compiler, there is YARV which is supposed to compile ruby 2.0.0 I''m just afraid that hereafter there will be 2 version of ruby. One> real and one in java.The java ruby version probably will just be used for special cases (one interesting example: together with red5 <http://www.osflash.org/red5> Flash streaming media server) -- Roberto Saccon - http://rsaccon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060330/b35a4621/attachment.html
On 3/30/06, Jon Gretar Borgthorsson <jon.borgthorsson@gmail.com> wrote:> > > > Thanks for this great post, Charles. Thanks especially for dispelling > > the "java is slow" myth that just will not die, and was getting thrown > > around a bit earlier. > > I don''t know about the speed in web service application. But most > people get the "java is slow" thing from java desktop applications. > Which are utterly useless and famous for being unresponsive and I have > never seen a good java desktop application. >This used to be the case, but Swing and SWT have come a long way. Take a look at SmartCVS, Eclipse, Azureus, etc. They may use a lot of resources and be hard to develop, but they aren''t necessarily slow. :) Anyways, back to Ruby... - rob -- http://www.robsanheim.com/ http://www.ajaxian.com/
Jon Gretar Borgthorsson
2006-Mar-31 01:08 UTC
[Rails] Re: Is this an elaborate hoax/troll?
On 3/31/06, Rob Sanheim <rsanheim@gmail.com> wrote:> > This used to be the case, but Swing and SWT have come a long way. > Take a look at SmartCVS, Eclipse, Azureus, etc. They may use a lot of > resources and be hard to develop, but they aren''t necessarily slow. :) >Actually... I hate to use both Eclipse and Azureus. Those are not slow in the processing part. But simple things like resizing the window or dragging seperators is intolerable. It''s like having the monitor working on 5 frames a second. And that is just wasting valuable time and intolerable in an IDE. And they don''t take a lot of resources.... The take A LOT of resources. Having Azureus running made my laptop unusable since it only has 512mb. -- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/
To me, that sounds to me more like failure to understand the concept of architecture than over-architecting. Architecture should be about making the programmer''s life easier by making the the processes cleaner and more obvious. This framework you describe is forcing programming by side effect, which is always a bad idea. An architecture is a wonderful servant, but a terrible master. I hate programming by side effect. It leads to misuse of the platform and odd behaviors when people unwittingly trigger event loops. I spent 5 years straightening out one of those messes. I understand your pain - I have seen similar situations. I am fortunate to be senior enough to get away with saying "that won''t work here because ..." and having the leeway to do things right. A lot of times, the degree of dynamism you describe is actually a result of a failure to understand the problem space fully. That does not mean spending a bazillion hours poring over some nimnul''s powerpoint presentations. It means recognizing that complex solutions generally mean that you don''t understand the problem yet, and striving for a simpler solution that encompasses the entire problem space. In general, it really is easier to solve the entire problem than to solve just bits and pieces. Special conditions (even if they are embodied in framework side effects) are generally a sign that something is not understood fully yet. This is true whether it is J2EE, Rails, .not (sorry - .net), or even lowly COBOL. On Thu, 2006-03-30 at 10:17 -0500, Gregory Seidman wrote:> On Wed, Mar 29, 2006 at 07:35:21PM -0600, David Johnson wrote: > } On Wed, 2006-03-29 at 15:21 -0700, Giles Bowkett wrote: > [...] > } > I''d imagine there are probably lots of overarchitected enterprise apps > } > that could run on Rails quite happily, though. > } > } Overarchitected? I''m not sure what you mean. I have seen poorly > } architected apps, and apps that solved complex problems, but I have never > } seen something that I could truly call overarchitected. Could you > } elaborate? > [...] > > I will give an example of an overarchitected app. This is not a web app, > but rather a .NET thick client. The names of the various companies involved > are withheld to protect my butt. Basically, the project is in-house, > mission-critical software. It is backed by several large databases, and > performs a variety of data entry, manipulation, cleaning, crunching, and > reporting functions. > > The basis of this application is the almighty framework. In this > application, there are persisted objects which are all represented in a > single table with universally relevant information like parent object, plus > side join tables for specific types. Loading and saving is handled > automagically by the framework. All such objects exist in memory as an > instance object which holds onto an ADO.NET typed dataset. > > All screens (and partial screens) must be implemented as subclasses of a > particular framework class, which does framework magic with the persisted > objects. Screens are actually shown to the user in nested tabs and stacks > and popups and such based on a database representation of how the pieces > fit together. For each (partial) screen a user will see, there is an > automagically-handled persisted object (AHPO from here on) which specifies > which class to load from which DLL, to what type of AHPO it is conceptually > attached, its title, etc. Of course, it may be a container screen for other > screens, in which case it has no DLL or class itself, just child screens. > And you can have another variant that just points to a screen but with > slight changes. All this information about screens makes it possible for > many controls, based on their names, to automagically bind to the > appropriate data value. > > Constants are held in the database as well. There are these items with a > unique number, a short name, a longer name, an ordering value, and several > additional fields for extra information. They belong to some primary group > of items, but they can belong to more than one group. In the additional > groups, the long name (but nothing else) can be overridden. These are used > for various automagical dropdowns. > > When first working with this framework, it seemed like it took care of a > whole lot of stuff for you, and the idea of separating out as much > functionality as data rather than code was appealing. Eventually, though, > it becomes clear that the app spends so much time on framework magic that > actual user interaction suffers. The system is painfully slow. It must be > deployed on terminal services so that the system running the app can be on > a gigabit link to the database server because so much data has to be read > by the app to accomplish anything, and so much data gets persisted when the > user does anything. > > This is what it means to be overarchitected. The system is full of > beautiful design ideals, but doesn''t actually get the job done well. Their > may be development and maintenance gains, but they are hidden by the > development costs (new developers require months of ramp-up time, which can > also lead to staffing problems) and the cost of lost user productivity as > the users wait for the system to respond. > > --Greg > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On Thu, Mar 30, 2006 at 10:47:19PM +0000, Jon Gretar Borgthorsson wrote: [...] } I don''t know about the speed in web service application. But most } people get the "java is slow" thing from java desktop applications. } Which are utterly useless and famous for being unresponsive and I have } never seen a good java desktop application. [...] I used a good Java desktop application some years ago. It was the DB2 administration application, and I was pretty pleased with it. I also wrote a very simple one that worked nicely. That said, I''ve used numerous Java applications that completely failed to impress me with their responsiveness, including Azureus and Eclipse. } Jon Gretar Borgthorsson --Greg
On Thu, Mar 30, 2006 at 09:01:55PM -0600, David Johnson wrote: } To me, that sounds to me more like failure to understand the concept of } architecture than over-architecting. Architecture should be about making } the programmer''s life easier by making the the processes cleaner and more } obvious. This framework you describe is forcing programming by side } effect, which is always a bad idea. I don''t know that it''s *always* a bad idea, but too much of it certainly gets frustrating. } An architecture is a wonderful servant, but a terrible master. [...] ...and I think that is an excellent definition of overarchitecting. Overarchitecture means that developers spend more time satisfying the framework''s demands than the system requirements. } A lot of times, the degree of dynamism you describe is actually a result } of a failure to understand the problem space fully. That does not mean } spending a bazillion hours poring over some nimnul''s powerpoint } presentations. It means recognizing that complex solutions generally } mean that you don''t understand the problem yet, and striving for a } simpler solution that encompasses the entire problem space. Oh, I completely left out the management issues that led to this. The project began (years before I got involved) with large chunks of the system being pushed into development before requirements had been written, and the framework was developed concurrently with them. It is only within the last year that the framework has stabilized and the developers have stood their ground on not starting to code without solid requirements. } In general, it really is easier to solve the entire problem than to } solve just bits and pieces. Special conditions (even if they are } embodied in framework side effects) are generally a sign that something } is not understood fully yet. This is true whether it is J2EE, } Rails, .not (sorry - .net), or even lowly COBOL. It would be lovely if a high-level list of desired features for the system were available to developers. If such a thing exists, it certainly isn''t available to us nor to the architect who built the framework. Without knowing what is planned, it''s hard to be abstract in the right places and concrete in the others. I experienced a similar issue in my first real job. I was tasked with building a new simulation and visualization frontend (in C++) for an AI engine. I was not told what future use the frontend might be put to, only that the existing one was too hardcoded. I wound up writing a magnificently abstract MVC system full of clean interfaces that was loosely coupled and automatically registered interface implementations at load time and instantiated objects based on a simple XML file format. It was a thing of beauty. It was also too complicated for the owner of the project to understand (granted, he hadn''t learned how to use any feature of C++ that wasn''t supported by g++ circa 1990), yet too restrictive to make it easy to split the UI and the simulation into separate threads easily. If they''d just talk to us, we could do what they need. But they never do. --Greg } On Thu, 2006-03-30 at 10:17 -0500, Gregory Seidman wrote: } > On Wed, Mar 29, 2006 at 07:35:21PM -0600, David Johnson wrote: } > } On Wed, 2006-03-29 at 15:21 -0700, Giles Bowkett wrote: } > [...] } > } > I''d imagine there are probably lots of overarchitected enterprise apps } > } > that could run on Rails quite happily, though. } > } } > } Overarchitected? I''m not sure what you mean. I have seen poorly } > } architected apps, and apps that solved complex problems, but I have never } > } seen something that I could truly call overarchitected. Could you } > } elaborate? } > [...] } > } > I will give an example of an overarchitected app. This is not a web app, } > but rather a .NET thick client. The names of the various companies involved } > are withheld to protect my butt. Basically, the project is in-house, } > mission-critical software. It is backed by several large databases, and } > performs a variety of data entry, manipulation, cleaning, crunching, and } > reporting functions. } > } > The basis of this application is the almighty framework. In this } > application, there are persisted objects which are all represented in a } > single table with universally relevant information like parent object, plus } > side join tables for specific types. Loading and saving is handled } > automagically by the framework. All such objects exist in memory as an } > instance object which holds onto an ADO.NET typed dataset. } > } > All screens (and partial screens) must be implemented as subclasses of a } > particular framework class, which does framework magic with the persisted } > objects. Screens are actually shown to the user in nested tabs and stacks } > and popups and such based on a database representation of how the pieces } > fit together. For each (partial) screen a user will see, there is an } > automagically-handled persisted object (AHPO from here on) which specifies } > which class to load from which DLL, to what type of AHPO it is conceptually } > attached, its title, etc. Of course, it may be a container screen for other } > screens, in which case it has no DLL or class itself, just child screens. } > And you can have another variant that just points to a screen but with } > slight changes. All this information about screens makes it possible for } > many controls, based on their names, to automagically bind to the } > appropriate data value. } > } > Constants are held in the database as well. There are these items with a } > unique number, a short name, a longer name, an ordering value, and several } > additional fields for extra information. They belong to some primary group } > of items, but they can belong to more than one group. In the additional } > groups, the long name (but nothing else) can be overridden. These are used } > for various automagical dropdowns. } > } > When first working with this framework, it seemed like it took care of a } > whole lot of stuff for you, and the idea of separating out as much } > functionality as data rather than code was appealing. Eventually, though, } > it becomes clear that the app spends so much time on framework magic that } > actual user interaction suffers. The system is painfully slow. It must be } > deployed on terminal services so that the system running the app can be on } > a gigabit link to the database server because so much data has to be read } > by the app to accomplish anything, and so much data gets persisted when the } > user does anything. } > } > This is what it means to be overarchitected. The system is full of } > beautiful design ideals, but doesn''t actually get the job done well. Their } > may be development and maintenance gains, but they are hidden by the } > development costs (new developers require months of ramp-up time, which can } > also lead to staffing problems) and the cost of lost user productivity as } > the users wait for the system to respond. } > } > --Greg } > } > _______________________________________________ } > Rails mailing list } > Rails@lists.rubyonrails.org } > http://lists.rubyonrails.org/mailman/listinfo/rails } }
Stephen Bannasch
2006-Mar-31 16:29 UTC
[Rails] how can action=>render add a ".jnlp" suffix?
I found an answer (Piers Cawley helped). Most of you probably already know this but just in case someone is reading or searching the list archive and would like to know: The routes in config/routes.rb are TWO-WAY, mapping incoming url requests AND used as the template to generate urls by the app. Of course now looking back it is obvious that it has to work that way. Adding this to the routes.rb map: map.jnlp ''page/jnlp/:id/activity.jnlp'', :controller => ''page'', :action => ''jnlp'' Not only handles parsing this incoming url: http://localhost:3000/page/jnlp/1/activity.jnlp But the map also is used when interpreting this code in a PageController view to produce the same url: link_to ''Run'', :action => ''jnlp'', :id => activity What I''d like to do now is figure out how to combine the :id number and the static text ''activity.jnlp'' so that the url can end in: /activity1.jnlp This doesn''t work, it is not parsed correctly: map.jnlp ''page/jnlp/activity'' + :id + ''.jnlp'', :controller => ''page'', :action => ''jnlp'' And this doesn''t work: map.jnlp "page/jnlp/:id/activity#{:id}.jnlp", :controller => ''page'', :action => ''jnlp'' It produces: http://localhost:3000/page/jnlp/2/activityid.jnlp I find it interesting reflecting on my process trying to figure this out. I tried to follow the url_for code in the rails source but I knew I was missing something. One part was getting my head around all the meta-programming used in Ruby and Rails and the other was the fact that as implemented in Rails, routes affect both halves of the url process. -- - Stephen Bannasch Concord Consortium, http://www.concord.org
have you tried just setting the Content-Disposition header? headers["Content-Disposition"] = "attachment; filename=''activity#{params[:id]}.jnlp''" if you still want to go the routes way link_to "Run", :action => :jnlp", :id => @activity_id, :filename => " activity#{@activity_id}.jnlp" then in your route map.connect "page/jnlp/:id/:filename", :controller => "page", :action => "jnlp", :requirements => { :id => /\d+/, :filename => /activity[\d+]\.jnlp/ } this should result in the URL: http://yourapp/page/jnlp/1/activity1.jnlp that route is just off the top of my head, but should be close to correct. Chris On 3/31/06, Stephen Bannasch <stephen.bannasch@gmail.com> wrote:> > I found an answer (Piers Cawley helped). > > Most of you probably already know this but just in case someone is > reading or searching the list archive and would like to know: > > The routes in config/routes.rb are TWO-WAY, mapping incoming url > requests AND used as the template to generate urls by the app. Of > course now looking back it is obvious that it has to work that way. > > Adding this to the routes.rb map: > > map.jnlp ''page/jnlp/:id/activity.jnlp'', :controller => ''page'', > :action => ''jnlp'' > > Not only handles parsing this incoming url: > > http://localhost:3000/page/jnlp/1/activity.jnlp > > But the map also is used when interpreting this code in a > PageController view to produce the same url: > > link_to ''Run'', :action => ''jnlp'', :id => activity > > What I''d like to do now is figure out how to combine the :id number > and the static text ''activity.jnlp'' so that the url can end in: > > /activity1.jnlp > > This doesn''t work, it is not parsed correctly: > > map.jnlp ''page/jnlp/activity'' + :id + ''.jnlp'', :controller => > ''page'', :action => ''jnlp'' > > And this doesn''t work: > > map.jnlp "page/jnlp/:id/activity#{:id}.jnlp", :controller => > ''page'', :action => ''jnlp'' > > It produces: > > http://localhost:3000/page/jnlp/2/activityid.jnlp > > I find it interesting reflecting on my process trying to figure this > out. I tried to follow the url_for code in the rails source but I > knew I was missing something. One part was getting my head around all > the meta-programming used in Ruby and Rails and the other was the > fact that as implemented in Rails, routes affect both halves of the > url process. > > -- > - Stephen Bannasch > Concord Consortium, http://www.concord.org > _______________________________________________ > 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/20060331/48cf4134/attachment.html
On Fri, 2006-03-31 at 08:54 -0500, Gregory Seidman wrote:> } An architecture is a wonderful servant, but a terrible master. > [...] > > ...and I think that is an excellent definition of overarchitecting. > Overarchitecture means that developers spend more time satisfying the > framework''s demands than the system requirements. >I can accept that, with reservations. To me, that still sounds like a failure to understand architecture at all, with a resulting failure to architect. But I can agree to disagree.> } A lot of times, the degree of dynamism you describe is actually a result > } of a failure to understand the problem space fully. That does not mean > } spending a bazillion hours poring over some nimnul''s powerpoint > } presentations. It means recognizing that complex solutions generally > } mean that you don''t understand the problem yet, and striving for a > } simpler solution that encompasses the entire problem space. > > Oh, I completely left out the management issues that led to this. The > project began (years before I got involved) with large chunks of the system > being pushed into development before requirements had been written, and the > framework was developed concurrently with them. It is only within the last > year that the framework has stabilized and the developers have stood their > ground on not starting to code without solid requirements. >Your organization is starting to mature. But, you have to be cautious of the other extreme that leads to capital-M paper Methodologies and endless meetings (sometime with evil Power Point presentations). Instead, get your programmers out doing the work of the people whose jobs they are automating for two weeks, then tell them the problem, and then let them loose to solve it. It''s a novel approach, but it can work.> } In general, it really is easier to solve the entire problem than to > } solve just bits and pieces. Special conditions (even if they are > } embodied in framework side effects) are generally a sign that something > } is not understood fully yet. This is true whether it is J2EE, > } Rails, .not (sorry - .net), or even lowly COBOL. > > It would be lovely if a high-level list of desired features for the system > were available to developers. If such a thing exists, it certainly isn''t > available to us nor to the architect who built the framework. Without > knowing what is planned, it''s hard to be abstract in the right places and > concrete in the others. > > I experienced a similar issue in my first real job. I was tasked with > building a new simulation and visualization frontend (in C++) for an AI > engine. I was not told what future use the frontend might be put to, only > that the existing one was too hardcoded. I wound up writing a magnificently > abstract MVC system full of clean interfaces that was loosely coupled and > automatically registered interface implementations at load time and > instantiated objects based on a simple XML file format. It was a thing of > beauty. It was also too complicated for the owner of the project to > understand (granted, he hadn''t learned how to use any feature of C++ that > wasn''t supported by g++ circa 1990), yet too restrictive to make it easy to > split the UI and the simulation into separate threads easily. > > If they''d just talk to us, we could do what they need. But they never do. >Most of the time, I have found that the end-users don''t really know what they want until they see it. It is our role as a support industry to understand their businesses that we are programming for better than the users do. The turning point for me was when I was the entire IT department (third hat), writing applications in support of my own work (first and second hats). If the programs didn''t work, the senior estimator (me) went to have a hear to heart with the IT manager (me) and we made things work. It didn''t matter that the user (me) didn''t tell the programmer (me) up front what he wanted. What mattered was that in transacting business we had discovered a weakness in the tools we had made that was costing us money, and we fixed the tool to meet our needs. Apart from multiple personality issues, that experience changed how I view and construct software. I became much better at anticipating business requirements in general, and much more understanding that the business requirements are often fluid. I began building my programs to offer options and guidelines instead of rigid rules, and in the process discovered that I was writing less code that was both simpler and more effective at meeting the business needs. I wish you good luck in untangling your product. Been there, done that. There is a light at the end of the tunnel, and it might not be a train. David Johnson
Stephen Bannasch
2006-Apr-01 05:54 UTC
[Rails] how can action=>render add a ".jnlp" suffix?
Thanks for the great suggestion Chris. Setting the ''Content-Disposition'' in the headers worked like a charm. I haven''t tried your route suggestion but thinking about how it should work is helping me to better understand routing. At 11:53 AM -0500 3/31/06, Chris Hall wrote:>have you tried just setting the Content-Disposition header? > >headers["Content-Disposition"] = "attachment; >filename=''activity#{params[:id]}.jnlp''" > >if you still want to go the routes way > >link_to "Run", :action => :jnlp", :id => @activity_id, :filename => >"activity#{@activity_id}.jnlp" > >then in your route > >map.connect "page/jnlp/:id/:filename", :controller => "page", >:action => "jnlp", :requirements => { :id => /\d+/, :filename => >/activity[\d+]\.jnlp/ } > >this should result in the URL: ><http://yourapp/page/jnlp/1/activity1.jnlp>http://yourapp/page/jnlp/1/activity1.jnlp > >that route is just off the top of my head, but should be close to correct. > >Chris-- - Stephen Bannasch Concord Consortium, http://www.concord.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060401/2ceb3053/attachment.html