Compyblog

Heute beim Testen unserer neuen Anwendung. Es ging darum, dass eine Reihe von Einstellungen für einzelne Tester zurückgesetzt werden sollten. 

F: Wie ist deine (ID-)Nummer?

A: $Name. Ähm, $Nummer.

So kommt man auch beim trockenen Testgeschäft mal zum Schmunzeln.

Heute konnte ich mal wieder live miterleben, dass doch man in Räume gelangen kann, für die eigentlich nur ganz speziell berechtigte Personen Zutritt haben, wenn man genügend sicher auftritt. Zitat dazu:

"Hallo, mein Name ist $Name. Ich würde Sie gerne kennenlernen." (sprach eine Frau (externe Kollegin) zu einem Systemverantwortlichen, der gestern dafür gesorgt hat, dass sämtliche Tests unserer ziemlich großen Anwenung mit einem Schlag abgebrochen werden mussten.

Wenn man in ein Programm extra Logik einbaut für einen Fall, der in der Wirklichkeit nicht passieren kann, ist das dann paranoid oder besonders sicher?

Konkret geht es um eine Adresse, die niemals leer sein kann, weil die Datenbank die Felder als NOT NULL definiert, und das Frontend eine leere Eingabe als nicht zulässig verweigert. Aus irgend einem Grund findet sich im Testbestand ein Datensatz, den wohl jemand per update set Feld = '' where bla='irgendwas'; manipuliert haben muss. Im Frontend lässt sich der Satz so jedenfalls nicht speichern. Nun habe ich auf besonderen Wunsch der fachlich Verantwortlichen Logik eingebaut, die im Fall, dass die Adressfelder leer sind, dafür sorgt, dass dann nicht nichts angezeigt wird. Als ob wir nicht noch genügend Fehler in der Anwendung vergraben hätten.

Heute war mal wieder der erste Tag für einen neuen Jahrgang von Azubis. Dass mir eben diese neuen IT-Azubis auf meinem Weg zum Frühstück begegnet sind, war Zufall, aber ganz okay. Immerhin werde ich im September genau den Azubis eine kleine Einführung in den Großrechner verpassen. Ich bin jedenfalls schon gespannt darauf, mit welchen Vorkenntnissen dieser Jahrgang so zu uns gekommen ist.

"Du bist schuld. Habe ich jetzt beschlossen."

Gut, dass das geklärt ist, dann können wir ja jetzt daran gehen, das Problem dahinter zu beseitigen :biggrin:

Heute ging die Odyssee ohne den XML-Parser weiter, was dann dazu geführt hat, dass ich ein paar ziemlich spezielle Klassen gestrickt habe, die netterweise sogar das tun, was ich von ihnen erwarte.

Nebenher habe ich dann mal durch einen kurzen Test festgestellt, dass ich einen anderen Wunsch eines völlig anderen Fachbereichs ohne Programmierarbeiten bedienen kann, weil ich bei der Entwicklung eines kleinen Kopierwerkzeuges gleich geringfügig mehr Aufwand auf mich genommen habe, was sich eben nun auszahlt.

Und noch mehr nebenher beweist der neue Oberhäuptling über ein Thema, mit dem ich bis vor einigen Jahren zu tun hatte, dass er wohl weder die Wünsche eines Fachbereichsanwenders (da steht ausdrücklich etwas von einem Standalone-PC) verstanden hat, wenn er sich gegenüber dem Oberhäuptling der Entwickler ausheult, wie böse das Rechenzentrum doch wäre, dass die dortigen Verantwortlichen nur bestimmte, eng definierte Rechnerinstallationen im produktiven Netz erlauben. Dass seine Leute den Rechner für den Fachbereich betreuen würden, steht allerdings ausdrücklich nicht in einem Schreiben, was eben dieser Oberhäuptling am Montag in die Welt geschickt hat. Daran ändert sich auch nichts, wenn er das jetzt behauptet (als "Klarstellung"). Da freut man sich dann doch auf das Outsourcong, wenn dann für solche Eskapaden Rechnungen erstellt werden können...

Irgendwie ist mir auf Arbeit alles andere als langweilig.

Als vorhin ein Kollege davon sprach, dass "wir" uns beim Frühstück zurückgehalten hätten, musste ich folgende Frage einfach loswerden:

"Sprecht Ihr schon im Majestätsplural, Hoheit?"

Ein anderer Kollege, der dabei stand (aber beim Frühstück nicht dabei gewesen war), hatte hörbar Schwierigkeiten, weil sein Kakao dringend durch seine Nase wollte. :biggrin:

Für ein Projekt auf Arbeit habe ich mich kürzlich mal etwas mit der Windows-API beschäftigen dürfen. Die Aufgabe sah so aus, dass ein Programmfenster eines anderen Programmes geschlossen werden sollte.

Nun gibt es in der User32.dll eine Funktion mit dem einladenden Namen CloseWindow. Also denke ich mir so, dass die wohl dafür gedacht ist, wenn man ein Fenster schließen will. Wäre ja irgendwie logisch. Aber nein, wenn man der CloseWindow-Funktion ein Fensterhandle reicht, dann minimiert die das Fenster nur. Naja, irgendwie so ganz offen ist das Fenster zwar nicht, aber naja. Also habe ich weitergesucht, und die martialisch klingende Funktion DestroyWindow gefunden. Wenn man mal von der Assoziation absieht, dass mein Programm dann mit einem Raketenwerfer das 'feindliche' Fenster bearbeitet, könnte man ja annehmen, dass nach der Zerstörung eines Fensters eben dieses weg wäre. Also habe ich auch das getestet, aber ohne jeglichen Erfolg. Das zu Testzwecken verwendete Notepad hat sich von den Angriffen gänzlich unbeeindruckt gezeigt.

Nach weiterer Recherche bin ich dann über ein Codebeispiel gestolpert, bei dem dem betreffenden Fenster eine Meldung WM_CLOSE geschickt wird, wonach sich das Fenster dann üblicherweise schließt. In der Dokumentation, die ich mir dann zu dem Thema noch verabreicht habe, stand dann noch, dass die Standardimplementation der Nachrichtenbehandlung nach Erhalt der WM_CLOSE-Meldung einen DestroyWindow-Aufruf absetzen würde. Hmm, okay, dann darf sich ein Programm wohl nur selbst wegbomben. Naja, solange es funktioniert.

Der testweise behandelte Editor hat sich dann auch brav beendet, und im Fall von ungespeicherten Eingaben den Nutzer mit einer Rückfrage auf den Umstand hingewiesen. Okay, works as planned. Dass sich hingegen ein bei weiteren Tests herangezogenes Explorerfenster gegenüber dem Schließungswunsch völlig verschließt, verwundert dann schon. Aber vielleicht wäre dort ja ein CloseWindow angemessener?

Heute früh haben bei der Bahn diverse Berufsgruppen gestreikt, unter Anderem die Lokführer. Unpraktischerweise auch die, die sonst für die S-Bahnen in Hamburg zuständig sind. Außer mir hatte das wohl so ziemlich Jeder mitbekommen, was dann dazu geführt hat, dass bei meiner Ankunft bei der Arbeit keine ordentlichen Parkplätze mehr frei waren. So blieb mir dann die Wahl, mich auf einen Parkplatz für 2 Stunden, in die zweite Reihe, oder quer in eine gerade zu knappe Lücke zu stellen. Ich habe mich dann wohl oder übel für die halbe Lücke in quer entschieden, weil ich da noch die geringste Chance auf ein Knöllchen gesehen habe. Mal ganz davon abgesehen, dass ich Recht hatte, habe ich mich aber doch über den dämlichen Streik geärgert, weil der eben vor allem die berufstätige Bevölkerung trifft, und die Bahn dann nur indirekt negative Auswirkungen (wenn überhaupt) erfährt. Warum bestreiken die Lokführer nicht einfach die Güterzüge, deren Ausfall nicht so sehr die normale Bevölkerung erwischt, sondern eher die Geschäftskunden, und die Bahnführung? Meine Sympathie haben sich die Lokführer dadurch jedenfalls nicht gewonnen, auch wenn ich den Wunsch nach mehr Geld (Laut Nachrichten: bis zu 31 Prozent?!) ja im Prinzip verstehe.

Unbestätigten Gerüchten zufolge soll ich ja gestern Geburtstag gehabt haben. Deswegen haben mir heute auf Arbeit einige Kollegen kondoliert gratuliert. Interessant fand ich, wer sich wann und wie bei mir gemeldet hat. 

Besonders bemerkenswert fand ich, dass sich ein ehemaliger Vorgesetzter in meinem Büro eingefunden hat, um mir persönlich die Pfote zu schütteln, während dessen Nachfolger mir telefonisch zu meinem fortschreitenden Alter gratuliert hat. Dass mein Vorgesetzter eine Ebene höher sich heute weder per Mail, Telefon oder gar persönlich gemeldet hat, finde ich allerdings schade.

Dafür ist einigen der externen Kollegen nicht aufgefallen, dass ich heute eine größere Anzahl Süßkram auf meinem Bürotisch bereitgestellt hatte. Aber einen Keks haben sich die Kollegen dann nach kurzer Gedächtnisstütze doch verdient. :biggrin:

Heute war der erste Arbeitstag eines Kollegen, der das letzte halbe Jahr erkrankt war. Ich durfte dann auch mal einen Blick auf sein Mailprogramm werfen, wo sich 370 Mails angesammelt hatten. Ich gehe mal davon aus, dass ungefähr 350 der Mails auch ganz gut gelöscht werden könnten, weil sie ohnehin irrelevant geworden sind. Oder wen interessiert, dass vor einem halben Jahr Abends die Stromversorgung unterbrochen wurde?

Heute auf Arbeit durfte ich mich den ganzen Tag damit rumschlagen, dass aus unbekannten Gründen mein User in der produktiven Windows-Umgebung immer wieder gesperrt wurde. Nun kann man ja meinen, dass das egal ist, schließlich haben wir unsere eigene Entwicklungsumgebung. Aber das ist leider etwas kurz gedacht: Jeder Internetzugriff läuft bei uns über einen Proxy, der zur Authentifizierung den produktiven Windows-Account verwendet. So stand ich vor der Wahl, ständig den User (zum Glück automatisiert) freischalten zu lassen, oder eben nicht ins Netz gelangen zu können. Zum Glück konnte ich die Programmierung ohne Netzzugriff erledigen, aber die ständige Sperrung nervt dann doch.

Warum kann der Mist nicht einfach mal funktionieren?

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.

Aus irgend einem Grund mochte mich die Terminalemulation gestern nicht besonders. Da habe ich mal bei den Kollegen angefragt, ob das Problem bei denen auch auftritt. Nein, tat es nicht. Irgendwann bin ich dann mal darauf gekommen, dass wohl die Konfiguration der Emulation kaputtgegangen ist. Warum, weiß ich nicht. Aber aus irgendeinem Grund mochte die sonstige Software den umkonfigurierten Emulator nicht. Und das, wo ich doch brav den zugehörigen Wizard verwendet habe, um die Konfiguration zu ändern. Naja, dann werde ich jetzt die Textdateien per Hand ändern müssen. Nur schade, dass ich nicht weiß, wo ich dran drehen muss, um die gewünschten Effekte zu erzielen.

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.