Conference registration is a mere $100 ($30 for students). There are three tracks, covering everything from beginner topics presented by 10gen staff to advanced, detailed MongoDB presentations by industry leaders. Here's the abstract for my talk:

This talk introduces the features of MongoDB by demonstrating how one can build a simple library application. The talk will cover the basics of MongoDB's document model, query language, and API. In addition, we will learn how to use MongoDB within a typical web application framework.

If you're in Boston and you've never used MongoDB before, or are thinking of trying it out, I'd highly recommend stopping by. The demo application for the talk is written with Mojolicious::Lite and will soon be available on GitHub for you to experiment with.

(Crossposted from my blog here.)

The first is Pod::Weaver::Section::Extends which will add a =head1 EXTENDS section with a list of everything in your @ISA at compile-time. It should work with any kind of object that modifies @ISA in a normal way.

The second is Pod::Weaver::Section::Consumes, which does the same thing for Moose roles. It will interrogate any Moose-compatible meta object for your class to find a list of roles.

The repositories for them are here and here.

I hate boilerplate with a burning passion, and I will often go to extreme lengths to avoid typing it. (I typed it once already, dammit! Leave me alone!)

After having a great time learning to mess with Dist::Zilla, I decided to give another of Ricardo's projects, Pod::Weaver a try. Here's the cool stuff I was able to do after not a lot of work.

The interesting bit is [Collect / METHODS]. That will find all the POD-like commands called =method in your document, collect the block of text under each, and put them together under a =head1 METHODS section.

So this:

=method foobar

Here is some text

=cut

Becomes this:

=head1 METHODS

=head2 foobar

Here is some text

=cut

That's pretty spiffy, but I wanted to go further. Because Redis::Client has something like 120 methods (each one implements one Redis command) I wanted to organize them under different sections. So I copied-and-pasted the default config into my weaver.ini and modified it thusly:

The command lines specify the POD-like command to collect into each section. Now, I can use =string_method or =list_method or whatever, and the sections will automatically be collected under the appropriate =head1 section when Weaver runs.

But wait, there's more!

Another thing I wanted to do was link each method section to the Redis documentation for that command. It would be really tedious to type L<Redis FOO command|http://example.com/foo> over and over again, so I figured there must be a way for Pod::Weaver to do this. Like Dist::Zilla, it has a very extensible plugin architecture. Also like Dist::Zilla, the docs are somewhat lacking, and I had to dive through a lot of code to figure out what was going on.

I have no idea if the following constitutes "correct" usage of the Pod::Weaver API; I accomplished it mostly through trial-and-error and lots of Dumpering. But it works.

The result is that a link like Redis LREM Command gets automatically added to a section that begins =list_method lrem. Very cool!

To use this, I just had to add [-RedisLinks] to my weaver.ini. I'm not sure why the - is required (they're not for Dist::Zilla plugins), but it seems to explode if I omit it.

The plugin is not really useful for anything outside this specific project, but lacking anywhere else to put it, I just stuck it in the Redis-Client distribution, in case someone might find it useful as a reference.

And finally, since this distribution uses Dist::Zilla, to get all this stuff to happen automatically, I just add [PodWeaver] to dist.ini. Voila!

REPL means read-eval-print loop. App::htrepl provides a commandline script, htrepl, which makes it easier to talk to your HTTP applications. The only dependencies are LWP and Term::ReadLine; the code is otherwise designed to be as lean as possible.

Here are some examples of how it can be used:

$ htrepl 
htrepl> head http://www.friedo.com/
Setting protocol http
Setting host www.friedo.com
Setting port 80


HEAD http://www.friedo.com:80//

200 OK
Connection: close
Date: Sun, 27 Feb 2011 21:23:14 GMT
Accept-Ranges: bytes
ETag: "ff1f6-88e-87f72640"
Server: Apache/2.2.4 (Fedora)
Content-Length: 2190
Content-Type: text/html; charset=UTF-8
Last-Modified: Tue, 16 Mar 2010 23:41:05 GMT
Client-Date: Mon, 28 Feb 2011 05:54:06 GMT
Client-Peer: 206.71.179.40:80
Client-Response-Num: 1

htrepl automatically determines the Host header and port name, and other details, which it remembers for subsequent requests.

htrepl> get /foobar


GET http://www.friedo.com:80//foobar

404 Not Found
Connection: close
Date: Sun, 27 Feb 2011 21:23:45 GMT
Server: Apache/2.2.4 (Fedora)
Content-Length: 283
Content-Type: text/html; charset=iso-8859-1
Client-Date: Mon, 28 Feb 2011 05:54:36 GMT
Client-Peer: 206.71.179.40:80
Client-Response-Num: 1
Title: 404 Not Found

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /foobar was not found on this server.</p>
<hr>
<address>Apache/2.2.4 (Fedora) Server at www.friedo.com Port 80</address>
</body></html>

If you only want to look at headers, you can throw away the response body:

htrepl> .hide body
Hiding body

htrepl> get /foobar


GET http://www.friedo.com:80//foobar

404 Not Found
Connection: close
Date: Sun, 27 Feb 2011 21:25:51 GMT
Server: Apache/2.2.4 (Fedora)
Content-Length: 283
Content-Type: text/html; charset=iso-8859-1
Client-Date: Mon, 28 Feb 2011 05:56:42 GMT
Client-Peer: 206.71.179.40:80
Client-Response-Num: 1
Title: 404 Not Found

And you can even turn off headers:

htrepl> .hide headers
Hiding headers

htrepl> get /foobar


GET http://www.friedo.com:80//foobar

404 Not Found

htrepl allows you to set arbitrary headers, User-Agent strings (the default is "perl-htrepl/$VERSION") and cookies.

htrepl> .header x-foobar-header blah blah
Setting header x-foobar-header => blah blah

On subsequent requests, the x-foobar-header will be sent, until it's deleted.

htrepl> .cookie mycookie 12345
Setting cookie mycookie => 12345

This saves a cookie in the session, and it will be sent to subsequent requests to the same host. You can inspect your cookies, including those sent from HTTP servers:

htrepl> .show headers
Showing headers

htrepl> get http://www.google.com/
Setting host www.google.com

GET http://www.google.com:80//

200 OK
Cache-Control: private, max-age=0
Connection: close
Date: Mon, 28 Feb 2011 06:02:03 GMT
Server: gws
Content-Type: text/html; charset=ISO-8859-1
Expires: -1
Client-Date: Mon, 28 Feb 2011 06:02:03 GMT
Client-Peer: 72.14.204.104:80
Client-Response-Num: 1
Set-Cookie: PREF=ID=f322e9c1e288ae57:U=2a0bdbd0aa3bc510:FF=0:TM=1298872863:LM=1298872923:S=jMevxo0BYrps9-T2; expires=Wed, 27-Feb-2013 06:02:03 GMT; path=/; domain=.google.com
Title: Google
X-XSS-Protection: 1; mode=block

htrepl> .look cookie PREF
PREF: ID=f322e9c1e288ae57:U=2a0bdbd0aa3bc510:FF=0:TM=1298872863:LM=1298872923:S=jMevxo0BYrps9-T2

If the method name is POST or PUT, htrepl will prompt you for the message data:

htrepl> put /
Enter PUT body data. Terminate with CTRL-d

PUT> blah
PUT> blah blah
PUT> 

PUT http://www.friedo.com:80//

405 Method Not Allowed
Connection: close
Date: Sun, 27 Feb 2011 23:08:08 GMT
Server: Apache/2.2.4 (Fedora)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 310
Content-Type: text/html; charset=iso-8859-1
Client-Date: Mon, 28 Feb 2011 07:38:59 GMT
Client-Peer: 206.71.179.40:80
Client-Response-Num: 1
Title: 405 Method Not Allowed

You can even load message data from a file:

htrepl> put /foobar < /path/to/some/file.dat

There's also a .help command which will explain most of the commands available. Anything not beginning with a dot is assumed to be an HTTP method name and URI to execute it upon.

TODO:

A lot. There are some bugs with URL-handling that need to be fixed. Support for saving cookies and prefs to disk would be nice. Expanding the docs (there is basically none right now) and cleaning up some of the code would be nice. All patches/pull requests are welcome.


foreach my $tag( keys %tags ) {
....
my $res = $ua->get( $url );
unless( $res->is_success ) {
my $status = $res->code;
if ( $status == 420 ) {
# we are being rate-limited
my $wait = $res->header( 'Retry-After' ) || 31;
warn "API rate-limit - waiting for $wait secs...";
sleep $wait;
redo;
}
....
}

my $json = $res->decoded_content;
....
}


This loops over a bunch of Twitter hash tags and asks for some information about each one. If Twitter gets antsy, instead of sending the information with a HTTP status of 200, it sends a "slow down" message with an HTTP status of 420. The script sits there and does nothing for the allotted number of seconds and then repeats the loop iteration to hopefully get the information that resulted in an error last time.

What language features have you never used, despite being aware of them, or were surprised to use for the first time after much experience?

my @records = $schema->resultset( 'CamelCasedClassName' )->search( ... );

Today, I used DBIx::Class::Schema::Loader to auto-generate a schema for a fun little 182-table database. I ended up with modules with names like MyApp::DBIC::Result::XStreamQueryParentArticle and MyApp::DBIC::Result::ArticleElementContent and so forth. Very useful, but what painful nomenclature.

So I ended up doing the same little hack that I always do, but improved upon it a bit this time, and have finally arrived at a solution that I really like.

sub new { 
    my $class = shift;
    my %args = 
      ( type => 'master',
        @_
      );

    # ... bunch of config stuff here

    my $dsn = sprintf 'dbi:mysql:%s;host=%s', $db, $host;

    my $schema = $class->connect( $dsn, $user, $pass );

    $args{schema} = $schema;

    return bless \%args;
}

Then I added a loop to load up some shortcut methods when the module starts up:

foreach my $source ( __PACKAGE__->sources ) { 
    my $source_class = 'MyApp::DBIC::Result::' . $source;
    my $tbl = $source_class->table;

    no strict 'refs';
    *{ 'MyApp::DBIC::rs_' . $tbl } = sub {
        my $self = shift;
        return $self->{schema}->resultset( $source );
    };
}

Now, instead of writing

my $schema = MyApp::DBIC->connect( ... );
my @records = $schema->resultset( 'OmnitureArticlePopularity' )->search( ... )

I can write

my $db = MyApp::DBIC->new( type => 'master' );
my @records = $db->rs_omniture_article_popularity->search( ... )

The auto-generated method names all come from the DB's table names (prepended with rs_ ) which are much easier to remember, and easier to type, than the CamelCased module names. The $db object also keeps track of some useful data about our environment, where there are multiple dev/stage/production databases and abstracts away the configuration.