Connecting Python People

Grig Gheorghiu thinks it is worth spending time to sign up and connect to people on LinkedIn. I agree! I think the whole circle-of-trust concept, which I first saw on Advogato, is one of most successful methods of recruiting, seeking advice or just meeting smart people.

Since joining LinkedIn last November, I've managed to reconnect with several former colleagues, and meet one new interesting person. If you're looking for work, new clients, or inside-contacts, LinkedIn is definitely worth investigation.

http://www.linkedin.com/in/simonwittber

A Pattern for Building Web Widgets

One of my favorite parts of being a Web Developer is implementing cool dynamic Javascript widgets. I've recently had to build a tab control and an 'accordion menu'. I spent most of today in Pair Programming mode, building a combo box which uses asynchronous calls to the server to fetch its data.

I admit, I was reinventing the wheel, but I really had no choice. I couldn't find any widgets that were readily customizable or worked just the way I liked.

In the end, the html snippet (I'm calling it a template tag) to create my widget looked something like this:

<input class="picker" data_source="/db/collection" fields="field_1" />

MochiKit makes this sort of thing very easy and clean. The code does a search of input tags with a class of 'picker' (getElementsByTagAndClassName), does some DOM creation magic, then finally uses the swapDOM call to drop the completed widget onto the page. I pass arguments into the widget constructor via the custom (non XHTML compliant!) attributes I stick in template tag.

I attach all the attributes and methods I need to the containing DOM element, so that the application code can use the getElement function to reference the widget, and then call its functions, change attributes etc. Basically, I ended up with a DIV element decorated with methods like update_list, get_selected, and a onselect stub method which is designed to be overridden.

In the end, my remoting combo box code was built over 6 hours with 87 lines of javascript and 50 lines of CSS. The backend code which supplied the data in JSON format was written within the TurboGears framework, and took 20 minutes and < 50 lines of code.

This is the basic pattern I now use for dynamically creating widgets using MochiKit.

if(typeof(widget) == 'undefined') {
  widget = {}
  widget.init = function() {
    var setup = function(template) {
        /*
        create the widget, assign methods 
        and attributes to the widget
        */
        swapDOM(template, new_widget)
    } 
    map(setup, getElementsByTagAndClassName('input', 'widget'))
  }
}

addLoadEvent(widget.init)

It gives me neat, easy to understand, self contained .js files for each widget, with MochiKit as the only dependency.

What was I thinking?

Late 2006, I posted a rant on the state of concurrent processing on Python.

Looking back, I don't really think I was thinking very clearly that day. I imagine I was contemplating a multi-threaded raytracer in Python. A fun idea, but kind of pointless really. Stupid even.

Since that post, I've implemented exactly one program where I had to explicitly use threads. Why did I need threads? Simply because I wanted non-blocking IO, and couldn't be bothered using other asynchronous mechanisms.

The lesson? YAGNI.

Unity3D Evaluated. Wow.

Unity3D is a game authoring application for OS X, which can deploy standalone binaries to OS X, Windows, and a Web Player Plugin. No Linux build yet, unfortunately.

I decided to investigate Unity3D because I read that it supports Python for scripting game objects. I've found this to be untrue. It supports Boo, which is not really Python, however it looks a lot like Python in most cases. Unity3D also uses Javascript, which is what I chose to use when running through the tutorials.

I decided to persevere and complete a few tutorials. I'm glad I did, as I am absolutely blown away by the power of Unity. It really is an amazingly productive, and flexible tool. It combines a generic 3D engine (with support for shaders, different lighting models etc) and a generic physics engine with a very intuitive GUI which ties all the game objects together using drag and drop scripting, which can be coded in Javascript, Boo or C#.

If you run OS X, and you want to write games, I recommend trying out the Unity3D demo, and running through a few tutorials. It won't take you long to realize that simplicity and ease-of-use has not been achieved at the expense of flexibility and power. You'll having a working game demo in a few hours, with animated particle effects, colliding objects and whatnot.

If you don't run OS X, and you want to write games... it is worth shelling our for a new machine, just so you can run Unity3D. Yes, it is that good.

Pyglet looks great!

I've just run the Pyglet tests on my new machine.

Wow, Pyglet is looking great! It has a great blur demo... which appears to use OpenGL shaders. Woohoo!

Pyglet even renders XHTML... using CSS for styling. That is _mad_. Alex Holkner and Richard Jones are Python-Coding-Machines!

I'm looking forward to playing with this some more...

Got Mac. Evaluating Unity3D.

The reality of web development, is that one code base must work on several platforms, Mac/Safari being one of them. I picked up an intel iMac last Friday, so that I can test my web code in Safari and Firefox in an OS X environment.

The iMac is a very tidy unit. I'd consider buying one even if I used it to just run Windows or Linux.

Of course, I couldn't wait to get my hands on a trial version of Unity 3D, and see if it's all its cracked up to be. I haven't had much time to play with it yet, though I have run through the first tutorial. It's well laid out, and easy to pick up, and produces good results. That's all I can really say at the moment. Hopefully I can get some more time in before the trial runs out, and post some nice screenshots!