Where Everybody's Crazy

Last week I wrote:

Next stop is, ideally, to get Skype to automatically update Last Contacted as well, which is perhaps a little bit of a pipe dream.

But then I thought "Skype has an API. I have Mac::Glue. This should be easy!" And it is. Harder than it needs to be, but still easy.

use Mac::Glue qw(:all);
use Time::Piece;
my $s = Mac::Glue->new("Skype");
my $ab = Mac::Glue->new("Address Book");
sub skype { $s->send(command => shift, script_name => "LastContacted") }

my %skypers; # Map of skype user (stored as a "skype:whatever" tag in the
             # contact's "note") to email address
for ($ab->prop("people")->get) {
    next unless $_->prop("note")->get =~ /skype:(\S+)/;
    my $mail = $_->prop("email")->get;
    $mail &&= $mail->prop("value")->get and $skypers{$1} = $mail;
}
my $c = skype("SEARCH RECENTCHATS");
$c =~ s/CHATS //; my @chats = split /, /, $c;
my $today = Time::Piece->new->ymd;
for (@chats) {
    my $ts = skype("GET CHAT $_ TIMESTAMP"); $ts =~ s/.*TIMESTAMP //;
    # We can't set it to a given date, sadly, so just pick out today's chats
    next unless Time::Piece->new($ts)->ymd eq Time::Piece->new->ymd;
    my $members = skype("GET CHAT $_ MEMBERS");
    $members =~ s/.*MEMBERS //;
    for (grep {!/lathosjp/} split / /, $members) { # Not me!
        if (!$skypers{$_}) { warn "Couldn't find email address for $_"; next }
        # Mac::Glue treats values of the contact_info class as
        # read-only, need to shell out to Applescript to get it done...
        system("osascript", "/Users/simon/update-last-sent.osa", $skypers{$_});
    }
}

Run this from cron, and Robert is your father's brother!

Jesse set me a challenge: make Perl 6-style parameter handling work in Perl 5. Without source filters. This is hard. But not, as was earlier claimed, impossible. When people say things are impossible with Perl, it just makes me want to go on and do them.

I've done this proof of concept:

package foo;
use Method;
sub new { bless {} }
sub bar :method { print $self; }
foo->new->bar();

The way it works is: all marked subroutines are scanned, and a pad (my) variable $self is allocated if there isn't one already. Then all references to $self the global - as in the method above - are converted into references to the lexical variable. Then - and this is the horrific bit - a bunch of Perl ops are injected into the code stream at the beginning of the method, like so:

    OP* padop = newOP(OP_PADSV, 0);
    OP* assignop =
        newASSIGNOP(OPf_STACKED,
            padop,
            0,
            newUNOP(OP_SHIFT, 0,
                newAVREF(newGVOP(OP_GV, 0, PL_defgv))
            )
        );
    OP* startop = Perl_linklist(aTHX_ assignop);
    padop->op_targ = offset;
    assignop->op_next = op->op_next;
    op->op_next = startop;

From there to full-blown Perl 6 parameter parsing is a simple matter of programming...

OK, after a hiatus of, oh, about two years, (mainly caused by not having a Windows machine, and sort-of fixed by Boot Camp) I've picked up work on Songbee again.

After updating the Javascript with some of the things I've learnt from YNTRT, a lot of the nasty bugs with that have now gone away.

The next task is to get it working on Windows Perl again. Thankfully, Windows Perl has moved on a lot in the past two years, and this is a lot easier than it used to be - especially with the advent of Vanilla and Strawberry Perl. They allow you to compile CPAN modules, even ones containing XS code, and having it Just Work.

Apart from the two modules I need, XML::LibXML and XML::LibXSLT. They don't just work, and nobody quite knows how to get them to work.

Ah well, challenges are fun, right?

Simon Wistow is right. I want to amplify and expand on some of what he said there.

• All web frameworks do exactly the same thing, in the same way that most programming languages are, as Dan says, just Algol with funny hats. So stress the distinctives: is yours supremely easy to set up? Does it allow you to admin it over the web nicely? (Nice one, Django)

• Pluggability is not necessarily a good distinctive to stress. Actually, the choice of model/view is largely irrelevant to gaining traction, as Rails - and, dare I say it, ASP has shown. I don't hear ASP folks crying out for twenty different ways to access the same data just because they can.

  When I was designing Maypole I tried to make it easy for people to implement other model and view classes. It is a matter of debate as to how well that design panned out, but, after long talks with Tony, I changed the emphasis on why I was doing this. As Simon points out, most people don't want a piece of software that can do a bazillion things; they want one which does do one thing, and one thing well. The Unix philosophy is there for a reason.

  So for me the support of alternate model and view classes was not primarily to allow Maypole to be all-things-to-all-people, (although it is a very nice side-effect) but as a proof of concept to ensure that I've got all the concerns properly separated at the right layers of abstraction. If Maypole is "too" tied to CDBI and TT, that's a feature, not a bug.

• Number and scope of plugins don't matter, for the same reason. Applications (in the sense of "what is applied") matters. I don't care if you have 40 different ways of doing authentication if I'm never going to use 39 of them.

• Develop for the 80 percent solution. I tried to do this with - and now I'm thinking about authentication plugins - the UserSessionCookie authentication module for Maypole. 80% of the time, it's exactly what you want. 10% of the time you have to subclass it. 10% of the time you need to write your own. Don't make people choose between a myriad of options for the most common case.

• I'm going to start working on a way to make setting up Maypole apps much easier; basically one command-line call should write you the code to get CRUD working with factory templates on an existing database and, what the hell, dump a new Apache config file out to /etc/apache/conf.d/ and restart Apache. Because 80% of the time, that's exactly what you want, and its ease of use would be a helpful distinctive for Maypole.

• Yes, those default templates need redoing by someone who has a better sense of design than me.

• I will start thinking about very cool demonstration project ideas.

I think that's all for now.

We haven't had a technical post for a while, so let's have on: today I have been playing a little with porting Maypole to Perl 6. It's very nice, quite a lot cleaner than the Perl 5 implementation, although that may be the refactoring process coming into play - I've split off request and response objects, for instance.

I take back a lot of what I thought about Perl 6; pugs has changed the whole scene. Things which I thought would be very nice Just Work, not only in the language, but they have implementation too:

    method BUILD ($.config, $.frontend) {
        $.config //= Maypole::Config.new();
        $.frontend //= ::Maypole::Frontend::CGI;
    }

    method setup {
        $.config.defaults;

        if (!$.model) {
            require $.config.model_class;
            $.model = $.config.model_class.new();
        }
        $.model.setup($?SELF, @_);
        if ($.model.can("adopt")) {
            $.model.adopt($_) for $.config.classes;
        }
        $:initialized = 1;
    }

The nicest part is the hundreds of auxilliary modules that Maypole currently needs are just part of the language in Perl 6. (And yes, I know they'd be part of the language in Ruby or Smalltalk or whatever, but this is Perl, or at least smells close enough to it to make me happy.)

Notice the "require" line, for instance, which would need UNIVERSAL::require in Perl 5; the instance data and accessors are all done for me.

And it runs. Today. Not next year. Today. I love it.

So the current meme going around the Perl community looks like this:

• How does Perl help you in your daily work?
• How could it help you better?
• If Perl is helping you, are there ways you could help Perl and other users of Perl?

I want to rule a couple of these questions out of court, for two reasons.

First, Perl is a tool and not an end in itself. That's a hard one to remember. And yes, while that's still not an excuse for taking the tool for granted, tools aren't responsible for what you do with them. I don't continually thank my ink pen (or even vi) because it helps me write great essays - I have to write the essay, not the pen. Perl might help me write great programs, but it's still me who writes the program.

Second, what is Perl these days? A twenty year old language? A ten year old interpreter? A useful collection of thousands of modules by a wide range of authors? Documentation and books to help me program better? All of the above? In that case, "supporting Perl" doesn't make sense; it's spread too thin. And if all of these things are what helps me now, why should it be that "supporting Perl" exclusively means paying people to work on a new language? - because that was, after all, the ulterior motive of Allison's questions.

A few people have asked me about my involvement in Beginning Perl 2. Like most stories about publishing, the story is an unfortunate one.

I was asked if I would like to write Beginning Perl 2. I said yes. I was then told that the publishers "would prefer to find an author who can carry revisions of the book from 5.6 to the present and beyond for Perl 6". I said that writing a Perl 6 book at this point was insane, but I took the hint that they were going to be using my first edition but getting another author to update it. I was also told (by Martin Striecher, editorial director of Apress) in a message recieved on the 14th of October last year that:

We use some or all of the material that already exists. You are paid 50% of the royalties of the book after the advance paid to revise the book is recouped.

Excellent. I like getting royalties.

In March 2003, I get asked by Chris Mills:

I just wanted to ask you if you wanted your name associated with the new version.

In April, Chris writes:

I would say that more than 25% of the original text is used.

Well, if you're going to admit that you're heavily using my material, it would be nice to have my name on it, I suppose. But what about those royalties, hey?

hmmmm, did anything formal get agreed, or was this just informally mentioned?

Oh, here we go, I can see the screw going in... Chris promised to see what he could do. That was in July. No word since. Yes, I should have got it in writing, but I thought these were decent folks.

Now I'm not going to pretend that I'm all high and mighty and that it's not about the money, it's about the principle. Anyone who says that sort of thing is almost certainly lying. I have no income, so the odd bit of cash here and there helps boring things like buying food. There is a principle, I guess; Apress have taken material that I own, under a creative commons license that does not give them the right to make modifications and resell them, and made modifications and resold it. But they're a publishing company and I'm a missionary, so there won't be a lawsuit.

But, you know, if you're thinking of buying Beginning Perl, remember that there's a perfectly good first edition freely available online under the Creative Commons agreement, (yes, teachers, this means you can copy it and give it to your classes) that I have a Paypal tipjar here, and that I have faith in you to do the right thing. Unlike my faith in certain publishing companies.

Oh yeah, prayer letter. Since it's been all spiritual and no Perl recently, I should say that that was produced with a modified version of the script I wrote about in The Perl Journal last year, and I used MIME::Lite::HTML to create a mixed HTML and plain-text email from the two Template Toolkit formats. Now since you can't do this directly from MIME::Lite::HTML, here's the trick:

my $x = MIME::Lite::HTML->new(
    From => 'simon@simon-cozens.org',
    To   => 'prayerletter@lists.netthink.co.uk',
    Subject => $vars->{title},
) ;
use File::Slurp;
$x->build_mime_object(scalar read_file($output), scalar read_file("email.txt"), []);
MIME::Lite->send('smtp', "localhost");
print "Sending to list\n";
$x->{_MAIL}->send;