Concurrent Casual - Virtuelle Güter im Web

Mein Vortrag beim Virtual Worlds Camp. Das VWC war angeschlossen an die Webinale und hatte den Themen-Schwerpunkt "Virtuelle Welten und virtuelle Güter".





happy_presenting()

Reverse Engineering Requirements from Solutions

I just read an article about Planning For Fun In Game Programming. It starts with a discussion of requirements and solutions. The essential is:

"It can be compelling to write solutions instead of requirements. It is tempting to design a solution to a requirement at the same time as writing the requirement -- especially the interesting ones! Writing solutions feels more authoritative, more formal, more precise and more accurate. But it is counterproductive. By prescribing a given solution, we preclude any potential superior solutions. Prescribing solutions also limits our understanding of the problem domain and intent of the requirement."

This is so true.

Programmers and especially lead developers work by requirements. The lead developers plans and the programmer implements to meet the requirements. But very often the so called requirement paper comes as a series of solutions. Business development, product management, sales, and marketing know what users need. They offer their advice about the next killer feature or the next product in form of requirements papers. Sometimes they even explain in detail what needs to be implemented with examples. This is the point where requirements turn into proposed solutions. This is done in good faith, but with the risk as described in the article above.

(symbolic)

My favourite example is:

Cast:
Development (a lead developer)
Marketing (any other non-technical person)

Marketing: "can we add a cookie?"
Development: "yes, we can."
Marketing: "... and then we can always recognize a user?"
Development: "wait, do you want a cookie or do you want to recognize the user?"
Marketing: "recognize the user!"
Development: "but you said cookie."
Marketing: "It thought this is the same."
Development: "Not in our case, because this is not a Web application."

This is a short example, solved in 2 minutes. But the same problem can easily waste weeks of development time in more serious cases. Whatever Development gets, it is always the task of Development to understand the problem, not the proposed solution. If Development slavishly implements a proposed solution and it turns out to be the wrong solution, then it is the fault of Development.

Marketing tries to specify problems as good as it can. If it is very good, then we (Development) get a requirements document. Otherwise we get solutions. Usually we get a mixture, which is the best case. But we must not fall victim to proposed solutions and examples.

Whatever we get, it is our responsibility to "reverse engineer" the problem. To find out what they really want in order to produce the optimal result. We must not hide behind "their" requirements document and just do. Proposed solutions are just a tool to understand the real problem. It is our job, because we can.

happy_backtracking()

Second Life generates 15 billion minutes in web voice calls

The article says:
- "[Second Life] peak concurrent users hit 88,000"
- "At any given moment, 50,000 Second Life residents are using the voice application"
- "More than 50 percent of the [users] are using the built-in voice chat..."

Max 88 k concurrent users (including bots) means about 70 k day's average. Can 70 k users really make 50 k voice conversations at any given moment, especially if "more than 50%" but not 100% use VoIP at all?

Either the voice number is a factor 10 too high or all logged in residents have the VoIP application running. This would mean the client starts it automatically and all running VoIP apps are counted no matter if the user is talking or not. But I would be surprised if everyone is really talking into a mike all the time.

70 k average users log 2.2*10^12 seconds per year. 15 billion minutes in 18 months (lately 1 billion per month) translate into 7.2*10^11 seconds VoIP per year. Meaning: all logged in residents talk 33 % of their inworld time. Considered, that only 50% are using VoIP I conclude, that the VoIP users in SL talk 2/3 of the time even during walking, flying, teleporting, profile clicking - almost always. This is a bit much. I wonder if so many people even have a headset and wear it. And indeed: the original press release only claims "Residents are now consuming over 1 Billion minutes per month". Consuming is the keyword. They are counting squawking speakers, not talking heads. The press release continues with the bold statement "making Second Life one of the largest VoIP providers in the world". Its rather one of the largest receivers. But the press liked it. Good story.

They make many VoIP minutes, but there is probably very much noise in the air.

Disclaimer: I am only talking about the numbers. The feature is great. Long live ubiquitous ambient 3-D proximity voice.

Update: the Q1 economy report makes it even sharper. It claims: "Second Life Residents log 124 Million hours". This translates into 58.000 average users, which means that my estimate of 70.000 was a bit high.Thus, VoIP users in SL talk 80% of their inworld time instead of 66%.

_happy_voiping()

Tencent’s virtual goods revenues keep growing during recession

China is always different. But here are indications that virtual goods remain strong during the economic downturn. Virtual goods are "small entertainment". "Big entertainment" like TV-sets and Porsches seem to sell worse. But it looks like people can still afford single dollars (or yuan) for one or the other virtual good, that makes life sweeter during recession.

There are also hints, that especially childrens' pocket money is recession proof. When did you see the latest reduction of pocket money? It was probably because of a family dispute over school marks rather than because of problems with the family income. In other words: it takes a long time until recession arrives in the pockets of children.

I recommend this article to all people, who do not believe in virtual goods, especially investors and a "great manager". Even those who admit that there is something to virtual goods, but still believe that virtual goods will dive, while advertisement revenues will always grow, please read.

When we said that Facebook earns already 40. Mio. $ with virtual goods half a year ago, we got a reply: "I don't belive it". Well, could be much more on the entire platform soon. Seems not only China is different but also Facebook. Maybe it's not the world that is "different". Maybe some people differ from the world.

_happy_spending()

Javascript Inheritance

Javascript is one of the coolest languages. What a pity, that the world needed 10 years to grok the concept of a prototype-oriented language. I have a deep respect for the inventor(s) and/or the one who chose the concept for Netscape Navigator 2.0. In the first years after 1996 most Javascript/DHTML programmers used it as a spaghetti code scripting language with global functions.

Later the world turned to use Javascript as an object-oriented language trying to emulate object-oriented inheritance with JS methods. There were many ways to do this. I used several over time. You always try to harmonize the coding style at least in a project. But there is a drift. Some time ago I proposed a OO-inheritance style as guideline for all JS coding in the company. Allan, being a JS wizard, could improve on it and we developed my latest OO-inheritance style for Javascript. The concept basically copies the prototype properties to the derived class using:

// Base class:
function Animal(param1) {}
// Derived class
Dog.prototype = {}; for (_ in Animal.prototype) { Dog.prototype[_] = Animal.prototype[_]; }

This is not as Allan would use it, because leaving the '_' variable in the global scope is bad style. We could encapsulate the transfer of prototype properties into a function, but that leaves a function in the global scope. Still, this can be regarded as more beautiful, so we get in full beauty:

// Prototype copy utility (beware, this is a long line)
window.deriveClass = function(baseClass, derivedClass) { derivedClass.prototype = {}; for (var i in baseClass.prototype) { derivedClass.prototype[i] = baseClass.prototype[i]; derivedClass.prototype.baseClass = baseClass; }};

// Base class:
function Animal(param1)
{
this.a = param1;
}
Animal.prototype.getClass = function() { return 'Animal'; }

// Derived class
window.deriveClass(Animal, Dog);
function Dog(param1, param2)
{
this.baseClass.call(this, param1);
this.b = param2;
}
Dog.prototype.getClass = function() { return 'Dog'; }

The function window.deriveClass also adds a prototype property baseClass so, that the Dog constructor can use it to initialize the base class without using 'Animal' explicitly. See the example.

Before that I used a shorter, but more dirty way to subclass, which calls the base class constructor once without parameters:

Dog.prototype = new Animal;

_happy_subclassing();

Wunderheilung mit Aloe Vera

Vor 4 Tagen habe ich mir ordentlich beim Kochen den Tippfinger verbrannt. Natürlich sofort gekühlt mit Wasser und Eis, trotzdem eine richtige Brandblase, 3 cm lang, 1 cm breit, dick, aua. Also Verbrennung 2. Grades, allerdings nur klein und nicht so.

Dann aber Aloe Vera drauf getan. Die Pflanze musste einen Arm opfern. Davon einen kleinen Streifen abgeschnitten und präpariert durch Entfernen der Schale an der flachen Seite, anschließend, wie im Bild dargestellt, mithilfe eines handelsüblichen Pflasters am Finger appliziert (sog. Sushi-Methode). Über Nacht draufgelassen. Am Morgen deutlich besser. Das gleiche nochmal und am 2. Tag war die Blase weg, und die Haut wiederbelebt. 4 Tage später etwas "ledrig", aber am Leben. Schmerzen waren nie.

Aloe Vera ist sozusagen Wasser, das man sich an den Finger schnallen kann. Sie gibt ganz langsam das Wasser ab und kühlt stundenlang. Die Haut trocknet nicht aus und vielleicht helfen sogar die Inhaltsstoffe dem Heilungsprozess.

Wikipedia sagt: "A more recent review (2007) concludes that the cumulative evidence supports the use of Aloe vera for the healing of first to second degree burns". Bingo! Genau mein Anwendungsfall. Kann ich nur empfehlen.

_happy_healing()

Testing Mail2Blogger

Man kann per Email bloggen, eigentlich ziemlich cool.



_happy_blogging()

Simple Remote Procedure Call - cstring Encoding as default

The cstring-like encoding of values is now default. In other words: the cstring encoding indication can be omitted.
A parameter line with line-feed (\n) now looks like:

1. News=Google Introduces New...\nAnalyst says...

instead of:

1. News=Google Introduces New...\nAnalyst says...
2. News/Encoding=cstring

More about Simple Remote Procedure Call

_happy_encoding()