I don’t actually expect you to be excited, but I am at least. I’m writing the new backend for this site in Python, using CherryPy as a FastCGI wrapper and request handler, and Cheetah as a template engine. Python is awesome. As you can see from the screenshot, I will be aggregating my various “net presences” into the one site, and providing a single RSS feed for everything “me”.
I’m getting really sick of Wordpress being so crap. I am in the process of returning to my roots, and building my own web site from scratch. This will hopefully include my entire Flickr back archive (as I am tired of Flickr also), and essentially consolidate my online presence into the one site.
With luck this will also make it easier to just post one-liners or put up stuff I’ve been working on, so expect more content.
All the best.
And now, for my biannual end-of-semester summary. I have finished everything now, except I have an exam for my Compilers subject at the end of the month, and I am presenting my Photography work on Wednesday next week.
For my major work I have been taking photographs of industrial areas, particularly those related to supply of resources. I spent a lot of time trudging around in the bushes that surround the fences that keep people like me out of those sort of places, so I ended up taking a lot of photos of them, too. Below are the four that I’ve had lambda-printed to 70 x 70cm, and will present next week.
In unrelated news, I have installed OS X on my Core 2 Duo-based PC and it all seems to be running quite well. (It is much faster in Photoshop when using large files - it must be better at managing memory.) If it continues to perform well, I’ll nuke my Windows XP partition and pick up a couple more 500gb drives and set up an ZFS-based file store on this machine.
The only downside so far is that my external audio interface (ESI QuataFire 610) is unsupported. I think I’d rather get a new interface than keep running XP, though. Anyone have any suggestions?
This photograph, taken by the Mars Exploration Rover a couple of years ago, just came to my attention. I find it absolutely amazing on so many levels. That we have been able to send a remote-controllable robot to another world is incredible. That it should send back such beautifully composed images is unexpected to say the least.
I’ve been working on a tune on and off for a few months. It’s a remix/remake of ‘Cheetah Style’ by the inimitable Keith! Party. I used Reason 4, and particularly the new Thor synthesiser (in fact I think all the synths use the Thor). Since it’s about as finished as it’s going to get, I’ve decided to release it. Download the tune here (4mb), and please, let me know what you think.
I’ve been too busy to work on much music recently, apart from practising the guitar whenever I can. However, Meyrick and I have just started sending Reason files back and forth with the hopes of creating something amusing, if not worth listening to. I’ll keep you posted.
Here are a couple of JavaScript things I’ve done, one of them about a year ago, another last week. I thought I’d better just write these up while I think of them, lest they disappear forever.
The first (and oldest) is the basis for a browser-based Raiden-esque game that I put together using Prototype. At the time I called it Journey to the Stars, and I’d intended to make it lightweight enough to be used as a loading screen for my (as yet unfinished, or really “unstarted”) web site. The game was never completed, and the engine notably lacks collision detection among other things. What I like most about the game is its CSS-based sprite engine, which seems to work pretty effectively. (It even supports animated sprites, although I never got around to animating anything.) If I were to do it again, I’d use a more lightweight framework like jQuery. That Prototype ‘extends’ (ie adds a bunch of helper functions to the prototype) of every object you call with its $() function creates a lot of unnecessary memory overheads that must certainly compromise speed.
The second more recent thing is this simple JavasScript implementation of cellular automata. I was prompted to write it after I’d read th wikipedia aricle on Rule 110, and thought “hey, why not?” It would definitely benefit from being rewritten to use the new <canvas /> element, as its current method of flippng the background colours of hundreds of DIV elements is dog slow (and very “old world” in its approach, I think).
I’m highly sceptical that either of these will work in Internet Explorer. I doubt anyone reading this site is running it, anyway.
As if the guy hasn’t done enough impressive things lately, he’s now gone and implemented Processing in Javascript. This required him to write a parser for the Java-like Processing language and convert it into JavaScript, and re-implementing the Processing graphics API for the new “canvas” element.
Now I must resist the temptation to port processing.js to Rhino using native Java graphics widgets, thus bringing the whole exercise full circle.
Emil beat me to it, but this ASCII Art Fart couldn’t be closer to the truth. (although they’re rarely off the mark, in any case) Having just bought a new MacBook (and a very slick Airport Extreme base station to go with it), the one thing that pains me is the poor virtual desktop and focus model. God damn it, Apple! Get it right!
I was completing a Parser for my Compilers subject at uni a couple of days ago, and I ran into an issue where my program (which is written in Java) was ending prematurely without producing any error messages. As I’m not very experienced with Java, I emailed my lecturer asking if he knew what was up. Kindly, he offered to take a look at my source file and tracked down the offending code (that was throwing an exception caught silently by the test framework (that I didn’t write)):
The error is that new_tAST = null before that constructor is called.
If you look back in your code to see what had gone wrong earlier:// this shouldn’t happen
in parseType() had actually happened:-)
Moral of the story: if it shouldn’t happen, it most certainly will.
Facebook’s new Chat feature certainly took me by surprise, but after a few minutes of using it I realised this was the smartest thing they could have done. It gives the whole “Facebook Platform” a new sense of immediacy, thus enhancing more or less every aspect of the site by adding the element of interactivity. (Eg, you can make a “witty” comment on a friend’s photo and immediately get an irate response from them.) At the very least, it’s caused me to spend more time looking at Facebook pages in the last couple of days than I had in the last month combined. I’m interested to see where this takes them, and if it can rejuvenate the platform whose user-base seemed to be suffering Facebook-burnout.
Social aspects aside, the technical implementation is rather clever. The one thing that made me go “buh?!” was the apparent persistency of chats across multiple windows. They make it seem like they are somehow able to preserve state between pages, but after some delving I found that they achieve the effect through some neat tricks.
When you open a Facebook page, your chat’s “state” is sent along with the main page data. They then make an GET XMLHTTPRequest to a specially-configured HTTP server. This is accepted, but the server delays its response until it has something to send (ie if there’s some change in state, like a message, or a user going on/offline). If nothing happens before the request times out, then another request is made. This effectively establishes a channel through with the server can “push” content at the user. I presume this is the same way that GTalk, MSN Web Messenger, and other similar web apps do this - although I’ve not personally investigated them.
As to persistence: If multiple browser windows are making GET requests to the same URLs, the browser’s internals will only make a single connection and serve the resultant content to all of the requesting windows. (the same way it would only download an image once that appears on several pages) When you send a message from one of your open windows, any others are then notified via the established “push channel” (not sure what the correct name for this is), keeping them in sync. If things go awry (connection issues, etc) an instance can POST to ‘history.php’ to refresh its state. This cleanly avoids out-of-sync issues that could conceivably plague such a system.
This all gives the illusion of a persistent chat application that spans multiple windows, and so far it seems to be pretty fault tolerant. Colour me impressed. It will be interesting to see if and how they decide to open this new feature up to developers via their API, although I’m fairly certain it won’t compel me to install any new Facebook apps in the near future.
Update: It happens that this technique has a name: see “Comet” at Ajaxian.