We're moving

Sorry about all the excuses and missed posts. I'm officially putting this blog on hold for the next few days while I bring our new domain on line. After the hiatus, the blog will continue there.

A good excuse

Sorry about the missed post yesterday. It's a little depressing that I didn't make it two weeks without missing a post, but at least I have a good excuse. You see, my girlfriend and I broke my bed (again) yesterday and clearing the pieces out of my room took quite a long time. It's a king-size futon bed, which means the mattress is a pain to move (takes three people) and too big to leave in the room while we disassembled the bed (which itself isn't a quick process). In the end, we had something we could sleep on (a futon on the floor, but still) but it took hours to get to that point.

Hosted, colo, or home server?

It's high time that I got my own domain name, but I'm having trouble deciding what kind of service it should call home. I'd always vaguely planned on having a home web server, but if I want to use it for anything serious (and I do), I'd need to start worrying about saturating my upstream bandwidth. We're already running into the occasional problem when both my roommate and I are both torrenting and playing WoW.

The first logical alternative is hosting. I have a couple of friends (including my SO) who have sites over at Dreamhost and I've been pretty impressed with them so far. They offer a decent amount of space and bandwidth without charging an arm and a leg, they offer a full LAMP environment, and — for the near-obsessive, like me — it's even possible to roll and use a custom PHP build. I'm still iffy, though. It wouldn't be a stretch to call me "territorial" when it comes to my technology and the idea of hosting my website on someone else's computer makes me a little leery.

The logical compromise, then, would seem to be colo, right? I'm within biking distance of HE's Fremont 1 center and I doubt I'd have any trouble finding a secondhand rackmount. The big problem with colo is the cost. I could run a home server for no additional cost beyond the electricity, and $10/mo or less for hosting is easy to find. Colo, on the other hand, is usually in the $50/mo and up range, in my experience, and that's simply more than I want to pay for what's essentially going to be a personal playground.

So I'm not quite happy with any of the three solutions I currently have on the table and I'm worried that if I choose poorly and regret the decision later that it's going to be a major fight to get my domain transfered elsewhere. Bleh. I should probably just host and have done with it… If nothing else, I think being forced to keep hosting after changing my mind would piss me off less than being forced to keep using a home server or colo.

That something is impossible does not make it wrong

The original formulation of this quote was "never redefine your processor's bit-depth on the fly". In my misspent youth, I once encountered a maddening bug in the code I was working on. It kept performing 16-bit arithmetic on 32-bit numbers. I'd double- and triple-checked everything I could think of. It was a 32-bit processor, I was using a 32-bit compiler with 32-bit integers, and it kept chopping them off! I eventually began stepping through the code in a debugger.

Partway though the program, I realized that the memory address representing the mode to use was, indeed, set for 16-bit math. Thinking I was on to something (I wasn't, as it turned out), I began digging into documentation and compiler options for how to change it, but nothing worked. Finally, in frustration, I used the debugger's memory editor to change the mode to 32-bit while the code was running!

Needless to say, things did not progress well from that point. I can well imagine the pins spinning off into darkened corners, cogs cracking from the strain, and billowing columns of smoke reaching up to the sky in my poor workstation's inner clockwork as it tried to interpret the 16-bit pointer table as a series of overlapping 32-bit pointers. Fortunately, I had the pretense of mind to shut the whole thing down before something triggered a disk write and started doing serious damage.

The lesson that I took away from this was that impossibility does not necessarily represent error. In this case, the mode was turned down to 16-bit as a form of sandboxing (to reduce the amount of addressable memory) and was not affecting arithmetic at all. Instead, I had accidentally redefined the keyword for 32-bit integers to point to the 16-bit integer type. I wish I could say this lesson had proved more valuable, however… I still find myself butting heads with the "impossible" distressingly often. At least I haven't recently made any response as dramatic as redefining my processor's bit-depth on the fly…

I, borg

I recently got my first iPod (yes, I'm several years behind the curve, but that's a long and unrelated story) and have taken to it like a fish to water. It's amazing how much of a difference having music playing 80+% of my waking hours has made to my stress levels.

It took me a while to find the right headphones. I don't really like the sound of earbuds and "word on the street" (i.e. unsubstantiated rumor from my friends) has it that buds are more likely than most headphones to damage hearing, even at lower volumes. Because I wanted to listen to music while riding my bike, I couldn't use over-the-head or even behind-the-head earphones; what I really wanted was some kind of supra-aural headphone which clipped to my ears. It was with some chagrin that, a couple hours of frustrated searching later, I learned that many manufacturers call these "earclips" (moral of the story: always try the simplest solution first). Nevertheless, I found a likely-looking pair on Amazon and put in an order.

I don't regret buying them — they're as close to the perfect headphones for me as exist on the market — but they're still the weakest link in the chain. The cord tangles and tugs, even under my shirt; the hooks interfere with my glasses and bite into my ears; the one I usually keep hooked to my shirt (one ear on music, on the world) has started to seriously distend the necks of some of my tees. The more I thought about it, the more I came to realize that I didn't want headphones, not even perfect ones. What I really want is a datajack in my head which pumps external audio (be it music, phone calls, or TV) directly into my ears.

It seems to me that ears are a natural starting point for learning to "mod" the human body. Neural interface — especially sensory interface — is going to play a large part in any future attempts we make to make electronics more "personal". As with anything new, it's best to start small and it seems (to this complete layman) that the signals generated by one's sense of hearing are relatively simple compared to other senses. It's my understanding that sound is carried from the ears to the brain in parallel as channels representing amplitude over time for all the sound ranges to which the ear is sensitive. While that's certainly more complex than how sound is typically represented digitally, it sounds likely to be less complex than the signals used for sight and less total data than touch. What's more, I see it as a "safer gamble". If I'm going to risk damaging or losing one of my senses in the pursuit of science, I'd rather risk hearing in one ear than sight in one eye!

It's unsurprising, then, that some work has already been done in this area, at least correctively. Cochlear implants are already being used to restore partial hearing in the deaf. These implants involve direct electrical stimulation of the auditory nerve at points corresponding to various frequency ranges. Despite the relative simplicity of the technology (the "business end" is nothing more than a string of electrodes on the cochlea), these implants already can restore sufficient hearing for the user to interpret speech! To me, that's simply astounding. It looks like the major limiting factor, from a technical standpoint, is the size and insertion of the electrodes. Whereas the human ear can distinguish thousands of frequencies, even the most advanced implant available has only 22 electrodes. Smaller electrodes would undoubtedly improve the quality of sound, but could quickly become impossibly small to implant surgically.

I sometimes wonder whether humanity's future lies in augmentation (non-corrective gene therapy, non-prosthetic cybernetics) or some kind of human essentialism (shunning augmentation as dehumanizing). I tend to lean towards the former, and I sometimes find myself looking eagerly towards this kind of "techno-prosthetic" in hopes of catching glimpses of the future.

Related Links

• Cochlear implants on Wikipedia

An Obvious Distraction

Crap. I spent all day working on my Blogger post editor and now I can't think of anything to post in my blog. Ironic, much? I need to start doing this earlier in the day.

Um… distractionary exoskeleton?

Ye Olde Assemblie Shoppe

I sometimes miss programming in assembly. Perhaps that sounds strange, but things were so much more concrete back then. You didn't worry about code profiling or variable types; you just counted clocks and used the data however you saw fit. And the flexibility was amazing — nothing I've since encountered quite compares to a program which rewrites its own jumps.

Of course, the flaws were equally impressive. Infinite loops, stack over-/underruns, and the dreaded Jump to Who-Knows-Where were sure to ruin your day — and your data — if you weren't careful about backups. This is especially true when coding for devices without any permanent storage. I remember the time in college when, bored between classes, I decided to test out a new input routine I was working on. One JMP into video memory later, I found myself having to assemble the instructions into machine code by hand (as it lacked an assembler in the ROM) and reenter the entire program manually (as I'd neglected to bring my serial cable).

Heh, good times. Good stories.

I've left that all behind me now. I live in a world of interpreted languages and exception handling, of versioning code repositories and package managers…. But I still wax nostalgic sometimes. I sometimes look at these languages throwing around "compiles to bytecode" and wonder if there's something there for an Assembler Refugee like myself.

Python data: URL script

Okay, I'll admit it's a bit of a cop out, but I didn't want to skip today entirely. This is a boringly simple little Python script I wrote to create data: URLs directly within my text editor. Select the text, run the script, presto. It has command line options for encoding style, mime type, input file, and output file, but defaults to guessing at the first two and using stdin/-out for the latter.

Related Links

• data-url.py

Conditional Comments Considered Helpful

Wandering around the interblag lately, I've come across a number of "conditional comments considered harmful"-type posts. I'll not name names, as some of them are from developers I quite respect… and I'd rather respond to the general arguments than take aim at an individual.

There are four major arguments I've seen:

1. conditional comments impede separation of content and presentation
2. conditional comments are not standards-compliant
3. XSLT doesn't "play well" with conditional comments
4. CSS hacks are superior to conditional comments because they do not suffer from the above problems

I find the first argument to be by far the most compelling — there's no denying the fact that the use of conditional comments adds non-content markup to a document, even when only used to reference external stylesheets. However, this seems to me more of an anthill-scale problem than a mountain-scale one. Outside of lab conditions, non-content markup is simply a fact of life. Onion skins, container <div>s, zebra striped tables, and other techniques ensure that few web sites achieve perfect separation between content and presentation. The reason for this is simple — HTML is not a pure content language. Trying to treat it like one is sure to painful and unfulfilling; better to use XSLT to transform pure content markup into HTML, adding conditional comments and other presentation markup as it goes.

Moving on to the second point, standards compliance. I feel it's a little disingenuous to call conditional comments a violation of standards. It's the browsers which recognize them which are non-standard (violating the instructions that comments "have no special meaning" and should be "ignored by the parser"). The contents of comments, however, are intentionally unspecified in standards… and considerable value has been found in placing data outside the scope of standards in comments. Javadoc and Subversion keywords, to name some popular examples. Plus, the nonconforming browsers in question are used by fifty to eighty percent of users (depending on who you ask). Steadfastly refusing to make concessions to their irregularities, while perhaps laudable in principle, risks alienating a large chunk of your potential visitors.

Now, XSLT. This one is surprising, as I've never had problems with it, myself. Here's the applicable snippet from a site I recently created for a friend:

<xsl:comment><![CDATA[[if IE 6]> <link rel="stylesheet" type="text/css" media="screen,print" href="style/default/style-ie6.css"/> <![endif]]]></xsl:comment> <xsl:comment><![CDATA[[if IE 7]> <link rel="stylesheet" type="text/css" media="screen,print" href="style/default/style-ie7.css"/> <![endif]]]></xsl:comment>

Which finally brings us to conditional comments vs. CSS hacks. Again, I feel this is fairly clear: CSS hacks exploit unintended behavior. Conditional comments, on the other hand, are intentional. I'd much rather hitch the usability of my site to a misfeature than a bug — the misfeature is likely to be more predicable and have better longevity.

In the end, sure… we'd all like to write beautiful, standards-compliant code and have it Just Work in all browsers, but that simply isn't the world in which we live right now. In the future, perhaps, we'll be able to do without but for the time being, I'd call conditional comments by far the lesser evil.