Bitte alle Funktionen ausreichend kommentieren. Die phpDoc-Dokumentation wird 2 mal täglich von der Live-Version erstellt und ist unter http://88.198.9.26/phpDoc/ abzurufen.
Groß- und Kleinschreibung
Funktionsnamen immer klein geschrieben
Variablen immer klein schreiben
ID-Variablen immer nach der Form: $held_id, also immer "_id" am Schluss
Datenbank
Tabellennamen immer in der Einzahl (held, ort, talent, ...)
Tabellennamen immer klein geschrieben
Tabellennamen immer mit Präfix:
"ant_": durch die Benutzer nicht veränderbare Tabellen, wie z.B. die Eigenschaften, die Waren, etc. Diese Tabellen können ohne Probleme gelöscht und neu hochgeladen werden. Es gehen keine Userdaten verloren.
"sys_": Tabellen, die durch das System von Zeit zu Zeit zurückgesetzt werden müssen, wie z. B. die Lagerbestände der Händler.
"usr_": durch die Benutzer veränderbare Tabellen, wie z.B. Talentwerte der Helden, deren Ausrüstung, etc. Wenn diese Tabellen verändert werden hat es Auswirkungen auf die Benutzer. Hier liegt dynamisches Leben dahinter.
Sonstiges:
Es ist zu vermeiden, in den Funktionsdateien die $_SESSION zu verwenden
Bitte die Rechtschreibung auch in den Variablen beachten
Antamar Repository Struktur
trunk - Livesystem
Dieses Verzeichnis entspricht genau dem, welches Online ist. Kleinere Bugfixes, Änderungen an den Zufallsbegegnungen u.ä. können direkt am Trunk gemacht werden. Deswegen muss beim Einspielen eines Branches darauf geachtet werden, dass der Trunk mit dem Branch synchronisiert (Branch-Merge) wird.
branches - Entwicklerversionen
Diese werden angelegt, wenn ein größeres Projekt ansteht. Nach Fertigstellung des Branches muss ein Branch-Merge mit dem Trunk durchgeführt werden, um die kurzfristigen Änderungen und andere Branch-Merges im Live-System in den eigenen Branch zu integrieren. Anschließend, wenn die Konflikte beseitigt sind, wird der Trunk gelöscht und der Branch zum Trunk verschoben. (Hierbei bin ich mir nicht sicher, ob das die richtige Methode ist. Vielleicht kann man den Branch-Merge auch gleich in den Trunk hinein machen.)
Ordner:
orden
sonderfertigkeiten
questen
...
tags - Abgeschlossene Versionen
Wenn ein Versionssprung gemacht wird, z.B. von Alpha auf Beta, wird hier der aktuelle Trunk unter dem aktuellen Versionsnamen hineinkopiert.
Ordner:
Alpha1
Alpha2
Alpha3
Beta1
...
docs - Dokumentation
Konfiguration und Testumgebungen
Antamar-Server (Live- und Testsystem)
Konfigurationsdateien liegen im Verzeichnis includes und haben die Form config_[Version].inc.php
[Version] ist variabel, je nachdem wo der Code gerade läuft (Livesystem → «live», Testsystem → «Branchname»)
Die Einbindung erfolgt über einen symbolischen Link, z.B. ln -s config_[Version].inc.php config.inc.php
- dieser Befehl muss im Verzeichnis includes ausgeführt werden wenn neu installiert wird
(also z.B. bei Erstellung eines neuen Branch)
Lokale Testsysteme
Apache/PHP aufsetzen
Checkout des Repository in ein lokales Web-Verzeichnis
Anlegen der Antamar-DB (passende Dumps im Verzeichnis docs) - der Datenbankname muss der Form dsa_[Version] entsprechen
In das Verzeichnis branches/[Version]/includes wechseln
Die Datei config_live.inc.php öffnen, die entsprechenden Parameter für die Testumgebung
(URLs, DB-Zugangsdaten, Konfigurationseinstellungen etc.) ändern und die Datei als config.inc.php abspeichern
Die Datei config.inc.php für Subversion in die Ignore-Liste aufnehmen, damit sie nicht commited werden kann
Über http://localhost/.../branches/[Version]/ steht das Testsystem für den gerade aktuellen Branch zur Verfügung
Für den Fall, dass für den Trunk (=Code der Liveversion) etwas getestet werden soll ergeben sich folgende Änderungen zu oben:
DB-Name: dsa_trunk
Verzeichnis: trunk/includes
URL: http://localhost/.../trunk/
Antamar MANTIS System und Ablauf
Problemeingabe - alle Nutzer
Q: Wie? → A: Im Menü oben Probleme eingeben auswählen, es öffnet sich dann ein Formular.
↳
FEATURE-WÜNSCHE oder PLANUNGEN sind nur von Programmierern des Projektes einzutragen!
Details soweit als möglich auswählen/eingeben
Auswirkung nach Störfaktor im Spiel auswählen/eingeben
Priorität nach eigener Eischätzung setzen, wobei Fehler generell dringender sind als Features
Profil wählen bei Browsereinfluß auf das Problem
Produktversion: hier können nur Versionen ausgewählt werden, die als veröffentlicht gekennzeichnet sind, normalerweise die jüngste, also aktuellste auswählen
Zusammenfassung: möglichst aussagekräftig (erscheint später als Schlagwort in Versionshistorie und sofort in der Roadmap
Beschreibung: möglichst präzise, wenn machbar mit links zu entsprechenden Themen/Berichten/etc im Forum
Zusätzliche Informationen: Links zum Forum oder zu hilfreichen Seiten
...
WICHTIG: Anzeigestatus für bugs ist "öffentlich", ALLES ANDERE MUSS "privat" GESETZT WERDEN (Grund: jeder User darf öffentliches sehen, aber nur private Sachen bleiben allen unterhalb des Entwickler-Zugang verborgen. Wäre doch schade, wenn geplante Sachen zu früh bekannt werden ;-) )
...
NICHT GEMELDET WERDEN brauchen folgende Probleme: Strassenfehler, Schreibfehler in Beschreibungen, Probleme die User selbst verschulden (z.B. ich bin sooo doof, ich habe meinen Orden gelöscht, weil ich dachte das geht nicht...):
Zuordnung - Entwickler und Admins
Q: Wie? → A1: Editor-Stiftbild anklicken. A2: Massenzuweisung an eine Person über Häkchen + Dropdown in Probleme anzeigen-Ansicht
↳
wenn klar ist, wer das Problem bearbeiten soll, kann von Anfang an zugewiesen werden
wenn man weiß, wer es lösen könnte, auch dem zuordnen (zurückweisen kann man ja immer noch ;-))
wer ein Problem haben will, das noch nicht zugewiesen ist, nimmt es sich!
...
ANSONSTEN: A-Team weist zu, nehmen darf aber jeder Entwickler
Überarbeitung bestehender Probleme - Entwickler und Admins
Q: Wie? → A: Editor-Stiftbild anklicken
↳
WICHTIG: immer die "Target Version: XY" setzen (→ Probleme)
WICHTIG: immer die "Behoben in Version: XY" und "Lösung: erledigt" setzen (→ Probleme)
Felder wie Projektion, Aufwand und so sind optional auszufüllen
Probleme anzeigen
zeigt alles an, eingegeben ist, in der Standardansicht sind lediglich geschlossenen Probleme ausgeblendet
Über die einzelnen Filter lassen sich die Probleme wunderbar eingrenzen, leider sind nicht überall "später als" oder "weniger als"-Eingrenzungen vornehmen
es gibt eine Reihe vordefinierter Filter, die ausgewählt werden können und schnell gewünschte Infos anzeigen
...
...
Änderungsprotokoll
zeigt alles an, was als "erledigt" gekennzeichnet wurde und einer Version zugeordnet ist, die als "veröffentlicht" gekennzeichnet ist
...
Roadmap
zeigt alles an, was mit einer "Target Version: XY" gekennzeichnet wurde
zeigt (durchgestrichen) alles an, was als "erledigt" gekennzeichnet wurde und einer Version zugeordnet ist, die als "nicht veröffentlicht" gekennzeichnet ist
...
Probleme
Versionen, die als veröffentlicht gekennzeichnet wurden, zeigen Probleme nicht mehr in der Roadmap an
"Lösung: erledigt" und "Behoben in Version: XY" muss extra gesetzt werden, sonst tauchen die Probleme nicht im Änderungsprotokoll auf
"Target Version: XY" muss extra gesetzt werden, sonst tauchen die Probleme nicht in der Roadmap auf
In der einfachen Probleme anzeigen-Ansicht ist nicht ohne weiteres filterbar, zu welcher "Target Version: XY" ein Problem gehört und deshalb die Dringlichkeit nicht einschätzbar