Re: an unusual [job request] + taking mod_perl to the commercial world

2001-04-27 Thread Michael Lazzaro

At 12:00 PM 4/27/01 -0400, JR Mayberry wrote:
>there will be more dreams jobs like you described.. simple fact is, I
>couldn't name more then 3 companies in my area who use it, and I never
>expect to do work with it again.

... on the other hand, even as recently as one year ago, it was almost 
impossible for our company (in southern california) to find mod_perl 
programmers.  Our last few job searches, tho, we've been able to find a 
*very* good supply of applicants with mod_perl experience... it's no longer 
been an issue.  (Most mod_perl applicants seem to have come by their 
experience from working on college campuses, BTW... which is another 
interesting -- and valuable -- change.  Not the fact that schools use it, 
but the _volume_ of applicants who are now learning it there.)

So I don't know how exactly it's happened, but mod_perl "knowledge" seems 
to have skyrocketed recently, and at least to my mind it's given mod_perl a 
viability that it didn't have recently.  A year ago, we were even talking 
seriously about moving our development to Java, simply because we could 
find a lot more Java programmers than Perl programmers, but that tide is 
definitely turned... we're no longer even considering switching, we have no 
trouble finding people, and I'm finding investors and corporate officers a 
*lot* more willing to consider the development and use of open-source tools 
in general as being a very valid and credible business decision.  The use 
of Apache and mod_perl has made me look very, very smart lately. ;-)

I think the key is going to be Perl 6.  If it improves the areas they think 
it will, and if Apache / mod_perl 2.x are themselves the improvements we 
expect them to be, we may all be pleasantly surprised by a major growth in 
usage.  The market downturn has given people who use open source tools -- 
Perl, Apache, mySQL, postgreSQL, Linux, etc... a major credibility boost, 
at least in my own circles -- I think we *might* be in for a pleasant 
surprise in 1-2 years.  :-/

MikeL




[BUG?] CGI::Cookie->parse() deletes $r->content()

2001-04-04 Thread Michael Lazzaro


I'm looking to see if anyone can verify whether the following behavior is a 
Feature or a Bug.  From within a PerlRequestHandler:

my $content = $r->content();
my $cookie = CGI::Cookie->parse( $r->headers_in->get('Cookie') );

works fine, but the reversed code:

my $cookie = CGI::Cookie->parse( $r->headers_in->get('Cookie') );
my $content = $r->content();

... sets $content to undef.  I'm aware you can only call $r->content() 
once; but it seems odd that Cookie->parse would squish it too.(?)  Note 
that this code:

my $cookie = $r->headers_in->get('Cookie');
my $content = $r->content();
my $cookie_parsed = CGI::Cookie->parse( $cookie );

... is OK, implying it's the ->parse() that's undef'ing $content, not the 
call to headers_in().

-- using
(Apache/1.3.19 (Unix) mod_perl/1.25 Perl5.6.0 CGI::Cookie/1.12) undef Red 
Hat i686-linux:
-- the behavior doesn't happen on similarly configured older system,
(Apache/1.3.12 mod_perl/1.24 Perl5.005_03 CGI::Cookie/1.06))

Anyone else see this / can verify?

MikeL