27. April 2005

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_

17. April 2005

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.

5. April 2005

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_