use Perl

I just received this email, addressed to me personally:

To: Geoffrey Young
Subject: mod_perl2 API change

Thank you very much for your API change. What you were thinking about when doing this? Maybe your ass?

Everything is broken now....
:((((

nice.

I was fortunate enough to have two of my talks chosen for YAPC::NA 2005.

Writing Tests with Apache-Test, Part II:

At last year's YAPC, between the beer and buffalo wings, you got to know the basics of Apache-Test. Now, it's time to get familiar with what really makes it a really valuable testing platform. Apache-Test allows you to run tests directly within the mod_perl runtime environment, providing the ability to exercise server-side APIs in a way no other testing framework can. If mod_perl is your thing, you absolutely need to check this out.

A Few Cool Things About mod_perl 2.0:

mod_perl 2.0 is certainly a lot to digest. But hidden deep in the recesses of this new release are lots of features that you won't find at the forefront of the typical "why mod_perl 2.0" discussion but which are super cool. Oh, and they are important to your migration strategy too. This talk will outline a few of the important but lesser known features of mod_perl 2.0 that will get you thinking in new directions as you migrate away from mod_perl 1.0.

unfortunately, the talk that I most wanted to do (Testing PHP with Perl with Chris Shiflett) wasn't selected. the talk met with a similar fate at PHP Quebec, which I gather is much like YAPC in its audience and expectations. I guess neither side has much of an interest in the other, at least not in the testing arena, which I find odd since it seems like the more people I talk to from either side the more they are willing to admit there is some degree of crossover in both directions. oh, well.

mod_perl 2.0.0-RC5, the next step toward an official "this is mod_perl 2.0" was announced and uploaded to CPAN today.

if you plan on migrating to this latest release, please take the time to read this document, which outlines very, very important changes between this version of mod_perl and all prior 2.0-branch releases

  http://perl.apache.org/docs/2.0/rename.html

this was a particularly stressful release for everyone, and I know a few people approached burnout-levels because of it. but hopefully mod_perl, and the rest of the perl community, is better off because of it.

at any rate, enjoy!

like many here in our little perl world, I'm getting into digital photography as an official hobby (or back into photography, depending on how you look at it). despite all the resources out there with pictures to look at (and there are tons) I have yet to find a decent community to discuss photography the way I want to discuss it. not that there aren't lots of places, but they all seem to use the old bbs-type mode of communication, being web-based forums using a terrible interface with horrid colors. I like mailing lists.

anyway, I know there are enough people here and around perl that are into photography - is there any interest in photo@perl.org or somesuch?

ORA put out digital photography hacks last year so we can kinda tie it into perl. and I spent way too much time getting set up in an all open source world, writing shell and perl scripts and figuring out life without photoshop, etc, so that might be a tie in too.

UPDATE: you might find this all confusing if you haven't heard about our Apache-Test efforts yet and how it joins PHP and Perl together in the testing world. take a look at the talk Chris and I gave at ApacheCon 2004:

• Testing PHP with Perl slides - http://xrl.us/phpperl
• Testing PHP with Perl demo - http://xrl.us/phpperlcode
• README from the demo, which has lots of details - http://xrl.us/phpperlREADME

now, back to the blog...

today I added the ability to run client-side PHP scripts to Apache-Test. so, now you can have

  t/foo.t
  t/bar.php
  t/response/TestPHP/baz.php

all within the same t/ directory.

the perl script t/foo.t will run using perl, just like always. t/bar.php will run using the php command-line interpreter, while t/response/TestPHP/baz.php will run via PHP within the Apache runtime (through standard Apache-Test magic). and all are executed with a simple make test and tabulated on the command line like you would expect.

furthermore, the test-more.php that Apache-Test generates can be automatically found from the client-side tests as well. so, here is what a sample t/foo.php looks like:

<?php
  require "test-more.php";

  plan(1);

  diag("this is a php test");

  is('php', 'perl', "something php passed");
?>

look familiar? so does the output...

$ make test TEST_VERBOSE=1
/perl/perl-5.8.6/bin/perl -Iblib/arch -Iblib/lib \
t/TEST  -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \
/perl/perl-5.8.6/bin/perl -Iblib/arch -Iblib/lib \
t/TEST  -bugreport -verbose=1 t/foo.php t/foo.t
/usr/local/apache/bin/httpd  -d /src/devel/perl-php-test/t -f /src/devel/perl-php-test/t/conf/httpd.conf -D APACHE1 -D PERL_USEITHREADS
using Apache/1.3.32

waiting 60 seconds for server to start: ..
waiting 60 seconds for server to start: ok (waited 1 secs)
server localhost.localdomain:8529 started
t/foo....1..1
# this is a php test
not ok 1 - something php passed
#     Failed test (t/foo.php at line 9)
#          got: 'php'
#     expected: 'perl'
# Looks like you failed 1 tests of 1.
FAILED test 1
        Failed 1/1 tests, 0.00% okay
t/foo....1..1
# this is a perl test
not ok 1 - something perl passed

#     Failed test (t/foo.t at line 7)
#          got: 'php'
#     expected: 'perl'
# Looks like you failed 1 test of 1.
dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
        Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------ -------
t/foo.t        1   256     1    1 100.00%  1
t/foo.php                  1    1 100.00%  1
Failed 2/2 test scripts, 0.00% okay. 2/2 subtests failed, 0.00% okay.

hard to tell which is Test::More and which is test-more.php isn't it?

I find it interesting that in a very large testing framework here at work we use a mixture of *.t tests that have nothing to do with mod_perl or Apache, yet we just let Apache-Test run everything for convenience. now, PHP users can do the same - code PHP clients to talk to their PHP web app using Test::More syntax, or just use Apache-Test as the engine for their CLI scripts:

$ t/TEST -no-httpd t/foo.php  -v
[warning] skipping httpd configuration
t/foo....1..1
# this is a php test
not ok 1 - something php passed
#     Failed test (t/foo.php at line 5)
#          got: 'php'
#     expected: 'perl'
# Looks like you failed 1 tests of 1.
FAILED test 1
        Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------ -------
t/foo.php                  1    1 100.00%  1
Failed 1/1 test scripts, 0.00% okay. 1/1 subtests failed, 0.00% okay.

because everyone with 3 kids needs a picture taking machine, I got a new Nikon D70 last week. so far, I've been pretty pleased with it, but because the camera is so complex I found that I needed to hunt around for useful information to get going.

anyway, I've wanted to throw some notes together on some of the linux-oriented things I've done since I started shooting digital, as well as a collection of notes on the D70. nothing major or revolutionary (I'm mainly posting here so google picks it up :) but if it helps someone...

http://www.crushedredpepper.com/nikon/

just for kicks I created a new irc channel on irc.perl.org: #perl-php. I guess my intent was to provide a forum for folks interested in trying out the Apache-Test hooks for testing PHP that Chris and I have been working on. of course, like all things on irc, I suspect there will be lots of diversions as well, but just in case people need some hand-holding getting started, I'll be around there to help.

stop on by.

one of the most interesting talks I heard at ApacheCon was Michael Radwin's HTTP Caching and Cache-busting for Content Publishers. In that talk he presented an (ingeniously simple) Apache C extension module called mod_images_never_expire.c.

I took that module, added some basic tests, and wrapped it up in an Apache-Test-based tarball, mod_images_never_expire-example.tar.gz .

in the below output, notice how mod_images_never_expire.c is compile and tested in a single command, all without invoking perl explicitly. make would simply compile the module, and sudo make install would install and activate the module for the specified Apache.

$ tar zxvf mod_images_never_expire-example.tar.gz
$ cd mod_images_never_expire-example/

$ export APACHE_TEST_APXS=/usr/local/apache/bin/apxs
$ make test
perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for mod_images_never_expire
make[1]: Entering directory `/src/mod_images_never_expire-example'
make[1]: Nothing to be done for `makefile'.
make[1]: Leaving directory `/src/mod_images_never_expire-example'
make[1]: Entering directory `/src/mod_images_never_expire-example'
/perl/perl-5.8.5/bin/perl -Iblib/arch -Iblib/lib \
t/TEST  -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS=/usr/local/apache/bin/apxs \
/perl/perl-5.8.5/bin/perl -Iblib/arch -Iblib/lib \
t/TEST  -bugreport -verbose=0
make[2]: Entering directory `/src/mod_images_never_expire-example/c-modules'
cd images_never_expire && make mod_images_never_expire.so
make[3]: Entering directory `/src/mod_images_never_expire-example/c-modules/images_never_expire'
/usr/local /apache/bin/apxs -D APACHE1 -I/src/mod_images_never_expire-example/c-modules -c mod_images_never_expire.c
gcc -DLINUX=22 -DHAVE_SET_DUMPABLE -I/usr/include/gdbm -DUSE_HSREGEX -fpic -DSHARED_MODULE -I/usr/local/apache/include -I/src/mod_images_never_expire-example/c-modules -DAPACHE1  -c mod_images_never_expire.c
gcc -shared -o mod_images_never_expire.so mod_images_never_expire.o
make[3]: Leaving directory `/src/mod_images_never_expire-example/c-modules/images_never_expire'
make[2]: Leaving directory `/src/mod_images_never_expire-example/c-modules'
/usr/local/apache/bin/httpd  -d /src/mod_images_never_expire-example/t -f /src/mod_images_never_expire-example/t/conf/httpd.conf -D APACHE1 -D PERL_USEITHREADS
using Apache/1.3.32

waiting 60 seconds for server to start: ...
waiting 60 seconds for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
t/01image.......ok
t/02nonimage....ok
All tests successful.
Files=2, Tests=24,  1 wallclock secs ( 1.35 cusr +  0.07 csys =  1.42 CPU)
[warning] server localhost.localdomain:8529 shutdown
make[1]: Leaving directory `/src/mod_images_never_expire-example'

As usual, ApacheCon was a blast this year. I wish I had the time to do a proper write up today, but I probably won't get around to it - I had too many great talks with too many great people to do it justice anyway.

for those that are interested in the presentation materials from my talks, here they are.

  Test-Driven Apache Module Development: slides and code

  mod_perl 2.0 at Warp Speed: slides

  Testing PHP with Perl (with Chris Shiflett): slides and code

many thanks to the folks who came to the talks and gave us such great feedback.

I released Apache-SSLLookup to CPAN yesterday, which was created to address the issues mentioned in this mod_perl discussion thread.

while the module is only really useful for interacting with mod_ssl, the code itself is actually a nice, simple example of a few new mod_perl 2.0 concepts.

it is written entirely in XS (except for the Dynaloader bootstrapping, of course). that it uses XS at all means that the Makefile.PL is a good example of how mod_perl 2.0 makes it very easy to generate a Makefile that can find what it needs on all platforms. in mod_perl 1.0 you needed a Makefile.PL like this to work on Win32. there's also a cool little Apache-Test feature in use there, which shows up only if a test fails.

speaking of tests, if you want to use Apache-Test to test SSL things then you will need to generate server-side certificates for mod_ssl to use. I haven't generated certificates in ages, but fortunately I didn't need to figure it out again - simply creating the directory t/conf/ssl is enough to have Apache-Test automagically generate a handful of certificates for you. see the ssl.conf.in for an example of putting these to use so you can issue https requests in your tests.

I also had a bit of fun in that the class is a proper subclass of Apache::RequestRec, but the constructor is written entirely in XS as well. so, the module shows you what you need to do to emulate

our @ISA = qw(Apache::RequestRec);

sub new {
  my ($class, $r) = @_;

  return bless { _r => $r }, $class;
}

in XS.

lastly, it illustrates how to interact with Apache's new optional function hooks, which is a pretty cool thing if you happen to need to do that.

anyway, enjoy.