peter.makholm.net

På vores nytårstur fandt vi en mus der var frosset inde i en isblok:

Først opfattede jeg det bare som en kuriositet at Dansk Erhvervsbeklædning sender en faktura til en email-adresse de har fundet på nettet. Men når jeg nu også har fået en rykker, så bliver jeg lidt småsur.

Nu har jeg i mere utvetydige vendinger meddelt Dansk Erhvervsbeklædning at de øjeblikket skal ophøre med at sende mig uretsmæssige opkrævninger.

Dette blogindlæg er en genudsendelse:

Vi har alle vore egne små mærkesager. En af mine mærkesager at at jeg gerne vil være fri for reklameri min mail og i min papirspost. Desvære er holdninger ikke underlagt markedsføringslovens bestemmelser, så religiøst og politisk spam er slet ikke forbudt.

Men de politiske parier burde alligevel respektere at jeg på min dør har taget en klar tilkendegivelse af at jeg ikke ønsker reklamer. Men det kan i hvert fald Socialdemokraterne ikke finde ud af.

Denne gang lyder opfordringen: Stem nej til politisk spam, stem nej til Socialdemokraternes Asger Løvskjold til Region Hovedstaden.

(Nej, Socialdemokraterne ville nok alligevel ikke have fået min stemme)

I dag har DIFO afholdt informationsmøde om deres planer for
implementeringen af DNSSEC for det danske toplevel domæne (.dk). Af personlig nysgerighed deltog jeg. I mit professionelle arbejde har jeg intet at gøre med domæneregistrering eller DNS-drift. I DIFO-sammenhæng er jeg newbie, privat, men absolut ikke upartisk.

Efter tidsplanen bliver .dk signeret 1. juli 2010. Herinden skal der i første kvartal af 2010 gennemføres en semioffentlig test med udvalgte testere (registratore, ISP’er og myndigheder) og i andet kvartal en fuldt offentlig test. Men den endelige afgørelse af hvilket produkt og hvilken service DIFO vil tilbyde, tages først af bestyrelsen i løbet af maj måned.

- Der bliv stillet en række spørgsmål til hvordan DNSSEC vil påvirke allerede kendte problemer og risici ved den nuværende administration af .dk. Svaret var en længere tirade om at der er risici ved alt og at det er farligt at bevæge sig ud i trafikken.

- EPP ville blive (nok) klar inden DNSSEC blev sat i drift 1.juli. (punktum). Men ellers ville man sætte DNSSEC i drift alligevel (med et webinterface til nøglehåndtering???). Men ellers er EPP iøvrigt et helt andet udviklingsprojekt der kørte helt uafhængigt af DNSSEC-projektet.

- Der blev stillet nogle spørgsmål til økonomien i DNSSEC og om det vil være gratis at bruge DNSSEC. Det vil være gratis! Måske, med mindre bestyrelsen beslutter noget andet. Der var i hvert fald ikke planer om at det ikke skulle være gratis, omend man kunne forestille sig at det blev bundled med VID-servicen.

- Det blev flere gange udtrykkeligt gjort klart at DNSSEC var et ønske fra brugerne. Personligt underforstod jeg at det i hvert fald ikke var Per Kølles kop te at skulle beskæftige sig med DNSSEC.

Den information jeg sidder og savner, det er hvad DIFO ønsker at opnå med den semioffentlige test. Vi har ikke en ide om hvordan produktet politisk bliver udformet. Hvilke interfaces DNSSEC skal administres igennem var muligvis først planlagt til at blive afgjort i andet kvartal og EPP var et helt selvstændigt projekt.

Hvis min chef i morgen derfor spørger om vi bør bruge resurser på at deltage i den semioffentlige test kan min svar derfor kun blive et rungende ‘Måske, men lad os invitere Robert til et møde’.

Tim Bunce mentioned my blogpost about Benchmarking serialization modules in a post on the perl5-porters mailing list. He wished that someone would make that benchmark into a distribution on CPAN.

How can I refuse. So here it is, Benchmark::Serialize is just uploaded to CPAN. (Might be some time before it appears).

Besides making the script into a module I also added a list of the size of the serialized data to the output. A replacement of the original script is available in the examples directory.

(I planned on naming the module Benchmark::Serialization, but my fingers slipped. Should I rename it?)

It would be nice if I could get my ORLite performance boost without really changing the (undocumented) API. So I got one more idea: Do the slicing in the ORLite generated code. It’s available in a new branch on GitHub.

To benchmark all three solutions I used a variant of CPANDB::Dependecy::csv():

sub csv {
    my $class = shift;
    for my $edge ( $class->select ) {
        my $foo = $edge->distribution . "\t" . $edge->dependency . "\n";
    }
}

My::Plain->begin;
My::Unsliced->begin;
My::SelfSlice->begin;

cmpthese( -30, {
    plain => sub { csv("My::Plain::Dependency") },
    unsliced => sub { csv("My::Unsliced::Dependency") },
    selfslice => sub { csv("My::SelfSlice::Dependency") },
});

Unfortunately it seems like both having DBI doing the slicing and doing it myself costs roughly the same:

            Rate selfslice     plain  unsliced
selfslice 1.61/s        --       -1%      -41%
plain     1.64/s        2%        --      -40%
unsliced  2.71/s       68%       66%        --

So I probably end up making some sort of ORLite subclass as Adam Kennedy suggested in a comment.

While profiling some code making heavy use of Adam Kennedy’s ORLite module for accessing a SQLite database I found that most of my time was spend in DBI.pm.

Sorted by inclusive time (ie. including time spent in subroutines) two non-XS functions stood out: selectall_arrayref and fetchall_arrayref. Looking a the code both of these functions had a comment stating that a C implementation existed in Drivers.xst and the comment at selectall_arrayref further said that the Perl version is used as a fallback if a slice is given

So could I get away with the slicing?

Turned out to quite easy. Just use array refs as objects instead of the usual hash refs.

The run time of the select() method provided by ORLite went from 344µs/call to 162µs/call on average. And as my test data makes at roughly 100000 select() calls this is a quite noticeable speedup. All included my running time (under Devel::NYTProf) improved from 400 seconds to 340 seconds.

Unfortunately I have to be able to update the state of my ORLite generated objects. This was easy while the objects was blessed has refs. Array refs are not as easy to update. The easy solution was to make the simple non-fk accessors to be lvalue subroutines.

For simple web-based services I usually just use Perl and CGI.pm. After having read a bit about HTTP::Engine I tried it for a simple project yesterday. Beside my own logic it only took a few line of code to have a stand alone HTTP server for my service.

My colleague needed it to be served from the same Apache server as the rest of his webapplication. Some tiny changes and my stand alone server was transformed into a plain CGI script. When we going to deploy the script I’m guessing we make some tiny changes and have it running as a mod_perl module.

Try it for you next project! Even if you usually just use CGI.pm.

I deres nyeste rekvalmefremstød illustrerer Dansk Folkeparti forskellem mellem demokrati og massediktatur.

Dansk Folkeparti taler ikke for demokrati. Demokrati baserer sig på frihed og lighed. De stiller sig som fortalere for den mest xenofobiske form for massediktatur.

Sig fra over for Dansk Folkepartis drømme om massediktaturets tyrani!

It is common knowledge that you can’t have private functions and methods in Perl5. But it turns out that you can do it, one way is to use namespace::clean. Using this module you can either declare all the names of private functions at the top or use a serie of non-obvious “use namespace::clean“, “no namespace::clean” calls.

Wouldn’t it be much nicer just to be able to write:

sub foo :Private {
    ...
}

You can, with my brand new Sub::Private module. It is actually quite simple:

use Attribute::Handlers;

use namespace::clean     qw();
use B::Hooks::EndOfScope qw(on_scope_end);
use Sub::Identify        qw(get_code_info);

sub UNIVERSAL::Private :ATTR(CODE,BEGIN) {
    my ($package, $symbol, $referent, $attr, $data) = @_;

    on_scope_end {
        namespace::clean->clean_subroutines( get_code_info( $referent ) );
    }
}

Putting the attribute handler in the UNIVERSAL namespace isn’t nice. I have to find a solution for that for the next version.