kentcowgill.org/blog

I made it my mission this week to teach Spike how to "shake".

I only had to use a few inches from the jar of thinkly sliced snausages™, as you might've noticed from my photos.

Today I evangelized my Sony reader, and ebook devices in general, to two separate people. So I figure I ought to do it with a bit wider audience.

I had about four devices to choose from. The iRex Iliad, the Bookean Cybook, the Amazon Kindle, and the Sony PRS505.

For a number of reasons, I went with the sony - chief among them being price and availability. Least expensive, and I could go to either a local Best Buy or Borders to pick one up, play with it, buy it, and start using it the same day.

It's just amazing. Small, slim, lightweight, and easy to read.

Works with my Mac.

Tons of ebooks available online - no late night trips to the bookstore to make sure I have reading material for the next days' commute.

No more need for additional storage space in my basement.

Life changing? Maybe a little melodramatic.

But it has made the time I spend getting to and from work a lot more enjoyable. And most importantly, more efficient.

Major props to Lisa for this awesome Christmas gift.

If you've already downloaded a copy of the slides from my first talk (Testing Code and Assuring Quality) then this update is for you.

By popular demand, I've added the lolcats back into the presentation in the appropriate places.

But more importantly, I'm no longer at the company for which I created this testing infrastructure. As such, I've updated the company name and technology name(s) to anonymize them a bit.

Just in case.

The biggest thing this means is that I need to re-record the screencasts before I can release those as well, being sure to remove any non-anonymous and non-proprietary information that may or may not already be in the recordings.

Which will take some time. :(

The good news is that the other talk I've prepared (and presented) on "Simple Photo Processing and Web Display" has never had any such information in it, so once I've got it in its final polished state, the publishing of the slides will be that much quicker.

Keep an eye on my slideshare slidespace for updates.

My mom sent us a nice christmas gift, including a dog toy for Spike, and two catnip scented toys for Shadow and Butterscotch. Turns out that shipping catnip toys in a box with another plush toy will pretty much make it smell like catnip, too.

We were wondering why the cats were so interested in the dog toy, but then we noticed that Spike was a little more interested in the toy than normal. Turns out Spike enjoys the scent of catnip too.

We had to capture some of the fun on video.

Full size video is here

There's another one where we discover that it's the catnip, as well as the rest of my videos, in my youtube channel.

So, I finally decided to stop putting it off and upload the slides from my testing talk onto slideshare.net. Click here to view these slides, as well as any future slides I make public.

Unfortunately, this presentation/slide set was heavy with screencasts, which don't survive the transition to PDFs very well. I'm considering hosting the screencasts elsewhere.

Enjoy!

After Lisa and I got back from Thanksgiving dinner, we decided to take a few pictures of how well Spike was balancing in order to earn some tasty morsels of smoked turkey.

For the full size movie, click here

So I'm working on a new presentation for my local Perl Mongers group, and (indirectly) thanks to Ricardo Signes, I've got a cool way to get properly syntax colored code into my slides.

Ricardo has been working on an easy way to get syntax colored code into Keynote presentations. I wondered why he was bothering to convert the syntax colored code to RTF - then I realized why - I think because TextEdit.app on Mac OSX is a cocoa application, the font coloring is preserved through copying and pasting the code into Keynote, another cocoa application.

A little later on, I was creating some other presentation, and was copying some code out of my blog and happened to notice that the code I copied and pasted from Safari, my web browser, also retained its coloring information.

Problem solved, right? Anything I want to put into a Keynote slide, I should blog about first. Right?

Wrong.

That's too much blogging.

Instead, I wrote a teeny tiny little CGI to post up the syntax colored source of anything sitting around on my server, using the same Text::VimColor module on the backend.

This is that CGI:

#!/usr/bin/perl -T

use strict;
use warnings;
use Text::VimColor;
use CGI qw/:standard/;
use CGI::Carp qw/fatalsToBrowser/;

$ENV{'PATH'} = '/bin';

my $file = param('f') || 'photos/photoblog';
my $lang = param('l') || 'perl';

die "Bad file" if $file =~ /^[^a-z]/i;
die "Bad file" if $file =~ /[^a-z\/._-]/i;
die "Bad file" unless -f $file;

die "Bad type" unless $lang =~ /(?:perl|php|xml)/;

open my $in, '<', $file;
my $text = do { local $/; <$in> };

my $vim = Text::VimColor->new(
  string      => $text,
  filetype    => $lang,
  vim_options
    => [qw(-RXZ -i NONE -u NONE -N -T xterm)],
  vim_command => '/usr/local/bin/vim',
)->html;

... and then a little HTML to display it in the right font, font size, and using my standard code stylesheet - which is left as an exercise for the reader.

Someone on #perl on irc.perl.org complained of someone else "blogging on IRC".

Well, blogging (as you can see above) is the short form of weblog.

On IRC, there is no web.

So, IRC logging (of events happening in one's life) is now known as "clogging". Instead of weblog, it's irclog, shortened to clog.

Enjoy.

Hello, I forgot to post a note about this.

My third contribution to CPAN is an important one. It is Acme::LOLCAT.

Or, to translate this announcement into LOLCAT using this module:

OH HAI, I FRGOT TO POST NOTE ABOUT THIZ.

MUH THIRD CONTRIBUSHUN TO CPAN AR TEH AN IMPORTANT ONE. IT AR TEH ACME::LOLCAT. KTHX.

OR, TO TRANSLATE THIZ ANNOUNCEMENT INTO LOLCAT USIN THIZ MODULE:

I'm really not understanding something. I've run into a module for which I had a lot of difficulty writing the first few tests. This usually happens when the module under scrutiny does something a little weird, so I'm used to it by now.

But this one is a lot weird.

The code for the module I'm looking at is structured exactly like this:

package foo;

use strict;
use warnings;

sub firstSub {
  my $string_orig = shift;

  # in the production code, this
  # somehow works and doesn't die
  my $string = secondSub $string_orig;

  return ( foo => $string, bar => $string_orig );
}

sub secondSub {
  my $string = shift;
  my $ret = join '', reverse split //, $string;
  return $ret;
}

1;

What's strange is that when I use the module and try to call "firstSub", I get a Can't locate method object secondSub via package VALUE_PASSED at line blah, of course substituting VALUE_PASSED for whatever value I actually pass :) But the module - as is - works on the development server, and has worked on the production server for years with this exact structure and syntax.

So for this example, this code (reduced to the smallest example that still exhibits the behavior, but essentially the same structure) tries to call the modules' subroutine via:

use foo;

my %q = foo::firstSub( 'MTFNPY' );
  
print "$_: $q{$_}" for keys %q;

And the output I get is:

A little boggling. I tried a few things, including this ugliness:

{
  no warnings 'once';
  *MTFNPY::secondSub = \&foo::secondSub;
}

... but of course that will only work as long as I'm passing the value of "MTFNPY".

Running the code through B::Deparse confirms that line is interpreted as my $string = $string_orig->secondSub.

I see I've got a couple of options:

1. Fix the code minimally - re-order the subroutines inside the module so the second subroutine is defined first, so it will be correctly interpreted as a function call.
2. Fix the code a little less minimally - add parens around the argument to secondSub.
3. Fix* my tests and don't touch the original code until my tests are complete so I am 100% certain I don't break anything else. (I'm fairly sure either of these changes won't, but "fairly" isn't 100%).

* By which I mean 'just make it work'

So, I add this near the top of my test file:

BEGIN {
  package foo;
  use subs 'secondSub';
}
use_ok( 'foo' );

... which basically tells the interpreter that package foo will be defining a subroutine called secondSub, which is to say predeclaring them - before the foo module has a chance to load, by taking place inside a BEGIN block.

And lo, testing successful.

But what I still don't understand is how exactly the code in the original module works at all! I'm testing on the same box where the code lives - where the code runs day in and day out without bringing the test server down to a screeching halt. I know - I added trace debugging statements all around, thinking that perhaps the code has always been silently failing and the failure was just dealt with. But no, the code was making it through that step and doing exactly what my predecessor(s) expected it to do. It's just doing it wrong.