blogs.perl.org

Stratopan is a slick new service for hosting custom CPAN-like repositories in the cloud. I've been doing all the development work for Stratopan on my laptop computer. But the other day, I decided to try running it on the Linode server I rent.

So I logged in to the (nearly pristine) server, fired up cpanm to install all the prerequisite modules, and launched the application. Lo and behold, it was broken! Read on to find out how Stratopan actually saved me from hours of debugging pain...

Today I was looking at old automated Perl test based on Test::WWW::Mechanize. It was it testing a complex form. For each of about 10 tests, it loaded the form (with a get_ok() call), and then submitted the form with a variety of input.

Now that we run about 25,000 tests in total in the test suite, I’m always looking for ways to speed up the tests. HTTP calls are relatively slow, so systematic ways to slim them down are attractive.

In this case, I found there was a simple change that I could apply that sped up the particular test by about 28%.

Each time the test was calling get_ok() on the page, it was getting back the same result, which is wasteful. I refactored it like this:

my $base_mech = Test::WWW::Mechanize->new;
$base->get_ok($page_to_test);

Then, everywhere we had a get_ok() call to load the page again, I replaced it with this:

$mech = $base_mech->clone;

Both approaches gave me a Test::WWW::Mechanize object in just the state I desired, but the new approach was must faster.

An alternate approach in a case like that is to submit the form just once to make sure that you’ve got all the form field names correctly matching up with the processing URI that it submits to. After that, instead of “GETing” the form again and calling submit_form_ok(), just call post_ok() to POST directly to the processing run mode with the appropriate values.

Either approach avoids a lot of unnecessary GET requests in your test suite.

For more tips on speeding up your test suites, come to my talk on topic of speeding up test suites in YAPC in June, 2013 in Austin, Texas.

the Chief Ticket Monkey of the Perl Mongers.
24.17 min of video or audio only.

And yet another short status update for the GPW 2014. The official Act-website is now available. You're now able to register and to submit talks.

http://act.yapc.eu/gpw2014/

German version: http://www.perl-community.de/bat/poard/message/167756

I'm at a conference in Portland this week to learn about a web framework called Symfony2 for my $DAYJOB. The Symfony2 stuff is all co-located with DrupalCon 2013 and one of the rooms across the hall from our workshop was for Drupal sprints. The sign in the picture was posted outside - and it makes it super clear that newbies are welcome, and who they should try to find to get going on a task quickly.

This is an idea we need to steal for Perl hackathons.

Been looking at Amazon's Simple Notification Service. Very cool. It is a simple topic/message system where you can:

• create topics
• subscribe to topics
• publish messages to topics

What's really nice is the subscriptions can be based on various protocols. For example, email, SMS (US only so far), HTTP(s).

I'm planning on using this for server monitoring and perhaps some workflow processing.

I'm already using Amazon's SQS (Simple Queue Service) with Proc::Daemon to implement some distributed processing across EC2 instances, but was looking at SNS to solve a different problem. In so doing I came across Amazon::SNS which does the trick, although it is a little long in the tooth and needs some polishing. It needs some additional meat around the sparse documentation and is missing some functionality that would be nice to have.

Anyone know of different interface to SNS that I should be using or should I break out the polish?

CPAN authors should look at the smoke tests for their modules to ensure that they're passing on Perl 5.18. The hash randomization change (and a few others) has bitten many a module that may currently be relying on undefined hash behavior. If you haven't checked your modules recently, you may be in for a surprise.

The problem is significant, especially when compounded by the fact that a single misbehaving module can block many more modules that may depend on it.

As an example (not to finger-point, but just to illustrate): Crypt::DES, Crypt::IDEA, Crypt::Blowfish, and Crypt::Twofish had a single line of XS code that was incompatible with Perl 5.18 (which happened to not be related to hash randomization). As a result, all modules that depended on any of these modules also would fail to install on Perl 5.18. This includes Authen::Passphrase, and Crypt::OpenPGP, as well as dozens of others.

For awhile during Perl 5.17 development Perl 5 Porters were keeping a list of modules they were aware of that had bugs made evident by the hash randomization change. But given that we've been hearing warnings about relying on undefined behavior for years, and in particular warnings about hash randomization for many months, at some point it stops being Perl 5 Porters responsibility to keep track of modules that have bugs.

In many cases, these bugs are in modules' test suites, and not the modules' primary code. But whatever the case, we need to be diligent in ferreting out such problems and resolving them. Having a good portion of CPAN break because of a number of modules relying on undefined behavior is one of those "egg on our face" moments that we need to wipe off and put behind us.

If you know one of your modules has begun failing on Perl 5.18, I encourage you to fix it. If you know of an unmaintained module that has begun failing, follow up with the author, or seek to take over maintenance. Report problems to the RT system. Contribute patches. Let's work together to get this problem resolved as quickly as possible.

Interested in meeting new people at YAPC::NA? Hallway++ means you're never interrupting