Perl Success Story - Managing PHP apps with Perl

WebPub helps install and manage popular web apps. We currently are doing WordPress, Drupal, MODX and phpBB. While the web UI is in PHP (decided before I came onboard) the backend is all Perl.

Some of the major components being used are: Mojolicious, Moose, DBIx::Class and Gearman.
Mojolicious provides the REST interface for the PHP front end and will be used in the near future by at least one other company we are working with. That company will write their client in Ruby.
Moose is used heavily for meta method creation, mapping various before / after 'method' to validation and DB update_or_create and the installer system loads the appropriate role (each app has its own role for things that are app specific - an install of Drupal needs more fixup than WP) at runtime.
DBIx::Class - no explaination needed
Gearman - actual interaction with remote systems happens from workers.

YAPC::NA 2012 donate ticket

I will not be using my badge to the conference. Is there a place where I can put this in a 'needs' pot? To be used by someone who can make the conference, thanks.

Asynchronous HTTP Requests Using Mojolicious

This is in response to this article, Asynchronous HTTP Requests in Perl Using AnyEvent - linked to from Perl Weekly. Particularly, this quote:
BTW, if you’re a Perl programmer and you’ve been jealous of all the cool kids and node.js, AnyEvent is how you do node.js-style programming in Perl.

UPDATE: this is a better example.
="http://https://gist.github.com/0dbc43…

How not to use Moose

Maybe this is legitimate and I just don't know why, but I have seen the following in a couple of projects where I have taken over after the original programmer left:

use Moose;

has [qw/foo bar baz/], is => 'rw';

no Moose;

sub something {}
sub somethingelse {}

OK, I collapsed the attrib declaration into one line for brevity. I will say that from the code, I can tell you these are not Perl programmers, they are old time C programmers with CS degrees who convinced someone they knew what they were doing because the…

Archive::Tar::Wrapper vs. Archive::Tar

If you don't know it, Archive::Tar is SLOW; it even says so. Running NYTProf recently on a project revealed that the major part of the program was taking a little more than 27 seconds to run and a little over 24 seconds of this was Archive::Tar reading the archive into memory. Since I did not need the in memory feature, I switched to Archive::Tar::Wrapper. That sub now takes about 2.5 seconds to run and the equivalent portion to Archive::Tar->new($file); is now Archive::Tar::Wrapper->new; $arch->read($file); now takes 631 ms.