Code Swarm: Shox Network Simulator

Code Swarm ist ein interessantes Experiment zur Visualisierung der Aktivitäten an Projekten. Mit der code_swarm Software wird aus der (SVN-)Commit-History eins organisch wirkende Visualisierung berechnet. Dabei fliegen die Namen der entsprechenden Entwickler in den Raum, wenn sie Dateien committed haben und verschwinden wieder, wenn die Aktivität nachlässt. Alle Dateien werden durch kleine Punkte visualisiert. Sie werden immer dicker und heller je öfter die Datei geändert wird.

Das Projekt ist hier zu finden. Das Programm selbst wird bei Google Code gehostet. Ich habe mal das entsprechende Video für Shox - einem Netzwerk Simulator für Sensornetzwerke - an dem ich mal mitgearbeitet habe.
. Im Grunde hat es keinen direkten Nutzen, aber die Aktivität wird auf interessante Weise dargestellt. Man erinnert sich dann sofort an die entschiedenen Phasen des Projektes.

Videos sind auch verfügbar für Python, Apache, Eclipse und PostgreSQL.

Do I want to go where the real action is?

The Linux Kernel Module Programming Guide:

You know C, you've written a few normal programs to run as processes, and now you want to get to where the real action is, to where a single wild pointer can wipe out your file system and a core dump means a reboot.

(Hervorhebung von mir)
Wollen? "Wollen" ist nicht der richtige Ausdruck, aber solange sich die iSCSI Target-Implementierung nicht ins Userland bewegt, muß ich mich in den Kernel bewegen. Ansonsten nix "Master of Science".

Zusammenarbeit Java und Python

Einer der Vorteile von Python ist die gute Integration von C-Bibliotheken z.B. um einzelne Funktionen aus Performancegründen auszulagern. Die Zusammenarbeit mit Java ist viel schwieriger. Es gibt mehrere Gründe, warum eine bessere Zusammenarbeit wünschenswert ist. Zum einen sind die sehr umfangreichen Bibliotheken ein riesiger Vorteil der Java-Welt, auf der anderen Seite könnte man eine Verbindung mit Java-Legacy-Anwendungen aus Python heraus herstellen wollen.

Es gibt mit Jython eine Python-Implementierung auf der JVM, die natürlich sehr einfach mit Java-Bibliotheken und -Programmen zusammenarbeiten kann. Jython hat in letzter Zeit einige Fortschritte erzielt, aber die Implementierung ist immer noch Jahre hinter der aktuellen Entwicklung der Sprache hinterher. In vielen Situationen scheidet Jython als Alternative einfach aus.

Eine Lösung, die ich seit einigen Wochen verwende, ist JPype. JPype erlaubt aus normalen (C-)Python heraus Zugriff auf Java-Bibliotheken und integriert diese gar nicht schlecht. Ein Beispiel: import jpype jpype.startJVM(jpype.getDefaultJVMPath(), "-Djava.class.path=%s" % classpath) java = jype.JPackage("java") de = jype.JPackage("de") contact = de.dirkmeister.example.Contact(surname = "Meister") contact.mail = "XYZ@XYZ.de" contact.sendMail("Test-Mail") java.lang.System.out.println("Mail sent") Die Integrationg geht soweit, dass Java’s hashCode() Methode als __hash__, equals() als __eq__ und toString() als __str__ verwendet werden, so dass man quasi kaum merkt, ob ein Objekt nur ein Python- oder ein “Java”-Objekt ist. Selbst Getter- und Setter werden als Python-Properties integriert und sogar Exceptions werden transparent umgesetzt. Auch Swing-Anwendungen sollen einfach möglich sein.

Nachdem die Hürde der Installation überwunden hat, gestaltet ich die Arbeit erstaunlich flüssig und problemlos.

Ich verwende JPype um in Python auf das Hadoop Distributed File System (HDFS) zu zugreifen und dabei die volle FileSystem-API auf eine pythonifizierte Art zu verwenden z.B. sollen die Stream-Objekte als “File-like Objects” integriert werden. Den Code will ich in ein paar Wochen auf hier vorstellen.

Quellcodeverwaltung Mercurial 1.0 freigegeben

Wie Golem die Woche berichtet hat, wurde die Version 1.0 von Mercurial freigegeben. Mercurial ist eine freie, verteilte Quellcodeverwaltung. Schon vor 1.0 wurde sie für zahlreiche Projekte verwendet. Die größten Projekte sind wohl die Sun-nahen Projekte wie NetBeans - by the way - Super RoR-Support - und OpenJDK.

Der größte Unterschied von einem verteilten Quellcodeverwaltungsystemen zu konventionellen wie Subversion ist (meinem Verständnis nach), dass ein Checkout (bei Mercurial Clone genannt) nicht fest mit einem Repository verbunden ist. Änderungen können kurzfristig im Repository A gesichert werden. Aber ein späterer Versionstand kann in eiem anderem Repository B gespeichert werden. Außerdem ist dort das erzeugen einer neuen Version durch Commit von dem Veröffentlichen dieser Änderung entkoppelt. Man kann lokal häufig committen, aber nur fertige Versionen können dann veröffentlich ("pull") werden. Im Mercurial-Wiki ist eine Beschreibung vorhanden.

Warum kann dies nützlich sein?
Zum Beispiel bei Uni-Projekten könnte (mit Mercurial) jeder Student mit seiner Bachelor- oder Diplomarbeit oder jede Gruppe von Studenten ein eigenes (privates) Repository erhalten mit dem er tälich oder stündlich Commits erzeugt. Aber nur funktionierende Versionsstände werden dann in das zentrale Hauptrepository geschoben.

Man könnte so etwas mit Subversion-Branches machen, aber selbst da ist jede "interne" Sicherung auf dem zentralen System sichtbar. Nicht so schön. Faktisch commiten Studenten tälich Zwischenstände ins zentrale Repository, was häufig zu Unannehmlichkeiten führt.* Oder sie arbeiten ohne Sicherung (Commit) bis zum einem Meilenstein, aber viel des Komforts einer Quellcodeverwaltung geht damit verloren. Und bei HD-Crashes verliert man nicht nur dem "Komfort".

In gewisser Weise sind verteilten Quellcodeverwaltungsysteme die dritte Stufe - nach zentralisierten, Sperr-basierten Systemen und zentralisierten, Merge-basierten Verfahren wie Subversion. Ein anderes verteiltes Quellcodeverwaltungssystem ist GIT, dass z.B. für den Linux-Kernel eingesetzt wird.

Ich selbst habe noch nicht mit veteilten Quellcodeverwaltungen gearbeitet, aber ich glaube, dass es z.B. in dem Uni-Kontext wirklich sinnvoll wäre. **

---

* Man kann eine Strategie fahren, dass man nur ein zentrales Repository mit häufigen Commits ohne Branches hat. In enggekoppelten Teams wie in Firmen ist dies wohl auch die Standardvariante. Aber bei lose-gekoppelten Teams wie bei Uni-Projekten ist dies wohl nicht die optimale Idee.

** Ebenfalls für den Einsatz für Studentenprojekten gedacht ist DrProject, eine Trac-Variante für "classroom usage".

Video: High-Performance Wordpress

This is a video about scaling the blogging site wordpress.com using techniques like WP-Cache and horizontal database partitioning using a "a plugin" called HyperDB.

The video is really interessing, but I woundered about the calculation of the maximal number of pages views possible with several configurations. The speaker claimed for example that the base wordpress installation can handle 8 requests per second and the can therefore handle 691.000 requests a day. But this is only true if the requests are uniformly distributed around the day.

When I plan to handle the requests even at the peak times (I mean day peak times not really extraordinary events like a Digg-attack), you can handle 8 requests per second at the peak, not on the average. Using the average over-the-day distribution of juli-blogs.de (based on the hours average) with peaks at 19h, I get a number that is smaller by more than a factor of 4. And even that is highly aggregated and not conservative calculation. Ok, even that number is clearly high enough for most wordpress sites (sure for dirkmeister.de ;-) )

Eclipse-Emma-Plugin: EclEmma

Emma ist ein Werkzeug zur Überdeckungsanalyse für Javacode. Man kann damit Basisanalysen erstellen wie gut JUnit-Tests die verschiedenen Zweige im Code überprüfen.

Doch der Einsatz der Emma-Bibliothek alleine ist ziemlich aufwendig. Man muss manuell den Code instrumentalisieren und Berichte aus den gesammelten Informationen erstellen. Mit einem guten ant-Skript ist dies kein Ding, aber für den einzelnen Entwickler/Unittester doch zu viel Aufwand.

Mit EclEmma (momentan Version 1.2.0) gibt es ein sehr gutes Eclipse-Plugin, das den ganzen Prozess extrem abkürzt. Die Coverageprüfung integriert sich als zusätzlichen Lunchmode (neben Debug und Run). Damit wird das Durchführen einer Coverageprüfung ein Kinderspiel. Der Code wird automatisch instrumentalisiert und die Resultate werden automatisch ermittelt und dargestellt.

Apropo Ergebnisse:
Bei der Anzeige der Ergebnisse zeigt sich der wahre Vorteil des Plugins. Ähnlich wie bei der Edition für Tester von Visual Studio 2005 werden die Überdeckungsinformationen direkt im Codeeditor angezeigt. Extrem übersichtlich. Man sieht direkt, wo die Tests noch nicht ausreichen.

Ich kann das Plugin nur empfehlen. Man erhält ohne großen Aufwand einen echten Mehrwert bei der Überdeckungsanalyse. Es ist nicht einmal notwendig die Projekteinstellungen zu verändern.

Nachtrag zu Jabber

In dem Artikel "Fazit vom 1. Webmontag" habe ich geschrieben, dass mir der Jabber-Vortrag überzeugt hat und ich nochmal versuche werde von ICQ nach Jabber zu wechseln.

Naja, nach einigen Beschwerden ich sei ja nie online oder würde auf Nachrichten nicht antworten, bin ich heute zumindest zu 50% zurückgewechselt: Das ICQ-Gateway vom Jabberserver nutze ich nicht mehr.

Ich konnte zwar ICQ-Kontakte sehen und selbst auch Konversationen beginnen. Für mich sah also alles gut aus. Aber mein Online-Status wurde nicht gesehen und eingehende Konversationen wurde nicht weitergeleitet. Von der anderen Seite sah es also gar nicht gut aus.

Fazit:

1. Es hat nicht so gut funktioniert wie gehofft, aber ich werde Jabber weiterhin als Zweit-Account nutzen.
2. Die Idee und auch die Umsetzung von Jabber finde ich super. Aber die Massenträheit, ...
3. Wenn einige Leser sich gewundert haben, dass ich nie online war und nie geantwortet habe. Ich bin nicht schuld, die Technik ist schuld ;-)

Präsentation zur Architektur von LiveJournal

LiveJournal ist ein bekannter amerikanischer Bloghoster, der seine Serversoftware auch als Open Source verfügbar macht.

Dessen Gründer Brad Fitzpatrick (2005 würde LiveJournal an Six Apart verkauft) berichtet in diesem Video über deren Softwarearchitektur, deren Ansatz zu skalieren und die dafür eingesetzte meist-selbstentwickelte und als Open-Source veröffentlichte Software.

Der Foliensatz der Präsentation sind auch separat verfügbar.

[via Tech Presentations]

Wordpress als einfaches CMS

Ich stehe für einen Bekannten von mir vor der Aufgabe aus ein paar statischen HTML-Seiten ein kleines Content-Management-System zu bauen, dass aber das Layout nicht verändert.

Bei den meisten CMS passt sich das Layout dem CMS an, manchen Seiten sieht man sogar auf den ersten Blick an mit welchem CMS die Seite verwaltet wird. Beispiele dafür sind phpNuke und Mambo (, das immer durch eine Safari-Warnmeldung auffällt). Hier muss das CMS so flexibel sein, dass die Seite nicht geändert werden muss. Außerdem soll es sehr einfach bedienbar sein.

Ich glaube ich werde dafür Wordpress verwenden. Das System, dass auch bei dirkmeister.de zum Einsatz kommt. Die Idee haben ich durch diese beiden Beträe (eins, zwei) von www.perun.net bekommen, die den Einsatz der eigentlichen Blogsystems als CMS erklären. Ich bin gespannt, wie sich das System bewähren wird.