Nun habe ich endlich eine lange überfällige Funktion in dWing eingebaut. Es ist nun möglich seinen Namen zu ändern. Vor allem für die ganzen Google und Yahoo Nutzer ist dies sehr gut, denn diese Dienste unterstützen nicht den Austausch von Nutzerdaten wie Name bei der Anmeldung.

Diesbezüglich habe ich auch probiert von der veralteten OpenID Simple Registration Erweiterung auf Attribute Exchange umzusteigen, nur um festzustellen, das keiner der Provider, nicht einmal MyOpenID diese Erweiterung unterstützen. Oder aber ich habe etwas falsch gemacht, kann natürlich auch sein.

Für OpenID habe ich auch ein sehr interessantes Widget gefunden, das es sicherlich wert ist ausprobiert zu werden.

Als ich also gestern mal wieder an dWing gearbeitet habe ist mir aufgefallen wie unbequem es doch ist damit zu arbeiten, und das es vielleicht viel besser wäre wieder einmal von null anzufangen. Möglicherweise sogar mit einem ganz anderen Technologiestapel als den altbekannten PHP und MySQL.

Ich habe also intensiv in die Richtung serverseitiges Javascript und NoSQL Datenbanken recherchiert. Node.JS und ExpressJS scheinen sehr interessante Lösungen zu sein. Zusammen mit einer Template Sprache wie Embedded JS, die ich in einer abgespeckten Version schon ein paar mal eingesetzt habe bietet dies sicher eine gute Kombination. Mit serverseitigen JS und Templates die am Server und am Client gleich sind kann man sicherlich schneller zu einem konsistenteren Ergebnis kommen.

Node basiert auf der V8 Engine aus Chrome, ich weiß also nicht genau wie viele der erweiterten Funktionen von Spidermonkey wie beispielsweise Array Comprehension oder Generators es unterstützt. Als Mozilla Entwickler würde es mich auch sehr interessieren, wie sich Jägermonkey in so einem Einsatzgebiet schlagen würde. Bisher ist allerdings ExpressJS sehr schnell. Mit keepalive Anfragen ergibt es über 5000 Anfragen die Sekunde für ein Hallo Welt Skript. PHP kommt auf vielleicht 2000. Hinter einem Lighttpd Proxy ohne keepalive kommt es immerhin noch auf etwas über 2000, also in etwa PHP Niveau. Ich denke aber, dass sich mit der Performance mehr ausgeht, denn die JS Engines haben bessere JIT Compiler und deren Performance wird auch ständig weiter verfeinert.

Wenn man eine andere Syntax mag kann man auch CoffeeScript benutzen. Dies ist eine etwas einfachere Syntax, die zu JS compiliert wird und ebenfalls Funktionen wie Array Comprehension unterstützt.

Als Datenbanklösung könnte sich MongoDB anbieten. Eine Dokumenten- und JSON-basierte Datenbanklösung wäre sicherlich sehr interessant auszuprobieren. Allerdings schweben mir einige Dinge vor von denen ich keine Ahnung habe wie diese damit zu lösen wären.

Für die Arbeit mit CSS finde ich Sass sehr interessant, macht die Arbeit in manchen Situationen sicherlich einfacher. Haml ist auch eine interessante Möglichkeit für Templates, allerdings gefällt mir die Syntax nicht ganz so sehr, und meine sehr alten Erfahrungen mit Smarty haben bewiesen, das es doch sehr viel sinnvoller ist eine echte Programmiersprache in den Templates zu haben.

Alles in allem sehr interessante Projekte die ich gerne mal ausprobieren würde, möglicherweise zuerst in TinderboxPushlog bevor ich mich daran wage aus meinem PHP dWing ein JS dWing zu machen.

Habe mein vServer Paket hochgestuft, nun steht mir vier mal so viel Hauptspeicher zur Verfügung. Habe ein dist-upgrade auf die Lucid Beta versucht, ohne Erfolg. vServer neu installiert mit Hardy. Backups über rsync einspielen, Software auf Server installieren.

dWing wollte anfangs nicht. Update auf die aktuelle Entwicklungsversion. Bug behoben, dass bei fehlgeschlagener SQL Verbindung das Passwort im Stack Trace angezeigt wurde.

Die OpenID Bibliothek hat viel Stress verursacht. Im Endeffekt hat das php5-gmp Paket gefehlt. Die Bibliothek sagt allerdings nichts und produziert einfach falsche Ergebnisse. Viel Zeit mit der Lösungssuche verloren, geht nun.

Die Bibliothek selbst hat dringend eine Neuprogrammierung von null auf nötig.

Server bietet nun 160 Zugriffe/Sekunde, 530 für einfache Seiten.

Schon seit einiger Zeit arbeite ich mit PDO und prepared Statements. Wem dies noch kein Begriff ist sollte wissen, dass prepared Statements die Wunderwaffe gegen SQL Injektionen sind und außerdem noch eine kleine Leistungsverbesserung bringen. Es wird also ein Query mit unbenannten oder benannten Platzhaltern versehen und einmal kompiliert, danach wird dieses Statement wiederverwendet und nur noch mit Daten befüllt. Da die Daten nicht als String in das Query hineinkopiert werden ist es gegen Injektionen sicher.

Eines meiner geliebten SQL Konstrukte ist das IN Statement. Ein id IN (1,2) ist gleichbedeutend mit id = 1 OR id = 2 und auch sonst sehr praktisch.

Leider ist IN anfällig auf Injektionen, weil ich z.b. implode(',', array) benutzen muss. Dabei muss ich selbst sicherstellen, dass Array nur Zahlen enthält. Schwieriger wird es, wenn das Array Strings enthalten soll. Dann muss ich mich weiterhin mit Escapes rumschlagen. Möglicherweise wird es dadurch unsicherer gegenüber Injektionen und der Geschwindigkeitsgewinn von prepared Statements geht auch verloren, denn jedes Query muss einzeln ausgewertet werden.

Gibt es denn eine Möglichkeit irgendwie Arrays an prepared Statements zu übergeben, damit diese mit IN genutzt werden können? Ich hätte dabei an folgendes gedacht:

$stmt = Core::$db->prepare('SELECT user_id, nick FROM '.Core::$db->pref.'user WHERE user_id IN (:ids);');
$stmt->bindValue(':ids', array(1, 5), PDO::PARAM_INT);
$stmt->execute();

Leider funktioniert der Code aktuell nicht.

Ich habe neulich die OpenID Anmeldung bei dWing etwas aktualisiert. Nun gibt es zwei Schaltflächen mit denen man sich direkt mit einem Google oder Yahoo Konto anmelden kann. Funktioniert auch super, also kann sich jetzt jeder mit seinem Google Konto anmelden der keine anderweitige OpenID hat.

Was mir allerdings an dem Googleschen OpenID nicht sehr gefällt ist die ID, denn diese ist scheinbar ein Hash-Wert. Eigentlich sollten OpenID Adressen ja merkbar sein. Auch musste ich sehr lange nach der Login URL suchen. Wie sollte dann jemand an seine Google OpenID kommen der sich nicht so gut mit der Technik auskennt als ich. Da hat Yahoo die Arbeit besser gemacht. Dort gibt man einfach yahoo.com als OpenID an und im Hintergrund bekommt man dann seine echte ID eingetragen, allerdings weiß ich grad nicht ob diese denn auch so gut lesbar ist.

Fazit: Funktionieren tut es super, allerdings scheint Google kein Interesse daran zu haben den Benutzern OpenID nahe zu bringen.

Etwas über eine Woche hat es bloß gedauert und schon ist dWing v4 pünktlich zum neuen Jahr einsatzbereit. Mit der neuen Architektur im Kern geht die Entwicklung eh sehr schnell voran.

Eigentlich halte ich ja nichts von den klassischen MVC Frameworks wie Ruby on Rails oder dergleichen. Aber irgendwie ist mir aufgefallen das ich genau das geschaffen habe. Ein MVC ähnliches Framework. Allerdings genau an meine Bedürfnisse angepasst. Das M aus MVC, also das Model habe ich sowieso schon gemocht. Allerdings habe ich eine für mich etwas besser zu bedienende API entworfen als es bei klassischem ActiveRecord der Fall ist. Die Erstellung eines neuen Objektes geht wie im klassischen ActiveRecord mit $object = new Model(); ... $object->save(); Allerdings kann ich auch direkt bestimmte Objekte erhalten mit $object = new Model($Id); Und löschen geht ganz einfach über ->delete(). Dies alles macht meine super CRUD Basisklasse, welche die ganze Drecksarbeit für mich erledigt.

Die Abgrenzung zwischen View und Controller hatte mir bisher nie gefallen aber als ich es selbst implementiert habe ist mir aufgefallen wie außerordentlich bequem dies doch ist. Mein C aus MVC ist mehr oder weniger meine REST Basisklasse bzw das RESTful Interface.

Und dann gibt es natürlich noch meinen RESTDispatcher der sich um das URL zu Controller mapping kümmert.

So viel dazu. Ich hoffe es funktioniert alles wie zuvor, oder sogar noch besser. Also, bewertet fleißig die Einträge und schreibt Kommentare.

Und ein frohes neues Jahr noch allen.