Yes.

It's been pointed out to me that many programmers have issues with my blog because I'm writing about allomorphism, exceptions as flow control and other topics that are, frankly, not something a beginner programmer is going to warm to. I think that's a fair point and I'm going to try to start including information aimed at those new to Perl and those new to programming.

I'll start with subroutines. Specifically, an old, horrible example.

I recently blogged about extending the Perl debugger. Basically, if you use xx $some_var, you get love Data::Dumper output instead of the confusing debugger output:

DB<2> xx $shiny                                                                               
{
  foo => [
    1,
    2,
    4
  ],
  guess => sub {
      my $x = shift @_;
      return $x + 1;
  },
  this => "that",
  uno => {
    this => "that",
    "what?" => {
      this => "them"
    }
  }
}

You can fork it on github and clean up my awful code or install it from the CPAN when it's available.

In other news, if you ever extend the debugger, your code is going to look awful by default because there is just no way to get around that mess of global variables and action at a distance.

There are some tests which pass, but routinely fail in the debugger. Here's one example:

#!/usr/bin/env perl 

use Test::Most tests => 2; 

my $sub = sub { 
  local *__ANON__ = 'anon_sub'; 
  foo(@_); 
}; 

sub foo { 
  my $arg     = shift; 
  my $subname = ( caller(1) )[3] // ''; 
  $arg++ if 'main::anon_sub' eq $subname; 
  return $arg; 
} 

is $sub->(3), 4, 'Calling foo through proxy works'; 
is foo(3), 3, '... as does calling it directly';

See the bug?

Last day of the hackathon and things are going well. We're doing enough yak-shaving that I think it should be called a Yakathon, but that's a separate issue.

I always forget how to do this, so this is just Google fodder.

If I want to checkout a branch from someone else's repository:

git checkout -t -b $local_branch_name $remote_branch_name

The '-t' option says "track the remote branch from my branch". The '-b' option says to actually create the branch with the given name (name will be derived from $remotebranchname if omitted).

It's so simple that I don't know why I forget this, but I do. Now that I've posted this, I probably won't forget it again :)

Hate the Perl debugger? Want it to do more? I do. For example, I hate it when I see this:

  DB<1> x $before                                                                                            
0  HASH(0x100e37fd8)
   'foo' => ARRAY(0x100c5f1d8)
      0  1
      1  2
      2  4
   'guess' => CODE(0x100dc0d78)
      -> &main::__ANON__[run.pl:13] in run.pl:10-13
   'this' => 'that'
   'uno' => HASH(0x100db9000)
      'this' => 'that'
      'what?' => HASH(0x10088dfc0)
         'this' => 'them'

A few folks have talked about adding tags to Test::Class. This would allow us to do things like load 'customer' fixtures if something is tagged 'customer', or only run tests tagged 'model'.

Here's what I have working now:

Arrived in Vienna last night and walked across the city center to get to the hotel. It's my second time in Vienna and I love how beautiful it is.

I know why "date" and "time" are in there, but I suspect it's not common for most folks.

~  $ history | awk {'print $2'} | sort | uniq -c | sort -k1 -rn | head
 255 git
 174 fg
 108 vim
  79 prove
  58 ack
  56 cd
  51 ls
  42 time
  41 rm
  31 date

I recently asked Adam Kennedy why he went back to blogging on use.perl.org. He replied:

I stopped posting to blogs.perl.org until I can migrate everything from use.perl over to it.

Anyone want to work on a migration script? I'd do it myself were it not for the Veure project I'm on. You just have to look at the gists in this post or the image on this post to see why the communication is so much richer here. Of course, there are plenty of other reasons, but clearly blogs.perl.org is a great, modern platform for the Perl community and I'd love to see more people promoting it.

Testing is, in some sense, a mess. Part of the problem is similar to the dynamic/static schism: nobody seems to agree on what those terms mean. Case in point: what's "integration testing"? Here's the definition from the excellent Code Complete 2:

Integration testing is the combined execution of two or more classes, packages, components, or subsystems that have been created by multiple programmers or programming teams. This kind of testing typically starts as soon as there are two classes to test and continues until the entire system is complete.

Read that carefully. Look for a flaw.