Unsichtbare Schneeflocken sehen

Heute morgen sehe ich aus dem Fenster: es schneit. Ich gehe ans Fenster und die ganze Straße runter schneit es. Klar, würde man denken. Wenns schneit, schneits überall.

Erstaunlich ist aber dass ich es sehen kann, auch in 50 m Entfernung. Ich bin kurzsichtig (Stärke 1,5) und ich kann sicher nicht eine Schneeflocke in 50 m Entfernung sehen. Ich kann ja ohne Brille nicht mal aus 10 m Entfernung den Tafelanschrieb lesen. Der Strich der Kreide ist so groß wie die Schneeflocken heute morgen, genauso weiss vor dunklem Hinergrund, aber 50 m: keine Chance. Also WTF?

Mein Verdacht: die Rübe spielt mir was vor. In der Nähe sehe ich wirklich Flocken, in der Ferne glaube ich auch Flocken zu sehen. Aber wahrscheinlicher ist, dass ich im Fernbereich statistische Dichtefluktuationen der Schneeflockenverteilung optisch verstärkt durch die Transversalbewegung sehe und mir einbilde ich sehe einzelne Flocken fallen, weil ich weiss, dass sie da sind.

_happy_flocking()

Simple Remote Procedure Call - Array Response

SRPC-ArrayResponse is an extension to SRPC. SRPC-ArrayResponse carries an array of key/value lists as response.

Multiple key/value lists could be encoded as SRPC values with an appropriate escaping and encoding for each list. But SRPC-ArrayResponse presents a standardized way to represent an array of key/value lists instead of the usual one dimensional list.

The normal SRPC response looks like:

1. a=b
2. c=d

The ArrayResponse allows for multiple values of similar keys:

1. 0:a=b
2. 0:c=d
3. 1:a=b1
4. 1:c=d1
5. 2:a=b2
6. 2:c=d2
   

The ArrayResponse allows for multiple values of similar keys:

1. Status=1
2. 0:Filename=sp.gif
3. 0:Data/Encoding=base64
4. 0:Data/Type=image/gif
5. 0:Data=R0lGODlhAQABAIAAAP///////yH5BAEAAAEALAAAAAABAAEAAAICTAEAOw==
6. 1:Filename=sp2.gif
7. 1:Data/Encoding=base64
8. 1:Data/Type=image/gif
9. 1:Data=R0lGODlhDwAOAIAAAP///////yH5BAEKAAEALAAAAAAPAA4AAAIMjI+py+0Po5y02osLADs=
   

The extension looks very similar to SRPC-Batch. The difference is that SRPC-Batch transfers multiple requests and multiple responses in a single transaction whereas SRPC-ArrayResponse has only one request and an item list in the response.

Rationale: the decoder can be shared for both cases. It is always clear how to interpret the array, because you know, if you expect an array response or multiple responses.

Google's Lively Learnings

http://www.virtualworldsnews.com/2008/11/google-lively-didnt-meet-tough-targets-looking-to-use-tech-elsewhere.html

Google says: "We set Lively tough targets and it did not achieve them, but Lively did teach us about what our users like and what they don't. We learned people want to be social in many places on the web, and we learned that users appreciate the ability to meet new people and share content with friends. These are important lessons for future product development."

That's 2 points for weblin:
- people want to be social in many places on the web (maybe everywhere on the web?)
- users appreciate the ability to meet new people (new people, not just friends as in social networks)

Simple Remote Procedure Call - TCP

SRPC-TCP is an extension to SRPC. It specifies the encoding of SRPC over TCP.
Rules:

• The message format over plain TCP instead of HTTP is identical to the HTTP POST body.
• A message is terminated by an empty line, in other words: 2 consecutive newlines.
• Multiple SRPC messages may be sent over the same TCP connection in both directions.
• Requests have a "Method" (can, but not has to be the first line).
• Responses have a "Status" (can, but not has to be the first line).

Example:

1. C: Method=GetQuote
2. C: Symbol=GOOG
3. C: Date=1969-07-21
4. C:

1. S: Status=1
2. S: Average=123
3. S: Low=121
4. S: High=125
5. S:

Options:

• Events: messages may be sent in one direction without a response,
• Streaming: multiple request messages may be sent back to back before the corresponding responses are received by the client,
• Ordering: responses may be sent out of order (needs SrpcId, see below),

SrpcId:
Responses are associated with requests by a special key called SrpcId. If the SrpcId key/value pair is included in a request, then the response must include the same key/value pair without interpreting the value. The SrpcId helps to find the request for a response.

Example:

1. C: Method=FirstRequest
2. C: SrpcId=abc
3. C:
4. C: Method=SecondRequest
5. C: SrpcId=def
   
6. C:
7. S: Status=1
8. S: SrpcId=def
9. S:
10. S: Status=0
11. S: Message=error
12. S: SrpcId=abc
13. S:
    

Der erste schwarze Präsident - hä?

Schon mal jemand aufgefallen, dass eine weisse Mutter und ein schwarzer Vater zusammen etwa fifty-fifty ergibt. Das kann man auf- oder abrunden (wenn man unbedingt runden muss). Oder zählt das weiss weniger, weil von der Mutter? Ist das versteckter männlicher Chauvinismus? Und wieso sind die "Weissen" (wer auch immer die sind, klingt irgendwie wie billige Nahrungsmittel) so scharf darauf, möglichst wenig zu sein? Jedes Baby, das mal einen pigmentierten Uropa hatte, wird den "Schwarzen" zugerechnet. Vorsichtshalber werden auch alle mit spanischen Omas rausgerechnet. Schon klar, dass die "Weissen" in USA Angst haben müssen "die Mehrheit zu verlieren". Wie blöd muss man eigentlich sein?

I am a Professional Paranoid

I am a software developer. I make things work. Sometimes I make a mistake. But only about once per year. I mean serious mistakes, a wrong Architecture, a buggy code line that requires an emergency release. That's OK, you think. But...

...there are 10 developers. Each of them does very good work. They deliver solid, tested, working code. They make only very few mistakes. Only one each year. I mean the very serious errors. This makes an emergency release every month. Each new release is followed by a bug fix release. Each new feature is retarded by the emergency release of the previous feature.

There are 6 big features every year. Each feature has >1 operating components. This makes 30 components in 2 years, easily 50 in 3 years. If a single components runs into problems once per year, then after 3 years operating plays firefighter every other week. But operating is already busy maintaining and expanding the operation without serious application problems. They have their own operational problems.

All this makes me 10 times more paranoid.

Of course you make mistakes, anyone does. We test, check, and we find and fix them. But still one per year might slip through. That's still too much. We need methods to eradicate them. My methods are paranoid programming, good architecture, expectation tests, slow down, and 4-eyes.

Paranoid programming and good architecture are classics. 4-eyes is useful in extreme cases and dangerous situations. You want to drop the backup database? Ask someone else, if the statement is correct. She will notice that you are actually dropping the live database.

Expectation testing means, that you plan what to expect from a test. Think of the result before you click the button. Do not interpret test results. Plan the result, make a theory, and confirm the theory. The system tells you facts. And facts are powerful arguments. They can easily convince your brain, that everything is OK. Do not let them convince you. Let the facts confirm your expectations. You are the boss. You tell what happens, before it happens.

Slow down means that you do not hurry delivery. Coding should be quick, dynamic, agile. But delivery, be it deployment, delivery of results or code check-in may be slow. Take your time to think about what you are doing and if it is really brilliant. Stand up, walk around the chair, sit back, think. Take the time. It's only 3 minutes. It's nothing compared to the work before, nothing compared to the consequences of failure.

The goal is NO MISTAKES. That's impossible. But if we do everything and more to make NO MISTAKES, then we might end up at really only one per year, per developer. That would be fine.

Standardising Virtual Worlds: Do Not Hold Your Breath

We know it all: there will be one 3D Web in the future. All virtual worlds will be unified into a single system. A single 3D world player will interface to many virtual worlds (VW) and there will be multiple compatible players. We know it, we talk about it, some of us even work on it. The term "walled gardens" expresses our dream to overcome the current fragmentation. But it is a dream, rather than an expectation. Because most of us in the VW domain do not really know how to achieve such standardization. We know it will happen, but we do not know how. The standardization question is wide open. Of course, some people can answer it already.

Multiverse and Metaplace develop protocols with standardization in mind. They also create showcases. But the real driving force is to provide infrastructure, that others can use to create content. Their infrastructure comprises protocols, formats, and mechanisms wrapped into sample implementations. Their answer is: "use our protocol. It's been designed exactly to be used by everyone". That is probably true. But for the rest of us the question remains: which of them? Would any of the new "created as a standard for all of us"-systems drop their protocol and use another one? Probably not.

Second Life and There.com also have answers. The Second Life community just says: OGP. Others say OGP is the least common denominator. That's neither fair nor true. See how much value has been created with HTTP as common denominator. A chat protocol would be the least common denominator for VWs. A chat protocol just mediates messages. OGP is much more. OGP is feature rich. But still There.com surely finds deficiencies and has no incentive to make a transition. There.com and many other mature VWs have a well running system. Would they join OGP? Probably not.

Then come World of Warcraft and other systems, which have 10 Mio. monthly paying power users. Their answer to the standardization question is: "why?". Maybe as good as "let's see".

There are newcomers striving to create standards, there are mature VWs which move to create standards based on their 10% market share and completely uninterested behemoths. The current situation ist very unlike the Web where competitors dropped out quickly when HTTP arrived. It is much more like the Instant Message and Presence (IM/P) situation 10 years ago. Uninterested behemoths (e.g. ICQ, AIM), established players tweaking their protocols (SIP, XMPP), and newcomers determined to create a standard from scratch.

If this is true, then there is no hope for a unified VW protocol. Extrapolating from the IM/P experience, we can expect multi-protocol VW clients with protocol plugins for individual systems. We are now running Miranda, Trillian and others and have our buddies on a unified roster. A typical protocol plugin has less than a MB of code. A SL/Metaverse/There client weights in the order of 20 MB. Applying a conservative Moore's law, the 500 kB of 1996 is the 20 MB of 2008. We are now talking about standardization. We go to conferences, which remind me of lively IETF meetings about IM/P standards. Some are implementing "the future standard". Some hurry to make small changes to their existing protocol to propose it as "the standard". Some just wait and see.

We can expect multi-protocol clients in a few years and it will be long time until there is a common standard. Maybe 20 years from now. The IM/P domain did not get there after 10 years. But there is progress. IM/P has only been partially integrated. The roster is unified, i.e. only one client with one window on the desktop. But account-wise IM/P is not integrated. There are some big players connecting their account spaces. But it is not yet common. You need an account in every network. We can expect the same in VWs for a long time.

Even with incompatible protocols we would hope for avatar unification. But it will probably turn out as in the IM/P space. Different world, different account, each one with an avatar. Primarily because of different policies. There are VWs with user created content. How would you use these avatars in WoW or a controlled There.com. If you buy something in one world and you get it for free in another, some content creators might be very upset. That's a pity for worlds which rely on user generated content. And there are technical limits. How shall engineers handle scripted clothing from SL in a world which does not support it.

What we can hope for is partial integration where a world manages an avatar and other worlds can at least show it. Maybe not all features, maybe just the basics. The goal for the near future is to display avatars from other worlds. That also fits to the business model of VWs. Users remain full members of their primary world. They customize the avatar with all features offered by the world, from a user driven clothing industry to quest rewards. But they can visit other worlds with this avatar.