Why I wrote Keyword::DEVELOPMENT

I've had a few discussions with people about why I wrote Keyword::DEVELOPMENT, a useful, but simple module. In short, it lets you do this:

use Keyword::DEVELOPMENT;

# later ...

sub consume_item ( $self, $item_slug ) {
    DEVELOPMENT {
      # expensive and time-consuming debugging code here
    }
    my $inventory = $self->inventory;
    return $self->new_exchange(
        slug => 'consume',
        Steps(
            Inventory(  $inventory => contains => $item           ),
            Consumable( $self      => consume  => 'item_instance' ),
            Inventory(  $inventory => remove   => 'item_instance' ),
        ),
    )->attempt;
}

The expensive debug block? With Keyword::DEVELOPMENT, is simply fails to exist in production unless the PERL_KEYWORD_DEVELOPMENT environment variable has a true value. Thus, there is no performance overhead to instrumenting your code with complicated debugging logic (as I'm currently doing with Tau Station).

It's been pointed out to me by several people that I can accomplish the above in regular Perl with constant folding. I'll explain what that means and why I prefer the keyword route.

What is a "Senior Developer"?

When a company hires All Around the World to develop new systems or work on existing ones, they're sometimes surprised to find out that, with few exceptions, we only hire senior engineers. We're not a "body shop." We're the experts you hire when you need things to work and you've discovered that the $100 a day freelancer wasn't such a bargain after all (true story).

So when a self-described intermediate developer asked me what I meant by "Senior Developer", and does it just meant "time on duty", I realized that what we're looking for is different from what other companies look for. We have high standards and a difficult hiring process, but it's worth it.

What follows is my (edited) response to that developer.

Writing Declarative Perl

At The Perl Conference in Washington DC, I'll be giving a talk on Modeling a Universe in Perl. For previous versions of this talk, people have asked for more information about how we model complex actions in a (mostly) declarative manner. For example, here's the code for purchasing a clone:

It's the Steps() function which is our declarative code. As you might imagine, there are tons of actions which might require that you be in a particular area, or have credits removed from your wallet, so the Area and Wallet lines can be dropped into any Steps() function anywhere throughout our code. But people want to know how this works. In reality, it's pretty simple.

Better SQL tracing with DBIx::Class

I've been trying to track down some SQL issues with Tau Station and to be honest, I've never been terribly happy with the output from the DBIx::Class DBIC_TRACE or the DBI DBI_TRACE. So I have something better.

Using the Perl debugger with DBIx::Class

I wrote about using the Perl debugger with Moose. In that post, I showed how to use DB::Skip to make it easier to use the Perl debugger with Moose and other modules whose guts you don't want to wade through.

Today's debugger hack will make using the debugger with DBIx::Class much easier.

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/