• 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).*