YAPC this year was great.

I met a lot of people I only knew on the interwebs, went to some great talks, and got my ass heckled. I enjoyed every moment of it.

Matt Trout gave a great ironman forfeit talk, Stevan Little gave a great keynote on Tuesday, Nick Perez gave (6) great talks, 2 of which I was able to attend, Jesse Leuhrs showed me how to extend Moose like a boss, Chris Prather told me why MooseX::POE sucks and why I shouldn't use it, and I learned some Klingon from Paul Fenwick. Jay Shirley talked about a sensible way to use templates to control your UI, keeping designers AND programmers happy, and Cory Watson talked about selling Moose to your bosses and managing your data verification stack with Data::Manager.

My talks went mostly okay. Intro to Catalyst was a bit of a farce, but hey! We all learned something that day: Catalyst makes things get done faster. Thumbit was fun to talk about, and I actually got a good deal of hacking done on the code to make it (almost) work. Google Summer of Code will always be near and dear to my heart, my first talk, which is about my first dip into the magical waters of open source development.

I bid YAPC2010 a fond farewell, and shout outs to every one I met and everyone I got to hang out with after hours.

Until next year!

I've finally been able to play with the massively fun toy that is Bread::Board.

What is it, you say?

Bread::Board is basically a way to wire application components up in a DRY, and efficient manner. This is extremely useful for application configuration, and application setup (database handles/connection pooling, configuration file location, logger class setup, etc.).

The example I have put together involves the above, with a relatively sane method for setting up a configuration API so it's reusable and not a TOTAL pain in the ass.

Basically, I looked at blawd and stole the configuration bits and mangled them into something I could use.

Check it out (this comes from my minimal CMS Deimos:

package Deimos::ConfigContainer;
use Moose;
use namespace::autoclean;
use Bread::Board;
use Data::Dumper;
use Deimos::Schema; 
use Config::JFDI;
use Template;

has 'log_file_name' => (
  is      => 'ro',
  isa     => 'Str',
  default => "deimos.conf"
);

has 'config' => (
  is => 'ro',
  lazy_build => 1,
);

sub _build_config {
  my $self = shift;
  my $cfg = Config::JFDI->new( path => $something . $self->log_file_name );
  return $cfg->get;
}

sub build {
  my ($self, $service) = @_;
  my $cfg = $self->config;
  my $c = container Deimos => as {

    service 'site_title' => (
        block => sub {
            my $self = shift;
            return $self->config->{'site_title'};
        },
        dependencies => [ depends_on('config') ],
    );

    service 'log_file' => $self->log_file_name;

    service 'config' => $cfg;

    service 'schema' => (
        lifecycle => "Singleton",
        block => sub {
            warn "config: " . Dumper $cfg;
           return Deimos::Schema->connect(
               @{ $cfg->{'Database'}->{'connect_info'} },
            );
          }
    );

    service 'templates' => ( 
        block => sub {
            return Template->new($cfg->{'templates'});
        }
    );

    service 'application' => (
        class        => 'Deimos',
        dependencies => {
            schema     => depends_on('schema'),
            config     => depends_on('config'),
            site_title => depends_on('site_title'),
        }
    );
};

    return $c->fetch($service)->get;
}

 __PACKAGE__->meta->make_immutable;
1;

Basically, this allows you to either use your configcontainer, or, like I plan to, create a role, and apply it as needed and do $self->config->fetch('service_name');

This makes life MUCH much easier on the configuration front.

I hope this helps someone out there like it helped me when I finally got it figured out.

Why use LeakTracker?

You have a Catalyst application that is consuming more and more memory over time. You would like to find out what classes are involved and where you may have cyclic references. Why not try out nothingmuch's handy dandy Catalyst::Controller::LeakTracker.

Full Article

Overview

Transactions are an important feature of many database management systems. Transactions allow one to make changes to a data store in a reliable way that can gracefully handle failure. In short you are guaranteed that the changes take place in their entirety or not at all. In addition, transactions provide isolation for concurrent transactions to avoid data from being changed out from under you. This petit article demonstrates transactions using DBIx::Class, a kickass ORM for Perl.

Full Article

I went through a lot initially trying to get perl to be able to interface to mysql and postgres on Mac OSX. My steps weren't optimal, and I wouldn't recommend them for anyone.

However, after purchasing my Mac Book Pro, I had to go through the process again, but this time, it was much more refined. So in essence, it boils down to this:

1. Make sure you have your flavor of mysql or postgresql installed AND PAY ATTENTION TO WHETHER IT SHOULD BE A 32 BIT BUILD OR A 64 BIT BUILD. If you are on a modern mac, chances are you're going to be using a 64 bit build of either of these.
2. wget the latest DBD::Pg or DBD::mysql driver from CPAN. You're going to have to manually build these with the libs and flags your mysql was built with. The easiest way to obtain these flags via mysql_config --cflags and --libs (respective config for pg too). Then, run perl Makfile.PL with --cflags and --libs set with the appropriate settings
3. Make sure mysql/pg are actually running! Your tests will fail otherwise.

This is brief, hurried, and probably not nearly as comprehensive as others. But, it should give you a relatively intuitive overview of how to get it going on your shiny mac.

Please let me know if I've left anything out!

Bracket is a web application that manages a group of players and their picks in the national college basketball tournament. It was written to provide an open source bracket system for the tourney that is fast, simple and ad free.

(update: sorry for the post-march madness post, this is all dhoss's fault)

MooseX::App::Cmd is a really handy little module to add robustness and decoupling to your command line applications. It allows you to treat each command as a separate class, keeping your code tidy, and pretty re-usable.

Continue reading for an example of what I recently used it for....

Many of you will have run into this problem: You want to stash a callback in Catalyst that will build you the URL for an action. It’s supposed to be a callback, because you want to dynamically pass an ID or other argument to the URL.

As nice as this sounds, you have to be careful so you don’t create a circular reference. I’ll discuss the current best practice for this problem below and will propose another kind of solution.

Abstract

There is more than one way to handle forms in your Catalyst/DBIC application. This paper speaks to the HTML::FormHandler way. Let's start with a simple example of building a registration form to allow new users to register with your website application¹. We will look at how to build a registration form object and use it in a Catalyst controller. Furthermore, the form will integrate with a DBIC connected database to persist the registration information submitted via the form.

Data::Manager is a really fantastic marriage of two very well thought out and uncoupled modules, Data::Verifier and Message::Stack. Data::Verifier does exactly what its name says, which is verifies data. You give it a hashref of constraints to verify against, and call ->validate on your data that you've passed in, and boom, data is verified with errors and filters. Messages::Stack is again, another very aptly named module. It gives you a programmatic interface to creating a stack of messages with a syslog flavor to them with regards to message level, scope, id, etc. You can then, after creating a stack of messages, retrieve messages matching a scope, or a block of messages pertaining to a certain attribute of your data, search through the messages and grab the ones that match your search criteria, or get all of the messages.