• Pittsburgh Perl Workshop fast approaching

    The Pittsburgh Perl Workshop is coming soon, October 13-14. If you're not yet signed up, there's still time to register. The price is only $40 for students for two days, or $70 for non-students, a heck of a deal for two days of talks from dozens of speakers. Plan to come early and make the Friday Social. Plans are also afoot for a Saturday Social.

    There are also spots available in the full-day From Zero To Perl training class, so you can bring your friends who aren't yet hep to the wonders of Perl.

    Finally, if you're going to PPW, and you've always wanted to speak at a conference, but never had enough to say, there is still time to get one third of your fifteen minutes of fame. Submit your lightning talk today.

  • Perl::Critic: an interview with Chris Dolan

    Chris Dolan recently received a Perl Foundation Grant to write 20 new policy modules for Perl::Critic. I managed to catch up with Chris by email and ask him a bunch of questions about his work on Perl::Critic, the TPF grant, and more.

    Kirrily: So, how did you first get involved in Perl::Critic?

    Chris: Funny, I had to look back at my email to remember this. You'd think I could remember two years ago...

    I read Damian Conway's Perl Best Practices (aka PBP) in summer 2005 and thought, "Finally! The solution to the 'Perl is not readable' myth!" I tried applying all of the ideas manually in a new module I was just about to release to CPAN (Net::IP::Match::Regexp). I found the process rewarding, but a little tedious and error-prone.

    After working with the PBP recommendations manually, I thought about writing some code to judge some of the recommendations automatically, but happily I decided to check CPAN first. I found Perl::Metric::Basic and posted some RT reports. Then I found Perl::Critic, which had just been renamed from Perl::Review. I found the code much more approachable that Perl::Metric and soon filed a few RT reports and a cpanratings review. Jeff Thalhammer, the P::C creator and leader, emailed me back personally thanking me for the feedback. After that, we had about a dozen back-and-forths where Jeff sent me pre-release tarballs of Perl::Critic and Test::Perl::Critic to test before sending them to CPAN. Then, I wrote my first from-scratch policy (Modules::RequireEndWithOne) about a month later, and I was hooked.

    Kirrily: What prompted you to apply for a TPF grant? How did you convince them to give you money? How did you find the grant process?

    Chris: I hope nobody criticizes me for admitting this, but my reason for applying for the grant was self-motivation. Our second child was born Jan 1, 2007 and the company where I worked was struggling, so it was a hard time to find energy for my open source efforts. I usually work best under pressure, so I decided the publicity of a TPF grant would force me to get something done (and the money will be a nice bonus too).

    I wrote a ton of grant proposals in my former life as an astronomer and, of course, tons of business proposals as a web/programming consultant, so I found the TPF grant process pretty easy. The positive impact of Perl::Critic is obvious on the community of people who care about good Perl code, so the justification part was straightforward. The harder part was deciding what part of P::C to propose to build.

    Kirrily: Is there a theme or themes to the 20 modules you're doing?

    Chris: Yep. We keep an extensive TODO.pod file in the P::C svn repository. One portion of that file is devoted to PBP recommendations that seemed feasible to implement in code. I had created that list over a year earlier by paging through the PBP book and brainstorming implementations for each recommendation. Needless to say, some of the PBP recommendations will never make it into P::C -- for example "Never assume warning-free compilation implies correctness" (page 432).

    It turned out there were an even 20 PBP-based ideas in the TODO list (vs. about 40 non-PBP ideas). Twenty seemed like a nice round number and a challenging-but-doable quantity. At that time, I was primary author of 27 of the 93 finished policies, so I had a pretty good idea of what was involved.

    Kirrily: Why should people use Perl Critic? Why shouldn't they?

    Chris: In my opinion, it's good for two things:

    1) Finding bugs (real bugs and potential bugs)

    2) Making your code more approachable

    Both are especially important for open source code that might be used by thousands of other programmers. Why write bad open source code?

    One reason not to use Perl::Critic is to put a badge of honor on your code. Achieving P::C compliance is a good thing to announce to the world because it tells users that you care about the quality and consistency of your code. But P::C doesn't help make your code better directly. It just tells you that your code isn't broken in one of about 100+ known ways. And some of those 100+ contradict each other! Compare that to the innumerable ways to write bad code. So, you've got to start with good code and use P::C as a tool to make it a little better.

    One piece of advice I like to share is that you should not be afraid to turn off P::C policies that don't work for your code. I think Damian gave similar advice in PBP. In the P::C code itself, we have 98 instances of ## no critic(...) which turns off certain policies. Even Perl::Critic is not 100% Perl::Critic compliant! But 98 out of 27,000 lines of code isn't bad.

    Another controversial topic is whether .t files should be P::C compliant. Personally, I don't bother. Writing test code needs to be fast and easy or it falls by the wayside.

    Kirrily: Do you know of any really interesting uses of P::C out there? Famous companies using it?

    Chris: Good question. We should ask Jeff Thalhammer about that -- as P::C founder, he has a closer connection to our user community. There was brief talk about creating a for-profit consulting entity to help big companies write better code using P::C, but I don't think anything came of that (I was too busy to participate).

    What I find interesting is the people/groups/companies who have privately implemented their own policies for P::C. Parrot, for example, had a few custom policies the last time I looked. Another example is MathWorks, who funded the Perl::Critic developers to write some specific policies they desired. Now that's a business model any open source developer craves!

    Kirrily: What next after you've implemented these P::C modules?

    Hmm, I have no real plans. More policies, I guess. I'd love to get more people writing them. They aren't too hard to create and without them P::C is worthless. If anyone wants to get involved, I'd be happy to be a mentor. Giving fish vs. teaching fishing, y'know.

    In my day job, I do a lot of Java coding (and often enjoy it). We use a commercial package called CodePro by Instantiations which is conceptually similar to Perl::Critic but is much more polished. They have over 900 policies to choose from, many of them specifically designed to squelch anti-patterns in the big APIs like Spring, Hibernate, Struts, etc. Jealously, I've often thought that they have an easier job than we do because Java is so much easier to parse than Perl, and the code smells seem to fall in more easily identifiable patterns.

    When Perl 6 becomes popular, I'd like to see Perl::Critic be implemented against it. Perl 6 will have a grammar that is much more amenable to grepping. Behind the scenes, I'd like to see the Perl 6 version of P::C work against de-sugared syntax or perhaps even the abstract syntax tree to simplify the policy writing. Unless a huge amount of work goes into improving PPI, that's not going to happen for Perl 5. At one point, we talked about writing P::C policies using an XPath-like notation, but nobody ever championed that goal. I discovered that FindBugs (another Java code analysis tool) took that approach successfully. Maybe P::C can benefit from the Parrot tree grammar engine (TGE). Or the optimizer. After all, the syntax pattern matching that P::C has to do is not that different from the opcode pattern matching that an optimizer performs.

    Overall, what I'd really love is for Perl 6 to avoid the "write-only language" moniker that got slapped on Perl 4 and Perl 5. If P::C can help with that, then it has succeeded.

    Thanks, Chris!

    Find out more about Perl::Critic at PerlCritic.com or listen to this PerlCast interview with Jeff Thalhammer, creator of Perl::Critic.

  • mod_perl 2 User's Guide published: An interview with co-author Jim Brandt

    mod_perl2 User's Guide (modperl2book.org) by Stas Bekman and Jim Brandt has just been published by Onyx Neon, and Amazon says it's shipping. I can't think of the last time I've been as excited to see a Perl book get published. Besides brian d foy's Mastering Perl, there hasn't been a significant Perl book in quite a while. Perlbuzz is going to work with Onyx Neon to have a book giveaway, so watch this space in the next few days.

    Jim Brandt took some time to talk with me about the book, why you need to switch to mod_perl 2, and why it took so long to get the book to market.

    Read on →

  • ctags 5.7 improves Perl support

    Exuberant ctags, the standard tags utility on most systems today, has released version 5.7 for download with the following improvements to its Perl support (among many other improvements):

    • Added support for 'package' keyword
    • Added support for multi-line subroutine, package, and constant definitions
    • Added support for optional subroutine declarations
    • Added support for formats
    • Ignore comments mixed into definitions and declarations
    • Fixed detecting labels with whitespace after label name
    • Fixed misidentification of fully qualified function calls as labels

    If you've never used tags or ctags, start today. Your life will never be the same after.

    For example, if you run ctags on a tree of source code, and then run vim -t some_function from the shell, vim will open the file where some_function lives and leave your cursor there. Alternatively, if you're editing a file with vim and you position your cursor over the word some_function and press Ctrl-], vim will jump to the function. Other editors have similar bindings.

    Your editor doesn't know Perl, but it relies on ctags generating a tags file, which is in a standard file. Of course, ctags isn't perl itself, so isn't as exact. These improvements in v5.7 will make your tag files more accurate.

    If you've got a Perl module, it's easy to add a makefile target for tags. See any of my major modules (WWW::Mechanize, ack, etc) and steal from the Makefile.PL, or just add the following to your Makefile.PL:

    sub MY::postamble {
    my $postamble = <<'MAKE_FRAG';
    .PHONY: tags
    ctags -f tags --recurse --totals 
    --languages=Perl --langmap=Perl:+.t 
    (With ctags 5.7 it turns out, that --exclude=.svn is no longer necessary, as ctags automatically knows to ignore it now.)
  • search.cpan.org makes improvements in searching

    search.cpan.org, which for many people is the CPAN, has added a crucial little enhancement. The star ratings given to distributions at cpanratings.perl.org now appear on the search results. This makes it easy to tell at a glance which modules may best serve your needs.

    Say you want a module to work with Excel spreadsheets. Now, when you search on "Excel", the star ratings in the results give the searcher starting points.

    Thanks to Graham Barr for making this change.