This is the inaugural post to Code Shorts. It is a weekend project gone a bit out of control. I could say that I wrote Code Shorts in Python using Django, but that is like saying that I built a table when I really just assembled one that I bought at Ikea.

I treated Code Shorts as a pedagogical exercise. My goal was to learn a bit about Django and bone-up on database-backed web development. I was pretty up on CGI scripting in the day, but the generation following it (to which J2EE belonged) was not really for the weekend warrior. Django and others like Ruby on Rails and Turbo Gears have really put the fun back in web app development.

In the end, I got a bit carried away. I did all of the blog HTML and CSS by hand. I had been meaning to get a better grip on CSS. Whether, I achieved that is debatable, but the results are better than anything I've done before. The logo was done in Maya of course (see the about page to understand why I say "of course").

Other nice fiddly bits include hooking up tags, comments, and RSS feeds. And I even added on an XMLRPC interface so that I could blog from TextMate, the best editor I have run across to date.

This is the story of how I learned that it is a good idea to plan the deployment of your web projects ahead of time, and then match up your development environment with your chosen deployment environment as much as possible.

When developing this blog, I decided to use Python 2.5 for development because I wanted to use Sqlite which comes with Python 2.5. I liked the idea of being able to nuke the database by deleting a file.

When I went to deploy, I did so on a Linux box that was running mod_python hooked up to version 2.4 of Python. Rather than trying to rebuilt mod_python and whatnot, I decided to just back port my code.

It turned out to be non-trivial. And, problems are a lot harder to diagnose on a remote server.

The main problem turned out to be my XMLRPC code. It would appear that xmlrpclib got a big upgrade in Python 2.5. Which is good, unless you are back porting...

The first problem is that they changed SimpleXMLRPCDispatcher to take constructor arguments in 2.5 to deal with string encoding issues. That was pretty easy to find and fix.

# In Python 2.4 
dispatcher = SimpleXMLRPCDispatcher()

# In Python 2.5 
dispatcher = SimpleXMLRPCDispatcher(False,'UTF-8')

Next, came the hard part. I was getting an obscure error about an argument requiring a float. Over XMLRPC you only get the final error message and not a complete stack trace. I eventually tracked this down to xmlrpclib.DataTime. After digging through the Python source I figured out that the constructor for xmlrpclib.DataTime was extended in Python 2.5 to allow initializing with a Python datetime.datetime object, such as the ones Django returns. It seemed pretty logical that xmlrpclib.DataTime would support that, so it took me a while to figure out that it didn't support it in Python 2.4.

Anyway, for anyone still interested, here's the fix:

# In Python 2.4 (Note that I stole the strftime format string right from 
# Python 2.5's xmlrpclib source)
datetime = xmlrpclib.DateTime( post.date.strftime("%Y%m%dT%H:%M:%S") )

# In Python 2.5 
datetime = xmlrpclib.DateTime( post.date )

About three months ago I made a hard decision and left the Maya development team at Autodesk. It was a hard decision because I'd been part of the Maya team since January 1994, when I started as a student intern. The main reason I left is that I had been working on the same piece of software for thirteen years, which is an eternity in the software industry. The Maya team is a great group of people and they've got lots of big plans for Maya stretching off for years into the future. But for me, its time for a change.

My new gig is Side Effects Software, makers of the Houdini 3D animation software. While Autodesk is the fifth largest software company in the world, Side Effects is at least in the top five makers of software named after famous escape artists. That is too say, they are a much smaller shop. For a developer, that means a less overhead and more connection to the customers.

For anyone who's written Houdini off as a niche product should have a look at the Houdini 9 Public Beta. There are some great things happening in Houdini.

Now that I've gotten this post out of the way, I hope to get back to writing up bits and bobs that I come across, probably unrelated to my daily work for the most part.

One of the things I've done for the upcoming version of Houdini for OS X is to fancy up some of the icons a bit. Our build system is still based on Makefiles. That means I've got to have some way to set a file's icon from the shell.

There are a number of solutions out there using AppleScript. However, Leopard's now standard inclusion of PyObjC makes things even more simple. Here's the Python code you need to set a files icon, given any image.

from AppKit import *

def set_icon(icon_path, file_path):
    image = NSImage.alloc().initWithContentsOfFile_(icon_path)

    workspace = NSWorkspace.sharedWorkspace()
    workspace.setIcon_forFile_options_(image, file_path, 
        NSExcludeQuickDrawElementsIconCreationOption)

Pretty simple. There is one thing to watch out for though. Since this is a Cocoa routine, it needs to access the window server. And therefore will not work unless the user running the script is logged into the console. That's a bit of a pain for automated builds, but not a big deal for most people.

Nokia has just announced that Qt v4.5 is going to be available in LGPL form. This is a huge announcement, and is interesting from a number of perspectives, many of which aren't necessarily obvious at first glance.

I was a recent guest on Late Night Cocoa where I extolled the virtues of developing applications in high level languages like Python, especially if you wish to do cross-platform development. Nokia's announcement could be a game changer.

I love Cocoa and the new Python bindings that Apple has supplied. However, if you need to do things cross-platform, Qt is the best alternative. I have concluded, from my many experiments, that Qt is the only cross-platform toolkit that approaches the polish of Cocoa. And, RiverBank's excellent PyQt is a very natural binding for Python. And, best of all, Qt 4.5 on the Mac is built on Cocoa.

However, up until now there has been a problem. If you licensed Qt for use in a commercial app, you would be forbidden to directly expose Qt via a scripting language to your customers. This makes sense from a certain perspective because a development license for Qt can run up to $3k. If you offer scripting in your app, and your app costs less than a $3k, then you would be undercutting Nokia. And, you would be keeping all the money.

In other words, until now you would have been prohibited from using PyQt in your commercial application if you exposed a scripting API, even if you were willing to pay the licensing fees for Qt and PyQt. However, with the LGPL, you'll be able to link to the Qt libraries from a commercial app without a commercial license from Nokia.

If people realize the inherent value in using Qt with a scripting language like Python, this could open up a whole new avenue for low-cost, high-quality, cross platform development.