PUBLIC MARKS with search clean

XML -- while modern and clean and uniform -- isn't as convenient as LaTeX and RST.

Shifting focus

Posted: Wednesday, December 23, 2009 ~ 4:54 PM

This is the last new post that I'll be making on this blog. I decided a while back to shift the focus of my web activities, and thought it was time to formally close things off here.

Why stop posting here? Mostly just a feeling that I needed to shake things up a bit, to put some serious effort behind a few other ideas that I've wanted to work on for a while. Making a clean break just felt right.

There may still be some activity on this site as I back-fill some old posts from other blogging platforms. My goal is to eventually have this as a (more or less) complete archive of my personal blogging from early 1998 to this year. That's a background project of mine that I plan on allocating a bit more time to in 2010.

A huge thanks to Karl Dubost for hosting this blog for so long. In addition to providing this infrastructure, Karl has supported and inspired me in more ways then he may realize. That you are reading this today is due in no small part to him, so you can thank (or blame!) him.

When it comes to releasing source code, I’ve always been torn. I really believe in the philosophy of open source, but I’m intimidated by putting my code out there for everyone to see. Underneath it all, I’m probably scared of being exposed as some kind of a charlatan (”You call that programming?”). So, to pre-empt that possibility, I’ll start by saying this: I’m not a great programmer. My code is clean and fairly well-structured, but don’t expect to find any particularly advanced code wizardry or complicated mathematics. I do, however, think that the projects that I’ll be sharing over the week contain some good ideas, and a lot of helpful techniques. Hopefully you’ll find one or all of them useful.

This is a design scratchpad for an HTTP RESTful API for Bugzilla. It will be implemented as a proxy, using a variety of methods (the existing API, web scraping) on the back end and with a clean interface as defined here on the front end.

This is (EF BB BF) C3 B6 3D 22 21 22 loaded into browsers under various labels. That happens to be properly formed ECMAScript code for all the encodings used. The bogus results for Opera9 can easily be reproduced in context of the testing script, but probably not individually from a clean cache; what's going on there is unknown. I also noted in running these tests that Opera claims "Opera supports the entire ECMA-262 2nd and 3rd standards with no exceptions" while in fact their implementation does not, the parser rejects code that follows the IdentifierStart :: UnicodeEscapeSequence production of ECMA-262 section 7.6. Instead it implements Opera-only extensions, like comma-free arrays ala [ 1 2 3 ]. Other fun facts include: IE does not implement onload for iframes and cannot modify the innerHTML or tr elements; Firefox ignores "tags" when setting the innerHTML of dynamically created tr elements with no ownerElement... Oh and Opera again needs /th "tags" so it won't nest adjacent th elements when setting innerHTML.