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_
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_
23.12.2004: Schlagzeile: "Putin vereidigt Yukos Übernahme". 5 mal die gleiche Information + 2 Bilder von Putin. Und wieder 2 zusätzliche Sätze auf der dritten Seite.
25.12.2004: Schlagzeile: "Weihnachtsbotschaft des Papstes von Sorge geprägt". 5 mal die gleiche Information + 2 Bilder vom Papst. Und wieder 2 zusätzliche Sätze auf der dritten Seite.
Wir wollen nicht vorschnell urteilen, aber eine gewisse Regelmässigkeit ist zu erkennen.
Warum? Weil Windows besser ist. Nochmal: Windows ist besser, deshalb sind Applikationen in der Praxis instabiler.
Windows bietet unendlich viele Systemkomponenten. Viele Dienste, die man im taeglichen Programmierleben braucht, bietet Windows als API. Das faengt an beim XML Parser, ueber HTTP mit Caching, URL-Behandlung, Embedded Browser, Verschluesselung, bis zu Sicherheitsdiensten und vielen anderen mehr. Als Programmierer bin ich froh, das alles nutzen zu koennen. Warum selbst implementieren, wenn das Betriebssystem das alles bietet? Auf Linux gibt es das alles nicht. Zumindest nicht als System-APIs. Natuerlich gibt es XML-Parser, Verschluesselung, HTTP-Libraries und Browser zum Einbetten. Aber man muss sie sich meistens im Netz beschaffen, selbst nochmals wrappen, moeglicherweise selbst kompilieren und dann dazulinken. Sehr muehsam, wenn man viel braucht, weil diese Komponenten auf Linux (oder Open Source) im allgemeinen eben aus verschiedenen Haenden kommen. Alle mit eigenen Coding Conventions und Interface Conventions.
Bei meinen Windows Anwendungen linke ich gegen LIBs, und benutzt werden dann vom Betriebssystem bereitgestellte DLLs. Bei Linux linke ich die libXX.a oder lege die Shared Libraries dazu. Meine-Windows Anwendungen haben damit Laufzeitabhaengigkeiten vom System. Meine Linux-Anwendungen sind selbst-konsistent. Jetzt kommt eine neue Betriebssystem Version oder (schlimmer) eine Bugfix Release (auch Service Pack genannt). Dann fliegen mir die Installationen der Kunden um die Ohren, und zwar fast nur die Windows Installationen.
Das kommt so: angenommen es gibt bei jedem Systemdienst, den ich verwende eine 0,1 % Wahrscheinlichkeit, dass sich die Semantik einer Schnittstelle, oder das Verhalten oder Abhaengigkeiten geaendert haben. Ich verwende 20 solcher Systemdienste. Ich habe 20 Kunden. Das ganze ueber 5 Jahre bei 8 Systemupdates pro Jahr plus 8 "signifikanten" Konfigurationsaenderungen des Kunden intern. Macht zusammen 30 Notsituationen in denen betriebskritische Dienste beim Kunden nicht laufen. Diese addieren sich zu den ueblichen Bugs, die es eh schon gibt und die erst bei "ungewoehnlicher" Bedienung auftreten. Bei jedem Kunden also zusaetzlich 1-2 mal. Fuer mich bedeutet das alle 2 Monate Emergency-Debugging am Livesystem waehrend der Betrieb eines Kunden steht.
Manchmal wuensche ich mir, Windows waere nicht so gut und ich wuerde alle Dienste wie auf Linux selbst einbinden muessen. Auf jeden Fall sollte man auch bei Windows statisch binden.
_happy_coding_
Meinen Handyvertrag habe ich bei o2. Heute habe ich mir mal das o2 Portal angesehen und ich bin entsetzt. Nehmen wir mal den Nachrichtenteil. Angenommen ich will schnell mal die aktuellen Headlines lesen. Dann passiert folgendes: GPRS Service starten, Startseite kommt,
da steht: "Müntefering kündigt gedrosseltes Reformtempo an". Bild von Müntefering. OK, ich will mehr, klicke auf die Headline. Seite kommt, da steht: Überschrift: "Müntefering kündigt gedrosseltes Reformtempo an". Text: "SPD-Chef Franz Müntefering hat angekündigt, dass Rot-Grün das Reformtempo gedrosseltes Reformtempo im kommenden Jahr drosseln wird, mehr...". User klickt "mehr...". Seite kommt, da steht: Überschrift: "Müntefering kündigt gedrosseltes Reformtempo an". Bild von Müntefering. Text: "SPD-Chef Franz Müntefering hat angekündigt, dass Rot-Grün das Reformtempo gedrosseltes Reformtempo im kommenden Jahr drosseln wird." und dann tatsächlich noch 2 ganze weitere Sätze.
Kann es sein, dass ich jetzt 5 mal den gleichen Satz gelesen habe? Nach der Überschrift musste ich 2 mal klicken und warten, noch 4 mal das gleiche zu lesen, um endlich 2 zusätzliche Sätze zu bekommen.
Soll ich noch was zu den Ladezeiten sagen? GPRS ist nicht langsam. Aber man kann es langsam machen. Bei jeder Seite werden die verdammten o2-Portal Buttons als Bilder wieder geladen. Von Caching keine Spur. Beim BACK zur vorherigen Seite werden alle Buttons wieder geladen. Von Caching keine Spur. Wegen den unsäglichen Menubildern, die nichts mit dem Content zu tun haben, lädt jede Seite 15 Sekunden. 5 davon mit drehender Weltkugel, dann ist 10 Sekunden lang das Bild eingefroren und die Displaybeleuchting geht auch noch aus, wie toll. Man sieht nichtmal, wenn es fertig ist.
Ich wollte mobil Nachrichten lesen. Ich wollte GPRS Traffic erzeugen und bezahlen. Aber nicht so. o2 belastet meine Trafficrechnung mit unnötigen Menubildchen, lässt mich warten und ich darf immer wieder das gleiche lesen. Das war kein Einzelfall. Gestern war es genauso. Anderer Ort, andere Headline, der gleiche Nerv.
Natürlich ist manches davon ein Zusammenspiel von Handy-Browser und Portal. Warum benutzt mein Nokia 6220 keinen Cache? Warum berücksichtigt das Portal das nicht? Aber der größte Teil ist die Schuld von o2. Es geht besser. Ich habe für EPlus iMode Content debuggt. Ich weiss wovon ich rede.
_happy_coding_
Immer wieder kommt es vor, das mal mal eben so nen Code schreibt, um was zu testen, mal eben schnell was kleines zu fixen und was herzuscripten. In solchen Faellen ist man doch immer versucht das mal eben schnell hinzuschreiben ohne auf Formatierung, korrekte Namensgebung, Fehlermeldungen usw. zu achten. Man return-ed mal eben wo es so passt und laesst die Fehlerbehandlung grad mal weg. Die ruestet man ja spaeter nach, falls der Code was dauerhaftes wird. Dann kann man auch gleich alles noch mal richtig benennen. "Ich mach das jetzt mal und wenns laeuft mach ich die Fehlerbehandlung". Pfui.
Das bringts nicht, weil...
1. Wir sind nicht dumm und oft laeuft der Code tatsaechlich.
2. Der meiste hingesketchte Code wird doch nie mehr weggeschmissen sondern weiterentwickelt und wird irgendwann produktiv.
3. Es ist echt uncool spaeter nochmal ueber den Code zu gehen und Fehlerbehandlung nachzuruesten. Dann muss man sich nochmal in alles genau hineindenken. Was fuer eine Zeitverschwendung.
4. Code lebt laenger als man denkt. Was total nervt sind Provisorien, die einem Jahre lang peinlich sind.
5. Ordentlicher Code ist stabiler als unordentlicher. Das gilt auch fuer Testcode.
Nur mittelgute Programmierer, die sowieso viel Code wegwerfen und ueber vieles nochmal drueber gehen muessen, damit es geht, koennen sich das erlauben. Gute Programmierer haben gar keine Zeit dafuer. Die programmieren es gleich richtig, ordentlich und anstaendig.
_happy_coding_
