Re: [JOB] Perl Programmer for large-scale Apache/mod_perl development
Dodger wrote: If you're unwilling to let a programmer telecommute, you're still in the dark ages, and I wouldn't want to work for you anyway. I am amazed by the technology companies that think that programming requires physical presence in the 21st century. Yeesh. This is only true if you restrict the definition of programming to the actual process of writing/testing/debugging source code, checking it into your source management repository, etc. It has been my personal experience that alot of the design breakthroughs happen as a direct result of informal conversations in the hallways, around the watercooler, in the smoking area, etc. This sort of dynamic interaction just isn't possible in a telecommute situation. Then there is the question of project management. The amount of personal interaction required for proper project management is an order of magnitude greater than that required for development. It has been my personal experience that telecommuting works best on short-term contracts (3-6 months) when bringing in talent that brings a skillset to the table that's not available in the local market. Given the New York City market, I doubt there are many positions that would meet that criteria. Restricting the job search to the local market also helps to avoid the conflicts that invariably arise when working with folks from very different cultural mindsets. Ian
Re: Apache-DBI
Octavian Rasnita wrote: I need mod_perl under Windows just for testing, so it doesn't need to work very fast. Can I use just the DBI module with mod_perl without using Apache::DBI? Under Windows it would be OK for a while. Hi Teddy, While I haven't run mod_perl + DBI (sans Apache::DBI) on Windows, I have run it under Linux without any issues. From what I understand, Apache::DBI provides certain performance benefits over DBI in much the same manner that mod_perl does over standalone Perl, but isn't required to use DBI in a mod_perl environment. HTH, Ian
Re: APR::Const
Octavian Rasnita wrote: I have seen that the site jenda.krynicky.cz cannot be found. jenda.crynicky.cz is alive and well. However, if you continue to have difficulty accessing the main site, Jenda has set up a US mirror at http://www24.brinkster.com/jenda/index.html. There's another mirror referenced on the main page (http://jenda.mydot.net), but I haven't had any luck accessing it. HTH, Ian
Re: (OT ?) issue with get_remote_host
jonathan vanasco wrote: I was googling for portions of the error string, and diving through the pages of mod_perl cooking and practical_mod_perl -- i saw nothing. Google actually had 4 entries, at most, for most portions of the error string, which I found odd. In addition to using Google to search the web, you can also search through usenet postings by clicking on the ´Groups´ link at the top of the search page. You may get more results that way next time. Ian
Re: Problem on RedHat Enterprise 3.0
Young, Darren wrote: Is there a different way to CPAN the newer version? Perl -MCPAN -e 'install Bundle::Apache' gets the 1.29 stuff. I believe Perl -MCPAN -e 'install Bundle::Apache2' should get you latest version of mod_perl 2.0 (2.0_RC3 as of this writing). Yes, Apache 2.0.46 on RHEL. If I decide to go from source, I'm guessing I need to build a fresh Apache RPM, or at least have the source handy for the mod_perl build. For the mod_perl side, does the tarball include a way to build an RPM or is there somewhere else I should check? You should be able to get source RPM's (AKA SRPM) from the same source that you get your binary RPM's from. These will include, along with the source tarball and any necessary patches, a file with .spec extension (this file will normally end up in /usr/src/redhat/SPECS if you install the SRPM using rpm), which tells rpm how to build the binary RPM. For more information, take a look at http://www.rpm.org HTH, Ian
