geek!daily

Wiimote Makes Your Screen A Canvas

Johnny Chung Lee of Carnegie Mellon University decided that the infrared camera inside the Wiimote could be put to interesting uses ... and he's right. This is some of the coolest stuff I've seen for a while. If some company out there doesn't build a $50 kit that converts your monitor to a poor man's Cintiq they're missing a really good opportunity.

You might also recall one of his earlier efforts, the $14 DIY Steadicam bracket featured in Make Magazine #1. I'm starting to be a serious fan of his. =]

OLPC: You Know, For Kids ... Theirs *and* Yours.

I just tripped over this video:

... which leads to the OLPC Laptop Giving website. The gist of it is that for $400 you can get an XO laptop for your kids ... and give one to kids who'll use it to change the world.

I think Sam's going to have a very happy holiday.

Cosco Busan, SF Bay, and Kurt Schwehr

Sometimes I'm dense. I've been reading Kurt Schwehr's excellent electronic work log (wlog? ;) for months and didn't even think to share it in the wake of the Cosco Busan allision (a term I wouldn't have known with Kurt's help =). If you're a geek, you should just read his whole blog as it's rich in very cool stuff you don't see every day ... but if not, here's his postings to date regarding the whole affair:

• SF Bay Bridge Allision
• An Allision Seen Through AIS
• Cosco Busan Oil Spill
• Spill Update
• Cosco Busan Links
• Google Earth - SF Oil Spill

Alameda's beaches haven't been hit hard (surprising, really) but there's a lot of cleanup still to be done. Grrr.

DSLs Are Our Future

I have to admit that I've been puzzled about the rise of domain-specific languages (DSLs) of late. Not resistant, just curious whether or not it was a fad due to geekish interest or a trend motivated by some unseen force at work. Joel Spolsky's Strategy Letter VI made it click by relating it to a pattern I'd lived through (and yes, I'm that old):

The C programming language was invented with the explicit goal of making it easy to port applications from one instruction set to another. And it did a fine job, but wasn’t really 100% portable, so we got Java, which was even more portable than C. Mmmhmm.

Right now the big hole in the portability story is — tada! — client-side JavaScript, and especially the DOM in web browsers. [...]

What’s going to happen? The winners are going to do what worked at Bell Labs in 1978: build a programming language, like C, that’s portable and efficient. It should compile down to “native” code (native code being JavaScript and DOMs) with different backends for different target platforms, where the compiler writers obsess about performance so you don’t have to. [...]

If you don't read Joel on Software, you should.

More cool tech from SIGGRAPH

A full 360° display using synced projection onto a rapidly spinning mirror:

Seems practical for small displays. I'll be curious to see if anyone commercializes this; seems like it has obvious medical imaging applications as well as biotech/nanotech.

The Difficulty of Non-Technical Users

Two things struck me about Kurt's post:

1. It's an incredible pleasure to watch a domain expert at work.
2. Every technologist has to deal with the dilemma of non-technical technology users.

Every technologist should have a measure of their market's median technical ability and target it carefully. And I'd have to say that differently if both of my readers weren't technical.

Link: Kurt's Weblog: External Sensors to Verify AIS Ship Data.

CoRaid ATA-over-Ethernet

Nice tight mini-SANs. This plus GFS is pretty sweet.

Link: Coraid :: The Linux Storage People.

Three Observations on Reverse Engineering

I'm working on the tech slides for our presentation deck today. The purpose is to demonstrate that not only do we have something (and we do =), but that it's easier to buy us than to rebuild us. This got me thinking about what influences how easy or hard it is to reverse engineer a thing. Here's what struck me as true.

1. It's straightforward to reverse engineer an existing product feature. The cost of doing so varies in direct proportion to the opacity and complexity of the feature.

2. It's more difficult to reverse engineer existing workflow as embodied in code (e.g. a pipeline) as it requires knowledge of the pipeline's foundations as well as an understanding of the nuances of its implementation. Lacking the nuances, you'll repeat the mistakes of others; lacking the foundations, you'll go horribly astray. The cost of doing so varies in direct proportion to your knowledge of the process, its basis and nuances, and your experience in working with it and its variations.

3. Most difficult is to reverse engineer strategy, which can be considered as the implicit fundamental knowledge and intent in which a product's features and workflow are grounded. The cost of doing this varies in direct proportion to your insight into the mind(s) formulating and executing that strategy.

You are not your product. You are not your workflow. You are your ideas.

Not Living In A Cave ...

... just refuse to post about the tech of the moment.

You know the one.

From Apple.

Yeah, that.

Not gonna give it more press. It's got enough.

But I desperately want one. =]

The Circle of (typographic) Life

I find it amusing that, in the early-to-mid-eighties we put a lot of typesetters out of work as desktop publishing eliminated the need to memorize cryptic typographic encodings.

http://hobix.com/textile/

We've come full circle.