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()

Typo3 Form Mail Attachment Max Size

Eigentlich ist Typo3 ja unglaublich toll und man kann alles einstellen. Aber man entdeckt doch immer wieder Stellen, wo einer (in diesem Fall Kasper :-) faul war. Die maximale Grösse von Attachments von Form-generierten Emails ist im Code nicht einstellbar festgelegt.

Wenn man also ein Formular hat, dass eine Email schickt mit allen Eingabewerten und dabei ist ein HTML-File-Upload Feld (Element type: File upload), dann ist das in Typo3 3.8.x beschränkt auf ca. 250 KB. Grössere Files wirft er einfach weg, ohne etwas zu sagen, was nicht nett ist. Aber wenn es nicht gefällt, muss man es ja nicht benutzen oder selbst ändern. Ist ja Open Source. Also ändern wir selbst.

Änderungen der allgemeinen Typo3 Konfiguration (All Configuration) bringen nichts, da die [BE][maxFileSize] = 50000 etwas ganz anderes ist.

typo3_src-3.8.1/t3lib/class.t3lib_formmail.php
In Zeile 142:

if (filesize($theFile) < 250000) {

Ändern in:

if (filesize($theFile) < 1500000) {

für max 1,5 MB

_happy_coding()

Kanzlerin Janeway

Gestern im Fernsehen 2 Frauen vor einer grossen Aufgabe. Beide müssen 2 Mannschaften zu einer schmieden. Die eine im Delta Quadranten, die andere in der Tagesschau.

Die eine: "We have no idea of the dangers we're going to face, but one thing is clear, both crews are going to have to work together if we're to survive. That's why Commander Chakotay and I have agreed that this should be one crew to seek out new worlds and to explore space."

Die andere: "Eine große Koalition, die wir jetzt schmieden wollen, bietet die Voraussetzung dafür, diese Aufgaben gemeinsam anzugehen. Und ich glaube, dass wir das vielleicht auch nur gemeinsam schaffen können."

Social Software

Grade einige Artikel über sogenante "Social Software" gelesen. Der Begriff taucht im Moment ständig auf. Software, die so gelabelt wird ist schon deshal Hype-verdächtig. Der Gründer von Netscape hat einen Teil seines Kapitals in eine Firma gesteckt, die eine Plattform für Social Software herausbegracht hat. Toll. Wenn man dann genau hinschaut ist es eine Plattform mit der man eine Kombination von Flickr, OpenBC, Bookmark Sharing und Foren erstellen kann. Toll.

Social Software ist im Durchschnitt so social, wie Live-Cams live waren in der Frühzeit des Internets. Wir erinnern uns: alle 15 Minuten ein neues JPEG-Bild. Super Live. Dass wir bei der Internet Modellbahn eine echte Live Cam hatten, bei der Live auch live bedeutet, also live im Sinne von live, glaubte keiner. Alle hielten es für ein Movie.

Zurück zur "Social" Software und zwar zur Virtuellen Präsenz, zu Webmobs, oder wie auch immer man es nennen mag. Richtig "social" ist es doch nur mit echten Leuten. Social Web heisst für mich Leute im Web treffen und das geht: LLuna (http://www.lluna.de/). Leute als Avatare auf Webseiten. Leute chatten in Sprechblasen, Avatare bewegen sich. Grüppchen gruppieren sich. Gehen gemeinsam auf andere Seiten, usw. Socializing im Web eben.

LLuna, wenns mal wirklich social sein soll im Web.

Guten Abend.

WoW Avatare im Web

3 Entwicklungen, die zusammenlaufen und plötzlich ein Gesamtbild ergeben:
1. Es gibt World of Warcraft Profile auf Community Sites, wie Allakhazam. Ein Profil wird immer automatisch zu Allakhazam geuploaded, wenn man aus WoW raus geht.
2. Es gibt einen WoW Model Viewer. Ein Stück Open Source Software mit dem man WoW Modelle aus den Game Files (MPQ) auslesen kann, um Figuren zu rendern.
3. LLuna hat eine Avatar Plugin Schnittstelle.

Deshalb haben wir beschlossen, dass wir jetzt ein Proof of Concept machen, um WoW Avatare mit dem WoW Model Viewer Code und Allakhazam Profilen in Luna auf die Webseiten zu bringen.

_happy_coding()

Computer Game Design and Technology Conference

In Liverpool fand die GDTW 2005 statt. 200 Leute aus der Computer Games Industrie diskutieren über Technik und andere Themen im Spieleumfeld. Es gab eine sehr interessante Keynote zum Thema "Emotion" in Spielen von David Freeman, der sehr viel Wirbel macht um Emotioneering, sein Buch und den Kurs, den er anbietet. Aber trotzdem gut. Es gab einige andere hochkarätige Beiträge und ein wissenschaftliches Begleitprogramm in dem auch die Thematik LLuna / Virtuelle Präsenz vertreten war mit einem Vortrag und einem Paper. Titel: Crossing Borders: Game Avatars on the Web.

_happy_coding()

Protokoll bluehands Seminar 28.10.2005

Thema: Firefox XMLDoc braucht Content-Length

Auch wir machen natütlich AJAX. Wir machen das schon seit 4 Jahren, also schon lang bevor es einen berühmten Namen hatte. Klar, die Leserin hat nichts anderes von bluehands erwartet. AJAX heisst im Browser mit einem HTTP-Request im Hintergrund Daten vom Server zu erfragen, die dann in Javascript ausgewertet werden. Dazu verwende an das in moderne Browswr eingebaute XMLDocument Objekt. Das heisst natürlich verschieden bei IE und FF, aber der Code fängt typisherweise so an:

var oXmlDoc = null;
if (document.implementation)
oXmlDoc = document.implementation.createDocument("", "", null);
else
oXmlDoc = new ActiveXObject("Microsoft.XMLDOM");

Dann setzt man einen Callback:

oXmlDoc.onload = OnLoaded;

und lädt eine Datai vom Server, die typischerweise dynamisch erzeugt wird:

oXmlDoc.load(sUri);

Soweit so gut, aber...

Manchmal geht es nicht bei FF. Das heisst er macht den Request, liesst die Daten, erkennt sogat das character encoding aus dem XML header, aber die Tags kommen nicht im DOM an. Bei manchen Anwendungen geht es.

Es stellt sich nach viel probieren heraus, dass es genau dann nicht geht, wenn der Server kein Content-Length HTTP-Headerfield schickt. Bei Servern, die Content-Length setzen, geht es. Das ist [seltsamwitziginteressant], weil es
1. dem IE nichts ausmacht
2. die HTTP-Spec sagt, dass Content-Length nicht notwendig ist, wenn die TCP Verbindung beednet. Dann ist die Content-Length nämlich genau die Daten, die bis zum Ender der verbindung kamen
3. Selbst wenn es dem FF unmöglich wäre die Content-Length herauszufinden,der XML Parser im FF aus dem Schliessen des auessersten XML-Tags erkennen könnte, dass das XML fertig ist. Danach darf sowieso nichts mehr kommen
4. PHP normalerweise keine Content-Length schickt, weil die noch nicht bekannt ist, wenn nach dem HTTP Header die ersten Daten geschickt werden und man.

Ergebnis: AJAX/PHP/Firefox geht nicht, denn das findet der normale PHP Programmierer nie heraus. Aber wenn er googelt und das hier findet sei ihm gesagt: Man muss alle Daten in einer Variable speichern und die Content-Length setzen mit:

header("Content-Length: " . strlen($data);

oder PHP output buffering einschalten, dann geht es möglicherweise auch (nicht getestet). Das hätte den Vorteil, dass der Code nicht umgeschrieben werden muss, um überall einzufügen:

$data .= DasWasVorherImEchoStand;

Das ganze hängt vermutlich nur an einem Detail. Ich nehme an, dass der TCPStream im FF beim XML Parser das "final" flag nicht setzt wenn die TCP Verbindung beendet und so dem Parser nicht signalisiert, dass die Daten fertig sind. Wahrscheinlich parst der Parser das XML korrekt (darauf deutet das character encoding hin), aber das DOM wird nicht fuer den externen Zugriff bereitgestellt, weil "final" fehlt.

Fazit: Noch ein Indiz, dass AJAX noch nicht erwachsen ist. Nicht das einzige. Aber dank des Überhypes darf man hoffen, dass sich Entwicklungsanstrengungen darauf konzentrieren und es das bald wird.

_happy_coding()

Mein erster eigener kleiner Firefox Security Bug

Javascript: Wenn eine Webseite auf Objekte oder Code in einer anderen Seite zugreift, dann heisst das Cross Site Scripting (XSS). Vor allem dann, wenn die Webseiten von verschiedenen Servern kommen. Dann ist das naemlich verboten. Was ein verschiedener Server ist ist Auslegungssache. IE meint, dass der Domainname gleich sein muss. Firefox zaehlt auch den Port dazu. Die Beschraenkung gilt auch fuer IFRAMEs. Aber es gibt einen Mechanismus, um die XSS Beschraenkung zu umgehen. Man darf die Security Domain des Dokuments aendern, aber nur verkuerzen. Wenn ein Dokument auf "spock.bluehands.de" liegt und ein anderes "kirk.bluehands.de", dann ...ist der Script-Zugriff verboten, aber man kann beiden Dokumenten sagen, dass sie auf "bluehands.de" liegen, also Domain Name verkuerzt.

OK, also die Browser haben einen Mechanismus, mit dem man Strings sinnvoll verkuerzen kann, bis nur noch ein Punkt drin ist. Damit kann Firma-A.de nicht auf Firma-B.de zugreifen, aber Host-1.Firma-A.de auf Host-2.Firma-A.de.

Und jetzt kommt der Witz: Das geht auch mit IP-Adressen. Man kann "212.86.216.75" verkuerzen auf "216.75" (1 Punkt muss bleiben). Nur: bei Domainnamen verkuerzt man dabei auf die Hauptdomain, aber IP-Adressen stehen andersherum. Da verkuerzt man auf die Spezialisierung. Und damit kann im Prinzip jeder in seinem eigenen Netz "102.168.216.75" verkuerzen auf "216.75" und die ganze XSS-Security-mit-Domain-Verkuerzung ad absurdum fuehren.

_happy_coding()

Mein Content Management System

Es heisst jeder Kuenstler macht in seinem Leben mindestens eine Madonna, als Skulptur oder als Bild. Was dem Bildkuenstler die Madonna ist, ist dem Programmierer das Content Managmenent System. Jeder Programmierer schreibt mal eins. Deshalb gibt es Content Management Systeme, wie Sand am Meer. Weil ich nicht der erste sein will, der mit der Tradition bricht, habe auch ich in den letzten Tagen ein CMS geschrieben.

Name: SCMS (= Simple CMS)
Features: Templates, CSS/DOM Pagegenerator, News, RSS, Weblog, Extensions.
Besondere Kennzeichen: einfach, keine Datenbank.
Kommentar: alle Dateien im HTML Editor editierbar, auch die Content-Dateien. Pagegenerator verwendet Decorator-Pattern.

Wer es haben will, bitte melden bei wolf@bluehands.de. Es wird nicht veroeffentlicht, weil es damit sicher bleibt. Security by obscurity. Die letzte Rettung, wenn man bei "Standardsoftware" von Hackern geplagt wird. SCMS bleibt geheim und sicher.

_happy_coding()

Protokoll bluehands Seminar 20.09.2005

Thema: Logging Strategie

Das Thema Loggin hat viele Dimensionen. Folgende Punkte wurden diskutiert:

• Logging in Applikationen vs. Logging in Libraries: Libraries sollten nicht selbst bis zur Oberflaeche loggen, sondern ihr Logging an die Host-Applikation delegieren (callback, delegate).
• Tracing: zusaetzlich zum Logging braucht man manchmal Tracing, d.h. jede Methode meldet Einsprung und Aussprung.
• Multithread-save Logging
• Loglevel: wir verwenden folgende Loglevel: Fatal, Error, Warning, Debug, Info, Verbose, Trace, VeryVerbose
• Bedeutung der Loglevel sollte ueber eine gesamte Applikation hinweg aehnlich sein.
• Channels; Logging braucht Channels damit Logging-Quellen getrennt (gefiltert) werden koennen. Man will zB nicht eine gesamte Applikation auf VeryVerbose schalten, sondern nur eine Klasse oder ein Modul. Der Klassen name als Channel ist ein guter Ansatz. Das muss dann manchmal verfeinert werden.
• Syslog/EventLog: Logging auf einen Systemdienst.
• TCP/MsgQ: Logging auf eine Netzwerkverbindung an einen Logserver.
  Logging sollte immer mitgefuehrt werden, nicht erst, wenn es Probleme gibt oder gar nach dem Deployment.
• Problem und Loesung von Logging in Libraries ist verwandt mit Konfiguration in Libraries.
• Daten fuer Verbose und VeryVerbose levels sollten nur dann erzeugt werden, wenn entsprechende Level aktiviert sind.

Loglevel-Bedeutungen bei bluehands:

• Fatal: wenn die Applikation beenden muss
• Error: Fehler, der zum Funktionsabbruch fuehrt
• Warning: Fehler oder schlechte Datenlage, die behoben werden kann
• Debug: temporaerer Level fuer printf-Debugging. (Auskommentieren, drin stehen lassen)
• Info: regelmaessige (wichtige) Systemzustaende und Aenderungen
• Verbose: Verarbeitungsverlauf, 10-100 Zeilen pro Sekunde
• VeryVerbose: 1000 Zeilen pro Sekunde

Logging Klassen sind bei bluehands fuer C# und C++/C standardsisiert.

_happy_coding()

Rechner gehackt

Vielleicht! Im Logfile stehen POST /xmlsrv/xmlrpc.php und einige "Maximum execution time of 30 seconds exceeded in /home/web/wwwroot/www.webmob.de/blogs/b2evocore/_functions_xmlrpc.php on line 402"

Es lebe die selbstgeschriebene Software.

Tja, plattmach.

Protokoll bluehands Seminar 08.09.2005

Thema: Binary Encoding und String Encoding

base64: Encoding, um binaere Daten in ASCII zu codieren, sodass sie durch ASCII Protokolle uebertragen werden koennen, z.B. SMTP (Email) oder XML. Je 3 Byte Ausgangsdaten werden so auf 4 Byte verteilt, dass das hoechste Bit 0 bleibt und keine ASCII Steuerzeichen vorkommen.

Unicode: Unicode ist eine standardisierte Aufzaehlung von Zeichen aus allen moeglichen Zeichensaetzen dieser Erde. Alle Zeichen bekommen eine Nummer. Zufaellig absichtlich liegen die ASCII Zeichen in den niedrigen Nummern auf den gleichen Plaetzen, wie man es von ASCII gewohnt ist.

Microsoft Unicode Implementierung: MS hat beschlossen, dass Unicode Strings aus Zeichen zu je 2 Byte bestehen (Typ: short). Dabei vernachlaessigt MS bewusst Unicode Zeichen mit Nummer ueber 64k. Alle Strings im NT/XP/Vista Kernel sind in Unicode im Memory dargestellt.

UTF-8: Unicde Transfer Format, mindestens 8 Bit, manchmal mehr. ASCII Zeichen werden mit einem Byte dargestellt, alle anderen mit mehr als einem Byte, z.B. MS Unicode mit 2 Byte. So wird z.B. ö als ö dargestellt.

Weitere Themen: PPP, SLIP encoding, Modem, Escape Sequenzen, ISO/OSI Modell.

_happy_coding()

Auto beleidigt

Mein Auto ist beleidigt, weil ich es verkaufen wollte. Es hat gemerkt, dass was in der Luft liegt. Ich hatte den Fahrzeugbrief herausgesucht und neuen TÜV gemacht, obwohl der erst in einem Jahr faellig gewesen waere. Und weil mein Auto sich in seinem Alter nicht mehr an jemand anders gewoehnen will, stellt es sich jetzt tot. Ploetzlich ist die Kupplung kaputt, verliert Wasser und Oel und die Bremsen sind hin. Jahrelang hatte es nichts. Ich habe es nicht verwoehnt, alle 30.000 km Oelwechsel musste reichen, aber ich habe es mit Achtung behandelt. Das hat es mir gedankt durch reparaturfreies Fahren bis 219.000 km. Aber anscheinend will es nicht verkauft werden. Dann kommt es jetzt zum Abdecker. Pech.

_happy_coding() trotzdem

Nachtrag: Das Abschiedsbild.

Protokoll bluehands Seminar 02.09.2005

Thema: select und asynchrone Socket Kommunikation

Normalfall bei einfachen Netzwerkanwendungen sind Systemcalls in der Reihenfolge: socket, connect, write, read. Wenn man auf mehrern Verbindungen gleichzeitig komunizieren will, dann kann man dafuer 2 Threads machen, die jeweils connect, write, read machen. Das gilt fuer Server, die normalerweise viele Verbindungen haben (read/write vertauscht) oder Clients mit Verbindungen an mehrere Server. Aktuelles Beispiel: der Jabber Bot, der mehrere LLuna User simuliert.

Es gibt aber Faelle, wo Threads nicht angebracht sind. Dazu gehoeren Server mit sehr vielen Clients (bei 100 Threads hoert der Spass auf) oder Frameworks, die kene Threads haben PHP). Manche wollen auch auf Threads verzichten, weil Threads eine Synchronisationsproblematik erzeugen, die nicht alle Programmierer vollstaendig ueberblicken (kein Witz).

Es stellt sich die Frage: wie macht man "read" auf 2 sockets gleichzeitig obwohl beide blockieren. Antwort: select. Es gibt versciedene Arten von Select auf verschiedenen Betriebssystemen und Frameworks, select auf Posix, WSAsyncSelect auf Windows, socket_select in PHP, etc.

Allen gemeinsam ist, dass man eine Liste von Sockets angibt, an denen man interessiert ist und einen Timeout. Select wartet solange, bis auf mindestens einem Socket etwas passiert (z.B. Daten ankommen) oder bis der Timeout ablaeuft.

Die Anwendung von select ist einfach. Angenommen man macht eine Anwendung, die nur regelmaessig Sockets schreibt und dann immer sleep() macht:

while (1) {
write(data)
sleep(2 sec)
}

Jetzt ersetzen wir sleep() durch select(). Der Timeout bleibt und dazu kommen die Sockets, fuer die wir uns interessieren beim read():

while (1) {
write(data)
select(socketlist, 2 sec)
}

Select sagt wie viele Sockets Daten fuer uns haben. Dann koennen wir auf den angezeigten Sockets read() machen (ohne ausseres while):

n = select(socketlist, 2 sec)
if (n > 0) {
foreach (socketlist as socket) {
read(socket);
}
}

Select kommt dann zurueck, wenn der Timeout ablaeuft oder wenn mindestens ein Socket signalisiert. Es kann also sein, dass select() nicht so lange wartet, wie angegeben. In diesem Fall muss man einfach nochmal select() aufrufen und die Restzeit als Timeout angeben. Dazu misst man die Zeit, die vergangen ist im select() und den nachfolgenden read(). Das Ergebnis sieht so aus:

timeout = 2;
while (timeout > 0) {
starttime = currenttime()
n = select(socketlist, timeout)
if (n > 0) {
foreach (socketlist as socket) {
read(socket);
}
}
endtime = currenttime()
timeout -= enddtime - starttime
}

Es fehlt noch einiges fuer eine reale Anwendung. Die Zeit muss in Microsekunden verarbeitet werden. Also z.B. gettimeofday() als Zeitmessung. Fehlerbehandlung natuerlich auch.

Wenn wir schon dabei sind: man sollte auch write() nicht blockierend machen. Wann man schreiben darf, sagt auch das select(). Dazu hat das select() in Wirklichkeit nicht nur eine Socketliste, sondern mehrere. Der innere Teil sieht dann etwa so aus:

n = select(readlist, writelist, exceptionlist, timeout)
foreach (readlist as socket) {
read(socket);
}
foreach (writelist as socket) {
write(socket);
}

Das bedeutet natuerlich: alles was man write()n will, in eine Queue haengen, und select sagt dann, wann man schreiben darf.

Weitere Themen waren Netzwerkkommunikation in Verbindung mit User I/O, Windows Events, Windows: WaitForMultipleObjects(), MsgWaitForMultipleObjects(), Posix: errno

_happy_coding()

HTML Olymp

Heute hat sich meine HTML-Messlatte verschoben. Ich dachte bisher ich kann HTML, aber es gibt Websites, da schlackern einem die Ohren ob der Korrektheit, Barrierefreiheit und technischen Aktualitaet. Ein schoenes Beispiel ist http://www.rainerwiegard.de/. Die Site ist barrierefrei in XHTML, sehr schick mit Design, aber ohne Tabellen. Mit Javascript und ohne gut lesbar, sogar in alten Browsern, nicht schoen, aber lesbar. Ohne, dass ein PHP im Server speziellen HTML-Code liefern muss. Wer hat schonmal eine Menuleiste ohne Tabellen gesehen? Ein Menu ist ein <ul> und Menuitems sind <li>. Es geht und man kann es auch echt schick aussehen lassen. Genauso sollte man es machen. Tolles HTML. Gratulation an Sandra Wiegard, die Designerin. OK, mein HTML bekommt kein "sehr gut" mehr. Im Web-Bereich rettet mich nur noch Javascript vor der Mittelmaessigkeit.

_happy_coding()

Kürzer Spielen

Hier ein schönes Beispiel, wie innovativ und am Puls der Zeit die Chinesen sind. Die Chinesische Regierung hat beschlossen, dass dauerhaftes Onlinespielen schädlich ist. 'Schädlich' beginnt bei 3 Stunden. Nun mag man den Beschluss an sich diskutieren und auch die 3 Stunden (Instanzen aufwiedersehen). Wie die Mündigkeit der Bürger bewertet wird, ist kulturell verschieden und die chinesische Kultur tendiert dabei zu mehr organisiertem Buergerschutz.

Was aber vor allem interessant ist, ist die reale Umsetzung der Entscheidung im Vergleich zur Erwartung. Was erwarte ich von einem Staat, der beschließt, dass ich nur 3 Stunden spielen darf? Klar, ich erwarte, dass der Staat ein Gesetz macht und Spielen nach 3 Stunden verbietet. Betreiber oder User werden mit Strafe bedroht. Das wäre eine typische Umsetzung.

Nicht so bei den Chinesen. Man kann spielen soviel man will, aber nach 3 Stunden werden die Characterstats halbiert. Nach 5 Stunden werden die Stats auf Noob-Niveau gesetzt und spätestens dann will keiner mehr spielen. Ich bin begeistert von der Praxisnähe der Umsetzung. Ganz ohne Strafen und Drohung. Ein moderner Staat, der seine Buerger hier liebevoll schützt.

Quelle: http://www.interfax.cn/showfeature.asp?aid=4913

happy_coding()

Google macht Jabber/XMPP

Die Jabber Mailing-Liste ist ganz aus dem Haeusschen. Google hat Google-Talk veroeffentlicht. Einen Instant-Messenger mit VoIP Funktion. Und der basiert auf Jabber. Das ist toll fuer die Jabber Community, denn es bedeutet, dass eine verteilte Open Source Architektur jetzt mit kommerziellem Nachdruck mit den zentralen/proprietaeren Systemen von AOL, MS, Yahoo konkurriert.

Und das ist toll fuer virtuelle Praesenz auf Basis des Jabber Protokolls (sprich: LLuna), weil Google eine riesige Jabber Infrastruktur aufbaut, die fuer virtuelle Praesenz geeignet ist. Weil Google an virtueller Praesenz interessiert sein sollte, weil das in die Geschaeftsstrategie von Google passt

Google ist insofern anders, als viele Webdienste, weil Google nicht auf eine Website konzentriert ist und damit Angst haben muss die user zu verlieren, wenn sie sich ueberall treffen koennen. Google lebt von der Dynamik des ganzen Web. LLuna (virtuelle Praesenz) zeigt das wahre Leben im Web und zwar auf den Seiten wo Google seine Werbung plaziert. Google hat die Vertriebsstruktur mit der man Ads in LLuna plazieren kann. Muss ich noch mehr sagen?

Ach ja: hat mir jemand mal bitte einen gmail Account? Ich wuerde gerne Google-Talk testen. Spenden bitte an wolf@bluehands.de
_happy_coding_

Games Convention 2005

Games Convention 2005 war ein grosser Erfolg. Die Aussteller waren sehr zufrieden. Fuer die Besucher hat die GC schon Kultstatus erreicht und die Leipziger Messegesellschaft lacht sich ins Faeustchen, weil sie der CeBIT den Rang abgelaufen hat. Die CeBIT ist ja mit der CeBIT-Home auf die Nase gefallen. Die klare Ausrichtung auf Games mit Business und wissenschaftlichem Begleitprogramm war ein gelungenes Konzept. Das ist uns natuerlich heute, wo Games mehr Umsatz machen als Video, allen klar und wir wuerden es auch so machen, aber als die GC begonnen hat, war das visionaer.

Wir (bluehands) hatten auf der Games Convention Termine mit ca. 10 Publishern von MMOG (Multiuser Online Games), um unser neues auf LLuna basierendes Produkt vorzustellen. Interesse gross. Konkrete Ausbeute wird die Nachmessezeit zeigen.

LLuna fuer MOG: Player MOG-Charactere als Avatare auf dem Web. In-Game Character kann auf Webseiten rumlaufen und andere Player treffen. Sogar, wenn man nicht mehr so viel Zeit im Spiel hat, kann man den Char noch auf dem Web nutzen und zeigen was man hat. Ein neues Feature fuer die User, ein Anreiz den Account etwas laenger zu behalten und deshalb Geld fuer die Publisher. So haben alle etwas davon.

Folien fuer meinen Vortrag auf der AMCIS 2005

Folien fuer meinen Vortrag auf der Konferenz AMCIS 2005.
Track: Virtual Communities
Titel: LLuna - Designing a Distributed Virtual Presence System
Datum: 12.08.2005
Ort: Omaha/USA

Weg mit dem Chatchannel, Freiheit fuer die Community

Gerade ist Wikimania. Der Wikipedia-Gründer proklamiert "Zehn Dinge, die frei sein müssen". Die 10 Forderung ist: "Befreit die Communities", ein Aufruf, dass sich die einzelnen Gemeinschaften von der Abhängigkeit von einzelnen Firmen oder Techniken lösen. Viele Communities seien etwa abhängig von Anbietern wie Hostern oder Providern -- gerade nach dem Platzen der New-Economy-Blase sei viel Community-Arbeit mit der Pleite von Firmen untergegangen. Ansätze, um Abhilfe zu schaffen, sieht Wales in Angeboten wie Wikicities oder Flickr.

Der hat doch glatt LLuna vergessen. Ist das doch ein Tool zur Befreieung der Community von der Webseite und dem Hoster. Weg mit dem Chatchannel, Freiheit fuer die Community. Chatten ueberall:

_happy_coding

Abstandhalter

Mal wieder was aus dem richtigen Leben: Wie jeder Heimwerker weiss, mach man beim Fliesenlegen Abstandhalter zwischen die Fliesen, damit sie sich nicht verschieben oder gar ohne Luecke aneinanderstossen. Da verwendet man typischerweise sowas: Abstandhalter aus Kunststoff.

Was dem Heimwerker recht ist, ist der NASA billig. Als das Space Shuttle gefliest wurde hat man auch Abstandhalter eingefuegt, damit die Kacheln nicht aneinanderstossen und kaputtgehen. Wenn das Shuttle mal oben ist, braucht man sie nicht mehr. Aber manchmal schaut einer der kleinen Frechdachse muter zwischen den Kacheln hervor. Dann muss man ihn eben rausziehen. Das wurde dann auch heute vor Milliarden Fernsehzuschauern live zelebriert.

Ich praesentiere den beruehmtesten Abstandhalter der Welt:

Haette der Schlingel sich widersetzt, dann waere man ihm mit diesem selbstgebastelten Folterinstrument zuleibe gerueckt:

Poster bei PRESENCE 2005

Mein eingereichtes Paper zur PRESENCE 2005 hat es nicht ins Vortragsprogramm geschafft. Aber immerhin doch als Trostpreis noch als 2-seitige Kurzpaper (Poster) in die Proceedings. Ehrlicherweise muss ich zugeben, dass sich in der Eile der Paperabgabe ein paar Fehler eingeschlichen haben, die einfach einen schlechten Eindruck hinterlassen. 2 Überschriften waren gleich, die Bildnummerierung durcheinander und ein paar Schreibfehler, die eine Rechtschreibkorrektur nicht erwischen kann. So gesehen kann ich noch froh sein, dass es überhaupt veröffentlicht wird. Und nicht nur das. Ich bin ja nicht auf Paper-Veröffentlichungen aus, sondern auf Zuhörer. Ein Poster-Display hat auf der Konferenz selbst vermutlich größer Öffentlichkeitswirkung, als eine Präsentation. Also dann, see you at Presence 2005 in London, 21-23rd September 2005.

Wer braucht XSL?

Habe ich jemals über meine Abneigung gegenüber XSL geschrieben? 2 Kritikpunkte: 1. Lesbarkeit, 2. Trennung von Code und Design. Wegen Punkt 2 finde ich XSL schlecht und falsch. Wegen Punkt 1 hasse ich es. Kurz: 1. XSL ist unleserlich. Die Skriptbefehle sehen genauso aus, wie die Daten und sind dazwischen verstreut. 2. Der Skriptcode im gleichen Dokument, wie das Design. Beides vermengt bildet das XSL. Früher hat man mal Code und Design getrennt.

Zu 1: XSL kommt heraus, wenn ein XML-Liebhaber eine Skriptsprache erfinden will und deshalb alle Sprachelemente in spitze Klammern packt.

Muss eine foreach Schleife wirklich so aussehen:

<?xml:namespace prefix = xsl /></xsl:for-each>

Das sah auch schon mal in anderen Sprachen so aus:

foreach (item in dom.xpath("/sales/record")) ;

Glaubten die XSL Erfinder wirklich, dass man nur XML ganz toll parsen kann und deshalb muss man eine Skriptsprachen im XML Format machen? Dazu kommt noch, dass die meisten Leute mit XSL am Ende dann HTML/XHTML erzeugen. Die HTML Fragmente stehen zwischen den XSL Tags und alles sieht nach Spitze-Klammer-Doppelpunkt-Slash Einheitsbrei aus.

Zu 2: Wo wir schon gerade bei der Mischung von XSL-Skript und HTML sind. Die XSL-Skriptanweisungen sind Code. HTML mit CSS ist das Design. Gerade, weil man bei HTML ja gerne mal Formatierung mit Tabellen macht. Also sind bei XSL Code und Design vermischt. Eine tolle Idee. Wer hat schon mal von Templates gehört? Ein Template, das ist ein Dokument, dass ein Design festlegt. Es enthält keinen Code, außer vielleicht Javascript Code für die Clientseite. Code sollte ein Template benutzen, nicht im Template drin stehen.

Das richtige Design wäre gewesen: Eine Skriptsprache, die aus Daten und einem Template schließlich HTML erzeugt. 3 Dateien: Skript(Code), Daten(XML oder Datenbank), Design(Template). XSL verwendet typischerweise nur 2 Dateien: Daten(XML), Code und Design(XSL). Schade.

Skriptsprachen gibt es genügend. Die hätte man nicht erfinden müssen. Im Fall von XSL hätte sich das Javascript angeboten, weil das sowieso schon im Browser implementiert ist und auch in vielen Application-Servern. Oder vielleicht PHP oder Python oder man hätte das variabel gelassen und nur eine einheitliche Templateschnittstelle geschaffen.

Warum rege ich mich überhaupt auf? Wir trennen Skriptsprache und Template bei allen Projekten. Was schert uns was die anderen machen? Es gibt eben Leute, die großen Einfluss auf die technische Entwicklung haben, weil sie in einem Moment an der richtigen Stelle sitzen und alle zu ihnen aufschauen. Eine solche Stelle ist(war) das W3C (WWW Consortium), dass die Web Standards macht(e). Wenn solche Leute falsche technische Entscheidungen treffen, dann haben sie eine Chance, dass es trotzdem die ganze Welt nachmacht. Auf diese Weise ist XSL zum Standard geworden und sogar in Browser eingebaut worden. Das wäre einfacher und besser gegangen. Schade dass keine 3-komponentige Formatierungsengine in Browser eingebaut wurde. Die könnte man gut verwenden.

Bei der Gelegenheit möchte ich auch noch mal anmerken, dass Leute, die HTML und PHP mischen, keinen Deut besser sind, als XSL-ler.

Etwas ausführlicher und auch schon etwas früher steht das auch hier, aber ich habe es erst heute entdeckt und musste das mal loswerden.

_happy_coding_

Jabber Software Foundation stellt sich selbst ein Bein

Apple hat seit einiger Zeit auch einen Instant Messenger. Apple spielt dabei den Good Guy und verwendet ein Open Source Instant Message Protokoll, naemlich Jabber. Natuerlich will Apple das Programm schoen machen fuer die User und dazu gehoert ein Bild von den Kontakten in der Buddyliste. Da fragte sich der Apple-Entwickler, wo er das Bild unterbringen soll. Der Benutzer will sein Bild uploaden. Das Bild soll im Server gespeichert werden, damit andere User es dort abrufen koennen. Leider hatte die JSF das JEP-0008, in dem der Avatarspeicher im Server spezifiziert war, zurueckgezogen. Aber es gab einen Rettungsanker. In der digitalen Visitenkarte (genannt vCard) kann man auch ein Bild unterbringen. Das tut Apple dann auch, und ist voellig standardkonform.

Daraufhin geht ein Aufschrei durch die Jabber Community, wie schlecht das technisch gemacht ist, weil jeder, der eine Email- oder Postadresse vom anderen braucht, sich die vCard runterlaedt und dann ausser 300 Byte Daten auch noch 10 Kb Bild bekommt ohne sich wehren zu koennen. Das ist wirklich schlecht und zeigt, dass das Bild nicht in die vCard gehoert. Schade, dass die JSF das JEP-0008 fuer ungueltig erklaert hat. Denn Apple haette es bestimmt verwendet. So blieb aber nicht anderes uebrig als das Bild in die vCard zu speichern.

Warum die JSF JEP-0008 'retracted' hat kann man nur vermuten. Ich glaube das geschah in der fruehen Euphorie des Publish and Subscribe (PubSub, JEP-0060). Damals meinten mache Leute in der Jabber Community, dass man eigentlich alles mit PubSub machen sollte und wollten die Entwickler davon abhalten, 'alte' Protokolle zu verwenden. Das war 1. unfreundlich gegenueber den Entwicklern, die das schon implementiert hatten (z.B. LLuna) und 2. ein Schuss ins Knie, wie die iChat/Avatar Geschichte zeigt. Zu allem Ueberfluss ist PubSub in 3 Jahren nicht so richtig in die Gaenge gekommen, so dass es seit 3 Jahren keine technisch vernuenftige Avatar-Spezifikation gibt, obwohl es schonmal eine gab.

_happy_coding_

Das Web sind wir

Mario Sixtus hat in Technology Review einen schönen Artikel geschrieben über neue echte Leben im Web: Das Web sind wir. Hier mein offener Brief an Mario Sixtus und alle, die sich für das wahre Leben im Web interessieren:

Mit grossem Interesse habe ich ihren Artikel "Das Web sind wir" in Technology Review gelesen.

Bei diesen Themen glaube ich, dass Sie sich auch fuer virtuelle Praesenz (VP) interessieren. Das passt perfekt zu Ihren Beobachtungen. Wir betreiben seit langem das Jabber Virtual Presence Project, dass sich zur Aufgabe gemacht hat, Menschen auf dem Web sichtbar zu machen. User erscheinen als Avatarfigur auf den Webseiten auf denen sie gerade surfen. User sehen sich gegenseitig. Sie treffen sich auf Webseiten. Sie sind also virtuell praesent auf den Seiten. Dort koennenn sie sich unterhalten durch Chat/Video und bald Voice.

Virtuelle Praesenz passt perfekt zu ihren Aussagen: Sie schreiben "Das Web sind wir" und dass immer mehr als reale Menschen auf dem Web erscheinen im Gegenatz zu erfundenen Identitaeten. Das passt zum Claim des VP Projekts: LLuna - das wahre Leben im Web (LLuna ist der Client Name). LLuna ist Social Software weil sich Leute auf Webseiten treffen. Oft kennen sie sich nicht vorher, aber manchmal trifft man sogar Bekannte. Fast immer trifft man Leute mit gleichen Interessen, weil man sich auf den gleichen Seeiten herumtreibt und sich so oefter trifft. Weblogs sind ideal als Seiten zum Treffen. Die Weblogs sind ja sozusagen die neuen Homepages und Autoren, die dort virtuell praesent sind, koennen dort ihre Leser treffen. NETZ-PARTYS: dazu muss man wenig sagen. Mit Usern, die sich auf Webseiten treffen, kann man richtige Netzparties machen. Eine LLuna-Userin macht bald eine Vernissage fuer ihre Gallerie-Website mit virtueller Praesenz. Sehr interessant, aber noch nicht implementiert, ist die Kombination von Virtueller Praesenz (VP) und Social Networks (SN). SNs koennen Hintergrundinformationen zu den Leuten geben, die man im Web mit VP trifft. Mit VP allein hat man nur einen Nickname und eine animierte Figur. Aber mit SN kann man erfahren ueber welche Ecken man denjenigen kennt, den man da trifft, selbst wenn man keine direkte Beziehung hat. Mit anderen Worten VP ist der ideale Stichwortgeber fuer SN.

Ich zitiere aus Ihrem Artikel: Wer Vorteile aus dem Internet ziehen und dort für sich nutzen will, wo wir alle Sozialversicherungsnummern haben, der muss als echte Person präsent und aktiv sein. Das "Web 2.0" wird ein Ort für echte Menschen sein. Herzlich Willkommen in der Wirklichkeit." - Das spricht mir aus dem Herzen. Mit virtueller Praesenz treffen sie im Web echte Menschen. Das sind zwar auch anonyme Chatter, aber der Trend gehtr eindeutig dazu sich selbst darzustellen und nicht eine Kunstfigur. Willkommen beim wahren Leben im Web.

Falls sie das interessiert, probieren Sie doch mal:
http://community.lluna.de (fuer User)
oder:
http://developer.lluna.de (fuer Entwickler)

Ein unmoegliches Bit

Heute mal etwas fuer Experten:

Bei einem Kunden stuerzt ein Videoserver mehrmals taeglich ab. Der Code ist natuerlich fehlerfrei. Deshalb stellt sich die Frage: wieso? Die Antwort: in einem Register des Prozesors ist ein Bit zu viel gesetzt. Der Registerwert wird zum Speicherzugriff verwendet und: Boing, Zugriff auf nicht gemappten Speicher.

Die fragliche Stelle sieht in x86 Assembler so aus:

mov edx,dword ptr [ebp-0Ch] # Load bits into edx
sar edx,cl # Shift arithmetic right by value of cl
and edx,0FFh # Logical AND with 0x000000FF

Nach dem "and" ist der Wert von edx: 0x80000041 statt 0x00000041.
Frage: wie kann das sein? von einem "and" erwartet man, dass es alle Bits plattmacht, ausser der Maske.

Antwort: das kann nicht sein, aber es passiert auf Intels Hyperthreading Prozessoren unter Last etwa jedes milliardste Mal, wenn der Code ausgefuehrt wird. Laeuft der Prozess nur auf einem virtuellen Prozessor, dann passiet es nicht.

Das Problem wurde behoben, durch ein zweites "and edx,0FFh". Das klappt dann meistens. Aber das Warum bleibt. Fehler im Hyperthreading?

Nachtrag: Wir haben beschlossen, dass dieser eine Prozessor fehlerhaft ist und kein grundsaetzlicher Fehler vorliegt.

_happy_coding_

Noch ein Vortrag über Virtuelle Präsenz

Gerade kam die Nachricht, dass mein Vortrag über Virtuelle Präsenz für Communities ins Programm des Virtual Communities Forum 2005 angenommen wurde. Die Veranstaltung findet statt in Kensington Town Hall, Central London, 9-10 November 2005. Titel des Vortrags: "Virtual Presence for Communities". Wieder ein Erfolg in der LLuna Publikationsoffensive. Zwei weitere sind schon eingereicht.

_happy_coding_

Software mit 25 Sollbruchstellen

Angenommen ich schreibe ein Stueck Software. Ich baue wissentlich 25 Stellen ein, die mit einer gerningen Wahrscheinlichkeit schief gehen. Natuerlich will ich, dass alles funktioniert, aber ich kann ein Risiko von 5% je Codestelle nicht ausschliessen. Ich hoffe einfach, dass alle durchgehen. Dann schicke ich die Software zum Kunden. Wie gross ist die Wahrscheinlichkeit, das sie funktioniert? Man koennte jetzt raten: 0,95 ^ 25 = 0,28. Das kann man nicht gerade als zuverlaessige Software bezeichnen. Ein bisschen unprofessionell ist das schon. Wenn ich so programmieren wuerde, wie andere Leute Europaeische Verfassungen machen, dann wuerde ich bald verhungern. Ein bisschen unprofessionell war es schon.

Twincoding Light

Twincoding ist eine der "Empfehlungen" der Xtreme Programming Methodik. Twincoding heißt, dass 2 Programmierer vieles zusammen programmieren.

Aber kann man es sich überhaupt leisten zwei Programmierer mit der gleichen Sache zu beschäftigen? Ich kann ja nicht meinem Kunden sagen: Bei uns ist alles doppelt so teuer, weil wir Twincoding machen. Twincoding muss, um überhaupt konkurrenzfähig zu sein, mindestens so produktiv sein, wie Einzelcoding. Das ist nicht einfach, aber möglich.

Die Theorie sagt, dass man Programmierfehler vermeiden kann durch das zweite Augenpaar. Die Vermeidung der Fehler wiegt den Mehraufwand wieder auf. Das kann nur stimmen, wenn man beim Twincoding keine Fehler macht und beim Einzelcoding mindestens 50 % der Zeit ineffizient mit Fehlern und Problemen verbringt, die man zu zweit nicht gehabt hätte.

Die Annahme, dass beim Twincoding keine Fehler auftreten ist sicher nicht ganz richtig. Teilen wir die Fehlerzeiten ein in Flüchtigkeitsfehler, Denkfehler und Blockaden. Flüchtigkeitsfehler kosten sehr oft wenig Zeit. Sie fallen meist schon beim Compilerlauf auf und werden schnell behoben. Dafür geht es aber um sehr viele Ereignisse. Flüchtigkeitsfehler werden bei Twincoding tatsächlich stark unterdrückt. Hier liegt Twincoding klar vorne. Die Behebung von Denk- und Architekturfehlern kostet wesentlich mehr Zeit, als die von Flüchtigkeitsfehlern. Und nicht nur die Korrektur kostet Zeit, sondern auch die Produktion des Fehlers. Erfahrungsgemäss reduziert sich die Wahrscheinlichkeit für Denkfehler deutlich, aber sie verschwindet nicht. Auch 2 Leute können sich gegenseitig von Unsinn überzeugen. Trotzdem ist sicher die Denkfehlerzeit geringer im Twincoding. Der Vorteil wird allerdings meistens mit einem höheren Kommunikationsaufwand bezahlt, das sich 2 Leute über Modelle und Architekturen verständigen müssen. Der Aufwand ist nicht unerheblich, wenn die beiden nicht sehr kompatibel sind. Die dritte Fehlerzeitquelle sind Blockaden, wenn Detailprobleme den Fluss unterbrechen. Diese können von Tools, Fremdfehlern (z.B. Libraryfehler) oder Informationsdefiziten herrühren und unheimlich viel Zeit und Motivation kosten. Oft kann eine zweite Sichtweise und ein komplementäres Wissen den Konten viel schneller lösen.

Flüchtigkeitsfehler kosten nur wenige Sekunden oder Minuten. Denkfehler kosten zig Minuten oder Stunden, selten Tage. Blockaden kosten oft Stunden oder Tage. Bei allen Fehlerarten kann Twincoding deutlich helfen. Ich schätze, dass gute Programmierer, die Dinge programmieren von denen sie etwas verstehen, aber trotzdem nicht die Hälfte Ihrer Zeit mit Fehlern verbringen, die durch Twincoding vermieden worden wären. Denn ein Teil der Programmierzeit besteht aus Routinearbeiten und Tests, die sich nicht beschleunigen lassen . Ob Twincoding wirtschaftlich gerechtfertigt ist, hängt vom Einzelfall ab. Oft müssen Routinetätigkeiten ins Einzelcoding verschoben werden mit der Gefahr von geringem Synchronisationsverlust. Selbst für den Spezialfall von zwei guten und gut abgestimmten Programmierern kann man keine klare Aussage treffen aufgrund der Reduzierung von Fehlerzeit. Die Effizienz von Twincoding ist fraglich.

Entscheidend ist der Faktor Motivation. Zwei Programmierer lassen sich weniger ablenken. Sie fangen früher an und bleiben länger bei der Sache. Mit anderen Worten: sie lesen nicht morgens Onlinezeitung und 10 mal am Tag zwischendurch Email. Sie verlagern projektunabhängige Wartungstätigkeiten auf den Abend und lassen sich weniger von Zwischenrufen anderer Kollegen ablenken, weil man den Partner nicht gerne warten lässt. Gemeinsame Motivation kann Twincoding ins Plus schieben.

Trotzdem sind 150 Euro pro Team-Programmierstunde ziemlich viel. Wenn man die Kosten reduziert, dann geht Twincoding deutlich ins Plus. Wir ersetzen deshalb gerne einen der zwei Programmierer durch einen Aufpasser. Der Aufpasser muss nicht ein erfahrener Programmierer sein, sondern z.B. ein guter Praktikant. Der Aufpasser vermeidet genauso gut Flüchtigkeitsfehler. Er hat etwas weniger Einfluss auf Denkfehler und Blockaden. Ist der Aufpasser nicht beteiligt an der Architektur, dann kann er wenig helfen Denkfehler zu vermeiden. Andererseits hat der Leadprogrammierer die Chance bei Erklärungen die Denkfehler selbst zu entdecken. Der korrigierende Einfluss des Aufpassers auf Blockaden kann genauso gut sein, wie bei einem erfahrenen Programmierer. Der Aufpasser hat eher ein komplementäres Wissen, als ein langjähriger Kollege und kann deshalb manchmal besser sein, als der zweite Programmierer. Die Motivationsfunktion wird vom Aufpasser genauso gut ausgefüllt.

Zusammenfassend verliert Twincodig-Light wenig Performance gegenüber traditionellem Twincoding während die Kosten deutlich sinken.

_happy_coding_

Gemeinsam surfen mit Miranda Instant Messenger Plugin

Endlich mal wieder Funcoden! 3 Programmiernaechte habe ich gebraucht fuer ein Miranda Plugin. Jetzt koennen Miranda User sich mit LLuna auf Webseiten treffen. Man kann in der Kontaktliste einfach die URLs vom Buddy abfragen. Wenn der antwortet, dann Klick und auf die Seite gehopst.

Link zum download.

Miranda ist ein Multiprotokoll Open Source Instant Messenger. Als Progammierer kann ich Miranda nur empfehlen. Projekt in das Developer Studio werfen, build, fertig. Es gibt wenig Doku, aber Code ist die beste Dokumentation, wenn man durchsteppen kann. Man kann durch den Miranda-Kern und andere Plugins laufen und lernen. Es gibt viele Plugins, auch mit Source, und die Community ist aktiv im Forum und beantwortet Fragen. Super Sache.

_happy_coding_

Die perfekt symmerische Zeit

Gestern abend war die Uhrzeit absolut symmetrisch mit mehreren Symmetrieachsen: 20.05.2005 20:05. Achsensymmetrisch und rotationssymmetrisch mit einer dreizählichen Achse. Ein denkwürdiges Datum und fast niemand hat es gemerkt (danke DF).



Die Zeit war so symmetrisch, dass der Verdacht naheliegt, dass dieser eine Moment vielleicht sogar der Mittelpunkt der Zeit war. Das würde bedeuten, dass Halbzeit ist und sich das Universum jetzt wieder zusammenzieht. Zum Glück sind es noch ein paar Milliarden Jahre.

_happy_coding_

Richtige Software is fett

Beim Programmieren verwendet man ja immer mal wieder ein Code-Snippet aus dem Internet, von einem Kollegen oder aus dem Samplecode des Herstellers. Dann noch ein paar Controls, Datasets und Formulare aus dem Designer und fertig ist die schlanke Anwendung. Schoene Programmierwelt, aber leider nicht die Realitaet. Denn richtiger produktiver Code ist fett. Die kleinen Codeschnipselchen, die mit wenigen Zeilen unheimlich tolle Sachen tun, gehen unter zwischen Massen an Code, die eine richtige Anwendung braucht.

Fangen wir an mit der Fehlerbehandlung. Regel: Alles was schiefgehen kann, geht mal schief, denn wenn 1000 User eine Funktion 1 Mio. mal verwenden, dann schaffen Sie die seltsamsten Bedingungen. Das heisst, dass jeder Pfad im Programm einmal abgelaufen wird und jede Funktion die schiefgehen kann auch mal schiefgeht. Benutzt man eine Funktion, die schiefgehen kann, dann muss man einen potentiellen Fehler fangen und bearbeiten. So werden aus einer Zeile leicht 5, denn der Fehler wird geloggt, und dann recovert, und zwar nicht in einem catch fuer 10 Statements, sondern einzeln, denn jedes Statement produziert characteristische Fehler.

Spezialfaelle: Das kennt jede Programmiererin. Ein Formular zeigt Werte aus der Datenbank an. Praktisch eine 1-zu-1 Abbildung. Aber der Kunde will, dass wenn im Feld A eine 5 steht, dann soll das Feld B eine Combobox sein mit den Werten aus Tabelle C statt dem einen Wert aus Tabelle D. Und schon kommt das dicke if-Statement mit einer Seite Spezialcode. Die Welt ist eben nicht rechtwinklig.

Toleranz: Benutzer machen tatsaechlich Fehler. Manchmal dumme Fehler, manchmal verhalten sie sich einfach nur anders, als die Programmiererin sich das gedacht hat. Die Software ist natuerlich so tolerant alle Eingaben zu pruefen, denn wenn der Benutzer sich seine Daten selbst kaputt macht, dann findet er ja trotzdem das Programm bloed und nicht sich selbst und das wollen wir nicht. Dann sind da noch die Anpassungen fuer fehlerhafte Systemsoftware/Libraries oder andere Programme. Andere Programme sind nicht besser, als User. Sie machen Fehler und trotzdem sollte unser Programm weiterlaufen. Also: tolerant sein.

Programmierhilfen: Testcode, Testfeatures, Debugcode, Live-Konfiguration, Remoteinspection, vielleicht ein kleiner HTTP Server mit HTML Interface als Statusanzeige, Laufzeitparameter online aendern? Automatische Ueberwachung und Fehlervermeidung: immer wieder pruefen, wie lange die Threads schon laufen, wie voll die Queues sind, ob etwas zu fixen ist. Datenbankschema erzeugen, falls das Programm gestartet wird ohne die Datenbank einzurichten. Das faellt schon fast wieder in die Rubrik Toleranz.

usw...

Das alles will eine richtige Applikation haben. Deshalb: keine Angst vor viel Code. Richtiger Code ist fett, weil er viel kann.

_happy_coding_

Designing a Distributed Virtual Presence System

AMCIS 2005 - Americas Conference on Information Systems, vom 11.bis 14. August in Omaha, Nebraska (USA) statt. Vortrag "Designing a Distributed Virtual Presence System".

Abstract:

The article describes a research project on virtual presence, which strives to populate the Web. The Web is extended by a new layer that shows users on Web pages while they are present at virtual locations. The document first describes the requirements for a large scale distributed system that fits to the Web. The requirements lead to design decisions which build upon a publicly available messaging infrastructure. The paper presents a feature rich implementation and describes our experience with real users. It finally shows what virtual presence means for virtual communities.

Endlich

Kommentiert ein Fussballer, bevor er ein Tor schiesst? Nein, er schiesst das Tor und laesst andere kommentieren. Warum soll ich Code kommentieren? Endlich kann man andere kommentiern lassen in meinem persoenlichen Stil: der Commentator

Ausserdem noch: Der Buerostuhl fuer die Xtreme XP Programmierer.

_happy_coding_

Virtueller Raum

Letztes Wochenende hab ich eine neue Form von Buddyliste entdeckt. Man kennt ja ICQ, MSN Messenger usw. Aber ich verwende Teamspeak. Teamspeak ist meine Buddyliste mit Sound. Teamspeak ist eigentlich ein IP-Telefonsystem fuer Gruppen in Computerspielen. Vor allem in Shootern (Counterstrike, Battlefield) koordinieren sich Leute mit Teamspeak. Wie funktioniert das? OK, Programm laeuft, es loggt sich am Teamspeak Server ein. Ich spreche was. Wird komprimiert, zum Server geschickt. Andere sprechen auch. Der Server mischt alles zusammen und schickt die Summe wieder zurueck. Alle hoeren, was alle sagen. Ganz einfach. Im Programmfenster sieht man, wer gerade online ist. Das ist meine Buddyliste. Aber nicht so lahm, wie ICQ, sondern live. Ich schalte Computer an, Teamspeak loggt sich automatisch ein und ich fange an zu sprechen. Meine Freunde hoeren mich. Ich hoere sie. Es ist wie wenn wir alle in einem Raum sitzen. Man laesst es einfach nebenher laufen und sagt was, wenn man was zu sagen hat. Always present, always on.

Sowas brauchen wir fuer LLuna auch. Auf eine Webseite gehen und einfach sprechen. Die, die auf der gleichen Seite sind hoeren es. Virtual Presence at its best.

_happy_coding_

Understand what you are doing

Bluehands bildet aus. Wir haben BA Studenten und Praktikanten. Wer bei uns arbeitet, lernt viel. Wir bringen niemandem das Programmieren bei und schon gar nicht den Spass am Programmieren. Was man bei uns lernt sind Technik und Methodik. Wir zeigen wie man richtig programmiert. Wir nehmen uns dafuer viel Zeit, denn wir haben einen Qualitätsanspruch. Wer bei bluehands gelernt hat, versteht sein Handwerk und kann solide Programmieren. Wir versuchen gute Hobbyprogrammierer zu Profis zu machen.

Eine der wichtigsten Lektionen ist dabei, dass Programmieren kein Gluecksspiel ist. Programmieren is bewusste, kontrollierte, zuverlaessige Konstruktion. Die Programmiererin MUSS verstehen was sie tut. Sie muss jede Zeile begruenden koennen. Code, der nicht mehr gebraucht wird, fliegt raus. Wer Code stehen laesst nur weil es momentan so funktioniert, ohne zu wissen warum und welche Teile wirklich wichtig sind, versteht nicht, was er tut. Das ist ein schlechtes Zeichen, denn auch ueberfluessiger Code tut etwas, und zwar genau dann wenn man nicht damit rechnet, weil man ihn ja nicht verstanden hat. Unverstandener Code ist heimtueckisch. Er springt einen von hinten an, wenn man ihm den Ruecken zudreht; besonders gerne nach dem Deployment der Software beim Kunden.

Deshalb: keine Macht dem unverstandenen Code. Understand what you are doing. Always!

_happy_coding_

FOSDEM 2005

Richard Stallmann

Letztes Wochenende war "Free and Open Source Developers' Europe Meeting" in Bressel. Wenn man je mal tausende Geeks und Nerds sehen will, dann ist das ein guter Termin fuer Europaeer. Viele, viele seltsame Gestalten reden ueber seltsame Dinge. Bei allem Erstaunen muss man sich aber bewusst machen, dass diese Leute die Sachen programmieren, die wir alle benutzen (von MS Windows mal abgesehen). Schonmal von Linux gehoert? FreeBSD? KDE? Jabber? Alles Programme, die von Millionen benutzt werden, direkt oder indirekt. Und trotzdem findet die Konferenz auf einem Unigelaende statt ohne Hochglanz. Die Einrichtungen sind genauso unrasiert, wie die Teilnehmer. Das bestaerkt wieder mal meine These, dass hinter jeder Innovation, hinter jedem Gadget, das die Massen im Alltag verwenden, ein Technofreak sitzt, der das Ding zum Laufen gebracht hat, ohne den Ruhm zu ernten. Den Ruhm und die Hochglanzkonferenzen bekommen die Vertriebler und die Anwender. Wir brauchen das nicht. Wir sind schon froh, dass jemand unsere Werke benutzt. Das bringt uns zum Copyright. Richard Stallmann (GNU) ist traditionell einer der Hauptredner der Veranstaltung. Er propagiert einen 10-jahres Copyright Schutz fuer viele Werke, aber absolute Freiheit ohne zeitlichen Schutz fuer funktionale Werke inclusive Software. Die Vorstellung sieht so aus: ein typischer Linux-Admin mit Rauschebart und laaangen Haaren steht in Struempfen auf der Buehne eines Hoersaals und filosofiert ohne Folien. Alle finden das OK. Content ist King.

Ich will User

Ich habe ein tolles Stueck Software programmiert. Und praktisch it es auch noch. Das finde nicht nur ich sondern hunderte von Testern. Wenn 80% aller zufaelligen Testuser die Software toll finden, kann das nicht so falsch sein. Komischerweise gibt es aber nur wenige richtige User. Sogar die begeisterten Testuser wundern sich, dass es nur wenige User gibt. Eigentlich sollte man meinen, dass es sich per Mund-zu-Mund Propaganda rumspricht und schnell viele User bekommt. So ist es aber nicht. Nur ab und zu kommt jemand zufaellig auf der Homepage vorbei, macht den Download, installiert, probiert und findet es gut. Und dann ... nichts weiter. Keine Mund-zu-Mund Propaganda, keine Massen von Usern. Es geht natuerlich um LLuna. Was ist falsch?

Ideen bitte an wolf@bluehands.de.

Trotzdem: ich gebe nicht auf. Moralische Unterstuetzung bitte an wolf@bluehands.de.

_happy_coding_

1 Mio mal fast nichts

Moderne Prozessoren sind rasend schnell. Sie machen eine Milliarde Operationen pro Sekunde. Manche auch 2, 4 oder 10, aber das ist so die Groessenordnung. Deshalb meinen manche Leute sie koennen dem Prozessor auch viel zumuten. Falsch! Prozessorzeit ist ein kostbares Gut. Sie muss gehegt und gepflegt werden weil sie sonst viel zu schnell aus ist. Jede Instruktion will bedacht sein. Nicht jede Prozessorinstruktion, aber jede Codezeile. Natuerlich nicht immer, aber immer in Schleifen, die 1 Mio mal durchlaufen werden. Und das ist das Thema hier: Wenn du etwas 1 Mio mal tust, dann tue FAST nichts.

Obwohl Prozessoren rasend schnell sind, ist einfach nicht mehr drin. 1 Mio mal in Speicher schreiben, um ein Array zu initialisieren ist OK. 1 Mio mal addieren ist auch OK, wenn man nicht erwartet, dass es nur eine Mikrosekunde dauert, aber lege NIE 1 Mio Objekte an. Das bedeutet 1 Mio mal Memory Management. Als Faustregel gilt, Memory Management ist 1000 mal so teuer, wie Memory schreiben. Also kosten 100 malloc oder new dann 1e9 Zyklen. Das dauert eine ganze Sekunde. Das ist nicht schnell. Und wenn die Applikation fertig ist, dann wird es noch schlimmer. Dann kommt jemand auf die Idee das ganze als Serveranwendung mit 100 Usern zu betreiben. Wenn das alle User machen, dauert es 100 Sekunden.

Deshalb: Wenn man etwas sehr oft tut, dann besser fast nichts. Auch im Zeitalter der Gigaherzen.

_happy_coding_

Entspannung

Wenn man angestrengt programmiert braucht man auch ab und zu etwas zur Entspannung. Was bei mir gut gewirkt hat war meine handbetriebene Holz-Klapsmühle. Die brauche ich jetzt nicht mehr, weil ich mich bei World od Warcraft entspanne. Alle, die keine Online-Rollenspiele spielen wollen, können meine alte, aber gut erhaltene Klapsmühle, auf Ebay kaufen

Tue Gutes und logge es

Kürzlich im aktuellen Projekt: Der Projektleiter mahnt nochmals alle Beteiligten, ausführliches Logging zu betreiben. Und zwar nicht nur Fehlerlogging, sondern auch informatives, bzw. gesprächiges (verbose) Logging, dass man im Zweifelsfall zuschalten kann. Begründung: wie soll man einen Fehlerfall debuggen, der beim Kunden ab und zu auftritt. Man will sich ja nicht dahinter setzen bis der Fehler passiert und dann im Debugger durchsteppen. Was man eigentlich will, ist verbose Logging einschalten und sich das Logfile zuschicken lassen, wenn es wieder passiert ist.

Und was passiert knapp 2 Wochen später? Kunde ruft an, hat ein "komisches" Verhalten. Was tut der Projektleiter? Loglevel hochsetzen und wieder darauf warten. Schade, wenn sich nicht alle Entwickler an die Bitte des Projektleiters gehalten haben und genau die fraglichen Teile im Logfile nicht enthalten sind. Das ist teuer. Das kostet Zeit und Reputation. Also: immer fleißig loggen. Gigabytes an Logdaten sind unsere einzige Waffe gegen "komisches Verhalten" von Anwendungen. Von strukturiertem Programmieren, Code Review, Software Patterns, Xtreme Programming einmal abgesehen.

_happy_coding_

SAX sucks

Eine Kritik am SAX Interface

Neulich auf der Jabber Developer Liste: Ein Noob-Developer beschwert sich, dass er das Jabber Protokoll nicht verarbeiten kann, weil das letzte Tag nicht kommt. (Zur Erklärung ein paar Vokabeln: Noob = Newbie (engl.) = Neuling, Jabber = XML-basiertes Instant Mesage Protokoll, das letzte Tag = das schliessende XML-Tag eines XML-Dokuments). Neben den üblichen mailinglistentypischen dümmlichen Antworten, erhält er die wertvolle Empfehlung, einen SAX Parser statt dem DOM Parser zu verwenden. Das ist richtig, denn im Jabber Protokoll wird ein XML-Strom verarbeitet. Der gesamte Strom ist ein einziges Dokument und da dieses nie fertig ist, geht es nicht mit einem DOM Parser. Danach war einen Tag Ruhe, dann kam die nächste Frage etwa so: "Der SAX Parser meldet zu viel und das falsche. Der SAX Parser ist nicht brauchbar. Was nun?"

Da hat er leider Recht. Der SAX Parser meldet nämlich Öffnen und Schliessen jedes XML-Tags und jedes Fitzelchen Daten zwischen den Tags, selbst wenn das nur ein Zeilenumbruch ist. Damit kann der Applikationsentwickler aber leider nichts anfangen. Eine Jabber Message sieht als XML so aus:

<message from='cs@bluehands.de' to='hw@bluehands.de'>
<body>Hallo Welt!</body>
</message>

Der SAX Parser liefert dafür eine Serie von Callbacks:

startElement "message"
characterData "\n "
startElement "body"
characterData "Hallo Welt!"
endElement "body"
characterData "\n"
endElement "message"

Was soll man jetzt damit anfangen? Klar, der Anwendungsprogrammierer muss alle Teilinformationen sammeln bis das Ende der Message signalisiert wird. Dann kann er die gesamte Message auswerten. Anders ausgedrückt: XML hat eine hierarchische Struktur. SAX serialisiert und unterdrückt die Struktur. Der Anwendungsprogrammierer muss die Struktur wieder rekonstruieren. Eine Aufgabe, die in eine Bibliothek gehört. Leider ist sie bei SAX Parsern nicht enthalten. Nu ist an SAX Parsern nichts falsch, denn SAX heisst "Simple API for XML". Man wundert sich nur, warum es nach vielen Jahren XML immer noch keine besseren Schnittstellen für XML-Streaming gibt.

Was man eigentlich will ist eine Mischung aus DOM und SAX. Für die Verarbeitung von XML-basierten Protokollen braucht man einen Parser, der wie eine SAX Parser XML-Fragmente verarbeitet, der dann aber jedes komplette XML-Tag als Struktur liefert, so dass man nicht selbst die Struktur rekonstruieren muss. Also eine Art "Fragment API for XML". Wenn jemand fragt, wie man das Jabber Protokoll verarbeitet, heisst die richtige Antwort: nimm einen FAX Parser, z.B. meinen.

_happy_coding_