• “Higher-Order Perl” available for free download

    Mark-Jason Dominus' fantastic book *Higher-Order Perl* is now available for free download at [http://hop.perl.plover.com/book/](http://hop.perl.plover.com/book/). MJD notes: > This is better than the bootleg copies available from download sites in at least three ways: > > - It is the complete text of the second printing, which incorporates many minor corrections; the bootleg copies are all bootlegs of the first printing. > > - It does not have a nasty little grafitto advertising a vainglorious bootlegger plastered on every page. > > - It was come by honestly, not stolen from the printer. Everyone is now out of excuses for not having read it. Go read it now if you have not. You will not be sorry.
  • CPAN Testers gives module authors new flexibility

    The CPAN Testers group do some pretty cool work. According to the group itself, they are > ... a group of over 100 volunteers who test as much of > CPAN as possible across a plethora of Perl versions and operating > systems, which is usually many more environments than authors have > available to themselves. Don't write for Windows, and don't have [access to a Windows VM courtesy of Microsoft](http://perlbuzz.com/2008/12/microsoft-will-support-cpan-authors-with-free-access-to-windows-machines.html)? At least the CPAN Testers will send you the error report from a failed attempt to build on Windows. The downside of CPAN Testers is that you may not care about certain configurations. If one of the CPAN Testers mistakenly tries to build Win32::OLE on a Mac system, the author of Win32::OLE isn't going to be very interested. Along those same lines, if your module for Perl 5.8 doesn't degrade nicely for 5.6 or earlier, then you're going to get error reports as well. Now, [the CPAN Testers site gives authors flexibility](http://stats.cpantesters.org/updates.html#December2008b) in how they'd like to tests on their modules reported. I can specify which types of reports (pass, fail, NA, etc) I get, and on which versions of Perl I'm interested. I can set up a default profile and then set up per-distribution profiles as well. It's fantastic. Anyone who is doing CPAN modules should take a look at [this excellent service](https://prefs.cpantesters.org/) and its new customizations. Thanks to the CPAN Testers for making it available.
  • Cool vim plugin of the day: surround.vim

    The always amazing Peteris Krumins is starting a series of blog postings on cool plugins for vim, starting with [this post about surround.vim](http://www.catonmat.net/blog/vim-plugins-surround-vim/). Just reading the article about the "old way" to do what surround.vim does was informative, showing me vim tricks I didn't know. Seriously, anyone who reads Mechanix should have [Peteris' blog](http://www.catonmat.net/) in her syndication reader.
  • Microsoft will support CPAN authors with free access to Windows machines

    [Adam Kennedy's announcement](http://use.perl.org/~Alias/journal/38036) tells the long story, but the short version is this: Microsoft will be providing every CPAN author with free access to a centrally-hosted virtual machine environment containing every major version of Windows. It will be interesting to see how this plays out. Will CPAN authors use the resources from Microsoft to make sure that our modules work on Windows? I know that I'm especially interested because I want [ack](http://search.cpan.org/dist/ack/) to be transparently cross-platform. Anything I can do to help get ack out on Windows boxen, to help Windows programmers know that the command-line can be better than an IDE, is a win. This is pretty big, and I'm glad to see Microsoft providing this service. I'm especially thankful for Adam putting what I'm sure was a huge number of hours making this happen. I'm glad we have him on our side.
  • Moving forward with Git and Perl

    *By Nadim Khemir* Perl is very often used as glue to quickly put together a functionality by using already existing components. This is a great use of Perl. Still, I believe that we made a mistake, a few years ago, when we kept being the glue instead for also becoming part of the componnents; this is one of the main reason Python took off, developers learned Python, an otherwise excellent language, to control and integrate into their favorite applications while Perl was still on the outside. I wish Perl was an intrinsic part of more applications. Among the applications that have Perl bindings, [Git](http://git.or.cz/) is a very interesting one. There is a lot of interest for Git in the Perl community. This is partly due to Perl 5's source code going over to Git. [Pages](http://www.perlfoundation.org/perl5/index.cgi?git) like [this](http://www.perlfoundation.org/perl5/index.cgi?perl_git_repositories) on the [Perl 5 wiki](http://www.perlfoundation.org/perl5) tell us that "Like Perl, Git has lots of flexbility, TIMTOWTDI" this matches The way most Perl developers think and may be why a lot of Perl developers are switching to Git. Git is easy to learn. Simple things are simple and complicated things possible. Rings a bell? There are many Perl developers involved in Git. Randal Schwartz even made [a presentation on git](http://www.youtube.com/watch?v=8dhZ9BXQgc4), and we've seen [articles here on Mechanix](http://perlbuzz.com/mechanix/2008/09/git-is-my-hero.html). And there are multiple modules on CPAN to handle Git-related functionality. The Git community itself has a Git.pm module that is part of the Git distribution. Git.pm needed some love and I am taking over its maintenance. My hope is to help the Git community and the Perl community as well. ## What's in it for the Git and Perl community? * Involvement of the Perl community in the Perl component distributed with Git * A closer cooperation. * Making Perl developer aware of version control systems. * Unify, if wished for, the multiple Git modules of CPAN (other are under construction but not on CPAN yet), this would be better for maintenance and for the users. * Not directly related but a wish, a CPAN with better versioning strategy. * What _you_ need (but you have to tell us. I'll be happy to get input from the Perl community, at nkh@cpan.org, in the form of comments, and patches) Jakub Narebski has written an [RFC for the Perl bindings](http://www.spinics.net/lists/git/msg86056.html) for the Perl bindings. This is an excellent stating point. *[Nadim Khemir](http://search.cpan.org/~nkh) is a technical manager and architect at Ericsson Mobile Platform in Sweden. His favorite subjects are process automation and build systems. He can be contacted at nkh@cpan.org and is often seen on #perl-qa.*
  • Lightning talks from outside the echo chamber

    I'm already tired of the hoohah about "Perl 5 is dead" and the hand-wringing and the useless flapping about what we should do. I'm more interested in what is going on in Perl that none of us have heard of yet. If I didn't have family and book obligations, I'd gladly take two days off and an 18-hour round trip to Omaha, Nebraska to check out the lightning talks presented by the University of Nebraska at Omaha on Tuesday. [Robert Fulkerson](http://www.cs.unomaha.edu/faculty/people/fulkerson.html) [posted to the Omaha.pm list](http://mail.pm.org/pipermail/omaha-pm/2008-December/001955.html): > The Fall 2008 UNO CSCI 2850 (Programming on the Internet) class > invites you to an evening of lightning talks on Perl programming, > the Firefox web browser and other (mostly) web-related topics. > > Lightning Talks are no longer than 5 minutes and can be about > anything: a new idea, an evaluation, an observation, a story, a > complaint, an explanation, a suggestion, a report of success or > failure, a call to action, a description of a technique, technology, > or a lament. > > Usually we split the talks over two nights, but this semester it's going to be one, big solid night of talks. > > Where: Peter Kiewit Institute, Room 252 ( http://tinyurl.com/5g83cb ) > When: Tuesday, December 9th, 2008 > Time: 6:00 PM until 8:30 PM > > Topics > > * Writing a Greasemonkey script for FireFox to make BlackBoard tolerable > * Obfuscating Perl > * Connecting Perl to databases > * Net::SSH::Expect > * Using BioPerl for sequence analysis > * Perl Google APIs > * Acid Test 3 > * Gossamer Forum > * Perl vs. Python > * Index a website starting with a single page > * Dictionary attack using Perl > * iTunes playlist extractor: C++ vs. Perl > * Regex Creator > * Regex Coach > * History of Perl > * Software Pirating Debate (Spore, SecuROM) > * Perl 6 vs. Perl 5 > * Rapid Exploit Development using Perl > * SSH on iPod Touch > * Regex usage in Perl vs. C > * Ubuntu with Conky > * Perl-XML: XML Made Easy with Perl! > * Perl Module - GD::SecurityImage > * Gmail:Checker module > * Improving Perl program efficiency/performance > * Subversion Tortoise client search > * Perl PayPal APIs > * JQuery UI > * Talking to LCD projectors using Perl "Talking to LCD projectors using Perl"? "Rapid Exploit Development using Perl"? "Perl 6 vs. Perl 5" by someone who (I assume) is not part of the core group? Someone get this on tape and YouTube 'em, willya? I would *love* to be there. (Plus, then I could go get some [Valentino's](http://www.valentinos.com/) pizza).
  • Database access in Perl 6 is coming along nicely

    [Simon Cozens](http://simon-cozens.org/) just [posted to the Perl 6 internals list](http://www.nntp.perl.org/group/perl.perl6.internals/2008/12/msg49626.html): > I just ran this code, which worked with the expected results: > > use DBDI; > my $conn = DBDI::DriverManager.getConnection( > "dbdi:SQLite3:test.db", "", ""); > my $stm = $conn.createStatement(); > my $rs = $stm.executeUpdate("CREATE TABLE foo (bar, baz)"); > my $stm = $conn.prepareStatement( > "INSERT INTO foo (bar, baz) VALUES (?, ?)"); > $stm.setColumn(1, 123); > $stm.setColumn(2, "Thingy"); > $stm.executeUpdate(); > > Merry Christmas, > Simon I love the smell of progress in the morning.
  • There is no “best” in software

    Dave Rolsky wrote a [fantastic article](http://blog.urth.org/2008/12/the-many-axes-of-software-development.html) on the many different criteria on which you can choose your software to use. For example: > # Easy to integrate - Some libraries are designed to be integrated with other modules (Catalyst), some want you to embrace their world (Jifty). > # Complete - Some libraries come with a complete solution (Jifty) and some require you to put together a bunch of pieces into a whole (Catalyst). Which is better? The answer, of course, is "it depends." Is the project for in-house use, or will it be distributed? Is it a one-off, where the base install will do most of what you want? Or are you likely to want to extend beyond those constraints? Most importantly, Dave points out: > I'd like to see people state their priorities up front, and explain why it's important for the work they do. Often this gets left out of the discussion. Without this information, we often end up just talking past each other. The extension of that is that many people may not even have thought about what their priorities are. Consider how often you'll see a question, such as at Stack Overflow, that asks ["What's the fastest way to do X?"](http://www.google.com/search?q=site%3Astackoverflow.com+fastest+way) Most of the time, the querist hasn't even thought about that "fastest" part; it's just assumed. (For that matter, that's like assuming that the most important part of a new job is how much it pays, but that's a topic for [another blog](http://theworkinggeek.com/).) Make sure you know what your priorities are. Question your assumptions. Your project will thank you for it.
  • Perl gratitude, 2008

    This year, I'm only listing a few Perl things I'm thankful for (still have to make corn souffle for dinner!), and I leave it to you, the Perlbuzz readers, to tell me yours. [Here's last year's list](http://perlbuzz.com/2007/11/perl-gratitude-2007.html). ## Devel::NYTProf I know, I talk about Devel::NYTProf a lot, but it's such a huge leap forward in technology for us. I love love love it. ## Web414 & Bucketworks I'm about as far from Milwaukee as I am from Chicago, and [Web414](http://www.web414.com/) is a great community of people. It's not all Perl, and not all programmers for that matter, but I'm glad they're there. I'm especially glad for [Bucketworks](http://www.bucketworks.com) and the amazing space they have there. If Pete Krawczyk (see below) and I organize another hackathon, it'll be at Bucketworks. ## Ricardo Signes Is there anything Ricardo doesn't work on? He's [Mr. Email](http://video.google.com/videoplay?docid=7054401183589794595), he's got an [assload of modules on CPAN](http://search.cpan.org/~rjbs/), and now he's trying to [replace Module::Starter for module maintenance](http://perlbuzz.com/2008/10/distzilla-eases-management-of-your-cpan-distributions.html). Someone out in Pennsylvania needs to buy him a beer for me. ## Pete Krawczyk Besides being a relatively unsung guy who makes a lot of things happen, like being instrumental in organizing two YAPCs and a hackathon, Pete happens to be physically close by most of the time, usually in a cube kitty-corner from me, and I can bounce all my crazy-ass ideas off of him. He's one of those people who doesn't get the spotlight, but makes things happen behind the scenes. ## The Parrot team I'm very excited about the progress that Parrot is making, [hurtling to version 1.0](http://perlbuzz.com/2008/11/parrot-10-will-be-out-in-march-2009.html). It's the basis of Rakudo Perl, but it also will help bring Perl culture out into the open again. ## You I'm thankful for you, the Perlbuzz reader, because you're going to let everyone else know, either here or in your own blog, what you're thankful for in the world of Perl this year. Happy Thanksgiving to all, and I can't wait for my post-turkey nap.
  • CPAN Testers considered useful

    *By Sébastien Aperghis-Tramoni* The [CPAN Testers platform](http://cpantesters.org/) has grown up so much in the recent months that some module authors began to publicly badmouth it or some of its maintainers, because they received more FAIL reports than previously. The situation lightened a little with the recent introduction of Barbie's "CPAN Testers Daily Report". This probably still won't be enough and some authors will still be angry. But keep in mind that for one angry author, there are plenty of happy authors. One of them is Ton Voon, maintainer of the Nagios::Plugin module. He recently posted on the [Nagios plugins blog](http://nagiosplugins.org/node/98) to recount how the CPAN Testers were very useful to him for spotting a hard-to-find bug, which only occurs when the test is ran with Test::More 0.86. This is typically something very hard to find for the maintainer of a module, because he naturally searches the bug in his own code, not in the modules he uses. Especially when the module is as trusted and tested as Test::More. This is exactly what CPAN Testers offer: a platform for testing code on more operating systems than the average developer has access to, with more variations of Perl versions than the average sysadmin is willing to install. This is a very good argument to convince co-worker to contribute generic Perl code from $work (or free software written in Perl) on the CPAN: they benefit from a testing platform that they couldn't create at $work, and the Perl users benefit with more useful code. Everybody's winning. And when trying to convince them, there isn't a better way than a tool that graphically summarise the reports as [Slaven Rezic's CPAN Testers Matrix](http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=Nagios-Plugin+0.27) does. It sure needs some polishing (and a shorter URL!), but this tool is extremely useful when a module author has to crawl through too many reports. I think I can speak for Ton Voon and all the happy module authors: to all the CPAN Testers, thank you. We value your reports, you are useful to us. *[Sébastien Aperghis-Tramoni](http://www.ohloh.net/accounts/Maddingue) is a system administrator and Perl expert at [France Telecom Orange](http://orange.fr/), in France, and maintains [several CPAN modules](http://search.cpan.org/~saper/). At Orange, Perl is the language of choice for writing all the backend and monitoring programs that make the stuff work.*
  • When to use JPEG, when to use PNG

    Too often I see web graphics that have been saved as JPEGs, not PNGs, and I cringe. How can I tell? This comic shows the difference.

  • A case for Catalyst

    By Jay Shirley

    Software is like any other product that is depended upon for doing any particular function. Software, vehicles and computer hardware are all simply tools intended for a particular audience; audiences that tend to become polar, enthusiastic and fanatical. Whether it is the car tuning crowd, the overclockers or the Perl hackers, they share the same thing in common: being devoted to something.

    This devotion drives a great number of innovations, and this is where Software really stands out. Particularly amongst the Open Source crowd, where Software is bound with something even more polarizing: Personality

    The merging of software and personality is both a blessing and a curse. People are seldom more motivated than when working with something that feels alive; but to attack or criticize is, by definition, personal.

    The people who are the most knowledgeable to defend, market, recommend (or even attack) are the ones already entrenched. They are part of the personality mesh, and as such it is exceedingly difficult to try to promote and defend a software product without going into the years of positive experiences one has shared with the product.

    This article is no different. I love Catalyst and have used it for years. I will, however, attempt to back up my passion with articles of reason and rational points rather than espouse virtues that are little more than anecdotal.

    To get started down this path, I think it is important to properly frame Catalyst in scope. On its own, it doesn't do much. It certainly doesn't do much well, but Catalyst by itself is really little more than a web server; it is a request handler and dispatcher and sends the response to the client.

    By itself, it fails to talk to a database or handle sessions. It won't even authenticate a user. It has no template system, and no caching. So why does Catalyst have a fanatical fanbase and successful sites with it?

    Quite simply, it's the CPAN.

    The Catalyst philosophy is populist, not dictatorial. A belief that tools should be built to do a specific feature or function, but not require usage of any given tool; granting flexibility to a developer to solve problems the Catalyst community has not thought of how to solve.

    Catalyst doesn't require you to use Template Toolkit or Mason. It doesn't push DBIx::Class as The One True ORM. It lets you pick. It trusts that you are a software developer and you are solving a problem. Catalyst just makes it easy to make your decision, and integrate that solution and start working. Between helper scripts and thin model adaptors (Catalyst::Model::Adaptor), there is virtually no hassle in integrating any CPAN module or custom code directly into your applications. The side-effect of the "trust the user" philosophy, aside from a fantastic framework, is that it is quite simply just that: a framework. It operates and evolves on the principles of synergy alone, striving to make the whole greater than the sum of its parts. A simple goal of striving to make a developers life easier, more productive and deliver higher quality results.

    The results are easily quantifiable. Software development, at its core, is about solving a specific and well-defined problem. The more advanced the software is (in evolutionary, organic growth), the tasks at hand are solved more efficiently, properly and faster. The most significant improvements in development speed and quality come in the form of frameworks and libraries that have been peer reviewed, tested, poked and approved by the fanatical masses.

    This lowers the barrier of entry to solve problems, and in general increases the supply of developers to meet the seemingly inelastic demand of problems that need solving. In effect, there is a framework for everybody, from the novice tinkerer who simply has an itch to scratch to the mathematically minded engineers that operate on puritan principles. Catalyst strives to match the pace of the whole spectrum, which is significant work. It makes the upfront learning curve a bit steeper than it could be. Looking historically over the documentation and tutorials, this will change and the learning curve will be greatly reduced.

    The important thing that every developer, whether extending Catalyst or using just the minimums, Catalyst is simply a tool. Tools in the software sense are different than in the tangible world, they can change shape and function. They can easily be used incorrectly, or adapted and accidentally solve an unexpected problem.

    Catalyst developers understand this, and the goal is to simply develop a robust foundation, particularly in the web application space, to solve problems. How those problems are solved is left up to the developer, though. The Catalyst community, just as the Perl or any other community, has suggestions and opinions but ultimately the responsibility lies on the developer. A core tenant of the Catalyst (and the greater Perl philosophy) is to trust that the developer knows enough to solve the problem. The tool should never impose philosophical beliefs; imagine if a hammer would only hammer specific nails, what problems could be solved then?

    This lack of capability, or rather tools being an obstacle rather than an aid, was what drove Catalyst to grow and evolve. Taking original concepts from other frameworks (like Maypole) and extending those ideas in an open minded fashion, and also to use more modern development practices and factor out common code to be shared outside of Catalyst.

    When Catalyst hit version 5.5 several years ago, the codebase was solid enough to call mature. It was grown up, but not done growing. At this point, the mature development cycle began and rather than a rapidly growing and changing framework, a stable and robust framework was in existence. This started a chain of high-quality (and some high-traffic) sites that were built on Catalyst. There was much rejoicing.

    There are a lot of websites running on Catalyst, for a full list please view the Catalyst wiki.

    Jay Shirley is a Catalyst evangelist, an EPO founding member and just another Perl hacker. He's launched and managed several large scale projects on Catalyst, as well. He is the co-founder of Cold Hard Code, LLC, a company set up to use Perl and open source technologies to spawn quality websites.

  • The evolution of Perl frameworks

    *by [Mark Stosberg](http://mark.stosberg.com/blog)* [In 2006](http://www.perl.com/pub/a/2006/10/19/cgi_application.html), the arena of Perl web frameworks pitted the heavyweight [Catalyst](http://www.catalystframework.org/) against the lightweight [CGI::Application](http://www.cgi-app.org/). Since then Perl's framework options have continued to evolve. While both CGI::Application and Catalyst remain popular, several new options have appeared lately. Here's a quick rundown. **[Titanium](http://www.summersault.com/community/weblog/2008/08/09/announcing-titanium-a-solid-lightweight-web-application-framework.html)** provides CGI::Application and a bundle of recommended plugins with unified documentation and easier installation. Because the underlying components are the same solid ones that have already been in use, it's safe and stable to use, despite the new name. Future plans include providing a download package which bundles the dependency chain, for even easier installation. **[HTTP::Engine](http://search.cpan.org/perldoc?HTTP::Engine)** is Moose-based evolution of the HTTP request object we saw in Catalyst, along with the abstractions to run web apps on various server backends. In short, it focuses on the HTTP parts of the web framework stack. On top of that you can build a complete framework in whatever style you want. **[Mojo and Mojolicious](http://mojolicious.org/)** represent a project lead by Sebastian Riedel, one of the original Catalyst contributors. Mojo is distictive for having no dependencies beyond core Perl. Mojo provides the same kind of low-level HTTP components as HTTP::Engine, while Mojolicious represents one possible complete framework built on top of it. Mojolicious' distictive feature is a new dispatching design in the spirit of Ruby-on-Rails "Routes". I have more [in-depth review of Mojo.](http://mark.stosberg.com/blog/2008/11/review-of-mojo-087-a-new-perl-web-framework.html) Some trends I see: * *Shared infrastructure* -- While Perl frameworks continue to compete at a high level, we continue to collaborate on shared utility modules. Projects like HTTP::FillInForm and Data::FormValidator get used by several frameworks, not re-invented. * *CGI.pm must die* -- While we share some things, HTTP::Engine, Catalyst and Mojo have all invented their own HTTP request object, replacing the function of CGI.pm. Clearly there is an interest is moving beyond this old standby, which crams 172 subroutines into the CGI name space. (CGI::Application remains neutral on this point, outsourcing the query object) * *Potential for convergence* -- A number of CGI::Application and Catalyst plugins are rather similar, but not interchangable. Because they are open source, they are usually easy to port from one framework to the other, but this is not ideal. HTTP::Engine and Mojo are both a kind of "framework for frameworks". I see potential for projects to agree on which backend they use, while providing distinctive experiences for programmers who may want to choose a lightweight framework or a featureful one. The result could be web framework plugins which more widely useful to the Perl community. *[Mark Stosberg](http://mark.stosberg.com/blog) has been using programming Perl for the web for over a decade. He is the Principal Developer at [Summersault](http://www.summersault.com) and maintains several CPAN modules including [Titanium](http://search.cpan.org/perldoc?Titanium) and [Data::FormValidator](http://search.cpan.org/perldoc?DataFormValidator).*
  • Speak up for Catalyst

    By Kieren Diment

    Over the past couple of months, Matt Trout and I have been putting together a book proposal for the Catalyst web framework. We did this because a. we want to publish a book about Catalyst, and b. because a publisher approached us. Now that the proposal is in, the editorial board are concerned that there is insufficient market.

    I've looked at a bunch of statistics (mailing list size, Google hits, IRC channel size, Amazon sales rankings and more) to compare the size of Catalyst to a group of other web frameworks. Catalyst comes out at the bottom of the top of this list, in that it's the least popular of the "big" frameworks - Ruby on Rails, Django and so on. On the other hand, it's clearly an order of magnitude more popular than the small frameworks (Pylons, Turbogears and the like). We also know that Catalyst runs some pretty big streaming media websites, including some that we're a bit embarrassed (NSFW) to talk about. Catalyst is also rumoured to be running the BBC iPlayer.

    Our publisher now has cold feet, and wants to collect more data on the size of the market before they give us the go-ahead, so if you use Catalyst, please answer a short survey for us . My aim is 100 responses (10% of mailing list subscribers).

    The questions are as follows:

    • What country are you in?
    • How many people are on your team?
    • How many of those people are writing code with Catalyst? If there are non Catalyst coders on your team, how many of the whole team would you like to be writing Catalyst code?
    • How many people using Catalyst on your team are subscribers to the Catalyst mailing list?
    • How many people writing Catalyst code on your team use the #catalyst IRC channel on irc.perl.org?
    • What do you see as potential for growth of Catalyst in your organisation? How many people do you think will be using Catalyst in your organisation in 12 months? In 2 years?

    Please email your answers to kdiment@uow.edu.au.

    Kieren Diment is a Researcher at the University of Wollongong in Australia. He uses Perl and Catalyst for the social science research that he does.

  • Devel::NYTProf continues its march of awesomeness

    The mighty Tim Bunce has added yet more cool features in 2.07. Brief summary:

    • Runs on Windows
    • You can now turn off statement-level profiling and just have subroutine-level profiling, for speed's sake
    • Tracks recursion more accurately
    • Subroutine calls made within string evals are now shown in reports.

    Check the full change log for all the details.

    Can we just all please buy Tim a beer for all his work on Devel::NYTProf, and Adam Kaplan for starting it? NYTProf is fantastic.

  • Dist::Zilla eases management of your CPAN distributions

    By Ricardo Signes

    At the Pittsburgh Perl Workshop this year, I gave a lightning talk about Dist::Zilla, the system I am increasingly using to manage my CPAN distributions. I'm using it instead of writing a Makefile.PL, but it doesn't do the same thing as Module::Build or ExtUtils::MakeMaker. I'm using it instead of running module-starter, but it doesn't do the same things as Module::Starter. I've had some people say, "So should I stop using X and use Dist::Zilla instead?" The answer is complicated.

    (Well, actually, for now the answer is simple: probably not. Dist::Zilla is a lot of fun and I really, really appreciate the amount of work it saves me, but it's really young, underbaked, and probably full of bugs that I haven't noticed yet. Still, the adventurous may enjoy it.)

    The idea behind Dist::Zilla is that once you've configured it, all you need to do to build well-packaged CPAN distributions is write code and documentation. If you're thinking, "but that's what I've been doing anyway!" then first consider this: If you are writing =head1 NAMEnnMyModule - awesome module by me then you are not just writing code and documentation. If you are adding a license to every file, again, you are not just writing code and documentation.

    If you use, say, Module::Starter to get all this written for you, then you're safe from writing that boilerplate stuff. Unfortunately, if you need to change the license, or you want to add a 'BUGTRACKER' section to every module, Module::Starter can't help you. It creates a bunch of files and then its job is done. It never, ever looks at your module-started distribution and fixes up things. This also means that if you realize that your templates have failed to include use strict for your last three module-started distributions, you have to fix them by hand. The same goes for the stock templates, which until recently didn't include a license declaration in the Makefile.PL.

    With Dist::Zilla this content is not created at startup. It is not stored in your repository. Instead, the files in your repo are just the code, documentation, and the Dist::Zilla configuration. When you run dzil build, your files are rebuilt every time, adding all the boilerplate content from your current setup. If you want to change the license everywhere, you change one line. If you want to start adding a VERSION header, you tweak the Pod::Weaver plugin's configuration.

    So, there does exist a dzil new command for starting a new distribution. All it really does, though, is make a directory (maybe) and add a stock configuration file. Why would it add anything else? If you want any code, you would only be writing the actual code needed, not any boilerplate, so adding anything would be foolish.

    There's also dzil release, which goes beyond what Module::Starter (and its competitors) do and into the realm of ShipIt or Module::Release. I'm hoping I can integrate with or steal from one of those sort of tools. Right now, it exists, but all it does is build a dist and upload it. In the future, it will have at least two more kinds of plugins to make the release phase more useful: VCS (so it can check in and tag releases) and changelog management. It has a changelog thing now, but it stinks and isn't very useful. In the future, you won't need to edit a changelog. It will be able to read changes out of your commits, or you will just tell it to record a changelog entry. Then the Changes file can be generated as needed.

    For now, I am manually editing my Changes file.

    So, eventually Dist::Zilla could obsolete Module::Starter for people who like what Dist::Zilla does. Then again, people might still want to have starter templates that add minimal boilerplate for using certain frameworks. We'll see what happens.

    Ricardo Signes was thrust into the job market with only a rudimentary humanities education, and was forced to learn to fend for himself. He is now a full-time Perl programmer, maintainer of the Perl Email Project, and frequent contributor to the CPAN.

  • Creating a module distribution with Module::Starter

    As Chris Prather pointed out in Write your code like it's going on CPAN, Perl's module toolchain is getting better every day, and the support for good coding habits can help even if you don't want to distribute your code. However, starting a module distribution from scratch can be a daunting task.

    I wrote Module::Starter a few years ago to make it easy to create a module distribution, but never wrote the kind of basic introduction that it needed. Now, Perl Training Australia has done just that with one of its Perl Tips, Starting a module with Module::Starter. I've already absorbed it into the Module::Starter distribution.

    Module::Starter does happen to be getting a little long in the tooth, and I know that Ricardo Signes, for one, has started his own module creation magic. If Ricardo or any other authors would like to let Perlbuzz readers know about their projects, let me know.

  • Write your code like it's going on CPAN

    By Chris Prather, from his recent blog entry

    One of the things I've discovered recently, and wished I'd known years ago is you need to write all your Perl applications like you were gonna be posting them to CPAN, even if you have no intention of ever doing so.

    At work we are starting to migrate from a legacy system that was written in the grandest of late 90s CGI (the code is clear, easy to read and for this era of script well documented, but lacks any architectural cohesion and has been patched and re-patched over the years to handle new use cases). This system is absolutely core to our daily business. You might even argue that it is our daily business.

    One of my tasks was to add Validation on some of the input parameters. My boss wants to move to something testable so I created a Validation module that contained a bunch of validation functions for the various pieces of data, and when we could easily do so we wrapped CPAN validation modules (Regexp::Common we love you!). This however added a couple of new dependencies to our system. This is where writing it like a CPAN package comes in.

    I added a Makefile.PL for the system. We have no intention of ever releasing this code, but the Makefile.PL uses Module::Install and lists the dependencies. The magic of this is that for recent versions of cpan you can just type cpan . and it will automatically install all the dependencies for the current directory. Failing that you can always run perl Makefile.PL && make && make test and it'll install dependencies and run your test suite.

    By treating code we were never going to release to CPAN as if we were, we win the support of all of the CPAN toolchain. A toolchain that is getting better every day.

    Chris has worked with Perl for 7 years in 3 time zones. He's responsible for Bender on irc.perl.org, and MooseX::POE. He is happy to be back in Florida where it is warm.

  • Using HTML::Table::FromDatabase

    By David Precious

    A task I find myself doing reasonably often when programming is producing a HTML table based on the result of a database query.

    This often ends up with the same kind of boring code being written again and again, which get tedious.

    For example:

    print <<TABLESTART;
    <table border="1">
    <tr><th>id</th><th>foo</th><th>bar</th></tr>
    TABLESTART
     
    my $sth = $dbh->prepare(
    "select id, foo, bar from mytable where something = ... "
    );
    $sth->execute() or die "Failed to query";
     
    while (my $row = $sth->fetchrow_hashref) {
    print '<tr><td>';
    print join '</td><td>', @$row{qw(id foo bar)};
    print "</td></tr>n";
    }
    print "</table>n";
    $sth->finish;

    Not hard, but it does get tedious.

    HTML::Table makes things better by taking out most of the HTML drudgery, but you still need to loop through adding rows to your table.

    This is where my HTML::Table::FromDatabase comes in - it's a subclass of HTML::Table which accepts an executed DBI statement handle, and automatically produces the table for you.

    For instance:

    my $sth = $dbh->prepare(
    "select id, foo, bar from mytable where something = ..."
    );
    $sth->execute() or die "Failed to query";
     
    my $table = HTML::Table::FromDatabase->new( -sth => $sth );
    $table->print;

    Much easier, and HTML::Table::FromDatabase does all the tedious work.

    Sometimes that won't be quite flexible enough though; you might have something you want to do to certain columns or values before outputting them.

    That's where HTML::Table::FromDatabase's callbacks come in handy. For a basic example, let's say that one of the columns you're fetching contains URLs, and you want to wrap them in anchor tags to make them clickable links. Simply done with:

     my $table = HTML::Table::FromDatabase->new(
    -sth => $sth,
    -callbacks => [
    {
    column => 'url',
    transform =>
    sub { $_ = shift; qq[<a href="$_">$_</a>]; },
    },
    ],
    );

    Another example - looking for all cells whose value is a number, and formatting them to two decimal places:

     my $table = HTML::Table::FromDatabase->new(
    -sth => $sth,
    -callbacks => [
    {
    value => qr/d+/,
    transform => sub { return sprintf '%.2f', shift },
    },
    ],
    );

    You can apply as many callbacks as you need.

    As HTML::Table::FromDatabase is a subclass of HTML::Table, all of HTML::Table's options can still be used to control how the generated table appears, for example:

    • -class => ‘classname' to give the table a specific class to help you apply CSS styling
    • -border => 1 to apply borders, -padding => 3 to set cell padding
    • -evenrowclass and -oddrowclass if you want to have different styling for even and odd rows (e.g. alternating row backgrounds).

    The full list of options can be found in the HTML::Table documentation, I'm not going to duplicate it all here.

    Currently, the row headings used in the generated table are taken from the column names in the query, but I plan to release a new version sometime soon which allows you to alias them, if you want to do so.

    (The code samples in this post are intentionally kept relatively simple, omitting obvious things like connecting to the database first, error checking etc).

    David Precious is a professional Perl developer, currently working for a UK web hosting company. He has released several modules on CPAN, and contributed to a number of other Open Source projects. He's also a keen motorcyclist, and has a fondness for beer.
  • Pittsburgh Perl Workshop 2008 is underway

    John Cappiello writes:

    So far I am enjoying the hallway track as always. Buglabs was semi interesting, but the business / product seems impractical, Rx talk by Ricardo Signes was both entertaining as always, and hopefully an informative piece to some, as it's quite an interesting product.

    There's only one track today, so talks are limited. I'll send more info as it comes along, and I have more conference photos to be uploaded to Flickr already. They're all tagged ppw2008.

    Any other reports from the field? Link to them in the comments!