Slashdot Mirror
Writing Perl Modules for CPAN
Besides Perl's abilities as a rapid development language, it's widely believed that the CPAN is its most valuable feature. This network of freely distributable code allows competent developers to achieve great heights of productivity, reusing the work of a generous community of programmers.
Of course, just as some will argue that Perl's copious documentation (spread over two thousand pages) is not immediately obvious to beginners, neither is how to use and even to contribute to the CPAN. For every coder who's successfully published a module, how many more would jump at the chance? How many registered CPAN authors would like to improve their skills?
With that audience in mind, Sam Tregar's Writing Perl Modules for CPAN plants itself firmly in the gap between novice and intermediate user. While much of the book presents information present in a multitude of FAQs, manpages, and the bittersweet experiences of those of us who did things the hard way, he's collected much knowledge into a short and readable guide.
What's to Like?Tregar starts by describing the history and usage of the CPAN itself. This includes the three most popular approaches to building modules: through the CPAN shell (including its configuration), by hand, and with ActiveState's PPM tool. Next, he explains module development in forty pages. This is pretty dense stuff for the intended audience and might require several passes by newer coders. Only after re-reviewing the chapter for this summary did I realize how much he covered. The next chapter covers design and style, from naming schemes to appropriate laziness through code reuse. It's more philosophical and more important.
The next two chapters cover bundling and submitting modules to the CPAN, as well as being a good author and maintainer. The general tone is quite similar to the impressive Open Source Development with CVS. While manpages usually describe the mechanics of making a distribution, for example, they rarely explain the reasons why things are done that way. As with previous chapters, several code examples illustrate the concepts under discussion.
After a brief chapter discussing a few very effective CPAN modules, Tregar dives into XS (the interface between Perl and C). In 60 pages, he describes just enough of XS and the Perl API to teach careful programmers how to be effective at extending Perl. This introduction compares favorably to the first few chapters of the new (and excellent) Extending and Embedding Perl. As expected in an overview, he provides links to more information. The writing and example style is clear enough that a decent coder with sufficient C knowledge should be able to write a Perl wrapper to a C library with relative ease.
The last two chapters describe Inline::C, an abstraction layer that makes XS much easier, and CGI::ApplicationC, a state machine framework for Perl CGI applications. It's not quite clear why the last chapter was included (besides Tregar's desire to see more CPAN modules extending CGI::Application), but it serves as an example of using and extending a CPAN module. Perhaps a future version of the book will elaborate further.
What's to ConsiderThe book's code samples are generally good. In the first half, they are all related parts of a larger project. The rest of the book moves away from this approach. Perhaps it would have been worthwhile to continue the theme, though the nature of the material makes it difficult to see exactly how to accomplish this.
Tregar also avoids the use of strictures and warnings in his code examples, claiming that they would make the examples too verbose. I disagree with the given reasoning -- teaching is the best time to enforce good habits, especially when encouraging the students to distribute their code to the world. This is a minor issue, though, as the code is readable and reasonable.
In the past few months, two projects have gained a great deal of momentum in Perl space. These are the CPANPLUS (disclaimer: I am contributing to this project and have contributed to CPAN.pm) and Module::Build. They may become the new standards, replacing CPAN.pm and MakeMaker as early as Perl 5.10. The book omits mention of these. This is understandable, given the time frame -- and the current tools will not be disappearing any time soon. Potential replacements for h2xs are described in a sidebar, though.
The SummaryThis is a readable book. It took only a couple of hours to read (though I'm assuredly not the target audience), and is well packed with good advice. Fresher Perl programmers who aren't yet comfortable enough with packages and interfaces will get the most benefit, but there's plenty of information for intermediate hackers as well.
Table of Contents- CPAN
- Perl Module Basics
- Module Design and Implementation
- CPAN Module Distribution
- Submitting Your Module to CPAN
- Module Maintenance
- Great CPAN Modules
- Programming Perl in C
- Writing C Modules with XS
- Writing C Modules with Inline::C
- CGI Application Modules for CPAN
You can purchase Writing Perl Modules for CPAN from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Stop with all this Perl nonsense, janitors!
Can't you see Perl is a big waste of time, and that there are better choices for *every single application area* where perl is hyped?
Come on, do we really want modules from people who can't figure out how to do it without reading a book about it???
1) Try to remember the command for accessing CPAN. It isn't cpan--that would be too easy.
2) Run it.
3) Realize that, because you aren't in the ivory-tower college environment, you will need to figure out the difference between "firewall" and "proxy" settings, both of which work differently, if they work at all.
4) Figure out how to search for a module.
5) Request module be downloaded
6) Wait for module download to timeout so it moves to the next site (you may have to do this a few dozen times)
7) Tell module to install itself
8) Reinstall Linux because module hosed your system.
EAT MY SMEGMA, COCKGOBBLERS
Myth: Slashdot moderation is not censorship. If it were censorship you would not be able to read the down moderated posts. Yes, it makes it harder to read these posts.
Fact: Slashdot moderation is a form of censorship. An example: A totalitarian government shuts down all the newspapers that won't conform to its agenda. This forces the shut down newspapers to resort to less effective methods such as distribution of photocopied fliers. Yet, the government could argue that they're not censoring the press because you can still read the fliers. It's only harder to read those news.
Why does CSPAN need Perl modules? oh wait.....must get new glasses!
I wonder if anyone would be interested in a Slash::Troll module?