Zusammen mit meinem ehemaligen Kommilitonen habe ich eine Seite zu unserer Diplomarbeit gelaunched. Dort wird die Arbeit zur Zeit grob, in Zukunft mehr im Detail vorgestellt und Ergänzungen behandelt. Auch mögliche Weiterentwicklungen stehen auf den Plan.
Archiv der Kategorie Diplomarbeit.. ftw!
Für unsere Diplomarbeit 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.
Presse & Co.
Geht nicht? Doch! Mit Hilfe des Visualisierungstool Gource (Open Source) lassen sich von SCMs wie Git oder Subversion sehr ansprechende Visualisierungen erzeugen. Es gibt auch einen netten Link, wie man das unter Mac OSX ans Laufen bekommt (man braucht dafür MacPorts).
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.
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.
Presse:
- Oberberg-Aktuell (12.12.09)
- FH Köln (22.12.09)
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.
Aug 7
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.
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.
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.
Bereits vor einigen Wochen hatte ich hier und dort beschrieben, wie man mit Eclipse/Ant seine Anwendung per Knopfdruck automatisiert deployen kann. Da es unter manchen Windows-Systemen zu Schwierigkeiten kommt, eine Jar-Datei zu starten (bspw. nicht verknüpft mit dem Jar-Launcher) empfiehlt es sich natürlich, für jene einen kleinen Exe-Wrapper zur Verfügung zu stellen. Launch4j bietet neben dieser Funktionalität auch diverse andere Tweaks: Splashscreen, Java-Download-Hinweis, JVM-Arguments und vieles mehr. Dabei gibt es Launch4j in zwei Modi: Im Gui-Modus lassen sich alle Einstellungen konfigurieren (und testen) und anschließend speichern, im Befehls-Modus wird eben eine solche Konfigurationsdatei erwartet.
Launch4j arbeitet selber mit Ant, daher ist die Integration in bestehende Build-Tasks sehr einfach. Wahlweise konfiguriert man die Optionen direkt im Hauptbuildscript oder verwendet ein eigenes Script, welches man durch die Gui erhält.
In dem eigenen Buildscript definiert man den Task etwa mit:
<taskdef name="launch4j"
classname="net.sf.launch4j.ant.Launch4jTask"
classpath="${launch4j.dir}/launch4j.jar :${launch4j.dir}/lib/xstream.jar" />
wobei launch4j.dir auf das gesamte Verzeichnis zeigt (Hinweis.. es werden mindestens bin, lib und conf benötigt).
Anschließend kann mit einem beherzten <launch4j configFile=”build_data/launch4j.xml” /> bereits der Prozess gestartet werden.
Beispielhafter Inhalt der build_data/launch4j.xml:
<launch4jconfig> <dontwrapjar>false</dontwrapjar> <headertype>gui</headertype> <jar>../deploy/Application.jar</jar> <outfile>../deploy/Application.exe</outfile> <errtitle>Please download Java 6.</errtitle> <cmdline /> <chdir /> <priority>normal</priority> <downloadurl>http://java.com/download</downloadurl> <supporturl /> <customprocname>false</customprocname> <stayalive>false</stayalive> <manifest /> <icon>Application_32x32.ico</icon> <jre> <path /> <minversion>1.6.0</minversion> <maxversion /> <jdkpreference>preferJre</jdkpreference> </jre> </launch4jconfig>