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

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 <pfad-zur-applikation>

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.

Von Lightbox-ähnlichen JavaScript-Bibliotheken gibt’s Unmengen, so dass es wahrscheinlich für jeden Anwendungszweck eine Variante gibt, wenn man sie nur finden würde.

Eine tolle Übersicht bietet “The Lightbox Clones Matrix“, wo mittlerweile mehr als 40 Lightbox-Clones gelistet werden, die sich auch nach Kategorien wie “zugrundeliegendes JavaScript-Framework” oder deren Features (kann Bilder/IFrames/Flash anzeigen) filtern lassen.

“Kann man denn schon was sehen?”

empfehle ich eine Antwort in Form von folgender URL zu geben:

http://www.kannmanschonwassehen.de

Da bisher jeder Hersteller von Widgets seine eigene Variante hatte, um so etwas zu bauen mussten Programmierer ihre Widgets für jede Plattform anpassen oder komplett umbauen. An dieser Stelle kommt die Universal Widget API von Netvibes ins Spiel, die es sich zur Aufgabe gemacht hat, ein einheitliches Framework und eine API zu schaffen, mittel dessen Widgets auf vielen Verschiedenen Systemen lauffähig gemacht werden können. Aktuell werden unterstützt iGoogle, Windows Vista, Apple Dashboard, Live.com, iPhone, Opera, MySpace und die Integration in Blogs.

Als Beispiel habe ich ein kleines Widget gebastelt, was das jeweils aktuellste Bild aus dem RSS-Feed von FFFFOUND! darstellt.

Im Prinzip besteht ein Widget für die UWA aus einer einzelnen XHTML-Datei, die sich aus 5 wesentlichen Teilen zusammensetzt:

Der Header
Im Header werden Metainformationen wie der Titel des Widgets, der Autor, eine Beschreibung und ähnliche Dinge eingetragen.

<meta name="author" content="Zustandsforschung" />
<meta name="description" content="image bookmarking" />
<meta name="apiVersion" content="1.0" />
<meta name="autoRefresh" content="20" />
<meta name="debugMode" content="true" />

<link rel="stylesheet" type="text/css"
href="http://www.netvibes.com/themes/uwa/style.css" />
<script type="text/javascript"
src="http://www.netvibes.com/js/UWA/load.js.php?env=Standalone"></script>

<title>FFFFOUND!</title>
<link rel="icon" type="image/png"
href="http://ffffound.com/favicon.ico" />


Die Konfiguration
Mittels eines speziellen XML-Formates wird dann die Konfiguration definiert, wobei man Checkboxen, Eingabefelder oder Dropdowns anlegen kann. Die vom Benutzer dort eingetragenen Werte können dann über eine API wieder ausgelesen und verwendet werden.

Bei meinem Beispiel hat’s keine Konfiguration – das geht auch und sieht dann so aus:

<widget:preferences>
</widget:preferences>


Styles
Da es sich bei einem UWA-Widget letztendlich um HTML handelt, kann das Widget mit CSS gestylt werden:

<style type="text/css">
.ffffound {
text-align:center;
}
.ffffound img {
max-width:250px;
}
</style>


JavaScript
Der Hauptteil des Widgets ist ein JavaScript: Hier muss man eine widget.onLoad-Funktion schreiben, die beim Start des Widgets aufgerufen wird. Ansonsten kann man hier so ziemlich alles machen, was man mit JavaScript so alles machen kann. Außerdem gibt’s noch eine API für den vereinfachten Zugriff auf AJAX-Funktionen und ein paar DOM-Erweiterungen.

<script type="text/javascript">
var FFFFound = {};

FFFFound.feedUrl = "http://feeds.feedburner.com/ffffound/everyone";

FFFFound.display = function(feed) {
widget.log(feed);
widget.log(feed.items[0].content);
widget.setBody("<div class=\"ffffound\">"
+feed.items[0].content+"</div>");
}

widget.onLoad = function() {
UWA.Data.getFeed(FFFFound.feedUrl, FFFFound.display);
}
</script>


Body
Im Body definiert man mit HTML die Grundstruktur des Widgets. Meistens wird man aber eher alles wichtige per JavaScript hinzugefügt und der Body sieht dann so aus:

<body>
<p>Loading... </p>
</body>


Das Endergebnis bzw. den kompletten Sourcecode für das Widget könnt ihr euch hier mal anschauen: ffffound-Widget. Und es gibt natürlich auch hierfür ein tolles Cheat-Sheet, wo alles draufsteht, was man wissen muss, um ein UWA-Widget zu erstellen.