I think most engineers share a unanimous opinion that users are stupid.  While I don't share this view, I am often times surprised at how a very intelligent person can become helpless and completely incapacitated when put in front of technology.

What is more amusing to me is that engineers are still surprised by this.  I think there is a level of intellectual avarice that is present in most engineers.  This causes a simple break down in expectations.  This violates one of my basic principles in life:

Last night was the Seminar #2 by the Japan Perl Association.  I had fun speaking, although my talk on Catalyst tips was not in sync with the audience.  They were not Catalyst users, but interested in it.  It would have been better to talk about an introduction to Catalyst and a live app building session, but I still enjoyed my time there.

Daisuke's Moose talk was very good, and I think engaged a lot of the audience members so I was very pleased about that.  There was immediate benefit to the audience, and it was apparent.

Daisuke has really done a tremendous amount of work in getting the JPA going, and working with various Japanese companies to provide a valuable community resource.  I'd like to give him a special hat-tip, because I think the Perl community needs more people in that type of role.

Perl is a great language, and is still (perhaps excessively) modern.  It languishes in perception only, and the businesses that utilize Perl have a hard time finding new employees. There tends to be interaction with the same -- nearly stagnant -- community members, with very few newcomers.

This is not a healthy ecosystem, but I think it will slowly improve.

By providing support to the companies that use Perl, it will highlight that there are jobs available and the language is still dynamic and growing.  This, in turn, will inspire other companies to investigate Perl as the language of choice (as I think PHP will continue a downturn in market share to the likes of Perl/Python/Ruby).

Supporting the businesses and showing them that the community can and will support them is important, and Daisuke and the rest of the JPA team is showing just how to do that.

I look forward to watching the JPA grow, and perhaps even open up other chapters in other countries that focus on providing value specifically to Perl-based businesses.

Geocoding has come a long way.  Back when I first launched, and subsequently (and regretfully) ignored, toEat the only real mechanism for Geocoding was to either pay a lot of money or to parse the US Census data (which I did via the Geo::Coder::US perl module).

Now, nearly 4 years later we have Geocoding services for multiple countries provided for free (I'd hate to be in the commercial geocoding business).  The accuracy is better, and generally an improvement over what was available in all forms.  Except, now there is more discrepancies.

If you look at the Google vs. Yahoo! geocoders, you'll get very subtly different results as far as the data.  The envelope is hideously different, and doesn't normalize properly.

As an example of this, if you put in a vague address such as "Main St. Vancouver, WA" into Google, you get a result with some information on the area (including county) as well as a bounding box to determine the location.  It gives an accuracy level, which lets you have confidence in what you are actually looking at.

Contrast to Yahoo.  You get a list of potential locations, with centered coordinates, but no accuracy or other information.  Very limited, and it seems like a very half-hearted attempt by Yahoo to provide a Geocode API just to compete with Google.

I can't just say to drop Yahoo! completely and use Google, because in some cases the Yahoo! results are more accurate than Google, but it seems reasonable to expect at least a similar format.

This has been the main impetus for me to work on a Geo::Coder::Any perl module that will normalize the response based on any Geocoder to "hide" some of these discrepancies.  The main problem is trying to apply an accuracy rating based on holistic evaluation of what other geocoders return.

I recently dove into an existing project, and one thing was subtly different from previous projects I was blessed to work with.  There was no style guide action.  Amusingly, the curator of this project is the one who initially introduced me to the splendid idea of style guide actions.

I've now just gained how much, from a developer perspective, I appreciate this.

The style guides are very simple to implement into an application, and generally platform agnostic.  Whether you use Django, Rails, Catalyst you can still do something like this very easily. 

Since I'm a Catalyst hacker, I'll show a recipe for building style guides that I commonly use.  It creates a "Debug" controller that you can place actions that should only run under debug mode, or some other conditional.  The 'guide' action then resides in this controller.

package MyApp::Controller::Debug;
use parent 'Catalyst::Controller';

sub setup : Chained('/') PathPart('debug') CaptureArgs(0) {
 my ( $self, $c ) = @_;
 unless ( $c->debug ) {
 # Detach (stop execution) and go to the default action
 # (Which is usually a 404 handler)
 $c->detach('/default'); 
 }
}

sub guide : Chained('setup') Args(0) {}

1;

I really love Perl.  I think the things you can do with the language are simply boggling, and unless you go into more academic languages you simply won't find them.

To support this bold assertion, I invite you to look at a rather interesting Moose extension called "MultiMethods".  Just look at the synopsis.  Oh, hell, we both know you aren't going to, so I'll reproduce it here:

  package Paper;  use Moose;
  package Scissors; use Moose;
  package Rock;   use Moose;
  package Lizard;  use Moose;
  package Spock;  use Moose;

  package Game;
  use Moose;
  use MooseX::MultiMethods;

  multi method play (Paper  $x, Rock   $y) { 1 }
  multi method play (Paper  $x, Spock  $y) { 1 }
  multi method play (Scissors $x, Paper  $y) { 1 }
  multi method play (Scissors $x, Lizard  $y) { 1 }
  multi method play (Rock   $x, Scissors $y) { 1 }
  multi method play (Rock   $x, Lizard  $y) { 1 }
  multi method play (Lizard  $x, Paper  $y) { 1 }
  multi method play (Lizard  $x, Spock  $y) { 1 }
  multi method play (Spock  $x, Rock   $y) { 1 }
  multi method play (Spock  $x, Scissors $y) { 1 }
  multi method play (Any   $x, Any   $y) { 0 }

  my $game = Game->new;
  $game->play(Paper->new, Rock->new);   # 1, Paper covers Rock
  $game->play(Spock->new, Paper->new);  # 0, Paper disproves Spock
  $game->play(Spock->new, Scissors->new); # 1, Spock smashes Scissorsaa

It seems the Perl world is picking up steam.  Perl 6 facilities are become more widely available, in conjunction with Moose and Perl 5.10 goodies.  While many others have said similar things, it's becoming less important to get Perl 6 out now, since so many great things are available right now.  Without evil hacks, even.  No source filters, no other hacky ideas.  Very solid code that helps you do more, better and more clearly.