use signatures;
use Path::Class;

file( 'file.txt' ) ~~ sub ($f) {
   say $f->basename;
   say $f->slurp;
};

This style and syntax is reminiscent of Python's with and Ruby's do, and, for this use case in particular, feels a bit more natural to me than right-to-left, functional-style Perl5:

map { say $_->slurp } file( 'file.txt');

I was just wondering if anyone likes them Perl served like tha'.

Thinking of an alternative, but similar syntax, a year or so ago I forked Perl 5.13.x and patched it trying to make it take sub { } as a method call. Things didn't work as I expected as I'm a Perl5 internals noob, it was a really hot Madrid summer afternoon and I had a higher-than-usual dead brain cell count, but the idea was to be able to call closures on objects:

my $f = file( 'ah-ha' );
$f -> sub {
    say $_->basename . ' = ' . $_->slurp;
};

Which probably could work nicely on native types too:

( 1..10 ) -> sub { ... };  # same as sub{ ... }->( 1..10 );
@arr -> sub { ... }; # sub{ ... }->( @arr );
%hash -> sub { ... }; 
"string" -> sub { ... };

The insignificant white-space before and after the arrow makes it even more expressive.

This is not a proposal, Perl6 already that covered: 'ponty-blocks' come to mind, which even drops sub altogether. But it sure feels like something that could make quite easily into Perl5 without causing a lot of grief.

But this time I wanted to give Plack a try.

I'm new to Plack and PSGI, but I can't wait to start moving my apps to this badass middleware framework.

Plack comes with 2 CGI wrapper modules, Plack::App::WrapCGI and Plack::App::CGIBin. WrapCGI seems like the most appropriate for my needs. Apparently it even precompiles CGIs using CGI::Compile, for added performance.

So I wrote a little app.psgi in the /opt/otrs directory:

use Plack::App::CGIBin;
use Plack::Builder;
my $app_main = Plack::App::WrapCGI->new(script => "/opt/otrs/bin/cgi-bin/index.pl")->to_app;
my $app_customer = Plack::App::WrapCGI->new(script => "/opt/otrs/bin/cgi-bin/customer.pl")->to_app;
my $app_web = Plack::App::File->new(root => "/opt/otrs/var/httpd/htdocs")->to_app;
builder {
      mount "/otrs" => $app_main;
      mount "/helpdesk" => $app_customer;
      mount "/otrs-web" => $app_web;
};

And fired it off:

/opt/otrs $ plackup

OTRS was listening on the default http://localhost:5000/otrs and working flawlessly! But, naturally as it's running on plain plackup, it was a little slow handling requests. So I decided to upgrade it to the preforking Starman.

/opt/otrs $ starman

All I had to do was run the starman command-line, it uses the same app.psgi to spawn 5 processes. OTRS responsiveness was noticiable.

Now, following advice from the Starman's POD, I decided to preload some modules to get the benefits of copy-on-write on forking. I don't know the OTRS internals well, so I chose packages almost randomly.

/opt/otrs $ starman --preload-app -MDBD::mysql -MKernel::System::Ticket

That brought total reported memory usage for 5 Starman processes from 90K to 130K and slowed down startup a little. But after firing off many requests, the preloading started to pay off, reporting a stable 150K (preloaded), versus 200K+ (no preload).

My server is somewhat overloaded these days, but I decided to fire off some concurrency benchmarks anyway. Values are in reqs/sec.

Starman does a really good job handling concurrency for dynamic content. For obvious reasons, Nginx static handling blows anything away. So a good setup would be Nginx for static content and Starman as the centralized application server.

Hopefully, more and more legacy Perl apps will migrate to Plack. For the meanwhile, Plack seems like an excellent choice for centralizing Perl webapp management.

I find it useful to syntax highlight when I peek at a module's source code in the CPAN website. You may find it useful too.

To install it, create a new bookmark and paste the following code into the location field (sorry, I couldn't find a way to post this as a javascript: link in this blog):

It will be even handier if you stick it in your bookmark toolbar.

Then view any module's source in CPAN, fire off this bookmarklet and voilà.

I've even thrown in some regex to allow linking from one module to the next. It works 90% of the time, moreless.

The code is actually kept here. There you'll also find a lushier, Alex Gorbatchev's syntax highlighter version available, but I couldn't get it to work in Chrome nor Safari, only in Firefox.

It should be easy to tailor these bookmarklets to fancy your taste buds.

It would tell programmers they have done something worth mentioning and throw in some inspirational kudos and uplifting recognition:

$ perlcritic --praise script.pl
Good! Filehandle is not a Bareword at line 4, column 1.  See page 202,204 of PBP.  (Cleverness: 1)
Nice use of comments in a regex. Maintainers will be happy at line 9, column 1.  See page 289 of PBP.  (Cleverness: 3)
Outstanding use of Moose roles at line 11, column 1.  (Cleverness: 2)
Named parameters are definitely easier to read at line 42, column 1 (Cleverness: 1)
Quite sure this 1 line of Perl translates to at least 12 in Java at line 58, column 1 
Oh yeah! You rock! at line 74, column 1.  (Cleverness: 4)
This package may be useful to the community. Make sure you upload it to the CPAN at line 74, column 1.  (Cleverness: 5)

I think psychologists call it positive reinforcement. :)

I was curious to see how I could put NoSQL databases to good programming use. MongoDB stroke me as a good contender for some experiments: it's easy to install, well documented and has an intuitive query language that reminds me of SQL::Abstract syntax. Besides, MongoDB allegedly is very fast and scalable, which left me wondering how my configuration management apps could benefit from a backend switch from relational to a non-ACID document based DB like MongoDB, just like these people did for their server monitoring software.

One of the things I liked the most about MongoDB is the fact that its Perl driver has a straightforward Moose-based interface. So I decided to take it out for a drive. Actually, my goal wasn't MongoDB's performance, nor its query language features. I was more interested in exploring how could MongoDB could become the base for a Perl object persistence framework out-of-the-box...Out of sheer curiosity and a chance for fun self-learning.

(I know KiokuDB is just sitting out there saying "well, try ME out then". It even has a MongoDB backend prêt-à-porter, but I feared KiokuDB could add some unnecessary overhead, since it caters to a wide range of backends. And, at this point, I just wanted to sketch something up myself to ruminate on.)

So I tried to model a very basic CD-Artist relationship. I came up with a use case:

my $db = MediaDB->new;
# create the artist and store it
my $artist = Artist->new( name => 'Paco de Lucia' );
$db->collection('Artists')->insert( $artist );
# create a CD and store it
my $cd = CD->new( title=>'Almoraima', artist=>$artist );
my $cds = $db->collection('CDs');
$cds->insert( $cd ); 
# now retrieve it back
my $favorite = $cds->find_one({ title=>'Almoraima' });
say $favorite->stringify;

Even though the MongoDB driver relies on Moose (Any::Moose actually) for most of its classes (Database, Collection, OID, etc.), data is represented by an unblessed hashref, which in MongoDB lingo is called a Document. So I figured I needed to wrap some of these objects up to create a proof-of-concept storage framework that would also fit in a blog post.

First I needed a MediaDB class that would make the get_collection method bless collections into my own classes. With a little help from MooseX::Declare, I sketched up a "MediaDB" class:

use MooseX::Declare;
class MediaDB extends MongoDB::Database {
	method BUILDARGS (ClassName $class: @args ) {
		my %args = (@args);
		$args{_connection} ||= MongoDB::Connection->new;
		$args{name} ||= 'mediadb';
		return \%args;
	};
	method collection( $name ) {
		return bless $self->get_collection($name), $name;
	}
}

Now, to be able to store my objects as documents, I needed to serialize them into hashrefs, and vice-versa. Just unblessing them wouldn't take care of its nested objects, so I went shopping around the CPAN. I found this neat module, MooseX::Storage, which I had no idea about. It came quite handy!

So I drafted up a serializing Document role for the MongoDB document common code:

role Document {
	use MooseX::Storage;
	with Storage;
}

That installs a pack and a unpack method for every Document-role consumer.

Now I went on to create the collection role for wrapping the two methods I needed for running my code, so that I could pack and unpack objects on the fly:

role Collection {
	around find_one( HashRef $query, HashRef $fields? ) {
		my $doc = $self->$orig( $query, $fields );
		my $doc_class = $doc->{__CLASS__};
		return $doc_class->unpack( $doc );
	}
	around insert( HashRef $doc, HashRef $options? ) {
		return $doc->{oid} = $self->$orig( $doc->pack );
	}
}

I'm not sure a Collection role is the best fit because I still need to extend MongoDB::Collection for every class I create.

As a nice collateral, when using MooseX::Storage I get MongoDB documents that have a __CLASS__ attribute telling me how to unpack them back after fetching data. It has some drawbacks though, since it ties data and code representation.

Now that I had a very embryonic framework, I threw in my "schema" classes:

class CDs with Collection extends MongoDB::Collection;
class Artists with Collection extends MongoDB::Collection;
class CD with Document {
	has 'title' => ( is=>'rw', isa=>'Str' );
	has 'artist' => ( is=>'rw', isa=>'Artist' );
	method stringify {
		$self->title . ', by ' . $self->artist->name;
	}
}
class Artist with Document {
	has 'name' => ( is=>'rw', isa=>'Str' );
	has 'cds' => ( is=>'rw', isa=>'CDs' );
}

Here, an Artist also has 'cds', an implementation bomb that I'll keep unused for the time being.

After running the use-case, this is how data looked in the DB:

$ mongo 
> use mediadb
switched to db mediadb
> db.CDs.find()
{ "_id" : ObjectId("4bf032abe293830299931162"), "__CLASS__" : "CD", "artist" : { "__CLASS__" : "Artist", "name" : "Paco de Lucia" }, "title" : "Almoraima" }

True. This experiment taps into the untamed waters of object persistance. It left me with a sense of accomplishment: creating a leaner homemade persistence layer is doable with MongoDB -- except I still have many issues to chew over:

• Relationships: instead of embedding documents into one another, sometimes it's best to store them separately and link the two -- good'ol normalization. But where would be the best place to enforce such "normalization"? How to avoid duplicating objects?

• Object IDs: the only reliable unique object id in MongoDB seems to be its auto-generated OIDs, which are guaranteed to be unique across replicated servers. How should I handle them in my classes? How about auto-increment ids from my relational models? Could I live without them easy to read, incremental numbers? Should I create UUIDs in my code?

• Performance: to serialize objects back and forth from the DB is expensive. What would be the most performant way of turning MongoDB documents into Perl objects, and vice-versa, without sacrificing too much? To just carelessly bless them, or to instantiate with Class->new every time?

• Approaches: what other difficulties and approaches on persisting objects into a document-based database like MongoDB can one come across?

I figure KiokuDB authors have sorted out most of these questions. Maybe next weekend I'll dive into that.

But it does look promising. MongoDB feels very natural in Perl, maybe because the MongoDB team tend to blaze the trail by creating and maintaining their own language driver implementations, something uncanny for most new and established databases out there.

This is what has worked for me:

$ ./configure --prefix=/opt/nginx --user=nginx--group=nginx \
--without-http_rewrite_module \
--without-http-cache --with-zlib=/opt/tmp/zlib-1.2.3

$ make

Of course, first you need to get gcc from the IBM Linux Toolbox. And download the zlib source, as the nginx make will attempt to build the zlib libs.