So I'm sitting at work, listening as I usually do to all sorts of music in the background. I found myself listening to the excellent soundtrack written for A Clockwork Orange (which also happens to be one of the best movies I've ever seen). Some of the classical pieces there have a distinct ring to them, as if they've been performed in a very peculiar and distinct (somewhat synth-y, for lack of a better word) style. It kept bugging me that I've heard this someplace before, and after some 40 minutes it finally struck me: it sounds highly similar to the soundtrack written for the movie Tron (also highly recommended).

I took a better look at the tracks to see who wrote them - a Walter Carlos. This was even more surprising for me, because I recall the Tron soundtrack credited to a Wendy Carlos. What's up?

Some digging in wikipedia proved once again extremely fruitful:

Her first six recordings were released under the name Walter Carlos, although, being a transsexual woman, she had already changed her name from Walter to Wendy. In 1972, Carlos underwent gender reassignment therapy. The last release to be credited to Walter Carlos was By Request (1975). The first release as Wendy was Switched-On Brandenburgs (1979). Carlos's first public appearance after her gender transition was in an interview in the May 1979 issue of Playboy magazine, a decision she would come to regret as it brought unwelcome publicity to her personal life. On her official site, her transition is discussed in an essay stating that she values her privacy on the subject.

The universe never ceases to surprise me.

I eventually get fed up with the various ReSharper builds I've been using for the past 7 months; the stability has been going steadily downhill since build 208 and performance is yet to improve. 217 originally seemed stable but turned out to be useless both for VS2003 and VS2005. I've been waiting in vain for a build as stable as 208 (which was practically beta-ready) but to no avail.

Eventually I broke down and installed the official 1.5.1 (build 164) for VS2003; unfortunately there are no official builds for VS2005 as of yet. I must say working with the official version is a pleasure - it's absolutely stable and, even more important, fast. So fast, in fact, that it feels just as responsive as the "regular" VS2003 IDE is, and the only drawback is a small increase in startup time.

I'm tenacious so I'll probably check the beta builds again when 218 is out, but in the meantime I can't help but feel pleasure in working with a mature product.

I came back to my apartment today after not being there for a couple of days, to find that our (my flatmate and I) router died due to a power outage. I needed internet access so I hooked up my laptop directly to the cable modem (a Motorolla) and for some reason couldn't get a ping anywhere; some digging showed me that for some reason the modem, which acts as a DHCP server, gives me a local (192.168.x.x) IP address, no DNS servers and no default gateway.

The modem would return pings and the operational web interface showed everything to be fine and dandy, so I spent the next 15 minutes having the most futile conversation I've ever had with a tech support guy. Now as a programmer and reasonably hardware- and network-savvy individual I figured that if a modem and computer restart won't solve the issue it must have something to do with the cable/ISP networks; there was nothing to indicate local failure, so I didn't think to examine the obvious.

The Motorolla modem has a standby button.

I'll be damned if I know why, but it does. And someone pressed it. All it took to get my internet connectivity back is to press it again. Which brings me to the point: it is well known that one of the cardinal sins is vanity, it is equally well known that programmers generally exhibit the three cadinal sins (vanity, hubris and laziness, I think?). So if you're a programmer, whenever you talk to tech support don't be a smartass. You'll save yourself time in the long run.

Back when I used to code demos with friends as a pastime (1995 or so) we would slave away on three or four PCs, at best interconnected with null-modem or parallel (a.k.a laplink) cables; whenever someone would have a breakthrough we'd reconnect the machines and shift sources around (sometimes opting to use modems or floppies instead). Eventually we'd get to a more or less complete set of codebases and integrate them into a single production.

That process could best be described as hectic. I'm amazed we ever managed to get any work done, particularly in the absence of automatic merge tools such as Araxis Merge; the number of times we would accidentally overwrite or modify each other's code, accidentally delete an object file or some other stupid mistake was astounding. With that baseline in mind, when I was introduced to SourceSafe back when I was serving in the Israeli army I was appalled. The concept of a singular repository for sources (with write access to everyone on the team, no less) seemed incredibly stupid, although in retrospect I couldn't tell you why. SourceSafe's (severe) problems aside, I'd expect the fundamental concepts of source control to strike a chord with me immediately, but it took a while for that to happen; over the years I've developed pretty rigid standards of working with source control - what should or should not be checked in, how long is it OK to check out a shared file exclusively (more or less the only option with SourceSafe...) and how to organize the repository effectively.

Fast forward to 2006. I'm working on a project that has several seperate components; the project, which is actually version 2.0 of a certain product, is kept in a central source control repository along with its dependencies (libraries, documents, installables) and everything seems to be fine. Only it isn't. The first problem is that the project was originally developed for an external company which uses Perforce as its source control provider of choice. We then brought the codebase back to Monfort and set out to rework the existing components and develop new ones. This means that while large portions of the code were being worked on, others remained completely untouched - in other words, some projects were imported into our source control system (Vault) and others were not. This proved to be very annoying when I had to re-integrate and test some version 1.0 code today; it's worth noting that Visual Studio is anything but graceful when it comes to handling unavailable providers or incomplete bindings:

So much for verbosity, but at least I can Work Disconnected...

... right after I click on OK again.

That was only the first hurdle. The second was an apparent lack of attention on a certain developer's part (sigh), who forgot to add installations for certain 3rd party dependencies to the repository. Fast forward another fourty minutes or so (DevExpress's installers suck) and I was finally on my way to a working test build.

At that point, a new developer on the project approached me with some compilation issues. This was pretty rudimentary stuff - installing a public/private key container, path variables, 3rd party installations etc., but the guy couldn't be expected to know how to do any of this stuff, let alone what needs to be done or where to get the required files. Which brings me to the conclusion of this here rant:

1. When you import a project into your development environment (source control, build system, back up, etc.) take the time to get (re-)acquainted with the codebase and make any necessary conversions. It'll pay off in the long run,
2. Always keep all dependencies safely tucked away in your source control repository. That's as close to a file server as you are going to get, it's properly backed up (isn't it?) and the files are kept close to their target audience - developers on that particular project.
3. A "Developer Workstation Setup" document is an absolute must-have. Saves everyone a lot of time and headache.
4. Try and maintain behavioural consistency between developers on a given project. This doesn't have to (and preferably won't) extend to indentation and code formatting issues, but some sort of check-in, documentation and dependency resolution policy is important, if not for the project than at least for your medical bill.

I'm a self-proclaimed part-time, low-budget audiophile (there's a mouthful), so I often try to combine good performance with reasonable cost. To that end, considering I spend about 80% of my time at work (and, up until recently, home as well) with headphones on my head, the Sennheiser HD600s I got about five years ago for the price of about 200 of today's US dollars after shipping and taxes were the absolute best bargain I've ever made. The Jean-Marie Reynaud Twin MK2 speakers I also bought at about the same time were so impressive that the lowest-priced comparable speakers were 60% more expensive.

Things have somewhat improved since then; the taxes on audio equipment in Israel have been considerably reduced, although at some 34% they're still very high (down from 70%...). I mentioned this before in my post regarding the Yakumo Hypersound Car. Since then I went to an auto shop for some additional equipment, specifically a 6x9" component set, 3.5" mids to replace the crappy ones in my Punto, a 12" Pioneer sub and 2x60w (continuous) amp (I'll post the models number later - damned if I remember).

On the left: Pioneer sub under the component speak, on the right: Yakumo Hypersound Car installed

While the CD receiver was a breeze to install, I'm pretty glad I didn't attempt to do the rest of it alone; I don't know jack about car electronics and some of the stuff involving the installation of the amp I didn't know to begin with (such as hooking up the negative terminal to the car chassis) and I would've done a heck of nasty job if I tried running some of the wires on my own. On the other hand, contrary to my usual cautious self I didn't do much market research and ended up paying considerably more than the equipment was worth. It was definitely a learning experience, though, and I won't make these mistakes next time.

That said, the sound is great - not perfect but I'm still tweaking it. The Yakumo unit turns out to have very poor amplification; at first I thought the specified 65dB signal-to-noise ratio was a mistype in the product manual, but it turns out rather accurate; there is a very audible hiss at even moderate volume levels (which I couldn't hear earlier because of the crappy speakers I bought the car with) and the rear-speaker sound is bright to the point of being harsh. This may or may not be attributed to the Pioneer component speakers - if so you can bet that they'll be replaced - but in the meanwhile I've found the amplification so horrid that I'm replacing the 2-channel monobridged Pioneer amp with a quad-channel amp to drive both sub and rear speakers (5- and 6-channel amplifiers are prohibitively expensive, so I'll skip those for now).

The Yakumo unit also suffers from some pretty severe usability issues; the TOC indexing times for USB devices (tested with a fully loaded iRiver H320) were nothing short of abhorring (about 3 minutes from iRiver boot). With CDs the problem is less of an issue, about 20 seconds for a 700MB CD, but I still think it's rather stupid that the unit can boot up to the exact location I last powered it off in but has to index the TOC first. The random mode is extremely useful with compressed files, but why does it change track when I turn it on? The fact that I can't navigate by folder (particularly with the existence of a jog dial!) without going through the tedious search function is ridiculous, and I've actually managed to get the unit's firmware to crash once or twice (Update: actually, the unit seems to be extremely crash-prone). I believe most if not all of these problems can be solved with a little work on the drive's firmware, but there is none from Yakumo. In my opinion the solution would be to simply open-source the firmware; it's probably based mostly on LGPL'd code to begin with, and it would allow community involvement in empowering the brand. I, for one, would be delighted to tweak the source code to my heart's content; it would make the unit all that more useful. With the lackluster amplification and usability issues it's very hard to recommend the unit to anyone but a die-hard OGG Vorbis fan.

Update: Having owned this unit for several months I can safely say that it, quite plainly, sucks. It is crash-prone, error-prone, extremely slow on boot up, requires constant resets and provides very low sound quality to boot. Its one saving grace is Vorbis support, and even for me that's not enough to save it from a "piece of crap" verdict. I'm going to replace this thing as soon as I find a decent alternative; the XiphWiki points at a similar product from Silvercrest, but given the track record of these things I'm inclined to forego in-dash players altogether and go for a hard-drive based solution. Now if I can only find a decent one...

Whenever I get a new machine (at work, at home, anywhere) I'm always astounded by the sheer amount of time it takes to get it up and running. I don't mean just the basics, I mean a fully-functional platform that is set up just the way I'm used to, right down to the folder display settings in Explorer and the toolstrip I always like on the right side of the screen.

I mean, seriously, there's gotta be a better way to do this. The following applications are just the basic things I need to be efficient:

• Windows XP Professional, drivers, settings
• Mozilla Firefox, extensions, profile import
• Thunderbird, profile import
• Maxthon
• Microsoft.NET 1.1 and 2.0
• Visual Studio 2003 and 2005
  • ReSharper (one version for each), import settings, resolve keyboard conflicts
  • GhostDoc (one version for each)
• Gaim, profile import
• FileZilla
• Latest JRE (java runtime environment)
• RssOwl, profile import
• Total Commander, plugins, customization
• 7-zip
• Microsoft Office, OpenOffice.org (Hebrew version)
• SourceGear Vault client
• CDBurnerXP Pro

And that's just to get me through the day. It doesn't include all the multimedia and development tidbits, like:

• QuickTime Alternative
• XviD/FFDShow
• VLC (VideoLAN Client)
• Free Download Manager
• XMPlay and associated plugins
• Ethereal and libpcap
• Cygwin
• Araxis Merge
• The Regulator
• The Gimp
• Stylus Studio

I reckon the net installation and customization time is over 10 hours (some installations can be done in parallel, some can be deferred to a later time). That is a lot of time to spend on just setting up your machine. The problem with using Ghost or some similar software is that I get a system without all of my current data (profiles, files, documents etc.), and as for virtual machines, they're simply not fast enough yet for constant use (at least on my modest home desktop or laptop).

... 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.