bluefeet

Fixing Pixelated Images on the iPhone

Sun, 29 Jan 2012 13:01:00 -0800

When an iPhone with a retina display (iPhone 4+) displays an image on a web page that image’s size is doubled, so each pixel in the image actually takes up 4 pixels and looks pixelated. This looks unprofessional and tacky. Here’s an example of a 245x80 image:

You’ll have to load this page on an iPhone to see the problem in the above image. The pixels in the image have jagged edges and the photo overall looks blurry.

To get around this all you need to do is double your image size and explicitly set the image size in the tag to its original non-doubled size. So, in our example the image is now 490x160, but we set the img tag as . Here’s what it now looks like with the image stored at double resolution:

Now it looks crisp on the iPhone.

Adding Responsive Design to Tumblr Themes

Sun, 29 Jan 2012 11:39:00 -0800

If you’re using a single-column fluid layout theme in Tumblr then adding responsive design is dead-easy. If you’re using a more complex theme, that is not fluid width and single-column, then you’ll have to put a lot more work in, but it is still well worth the effort.

By default Tumblr overrides your theme with a mobile-friendly theme when your blog is accessed by a phone. Here’s what my site looks like when Tumblr does this:

The override theme is incredibly basic and provides no extra functionality. You loose your custom design that sets you apart, you loose Disqus comments, etc.

The first step then is to disable Tumblr’s override mobile theme. To do this, go in to the “Customize appearance” tool for your theme. Once open, scroll down in the left-hand pane and open the “Advanced” section. Under here there is a checkbox titled “Use optimized mobile layout”. Uncheck this and click save at the top. Now your theme will always be used. Load up your site on your phone and have a look. Here’s mine at this step:

At this point this appears to be a step backwards - you’ve now made your site less usable. In order for people to use your site now they have to zoom in and scroll left to right for each line they want to read. If we left our site in this state it would be a miserable fail. You can fix this by adding this line just before the tag in your theme’s HTML:

This “viewport” meta tag is telling the browser to not zoom out. By default mobile browsers zoom out enough so that the site can have a display width comparable to a desktop. For fixed-width sites there is no better solution, but for fluid width sites (or sites that only have a max-width, but not a min-width) disabling this auto-zoom provides a much better experience.

So, with this meta tag added, the site now looks like this:

Now the site looks very close to Tumblr’s mobile override theme, but with all your customizations and custom design enabled. Not bad! There are still some issues, such as the body padding being too thick at this resolution. But, overral this is a great step forward.

Now we can make a few more adjustments by using CSS3 media queries. Media queries allow us to craft CSS that is applied only in certain situations. In this case we want the padding around the body to be reduced if the width of the site is below a certain level. Adding this line to the CSS does just that:

@media screen and (max-width: 480px) {
    body { padding: 5px; }
}

Now, when accessed with a browser that reports a width of 480px or less (which in my testing is iPhone in both portrait and landscape mode) then the site looks like this:

Much better! Now when the site is accessed by a phone, the padding is reduced from 30px to 5px and we take better advantage of our screen real-estate.

Now you should have the tools to take your own Tumblr blog to the next level and make it friendlier for your visitors.

Adding Syntax Highlighting to Tumblr Posts

Thu, 26 Jan 2012 10:56:00 -0800

I’ve just moved my blog to Tumblr. One thing that most my posts have are code examples. Here’s how I added this to my Tumblr blog. Go in to the customization section of your blog where you can configure the theme. Once there, click the “Edit HTML” button and add this somewhere before the ending tag:

Adjust “solarized_light.min.css” to point to whatever highlight.js theme you’d like to use. The themes can be viewed on the highlight.js test page.

The only problem I’ve run in to is with tumblr’s infinite scrolling feature. Since highlight.js is applying syntax highlighting when the page first loads then any code blocks that are loaded as you scroll will not get highlighted. I’m sure there is a way around this, but for now I just disabled this feature in my blog’s preferences.

Check out SQL::Abstract::Query

Mon, 19 Sep 2011 19:47:00 -0700

During the last few months I’ve been working on the CPAN distribution SQL::Abstract::Query. The drive for doing this is that DBIx::ResultSet (another module of mine) currently has lack-luster support for auto-incrementing IDs, has a custom and inflexible solution for GROUP BY, and has no support for JOINs.

To solve the first problem, with lack of good auto-incrementing ID support I wanted to make a generic module that would allow anyone to retrieve these IDs and could be used independently from DBIx::ResultSet. So, I set out to build DBIx::AutoID. I quickly found that there is a huge myriad of complexities to do this right for all the different databases out there. In the end I came to the conclusion that I need some way for an INSERT to be represented as an object so that DBIx::AutoID can modify it, if it needs to, before it is executed so that the ID may be returned.

The second two issues, bad support for GROUP BY and none for JOINS, really just required extending SQL::Abstract and overriding its behavior.

So, take a look at SQL::Abstract::Query on CPAN and let me know what you think. I’d really like to get some feedback. There is a large list of TODOs, but I’m confident that the interface as it is now won’t change much, just the internal guts need some work here and there.

Expect DBIx::AutoID (with inspiration from DBIx::Class) to be on CPAN in a few weeks as well. Then, I’ll get around to updating DBIx::ResultSet with all these new and more powerful features.

PS: The current development work is being done on the SQL-Abstract-Query github repository.

Using DBI Effectively: bind_columns()

Tue, 16 Aug 2011 22:13:00 -0700

One of the most under-utilized features of DBI is is the bind_columns() method. The majority (as in everyone) that I show bind_columns() to have never seen it before or used it. Here’s what it looks like:

my $sth = $dbh->prepare('SELECT name, email FROM users');
$sth->execute();
$sth->bind_columns( \my( $name, $email ) );

while ($sth->fetch()) {
    print "$name: $email\n";
}

bind_columns() takes a list of scalar references as its arguments. The form you see above with \my(…) is just a little known Perl-ism shortcut for:

my ($name, $email);
$sth->bind_columns( \$name, \$email );

There are two important reasons why bind_columns() is so awesome:

First, it greatly reduces the complexity of the code within the while() loop since you do not have to lookup in to an array ($sth->fetchrow_array()), de-reference an array ($sth->fetchrow_array()), or de-reference a hash-ref ($sth->fetchrow_hashref()). Instead the values themselves are available via appropriately named scalars.

Secondly, when using bind_columns() DBI is re-using the same scalars every time a fetch() is done which is much faster than creating an array or hash every fetch and typically causes the values to be copied one less time than normal. Benchmark it yourself - bind_columns() can make a huge difference when processing large sets of data.

Chained Git Hooks

Tue, 02 Aug 2011 08:50:00 -0700

So I’ve be wrestling with getting chained git hooks working. I’m surprised that Git doesn’t support this out-of-the-box as it seems very short-sighted. Here’s a Perl script I implemented to get this working:

#!/usr/bin/env perl
use strict;
use warnings;

use autodie;
use File::Temp qw( tempfile );
use IPC::Cmd qw( run );

if (@ARGV and $ARGV[0] eq 'wrapper') {
    shift( @ARGV );

    my $hook_filename = shift( @ARGV );
    my $temp_filename = shift( @ARGV );

    open( STDIN, '<', $temp_filename );

    exec($hook_filename, @ARGV);
}

my $hook_type = $0;
$hook_type =~ s{^.+/}{};

my $git_dir = $ENV{GIT_DIR} || `git rev-parse --git-dir`;
chomp( $git_dir );
my $hook_dir = $git_dir . "/hooks";

opendir( my $dh, $hook_dir );
my @hooks = sort grep { /^${hook_type}_/ } readdir( $dh );
closedir( $dh );

my ($temp_fh, $temp_filename) = tempfile(UNLINK => 1);
while (my $line = ) {
    print $temp_fh $line;
}
close( $temp_fh );

foreach my $hook (@hooks) {
    my ($success, $error) = run( command => [
        $0, 'wrapper',
        "$hook_dir/$hook", $temp_filename,
        @ARGV,
    ]);
    print join('', @$full_buf);

    if (!$success) {
        die "Error running hook: " . $hook . ": $error\n";
    }
}

So, what you do is put this somewhere you can get at (perhaps just drop it in your hooks directory with the name “chained_hook”), chmod 755 it, and then symlink all your hooks to it, for example:

ln -s chained_hook applypatch-msg
ln -s chained_hook commit-msg
ln -s chained_hook post-commit
ln -s chained_hook post-receive
ln -s chained_hook post-update
ln -s chained_hook pre-applypatch
ln -s chained_hook pre-commit
ln -s chained_hook pre-rebase
ln -s chained_hook prepare-commit-msg
ln -s chained_hook update

Each of these chained hooks will now look for sub-hooks with the name “hookname_subhookname”. So, you could add a “post-receive_email” and “post-receive_foo” hooks and both will be called, in sorted order, by the post-receive hook.

So, I’m wondering - do people think this is a good solution? Are there better solutions? Is there a simpler way to write this script?

Adding Files to Subversion With @ in Their Name

Thu, 21 Jul 2011 08:26:00 -0700

I just ran in to this today. If you try to do this:

svn add this\@that
svn: warning: 'this' not found

In order to ‘svn add’ a file with a ‘@’ character in it you must end the add command with an ‘@’ character, as in:

svn add this\@that\@
A          this@that

Presentation: Moose Best Practices

Fri, 13 Aug 2010 14:57:00 -0700

I wrote this for the TO.pm meeting on August 11th, 2010:

Presentation: Tools of the CPAN Ninja

Thu, 10 Jun 2010 08:22:00 -0700

I wrote this for the TO.pm meeting on June 10th, 2010:

BLOBs, Synonyms, and DBD::Oracle

Thu, 03 Jun 2010 15:29:00 -0700

INSERTing, UPDATEing, and SELECTing LOBs (CLOB/BLOB) in Oracle using Perl can be a PITA. Case in point: 2 years ago a fellow coworker ended up writing some extremely complex code using ora_lob_write(), etc, when all he really needed to do was use bind_param() and declare that the blob column is a blob so that DBD::Oracle would know to treat is specially. At the time I believe he did try something like:

my $sth = $dbh->prepare(q[
    INSERT INTO some_table (color, blob_data)
    VALUES (?, ?)
]);
$sth->bind_param( 1, 'red' );
$sth->bind_param( 2, $data_for_blob, {ora_type => ORA_BLOB } );
$sth->execute();

But then an error like “DBD::Oracle::st execute failed: ORA-04043: object some_table does not exist (DBD SUCCESS: OCIDescribeAny(view)/LOB refetch)” was raised. Which made no sense since some_table is very much an object and any number of SQL operations work on it… when BLOBs are not involved. In the end he ended up having to write code that was triple the size to get around this issue.

So, 2 years later and a little hair pulling, I come to figure out by luck that the problem is that the underlying DBD::Oracle code, that makes dealing with BLOBs simple, fails when you are using a synonym in your insert. All we had to do is fully spell out the table name, and it works!

my $sth = $dbh->prepare(q[
    INSERT INTO some_schema.some_table (color, blob_data)
    VALUES (?, ?)
]);
$sth->bind_param( 1, 'red' );
$sth->bind_param( 2, $data_for_blob, {ora_type => ORA_BLOB } );
$sth->execute();

Generating Constants in Perl

Fri, 21 May 2010 16:29:00 -0700

The other day @ $work I was throwing together a module that creates constants based on a fairly static table in the database. Of course I didn’t want to hard code the contants, I wanted them to be magically created by what was in the database. For the sake of this example I had a table called “toy_categories” where each record has a unique ID (toy_category_id) and a name that can only be letters and underscores. The data would look something like:

ID  NAME
--  --------------
12  dolls
 7  action_figures
92  education

And the resulting constants would look something like this:

TOY_CATEGORY_DOLLS = 12
TOY_CATEGORY_ACTION_FIGURES = 7
TOY_CATEGORY_EDUCATION = 92

If you read the core perl documents you might be lead to think that the constant pragma is the way to go. This is not the case - just because a particular library is distributed with Perl does not mean its a good tool, instead it usually means that the library cannot be removed or substantially modified for backwards-compatibility reasons. In my experience most core libraries are to be avoided - there are much better solutions on CPAN.

So, the CPAN solution to constants is Readonly. This module hooks in to Perl’s ability to mark a variable as read-only, much like how variables can be flagged as tainted or scalars as UTF. Make sure you grab Readonly::XS as well to get the full benefit of read-only variables without the performance hit.

So, if you were to create a module for these constants you might do something like this:

package MyApp::Constants::ToyCategories;
use strict;
use warnings;

use Readonly;
use Exporter qw( import );

our @EXPORT = qw(
    $TOY_CATEGORY_DOLLS
    $TOY_CATEGORY_ACTION_FIGURES
    $TOY_CATEGORY_EDUCATION
);

Readonly our $TOY_CATEGORY_DOLLS => 12;
Readonly our $TOY_CATEGORY_ACTION_FIGURES => 7;
Readonly our $TOY_CATEGORY_EDUCATION => 92;

1;

And then in some module you can access these constants:

use MyApp::Constants::ToyCategories;

if ($toy->category_id() == $TOY_CATEGORY_EDUCATION) {
    my $response = ask_question('Are you an educator?');
}

Now, like I said, I don’t want to hardcode the constants. I want them to be dynamically created by records in my toy_categories table which resides in my database. Its actually pretty simple to do this with some tricky evals:

package MyApp::Constants::ToyCategories;
use strict;
use warnings;

use Readonly;
use Exporter;
use Exporter qw( import );

our @EXPORT;

{
    my $dbh = code_that_returns_a_dbi_handle();
    my $sth = $dbh->prepare(q[
        SELECT toy_category_id, name
        FROM toy_categories
    ]);
    $sth->execute();
    $sth->bind_columns( \my( $id, $name ) );
    while ($sth->fetch()) {
        _export_variable( "toy_category_$name" => $id );
    }
}

sub _export_constant {
    my ($variable, $value) = @_;

    $variable = '$' . uc($variable);

    my ($error, $failed);
    {
        local $@;
        $failed = not eval(
            "Readonly our $variable => \$value"
        );
        $error = $@;
    }
    if ($failed) {
        die "Unable to create constant $variable: $error";
    }
    push @EXPORT, $variable;
}

1;

What’s going on here? Let’s start at the top:

use Exporter qw( import );

This is the least intrusive way of using exporter and doesn’t pollute your namespace nearly as much as ‘use base qw( Exporter );’ does and is friendlies to other modules.

my $dbh = code_that_returns_a_dbi_handle();

Replace this with whatever you use to get a DBI database handle. Take a look at DBIx::Connector for a great alternative to doing this directly with DBI.

my $sth = $dbh->prepare(q[
    SELECT toy_category_id, name
    FROM toy_categories
]);
$sth->execute();
$sth->bind_columns( \my( $id, $name ) );
while ($sth->fetch()) {
    ...
}

I’m a big fan of writing my DBI selects in this fashion with bind_columns() because it tends to be the fastest way to get the data (versus fetchrow_hashref, etc) and tends to lead to the simplest code within the while loop since it just needs to use $id and $name versus $row->{$id} and $row->{name} (for example).

_export_variable( "toy_category_$name" => $id );

While all of the code within _export_variable() could just be inlined right in the spot, that’s bad design. If you can get a piece of your code generalized and moved to a subroutine, do it.

$variable = '$' . uc($variable);

Constants should always, due to convention, be uppercase. It is very important that you code to popular conventions because other people will most likely be working on your code later and if you come from a common expectation of how various things are done they will have an easier time ramping up to your code. I try to code to the Modern Perl / CPAN conventions.

my ($error, $failed);
{
    local $@;
    $failed = not eval ...;
    $error = $@;
}
if ($failed) { ... }

This bit of code was taken from nothingmuch’s blog entry where he announces Try::Tiny which provides a safe way to handle eval errors. Read up there if you want to understand why the code was written this way.

$failed = not eval("Readonly our $variable => \$value");

While this code is several blocks deep in scope, this constant will exist in the package’s scope since it is being declared with ‘our’.

push @EXPORT, $variable;

And finally we add the variable to the list of variables that will be exported.

That’s it. After this was implemented I thought it was so useful, simple, but requiring the knowledge of a few tricks, that I’d share it with ya’all. Enjoy!

YAPC::NA 2010 Talks are Being Approved

Sat, 17 Apr 2010 23:36:00 -0700

I just got my approval for the two proposals I had submitted for this coming YAPC::NA 2010! I’m very excited. This will be my first time doing any sort of talk at a YAPC. I’ve been wanting to do this for years and I am very grateful that the organizers of the conference considered me. Over the last few years I’ve been trying to hone my presentation skills by presenting various topics almost monthly at the Thousand Oaks Perl Mongers and Los Angeles Perl Mongers.

The first talk is a five-minute lighting talk about how to clone yourself in Perl. For those that are unaware: lighting talks are a great YAPC tradition where around a dozen speakers will present 5-minute or less talks. These talks range from very advanced computer science topics, down to the silly, and sometimes bizarre.

The other talk I’m doing is a 40-minute lecture/discussion showing examples of writing concise code. This will be an extended version of the similar presentation that I’ve given at mongers. I’ll be delving in to real-world cases where writing code in a more concise manner, reduces technical dept, leads to more robust code, and a whole lot more.

See you at YAPC!

Cassandra Presentation

Thu, 15 Apr 2010 19:06:00 -0700

I wrote this for the TO.pm meeting on April 14th, 2010:

Robust DBI Transaction and Connection Handling

Sat, 23 Jan 2010 22:27:00 -0800

Edit: It turns out there is already a module on CPAN that does exactly what I talked about here. Its called DBIx::Connector. I haven’t tried it yet, but it looks like the guy that wrote it designed it with input from the DBIC guys.

I’m a big fan of DBIx::Class. Among DBIC’s many great features is its superb transaction and connection handling via DBIx::Class::Storage::DBI. When I’m using raw DBI I feel like I’m missing these core components. I should always be able to expect robust transaction and connection handling.

I started playing around with creating a new CPAN module (something like DBIx::Robust, DBIx::Transaction, etc…) but each time I dove in to it I kept coming to the conclusion that DBIC’s DBI storage drivers provide everything I need and I would just be shooting myself in the foot by either porting DBIx::Class::Storage::DBI to a DBIC independent API or by writing it from scratch.

Before I go any further, let me show you how attractive and awesome DBIC’s storage layer is:

Transactions may be nested, even without savepoints.
Transaction savepoints can automatically be tracked allowing for reliable and incremental rollbacks.
The appropriate DateTime::Format class is automatically determined based on the type of database.
All database calls efficiently pass through a layer that detects stale connections that will attempt to re-connect to a database.

“There is no charge for awesomeness, or attractiveness.”

The DBIx::Class::Storage::DBI pod illustrates all this in a round-about way: “If you set AutoCommit => 0 in your connect info, then you are always in an assumed transaction between commits, and you’re telling us you’d like to manage that manually. A lot of the magic protections offered by this module will go away. We can’t protect you from exceptions due to database disconnects because we don’t know anything about how to restart your transactions. You’re on your own for handling all sorts of exceptional cases if you choose the AutoCommit => 0 path, just as you would be with raw DBI.”

This stuff is really powerful, and we should never have to work with databases in Perl without it. But, currently, it is only meant to work under DBIC, which is a shame. I’m betting that DBIx::Class::Storage::DBI could be used directly, bypassing DBIC completely. There is some DBIC stuff layered in there, but that should be ignorable.

What do the rest of you think? Has anyone considered moving this logic out in to a generic distribution that isn’t DBIC specific? Is there merit in what I’m talking about? Does anyone use DBIx::Class::Storage::DBI directly, bypassing DBIC?

use HTML::FormHandler;

Mon, 12 Oct 2009 09:00:00 -0700

I’ve been meaning to give HTML::FormHandler a try for quite some time now. Over the weekend I converted a form from some home-grown form validation and html generation to use HTML::FormHandler instead. HTML::FormHandler was inspired by, and quasi-forked from, Form::Processor. There are many options for processing forms, such as FormValidator::Simple (Catalyst’s default) and Data::FormValidator, to name a few.

Up until now I’ve always thought that the existing form handling/validating modules on CPAN were incredibly lacking. They all have these crazy and inconsistent APIs that in the end limit what you are able to do. I don’t expect a form validation API to handle every possible situation, but I do expect it to provide a consistent API that is well documented and allows me to easily extend if I need additional functionality. Plus none of them use Moose (AFAIK), which isn’t just me being a Moose evangelist, its also practical because Moose provides mechanisms to extend functionality via roles and to provide reusable validation with MooseX::Types.

HTML::FormHandler solves these issues. HTML::FormHandler can be a complete end-to-end solution for declaring form fields and types, applying server-side validation, generating the HTML for a form, and applying form submits to the database. Almost everything and the kitchen sink is there, except client-side form validation, which can be added separately of course. Normally a “do everything” package scares me, especially for something like form validation. But, Gerda Shank (the author of HTML::FormHandler) did a great job splitting out the various pieces of HTML::FormHandler so that any piece of the form handling process can be subverted to your own needs, and there is copious amounts of documentation explaining how to do so.

The HTML::FormHandler::Manual::Intro does a great job introducing HTML::FormHandler.

There are a few downsides to this module’s current state. It is relatively new and is still stabilizing. For example, just recently the results of form validation were separated from the form object itself. This is a huge fundamental change, but a necessary one. Also, the concept of widgets was recently introduced. Widgets are a great way to extend and customize the display of form fields, and the form as a whole. But, this was just introduced and is still experimental, and has some rough edges. Despite this, the widget design is very promising and I ended up using it myself (thanks to HTML::FormHandler::Manual::Rendering) as my preferred rendering method.

Enjoy.

IE8, another screwed up version.

Tue, 01 Sep 2009 11:32:00 -0700

I was really hoping that Internet Explorer version 8 (IE8) would finally be the version of IE where Microsoft stepped up to the plate and produced a fast browser, with few bugs, less Microsoft-only features, and a good and modern UI.

I’m the kind of guy that holds judgment for a very long time, sometimes too long. So it comes with great sadness that I announce that IE8 is not the browser I was hoping for. It is riddled with bugs, the rendering engine crashes on many web sites, and it is SLOW. Its the slowest browser of them all as far as I can tell. It renders many web-2.0’ish sites with teeth-gritting sluggishness. Once rendered, javascript animations tend to be jumpy as well. I’ve found several cases where the event engine is even more screwed up than it was in IE7.

If you’re a web developer and IE8 is causing the same pain for you as it has for me, consider adding this to your HTML*:

* This should be the very first tag after the opening tag.

This will force IE8 to run in IE7 compatibility mode. When in IE7 compatibility mode IE8 will not crash nearly as often and will render your HTML/CSS/JS much more predictably and act more similar to how Chrome and FireFox behave.

I don’t understand why Microsoft keeps doing this. They have all the power in the world to WIN the browser war, but they are just going to keep failing with crap software like this and loose one more market to Google.

use Path::Class;

Wed, 05 Aug 2009 22:26:00 -0700

The CPAN (Comprehensive Perl Archive Network) distribution, Path::Class, provides a simple OO API alternative to the built-in perl file IO functions such as open, opendir, stat, etc. Code written to use Path::Class tends to be smaller (concise, easier to maintain, etc) than similar code that uses the standard built-in functions.

Here is an example of how a small utility might be written without Path::Class:

print "Find all files that are less than 10k in size...\n";

my $dir = '/some/dir';
opendir( DIR, $dir );
    my @files = readdir( DIR );
closedir( DIR );

foreach my $file (@files) {
    next if !-f "$dir/$file";
    if ( (stat "$dir/$file")[7] < 1024 * 10) {
        print "$dir/$file\n";
    }
}

And here it is re-written to use Path::Class:

use Path::Class;
print "Find all files that are less than 10k in size...\n";

my $dir = dir('/some/dir');

while (my $file = $dir->next()) {
    next if $file->is_dir();
    if ($file->stat->size() < 1024 * 10) {
        print "$file\n";
    }
}

Using Path::Class is a no-brainer when you compare (stat "$dir/$file")[7] with $file->stat->size().

One of Path::Class’s greatest stengths is that it is very simple and many of the features it provides are done so by glueing with other well-tested modules that have been on CPAN for a long time. These modules include IO::Dir, IO::File, File::Path, and File::stat.

Some other highlights include:

Has a recurse() method that provides an enhanced File::Find-like interface.
Works equally well with absolute and relative paths, and can correctly convert between the two.
Symlinks are handled correctly and there are methods to interact with them.
Works equally well under different operating systems, such as Linux and Windows.
The interface, for me anyway, is about as intuitive as it gets. Very well designed to DWIM.

I’ve been using this module at $work for a while now and am very happy with it and have had coworkers tell me, after they gave it a try, how much cleaner their code ended up being because they used this module.

Enjoy!

Upgrading to Catalyst 5.8

Tue, 28 Jul 2009 17:15:00 -0700

Update: Catalyst now comes with an upgrade document: http://search.cpan.org/perldoc?Catalyst::Upgrading

Over the last few days at $work I’ve been upgrading Catalyst from 5.7 to 5.8. This new version of catalyst, released in April, has been completely overhauled to use Moose for it’s OO system, among other enhancements and bug fixes.

I found that the Catalyst::Manual::CatalystAndMoose manual was a great starting point to using Moose with Catalyst. Also, Catalyst::Upgrading has specific points to consider when upgrading to 5.8. During the initial install of Catalyst 5.8 I was told that I had a few related modules installed, that while not Catalyst prerequisites, I should upgrade them as they were known to fail on the new Catalyst. I was lucky that I caught this message, as cpan did not pause to wait for me to read it and went on its marry way building, testing, and installing Catalyst.

Once installed I went ahead and also upgraded some related modules we use such as Catalyst::Plugin::Authentication, DBIx::Class, Catalyst::Plugin::Session, Catalyst::Authentication::Store::DBIx::Class, etc. This way I could test all these upgrades all at once instead of one at a time.

Next I modified all my custom plugins to use MRO::Compat instead of Class::C3 per the documentation in Class::C3::Adopt::NEXT. But, then I realized I might as well just rewrite all my plugins as Moose::Roles as its pretty easy to convert a plugin to a role and you end up with much cleaner code.

I started Apache up and things mostly worked. There were a few backwards incompatibilities that I wasn’t aware of, such as there were a few cases where developers had done this:

sub index : Local { }

Instead of:

sub index : Private { }

In our previous version of catalyst (5.7) using :Local, while not documented, worked just like :Private if the subroutine was named index. In 5.8 only :Private will cause a handler named index to be the default handler if the URL resolves to the controller only. This was an easy fix. There were a couple other small issues, but nothing major. I found and fixed a bug in Catalyst::Model::DBIC::Schema and added the support for the compute() method to Catalyst::Plugin::Cache. Both of these changes reduced the amount of changes I needed to make to my own code.

A couple hours in to it I was upgraded and everything was working. Of course I spent the next few days upgrading/enhancing/rewriting Catalyst bits that could be done much more elegantly, and with less code, using Moose.

On a side note, during the upgrade I found this great quote in Catalyst::Model::Adaptor:

Catalyst is glue, not a way of life!

Amen! Most people, myself included, start out by writing all their business logic in their Controllers because that is what MVC told them to do. Don’t do it! Catalyst is meant to be a GLUE - most of your application should be written in a way that it doesn’t give a flying crap how, or by whom, it is used. Put your business logic in modules that optionally expose themselves as Models (perhaps via Catalyst::Model::Adaptor) or just by adding a use statement in your controller that then uses that module. Your controllers should be little more than code to glue a data source with the view and provide some input validation.

I’ve been waiting a long time for this Moosification and its been a joy working with this new Catalyst. Next up to bat will be the Moosification of DBIx::Class! Think we’ll get it by Christmas? :)

Don’t forget to buy the new Catalyst Book! If purchasing from Amazon make sure you follow this link to ensure that the Enlightened Perl Organisation gets a cut of the sale.

XS Hits Newb; Bystanders Watch in Dismay

Mon, 20 Jul 2009 20:53:00 -0700

Last year I wrote GIS::Distance::Fast to provide some much needed speedups to the pure-perl GIS::Distance. This ::Fast version used Inline::C which isn’t all that optimal and was just a scapegoat for doing the right thing.

So, this evening I rolled up my sleeves and went to work. I first looked at a module I already knew to use XS, Cache::Memcached::Fast. That was overwelming.

Then I went on over and read through the perlxs and perlxstut docs. I was STILL floundering about not sure what to do. I then took a whack at using SWIG (Simplified Wrapper and Interface Generator). OhMyGodz I’m feeling overwhelmed now and still nothing works. I’m not going to even document my attempts up until this point.

I then found this document that goes in to more detail about using SWIG with Perl. The thing about this document that helped me so much is that in section 2, Perl Extension Building, it had the simplest example I had yet run in to, and it made sense! Its kinda funny that a SWIG document was what taught me how to write my own XS without using SWIG. :)

An XS distribution can contain as little as two files (well, beyond the usual Makefile.PL, etc). A single .pm file and a .xs file is enough. You can get more complex, if you want, of course. Once you’ve written your Module.xs file you can run it through xssubpp Module.xs > Module.c to see what the .c file looks like and to verify that your .xs file is correct.

Note that xssubpp may complain about you using types that aren’t in your typemap. This is because xssubpp doesn’t know how to find your system’s typemap file. You can specify a typemap file using the -typemap switch. The file is located somewhere in your perl lib path as ExtUtils/typemap.

So, let’s go for an example. Let’s make an XS module that convert hours to minutes. I structure all my code and files as if they would be distributed as a CPAN module. This has added benefits as you’ll see in a moment.

convert-hoursminutes/lib/Convert/HoursMins.pm:

package Convert::HoursMins;
use strict;
use warnings;

our $VERSION = 0.01;

use XSLoader;

XSLoader::load('Convert::HoursMins', $VERSION);

1;

convert-hoursminutes/HoursMins.xs:

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

double convert_hours_mins( double hours ) {
    return hours * 60;
}

MODULE = Convert::HoursMins  PACKAGE = Convert::HoursMins

PROTOTYPES: DISABLE

double
convert_hours_mins (hours)
    double hours

convert-hoursmins/Makefile.PL

use inc::Module::Install;

name     'Convert-HoursMins';
all_from 'lib/Convert/HoursMins.pm';
requires 'XSLoader';

WriteAll;

convert-hoursmins/t/00_basic.t

use strict;
use warnings;
use Test::More tests => 2;

BEGIN{ use_ok('Convert::HoursMins'); }

is(
    Convert::HoursMins::convert_hours_minutes(1.5),
    90,
    '1.5 hours is 90 minutes',
);

Now lets see if it worked:

perl Makefile.PL
make
make test

Bottom line for me is XS isn’t all that hard when your C code isn’t all that complex. SWIG is overkill for small stuff. But for large swaths of C code I bet SWIG saves lives. Also, XS is a little arcane, but its not too bad.

$(document).ready() Shortcut

Fri, 17 Jul 2009 14:54:00 -0700

When writing jquery you almost always put your code within a ready block:

$(document).ready(function(){
    // Code...
});

And I always forget the exact syntax. I just found that jQuery has a shortcut:

$(function(){
    // Code...
});

Much better!