Web based Communities

Ein Paper wurde akzeptiert für die IADIS International Conference Web based Communities 2006. Das Paper ist deshalb wichtig, weil es zum ersten mal Anforderungen an ein weltweites System für Virtuelle Präsenz aufzählt und daraus eine Modellarchitektur ableitet. Die Architektur ist verteilt und protokollunabhängig. Der Kern ist das URL-Mapping von Dokument-URL (Webseite) zu Location-URL (Chatraum) bei der die Webseitenbetreiber eine Schlüsselrolle spielen und so ihr Hausrecht ausüben können.

_happy_coding()

Java is so 90s

Jahrelang kam man sich ja fast doof vor, noch C++ zu programmieren, weil in Java ja alles besser war. Aber es gibt Gleichgesinnte. Danke Slashdot.

Was hat uns eigentlich so gut an Java gefallen?
- Keine Pointer (nur Objektreferenzen, die null sein können, aha).
- Tolle Containerklassen dabei (bei C++ muss man STL nehmen, oder MFC oder wx oder ACE oder das selbstgebaute Framework, das eh jeder erwachsene Programmierer schon hatte).
- Kein delete, dafür Garbage Collector (schon toll im Normalfall, aber ich erinnere mich an Jigsaw Versionen, die nicht gingen, weil der GC buggy war).
- Threads ganz einfach, man muss nicht mal mehr wissen was in welchem Thread laeuft (fuers Protokoll, das ist Ironie. Wenn Programmierer nicht wissen wo was laeuft, dann sterben sie).
- JIT, eine gute Idee (um laaangsamen Code langsam zu machen).
- keine #defines und Templates (#defines, na ja, aber ohne Templates aus Containerklassen immer das Object hochcasten war schlicht beknackt).

Java war ein Schnellschuss. Die Marketingabteilung hat Goslings Spielzeugsystem breitgetreten, um die Welt mit Applets zu begluecken. Inzwischen kann man Java als Zwischenschritt auf dem Weg zu einem richtigen Framework betrachten. Manche nennen es Mono, andere .NET.

C#/NET hat genau die gleichen Features, wie Java. Eigentlich komisch, dass der GC bei .NET geht und der JIT lichtschnellen Code produziert. Ist MS besser, als Sun? Unwahrscheinlich. Die Konzepte waren in Java einfach noch nicht fertiggekocht. Die Programmierer haben sie zum 1., 2., 3. mal umgesetzt und noch nicht fertiggedacht. Bei .NET wurden die gleichen Konzepte zum 6., und 7. mal implementiert. Man hat Erfahrung gewonnen und aus Fehlern gelernt. Ein schoenes Beispiel fuer einen Software-Reifeprozess. Nicht nur Individualsoftware reift beim Kunden. Auch die Java Konzepte haben 8 Jahre lang bei Millionen Programmierern und Anwendern vor sich hingereift. Der Reifeprozess hat auch ergeben, dass #defines manchmal nötig und Templates doch praktisch sind.

Java musste einfach sein auf dem Weg. Da mussten wir durch. Jetzt sind wirs.

_happy_coding()

Graceful Degradation

Entwickler schreiben Software für ein Anwendungsszenario. Manchmal steht das Szenario im Pflichtenheft, in Meeting Notes, manchmal ist es nur im Kopf. Die wird dann so ausgelegt, dass sie den Anforderungen des Szenarios genügt und vielleicht etwas darüber hinaus. Aber manchmal wird Software später ganz anders eingesetzt, als vorgesehen. Aus Einzelplatzanwendungen werden Serveranwendungen mit 100 Usern. Aus kleinen Communities werden grosse Netze. Was über 1 MBit Leitungen funktionierte, soll auch auf 64 kB gehen, usw.

Mit Szenarioänderugen strapaziert man die Software und meistens dann auch die Geduld der User. Software kann nicht von Anfang an für alle Szenarien entwickelt werden. Das ist vor allem ein Budgetproblem. Ein Auto wird nicht zum Zementtransport verwendet. Und wenn, dann ist die Rückbank dreckig und es geht langsam. Software sieht nur flexibel aus, ist aber genauso für einen bestimmten Zweck gemacht, wie ein Auto.

Das Problem liegt eher darin, dass Software für User so aussieht, als ob andere Szenarien möglich sind. Das Auto sagt dem Benutzer (durch irreversibles Dreckigwerden der Rückbank), dass das Anwendungsszenario nicht passt oder zumindest, dass mit Beeinträchtigungen zu rechnen ist. An diesem Punkt können Entwickler ansetzen. Das User Interface kann sagen, wenn ein Szenario nicht zur Entwicklungsvorgabe passt. Wenn wir ein Serversystem für 20 User entwickeln, dann wird der Betrieb bei 30 zäh und alle beschweren sich. Wenn die Software ab Nummer 21 sagen würde, dass eigentlich zu viele User angemeldet sind, dann würde sich niemand wundern. Die Verantwortung wird damit abgewälzt auf die Beschaffungs-/Betriebsabteilung, die dafür sorgen muss, dass eine passende Software angeschafft wird. Und genau darum geht es uns als Entwickler.

Wir wollen nicht verantwortlich gemacht werden, dass Software falsch eingesetzt wird. Deshalb müssen wir (unsere Software) rechtzeitig zu erkennen geben, dass die Software strapaziert wird und mit Beeinträchtigungen zu rechnen ist. Wenn die Entwicklerin versucht, trotzdem den Betrieb aufrecht zu erhalten, dann ist das ehrenhaft, aber wenn es schief geht (Stichwort: zäh, Absturz), dann hat sie versagt. Deshalb: lieber die rechtzeitig gut sichtbar vor Überlastung warnen und weitermachen, als nichts sagen und zusammenbrechen. Denn Software, die zusammenbricht ist schlechte Software, zumindest in den Augen der User.

_happy_coding()