OpenID - Closed Data on Google App Engine

Oder: Daten? Wer braucht schon Daten?

Relativ kürzlich hat ich in der Google App Engine mindestens für Java Anwendungen etwas recht störendes geändert.
Bisher war es immer einfach möglich, mit dem Python Werkzeug den kompletten Datenbestand aus dem Data Store der App Engine herunterzuladen oder einen kompletten Stand wieder hochzukopieren.
Solche Kopien sind für das Testen von Anwendungen lokal in meiner Welt essenziell. Es geht einfach meist nicht ohne einen wenigstens teilweisen Abzug von Produktionsdaten. Man kommt so einfach näher an Probleme heran, die man nicht entdeckt, wenn man nur auf einem zu kleinen, synthetischen lokalen Datensatz arbeitet. Außerdem zeichnet sich der Data Store in der Entwicklungsinstanz der Google App Engine als nicht gerade persistent heraus, wenn man bedenkt, daß das Verzeichnis bei jedem sauberen Build der Software eigentlich bei jedem Buildsystem gelöscht wird. Und umgekehrt kann man mit dem Werkzeug lokalen keinen Datenbestand erzeugen und als Basisdaten installieren. Dieser Weg war nie möglich, da man zwar lokal alle aus einer Datenbank einpielen konnte, sie aber nicht extrahieren konnte. - Seltsam aber dokumentiert.
Und selbst das geht nun nur noch, wenn die Anwendung nicht den OpenID Login benutzt. Dieser heißt zwar immernoch "Experimental", funktioniert aber seit geraumer Zeit sehr zufriedenstellend.
Was hat jetzt der Login mit den Datenkopien zutun? Eigentlich wenig, wäre da nicht die remote_api, die die Nutzung der Tools erlaubt hat. Diese braucht natürlich zu Sicherheit einen Login, und eben diesen Login erreicht sie nur über Google Accounts - nicht über OpenID.
Und seit kurzen kann man in der Google App Engine nicht mehr die Authentisierungsmethode umschalten.
Wege um dieses Problem herum ergeben sich aber realistisch nur für Python Anwendungen.
Schön, daß man die Daten zwischen Google Diensten hin- und herschieben kann, aber im Zweifel brauche ich vollen Zugriff auf meine eigenen Daten, nicht weil ich den Google Diensten zum Backup nicht traue oder so, sondern einfach um Anwendungen zu schreiben.

Bis das nicht wieder anders aussieht oder mir jemand einen Ausweg zeigt: Finger weg von der Google App Engine für Web-Anwendungen - also für allen, was wirklich einen Benutzerlogin braucht, es sei denn, man will ausgerechnet den selbst implementieren, was nun nicht mehr in den modernen "Mesh-Up" passen würde.

Herbst Update

Ruhig hier gewesen in letzter Zeit. Aber es gab ja auch einige Probleme, die relativ nervig waren, und für die es keine Lösungen gab, die man mal eben aus dem Internet kopieren könnte.

JDO ist eine schöne, einfache Persistenz-Schnittstelle (Auch wenn man die Kritik an der Google Implementierung in der Google App Engine mal mit einrechnet.), aber der Enhancement Prozeß auf dem Kompilierten Code war für Tangram nicht nur eine Konzeptionelle Unschönheit.

Das wichtigste Problem damit war die mangelnde Update-Fähigkeit des Entwicklungssystems für Tangram auf neuere Java-Versionen, weil dort der JDO Enhancer nicht mehr als Compiler-Plugin funktionierte

Dafür gibt es nun eine neue Enhancement-Mimik in Tangram und allen Beispielanwendungen, die sicherstellt, daß man nicht mehr mit "aus Versehen" nicht enhancetem Code und damit ohne jede Möglichkeit die Anwendung zu benutzen auch nur einen Testlauf starten kann. Das gibt wesentlich mehr Vertrauen, daß das produzierte Ergebnis auch irgendwo sinnvoll laufen kann und nicht nur den Compiler, der ja von dem ganzen Prozeß ohnehin nichts mitbekommt, glücklich macht.

Der Compiler wurde mit den letzten Commits nach GitHub aber auch wieder ein wenig glücklicher, da ich die Warning-Levels weiter heraufgesetzt habe und in der Folge ein paar Zeilen für Sicherheit und Eleganz des Codes investiert habe. Natürlich ist der CI Server im BuildHive der cloudbees dabei eine große Hilfe, das am Ende wieder alles zusammenpaßt.

Das Aufsetzen der eigenen Umgebung für Tangram mit Eclipse wurde um ein paar lästige Schritte bereinigt, sodaß es nun endlich wieder auf zu neuen Ufern in den Anwendungen von Tangram gehen kann.

BuildHive

Wer sich heute noch selbst Computer in ein Rechenzentrum stellt, kann irgendwie nicht rechnen - oder es ist sein Kerngeschäft.
Ein Stelle, wo es bisher immer sehr bequem oder notwendig war, noch detailliert auf die Server zugreifen zu können, ist der Softwaretest und -bau. Aber mit dem neuen BuildHive Dienst für Projekte auf github ist auch hier ein weitere Schritt getan, dieses auch in die Wolke zu schieben.
Natürlich ist eine Voraussetzung dafür, daß man sich standardisierter oder verbreiteter Techniken bedient. Mit Gradle, Java, Maven-Repositories etc. ist das z.B. gegeben. Erfreulich: Auch meine persönlichen Extravarganzen in Sachen Ordnerstruktur sind mit dem Build-System beschrieben und damt kein Problem. Zeitaufwand, hier einen CI-Server zu bekommen? Keine 5 Minuten!
Andere Projekte sind da viel komplizierter und überhaupt, muß man da sehr individuell vorgehen? Ich habe viel Verständnis für Individualisten und persönliche Bedürfnisse, aber nach all den Jahren in diesem Gewerbe ist es für mich ein Indikator, daß man evtl. nicht seinen Grips in diese Stelle der Software setzen sollte sondern genau hier die ausgetretenen Pfade nehmen sollte, die einem Sicherheit beim Bauen, Testen und Betriebsübergang geben. Fünf Minuten werden es vermutlich nicht sein, aber in diesem Bereich sehr schematisch vorzugehen ist eher eine Hilfe als ein Zeichen fehlender Ideen, es besser zu machen.
Der erfreuliche Nebeneffekt - und genau dafür ist so etwas ja da: Diese Umgebung deckte wieder einmal ein paar kleinere Schwächen im Code auf und regte mich dazu an, noch einmal ein Versions-Update von Gradle durchzuführen.
Schon wieder? Ja, Gradle bewegt sich mit großen Schritten auf eine ehrliche Version 1.0 zu und ließ es sich - zum Glück - nicht nehmen, noch ein paar inkompatible aber notwendig Änderungen durchzuziehen.

Noch mehr funky Groovy - und gradle blues

Rendering war ja nun schon lange nicht mehr mein Problem mit den bequemen Velocity Templates im Repository. Einiges Sites laufes ja schon damit (z.B. themen-geburtstag.de). Die URL-Formate lassen ebenfalls dort definieren, wenn man möchte, was sicherlich ein wenig schwieriger im Coding ist.
Neben dem eigentlichen Datenmodell fehlt nun noch die Action im ganzen, die ich auch gerne in's Repository verlegen würde - zumindest wieder einmal als Option, da das Verhalten doch etwas ist, was man ähnlich oft tunen will, wie das Layout.
Bisher habe ich das mit einem eigenen Satz Controller sauber lösen können, aber eben nicht so agil oder dynamisch wie die Styles und Templates.
Zumindest ist es nicht mehr meine Sicht auf moderne Web-Entwicklung, daß man einen Satz an Funktionalität fest eingebaut hat und nur noch Views darüber legt.
Und da sich am Horizont weitere Projekte abzeichen, die eher Communities als reine Websites werden sollen, bestand wieder einmal Handlungsbedarf.
Also habe ich nun den lange vorhandenen Action-Parameter bei der Link-Generierung einmal zu konsistenterem Leben erweckt (und nicht nur in der simplen Editing-Komponente verwendet) und mit zwei Annotations lassen sich nun in den LinkScheme Instanzen Methoden als Actionen markieren, die direkt über URLs angesprochen werden. Parameter-Übergabe und Resultatseiten Ansteuerung inklusive. Kommentare nach Lektüren der aktuellen Codes bitte gerne an mich.
Leider war eine Entscheidung nicht gerade förderlich (evtl. hatte ich sie deshalb beim letzte Lesen auf gradle.org auch nicht getroffen): Das update auf gradles 1.0 Milestone 7 bremst hier gerade extrem. Gut war es nur, als ich offline im Zug saß :-) Da war diese Version schneller. Ansonsten quält mich diese Version mit ewiglangen Suchaktionen nach den Dependencies. Zum glück kommt gerade Milestone 8 um die Ecke: Downloaden benutzen! Damit fühlt sich gradle wieder so gut an wie vorher :-)

Neues auf der App Engine

Nachdem die letzten Monate vom Spielen mit Gradle, dem direkten Arbeiten mit einem eigenen RDBMS und dem CoreMedia CMS Adapter für tangram geprägt waren, habe ich mir nun mal wieder angesehen, was die App Engine so an Weiterentwicklungen gebracht hat.

1. Ich vermisse immernoch das Tool zum Datastore dump und restore in der Java Version. Als lästige Konsequenz muß ich als "Nicht-Python-Entwickler" (aka Java-Entwickler, aber ich bin eigentlich nicht so festgelegt) auf noch die Python-Version installieren.
2. Ich habe in den Release-Notes noch nichts entdeckt, das mir ein Update auf aktuellen Java-Versionen erlaubt.
3. Es gibt anscheinend nun Google Cloud SQL - und das auch mit Google App Engine angenehme integriert. Leider konnte ich anhand der Texte noch nicht erkennen, wie das ganze mit JDO (oder JPA) zusammenspielen könnte. Die Beispiele von Webanwendungen nutzen direkt JDBC - und das in einer grusligen weise direkt in Servlets/JSP. Das ist also eher ein kleiner Scherz, der die Syntax für JDBC aufzeigt, aber nicht, was man auch nur ansatzweise in einem Hobby-Programm nutzen möchte.
4. Es gibt keine konsistente Liste von OpenID Providern, wo man mal nachschlagen könnte, ob die Liste sich erweitert hat. Das ist recht schade, denn dieser Weg ist für mich immernoch der bevorzugte.
5. Das neue Eclipse Plugin, das mich in seiner alten Fassung für den schneller Start doch sehr begeisterte und die Arbeit enorm beschleunigte, ist nun, nach dem Bau eines "richtigen" Build-Systems, mit dem es nicht integrierbar ist (mit Maven oder ANT wäre die Lage nicht besser), so eine Plugin eher im Bereich Spielzeug zu finden als eine Entwicklunshilfe. Professionell könnte ich es jedenfalls überhaupt nicht einsetzen.

Warum in dieser Zeit die Google App Engine den Preview Status verlassen hat, ist mir also bei dem dünnen Weiterentwicklungsstand schleierhaft. Das Thema Persistenz wird auch mit dem neuen Blob Store eher komplizierter als für die Anwendungsentwicklung besser.

Security Update "Low Priority" bei Datanucleus?

Nachdem die Software ja nun ein paar Monate auf github verfügbar ist, fallen in freier Wildbahn natürlich Kleinigkeiten auf, die im 0.7-Zweig bereinigt sind. Alle? Nicht ganz alle: Eine Kleinigkeit liegt ein wenig Außerhalb meines Einflußbereiches...
Der Bytecode "Enhancer" der datanucleus Implementierung von JDO funktioniert in der Fassung, wie ich sie für die Google App Engine und auch die RDBMS Variante als "Compiler Processor" benutze, nicht mit den aktuellen Versionen von Java, die seit Juni Verfügbar gemacht wurden. 1.6.0_26 ist die letzte Version, die noch läuft.
Mein Problem mit der Software fühlt sich so ähnlich an wie http://www.datanucleus.org/servlet/forum/viewthread_thread,6958 und die Antwort dort macht mir Sorge, denn es ist wohl nun auch der Java 6 Strang betroffen - und Security Updates wollen meine "Commercial Clients" alle gerne haben :-). Also für's Bauen bitte die o.g. Version benutzen oder den Enhancer auf aktuelle Software erweitern. Danke.
Auch wenn erfreuliche Zeichen aus der Google App Engine Welt zu hören sind und der Code zwischen RDBMS und GAE vereinheitlicht werden kann, bleibt also mit datanucleus 3.0.4 das Problem bestehen! Version  3.0.5 suche ich nocht zum Download.

Endlich in's CoMA gefallen

Habe eben gerade einmal die neuen Errungenschaften des Wochenendes nach github geschoben - gepuscht auf neudeutsch. Ein kleines Update auf den neuesten Meilenstein von Gradle habe ich auch gleich noch eingezogen, weil Gradle langsam immer schneller wird und ich damit keinen nennenswerten Migrationsaufwand hatte. - Sehr zu empfehlen!
Letzte Woche hatten einmal wieder ein paar Leute gefragt, ob man nicht auch direkt auf eine CoreMedia Datenbank zugreifen kann. Kann man - aber wer will das schon.
Also habe ich jetzt endlich meinen CoreMedia Adapter (CoMA) in seiner schlichtesten Ausprägung in tangram integriert.
Nein, ich bin nicht zu doof, es ausgefeilter zu machen, aber ich will weder das Copyright von CoreMedia verletzen noch deren System nachbauen. Ich muß auch erst noch am Textkovertierer für den Richtext arbeiten.
Gemäß der neuen Doktrin seit Oktober ist nun ein Beispiel natürlich anbei. Wobei man für die Sache das Original-Beispiel von CoreMedia benötigt. Da meine Teile ohnehin nur als Ergänzung zu verstehen sind, ist das ja aber wohl keine Einschränkung.