Keyboard Diarrhea

Funny, but in my head, all my posts are short. In real life, not so much.

Time-wise, its all about the same - the only posts that take more time than the average e-mail (or two, maybe) are the coding-type posts, which are few and far between. Verbosity has never been one of my personal challenges :)

Still, I'd rather be concise - "Brevity is the soul of wit", and all that. There's some positive reinforcement that you'd think would help me: my smaller articles and posts tend to generate more comments and discussion - seems to be less interest in my more wind-bag-y dissertations.

On balance, that's probably because (a) the smaller posts get read more - "economy of motion" in action, and (b) they get misunderstood more - that is, people read what they want into them, which always makes for good fun. Or it could be because (c) my "insights" are, well, a bore :)

And that's all I have to say about that.

Really :)

Almost.

(Except to mention that this post title is not SEO friendly :P)

Best. Product. Name. Ever.

Updated: My bad. Amapi is till kicking (and NOT to be confused with this :))

I was looking for a 3D appplication to play with some things, and noticed that (it appears) Amapi 3D is no longer on the market.

Amapi was a Mac 3D modeler (from back in the day), with a killer innovative "workbench" UI and a gestural interface. It was a enjoyable, useful product, but got squeezed quite a bit (along with a lot of other rich authoring tools) as people moved from productive to consumptive behaviours with the explosion of the Internet (not to mention the time-coincident shift from Mac to Windows - a move from which many Mac products never recovered).

Amapi survived though, moving through various acquisitions and continuing to improve and innovate through the years- its a little sad to no longer be able to find it.

But as good as the product was (and I loved it), the best part was the name. It was (originally) developed and marketed by a French company called Yonowat.

Get it?

Yonowat? Amapi.
(or, in English: You know what? I'm happy)...

It's the little things, you know :)

December WPF/E CTP: First Impressions

Updated: Some more details about WPFE and texture sampling issues.

So.... not bad.

I've been playing with the Microsoft WPF/E CTP a little over the last week-ish (its a slow time of year), and I thought I'd post some early thoughts. These are mostly a ramble - no particular point that I'm making, and it might not be entirely coherent.

Rendering
Appears to be a pure software rendering pipe (that is, there appears to be no Hardware acceleration in this CTP). Good antialiasing quality - appears to 4X oversampled in the y-direction and analytical in the X. As with GDI plus, I think they botched the texture sampling rules. Its a little better than GDI plus was, but still wrong (IMHO) for resolution independent UI - which of course, is a big part of the goal. Macromedia got this right (at least, starting with Flash 8). Although its a software rendering pipeline, it also looks like WPE/E employs a front-to-back display (or some form of overdraw prevention, at least), and performance is pretty decent - though I haven't stress tested complex shapes or the like yet (Updated: I tried, and failed, to load the simplest benchmark - must be a point limit, though I couldn't find any documentation/info on that).

And no 3D support.

Interactivity
No controls (buttons, menus, text edits, etc.) are present in this CTP - you get events, and you get shapes and images (textures), so... hard to say much about this yet. Startup time for the WPF/E plug-in appears good - the header of theWPFblog (appropriately) is WPF/E, for example, and loads nicely/quickly - WAAAAAY better than .NET 3.0/XBAP (e.g. try this sample).

Still, I think the packaging streaming model, although goofy in Flash, makes it much easier for developers to explicitly control and manage assets loading. It will be interesting to see how important this becomes in the real world for building larger scale applications - I think Microsoft is at major experience deficit in this one key area.

Animation is a bit odd still, and the property/element "." syntax rules still throw me a bit...

Samples/SDK
Documentation and SDK - really nice.
Samples? Laaaaaame.
Pretty much most of them could have been built trivially in Flash, or even DHTML. Even the Page-turn example is mostly about clever content (for example, the shading is a part of the ARTWORK). Not one example shows the expressiveness potential of the runtime. Most of these HTML samples are more inspirational. I realize this is just the first CTP - but *ONE* killer sample would have been nice.

Overall
The language is nice and expressive - its pretty easy to get started and build "rich" interactive content. If you're starting from scratch, much easier than Flash, Flex, or DHTML even. The browser integration and support for multiple platform (browser and OS) right out of the gate is a good move. CLR integration (and the release of the mini-CLR) is the big "FUD" thing we're all waiting for, I think. The code-behind model really leverages the excellent "first class" host DOM integration. Plug-in size and updating may be an issue, but its early enough that I'll reserve judgment on that. Currently, the IE control is 1.1 MB - the other variants (browser and OS) are quite a bit bigger.

All in all... a decent first CTP - looking forward to more... and some clearing up of the massive general confusion about how WPF, .NET 3.0, XBAP and WPF/E are supposed to fit. Everything I've seen so far seems to be after-the-fact rationalizing of internal competition and overlap.

Math is your friend

This made me smile:
*
Isn't that what friends do? :)
(of course, this made milk come out my nose... but to each his own :))

*from xkcd under CC license.

Epilogue: AOL Layoffs, 2006 Edition

So... I didn't think I'd be posting about AOL anymore (buh-bye). But today was my last official act (I think): laying off more than a few people as the Company restructures around the Web (and advertising). It was a fairly crappy way to spend a day, but I was asked to help; and I guess I'd rather folks that work(ed) for me hear it from me as opposed to some person they don't know - even if I am done there.

Its a tough thing, but it is a [media] business... and costs have to trail revenues :/ - though knowing that doesn't make the human component any more palatable, and I do feel AOL tried to make it as right as possible, all things considered.

I was also sent this today (I don't know who the original source was - I got it from someone no longer at AOL) ... It's in clearly poor taste (but still funny) - some employee's reaction (that last one had me in stitches) - in the category of gallows humour, I suppose.

Java 6 and Scripting

Sun released Java 6 yesterday. Of particular interest (to me at least) is the explicit direct support for scripting languages as a "core" part of Java (more or less - of the Java 6 edition "package" at least...).

Though I intuitively understand it (and believe it), I've still yet to see a reasoned justification as to why we need scripting languages? Is the compiler that much a barrier to productivity?

Otherwise - some nice additions to Java 6 (especially the XML APIs, which, like E4X, are critical for easing web services development - nice), but despite them, I think Java 6 moves it further away from a credible client-side computing platform - too much increasing complexity, which creates distribution issues. I think Microsoft's mini-CLR is a better step in that direction. Open source and mobile/phone development may change that for Java, but I think a variety of factors will continue to impede relevance in that space.

So long, and thanks for all the fish...

Went to my good-bye party at AOL on Friday. It was fun :)
(Armughan has a picture).

Everyone keeps asking me what I'm up to next. I have some definite plans... but none concrete at this time, and I hope to keep it that way for a little while yet. At a minimum, not even close to ready to discuss it yet :)

Meantime, you can find me here.

Closing thoughts:
1) They say all truths go through 3 phases - first ridicule, then violent opposition, and then self evidence. AOL's getting through its truths, and that's a healthy thing. Good luck and good wishes. I think the company has the assets to be successful. I hope that it will.

2) Always good to remember: At software companies, the intellectual capital is in the people, not the code, and not the products. At software companies.

I must be getting older...

I'm more interested in the Wii than in the PS3 (neither of which I'm likely to get anytime soon...). It just looks like more fun (for everyone :))

(Note: The Wii clip below is a spoof - but be warned, its a little sexist/sexual)

WPF/E CTP now available

The application runtime arms race is off.

Adobe's Apollo is due early next year, as is a more functional (read: useful) XULRunner from the Mozilla foundation. But first out of the gates is Microsoft with their cross platform web content runtime framework: you can now try out WPF/E. Read more here.

At least from a "promise" perspective, WPF/E more squarely what Avalon - now WPF in Vista - or even ChromeEffects (for you old-timers) was going to offer, but, significantly, this is cross-platform from the get-go. The "E" is for "Everywhere". And just to prove it, the CTP is available for Windows and Mac OS X (well, Safari on OS X anyway).

I'll post some thoughts later this week after playing with it. As I've mentioned before, the evolution is towards general purpose computing technologies to make rich application distribution instantly ubiquitous. There are some significant and interesting technology choices that imply certain classes of applications and uses... more on this in the future. Confusingly, WPF will ALSO run in your browser and enable web applications but only on Windows, and its, uh, somehow different than WPF/E, and, uh, richer (?) somehow... though neither is a subset of the other... yeeeeahhh.... quick over there! Linux is eating your IP!!!! .....

Of course, still an open question is what "rich" really means and if people really care at all ... :)

My (biased) guess is that it does, but our current generation of applications and infrastructure (not to mention imagination) just isn't there yet. After the fact, I think we'll go "of course!" (iPod anyone?)

(and oh, btw, this was the idea with Boxely and the OCP, too, but... cie la vie :))

Unicode is a pain in the @$$

I was playing around with some code-y things, and wanted to find a simple, cross platform way to deal with Unicode strings. Good luck!

The closest thing I could find for C/C++ was the ICU library from IBM. While its VERY complete and functionlly rich - oh my god is it huge and complicated!

In the past, I've had to write my own (simple) functions to deal with really exactly the cases I needed, but, this being 2006, I thought I could find some nice publicly available routines to deal with this.

Not so much.

There's definitely code out there, but either by license or implementation, its bound up in ways that make it not so useful... so...

...I think I'm going to have to roll my own on this (again), which I'll then release source code for publicly - something simple, but hopefully more useful than what I've seen. Anybody have/use anything they like better that's already out there, let me know please... save me the hassle :)

As far as I can tell, here's what it takes to decode a single UTF-8 character:

(code snippet)


Ouy!! ...and its not even "fully" right for the invalid/stict case - there are invalid bit distributions within the byte group ranges.

And UTF-16 isn't much better... it's a little less code, but FAR more complicated in logic. Originally, it was intended to be 1 code point per unit (an unsigned short), but that become untenable over (a short amount of) time, and so they introduced support for multibyte surrogates, just like UTF-8. But because it had not orginally been designed for UTF-16, it used some odd ranges to support them (one of many reasons I don't like it). So THAT code, to decode a code point from a UTF-16 stream, looks like this:

(code snippet)


And all this just to decode ONE codepoint... of course, if you've ever actually looked at the algorithmic complexity of converting a floating point number to a string (even most veteran code monkeys haven't)... well, you start to appreciate the value of a good code library.

Anyway, I want length, count, cat, copy, compare (case sensitive and not), at least, and probably one or two other classes of functions (conversions betwixt UTF types certainly, but that's reasonably there already, if a little "stricter" than necessary). Locale code pages I can do without .... I'm looking for "pure" Unicode functionality in a lightweight package.

Pointers welcome.