UGamela Blog

Ich dachte ich notiere einfach mal den letzten Fortschritt und verbundene Pleiten, Pech und Pannen.

Mein Pseudo-Mapper ist quasi fertig, das heißt ein sehr wichtiges Grundgerüst steht. Das hat mich einigen Schweiß gekostet, denn mein lokaler Apache ist derweil kaputt gegangen und hat nicht gerade zu meinem “Ah, jetzt gehts”-Denken beigetragen. Ich war das Wochenende am Debuggen um ein wenig Ordnung in mein Klassengewurschtel zu bekommen. Derweil hat sich nicht selten mein Debugger einfach verabschiedet.

Fatal error: Exception thrown without a stack frame in Unknown on line 0

ist mein Lieblingsfehler, direkt nach dem kompletten Absturz. Das bedeutet soviel wie “Beim Aufräumen und somit in den Destruktoren ist etwas schief gegangen”, aber wo genau, das ist meist das nächste Problem herauszufinden.

Parent: child process exited with status 3221225477 -- Restarting.

War die einzige Fehlermeldung, die mir der Apache gab. Ich habe heute erst verstanden, dass dies nichts mit meinem Destruktorproblem zu tun hatte. Es handelt sich um ein momentanes Problem mit dem MySQL Treiber auf Vista. Ich installiere gerade eine Locale Maschine mit Ubuntu, um solchen Problemen zukünfitig aus dem Weg zu gehen (Apache&PHP laufen grundsätzlich besser auf Linux). Eigentlich will ich schon seit Monaten auf ein Linux umsteigen, hatte aber ein paar Startschwierigkeiten und wollte mein Vista nicht ganz aufgeben.

Soviel für heute. Ich denke ich bin eine gutes Stück weitergekommen, nun folgt die Entwicklung des MVC Modells, vor allem zugehörige JavaScript Algorithmen und mein JS-TemplateParser. Schätzen, wann es fertig wird traue ich mich noch nicht, besonders weil mein Abitur bevorsteht.

Ich traue mich jetzt einfach mal einen Artikel über Performance zu verfassen. Ein paar Leute meinten schon ich würde mir viel zu viel Sorgen über Performance und Optimisation machen, dabei möchte ich es doch nur gleich beim ersten Anlauf richtig machen.

Multi Update: Mehrere Datensätze einer Tabelle haben sich geändert und sollen aktualisiert werden. Anstatt nun jede Menge einzelne Queries zu schreiben gibts es nun zwei Methoden dies möglichst schnell ablaufen zu lassen.

Weiterlesen “MySQL Multi Update”

Ich bin nicht untätig in den Ferien, wobei ich mich allerdings eher der Schule widmen sollte, als meinem Projekt hier…

Die letzten Tage habe ich erste Tests meines Pseudo OR-Mappers (ObjektRelational) gemacht und bin auf ein bzw. mehrere Probleme gestoßen, die ich leider nicht so leicht ausräumen kann.

Ich wollte in einem einfachen Ansatz einer ORM ähnlichen Struktur Objekte um Arrays “mappen” und einen Mechanismus einbauen der ein automatisches Update ermöglicht, das heißt Veränderungen in den Objekten würden ohne weiteren Codeaufwand selbstständig in die Datenbank geschrieben.

Dabei sollte das Array im Objekt versteckt (private) werden, die einzelnen Eigenschaften (protected) sollten auf Werte des Arrays referenzieren. Diese PRIVATE <-> PROTECTED Relation ist nicht möglich – was auch logisch erscheint, wenn man darüber nachdenkt. Ich werde mir was anderes einfallen lassen.

Gleichzeitig informiere ich mich über OR-Mapper im Allgemeinen. Und stelle fest, dass mein Entwurf lange nicht alle Fähigkeiten der ganzen Idee deckt. Aber das möchte ich gar nicht. Ich versuche ein leichtgewichtiges Basisgerüst zu schaffen. Ich hoffe bald zu den JS Templates übergehen zu können, aber vorher wird es ein erstes Release geben. Damit etwaige interessierte Entwickler erste Schritte mit dem Aufbau machen können.

Wieder was gelernt:

Es gibt in PHP zwei Typen von Objektreferenzen, auch wenn es keine Dokumentation dazu gibt (Wer eine findet bitte sagen..!).

Im Handbuch steht nur: Objekte werden immer als Referenz übergeben

Das stimmt natürlich, nur ist es nicht ganz so einfach. Das Problem fällt allerdings erst auf, wenn man Objekte kontrolliert zerstören will.

$obj = NULL; # (1)

Sollte ein Objekt zerstören, wie unset(). Doch was wenn man vorher

$obj2 = $obj;

gemacht hat? Plötzlich zerstört der erste Befehl (1) nichtmehr, er setzt nur die erste Variable auf NULL. Nun das selbe ein bischen verändert:

$obj2 = &$obj; # & für Referenz sollte eigentlich nicht nötig sein

(1) Führt nun dazu, dass beide Variablen NULL sind. Huch?

Diese Referenzen heißen entweder hard/soft oder echt/unecht, wie auch immer.

Bin eigentlich zur Zeit weniger mit dem Template beschäftigt und dachte, dass ich mir bereits sicher sei, wie ich es lösen würde, doch mir kommt nun eine neue Idee:

Ich werde das Parsen der Templates auf den Client verlegen. Neuladen soll die Seite sowieso nicht mehr, Ajax wird eine große Rolle spielen.

Der Client läd zweierlei Dinge wenn er eine Seite anzeigen soll:

• Das Template, HTML Code mit Platzhaltern
• Die Daten als JSON oder XML

Der Browser füllt dann die Daten in das Template. Dabei kann man auch Schleifen für Listen verwenden.

Dabei wird praktischerweise der Server entlastet. Weniger Traffic und schnelleres Seitenladen sind weitere Folgen. Für Widgets, die sowieso oft aktualisiert werden müssen, wird nicht immer wieder das Template neu geladen, sondern immer nur neue Daten eingefüllt.

Dennoch werden einige Dinge nicht einfach zu implementieren. Erstens möchte ich mir nicht alles verbauen, das Spiel, wenn auch minimal ohne JavaScript laufen zu lassen, zumal es immer noch einige Browser gibt, die das nicht können (Handys). Des weiteren muss eine Art zurück/vorwärts-Funktion erstellt werden, da ja das Neuladen der Seite wegfällt.

Ich muss Wege finden, vereinzelte kleine Abfragen schnell durch den Komplex des Spiels zu schicken oder diesen zu umgehen um Zeit und Rechenleistung zu sparen. Dabei dürfen keine Sicherheitslücken entstehen.

Zu Deutsch “Schnittstellen”. Ich habe gemerkt, dass dieser Begriff sofort zu einer Fehlinterpretation führt, jedenfalls wars bei mir so. Ich hab diesen ganzen OOP Kram sowieso mind. zehn Mal lesen müssen, bis ich ihn annähernd gerafft hab. Einige Sachen sind mir immer noch unklar.

Die letzten Tage bin ich aber endlich darauf gekommen, wofür man diese Interfaces in PHP verwenden kann.

Zuerst einmal: Was ist so ein Interface?

Interfaces sind Klassen, die bestimmte Funktionen vorbestimmen. Die Funktionen bilden dann eine Schnittstelle, also eine bestimmte Möglichkeit von anderen Objekten angesprochen zu werden. Im Gegensatz zu anderen Klassen werden Schnittstellen implementiert (“implements”). Dadurch kann eine Klasse mehrere Schnittstellen haben, aber nur von einer einzigen normalen Klasse abstammen.

Man muss also nur die Schnittstelle kennen, um die Klasse verwenden zu können, die sie implementiert. Anders gesagt, man kann die Klasse so verwenden wie man die Schnittstelle als Klasse verwenden würde.

Sehr konkrete Beispiele liefert PHP selbst mit einigen Schnittstellen:

ArrayAcces: Die Objekte einer Klasse lassen sich wie Arrays ansprechen.
Iterator: Die Eigentschaften einer Objekts lassen sich iterieren, also auf eine bestimmte Weise durchlaufen.

Interfaces lassen sich aber auch noch weit abstrakter verwenden:

Ich schreibe ein Interface Datenbankverbindung, das ich aus praktischen Gründen dokumentiere. Ich weise nochmal darauf hin, dass dieses Interfaces keinen Programmcode enthält, es gibt nur Struktur vor.

Danach schreibe ich einen Dekorierer für meine mysqli Klasse und achte derweil auch etwas darauf, wie PDO aufgebaut ist, denn wahrscheinlich wird das eine weitere mögliche Datenbankverbindung (->Interfacename…) mysqli wird etwas zurechtgebogen und erweitert.

Resultat: Ich kann verschiedene Datenbankklassen nach ein paar Anpassungen verwenden. Ich benutze mysqli, weil es anscheinend die schnellste ist, was MySQL angeht. Letztlich verwende ich Typehints auf “Datanbankverbindung” und Autovervollständigung für das Interface, welches ich dokumentiert (phpDoc, Zend Studio) habe.

Ich hoffe, ich habe es etwas anschaulicher erklärt, als es das Handbuch tut. Ich erinnere nocheinmal daran, dass dies keineswegs einfach ist und ich selbst lange gebraucht habe es zu verstehen.

Bevor ich meinen neuen Entwurf erkläre, der übrigens auf Entwurf Nr. 2 basiert – ich habe also nicht wieder alles verworfen -, möchte ich eine Analogie voranstellen:

Anfängliches Programmieren ist wie Gartenhäuschen bauen

Gutes Pogrammieren ist wie schöne, verzierte Gartenhäuschen bauen

Professionelles Programmieren ist wie Hochhäuser bauen

Weiterlesen “Phlame Engine: Entwurf Nr. 3″

Ich bin ja dabei ein Framework zu schreiben… oder zumindest den Teil eines Frameworks.

Framework.. vor ein paar Monaten hab ich noch Gedacht damit ist der Plan oder die Vorgehensweise für ein Projekt gemeint, dem ist aber nicht so. Ein Framework ist eine Bibliothek aus Scripten, auf der man ein Projekt aufbauen kann. Dies beinhaltet vor allem Grundfunktionen und geben bereits eine MVC Struktur vor.

Nun ein paar Frameworks, die ich mir angesehen habe:

Das Zend Framework erschlägt mich fast mit seinem Umfang. Es führt auch sehr viele Sachen, die ich überhaupt nicht brauche. Es ist meiner Meinung nach ein Schwergewicht. Ich habe keine Tests gemacht, aber ich kann mir denken, dass das ganze trotz direkter Einbindung auf dem Server (keine PHP Scripte) nicht so performant wie ein kleines leichtgewichtiges Framework ist. Ich verwende es aus dem selben Grund nicht, wieso ich Smarty nicht verwende – ich brauche diese Schwerfälligkeit nicht, so praktisch sie auch sein kann, sondern brauche etwas Leichtgewichtiges, das gut auf meine Zwecke zugeschnitten ist.

Das PHP Framework symfony gefällt mir schon besser, obwohl die Dokumentation nur auf Englisch ist. Vor allem ist ORM mit Propel möglich. Nach näherem Hinsehen kann Propel zwar einiges, was ich gebrauchen könnte oder selbst gar nicht schöpfen werde/würde, doch eine sehr wichtige Eigenschaft fehlt mir: Row-Level-Locking, ein Schreibschutz auf bestimmte Tabelleneinträge, der auf InnoDB Tabellen in MySQL viel besser ist als das bekannte “LOCK TABLES” auf MyIsam Tabellen. Aus diesem Grund kann ich Propel, mit oder ohne Symfony nicht verwenden.

Ich falle zurück auf die Idee ein eigenes, sehr leichtgewichtiges Framework zu schreiben.

ORM wird größtenteils den Kern meines Frameworks darstellen.

Nur, was ist ORM? [Ich meine hier übrigens nicht Objekt Role Modeling, das auch ORM abgekürzt wird]

Ich muss vorwarnen, das wird jetzt wahrscheinlich für den Großteil der Blogleser unverständlich. Es gehört wohl zu den Tiefen des Programmierens, neben den Entwurfsmuster. Oft wird hier mit Fremdwörtern nur so um sich geschmissen. Ich habe immernoch so meine Probleme, so lange mache ich das ja noch nicht. Ich werde mich trotzdem bemühen es einfach auszudrücken.

Relationale Datenbanken, wie MySQL, legen Daten in Tabellen ab. OOP arbeitet aber mit Objektinstanzen. ORM soll nun das Zwischenstück bilden, das die Objekte in der Datenbank abbildet. Ich möchte mittlerweile nurnoch mit Objekten arbeiten, es vereinfacht das Programmieren ungemein. Ich möchte vor allem Spielelemente wie Flotten als Objekte verwalten, um besser Interaktionen zu überblicken. Doch bevor man sich bei jedem Objekt mit dem Speichern in der Datenbank herumschlagen muss, möchte ich das lieber in verschiedenen (Abstraktions-)Schichten verstecken. Für die “Community-Entwickler”, die hoffentlich nach Fertigstellung des Frameworks tatkräftig mithelfen ein Spiel zustande zu bringen, bedeutet dies, dass ein Haufen Arbeit wegfällt. Dafür müssen sie sich halt mit (relativ einfachen) Klassen herumschlagen, was sie vielleicht von PHP noch nicht gewöhnt sind.

Ganz nebenbei wird dann übrigens gecacht und Race Conditions umschifft, ohne dass man etwas davon mitbekommt. OOP hat den großen Vorteil, dass man anderen Code nicht kennen muss, man muss nur wissen was er tut, und dafür gibt es die Dokumentation.

Die Phlame Engine wird natürlich weiterentwickelt, auch wenn ich dieser Tage besonders wenig Zeit habe, diese Woche schreibe ich zB zwei Arbeiten und zwei Tests in der Schule, da bleibt nicht viel Zeit für Programmieren.

Ich muss das Schema, das ich aufgestellt hatte, revidieren. Das Datahandler verliert eine seiner Rollen, das Erstellen der Models. Diese werden direkt in den Requestern gebildet um ein paar Schleifen zu sparen, und haben dadurch auch eine Bindung zu diesen, die ich nicht Cachen möchte, da die Requester eigentlich eine Erweiterung der Datenbankverwaltung darstellen, welche eine Resource ist (Resourcen kann man nicht serialisieren/cachen).

Ich habe kürzlich ein neues Forum entdeckt, das mir gefällt: http://www.galaxy-news.de

Dort habe ich ein paar ähnlich gesinnte Entwickler gefunden. Hier die erste teils “geklaute” Idee:

Die Models erhalten Module, die entweder selbst Models (zB im Falle einer Flotte Schiffe) oder eben bestimmte Module, mehr dazu gleich.

Ich habe überlegt den Techtree in Models abzubilden, dadurch hätte man optimale Möglichkeiten an den einzelnen Einheiten herumzubasteln. Für Basisfähigkeiten oder oft Genutztes kann man in Module, wie oben beschrieben verpacken. Für die Basisfähigkeiten gibt es zudem noch eine (abstrakte) Basisklasse (zB Ship) die bestimmte Fähigkeiten bereits vorgibt oder vorraussetzt. Der Vorteil an den Modulen wäre allerdings auch noch, dass man sie vllt sogar über ein grafisches Interface im Adminbereich in bestimmte Einheiten einbauen könnte. Diese Module wären tatsächlich auch von außen modular, das heißt man könnte die Dateien einfach auch (de)installieren.

Die Idee ist gerade im Anfangsstadium, kann gut sein, dass ich dies die Tage nochmal umdenke und editiere.