blogs.perl.org

It’s the first Tuesday of the month, so that means it’s YAPC::NA Planning Meeting time. If you’re in the Madison area, or don’t mind a drive there is a YAPC planning meeting tonight at the Essen Haus at 7pm. As always the food and beer are sponsored by Plain Black, and the room is sponsored by Essen Haus.

We’ve got a lot to discuss so the meeting will probably last until around 9pm, but you’re free to come and go as you please.

[From the YAPC::NA Blog.]

Following on from a recent feature request I’ve released version 0.0.8.10 of Catalyst::Plugin::ErrorCatcher.

The reports from the module now include POST and GET parameters for the request. Also included, if present, is the referer header value.

The new information looks like this:

For my first (real) tale, I thought I’d tell the story of how I came to be the maintainer for Data::Random.

I first came across this module when I was trying to find some way to test some date routines I was doing for $work.  Funnily enough (or not, depending on your perspective), the date routines were themselves for testing—I’m working on introducing TDD to my department, and so I try to maintain a decent library to make testing easier.  To that end, I decided to make it easier to set up records with certain dates:

    # go far back in time to avoid conflicting with real rates
    my $initial_date = '1/1/1990';
    $prop->create_billing_period(
        start_date => days_from($initial_date, 30),
        end_date => days_from($initial_date, 60)
    );

After falling in love with Pod::Weaver, I've released two new Pod::Weaver plugins which you may find useful for assembling boilerplate POD sections in your distributions.

The first is Pod::Weaver::Section::Extends which will add a =head1 EXTENDS section with a list of everything in your @ISA at compile-time. It should work with any kind of object that modifies @ISA in a normal way.

The second is Pod::Weaver::Section::Consumes, which does the same thing for Moose roles. It will interrogate any Moose-compatible meta object for your class to find a list of roles.

The repositories for them are here and here.

I’m happy to announce that Rimm-Kaufman Group (RKG) has decided to sponsor YAPC::NA 2012.

RKG is a full-service digital marketing agency that combines talented and creative marketing analysts with unmatched proprietary technological capabilities to create the industry’s most efficient and effective data-driven online marketing solutions. We drive business to our clients by maximizing a full range of opportunities including Pay-Per-Click, SEO, Social Media Advertising, Comparison Shopping Management, Display Advertising and Multichannel Attribution Management Services. RKG was founded in 2003 and works with organizations ranging in size from young startups to established Fortune 500 companies in sectors including retail, travel and finance.

[From the YAPC::NA Blog.]

I attended the latest Tel Aviv Perl Mongers (TelAviv.pm) meeting the other day, and am writing this report in order to encourage more people to come. We didn't have meetings in September or October due to the Jewish holidays and some renovations on the site, so it was good to finally have a meeting.

Before the meeting, I had helped publicise it on various online news channels, and thankfully quite a few people (about 20-30) came. I had a previous appointment that day at 12:00, and so returned home where I ate, worked on the computer, and rested before the TelAviv.pm meeting.

As people have been repeatedly surprised to discover that I'm moving to Paris, I thought I would mention it here in hopes that I don't have to keep explaining over and over again.

Leila and I were quite happy in Amsterdam and I enjoyed my job at booking.com. However, for a variety of reasons, not the least of which was Leila's difficulty in finding a job in Amsterdam, I decided to accept a position in Paris. I started at Weborama on December 1st. We'll be in Amsterdam for two or three months until we make the actual move. We'll likely be moving to a small town outside of Paris (we currently have our eye on Meaux), but nothing is quite decided yet.

• Background
• Problem
• Implementation
• Solution

Background

I like the Perl debugger a lot. I use it daily, since understanding code by seeing it execute is much better than guessing at what it does based on its API. I do however seldomly use the actual command line debugger module, but instead use the Perl debugger built into Komodo IDE because it streamlines a lot of the busywork that is necessitated by having a debugger bound to a terminal:

I’ve apparently been too effective in asking for the talks we want for our primary two tracks, or not effective enough at explaining that we have 5 total tracks and that you can submit any kind of talk you want for YAPC::NA 2012. I say this because Sawyer X posted a comment indicating he didn’t think his talks would be welcome. I apologize that I gave that impression to anyone.

For the record, here are the tracks at YAPC::NA 2012:

1. Perl in the Wild - Real world Perl applications.
2. Perl 101 - The stuff everybody needs to know to be a good Perl programmer.
3. Anything Goes #1 - Talk about your favorite module, framework, or what halve you.
4. Anything Goes #2 - Same as Anything Goes #1.
5. Mini Workshops - 1 or 2 hour long hands-on tutorials. 

We’re still looking for sessions to fill all of those areas, although we could definitely use some 1-hour long mini workshops. 

[From the YAPC::NA Blog.]

When I started Excel::Writer::XLSX I had, more or less, a clean slate to start with. So I chose to use perl 5.10.

It was mainly because I wanted to use the defined-or operator //. There were other reasons as well but Excel::Writer::XLSX is an API heavy module and, although it may sound trivial, defined-or saved me a lot of time.

I also wanted to use some of the other Modern Perl features. In fact I would really have liked to have used perl 5.14 but I thought that was probably a step too far.

Perl 5.10 isn't exactly new. It came out around the same time that Excel 2007 and the xlsx format came out. So, I thought that it was reasonable to use a recent perl for a module targeting a recent file format.

The DC Perl Mongers, have started publishing a podcast of their monthly meetings, along with pngs of the presenters screens when available.

The podcast url is: http://dcpmpodcast.dyndns.org/rss_feed.rss

Or via itunes at: http://itunes.apple.com/us/podcast/washington-dc-perl-mongers/id485073172

Slides are available at : http://dcpmpodcast.dyndns.org/ and then selecting the slides link for the episode you are interested in.

The editor that came with MacOS Perl (for Mac OS 9 and below) was able to save your script as a droplet -- that is, an application that you could run by dropping files onto it. When your script got control, the paths to the dropped files were in @ARGV

Under Mac OS X you can get this functionality by wrapping your Perl script in an Apple Script. The following example assumes you want to wrap a Perl script named droplet.PL in an application called PerlDroplet. It works because a Mac OS X application bundle is simply a directory whose contents are known to the system.

1. Run the Script Editor, which is found in /Applications/AppleScript/
2. Paste the text of the Apple Script as it appears below into the editor.
3. Save the script as an Application Bundle named PerlDroplet.
4. Copy your Perl script to directory PerlDroplet.app/Contents/Resources/.

Yes, this will work if you move PerlDroplet somewhere else.

The talk submission process for YAPC::NA 2012 closes on March 15th. After that time we’ll finish building out the schedule with the talks that have been submitted. So if you’d like your talk considered, please submit it today.

[From the YAPC::NA Blog.]

A while ago I did some comparison on serialization and logging modules, and I hope to do or see comparison on others. Here are some of them:

• PID files. About a decade ago I wrote Proc::PID_File, including fork() handling, it does the job pretty well but I ended up abandoning it in favor of Proc::PID::File because I don't have time to maintain it and I hated the name. Turns out that there are several other modules pertaining to PID files like Piddy, Pid::File::Flock, IPC::PidStat, even Unix::PID (which is not recommended). The comparison article should discuss what issues surround managing PID files and also mention other means to detect program instances, like locking DATA filehandle (forgot which module does this).

• INI files. Tried several INI modules in the past, not satisfied with any of them. Used Config::IniFiles in the end, but recently wrote another implementation (unfinished). A comparison article could be helpful.

• Command-line-argument processing. Have always used Getopt::Long, heavily used App::Options a few years ago, now settling with my own module. Recently there have been some new development efforts like MooseX::GetOpt, Moo::Getopt, and App::Rad.

As a few of my previous posts have implied, I am attempting to reinvigorate the Zoidberg Perl shell. Much of the work of getting it back to a functional state has already been done at my GitHub repo. I have a bigger post coming on why this is cool and even another with some examples, but for now I have a question:

Is an AutoSplit/AutoLoader mechanism helpful on modern hardware? I mean Moose/MOP (and many other projects) are huge and doesn’t use it. In fact it seems that very few modules depend on it.

Now, I understand that AutoLoader has some cool uses for causing subs to spring into existance. In the context of Zoidberg, though, I only care about its use to defer loading infrequently used subs.

To test some things, I created a branch in which I naively removed these bits, and lo and behold, with only one missing my (see AutoLoader Considered Harmful), the tests all pass and a quick run seems fine.

So I fairly call the question: should I leave AutoLoader in, or pull it?

Pop quiz! What does this perl 5 program prints when executed with no arguments?

brian d foy will be giving a talk at YAPC::NA 2012 described as:

A modulino is a module that also can act like a script. This talk explores how a typical command-line invocation of the script, with switches and standard input and output, can connect with a module’s interface without sacrificing flexibility.

[From the YAPC::NA Blog.]

Now that Perl's builtin functions can directly operate on hashrefs and arrayrefs (I'm already starting to dread having to write push @{$foo->{bar}} instead of just push $foo->{bar}, but I'll be stuck with 5.10 for at least a couple more years), it chuckles me a bit imagining a future where beginners only use and know about scalars, and not arrays/hashes. Where they just need to memorize $ as the variable prefix. And where % and @ are nowhere to be found in baby Perl.

Among the issues with this would include the many special variables like @_, @INC and %INC, %ENV, %SIG and so on. We can provide some abstraction like self or MooseX::Declare for @_. With Moose et al, we already don't need to muck with @ISA directly.

Another would be list assignment, but I don't think beginners use it much.

Wouldn't it be cute? Albeit a bit pointless maybe. I can do away with context in Perl, but for now I like being able to have $thing, @thing, and %thing at the same time. Or do I?

I noticed today that my firefox has been really slow lately. I use a firefox plugin named vimperator which provides vim-like keybindings for firefox. I have it configured it to store 5000 command history entries, which is considerably more than the default (500). It has always been in the back of my mind that this might come back to bite me one day. So today I decided to check how many entries have so far been saved in the history file. I easily found that the history is stored in a json file located at ~/.vimperator/info/default/history-command. Running wc (word count) wouldn't help because all the data is stored on one line. I noticed that the file simply contains a serialized json array. To determine the size of this array, I used App::p and whipped up this simple one-liner:

    p 'p @{jl r "history-command"} + 0'

http://svn.ali.as/cpan/releases/Test-NoWarnings-1.04.tar.gz

One of the common gotchas with Test::NoWarnings is that the warnings are collected up and displayed in one go at the end of the script.

While this is strictly speaking the correct time to show them and has the least likelihood to result in a collision with some other test module resulting in an explosion, it makes debugging test scripts much more difficult.

Since I took over Test::NoWarnings a number of people have asked me to “fix” this problem.

After much thought, I’ve decided to leave Test::NoWarnings default behaviour the way it is and show everything at the end.

Instead I’ve added a specific debugging aid in the form of an :early pragma.

use Test::NoWarnings 1.04 ':early';

The :early pragma explicitly turns on emitting warnings at the time they occur instead of gathering them until the end.