Skilling Items

If you start a new game design, there is always the same old question: will it be class based or skill based. If it is class based, then players usually select their class at the start. They level in the class using class equipment doing class specific quest lines. Finally they end up at the level cap being the best skilled and equipped tank, damage dealer, or healer. But a priest always remains a priest. It won't ever be able to use plate armor. This would make the priest uber. The class system makes balancing easier.

An open skill system on the other hand allows anyone to be anything provided the player invests the time. I can choose an area effect damage dealer career specializing in smart bombs and cruise missiles. A year later the same character can be a maxed out healer by pushing repair drones around while the battle rages. Given the time, you can be anything and a combination of it. This makes balancing more difficult. Still, there are means to overcome the problems.

Skill based systems work well. They offer more freedom to players. Freedom is the right to choose, and the burden. Skill systems often appear complex to newbies, because there are so many options. A class system might be easier, because the career path is clear.

So, that's that.

Recently I read a player complaining, that he had to sell his sword and get a new one in order to progress. He asked why the sword does not grow and get better so, that he could keep it while leveling up. The sword could get more rune sockets and other upgrades over time. It could have a name like a pet and grow with the character.

This is a great idea.

What about omitting the character leveling at all. We could skill and level the items only. Skilling items would combine class and skill systems. No need to choose a class, because you are choosing an item. The item has a type, which works like a character class. So the simplicity of a class system is built in. On the other hand you are free to choose items. You can train items (like pets) and skill items to high levels. You can get very good items of any type, given time and money. This is very much like a skill system where you can specialize in anything you want, only that you have specialized items. Still the character counts. If items are bound to the character (e.g. on pickup), then the player is bound to the character. Only this character can use a specific item. The skilled item is perceived as a part of the character. It defines the character class and at the same time it is exchangable for another item with a different specialization. Transferable items may even be used to transfer skills between characters. Sword sharper might be a profession much like a beast master. In other words: everything is a pet, even your sword. There is no difference between feeding the pet with expensive food and sharpening the sword regularly with an expensive grindstone. Both will perform badly if you do not care.

The item skilling system lets us even adjust the death penalty. Death penalty is a hot topic in game design like the skill/class question. If the death penalty is too low, then people risk to much and never really feel the danger. In recent games death is a minor inconvenience, a waste of a few minutes at most. Some game theories say, that the best games in terms of immersion have permanent death. But being set back by months or years because of a lost fight is a major annoyance and not suitable for the mainstream. The truth probably lies somewhere in between. If the pirates attack, then you should feel you heart beat, because you have much to loose. If you finally loose, then not everything should be lost. The publisher of the game is afraid, that you switch to another game instead of starting over from square one. The truth is probably somewhere in between.

If items (pets, robots, drones) fight and if they loose a fight, then they might be lost. This might be a severe loss, because the item has been skilled and was expensive in terms of time and/or money. Still the loss might not be fatal, because the owner might be able to save the upgrades. Maybe it's not only the sword that was upgraded, but the plugged rune. Maybe the owner can save the rune, but looses the sword. The really important (skilled and named) item might be not the sword itself, but the forge. Maybe the forge has upgrades and produces high-end swords. Swords need expensive resources, but after all they are consumables. The forge with all it's upgrades might be the important item. Maybe even the forge is a consumable. It's expensive, but the real value is in the forge's tools. You could loose swords regularly. If someone attacks the forge, you could loose the forge (ouch, the forge ought to be protected, maybe in a guarded industrial park). But if you can save some tools before the forge blows up, then you can plug them into a new forge to produce the same high-end swords as the old forge.

With items, the death penalty can be adjusted easily. An early design decision is not required. No cementries, where you re-appear, no cover story with clones and such, to make the death penalty reasonable. The true beauty of an item skilling system is that the game designer can defer decisions. This makes game design more flexible and error tolerant without drastic changes.

_happy_designing()

Windows Unicode

Der Windows Kernel ist komplett Unicode, und zwar immer 2 Byte, nämlich "unsigned short". Das hat die Portierung von ASCII zu Unicode und paralleles Programmieren von ASCII und Unicode Programmen erleichtert. Man programmiert alles in C++ Macros mit TCHAR als Datentyp und der Compiler macht entweder ASCII (char) oder Unicode (WCHAR).

Soweit so gut. Aber wenn man plattformübergreifend programmieren will, also das gleiche auch auf Mac/Linux kompiliert, kann man TCHAR nicht verwenden. Auf Unix gibt es nur UTF-8. Viele Open Source Libraries sind auch nur in UTF-8, manche in ASCII, aber fast keine in Windows Unicode.

Ich sage: WCHAR war ein Fehler. Sie hätten den Kernel in UTF-8 machen sollen. WCHAR ist nicht wesentlich schneller als UTF-8, ausser, wenn man in langen Texten einen Buchstaben sucht, aber wann macht man das schon und wenn kann man es auch bei UTF-8 effizient hinbekommen. Es ist auch nicht wirklich richtig einfach zwischen ASCII und Unicode umzuschalten. Die "Einfachheit" von TCHAR erkauft man durch viele C++ Macros, viel Disziplin beim Programmieren und doppeltes Testing.

Ich programmiere jedenfalls auch auf Windows in UTF-8. Die Stringklase macht UTF-8. Wenn man das WinAPI bedient, dann wird in Windows Unicode gewandelt. Erstaunlicherweise hält mich jeder gestandene Windows Programierer für verrückt, manche sogar für unfähig, unerfahren, nixblickend. Alle meinen es echt gut und wollen mir erklären, wie man auf Windows "richtig" programmiert: WCHAR für interne Verarbeitung und UTF-8 für Datenaustausch, ich weiss. Ständig konvertieren soll toll sein? Warum nicht immer UTF-8 und nie konvertieren, dabei auch noch mit anderen Plattformen und Libraries kompatibel sein?

Ein deutliches Indiz dass was faul ist, ist dass der NT Kernel ursprünglich auf genau 2 Byte pro Buchstabe festgelegt war. Das nennt sich dann UCS-2. Später hat man das umdefiniert zu UTF-16, was soviel heisst wie: ein Buchstabe hat 2 oder 4 Byte. Damit entfällt die feste Länge und praktisch der gesamte TCHAR Mechansimus ist ad absurdum geführt. UTF-16 ist für UCS-2 genau das gleiche wir UTF-8 für ASCII. Wenn man von UCS-2 auf UTF-16 wechselt, dann hätte man auch gleich von ASCII auf UTF-8 wechseln können ohne den unglaublich aufwendigen Umweg über WCHAR.

Ich weiss was alle denken, was richtig wäre auf Windows, aber ich glaube trotzdem dass da jemand anders mal einen dicken Denkfehler gemacht hat und alle Windows Programierer machen seit 15 Jahren mit.

_happy_coding()

Solarenergie aus dem Weltraum

Das Thema geht ja immer mal wieder durch die Presse: man macht kilometergroße Solarsatelliten und strahlt die Energie per Mikrowelle zur Erde. Ist teuer wegen den Startkosten, aber es gibt immer wieder Vorschläge, die behaupten es ist finanzierbar. Und wenn dann alle Energieprobleme gelöst sind, kann man es sich ja auch was kosten lassen.

Kann ja sein, aber irgendwas ist daran komisch.

Der Punkt ist: die Solarsatelliten erzeugen Strom, der zur Erde tranportiert werden muß. Kabel geht nicht. Aber Mikrowellen kann man einfach erzeugen und ziemlich effizient wieder einfangen mit sogenannten Rectennas.

Nun haben aber manche Leute Angst, dass der Mikrowellenstrahl "abhauen" könnte und Leute in Städten röstet oder dass Vögel durchfliegen und gebraten werden. Vom Waffenpotential mal ganz zu schweigen. Deshalb fächert man den Mikrowellenstrahl so weit auf, dass er keinen Schaden (respektive Kriegsnutzen) anrichten kann. Er hat dann etwa die Energiedichte von normaler Sonnenstrahlung. Das ist dann für alle verständlich, weil Vögel ja sonst auch kein Problem mit der Sonne haben.

Für 1 Gigawatt, das entspricht etwa einem Kernreaktor, braucht man ein 1 km großes Feld von Empfangsantennen. Kann man machen, ist sicher nicht billig. Aber was mich vor allem wundert: warum fängt man nicht gleich Sonnenstrahlung auf dem Boden ein, statt Sonnenstrahlung im Weltraum, dann per Mikrowelle zur Erde und auf dem Boden Mikrowelle einfangen. Wenn die Leistungsdichte des 1 km breiten Mikrowellenstrahls so ist, wie die Sonnenstrahlung dann kann man doch gleich die Sonnenstrahlung einfangen. Die Sonne liefert ca. 1 kW/qm. Das nennt man Solarkonstante. Genauer: 1,37 kW +/- 5% pro Quadratmeter. Aber 1 kW reicht als Abschätzung.

Und siehe da, 1 kW/qm multipliziert mit 1 Quadratkilometer Empfangsfläche ist genau 1 Gigawatt. Natürlich hat man Nacht und mal Wolken, aber statt das Zeug ins All zu transportieren kann man auch einfach 4 mal so viele Solarkollektoren bauen. Für den Preis des Transports bekommt man sicher 4 mal so viele Solarzellen oder Spiegel. Kommt noch dazu, dass man auf der Erde nur auf Energieeffizienz achten muß, im Weltraum aber vor allem auf Gewicht. Da meistens leichter=teurer kann man sich auch deswegen mehr Quadratkilometer auf der Erde leisten.

Dass mir jetzt keiner sagt man muß Platz sparen. Platz ist genug da. Und zwar genau dort wo er billig ist und die Sonne ohne Wolken brennt: in der Wüste. Auch die Mikrowellenempfänger würde man ja wohl in der Wüste bauen. Jedenfalls abseits von Städten und da wo keiner jammert, wenn das Gemüse mal ausversehen Mikrowelle abbekommt, d.h. nicht in der Kulturlandschaft. Berge sind auch unpraktisch.

Bei so attraktiven Kriterien wie "flach, billig, leer, trocken" bleibt auf der Erde nur die Wüste. Es gibt Millionen Quadratkilometer Wüste. Nevada reicht für die USA. Ein tausendstel Sahara reicht für allen Strom in Europa. Kurze Rechnung: 1 Atomkraftwerk bringt pro Reaktor ca. 1 Gigawatt. Die Sonne pro Quadratkilometer auch. Die Sahara hat 9 Mio. Quadratkilometer. Das wären 3 Mio. Atomkraftwerke. Baut man nur ein Hundertstel der Sahara mit Solarzellen oder Spiegeln zu, dann erzeugt man genügend Strom für die ganze Erde. Auch in Zukunft. Energie ist nicht knapp. Die Sonne liefert im Überfluß. Wie nutzen sie nur nicht.

Zurück zu Solarenergie aus dem Weltraum: also entweder

• der Mikrowellenstrahl wird doch gebündelt und hier ist eine große Augenwischerei im Spiel

oder

• Solarsatelliten mit Mikrowellenübertragung sind totaler Unsinn und man sollte lieber 4 Quadratkilometer Solarzellen in die Wüste bauen, statt 1 Quadratkilometer voller Mikrowellenempfänger.

oder

• ich habe was nicht verstanden.
  

Mal ganz davon angesehen, dass man sowieso nicht Tausende Quadratkilometer Solarzellen herstellen würde, sondern eher solarthermische Kraftwerke, die Sonnenstrahlung mit Spiegeln bündeln.

_happy_burning()

Wolfspelz's Primzahl-k-linge Vermutung

Habe gerade gelesen, dass die Zahl der Primzahlen unter einer Zahl n etwa gleich n/log n ist. Das "etwa" heisst: der Grenzwert für n gegen unendlich der wirklichen Zahl der Primzahlen geteilt durch den Schätzwert "n/log n" ist gleich 1. Mit anderen Worten: für große n ist der Unterschied vernachlässigbar und die Schätzung ziemlich genau.

Es gibt außerdem noch Primzahlzwillinge, das sind aufeinanderfolgende Zahlen, die beide Primzahlen sind. Natürlich nicht direkt aufeinanderfolgend, weil dann immer eine gerade Zahl dabei wäre, die durch 2 teilbar und deshalb keine Primzahl ist. Aber wenn n und n+2 beide Primzahlen sind, dann sind sie Primzahlzwillinge. Die Zahl der Primzahlzwillinge unter einer Zahl n ist etwa n/(log n)^2. Das sieht mir ziemlich ähnlich zur Zahl der Primzahlen unterhalb von n aus.

Jetzt kommts: ich stelle mal die Vermutung auf, dass die Zahl der Primzahldrillinge unterhalb von n etwa gleich n/(log n)^3 ist. Verallgemeinerung: die Zahl der Primzahl-k-linge unter n ist etwa n/(log n)^k.

Warum ist das eine "Vermutung"? Weil jeder große Mathematiker eine Vermutung aufstellt an deren Beweis sich Generationen die Zähne ausbeissen (Fermat, Poincaré, Riemann, Goldbach, Legendre, Hodge). Ergo: die Vermutung reicht für den Ruhm. Vielleicht ist es auch so, dass nur die Vermutungen von großen Mathematikern überhaupt bekannt sind, weil von den anderen keiner Notiz nimmt. Also: ich hab meinen Teil getan, die Vermutung aufgestellt. Jetzt ist es an Euch, Notiz zu nehmen und die Zähne daran auszubeissen, damit es noch für den Titel "großer Mathematiker" langt.

_happy_proving()

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.

And the Geeks Shall Inherit the Earth

http://www.pbs.org/cringely/pulpit/2008/pulpit_20080922_005421.html

Stromkonzerne steuern Kraftwerke nach Bedarf. Kernkraft sorgt für die Grundlast. Wind und Sonne sind Glücksache. Kohle und vor allem Gas versorgt die Spitzen. Wenn in der Halbzeitpause alle warmes Wasser brauchen fahren Gasturbinen an. In Wirklichkeit fahren die schon vorher an, weil man ja weiss, dass die Pause kommt. "Man"? "die Konzerne"? Nein, jemand. Es ist jemand, der für 10 Millionen Verbraucher mitdenkt und die Turbinen anwirft. Nicht Software, nicht ein Kommittee, nicht der Vorstandsvorsitzende, sondern einer den keiner kennt: der Geek, der Techniker, der das schon seit Jahren macht, der schon viel gesehen hat und weiss wie die Dinge laufen. Einer mit tiefem Technikwissen und technischer Intuition (auch Bauchgefühl genannt). Sicher, da gibt es viele Leute, die mithelfen. Techniker in den Werken, in den Netzen, Händler und Vertriebler, denn irgendwo muss auch das Geld herkommen für die teuren Spielzeuge.

Aber wenn all die Technik, die Verbraucher, die Ressourcen bereitstehen, dann ist da einer, der weiss wie viel das Netz in 10 Minuten braucht und wo er es her bekommt. Der meldet an das Gaskraftwerk A und Kohlekraftwerk B, dass in 10 Minuten 350 MW gebraucht werden. Er hätte auch C anrufen können, aber C hatte in letzter Zeit Probleme mit der Umspannkopplung und liefert außerdem gerade ins Ausland. Wenn da beim Netzumschalten was schief geht, sinkt die Spannung in den Bereichen D und E unter 200 Volt und 10% der PCs vertragen das nicht. Deshalb lieber von A und B beziehen bis die Uptime von C wieder besser ist. Ok, F wäre auch ein guter Lieferant, aber teurer, als A+B und ausserdem hält der Wind in Norddeutschland noch ein paar Stunden, sodass der Ökostrom gerde stabil ist und die volle Kapazität von F nicht gebraucht wird. Das klingt vielleicht langweilig, aber so sind die Entscheidungswege in der Leitzentrale. Viele Faktoren, Fakten, Randbedingungen, aber auch Erfahrungswerte und Intuition.

Nichts anderes bei einer guten Werbekampagne. Dahinter steckt ein Kopf, der einen neuen Trend umsetzt mit einem guten Bauchgefühl einer Idee, ein Visionär der oder die weiss was dem Markt jetzt gerade voll reinlaufen wird. Viele Mitarbeiter, Ausarbeiter, Zuarbeiter, aber eben auch ein(e) Leader(in) mit dem vernetzen Denken für die entsprechende Branche.

Hinter jedem Produkt steht ein Geek. Der(die) Designer(in), Macher(in), Tüftler(in), Realisierer(in). Meistens irgendwie unbequem, unkommunikativ, exzentrisch, rechthaberisch und in den Augen mancher schwer steuerbar und potentiell gefährlich, aber trotzdem irgendwie unentbehrlich. Das ist die, die Bob Cringely meint.

Gummibärchen...

...sind kein Stück besser als wir Menschen. Rote Gummibärchen als "anders" zu bezeichnen bloss weil sie eine andere Farbe haben, ist echt ungummibärlich. Die Roten sind zwar in der Minderheit, aber auch die Gelben sind nur eine von vielen Farben. Die Vielfalt macht die Tüte bunt.

Wären die Gelben wirklich besser dran, wenn es nur Gelbe gäbe? Fühlen sie sich durch die wenigen Roten bedroht? Würden die Gelben wirklich besser schmecken, wenn es keine Roten gäbe? Eigentlich sollte nur der Geschmack zählen und nicht die Farbe. Und die Vielfalt.

Auch Du kannst helfen: bevorzuge nicht die roten Gummibärchen. Zeige den Gelben, dass sie genauso geliebt werden.

Slashdot Auswertung

Das gestrige Slashdotting brachte 30.000 Unique Visitors.

Davon:
14.000 aus USA,
2500 UK
auf Platz 6 mit 1049 Deutschland

61% Firefox, 21% IE
72% Windows, 14% Linux, 12% Mac

Erstaunlich sind die 61% Firefox, aber trotzdem 72% Windows. 61% Firefox ist ziemlich geeklastig und wahrscheinlich typisch für Slashdot. Aber ich hätte mehr Linux und vor allem Mac erwartet. Mac entspricht ziemlich genau dem Marktanteil und ist damit nicht geekig verzerrt. Das heisst: bei echten Geeks (Slashdot Lesern) ist eher Linux stärker vertreten, als Mac.

Das große weblin-Banner rechts brachte unglaubliche 6 weblin User, immerhin einstellig. Das ist wahrscheinlich die schlechteste Conversion Rate, die es jemals gegeben hat. Das heisst: mit einem Slashdot Artikel werben bringt nichts. Der Artikel muss zum Produkt passen. Sowohl Artikel, als auch Produkt müssen Slashdot Lesern echten Mehrwert bieten. Slashdot Leser lassen sich nicht verführen.

Die Bildschirmauflösungen sind auch bemerkenswert für Webdesigner: ca. 1/3 haben 1280x1024. Dann liegen fast gleich auf 1680x1050/1024x768/1280x800/1440x900 mit 13/13/11/10 %. Also insgesamt die Hälfte mit vertikal >= 1050 und nur 1/3 mit weniger als 1024.

Als Anekdote: Flash ist mehr up to date als Internet Explorer. Fast alle (95%) haben die neueste Flash Version. IE 7 und 8 kommen nur auf 64%. Ein Drittel bleibt standhaft bei IE 6.

Java ist noch nicht tot wenn man auf 11% verzichten kann. Wenn allerdings Mac ein "must" ist wegen dem Marktanteil, dann ist Java ein "don't".

Nachtrag: Inzwischen sind 40 k zusammen gekommen. Sehr schöne Grafik von Google Analytics:

_happy_slashdotting()

TwiX - a Twitter to Jabber (XMPP) Gateway

Tired of waiting for Jabber device updates from Twitter.com?

Try TwiX ...

...and use your Jabber client to send and receive tweets.

TwiX polls twitter.com for new tweets and sends them to your Jabber account as instant message. It also sends your tweets to twitter.com.

Features:

• Twitter from your Jabber client
• get tweets to your Jabber client
• runs on Windows and Linux with .NET and mono
• Jabber command line + statistics
• detailed log output
• many command line options (you won't really need)
• TwiX runs well on just the 3 account parameters shown below
  

Release: TwiX-0.5.0.zip (Best ever)
Source code: TwiX-src-0.5.0.zip (MS Visual Studio 2008)
License: 3-clause BSD (Use it but don't sue me)

Sample command line:
% twixd -twitter my-twitter-token:my-twitter-token-secret
-xmpp my-real-jid@jabber.org
-client my-twitter-gateway@jabber.org/TwiX:gateway-password

Command line options:
Usage:
-twitter : # required: twitter oauth token and secret, colon separated
-xmpp # required: your Jabber ID to send/receive tweets
-client : # required: an arbitrary Jabber account to be used by this Jabber client as a relay, colon separated
-interval # optional (default=120) twitter polling interval
-hideself # optional (default=yes) hide my own status updates
-xmppresponse # optional (default=yes) tell me about the submission status
-xmppupdates # optional (default=yes) send updates at all
-xmppreconnectinterval # optional (default=30) XMPP reconnect interval
-loglevel # optional (default=user) max log level
-logfile # optional (default=) log file name
-logconsole # optional (default=yes) log to console
-version # optional: print version info
-help # optional: this text

Jabber command line:
/twix quit
/twix reload
/twix stats
/twix resetstats
/twix set xmppresponse <on|off>
/twix set xmppupdates <on|off>

_happyTwittering()

Tscheljabinsk Smiley auf Google Maps

Die Bewohner der russischen Stadt Tscheljabinsk haben berechnet, wann der Satellit QuickBird, der Fotos für Google Earth und Google Maps macht, ihre Stadt überfliegt. Sie bildeten einen riesigen Smiley. Damit viele Leute kommen wurde ein Volksfest mit Band organisiert und alle Zuschauer haben sich gelbe Capes übergezogen.

Und es hat tatsächlich geklappt. Das Foto ist auf Google Maps angekommen. Es sieht so aus, als ob sich die Verantwortlichen bei Google hier ganz besonders schnell waren. Normalerweise stellen sie neues Material nicht so schnell online. Vielleicht sind sie selbst begeistert von der Idee, dass eine ganze Stadt sich so ins Zeug legt.

Wenn das mal keine Nachahmer findet.

Chelyabinsk: Giant Smiley on Google Maps

Citizens of the russian town Chelyabinsk calculated when the satellite QuickBird would cross above their city. QuickBird takes images for Google Earth and Google Maps. They created a giant smiley face. A rock concert on the main square attracted many people and everyone got a yellow cape.

And it worked. The image is on Google Maps. It looks like someone at Google was quicker than usual to put up the new data. Maybe Google likes the idea, that an entire town works hard to get its 15 minutes of fame on Google Maps.

To the right is a screenshot of the Chelyabinsk city center. There are also images taken at the event.

( The figure in the lower left corner is my Weblin )

Update: It looks like they restored the original image. Maybe they do not want to encourage copy cats. After all they are trying to show a realistic view of earth and not a collage of events.

LHC : Schwarze Löcher überbewertet

Eine kurze Zusammenfassung dieser Sache mit den Schwarzen Löchern beim LHC.

Beim LHC wird mit Energiewerten gearbeitet, die 1000 mal höher sind als beim Vorgänger LEP. Es kann sein dass dabei schwarze Löcher erzeugt werden. Das ist aber kein Grund zur Panik weil...

...wenn der Physiker sagt "kann sein" nicht heisst das welche erwartet werden. Es ist nur nicht 100% ausgeschlossen weil die Physikerin nie was falsches sagen will.

...die Energie zwar höher ist als bei LEP, aber wenn daraus Materie erzeugt wird ist das immer noch verdammt wenig. 100 mal weniger als man für eine Bakterie braucht. Man braucht also keine Angst haben davon eingesaugt zu werden, weil man die Anziehungskraft einer Bakterie nicht merkt. Man merkt ja nicht einmal den Mount Everest, wenn man daneben steht (also von der Gravitation her meine ich).

...ein schwarzes Loch mit dem Gewicht einer Bakterie so unglaublich klein ist. Die ganze Erde wäre als schwarzes Loch nur 1 cm gross. Verkleinert man eine Bakterie entsprechend, dann ist das Ergebnis viel viel kleiner als ein Atomkern. Das heisst es fällt einfach zwischen den Atomen in der Erde durch bis zum Mittelpunkt im freien Fall. Es braucht eine halbe Stunde bis zur Mitte und fliegt dann weiter bis auf die andere Seite. Nach zwei Stunden kommt es wieder hier vorbei und hat keinem weg getan. Einfach zwischendurch gewitscht, denn was für uns feste Materie ist ist eigentlich ziemlich leer. Wenn wir die Hand auf den Tisch legen, dann spüren wir den Gegendruck der Elektronenhüllen. Zwischen Elektronenhülle und Atomkern ist aber viel viel NICHTS wo das Bakterien-Black Hole durchpasst. Und für ein Bakterien-Black Hole ist sogar der Atomkern fast NICHTS. Nur wenn es ein Proton head-on trifft kann es das fressen. Das ist aber sehr selten.

...selbst wenn es ab und zu einen Atomkern frisst auf dem Weg durch die Erde dann wächst es trotzdem sehr langsam. Es braucht 3 Milliarden Jahre, um ein (in Zahlen: 1) Gramm Erde zu verputzen. Und selbst dann ist es ungefährlich, weil die Anziehungskraft von einem Gramm auch nicht groß ist. Schon mal jemand von einem ml Wasser eingesaugt worden?

...es das nach der Hawking-Theorie das alles gar nicht machen kann. Je kleiner ein schwarzes Loch ist, desto schneller "verpufft" es. Große schwarze Löcher sind sehr stabil, wenn sie die Masse der Sonne oder der Erde haben. Aber wenn sie nur so viel wiegen wie ein großer Lastwagen, dann leben sie nur eine Sekunde. Ein Black Hole mit der Masse einer Bakterie verpufft viel schneller. Gerade wurde es geboren und beginnt langsam zum Erdmittelpunkt zu fallen, aber bevor es den Boden erreicht, ZAPP, kaputt. Es endet als Teilchenschauer im Detektor und bringt dem Physiker, der gerade hinschaut einen Nobelpreis. Immerhin - wer kann das von sich sagen.

also: Don't Panic.
in Memoriam D.N.A.

Big and Bigger Systems

I started to compile a list of guidelines for developing big systems. So, what is a big system?

• "Big" means 5k - 100k concurrent users.
  

Of course, there are even bigger systems. There is also

• "Massive" 50k up to 1 Mio. concurrent and
  
• "Mainstream" 500k up to 10 Mio. concurrent and beyond.
  

The guidelines are for the smallest one the of 3 noteworty categories: "Big". This is the category I am experienced with. 10 or 20k concurrent is significantly different from normal/sparetime/hobby systems. But it is still conventional technology (e.g. on standard LAMP). I can imagine what needs to be done to get a massive system up and keep it running. ButI have never done it, yet. I can only dream of a mainstream scale system, especially a unique and not sharded one (see below).

Examples:

• "Big": Xing, major online newspapers, Wikipedia, many browser games,
  
• "Massive": Second Life, EVE-Online (barely), Runescape (I guess), Habbo, Facebook,
  
• "Mainstream": WoW (barely), major IM networks (QQ, ICQ, MSN), Google search, mobile networks.

In other words:

• "Big" ranges from "substantially over the top of your single server" to "the complete cluster would appear in the Top 500 Supercomputers list". EVE-Online is at the top of "Big" by sheer numbers, but it is on the brink to "Massive" because of its complexity. Xing: more than 10k click around on the web site at any time, sometimes twice as much.
  
• "Massive" is really large. Think about thousands or ten times more servers. That's a decent farm. Second Life is at the lower end. Their server numbers are a bit high for the user count, because of their architecture. Facebook is somwhere in the middle with 50 TB cache memory alone. This number is already 20,000 times more than your PC and growing. We are talking about the large web services, companies with 10 B market capitalization. These are "Massive". The big guys.
• "Mainstream" is unthinkable. Can you imagine half a million servers? If you stack them, they scratch the International Space Station. If you plan a system like this for everyone, then better avoid the hazzle and make it distributed like the Web. It's made for 10% of the world population (registered users not concurrent). There are few such systems on the planet. Few people managed to build in this order of magnitude. I am sure they grew into it with the system. Nothing that you can buy.
  

Of course there are differences in complexity between a static web site and an MMOG. A static web site, e.g. a newspaper may need much less resources for 10k concurrent readers, than a vitual world for 10k concurrent players. Comunication in an IM network is very different from a MMOG. MMOGs enter the "Massive" category earlier than browser games.

But there are also factors, which make the complexity similar or at least in the same order of magnitude.

• As an example, 10k HTTP/HTML readers make more network connections (easily 10k conns per sec.) than 10k players (100 conns per sec. when people log in).
  
• The data delivered may be in the same order of magnitude. Lets face it: a web site consists of min 100 items and active readers fetch 0,1 pages per second. This makes 10k x 0,1 x 100 = 100k items/sec. I doubt, that MMOGs deliver more than 100 items/sec to clients. This is 10 times more than what the web server does, but most MMOG items are just IDs of data pre-installed at the client. The web-items are all completely transferred. This reduces the difference. SecondLife transfers really many items by data. For a virtual world it is still an exception and it shows in the bad performance when discovering new areas.
  
• Then, there is a stupid reason, why web servers may feel the same load as MMOG servers: average web server technology is much worse, especially if they use scripting languages. Nobody would make MMOG servers in PHP. They are compiled code, C++, C#, compiled Java, compiled Python. But many "Big" web sites run on (uncompiled) byte code. Better than the script, but still byte code.
  
• Also, apart from good and bad technologies, there is good and not so good (=stupid) code. This happens to all types of systems and can make an MMOG more responsive than a web site at the same number of users.
  
• Across all types of services, some are sharded, some are unique worlds. EVE-Online is unique, which means everyone can play with everyone. WoW is sharded into 1,000 (?) servers of up to 3,000 (?) concurrent players. Your friend is on a different server? you do not even chat to him. Sharding largely reduces communication and DB load. If shard=host then communication overhead disappears. A DB per shard allows for 100 or 1000 times less DB load per instance. This helps a lot.
  
• After all, each category covers an order of magnitude. There is much room for "small" or "large" inside a category.
  

All in all, the classification into "Big", "Massive", "Mainstream" works.

Distributed systems do not really count here. This is about operating the resources required to support concurrent users. E.g. the Web is not operated by a single entity (though you could count the DNS). The Skype network has a (cool) architecture, that lets Skype, the company manage the network without the need to provide all required resources. Skype is also not an issue here. But most systems are operated by someone with a server farm and this is about what these people do.

So, these lessons are for "Big" systems. Actually primarily for web servers but also some messaging issues and general remarks. Some lessons are obvious, some are obvious in hindsight, some are not so obvious, some may be interesting even if you are one of the few (thousand) architects of big systems worldwide. Read the (far from complete but growing) list of lessons here.

RocketOn Adds Monsters, Quests for Launch - GigaOM

http://gigaom.com/2008/08/08/rocketon-adds-monsters-quests-for-launch/

RocketOn wird am 15. September starten, mit "Monstern und Quests". RocketOn positioniert sich anscheinend für Gamer, die wie in anderen virtuellen Welten Quests machen, Monster bekämpfen und ihre Pets kämpfen lassen. Es gibt 2 virtuelle Währungen: die eine kann man gegen harte Währung kaufen, die andere verdient man sich durch Aktivitäten (genau wie bei wie bei weblin!).

Während weblin mehr parallel zum Web Surfen läuft, aktiviert man RocketOn und kann dann nicht mehr mit der Webseite interagieren. Vielleicht ändert sich das ja auch noch bis zum Start.

RocketOn orientiert sich eher am Gamer, weblin ist eher allgemeine Präsenz und Avatarchat auf dem Web und weniger zielgruppenspezifisch. GigaOM geht sogar so weit zu behaupten, dass sich weblin an eine ältere Zielgruppe wendet, als RocketOn.

Ein zartes Anzeichen, dass sich das Genre diversifiziert. Eine Vorbedingung für die Entstehung eines Massenmarkts, (aber natürlich keine Garantie).

Insgesamt sehr cool. Weiter so.

Layered Virtual Worlds

http://www.virtual-presence.org/news.html?Title=Overlay_Virtual_Worlds

Hier ein Kommentar zu "Layered Virtual Worlds" (englisch) auf www.virtual-presence.org.

Mal richtig "selbstreferentiell". Manche nennen es selbstreferentiell, andere nennen es Trackback. Dafür aber umso schöner mit weblin Publisher fix hergestellt. Ehrlich, wenn ich Avatare doof fände, ich würde weblin für den Publisher laufen lassen. Wenn es nicht läuft mache ich weblin sogar an, um was zu bloggen. Wer hätte das gedacht.

Neuer Server

Endlich mal abends Zeit gefunden den Server aufzusetzten. Der übliche Hetzner minimal-bootstrap, mit RAID1, dann:
- firewall
- apache
- php, memcache, apc
- minimales Hardening
- SSL Zertifikat
- default Virtual Server nur über https
- mysql, phpmyadmin
- ejabberd
und Domain Umzug im DNS.

Viel Glück Me.dium

http://denver.bizjournals.com/denver/stories/2008/07/21/story9.html

Me.dium macht jetzt Google Konkurrenz:

"What we show you is what people are interested in and find useful". Wenn sich das nicht nach Google anhört.

"We don’t think we’re going to take Google out", na dann.

Früher hat Me.dium die Leute angezeigt, die auf "verwandten" Webseiten gesurft sind. Also nicht nur auf der gleichen Domain, wie weblin, RocketOn, Skabble, sondern auch Seiten mit ähnlichem Content. Ich gebe zu, dass mir das schon immer zu komplex war. Content crawlen und den Inhalt herausfinden, dann Inhalte assoziieren ist eine schwierige Sache. Das ist ziemlich genau das was Suchmaschinen machen und sicher nicht das was eine kleine Firma gut kann. Wenn man wie Me.dium jetzt das Surfverhalten seiner User dazu nimmt, kann das sicher helfen. Aber wer glaubt denn, das Google das nicht macht? Google bekommt über ziemlich viele GAnalytics Tags das Surfverhalten und wer auf Suchergebnissen klickt sagt Google auch was gut ist. Das Surfverhalten dass Me.dium bekommt ist im Vergleich dazu vielleicht etwas besser und vollständiger, aber vermutlich nicht so viel besser, dass man die Suche ernsthaft besser machen kann als Google.

Me.dium bekommt etwa die Daten, die auch Alexa hat. Alexa hat auch ein Search Produkt, Alexa: "Alexa has taken search and browse to the next level and made it more complete, more relevant and more useful." Natürlich verwendet Alexa die Daten, die die User "nur zu rein statistischen Zwecken" schicken auch für die Suche. Und hat man schon mal von Alexa Suche gehört? Kann ja sein dass sie Google aussticht, aber so bekannt ist sie nicht obwohl Alexa schon seit 10 Jahren auf dem Markt ist. Alexa gehört zum Web-Urgestein.

Warum glaubt Me.dium Alexa und Google Konkurrenz machen zu müssen. Der Search-Markt ist sowieso gesättigt (oder zumindest eng). Microsoft versucht sich da seit Jahren mit viel Geld. Ich glaube Me.dium sollte lieber in Konkurrenz zu weblin, RocketOn, Skabble, usw. bleiben und sich um 100 Mio. neue User auf einem noch nicht gesättigten Virtuel Presence Markt schlagen.

Mal von Marktchancen abgesehen, finde ich es immer noch bedenklich, dass Firmen das Surfverhalten der User verfolgen und alle URLs mitlesen. Das macht Alexa schon immer so, Me.dium jetzt auch, Google "nur" auf den eigenen Seiten und da wo Web-Admins ein Analytics-Tag einbinden, Facebook hat sich mit Beacon, gerade eine leichtrote Nase geholt. PMOG, RocketOn, Skabble natürlich auch.

Aber ich bleibe dabei: Web-URLs von Usern sollten den PC nicht verlassen. Zumindest nicht für den Basisdienst. Wenn User/in will, dass das Surfverhalten FÜR IHN/SIE verwendet wird, dann ist das was anderes, aber Web-Dienste, die nur auf dem Übertragen von URLs basieren, bereiten mir Unbehagen. Das muss auch anders gehen. Man kann doch nicht Leuten eine Toolbar unterschieben nur damit man an alle URLs kommt, die sie absurfen.

Naja, trotzdem viel Glück Me.dium

Nachtrag: Anscheinend ist das auch noch anderen aufgefallen. Hier ein Vergleich Google, Cuil, Me.dium bei dem Me.dium sogar deutlich vorne liegt.

Layered Social Virtual Worlds

http://www.personalizemedia.com/the-avatars-take-over-the-asylum-layered-social-virtual-worlds/

Schöner neuer Name: Layered Social Virtual Worlds.

Web 1.0: Push, Web 2.0: Share, Web 3.0: live. Wenn mich mein Gefühl nicht trügt, könnte die 3 auch 3D bedeuten.

RocketOn ist Weblin

Mehr zum Thema was-was-ist-und-was-was-nicht-ist: RocketOn ist Weblin. Weblin ist RocketOn. Beide machen Avatare auf allen Webseiten, zwar mit unterschiedlichen Technologien, Protokollen und mit verschiedenem Fokus, aber wenn es eine ernsthafte Konkurrenz gibt, dann ist das RocketOn.

Mit anderen Worten: beide machen virtuelle Präsenz im Web. Ob hier jemand jemandes Killer ist, ist schwer zu sagen. Das Web hat 1000 Mio. User. Wenn nur 10% davon irgendwann virtuelle Präsenz machen, dann sind das 100 Mio. potentielle User. Wer die alle bekommt wissen wir noch nicht, aber wenn RocketOn wiederum 20% Marktanteil gewinnen kann, dann sind das 20 Mio. Aber was ist wenn Google 50% bekommt mit einem Produkt das sie noch nicht haben? Dann bekommt RocketOn "nur" 10 Mio. User. Das gilt auch für die Mitbewerber. Der Verdrängungswettbewerb um Marktanteile im Genre virtuelle Präsenz geht bei 10 Mio. User los. Das sollte einigen zu denken geben.

Ausserdem: es gibt auch mehrere Browser und mehrere Instant Messenger. Es gibt mehrere Autohersteller, Blogsysteme, Betriebssysteme. Was ist der USP von MSN gegenüber ICQ? Die Frage kann man nicht schlüssig beantworten. Virtuelle Präsenz ist ein gigantischer Markt. Wenn es "normal" wird präsent zu sein, wenn 10% der Web-Bevölkerung mitmachen, dann teilen wir uns gerne die 100 Mio. User mit RocketOn. So wie ICQ mit MSN teilt und gut davon lebt. Von GTalk, Yahoo Messenger und anderen mal gar nicht zu reden.

Weblin hat eine gute Chance seinen Teil zu bekommen, weil es

offen, verteilt, sicher

ist.

1. weblin ist das offene System. Das fängt beim Avatare Uploaden und selbst Gestalten an. Geht weiter dass man komplett das Aussehen selbst bestimmen kann und dass Communities und Virtuelle Welten das Web-Aussehen ihrer User in weblin selbst bestimmen. Bis dazu, dass Webseitenbetreiber selbst Chaträume einrichten können, dort selbst moderieren und ihr Hausrecht ausüben können.

2. weblin ist verteilt wie das Web. Es gibt Millionen Webserver, jede Firma hat ihren eigenen. Deshalb arbeitet weblin mit Millionen Chatservern und jeder kann den eigenen Chatserver selbst betreiben. Wenn man die Last von 100 Mio. Chattern verarbeiten will, dann muss das System verteilt sein wie das Web.

3. weblin ist sicher, weil es die Privacy des Users schützt. Bei anderen Systemen wird die komplette Spur beim Websurfen an deren Server geschickt. Alle URLs von den Seiten, die ich besuche werden an sie übermittelt. Im Gegensatz dazu bei weblin verlassen die URLs nicht den PC. Weblin geht in Chaträume aus denen man nicht erkennen kann wo jemand surft. Das ist sehr wichtig, wenn wir ein weltweites System machen wollen in dem Hunderte Millionen Menschen aus allen Ländern präsent sind. Völlig undenkbar, dass eine einzige Firma dieses System beherrscht und hundert Mio. Benutzer dort alle Seitenbesuche hinschicken.

Fürs Protokoll: ja, RocketOn und andere haben auch viele Vorteile. Sollen sie aber selber genau beleuchten.

Für die Nörgler: heute auch wieder Links zur Konkurrenz, wie gestern, natürlich! Irgendwann muss ich mal was schreiben zum Thema "Links sind überbewertet". Links sind für Leser zum Klicken. Wer vor allem an den Google Spider denkt, ist echt fehlgeleitet.

_happy_chatting()

Lively ist nicht Weblin

Wie inzwischen jeder mitbekommen hat, beteiligt sich Google mit Lively am 3D-Welt/Avatar-Hype. Wir sehen im Moment ein Browser-Plugin mit dem man einen 3D-Raum in eine Webseite einbetten kann. Besser gesagt: wenn man das 10 MB Plugin installiert hat, dann kann man Lively-Räume betreten, die auf Webseiten eingebettet wurden.

Damit reiht sich Google ein in eine Unzahl von ähnlichen Systemen, wobei die meisten Flash als Player verwenden, statt einer eigenen installierpflichtigen Engine. Ein klassisches MeToo. Und das von Google, wie un-innovativ.

Naja, vermutlich ist das nur der Anfang. Google hat mit Google-Earth schon eine virtuelle Parallelwelt. Da fehlen eigentlich nur die Avatare. Vielleicht ist Lively ein Weg, um sich an das Avatargeschäft heranzutasten. Wenn Google wirklich Avatare, Inneneinrichtungen und eine Ökonomie in Google-Earth bringt, dann müssen sich ein paar andere virtuelle- und Parallelwelten warm anziehen. Aber das ist es ein weiter Weg und bis dahin droht von Lively keine Gefahr.

Gefahr droht vielleicht für die anderen eingebetteten Welten, die sich nicht auf Games spezialisieren. Runescape, Habbo, usw. sind bestimmt sicher vor Lively. Multiverse, Metaplace, und viele andere gerade gestartete oder in der Entwicklung befindliche Plattformen für "einbettbare" virtuelle Welten sind eher betroffen. Obwohl auch bei denen Unterschiede bestehen und sie sich selbst nicht betroffen fühlen.

Aber es gibt da eine virtuelle Welt, die sicher nicht von Lively betroffen ist: das Web. Systeme, die Leute auf Webseiten sichtbar machen wie weblin und (ganz neu:) RocketOn machen etwas ganz anderes, als virtuelle Welten, die in Webseiten eingebettet sind.

- weblin: Avatare AUF der Webseite (= die Webseite ist der Raum) und zwar auf JEDER Webseite im Gegensatz zu:

- Lively: Raum ist in Webseite eingebettet und Avatare da drin.

Avatare auf jeder Webseite geht auf 100 Mio. Webseiten oder wie viele das Web eben so hat. Avatare in Räumen in Webseite eingebettet geht auf 10.000 Webseiten oder wie viele so etwas eben eingebettet haben. Das ist eine kleiner Unterschied.

Trennung von Memcache und Web Server

Memcache (memcached) nimmt meiner Datenbank fantastisch viel Arbeit ab. Alle Objekte sind im Memcache, kein Code greift direkt auf die Datenbank zu. Die Datenbank wird dadurch um eine Größenordung entlastet. Was die Datenbank leisten müsste sieht man dann, wenn der Cache leer ist. Dann geht alles direkt auf die DB bis der Cache wieder gefüllt (warm) ist.

Der Memcache ist ein verteilter Speicher. Er ist verteilt über mehrere Rechner. Will man keine Rechner extra für den Memcache abstellen, dann verwendet man traditionell die Webserver auch als Memcache-Server. Das heißt nicht, dass es schneller wird, weil die meisten Zugriffe nicht lokal sind, aber billiger weil man keine extra Rechner braucht. Die Webserver hat man ja sowieso. Die Standardvorgehensweise ist also: 10 Webserver hinter einem Loadbalancer. Auf jedem Webserver ein memcached. Das wird deshalb empfohlen, weil Webserver vor allem CPU brauchen (CPU bound) und der Memcache vor allem Speicher (memory bound). Man kann also die jeweils "andere" Ressource auch noch nutzen.

Soweit die Standardvorgehensweise. Tatsache ist aber, dass bei PHP/Apache basierten Webservern (LAMP!) Webserver meistens auch memory bound sind. Apache und PHP werden nämlich normalerweise im Prefork-Modus verwendet. Also viele Apache Prozesse, jeder mit einer eigenen PHP-Runtime. Bei einer großen Applikation braucht ein so ein Apache/PHP Prozess schnell mal 16 MB Speicher. Der geteilte Speicher der verwendeten DLLs fällt kaum ins Gewicht. Das sind fast alles Daten. Ein Standardserver vom letzen Jahr hat 2 GB Speicher, 2 Cores. Will man 100 Apache Prozesse laufen lassen, bekommt man 16 MB x 100 = 1,6 GB. Da bleibt nicht mehr viel für den Memcache, der auch sein 1 GB pro Rechner haben sollte. Schließlich sind ja 1 Mio. User und zig Millionen Objekte im Cache. Dieses Jahr sind es 4 GB und 4 Cores, aber man erwartet auch 200 Prozesse pro Rechner, also auch nicht besser. Apache und Memcache konkurrieren um den Speicher.

Und es wird noch schlimmer. Apache und Memcache haben in der Standardkonfiguration unterschiedliche Verfügbarkeitsanforderungen. Webserver hinter dem Loadbalancer können ab und zu mal ausfallen. Der Loadbalancer merkt das schnell und nimmt sie aus dem Lastverteilungsverbund. Alle Daten, alle Sessions sind im Memcache und damit stets transferierbar. Aber: vom Memcache-Verbund darf kein einziger Rechner ausfallen. Selbst wenn man das schnell merkt und ihn aus dem Verbund nimmt, bedeutet der Ausfall eines einzigen Memcache-Servers einen 50% Cache-Flush. Memcache-Clients berechnen aus dem Key und den verfügbaren Memcache-Servern auf welchem Server die gefragten Daten liegen und holen sie direkt dort. Fällt ein Server aus, dann ändert sich die Zuordnung der Keys zu den Memcache-Servern. Die Daten bleiben dort gespeichert, aber die Clients finden sie nicht mehr und nehmen an, dass sie nicht da sind. Es gibt alternative Zuordnungsalgorithmen, die verhindern, dass sich alle Keys umsortieren. Das ist bitter nötig in großen Memcache-Clustern (Facebook: man spricht von 800 Rechnern mit viel Speicher). Denn dann fällt immer einer aus oder es kommt einer dazu.

Aber trotzdem reicht das nicht, denn Webserver sind manchmal überlastet und fallen für den Loadbalancer effektiv aus. Wenn auf dem gleichen Rechner ein memcached läuft und der auch nicht mehr antworten kann, dann fällt ein Teil (20% oder 10%) des Caches aus. Das treibt die Datenbank sofort zu Höchstleistungen und propagiert das Überlastproblem vom Frontend-Rechner zur DB. Das kann schnell die Performance des Gesamtsystems zerstören. Denn braucht die DB 1 h bei leerem Cache um den Cache zu füllen, dann führt der Ausfall von 1 aus 5 Memcaches immerhin zu 1h / 5 = 12 Minuten Überlast auf der DB. Das hört sich nicht gut an, denn eigentlich ist es das Ziel überhaupt keine Spannungssituationen zu erzeugen bloß weil ein Webserver ausfällt.

Webserver arbeiten viel mit der Festplatte. Das ist im high-performance Bereich auch zu vermeiden, aber ist trotzdem Standard im Medium-Segment. Geht die Festplatte kaputt steht der Webserver. Memcache arbeitet nur mit Speicher, überhaupt nicht auf der Platte. Steht die Platte kann er weiterarbeiten. Es ist unsinnig den Memcache von der Festplatte des Webservers abhängen zu lassen. Eigentlich sollte der Memcache-Server vom Netz booten und ohne Platte arbeiten. Ein Teil weniger was kaputt gehen kann, und zwar das häufigste.

Webserver und Memcache haben sehr unterschiedliche Profile und sollten deshalb nicht die Rechner teilen. Webserver (sollen nicht, aber) dürfen ausfallen, deshalb Software RAID-1. Memcaches (tun es, aber) dürfen nicht ausfallen, deshalb entweder RAID-Controller, damit die Platte im Betrieb getauscht werden kann oder gar keine Platte. Webserver so bemessen, damit sie CPU und Speicher Last tragen können. Separate Memcache-Server bemessen, so dass alle zusammen alle Daten der Applikation speichern können, die innerhalb der TTL der Cache-Items anfallen.

happy_coding()

Danke Adobe für TCP Port 843

Vor ein paar Tagen den ersten erntzunehmenden Konkurrenten von weblin entdeckt: ROCKETON. Der ROCKETON ist im in Flash 9 programmiert und ROCKETON schreibt, dass man Port 843 outgoing öffnen muss.

Von der Hilfeseite: "Since our application uses Adobe Flash, we must abide by their security policy. In order for Adobe Flash to work in a multiuser environment, you must have port 843 open. Please ask your system administrator to make sure port 843 is not being blocked."

Auf Port 843 liegt ein Policyfile für Flash. Die Datei muss jeder anbieten, der mit Flash 9 Socketverbindungen zu anderen Hosts benutzen will. Das Policyfile muss auf dem Server liegen zu dem verbunden werden soll und zwar auf Port 843. Nu ist mir nicht ganz klar warum ROCKETON Socketverbindungen benutzt, da ROCKETON eigentlich HTTP-long-polling verwendet, aber sie werden es schon wissen.

Was mich aber wieder einmal gewundert hat ist der Port 843, den Adobe für Flash 9 erfunden hat. Klar, mit Socketverbindungen kann man allerhand Unfug treiben. Java benutzt ja auch das für Security eigentlich ungeeignete DNS, um Applets nicht auf beliebige Adressen verbinden zu lassen. Dass das nur ehrliche und hart arbeitende Normalbürger behindert, aber nicht echte Schlimmfinger ist inzwischen bekannt (Stichwort: DNS Rebinding Attacks). Flash dagegen läßt sogar Verbindungen zu anderen Rechnern zu, aber nur wenn dort das Policyfile verfügbar ist. Leider liegt das Policyfile nicht auf den üblichen Ports 80 oder 443. Diese Ports sind meistens offen, haben schon einen Webserver und man müsste nur eine Datei hinlegen. Nein, man muss extra ein Programm laufen lassen auf Port 843, das die Datei hergibt. Und noch schlimmer: der Port ist in Firmen-Intranets meistens nicht offen. Das heißt, Software in Flash 9, die im Labor und bei normalen Benutzern geht, versagt typischerweise im Büro von Kooperationspartnern und Journalisten. D.h. immer wenn man im Business-Development jemand eine Vorführung machen will geht es nicht. Zuhause aber schon. Danke Adobe.

Warum ist das so. Warum nicht Port 80? Vermutlich ist es Adobes Absicht, dass Socketconnections im Firmenumfeld nicht gehen, damit Attacken, wie DNS Rebindung und Portscanning nicht funktionieren. Nette Idee, um private Rechner von Firmenrechnern zu unterscheiden, aber irgendwie auch ganz schön doof und vor allem ziemlich nervend, wenn man mit Flash tolle Sachen machen will. Ja, sie können es machen. Flash gehört ihnen und wir müssen es ja auch nicht benutzen. Aber irgendwie habe ich das Gefühl, dass es bessere Schutzmechanismen geben muss, als DNS, Stringvergleiche und gesperrte Ports.

Weblin Whiteboard oder: User finden alles

Jemand hat das Whiteboard in weblin entdeckt und User erschreckt. Das Whiteboard kann einfache Grafiken auf Webseiten produzieren, die dann alle im Raum sehen. Kommt man zu spät in den Raum, sieht man es nicht, weil es nur wie Chat als Message vorbeisaust. Wenn es keinen Protokollbot gibt, der die Messages speichert und wieder abspielt, sind die Whiteboard-Messages transient (flüchtig). Die Grafik liegt über allen anderen Fenstern, so dass man den Eindruck bekommt, dass sie auf allen Seiten ist. Ist sie aber nicht, sondern nur in dem Raum wo sie gemacht wurde. Übrigens wenn es nervt: Rechtsklick auf den Rand, oben steht wer es gemacht hat und unten steht "Löschen".

Der Whiteboard Code ist in weblin noch drin und eigentlich nicht erreichbar. Aber natürlich zu Debugzwecken dann doch. Das zeigt wieder mal, dass User alles finden. Security by Obscurity hat keine Chance.

Es gibt einfach so wahnsinnig viele User, die sich so engagiert mit dem Thema befassen. Die kennen das System oft besser als Entwickler. Entwickler benutzen das System weniger, als User. Natürlich kennen Entwickler den Teil den sie gemacht haben sehr gut, aber Entwickler sind trotzdem meistens keine Poweruser. Entwickler kennen die Theorie, User die Praxis. Entwickler programmieren einzelne Features und bedenken dabei manchmal auch Zusammenhänge. Aber User erkennen Muster im Verhalten von Software, die die Entwickler nicht explizit programmiert haben. Vielmehr sind entstehen Wechselwirkungen mehrerer Features, die sich durch sehr intensive Beschäftigung zu einem Muster verbinden.

Das gilt genauso für Games, wo diese Bedienungsmuster im High-End Bereich ein wichtiger Teil des Gameplays werden. Das gilt auch für alle anderen Programme, wie in diesem Fall weblin, mit denen sich User intensiv und lange beschäftigen. Manche Leute lernen das Programm einfach durch intensive Benutzung seiner Features, andere durch Analyse von Code, Protokoll und Reaktionen.

Weiter so Leute, zeigt den Entwicklern was "Wisdom of the Crowds" heisst.

RSS-Feeds: eine Fehlentwicklung - warum XMPP besser gewesen wäre

Ich bin ja wirklich ein Fan von RSS-Feed-Readern. Inzwischen besuche ich gar keine Blogs mehr, sondern lese nur noch die Feeds im Reader. Echt toll, dass die Nachrichten zu mir kommen, statt dass ich alle Websites abklappern muss.

Schade nur...

...dass die Nachrichten gar nicht zu mir kommen, sondern dass meine Software sie abholen muss. Ich muss zwar nicht alle Websites abklappern, aber mein RSS-Client schon. Der schaut ständig nach ob es was neues gibt (polling). Dabei sollt er eigentlich benachrichtigt werden. Der Begriff RSS-Feed ist glatt gelogen. RSS-Feeds sollten RSS-Fetch heißen. Nochmal: Die Nachrichtenquelle sollte eine Nachricht an meinen Reader schicken, statt dass mein Reader alle 10 Minuten nachschaut ob etwas neues da ist. Traffoc-mässig echt eine Schweinerei und nur im Zeitalter von Torrent und Videodownloads gerade noch tragbar.

Diese Fehlentwicklung liegt natürlich daran, dass der ganze RSS-Mechanismus auf Web-Technologien aufbaut, die wegen HTTP per se nur Request-Response können. Dabei gibt es etablierte Technologien mit denen man einen echten News-Feed aufbauen könnte, z.B. XMPP/Jabber.

Was besser gewesen wäre

Bei XMPP ist mein Client ständig mit meinem Server verbunden. Andere Server können jederzeit zu meinem Server Kontakt aufnehmen und dieser schickt dann alles an mich weiter. Wenn ich einen News-Feed haben will, dann registriere ich mich mit meiner Adresse bei der Nachrichtenquelle. Die Nachrichtenquelle schickt mir dann immer eine Mitteilung, dass etwas neues da ist (mit Titel und Zusammenfassung). Mein Reader zeigt es mir sofort (!) an und ich kann die Nachricht lesen. Kein "Pollen", keine Verzögerung, kein unnötiger Traffic.

Jetzt mal ehrlich...

...RSS ist Really Stupid Syndication. Diese Art von News-Pollen gehört in den Mülleimer der Geschichte. Die Zeit ist reif für ein Message-basiertes News-System. Die Technik ist verfügbar: XMPP und andere IM.

Aber inzwischen gibt es so viel Content der die schlechte alte Technik benutzt, dass wir noch lange damit leben werden müssen. Und mit Web-basierten RSS-Readern entspannt sich auch die Lage beim Traffic, weil ein Betreiber (z.B. Google) die Feeds für alle gemeinsam abfragt. Und wenn es komplizierter gewesen wäre, dann hätte es sich vielleicht nicht so durchgesetzt und es wäre weniger Content verfügbar.

Lesen Sie auch bald wieder hier: "Web und Request-Response: eine Fehlentwicklung - warum ein Mesh und Messaging besser gewesen wäre".

Simple Remote Procedure Call - Response Format

SRPC-Response Format is an extension to SRPC. It specifies a request parameter which selects a response format.
This is primarily intended for the REST variant of SRPC where the SRPC parameters are in the request URI and the result is the response body. Usually, the response body carries a data structure. But it is not clear in which format the data is encoded. A "Format" parameter in the request can select if the response is encoded as XML, JSON, WDDX, etc.

1. Format=<one of: json, php, wddx, xml, yaml, etc.>

Example:

1. Format=xml

XML Example: HTTP query:

1. C: GET /srpc.php?Method=GetPrices&Symbol=GOOG&Date=1969-07-21&Format=xml HTTP/1.1

HTTP response (with a sample XML as a the result value):

1. S: HTTP/1.1 200 OK
2. S: Content-type: text/xml
3. S:
4. S: <?xml version="1.0"?>
5. S: <prices>
6. S: <price time="09:00">121.10</price>
7. S: <price time="09:05">121.20</price>
8. S: </prices>
   

JSON Example: HTTP query:

1. C: GET /srpc.php?Method=GetPrices&Symbol=GOOG&Date=1969-07-21&Format=json HTTP/1.1

HTTP response (with a sample JSON as the result value):

1. S: HTTP/1.1 200 OK
2. S: Content-type: application/json
3. S:
4. S: {
5. S: "prices": [
6. S: { "time": "09:00", "value": "121.10" },
7. S: { "time": "09:05", "value": "121.20" }
8. S: ]
9. S: }

Wege aus der kleinen Coderkrise

Jeder Coder kennt die kleine Krise, wennn man zu lange an einem Programmierproblem hängt, dass eigentlich schnell erledigt sein sollte. Manchmal ist es ein Algorithmus, der sich nicht schön in geschlossener Form ausdrücken lassen will. Manchmal ist es eine Lösung die sich standhaft weigert auch alle Grenzfälle abzudecken. Manchmal ist es eine Komplexität, die sich nicht beherrschen lässt. Die Lösung der Krise wäre für den Coder ein Riesenschritt, für den Rest der Welt nicht. Meistens ist es sogar so, dass der Rest der Welt das Problem nicht sieht, weil es "nicht wirklich ein Problem sei kann" oder es "am Ende ja sowieso geht, wozu also aufregen?". Trotzdem bereitet es dem Coder schlaflose Nächte, Haareraufen, Hirnzermartern, Überstunden.

Im Nachhinein gesehen ist die Lösung dann doch meistens entweder "ziemlich einfach", "offensichtlich" oder "ein Hack". Jedenfalls ist es gelöst. Der Coder ist glücklich. Aber sonst interessiert sich keiner dafür.

OK, das war bisher nur Gerede. Diese zwei Absätz helfen keinem. Damit das ganze noch Hand und Fuss bekommt also hier meine Lösungsansätze. Natürlich hängt die konkrete Lösung sehr stark vom Problem hab. Deshalb hier nur Lösungsstrategien, keine Lösungen. Wie immer bei "Patterns": bitte keine Wunder erwarten. Hier steht nur was der vernünftige Coder eh' schon immer gemacht hat.

Wolfspel'z Wege aus der kleinen Coderkrise:

1. Display State

Short: Replace the display of state transitions with a display of the state.

Description: If a system has a complex state and if the state is displayed, then state transitions can be shown by changing the display according to the state transition. But sometimes there are too many possible transitions, similar, but different transitions, transition variants, so that changing the display to reflect the change of the model might be too complicated. Also: testing is very difficult, because all transitions (e.g. by user input) must be tested. If anything changes, then testing all transitions must be repeated. It is difficult to keep a the display consistent with the model, because changes are applied to both. They do not depend on each other. A model-view architecture surely helps, but introducing MVC might be a disruptive architecture change. So, the simpler solution is to redraw the complete display on each model change. If a state transition changes the model, then just repaint the screen.

Variant: If repainting is not feasible, e.g. in case of HTML user interfaces, then rearranging all elements to reflect the model's state is equivalent.

Comments: The downside of this approach is that it might be bad for performance. Applicability depends, but it might give you time for a real solution, especially if there is a deadline. (Let performance issues come back as a bug report :-)

Example:
If the code reads:
model.changeSomething();
display.showChanges();
model.changeSomethingElse();
display.showOtherChanges();

Change it to:
model.changeSomething();
display.showAll();
model.changeSomethingElse();
display.showAll();

2. Perturbation Theory

Short: If special cases prevent a closed solution, then treat them separately.

Description: An algorithmic solution might be difficult, because of context dependencies, special cases, or edge cases. They can make the algorithm complex. Complex algorithms are not good. algorithms should fit on a small page. A solution is to create the core algorithm as if there were no special cases. Then fix the remaining cases separately. A typical solution then starts with the core algorithm. If that is understood and tested, then work around it. The core algorithms could be followed by an additional code section that "fixes" wrong results of the core for special cases. There can ba multiple consecutive such fix-sections. Try to identify the core and then classes of deviations from the core. Then make all individual code sections starting with the core. Do not try to mix special cases into the core algorithm.

Comment: This approach is known as Perturbation Theory in physics. The first order solution is linear and understandable. Higher order solutions add special detail, but are more difficult to comprehend. Therefore they are split fom the first order and added later when the first order works.

3. Simplification

Short: Reduce complexity if possible.

Description: Structure is usually a good thing. But structure also makes solutions more complex. A single layer of hierarchy might make a problem just the bit too complex for the coder to understand it easily enough to derive a simple solution. If you strip away complexity, then you use features or potential features. Even features you might need or find cool or need in the future or might need in the future. Ask yourself: could it be simpler? The answer "no" is forbidden, because anything can be simpler even though you might loose something. The question is: do you loose something that you really need NOW. It might be, that you can even generalize and undo the simplification later. The problem is now. It must be solved now. Do not solve future problems. Just try not to inhibit future extensions while doing the simple thing.

Application:
Ask:
- could it be simpler? - the answer is "yes, but..."
- what would be missing?
- does it hurt now?
- does it hurt later? if yes, does it damage the structure so sverely, that it can not be fixed later.
Typical questions:
- is the hierarchy required, could it be flat? (remember XML-namespaces? XML is simple, namespaces build on top of flat names.)
- do I really need the full implementation or is a solid API with a fake implementation behind good enough?
- does it really have to be a dynamic registry or could we hardwire the modules and just pretend to use a dynamic list?

Then, get rid of it.

4. Start Over

Short: Throw it away and do it again (applies only to small pieces).

Description: Sometimes we produce much code over time. Sometimes very quickly, because a problem has many special cases. Sometimes code accumulates slowly. Anyhow, the result is not understood anymore with all side effects. Each additional feature which must be added, can be a nightmare. Either for the coder who wants to guarantee that "the old mess + the new feature" is still working or for the user who gets random behaviour occasionally. All these are symptoms for a system that is out of control. The same applies to algorithms. This is about solving small problems, not about systems. In case of systems there is no easy way to redo everything. But algorithms and few pages of implementation can be recreated. A new implementation might even get rid of the ballast that was added, but is not used anymore.

Comment: Start Over is a valid last resort to comply to the holy principle of "understand what you are doing". You must completely understand what you are coding and what it does to the data and to users. If you do not understand what you are changing or trying to fix, then you should make it so that you understand, even if that means to write it again in your own words.

Application:
Select code, copy to temp file, press delete.
Kids: do not try this at home.

5. Be Quick

Short: Do not spend much time on the solution. Find a solution quickly.

Description: Do not spend more than 30 minutes on a single algorithm. Do not think too long about a solution. They do not pay you for thinking. They pay you for coding. Programmers spend their time writing I/O, error handling, initialization, synchronization, testing. There is no time to brood for hours, because there is so much else to to. Maybe you can find a solution instead of squeezing it out. A similar problem has already been solved. There is a library for it. There is a software pattern. There is a similar service, that must have had a similar problem. Find the similarity and find out how they have done it.

Application:
Generalize your problem. What is the core of it. What are you really doing. Abstract from your class names and marketing labels. Then try Google.

6. Problem Elimination

Short: Change the problem, if the solution is too difficult

Description: There are all kinds of difficult problems. Most can be reduced to a series of smaller problems. But some withstand reduction, because "everything depends on everything else" and "a small change makes a big difference somewhere else", especially if the "somewhere else" is the marketing department. If a problem has too many (or unclear) requirements, then it might end up in a complex solution after a long time that does not benefit anyone, especially not future coding performance. A complex solution is an indication for a difficult problem. The possibility to create a good code structure indicates a good problem. On the other hand, the lack of a cool code solution indicates lack of a good problem. The problem might not be understood. Simplify the problem. Check what you really need. Use external solution proposals as a description of the real problem, rather than an implementation guideline. Re-create the real problem and make up your own solution.

Comment: It might be necessary to convince the product owner that what she really wants is something different than she talked about.

Application:
Analyze proposed solutions.
Find the core of the problem or find a better problem.
Convince them to change the task.

_happy_coding()