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 P. [email protected] wrote:
However, that seems to be returning Time.now. Any suggestions?
-----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
On Wed, 2006-03-29 at 03:01 +0000, Jon Gretar B. 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.
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 W. wrote:
The idea, btw, that Java programmers/programs are inherently better at
about the maturity of the platform for use in large scale
> On Mar 28, 2006, at 5:41 PM, David J. wrote:
> Ruby lacked support for regular expressions, instance variables,
> "The computer allows you to make mistakes
Rails mailing list
–
Sau S.
http://www.saush.com
http://read.saush.com
http://jaccal.sourceforge.net
On Wed, 2006-03-29 at 11:24 +0800, Chang Sau S. 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’ 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).
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.
On Tue, 2006-03-28 at 21:25 -0500, Larry W. 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 J. 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 P.
[email protected]
“The key to performance is elegance, not
battalions of special cases.”
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 H.
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 Tue, 2006-03-28 at 21:59 -0600, Jason P. 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.
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 Mar 28, 2006, at 10:56 PM, David J. wrote:
On Tue, 2006-03-28 at 21:59 -0600, Jason P. 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 P.
[email protected]
“The key to performance is elegance, not
battalions of special cases.”
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 J.
On Tue, 2006-03-28 at 23:00 -0500, Jeremy H. wrote:
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.
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.
What are you talking about? Ruby already runs in a virtual machine:
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
Ben M. wrote:
What are you talking about? Ruby already runs in a virtual machine:
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.
regards
Justin
Il giorno 29/mar/06, alle ore 05:05, David J. 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 C.
Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Evil or Not?: http://evilornot.info/
Company: http://www.sourcesense.com/
David J. wrote:
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.
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
–
Sau S.
http://www.saush.com
http://read.saush.com
http://jaccal.sourceforge.net
David J. 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.
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. [email protected] wrote:
programming.
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
On Wed, Mar 29, 2006 at 02:25:07PM +0000, Jon Gretar B. 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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs