Best House Ever (.com)

I've settled into the Seattle area reasonably well, and even have a few blog articles in the works courtesy of time commuting on the bus. They're enough in-depth that they need a little bit more polishing though, and that's hard to do without sitting down at a desk - and when I've been at a desk, I've been working on BestHouseEver.com:


Being a geek I decided to see if I could make it a little easier to get our house noticed (Utah's got a saturated real-estate market), and to transmit that information by word of mouth. I was fortunate that an easy to remember, difficult to misspell, and catchy domain was available for exactly that purpose. Usually there is a unique domain per house these days for those which do actually get web sites, but they're derived from the address like "2073WindsorOak.com", which works OK on a flier or in email but not conversation where it would requiring writing down and later review. For purposes of compliance I picked up the address-as-domain too, and promptly pointed at the Best House Ever site.

I'll probably sell or rent the domain name to others after the place sells, or maybe even hang onto it in order to launch a company which does an extremely limited / premium service, maybe 1 house per-region with regions auto-selected based in geotargetting (but overridable through navigation to see other regions) for a pretty penny. For the moment I'm just hoping it brings enough attention to sell this house, which we're offering considerably under market (and drastically below tax assessment) just to unload it quickly so we as a family are not separated for too long. Selling it at this price shouldn't be hard - getting it noticed in the current market is the sticking point, so tell your friends, neighbors, co-workers, colleagues, associates, relatives, acquaintances, etc.

They won't even have to write it down.

Seattle Bound

Effective September 1st I'll be working as a Sr. Manager of Software Development for Amazon.com in Seattle, Washington.

This is a decision a while in the making, and a tremendous opportunity for the family - but not without sacrifice. There are many in Utah we'll miss deeply, and much extended family we'll be away from. Rather serendipitously, we do have some family ties in Washington, and having grown up near Seattle I do still have a network there we can plug into.

I'll have more updates as soon as I can, but the next 3 weeks are going to be packed getting ready for the move and prepping the house for sale. Oh, and for those unfamiliar, the above picture is of Mount Rainier, Washington's highest peak, as visible from the plane on my return flight from the Amazon interviews.

Chapter 1, Scene 2, of something I'll probably never finish.

So, after 13,000+ words of manuscript text and who knows how many in the outlines and various scene roughs, I'm pretty sure that the current novel attempt had contracted a terminal case of World Builder's disease. This happened a few months ago, when I realized that there was quality in the writing that editing could save, but that it would require a larger effort than I could dedicate to it within my time constraints. Instead, I lovingly laid the files aside and decided "That one's for practice... or at least for a time far away from here."

Which means I feel entirely safe sharing bits and pieces from the unfinished rough of the manuscript, because these are posthumous as it were. Continuing on, then...

---

Yuri's breath reflected a hollow kind of echo into his ears in the isolation suit, forming a rhythmic barrier between him and the howling of wind in the thin atmosphere only inches away. Small beads of sweat tickled down his cheeks and nose in defiance of the built-in sweatband. The rest of him was sure to be soaked as well, when he finally stripped down.

He finished muscling the new greenhouse frame into place and bounced easily back to the cargo hatch of the crawler. Two more trays of green-black slop waited for him there, typifying the infinite patience available only to dirt. With barely a grunt of effort he hauled them into place and swung the hinged transparent lid down to lock above them. Almost instantly the tiny spikes of hoar-frost that had sprung to life on the short journey between compartments evaporated from the lumps of muck and turned instead to a fog of condensation on the interior of the golden-hued crystal glass. Yuri nodded approvingly.

He reached into the control box and twisted valves for the hoses connecting this stand to its several hundred siblings, then touched a microphoned finger in his left glove against the junction. The short, high hiss ended abruptly with a melodic snort as air sloshed and rebounded between chambers. Satisfied, he mounted the slow six-wheel and began the forty-minute trip home.

"Honey, are you on your way back yet?" His wife's voice interrupted the labor-bestowed reverie, suddenly making it feel much shorter than the several hour respite he felt he deserved. He waited until his sigh was done and cleared his throat before activating the pickup to respond.

"Yes, darling, just finished. A little more than a half-hour out now."

"Everything go OK?"

"Mostly. There is still more dust on the roof than I like." The latest attempt to thwart the constantly shifting deposits of Martian soil had only succeeded in arranging the micro-drifts into interesting patterns. "And FIDO's charge seems to be a little short."

"Will you be able to make it home?" Her sudden concern sounded more needy than anxious for his safety. Or even his convenience.

"Yes, with several hundred kilometers to spare. There is no worry, it is just an annoyance. I'll bring it into the shop tomorrow and have a look." A few amps wouldn't make a difference one way or another, and it's entirely possible that the non-linear initial drop was in keeping with the power profile for the unit. Still, no sense in taking risks. And maybe he'd get the quiet he was looking for.

Lynette sounded disappointed after a moment's hesitation. "Alright. Just be careful. And let me know when you're getting close so I can start dinner."

"I will need to shower first."

"Come straight home then, but please hurry." She sounded fragile in his earpiece. "I love you."

"Love you too, darling." Yuri closed the channel and guided the large vehicle back across the worn and rocky path toward the outpost.

---

Some distance to the east, Lynette returned the radio handset to its dock and slumped deeper into her depression. As though mourning a lost world and family weren't enough, she now pined for a man somehow distant even when he was in the same room. Her sworn strength and lifeline.

She looked out a porthole window at the too-small evening sun; another day gone.

Persistence, Part II

A few more words and details about the Persistence of Vision hack previously mentioned. Pictured at left is a screen-shot of the application in operation. The astute observer will note that there's enough room for at least 3 more columns to the right of the one on display, and may even wonder why I didn't incorporate that space as well. Honest truth is I did - but the switching time (based on navigating the object model behind the scenes) was painfully slow when the additional 18 cells were added to the process, enough so that the entire effect was rendered defunct (the speed required for movement to match the manifest processor lag was slow enough as to nullify the PoV phenomenon). While it may be possible via native code (sans-framework) and/or enhanced algorithms to achieve a sufficient switching rate, the refresh rate of the screen still poses problems.

The photos of the demo operation in the original article testify of this. Looking closely, there are a few instances where one of the 5 columns composing the virtual letter is absent even in the interior (not on the edge of either the wave or the letter). This demonstrates the mismatch between target refresh rate and screen draw/refresh. Also in that picture my fingers were being held such as to cover the battery/status bar visible at the top of the screenshot (although imperfectly, as evidenced by the tracer in the demo photo). All this griping and analysis is fine for diagnosing the problem, but doesn't do anything to improve chances for success other than defining a starting point. So...

Solutions

• Full-screen draw available via native libraries (eliminates the battery/status bar)
• Improved drawing routines (faster object navigation via native libraries, bitwise AND comparison to minimize number of addressed cells per call, etc.)
• Automatic brightness control (demo was taken at half-brightness w/auto adjust turned on - sub-optimal test, and an error of omission on my part).
• Processor and/or screen overclocking (don't know if this one is possible yet) OR tapping into hardware accelerated GL routines for performance
• Not being so @#$& picky.

I'll state for the record here that I have satisfied my original curiosity in the exercise and do not anticipate investing the time to explore the above (or other) solutions. I'm willing to let this one die on the floor and move on to the next project(s) I have in mind, which may or may not eventually be disclosed here. Anybody interested in the source code to this point is welcome to contact me.

Persistence

Not too long ago I was fortunate enough to pick up an iPod Touch (bonus had come in from last year's work). The device has been remarkable, smaller than it looks and packing a nice little portable media punch. It also happens to be a fairly robust mobile computing platform, as evidenced by the strength of community development for the device even prior to the release of the official SDK. Being a developer myself, I was intrigued enough to give that part of it a shot.

Rather than put together an Intel hacintosh or risk the wrath of my wife by messing with her new Intel iMac (used for her wedding photography) as required to run the X Code IDE/SDK, I decided to use Jiggy's JavaScript based framework and IDE. While this surely introduces some functional limitations and performance overhead, it was also a very painless way to slap together a proof-of-concept to get a good idea of the problem space I was approaching.

Given that the device contains a set of accelerometers (used by the iPod/iPhone user interface to determine landscape and portrait layout), I thought it would lend itself well to a Persistence of Vision hack - which is to say, using a thin portion of the display, flash certain bits of it on and off as the device is shaken back and forth. The flashes correspond to certain spaces of the visual field during the swipe, and as a result of the mechanics of the human eye (which takes roughly 1/60 of a second to clear out the stimulus) appears to create many little spots floating in the air which can be used to write letters, display images, etc.

I first encountered the effect at a novelty store when I was about 9, when I saw a clock which consisted of a sturdy base and a spring-loaded wand which, when flicked, would flash it's LEDs as at waved back and forth and created the illusion of floating time. While several devices have picked up the gimmick since then, I've never actually bothered to own any of them. Now that the opportunity was right in front of me with a low barrier of entry, why not give it a shot?

First came the math. Working with my wife we were able to determine that a good hand-wave average was roughly 16", making a full cycle (back and forth) every 1/2 second or so (11 over 5 seconds). In order to achieve sufficient resolution to be able to display any letter of the alphabet discernibly, while still keeping the overall number of cells sufficiently low (so as to have low logical and processing requirements) we chunked this 16" section into 6 letters per wave, with each letter broken into 5x6 segments. 6 letters per wave is pretty low, but the idea was to have a word persist only through a single wave - as soon as the accelerometer detected a significant shift in direction it would load the next word, allowing sentences to be spelled out sequentially.

( 6 letters * 5 columns = 30 columns ) / 16" / 0.25 sec (single wave phase) = 120 columns / 1 second, or 120hz switching. In order for a line to pass through 1/2" of space during the course of a single wave, it would need to be on for only 0.008333... seconds. That's for a perfect line - I would of course be switching a region rather than a mathematical construct, so I would in theory need to divide that 120^th of a second by the width of the region in order to achieve the target resolution. I fudged this part, and for the sake of the proof-of-concept development decided to have the region correspond to the width of the column itself - 1/2" square, which means that if everything worked perfectly a total of 1" would be illuminated, a 1/2" of virtual overlap with itself (area of continual brightness) giving a linear fall-off to either side. So the letters would look a little fat and maybe just a touch blurry - but that's acceptable to start with.

However: most displays only refresh at a rate somewhere between 70-90hz. If I'm trying for 120hz it means that each cell would fall quickly out of sync, ending up only partially drawn or have some frames of display skipped altogether (compounded by the actual switching rate of the LCD). The second component of the problem is the brightness of the display itself - in order to sufficiently invoke that perceived persistence of stimulus, a certain intensity is required. If intensity is not available contrast may be substituted, but this means it will only ever work in a darkened environment.

Despite the math working against me I decided to give it a go. Setting the interior timer to 120hz is easy enough, but I suspect the time to navigate the DOM logic to the desired cells and switch their states runs slower than that anyway, plus whatever overhead the Jiggy framework required to assist in doing that. I set up the code to follow this plan, draw a column of cells and switch them over the course of fractional sections to the different mapped columns which comprised an entire letter table (in this case a letter is an array of 5 different numbers 0-63 which corresponds to a 6-bit binary display indicating which cells to turn on and off - makes for very tight book-keeping and rapid addressing, and binary logic is just fun anyway so why not?). My test consisted of letters A through E sequentially set up in memory in a per-wave array (all in a single wave) with events tacked to the accelerometer which would catch significant departures from one direction to the next and determine whether that array was being walked forward or backward, even capable of reversing mid-display.


And it almost worked. In the end I had to simplify the display to at most 2 letters, and it only works if 1) the room is dark and 2) one covers the persistent battery-level display at the top of the screen (otherwise it wrecks the PoV effect). Photographing this is especially difficult when one is both the photographer and demonstrator, compounded by doing it in a dark bathroom shot "through the mirror" without being able to effectively test the composition. In the end I got a few good shots and many not-so-good - shown here are 2 images (ISO 80 f/2.0 @ 1/25 sec, the display simplified to just the letter 'A') combined and slightly enhanced for contrast. This shows the difficulty of keeping in sync with the animation - something that with enough tuning of the accelerometer event code and a steadier hand would become easier, but which I don't plan to pursue due to the aforementioned global limitations. The predicted linear fall-off is visible, as are the very slight gaps between vertical blocks on the display.

Overall I'm very pleased with the exercise: it taught me more about a really fun toy, gave me a chance to play with some simple science, and allowed math to Save the Day. Everything worked almost perfectly the first time and I come out richer in knowledge for the effort. The fact that any of this at all pleases me just reinforces the fact that I'm in the right line of work - I'm pretty sure most of the world would find this pretty dull. Hurray for geeks!