UGamela Blog

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.

Vor ein-zwei Monaten habe ich Entwurfsmuster – in PHP – kennengelernt, obwohl ich davor schon viel früher über sie gestolpert war, hatte ich sie irgendwie nie richtig wahrgenommen oder einfach nicht verstanden.

Wenn Programmieren abstrakt ist, dann sind es Entwurfsmuster erst recht. Die Beschreibungen der Muster sind gar so abstrakt, dass man umbedingt Beispiele für die Anwendung braucht.

Auch wenn man sie leicht übersieht, stehen bereits im PHP Handbuch zwei Entwurfsmuster. Singleton und Fabrik. Ich möchte auf Singleton eingehen, hole aber noch etwas weiter aus.

Ich habe mich, als ich OOP anfing, gewundert wofür die public, protected und private Deklarationen sind und denn Sinn einfach nicht verstanden. In PHP dienen sie größtenteils gar nicht dem Programmierer selbst, sondern anderen Programmierern, die am selben Projekt schreiben. Sie schließen einfach die falsche Verwendung aus und kapseln Funktionen und Eigenschaften durch die Zugriffkontrolle. Für die Codefunktionalität sind sie somit unwichtig. Man könnte auch einfach alles public deklarieren, wenn man es trotzdem richtig verwendet (PHP4 ist noch alles public).

Singleton geht auf diesem Weg weiter, er erlaubt nur eine Instanz eines bestimmten Objektes, auf welche gleichzeitig global zugegriffen werden kann.

Das benötigt man zum Beispiel bei der Datenbank, die meist nur eine einzige Verbindung umfasst.

http://docs.php.net/manual/de/language.oop5.patterns.php

Es gibt aber noch viele andere komplexere Entwurfsmuster. Ich werde demnächst nochmal das neue Schema für mein Projekt erklären.

Entwurfsmuster zählen definitiv zur Professionellen Programmierung, das Niveau ist deutlich anders, als das simple Programmieren von einfachen Websites.

Ich weiß den genauen Geburstag nicht mehr, aber irgendwann dieser Tage hab ich mit Sascha am frisch gebackenen deutschen UGamela Forum herumgebastelt und die ersten User haben sich registriert. Zu dieser Zeit kamen auch die Versionen 0.3 und 0.3a heraus. Beide fürchterlich verbuggt und größtenteils unvollständig. Das ist nun ein Jahr her, seitdem ist viel geschehen!

Anfang Dezember habe ich das Forum neu aufgesetzt, weil ich dachte, dass wir kein PHPBBplus mit User-Sternzeichen brauchen^^. [Phlegmas Registrierungsdatum: 7.12.2007]

Danach kam noch die Version 0.4(a) raus, die Chlorel Anfang 2008 für sein XNova verwendet hat. Ich habe noch vor Jahrende den Downloadbereich gesperrt, weil 0.4a schon damals schlecht war und es nur so Bugmeldungen hagelte.

In der nachfolgenden Zeit habe ich das Release der Version 0.5 immer weiter verschoben und sehr viel dazu gelernt.

Anfang des Sommers gab es mal intern eine Version 0.4++, die irgendwie geleakt ist. Später habe ich dann “meine” 0.5 an Sascha übergeben, der sie immernoch vertreibt, wenn auch mit wenig Andrang.

Zur Feier des Jahres habe ich eine Reihe von Themen für den Blog vorbereitet, die meine jüngsten Erkenntnisse dokumentieren und die Blogleser teilhaben lassen. Erwartet nicht zuviel, aber freuen dürft ihr euch drauf! ;D

Wieviele XNova Spiele geistern da draußen im Netz herum? Keiner außer Google weiß das genau, aber die haben ja ganz andere Probleme. Jedenfalls sind es jede Menge, täglich kommen neue dazu, täglich brechen welche zusammen.

Ich möchte das nun einmal analysieren. Dazu versuche ich mich in die Lage eines der “Kiddies” zu versetzen, die den Großteil der vermeintlichen Spieladmins darstellen.
Danach werde ich versuchen dem Problem auf den Grund zu gehen! Weiterlesen “Ein Haufen UGamelas / XNovas”

MySQL Events gibt es schon seit MySQL 5.1, aber ich habe sie erst diese Woche entdeckt.

Meiner Meinung nach eine geniale Erfindung, weil sie mit ein wenig MySQL Kenntnissen Cronjobs ersetzen kann. Die anstehenden Änderungen müssen zwar vollständig innerhalb des MySQL und damit in der Datenbank ablaufen, sind dafür aber deutlich flexibler und verlässlicher als Cronjobs. Für mich ist die Handhabung sogar einfacher.

Diese Events eignen sich auch um einen Daemon auf MySQL Basis zu schreiben, der sehr datenbanknah arbeitet. Events werden dadurch in Echtzeit ausgeführt, anstatt, wie beim klassischen Eventhandler, bei jedem Aufruf durchgeführt und zurückberechnet. Das macht einiges deutlich einfacher.

Unheimlich.

Mein Forum scheint ausgestorben und doch wird es täglich von treuen Mitgliedern besucht. In Saschas verbleibendem Forum ist auch nicht viel los. Auf meinem Blog ist dies nun etwas Neues seit Wochen.

Gefällt mir natürlich genauso wenig wie euch! Wir haben schon November und ich bin immernoch nicht sonderlich weiter, so kommt es mir jedenfalls vor. Stattdessen denke ich darüber nach die Sprache zu wechseln (PHP+PgSQL/Python+PgSQL/Java+PgSQL), möchte aber nicht schon wieder aufgeben, was ich bereits geschafft habe.

XNova ist so aktiv wie immer, kann aber die Ruhe um UGamela nicht nutzen um einmal etwas wirklich Gescheites zustande zu bringen. Stattdessen gibt es diverse Kleinkriege zwischen Membern oder Großkriege um Copyrights – wie üblich.

Vor lauter XNova, XNova, XNOVA hört man gar nichts mehr von UGamela; kaum einer weiß überhaupt noch, dass XNova auf UGamela basiert.

Damit muss man leben.  Ich bin über meine Ruhe froh ;D