jerakeen.org

Right. Here’s an idea I want someone else to build, because I’m too lazy/busy. I want a Stomp interface to mysql.

Let me explain. There are lots of reasons you might want a message queue architecture in your new web application. You want long-running background processes, or you want to fan out changes to lots of users without tying up the web server process. Or you want to make calls to an API somewhere, again without tying up an expensive web server process. It’s a lot easier to build this stuff in from the beginning than to try to work out later which bits of your application flow don’t need to happen before the web page is returned to the user.

At the same time, it’s a tiny new web site. You don’t want to have to run a message queue just yet, so you want to fake it - write tasks into a database table, and have a long-running daemon loop forever, pulling out rows in order and doing them. Almost as good as a real message queue for small volumes of messages, and a lot cheaper. So what I want is a way of doing this that has the same API as a real message queue, so that when you cut over, you don’t have to change any code, everything just gets more responsive. Yay!

Right. Now someone do it. Let me know when you’re done.

Fascinating stuff about the techniques Dungeon Siege uses to power its continuous world. Includes scary threading, performance hacks, etc. via some other tab that’s long since been eaten by the ravages of time and system crashes (thank goodness for what little session saving Safari does) but I think I might have been tomc. (blech tells me it’s via Migurski’s uxweek notes )

http://www.drizzle.com/~scottb/gdc/continuous-world.htm

http://www.ibm.com/developerworks/aix/library/au-threadin...

One of the better python XML libraries. Ships in core python.

http://effbot.org/zone/element-index.htm

One of the things that’s been annoying me about JavaScript recently is the inability to only catch certain classes of exception, as in Java or Python, for instance. The try {..} catch(e) {..} block has always seemed too inclusive. But recently Ash found a crazy syntax in SpiderMonkey that lets us only catch certain exceptions.

try {
  // something that can throw
} catch(e if e.bar == 'foo') {
  // an error is only caught here if it has a 'bar' property of 'foo'
} catch(e if e.bar == 'baz') {
  // there can be different catches for different conditions
} catch (e) {
  // otherwise it's caught here. Without this block, the error would fall
  // through the 'try' and be re-thrown.
}

I haven’t bothered testing this in Internet Explorer (or any other web browser for that matter), because I’m only interested in server-side JavaScript execution at the moment. It works in at least recent SpiderMonkey CVS and Rhino 1.6r6, not sure about earlier versions.

Ash Berlin and I recently hacked together an Apache module that embeds the SpiderMonkey JavaScript engine and lets you run JavaScript code on the server as CGI scripts. We called it mod_js.

I’m finding E4X to be one of those weird technologies that is alternately utterly wonderful and incredibly irritating. The ability to treat XML data as any other JavaScript data structure allows very fast app development and messing around, but every so often I find myself amazed at how awful the syntax is.

Today’s irritation is about E4X attributes.

// a perfectly normal E4X object.
var myXML = <xml foo="bar">content</xml>;

// the attribute with value 'bar'
var myAttribute = myXML.@foo;

Easy. I love this stuff. Unfortunately, Zimki, my company’s product, uses uneval to store complex objects, and the myAttribute variable there would count. uneval won’t produce JSON but it does produce a string that, when run through eval, will probably produce the original data structure, and we store that string in a database to store object.

Not so for E4X nodes. Playing in the SpiderMonkey JS console,

js> uneval( myXML );
<xml foo="bar">content</xml>

js> uneval( myAttribute );
bar

The first one is fine. That string will eval nicely back to the original E4X object. But the ‘bar’ there isn’t valid JavaScript - eval won’t restore the original object. In fact, had the original XML been something like:

<xml foo="delete_all_zimki_data()">bar</xml>

and we’d tried to use eval/uneval to store this XML, we’d have executed the attribute as JavaScript. Ick.

Unusually, Rhino handles this much better (normally I find Rhino lags in features..):

js> uneval( myAttribute );
<>bar</>

Not really an attribute node any more, but at least it’s valid JavaScript and won’t destroy my server.

I don’t even have a good solution for this. Right now I’m fudging E4X nodes in the storage engine, but I really feel that attribute nodes should uneval to something a little more sensible. Perhaps I’ll be able to produce a patch to SpiderMonkey, if I have time..

sheets in cocoa. Because it’s not clear how to close them safely otherwise.

http://cocoadevcentral.com/articles/000014.php

greatest. slide. evar.

http://perl.plover.com/yak/12views/samples/slide045.html

Camelbones 1.0. Congratulations to Sherm

http://camelbones.sourceforge.net/documentation/history/d...

things to play with when I get back to a desk that has a mac on it.

http://nodebox.net/

A comparison

http://www.25hoursaday.com/CsharpVsJava.html

Having played around with the JavaScript string type some more, I think I understand why it acts as it does. I’m a Perl monkey normally, so I’m not used to the concept of immutable strings, but JavaScript strings are immutable. Playing with the === operator (approximately, ‘is this the same object’) gives:

js> "a" === "a";
true
js> "a" + "b" === "ab";
true
js> "ab".replace(/./, "c") === "cb";
true

but

js> new String("a") === new String("a");
false

If strings were to magically upgrade themselves to objects, they’d change behaviour - previously equivalent strings would suddenly not be equivalent. Likewise, suppose this worked:

var a = "string";
var b = "string";
a === b; # true
a.foo = 1;

Shoud a still be equivalent to b? If not, a clearly isn’t immutable, as we’ve changed it. But if it is, then we’ve chanaged b at a distance - it’s grown a foo attribute.

Still all very annoying, of course, but I understand why now.

More playing with JSON and Spidermonkey has revealed yet another incredibly annoying fact (I hate those guys). Spidermonkey provides a lovely uneval() function, that does the exact opposite of eval() - turns JS objects into strings. It works on almost everything, and make life very very nice. There’s also Object.toSource() which does something similar (but not the same - try uneval("") vs "".toSource()).

But the strings that uneval produce are not valid JSON, as I have been assuming. I’ve been getting steadily more worked up at all the JSON parsers in the world, refusing to parse things that are clearly valid JavaScript, and eventually I go look at the spec, which fails to list ' as a valid string delimiter. And guess what delimiter uneval produces? Yay. So all the parsers are fine, and it’s just SpiderMonkey that’s broken.

Fortunately, Mochikit provides a nice serializeJSON() function.

http://www.alice.org/

On test-driven development in the real world - [[ All these are ugly solutions, design-wise. And Feathers knows it; he makes multiple apologies for his techniques. But he stresses that they work. ]]

http://www.helpfultiger.com/helpfultiger/2005/11/it_only_...

Javascript templating language. Completely insane.

http://trimpath.com/demos/test1/trimpath/template_demo.html

Off I go, making random unsubstantiated claims about the danger of using JSON with non-ASCII characters. This called for a Test. So I wrote one. Visit my JavaScript unicode test page and see how your browser interprets external JavaScript files - I serve an ‘é’ using JavaScript to the page via 3 methods and 2 character set encodings, and try to render them all.

My conclusions from some limited testing? Owch. You can’t include a JavaScript file and expect the client to interpret it properly, unless you control both the server serving the JavaScript and the HTML page requesting it, and can make sure that they’re both in the same character set. Alternatively, you can escape all non-ascii characters in your JavaScript files using the \xXX or \uXXXX notations, which seems to work everywhere I’ve tried, but also seems like a pathetic work-around. Anyway, needing a work-around for only the non-obvious case means that no-one will actually do it, because no-one ever seems to bother testing with non-ASCII (see any on the JSON examples page, for instance?).

However, requesting JSON using XMLHTTPRequest seems to do the Right Thing in every browser I’ve tested, including those that include JavaScript wrongly. So if you’re using JSON as an RPC transport, instead of XML, for instance, it looks safe. From a character-set point of view.

In the bad old days of web 1.7ish, the cool thing to do for dynamic web applications was to generate HTML snippets on the server-side, pull them into your app using XMLHTTPRequest, and shove them bodily into a DIV on the page somewhere. “generating DOMs is hard” was the excuse, “the server already has a nice templating language”, etc, etc. And this was Good.

Nowadays, of course, this is Evil. Pulling HTML across the wire? It’s inefficient! Even worse, we want to send XHTML to the client, because it’s cool, but then you can’t treat your HTML like a string, you really do have to mess with DOMs. Fortunately, cute tools like MochiKit make it really easy to create DOM nodes, and provide really nice tools for making ajax requests. We see the rise of JSON - serializing your raw data on the server into a JavaScript-evaluatable string and sending that across the network, then building the DOM on the client side based on that data. And this is Good.

Soon, I expect, people will run up against annoyances in JSON. For instance, I bet there are lurking character set issues. It’s also not very portable - if I go to all the trouble of writing and exposing interesting functions of my web application in machine-readable ways, I’d like to be able to access this data using things other than javascript. Sure, there are modules like JSON that will both create and parse these things, but throwing actual XML around seems much neater to me.

We have a strange mix of XML and JSON APIs at the moment, some toolkits even making it easy to ask for either. But I consider XML far superior for this sort of thing, if only because the character set issues (my personal bugbear) are properly solved with XML. It’s disadvantage is that the JavaScript tools for dealing with the DOM are very annoying, but when we have something like XML::Simple or xmltramp for JS, and reading incoming XML is almost as easy as reading JSON, we can get rid of it and use nice sensible RPC mechanisms. JSB is a lovely example of this, for instance. And this will be Good.

http://search.cpan.org/~thaljef/Perl-Review-0.04/lib/Perl...

http://www.gotw.ca/publications/concurrency-ddj.htm

http://www.amk.ca/python/howto/unicode

http://gusmueller.com/odb/

http://www.joelonsoftware.com/articles/fog0000000043.html

I’ve played with python some more, and there are more things I don’t like about it.

For objects, attributes and methods are called with the exact same syntax, the ‘.’ character. So for an object ‘foo’, foo.bar is the attribute (member variable) ‘bar’ of foo, and foo.baz() is a function call on the method ‘baz’ of the foo object. But if a foo object has an attribute ‘bar’ and a method ‘bar’, foo.bar gets the attribute, and foo.bar() explodes, because an attribute isn’t a function. I don’t like that you can hide functions behind attributes.

More object stuff - there’s no abstract ‘call my superclass method’ calling convention. You have to either explicitly call a class method on your superclass (calling it by name, so changing your superclass would be Pain) and passing ‘self’ as the first parameter, or you use the magic ‘super’ method, which requires you to pass your class explicitly, also meaning Pain if you rename things. Hello? self.super? Sigh.

Incidentally, there are plenty of things about python I’m really liking - it’s not all pain. But people don’t blog about things that they like, they blog about things that annoy them. Human nature - deal with it.

Wheels that perl programmers always end up reinventing.