Der Laufplan für die Diplomarbeit

Ich hatte eben in den alten E-Mails gesucht, da ich mal „aufgeschrieben“ hatte, was man alles für die Anmeldung [sic!] zur Diplomarbeit benötigt. Ich stelle den mal kommentarlos zur Verfügung.

Hallo zusammen,

wer gedacht hat, das Anmelden zur Diplomarbeit wäre bei der FH easy, der hat die Rechnung ohne das Prüfungsamt gemacht. Leider steht folgende Todo-Liste NICHT online, wohl aber findet man aber Formulare auf dieser Seite http://www.studium.fh-koeln.de/service/formulare/u/01256.php – wer also schon mal eine Diplomarbeit geschrieben hat, der weiß wie der Hase geht.. der Rest steht nur dumm da.

Erstens: Der Antrag auf Zulassung
Weil es ein Amt ist, gibt es keine „Anmeldung“, aber einen „Antrag auf Zulassung“. Klingt komisch, ist aber so. Den „Antrag auf Zulassung zur Diplomarbeit und Kolloquium…“ muss in _zweifacher_ Ausfertigung abgegeben werden.. und nein, das war noch nicht alles..

Zweitens: BAFÖG
Für diejenigen, die BaFög erhalten haben, müssen das zugehörige Formblatt abholen. Diejenigen, die kein BaFög erhalten haben, müssen aber auch ein Formular ausfüllen.. nämlich um zu unterschreiben, das sie.. ui, richtig.. kein Bafög bekommen haben. Warum? Die besten 30 Absolventen müssen weniger zurückzahlen. Eigentlich ja keine schlechte Sache.

Drittens: Alle Guten Dinge sind drei – Externe Arbeiten
Sollte man außerhalb der FH eine Arbeit schreiben – was ja durchaus vorkommen wird – so benötigt man ebenfalls das Formblatt „Betreuerin/Betreuer der Diplomarbeit aus der Industrie/Wirtschaft“.. da bei ist es völlig egal, ob der externe Betreuer wirklich in Industrie/Wirtschaft sitzt, man könnte auch schreiben „nicht aus der FH Köln“. Richtig geraten, dieses Formblatt muss auch _zweifach_ ausgefertigt abgegeben werden.

Der aufmerksame Leser, der gut im Kopfrechnen ist, sollte im schlimmsten Fall auf fünf Formulare gekommen sein, die auszufüllen sind.

Viele Grüße aus Köln,
Jan

Jegliche Form von versteckter Ironie, Sarkasmus oder bösen Witzen sind rein zufällig. Wirklich.

Univention Absolventenpreis 2010 [Update]

Für unsere Diplomarbeit [siehe Update!] haben mein Kommilitone und ich den 1. Platz des Univention Absolventenpreises 2010 erhalten. Der Preis wurde im Rahmen der Auftaktveranstaltung zu den LinuxTagen 2010 in Berlin vergeben. Kriterien für den Preis waren u.a. innovative und praxisnahe Open-Source-Software-Lösungen.

Update: Unter einer neuen Adresse erreichbar: www.visualdependencies.de (11.11.2010)

Presse & Co.

Diplomarbeit – Quo vadis?

Unsere betreuende Professorin der FH Köln bietet eine Weiterentwicklung/Fortführung unserer Diplomarbeit an, vor allem hinsichtlich Erweiterungen der graphischen Darstellung (andere Graphen, neue Graphen) sowie neue Arten von „Mustern“. Bei Interesse einfach bei ihr melden.

Unabhängig davon habe ich selber damit angefangen, das Projekt nach zubauen neu zubauen. Das Projekt steckt allerdings noch in den „anfänglichen Anfängen“ 😉 und konkurriert daher noch nicht wirklich als Fork o.ä. Voraussichtlich wird die Neuentwicklung auch zunächst nur zum Sammeln & Analysieren sein, und die Daten entsprechend exportieren können, damit es mit dem vorhandenen Programm kompatibel ist. Aber wie gesagt, noch ist da nichts zu sehen.

Auszeichnung mit dem Innovationspreis (Update)

Just for note: Im Rahmen unserer Diplomarbeit sind mein Kommilitone und ich gestern Abend auf der Weihnachtsfeier der Firma Opitz Consulting mit dem „Innovationspreis für Informatik (3. Platz)“ ausgezeichnet worden.

Weitere Informationen

Presse:

Veröffentlichung der Diplomarbeit

Bereits in einigen Beiträgen der letzten Monate hatte ich Themen aufgegriffen, die im Zusammenhang mit meiner Diplomarbeit standen. Diese ist nun fertig, bewertet und kann nun veröffentlicht werden. Die Diplomarbeit von von einem Kommilitonen und mir zusammen ausgearbeitet. Eine Downloadmöglichkeit der Diplomarbeit ist nun vorhanden.

Die Arbeit beschäftigt sich mit dem Thema der Visualisierung von Datenbankobjekten, also Tabellen, Views und Trigger. Dabei geht es jedoch nicht um die Objekte selber, sondern vielmehr um eine geeignete Darstellung der Abhängigkeiten. Diese können sowohl wechselseitig (Trigger) als auch nur „einfach“ komplex sein (Viewhierarchien). Als Produkt entwickelten wir das Produkt „visualDependencies“, welches ebenfalls derzeit kostenfrei zum Herunterladen verfügbar ist.

Vollbracht.

Hoffentlich ist es dem Leser aufgefallen (weil das würde ja implizieren, dass der Blog bereits vorher einmal gesehen wurde *g*), habe ich dem Blog ein frischeres Design spendiert. Nicht zuletzt nutzt es den Platz etwas effektiver, bisher wurde viel verschenkt.

Diese Woche haben wir unsere Diplomarbeit gedruckt und abgegeben. Jetzt heißt es warten. Für Interessierte: Es wird auch hier eine Veröffentlichung mitsamt der entwickelten Software geben. Bitte Geduld.

Statistiken via Subversionhistory

Nach einem erfolgreichen Projekt ist es interessant, was denn so alles gelaufen ist. Bei der Verwendung von Subversion (oder natürlich auch einem anderen Versionskontrollsystem) ist es „leicht“, die History einfach nach den Taten zu analysieren und daraus Berichte zu erstellen. Einfach deswegen in Anführungszeichen, weil dies natürlich händisch gesehen zuviel Zeit beanspruchen würde.

Für diesen Fall gibt es StatSVN, ein kleines in Java entwickeltes Tool, welches für eine Working Copy die komplette History in einem HTML-Report (wahlweise auch XML/XDOC) visualisiert. Dabei werden sowohl Tabellen als auch Diagramme erstellt – genial Sache! Da komplett über Kommandozeile lauffähig, ist eine Integration in Ant/Maven kein Problem; ebensowenig in andere Buildscripts.

Nachdem man eine neue Working Copy erstellt hat (bevorzuge ich mal an dieser Stelle), reichen 2 Befehle zum Generieren:

svn log -v --xml [ort] > svn.log

erstellt eine XML-Log der Commits, dabei ist „Ort“ natürlich optional und kann bspw. der Ort der Workingcopy sein (in Scripts)

java -jar statsvn.jar {working-copy-dir} {svn.log}

erstellt schließlich den Bericht. Wichtig sind dabei vor allem die Paratemer -output-dir, -threads. Die letzten beiden Parameter sind Pflicht.

Tatsächlich sollte man sich jedoch vorsehen, auf welchem Repository man es ausführt. Zwar lässt sich die Threadzahl (Standard 25) einstellen, aber es gibt auch Server, die damit absolut nicht klarkommen. Für diesen Fall empfehle ich das Spiegeln des kompletten Repositories auf die lokale Festplatte; dann muss ein neuer Checkout gemacht werden sowie zwischenzeitlich ein weiterer Sync der Repositories, aber das Generieren der Statistiken funktioniert wesentlich(!) schneller.

Mit dieser Anleitung ist ein Spiegel schnell eingerichtet, mittels dem letzten Befehl (svnsync sync…) wird das Repository auch später schnell gesynct, ähnlich einem svn update.

Java-Anwendungen mittels Ant-Script in eine Drop deployen

Im Anschluss an meine vorangegangenen Artikel über das automatische Builden und Deployen einer Java-Anwendung (als Jar, als Mac-Applikation und als Windows-Exe) folgt nun ein Howto, wie man eine Drop von drop.io automatisch aktualisieren kann.

Leider gibt es derzeit weder eine Java-API-Implementierung der drop.io API noch einen Ant-Build-Task, letzteres ist dann natürlich keine Überraschung. Daher verwende ich iOrb, ein drop.io command line interface, entwickelt in Ruby. Daher ist auf dem System Ruby zwingend erforderlich — für Alternativen bin ich selbstverständlich offen.

Nach einer beispiellos simplen Installation ist iorb als Command verfügbar. In meinem Falle beginnen die Deploy-Apps mit „application-„, daher reicht ein Pattern, um alle zu löschen.

<target name="deployToDropio" depends="makeAll">
  <!-- Delete all application assets -->
  <exec executable="iorb">
    <arg line="destroy ${drop.drop_name}:/application-*/ --force" />
  </exec>
  <!-- Upload new versions -->
  <exec executable="iorb">
    <arg line="add deploy/Application.jar --drop-name ${drop.drop_name}" />
  </exec>
  <exec executable="iorb">
    <arg line="add deploy/Application.exe --drop-name ${drop.drop_name}" />
  </exec>
  <!-- zip mac app dir -->
  <zip destfile="deploy/Application.app.zip" basedir="deploy/Application.app" />
  <exec executable="iorb">
    <arg line="add deploy/Application.app.zip --drop-name ${drop.drop_name}" />
  </exec>
</target>

Vor dem ersten Starten muss/will iOrb eine Profildatei in ~/.iorbrc anlegen. Dafür ist ein API-Token von drop.io notwendig.

Dort werden auch im Yaml-Format die angelegten Drops gespeichert. Falls man bereits im Vorfeld eine Drop angelegt hat, so kann man diese Datei auch später im einen Texteditor entsprechend bearbeiten. Dort werden auch die Passwörter und Tokens abgelegt.