UGamela Blog

Das kommende UGamela wird komplett in JavaScript geschrieben, kein PHP und auch kein Python wie ich überlegt hatte. Ein Argument ist einfach durchschlagend: Da man die kommende Version als RIA (Rich Internet Application) bezeichnen kann, ist die ganze Oberfläche in JavaScript gebaut. Um das MVC-Pattern anwenden zu können, werden auch auf Clientseite alle Models implementiert. Anstatt sich nun doppelte Arbeit zu machen und das Spiel doppelt zu implementieren (in JavaScript auf Clientseite und in einer anderen Sprache auf Serverseite), schreibe ich den Code nur einmal und verwende ihn auf beiden Seiten. Natürlich gibt es auch Code, der nur auf einer Seite verwendet wird: clientseitig Views oder serverseitig OR-Mapping (sofern ich mich nicht doch noch zu CouchDB durchringen kann).

Weiterlesen “Struktur UGamela 0.6″

Ich kam noch nie dazu hier einen Codefetzen vorzustellen (außer des Beitrags zum Dekorierer). Nun nutze ich diese Gelegenheit eine meiner ersten JavaScript Klassen zu besprechen.

Gleichzeitig handelt es sich um das Muster Wertobjekt (ValueObject), welches unveränderlich ist.

Vorweg muss noch gesagt werden, dass alle Attribute als Konvention protected gelten, public wird nicht benötigt und private lässt sich über Closures realisieren. Einfache Attribute tragen zudem den Anfangsbuchstaben ihres Typs (z.B. s für String).

Objekte der Klasse stellen eine Menge eines Rohstoffs dar.

/**
 * Represents an amount of a resource
 * @param {number} amount
 * @param {string} type
 */
function Resource(amount, type) {
    var nAmount = amount;
    var sType = type;

    if (amount < 0) {
        throw new IllegalArgumentException("amount has to be positive");
    }

    /**
     * @method Resource
     * @return {number} amount of the resource
     */
    this.getAmount = function() {
        return nAmount;
    };

    /**
     * @method Resource
     * @return {string} resource type
     */
    this.getType = function() {
        return sType;
    };
}

/**
 * Addition of two resources produces a new resource with the sum amount
 * the new object uses the old one as prototype
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.plus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    var newRes = Object.create(this); // create a new object based on the current one
    // execute the Resource constructor on it
    Resource.call(newRes, this.getAmount() + resource.getAmount(), this.getType());
    return newRes;
};

/**
 * Subtraction of two resources produces a new resource with a smaller amount
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.minus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    if (this.getAmount() < resource.getAmount()) {
        throw new IllegalArgumentException("can't substract a higher amount");
    }
    var newRes = Object.create(this);
    Resource.call(newRes, this.getAmount() - resource.getAmount(), this.getType());
    return newRes;
};

Interessant ist vor allem die Stelle, an der dynamisch neue Objekte der selben Klasse zurückgegeben werden (plus() und minus()), ich möchte Resource noch erweitern können und evtl. für die verschiedenen Rohstoffsorten eigene Klassen ableiten, daher sollten diese Methoden dann nicht nach einer mathematischen Operation auf die Klasse Resource zurückschrumpfen. In PHP kann man “new” einfach einen String übergeben, in Java muss man einen Umweg über eine Factory oder Reflection machen.

In JavaScript bietet es sich an, das momentane Objekt als Prototyp für das neue zu verwenden und dieses durch den Resource Konstruktor zu initialisieren.

Ich weiß noch nicht, ob mir dieses Pattern noch öfter begegnen wird, aber vor allem bei Wertobjekten (ValueObject), die mit Vererbung erweiterbar bleiben sollen ist dies praktisch. Allgemein wenn man ein neues Objekt des selben Typs wie das momentane zurückgeben möchte.

Jetzt kann ich eine Kindklasse ResourceContainer schreiben, die noch Funktionalität für Gewicht und Volumen des Rohstoffs bereitstellt (z.B zum Beladen von Schiffen):

/**
 * stores resources, adds weight and volume to a resource object
 * @inherits Resource
 * @param {Object} amount
 * @param {Object} type
 */
function ResourceContainer(amount, type) {
    Resource.call(this, amount, type); // inherit priviledged Resource methods
}
ResourceContainer.prototype = Object.create(Resource.prototype); // inherit nonpriviledged Resource methods

Resource.DESITY.metal = 7.85;
Resource.WEIGHT.metal = 1000;

/**
 * @return {number} weight of the resoure amount
 */
ResourceContainer.prototype.getWeight = function() {
    return this.getAmount() * Resource.WEIGHT[this.getType()];
};

/**
 * @return {number} volume of the resource amount
 */
ResourceContainer.prototype.getVolume = function() {
    return this.getAmount() * Resource.DENSITY[this.getType()];
};

Ich beginne langsam die Prototypennatur von JavaScript zu verwenden, bin aber immer noch sehr von Klassen von PHP und Java geprägt.

Nun, über ein halbes Jahr habe ich mich jetzt mit Softwareentwicklung und Objektorientierung beschäftigt. Immer im Hinterkopf meine Browsergame Idee gehalten und festen Glauben in PHP in Verbindung mit viel JavaScript im Browser gehalten. In diesem Moment, da ich versuche mir alles schön herzurichten um wirklich loszulegen, springen mir die Schwierigkeiten mit PHP nur so entgegen.

Zuerst suche ich eine geeignetes Test-Framework, am besten BDD getrieben. Für JavaScript wimmelt es nur so von solchen Frameworks: Screw.Unit, jsspec, jspec, inspec etcetc. PHP bietet genau eines: PHPSpec, dessen Projekt vor über einem Jahr eingeschlafen ist. So bleibt nur noch PHPUnit, welches nicht wirklich BDD zulässt.

Okay, also mache ich mich daran meine IDE einzurichten und ein paar Klassen anzulegen. Netbeans stellt sich aber als sehr schwachbrüstig heraus, was Refaktorisieren in PHP angeht. Die Java Aufgaben für die Uni habe ich mit Eclipse gelöst, daher ist das mein nächster Anlaufpunkt. Naja, Eclipse ist auch nicht viel besser, aber moment, da gab es doch Zend Studio für Eclipse, das mich früher schon mehrfach enttäuscht hat, als es nach Version 5.5 mit Eclipse vereint wurde. Mittlerweile ist es allerdings in Version 7.1 und bittet seine Nutzer doch von 5.5 umzusteigen. Gut, denke ich mir, vielleicht ist es wirklich besser geworden.

Fehlanzeige, Zend geht seit Version 6.0 den Bach runter, die neue Version untstützt nichteinmal Drag and Drop von Text im Editor, ohne das kann ich einfach nicht arbeiten. Wieder runtergeschmissen (das dritte Mal, ich glaub nicht, dass ich das so schnell wieder versuche).

Nun steh ich da, mit dickem Hals auf PHP. Je mehr ich darüber nachdenke finde ich nur Nachteile, weil ich an PHP festhalten will, um irgendwann einmal eine Referenz zu haben und das Spiel auf jeden Webspace klatschen zu können. Nun, das muss nicht sein, wieso all diese Schwierigkeiten in Kauf nehmen, nur um dann einen Haufen Kinder am Hals zu haben die mit der Objektorientierung nicht klar kommen.

Wenn ich mich jetzt gegen PHP entscheide stehen mir plötzlich alle Möglichkeiten offen: Python, Java, … Aber ich weiß etwas besseres:

JavaScript serverseitig! Damit muss ich auch nicht mehr Code duplizieren wenn ich reiche Funktionalität im Browser haben will, weil ich die gleichen Scripte, die auf dem Server laufen, auch im Browser laufen lassen kann (gut, mit ein paar Feinheiten), trotzdem ist das viel besser, als den Code in PHP und JS duplizieren zu müssen.

Nun habe ich die Wahl, JavaScript serverseitig ist mittlerweile mit einigen verschiedenen Grundsystem möglich. Aptana Jaxer bietet sich an, da ich die IDE bereits für JavaScript nutze. CouchDB wäre mal ein interessanter Ansatz.

Insgesamt wird das ganze um einiges Noob-feindlicher, was aber sowieso schon zur Debatte stand.

Weitere Infos kommen, sobald ich mich entschieden habe.

Edit: Ich habe den Artikel eine Woche zurückgehalten, um nicht irgendwelche voreiligen Entscheidungen in den Raum zu stellen.

Seitdem wurde ich weiter enttäuscht: Mein Favorit Aptana Jaxer scheint nicht mehr wirklich gepflegt zu werden – in der IDE lässt es sicht nicht mehr installieren, auf der Aptana-Seite ist es verschwunden und auf jaxer.org sind bereits einige Links tot. Schade, das Projekt sah vielversprechend aus.

Alternativen gibt es zum Glück genug, bisher sieht Myna am vielversprechendsten aus. Ich habe die Entscheidung allerdings ein wenig verschoben und schreibe vorerst die Clientseite und verlagere danach Elemente nachträglich auf den Server.

Insgesamt beabsichtige ich einen sehr fließenden Ablauf im Browser zu erreichen. Die Ajaxabfragen werden dann im Hintergrund ausgeführt, nach Möglichkeit unabhängig von der momentanen Aktion des Users, damit es nicht zu Wartezeiten kommt.

Testgetriebene Entwicklung.

Ich habe mich entschieden nach diesem bewährten Schema vorzugehen. Dabei arbeite ich mich gerade in das schreiben solcher Tests ein. Die Schwierigkeit besteht darin, die richtigen Tests zu schreiben. Diese Tests können dann während der Entwicklung immer wieder verwendet werden um den Code zu prüfen. Ich werde dafür Tests mit PHPUnit sowie JSUnit schreiben, denn mittlerweile bin ich mir sicher, dass beide Parts ähnlichgroße Komplexität erreichen werden.

Warum? Weil diese bewährte Strategie mir hilft Fehler früh zu erkennen und spätere Änderungen zu erleichtern. Sobald alle Tests erfolgreich durchlaufen bin ich fertig.

Leider fehlt mir noch die große Vorraussicht alle Tests von vornherein zu schreiben, ich werde Stück für Stück vorgehen müssen. Gleichzeitig überlege ich zuerst ein UML Diagramm anzulegen.

Ich dachte es wird Zeit für einen Statusbericht, ich bin gerade wieder dabei intensiv zu programmieren und zu lernen.

Leider muss ich zugeben, dass ich in den letzten Wochen nicht wirklich vorwärts gekommen war. Fehlende Motviation und Wissen waren wohl die Gründe. Momentan begreife ich die Objekt-Orientierung in JavaScript, die doch relativ schwierig zu entdecken ist, zumindest war sie das für mich. Wohl einfach aufgrund der größtenteils funktionalen Verwendung von JS. JS OOP programmiert sich zudem ganz anders wie PHP OOP, weil JavaScript vorallem auf Prototypen setzt.

Weiterlesen “Statusbericht”

Die Entwicklung des (PHP-)Codes schleicht eher voran, als dass es wirklich vorwärts geht. Dafür formt sich eine Idee, die mehr und mehr auf die browserseitige Scriptsprache JavaScript setzt. Ich habe bereits geschrieben, dass ich Templates mit JavaScript parse, nun sollen ganze Inhalte nur mit JavaScript generiert werden. Views des MVC werden in dieser Sprache geschrieben. Dabei muss man aber extrem auf die Sicherheit aufpassen. Clientseitig darf man nur mit Daten arbeiten, die sowieso öffentlich sind. Ein gewisser Arbeitsaufwand bleibt deshalb immer auf der Serverseite hängen, die bei diesem Projekt mit PHP gebaut ist.

Nun verwende ich zu großen Anteilen die zwei verbreitetsten Websprachen, die beide von vielen Leuten verachtet werden, weil sie vor allem von Amateuren verwendet werden.

Besonders JavaScript scheint eine interessante Vorgeschichte zu haben. Vor einigen Monaten, als ich anfing JS zu lernen, kam ich auf D. Crockford und habe mir seine Videovorträge angesehn. Ich habe JS somit direkt OOP gelernt, wie es sich eigentlich gehört. JS ist sehr objekt-orientiert, Crockford nennt sie “ausdrucksstark”. Die genau Übersetzung ist mir unklar, ist aber auch egal, denke ich.

Ich kann diesen Artikel nur empfehlen, notfalls auch übersetzt, für diejenigen die weniger gut Englisch können. Um Englisch kommt man aber beim Programmieren kaum herum und Crockford schreibt und redet eigentlich ein sehr gut verständliches und deutliches Englisch. Auch seine Videos kann ich nur weiterempfehlen, es lohnt sich!

Ich entwerfe also ein kleines Grundgerüst in JavaScript, das mit dem serverseitigen Teil, den ich in PHP geschrieben habe, zusammenarbeitet. Dabei ist vor allem der ganze AJAX-Kram sehr nervig. Da alles asyncron ist, muss man ständig mit Callbacks arbeiten (Man übergibt die Funktion, die ausgeführt wird, sobald der Request abgeschlossen ist und die Daten zur Verfügung stehen), was ständig zu Verschachtelungen führt, die ich eigentlich umgehen möchte.

Derweil feiere ich mein Abi und mache ein wenig Urlaub mit Freunden. Ich werde also nicht permanent hieran arbeiten, aber hoffentlich dennoch vorwärts kommen.

Nein, ich habe nicht aufgegeben, nur weil ich einen Monat nicht geschrieben habe, auch wenn ich weder Ideen für Blogartikel, noch Zeit fürs Coden hatte. Ich war tief im Abiturstress, erst Donnerstag habe ich meine letzte Prüfung hinter mir gelassen, dass weitere folgen ist unwahrscheinlich. Ich warte nun auf meine Ergebnisse, das kann ein wenig dauern, aber sehr froh bin ich trotzdem. Der ganze Schulstress fällt von mir ab. Ich fahre jetzt (morgen) für zehn Tage nach Spanien – Abifahrt.

Danach geht es richtig los. Ich habe quasi jeden ganzen Tag Zeit mich dem Projekt zu widmen. Auch wenn ich nicht den ganzen Tag vor der Kiste hocken werden, wird sich viel tun. Ich bin gespannt, ob ich es schaffe, dass im Sommer schon etwas steht, aber ankündigen werde ich vorsorglich nichts. UGamela und die Phlame Engine bleiben mein liebstes Hobbyprojekt, so schnell ändert sich da nichts.

Ich beschäftige mich zur Zeit intensiv mit JavaScript, da es mir clientseitig einige Arbeit abnehmen soll.

Beispiel: JavaScript Templateparser

Ich stehe immer noch zu OOP und auch JavaScript untersützt OOP hochgradig, allerdings in einer für PHPler ungewohnten Form: mit Prototypes, ohne Klassen. Überhaupt ist in JavaScript alles ein Objekt oder – noch besser – eine Funktion! Ich habe hier keine Zeit eine JavaScript Einführung zu geben, ich bitte daher um selbständige Fortbildung um diesen Artikel verstehen zu können.

Weiterlesen “JavaScript / AJAX: Callbacks umgehen, Verkettung von Befehlen”

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”