Perl: May 2009 Archives

I came across this the other day, and since it pre-dates the Ironman competition, I wanted to pass it on. Dave Rolsky came up with some interesting comments about software and the documentation process.

You know how it has been said that a good way to judge the quality of your writing is to read it aloud? Dave points out that the same thing applies for your code. When you force yourself to describe how your system / code works, you will notice inconsistencies and problems that you otherwise might not notice.

I have found this to be very true and the first commenter has a point as well. When I am designing new software from scratch, I always start with a legal pad and a nice free-flowing pen, and draw diagrams and write down ideas for how the different pieces fit together. I find that while I can write code without this step, the code I produce having done this is far superior in quality and cohesiveness.

Thanks Dave, for sharing that wisdom.

You've read the tutorial but you still can't seem to get a grasp on what exactly to use Chained dispatching for.

Chained is just another method of method/url dispatching that Catalyst allows you to use. Chained, however, allows you to chain together methods that need to share information across requests....

As many of you will know by now, Moose comes with its own type system that you can use, extend and introspect. Since the types are handled in a global registry, you have to be concerned about namespaces like with every other perl package.

I started writing MooseX-Types with the objective of writing a tool that provides a solution to the namespace problem by simply enclosing type definitions in a library and turn the types into exports.

Since then, the community has put a lot of thought and effort into the idea and made it into much more. There are reusable type libraries on CPAN for DateTime, Path-Class, data structures, input/output, URIs, and the common extensions of the core types. You can also for some time now refer to imported types in MooseX-Method-Signatures.

With the recent rise of Devel-Declare, we have a lot more options for defining our interfaces. There is already thought and work put into developing nicer sugar for declaring type libraries, so I focused on sugar for importing the types that models nicely onto MooseX-Declare. This article is a summary if what I’ve come up with so far.

English is an interesting language. It has lots of rules, and over 170,000 words in common usage. That seems like a lot, until you realize that there are even more concepts that are described using multiple words. Those words are arranged and rearranged to create millions upon millions of books.

One of the things I find most interesting about English is that it's a very idiomatic language. There are many phrases that, if you pick them apart into their individual words, do not carry the same meaning as when they are used together. "In her element," "red herring," and "chip on your shoulder," are just a few examples.

These idioms allow you to deliver a significant amount of meaning in a small number of words. It's a conceptual shortcut. It's natural for people to want to communicate as much information in as small a space as possible because most of the time, there is more to communicate than there is time to communicate it.

In that respect, programming is very similar. We can think far faster than we can generate code. Therefore the less we have to write, the more meaning and function we can deliver per line, the more we'll be able to accomplish.

In the Perl world, this value is commonly referred to as DRY or Don't Repeat Yourself. The concept behind DRY is that we all know that there are activities our programs must do over and over, but that doesn't mean that we should have to write them over and over. Also in the Perl world, there is a temple for this worship of this value. It's called CPAN.

Everyone knows that you can write web tools using Perl and CGI. Most folks know that there are web frameworks for Perl such as Catalyst that allow you to create large and complex web applications relatively easily.

Today I have a question for all you Perlers out there. What options does a Perl developer have if they need to develop a small amount of interactive code for a web site and they don't want to go all in for a complete web framework?

So if you are in need of only a handful of interactive responses for your site, or you work in an office with a CPAN hostile admin who balks at the dependency chains on some of the larger frameworks, what choices do you have?

Are there any options that are a bit better than CGI, but not quite as complex as a whole web framework? I know mod_perlite is on the horizon somewhere, but is there anything that you have heard of or are using now?

Sound off in the comments!

For quite some time now there have been appearances of a new type of declarative modules on CPAN. Some of these (but not all) are MooseX::Method::Signatures, giving you a method keyword with signatures and type validation; TryCatch which provides you with a modern and elegant way to catch exceptions; and MooseX::Declare, a whole extendable, declarative framework around the Moose ecosystem.

To many people who don’t have the time or the interest to live on the edge of advancements in the Perl community, this might seem like magic trickery, much like source filters. And because of this many people keep a safe distance from all these developments, like they rightfully do with source filters. You should never use something before you know how it works on a deep enough level for decision making. This is why I decided to write this post, and to show how all of this is made possible.

Perl 5 is a vibrant, mature, growing language.

Now that I've said two seemingly incredulous things in as many sentences and have grabbed your attention, I'll continue with this post properly. 

New in Perl 5.10 is the smart match operator (and companion given/when syntax that finally implements switch/case type syntax without a source filter). The issue with this is that there are some edge case bugs with this new functionality. We need as many people hammering at the code as possible to identify all of these edge cases so that they can be fixed for 5.10.1.

Why? I can start with a personal reason. I LOATHE source filters. Nothing makes my blood boil hotter or more quickly than seeing someone use a source filter. They are a disaster for maintainability and introduce indeterminism into an engineering discipline. I have seen the same code using Switch.pm operate differently on two different machines. The smart-match and given/when features in Perl 5.10 provide equivalent (but better) functionality without a source filter. This is good for my blood pressure. There's also the fact that I've wanted this feature in Perl for years without it being a source filter and can finally use it.

But my employer deploys on 5.8.8, not 5.10. This means I don't get to play with this shiny new toy. So anything I can do to convince them to roll out 5.10 makes me a happy coder. Studies easily findable with a Google search show that happier workers do better work and are overall healthier. Therefore, it is in my and my employer's best interests to roll out 5.10.

What about you? Maybe you love the new state variables. Maybe you want to replace Perl's regex engine with the PCRE engine just to annoy me when I go on a rant about how PCRE isn't Perl and why I refuse to answer PCRE questions in Freenode's #perl. Maybe you're like me, a maintenance coder at heart, and you want nothing less than to leave a smoking hole in the universe where Switch.pm used to be.

"But I'm not a tester! I don't know how to test! What can I do?" I'm glad you asked. There's a github repo at http://github.com/rjbs/perl-smartmatch-tests/tree/master which contains a repository of tests and instructions on how to proceed. Take a look at the existing tests (including the just-added failure) to get a feel of how things (don't) work. Be crazy with it. Do things that you're sure should give an error message just to be sure that they do so instead of crashing. Be creative, pathological, and cruel. Apply ~~ to a tied array that randomly deletes its elements upon a FETCH. Try to break it however you can. This is the coolest new feature to make mainstream perl in a long time (since indirect filehandles in 5.6, IMO). I want to be able to deploy (and publish to CPAN) code using this. Surely if you've read this far you want to, as well. 

Those of you who are not regulars on irc.perl.org or don’t hang out in the #catalyst channel might not be aware of this, but the discussion, planning and chanting was going on for a while. With the recent rise of Devel::Declare this discussion has flamed up again.

There are many people thinking about how to design this, and even some implementations are already around. I’d like to use this article to discuss my own take on how a declarative Catalyst might look like.

Ok. So you've heard of Reaction. You've read a blog post or two about it. You've even taken a crack at reading the fine manual, but you still don't quite get it. Don't feel bad. I was in the same boat as you.

The manual does a fine job of explaining how Reaction works. It does a pretty good job of telling you how to build bits of Reaction code. It doesn't really explain what Reaction is for and why you should care.

I spent some time discussing this with one of the folks who wrote the majority of the Reaction documentation. My questions were all over the place but they boiled down to one thing: 'Why do I care?' I finally had the 'AH HA!' moment about 2 hours in to the discussion.

Reaction provides a way for you to easily plug-in features into your Catalyst app with minimal effort. It allows you to build new features in a distributable way that allows for per-app customization while maintaining a clean base set of code.

Reaction takes DRY (Don't Repeat Yourself) to the next level. DRY usually applies on a per-application basis. Features built using Reaction become mobile between applications and even distributable via CPAN. The best part is you can still customize them without editing the distributed code.

That's why Reaction is interesting. It gives Catalyst authors a way to share their features with each other, and across their own projects.

Perl is quite different to languages such as Java and Python. It is an open language with relatively few pre-defined ways to do things. This is one of the greatest strengths of the Perl language. It allows the language to evolve over time. It allows the language to change and to adjust to new methodologies and concepts without a gutting of the core language.

One of the core values of Perl is TIMTOWTDI, or "There Is More Than One Way To Do It." This too is different from other languages whose 'how to do it' is often defined by large commercial organizations or 'language elites' who decide the course of the language. Today we will look into TIMTOWTDI and explore some of it's effects, both good and bad.

When you build a web application with Catalyst, your controller will retrieve data from your model (or operate on it), prepare it, and put it in the stash so the view can access it. Your layout will be organized by templates that load more or less reusable subtemplates.

Reaction on the other hand comes shipped with its own UI system. In this post I will try to describe its components and how they interact.

As some of you may know, I comaintain local::lib with Matt S. Trout. We've had issues with local::lib on Red Hat / CentOS systems in the past. We thought that this was due to Red Hat breaking Perl, because they've had a history of doing so. As some of you may know, I now work at Pobox. They kindly provided me with a MacBook for work purposes. During the process of setting up this MacBook, I installed Perl from MacPorts, because of known issues with users modifying their system's Perl on a commercial Unix OS. In addition to this, I wanted to set up a local::lib environment to make working on Pobox code easier.

Everything was going well with this until I wanted to bootstrap local::lib:

    $ perl Makefile.PL --boostrap

    [churn]

    $ ls

    [lack of Makefile]

    # !

    $ perl Makefile.PL --bootstrap

    [churn]

    $ ls

    [presence of Makefile]

This behavior is exactly the same as what Red Hat and RH-derived systems exhibit when installing local::lib. Therefore, it seems safe to say that the problem is not Red Hat-specific and warrants an entirely new angle of investigation. I'm going to be pursuing this tonight, but I wanted to make note of my findings here. Like it or not, Red Hat is used a fair deal out in the wild, and getting local::lib to work on it would be a big win (not to mention the fact that I want it to work on the Mac that Pobox is graciously allowing me to use). I'll post here again with progress sometime very soon.

I've said before that Perl has a very active community. There are hundreds of people in each of the Perl related IRC groups I frequent. There are thousands of people on the mailing lists and more who frequent places like use.perl and perlmonks. There are several hundred modules uploaded to CPAN every month. Each one of those uploads usually involved the work of several people working together to improve those modules.

Having spent the last decade in the Perl community, I can tell you that it is composed of a lot of very smart people. It is generally open and accepting of new people and can be a very lively and rewarding group to be a part of.

That said not everyone finds it to be that way. At least once a week someone will join one of the Perl related IRC channels I frequent and within a few minutes will get what amounts to an 'ok, you can go away now.' This happens on forums and mailing lists as well. So if the Perl community is as lively and accepting as I claim, what's the deal?

I was in #catalyst working on some Varnish (or at least attempting to get it working) when someone had an issue with DBIx::Class.  I wasn't really paying attention until someone mentioned that ORMs are evil and they could look at KiokuDB as an alternative.  It's a Moose based OO database system (object graph storage engine [thanks dandv]).  Today we'll take a quick peek at Kiokudb.