März, 2007

Nachdem ich schon seit gestern über die Möglichkeit nachdenke, Sametime Bots zu erstellen, hab ich mich auch auf die Suche nach Möglichkeiten für Jabber gemacht. Und siehe da: Mit der Java-API Smack ist das ganze überhaupt kein Problem mehr! Bei der Programmierung stellt sich aber die Frage: Wie teste ich jetzt, ob das ganze funktioniert? Für Sametime ist die Installation eines Sametime-Servers ein wenig zu aufwendig, aber für Jabber ist das ganze mit wenigen Mausklicks erledigt. Dazu kann man den Jabber-Server Openfire (früher Wildfire) von IngiteRealtime (den Herstellern der Smack-API) benutzen. Der lässt sich unter Windows einfach entpacken und starten – schon ist man im Besitzt eines Jabber-Servers. Dort habe ich mir dann auch gleich 2 Accounts angelegt: einen zum Testen des Bots und natürlich einen für den Bot selbst. Jetzt kann es an die Implementierung gehen.

Update: So, der Bot ist etwas erwachsener geworden: Er kann jetzt durch Plugins erweitert werden und kennt die Befehle date, =>, forget, plugins, DIE!, SAVE!, SHOWALL! und antwortet auf Begrüßungen.

Mehr: Lies den Rest dieses Artikels…

Es ist etwas ruhiger geworden um meinen NNTP Newsreader JUsenet, aber heute habe ich eine neue Version bei SF hochgeladen. Die Versionsnummer 0.0.2 sagt bereits, dass man die Software nicht für die tägliche Nutzung einsetzen sollte, im Moment ist es auch eher ein Beispiel für die Nutzung von Hibernate und HSQLDB im Hintergrund. Damit habe ich quasi kostenlos das Offline-Lesen bekommen. Wichtiger ist aber die Abstraktion der Datenbank, so dass ich mich nicht mehr mit SQL-Geraffel herumschlagen muss…

Die Oberfläche musste im Gegensatz zur Version 0.0.1 ordentlich Federn lassen. Das hängt unter anderem damit zusammen, dass ich einige Events und Listeners eingebaut habe, um asynchrone Verbindungen zum NNTP-Server zuzulassen. Das ganze kommt spätestens dann zum Einsatz, wenn ich die Stacks einsetze, in denen ich die geöffneten Verbindungen speichere – ok, im Moment ist das nur eine, aber es könnten eben auch mehr werden.

Ich werde in den nächsten Wochen auf jeden Fall das NNTP-Backend erweitern, so dass alle Header richtig ausgewertet werden und alle Artikel geladen werden. Im Moment bringen einige Artikel die Software leider zum Abbruch des Downloads, aber das sollte sich schnell korrigieren lassen. Immerhin gibt es RFCs für NNTP. In diesem Release ist der Fehler aber noch drin, ich hatte eben einfach nicht mehr die zündende Idee, was es sein könnte.

Wer den Sourcecode haben möchte, muss sich auch noch ein paar Tage gedulden: Irgendwie spinnt meine Subversion-Verbindung. Sobald ich das korrigiert habe, kann man das aber in den Projektnews nachlese. Für Kommentare oder Hilfen bin ich immer offen – dafür solltet ihr aber lieber die Fähigkeiten von Sourceforge nutzen:

http://sourceforge.net/projects/jusenet/

Heute gab es einige Wirrungen mit javadoc, und ich möchte meine Fragen und Antworten hier gern festhalten. Ich weiß sicherlich nicht alles über javadoc, aber ich versuche es in allen Quelltexten einzusetzen. Ich kenne auch Doxygen und weiß, dass man damit auch gute Dinge machen kann – und dass es eine grafische Oberfläche zur Konfiguration hat. Aber dafür gibt es Eclipse und so muss ich mir auch mit javadoc nicht die Mühe machen, auf der Kommandozeile zu hantieren.

Jetzt aber direkt zum ersten Punkt:

Kann javadoc rekursiv für alle Verzeichnisse Javadocs erstellen?

Meine Antwort: Nein. javadoc ist dafür anscheinend zu doof. Es gibt zwar eine Option -subpackages, doch die befreit mich nicht davon, alle – und ich meine wirklich alle – Packages aufzulisten, die in den erzeugten Javadocs enthalten sein sollen. Wieso gibt es nicht das sonst übliche -r, dass alle Klassen, Packages und sonstigen Dinge im src-Verzeichnis erfasst? Oder habe ich es nur übersehen…?

Kommt man in die Verlegenheit, die Javadocs doch mit der Hand erzeugen zu müssen, endet man also schnell in einer Batch-Datei, die einen Aufruf wie diesen enthält:

%JAVA_HOME%/bin/javadoc -subpackages pack.data,pack.chart,pack.foo,pack.bar -classpath dir/dir1/dir2:dir/dir3/dir4 -public -d doc -sourcepath src pack.model.argh pack.data.validation pack.gui.properties pack.gui.nochvielmehr

Gut, aber damit kann man auch noch leben, wenn man es erst raus hat.

Dann gibt es da noch die Sache mit den Beschreibungen der Packages. Wie soll man Packages beschreiben, wenn man doch keine einzelne Datei dafür hat, in die man die javadocs eintragen kann? Nun, man hat so eine einzelne Datei und zwar in jedem Verzeichnis eines jeden Packages.

Die Datei muss package.html heißen und enthält neben der textuellen Beschreibung auch javadoc-Tags, z.B. @author oder @since. javadoc folgt wieder der Konvention, den ersten Satz bis zum ersten ‘.’ als Kurzbeschreibung auf die Übersichtsseite zu übernehmen.

Es gibt auch noch ein paar Tipps zur Kommentierung:

• Verwende 3. Person
• Beginne Methodenbeschreibungen mit einem Verb
• Verkürze Sätze, wenn möglich
• Benutze <code> für Keywords und Namen

So, das war’s erstmal. Vielleicht finde ich ja noch etwas mehr heraus. Falls ihr Korrekturen habt oder andere Dinge bemerkt, schreibt einfach einen Kommentar.