Technical Ramblings

On Thursday night, I attended the first meeting of what looks to become a great group of people, at the first PySig meeting, in Manchester, NH. The meeting release has some more information on it, and the mailing list is a great place for discussion of it for people who may be interested.

It was interesting to speak to a mixture of people ranking from 20 years in the computer industry to people like me with one or two, and note that they were all interested in learning Python – and that I definitely had a thing or two up on most of them in this day and age. For example, in a room of 20 participants, several of whom have been working with Python for years, I was the only person who had actually had work posted to Daily Python URL.

During the meeting, I wrote some code (a clunky registration page) which we then did some initial code review on. I demonstrated a trick I learned from sbp, including a “View Source” part of my application so people could see exactly what it was doing.

I’m falling back in love with Python quite quickly. This is nice for a number of reasons, not the least of which is the start of a bit more free time as of this week. I’ll explain that in a later post.

Mostly, I’d like to put out the word to anyone that attended that I had a great time, and I’d love to see more people in the area attend. So far as I can find, there is no group of people in the Northeast that has as much coverage as the pysig.org website: there’s been a couple postings around Boston, but nothing big enough that they have a website. I’d be glad to find out I’m wrong, however, so feel free to tell me so. 🙂

Matt Croyden mentioned the other day that there is a new Python for Series 60 Alpha release. Reading through Erik Smartt’s post on the topic, I realized that this offers a number of the features that I had wanted built in in the original release: Camera access, Address Book and Contact APIs, and other similar things.

I had put off working on Symbian Python work for a while, but with the new release, I think I’m going to put some more effort into it: use of the new APIs will make things easier (like automatically uploading pictures taken to flickr, one of my original goals) and makes me want to get hacking again.

Congratulations to the Python-on-Symbian team, and I’m looking forward to starting work with the new alpha release.

After some thinking this morning, I converted the current PHP-based crschmidt.net templating system to a Cheetah Python template. This means that some more of my tools can move to being Python powered, rather than PHP powered.

“So what?”

Currently, the interface to Redland that I have available in PHP is significantly less good than Python. It’s coded by yours truly, and it’s basically only designed for my use cases, so every time I want to use something new, I have to go and code it, or use a closer-to-native C-style interface translated into PHP. Neither of those are particularly enjoyable.

Python is a much more comfortable language for me to use. It is more intuitive for me. It feels more natural, not to mention the fact that I keep forgetting semicolons in my PHP code. It has an awesome binding for Redland, which is one of the things that I’ve been working with most over the past while.

In the past, all my scripts had been either 1. PHP or 2. Python with no site theming. Hopefully the new Cheetah template will help make me create some more tools in Python, which is the language I feel most comfortable in.

With that in mind, I’ve created a new crschmidt.net web service: an RDF Validator. A number of times, I have found that the official RDF validator will puke, but won’t give much of a reason why. This tool uses Redland, which has a tendancy to return what I consider better error messages on worse RDF. It’s designed as a one-off example of the new templating system, and should not be considered indicitive of most of the expected output of such scripts. Just a first attempt at getting myself into more code.

Earlier today, on the OpenID mailing list, I was asked to supply Perl code to look for PPDs in FOAF docs and return some basic props on the user who owned the FOAF file. My Perl skills have long since fallen by the wayside, but I was able to put together something in Python which seems to me to work pretty good.

ppd.py is a FOAF parser using xml.dom.minidom to look for a PPD, and parse out a couple basic forms of the Personal Profile Document, for cases in which you can’t bring a full RDF parser to bear on the situation. (I know that the question of when this arises has been argued a million times, but an RDF parser is an extra dependency that some projects simply have no interest in bringing on.)

This parses two basic forms of PPD: one in which the foaf:maker is identified by an rdf:nodeID=”nodename”, or one in which the foaf:maker is identified as an rdf:resource=”#nodename” coupled with a rdf:ID=”nodename”.

This hasn’t been fully tested: it was mostly done as a quick proof of concept that people could expand on. I’ve tested it on the nodeID case, and tested that if it can’t find an appropriate PPD, it falls back (against LiveJournal files). I’m not sure how python-esque my code is, but it does seem to work, which was my primary concern.

As usual, this code is designed to be used at the command line as “python ppd.py http://crschmidt.net/foaf.rdf”, or imported as a module, after which you can run ppd.get_person(“http://crschmidt.net/foaf.rdf”).

Thoughts on the method? Will this work with a sufficiently constrained FOAF doc?

I was just looking around for a tutorial on working with MySQL in Python, and found a great Into to MySQLdb in Python page. Since I know some of you reading this are fans of Python, and may have to work with MySQL at some point, I thought this might be interesting to those of you who have to look for it.

It’s not advanced, just an intro, but quite useful, in my opinion, for what it is.

How to Parse SVG Metadata, the Redland + Python way:

import urllib
import xml.dom.minidom as minidom
import RDF

m = RDF.Model()
p = RDF.Parser()
u=urllib.urlopen(“Location Of SVG File”)
svg = u.read()
doc = minidom.parseString(svg)
p.parse_string_into_model(m, doc.getElementsByTagName(“rdf:RDF”)[0].toxml(), “Location of SVG File”)
print m

In other words: Bring in the RDF and minidom modules, Create an RDF model and parser, download the SVG file to a string, parse the string into a minidom compatible variable, then look for RDF in the SVG file, parsing it into the model, and serializing the model.

Problems: What if someone uses something that’s not rdf: as the prefix?
Solutions: mattmcc offers that minidom supports getElementsByTagNameNS, so the parse line would become:
p.parse_string_into_model(m, doc.getElementsByTagNameNS( “http://www.w3.org/1999/02/22-rdf-syntax-ns#”, “RDF”)[0].toxml(), “Location of SVG File” )
resolving the Namespace issue.

Of course, since this is Redland, this is taken care of for you. Rather than doing it in this way, which is specific to SVG, we can scan for RDF in any XML doc. Simply:

import RDF
m=RDF.Model(); p=RDF.Parser()
p.set_feature(“http://feature.librdf.org/raptor-scanForRDF”, “1”)
p.parse_into_model(m, “URL Of SVG File”)

There are a number of other features you can use with a Parser. They are available via rapper -f help, but here’s a list: assumeIsRDF, allowNonNsAttributes, allowOtherParsetypes, allowBagID, allowRDFtypeRDFlist, normalizeLanguage, nonNFCfatal, warnOtherParseTypes, checkRdfID.

Naturally, Redland already does what I want it to do. Another pat on the back for Dave (and thanks to him for pointing it out).

Apparently, when the TrafficCam flash program was released, Justin was opening a can of worms that was bigger than I could have imagined.

After my example of quick development on the Python app, I got a lot of interest in my own TrafficCam application. Suddenly, there was a London version. And a Dubai version. And every time I mentioned it, someone else wanted to create their own version and load it in so that they could use the same nifty features. If there’s one thing that I do right, it’s listen to what my users are telling me. So, this afternoon, upon the arrival about my new Nokia 6600, I got to work.

First step: Build a file loader. This function should take a file of predefined format and read it in over the web, letting you specify some parameters to the program. This data should then be returned in a way that the application can use. We can’t make the file format too complex: the default Python install comes with no XML support, remember, so we’re using a very basic, tab delimited layout for this. The format is pretty simple: It’s described in the TrafficCam Format Documentation, for those of you who may want to use it.

Step two: Build the app around the data. Given a specific URL, construct the entire application setup, from the tabs to the title to listings, from that returned data. Not too hard: required a little bit of changing how I did things so that it could be reloaded easily, but as always, Python was cooperative.

Step Three: Build a frontend to choosing URLs to load data from. Store a title an a URI, and let people choose which to load. Not too bad: using the popup_menu that symbian provides, can easily associate the resulting choice with your earlier list.

Step Four: Add support for reloading. Once I’m done with one set of cameras, I want to view another without having to exit and restart. This is a bit more complex: it requires me to move some of the logic around so that the application flow stays mostly the same. In the end, I ended up cleaning up some ugly repetition of the code this way, which was useful.

Step Five: Make it more user friendly. Add an “Other” for choosing their own URLs, add progress meters and information boxes, put in exception support for when a URI doesn’t load correctly, and in general, make the app work better.

All in all, I spent six hours yesterday working on the application, and basically rewrote it from top to bottom. It’s now easy to use, and extendable to do whatever people want. I can admit that it’s probably the single most user-friendly application I’ve ever written: almost all my work in the past has been command line based, but this is truly a cool application.

If you have a phone which supports Python, I highly recommend this application. Although I’m sure there are better apps out there, this one is my personal favorite: lets you get a glimpse of the world through your phone. Of course, you should be aware that this is not a low bandwidth application: the camera listings are only about 3-4k apiece, but each camera image can be anywhere from 10-15k, sometimes more depending on the cameras you’re using. Yesterday, while doing development, I used up a megabyte of GPRS bandwidth – luckily, I have unlimited GPRS through my provider.

If you live in an area where there are traffic cameras, and you’d like to see them added, simply construct a file according to the format documentation, and drop me a line.

Have I mentioned lately that I love Python?

Now, to get working on that contact database export I had in mind…

Russ posted about a pretty cool Flash Lite application that was developed: a way to look at the NYC traffic cameras using your phone. It’s an extremely cool app – if I lived in New York, I’d buy Flash Lite just to be able to use that application. One thing that Russ mentioned was the development time for the project: 20 hours of development time, when something in Java would have been way larger.

Well, I’m a Python man, not a Flash man, so I can’t get much out of this yet. However, I do think it’s a cool use case: so I did a little research, found out where the data that the Flash app uses was coming from, and did a little hacking. The result? TrafficCam version 0.1, in Python. This little app took me 45 minutes to develop a fully functional prototype: this included taking the HTML from the NY Transportation site, building it into a Python file, creating a user interface, and downloading and displaying the image in the built in phone image viewer.

Not only did I do all this in 45 minutes, I did it without even having a phone to test with. Passing it off to the owner of a 6600 and a 6630, both say it works just fine, as is.

(Note that I think it probably doesn’t, but in ways that aren’t visible: There has been no testing done yet.)

So, although Flash is great for pretty apps – the Python app is *nothing* like the Flash app, which is a great user interface and something that’s really fun to use, even in a browser – but Python can be really great for *quick* apps, especially on the phone.

Update: With another 35 minutes of work, I now have fully functioning tabbed lists, one for each borough. So, with a total of less than an hour and a half of development, I have an application which allows you to download any of the traffic cam images and view them on your phone. It’s no flash, but I call that pretty damn impressive.

Recently, a number of local Python users have assembled some form of organization, to the point that there is actually now relatively regular meetings of these groups of people (before other Linux Users Group gatherings, thus far). With the recent Nokia Python announcement, there’s been some renewed interest in my mobile python work, so I’m hopefully going to get some of that into shape over the weekend for a demonstration to the group on Monday, assuming I can make the meeting.

For those of you who have an interest in Python: What do you think would be interesting to a bunch of Python coders as a demonstration? Is there something that’s particularly spiffy that I could show off, or convert from being a command line application to being a cell phone application? Note thave I’m thinking relatively simply here: I only have a relatively limited memory space to work in, and I only have a small subset of modules to work with, and I’m in Python 2.2.

So, what do you see as being interesting topics/programs to demonstrate to the world the power of Python on the cell phone?

I’m really looking forward to getting together with a bunch of like-minded hackers, and racking their brains on what I can do better. I’ve never really had a good development process before, but Python developers seem to have one, especially the ones that I’ve seen discussing things on the mailing list. I’m used to LiveJournal’s spaghetti code, or writing in PHP which is typically not so well tested. It’ll be interesting to enter conversations with a group of more “formal” developers than myself.

Just looking for thoughts on what I should be working on.

Although I love being able to develop things quickly and easily on my 3650, there’s a few major sticking points for me that I don’t understand. I know that my phone is considered an “untested” phone for this application: it’s almost the oldest Series 60 around, so I don’t expect everything to work nicely, or even at all. I was totally psyched when I learned that I was on the accepted list. Yet there are some things that bug me.

Lack of Documentation: Nokia has done an admirable job at documenting what their Python does and does not do, and has done pretty awesome, except for a couple things. First of all, there is completely undocumented UI funtionality in the Examples code that they give out. (Specifically, for the pop up choices: appuifw.popup_menu). I don’t know how much it bugs me that I looked through their entire PDF documentation 3-4 times looking for this feature described and found nothing. For a great project otherwise, to skip things like this when you’re releasing a public version is just a bit annoying. Additionally, 3 of the 6 references from the API reference don’t go anywhere: they’re just titles of publications, with no additional information. I believe two of these files are included with the distribution (I can’t check right now: The batteries of the computer I downloaded it to are dead), howeverm, to not even mention that and only list a title is again, quite silly.

Clear Lack of Testing: Again, as I said, the 3650 is not a “well supported” phone in this endeavour. However, there is a relatively major crasher bug in the Python distribution: when running in the Interactive Shell, if you press the “return” key equivilant while still on a word while using predictive text… it crashes.

That’s right, if you’re using a built in feature of the interface, it crashes. For no apparent reason. Doing something that most python programmers will do first, before anything. (The interactive shell in python is impressive, and is a good “sandbox” type environment to test small scripts out.) Granted, on a cell phone, the interactive shell users are going to be relatively slim: who wants to type on a phone when you can just type on a computer and send it over? However, to leave a standard python feature so broken is just silly.

Other than these two minor niggles, I’m very impressed, and hope to see the available UI interfaces grow over time: I’d like to be able to have as much control over user interface tools as Symbian native apps do, and I think Nokia would like to see that as well. I’m especially happy with the “location” module, which allows you to retrieve Network, Area and Cell IDs: I can now write my own tool to do MiniGPS-type cell storage, as well as uploading data to MeNow.

A list of standard modules which are included:
anydbm, atexit, base64, bdb, binascii, cmd, code, codecs, codeop, copy, copy_reg, cStringIO, dis, errno, exceptions, __future__, httplib, imp, keyword, linecache, marshal, math, md5, mimetools, operator, os, pdb, quopri, random, re, repr, rfc822, socket, sre, string, StringIO, struct, sys, thread, threading, time, traceback, types, urllib, urlparse (urlsplit only), uu, warnings, whichdb, xreadlines, as well as a “location” module for determining GSM cell info and “messaging” for sending SMS messages. Additionally, there is a UI Specific module, appuifw, the e32 Module, which offers some Symbian related utilities, e32db, a relational database module, and the e32dbm module, which offers an API to the Symbian RDBMS.

All in all, an impressive an useful subsection of the modules which most people use. The socket library has been extended to include a number of bluetooth functions, which apparently work quite well (I wouldn’t know, haven’t tried them yet.) I’m very pleased. It’s fun. But I think nokia could have waited just a little longer to ship this, to make sure that some things weren’t broken.