June 22nd, 2006

diesel, learning, evil, sweeti

A splash of hubris and a slight turd polishing

I finally got round to doing something I've been threatening to do for ages - which is automatically generating my CV in multiple formats from one source.

It actually turned out to be quite easy and I wish I'd done it before. Of course it was helped by the awesome and new PDF::API2::Simple which basically did exactly what I was thinking of doing without me having to do it. for t3h w1N!!1111.

Currently it can output Text, HTML, PDF and Doc (technically RTF with a .doc file extension) which should be enough for anyone.

Over the weekend I abstracted out the stuff that controls look and feel (sort of) so that each someone else can make everything look different by writing an .ini style file. There's a default file contained within the CV::Style module which looks something like

    [title]
    font        = Helvetica
    font-size   = 20
    font-colour = #c0c0c0
    font-weight = bold
    font-style  = italic
    align       = left

or something. That's a slightly contrived example but it borrows heavily from CSS.

There's still some hard coding for the order of things, padding in a couple (RTF, PDF) filters and how urls look and titles. Also, most output filters don't understand font-styles other than italic or font-decoration like underline.

I'm pondering allowing each section to have call backs for transforming the object so that instead of the current system wherby the name of the CV is always prefixed with '::' (because I think it look arty like) and titles always look like '[ title ]' and urls look like '< url >' you'll be able to do

    [name]
    callback = sub { my $name = shift; return ":: $name"; }
    [title]
    callback = sub { my $title = shift; return "[ $title ]"; }
    [url]
    callback = sub { my $url = shift; return "< $url >"; }

or something.

diesel, learning, evil, sweeti

Module::Pluggable gutting

I finally got round to completely gutting Module::Pluggable and refactoring it.

The upshot of this is that there's now Module::Pluggable::Object which has object orientated, as the name suggests, which makes it much easier to reafctor out into smaller methods which in turn makes it easier to subclass. The inner package stuff is refactored out into Devel::InnerPackage and then Module::Pluggable itself just has an import {} sub that instantiates a Module::Pluggable::Object and calls it.

This means that instead of shoving new functionality into the main class which was becoming increasingly large and brittle, people can sub class.

Less work for me. Yay!

diesel, learning, evil, sweeti

Desktop Dipsy is alive

For a while, I've been talking about Desktop Dipsy - a sort of natural language parsing shell that's useful for all the little one off things you want to do without dropping into another app. I've had these for a while but I figure I'd mention them now.

Desktop Dipsy

Desktop Dipsy

Of course, ideally it'd index my local data - sort of like a cross between Beagle, Yub Nub and the venerable Infobot but with more smarts and a friendlier interface.

diesel, learning, evil, sweeti

CalDAV and Exchange and GData, oh my!

At some point I want to make a CalDAV module that allows me to accept and present objects as CalDAV type action so that EventQueue can both present and consume CalDAV feeds.

Similarly I've been looking at how Exchange does its thang and I think it might be possible to read from it and update it if not pretend to be an Exchange server.

Finally, I'm pretty sure I can create a fairly good GData look a like so that I can pretend to be Google Calendar as well.

muhahahahahaha.

muhahah hahahah hahahaha.

diesel, learning, evil, sweeti

I want to live with common people^W parts

The one thing about the keywords service from Yahoo! is that it's prone to returning keywords with common stems. For example if I was talking a lot about sheep it might return

    sheep, sheep shearing, sheep dipping, sheep rustling 

when really all I want to do is have it return 'sheep'. Enter Text::CommonParts which will also do the trick of

taking

    sheep shearing, sheep dipping, sheep rustling, sheep shearing shears, sheep shearing shed

and returning

    sheep, sheep shearing

Given a singleton

    thing one, thing two, another thing

it does the right thing and returns

    thing, another thing

It has occurred to me that I may want a more complicated API that returns, instead of a list of common parts, a hash of common parts with the key being the part and the value being a list of the snipped off tails.

diesel, learning, evil, sweeti

/dev/diary to LiveJournal

For various reasons I'm probably going to want to start keeping a technical diary over at Livejournal and since I've already got this content it would seem a shame not to use it.

Currently everything is stored in a Pod file which is converted into the HTML you see around you using baroque processes which I appropriated from Richard Clamp

Some day I ought to get around to rewriting it but the upshot is that, theoretically, everything should be easily extractible and thus prime for sticking into LJ.

And lo! It was.

There were a couple of problems - the current structure is a heading followed by one or more subheadings representing posts. Obviously LJ doesn't have that so they had to go but, sometimes, a subheading refers to a heading like this so at that point it had to DTRT and combine the two. Related to that was the problem that I didn't want to give each post on a given day the same time so it assumes I post one an hour.

Secondly there were a number of internal links, possibly referring to stuff we haven't seen yet (since the latest entry is at the top of the Pod file) which required some finessing.

Thirdly it also had to make special cases for finding links to LJ blogs and making those use the internal linking markup.

Tagging was added by using the Yahoo!'s Term Extraction Service.

Now I just need to start listening to Fields of the Nephilim and whining about how my parents don't understand me.

Current Mood: smug