November 2008 Archives

Perl gratitude, 2008

| 1 Comment

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.

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 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 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, he's got an assload of modules on CPAN, and now he's trying to replace Module::Starter for module maintenance. 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. 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

| 4 Comments

By S├ębastien Aperghis-Tramoni

The CPAN Testers platform 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 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 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 is a system administrator and Perl expert at France Telecom Orange, in France, and maintains several CPAN modules. At Orange, Perl is the language of choice for writing all the backend and monitoring programs that make the stuff work.

Parrot 1.0 will be out in March 2009

| 5 Comments

At the first Parrot Developer Summit in Mountain View, CA, core Parrot developers got together and worked on the plan for Parrot language, including a release schedule for the next three years. From the summary posted by Allison Randal:

  • March 2009, 1.0, stable API for language developers
  • July 2009, 1.5, integration
  • January 2010, 2.0, production use
  • July 2010, 2.5, portability
  • January 2011, 3.0, independence
  • July 2011, 3.5, green fields

Very cool that they'll be stabilizing the API so that language development can have a solid base to work with. I'm just a little disappointed that "production use" is 14 months away. Does that mean that the soonest Rakudo will be available for "production use" will be January 2010?

A case for Catalyst

| 2 Comments

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

| 7 Comments

by Mark Stosberg

In 2006, the arena of Perl web frameworks pitted the heavyweight Catalyst against the lightweight CGI::Application. 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 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 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 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.

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 has been using programming Perl for the web for over a decade. He is the Principal Developer at Summersault and maintains several CPAN modules including Titanium and Data::FormValidator.

Perl 6 and Rakudo command line to be worked on in earnest

| 3 Comments

The Perl Foundation has announced a Hague Grant for Jerry Gay to implement the Rakudo Perl command line interface.

The work will be to define the S19 synopsis pertaining to command-line interaction with Perl 6, and to provide a Rakudo implementation of the synopsis.

Jerry will need to document the Perl 6 command line syntax, implement its tests, create a command line parsing library for Parrot, and implement a subset of the Perl 6 command line syntax.

I couldn't be happier with this direction. I made some vain stabs at command line interaction on Rakudo long ago, but not much came of it. Having a command line interface will make it much easier for users to work with Rakudo as it progresses. Perl without being able to do filtering magic isn't very Perly, no?

Patrick Michaud also received a Hague Grant, to work on the Perl Compiler Toolkit and regexes and other internal hoohah. I'm sure it's useful, but this feeble-minded reporter's head hurt when trying to follow the details of the grant.

Speak up for Catalyst

| 9 Comments

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.

BBC joins Parrot Foundation advisory board

| 1 Comment

The Parrot folks announced that the BBC was now on its advisory board, and it makes me happy to see. It's good to have big players in the Perl world like ActiveState join the advisory board, but I think it will mean much more to the outside world to see organizations outside of the software industry involved.

Thanks to all at the Parrot Foundation for what I'm sure took untold hours of discussion, red tape and finagling.

Devel::NYTProf continues its march of awesomeness

| No Comments

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.

« October 2008 | Main Index | Archives | December 2008 »