Vendor Lock In - III

Und nun wieder zurück zu dem Thema, welche Wege man sich verbaut und welche man sich offen halten möchte.

Bisher habe ich nur darüber geschrieben, daß ich mich auf Google App Engine wohlfühle und daß es nun belegt und testweise umgesetzt ist, daß es auch mit dedizierter Datenbank, JSP-Contaienr etc. geht.

Aber da war ja immernoch eine Ausbaustufe vorgesehen, die sich nicht darauf verläßt, daß JDO als ORM Layer benutzt wird. Letztlich läßt sich auf das Kernmodul alles aufsetzen, was irgendwelche Java Objekte erzeugt ,und mit diesen kann man dann objektorientiert Templates für die HTML Ausgabe schreiben.

Mein prominentes Beispiel war die (read only) Nutzung einer Datenbank, wie sie vom CoreMedia CMS beschrieben wurde. Exemplarisch habe ich das umgesetzt, nur mit den Richtext-Elementen habe ich noch so meine Probleme. Und für dieses Szenario gibt's nun tatsächlich ganz praktisch Systeme, für die das nützlich wäre. Mal sehen, ob sich endlich jemand "traut" diesen Weg zu gehen.

Die Lösung dient natürlich nicht dazu, ein CoreMedia CMS abzulösen. Die Kernkomponenten Content Management Server, Master Live Server, Workflow Server und Editoren bleiben notwendig. Wenn man aber unter Aufgabe aller Skalierungsoptionen eine datenausspielende Webanwendung mit dem vorhandenen Content umsetzen will, kann Tangram ein zusätzlicher Baustein sein.

Für diese Zusätzlichen Komponenten könnte der Deal dann so aussehen: Keine Lizenzkosten - Keine Performance.

Die Architektur ist einfach, hat keine zusätzlichen Serverkomponenten, benötigt ggf. die Replikation auf Datenbankebene und skaliert damit nicht ansatzweise so weit wie das "Original". Synergien mit Webanwendungen auf Basis der CAE / Unified API gibt es dann auch nicht mehr. Über Integrationen mit Suchmaschinen etc. habe ich mir nicht einmal große Gedanken gemacht. Was bleibt ist einfach, aber essenziell: Man bekommt seinen Content in's Web.

Muß es denn Maven sein?

Im Moment ist mein Code hier für mich total gut zu benutzen, aber es ist eben ein Workspace für genau einen Benutzer, der eine Reihe von Websites (z.B. www.themen-geburtstag.de und www.dragon-map.de) bastelt.

Dabei fehlt natürlich auch mir ein gutes Dependency-Management für die eingesetzte Libraries (ja ich habe síe total unzivilisiert einfach in meine jeweiligen lib/-Verzeichnisse gelegt). Im Moment pushen die einzelnen Module ihre Ergebnisse in die jeweils nächsten Schichten.

Klingt gruselig? Ist aber einfach sehr schnell und effizient zu benutzen, und das will ich auf keinen Fall verlieren!

Gewohnheitsmäßig benutzen zur Zeit viele Projekte Maven. Dabei mußten wir alle lernen, daß man nicht Maven an seine Bedürfnissen anpassen kann, sondern sich an Mavens Bedürfnisse anpassen muß. Emotionaler ausgedrückt meinte ein Kollege, daß Maven ihn nicht möge. Aber wir stellten fest, daß es noch viel schlimmer war: Maven ignoriert ihn!

Wenn ich Maven einsetze verliere ich die schöne, einfache Deploybarkeit meiner Projekte nach Google App Engine aus der IDE heraus (denke ich) und ich verliere die enorm kurzen Round-Trips beim Entwickeln, die es ermöglichen das Framework weiterzuentwickeln und die notwendigen Änderungen an den benutzenden Appliaktionen sofort zu sehen. - Sofort, nicht 4min später! Dafür bekomme ich ein sauberes Dependecy-Management und ein etwas unverständliches Build- und Packaging System. Das klingt also genauso gruselig wie der Status quo.

Also habe ich mal nach Möglichkeiten gegooglet. Dabei entdeckt man natürlich sofort JAppStart als Startpunkt für die Entwicklung einer Java-Anwendung für die App Engine. Leider bin ich über den Punkt schon seit Monaten hinaus. - Danke Jungs - zu spät. Außerdem habe ich ja einen modularen Ansatz und nicht einfach nur ein Webprojekt. Dann gibt's da die angeblichen Alternativen zu Maven (z.B. http://www.streamhead.com/maven-alternatives/). Davon habe ich mir mal Gradle genauer angesehen, weil die anderen nicht erstrebenswert schienen. Die Beschreibungsdateien für den Build-Prozeß mit Gradle sind einfacher als bei Maven, obwohl ich hier ja bei der Lernkurve bei Null anfange (bei Maven bin ich doch schon kanpp über Null nach ein paar Jahren), andererseits muß ich mir nun doch auf einmal ein komplettes Build-System aufbauen und nicht einfach etwas funktionierendes zusammenstöpseln. Das gefällt mir noch nicht. Verstanden hat der Autor aber anscheinend, daß XML nicht als Sprache zum Schreiben für Menschen gedacht ist. Gradle schreibt sich als DSL zielorientierter als das Maven XML. Das Dependency-Management kann auf Maven Repositories zurückgreifen (die sind ja in jedem Fall genau das was ich brauche) und sogar mein lokales Repository findet Berücksichtigung. Ich traue mich nun nach dem Posting gestern nicht "Maven done right" zu Gradle zu sagen, aber es fühlt sich gut an. Einziger Wehrmutstropfen: Es werden als Default Ivy-Repositories genutzt und angelegt. Ivy ist bei mir nicht positiv besetzt. Liegt das an mir?

Aber mit Gradle wie mit Maven müßte ich nun wieder alles selbst erstellen. Dazu habe ich eigentlich keine Lust. Möchte jemand übernehmen oder Tips geben?

Bekehrung zu GIT

Hat schon jemand von dem Zeug, über das ich hier schreibe, den Source Code gesehen? Nein? Ok, einer hat es, aber der liest hier wohl gerade nicht.
Das hat zwei einfache Gründe: Der Code ist noch nicht in einem Zustand zusammengestellt, den ich herausgeben mag, und ich habe mich noch nicht für das "richtige" Source-Code-Verwaltungssystem und entsprechende, konkrete Repository entscheiden können.
Zum ersten Punkt gibt es entschuldigend nur zu sagen, daß die Module alle brav sauber geschrieben und zugeschnitten sind, aber das Buildsystem einfach nicht existiert. Ich fürchte mich einfach vor dem Verlust an Produktivität den mir Maven bringen würde. Gibt es Alternativen?
Für die Source-Code-Verwaltung dachte ich bisher, daß man im Open Source Bereich nun einfach mal so GIT (http://git-scm.com/) nimmt. Das lag hier so als Entscheidung herum und ich wartete nur auf den Zustand des Codes ihm bereitzustellen. Nun habe ich aber endlich Verstanden, was GIT für mich leisten kann und frage mich, worauf ich die ganze Zeit gewartet habe. Ich bin absolut bekehrt! Der Vortrag von Linus Torvalds bei Google dazu ist zwar erschreckend überheblich und er scheint auch zu wenig Erfahrung mit den anderen Arbeitsweisen im kommerziellen Umfeld zu haben (http://www.youtube.com/watch?v=4XpnKHJAok8), aber wahr bleibt wohl, daß ich mit dem Werkzeug alle Abläufe, die ich in verschiedenen Projekten brauche, damit abdecken kann. Egal, was Ihr mit Source Code macht, legt Euch einfach ein GIT-Repository an! (http://code.google.com/p/tortoisegit/) Man kann nichts falsch machen. Ich jedenfalls werde mich nun bemühen, das Backup des Tangram Workspaces (er enthält leider auch noch das halbe Dutzend Sites, die damit umgesetzt sind) durch ein GIT-Repository zu ersetzen. Das muß ich natürlich wieder sichern, aber das war es schon. Der einzige Kampf, der dann einer Herausgabe noch entgegensteht ist die Frage, ob ich ein "Superproject" in GIT brauche...

Hallo Nachbarn

Nachdem ich mir ja nicht so sicher war, ob man die Lösung mit Google App Engine nun als Schmalspurvariante sehen muß, weil in mener Umgebung - gerade bei den ach so konstebewußten Kunden - noch so viele auf dedizierte Serverchen im eigenen Schrank setzen (was ja an einigen Stellen definitiv eine Berechtigung hat und behalten wird, aber man sollte doch bei ohnehin veröffentlichten Web-Inhalten drüber nachdenken können), fand ich heute bei auf welt.de (http://www.welt.de/fernsehen/specials/eurovision-grand-prix/article13361306/Lena-unheimlich-sexy-und-duester-beim-Grand-Prix.html) ein "Widget". (Sie nennen's Gadget, werde die Lieferung der Hardware verlangen! Ein Gadget ist bei mir immer ein Stück Blech oder Plastik und keine Software... ;-) )

Und siehe da, das Ding läuft auf appspot.com. Wir sind also quasi Nachbarn und die Frage der Lasttauglichkeit ist bei so einem Ereignis dann wohl auch beantwortet. (http://eurovisiongadget.appspot.com/?lang=de) Sie habe sich also nicht einmal die Mühe gemacht, eine eigene Domain dafür zu buchen (jaja, wozu auch in diesem Fall).

Wenn es Probleme damit gibt, liegt's als an meinen eingesetzten Frameworks und der Beschränktheit des Entwicklers. Das kann man ja alles noch ausmerzen, wenn es im Betrieb zuschlagen sollte. Auch in Anbetracht dessen, welchen Aufwand eine Deployment für eine eigene Umgebung bereitet und wieviel man leisten muß, um all die Möglichkeiten des Betriebs, die Google bietet, selbst bereitzustellen, sehe ich Google App Engine weiterhin als den Schwerpunkt an, wenn nicht bald ein Projekt zuschläft, das es anders braucht.

Für alle, die es lieber dediziert haben, gibt's ja schon, wie erwähnt die Möglichkeit mit eigenem Servlet/JSP Container und RDMBS nach Wahl. Außerdem bastele ich weiterhin an einem anderen Adapter...

"Erste" Web Site online

Auch wenn natürlich schon seit Monaten einige Sites mit Tangram laufen und auch schon die Integration über Google Apps und eigene Domainsnamen länger genutzt wird, verkünde ich heute mal offiziell, daß wir eine Site in Betrieb genommen haben (indem wir nur den globalen Login entfernt haben).
http://www.themen-geburtstag.de/
beschäftigt sich mit Konzepten zur Ausgestaltung von Kindergeburtstagen zu verschiedenen Themen - und es werden immer mehr - inklusiver aller Vorbereitungen, eines Leitfadens für den Ablauf. Dazu noch ein allgemeiner Teil. In Zukunft sollen hier noch mehr Themen und Hilfestellungen hinzukommen für alle, die nicht einfach eine Party irgendwo "einkaufen" wollen.

Vendor Lock in II

Leider habe ich hier über die weitere Entstehungsgeschichte von Tangram nicht mehr berichtet. Es ist aber einiges passiert.
Als nächstes wollte ich eigentlich unter dieser Überschrift darüber schreiben, wie ich unter das Tangram Modul statt JDO und Google App Engine eine CoreMedia-Datenbank geschraubt habe und mit als Modul "CoMA" einen CoreMedia CMS Adapter gebaut habe. Das habe ich zwar auch, aber das interessiert im Moment anscheinend niemanden. Wer's haben möchte: Mailen ;-) (GIT Zugange inkl.  aller Vorarbeiten den Code herauszugeben fehlen ohnehin noch, aber ich geb's gerne her)
Was ich jetzt allerdings kurzfristig beweisen wollte, war, daß das JDO-Modul auch mit anderen Spezialisierungen nutzbar ist. Das klappt derzeit auch recht gut. Der Editor, mit dem sich die JDO-Beans generisch bearbeiten lassen, läuft nun brav auch ohne Google App Engine. Der einzige "Nachteil" ist, daß die Version des GAE-Moduls nicht angezeigt werden kann, weil das ja die Spezialisierung ist. Mit dieser neuen Varianten bin ich aber wieder einem Lieferunanten ausgeliefert: Datanucleus. Das ist auch unter Google App Engine drin und die einzige JDO Implementierung, die bei meiner Recherche den wenigen Kriterien nach Lizenz und aktiver Entwicklung standhielt.
Die größte Schwierigkeit wäre nun, das Architektur-Diagramm aus dem letzten Posting wieder anzupassen.
Wer jetzt also nicht in die Cloud wollte, kann nun loslegen. Er muß nur noch das Themen Benutzerverwaltung angehen, weil sonst jeder seine Website editieren kann. ;-) Eine integration mit Springsecurity für die elementaren Notwendigkeiten, wie sie in der App Engine zur Verfügung stehen, scheint schlank zu sein, aber ich hatte dieses Wochenende einfach keine Lust dazu. Ich ziehe die Lösung aber jedem kleinen CMS vor.