[29dsnh4p5a] Am 23. Juni fand das erste Treffen der Google User Group Hamburg statt. Sie beschäftigt sich mit der Vielzahl der Technologien jenseits einer einfachen Suche, die Google inzwischen zur Nutzung auch für eigene Projekte anbietet.
Die Firma “eprofessional” stellte an diesem Abend den Raum und netterweise auch die Getränke.

Im ersten Teil des Abends stellte Jens Trapp die AppEngine und speziell die Nutzung mit Java vor.
Die AppEngine nutzt nicht eine “normale” relationale Datenbank, sondern die speziellen Datastores von Google zur manchmal über die ganze Erde verteilten Speicherung großer Datenmengen. Um die Anpassung bestehender Software zu vereinfachen, ist für einfache Fälle auch eine Abfrage in SQL-Syntax möglich. Einen ähnlicher Weg ist mir auch von der nativen Symbianentwiclung bekannt. Mich persönlich überzeugt das nicht richtig. SQL ist eine interpretierte Sprache. Wird sie von einer statisch typisierten, compilierten Sprache wie Java oder C++ aufgerufen, verbindet man die Nachteile beider Konzepte, ohne die Vorzüge zu genießen. Man verliert die Typsicherheit, riskiert sogar noch Sicherheitslücken (SQL-Injektion), kann andererseits nicht die wunderbaren Eigenschaften einer kompletten SQL-Implementierung nutzen.

Im zweiten Teil stellte Thomas Steiner “Mapplets” und ihre technologischen Verwandten “Gadgets” vor. Gadgets können per Javascript auch Webservices aufrufen, dabei werden auch die Sicherheitsrichtlinien der Browser beachtet. Die Gadgets können neben der iGoogle-Webseite auch in anderen Kontexten aufgerufen werden und sogar als Suchmaschinenanzeigen geschaltet werden. Als nettes Beispiel wurde eine Anzeige präsentiert, die bei Sonnenschein oder bei Regen jeweils verschiedene Angebote darstellt.

Zum offiziellen Blog der Google Technology User Group Hamburg

Die Notwendigkeit für so einen Test habe ich schon vor drei Jahren erkannt. Mein damaliger Webhoster hat nach einem Serverupdate vergessen den Mimetyp zu konfigurieren :-( . Solche Fehler wollte ich in Zukunft schnell finden. So habe ich zunächst ein Kommandozeilenwerkzeug geschrieben. Da war ich der Zeit wohl voraus, selbst Online-Shops für Handysoftware haben sich unnötige Fehler in der JAD-Erzeugung geleistet. Schließlich kam ich auf die Idee, eine Onlineversion zu veröffentlichen und so auch Werbung für meine Kompetenz zu machen.

Der Jad Checker ist zugleich mein Projekt, um Googles App Engine einen Praxistest zu unterziehen. Seit August 2008 ist der Dienst online und wurde in den Entwicklerprogrammen von Nokia, SonyEricsson, Sun und Vodafone vorgestellt. Ein Mitarbeiter des Nokia-Entwicklerprogramms gab als Kommentar “Cool”. Wahrscheinlich hat er schon mit vielen dieser JAD-Problemen zu tun gehabt.

Bisher bin ich mit der AppEngine zufrieden. Die Entwicklung ging zügig, die Anwendung läuft rund, und es gab noch keine negativen Rückmeldungen. Den Onlinedienst finden Sie hier: jadcheck.appspot.com

from google.appengine.api import urlfetch
...
response = urlfetch.fetch(url)
content = response.content

Wenn alles gut geht, reicht das schon. So weit ist es sehr praktisch. In der Praxis muss man jede Menge Fehler abfangen, zum Beispiel wie in diesem Ausschnitt:

    try:
        response = urlfetch.fetch(jadurl)
        if response.status_code == 200:
            self.xxheaders = response.headers
            self.xxcontent = response.content
            self.xxFetched = True
        elif response.status_code == 404:
            self.errortext = "File not found"
            self.xxcontent = "not found"
        else:
            self.errortext = "Bad Response Code"
            self.xxcontent = response.status_code
    except InvalidURLError:
        self.errortext = "Invalid URL"
    except DownloadError:
        self.errortext = "Error downloading file"
    except ResponseTooLargeError:
        self.errortext = "File to large"

Man hat auch Zugriff auf die HTTP-Header, beispielweise erhält man den Mime-Type mit

response.headers['content-type']

In meinen speziellen Fall würde mich auch interessieren, ob ein Header doppelt geschickt wird. Diese Information scheint man leider nicht zu bekommen.

Man kann auch SSL-geschützte Seiten mittels “https://” runterladen. Leider werden dabei derzeit (1.1.) laut Dokumentation die Zertifikate nicht geprüft, sprich die stärkere Sicherheit ist nicht da. Das schränkt die Anwendung zurzeit noch ein.

filecontent = self.request.get('uploadfile')

Der Dateiinhalt befindet sich danach in der Variable “filecontent”. Wenn es eine Textdatei ist, kann ich den Inhalt einfach wie einen String verarbeiten.
Für viele Anwendungsfälle ist das sehr bequem und ist völlig ausreichend. Interessant wäre noch zu wissen:

• Wie kommt man an den ursprünglichen Dateinamen ran?
• Kann man möglichst früh die Verarbeitung verweigern, wenn die Datei zu groß ist?

Das SDK kommt mit einem eigenen Webserver. Man startet den Servers mit
dev_appserver.py helloworld
Im Verzeichnis muß eine Konfigurationsdatei im Yaml-Format liegen. In dieser Datei werden URLs den Python-Dateien oder auch Bildern, etc zugeordnet. Fehlt die Datei, oder enthält sie nicht die benötigten Informationen, wird eine Exception geworfen.

Einige Dateien werden werden automatisch in Starverzeichnis des Nutzers angelegt, man kann diese leicht mal übersehen:
eine Konfigurationsdatei des SDK in userdir/.appcfg_nag sowie ein Datastore (praktisch die Datenbank) in userdir\temp\dev_appserver.datastore

Enthalten ist ein kleines Framework mit Namen “WebApp”.

Um den Python-Code vom HTML-Code zu trennen, gibt es eine Template-engine mit Django-kompatibler Syntax.
Ich hatte ein Problem mit den Templates: der XML-Header() am Anfang führte dazu, dass diese nicht angezeigt wurden.

Die Template-Sprache selbst nutzt geschweifte Klammern. Das ist verhältnismäßig kompakt, leider kann dadurch das Template schnell zu invaliden HTML-Code ausarten, so dass man das Template selber kaum noch im Browser überprüfen kann.

Zum Speichern der Daten einer Webanwendung nutzt man weder die sonst allgegenwärtigen SQL-Datenbanken noch das Dateisystem. Statt dessen gibt es ein spezielles Storage. Positiv dabei: Man kann eine Klasse einfach von “db.Model” ableiten, und die Objekte lassen sich dann komplett in den Datastore schreiben und lesen. Um die einzelnen Instanzvariablen muss man sich keine Gedanken machen, und man muss auch keine Datenbanktabellen deklarieren. Eine SQL-ähnliche Abfragesprache gibt es auch, aber offenbar eher als “syntaktischer Zucker”.