Veröffentliche Beiträge in “Programmierung”

Für den Normalsterblichen sind Softwareentwickler wie eine eigene Spezies, die den Sprung in ein Leben jenseits von Raum und Zeit geschafft haben. Tag und Nacht, Arbeitswoche oder Wochenende - ihr Leben scheint sich nur um Computer zu drehen. Selbst wenn sie sich in ihrer Freizeit zu kleinen Grüppchen zusammenrotten, handelt es sich meistens um Computerbezogene Probleme, die da besprochen werden. Wer sind diese Menschen, die sich scheinbar Tag und Nacht hinter Bergen aus Monitoren, Rechnern und mit ominösen Krakeln beschriftetem Papier verbergen?

Auf der Seite der Programmierer wundert man sich über die verwunderten Blicke, die einem zugeworfen werden, wenn man versunken in Gedanken über die Lösung eines Problems durch den Gang läuft und jegliche Existenz anderer Lebewesen ausblendet. Man nimmt sie erst wahr, wenn sie vor einem am Arbeitsplatz stehen, von ihren Problemen berichten, welche die neue Erweiterung mit sich gebracht hat und deren Unverständnis, warum man sich weigert, die Funktion des zeternden Anwenders nicht zu implementieren, weil die Effizienz zwischen mehreren Wochen Programmierung und 5 Minuten Zeitgewinn pro halbem Jahr einfach nicht gerechtfertigt erscheint.

Jeder Programmierer ist sich dessen bewußt, dass er ohne die Anwender keine Arbeit hätte, aber manchmal träumt er davon, dass es zu der Lösung, die er sich gerade ausgedacht hat, auch ein Problem geben müßte, das unbedingt umgesetzt werden muss. Deswegen reagieren sie auch unwirsch darauf, wenn ein Anwender kommt und daran etwas auszusetzen hat. Programmierer sind deshalb wie kleine verletzte Gottheiten zu behandeln, die sich auf die Erde verirrt haben. Jeder Anwender wäre erstaunt, wie milde man einen Programmierer stimmen kann, wenn man ihm eine kleine Aufmerksamkeit zukommen läßt und wie bereitwillig er sich auf einmal zur Kooperation zeigt. Hier ein paar Vorschläge zur Konfliktvermeidung beim nächsten Treffen zwischen Programmierer und Anwender.

Softwareentwickler trinken Kaffee. Ja, es gibt auch die Fraktion der Teetrinker, aber die meisten ziehen halt doch das schwarze Lebenselixier vor. Programmierer suchen während ihrer Arbeit immer den "Flow". Es ist der Moment der Einheit zwischen Programmier und seinem Code. Ob es einen wissenschaftlichen Zusammenhang zwischen dem "Flow" und Kaffee gibt, sollte mal untersucht werden. Fest steht: Es ist verdammt schwer reinzukommen, wenn man ständig aufstehen muss oder gestört wird. Deswegen sollte Kaffee immer in ausreichenden Mengen zur Verfügung stehen. Ob der Kaffee noch kochend heiß getrunken wird oder auch kalt noch als genießbar empfunden wird, liegt im Auge des Genießenden. Es ist aber eine Tatsache, die für Programmierertassen gilt: Je größer, desto besser - mit kleinen Näpfchen zieht man sich eher den Zorn des Programmierers zu. Ich empfehle deshalb das Modell Xtra Large zu schenken, am besten randvoll gefüllt. Und man tut auch gleich etwas für die Umwelt, denn Kaffee gehört ja zu den nachwachsenden Energiequellen!

Informatiker stehen ja unter dem Verdacht, nicht besonders kommunikativ zu sein oder sich nur schwer verständlich machen zu können. Wer aber mal das programmierende Volk unter sich beobachtet hat, kommt schnell zu der Einsicht, dass es dort stellenweise schlimmer zugeht, wie bei Tante Elsbeths Kaffeekränzchen. Dabei ist es ja auch klar, dass ein Programmierer nur ungern seine wertvolle Zeit verschwendet, einem unbedarften Anwender seinen letzten fiesen Hack zu erklären, wenn der nicht mal weiß, was ein Kontextmenü ist. Außerdem gehören Programmierer ja nicht nur zur schreibenden Zunft, sondern sind Künstler, die geschickt kleine Buchstabenketten verbinden, um den Millionen von Transistoren ein schönes Bild oder Wunderwerke auf Papier zu entlocken. Deswegen outet man sich gern, jedoch nicht nur deswegen, sondern auch um seinesgleichen sofort zu erkennen. Und als kleine Gottheit genießt der Programmierer den fragenden Blick des Anwenders auf das T-Shirt, verbunden mit der Frage "Was bedeutet denn das?"

Und mit einem Mißverständnis muss noch aufgeräumt werden - der Programmierer und sein Computer haben nicht die harmonische Beziehung, wie es nach außen wirkt. An schlechten Tagen kriselt es doch ziemlich heftig zwischen den beiden, aber eine Trennung ist schlecht möglich, handelt es sich doch um eine Berufsehe. Diese Berufsehe zwischen Programmierer und einem Blechwesen mit einem Herz aus Silizium sorgt stellenweise für reichlich Spannung, da der Computer das wohl sturste Wesen ist, was man sich vorstellen kann. Selbst die schmollende Superzicke verblasst im Schatten eines Computers, der einen kryptischen Fehler ausgibt, den es tagelang zu beheben gilt. Bevor ein Programmierer seine schlechte Laune an die Umwelt weitergibt, empfiehlt es sich den Konflikt etwas eskalieren zu lassen. Der Monitor ist zwar ein peripheres Ziel, eignet sich trotzdem für gezielten Aggressionsabbau mit dieser aufblasbaren Keule. Anfänglich wurde ich müde belächelt für dieses Entwicklungswerkzeug, aber mittlerweile wird sie doch sehr gern mal ausgeliehen und gehört somit in den Schreibtisch eines jeden Softwareentwickler. Aber Vorsicht: Nach Einsatz unbedingt wieder wegräumen, ein nicht eingeweihter Anwender könnte es als Akt der Bedrohung wahrnehmen.

Ich hoffe, ich konnte ein wenig damit aufklären, dass Programmierer auch nur Menschen wie du und ich sind ;)

Nachtrag: Ich habe den Titel mal geändert, denn es hat ja weniger mit Geschenke zu tun. Mir ging es ja mehr um die Kommunikationsschnittstelle Mensch - Programmierer und welche Werkzeuge dort zum Einsatz kommen.

Natürlich habe ich noch das wichtigste vergessen: Der Programmierer sucht nach Identifiktion, dass heißt ein Vorbild, welches mit ihm leidet und seinen Schmerz in Sachen Wünsche und Forderungen von Seiten des Managements und der Anwender kennt. Das kann nur einer - Dilbert.

Wer denkt, Cocoon sei ein Club, ein Label oder ein Film, für den wird dieser Beitrag eine harte Nuss, es geht nämlich um Cocoon, das Web-Entwicklungs-Framework. Mit dem habe ich mich die letzten Tage und Wochen um die Ohren geschlagen und dabei Schritt für Schritt die Schwierigkeit erhöht. Problematisch erweist sich dabei, dass mit wachsender Schwierigkeit auch die Zahl der Webseiten sinkt, die einem weiterhelfen.

Level 1: May I introduce myself?

Um unsere Intranetabfrage vor unerlaubten Zugriffen zu schützen, sollte eine Authentifizierung integriert werden, die Abteilungen erlaubt, darauf zuzugreifen bzw. den Zugriff zu verhindern. Kein Problem - In der Dokumentation zum Cocoon gibt es eine Sektion, die Schritt für Schritt das Einrichten der Authenfizierung erläutert und wo man an welcher Stelle drehen muss, um ein bestimmtes Ergebnis zu erreichen.

Der Abruf einer Webseite beim Cocoon gliedert sich in drei Teile:

• Erzeugen der Daten (z.B. Datenbankabfrage)
• Transformation der Daten (optional)
• "Ausgabe" der Daten

Diese Abfolge wird im Cocoon Pipeline genannt und bleibt für den Anwender völlig unsichtbar - er ruft nur eine Webseite auf, nach deren Namen die entsprechende Pipeline aufgerufen wird. Zur Authentifizierung wird um diese Abfolge ein Päckchen geschnürt, das den Zugriff schützt, der Handler. Der Authentifizierungshandler kennt zwei Pipelines: das Login und die Überprüfung der Nutzerdaten. Ist ein Nutzer eingeloggt, wird nur noch geprüft, ob der Nutzer eingeloggt ist und er auf die Daten zugreifen darf. Also integrierte ich anhand des Beispiels den Handler und ließ die Authentifikation gegen eine XML-Datei laufen. Wie gesagt, ganz einfach...

Level 2: Bürger, ihren Ausweis bitte!

Zur Überprüfung der Login-Daten sollte unser LDAP-Server dienen. Auch hier gab es erstmal kein Problem, im Cocoon ist ein LDAP-Transformator integriert, der mit XML beschriebene LDAP-Abfragen an den Server stellt und das Ergebnis wiederum als XML liefert. Nur beschränkt sich hier die Dokumentation des Cocoon einzig und allein darauf, wie das XML aufgebaut sein soll, was zur Abfrage dient. Also stöberte ich nach einigen Beispielen herum und gewann dabei mehrere Erkenntnisse...

• Die Daten der Authentifizierung werden in Form von XML gespeichert
• Diese Daten müssen einen bestimmten Aufbau haben, um akzeptiert zu werden
• Automatische Anmeldung geht nicht, denn auf die Umgebungsvariablen zurückzugreifen ist sinnlos. Was interessiert mich der Nutzername unter dem der Cocoon läuft? Ich will den Nutzernamen der Nutzers vor dem Browser!

Nach mehreren Anläufen und Versuchen unter Mithilfe unseres Admins hatte ich eine Abfrage fertig, die mir die entsprechenden Daten lieferte. Damit war das Problem erstmal gelöst. Ich konnte bestimmen, welche Abteilung sich anmelden darf und auf welche Seiten sie zugreifen darf. Aber damit hört es ja nicht auf...

Level 3: Im Zentrum der Maschinenwelt

Das Problem besteht ja nicht darin, nur eine Abteilung zuzulassen und die anderen auszusperren. Nein, unterschiedliche Abteilungen sollen auf verschiedene, ja sogar gleiche Seiten zugreifen können. Das Problem war: 1 Abteilung = 1 Authentifizierungshandler und 1 Webseite = 1 Authentifizierungshandler. Alles klar? Nö? Na dann... Ich kann den Zugriff auf eine Webseite nur mit einem Handler schützen. Dieser Handler überprüft die Nutzerdaten so, dass sie genau einem Kriterium entsprechen, in diesem Falle der Zugehörigkeit zur Abteilung. Also geht es nicht so einfach, zwei Handler auf eine geschützte Webseite zu bringen. Lösungsmöglichkeiten:

1. Jeweils eine Pipeline pro Abteilung, aber mit unterschiedlichen Handlern (schlechte Idee, weil eine Unmenge an Code entsteht, der redundant ist)
2. Für jede Mischungskombination von Abteilung einen neuen Authentifizierungshandler schreiben (ganz schlechte Idee, denn die Kombinationsmöglichkeiten wachsen mit n! [sprich: n Fakultät])
3. Es gibt einen Handler, der nur prüft, ob die Abteilung auf die Intranetabfrage zugreifen darf. Mit den Nutzerdaten, die von der Authentifizierung als XML abgelegt sind, kann bestimmt werden, welchen Menüpunkt sie sehen dürfen und welchen nicht (Fantastische Lösung - das Menü baut sich dynamisch zusammen, je nach Login-Daten)

Die letzte Lösung klang nur zu schön. Seit Montag hab ich mich (neben anderen Sachen) damit herumgeärgert. Man suche im Netz: Eine Möglichkeit in einer eXtensible Server Page (XSP) das XML der Authentifizierung auszulesen (Die XSP gehört in der Pipeline in den Bereich der Datenerzeugung). Mit XSP kann man prima XML erzeugen und in der Transformation kann ich prima die Authentifizierungsdaten auslesen (Tja, leider zu spät), aber dazwischen - nichts! Bis heute Nachmittag... ich kämpfte mich schon durch die Javadoc's des Cocoon, als ich plötzlich die Lösung fand. Zwar etwas unorthodox, aber es ging...

UserState ustate = ((UserState) <xsp:expr> <xsp-session:get-attribute name=
   "org.apache.cocoon.webapps.authentication.components.
   DefaultAuthenticationManager/UserStatus"/></xsp:expr>); if (ustate.hasHandler()) {    UserHandler uhand = ustate.getHandler("handlername_as_defined_in_sitemap");    String username = uhand.getUserId();    ... }

Und wie drücke ich das am besten für Menschen verständlich aus? Man bekommt die Hauptspeise serviert und möchte aber schon wissen, was es als Nachspeise gibt. Die steht aber im Kühlschrank. Also guckt man, während die Hauptspeise serviert wird, durch die offene Küchentür und erkennt anhand der Sauerei in der Küche, was es als Nachtisch gibt. Deswegen müssen Programmierer immer so viel logisch denken - sonst gibt's keinen Nachtisch :roll: Au weia... ich muss gehen...

Erstmal grimmig gucken... Am Wochenende wurde mir witzelnd die Frage gestellt, wann denn mal eine neue Ausgabe von "Besser programmieren für die Welt von morgen!" erscheint. Ziemlich sicher antwortete ich darauf, dass ich doch nun mittlerweile alle Bugs beseitigt hab und es wohl keine weiteren Ausgaben geben wird. Naja klar, solange bis man das nächste Mal auf Arbeit geht - Danke, Herr Murphy.

Kurze Schilderung des Problems: Ich muss einen Betrag aufteilen und durch interne Berechnungen und Rundungen kommt es zu einem Differenzbetrag zwischen dem aufzuteilenden Betrag und der Summe der Einzelbeträge. Und nun stolperte ich beim Durchsehen der Tests, dass statt einem Cent eine Differenz von 0 Cent ausgegeben wird. Ich schob die Schuld natürlich wieder auf die Konvertierungsroutine, denn eine fix reinprogrammierte Ausgabe zeigte mir auch einen Betrag von einem Cent an. Merkwürdigerweise konnte ich dort keinen Fehler finden. Gaukelt mir etwa der Rechner was vor? War die Differenz von einem Cent auch wirklich ein Cent? Also zog ich von dem Betrag den Wert von 0.01 ab und ließ mir das Ergebnis ausgeben. Vermutung war vollkommen korrekt, denn die 0.01 war in Wirklichkeit eine 0.009999999999998. Und damit rutschte sie in dieser Routine an der Rundung der Nachkommastellen vorbei.