Hi! Please consider following me on twitter: @hanekomu.

2009年06月11日

Sending DBI trace output to FirePHP with HTTP::Engine

As promised last time, here is a complete example of how to send DBI trace output to FirePHP in an HTTP::Engine demo web application.

First we create a very small example SQLite database. Let's model a company that has two departments with two employees each. Create a file called create.sql and enter the following SQL commands:

CREATE TABLE departments (
    id INTEGER PRIMARY KEY,
    name TEXT
);

CREATE TABLE employees (
    id INTEGER PRIMARY KEY,
    name TEXT,
    department_id INTEGER
);

INSERT INTO departments (id, name) VALUES (1, 'publishing');
INSERT INTO departments (id, name) VALUES (2, 'accounting');

INSERT INTO employees (id, name, department_id)
    VALUES (1, 'Yamamura Masayoshi', 1);

INSERT INTO employees (id, name, department_id)
    VALUES (2, 'Ueda Akira', 1);

INSERT INTO employees (id, name, department_id)
    VALUES (3, 'Matsumoto Daichi', 2);

INSERT INTO employees (id, name, department_id)
    VALUES (4, 'Yasuda Ryota', 2);

Now we create the database itself:

sqlite3 kaisha.db <create.sql

The web application is pretty simple as well. We create an HTTP::Engine object and run it; the handler connects to the database, runs a simple query, creates an HTML table from the results and sends it in a response back to the engine.

#!/usr/bin/env perl

use strict;
use warnings;
use DBI;
use HTTP::Engine;
use HTTP::Engine::FirePHP;

my $engine = HTTP::Engine->new(
    interface => {
        module => 'ServerSimple',
        args   => {
            host => 'localhost',
            port => '1984',
        },
        request_handler => \&handler,
    },
)->run;

sub handler {
    my $req = shift;
    my $dbh = DBI->connect('dbi:SQLite:dbname=kaisha.db', '', '');
    my $res = HTTP::Engine::Response->new;

    $dbh->trace(2, $res->get_fire_php_fh);

    my $r = $dbh->selectall_arrayref('
        SELECT E.name, D.name
        FROM employees E, departments D
        WHERE D.id = E.department_id
    ');

    $dbh->disconnect;

    my $body = "<table>\n" . 
        (join "\n" =>
             map { sprintf "<tr><td>%s</td><td>%s</td></tr>\n", @$_ } @$r
        )
        . "</table>\n";
    $res->status(200);
    $res->body($body);
    $res;
}

The relevant command to send DBI trace output to FirePHP is:

$dbh->trace(2, $res->get_fire_php_fh);

In version 0.02, HTTP::Engine::FirePHP gives HTTP::Engine::Response the method get_fire_php_fh, which will return a filehandle that has been opened to a PerlIO::via::ToFirePHP layer, so you don't even need to do that manually anymore.

With this one line, DBI knows that it should trace all calls and send the trace output to the filehandle. The trace output will automatically be put into the HTTP response headers so FirePHP can display them. Here is what the Firebug console looks like when we make a request to the server:

Sending DBI trace output to FirePHP

Tags: , , , .

Write a comment | Bookmark and Share

posted at: 14:54 | path: /dev | permalink | 0 comments | 0 trackbacks

Log to FirePHP via an PerlIO layer

I have released PerlIO::via::ToFirePHP. This PerlIO layer sends everything it receives to FirePHP. When constructing a filehandle using this layer using open(), you need to pass an object of type FirePHP::Dispatcher that has been initialized with a HTTP::Headers object.

use PerlIO::via::ToFirePHP;
my $fire_php = FirePHP::Dispatcher->new(HTTP::Headers->new);
open my $fh, '>:via(ToFirePHP)', $fire_php;

Everything you print on the filehandle will be sent to FirePHP.

A typical use of this PerlIO layer is to send DBI trace output to FirePHP:

use PerlIO::via::ToFirePHP;

my $dbh = DBI->connect(...);

open my $fh, '>:via(ToFirePHP)',
    FirePHP::Dispatcher->new($http_headers_object);
$dbh->trace(2, $fh);

Now the trace output of all calls to that database handle will be sent to FirePHP.

The PerlIO layer is implemented in PerlIO::via::ToFirePHP instead of just PerlIO::via::FirePHP because of a bug in PerlIO::via in perl 5.10.0 and earlier versions. If we used just PerlIO::via::FirePHP, we would not be able to use the shorthand layer notation of open my $fh, ':>via(FirePHP), $fire_php. PerlIO::via would look for a PUSHED method in package FirePHP. There is no such method, but because FirePHP::Dispatcher has been loaded, the namespace FirePHP has been autovivified. So PerlIO::via would stop looking. This bug seems to be fixed in perl 5.10.1.

In the next article I will show a complete example of how to send DBI trace output to FirePHP in an HTTP::Engine demo web application.

Tags: , .

Write a comment | Bookmark and Share

posted at: 12:05 | path: /dev | permalink | 1 comment | 0 trackbacks

2009年06月10日

Building our own tools

As software engineers, we are in the enviable position to be able to build our own tools. At work one my subprojects involves writing a Web application that using HTTP::Engine and jQuery. This suits me fine because I wanted to learn these technologies anyway. To debug the Web app, I've installed FireBug. To see remote logs in the browser, I've installed the FirePHP plugin, then written a tool to send logs to FirePHP from within HTTP::Engine.

I have written more tools based on this one, and there are also lots of tools to help my workflow — shell and editor configuration files, distribution building tools, and so forth. And because we write software to help us write software, we can make that software available to help others, who also want to write software.

This is a nice way of working, and I think few professions, apart from toolsmiths, are able to make their own tools.

Write a comment | Bookmark and Share

posted at: 20:24 | path: /dev | permalink | 0 comments | 0 trackbacks

PerlIO::via and autovivifying namespaces

PerlIO::via, in perl 5.10.0 at least, has a bug, or let's call it an unintuitive feature. To start, let's look at this excerpt from its manpage to see what it should do.

The PerlIO::via module allows you to develop PerlIO layers in Perl,
without having to go into the nitty gritty of programming C with XS as
the interface to Perl.

One example module, PerlIO::via::QuotedPrint, is included with Perl
5.8.0, and more example modules are available from CPAN, such as
PerlIO::via::StripHTML and PerlIO::via::Base64.  The
PerlIO::via::StripHTML module for instance, allows you to say:

       use PerlIO::via::StripHTML;
       open( my $fh, "<:via(StripHTML)", "index.html" );
       my @line = <$fh>;

to obtain the text of an HTML-file in an array with all the HTML-tags
automagically removed.

Please note that if the layer is created in the PerlIO::via::
namespace, it does not have to be fully qualified.  The PerlIO::via
module will prefix the PerlIO::via:: namespace if the specified
modulename does not exist as a fully qualified module name.

As the manpage later explains, the way to create these I/O layers is to declare certain subroutines like PUSHED(), OPEN(), WRITE() or CLOSE() in the layer package.

So I've written a simple layer that uppercases everything that passes through. Imaginatively, I'm calling this layer Foo, and, for demonstration purposes, I'm only writing the bare minimum to make it work.

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

package PerlIO::via::Foo;

sub PUSHED { bless {}, shift }
sub OPEN   { 1 }
sub WRITE  { print uc $_[1]; length $_[1] }
sub CLOSE  { 0 }

package main;

open my $fh, '>:via(Foo)', 'whatever' or die $!;
print $fh "Hello\n";
close $fh;

This program runs as expected and prints:

HELLO

To demonstrate the bug, let's add a simple package declaration.

package Foo::Bar;

We didn't declare any subroutines or variables in that package, just the package itself. When we run the program now, it prints:

Function not implemented at ./test.pl line 15.

What's going on?

When we declare the Foo::Bar package, the Foo namespace seems be autovivified, that is, it seems to magically spring into existence. PerlIO::via only seems to check whether the unqualified namespace — Foo in this case — exists and if so, whether there is a PUSHED() subroutine in it. If there isn't, it declares ENOSYS, that is, Function not implemented. It does not try to fallback on the fully qualified namespace — PerlIO::via::Foo in this case — like AUTOLOAD would.

I think it should fallback, so I consider it a bug in PerlIO::via, or at least a very unintuitive feature.

Tags: .

Write a comment | Bookmark and Share

posted at: 13:12 | path: /dev | permalink | 0 comments | 0 trackbacks

2009年06月09日

Vote to add Perl support to the Android Scripting Environment!

The O'Reilly Radar reports about the Android Scripting Environment:

Google is bringing scripts to Android. The Android Scripting Environment (ASE) will make development accessible and easy for devs who don't want to build a full-fledge application. [...] Scripts can be run interactively in a terminal, started as a long running service, or started via Locale. Python, Lua and BeanShell are currently supported, and we're planning to add Ruby and JavaScript support, as well.

That's nice, but where's the Perl support?

An issue to add Perl support to ASE has been opened on Google Code. Please add your vote by clicking the star to the left of the issue header.

Vote for Perl support on the Android Scripting Environment!

Update:

18:25 hanekomu has joined (n=hanekomu@chello212186070159.1.14.univie.teleweb.at)
18:25 Topic: YAPC::Asia 2009 - Sometime this fall - http://twitter.com/yapcasia
18:25 lestrrat set the topic at: 2009/06/03 00:38
18:25 Mode: +sn
18:25 Created at: 2006/11/26 07:42
19:12 a3r0: Perl on Android  http://code.google.com/p/android-scripting/issues/detail?id=32 is accepted. :)
19:18 hanekomu: our information-spreading machinery is efficient :)
19:19 hanekomu: a3r0: thanks for spotting the issue
19:19 a3r0: No problem :)
19:26 a3r0 has left IRC ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]")

Write a comment | Bookmark and Share

posted at: 17:14 | path: /misc | permalink | 1 comment | 0 trackbacks

2009年06月07日

Logging to Firefox with HTTP::Engine::FirePHP

I have released HTTP::Engine::FirePHP on CPAN; the development version is on Github.

If you are developing a web application and don't want to or can't check the error log, the traditional way is to include debug messages in the HTML page. However, this messes up the layout and mixes content with logging; the two really need to be separate.

FirePHP is a Firebug plugin which enables you to log to your Firebug Console by sending certain HTTP headers in the HTTP response. FirePHP is not just useful for PHP, though; any server-side application that can manipulate HTTP headers can log to Firebug.

The FirePHP response headers use the Wildfire protocol. The CPAN module FirePHP::Dispatcher can generate these headers.

This module then integrates FirePHP::Dispatcher with HTTP::Engine. By simply using this module, HTTP::Engine::Response gets a fire_php() accessor through which you can log to FirePHP.

Here is an example:

#!/usr/bin/env perl
use strict;
use warnings;
use Data::Dumper;
use HTTP::Engine;
use HTTP::Engine::Response;
use HTTP::Engine::FirePHP;

HTTP::Engine->new(
    interface => {
        module => 'ServerSimple',
        args   => {
            host => 'localhost',
            port => '10012',
        },
        request_handler => sub {
            my $req = shift;
            my $res = HTTP::Engine::Response->new(body => 'Hello');
            $res->fire_php->info('Hello from HTTP::Engine');
            $res->fire_php->warn(sprintf 'path was %s', $req->uri->path);
            $res->fire_php->log(Dumper $req);
            $res;
        },
    },
)->run;

When you load the response into Firefox, open the Firebug Console and you will find the logged messages there.

Logging to Firefox with HTTP::Engine::FirePHP

When you restart the HTTP::Engine-based server, be sure to do a shift-reload of the relevant page in Firefox; this ensures that headers aren't cached. If you don't do this, you might see remnant headers from previous responses.

Tags: , , .

Write a comment | Bookmark and Share

posted at: 14:54 | path: /dev | permalink | 0 comments | 0 trackbacks

2009年06月03日

I'm going to YAPC::Europe 2009 in Lisbon

Last night we had a Vienna.pm meeting. I got enthusiastic about YAPC::Europe 2009 so I booked a flight to and hotel in Lisbon and bought the conference ticket. I'm looking forward to seeing fellow Perl hacker friends again, especially @keiosu, @maokt, and @kawa0117.

Tags: , .

Write a comment | Bookmark and Share

posted at: 13:02 | path: /conferences | permalink | 0 comments | 0 trackbacks