Skip to content

etwas Ähnliches wie fertig

Die Geschichte rund um den Achtzig-Prozent-Parser für XML konnte ich dann heute im Prinzip beenden. Will heißen, ich habe jetzt zwei neue Javaklassen gestrickt, die die interessanten Daten aus dem XML herausholen, und in die gewünschte Form überführen, die da Geschäftsobjekte mit bestimmten Ansprüchen an die in ihnen enthaltenen Datentypen haben. Heute wollten nun diese Geschäftsobjekte noch in weitere Objekte verpackt werden, damit sie den Weg aller Daten in der Anwendung nehmen können.

Eigentlich hätte ich mich dann nächste Woche um die Darstellung der Daten im Frontend bemühen sollen, aber daraus wird nun nichts, weil es beim Testen zu einem Engpass gekommen ist, und ich dort aushelfen darf. Die Darstellungslogik wird stattdessen ein anderer Projektmitarbeiter übernehmen dem das wahrscheinlich leichter fallen dürfte, weil der bereits eine Menge Darstellungslogik für die Anwendung gestrickt hat.

Dafür darf ich dann ab nächster Woche die anderen Entwickler mit Bugs quälen, die ich entdecke. Und da werden bestimmt noch Einige vorhanden sein.

eingeschränkt funktionsfähig

Heute durfte ich mich mit einem Problem herumschlagen, das durch einen zu simpel gestrickten Parser für XML-Daten verursacht wurde. Bisher wurde der Parser immer nur mit Daten gefüttert, deren Struktur extra erstellt wurde. Dass ausgerechnet meine erste Entwicklung in der Ecke eine Datenstruktur beeinhaltet, die der Parser nicht verarbeiten kann, ist wohl mein persönliches Pech. So darf ich mich morgen damit beschäftigen, ob ich die XML-Daten nicht besser auf einem anderen Weg interpretieren kann. Aber was tut man nicht alles, um Endanwender glücklich zumachen?

Fehlersuchtag

Heute habe ich den ganzen Arbeitstag damit verbracht, dass ich versucht habe herauszufinden, warum ein bestimmter, für die Anmeldung sehr wichtiger Aufruf in unserer Anwendung auf meinem Rechner (und auch nur dort) nicht funktionierte. Zuerst hatte ich ja die Gegenseite des Aufrufs im Verdacht, aber das dortige Log zeigte nicht einmal, dass mein Rechner irgendwas mit dem System gemacht hätte, geschweige denn, dass dort ein Fehler passieren würde. Dann habe ich das Serverprofil komplett gelöscht und neu aus dem Repository geholt, auch ohne jeden Erfolg. Auch mehrfaches neukompilieren aller beteiligten Klassen brachte mich nicht weiter, genau wie wiederholtes Veröffentlichen (publishen, wie man wohl in Denglish sagt) der Anwendung brachte nichts. Dann habe ich mir einen der externen Kollegen dazugeholt, weil der letzte Woche noch im Umkreis der Aufrufe etwas geändert hatte, aber auch der konnte keine Ursache für das Problem erkennen. Zwischenzeitig fiel der Verdacht noch auf Windows-Patches, die ich heute morgen installiert hatte, aber auch das führte bei den Kollegen zu keinen Problemen.

Kurz vor Feierabend fiel mir dann noch ein, dass ich zur Behebung eines anderen (aber ähnlichen) Fehlers im Zusammenhang mit einer völlig anderen Java-Anwendung ein paar Dateien in ein bestimmtes Verzeichnis des RAD kopieren musste. Kaum hatte ich die Dateien dort entfernt, lief auch alles wieder. Es sieht so aus, als hätte ein FixPack, was wir letzte Woche alle installiert haben in Zusammenhang mit diesem alten Fix zu einem neuen Problem geführt. Und das erklärt dann auch, warum ich der einzige Betroffene war: Die anderen Kollegen hatten die Dateien ja nicht als Fehlerbehebung führ andere Anwendungen einspielen müssen, und folglich trat bei denen das Problem nicht auf.

Sollte mir mal irgendwann langweilig werden, kann ich ja einfach die Dateien dort wieder hinkopieren und abwarten, bis die ersten Aufrufe der Anwendung wieder fehlschlagen.

Die Tischkante, in die ich vorhin gebissen habe, hätte mit einem Schoko-Überzug aber bestimmt besser geschmeckt.

Genug Zeitmord

Heute ging der Zeitmord weiter. Aus irgend einem Grund ließ sich die Sicherheitseinstellung nicht umstellen, und dann kamen noch weitere Änderungswünsche aus dem Test. Mein Projektleiter hatte beim morgendlichen Statusmeeting schon gesagt, dass er sich darum kümmern würde, dass ich die weitere Betreuung der Anwendung loswerden kann. Also bin ich zu dem Mann gegangen und habe ihm von den weiteren Anforderungen berichtet. Die Anforderungen und meine Aufwandseinschätzung hat er dann an unseren gemeinsamen Vorgesetzten weitergeleitet, der daraufhin das Thema Kollegen übergeben hat, mit denen ich die Anwendung bis vor einigen Monaten entwickelt habe.

So verhältnismäßig einfach bin ich das Zeit-Totschlags-Thema losgeworden. Dafür durfte ich mich dann nochmal damit beschäftigen, warum die aktuelle Projektanwendung nicht funktionieren wollte, was aber deutlich weniger Zeit in Anspruch genommen hat. Ab Montag kann ich dann auch wieder meine ganze Zeit dem Projekt zuwenden. Ist vielleicht auch besser so.

Zeit erschlagen?

Heute habe ich den ganzen Tag damit zugebracht, eine Anwendung, die im Test unter bestimmten Umständen intern eine Exception wirft (lies: Es taucht in der Logdatei eine Fehlermeldung auf, die aber weder einen offensichtlichen Grund, noch  erkennbare Auswirkungen hat), auf meinem Arbeitsplatzrechner (wieder) zum Laufen bringen. Seit inzwischen zwei Monaten bin ich in einem neuen Projekt beschäftigt, was mir in der Zwischenzeit eine Neuinstallation meines Rechners eingebracht hat. Die Anwendung, die vorher auf dem Rechner eingerichtet war, habe ich mir seitdem nicht wieder aufgesetzt, dafür gibt es ja zentrale Testserver. Zum Debuggen von (unerklärlich) geworfenen Exceptions sind die zentralen Server allerdings einigermaßen ungeeignet. 

Nachdem ich mehrere Stunden damit zugebracht habe, erst den lokalen WebSphere-Server einzurichten, die Verbindungen zu den entsprechenden Datenbanken zu erstellen (was aus irgend einem unbekannten Grund deutlich schwieriger war, als ich erwartet hatte, und Unterstützung von unseren Datenbänkern benötigte), gab es dann noch einen Patch, den ich einspielen musste, weil ich sonst beim Start der Anwendung ganz andere Exceptions um die Ohren geschmissen bekomme. Warum die Anwendung zum Schluss immernoch meinte, sie müsste sich von alleine anmelden (was nicht funktioniert, weil das nicht vorgesehen ist), werde ich dann wohl morgen erst herausfinden.

Und das alles, um eine eigentlich harmlose Exception zu beseitigen.

komische Idee

Wenn man sich fragt, warum ein Kalenderdatum in Java nicht funktioniert wie erwartet, kann man mal in die Sourcen schauen:
/**
* Value of the MONTH field indicating the
* first month of the year.
*/
public final static int JANUARY = 0;
Wer ist denn bitte auf die selten dämliche Idee gekommen, Monate ab 0 zu zählen?

Lieber nicht nochmal

Wenn der Zugriff auf eine Datenbank per Programm nicht funktioniert, kann man das natürlich mit einem anderen Tool testen. Blöd ist es nur, wenn man beim Testen versehentlich ein DELETE from Tabelle where xy='a'; ausführt. Dass der Zugriff dann gleich klappt, ist ja dank Mister Murphy klar gewesen.

Eigenintelligenz?

Heute auf Arbeit haben wir eine ganze Weile suchen müssen, warum die Anwendung an der wir entwickeln auf einmal nicht mehr starten wollte. Irgendwann brachte uns dann ein langjähriger Entwickler auf die Idee, dass wir doch nach einer bestimmten Java-Datei schauen sollten, was da drinsteht. Die Überraschung war dann, dass die Datei allem Anschein nach verschwunden war. Im CVS war davon auch nicht mehr viel zu sehen. Zum Glück ließ sich die Datei aus einem anderen Programm kopieren und anpassen. Ganz hat das aber trotzdem nicht ausgereicht, so dass wir im CVS nach Überresten der Datei gesucht haben, und letztlich auch fündig wurden.

Die Frage, die sich mir jetzt stellt: Wie konnte die Datei verschwinden, wenn sie doch von niemandem auch nur bearbeitet wurde? Muss man vor einem cvs commit immer besonders aufpassen, ob nicht vielleicht irgendwo eine Datei versteckt ist, damit die auch übernommen wird? Und wie lässt sich verhindern, dass nicht demnächst etwas ähnliches passiert?

produktiv und nachgefragt

Mein erstes kleines Java-Programm ist in Produktion und wird in dieser Woche erstmals eingesetzt werden. Das Programm dient dazu, Dateien an verschiedene Außenstellen meines Arbeitgebers zu kopieren, die durch eine Nummer eindeutig identifiziert werden. Als zusätzliches Schmankerl hat heute schon ein Kollege aus meiner Arbeitsgruppe sich nach dem Programm erkundigt, weil er vor dem Problem steht, Dateien für die Außenstellen kopieren zu müssen, das aber mit seinen Mitteln (insbesondere von der Berechtigung her) nicht machen zu können. Wenn sich dann auch noch bewahrheitet, dass in dem Fachbereich, der das Programm ursprünglich bestellt hatte, Kopier-Aufgaben füpr mein Programm anfallen, wird das wohl mein bisher meistgenutztes Programm in der Firma. :biggrin:

Nochmal Schulungsunterlagen

In den letzten Tagen habe ich mich mal wieder durch Schulungsunterlagen qequält. Diesmal ging es um das Thema 'Enterprise Java Beans' (aka EJB). Das Thema hätten wir zwar theoretisch bei den Schulungen letztes Jahr gemacht haben sollen, aber wir haben dann doch die Themen JSP und Struts noch etwas vertieft. Das heißt, dass das Thema EJB für mich totales Neuland war. Leider haben mir dazu die 'offiziellen' Unterlagen nicht wirklich geholfen. Ich weiß nicht, welche Zielgruppe von den Unterlagen angesprochen werden soll, aber ich fand die Formulierungen deutlich zu komplex, und dafür den Anteil, den Beispiele in Form von Java-Code einnehmen viel zu gering. Heute habe ich mir dann mal die Unterlagen von unserem Schulungsleiter zur Hand genommen, und das genaue Gegenteil erlebt: Diese Unterlagen sind sehr gut verständlich formuliert, und jeder Teilabschnitt wird von einem (auch als Dateien vorliegenden) Quellcode begleitet, so dass man auch am 'lebenden Objekt' verfolgen kann, wie das jeweilige Thema als Programm aussieht. So verstehe ich dann auch, was EJB sind, und wie die eigentlich funktionieren.

Schulungsunterlagen

In den letzten Tagen habe ich mich durch die Java-Schulungsunterlagen gelesen. Allerdings nicht die Unterlagen, die unser Seminarleiter selbst angefertigt hat, sondern die Unterlagen, die Unilog Integrata, der Schulungsanbieter, zur Verfügung gestellt hat. Die Java-Grundlagen fand ich recht gut, aber mit den Unterlagen zu Servlets und JSPs war ich nicht so begeistert. Das lag vor allem daran, dass in den Unterlagen von der RFC 2068 aus dem Jahr 1997 ausgegangen wird, die seit 1999 durch RFC 2616 ersetzt wurde. Einige andere Informationen aus den Unterlagen wirken ähnlich alt (Netscape Navigator 4, anyone?). Ich habe dann beschlossen, die Unterlagen erstmal beisiete zu legen, und mit dem nächsten Ordner weiterzumachen. Dieser Ordner war der Ordner zu Struts, der mir allerdings noch weniger gefallen hat. Der gesamte Ordner besteht aus Bildern einer Präsentation (also aus den Folien), die wahrscheinlich die 'offizielle' Schulung darstellen sollen. Unser Seminarleiter hat allerdings seine eigenen Unterlagen verwendet, die ich auch sehr passend finde. So habe ich den Ordner dann auch beisite gelegt, und mich wieder dem nächsten Ordner gewidmet.

Wünsche ich mir zuviel, wenn ich ausführliche, aktuelle Schulungsunterlagen haben will?

So macht Arbeit Spass

Heute war ich den Vormittag über in einem total langweiligen Meeting. Da wurde (mal wieder) über die Umorganisation (siehe dazu auch Wer bin ich?) geredet, und wie die bestehenden Programme auf eine neue Umgebung portiert werden können. Kurz: es war ziemlich sinnlos, dass ich dabei war.

Nach dem Mittag ginbg es dann mit einem Java-Beitrag weiter. Ich war nicht der einzige von uns Neuen, der nach ner Stunde Ermüdungserscheinungen zeigte. Mein Eindruck von Java und Fließkommaberechnungen: Das Zeug ist in etwa so genau, wie ein Pentium mit FDIV-Bug. Muss ich das jetzt gut finden?

tweetbackcheck