Slide Show of Photos from Paradise

I have been working at Slide for a few months now. We are working on making photo sharing and real-time media communication easy to use. We've made a lot of progress on the web site recently, and one of the things we are working on is making embedding a Slide Show in an external web page easier. Here is one of my Slide Shows, pictures of my trip to Michigan this summer immediately before I began working at Slide.

Get the latest version of Flash to view Slide Show, above. Visit Slide.com to create your own Slide Show



Something weird happened to me recently. I had my first screaming-crying-girl-throwing-her-panties fanboy moment for some guy I discovered on teh intarnets. He's virt (http://virt.vgmix.com) and I felt so ecstatic from sleep depravation and listening to his music that I wrote him the following email:

I have no idea how I came across your site. Probably after reading the wikipedia Chiptunes page and searching around a bit (since you don't seem to be linked on there... go add yourself!). I had the contents of your Chiptunes page on my ipod for a while before I really listened to it a lot. The first song I downloaded and listened to a lot was the thriller cover, which I thought was just so cheesy to be brilliant. I used it to test a Mac audio editing application I was working on this summer, SoundFarmer. Check it out:




I didn't really listen to much of the other stuff from the chiptunes page or thriller for a while. Then, I was at the gym yesterday on the treadmill, sorta in the zone, just closing my eyes and concentrating fully on what I was hearing. I think it was in the middle of "blastoff", right about 1:08, where the progression slams right through the fucking roof and the chorus kicks in and breaks it down and then the next section starts slicing microthin shavings through your brain with the distorted guitar and then here we go up and up and up and arpeggio and staccato and tension hold and release and OH FUCK YEAH bring it back around to the chorus again!!! I was almost in tears. I actually had chills. Goosebumps. (All while sweating my ass off at the gym!) I am not shitting you.

Anyway, I went and downloaded every other single mp3 I could find on your site earlier this morning (say hi to your server logs for me ;-) and was digging the gameboy choons but it wasn't until I got to MC Nachbar that I realized that you are a fucking GENIUS. GEE-NEE-USSSSSS. A fucking polymath. So I wanted to mail you and let you know. You made my year.

Nostalgia and speculation on the nature of human creativity follows:

When I was in highschool, I found a copy of SoundTrecker (a Mac mod tracker) and a few mods somewhere. Pretty soon I was downloading mods from boards as fast as I could. At one point I had an entire syquest 44 cart filled up with em. Pretty amazing over a 9600 baud modem! I remember when I eventually had a 28.8 and I could download mods faster than I could listen to them... that was quite an epiphany (I had the same epiphany when I discovered mp3 ftp servers a few years later when I worked at the state of michigan, which had a T3. I have not yet had that epiphany with movie torrents yet, but I have a feeling we're close. I also don't really like video as a media). Then when I was in college I found my favorite song ever... FOOP.MOD, a brilliant breakbeat choon that I still love to this day. I was also buying CDs at the time from various random techno acts of the day, but with the exception of Aphex Twin, Luke Vibert, and Mike Paradinas, I was continually disappointed. There was just something about the raw emotion and uncut feel of mods that compelled me much more than some random crappy-ass major label release.

There is a psychic difference between the product that one creates for love versus money. When someone really, truly loves something and does their absolute best, it bleeds out between the lines, oozes all over your hands and sticks to you and won't wash off. I work at slide because I love programming, and the fact that I get paid is a pleasurable side effect. It is this raw hot plasma passion that fuels the internet, the blogs-versus-journalists and mp3-versus-record-mafia battles. The 9 to 5 work week and the boss-employee fiction is a recent creation in human evolution. The creative drive of which I speak is not. It may not happen tomorrow, but the politcal and social fads of the day will fade. They will be replaced with new social customs and norms. Each step of the way humanity will delude itself into thinking this custom is "natural" and has somehow always existed. But the only thing that has always existed is the creative big bang. God. The Universe. Order from chaos, strange attractors in the cellular automata. Find it, feel it, follow it, hold on.

So yeah. Thank you for who you are and for letting me see it through the magic of the internet.

If I don't post to my blog more often it is going to become a barren wasteland, so perhaps I shall begin posting on a wider range of topics like this one.


JavaScript sucks ass, part one million

In the spirit of Bob Ippolito's JavaScript Sucks posts, here is one of my own. Sit down and let me tell you a tale about the little language that is so close to being good, yet so far...

Recently, I changed jobs. I joined a company called slide, which is building a hybrid photo sharing application using a combination of fat client and rich web technologies. In my drive to create responsive web applications I have been exploring techniques which make heavier and heavier use of client-side JavaScript. I now find myself doing less and less Python and more and more JavaScript rendering code.

I don't really mind this too much. I think JavaScript is a reasonable language, with reasonable anonymous function syntax, real closures with mutable parent scopes, and prototype inheritance (with the most bizarre implementation that unfortunately renders it almost unusable). However, every once in a while I hit some issue which drives me absolutely insane trying to debug.

Here is what I ran in to. The following:

{'foo': 1}

Is not valid syntax. However, the following:

foo = {'foo': 1}

Works fine. I ran in to this issue while trying to eval constructed strings of javascript. Even though eval returns a result, giving it a single JavaScript object literal results in an exception. Tacking on an assignment at the beginning fixes the issue. Ugly.


From San Francisco to Detroit for MacHack 20

I have always wanted to go to MacHack, but I never actually have. Ironically, I even lived in Ann Arbor—just miles away from the Dearborn location—for a few years in the 90s. This year, since I was laid off from work and could afford to take the time, I decided to go. So far it has been an amazing experience, and thus I relate a story of the journey as told in pictures.

Before boarding a plane for Detroit, I spent a night at a hotel in San Francisco. They apparently had internet access from out of the 19th century.

The view from my hotel in San Francisco was stunning...

...while the view from my hotel in Detroit is less so...

...and apparently in a low-rent neighborhood.

The snacks at MacHack are sponsored by Google this year and are therefore of very high quality...

...especially the candied fried eggs, which are delicious.


LivePage rules

At SuperHappyDevHouse last weekend, I finally got the time to update the Chatola example to the latest livepage APIs, which I was developing in a series of branches named livepage-completion-notification. Since all the examples are now updated and the new API is relatively robust and stable, I merged this long-standing branch into trunk today.

These API changes were the major thing I wanted to get done before releasing Nevow 0.5. Unfortunately, after the 0.4.1 release the other major change occurred: Depending on zope.interface. formless.annotate.TypedInterface did some things with Interface that zope.interface doesn't like at all. So I'll have to decide how to deal with this; right now I'm leaning towards hacking them out using any means necessary. It won't be pretty.

With livepage solidifying, formless next up to be put through the refactoring ringer, and a planned context refactoring in the future, Nevow is really starting to move towards a stable 1.0 target.

One last thing... I have a secret LivePage project that I have been working on which I am very eager to show the world. Some of you know about it; don't tell anybody what it is yet, I want it to be a surprise :-)


Please take this oath

I, your name here, do solemnly swear, never to play a 6 over 4 polyrhythm in a four-on-the-floor dance track, where the rhythm repeats every 4 or 8 measures, lasts for a duration of one measure, and has a timbre similar to that of knocking on wood or stomping on the floor.

Thank you.


Multiuser Programming

When I was in High School, LambdaMOO opened to the public. I spent a lot of time in high school and college hanging out there, programming, and even did my first web application development on E_MOO, which had an HTTP server implemented in moocode. After E_MOO went down, I decided that I wanted to recreate the MOO experience as a graphical multiuser networked programming environment. The ability to log in to a machine, edit some code, manipulate the "object" whose code you just edited, and hand it to your friend halfway around the world for debugging is a very compelling experience. I hadn't seen it recreated to my satisfaction and I wanted to do it.

I spent a few years coding, but it was slow going. Both network applications and GUI applications require a different mindset than the batch process style of programming which is what you learn in computer science classes. Event driven programming takes a lot of getting used to, and even when you understand what you are doing, it can be difficult to write and debug event-driven in C or C++, the language of choice in the mid 90s.

In 1999, I was doing a lot of Flash work and saw how it might be possible to tie a Flash front end to a multiuser back end server. When Flash 5 came out, I decided to revive the idea of a graphical front end to a multiuser programing environment. I wrote a simple HTML page which contained some JavaScript DHTML code I put together for mutating the DOM and embedded a small, wide Flash movie towards the bottom of the page. The movie contained an input text box and some ActionScript which sent the contents of the box over an XMLSocket when the user pressed return.

Because the XMLSocket used null bytes to delineate each message sent across the wire, I hacked the C source of the MOO server (running a MOO core my friend Pictwe and I had been running since 1995 -- MOOf) to send null bytes between each "line" of output from the server. Because of restrictions Flash placed on the hosts and ports to which you could open an XMLSocket, I had to create an application server capable of both serving the HTML, JavaScript, and Flash files, and proxying the XMLSocket connection to the actual MOO server. I had done a few simple CGIs in perl and thought about using that, but perl sucked. I did a bit of web searching and discovered Python.

After reading the socket and threading documentation (old habits die hard) I had a simple server working. You could load the web page, type commands in a text box, press return, and your command would be sent to the server where it was executed like it came from any other client being used to access the MOO. Any time the MOO generated any output on your connected socket, the intermediary server would push it into the browser over the XMLSocket, the ActionScript would unpack it and send it to JavaScript using LiveConnect, and the JavaScript would use DHTML to change the page. Sound like AJAX? :-)

Shortly thereafter I got a full-time job writing Python web applications. After developing for a few years in Webware and Zope, I decided to play around with some ideas I had for an easier to use templating system. This led to the creation of DOMTemplate, Woven, and Nevow, and it turned out to be a longer process than I had hoped. Sometime in late 2002 I decided to revisit the idea of performing out-of-band communications with a server to allow the web application running serverside to push and pull information into and out of the browser. I called it LivePage, and it was based on a highly transparent Model-View-Controller design, where controllers received events from the browser, updated models, and views automatically re-rendered themselves based on model dependencies. The results were then shipped to the browser and some DOM hackery was employed to replace the old DOM fragment with the newly rendered view.

The original Woven implementation of LivePage used Flash XMLSocket as the out-of-band event conduit. XMLHttpRequest was around at the time, and I did attempt to use it, but it reeked of MSIE nastiness and wasn't very standard cross-browser. XMLHttpRequest also has the distinct disadvantage of being based on HTTP. XMLSocket is a persistent, two-way, asynchronous socket architecture that made it delightfully easy to implement both Client-to-Server events and Server-to-Client events. XMLHttpRequest can only send data to the server once, and if you repeatedly send data from the server to the client and handle it incrementally, the document will consume memory without bound.

People thought I was crazy to even try to make web browsers do the things I wanted to do. It'll never work, it'll never be cross-browser, browsers can't handle it, people won't understand it... But I persevered. Browser stability was a real problem. After leaving a live page open for a while, with lots of changes being sent, browsers would leak all over the place and eventually crash. Both IE and Mozilla crashed like crazy. Eventually, after Gmail came out, the browser vendors seemed to get things under control and DOM mutation is relatively reliable now.

In October of 2003 when I sat down to spend a bit of hacking to try to come up with ways to simplify Woven, Nevow went from proof-of-concept to ready to use in a weekend. It wasn't until Gmail was in private beta that I decided it was time to revisit LivePage. This time, the aim was to keep the implementation as short and easy to understand as possible, with the hopes that other people would be able to figure out how and why to use it. I also decided to use XMLHttpRequest as an experiment, to reduce the number of dependencies. XMLHttpRequest makes some aspects of the architecture more difficult (Server-to-Client events) but in some ways makes other parts of the implementation much easier.

Since I only get to work on LivePage in my spare time, it has been slow going. However, the implementation as it is in Nevow is now almost ready to tackle the task of constructing very dynamic, complex applications. There are some implementation details which, after being exposed to the real world for a while, need refactoring. I have a few ideas on how to make it even easier to use from an end-user programmer's perspective. Finally, a coherent idea of how error handling occurs between client and server is starting to take shape. In the latest livepage branch which includes some unfinished improvements, which I hope to merge in the next week or so, the server can reliably handle an exception which occurs on the client. That's right, Python code can be written to handle client-side JavaScript exceptions. Also, LivePage as it exists in the 0.4.1 release has very robust "User has left the page" notification support. If the user clicks the back button, closes the browser, or even crashes their machine, the server is guaranteed to know about it no more than a minute or so later.

I have spent 10 years of my life, on and off, working towards this dream I have. Nevow and LivePage are the latest incarnations of puzzle pieces which fit into the mosaic of this dream. Hopefully someday very soon I will start fitting the pieces together and start to see what a true multiuser web application looks like. We already have a taste for what collaboration can enable; sharing information using weblogs, instant messengers, wikis, file sharing applications, and tools like SubEthaEdit allows to more rapidly fine-tune our idea of what others are thinking. Only a few pieces are missing; a more graphical, spatial ability to arrange information, where information can be picked up easily and carried from place to place in order to sort and categorize it; a more real-time sense of community where presence information gives us a sense of who we are near and allows us to easily communicate with them; and a more immediate programming model where changes can be made to live applications and applied immediately, with results available for all to see. All the pieces are there, they just need to be put together to complete the puzzle.


SSH authorized_keys problems

Note to self: whenever you have problems with SSH authorized_keys not working, check the permissions on the directories and files. Here are some quick instructions for getting SSH authorized_keys working on a new host:

ssh to the remote host and:

mkdir .ssh
chmod 700 .ssh

Back on the local machine:

cat .ssh/id_dsa.pub | ssh remotehost "cat > .ssh/authorized_keys; chmod 600 .ssh/authorized_keys"



I'm at PyCon this week. PyCon is my favorite conference, ever. This year it is better than ever, with tons of people at the sprints and lots of activity.

amk told me "if you're sprinting and have gotten something
accomplished, please weblog it.", so I am :-)

Zac Bir and I sprinted on a simple PyObjC app which scratches a simple itch I have occasionally. He describes it more eloquently than I could.

While MacGregor is incredibly cool and fun, the exciting Nevow related thing I completed is LiveTest, a browser-based functional web testing framework. Since it lives in the browser and triggers actual browser events, it is capable of testing highly JavaScript based apps, such as LivePage apps. There is an example of using it to test a LivePage application, LiveAnimal, in Nevow now.

Finally, I released Nevow 0.4! There are lots of improvements and bugfixes in this release, which is available for download from here.


Using Python to find Type/Creator codes

It has been a while since I needed to know about old-style Mac Type/Creator codes, but today I wanted to search my hard drive for files of a specific type. I thought you used to be able to drag a file into the find file Type box and it would automatically assign the Type to the input box, but this no longer seems to be the case on OS X.

I thought about downloading some utility which would allow me to see the Type code of a file of the same Type as the one I was trying to find, but then I realized I could probably do it with Python, and I was right.

>>> MacOS.GetCreatorAndType('/Volumes/Stormbringer/Audio/New Sessions/Guitar Project/Guitar')
('MOUP', 'PERF')

I also find myself occasionally using the Python REPL to do things like perform some quick math, convert between a char and the ordinal of that char, and look up unicode glyph names and resolve them. Instead of downloading some specific program to do some task, I have access to this vast functionality space which I can use to create my own utilities simply by remembering the steps to perform.



I am always interested in new languages. I enjoy learning new ways of thinking about problems. While I was catching up on 6 months of unread NetNewsWire feeds, I read r0ml's post on languages and felt compelled to respond. r0ml doesn't seem to have comments or trackbacks enabled, but perhaps he'll see this in his referrer logs.

I was talking to a friend of mine about CPU megahertz, Moore's law and the laws of Physics, and the increasing need for programmers to be aware about concurrency. We started talking about one good way of scaling applications to multiple processors, vectorization. The first thing that comes to my mind when I think about vectorization (besides Altivec) is APL, thanks mostly to r0ml. So I did a search for "apl mac os x" and one of the first things that comes up is APLX. I don't know if r0ml has looked at this and discarded it as unviable or uninteresting, but it looks promising.

Smalltalk is another language that I like very much. The syntax feels so much easier to read. Smalltalk has historically not integrated well with it's environment. ambrai Smalltalk looks like it is on the way to fixing that problem. Not only does it very tightly integrate with the Mac OS X gui, it even appears to have command-line integration features.