I don't know when nor why it happened but Akismet now thinks my blog comments are spams, even comments to my own posts. How do I redeem myself to Akismet? O Kiss Me Akismet!

During my daily visit to Cute Overload, I noticed what looked like a plea for help. Clicking through, I ended up at SaveMyHusband.com site where there were two videos, one by the wife of the abducted man and another of the abduction taking place. The site and videos smelled fake but I didn't notice anything that clearly indicated that site is a marketing gimick by CourtTV.
I don't know who is responsible for this highly offensive marketing stunt but it disgusted me enough to never look at another CourtTV program. I am also unsubscribing from Cute Overload because they allowed this highly deceptive ad to run on their blog.
I guess marketing breeds intolerance too.
UPDATE: The 'plea' video is now clearly marked to indicate it's just a dramatization. Good. Their ad at CO still has nothing more than an easily overlooked gray Premium Ad link at the bottom. Even noticed, all that say is that someone paid for the ad, not that it's a game.

Out of sight, out of mind. How do we reconcile that with technology bringing the world closer, close enough for everyone to be within sight of everyone? When etiquette and freedom of speech collides in a world-size room from which no one can exit from, which should have the upperhand?
There are no clear answers to these questions but I think that people will choose to build private spaces within the 'room', spaces which appear to be pockets of tolerance when viewed from inside and pockets of intolerance when viewed from outside.

Microsoft Surface is an impressive execution of multi-touch HCI concept. In particularly, they've extended the idea to embrace not just fingers but objects to the repertoire of interaction.

However, I can see several issues that prevents surface computering from being practical for personal and general uses.

1. Internal camera provides object identification and location info but it's too bulky.
2. Flat horizontal viewing-angle could be too stressful for prolonged use and for reading detailed info which means, even in retail setting, information will have to be provided in paper form. Inclined viewing-angle is more comfortable but not for reading.
3. Traditional laptop designs will tend to tip over. Tablets are better but tablet's are typically held in one hand into inclined position so two-handed multi-touch will be less handy.
4. I've yet to see several multi-touch applications running simultaneously and I suspect windows metaphor as-is will be confusing for multi-touch use, particularly when mixed with multi-touch's tendency to use 'real objects'.
5. Multi-touch enabling legacy applications will be difficult to say the least.

Given these and other issues, it's undersandable why Microsoft Surface is being initially targeted to be used in retail and casino settings. Both settings use a handful of domain-specific hand-integrated applications. In contrast, personal computers support open set of applications integrated through general window-based GUI support. But then where would we engineers be without problems? ;-p

It wasn't clear from docs exactly what gets serialized when an object is saved or sent so I thought I would share what I found.

1. Any public instance variable.
2. Any state accessible via matching public get/set method pair.

Read-only properties are not serialized. Why is obvious but unnecessarily leaky class design is the price to pay in practice. A related problem is that Event subclass can't be serialized without implementing IExternalizable because the 'type' property is read-only.

Overriding type property in Event subclass conflicts with internal dispatchEvent implementation which apparently ignores the overriden value, causing events to be  dispatched using the internal type. A workaround is to clone the serialized event before dispatching. Not pretty but this enables events to flow across systems, a requirement of mine.

Silverlight 1.0 is a graphics presentation platform which means it can be used to present information graphically. But Silverlight is not yet a graphics user interface platform because the host browser's scripting language, which it depends on to add dynamic behavior, is not fast enough to prevent sluggishness and jerkyness from showing up in highly interactive applications like Popfly. For GUI developers, Silverlight 1.1 should be their target because interactive behaviors can be coded in .NET languages, leaving overall page-level behaviors to be coded in browser scripting language.
Silverlight 1.0 is a highly focused subset of .NET so there are areas where it lacks even as a graphics presentation platform. For example, images can be loaded but image pixels can not be accessed directly. This is because most Silverlight 1.0 objects are just a bundle of properties without methods (they have a handful of common model maintenance methods but they don't provide object specific behavior). API to host browser scripting language is simply the hierarchy of those objects and their properties. Understanding this makes it easier to grasp the limitations of Silverlight 1.0. IMHO, it's a smart compromise. While it is theoretically possible to extend the granuarity of Silverlight object model all the way down to pixels, it is not practical to do so.
CLARIFICATION: When I say host browser scripting language is not fast enough, I don't mean just the language. Binding mechanism between scripting language and Silverlight plugin is subject to browser and platform implementation quirks and limits which will result in platform/browser specific slowdowns and other problems. Following has to happen for each UI event like mouse move:

1. Silverlight: detects mouse move
2. Silverlight: calls host browser javascript event handler.
3. Binding: marshall parameters and wait for javascript engine thread
4. Browser: event handler manipulates Silverlight object model (i.e. move object to match new mouse position).
5. Silverlight: update display to match object model.

I don't know how Silverlight exposes its object model in each platform and browser combination but accessing external object model from a scripting language is a potentially expensive operation.

Checkout this video of about how white tigers are created and pass it on. It's just a tip of the iceburg because designer dogs and cats are bred that way too but we have to start somewhere. My hope is for a worldwide ban on pet in-breeding. I love animals but cuteness is poor excuse for cruelty.

Sometimes you need to build a custom remoting protocol layer in Flash. I had an XML-based one but it was slow. Aside from verbosity, it was slow to process on both sides because XML must be parsed as a whole (stopping is possible through streaming API but not skipping selectively). That costs time and space which one can't afford in use cases like mine. Also, it's rather awkward to add encryption and compression layers transparently on top of XML, awkwardness stemming from having to use HTTP headers to get the job done.
In my use case, most of the payload was intended to opaque to the server because the server acts only as a distributor. Server just reads what's on outside of the box, saves a time limited copy for latecomers then forwards the box to destination clients without knowing what's in the box. This means I can compress the content if it's big enough. I can also encrypt it using a symmetric key then encrypt the key for each intended audience with their respective public key. Each step adds only a sticker ("Inflammable!") on the box. Archiving is done by a server-side subscriber that saves anything with a specific sticker.
I suppose I could have used Flash's built-in support for remoting but it was tedious to figure it out enough for me to use. Breaking things down to headers and bodies is easy but figuring out headers I need to support and handling body and result the way Flash expects is non-trivial and unnecessary in my case.
So I built my own and it's looking fast and flexible enough for my app. Here are some notes from my workbench:

1. Java Preferred – Adobe's server teams use Java so a lot of Java leaked into serialization API and encoding format. You'll find it somewhat easier to build the server-end in Java.
2. writeObject saves space – most of IDataInput and IDataOutput methods writes out data as-is. writeInt will write out 4 bytes. To write out in compact AMF3 format, use only writeObject. Rest of the methods will be necessary if you are using non-Flash object serialization like that of Java's built-in object serialization.*
3. Use registerClassAlias – [RemoteClass(alias=…)] trick seems to work only when Flex classes are used.
4. ActionScript is single-threaded – a fact that both simplifies and complicates. Very forgettable too.
5. ActionScript is not Flash – ActionScript runs inside Flash but the two are not the same. For example, Flash may have other threads than the one ActionScript is on.
6. Flex is not Flash – Flex adds a boatfull of ActionScript classes, source of much but not all of which is included in Flex SDK. Each Flex class you use will add byte codes to the output Flash movie and class dependency will often result in surprising size increases.
7. Watch your weight – A minimal Flex app weights around 100K. A few more lines and, wham, your app is 200K. If you don't use any Flex classes, you only have to worry about embeded resources. My custom remoting fancy app with encryption and compression is about 40K and loads seemingly instantly.

• One problem with using IExternalizable is that AMF3 doesn't offer no hint as to where externalized object data ends because a matching Java class is expected 'know' internally. You'll have to write ObjectInputStream equivalent for AMF3 or, if your AS3 class hierarchy is simple, add the hint yourself. I do this by adding an intermediate serialization step using an interface like this:
  public interface Shareable {

    function readAMF(input:Array);

    function writeAMF(output:Array);

  }
  readAMF() implementations just shift() values out in turn and writeAMF() does the opposite by pushing values into the array in the same order. In writeExternal(), writeAMF is called to build an array of data across class hierarchy then it's written out together. Equivalent is done in readExternal(). This way, server-end logic gets not only simpler but need zero knowledge about client-side classes.
  That's it for now. There are other Flash related funkiness I can enumerate but where is the fun in that? ;-p

Cute Overload is on my daily visit list because I love pets and a quick dose of cute animals has become a morning routine for me. But, being a grouch by nature, I have a couple of complaints with Cute Overload.
First, I can't decipher the poster's babytalk-style writing. Second, I want more background story or pointers to the source. Videos of cat-chasing turtles is worth some hee-hees and ha-has but I want to hear from the pet owner and stories of each pet weaved into a series so I can have some ahs and woos. Instead, all I get is a handful of mutilated words. Babytalk is fine for babies but how am I suppose to understand the ct'zy w'zy booboo?

Looks like I hit a design bug in Flash 9's AMF3 encoding and checking the sources of AMF3 deserializers out there tells me that the Array related condition this bug affects is not being handled properly, probably causing Flash servers to throw up mysteriously and leave developers scratching their heads.
An array in AMF3 can be either a list of typed values or an associative array of name/value pairs. The former has entry count greater than zero and empty key. Later has zero entry count and non-empty key. So far so good although I see no good reasons for them to squeeze the two under one type code (9).
Problem starts with special cases. Empty arrays have zero entry count and empty first key without subsequent data. Associative arrays with a name/value pair with empty name also starts with the same sequence of bytes (09 01 01). I don't see a way for deserializers to tell the two apart.
To be more specific, following two arrays are starts with same 3 byte sequences when encoded in AMF3:

var array1:Array = [];

var array2:Array = new Array();  array2[""] = 1; array2["2"] = 2;

<p>I am too lazy to file a bug report so this blog post is the equivalent of yelling at the end of my driveway in pajamas. Can someone from Adobe confirm? How am I suppose to handle arrays starting with 09 01 01 byte sequence when the array is not at the end of the payload?
My apology to non-geeks for this blatant display of geekery.