Die Bachelorbarbeit geht langsam ihrem Ende zu und es wird Zeit, mal mit der Dokumentation zu beginnen, falls man diese nicht schon nebenbei am Schreiben ist. Bei uns am IFS werden, soviel ich weiss, alle Arbeiten komplett in Englisch geschrieben, deshalb möchte ich noch schnell einen Tipp loswerden, den ich vor einigen Tagen in Bugs in Writing gelesen habe.

Wie das in technischen Berichten üblich ist, benützt man sehr viele Akronyme, also Abkürzungen, die aus den jeweiligen Anfangsbuchstaben mehrerer Wörter bestehen, wie beispielsweise DVD. Falls man also ein Akronym in seinem Text einführen will, schreibt man dieses bei der ersten Verwendung in Klammern dazu. Also folgendermassen:

The parser creates an abstract syntax tree (AST).

Was nicht korrekt ist, aber vielfach gemacht wird, ist die Buchstaben des Akronyms gross zu schreiben (es sei denn, man würde das auch sonst gross schreiben):

The parser creates an Abstract Syntax Tree (AST).

Genauso unschön ist es, das ganze umzukehren:

The parser creates an AST (abstract syntax tree).

Ach ja, falls man ein Akronym im Abstract oder Management Summary einführt, muss man es im Hauptdokument trotzdem nochmals definieren, da das Abstract als eigenes Dokument gilt. Auch sollte man natürlich nur Akronyme einführen, die man auch tatsächlich mehrmals einsetzt.

So, jetzt ist endgültig fertig mit der Diplomarbeit: Heute Abend hatten wir noch die “mündliche Prüfung”, welche zum grössten Teil aus einer Präsentation und einer kurzen Fragerunde bestand. Das ganze lief ziemlich gut, die Demos haben funktioniert und wir mussten bei den Fragen nie passen.

Wer möchte kann sich die Präsentation natürlich auch anschauen, Powerpoint .ppt und PDF stehen zur Auswahl.

Ich drücke allen die Daumen, die im Laufe der Woche Ihre Präsentation noch haben!

Von der bbvSoftware Services AG habe die Diplomarbeiter der HSR diese Woche ein kleines Fresspaket bekommen. Der Inhalt so ungefähr so aus:

Also Isostar-Getränke und Riegel, Choc-Ovos und 2 Stress-Abbau-Bälle, die ich auf dem Foto leider vergessen habe. Und zudem noch eine Hand voll Sugus, welche wohl noch von irgendwo übrig waren, vielleicht auch aus dem letzten Jahrtausend: die Dinger sind nämlich grausam bitter und steinhart! Pfui, echt. Und nicht nur bei mir, dem Nachbarn geht es genau gleich. Als erstes dachten wir ja noch, die bbv wolle sich für die Unannehmlichkeiten, die wir dank ihres Unterrichts-Verwaltungs-Tool gehabt hatten entschuldigen, aber offensichtlich will man uns vom gelingen unserer Arbeit abhalten , ich fühl mich im Moment nämlich gar nicht gut.

Also, nochmals Danke für das Päckchen, es war bestimmt gut gemeint, auch wenn die Sugus ungeniessbar sind.

Da wir in unseren Projekten einige Zeit mit dem Schreiben von Unit- und Integrationstests verbringen, hat es mich schon immer interessiert, wie gut unsere Testabdeckung eigentlich ist. Nicht, dass die Testabdeckung allzu viel zur Qualität der Tests aussagen muss, aber interessant ist es trotzdem und es hilft, eventuell beim Testen vergessene Bedingungen zu finden. Bis anhin prüfte ich die Testabdeckung jeweils mit Coverlipse, einem Eclipse Plug-in. Da HTML-Reports, die man veröffentlichen kann und vor allem automatisch erstellt werden aber schöner sind und ich gerade in einem Buch über Cobertura gelesen habe, wollte ich es einmal ausprobieren.

Eigentlich ist es nicht allzu schwer, man sollte der Anleitung einfach genau folgen und sicherstellen, dass man sich genau merkt was man getan hat. Ausserdem ist es anzuraten, jeweils einen möglichst “frischen” Workbench zu haben, da es beim ausprobieren schnell passiert, dass man die Reports aufgrund alter Daten erstellt und dann das ganze auf dem Server, der jedes mal alles neu erstellt, doch nicht funktioniert. Ich spreche aus Erfahrung

Ach ja, und das Resultat, das sieht man hier. Wie man sieht, sind die ui- und action-packages kaum getestet, das liegt daran, dass wir keine Plug-In-Tests geschrieben haben. Ansonsten haben wir auch noch einige Lücken, wir haben also noch zu tun

Heute Nachmittag stand bei mir das erstellen des Extract-Method-Dialoges auf dem Programm. Wir wollten uns so weit wie möglich an die Vorgabe des JDT halten, natürlich angepasst an Ruby. Da ich auch schon so meine Erfahrungen mit SWT gesammelt habe, habe ich mir genügend Zeit eingeplant, schlussendlich war ich dann doch rund 4 Stunden dran, und das ist dabei herausgekommen:

Der Dialog ist vielleicht etwas zu lang, durch den Refactoring-Wizzard ist unten und oben auch recht viel Platz. Was man halt im Bild nicht sieht: alle Controls “dehnen” sich aus, wenn man den Dialog in der horizontalen streckt, wobei sich nur die zwei Eingabefelder und die Tabelle in der grösse verändern. Wenn man den Dialog vertikal streckt, verändern sich die Tabelle und das StyledTextWidget jeweils gleichmässig. Alles andere bleibt an Ort und Stelle. Ich bin eigentlich ziemlich stolz drauf Und erleichtert, als ich endlich fertig wurde.

Da ich ein grosser Fan von Qt bin, habe ich das ganze heute Abend nochmals gemacht, allerdings in nur 5 Minuten:

Das Verhalten ist genau gleich wie bei SWT. Und das in einem Bruchteil der Zeit. Auch das Duell um den kleineren Code gewinnt Qt mit 280 Zeilen XML, bzw. 200 Zeilen C++ gegen SWT mit 350 Zeilen Java.

Tja, leider kann man sich nicht alles aussuchen, und ein Eclipse-Port (bzw. SWT) auf Qt wird wohl mein Wunschtraum bleiben.

Argh, Eclipse ist ja schon ziemlich cool, aber zum Teil nervt es auch ziemlich. Was ich zum Beispiel gar nicht mag, sind die plugin.xml-Dateien.

Aber mal von Anfang an: Für unsere Refactoring-Plugins für RDT habe wir auch zwei Menus erstellt (Source und Refactor), wie bei unserem grossen Vorbild, JDT. Lukas hat das alles mal gemacht und es funktionierte. Bis auf die Kleinigkeit, dass die Menus auch dort waren, wenn man kein Ruby-File geöffnet hat, es also gar nichts zu refactoren gab. Ausserdem hätten wir gerne Shortcuts für gewisse Refactorings. Kann nicht allzu schwer sein, das zu korrigieren, oder?

Das mit den Shortcuts ging ganz schnell, allerdings erschien kurz darauf ein kleines, gelbes Icon mit der Warnung, dass meine Konfiguration für die Shortcuts deprecated sei. Nach einigen langen Minuten googlen und Bücher lesen hatte ich rund zwei Stunden später funktionierende Shortcuts.

Also noch das Problem mit dem verschwinden der Menus: Das war dann doch etwas schwerer zu finden, schlussendlich bin ich dann darauf gekommen, dass ich nun anstelle eines ActionSets eine EditorContribution erstellen muss. Das wars dann schon, es funktionierte. Dachte ich. Die Menus verschwinden nun zwar, aber beim auslösen einer Action erhielt ich nur die Fehlermeldung, dass die Operation zur Zeit nicht verfügbar sei. Keine Exception, nichts. Nach einer weiteren Stunde hab ich dann die Lösung gefunden: Die Action-Klasse, die schlussendlich das Refactoring auslöst, implementierte bisher das IWorkbenchWindowActionDelegate-Interface. Leider hätte es aber IEditorActionDelegate sein müssen… tja, hätte ich das vorher gewusst.

Wie es aussieht bin ich nicht der einzige, der von Eclipse genervet ist, jemand betreibt sogar ein Blog dazu. Aber insgesamt bin ich doch einiges zufriedener als der Autor

Heute morgen, Punkt 7 Uhr hat für mich die Diplomarbeit angefangen. Wie die meisten meiner Leser sicher wissen, geht es darum, automatisierte Refactorings für RDT zu erstellen. Am Anfang stehen aber banalere Dinge: Nachdem ich meinen Arbeitsplatz gefunden hatte gleich die erste Enttäuschung: der Monitor der hier steht und den ich gerne an mein Notebook hängen würde hat nur ein DVI-Kabel dran. Janu, gleich den Adapter online bestellt, aber was passiert beim bezahlen:

An error occurred while loading https://www.yellownet.ch/start_e.html:
Could not connect to host www.yellownet.ch.

Ok, dann halt doch mal mit arbeiten beginnen. Beim Verbindungsversuch zu unserem Server hiess es dann aber:

An error occurred while loading http://r2.ifs.hsr.ch/:
Unknown host r2.ifs.hsr.ch

Und ja, natürlich habe ich eine Verbindung. Nur nicht zu den beiden Rechnern die ich gerade bräuchte Ich hoffe, das sind keine schlechten Omen für den Rest der Diplomarbeit.