From what I can tell it looks very much like XMPP messaging an added layer of conversation IDs added – i’m wondering if it’s PubSub or MUC based or have they written their own custom component layer. Won’t know until they release more info.

Lots of chatter about it on Twitter, jdev@conferences.jabber.org and other places

import time, pymetar, xmpp

# Philly International KPHL

metarRF     = pymetar.ReportFetcher("KPHL")
metarRP     = pymetar.ReportParser()
metarData   = metarRF.FetchReport()
metarReport = metarRP.ParseReport(metarData)

weather     = "looks out the window: %s, %s F (%s C)" % (metarReport.getWeather(),
                                                         metarReport.getTemperatureFahrenheit(),
                                                         metarReport.getTemperatureCelsius())

print 'weather: %s' % weather

jid = xmpp.protocol.JID('you@jabber.org')

to_list = [xmpp.protocol.JID('twitter@twitter.com'),
          ]

c = xmpp.Client(jid.getDomain(), debug=[])

if c.connect():
    a = c.auth(jid.getNode(), 'password', resource=jid.getResource())

    if a:
        print 'authenticated using', a

        for j in to_list:
            print j, '::', c.send(xmpp.protocol.Message(j, weather, 'chat'))

        time.sleep(1)
    else:
        print 'error authenticating', a

    c.disconnect()
else:
    print 'error connecting'

Instead I’ll echo the sentiment that preed said last week in his blog posting A Builder in a Build Land — it’s hard finding either current or relevant to open source information about build/release methods and/or tools. Like preed, I tend to find either really large cumbersome commercial options or “hey! this is what I did this past weekend” items.

Not that there isn’t any good information out there, there is and I’ve been slowly building up a list of bookmarks that I always scan when I have a problem to solve. But that’s not the current point of my ramblings.

The current point is a question I have to ask myself – do I step up and try to help solve this issue? Now I’m not talking about being the end-all to the world of SCM — heck, there are a lot of commercial vendors in that space. Instead I’m talking about the world of Bonsai, Tinderbox and the like. Those tools that small shops try out because they can’t (or don’t want to) spend half their development budget on SCM.

It’s a tough call, my personal time is already slim as it is (heck, I still have to finish the Bonsai SVN changes) and work is keeping me very busy (thankfully :).

But I think that’s the answer also – work is keeping me busy because of the fact that I’m running around dealing with little changes here and there to support the different environments that are found at OSAF. Maybe if I started to map out some common features, things that cause me to wince and out-right deficiencies I would find out that my list is very similar to preed’s.

If you think about it there are a myriad of little tools (and some big ones) that are good and just need some thought but I have also found that there is a bunch of tools that are being used just because they work just enough so as to be below the damn-this-sucks-I-have-rewrite-it threshold.

One thing I would have to do is put myself even further into the info-stream that has become the google-verse and deal with the issues that brings along, another is that I would have to get my shit together and do more than my job. Posting and trying to change the build landscape is a lot harder than just keeping OSAF’s builds running.

gotta chew on it some

I’ve always had it in my head that this kind of support would be necessary and knew that I would be doing the code sooner or later. Looks like it was sooner ;)

With the changes I recently made to support PyICU and locales in general a lot of the hard work has already been done. What was left was figuring out how to convert Darshana’s parseDate() code (she had extracted some of the code I was using in a couple different spots and made it into a function) into something that could be data-driven.

First I needed to solve the issue of how do you figure out programatically what the order is? Oh sure, for the pdtLocale classes I create manually when PyICU isn’t available I can just specify the order, but I wanted to be able to also figure it out for PyICU and since I had already come up with a way of extracting from the short time format the time separator and optionally the meridian text, I kinda figured I could use the same thing for dates.

Here’s the code that extracts the order from PyICU’s short date format:

      # grab the ICU date format class for 'short'
    o = ptc.icu_df['short']

      # ask ICU to build a date string using the given datetime
    s = o.format(datetime.datetime(2003, 10, 30, 11, 45))

      # because I used unique values, I can replace them with ''
      # which *should* leave only the date separator
    s = s.replace('10', '').replace('30', '')

      # extract the separator, or default if nothing found
    if len(s) > 0:
        ds = s[0]
    else:
        ds = '/'

    ptc.dateSep = [ ds ]

      # now that I have the date separator
      # parse the short date format string
    s        = ptc.dateFormats['short']
    l        = s.lower().split(ds)
    dp_order = []

    for s in l:
        if len(s) > 0:
            dp_order.append(s[:1])

    ptc.dp_order  = dp_order

The above code will return ['m', 'd', 'y'] for en_US and ['d', 'm', 'y'] for en_AU.

With the order determined, the following code takes the values returned from the regex’s and builds the appropriate values

      # v1, v2 and v3 are initialized to -1
      # this lets 0 values in the text pass thru
      # so they are flagged as errors downstream
    v = [ v1, v2, v3 ]
    d = { 'm': mth, 'd': dy, 'y': yr }

      # run thru the dp_order list in sequence
      # and replace the value in d if it's not -1
    for i in range(0, 3):
        n = v[i]
        c = self.ptc.dp_order[i]
        if n >= 0:
            d[c] = n

    mth = d['m']
    dy  = d['d']
    yr  = d['y']

Pretty nifty if I may say so myself :) but I want to run it by people like Phillipe (pje) to *really* find out if it’s a good python algorighm.

Ok, so now that you know I’m a certifiable geek ;) I’ll let you know whey I’m so excited!

DevCo, aka The company that finally escaped the corporate clutches of Inprise, is bringing back the Turbo family of products! http://www.turboexplorer.com/homepage.htm

Sure, it may be the same “explorer” version they offered before, but just the fact that the team is thinking back to their roots and offering free versions again to me is a great sign

I must admit I’ve been having fun doing all the little things that are required to support a library/package. There has already been a couple of questions on the mailing list for parsedatetime and even a feature request! Which I was able to implement and it should be in the next version.

Part of the fun is all the little things that were put into the “I’ll do that when it’s ready to be released” pile that suddenly I realized needed to be done: generated docs, make sure the API is as clean and simple as can be, read the code like your a user, etc.

All basic stuff but it needed doing and with even more unit tests I can make sure that each round of cleanup doesn’t introduce subtle bugs – good stuff.

WWDC 2006

It was fun watching the WWDC Keynote speech tonight — a lot of little bits of code-candy to look at now, but I think the really fun stuff is happening tomorrow when some of the OSAF crew are helping to demo the CALDAV connectivity that sounds like will be a part of the new OS X version.

Most of what they were showing were “meh” items to be honest. Sure they really looked good and you know that the feature sets will be pushing the right buttons, but really – did we really need HTML templates for mail? But for sure the demo of TimeTravel and also of the new ToDo and Notes features was *very* cool. I couldn’t help but notice how the ToDo and Notes toolbar icons looked a lot like, and behaved like, the stamping items Chandler does :)

So with the latest version installed, a step made painless and very simply by running easy_install epydoc, I set about adding the various epydoc related items t the docstrings, cleaning up the code some more and then generating the docs.

Total time from install to generate about an hour, then it was time to upload them to the web server and create some links.

So now the parsedatetime project page has a nice shiny new API Docs link.

Now sure, it’s only 7 right now, but for my first public python module ever I am delighted ;)

Of course this means that the todo list for documentation just got bumped up on the list as currently the only thing that shows how to use it is a single line in the README :(

For the past couple of weeks Darshana has been using, breaking and refactoring parsedatetime. Her changes have really shaken out the weak points and helped expand what the code does. Some of the changes are very Chandler specific but I’ve been trying to merge them into my code-base in as generic a manner as possible. It helps that no one uses this code yet because we have broken the API a number of times :)

Also because of this use I’ve had to get serious about packaging as the code is now listed as a dependency for Chandler and since I’m the build person I have no one to blame but myself for any build/integration issues!

Now that I’ve done some of the dirty work you can get parsedatetime as either a source tarball or a
Python egg and the source is available via SVN from
code.google.com. I’m not quite ready yet to put it up on
Python’s Package Index as that gets a little too much visibility right now and I don’t think I’m ready for a public peer review.

Some of the changes Darshana has made has moved more constant text back into the main code so I know I have to make a round of refactoring to move it back to the consts module – otherwise localization will be impossible. Also in the i18n context I really want to look into having the consts module sense if
PyICU is available and use if if so – this will make it more robust (I hope.)

To check it out I went ahead and added my parsedatetime (yes, I renamed it) to the service and it was fairly painless. Not a lot of metadata available but the basics seem to be covered. You can add owners or members to your project and it also has an issue tracker – I’ll have to try that out later.

Once I added the project I then did an initial checkout of my new project but it seems the example URL they give you for the checkout pulls the trunk directory – probably a good default but I was wondering if they were going to allow branches/tags – all your normal SVN stuff. I clicked on the “Subversion Repository” link and did see that they are available so I took another look at the URL and noticed that they specified “trunk/” so after removing that I was able to get my project directory with branches/ tags/ trunk/ just as I like it.

Now that I saw a sane directory structure I copied over the current (0.6) version of parsedatetime and added it and did the initial commit. Everything worked and while it was a tad slow, it was no where near as slow as SourceForge’s and on-par with others like Berlios, etc.

It will be interesting to see how it holds up after it is slashdot’d and digg’d — but I’m also wondering how many people move from SourceForge to Google. I’m not expecting a lot as Google doesn’t have many of the features that SourceForge has (home page customization, filespace) but I’m sure there will be a minor stampede :)