Path::Dispatcher: a dispatcher that can work just about anywhere. It works (roughly) analogously to the way mod_perl works when matching URIs and dispatching to URI handlers. This code can work in any context including the command line.

These really aren't that recent, but I just discovered them. They also aren't 'talks' (well, they were talks, but the talk itself was not recorded), but, instead, slideshows. Nevertheless I found them all interesting.

I've been using DBIx::Class recently. It's the first ORM I've ever used and it seems seemless. Here is a slideshow introducing DBIx::Class. Another detailing the much newer DBIx::Class::DeploymentHandler.

Plack is another interesting platform I've been unable to use as of yet. But here is a slideshow that has some very impressive example code.

About 6 or 7 months ago I noticed I was being indexed by a search engine named Duck Duck Go. I went to the main page and it seemed interesting, but I never went back. Today I read that Duck Duck Go is written in Perl. I still don't know that I'll start using Duck Duck Go, but I find it very interesting that what is likely a very large project is using Perl. People who talk about the lack of scalability of Perl or the poor performance of Perl should take notice.

I agree with this post very much.

The Director of Engineering at ActiveState attempts to make the case that Perl Isn't Going Away Soon (Or Ever). Certainly he has some stake in such a prediction being that he's at a company that makes its money from dyanamic languages such as Perl. Does he make the case?

My current employer is hiring Perl developers. Now, I have no illusions that hundreds, or even dozens, of people read this blog, but, should you stumble upon this blog posting, please contact OpenX and we'll get back to you.

Is there a contradiction between employers complaining about the quality of Perl job applicants and Perl programmers complaining about the quality of Perl jobs available?

I don't know anything about the book so this is not an endorsement. However, be aware, that Addison-Wesley has released a free chapter for the upcoming Perl book Effective Perl Programming.

It may be worth a look.

I was unaware of the effort (and, besides, I don't have an Android phone), but apparently the effort to have Perl running on the Android OS is progressing.

I think this is exactly right. Knowing about perldoc and how to use perldoc is very important to becoming a good Perl developer (and, really, learning the documentation system for any language will be important). Two things that are not mentioned in the article are the '-m' and '-l' arguments. I use '-m' every single day. It is very useful for quickly viewing the code for a module, and, thus, it is a useful tool for seeing how others have solved particular problems. '-l' I use less frequently but it is useful for finding the absolute location of the module on the file system.

The title of this post is also the title of a post by JT Smith. He thinks that, because of Moose and other interesting technologies, Perl has its second wind. Well, here's hoping.

Related somewhat is a presentation by Tim Bunce entitled Perl Myths.

Chromatic has written a nice blog post detailing what the big deal is with Perl 5.12. It talks about the new release schedule and the important new features in 5.12.

IPC::Run3: the successor to IPC::Open2. A simpler API with the same functionality.

Perl 5.12 has been released. Go here to find out what is new (since 5.10.1).

Some may be surprised that 5.12 has come out so soon after 5.10. After all its only been two and a half years since 5.10.0 was released. It seems the perl5porters are now on a new release cycle.

If your company is using a slow moving or outdated RPM-based Linux distribution then you likely have an ancient version of Perl (some popular Centos distributions distribute a Perl that is nearly 6 years old). The recommended way to deal with this is to leave the system Perl untouched and package and install a second Perl.

Actually compiling and installing a second Perl is fairly easy. Popular places to install a second perl would be under /opt or under /usr/local. In my example I will install Perl in /opt/perl/<version> where <version> is 5.10.1. This directory structure allows me the ability to install other parallel versions of Perl should I want/need to do that. This blog posting will not cover how to build Perl. That is done adequately enough in the INSTALL file in the Perl source code. One important thing to do is to build with the -Dinc_version_list=none option. This tells the build to not use the @INC from older Perl's in the @INC for this new Perl. This option allows for a complete separation of installation for this new Perl.

When RPM packaging the Perl source code I find it useful to make it provide a virtual package. If your company is named FOO then let's call this virtual package FOO-perl.

  Provides: FOO-perl

Now every Perl package you create will require FOO-perl.

  Requires: FOO-perl

The hard part is creating module packages. Each Perl module RPM you create will have dependencies and it will also provide certain capabilities. By default all Perl code has a capability that looks like this:

  Requires: perl(Module::Bar)
  Provides: perl(Bar::Module)

Unfortunately this perl(...) naming scheme will conflict with the module packages for the system Perl. This is not what you want so what do you do? What I did was this: I copied the two programs in /usr/lib/rpm/ that gather dependencies and provides for a Perl program and placed them somewhere else (for this example let's say /home/user/bin). The two scripts are named perl-requires and perl-provides. I then edited them to return capabilities that look like this:

  Requires: FOO-perl(Module::Bar)
  Provides: FOO-perl(Bar::Module)

If you know Perl this should be trivial and I won't go into the details here.

To get the RPM automatic dependency engine to run the two new scripts you must place the following in your spec file:

  %define __perl_provides /home/user/bin/perl-provides
  %define __perl_requires /home/user/bin/perl-requires

You should also make certain that %_use_internal_dependency_generator is set to a non-zero value (it is set to 1 by default). If this macro returns a zero value the two scripts above will not be run.

Also, each RPM will have a Name: that looks like this:

  Name: FOO-perl-Module-Bar

So now when you build an RPM of a Perl module it will only have provides and requires for your custom Perl install and the RPM will be named FOO-perl-Module-Bar.

So what do you do if you want multiple custom Perl installs? That I don't know about. One way I can think of is to version your FOO label. So instead of capabilities that look like the above you might do this:

  Requires: Foo-perl-5.10(Bar::Module)
  Provides: Foo-perl-5.10(Module::Bar)

And your package would be named Foo-perl-5.10-Module-Bar. Seems complicated but it should work.