By Shlomi Fish

Most people who are actively developing using Perl are familiar with sites for searching CPAN (the Comprehensive Perl Archive Network) such as search.cpan.org and kobesearch.cpan.org. These sites provide a simple search bar where users can search for keywords or key phrases, and find a list of results. These sites also feature pages for the various CPAN distributions, the various authors, and the individual pages of documentation inside the modules.

Recently, Andy Lester started the "Rethinking CPAN" mailing list and wrote a Perlbuzz post titled "Rethinking the interface to CPAN", where he gave the case that the current resources may be inadequate for the process of selecting a module on CPAN. For a long time, there was an intermittent discussion and some brain-storming, but very little code (if any) has been written. This has all changed with CPANHQ.

So what is CPANHQ? As documented in the first and only wiki page it has so far (which I wrote a few days ago), "CPANHQ aims to be a community-driven, meta-data-enhanced alternative to such sites as http://search.cpan.org/ and http://kobesearch.cpan.org/. Currently, the functionality is very basic, but we have great ambitions."

I learned about CPANHQ by overhearing a conversation on Freenode's #perl channel. I joined the effort, and made several enhancements to the Catalyst and DBIx-Class-based code. The functionality is still very basic.

Some of the plans and ideas we have for CPANHQ, which may be translated into code in the future are:

1. The code is and will remain open-source, which makes it easy for people to contribute to.

2. We plan to have most of the current features of search.cpan.org and kobesearch.cpan.org including pages for authors, distributions, and individual modules and their documentation.

3. CPANHQ was already enhanced with some jQuery and jQuery UI JavaScript goodness, and we plan to add more of it to make the user experience better.

4. The site aims to be more integrated than the many separate CPAN-related sites today: search.cpan.org, CPAN Forum, AnnoCPAN, CPAN Ratings, CPANTS, CPAN Dependencies, etc. By putting everything under one roof, we can provide a better user experience than the many sites with very loose integration.

5. We plan to enhance the site based on meta-data as provided by both the module authors (in the META.yml file and the users of the site.

   For example, we have already added support for the META.yml's keywords which allow authors to tag modules, and we plan to support user-tags too.

6. CPANHQ will be very community-driven. People would be able to open user accounts there, which will allow them to contribute content to the site, such as tags/labels, comments, wiki pages, chatter, etc.

The CPANHQ wiki page contains more ideas and insights. Like I said, the current functionality is incredibly basic, but we hope that with enough help, time and dedication, we can create an attractive and engaging interface to CPAN, to make finding a module on CPAN faster, easier and more fun.

In the meantime, you can look at the screenshots we have of the interface so far, or clone the github repositories, and set up a local web-interface.

Shlomi Fish has been writing using Perl, about Perl and for Perl, since 1996, when he started working for a web-design shop, and discovered Perl and UNIX, which he's been in love with ever since. He initiated and is maintaining many CPAN modules and contributed to many other Perl and non-Perl related projects.

Perl 6 is hurtling toward completion. The specification is nearly complete, and Rakudo now passes 68% of the specification tests. Applications like November are being written in Perl 6. Perl 6 is no vaporware, and the day when Perl 6 is ready for widespread use is coming quickly. Perl 6 has been in development since 2000, and in that time many people may have forgotten about the plans we've had for Perl 6. There may be those who have never even heard about the plans for Perl 6. Those of us who live in the Perl world are aware of the great changes afoot, but there are plenty of people who are not. I think that the time is right to help make those people aware of Perl 6, and to remind them constantly of what's coming. My proposed technique is simple and it takes advantage of the key elements of time and repetition to help remind everyone about Perl 6. > **We need to stop referring to Perl 5 as "Perl" and start calling it "Perl 5."** Specifying the "5" in "Perl 5" calls attention to the fact that there is more than one Perl. It makes the listener or reader who is unaware of Perl 6 wonder why the 5 is specified. For the reader who knows about Perl 6, hearing "Perl 5" reminds her that Perl 6 also exists. I don't think it will be too tough. All I ask is that, at the very least, when writing about Perl 5 in your blogs or mailing lists that you specify the version you're talking about. It doesn't even need to be every instance. I'm guessing we'll find that repeatedly saying "Perl 5" in a long message will get tedious both for writer and reader. I think the way to look at it is that "Perl 5" is the formal name for the language, and later references can refer to it as "Perl," almost like a nickname. Just that first reminder of "Perl 5" will be enough to help lodge in the reader's brain. With enough time & repetition, it will get to be habit in our minds. With enough time & repetition, the computing world will be reminded of Perl 6 coming soon.

Which of these two events sounds more interesting? > Joe Celko is going to be giving talks at YAPC this summer. Or, in an announcement entitled ["Learn Mad Database Skillz at YAPC::NA 2009"](http://justatheory.com/computers/databases/celko-at-yapc.html) > It really, truly pays to learn the ins and outs of SQL, just like any other language. And if you’re a Perl hacker, you have a great opportunity to do just that at [YAPC::NA 10](http://yapc10.org/) this summer. Famed SQL expert [Joe Celko](http://www.celko.com/), author of [numerous volumes on SQL](http://www.amazon.com/Joe-Celko/e/B000ARBFVQ/) syntax and techniques, will be offering two classes on SQL at YAPC: > - [Introduction to RDBMS and SQL for the Totally Ignorant](http://yapc10.org/yn2009/talk/2050). Well, okay, the name of the course is a bit unfortunate, but the material covered is not. If you know little or nothing about SQL, this course should be a terrific introduction. > - [The New Stuff in SQL You Don’t Know About](http://yapc10.org/yn2009/talk/2051). So much great stuff has been added to SQL over the years, and ORMs know virtually none of it. Learn how to put that stuff to work in your apps! That first announcement is usually what I get when people ask me to announce something in Perlbuzz. "Hey, we're having the East Podunk Perlapalooza next week." Yeah, so? Who cares? Why will Perlbuzz readers care? David Wheeler, author of the latter text, understands what most geeks seem not to grasp: **The mere existence of your Foo is not enough for people to be interested.** Look at all the topics that David covers, to encourage interest from as wide a range of people as possible. * What YAPC is. * Who Joe Celko is. * Joe Celko's body of work. * Why we still need to know SQL in the age of ORMs. I was reminded of this while going through Chad Fowler's excellent [*The Passionate Programmer*](http://www.pragprog.com/titles/cfcar2) in preparation for [our webcast "Radical Career Success in a Down Economy"](http://www.oreillynet.com/pub/e/1360) next week. One of Chad's big points is "Your skills are not self-evident." It's not enough to do great work at work, but you must also let people know about what you've done, specifically your boss. The same is true of your open source projects. Why do people use [ack](http://betterthangrep.com)? It's useful, but how do people know about it? I talk about it, and I tell people why they should use it on its home page, in a section called "Top 10 reasons you should use ack." If someone asks you about your project, can you explain its awesomeness, and why he should use it? If not, why are you bothering? And if you can, are telling everyone you can about it? If not, why are you bothering? For more on writing interesting announcements, please see the Perlbuzz [How to contribute](http://perlbuzz.com/how-to-contribute.html) page.

Discourse on the Net is tough enough without lowering yourself to pointless name calling. The Free Software Foundation ought to know better, especially when their work is so important. Today John Sullivan posted a story about problems the FSF has with Amazon's release of the Kindle source code yesterday. Their three main issues are: - Not all the code is included. - Changes to Kindle code do users no good because users cannot legally update their devices - Important features remain secret. The article is well-thought out, and clearly makes the three points. It would be a fine article if not for the insulting headline: [No, Amazon did not release all of the Swindle's source code](http://www.fsf.org/blogs/community/kindle-swindle-source-code). Why, FSF? Your article stands on its own, so why sling the mud? Why lower yourselves to juvenile name-calling? What do you hope to gain by calling the Kindle the Swindle? Are we to think "Ho, ho, those clever FSF folks!" I can't imagine. Relatedly, please read Roger Ebert's article ["The O'Reilly Procedure"](http://blogs.suntimes.com/ebert/2009/06/the_oreilly_procedure.html) on the lowering of the standards of debate in our society.

[Masak's recent post on use.perl.org](http://use.perl.org/~masak/journal/39090), called "How can we scale kindness?", boils down my frustration with anti-helpful behaviors like geek pissing contests, [telling newbies "RTFM"](http://perl.plover.com/yak/12views/samples/notes.html#sl-33) and [calling people "fuckhead"](http://petdance.com/perl/geek-culture/). > Every day, we contribute to shaping our community. By extension, I think it's fair to say that allowing anti-helpfulness to stand unanswered is part of shaping our community. I might even expand it to say: > Every day, through action and inaction, we contribute to shaping our community. I understand that every community will have jerks, and the Perl community is no different. However, it's possible to balance the bad signal with good. Answering hostile behavior doesn't have to be, and in fact shouldn't be, a flame war. Instead, bypass the damage of the hostile participants and address the topics as they should be. If a newbie in IRC asks a "dumb" question, and is beaten down by the regulars in the channel, go ahead and answer the question for him. It's a far better response than ragging on the beaters. How do you handle the negative in the Perl community?

If you use Vim for your Perl programming, here's a new project and mailing list you might be interested in. A few months ago I became the maintainer of the syntax/perl.vim file that comes with vim. I started a [github project for it](http://github.com/petdance/vim-perl/tree/master) for maintaining the perl.vim file, and for starting to get a perl6.vim file together that could be put into the vim core as well. There are a couple of versions of perl6.vim and I need to make sure we get the latest/greatest to Bram for inclusion. Now that github added capability for issue tracking, there's now a [vim-perl issue tracker](http://github.com/petdance/vim-perl/issues), and I created a [Google group for vim-perl](http://groups.google.com/group/vim-perl) as well. This project + group are not intended to be just about the .vim files. I want to discuss all aspects of using Perl and Vim together, so join in and share your tips and ideas. If there are any Emacs, Eclipse, etc equivalents, let me know so I can post about those, too.

Piers Cawley has a great article explaining [what happens at a hackathon](http://www.h-online.com/open/What-happens-at-a-hackathon--/features/112997), using the Perl QA Hackathon in Birmingham as the example. This is the second great article that Piers has written about Perl and its culture for the general masses, after ["Healthcheck Perl"](http://www.h-online.com/open/Healthcheck-Perl-The-Perl-Future--/features/112388) back in January. Thanks, Piers! The hackathon was a who's who of QA folks: Ricardo Signes, Michael Schwern, Andy Armstrong, Curtis Poe, Adrian Howard, David Golden, Michael Peters, Jon "JJ" Allen and Antonia Mayer. Makes me wish I'd been there! Ricardo has his own write-ups on the hackathon at ["An overview of the Metabase"](http://rjbs.manxome.org/rubric/entry/1742) and ["Look back at the Perl QA Hackathon"](http://rjbs.manxome.org/rubric/entry/1741).

There have been a number of posts today for Ada Lovelace Day, honoring women in computing. * Tim O'Reilly posts about [the women at O'Reilly](http://radar.oreilly.com/2009/03/ada-lovelace-day-at-oreilly.html) who make things happen. If it weren't for Edie Freeman, we wouldn't think of the camel and Perl. * Nat Torkington highlights three women, including Perl's own Allison Randal, in [Ada Lovelace Day ABC](http://radar.oreilly.com/2009/03/ada-lovelace-day-abc.html). Brenda Wallace gets a shout-out as well. Brenda's not known for public Perl contributions, but she's well-known as a driver of the Perl community in New Zealand. * Casey West honors Audrey Tang, who should need no introduction. [Casey's blog post](http://caseywest.com/2009/03/24/ada-lovelace-day-audrey-tang/) gives the briefest of summaries of some of Audrey's amazing achievements. * Hundreds more at [http://findingada.com/](findingada.com) I'd like to call out a few more Perl people while we're at it: * Skud (Kirrily Robert) who helped me start Perlbuzz, is at the top of the list. If you've ever used [WWW::Mechanize](http://search.cpan.org/dist/WWW-Mechanize) instead of dealing with the inner workings of LWP, thank Skud. * Jacinta Richardson is half of [Perl Training Australia](http://perltraining.com.au/). Together with Paul Fenwick, they are a huge force in the Perl community in that corner of the world. My understanding is that their marvelous [Perl Tips newsletter](http://perltraining.com.au/tips/) comes from her. * Elaine Ashton was instrumental in getting the CPAN going, and keeping it going today. * Ricardo Signes rattled off names to me: [Jess Robinson](http://search.cpan.org/~jrobinson/), Karen Cravens, [Liz Cortell](http://www.slideshare.net/zrusilla/pulp-perl), [Beth Skwarecki](http://bethskwarecki.com/about/) and "[Elizabeth Mattijsen](http://search.cpan.org/~elizabeth/) who is TOTALLY badass." Perhaps he'll comment to fill in the details. I'd like to also steal a bit from Tim O'Reilly's article as well. He said:

My first hat tip has to go to my wife, Christina O'Reilly. She's a playwright and choreographer, not a techie. But if you've been influenced by me, you've also been influenced by her.... [S]he's been part of everything I've ever done, in the same way that Elizabeth Barrett Browning said of her husband, Robert Browning: "What I do and what I dream include thee, / As the wine must taste of its own grapes"

In the same way, let's remember our spouses, partners, and other special women in our lives, starting with Larry Wall's wife Gloria, who you've probably seen at Perl conferences keeping things together for the clan. Whenever you see the work of someone like Josh McAdams, Ricardo Signes, or Casey West, you've got a Heather McAdams, Gloria Signes and Chastity West, and the rest of their families, supporting them. That's community support to remember. Please add your praise of the women of Perl I've forgotten or don't know in the comments below.

In my job as editor of Perlbuzz, I get email all the time asking me to run announcements about all sorts of Perl-related things. They're usually announcements of a new release of some module, or something about an upcoming conference. And usually I don't run them, because they violate the first rule of announcing something: An announcement that says "PerlWhacker v1.5.3 has been released" **is not interesting** to anyone but a small handful of people. The most important part of being interesting is that your announcement has to have an angle. ## Without an angle, there is no reason for the reader to read past the headline The angle is the part of the story that says "This is why this is interesting to you, the reader." There has to be a reason that a story is interesting, not simply a recitation of facts. There has to be a hook, a reason for the potential reader to see a headline, or maybe the first paragraph, and say "Huh, I'd like to read that." Here are some examples. * **Bad**: "Devel::NYTProf version 2.04 got released, here's the change log." **No angle**, very boring, unlikely the reader will pay any attention to the story, if she even clicks it in her feed reader. * **OK**: "Devel::NYTProf v2.04 got released, and it now uses 90% less disk space by using the Zlib compression library." **Sort of interesting**, because the reader can say "Huh, that sounds like a cool hack. Still, what's the effect on the reader? * **Good**: "Devel::NYTProf v2.04 got released, and it uses 90% less disk space, because Nicholas Clark was trying to run NYTProf on the entire Perl test suite and ran out of disk space, and he worked with Tim Bunce on a patch." **That's an angle** because it tells a story that the reader can relate to. * **Great**: "Devel::NYTProf v2.04, and it uses less space, because Nicholas Clark was running the Perl test suite against it, and here's a link to the findings from that research." **Bingo**! ## Assume that the reader knows nothing about what you're announcing. Finally, you must assume that the reader doesn't know what you're talking about. Most of the announcements I see are announcing to a small group of people who are aware of what is being announced, simply notifying that group that something has happened, excluding the readers not yet in the know. I'm going to pick on the announcements for Summer of Code, both because they're excellent examples of how to exclude readers, and because I want the GSoC to succeed wildly. That's why I took the time to [revamp the announcement](http://perlbuzz.com/2009/03/get-paid-for-working-on-perl-projects-in-google-summer-of-code-2009.html) when I ran it last night. The original announcement that Eric Wilhelm ran is this:

The Perl Foundation has been officially accepted into the Google Summer of Code 2009 program as a mentor organization!

Hopefully some of you have identified some potential students already. Now we need your help getting them to submit their proposals.

http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html

The student application period begins Monday, March 23rd and runs through April 3rd. (Students note: you can edit your proposal throughout that 11-day period -- getting it started early and talking to potential mentors greatly increases your chances vs throwing it over the wall at the deadline.) See this page for details:

http://code.google.com/soc/

Interested students and potential mentors, please read the GSoC info on the Perl wiki:

http://www.perlfoundation.org/perl5/index.cgi?gsoc http://www.perlfoundation.org/perl5/index.cgi?gsoc_2009_projects

If you're interested in mentoring or have a good project suggestion, now is the time to get your info up on the wiki so students will know about your code and where to find you.

Eric has done a ton of work for GSoC this year and last, and it's safe to say that the Perl involvement GSoC wouldn't be as great, in fact might not even exist, without Eric's work, so this is no knock on Eric. But this announcement has some huge failings, and it leaves questions in the mind of the reader who doesn't know what GSoC is. * What is Google Summer of Code? * Why is it interesting that TPF is a mentor organization? * Why do I care about it? * What's in it for me, the reader? * What is a student? * Why would a student want to join GSoC? * What is a mentor? * Why would someone want to be a mentor? In short, Eric wrote the announcement for the people who already know what GSoC is, and excluded the other 90% who don't. [Jonathan Leto's announcement](http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html) has the same failings. It makes sense why Eric and Jonathan wrote they way they did. They've been busting their asses for weeks (months?) working to set things up. They've been working inside the echo chamber of other people that are involved in the project. The parts of the project in the forefront of their minds are the details like how to sign up and how to write a proposal. However, to someone unfamiliar, it's noise until he knows the overview. ## Get people to read your words Whether it's an announcement of your software, or a resume, or a posting in your blog, you have to give the reader a reason to read what you've written. When writing, we tend to focus on the details of the text, expecting that the reader will consume our every word. Problem is, people aren't like that. We skim. We read titles. If it's not interesting we move on. In [my book on job hunting](http://www.pragprog.com/titles/algh/land-the-tech-job-you-love), I hammer home the idea that without a compelling summary at the top of your resume, the reader is not going to spend much time digging the good stuff out of your bullet points at the bottom. It's the same rule with announcements about your software project. Next time you're going to announce something, show the announcement to someone who is not involved with the project, maybe a co-worker or your spouse. Ask him or her to explain what you're announcing. Try to understand how your article sounds to someone unfamiliar with it. Your project's success may rely on it.

Each year, [Google Summer of Code](http://code.google.com/soc/) puts hundreds of students to work on open source projects, and pays them for it. The Perl Foundation is proud to announce that it has been accepted as a sponsoring organization this year. Students propose projects that they'd like to have funded, and are assigned a mentor who will help guide the student and project to completion. For students, this is a great way to contribute to open source, get experience working on real projects that you can put on a resume, and get paid for it. You'll be helping open source while helping yourself. For mentors, you'll also be helping open source, and helping a new programmer get his or her start. Jonathan Leto's blog has [links to find out more](http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html).

At the nudging of some users, I've gone back and fixed up some bugs in long-untouched modules, and at the same time moved their repositories over to [github](http://github.com), which I am enjoying more every day. Template::Timer fixes a bug that's been around since 2005 during installs. Perl::Critic::Bangs was doing invalid testing that meant breakage with the new 1.098 release of [Perl::Critic](http://search.cpan.org/dist/Perl-Critic).

Rakudo Perl, the implementation of Perl 6 on the Parrot virtual machine, has made [a milestone release](http://use.perl.org/~pmichaud/journal/38562). For years now, Rakudo has been tucked into the Parrot project, but no longer. Rakudo is now its own project, with its [own source repository](http://github.com/rakudo/rakudo) and its own release schedule, following the Parrot release schedule closely. This 14th development release of Rakudo is codenamed Vienna, after Vienna.pm, the Perl Mongers group that has been sponsoring Jonathan Worthington's development work since April 2008. Future releases will be named after other Perl-related cities. This is a fantastic time to take a look at Rakudo and see what's happening. We're reaching the top of the hill, and I couldn't be more excited.

I got errors on my Mac today complaining about IO.pm. I had just installed Parrot on the way to building up a Rakudo to work on, so I figured something in the still-not-ironed-out Parrot install had caused the problem. It looked like this:

% perl -MIO
IO object version 1.22 does not match bootstrap parameter 1.23
at /System/Library/Perl/5.8.8/....

I just figured I'd reinstall the module.I tried to update IO.pm, but the CPAN shell uses IO, and so barfed. Had to install it manually by downloading a tarball (gasp!) and doing it manually. And then everything was fine.

And then my old colleague Ed Silva IMs me asking if I knew anything about it. I had to confess I was surprised to see he had the same problem.

And now Miyagawa, bless his heart, lays it all out for you in this blog post about the Mac OS X security update. Ooopsie!

Thanks to Miyagawa for explaining the problem.

I just gave [my keynote at Frozen Perl](http://www.slideshare.net/petdance/frozen-perl-2009-keynote), and one of the big points I made was that we don't know what Perl 6 is going to look like. It's totally a green field. There's no toolchain, no LWP, no DBI, etc. My big question: Should Perl 6 use the CPAN? Does an 11 year-old distribution system make sense in 2009? In 1998, when we didn't have everything living in a cloud, and hosting websites took a lot of money, and if you wanted massive bandwidth, you were at a big company or a university. In 2009, those are no longer true. Of course, I'm not suggesting that we don't distributing thousands of excellently awesome modules to the world. If we didn't, we wouldn't be Perl. But does it need to be through a centralized distribution channel like PAUSE + CPAN? I don't have an answer. Discuss.

Jeffrey Thalhammer has posted about how the [immensely helpful Perl::Critic](http://search.cpan.org/dist/Perl-Critic) system [needs some help](http://perlmonks.org/?node_id=736290) slogging through its backlog of bug tickets. If you're a user of Perl::Critic, please consider pitching in and helping close some tickets. If you're not yet a user of Perl::Critic, today's a great day to start. I hope you love it as much as I do.

Perl 5's source code is no longer locked into the odious proprietary Perforce repository where it's been hosted for years. It's now hosted in the git distributed version control system. This is a huge win. [The announcement](http://use.perl.org/article.pl?sid=08/12/22/0830205) lists a number of benefits: - With a public repository and Git's extensive support for distributed and offline work, working on Perl 5's source becomes easier for everyone involved. - Because Git is open source, all developers now have equal access to the tools required to work on Perl's codebase. - Core committers have less administrative work to do when integrating contributed changes. - Developers outside the core team can more easily work on experimental changes to Perl before proposing them for inclusion in the next release. - A vast array of improved repository and change analysis tools are now available to Perl's developers. - The new Git repository includes every version of Perl 5 ever released, as well as every revision made during development. Before this move, if you wanted to submit a patch to Perl 5, you had to submit the patch against bleadperl, the main development branch, which was an always moving target. The repository wasn't directly available, so you had to either keep your own repository that got updated with patches as they were applied, or just deal with your local changes getting stomped on. Now, that's all over. It's butt simple to get the Perl source:

$ sudo yum install git
(Your package manager may vary)
$ git clone git://perl5.git.perl.org/perl.git
(Time passes as much downloading happens)
$ ls
AUTHORS       configure.com    perl.h
Artistic      configure.gnu*   perl_keyword.pl
Changes       cop.h            perlapi.c

That's it. Now you have a copy of everything, and can make patches much more easily. Thanks to Sam Vilain and everyone else involved in this huge move.

[Booking.com](http://booking.com/), a global hotel reservation service based in the Netherlands, has [donated $50,000 to the Perl Foundation](http://www.hsyndicate.org/news/4039070.html) to help in further Perl development, specifically Perl 5.10. As Richard Dice, president of TPF says, "booking.com has demonstrated extraordinary vision and community spirit," but they also know that their infrastructure needs ongoing support. Their IT team is 50+ persons, and Perl is the "language of choice." Thanks to booking.com for this donation, and let's hope it is part of an ongoing trend. Now, if only TPF could get, say, $5 from every company that used Perl. Think how many programmer-years that could buy to help get [Rakudo](http://rakudo.org/) out the door.

[Max Kanat-Alexander](http://max.kanat.us/) posted an article called ["How Not To Get Hired."](http://avatraxiom.livejournal.com/95669.html). Since I'm in the end stages of finishing [my book on geek hiring](http://oreilly.com/catalog/9781934356265/), I was hoping there would be swell interview horror stories. The first bullet talks about not following instructions in a job ad, but the rest is really a laundry list of Perl practices that nobody should be doing any more, and a few more on what we should be doing, starting with using Moose. I'm sure there'll be some crabs out there who say "Aw, that's just all common sense," but common sense rarely is. It's well worth a read.

Perl 5.8.9 is [available for download](http://search.cpan.org/dist/perl-5.8.9/). From reading the changelog, it doesn't seem like there's too much earth-shaking in it. There is a wonderful new utility added. An analogue to *perlbug*, the [new *perlthanks* program](http://search.cpan.org/~nwclark/perl-5.8.9/pod/perl589delta.pod#perlthanks) lets you send your thanks to the development team. What a great idea that is.

In addition to the yearly [Perl Advent Calendar](http://www.perladvent.org/2008/) from Jerrad Pierce, originally started by Mark Fowler, the Catalyst Team have put together their own [Catalyst Advent Calendar](http://www.catalystframework.org/calendar/). Each calendar gives a new tip or trick or module to use each day. [Today's tip](http://www.perladvent.org/2008/8/) on the Perl Advent Calendar is about how to use IPC::Filter to communicate between processes, while [yesterday's entry on the Catalyst Advent Calendar](http://www.catalystframework.org/calendar/2008/9) discusses how to create PDFs for your web application.