jerakeen.org

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

http://www.pingwales.co.uk/software/cox-on-better-softwar...

Programming languages have grammar. There are languages like perl, where the grammar is composed almost entirely of random ‘$’ and ‘%’ symbols scattered throughout the code. And there’s languages like AppleScript, where the grammar is practically english, making it much nicer to read than perl. Hah, perl is often called a ‘write-only language’, it’s so incomprehensible.

But I loathe Applescript, and I think perl is luuurvely. And it’s for this exact rule. I can use computers. I’m a geek. And I’m prepared to learn a new grammar. That’s fine, and it’s a specialist grammar, and programming is like that, I’ve learnt a heap of these things. But english-like programming languages are confusing. I can speak english. I know how it works. In english, you can rearrange words and have the sentence still make sense. Try doing that in Applescript. Grammars that look like english, but aren’t actually english, annoy the hell out of me.