High-Tech Humanities

A power band, long the instructors' mantra at DMW Martial Arts, meant delivering a strike with maximum torque relative to proper form and requisite rotation. I know I've overshot my personal power band when I deliver a strike in the midst of a form and my hand tremors. Or, when I throw a back kick against a bag and the force of the rotation results in a departed angle and the kick placement is inaccurate. I understood the sentiment in referring to the body's physical operating range as its power band. Recently, it took on a new level of meaning.

Somewhere past Methow, WA on SR 20, over the whine of a 2010 Shelby supercharger, and shifting in the power band, came the existential connection. One may speak about power bands with graphs, describe the magnificence of holding the reins to five-hundred and forty ponies, or signal their exit from the discourse with a fact or pith on why their martial art, vehicle, or programming language is better. In action, the instruction, facts, and pith yield to how well the person executes by their capabilities with the equipment at their disposal.

The joy we take in putting down the established to chase flecks of shiny metal, the arrogance we succumb to drive through our myopic views upon the collective, and the education and practice we afford ourselves, shape our power band, metaphysically and beyond. The act of passing a car in a nearly four-thousand pound Shelby from 1,200 RPM means the effort begins below the vehicle's power band. As the car crosses the center line and the pedal stomped, the intercooled V8 has to work up to its potential, which, if there is oncoming traffic, may be a bit late. At the moment when the driver expects the car to respond, there is no point in becoming frantic when it trots instead of bolts, but it may require one to pull back. Understanding the capabilities of the vehicle and beginning the same procedure from within the power band, and shifting within the power band during the operation, has entirely different results. This is true for athletes who understand the importance of training adequately for an event. And, this is true for software developers and architects when selecting software processes, patterns, and runtimes.

While working with enterprise application server software that included a number of third-party and quasi-open source tools, and in trying to architect solutions that followed prescribed technical guidelines, I found myself spending more time working around errors in the tools than developing or unit testing my own software. And, when it came to unit testing my software or ferreting out bugs in the enterprise solutions, I wondered aloud: Where is the unit testing for the Web content? There are many unit test frameworks available, but far fewer that operate within the page, and of those, I didn't find any that were generic, easy to instrument, or easily abstracted. Preferable, I wanted to be able to write a simple test function and run the test across the page, or attach the test to a node in an easily-removed fashion, all without relying on further discoverability via global ids or class names.

Without testing the view, each shift from actual work to digging through third-party toolkit and runtime errors narrowed the power band of my development stride. I knew what I wanted, but couldn't find an implementation that met my three criteria of generic, easy of instrumentation, and abstracted. What I did have was a framework with most of the pieces already in place: I had written a lightweight unit test extension to Hemi. All that was missing was a convenient way to bundle, run, and abstract the tests. The result was a set of additional templates and a method for embedding JSON-esque configuration into a CSS class name (for schema compliancy where custom attributes are not allowed).

The result was captured as a pair of tutorials: TDD and Unit Testing.

One caveat to the architecture of large initatives is the process of selecting and standardizing on software and libraries may not fully include a full review of the ramifications of those choices. In my example with in-page unit testing, that worked because I had a specific set of problems I wanted to solve. Although myriad problems remain, in this one area I could influence, I identified the range of my development power band: The optimal power range of capability torqued by the technology.

Somewhere on SR 2, on the south side of the Cascade Loop, it started to rain. Pulling aside the Shelby to raise the top, idling around 1000 RPM, and expecting traffic to back up in Sultan, WA, I knew, at that moment, I was outside of the power band. And, given the circumstances, that was okay.

I bought an unlocked Google Nexus One. Two weeks later, I was shocked by the headphones. Herein is that story.

I wanted an iPhone. I bought a Nexus One. At the end of the day I wanted to be able to load the SDK and the iPhone SDK requires a MAC, which I don't have. The next closest competitor was the Nexus One. Until this point, my last experience with a phone that wasn't challenged (aka: not a smart phone) was my foray into medical software for smart phones in 2004.

I like the Nexus One; Didn't care for being shocked. At first, the battery life seemed abysmal even after following the performance guidelines of shutting off unused items (vibrate, lower backlight, disable GPS, bluetooth, and WiFi when not in use) but, around the time of the early February update, it's been much better.

The user interface has been hit or miss. It's very nice and sporty, with a few random gotchas. In conference calls, where I'm tapping the mute-button quite a bit, the UI transposes the finger-tap to other parts of the screen and I wind up sending numeric tones to the attendees.

On one such call, I switched from speaker to the included headphones. After some minutes, I stood up and the earbuds delivered a mild shock. A quick search turned up a similar issue with iPhones.

Over all, in the first few weeks, I've enjoyed the new phone and hope to be able to spend some time mucking about with the SDK.

The Hemi Framework project page was updated to include the Hemi_3.0.2.zip and Hemi_3.0.2_build.zip distributions, as well as a little more content.

The examples section still needs to be fleshed out. Rather than use static examples, I'm thinking of using the included unit-tests to drive the examples, and fixing up the Framework Designer for better anonymous use. The Framework Designer includes builders, with example implementations, for DWAC projects, tasks, components, fragments, templates, a runtime container, and pseudo-debug linkage to the Framework Profiler. I like the experience of opening one of the in-page editors and, for example, making a new task-list with selectable feature examples, and then being able to run it right there on the page, than making static examples of various combinations.

I also think the Framework Designer and Distributed Web Application Components (DWAC) features fit very well with Net Books and OS's like Chromium because authenticated and authorized users can create new Hemi facets (components, templates, fragments, tasks), projects, or deployments in the browser. These features would also work well in environments where Web pages with multiple client-side frameworks, and their corresponding widgets and tools, could be instrumented, updated, and deployed in-page and on-demand while being compliant to security policies and, if desired, released by a workflow.