535 Design

We're moving

2007-12-11T21:56:00.001-08:00

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

2007-12-09T10:10:00.000-08:00

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?

2007-12-07T20:25:00.000-08:00

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

2007-12-06T19:54:00.000-08:00

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

2007-12-05T20:10:00.000-08:00

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.

An Obvious Distraction

2007-12-04T18:46:00.000-08:00

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

2007-12-03T20:22:00.000-08:00

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

2007-12-02T19:08:00.000-08:00

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.

Conditional Comments Considered Helpful

2007-12-01T18:39:00.000-08:00

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:

conditional comments impede separation of content and presentation
conditional comments are not standards-compliant
XSLT doesn't "play well" with conditional comments
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.

Blogger Enhanced Post Editor

2007-11-30T17:09:00.000-08:00

Bet you guys thought I forgot to post today, didn't you? C'mon, admit it. Tsk, tsk, no faith in me at all.

In fact, I'm posting this so late because I've spent all day putting together a Greasemonkey script to fiddle with the Blogger post editor. You can see the result on Userscripts.org.

And to give you an idea what it looks like…

Encoding "data" URLs

2007-11-29T09:40:00.000-08:00

"data" URLs can sometimes be useful for embedding small pieces of data when hosting a file is impossible or undesirable.

Two types of encoding are supported by data URLs — standard URL-escaped encoding and base64 encoding. (The result of the latter is technically URL-escaped as well, but none of the 65 symbols used actually require escaping.) Which encoding produces a shorter URL depends on what percentage of the characters it contains must be escaped in URLs. URL escaping triples the size of escaped characters (a percent sign followed by two hexadecimal digits) but leaves non-escaped characters intact, whereas base64 increases the size of all characters by ~33%.

This means that base64 is more efficient whenever the number of escape-requiring characters exceeds ~17% of the document's size:

3x + (1 - x) > 4/3
      2x + 1 > 4/3
      6x + 3 > 4
          6x > 1
           x > 1/6 = 16.6%

Stupid Firefox tricks: Safari-style stop/reload button

2007-11-28T15:43:00.000-08:00

Yup, still on my userChrome.css kick. This time, it's a way to make Firefox look like it has a Safari-style stop/reload button. First, arrange your toolbar so that your Reload button immediately follows the Stop button:

Then, add the following code to your userChrome.css… when you restart your browser, the Stop button will only be visible when it is enabled and the Reload button will only be visible when Stop isn't.

/* safari-style stop/reload button */
#stop-button[disabled="true"] {
 display: none;
}

#stop-button:not([disabled="true"]) + #reload-button {
 display: none;
}

Quote: Irrelevance is no excuse for ambiguity

2007-11-27T11:46:00.000-08:00

Imagine you're giving someone driving directions to a house which is on a street which makes a loop. When the driver approaches the street, it doesn't matter which way they turn — either direction will get them to their destination, so you could simply omit it and skip straight to the street number. However, the poor driver is still going to be confused… unless you provide a direction or explicitly tell them that it doesn't matter, they won't know whether it's (A) irrelevant, (B) unintentionally omitted, (C) the result of incorrect instructions, …

Instead, the person providing the instructions should either provide a direction or make it clear that both are acceptable. Irrelevance is no excuse for ambiguity.

Stupid Firefox tricks: colored tabs

2007-11-26T10:31:00.002-08:00

When I switched from using PermaTabs to Tab Mix Plus for protected tabs, I missed PermaTabs' coloring them. Fortunately, this can be easily accomplished for Tab Mix Plus via userChrome.css — just add the following rules (and, of course, change the colors to taste).

/* yellow for locked tabs */
tab[locked=true] > * {
    background-color: #F2F2A9 !important;
}

/* green for protected tabs */
tab[protected=true] > * {
    background-color: #A9F2A9 !important;
}

/* blue for frozen tabs */
tab[locked=true][protected=true] > * {
    background-color: #A9F2F2 !important;
}

Tab colors can also be triggered off a web site's <title> by using the tab's label= attribute. The following uses the CSS3 [attr^=startswith] selector to provide a simple Gmail notifier — if I leave Gmail on my Inbox, the tab turns red when new mail arrives.

/* Gmail new message flagging */
tab[label^="Gmail - Inbox"]:not([label^="Gmail - Inbox -"]) > * {
    background-color: #F2A9A9 !important;
}

Intro

2007-11-25T11:47:00.000-08:00

This blog is an introspective record of odd things I think about and tangents I venture upon while working, mostly while writing code. I'll be trying to make at least one post a day (just to keep in habit).

stupid tricks: When a tool doesn't do exactly what I want it to, I'm prone to spending unreasonable amounts of time trying to "fix" it. If I'm successful, I call the result a "stupid trick". I don't necessarily research the problem exhaustively before beginning, so I don't guarantee these tricks to be unique or even the best approach. All I can really say is that I came up with them myself.
quotes: These are the unfortunate results of my attempts to phrase things cleverly. Some may have value, but most are simply the product of my ability to be easily amused.