Doing the Jitterbug

Jonathan Leto (dukeleto) presented Jitterbug, a cross language continuous integration tool for git (and written in Perl). It's a smaller, lighter tool than Jenkins, though it lacks distributed testing capabilities. It seems really good for small to medium sized Perl projects, as it already understands how to build and test things with a Makefile.PL or Build.PL. (see slides [pdf])

Javascript is Code

Jay Shirley (jshirley) gave a non-Perl talk that explained why Javascript tends in practice towards spaghetti code. He recommended the YUI3 framework and explained why it provides better structure and why it would be familiar to Perl programmers used to Moose.

A Brave New Perl World

Stevan Little (stevan) presented some ideas from the work-in-progress prototype of a meta-object protocol (aka MOP) for the Perl 5 core. I'm really excited by this and I think the design team is finding a pragmatic balance between power and simplicity.

Tweakers Anonymous

John Anderson (genehack) gave an editor-agnostic half-rant/half-tutorial about why and how to tweak your editor to be more productive and less repetitive. There were some good tips that I've already put intro practice, like teaching the editor to automatically "chmod +x" when saving any "*.pl" file. (see slides)

The First Thing Tak Did - Elegant Remote Control For Sysadmins

Matt S. Trout (mst) showed an insanely complicated but powerful command line tool to remotely execute any pure Perl code over ssh, without needing any prerequisite modules installed on the remote machine. It's worth exploring just to understand the magic that makes it work.

Game Development with Perl & SDL

Breno Oliveira (garu) gave a playful talk that showed how easy it has become to use Perl to write simple graphical games. In only a couple dozen lines of code, he demonstrated a simple 2D platform game using the built in physics model. (see slides)

Cooking Perl with Chef Solo

This was my talk, where I explained what I've been doing to make it possible to deploy Plack apps using Chef and Perlbrew and friends. (see slides)

Lightning talks

There was the usually assortment of amusing talks, though several presenters thought it would be "fun" to present their 20 minute (or longer) talks in 5 minutes for anyone who missed the original. (Note to future presenters -- please don't do that. Pick 5 key slides and just show those.)

The most interesting to me was the lightning talk by Bruce Gray (util), who introduced Rosetta Code, a site that shows how different languages solve hundreds of common programming problems. He said that Perl needs more solutions written to catch up to other languages, so if you have time and interest then please check it out.

Keynote

Cory Watson (gphat) gave a funny talk that in style was nearly worthy of Larry Wall. It meandered around the broad theme of "diversity" and whether more ways of thinking about things makes one smarter. It eventually circled back to Perl, but the overall call to action was to get out of the usual comfort zones and try something you haven't done before and aren't good at -- whether radical or minor -- in order to stretch your brain. (I can't do it justice in text -- I think you had to be there.)

Hackathon

On Sunday, I went for brunch with some other attendees and then parked myself at the hackathon until it was time to leave for the airport. While I was there, I sucessfully ported my auto-install CD creation tools to work on Debian ISOs instead of just Ubuntu ISOs, so I can test my Perl/Chef tools on that server platform as well.

Coda

As a final note, Chris Prather (perigrin) -- who appeared ably supported by his family -- put on an excellent conference and I want to thank him for the work that went into it. I hope I can attend again in 2013 and recommend it to anyone who wants to get away and have some fun with Perl in the dark of January.

The (not) funny thing is that none of what he's saying is a risk would be one when running in taint mode.

Consider "/tmp/foo.pm" with this:

package foo;
print "Loaded foo\n";
1;

Then consider this example of how Module::Load does something "unexpected":

$ perl -MModule::Load=load -wE 'my $file=shift; load $file' ::tmp::foo
Loaded foo

(The "threat" is that given an arbitrary module name to load, it will gladly load outside @INC.)

What if that was run under taint mode, instead?

$ perl -MModule::Load=load -wTE 'my $file=shift; load $file' ::tmp::foo
Insecure dependency in require while running with -T switch at /home/david/perl5/perlbrew/perls/perl-5.14.0/lib/5.14.0/Module/Load.pm line 27.
Insecure dependency in require while running with -T switch at /home/david/perl5/perlbrew/perls/perl-5.14.0/lib/5.14.0/Module/Load.pm line 27.

I'm not sure why that message is printed twice, but that was still a fatal error and foo.pm didn't load.

The moral of the story: if you incorporate arbitrary user input into your execution path, use taint mode and validate the input to make sure it's something safe.

use Path::Class::Rule;

my $rule = Path::Class::Rule->new; # match anything
$rule->file->size(">10k");         # add/chain rules

# iterator interface
my $next = $rule->iter( @dirs );
while ( my $file = $next->() ) {   # $file is a Path::Class object
  ...
}

As you can see, it has the same method-chaining of rule helpers that File::Find::Rule does. However, it's not built on top of File::Find, so you get a real, lazy iterator instead of the File::Find::Rule iterator that precomputes the results and hands them to you one at a time. The iterator returns Path::Class objects, which makes it a little easier to do some common file manipulations.

While Path::Class::Rule is very new, it already implements the following kinds of rule helpers:

• File name rules
• Directory skipping rules
• File test rules, e.g. -f, -d, -r, -w, etc.
• Stat test rules, e.g. results of stat()
• Search depth rules
• Perl file rules
• Version control file skipping rules

It's also easy to extend. You only need to "and" together a callback that gets $_ set to the Path::Class object under examination:

$rule->and( sub { -r -w -x $_ } ); # stacked filetest example

You can write extension classes with new helper methods using the add_helper method. Here's a simple example that matches files named "foo":

package Path::Class::Rule::Foo;

use Path::Class::Rule;

Path::Class::Rule->add_helper(
  foo => sub {
    my @args = @_; # do this to customize closure with arguments
    return sub {
      my ($item) = shift;
      return if $item->is_dir;
      return $item->basename =~ /^foo$/;
    }
  }
);

1;

If this module sounds interesting, give it a try! If you want to help improve it, fork it on Github and let me know what you have in mind.

(If you're a curmudgeon and want to know why I wrote another file-finding module for CPAN, read the "SEE ALSO" section of the documentation for my comparison to other things out there.)

Update I've released 0.004 with some additional SEE ALSO entries based on suggestions below.

I like that idea, and it inspired me to remind people to please also consider just giving "thanks", too.

Sure, I'd love a song or a small ebook (and maybe I should set up a wishlist), but I also love getting an email saying thanks, particularly when it is from someone I don't already know telling me that they like a module I released to CPAN or telling me how they are using my code to solve some problem they have. Email is cheap, but still has huge impact.

Perl is a community built on altruism. Don't forget to say thank you!

# from this
do_something()
  if condition();

# to this
if ( condition() ) {
  do_something();
}

I decided to automate that with a vim macro:

map ,if V:s/\(\s*\)  if \(.*\);/\1if (\2) {/<CR>kVdp>>$a;<CR><BS>}<CR><Esc>kkk^

For it to work, the if modifier has to be on a line of its own (which I usually do for code clarity) and the cursor needs to be on that line when running the macro.

Feel free to copy and adapt to your own needs and preferences.

Here are some options. See the last for a new way that I just cooked up and released to CPAN.

Use your favorite CPAN client against the current directory

Example:

$ cpan .

Beware that this also installs the module in the current directory, which may not be what you want.

cpanminus is smarter than that if you give it an option

$ cpanm --installdeps .

For Module::Build-based modules: Build installdeps

Example:

$ perl Build.PL
$ Build installdeps

For (some) Module::Install-based modules: make installdeps

Example:

$ perl Makefile.PL
$ make installdeps

Note that this requires the Makefile.PL to use the 'auto_install' plugin.

For Dist::Zilla-based modules: dzil listdeps

Example:

$ dzil listdeps | cpanm
# or
$ cpan $(dzil listdeps)

This requires installing Dist::Zilla any any dist.ini dependencies first:

$ cpanm Dist::Zilla
$ dzil authordeps | cpanm

(Notice a pattern here?)

Anything with Makefile.PL or Build.PL: MYMETA and mymeta-requires

Install the latest ExtUtils::MakeMaker, Module::Build and App::mymeta_requires. Then configure as usual and run 'mymeta-requires' to get a list of dependencies.

Example:

$ perl Makefile.PL
$ mymeta-requires | cpanm
# or
$ cpan $(mymeta-requires)

A nice feature of 'mymeta-requires' is that it gives you access to all the different prerequisite types defined in the CPAN::Meta::Spec. So if a module offers 'develop' prerequisites, you can include those like this:

$ mymeta-requires --develop | cpanm

See the documentation for other ways to control which prerequisites are included in the output.

One drawback is that you'll still need to install any configuration prerequisites needed to run Makefile.PL or Build.PL, but that is true of all other recipes above (except that ones that use a CPAN client).

Update: as of version 0.002, 'mymeta-requires' will fallback to a META.json|yml file and also picks up configuration prerequisites. So now you can bootstrap completely like this:

# get configuration prerequisites
$ mymeta-requires | cpanm

# run configuration
$ perl Makefile.PL

# get any additional dynamic prerequisites from configuration
$ mymeta-requires | cpanm

Easy!

I don't know what it would take to make that happen, because getting Alien packages right across platforms is tricky, but a first step is figuring out what libraries people wind up needing the most.

If you install libraries/headers by hand, what do you wind up using most often? Please answer in the comments.

Here's how I used Perl to rename these pictures into the right order based on the timestamp metadata inside the JPEG files:

#!/usr/bin/env perl
use 5.010;
use strict;
use warnings;
use autodie;
use Digest::MD5 'md5_hex';
use Image::ExifTool 'ImageInfo';
use Path::Class;

for my $f ( dir()->children ) {
  next if $f->is_dir;
  my $exif = Image::ExifTool->new;
  $exif->ExtractInfo($f->stringify);
  my $date = $exif->GetValue('DateTimeOriginal', 'PrintConv');
  next unless defined $date;
  $date =~ tr[ :][T-];
  my $digest = md5_hex($f->slurp);
  $digest = substr($digest,0,7);
  my $new_name = "$date-$digest.jpg";
  unless ( $f->basename eq $new_name ) {
    rename $f => $new_name;
    say "renamed $f => $new_name";
  }
}

This program renames everything in the current directory into a format like this "2011-05-28T14-48-20-7fc2e71.jpg" -- which is an ISO8601 datetime (with "-" instead of ":") plus the first 7-hex-characters of an MD5 checksum. I use the checksum on the off-chance that two pictures were taken at the exact same second (e.g. from two cameras) or that one picture was a cropped/retouched version of an original. Anything that doesn't have EXIF datetime information is skipped and then I have to examine those manually to sort them into the rest.

It's not much, but it's quick and it worked.

The counterfactual is this: "If Perl 6 never existed, then Perl 5 could bump itself to Perl 6 NOW in order to signal a backwards-incompatible break from the past."

If the counterfactual were true, I believe this could happen, even with the limitations of the Perl 5 development process we have today. Perl 6 (as it actually does exist today) is revolutionary design, not evolutionary design, but that doesn't preclude an evolution of Perl 5 that significantly breaks backwards compatibility.

Without recommending any particular change, here are some examples of things that I think could be possible, just to give a sense of what evolutionary (rather than revolutionary) changes could attempt:

• Replacing eval BLOCK syntax with try BLOCK
• Removing of Unix-specific user/group functions and similar cruft
• Eliminating of indirect syntax
• Replacing method call arrow -> with the shorter (and more widely recognized) dot/period character (and finding a new concatenation operator)
• Eliminating version objects and v-strings
• Replacing (frequently misunderstood) function prototypes with function signatures

Those are just ideas off the top of my head, but I hope it's easy to see than any of those break enough existing code as to make them very difficult to envision being added to any future release of Perl 5. However, if the counterfactual were true, then there would always be the option of making a clean break to "Perl 6", ensuring that there is no automatic expectation of backwards compatibility.

Even if the counterfactual were true, making such evolutionary changes would not necessarily be easy. It would require a Pumpking (other than Larry Wall) to play language designer for Perl 5 and to push the Perl core developer community into a rough consensus. But hard does not mean impossible.

However, with the reality of Perl 6 as it stands, even a name change by Perl 6 ("Camelia" was one suggestion) doesn't help Perl 5's evolution. Given the expectations that have been set for Perl 5, it seems unlikely to me that there would be broad community support for Perl 5 evolving into Perl 6 if Perl 6 were renamed. "Hi, we promised you Perl 6 ten years ago, but it's not ready for production, so we're going to call this other thing Perl 6 instead." I don't think that's great for external perceptions, either. What then? Jump over Perl 6 straight to Perl 7? I don't think that would be well received, either.

For Perl 5 to evolve in ways that are significantly backwards-incompatible, I see only two realistic options:

• Rename Perl 5 to something else, with all the associated branding and marketplace traction issues that would cause, but with the ability to make a major version number bump to manage compatibility expectations.
• Increase the speed of mutation of Perl 5 so that Versions 16, 18, 20, etc. become bigger departures cumulatively than we ever saw with Versions 6, 8, 10, etc., and become much more ruthless about setting future compatibility expectations.

(I suppose an interesting variation on the first way would be for Perl 5 and Perl 6 to be renamed simultaneously. I could see that having some positive opportunities for branding and marketing.)

The status quo alternative is for Perl 5 and Perl 6 to continue as they have been, slowly chugging along on their respective tracks. Perl 5 will continue to put backwards compatibility over evolution and won't see substantial new features added or old mis-features cleaned up. Perl 6 will continue to push towards some sort of production readiness.

For some (perhaps many), the status quo is ideal. For me, I would find it rather boring to be a part of.

So -- let that be the real debate in the Perl 5 community: compatibility or evolution? Names and version numbers are just the means to an end.

However, as I reflect on the doubling of my parental responsibilities and a pending shift to more entrepreneurial employment, I've decided to throw in the towel on Iron Man. I plan to keep blogging, but probably not at the pace I've been, nor always about Perl. I have new challenges in front of me and new projects in mind to tackle them. Of course, when they involve Perl, i'll be sure to mention it.

Stay tuned...