Perl: June 2009 Archives

Everyone's got their preferred "stack" of modules + frameworks they like to use for any big project they use. I typically break mine down into a (web) framework, an ORM (or database interaction layer if you don't like ORMs), a templating system, caching, reverse proxy, application server (for instance, FastCGI for web stuff), web server software and version control.

Mine are:

• Framework: Catalyst
• ORM: DBIx::Class
• Templating: Template::Toolkit -
• Caching: memcached
• Reverse proxy: Varnish (caching too)
• Application server: FastCGI
• Web server: nginx
• Version control: git

Those may or may not be grouped together properly, but it's the best i could think of. Being a web developer, mine are all network/web oriented. Let's see yours! Add them to the Wiki Extras for this post, or just comment below!

Last time we took a detailed look at MooseX-Types. In today’s article I want to show you the implications of coercions to global types, why you shouldn’t do it, and how to do it better.

Perl has had Object Oriented features since the release in Perl 5 in 1994. The Perl 5 OO is somewhat of a roll-your-own variety however, in that in classic Perl style, it provides the minimum in-language support required and leaves you to handle the rest.

Perl's roll-your-own OO feature has a major benefit in that there is very little dictated by the language about how you do things. It also has the drawback of being somewhat daunting for the newcomer, but for better or worse, it has become familiar.

Another benefit is that the feature has been free to evolve, and since OO is not dictated by the language some very smart developers have been free to explore ways of doing things that might not otherwise be thought of. Moose is the product of that exploration and is rapidly becoming the de-facto standard for OO in Perl. Today we'll explore the basics of creating and using objects in Moose.

We love Moose.

We love email.

Let's put them together!

The idea:

I'm working on a website where email is going to be used extensively. Like most sites, I'll need registration confirmation, email updates to users, confirm password change, and future things like emailing photos in, etc.

I've used other modules for email and have never really been happy with them. I came upon Email::Stuff recently, and decided to give it a whack. However, I didn't want to have to set it up over and over everywhere it needed to be used. So this is where Moose came in.

While most people in Mooseland are using its core typesystem as if it’s been there all the time. The MooseX-Types extension on the other hand is a bit too much magic without obvious advantages to many people. To some it might seem a lot of work to create yet another module just to put some types in. Others might not see any value in using exports instead of strings. With this article I’ll try to show the why’s, the pro’s and the yay’s of designing type libraries with MooseX-Types.

POE is the incumbent. It's been around forever, it has a ton of extension and support modules, and when people are talking about creating a server of any sort, POE inevitably comes up.

I've done a bit of work with POE. I find it to work pretty well, but it does take some getting used to at first. Until recently I'd never heard of AnyEvent. It seems like an interesting dist, but I only have room in my head to know one Event system well. So the question is, is AnyEvent worth learning instead of POE?

This entry will be short and to the (very cool) point. Thanks to confound (hdp@cpan.org), we now have a version of local::lib that will properly bootstrap regardless of Module::Build issues. The latest version (just uploaded tonight, 2009-05-21) is 1.4.1. Please do give it a try and let me know how it works. Also thanks to confound is the start of the eg/ directory of example code, showing local::lib use in the real world. We also have the beginning of a troubleshooting section, many thanks to pattern on Freenode IRC. local::lib is maturing quite nicely--I'm quite pleased with how well things are going. Please do beat it up and get back to me with any problems you encounter. Thanks!

As I write this, I've been poking at another issue with local::lib. I ran into this issue myself at work. If there's a global CPAN configuration, but no user configuration, and this global configuration specifies paths for CPAN stuff that the user can't write to, local::lib (technically CPAN called by local::lib) goes into an endless loop trying and failing to write to the bad directory to store settings. Presently I'm working at getting it to be smart enough to know to completely disregard those bad settings and instead generate user-local settings. Expect to hear from me again once this is fixed.

Hello everyone. Just a quick note to let you all know that the Catalyzed.org wiki is now online. The content is still somewhat sparse, but we here at Catalyzed are excited.

We have integrated the Wiki into the main website, and now every post can have it's own 'wiki extras' page on the wiki, allowing additional files, code listings, and more in-depth discussion of articles.

In addition to the integration, we have added some general purpose sections and something we feel should have been around for a very long time, wikified cpan module pages. If you have caveats, concerns, or simply want to sing the praises of a particular module, head on over to the CPAN modules section of the Catalyzed Wiki, and speak your piece.

We've also added a code samples section as a drop box for code that you find useful or you think might be helpful to other folks.

We know that there is a lot of Perl wisdom out there and much of it never gets published anywhere because there doesn't seem to be a place for it. We hate to see such a waste, so we've created a special section of the wiki. If you've got something to say or add that doesn't fit anywhere else, or you just aren't sure where to put it or who will care... just drop it in the Junk Drawer. It can stay there forever or until you or someone else can figure out a place for it.

So, now it's your turn... Head on over to the wiki... Add a page or edit an existing one. Share your favorite bit of Perl-fu. Complain loudly about the CPAN module that drives you nuts. Create a page that says 'someone should write about XYZ.' Whatever you think needs to be 'out there' for other Perl folks to read, you can put in the Catalyzed wiki.

No rules, just write.

Here are just some quick helping things that accumulated and I wanted to document:

From my .zshrc

These are some simple shortcuts for common perldoc functions:

alias perlsource='perldoc -m'
alias perlwhere='perldoc -l'

From my .gvimrc

For a long time I hated to have to type the package name after creating a new file from hand. So I hacked up this little function to insert the part below the lib directory as package name.

function! InsertPackageFromFile()
perl << EO_MAP
    my ($row, $col) = $curwin->Cursor;
    my $file = $curbuf->Name;
    $file =~ s/\.pm$//;
    use List::MoreUtils qw( after );
    my $package = join '::',
        after { $_ eq 'lib' }
        split m{/},
        $file;
    my $line = join '',
        substr($curbuf->Get($row), 0, $col),
        $package,
        substr($curbuf->Get($row), $col);
    $curbuf->Set($row, $line);
EO_MAP
endfunction

map ,pp :call InsertPackageFromFile()<CR>

How about you?

Got any more Perl specific things to ease your daily routine?

File::ShareDir is a neat little module you can use to access your non-code files that you need to pack with your distribution. Files like images, Template::Toolkit templates, etc.

One cool use I've found for File::ShareDir is using it to replace the jumble of code that is currently being used for Catalyst::Helper's file generation. I was able to cut out the stuff from the DATA section, put it in a share/ directory in the distribution, run a make install and voila. I'm able to access my files, and even throw Path::Class into the mix to get easy file slurping and such.

Here's a bit of code I used:

sub get_sharedir_file {
     my ($self, @filename) = @_;
     my $file = file( dist_dir('Catalyst-Devel'), @filename);
     warn $file;
     my $contents = $file->slurp;
     return $contents;
 }

 sub render_file {
     my ( $self, $file, $path, $vars ) = @_;
     $vars ||= {};
     my $t = Template->new;
     my $template = $self->get_sharedir_file( 'root', $file );
     return 0 unless $template;
     my $output;
     $t->process( \$template, { %{$self}, %$vars }, \$output )
       || Catalyst::Exception->throw(
         message => qq/Couldn't process "$file", / . $t->error() );
     $self->mk_file( $path, $output );
 }

 sub _mk_test {
     my $self      = shift;
     my $script    = $self->{script};
     my $appprefix = $self->{appprefix};
     $self->render_file( 'test.tt', "$script/$appprefix\_test.pl" );
     chmod 0700, "$script/$appprefix\_test.pl";
 }

file() is a Path::Class method for returning a file object, with which you can call ->slurp on and get its contents.

Easy!