bricas’ blog

My latest five:

RT #33158 - rejected (DBIx::Class)
RT #25445 - already applied (DBIx::Class)
RT #26978 - closed (DBIx::Class)
RT #31473 - closed (DBIx::Class::Schema::Loader)
RT #29041 - fixed this last year (Catalyst::Plugin::Session::PerUser)

I ventured into some DBIC related bugs this time.

RT #32497 - rejected (Catalyst::Model::DBIC::Schema)
RT #31848 - doc fixed (Catalyst::Model::DBIC::Schema)
RT #29282 - duplicate (DBIx::Class::Schema::Loader)
RT #23749 - already patched this last year (Catalyst::Plugin::Session::State::URI)
RT #20142 - closed (Catalyst::Plugin::UploadProgress)
RT #32276 - rejected (Catalyst::Runtime)
RT #26732 - closed (Catalyst::Runtime)
RT #34293 - duplicate (DBIx::Class)
RT #32988 - pod fixed (DBIx::Class)
RT #33217 - closed (DBIx::Class)

I ended up doing twice my quota for today (it's easy to take care of the low-hanging fruit). A variety of Catalyst::* and DBIx::Class tickets were closed.

RT #15941 - rejected (Catalyst::View::TT)
RT #32254 - duplicate (Catalyst::Plugin::Authentication)
RT #30506 - closed (Catalyst::Plugin::Authentication)
RT #33302 - closed (Catalyst::Manual)
RT #32091 - closed (Catalyst::Manual)
RT #29496 - duplicate (Catalyst::Manual)
RT #32636 - pod fixed (Catalyst::Manual)
RT #34256 - dependencies updated (DBIx::Class)
RT #33667 - patch applied (Catalyst::Session::Store::FastMmap)
RT #32393 - closed (DBIx::Class)

The Ubuntu "5-A-Day" campaign has caught my eye. It's turned a heinous task into a bit of a game. It reminds me a little bit of the ESP Game for image tagging (i.e. boring task => game).

I don't expect I could ever really take care of 5 bugs every single day, but I've given myself a little jump start by closing 7 Catalyst-related bugs yesterday. Only one of them took a significant amount of time to fix as it required some patching to the various parts of the Catalyst dispatch cycle.

Here are my five (plus two):

RT #30660 - Just needed to be closed
RT #30087 - Again, just needed to be closed
RT #35690 - Fixed POD
RT #33236 - Tiny grammar fix
RT #29334 - Fixed in trunk
RT #26452 - Test workaround in trunk
RT #24743 - Latest Catalyst::Manual upload fixes this

So, we're experiencing the worst flooding we've ever had in 35 years. [1] [2] My $work is only a few blocks from the river, but we've lucked out and haven't had any water in the building. What's even more remarkable is that they didn't shut the power off to our section of the grid so all of our services remain online! (disaster planning? ppfft! who needs it?)

The office was closed Thursday as the city wanted people to stay out of the downtown district. We came down anyway (as did a pile of other people) to try and grab some photos.

Above: the first photo is from Wednesday, when we could still get into Officer's Square -- By thursday afternoon, it was completely flooded.

Above: This is a street one block away from my office

Above: The lighthouse, normally accessible by land, is now more like a real lighthouse. The onramp to the bridge is innaccessible, as is the underpass. "parking lot full" hah!

I've been using Ubuntu since Dapper was released. As Hardy is the next LTS release, I decided now would be a good time to blow the whole thing away and start fresh. At the same time, I thought I could give rid of some KDE-based software I've been using and stick to a strictly Gnome environment.

I've been using Amarok as my media player, but, as stated above, that doesn't jive with a pure Gnome setup. By default Rhythmbox is installed. I can import all of my tunes in no problem, but I'm missing some play stats.

Given my old Amarok database, which is just an SQLite database, and a Rhythmbox database, which is a simple XML file, with freshly imported tunes I was able to write a script to pull out some of my old data including: rating, import date, last play date and play count. NB: Rhythmbox ratings don't understand half-star ratings, though it doesn't complain.

Usage: import.pl rhythmdb.xml collection.db

use strict;
use warnings;

use XML::Simple;
use DBI;
use URI;

my $xml = shift;
my $data = XMLin( $xml, KeepRoot => 1, ForceContent => 1 );

my $dbh = DBI->connect( 'dbi:SQLite:dbname=' . shift, undef, undef );
my $sth = $dbh->prepare( 'select rating, playcounter, createdate, accessdate from statistics where url = ?;' );

for my $row ( @{ $data->{ rhythmdb }->{ entry } } ) {
    my $mp3 = URI->new( $row->{ location }->{ content } );

    next unless $mp3->scheme eq 'file';

    $sth->execute( '.' . $mp3->file );

    my $dbrow = $sth->fetchrow_hashref;
    $row->{ rating }->{ content } = $dbrow->{ rating } / 2;
    $row->{ 'play-count'}->{ content } =  ( $row->{ 'play-count'}->{ content } || 0 ) + $dbrow->{ 'playcounter' };
    $row->{ 'first-seen' }->{ content } = $dbrow->{ 'createdate' };
    $row->{ 'last-seen' }->{ content } = $dbrow->{ 'accessdate' };
}

XMLout( $data, KeepRoot => 1, XMLDecl => 1, OutputFile => $xml );

Dear lazy-perl-web,

Has anyone done non-blocking access to USB devices? Device::USB uses libusb 0.1.x -- which only does blocking access. libusb 1.0 is to include callback-based access -- it's under development at least, but no perl bindings exist.

Is there anything else out there to try?

At $work, we decided that we kind of liked the idea of showing thumbnails of the sites we've linked in a particular section of our site. Naturally, there are existing services that can be used to do this. However, we weren't too hip on relying on those services.

We decided to try and make our own thumbnail service. We took an old machine, put Ubuntu (7.10) on it, and created a fairly simple script to control Firefox and generate the screenshots. It uses X11::GUITest to do the automation and Imager::Screenshot to process the screen:

use strict;
use warnings;

use Imager::Screenshot ();
use X11::GUITest       ();
use Digest::MD5        ();
use CGI                ();

my $start   = '~/blank.html';
my @urls    = load_config( shift );
my $destdir = shift;
my $id      = close_and_reopen_firefox();

my $count = 0;
for my $url ( map { CGI->unescapeHTML( $_ ) } @urls ) {
    # skip "comments"
    next if $url =~ m{^#};
    # skip existing screenshots
    next if -e gen_filename( $url );

    load_page( $url );
    sleep( 20 );
    take_screenshot( $id, $url );

    # reload firefox after 100 urls
    if ( ++$count == 100 ) {
        $id    = close_and_reopen_firefox( $id );
        $count = 0;
    }
}

# close firefox
X11::GUITest::SendKeys( "%({F4})" );

sub gen_filename {
    my $url = shift;
    return "${destdir}/" . Digest::MD5::md5_hex( $url ) . '.jpg';
}

sub take_screenshot {
    my $id  = shift;
    my $url = shift;
    my $i   = Imager::Screenshot::screenshot( id => $id );

    # remove the scrollbar + scale
    $i = $i->crop( right => $i->getwidth - 15 );
    $i = $i->scale( xpixels => 150 );
    $i->write( file => gen_filename( $url ), jpegquality => 75 );
}

sub load_page {
    my $url = shift;
    X11::GUITest::SendKeys( '%({LEF})' );    # go "back"
    X11::GUITest::SendKeys( "^(l)" );
    X11::GUITest::WaitWindowViewable( 'Open Web Location' );
    X11::GUITest::SendKeys( "${url}{ENT}" );
}

sub close_and_reopen_firefox {
    my $id = shift;
    if ( $id ) {
        X11::GUITest::SetInputFocus( $id );
        X11::GUITest::SendKeys( "%({F4})" );
    }

    X11::GUITest::StartApp( "firefox $start" );
    ( $id ) = X11::GUITest::WaitWindowViewable( 'Mozilla Firefox' );
    sleep( 2 );
    X11::GUITest::SetInputFocus( $id );
    X11::GUITest::SendKeys( "{F11}" );

    return $id;
}

sub load_config {
    my $file = shift;

    open( my $data, $file );
    my @urls = split(
        "\n",
        do { local $/; <$data>; }
    );
    close( $data );

    return grep { length } @urls;
}

Now, you might have noticed that we close firefox after 100 urls -- in reality, it never gets that far. Things seem to segfault around 25 urls in. I don't particularly understand why it's so unstable. We've disabled the "session recovery" feature so firefox won't get stuck asking questions on startup, plus fast back<->forward history rendering in case it was leaking memory.

Hopefully someone will find this bit of code useful, and perhaps someone has some ideas as to how we can make this setup a little more stable.

I've pushed an initial release of XML::Atom::Ext::OpenSearch to CPAN. It's a pretty simple add-on to XML::Atom that will lead you read and write OpenSearch enabled Atom feeds. This module has been in the works for nearly a year. I've been working with jshirley and miyagawa and with the release of XML::Atom 0.28, all of the bugs seem to be ironed out.

In the distribution, I've included a Changes file which is YAML-compatible. NB: I've also copied the file to Changes.yml as one cannot expect every Changes file to be YAML. For the purpose of discussion, here it is inline:

# Revision history for Perl extension XML::Atom::Ext::OpenSearch.

0.01:
  date: Wed, 07 Nov 2007 08:39:38 -0400
  maintainer: Brian Cassidy <bricas@cpan.org>
  urgency: low
  changes:
    - original version

I've basically pilfered the ideas from the debian changelog specs. It's simple enough that it could be hand-generated, but at the same time parts could be auto-generated. Comments?

HTML tag clouds are pretty popular in a lot of websites. For the project I'm working on right now, i decided to try and mimic del.icio.us's implementation which is sortable by name or by frequency.

HTML::TagCloud is definitely the defacto standard for generating tag clouds in perl. I sorted the data in my SQL query based on the parameter pulled in from the query string and stuffed the data into the cloud. However, no matter what I did the output was always alphabetical.

It turns out that HTML::TagCloud doesn't retain insertion order and automatically sorts your data by tag name.

With Leon's blessing, HTML::TagCloud::Sortable is born. It's API compatible with HTML::TagCloud -- it even passes the same test suite. However, this subclass will also retain the insertion order, allow you to store arbitrary data for tags and sort of any tag field.

It's a little ironic that my main use case for the module was to not sort the tags, but, oh well.