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.
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.
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 TEST.pl 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. TEST.pl 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.
#!/usr/bin/perl use strict; use warnings FATAL => 'all'; use FindBin; use lib "$FindBin::Bin"; package My::TestRun; use base 'Apache::TestRun'; use Apache::TestConfig; __PACKAGE__->new->run(@ARGV)
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 ./smart-comments-example.pl ### 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.
#!/usr/bin/perl
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";
}
__END__
=head1 NAME
smart-comment-example - Using Smart::Comments with Getopt::Long (and Pod::Usage)
=head1 SYNOPSIS
smart-comment-sample [options]
Environment
Smart_Comments Set the environment variable Smart_Comments = 1 to enable comments.
Options:
--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
=back
=head1 DESCRIPTION
B<This program> will demonstrate smart comments (Smart::Comments) as well as
boilerplate for setting up Getopt::Long with Pod::Usage
=cut
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?
Speakers:
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 (http://www.rubiconproject.com)
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
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.
