Tangram 0.8 Release - Mehr Dynamik bitte

Es wurde langsam Zeit für ein neues Tag auf dem Tangram Repository. Die Änderungen gegenüber der letzten Version sind doch umfangreich und viele Anwendungen, die Tangram nutzen - und dringend Version 0.8 brauchen, sollten wieder eine Stabile Basis bekommen.
Die aktuelle Fassung auch von den Beispielen gibt es als Code wie immer bei github und die Dependencies bezieht man aus dem amor.

Was gibt's neues?

Version 0.8 beschäftigt sich viel mit Dynamik. Dazu bedurfte es eines Erheblichen Tunings - insbesondere auf der Google App Engine - allgemein für die Nutzung in der Cloud. Aber etwas anderes kommt unter der Überschrift Dynamik ja auch nicht in Frage.
Zu den umfangreicheren Caching Techniken ebenfalls mit Zielgebiet Cloud werde ich hier noch einen separaten Beitrag veröffentlichen.
Mit Version 0.8 ist die Programmierung von Tangram-Anwendungen nun endgültig in die Datenbank gewandert und wird dort mit Apache Velocity und Groovy umgesetzt, wobei einige Schwächen und Fehler bereinigt wurden.
Dabei sind nun neben den bekannten URLs auch Benutzeraktionen auf der Weboberfläche mit (in den sogenannten Shims) Groovy umsetzbar.
Das dynamische Zusammenstellen der Inhalte auf der Site ist nun ausreichend performant, in der API vollständig und ebenfalls mit Groovy handhabbar.
Um das alles benutzbar zu halten wurde der Editor - eigentlich nur ein Stiefkind in Tangram - in wichtigen Details verbessert und in den Abläufen einfacher gestaltet.
Technisch wurde die RDBMS Umsetzung vom Proof of Concept neben der Google App Engine zu der Hauptumsetzung und das System um die Anbindung MongoDB erweitert. Dabei wurde der JDO-Layer von den historischen Altlasten früher Google App Engine Zeiten befreit und auf API-Level 3.0 gehoben.
Natürlich sind alle genutzen Komponenten auf aktuelle Versionen umgestellt und auch das Buildsystem mit Gradle - jetzt in Version 1.8 - konsistent weiterentwickelt.

Neuer Standard-Startpunkt

Wer nun eine neue Web-Idee ausprobieren möchte und kein Geld in die Hand nehmen will, nimmt nicht mehr die Tangram und die Google App Engine und den Google Apps sondern Tangram und Cloudbees - ggf. mit MongoDB als Backend, an dieser Stelle sogar mit integrieten git-SCM und Continous-Integration-Server über Jenkins.
Auch hier gilt: Wenn die Idee fliegt, besteht ein professionelles Angebot für eine kommerzielle Nutzung der Plattform.
Ersatz für die Google Apps, die wir in der Vergangenheit für den Rest des Auftrittes wie Mails, Calender, Dokumentablage etc. genutzt haben, findet man bei zoho.

NATURINSPIRIERT.org mit Tangram

Die Meldung kommt eigentlich etwas spät, aber es gibt einmal wieder eine neue Site, die mit Tangram realisiert wurde. Das kleine Foto-Blog naturinspiriert.org ist mit dem Tangram Framework auf der Google App Engine realisiert worden.
Das ganze ist insofern technisch dennoch nicht "yet another" und "nur klein", da hier zum ersten Mal live die dynamsichen Content-Zusammenstellungen genutzt werden. Die einzelnen Rubriken der Site befüllen sich mit den passenden Artikeln von selbst. Alle anderen Projekte, die diese Feautures von Tangram 0.8 nutzen sind leider noch nicht online oder können hier nicht öffentlich erwähnt werden.
Was bei der Umsetzung aufstieß sind allerdings die Probleme mit der Google App Engine: Man darf sich nicht mehr blenden lassen von veralteten Hinweisen und Links: Ohne kostenpflichtigen Google Apps Zugang bekommt man keine eigene Domain mehr für Google App Engine Anwendungen geschaltet. Punkt. Die erwähnten Links gibt es nicht mehr. Wir haben sie in keinem Szenario aus Google App Engine Anwendungen und Google Accounts nachstellen können.Wir werden also nun weiter an den alternativen Arbeiten.
Wenn's Geld kosten darf, ist Google Apps sicherlich eine gute Lösung und Google Appengine eine sehr attraktive Plattoform. Wenn man allerdings noch nicht weiß, ob eine Lösung Geld verdient, ist es nach erfolgreichen Jahren seit 2013 nur noch zweite Wahl.

My App Engine

Der Schock am Wochenende, was sich bei Google mit dem Gesamtszenario aus Google App Engine und Google Apps, um eigenen Domains der App-Engine Anwendung zuordnen zu können, so verändert, ist ja wieder immer heilsam. Panik ist sicherlich übertrieben und die spontane Sicht etwas pointiert, aber es ist nicht der erste Schritt, bei dem Google Einschnitte im Bereich App Engine und Google Apps vornimmt. Und so war es wieder einmal Zeit, sich die Optionen anzusehen. 

Mit Tangram steht man nicht gerade festgelegt da und kann die Anwendungen normalerweise direkt auf einen Servlet/JSP Container umstellen und sich eine Datenbank suche, die von DataNucleus' JDO Implementierung unterstützt wird.

Das ist natürlich mit einer Umstellung der Codes verbunden. Außerdem hat sich ja gerade die Frage nach der Datenmigration als einer der verschlechterten Punkte in der Google App Engine herausgestellt. Es ist also eine gute Option für Tangram aber eventuell eine schlechte für ein bereits damit bestehenden Projekt.

Beim Stöbern im Netz stößt man als zusätzliche Option mitterweile aber auch auf zwei Projekte, die es sich zum Ziel gesetzt haben, eine zur Google App Engine kompatible Infrastruktur auf anderen Systemen als denen von Google zum Laufen zu bekommen.

AppScale und TyphoonAE wollen sich dabei wie ein "Plug-In-Replacement" anfühlen, sodaß die Anwendungen ohne Änderungen laufen können. Dafür muß man dann eben mit unterschiedlichen Mitteln - entweder entsprechenden Computern oder Cloud-Infrstrukturen - die App Engine Infrastruktur nachstellen - also statt an der Anwendung gewaltig and er Umbgebung arbeiten.

Um es gleich ganz deutlich zu sagen: Für keine der beiden Umgebungen sind alle APIs umgesetzt und keine ist in einem Zustand, daß man über einen produktiven Einsatz wirklich nachdenken sollte. Es ist nur jetzt an der Zeit, sich prototypisch anzusehen, ob man mit dem Weg etwas anfangen kann, und ihn mitzugehen oder nicht.

Die wesentliche Warnung an dieser Stelle ist aber eine, die bleiben wird: Die APIs und Lösungen der Google App Engine müssen bei beiden Lösungen nachprogrammiert werden. Und wenn sich bei Google etwas ändert, das man in der Anwendung nachführen muß (trotz der recht stabilen APIs ist das natürlich schon vorgekommen in den letzten Jahren), muß man bei den beiden Emulationen darauf warten, daß es dort auch entsprechend umgesetzt wird - oder es selbst tun. Es sind ja Open Source Lösungen und man kann die Erweiterungen auch wieder einbringen. Der Zeitliche Versatz bleibt so oder so und es wird immer ein Hinterherprogrammieren bleiben.

Von den beiden Lösungen kommt man mit der "Kleinen" TyphooeAE schneller an ein lauffähiges System aus dem bereitgestellten Code heraus. Hier wird ein Pyhthon-basiertes Build System bereitgestellt und man kann from Scratch bauen.

Die AppScale Lösung ist größer und zielt in jeder Hinsicht auf die größeren Installationen. Zum Ansehen gibt es hier dafür allerdings fertige VMs für Xen und KVM. Dumm nur, daß ich mich gerade wegen der Nutzung unter Windows und Linux für die Oracle Virtual Box entscheiden mußte.

Tür zu zum Talentschuppen

Wer gute Ideen in's Web bringen will, muß erst einmal aussortieren, was gute und was schlechte Idee sind. D.h. man muß leider all die schlechten auch in's Web bringen und dann aussortieren, was funktioniert und was nicht.

Alle, die nur wirtschaftlich garantiert erfolgreiches in's Web bringen, leben von denen, die vorher einmal mit Idee gescheitert sind.

Ganz in diesem Sinne hatte Google für die Google App Engine und die Goople Apps kostenlose Angebote, mit denen man schnell, einfach und ohne Risiko Idee in's Web bringen konnte. - Ja, konnte. Denn zeitgleich mit der FTD hat Google heute die kostenlose Version der Google Apps eingestellt - und damit den Weg verbaut, in der gegenwärtigen Fassung Anwendungen aus der Google App Engine mit einer eigenen Domain zu versehen.

Das bedeutet deutlich mehr, als daß man eben keine kostenlosen Mail- und Office-Anwendungen etc. für seine Domains mehr bekommt! Eigene Domains für die Google App Engine sind - und das auch jetzt noch - nur mit den Google Apps zu realisieren.

Auch der in diesem Blog beschriebene Weg, klein anzufangen, und dann im Erfolgsfall einfach wachsen zu können mit der Google Infrastruktur ist damit verbaut. Man kann keine Websites mehr erstellen, die mit - hoffentliche - innovativen, selbst programmierten Ideen - und damit ohne die fertigen Versatzstücke Blog, Sites etc. von Google - kostenlos starten und wenn es viele Teilnehmer gibt, technische wie wirtschaftlich - dann natürlich auch gerne für Google - anfangen zu fliegen.

Jetzt kann jeder für sich durchrechnen, ob die konsteplflichtigen Angebote von Google in diesem Zusammenhang einen Testbalon für die ein oder andere Sache trotzdem sinnvoll erscheinen lassen.

Hier beginnt nun erst einmal die Suche nach den alternativen, die das kostenlose Szenario - und damit auch für Projekte ohne Gewinnabsicht - wieder bedienen.

Bisher war die Rechnung wie folgt:

- Coole Idee mit Google App Engine umsetzen (kostenlos)
- Domain kaufen (Mindestpreis .de Domain 4,65€ pro Jahr)
- Google Apps für die Domain einrichten (kostenlos)

Ich geh dann mal suchen...

Update:
Mini Google-Apps gehen noch, sind aber sehr klein geworden und evtl. zeitlich nur noch begrenzt verfügbar.