Programmierpraktiken, die nach der Wiederbelebung der Inquisition schreien:

[flaite]

Das sieht mal wieder nach einer längeren Serie aus.
Früher hatte ich Erklärungen für den unglaubliche Unsinn, der in dem Code der von mir betreuten Notes Programmen stand.
Notes Programmierer sind eben schlecht ausgebildet und wissen es nicht besser.
Das Leben war einfach. Es gab Hoffnung.
In den letzten Jahren bin ich schlauer geworden:
Es liegt an der Menschheit als solche.
Oft jahrelang an irgendwelchen "Hochschulen" hochgepäppelte Java-Programmierer schreiben den gleichen Unsinn. Der einzige Unterschied ist, dass sie sich für noch großartiger halten als Notes Programmierer zur widerwärtigen Hype-Zeit 1999/2000 und deshalb naturgemäß mehr Unsinn verzapfen.

Vieles ist versucht worden:
- Entwicklungs-Hilfe von Programmierern aus Indien
- Zertifizierungen
- Tonnen vom Schulungsmaterial im Web

Es hilft leider alles nichts. 

Beispiel Nummer 1:
Programmierer haben die völlig überkomplizierte XML-DOM Api geschaffen. Die gilt nicht für eine reale Programmiersprache. Nein. Sie gilt für alle Programmiersprachen zusammen. Im Internet können Programmierer stundenlang über die "Überlegenheit" (haha) der Features der von ihnen gewählten Programmiersprache streiten. Aber wenn es dann ans anwenden geht, dann wird eine "gemeinsame" Spezifikation gewählt. Eine Api, die unabhängig von der Sprache funktionieren soll. In der also die angeblich so "wichtigen" Spezialfeatures der einzelnen Sprachen gar nicht anwenden kann.
Einige schlaue Leute haben dann Jahre später in Java festgestellt, dass die XML-DOM Api unnötig kompliziert ist. Zur Abhilfe haben sie einfachere, javaspezifische Apis angeboten. Natürlich nicht eine, sondern direkt mehr als 8 konkurrierende oder so, wovon dann 2 oder 3 häufig benutzt werden.
 
UND WAS MACHT NUN DER JAVA-ANWENDUNGSPROGRAMMIERER?
Richtig. Er benutzt die einfachere Api. Schliesslich muß es einen Grund geben, dass die 8 konkurrierenden Apis jeden Monat in "Fachmagazinen" vorgestellt werden. Er benutzt dann aber nur 40% der Features "seiner" einfacheren Api. Den Rest der Api interessiert ihn nicht. Schliesslich kann man sich aus dem Document Objekt prima ein w3c-xml-dom-Document genererieren. Und dagegen kann er ja prima die XML-DOM Api benutzen. Zwar ist die komplizierter, aber für bestimmte Aufgaben kennt er die Methoden auswendig. Natürlich erzeugt das einen wahnsinnigen Overhead. Aber egal. Hauptsache man kann das Feature abhaken. Und der nächste Programmierer muß dann direkt 2 Apis beherrschen, um aus dem Code schlau zu werden...

[m3]

http://de.wikipedia.org/wiki/Constitutio_Criminalis_Theresiana

[animate]

Wo ist Beispiel Nummer 2? 

[flaite]

Danke.
Als nächstes folgt ein Aufsatz über das Thema:
"Rum-Mantschen wie damals im Sandkasten: Das Zusammenklabüsern von halbstrukturierten Datenstrukturen mit XML oder Lotus Notes."

[Fedaykin]

Au ja, da freu ich mich schon drauf. 

[flaite]

Gehts noch? 
Nachdem ich eben 90 Minuten dafür gebraucht hab unter meinen 4 vorhandenen WebProjektAufTomcatErzeugenDeployenUndDebuggen Eclipse Projekt "Wizzards" (haha) den Funktionierenden zu finden (Web/Dynamic Web Project) bin ich jetzt dabei unter meinen über 100 Eclipse Wizzards den richtigen für das Erstellen eines Servlets zu finden (war im letzten Jahr kein Webentwickler und plug-ins Moden wechseln verdammt schnell). Werds mal mit Web/Servlet versuchen.
Aber spätestens nach der Installation von MyEclipse wird Eclipse echt unübersichtlich, wenn man was neues macht.
Frag mich ob meine "Ey.das.ist.ja.wohl.sowas.von.Nineties"-Reaktion auf die hiesige Anhänglichkeit zum (technisch nicht mehr dem aktuellen Stand entsprechenden) Sysdeo plug-ins richtig war. Auch mit Sysdeo kann man auf Tomcat deployen.

Select a wizzard. Achte auf den Balken rechts.

Gruß Axel

[flaite]

Was auf unserem schönen Welt mit dem eigentlich brauchbaren Swing Framework passiert, ist eindeutig ein Fall für das Haager Kriegsverbrechertribunal. Swing wird ungefähr so behandelt wie Kommunisten in Chile/Argentinien zwischen dem 11.09.1973 und dem Sommer 1978. Oder Juden in der Ukraine zwischen 1941 und Anfang 1944.
All diese jungen Java-Programmierer fühlen sich im Grunde zu erhaben dafür. Schliesslich fühlen sie sich als krasse Främwörk- Enterpreis-Progrämmer. Swing Programmierung halten sie für eine Zumutung und so verhalten sie sich. Es wird fröhlich nach unordentlichen Abkürzungen gesucht. Zum Bleistift deklariert man das GUI in phonky http://www.swixml.org xml Dateien. Das sieht dann schön enterprisey aus.
Irgendwann stellen sie dann fest, dass man GUI Felder, Checkboxen, etc. nicht nur hinmalen muss. Oh nein. Das Programm muß unter Umständen auch einmal auslesen, was der User in diesen schönen Feldern so eingetragen hat. Was eine große Überraschung! Tja. Und leider muss man dann alle verwendeten Swing Objekte nochmal neu in einer eigenen GUI-Klasse deklarieren mit gettern und settern. Aber vielleicht ist es denen wichtiger, dass sie überhaupt eine xml-Datei haben, weil das so främewörk-enterprisey ist. Struts hat das ja auch.

Als Layoutmanager nehmen sie natürlich GridBagLayout. Schliesslich ist das einfach nur ein Attribut in der xml Datei. <panel Layout="GridBagLayout()">. Und die Kugel des Verhängnisses ist ins Rollen geraten... In ihrer Google Suche haben sie irgendwo gelesen, dass der komplexeste Layoutmanager so heisst. Und das ist ja wohl klar der Mindeststandard für jeden sich selbst respektierenden  enterpreisy främewörker. Soll sich doch der nächste Programmierer darum kümmern, wie er dort einen neuen Button einfügt. Vielleicht kann er ja mit viel Glück die richtigen Parameter für weightX, weightY ausknobeln, so dass das nicht völlig bescheuert aussieht. One never knows.
Projektmanager: „Wir brauchen rechts noch einen Button“
Programmierer: „Das dauert 2 Tage“.
Projektmanager: „Ist die Funktionalität mit dem http Zugriff aus der GUI über SSL wirklich so schwierig“.
Programmierer: Nö. Das geht mit Errorhandling in 2 Stunden. Das Problem ist die Platzierung des Buttons in einem Container mit GridBagLayout.“
Oh. Ich mag das.

Und dabei hat Sun in den letzten Jahren eine Menge Energie in Swing gesteckt. Carsten Lentzsch, Romain Guy, Scott Delap, Hans Mueller, Chat Haase haben tolle Sachen für Swing entwickelt und sich den Mund fusselig geredet, damit auch struts-aficionados eine "faire" Chance bekommen zu verstehen. Damit kann man Swing GUIs entwickeln, die nicht zu einem hoffnungslosen Urwald verkommen.

Wann immer ihr solchen Unsinn begegnet, schreibt es um. FormLayout von Carsten Lentzsch. Sowieso die von Scott Delap in seinem Buch beschriebenen Konzepte. Das Buch hat ca. 334 Seiten.