I also spoke at the Japan Perl Association Seminar #1, at Akihabara.  I wasn't easily able to blog about it at the time, and I'm giving the same talks for Seminar #2 so no big deal.

Better Perl Practices

Catalyst Tips: 10 things you should know

With all the thought I put into this title, I really have only those two words to say.  I personally hate testing.  I hate singular test files even more.  I find that I have to copy and paste a lot of code.  The next step is to shove some stuff into upstream packages that abstract out tests.  This just makes things uglier, and in my opinion, harder to test.

I was very happy when I saw Test::FITesque hit the CPAN.  The reason is that it separates out what you are testing versus what you are testing with (in terms of data).  You also can establish different routes of tests, and between the magic with Test::Builder, it all Just Works™.

Even though I read the documentation and witnessed a talk by Scott McWhirter (konobi in the perl world) I was still not certain of how it all came together.  My first attempt was hideous.  After several increasingly positive tests, I now cobble together a test suite that looks like this:

package Roostermatic::Test::Team;

use parent 'Test::FITesque::Fixture';

use Moose;

with
    'Roostermatic::Test::Fixture::Schema',
    'Roostermatic::Test::Fixture::Team',
;

1;

use Test::FITesque::Test;

my $test = Test::FITesque::Test->new({
    data => [
        [ 'Roostermatic::Test::Team' ],
        [ 'init_schema' ],
        [ 'team_create', 'Liverpool' ]
    ]
});

$test->run_tests;

package Roostermatic::Test::Fixture::Schema;

use parent 'Test::FITesque::Fixture';

use Test::More;

use Moose::Role;

use Carp;
use DBI;

has 'schema_class' => (
    'is'    => 'rw',
    'isa'   => 'Str',
    lazy    => 1,
    default => 'Roostermatic::Schema'
);

has 'connect_info' => (
    'is'  => 'rw',
    'isa' => 'ArrayRef',
    lazy  => 1,
    'default' => sub {
        [
            'dbi:SQLite:t/var/test.db',
            '', '',
            { quote_char => '`', name_sep => '.' }
        ]
    }
);

has '_schema' => (
    'is'        => 'rw',
    'isa'       => 'DBIx::Class::Schema',
    lazy_build  => 1,
);

# Define the lazy builder here to actually connect to the schema as configured
sub _build__schema {
    my ( $self ) = @_;
    my @parts = DBI->parse_dsn( $self->connect_info->[0] );
    if ( $parts[1] =~ /sqlite/i ) {
        if ( -f $parts[4] ) {
            unlink($parts[4])
                or croak "Couldn't unlink $parts[4], deploy may fail";
        }
    }

    Class::MOP::load_class( $self->schema_class );
    my $class = $self->schema_class;
    my $schema = $class->connect(@{ $self->connect_info });
    # die if we can't connect?

    return $schema;
}

=head1 METHODS

=head2 schema

Read-only accessor, returns a connected schema

=cut

sub schema { shift->_schema; }

=head2 init_schema

Runs 2 tests, and returns a deployed and initialized schema

=cut

sub init_schema : Test : Plan(2) {
    my ( $self, $params ) = @_;

    my $schema = $self->_schema;
    ok($schema, 'schema connect');

    eval { $schema->deploy };
    ok(!$@, 'deployed schema');

    return $schema;
}

1;

Project

A project is comprised of many high level goals. This is the configured test run, as verification a project is done

Goal

A runnable and complete test group is called a Goal (this would be a Suite in most nomenclatures). This is just to test a specific aspect, a line item in the project

Achievement

A goal is made up of several achievements.  This is a higher level than a unit test, and is what I am using as a role above.

Unit

An atomic unit in an achievement is a unit test (nothing different there).

This is a precursor to Catalyst Input Validation with DBIx::Class Models

I just recently gave two talks at the first Japan Perl Association, and one of the things I didn't focus on was design of your Catalyst application.  I opted to not talk about this, because I feel it to be a subject beaten to death.  In hindsight, I guess it isn't as a lot of people don't take the initiative to search through mailing list archives, and there needs to be some more public discussion on the matter (outside of mailing lists).

First, please try to forget the concept of MVC if you aren't already familiar with it.  Without a lot of thought, you're possibly going to go down the wrong path.  Instead, you need to think about what things are actually doing.  In a way, this is a role (not in the Moose sense).

The way I see it MVC is better extrapolated as:

• User Facing
• User Input
• User Output
• Visible Output (Template Rendering)
• Invisible/Async Output (Emails, Long running jobs)
• Business Facing
• Business API Layer
• Backend Implementation

$user->verify_and_upgrade( $code );

my $user = $c->model('Schema::User')->create_unverified( $data );
my $code_to_email = $user->verification_code;

I encountered an interesting problem, without any clear solution in front of me.  To save you from a lot of reading, I just deleted a 3 paragraph rant about the software I'm replacing.

Now, what I have is a 3 part system.  First is the Catalyst application that runs in a secure environment and handles purchases and registrations.  The second larger component is the content management, which is comprised of the legacy system and the new Movable Type based system.

MovableType was a fantastic choice, for the static publishing and easy user interface.  While the asset management could be better, I can always fix that for our needs after the fact (which I will be, most likely).

The problem is getting 3 applications to live together harmonously when they're very disjointed.  I don't really want to server the MovableType CGIs, so I can block any .cgi scripts at the frontend.

MovableType would be able to handle everything together, except for one caveat: A user logged in, with a valid membership, is presented with different content.

This, quite obviously, is a fantastic case for ESI.  I think most people in the MovableType world would have their templates omit PHP and put the generated HTML files behind Apache and PHP. 

Hell no.

There's 3 reasons for this:

1. I hate PHP
2. I don't want the bloat of dynamic pages when it isn't necessary
   
3. I already have an application that has all the snippets of templates, and uses a unified CSS structure

Continue reading Varnish and MovableType for content management and application integration.

First, a short preamble to the recipe I will present.  I had been trying hard to write up an entry here once every two weeks, focusing on substance.  I was falling behind on a draft entry so it was looking like 3 weeks was going to lapse before it was released.  It's a good article, though, on using Git and FastCGI for deployment management.  It was requiring some code-as-I-go, as it was largely a play thing and I'm not using it in production (which is something I typically refrain from writing about but in this case I was making an exception).  I was doing well, and tragedy hit and I lost my awesome nephew.  Since then, it's been very hard to engage myself in anything of importance, and I've really struggled.  Now, nearly 2 months after the terrible event I'm mentally recovering.  The outpour of support and encouragement has been amazing, and I'm truly grateful.  Now, on to business with a completely different recipe...

I posit the following statement which I hold true: Command-line applications are typically called with the same options specified.

With this in mind, it seems a gross oversight that the most commonly used command-line tools don't support configuration files to populate options and default state.  I would personally love to simply be able to do mysql --configfile work.yml.  Unfortunately, I am unable to.

Fortunately, Perl and Moose lovers can.  Allow me to introduce you to MooseX::SimpleConfig.  This fantastic role gives you the capability to bake in configuration into your application with very little fuss.  If you use MooseX::Getopt, most things are effectively free -- including the --configfile command line option to explicitly specify the configuration file.

Things, however, get better from there.  I found myself wanting to setup local overrides of configuration.  I desired something similar to the way that Catalyst merges in from myapp_local.yml, to myapp.yml (or .conf) and finally into the Perl packages for defaults.  What I ended up with is a way to just traverse a list of paths, and load the first one found.

It's a dead simple recipe:

with 'MooseX::SimpleConfig';
with 'MooseX::Getopt';

has +configfile => (
    default => ( grep { defined $_ and -f $_ } @list_of_places_to_look )[0] || ""
);

# Populate like this:
my @list_of_places_to_look = (
   File::Spec->catdir($ENV{PROJECT}, 'etc'),
   File::Spec->catdir($ENV{HOME}, 'etc')
);
# And then:
$ PROJECT=foo myscript.pl
# Profit!