Marshmallow Bow & Mallow - because food fights are serious business

A holiday gift for all ages. :-)

Marshmallow Bow and Mallow

Cue Hard Driving Rock Beat

A video article from CNET, Skywalker Sound secrets, got me wondering.

What would happen if I added a jamming sound track to the presentation at my next architecture pitch session?

It might even save me the need to stand up there and talk about it. Just cue the slides and let the music do the rest.

I'm oh so tempted.

/me adds a can of wet dog food to the grocery list

Blogging2.0-beta

I think I've struck upon a solution for the perennial problem of creating fresh new blog content.

I call it blogging2.0.

It will leverage2.0 the latest trend2.0 by respinning2.0 everything2.0 as fresh2.0 and modern2.0. Everything2.0 I write2.0 will, by definition2.0, be new2.0. No longer will I2.0 need2.0 to be worried2.0 about use2.0 of the term2.0 2.02.0.

What happens2.0 when everyone2.0 starts to mimic2.0 me2.0?

Not to worry3.0. I'll simply change3.0 to keep up with the times3.0.

I'm sure there are a few kinks to work out. Perhaps I should call it blogging2.0-beta.

Cheers2.0,
AloofSchipperke2.0-beta

Fog2.0

It's been an odd day. I woke up feeling nauseous but pressed on. Cracking open the car windows on the way to work seemed to help. Fresh Oregon air seems curative.

Getting to work, a co-worker and I walked over to Starbucks for a fresh cup of coffee, one of the universal remedies. It didn't help. After sending out a few email messages I went home for the day.

Upon arriving home, my wife fixed me a bagel and a 7-up. I finished those and went to bed. I fell sound asleep, waking up in the late afternoon.

Still disoriented from the mid-day sleep, I decided to read some blogs and formulate my daily post. My brain was still in a fog. My queasy stomach soured my frame of mind.

Nothing in my feed reader grabbed my attention. I was contemplating skipping the daily blog post.

Besides, it's not like there are legions of readers waiting for my next earth shattering declaration. Why am I even worrying about writing on a regular basis.

My funky day was starting to get the better of me.

Then I noticed an article.

In The hardships of being a nobody 2.0, Seth Eagelfield reminds us that A-list status is relative. It's not the numbers that matter, it's the fact that we select what we read and others select to read our work. It's all good.

If you like writing, Seth's blog provides a nice dose of micro-prose on a regular basis. It's good for what ails you.

And yes, I too couldn't resist tacking on the 2.0 doodad. Seth apologizes for his use of the suffix. Not me. I'm contemplating an all 2.0 blog posting. News at 11.

and now I'm going back to bed, hoping to wake up tomorrow ready to get back on track

Scalability is NOT an Optimization

In Is premature scalation a real disease?, Todd Huff points to an article from Dharmesh Shah, Startups and the Problem of Premature Scalaculation.

The heart of the conversation is a question regarding how much attention should be paid to scalability when in the early stages of a startup. Dharmesh suggests not worrying about scalability too early. Todd reminds us that scaling is no longer the exotic knowledge of yesteryear and that the travesty of focusing purported precious resources on scaling is an overstatement.

To be fair, Dharmesh is not proposing that problems of scaling be ignored. Rather, he's recommending people avoid prematurely optimizing for scale too early in the process.

It is indeed a delicate balance, as are all interesting problems in architecture and design. Besides, we've all grown up with the warning to avoid premature optimization. It's been hammered into our brains.

Here's my problem.

It's a fundamental mistake to frame scalability as an optimization problem.

Scalability fall into the non-functional requirements bucket. It keeps company with a shady cast of characters - security, maintainability, usability, and all the other *ilities.

The primary challenge with non-functional requirements is they tend to pose the risk of significant rework if not taken into account early in the architectural and design phases of a projects. This is where the real skill comes in. If you're in a waterfall mode, you can hope you do an effective job eliciting an accurate picture of the non-functional requirements. If you're in an agile mode, you can hope you do an effective job refactoring the code as you evolve the idea. In both cases, the primary goal is to avoid the decision of whether to implement dramatic amounts of rework or whether to scuttle the ship.

If a particular operation needs to complete in less than 3 seconds and the initial implementation takes 30 seconds, this is not a problem of optimization - something is flawed. To be sure, you might be able to rationalize that future improvements will shave it down to 3 seconds, but most audience members would suspect breakage rather than a lack of optimization.

If a web service is targeted for a million users, the basic framework must be capable of evolving from the initial user base of two. The design is fundamentally lacking if one cannot provide a rational roadmap between these two numbers.

Optimization seldom crops up as a non-functional requirement, except in cases where initial performance is disappointing. The same cannot be said for scalability.

Ok, here's one more way to illustrate the point.

Fail to factor security into a design. Go ahead, I dare you.
Fail to factor maintainability into a design. You'll sell it before it becomes a real problem, right?
Fail to factor usability into the design. Hmmm... will that affect your user base?
Fail to factor scalability into the de...........

On the other hand, ignore scaling. It makes for minutes of entertainment on slashdot.

Building a builder for tiny lamps

In How much of an OS distro is necessary for a Pile of Lamps, I described my basic environment for exploring ideas related to Pile of Lamps.

I've tweaked the workbench a bit, so I'm now at version 0.6. The primary difference is the addition of a dedicated build server. My laptop, while sufficiently beefy, is somewhat prone to thermal problems. The burden of lengthy compile cycles was too much, so I cobbled up a dedicated server for compiles. As an added benefit, I can continue compiling while the laptop is suspended.

The build server is running the T2 distro. The more I use T2, the more I like it. Thus far, I've only encountered one problem. The installation of perl in 7.0-rc2 appears to be missing quite a bit of /usr/lib/perl5. A forced rebuild of perl rectified the problem.

Ok, so here's the current plan of attack.

I'm initially building the default distro defined by the generic T2 recipes. This is primarily to familiarize myself with T2 and to make sure the entire tool chain works.

I was hoping to have the generic build done this weekend, but the build server took priority. The generic build is compiling as I write this blog article.

Once I have a working generic T2 target, I'll shift my attention to the creation of a new target definition. While my end goal is to create a clean recipe for the desired distro, I might need to toy around with whittling down an existing recipe until I get a handle on the T2 build environment.

Until next time...

Buglabs no longer in wood mode

I posted an link to buglabs back in September. Meanwhile, it looks like they're making progress.

They've posted some product images.

Robert Scoble posted a series of video interviews to his blog.
BugLabs.net’s really cool reconfigurable gadget in depth

This is insanely cool!