Or perhaps better yet I should rephrase the title above and instead write: Is agile development conducive to Perl?

For the last ten years or so there's been a big rage about the benefits of agile software development and how much better this methodology is compared to good old Waterfall or RUP or Ruby on Rails or whatever.

I would like to claim that Perl is just as good if not better than any other programming language when it comes to going agile. I've used it often enough and it has resulted in successful products hitting deadlines and bringing in big bucks. Who ever told us that early-to-market is an impossible task?

Perhaps Perl is not ideal, but it's flexible enough. Perl fosters creativity in such a way as to bring about visible results very quickly. There are many ways of doing things, and these alternative can be compared, the good with the not so good and even the bad with the outright bad, when choosing the most viable direction to take. Perl means moving forward not backwards.

Is speed the most important? Sure. Should we keep quality in mind? Yes, of course. Is there enough time to test? You better or else. Should we demo even though it's not quite ready. Yes and yes.

Let's have a look at Scrum which is one way of being agile. Since I've had more experience there, I feel more comfortable discussing it in light of the Perl programming language.

Scrum's success is based on a number of important concepts including the following:

• Describe requirements as user stories
• Prioritize tasks by business value
• Commit to short-term goals and go for it
• Allow the team to do anything to accomplish the goal
• Do not disturb development during each cycle
• Develop quickly and pragmatically

• Take part in daily stand-up meetings
• Measure speed by iterative development cycles
• Empower the development team to make any and all decisions
• Embrace change because it will happen
• Review and improve
• Foster bleeding-edge technology that might break things
• Accept delays as part of life and make them public
• Tackle risks early and do not fear failure
• Verify, rework and move forward
• Be proud of what you create
• Have a fun and relaxing time getting things done

I could go on and on explaining the fine art of doing Scrum within the wonderful world of Perl, but I believe I've said enough for the time being.

Hopefully my short discussion here has tickled enough people out there to make them think and reflect upon their own experiences. Enough so at least that they are inspired to leave comments of all kinds, foster even more discussion, defending and/or judging good old Perl as a agile way of doing things (or not).

So is Perl really conducive to agile development? I think so.

Looks like we've got some ideal golfing weather ahead, and I'm definitely going to take advantage of this fantastic stroke of luck.

Here's my golfing schedule: tomorrow early shotgun with the oldies, Friday afternoon practice round by myself, Saturday morning 1st round club stroke play championship, Saturday afternoon golf lessons, and Sunday if I qualify 2nd round club play championship.

The clubs have been cleaned and polished and I'm ready to have a fun and relaxing time.

I cannot believe that she died today.

As a teenager I had the biggest crush on her and that poster of her in that skin-tight red swimming suit was an all time classic that's for sure.

Well, if it means anything to you now, thanks alot for all of the pleasure you brought me while I was growing up and trying to make sense of the world as a crazed young man in need of direction.

Recently I've been setting up an extensive test harness suite for a web-based application running on the Catalyst Web Framework for Perl.

In addition to the popular Test::MoreCPAN module, many of the tests make use of the CPAN module Test::WWW::Mechanize::Catalyst where I run automated scripts to access various pages, fill in fields with various values, submit forms and check for success or failure.

One of the tests involves creating a new user account that generates a notification email which is sent to the new user. Within the message text there is a verification link. The idea is that upon receiving this email, the user will click on this link and be redirected back to the application to a welcome page. This welcome page verifies that registration has been completed successfully. The user is invited to login in by submitting a form with the username and password pre-filled.

The problem is that I do not want to be generating all kinds of external emails into the big bad world for these tests. Besides, how can I use automated scripts when they depend on external events like users having to click on links in emails wherever they might be?

So here's the trick. First of all I redefine the Email::Send::send() method so that I can hook into it thereby mocking it's behavior. This redefined method is used to scrape out the embedded validation link we must click on in order to finish the registration process.

our $email_mime_ref;
{
    no warnings qw/once redefine/;
    *Email::Send::send = sub {
        my ($self, $message, @args) = @_;
        $main::email_mime_ref = $message; return 1; };
}

Note that we use no warnings qw/once redefine/ in order to disable the warning messages for redefining the method and only using it once.

Whenever Email::Send::send() is called, we copy the message for later use. Note that since we are in the namespace of Email::Send when this is called, we need to make sure that the message is copied back into the namespace of where we are calling from, namely $main::*:

$main::email_mime_ref = $message;

$mech->submit_form(
    form_number => 0,
    fields => $fields,
    button => 'submit' );

my @uris;
my $finder = URI::Find->new( sub { push @uris, shift; } );
$finder->find(\$email_mime_ref->body_raw);

$mech->get_ok($uris[0], "Click on URI '$uris[0]'");
$mech->content_contains("Welcome " . lc($username) . 
    ", your email has been validated. Please log in.");