face - Dave's Blog

When writing a JavaScript library that uses postMessage and the message event, I must be considerate of other JS code that will be running along side my library. I shouldn't assume I'm the only sender and receiver on a caller provided MessagePort object. This means obviously I should use addEventListener("message" rather than the onmessage property (see related What if two programs did this?). But considering the actual messages traveling over the message channel I have the issue of accidentally processing another libraries messages and having another library accidentally process my own message. I have a few options for playing nice in this regard:

Require a caller provided unique MessagePort

This solves the problem but puts a lot of work on the caller who may not notice nor follow this requirement.

Uniquely mark my messages

To ensure I'm acting upon my own messages and not messages that happen to have similar properties as my own, I place a 'type' property on my postMessage data with a value of a URN unique to me and my JS library. Usually because its easy I use a UUID URN. There's no way someone will coincidentally produce this same URN. With this I can be sure I'm not processing someone else's messages. Of course there's no way to modify my postMessage data to prevent another library from accidentally processing my messages as their own. I can only hope they take similar steps as this and see that my messages are not their own.

Use caller provided MessagePort only to upgrade to new unique MessagePort

I can also make my own unique MessagePort for which only my library will have the end points. This does still require the caller to provide an initial message channel over which I can communicate my new unique MessagePort which means I still have the problems above. However it clearly reduces the surface area of the problem since I only need once message to communicate the new MessagePort.

The best solution is likely all of the above.
Photo is Sharing by leezie5. Two squirrels sharing food hanging from a bird feeder. Used under Creative Commons license Attribution-NonCommercial-NoDerivs 2.0 Generic.

Having worked on Windows 8 I'm not in a neutral position to review aspects of it, however I'll say from a high level I love taking the following various positives from smart phone apps and app stores and applying it to the desktop:

• Independent developers can easily publish apps.
• One trusted place for a user to find apps.
• User can trust apps are limited to a declared set of capabilities.
• One common and easy way for users to buy and try apps.
• Easy mechanism for independent developers to collect revenue.

Relieving the independent developer of software development overhead, in this case Windows taking care of distribution and sales infrastructure is wonderful for me with my third party developer hat on. This combined with my new found fun of developing in JavaScript and the new Windows Runtime APIs means I've been implementing and finishing various ideas I've had - some for fun and some for productivity on my Surface. Development notes to follow.

I'm done playing Fez. The style is atmospheric retro nastalgia and on the surface the gameplay is standard 2D platformer with one interesting Flatland style game mechanic but dig deeper to find Myst style puzzles. Despite the following I thoroughly enjoyed the game and would recommend it to anyone intrigued by the previous. Five eighths through the game I ran into one of the game's infamous Fez save game breaking issues, but I enjoyed the game enough that I started over before any patches were released and had no further issues.

While playing the game I created some tools to help keep track of my Fez notes (spoilers) including a Pixelated Image Creator that makes it easy to generate data URIs for large, black and white pixelated images, and (spoilers) a Fez Transliteration Tool to help me translate the in-game writing system.

With Facebook changing its privacy policy and settings so frequently and just generally the huge amount of social sites out there, for many of us it is far too late to ensure our name doesn't show up with unfortunate results in web searches. Information is too easily copyable and archive-able to make removing these results a viable option, so clearly the solution is to create more data.

Create fake profiles on Facebook using your name but with a different photo, different date of birth, and different hometown. Create enough doppelgangers to add noise to the search results for your name. And have them share embarrassing stories on their blogs. The goal is to ensure that the din of your alternates drowns out anything embarrassing showing up for you.

Although it will look suspicious if you're the only name on Google with such chaff. So clearly you must also do this for your friends and family. Really you'll be doing them a favor.