Margaret Thatcher would be spinning in her grave, if only the old bitch would actually die, at the...

posted 23 February 2003
Margaret Thatcher would be spinning in her grave, if only the old bitch would actually die, at the increasingly farcical sight of the ongoing collapse of the Conservative party. Good ol' IDS (never elect a leader whose name is reminiscent of a deadly disease) told the party to "unite or die", and it seems pretty clear that they've gone for option B. At this rate of defection, it looks like the lib dems are headed to be the opposition party next election, which would be cool.

Incidentally, that biography I linked to at the beginning mentions another time when the US and the UK were as united on foreign policy as they are now: during the Reagan administration. Dubya looks more and more like Reagan every day, and it's already been repeatedly pointed out that Blair is more thatcherite than Thatcher ever was.

0 comment

The BBC has an article up about blogging from your mobile phone. The idea is not really news, but...

posted 23 February 2003
The BBC has an article up about blogging from your mobile phone. The idea is not really news, but the interesting part is the host of links to interesting new (free) software that lets you do it, including:
  • Manywhere Moblogger (Java)
  • WAPBlog (Perl)
  • KABLOG (J2ME mobile Java, runs on devices like Palms, the Treo and Blackberries)
    All three of these interface to also-free server side tech which you need to set up yourself (KABLOG interfaces to the popular MovableType server and compatibles). The article also mentions the proprietary foneblog service which seems very easy to use, but it is software intended to be run by cellphone companies for their users.
  • 0 comment

    A look into my twisted mind, and my bizarre design method. To make up for lack of short-term...

    posted 23 February 2003
    A look into my twisted mind, and my bizarre design method. To make up for lack of short-term memory, I make design decisions by writing down my train of thought -- otherwise I just go in little circles, constantly coming up with the same problems and solutions. The effect is that of a schizophrenic having an argument with himself, which is probably not too far from the truth. An innovation I used in this one was to use indentation to signify a tangent from the main decision-making process; it turned out to be very useful.
    - two types of specificity!
    in the filesystem: this rule applies to all files underneath here, they are all in X
        = 1 rule: filesystem claims /x, OR
        = many rulesl: filesystem claims /x/y/z1, /x/y/z2
        (silly! converting rules into lots is dumb)
    BUT then you have the possibility of file-not-founds on a valid claim
        ( assuming you just convert the claim and then add the path )
        - sometimes the file isn't there
        BUT then you want to give an earlier doc, not root (right???)
        - yes, you just recurse up the tree
            BUT how does that work for multiple parents?
            - doesn't matter: you're given one path, not many
    AND you might have had a valid response from a less-specific DB claimant
        e.g. DB takes /bob/
             filesystem takes some exceptions in /bob/mary/ (jane and jack)
        filesystem would always win for bob/mary/* even though DB has them
            BUT how likely is that scenario?
            - not very... if it's a few exceptions it would be per file
            - if it's lots of info, then DB is unlikely to have it anyway
    SO the filesystem doesn't need to make per-file claims
    SO how would it resolve two claims for /bob/* from separate locations?
        - using the ordinary rules of precedence over the two
        BUT what the /bob/ versus /bob/mary/* situation with files?
            - well, yeah, you'd end up with a 404
            BUT that's not supposed to happen!
            - true
                SO some kind of feedback is needed when a claim fails
                - that would allow lower-scored claims a shot
                BUT that means our single-winner algorithm is buggered!
                - yep
                    SO we need to return a scored array of winners
                    SO should this include specificity score?
                        -yes, probably
                AND what about our search algorithm?
                - That was based on specificity winning absolutely
                - Which is no longer the case, so it's buggered.
            SO the search algorithm should return an array of scored matches!
                - how do we score specificity over priority?
    
    RESULT
        New algorithm that attempts all valid claims before failing, in order
        Tweak to make sure results are neither too small nor too large...
        (and perhaps make these configurable)
    
    tagged with
    0 comment