Overheard on stackoverflow

Commenter: why did you comment out use strict;?

OP: because i was getting errors and warnings because not all variables are defined as "my" or "our". it is for testing purposes only. I will uncomment that line later when the script works.


No link to protect the innocent.

Modules in core: who cares?

two-things-i-dont-like.jpeg

When I first read about the idea to remove CGI.pm from core, I was like "Yeah!". And then I thought about it and I was like "meh".

Who cares? Your typical noob that needs to be protected from the horrors of CGI.pm is not the kind of guy who builds his own perl. He is also not the kind of guy who uses an up-to-date perl. He probably has some company server running 5.8 or he might use whatever his hoster installed. Before he learns that there even is a core, he'll have a zoo of spaghetti cgi-scripts that won't work when using strictures.

But here is someone who will care about a missing CGI: the package maintainers of all the Linux distros out there. They will have to decide whether to pack CGI.pm into their main perl-package or whether to put it in its own new package. Since there are about a gazillion packages that quietly depend on CGI.pm, their most likely choice will be the former option.

So what I am trying to say is: You will not kill CGI.pm by removing it from core. But removing it from core will also not be noticed by any kind of user who doesn't know how to use a cpan client.

How to use SOAP::Transport::HTTP::Plack

I needed to port a little cgi-script that implements a simple SOAP-server to Plack. After a little searching, I came across SOAP::Transport::HTTP::Plack.

Unfortunately, the documentation of this module is ... not really helpful.

Here's my (slightly modified) cgi-script:

#!/usr/bin/perl

use SOAP::Transport::HTTP;

SOAP::Transport::HTTP::CGI
    ->dispatch_to(
        '/some/directory', 
        'Some::SOAP::Module1', 
        'Some::SOAP::Module2',
    )->handle;

Simple enough.

After some help of the awesome hobbs on IRC, here's part of my Plack psgi file:

use Plack::Builder;
use Plack::Request;
use SOAP::Transport::HTTP::Plack;

my $soap = SOAP::Transport::HTTP::Plack->new;

my $soap_app = sub {
    my $env = shift;

    return $soap
            ->dispatch_to(
                '/some/directory', 
                'Some::SOAP::Module1', 
                'Some::SOAP::Module2',
            )->handler( Plack::Request->new( $env ) );
};

return builder {
    mount 
        '/soap_test' => $soap_app;
}

And low and behold, it works!

LCLOC of the month

Here's the Least Comprehensible Line Of Code I came across this month. Took me a while to make sure it really did what I thought it did.

my @array;
# ...
@array = map {$_;} (@array, keys %{$this->{'someobject'}->get_some_hash_ref()});

Bonus points for using $this instead of $self.

What Moose is doing to my nose

It's only been a couple of months since I've been using Moose, but it is already changing the way I read code. Of course, it changed the way I write code in a very short time, but I was surprised when I realized that it also changes the way I smell code.

Things that seemed normal last year, now are a code smell to me. Whenever I see an object being constructed inside a method whose name doesn't start with '_build_', I wonder if something bad is going on. Even method calls with parameters are now becoming a code smell. Whenever I smell that smell, I ask myself "should this be an attribute?".

And that's a pretty good thing. I never found testing my code easier. "Dependency injection" is harder to spell out than it is to just do it. And I find myself being able to understand my own code a couple of weeks later.

So, to sum it all up: Thank you, Moose Cabal!