Die JVM bringt aber auch ein eingebautes Profiling mit, das zwar nicht mit dem was eben die “richtigen” Profiler liefern vergleichbar ist, aber eben doch ganz brauchbar, wenn es darum geht herauszufinden, warum eine Applikation lahm ist. Die Funktion nennt sich hprof und viele kennen das vielleicht als Methode, um Heap-Dumps zu erzeugen. Aber das Ding kann noch mehr: um zu zeigen, wie man damit Performance-Probleme erkennen kann, verwende ich hier ein einfaches Beispiel, das Fibonacci-Zahlen rekursiv berechnet (der Source-Code für das Beispiel ist hier verlinkt).

Das hier ist die Java-Klasse, mit der wir die entsprechenden Daten erzeugen:

package example;
 
public class Fib {
 
	public long calculate(long n) {
		if(n == 0) {
			return 0;
		}
		if(n == 1) {
			return 1;
		}
		return calculate(n-1) + calculate(n-2);
	}
 
	public static void main(String[] args) {
		Fib fib = new Fib();
		System.out.println(fib.calculate(Long.valueOf(args[0])));
	}
 
}

Ruft man nun diese Klasse mit folgenden Parametern auf, erhält man eine Datei java.hprof.txt, die jede Menge Stack-Traces und am Ende eine Tabelle mit Profiling-Informationen enthält:

java -agentlib:hprof=cpu=times,depth=100 example.Fib 20

Den vollständigen Satz an möglichen Optionen erhält man mit java -agentlib:hprof=help oder im Artikel HPROF: A Heap/CPU Profiling Tool in J2SE 5.0.

Die Tabelle am Ende der Datei sieht ungefähr so aus:

CPU TIME (ms) BEGIN (total = 96) Wed Dec 07 16:53:53 2011
rank   self  accum   count trace method
   1 15.63% 15.63%    5020 301386 example.Fib.calculate
   2  9.38% 25.00%    4760 301385 example.Fib.calculate
   3  8.33% 33.33%    3632 301387 example.Fib.calculate
   4  7.29% 40.62%    2942 301384 example.Fib.calculate
   5  6.25% 46.87%    2026 301388 example.Fib.calculate
   6  5.21% 52.08%    1024 301389 example.Fib.calculate
   7  5.21% 57.29%     512 301390 example.Fib.calculate
   8  2.08% 59.38%     174 300332 java.lang.StringBuffer.append
   9  2.08% 61.46%    1152 301383 example.Fib.calculate
  10  1.04% 62.50%     256 301375 java.lang.Long.<init>
  11  1.04% 63.54%     256 301374 java.lang.Number.</init><init>
  12  1.04% 64.58%       1 301231 java.util.Hashtable.get
  13  1.04% 65.63%       5 301162 java.lang.StringBuilder.toString
  14  1.04% 66.67%       1 301111 java.io.FilePermissionCollection.<clinit>
  15  1.04% 67.71%       1 301031 java.io.Win32FileSystem.normalize
  16  1.04% 68.75%       1 300988 sun.net.www.protocol.file.FileURLConnection.getPermission
  17  1.04% 69.79%       1 300986 java.io.FilePermission.init
  18  1.04% 70.83%       1 300982 java.io.FilePermission$1.run
  19  1.04% 71.88%      44 300950 java.lang.StringBuffer.append
  20  1.04% 72.92%       1 300886 sun.net.www.protocol.file.Handler.createFileURLConnection
...

Hier kann man schon sehen, dass unsere Methode calculate() wohl nicht die schnellste ist. Außerdem sieht man noch, dass die langen Laufzeiten in dieser Methode in unterschiedlichen Threads immer mal wieder vorkommen.

Jetzt kann man in der gleichen Datei nach der Nummer, die in der Spalte trace steht suchen und findet dazu für die erste Zeile folgenden Thread

TRACE 301386:
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.calculate(Fib.java:Unknown line)
example.Fib.main(Fib.java:Unknown line)

Hier kann man dann ablesen, dass es sich wohl um den rekursiven Aufruf handelt, der hier das meiste der Performance auffrisst. Wenn man Glück hat, dann stehen da auch noch die Zeilennummern dabei – warum das hier nicht der Fall ist, weiß ich ehrlich gesagt nicht.

Weil diese java.hprof.txt-Files gerne mal ziemlich riesig werden können und die Sucherei in den Files nicht wirklich Spass macht, habe ich ein kleines Python-Skript geschrieben, das die Files in eine HTML-Seite umwandelt, in der man per Klick von der Liste zu den Threads springen kann und wo man auch bestimmte Klassen ausfiltern kann, von denen man schon weiß, dass die nix mit dem Problem zu tun haben. Das Skript habe ich hprof2html getauft und es kann hier heruntergeladen werden: https://github.com/zustandsforschung/hprof2html

Da gibt es dann die unterschiedlichsten Paradigmen, nach denen man eine solche Versionsnummer vergeben kann. Am bemerkenswertesten finde ich die Variante bei TeX, wo sich die Versionsnummer mit jedem Release der Zahl pi annähert – aktuell ist man bei 3.1415926.

Aber was ist wirklich sinnvoll und gibt es eine Art Standard dafür? Tatsächlich gibt es wirklich so etwas wie einen Standard. Er heißt SemVer (Semantic Versioning) und wurde von Tom Preston-Werner (Gravatar/GitHub) verfasst. Obwohl sich dieser Standard hauptsächlich auf alles bezieht, was eine öffentliche API zur Verfügung stellt, kann das dort beschriebene Schema doch auch für andere Software-Produkte angewandt werden.

Darin folgt eine Versionsnummer folgendem Format:

<major>.<minor>.<patch><tag>

Daraus ergeben sich dann Versionsnummern wie z.B. 1.4.2 oder 0.4.1beta2 – Tags in der Versionskontrolle lauten dann v1.4.2 oder v0.4.1beta2. Dabei gilt es folgende Regeln zu beachten:

Major

Sollte immer dann inkrementiert werden, wenn sich essentielle Dinge geändert haben. Im Fall einer API könnte das eine Inkompatibilität zur vorhergehende Version sein. Bei einem Produkt ein komplettes Neuschreiben oder ein deutlicher Sprung in der Funktionalität. Ich würde empfehlen vor dem ersten Release eine 0.x.x-Version zu verwenden und danach auf 1.x.x zu erhöhen – außer im Fall von Open Source Software natürlich

Minor

Kleinere Funktionserweiterungen erhöhen die Minor-Version. Bei APIs gilt, dass diese Änderungen in jedem Fall abwärtskompatibel zur nächstkleineren Minor-Version sein müssen.

Patch

Bugfixes, Konfigurationsänderungen und eigentlich alles, was nicht die bestehende Funktionalität erweitert erhöht die Patch-Version.

Tag

Um besondere Versionen besonders zu kennzeichnen, kann an die Versionsnummer noch ein Tag angehängt werden (z.B. “beta2″ oder “criticalfix”).

Die SemVer ist natürlich nicht das einzige Versionierungs-Schema. Zum Beispiel gibt es noch die Versionierungsregeln des Apache Portable Runtime-Projekts oder die Maven Version Number Rules. Egal welche Versionierungsregeln man am Ende wählt – wichtig ist vor allem, dass diese Regeln klar dokumentiert sind und sich über die Projektlaufzeit nicht ändern, damit man tatsächlich auch aus der Versionsnummer Informationen ableiten kann.

“The canvas element provides scripts with a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.”

Das Canvas-Element wird irgendwo auf der Seite platziert und tut selbst erst mal gar nichts:

<canvas id="canvas" ></canvas>

Das was dieses Element so speziell macht, ist die damit verknüpfte JavaScript-API: Man kann Linien und Kästchen zeichnen, Bilder und Text dort hineinmalen, mit Schatteneffekten versehen und transformieren.

In diesem Beispiel werden wir zunächst einen Text auf unsere Leinwand schreiben. Dazu benötigt man zunächst den Context des Canvas (den Parameter “2d” muss man immer mitgeben):

var canvas = document.getElementById("canvas");
var context = canvas.getContext("2d");

Dann können wir in den Context etwas schreiben:

context.shadowColor = "#440a0a";
context.shadowOffsetX = 100;
context.shadowOffsetY = 100;
context.shadowBlur = 10;
context.fillStyle = "#0a0a0a";  
context.font = "bold 100px sans-serif"; 
context.textAlign = "center"; 
context.textBaseline = "middle";
context.fillText("Amsterdam", width / 2 - 100, height / 2 - 100);

Wir setzen eine Farbe, Position und Verschwommenheitswert (shadowBlur) für den Schatten, bestimmen dann wie der Text geschrieben werden soll und schreiben den Text am Ende in den Context. In diesem Fall hat der Text die gleiche Farbe wie der Hintergrund, so dass wir tatsächlich nur den verschwommenen Schatten sehen können – was für einen netten Effekt sorgt.

Der nächste Schritt besteht darin, Bilder in das Canvas zu malen, die darüberhinaus auch gleich noch animiert werden sollen. Animation im Canvas-Element bedeutet ganz einfach alle paar Millisekunden den kompletten Inhalt in leicht veränderter Form neu zu zeichnen. Man erreicht dies über setTimeout oder wie im Beispiel über setInterval:

setInterval(draw, 10);

Zuvor wurden zunächst 20 Objekte erzeugt, die ein Bild enthalten und zusätzliche Parameter erhalten können. Diese Parameter werden zunächst in der initialize-Methode initialisiert, um den Bildern eine Richtung, Orientierung, Initialposition und -rotation zu geben:

function initialize(image) {
    image.rot = Math.random() * 360;
    var xOrientation = (Math.ceil(0.5 - Math.random()) - 0.5) * 2;
    var yOrientation = (Math.ceil(0.5 - Math.random()) - 0.5) * 2;
    image.x = xOrientation > 0 ? width : -240;
    image.y = yOrientation > 0 ? height : -240;
    image.dirX = xOrientation * -1 * Math.random();
    image.dirY = yOrientation * -1 * Math.random();
}

Dann wird wie oben erwähnt die draw-Funktion alle 10 Millisekunden aufgerufen. Dort wird immer erst der gesamte Zeichenbereich gelöscht und anschließend neu gezeichnet. Dabei zeichnen wir zunächst den bereits beschriebenen Schriftzug. Dann wir innerhalb einer Schleife die Position und Drehung für jedes Bild neu berechnet und dann das Bild in das Canvas gezeichnet.

Wichtig ist hier das Prinzip zu verstehen, wie beim Canvas-Element transformiert wird: Es existiert eine Transformationsmatrix, die mit den entsprechenden Befehlen geändert wird. Danach wird beim Zeichnen eines Objekte in das Canvas diese Matrix auf das zu zeichnende Element angewendet. Zusätzlich gibt es einen Stack für Transformationsmatrizen (und Canvas-Attribute), den man verwenden kann, wenn man so wie in diesem Beispiel mehrere Elemente unterschiedlich transformieren möchte.

amsterdam[i].x += amsterdam[i].dirX;
amsterdam[i].y += amsterdam[i].dirY;
amsterdam[i].rot = (amsterdam[i].rot + 1) % 360;
context.save();
context.translate(amsterdam[i].x + 120, amsterdam[i].y + 120);
context.rotate((2 * Math.PI / 360) * amsterdam[i].rot);
context.translate(-(amsterdam[i].x + 120), -(amsterdam[i].y + 120));
context.drawImage(amsterdam[i].image, amsterdam[i].x, amsterdam[i].y);
context.restore();

Um jedes Bild einzeln drehen zu können ist folgendes Vorgehen notwendig:

1. Der aktuelle Zustand des Canvas-Contextes wird abgespeichert. Der Zustand enthält nicht das was im Moment im Canvas zu sehen ist, sondern die aktuelle Transformationsmatrix und gesetzte Attribute.
2. Die Transformationsmatrix wird geändert und der Ursprungspunkt des Koordinatensystems zum Bildmittelpunkt verschoben.
3. Die Transformationsmatrix wird für eine Rotation geändert.
4. Das Koordinatensystem wird wieder zurückverschoben.
5. Das Bild wird tatsächlich auf das Canvas gezeichnet.
6. Der vorherige Zustand des Canvas wird wiederhergestellt, damit die nächste Drehung wieder korrekt abgebildet werden kann.

Das ganze machen wir alle 10 ms für jedes Bild und dadurch entsteht dann die Animation, die alle Bilder durch das Fenster rotieren lässt. Hinter folgendem Link befindet sich das hier beschriebene Beispiel (funktioniert natürlich nur mit einem HTML5-fähigen Browser):

Fliegende Bilder in HTML5

HTML5 besteht natürlich aus noch viel mehr als nur dem Canvas-Element. Dive Into HTML5 ist ein ausgezeichnetes englisches Tutorial, das die wichtigsten Neuerungen von HTML5 verständlich vorstellt.

Unterschied zum zentralisierten Modell

Der wichtigste Unterschied zwischen Mercurial und traditionellen Versionierungssystemen wie CVS oder SVN ist das verteilte Modell. Das bedeutet, es gibt nicht mehr nur ein zentrales Repository, sondern jeder Entwickler hat quasi eine Kopie des zentralen Repositories bei sich lokal liegen.

Der Entwickler checkt nun zunächst in sein lokales Repository ein und kann damit arbeiten wie z.B. mit einem SVN, über das er die alleinige Kontrolle hat. Zu einem Zeitpunkt, an dem der Entwickler mit seiner Arbeit so weit zufrieden ist, dass er sie den anderen an dem Projekt beteiligten Entwicklern zur Verfügung stellen möchte, schiebt er alles in das übergeordnete Repository.

Bei diesem Vorgang wird nicht nur der aktuelle Stand hochgeschoben, sondern auch alle Zwischenstände, die der Entwickler an seinem lokalen Repository eingecheckt hat. Außerdem kann sich das übergeordnete Repository selbst von einem weiteren Repository bedienen, so dass nicht nur zwei Ebenen sondern eine ganze Repository-Hierarchie möglich ist.

Für mich selbst war zunächst vor allem die Tatsache ungewohnt, dass man bei sich lokal eincheckt – das klingt ein bisschen so als wäre der Code in größerer Gefahr, weil er ja nur auf dem eigenen Rechner liegt. In der Praxis erweist sich das aber als großer Vorteil, denn man kann auf die Art viel freier ausprobieren und auch mal Zwischenstände einchecken, die nicht so hundertprozentig stabil sind und die man normalerweise seinen Kollegen nicht als Checkin zumuten würde.

Mercurial

Mercurial selbst ist Open-Source-Software und benötigt Python ab Version 2.4 zum Funktionieren. Mitte 2005 gab Mat Mackall bekann, daran zu arbeiten. Mittlerweile hat Mercurial die Versionsnumer 1.6 erreicht und ist recht verbreitet – so werden unter anderem die Sourcen von FireFox, OpenOffice und Python damit verwaltet. Außerdem kann man bei den bei Google Code gehosteten Projekten außer SVN auch Mercurial einsetzen.

Es gibt ein gutes Eclipse-Plugin, das sich MercurialEclipse nennt und eine Shell-Extension für Windows ähnlich dem bekannten TortoiseSVN, die sich TortoiseHG nennt.

Das folgende Mini-Tutorial zeigt allerdings den Standardfall: Mercurial über die Kommandozeile.

Mini-Tutorial

Der Befehl, um Mercurial aufzurufen ist hg (das chemische Zeichen für Quecksilber, englisch eben “mercurial” – soll wohl so ‘ne Art Wortspiel sein). Mercurial bring eine gute Dokumentation gleich mit. Eine Kurzversion wird angezeigt, wenn man nur hg aufruft – eine ausführlichere Variante wird bei hg help angezeigt.

Um ein neues Repository anzulegen, muss man nur in das Verzeichnis seiner Wahl wechseln (wo evtl. bereits nicht-versionierte Dateien liegen) und den Befehl hg init ausführen. Damit erstellt Mercurial ein neues Verzeichnis .hg, in das das komplette Repository abgelegt wird.

Nun kann man mit hg add und einem anschließenden hg commit -m "Adding files." seine Dateien in das Repository einchecken. Nun kann man den Source-Code weiterbearbeiten, irgendwann dann mit einem hg status nachschauen, was man so alles geändert hat und dann wieder mit hg commit einchecken.

Interessant wird es dann, wenn mehrere Repositories ins Spiel kommen. Möchte man jetzt eine Kopie des Repositories erstellen, wechselt man beispielsweise ins übergeordnete Verzeichnis und führt hg clone Original-Verzeichnis Clone-Verzeichnis aus. Dann kann man im Clone-Verzeichnis weiterarbeiten und auch hier einchecken.

Das Original-Verzeichnis ist so lange davon nicht betroffen, wie man ein hg push ausführt, das dann die Änderungen ins Original-Verzeichnis hochschieben würde. Idealerweise macht man vorher erst ein hg pull, um das Clone-Repository auf den neuesten Stand zu bringen und dann ein hg update, um die Dateien im Clone-Verzeichnis zu aktualisieren. Falls es im übergeordneten Repository schon Änderungen gegeben hat, muss vor dem Push mit hg merge gemergt werden.

Weitere Detail zur Nutzung von Mercurial kann man dem sehr guten Tutorial auf der offiziellen Mercurial-Seite entnehmen oder dem Tutorial von Joel Spolsky auf hginit.com.

Mercurial zusammen mit SVN

Man kann mit Mercurial auch dann nutzbringend einsetzen, wenn für das aktuelle Projekt ein anderes SCM wie zum Beispiel Subversion im Einsatz ist. Das kann dann folgendermaßen funktionieren:

Zunächst checkt man den Code wie gewohnt aus dem Subversion-Repository aus. Dann führt man im obersten Verzeichnis hg init aus. Dann legt man dort ein zusätzliches File .hgignore mit folgendem Inhalt an:

syntax: glob
.svn

Das verhindert, dass man die SVN-spezifischen Files mit eincheckt. Umgekehrt sollte man das Einchecken des .hg-Ordners ins SVN verhindern, indem man das svn:ignore-Property entsprechend setzt. Danach kann man mit hg add und hg commit das lokale Mercurial-Repository mit Inhalt füllen.

Nun arbeitet man immer zunächst gegen das Mercurial-Repository und checkt dort ein. Wenn man seinen Code der Allgemeinheit zur Verfügung stellen möchte, macht man schließlich ein svn commit. Man muss allerdings darauf achten, wenn man ein Update aus dem SVN macht, dieses Update auch in das lokale Mercurial-Repository einzuchecken.

Ein Wort zu git

Wenn es um verteilte Versionskontrollsysteme geht, fällt einem meistens vermutlich git ein. Wahrscheinlich hat man schon davon gehört, wie toll git ist und was git alles kann. Es gibt sogar eine Internetseite, die erklärt warum git besser ist als alles andere. Warum also Mercurial ausprobieren?

Für meine Begriffe liegt die Popularität von git – abgesehen davon, dass es sicher ein geniales SCM ist – hauptsächlich daran, dass die git-Benutzer lauter schreien als die Mercurial-Benutzer Ich bin immer davon abgeschreckt, wenn irgendetwas zu sehr gehypt und zu vollmundig angepriesen wird. Deshalb habe ich mich dazu entschieden, Mercurial auszuprobieren. Mercurial-Benutzer müssen nicht rumlaufen und Leute missionieren – sie benutzen einfach ihr SCM und sind glücklich damit dass es so toll funktioniert.

Nein. Scherz. Ich denke die Entscheidung sollte im ersten Schritt nicht zwischen Mercurial oder git getroffen werden, sondern für ein verteiltes Versionskontrollsystem. Denn das ist das zentrale Merkmal, das beide Systeme auszeichnet. Der Rest ist dann Geschmackssache.

Mittlerweile wurde der Artikel mehr als 3000 mal geklickt, hat 27 Antworten und eine intensive Diskussion produziert. Obwohl sich tatsächlich auch einige Leute gefunden haben, die ein paar Vorteile von ClearCase aufzeigen, ist doch die Mehrheit der Antworten damit beschäftigt Nachteile aufzuzeigen. Für mich kommt das natürlich nicht wirklich überraschend, aber es ist doch interessant zu sehen, dass es nicht nur daran liegt, dass ich keine Ahnung von ClearCase habe.

Was mich seit ich ClearCase kenne immer gewundert hat, ist dass es mindestens eine Person braucht, die sich um nichts anderes kümmert und andere Leute sehen das ebenfalls so:

The very fact that it’s complicated enough to require a full-time nanny is also worrying.

Auch immer noch ein Rätsel ist mir der Zweck der Dynamischen Views in ClearCase – seit wir wieder darauf umgestellt hatten, haben wir gemerkt, dass das Resultat davon, dass man sofort alle Änderungen sieht, ist dass man sofort alle Fehler hat, die jemand anders gemacht hat. Auch das war Thema der Diskussion:

Dynamic views are terrible unless you are in a very small team. And if that’s the case, why do you even have ClearCase? I have seen countless people’s views getting hosed because someone checked in files that broke the views of everyone else. You should always update and merge any conflicts on your own view. That way, the changes only affect you. With a dynamic view, you cannot merge down before pushing back up; you just commit and hope.

Dann habe ich noch einen nicht ganz ernst gemeinten Ratschlag bekommen, der zwar für uns leider nichts gebracht hat, weil ja ClearCase schon gesetzt war, den ich aber wegen seinem Unterhaltungswert hier wiedergeben möchte:

If you need an argument to convince people not to use ‘clearcase’, you can say that all the good developers hate it. I know, I wouldn’t work at any place who used clearcase as their source control. Heck, I would gladly suffer the pain of VSS to avoid clearcase.

Wer möchte kann sich einfach mal die ganze Diskussion auf Stackoverflow durchsehen – es sind echt ein paar interessante Kommentare dabei.

Als Schlusswort möchte ich noch diesen Kommentar zitieren, den ich so voll und ganz unterschreiben könnte:

If you’re considering integrating ClearCase into your development environment, I can offer only one piece of advice: don’t.

Für einen Softwareentwickler klingt der Spruch “wir sind zu 90% fertig” allerdings gar nicht gut. Denn in der Softwareentwicklung kennt man die sogenannte 90-90-Regel, die besagt, dass die ersten 90 Prozent der Entwicklung 90 Prozent der Zeit brauchen und die restlichen 10 Prozent die anderen 90 Prozent der Zeit. Die letzten 10 Prozent bis zur Fertigstellung einer Entwicklung dauern immer am längsten und sind auch immer die schwierigsten.

Wenn der Typ nun also sagt, “es sind doch nur noch 10 Prozent“, dann soll das eigentlich heißen “wir sind bald fertig” aber tatsächlich heißt es eher “es gibt noch eine ganze Menge zu tun“. Yamauchi liefert quasi selbst den Beweis dafür ab, denn in einem Interview Anfang dieses Jahres waren’s auch schon 90 Prozent

Mehr Infos zum Thema ninety-ninety rule gibt’s bei der Wikipedia oder im Artikel Ninety Percent Done, der auch ein paar Ansätze beschreibt, was man dagegen tun kann.

• How does Java technology relate to Web application development?
• How does Java technology relate to SOA/Web services?
• How does Java technology relate to dynamic languages and functional programming?
• How does Java technology relate to open source software development?

Jeder Abschnitt enthält weiterführende Links zu developerWorks- oder auch anderen Tutorials, wo man seine Kenntnisse dann auffrischen oder vertiefen kann.

^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$

über komplizierte wie

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

bis hin zu solchen, die man schon eher als völlig irre bezeichnen könnte:

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

die allesamt darauf abzielen eine mehr oder weniger genaue Abdeckung der in RFC 2822 – Internet Message Format definierten Vorgabe zu erfüllen.

Die Frage ist doch aber – warum tut man so etwas? Klar, man möchte dass der Benutzer eine gültige E-Mail-Adresse (im besten Fall seine eigene) in ein Formular einträgt. Aber dient eine Validierung der Gültigkeit mittels Regular Expressions wirklich diesem Zweck?

Mit fallen zwei Szenarien ein, wo ein Benutzer eine ungültige E-Mail-Adresse eingibt: Entweder er macht es unabsichtlich, wenn er sich vertippt oder so. Oder er macht es absichtlich, um irgendeine Zwangsregistrierung zu umgehen. In beiden Fällen greift die Validierung über Regular Expression nicht wirklich.

Erster Fall – Versehen: Wenn ich mich beim Eingeben der Mailadresse vertippe, dann dreht sich das doch meist um einzelne Buchstaben – dass ich das “@” vergesse kommt eher selten vor. D.h. ich kann mich leicht so vertippen, dass ich zwar eine formal gültige Adresse eingebe, die aber leider trotzdem falsch ist (z.B. Buchstabendreher im Vornamen).

Zweiter Fall – Absicht: Ich kann mir leicht eine lustige Mailadresse ausdenken, die bei der Validierung zwar durchgeht, aber völlig frei erfunden ist. Die Mailadresse hab.ich@erfunden.de erfüllt zwar die Validierung – ist aber deshalb noch lange keine gültige E-Mail-Adresse.

Eine mögliche Lösung könnte daher sein, die Mailadresse über Double Opt-in zu validieren, also dass man dem Benutzer eine Mail an diese Adresse schickt, die einen Link enthält, den der Benutzer klicken muss, um seine E-Mail-Adresse zu bestätigen. Aber auch diese Variante schützt nicht gegen mutwillige Falscheingabe – es gibt immer noch Spamgourmet, Mailinator und ähnliche Sites, die Wegwerf-E-Mail-Adressen bereitstellen.

Fazit: Mit Regular Expressions kann man zwar den Benutzer bei der Eingabe etwas unterstützen, aber der Weisheit letzter Schluss sind sie für die E-Mail-Validierung deshalb noch lange nicht. Und gerade deshalb braucht man sich auch nicht verkünsteln, um zu beweisen, wie toll man Regular Expressions (kopieren) kann.

Die Google App Engine ist die Cloud-Lösung von Google. Das Prinzip ist, dass man sich in der Implementierung seiner Applikation an die Vorgaben von Google hält und im Anschluss daran seine Applikation auf die Server von Google hochlädt und dort deren Ressourcen bis zu einem gewissen Grad kostenlos nutzen kann. Darüberhinaus hat man die Möglichkeit gegen Bezahlung weitere Ressourcen zu benutzen. Die Vorgaben sind entweder Python oder Java als Programmiersprache zu verwenden und gewisse Einschränkungen bei der Implementierung zu beachten, wie zum Beispiel keine direkten Filesystemzugriffe zu machen.

Im Gegenzug bekommt man eine API, mit der man auf die von Google zu Verfügung gestellte Infrastruktur zugreifen kann. Daten werden beispielsweise nicht in einer Datenbank gespeichert, sondern im Bigtable-Datastore. Das fühlt sich im ersten Moment an wie eine Datenbank, hat allerdings z.B. die Einschränkung keine Joins zu unterstützen, wodurch man ab und zu dazu gezwungen ist, seine Daten zwecks besserer Performance zu denormalisieren (siehe Artikel How I Learned to Stop Worrying and Love Using a Lot of Disk Space to Scale).

Das Projekt

Eins gleich vorweg: Ich zeige euch hier nicht, wie ihr mit der Google App Engine ein Blog implementiert. Ich glaube es gibt tausende Tutorials, die das tun. In diesem Artikel werde ich mit der Python-Version der Google App Engine eine kleine Applikation implementieren, die von Twitter die neuesten Tweets zieht, die mit dem Hashtag “#confession” getaggt sind. Wie die fertige Applikation einmal aussehen soll, könnt ihr euch hier ansehen: http://confessiontweets.appspot.com.

Ich werde die wichtigsten Features der Google App Engine hier jeweils kurz anreißen – weitere Details findet ihr in der sehr guten, aber leider nicht auf Deutsch verfügbaren Anleitung unter http://code.google.com/appengine/. Ich bitte meine manchmal vielleicht ein bisschen unbeholfene Art, Python zu implementieren zu entschuldigen – eigentlich komme ich aus der Java-Welt und habe die Google App Engine auch dazu benutzt, ein bisschen Python zu lernen.

Der vollständige Source-Code kann hier heruntergeladen werden: ConfessionTweets.zip

Update: Der Source-Code ist jetzt auch auf GitHub zu finden: https://github.com/zustandsforschung/ConfessionTweets.

Die Applikation

Die Applikation selbst basiert auf dem mit der App Engine mitgelieferten webapp Framework. Der Einstiegspunkt in die Applikation ist der folgende Code in der Datei “controller.py“:

application = webapp.WSGIApplication([('/', ConfessionListPage),
                                      ('/c/.*', SingleConfessionPage),
                                      ('/ajax', AjaxConfessionService)])
 
def main():
  run_wsgi_app(application)
 
if __name__ == "__main__":
  main()

Hier wird im Wesentlichen definiert, dass Zugriffe auf “/” auf die Klasse “ConfessionListPage” gemappt werden sollen, Zugriffe auf “/c/.*” – also auf alles was mit “/c/” anfängt auf die Klasse “SingleConfessionPage” und Zugriffe auf “/ajax” auf die Klasse “AjaxConfessionService“.
Für die beiden Klassen, die einzelne Seiten darstellen, habe ich eine gemeinsame Superklasse “Page” geschrieben, die bereits einige Variablen bereitstellt, die von beiden Klassen benötigt werden. Diese Klasse erbt selbst von “webapp.RequestHandler“, und hat damit deren Funktion als Einsprungpunkt in die Applikation.

class Page(webapp.RequestHandler):
  collection = None
  template_values = {}
  template_url = ''
 
  def get(self):
 
    header_path = os.path.join(os.path.dirname(__file__), '../templates/header.html')
    footer_path = os.path.join(os.path.dirname(__file__), '../templates/footer.html')
 
    live = 'localhost' not in self.request.host    
 
    self.template_values.update({ 'header_path' : header_path,
                                 'footer_path' : footer_path,
                                 'live' : live })
 
    self.page_title = 'ConfessionTweets'
 
    self.service()
 
    self.template_values.update({ 'page_title' : self.page_title })
 
    path = os.path.join(os.path.dirname(__file__), self.template_url)
    try:
        self.response.out.write(template.render(path, self.template_values))
    except TemplateDoesNotExist:
        logging.error('Template %s not found!' % self.template_url)

Die Methode “get” wird automatisch vom webapp Framework aufgerufen, wenn eine Seite (per GET-Request) angefragt wurde. Ebenso gibt es Framework-Methoden für POST- oder HEAD-Requests. Dann werden hier einige Werte initialisiert wie beispielsweise der Pfad zu Header und Footer oder der Seitentitel. Dann folgt ein Aufruf der Methode “service“, die wie wir gleich sehen werden von den erbenden Klassen implementiert wird. Abschließend wird die Methode “template.render” aufgerufen, die als Parameter den Pfad zum Template, das die Seite darstellt und ein Dictionary mit den auf dem Template verwendeten Werten bekommt. Innerhalb dieser Methode werden die Werte in das Template geschrieben und das Resultat in die Response ausgegeben.

Die ConfessionListPage

Von dieser Klasse wird nun die Klasse “ConfessionListPage” abgeleitet. Diese Klasse ist für die Listendarstellung der einzelnen Tweets verantwortlich.

class ConfessionListPage(Page):
 
    def service(self):
        self.template_url = '../templates/confession_list.html'
 
        twitter_request = TwitterRequest()
        tweets = twitter_request.get_latest_tweets()
 
        self.template_values.update({ 'tweets' : tweets })

Da alles andere schon in der “Page“-Klasse passiert, muss hier nur noch die “service“-Methode implementiert werden, die von der Page-Klasse aufgerufen wird. Als erstes wird der Pfad zum Template, also der View für diese Seite definiert. Dann wird mit Hilfe der Klasse “TwitterRequest“, die wir gleich implementieren werden, eine Liste von “Tweets” erzeugt, die dann mit der Anweisung “self.template_values.update” an das Template übergeben werden.

Im Template selbst findet sich der folgende Code:

{% include header_path %}
{% for tweet in tweets %}
	<script type="text/javascript" >
		confessions["{{ tweet.key.name }}"] = "{{ tweet.key.name }}";
	</script>
	{% if forloop.first %}
		<div id="{{ tweet.key.name }}" class="first_confession">
			<h3><a href="/c/{{ tweet.key.name }}">{{ tweet.title }}</a></h3>
			<p>Confessed {{ tweet.published|timesince }} ago by <a href="{{ tweet.author_url }}">{{ tweet.author }}</a></p>
		</div>
	{% else %}
		<div id="{{ tweet.key.name }}" class="confession">
			<h3><a href="/c/{{ tweet.key.name }}">{{ tweet.title }}</a></h3>
			<p>Confessed {{ tweet.published|timesince }} ago by <a href="{{ tweet.author_url }}">{{ tweet.author }}</a></p>
		</div>
	{% endif %}
{% endfor %}
	<div id="new_confessions" ></div>
	&darr; <a id="more_button" href="javascript:void(0)" onclick="getConfessions(confessions)" >more</a> &darr;
{% include footer_path %}

Die Templates für die Goolge App Engine werden mit Hilfe des Django-Frameworks erzeugt. Eine Liste von verwendbaren Template-Tags kann man daher der Django-Dokumentation selbst entnehmen: Built-in template tags and filters. Die erste und letzte Zeile binden den Header und Footer entsprechend den in der Klasse “Page” definierten Pfaden ein. Dann wird über die Liste der Tweets mittels “for tweet in tweets” iteriert. Innerhalb dieser Schleife stehen die einzelnen Listenelemente dann in der Variable “tweet” zur Verfügung. Da wir das erste Element dieser Liste speziell formatieren wollen, machen wir von der innerhalb von “for“-Schleifen vorhandenen Variable “forloop.first” gebrauch: Wenn wir das erste Element haben, dann schreiben wir einen anderen Div um die Ausgabe drumherum als für alle anderen Schleifenelemente. Zur Optimierung könnte man sicherlich nur das “class“-Attribut in den if-else-Block setzen, ich habe das hier aber nicht gemacht, um zu verdeutlichen, was mit diesem Template-Tag so alles möglich ist.

Die SingleConfessionPage

Da ich auch in der Lage sein möchte, jeden Tweet unter seiner eigenen URL darstellen zu können, habe ich eine Tweet-Klasse implementiert, die alle Daten aus dem Feed im Datastore speichert:

class Tweet(db.Model):
    published = db.DateTimeProperty(required=True)
    status_url = db.StringProperty(required=True)
    title = db.StringProperty(required=True)
    content = db.StringProperty(required=True)
    profile_image = db.StringProperty()
    author = db.StringProperty(required=True)
    author_url = db.StringProperty(required=True)

Diese Klasse erbt von der vom App-Engine-Framework zur Verfügung gestellten Basisklasse db.Model und hat damit schon eine Menge Funktionen, wie z.B. die get_or_insert-Methode, die innerhalb der __get_tweet_from_xml__-Methode der TwitterRequest-Klasse aufgerufen wird, und die alle übergebenen Daten auch gleich im Datastore speichert, falls es den gleichen Tweet nicht schon gibt:

        tweet = Tweet.get_or_insert(key_name=key_name, published=published, status_url=status_url, title=title, content=content, profile_image=profile_image, author=author, author_url=author_url)

Man muss diese statische Methode nicht benutzen, um ein Objekt im Datastore zu erzeugen, man kann auch einfach den Konstruktor der Klasse verwenden und dann mit der “put“-Methode die Daten persistieren:

	tweet = Tweet(key_name=key_name, published=published, status_url=status_url, title=title, content=content, profile_image=profile_image, author=author, author_url=author_url)
	tweet.put()

Ich identifiziere dabei die einzelnen Tweets anhand der base-64-codierten Status-URL, die mir von Twitter geliefert wird und die pro Tweet eindeutig ist. Diesen Wert verwende ich nicht nur hier als key_name, sondern auch in der URL für die einzelnen Tweets, die dann etwa “/c/eG94T3BhbEFtYW5kYS9zdGF0dXNlcy8yMjgzMTI0MDg5” lautet. Eine solche URL wird dann vom Controller auf die get-Methode der Klasse SingleConfessionPage gemappt:

class SingleConfessionPage(Page):
 
    def service(self):
        self.template_url = '../templates/confession.html'
 
        match = re.match("/c/(.*)", self.request.path)
        if match is not None:
            key_name = urllib.unquote(match.group(1))
 
        tweet = Tweet.get_by_key_name(key_name)
 
        if tweet is None:
            self.redirect('/')
            return
 
        self.page_title += ' - A confession by ' + tweet.author + ' made ' + timesince.timesince(tweet.published) + ' ago ' 
 
        self.template_values.update({ 'tweet' : tweet })

Dort lese ich den Key wieder aus der URL aus, und hole dann den entsprechenden Tweet per “Tweet.get_by_key_name(key_name)” aus dem Datastore und übergebe ihn ans Template, das dann eine vereinfachte Variante von dem für die ConfessionListPage ist:

	{% include header_path %}
			<div id="{{ tweet.key.name }}" class="first_confession">
				<h3><a href="{{ tweet.status_url }}">{{ tweet.title }}</a></h3>
				<p>Confessed {{ tweet.published|timesince }} ago by <a href="{{ tweet.author_url }}">{{ tweet.author }}</a></p>
			</div>
	{% include footer_path %}

Der TwitterRequest-Service

Diese Klasse führt in der Methode “get_latest_tweets” den eigentlichen Request an Twitter aus, mit dem die Applikation ihre Daten erhält. Dabei wird in der Methode “__get_xml__” mittels der urlfetch-Methode des Frameworks von der Twitter-Suche ein XML geholt und in eine DOM-Datenstruktur überführt:

class TwitterRequest:
 
    def __init__(self):
        self.request_url = 'http://search.twitter.com/search.atom?q=%23confession&rpp=5'
 
    def get_latest_tweets(self, page='1'):
        tweets = []
 
        self.request_url += '&page=' + page;
        logging.debug('Requesting %s' % self.request_url)
 
        twitter_response = self.__get_xml__(self.request_url)                
 
        if twitter_response is None:
            logging.warning('Trying again...')
            twitter_response = self.__get_xml__(self.request_url)
 
        if twitter_response is None:
            return None 
 
        for entry in twitter_response.getElementsByTagName('entry'):
            tweets.append(self.__get_tweet_from_xml__(entry))
 
        return tweets
 
    def __get_xml__(self, request_url):
        try:
            result = urlfetch.fetch(request_url)
        except DownloadError:
            logging.error('Could not contact webservice.')
            return None
        if result.status_code == 200:
            return parseString(result.content)
 
    def __get_tweet_from_xml__(self, entry):
        published_string = entry.getElementsByTagName('published')[0].firstChild.data
        published = datetime.datetime.strptime(published_string, "%Y-%m-%dT%H:%M:%SZ")        
 
        status_url = entry.getElementsByTagName('link')[0].getAttribute('href')
        title = entry.getElementsByTagName('title')[0].firstChild.data
        content = entry.getElementsByTagName('content')[0].firstChild.data
        author = entry.getElementsByTagName('author')[0].getElementsByTagName('name')[0].firstChild.data
        author_url = entry.getElementsByTagName('author')[0].getElementsByTagName('uri')[0].firstChild.data
        profile_image = entry.getElementsByTagName('link')[1].getAttribute('href')
 
        key_name = base64.standard_b64encode(status_url[len('http://twitter.com/'):len(status_url)])
        tweet = Tweet.get_or_insert(key_name=key_name, published=published, status_url=status_url, title=title, content=content, profile_image=profile_image, author=author, author_url=author_url)
        return tweet

Dann rufe ich für jeden “entry“-Knoten in diesem XML die “__get_tweet_from_xml__“-Methode auf, die die relevanten Daten aus dem Knoten ausliest und letztendlich mit der “get_or_insert“-Methode von db.Model die Daten im Datastore abspeichert. Die “get_latest_tweets“-Methode gibt schließlich eine Liste mit den einzelnen Tweet-Objekten, die aus dem XML des Webservice abgerufen wurden zurück.

Der AjaxConfessionService

Ich möchte auf der Startseite auch die Möglichkeit bieten, durch die Liste der Tweets blättern zu können. Zu diesem Zweck benutze ich eine AJAX-Schnittstelle, um beim Klick auf den more-Link weitere Tweets von Twitter abzuholen und einzublenden. Das JavaScript schickt den Request an den Pfad “/ajax“, der auf die Klasse “AjaxConfessionService” gemappt wird. Auch diese Klasse erbt wieder von “webapp.RequestHandler” und implementiert die “get“-Methode:

class AjaxConfessionService(webapp.RequestHandler):
 
    def get(self):
        page = self.request.get('page', '');
 
        twitter_request = TwitterRequest()
        tweets = twitter_request.get_latest_tweets(page)
        self.response.out.write('{ "confessions": {')
        for tweet in tweets:
            self.response.out.write('"' + tweet.key().name() + '" : { ')
            self.response.out.write('"title" : "' + tweet.title.replace('"', '\\"') + '", ')
            self.response.out.write('"author" : "' + tweet.author.replace('"', '\\"') + '", ')
            self.response.out.write('"author_url" : "' + tweet.author_url.replace('"', '\\"') + '", ')
            self.response.out.write('"published" : "' + timesince.timesince(tweet.published) + '"')
            self.response.out.write('}')
            if tweet is not tweets[-1]:
                self.response.out.write(', ')
        self.response.out.write('}}')

Hier werden auch wieder die aktuellsten Tweets der entsprechenden Ergebnisseite bei Twitter abgeholt. Hier habe ich kein Template verwendet, sondern wandle die resultierenden Tweet-Objekte direkt in einen JSON-String um, den ich in die Response schreibe. Auf der Clientseite liest jetzt mein JavaScript wiederum das JSON aus und konstruiert HTML, das in die Seite eingefügt wird.

Konfiguration

Damit die Applikation überhaupt in der Google-App-Engine lauffähig ist, braucht sie noch eine Konfiguration. Diese wird in der Markup-Language YAML geschrieben und landet in einer Datei “app.yaml” im Wurzelverzeichnis der Applikation:

application: confessiontweets
version: 1
runtime: python
api_version: 1
 
handlers:
- url: /robots.txt
  static_files: robots.txt
  upload: robots.txt
 
- url: /css
  static_dir: css
  expiration: 1h
 
- url: /images
  static_dir: images
  expiration: 1d
 
- url: /js
  static_dir: js
  expiration: 60s
 
- url: /.*
  script: confession/controller.py

Zuoberst muss man das Label seiner Applikation deklarieren, so wie man es später auch in der Verwaltung der App-Engine angibt. Dann kommt die Version der Applikation und die Runtime – in unserem Fall Python. Die API-Version ist aktuell noch immer 1.

Unterhalb dieser Sektion definiert man nun einzelne Handler für verschiedene Files. Man kann keine der hochgeladenen Files direkt aufrufen, daher definiere ich hier zunächst die Position der robots.txt und der Verzeichnisse für CSS, Bilder und JavaScript, jeweils mit einer unterschiedlichen Cache-Expiry-Zeit.

Als letztes definiere ich noch, dass alles, was bisher nicht gemappt werden konnte an das Skript “/confession/controller.py” delegiert werden soll.

Und jetzt ins Internet damit…

Um das ganze wirklich ins Netz zu bringen, muss man sich mit einem Google-Account auf der Seite anmelden und bekommt dann einen Freischaltcode per SMS zugeschickt. Damit kann man dann bis zu 10 Google-App-Engine-Applikationen hosten lassen. Im Web-Interface muss ich jetzt zunächst eine Applikation mit dem gleichen Label wie in der Konfiguration unter “application” angegeben anlegen:

Da diese Applikations-Ids über die gesamte Google-App-Engine eindeutig sind, muss man unter Umständen ein bisschen rumprobieren, bis man einen Namen gefunden hat, der noch verfügbar ist.

Der Upload der Applikation erfolgt dann über ein mitgeliefertes Python-Skript:

	python appcfg.py update

Man wird noch nach Mailadresse und Passwort gefragt und kann anschließend sein Werk im Internet bewundern.

Wenn man jetzt noch ein bisschen Styling und eine nette Hintergrundgrafik hinzufügt, erhält man bereits ein nettes kleines Mashup. Ich habe der ganzen Sache noch ein paar nette Animationseffekte spendiert und im Endergebnis sieht das ganze dann folgendermaßen aus:

Fazit

Natürlich hat man bei Verwendung der Google-App-Engine einen gewissen Vendor-Lock-In-Effekt, vor allem durch die Verwendung des Datastore statt einer Datenbank. Auf der anderen Seite bietet die GAE eine interessante Möglichkeit, mit einer neuen Idee schnell und günstig – weil kostenlos – Live zu gehen und erst wenn die Applikation ein gewisses Maß an Usern erreicht hat muss man sich über Rentabilität überhaupt Gedanken machen.

Außer dem hier beschriebenen Mini-Mashup habe ich noch meine Video-Verwaltungsapplikation “veedemus – movie collection” mit der Google App Engine implementiert. Dort kann man schon eher sehen, dass nicht nur Spielereien, sondern auch komplexe Applikationen mit der GAE umsetzbar sind.

Abgesehen davon dass das Team ein Produkt verwenden soll, von dem es keine Ahnung hat, ist ClearCase selbst ziemlicher Schrott.

Ein kleines Beispiel: Um eine Datei zu löschen, reicht es nicht das File zu löschen und einzuchecken. Man muss zunächst zusätzlich zur Datei den übergeordneten Ordner auschecken, dann kann man die Datei erst löschen und dann am Ende alles zusammen wieder einchecken.

Ein weiteres interessantes Thema: Die dynamischen Views, für die ClearCase so berühmt ist. Schade nur, dass wir feststellen mussten, dass ein Build auf der dynamischen View bei uns so zwischen 15 und 30 Minuten dauert – hat man die Files lokal, dann ist das eine Sache von ungefähr einer Minute. Daher pfeifen wir jetzt auf dynamische Views und arbeiten mit Snapshot-Views.

Auch lustig: Es gibt keine Möglichkeit, Dateien von der Versionskontrolle auszuschließen. Also sowas wie die ignore-Funktionalität bei CVS oder SVN. Eine absolute Notwendigkeit, um vernünftig arbeiten zu können. Geht bei ClearCase einfach nicht. Resultat: Wir haben bereits nach 2 Wochen ein lustiges Durcheinander an Dateien im Repository, die dort nie hätten rein sollen.

Noch mehr über die interessanten Features von ClearCase kann man in den beiden Artikeln ClearCase, making easy things hard und Reasons NOT to use ClearCase lesen.

Insgesamt bekommt man bei der Bedienung so ein bisschen den Eindruck, dass sich jemand wirklich viele Gedanken gemacht hat, wie er den Entwicklern die Arbeit mit dem Tool besonders schwer machen kann. Ich glaube ich habe in den letzten zwei Wochen die Hälfte der Zeit damit verbracht, mit ClearCase zu kämpfen und mit den Support zu telefonieren.

Ich bin schon sehr gespannt wieviel Zeit wir noch mit diesem Tool verlieren, das uns eigentlich die Arbeit hätte erleichtern sollen.