... there's an online video of 8088 Corruption that is an absolute must-see.

Trixter, you rock!

1. Ever since I bought my car several months ago I've been looking for a decent audio platform to put on it. My primary concern was support for the excellent Vorbis audio codec - this is the codec I use most often in my music archive due to its superiour quality (I spent hours and hours comparing best-case rips encoded with LAME [MP3] and Vorbis and have found Vorbis to be the better codec - I'll write another post about that if anyone's interested), smaller footprint and patent-free nature.

Although Vorbis (and its container format OGG) has seen lackluster support from hardware vendors since its introduction in 2001, the past two years have seen thoroughly improved support for the codec -- most portable players (including oblique Chinese models) now support Vorbis just fine. Cars, however, are a completely different issue: there are exactly four car-oriented products that support Vorbis (the Vorbis wiki contains a complete list) and I wouldn't settle for 'just' an MP3 player. For a time I was considering building an ITX-based car computer, orevaluated products such as the PhatBox; eventually I settled on a more mundane in-dash CD receiver called Yakumo Hypersound Car. The decision was mostly based on the cost of the more exotic solutions and the much higher risk of someone trying to break into my car.

The Yakumo is very difficult to get; you can either get it from Amazon UK (but they don't deliver electronics overseas) or from certain German vendors. I eventually ordered the unit from a very efficient eBay shop and it finally arrived last week.

Anecdote: Israeli tax is murder; not only did I have to pay the 16% European VAT (having bought the unit from a German reseller), which I may or may not be able to get back, and the €40 shipping fee; on top of that I had to pay an additional 15% customs tax and 16.5% Israeli VAT, and that's on the shipping too! So bottom line, a €96 unit cost me close to €200, shipping included. That's an insane amount of money to pay just for the privilege of buying something you can't get in your own country, and even if you could you'd probably be forced to pay the local importer handsomely. And imposing a tax on the shipping fee should be proper illegal.

Installation was a breeze (any experienced technician should be able to do it in 20 minutes; I'm not an experienced technician so it took close to an hour with my dad helping out), and with everything hooked up I inserted a freshly-burned CD, held my breath and... woah! Iris playing in my car in gorgeous Vorbis! That alone was worth the price of admission. I do have some qualms with the device, though, primarily the lackluster display (yeah, OK, blue backlighting has been out of fashion for at least a couple years) and the awkward navigation (you can't easily navigate by album), but considering the very reasonable initial cost of the unit, which also comes with an SD card-reader, USB port for mass storage devices and remote control (!) and the so-far excellent sound quality which easily rivals the generic JVC CD receiver I had earlier, this product comes highly recommended. Update (after a short period of constant use): I do NOT recommend this product.

2. I just got my second Microsoft Natural Ergonomic Keyboard 4000 (a.k.a Ergo 4000). It has replaced the trusty Model M; we'll see if it lives up to the hype. I actually got one last month, but returned it the same day because Hebrew character engraving looked as though they were hand-drawn by a five year-old with severe ADD. This one feels a bit different but is so far extremely comfortable; I'm astounded that no other keyboard features a cushioned hand-rest like this one, it makes working with the keyboard infinitely more comfortable to the point where I don't know how I managed to live without it all these years. I've used Microsoft Natural keyboards for the last ten years so the ergonomic ("split") design is one I'm very familiar with. There are some differences though - some keys are aligned a bit differently and require different finger movements, but so far I seem to be getting used to the layout very rapidly. The tactile feel of the keyboard is also different from the Microsoft Natural Elite I've been using these past few years ('till I switched to the Model M); it's softer and at first seems slightly less responsive (during the first couple hours of working with the keyboard I was very prone to the classic manglign-of-the-last-two-lettesr syndrome) but as soon as you adjust the strength with which you depress the keys it becomes very natural (no pun intended). Unlike my dad's crappy Microsoft Desktop Multimedia keyboard this one has the f-lock enabled by default, and so far I haven't touched the extra keys or zoom slider. At $65 it's not cheap but not prohibitively expensive either (unlike the $80 Logitech MX1000 mouse I use).

So far, so good. I'll post further comments on the keyboard when I've used it for a while.

 

I was doing some research on how to use a certain component we were given as part of a project. It is a COM object written with ATL; I referenced it via interop and everything seemed to work perfectly. Until we integrated it into the main codebase, that is. For some reason the same code would barf on any call made to a method/property of a legacy ADO Recordset object; an instance of Recordset is passed by reference to the COM object, which initializes it to certain values. For some reason any call to the Recordset instance after the COM method call would result in a NullReferenceException being thrown by the framework.

Oddly enough, tests on the research codebase (on my own machine) now proved to generate the exact same error; considering I had written and tested the code merely two days before, I was disinclined to believe the code to be at fault. Something told me to look into the interop assemblies - we sign every COM/ActiveX import in the project with our own keyfile using a script which runs tlbimp/aximp - and reverting to the VS-generated interop assemblies did indeed resolve the issue. I couldn't find any solution using Google (a Groups search provided a similar issue with no solution offered). Finally I stumbled upon the following quote in this article:

But Primary Interop Assemblies have another important use. Interop Assemblies often need modifications, such as the ones shown in Chapter 7 to be completely usable in managed code. When you have a PIA with such customizations registered on your computer, you can benefit from these customizations simply by referencing the type library for the COM component you wish to use inside Visual Studio .NET. For example, the PIA for Microsoft ActiveX Data Objects (ADO), which ships with Visual Studio .NET, contains some customizations to handle object lifetime issues. If you created your own Interop Assembly for ADO using TLBIMP.EXE, you would not benefit from these customizations.

Since the ADO COM object was automatically imported along with our proprietary objects this got me wondering what sort of "custom optimizations" I might be missing out on. A quick look in the knowledgebase article on the ADO PIA didn't prove very effective (short of a vague statement about "the ADO PIA helps to avoid certain problems with ADO and .NET COM interoperability") but I decided to try it out anyway; I removed the preexisting reference from the project, added "adodb" from the .NET tab in the Add References dialogue (you could look it up manually in the GAC, but why would you?), fired it up - problem solved.

As an anecdote, referencing an external library with tlbimp's /reference command line parameter (particularly the ADODB PIA from the GAC) did not stop it from generating the imported library anyway. Just go ahead and delete it.

I saw this joke and couldn't help myself. Sorry, it won't happen again.

Or rather, help me to help them   I keep filing bugreports (which are usually fixed by the next release) and feature requests, but in order to get attention the feature requests need votes. Have a look at these two feature requests and vote (or comment) if you think they're important. If not, tell me why:

Additionally, build 215 is out.

Or: How I Learned To Stop Worrying And Love Firefox (this is a Dr. Strangelove reference, in case that wasn't obvious).

There are some fundamental principles of UI design most developers have not taken to heart. Developing a good UI is hard, designing one is excruciatingly hard. A good UI designer needs to have a very developed sense of how a typical user thinks; it is therefore a commonly held belief that most programmers make lousy UI designers because they can't "stoop to the level of the non-technical user" (a slightly less rehearsed mantra is that developers are users as well and are susceptible to the same problems with crappy UI, although possibly a little more forgiving). The developer-oriented UI trend is most obvious with open source software, but it is actually exacerbated when we're talking properietary, even if free, software. An open source tool that is essentially really good but has crappy UI will eventually attract someone who is actually capable in that department. Take a look at Eclipse, OpenOffice.org, The Gimp etc. - although based on a more or less solid foundation, these tools were practically useless a few years ago and have only become mainstream when they made leaps and bounds in usability. An even better example is Firefox; although I was personally attracted to Firefox on merit of its technical achievements, I was only able to sell it to friends and relatives becaues it is infinitely more usable than IE and just as free (I mean come on, does anyone doubt why Opera never gained marketshare?)

A proprietary program however, even if fundamentally sound and useful, can only grow better by the efforts of its owners. Even the most obvious bugs can never be fixed by a 3rd party. w.bloggar is a classic example of this; the last version was out in January and, despite being fundamentally stable and usable, has huge flaws which the author never fixed, instead allowing the software to stagnate. I reckon a lot of you, at this point, are thinking along the lines of "hey, you get what you pay for; you should be thankful that w.bloggar is free, let alone supported!" In a way you are right, but also dead wrong. As far as I know Marcelo (the author of w.bloggar) isn't seeing much money from his work on the software; what money he does get is from donations. So why not release the source? Donation systems seem to work for high-profile open-source projects at large, why not for w.bloggar? At least that way someone can fix the bugs that (for me) turned w.bloggar from a useful tool to a constant cause of frustration.

To get to the point, I wrote a blog entry in w.bloggar (specifically the one about missing tools), published it and went on with my work. At the end of the day I left the machine running (as I always do when I'm not leaving for days at a time) along with w.bloggar. Why'd I leave w.bloggar open, you ask? Simple: one of these glaring bugs I mentioned is that w.bloggar does not retain my preview template options (CSS links and so forth), and it's a pain in the ass to enter them manually whenever I want to edit or write a new post. Anyway, w.bloggar has a "Clear Editor after Post" option which in my case was disabled. This means that whenever w.bloggar finishes uploading a post, it retains the text and changes its internal state so that subsequent clicks on Post update the same entry (as opposed to creating a new one). So what basically happened is that when I came in today and wanted to write the note on OpenOffice.org, the previous post was still "live" on w.bloggar. Usually at that point I click on New (which shows a nice, useless warning dialog) and get on with it; this time I guess I was distracted, just shift-deleted everything and proceeded to write. When I next clicked on Post and got the "Post so-and-so-GUID updated successfully" notice I knew I was up the creek: my earlier post was overwritten with no prior warning, no delay and worst of all: no backup.

Which brings me to my first point: w.bloggar sucks. Bugs (like not retaining options and the most defective HTML syntax highlighting known to man) aside, this is a huge usability problem - a user can (and evidently will) inadvertently erase his/her own work and have no way to recover it. The undo buffer is not even remotely deep enough; there are no dialogs to warn you that you're about to update a live post, and there are no backups-shadow copies-anything of published posts if you do not actively save them. Worst of all, there is no-one to mail, no bug tracker, not even a forum (the forum link on the w.bloggar site is broken). My first resolution for 2006: make more effort on PostXING and help Chris make it actually useful.

Now that that's out of the way, time for some damage control; w.bloggar is useless in recovering the lost content, dasBlog does not maintain any sort of backup (side resolution: implement shadow copies into dasBlog) and considering how cheap my hosting package is I seriously doubt my ISP would help me recover yesterday's daily backup (assuming there even is one) without significant trouble and/or cost. The only option that comes to mind is the browser cache; in case it isn't obvious from the title (and the large "take back the web" icon on the right), I use Firefox. Going over the cache files manually proved futile as most of them seemed to be binaries of some sort; some research showed me that you can access cache statistics by navigating to about:cache; from there you can access an actual dump of the in-memory and on-disk hashes. Looking at the on-disk cache via about:cache?device=disk and searching for something useful, I found a cache entry for the editing page. Clicking the link did not prove readily useful (the actual content is not displayed), but the information displayed shows two important details: the file location and the content encoding (in this case, gzip). This explains the strange binaries I found in the cache! A quick decompression via the excellent 7-zip and I had my content back. Second point of the day: Firefox has once again proved its mettle. Firefox rocks!

Coninciding with the release of OpenOffice.org 2.0.1, the OOo.il team has released a Hebrew version based off of the 2.0 codebase! It is sponsored (ironically) by the Israeli Ministry of Finance.

I haven't really tested this version but I do hope it's all it's cracked up to be. Time will tell.

Every developer has some glaring omissions from his/her toolbox. I just found one of mine: Chris Sells' XmlSerializerPreCompiler. I honestly don't know how I managed without it thus far.

Now that I mention it, here's a short (?) list of tools I constantly use as a developer, at work and elsewhere:

I hate ugly hacks, but sometimes you're left with no choice. I was hacking away at the XML schema for one of our projects, and eventually settled on a neat solution. Imagine the following scenario: your system stores its configuration in XML format; the configuration defines several types of events that can occur, and all these events share the same actions. What's the most efficient way to go about it?

Borrowing a page from the object-oriented software design book, I decided to create an abstract BaseActionType. It will include some basic self-describing information (lets suppose I'd like to have an action category; I would simply add an element to the base type and override the value in each subclass.) Each subclass would describe a different type of action, for example a SendEmailActionType would extend BaseActionType, override its category with a fixed value and add fields such as server, subject etc.

Unfortunately, it appears that XML Schema only supports one of two modes of derivation: derive by extension or derive by restriction, whereas what I in fact require is a hybrid of the two. xs:extension will not allow you to override values, whereas xs:restriction will not allow you to define new elements. This is a problem I used to encounter all the time when creating XML schemas, and today it finally pissed me off enough to find a solution. I was really stumped for a while, but eventually noticed that one of the examples on the XML Schema specification was:

It got me thinking: how can they be restricting a type while adding elements? Then it hit me - this is in fact a restriction on an xs:any particle! Here's the solution I came up with:

I reckon developers who are more experienced with XML than I am already knew the answer, but since I've been using XML far more intensively than the average developer and was repeatedly stumped by the same problem I hope someone finds this useful.

Update (January 2nd, 10:26): My technological enthusiasm has an annoying tendency to turn into a display of naïveté. Specifically, the hack above seems to work just fine for Stylus Studio (any maybe other technologies, who knows?) -- but isn't really accepted by the .NET SDK xsd.exe tool. There are two issues here:

I haven't been able to work around these limitations (yet), nor have I the time at the moment to research into XML Schema and find out if these features are supposed to be supported. In the meanwhile I'm reverting to another solution.

I've been getting into ARM assembler a little bit. The ensuing conversations were amusing in the extreme (I'm Holograph, in case that wasn't obvious):

I rest my case.