Monday, June 29, 2009

July LA Perl Mongers Meeting.

Next LA perl mongers meeting: Thursday, July 16, 2009.

Open call for presenters:

What have you done recently with Perl? Come tell your friends and lets all learn together.

What: LA Perl Mongers Meeting
When: 7-9pm
Date: Thu, July 17, 2009
Where: The Rubicon Project HQ - 1925 S. Bundy, 90025
Theme: Perl!
Food: Pizza and beverages provided.
RSVP: Responses appreciated.

June Perl Mongers recap

"Thank you!" to all who came out to the June meeting. We had nearly 20 people and two excellent presentations.

David's talk challenged the common belief that "Perl is Slow" and sparked an excellent discussion that ranged from data models, snowflake schemas and pure perl olap cubes and off to Bloom filters, scaling horizontally vs vertically, hadoop/hbase and onwards. To paraphrase: Make it as simple as possible (elegance) and think about every speed consideration (diligence).

Matt's presentation was packed as he demonstrated the technologies and ideas behind his latest project. We got to see a lot of live code and patterns in action. Touching on Moose, MooseX::Storage, KiokuDB, Coro, Continuity, Mason, JSON, AnyEvent, Moose::Object::Pluggable, Process, HTML::Seamstress, HTML::Tree, HTML::Element, Net::Server, IPC::Cmd, jquery and Joose. Then gluing it all together and testing it. Here's the pdf cheatsheet from his talk.

In between speakers we continued the discussion while we munched pizza and raided the beer fridge. We had a fun cross section of people, those who signed in to show support: Gray, HSiegel, Jordan, David, David, Matt, Allen and others). Eric and his coworkers from Campus Explorer even drove to Santa Monica on their work-from-home-Wednesday. Rubicon Project, thanks for the support, location, food and vibe.

Can't wait to see you all in July.

Friday, June 19, 2009

Using Apache::Test with Test::Class

I've recently switched from simple Test::More scripts to trying Test::Class. I'm also revisiting some apache module testing with Apache::Test and friends. Today I tried to merge the two.

With Test::Class, you make a test runner script that imports modules and then executes tests. The tests are defined in modules, and then run in module import order by the Test::Class test harness. Test::Class has some nice convenience methods and sugar. You defined test subroutines by adding :Test(n) where n is the number of tests run in the method. Methods can be tagged to run at the start and finish of each test as well as at startup and shutdown, and you get a handy $self object passed around to the methods that you can use to store configuration and etc.

With Apache::TestRun, the standard boiler plate is to create a script which isa Apache::Test and calls __PACKAGE__->run_tests, which then runs all the .t tests in the directory.

To get them working together, I've created two wrappers. uses Apache::TestRun and then I have a test_wrapper.t which uses Test::Class and loads my tests where are defined in modules.

As I get this smoothed out a bit, I'll update. I've been planning to write a talk on "Using Apache::Test to test Apache modules" talk to have handy in case I need something for perl mongers or similar. I think adding Test::Class to the mix will nicely improve the signal-to-noise, assuming I can get it worked out in a non-cludgey manner.


use strict;
use warnings FATAL => 'all';

use FindBin;
use lib "$FindBin::Bin";

package My::TestRun;
use base 'Apache::TestRun';
use Apache::TestConfig;

Monday, June 15, 2009


Here's a quick example of Smart::Comments. I originally planned to have a Getopt::Long flag to turn smart comments on-and-off, but that doesn't work due to the way Smart::Comments uses filters and where that happens in the compile&run cycle.

This example code still serves as a nice boilerplate for Getopt::Long and Pod::Usage.

The following script shows debugging behavior if the environment variable Smart_Comments is set to a 1.

Ex: Smart_Comments=1 ./
### Base Smart Comments - Show variables
### $help: 0
### $man: 0
### $DEBUG: 0

### @array: [
###           1,
###           2,
###           3,
###           4,
###           5,
###           6,
###           7,
###           8,
###           9,
###           10
###         ]
Debug output of variables is neat and worth the price of admission. "### $help" in the code turns into "### $help: help_value" during output. Arrays get dumped via Dumper. And all of this code output is on STDERR and prefixed with three hashes -- so it'll get ignored by the Test Any Protocol if it gets triggered by your unit tests.

Add to that cute progress bars that are only around when people want them? Sweet.

It sure would be nice to have an explicit flag to set/unset the smart comment level, but I don't think that's possible the way it smart comments is implemented as a filter.

Fun for personal code and scripts, but I don't think I'd use it in production, without looking a bit closer under the hood to see what (if any) affect it has when used with -ENV and with the ENV variable not set.


use strict;

use warnings;

use Getopt::Long;
use Pod::Usage;
use Smart::Comments -ENV;

my $help  = 0;
my $man   = 0;

my $DEBUG = 0;

my $result = GetOptions(
 'help|?' => \$help,
 'man'    => \$man,
 'debug'  => \$DEBUG,
pod2usage(1) if ( $help or !$result );
pod2usage( -exitstatus => 0, -verbose => 2 ) if $man;

my $quiet = $ENV{Smart_Comments} ? 0 : 1;

#### Base Smart Comments - Show variables
### $help
### $man
### $DEBUG
my @array = ( 1 .. 10 );
### @array

print "Now running 4 runs through the slow loop\n" if $quiet;

#### <now> Slow Array 1 at <line>...
for my $num (@array) {    ### Slow array1...       done
 ### $num
 sleep 1 if $num % 4;

#### <now> Slow Array 2 at <loc>...
for my $num (@array) {    ### Slow array2--->       done
 sleep 1 if $num % 4;

#### <now> Slow Array 3 at <place>...
for my $num (@array) {    ### Slow array3 [===|   ] [%] done
 sleep 1 if $num % 4;

#### <now> Slow Array 4 at <where>...
for my $num (@array)
{                         ### Slow array4===[%]       done
 sleep 1 if $num % 4;
 print "$num\n";


=head1 NAME

smart-comment-example - Using Smart::Comments with Getopt::Long (and Pod::Usage)


smart-comment-sample [options]
  Smart_Comments  Set the environment variable Smart_Comments = 1 to enable comments.

  --help         brief help message
  --man          full documentation
  --DEBUG        increase debug level

=head1 OPTIONS

=over 4

=item B<--help>

Print a brief help message and exit.

=item B<--man>

Print the manual page and exit.

=item B<--DEBUG>

Affect the DEBUG/verbose level



B<This program> will demonstrate smart comments (Smart::Comments) as well as
boilerplate for setting up Getopt::Long with Pod::Usage


organizing: less fun than coding.

I finally emailed the Thousand Oaks perl mongers list about the June LA Perl Mongers Meeting. We crossed wires and it didn't get announced at TO.PM last Wednesday.

I just talked with Matt Burns and he assures me his presentation is coming along nicely. Now it is time to follow-up with David about the other presentation.

Maybe after all this organizing I'll get to write some perl?

Saturday, June 6, 2009

June Perl Mongers Meeting.

Hello Los Angeles!
I am pleased to announce a Los Angeles Perl Mongers Meeting:

What: Perl Mongers Meeting
When: 7-9pm
Date: Wed, Jun 17, 2009.
Where: The Rubicon Project HQ - 1925 S. Bundy, 90025
Theme: Perl!
Food: Pizza and Pop provided. Responses appreciated.


  1. Data processing and Numerical Analysis in Perl (David Williams)
  2. Moose and Joose -- Programming is (more) fun again. (Matthew Burns)

About our speakers:
David Williams is a Senior Software Engineer and Researcher at the Rubicon Project, formerly of RAND. He's a mathematician, puzzle solver and perl lover.

Matthew Burns is a Senior Software Engineer at ValueClick / Search123. He has modernized and revitalized the S123 team and product over the past year. He's a magician and great at finding creative ways to plug things together.

About your host:
* Andrew Grangaard is a Senior Software Engineer at the Rubicon Project, and long time Perl Monkey. A Caltech EE, he made the switch from Hardware to Software in 1998 and hasn't looked back.

* The Rubicon Project (
The Rubicon Project is an Advertising Technology Company headquartered in Los Angeles. Their mission is to automate the selling and buying of online advertising.

See you at 7 on the 17th.

View Rubicon Project in a larger map

Thursday, June 4, 2009

Non-stick is the new sticky

Here at Rubicon Project I've heard the complaint "we have to be more sticky!" The fear being that clients can turn us off very easily just by adjusting tags on their sites. Some people think this means they want a higher barrier to exit.

It's time to turn that idea on its head.

Now, it may be that I'm just a F.O.S.S. junkie, but I tend to avoid software that has strong lock in because I know that I'm going to be trapped if it doesn't live up to the hype. So having lowered perceived stickiness will lower the barrier to entry.

Secondly, if I see a product with low barrier-to-exit and yet it is popular and clients renew and stick with it, I know the clients are staying for quality and not due to a technical lock-in. For me, that is the real stickiness.

When I talked to Damian (Hogan) about this last month, he agreed and expanded to say how true stickiness comes from providing a value proposition where it's worth more for clients to stay than to leave.

And when it comes to that kind of stickiness, we are very, very sticky.