FAQ zur Vorlesung - Neue Version
Diese Seite beantwortet die nicht technischen Fragen, rund um die Vorlesung und das Projekt. Fragen zum Entwickeln in Smalltalk/Squeak werden in der Sqeak FAQ beantwortet.
Wie sind meine Zugangsdaten zu Squeaksource?
Benutzername ist der HPI Benutzername und das Password wurde dir per Mail geschickt. Bitte ändere dein initiales Passwort. Da das Passwort nicht über eine gesicherte Verbindung übertragen wird, empfehlen wir ein Passwort zu nehmen, dass du nicht (auch nicht in ähnlicher Form) bei anderen Diensten nutzt.
Wo finden die Konsultationen statt?
In der Kommunikationszone C.E.
Welchen Umfang sollten die SWA-Projekte haben?
Die Anforderungen, welche durch die Spiele umgesetzt werden sollen, reflektieren auch den Umfang des Projektes. Alle Projekte wurden so gewählt (oder von uns freigegeben), sodass sie einerseits mit 4 Studierende in der vorhandenen Zeit sehr gut realisierbar sind und andererseits auch ausreichend Raum lassen, um eine sehr gute Architektur zu entwickeln.
Eine Zahl entsprechend der Menge an Quelltext lässt sich nur schwer bestimmen, da es von zu vielen Faktoren abhängt (Verwendung von Mustern, Kenntnis der Smalltalk Bibliothek, Benutzte Abstraktionen etc.). Falls es euch hilft: Wir hatten schon sehr gute Projekte, welche nur knapp 1.000 Zeilen geschrieben haben aber auch sehr gute mit mehr als 4.000 Zeilen. Versucht euch am Besten dazwischen einzupendeln und setzt euren Fokus lieber auf Qualität statt Quantität. Uns geht es in dieser Lehrveranstaltung vor allem darum, dass ihr lernt und versteht, was es heißt "schönen" Code zuschreiben.
Wie kann ich meine Codequalität automatisch prüfen lassen?
Dafür git es sogenannte Lint Tools, die euch dabei unterstützen schönen Code zu schreiben. Diese analysieren euren Code und weisen euch auf "unsaubere" Abschnitte hin. Diese können sowohl mögliche Fehlerquellen sein, als auch Codeabschnitte, die nicht Idiomen entsprechen. Das entsprechende Tool in Squeak heißt SWALint. Ihr findet es im Apps Menü.
Die Benutzung erklären wir in einem Screencast.
Es lohnt sich das Tool von Zeit zu Zeit oder am Besten vor jedem Commit laufen zu lassen um den Code ständig sauber zu halten.
Gibt es auch Design Pattern, die sich besonders für Spiele eignen?
Eine übersicht von Design Pattern, die sich für Spiele anbieten findest du hier. Einige dieser Patterns werden in der Squeak Umgebung bereits bereitgestellt bzw können direkt benutzt werden. Beispiele:
WorldState >> #doOnceCycleNowFor: Morph >> #step (#startStepping, #stopStepping, #stepTime) Morph >> #drawOn: (#fullDrawOn:) Morph >> #keyStroke: (#eventHandler:) WorldState class >> #addDeferredUIMessage: MenuIcons class >> #base64ContentsOfFileNamed: (MenuIcons, HelpIcons, …)
Welche Wege gibt es Resourcen, wie z.B. Bilder, zu teilen?
Bilder können zwar im Squeak Image gehalten werden, in dem man die entsprechenden ByteArrays am besten auf Klassenseite abspeichert. Wir empfehlen euch, dass ihr direkt einen Unterordner vom Resources Ordner teilt. Dazu kann man ganz einfach Dropbox/OwnCloud nutzen und einen Symlink in den Unterordner legen. Alternativ könnt ihr auch ein Git Repository einrichten, was dann im Resources Ordner ausgecheckt werden kann. Der Vorteil ist, dass ihr die Fotos schnell austauschen könnt. Außerdem bleibt euer Repository kleiner.
Wie treffe ich Designentscheidungen?
Bei vielen Designentscheidungen gibt es aber kein klares richtig oder falsch. Ihr selbst kennt euer Projekt am besten und könnt selbst am besten entscheiden, wie man ein bestimmtes Feature schön implementiert. Solange ihr euch weitestgehend an Modularitätsregeln und Regeln für objekt-orientiertes Design haltet und der Code schön aussieht, könnt ihr so ziemlich jedes Design rechtfertigen. Dazu zählen zum Beispiel, aber nicht nur:
- DRY (Don’t repeat yourself)
- SRP (Single responsibility principle)
- Open/closed principle
- Law of Demeter
- Composition over inheritance
- Simple Design
- Loose coupling
- Korrekte Verwendung von Smalltalk/Squeak-Klassen und Sprachidiomen
- Code Metriken (z.B. Lines of Code in der Methode, God Class, etc.), um Code Smells zu vermeiden
SWALint und Design Patterns können euch dabei helfen, diese Ziele zu erreichen.
Wann sollte Global State verwendet werden?
Global State/Singletons sollten nur verwendet werden, wenn es unbedingt notwendig ist. Formen von globalem State existieren in jedem System und können einen auch über Prozessgrenzen hinweg beissen. Das ist vergleichbar mit der Situation heute, in dem die Instanz der Spielwelt an einer globalen Stelle gebunden wurde. Jeder andere, der diese Stelle schreibt (nicht nur ein fremdes Stück Code, sondern eben auch eine zweite Instanz des Spiels) kann somit Probleme verursachen.
A
Was ist ein Legacy System?
Der Begriff des "Legacy System" bezeichnet im wesentlichen Softwaresysteme, welche a) bereits existieren und weiter gepflegt (Maintenance) werden sollen/müssen b) ausreichend komplex sind (die wenigstens Programm sind trivial) c) für jemanden einen bestimmten Wert haben (häufig wird hier natürlich der finanzielle Aspekt genannt aber es gibt auch genug andere Gründe (z.B. will jemand Monkey Island wieder auf dem iPad zum Laufen bekommen oder ihr entwickelt den internen Squeak Browser weiter damit die Community ihn wieder nutzen kann)). Der Begriff ist jedoch vorsichtig zu verwenden, da “Legacy” in der Informatik einen negativen Aspekt im Sinne von “Altlast” beinhaltet. Da ihr natürlich bestehende Softwareprojekte nicht unbedingt beleidigen wollt, solltet ihr das im Hinterkopf behalten.
Sollten wir das System Window für die SWA-Spiele benutzen?
Viele wollen sie benutzen, um die gewohnt Standardfunktionalität (minimieren, schliessen, etc.) zur Verfügung zu haben. Dazu nun ein paar Hinweise:
- Morphic Spiele sind normalerweise nicht in Standardfenster eingebettet, da Kinder die Zielgruppe sind. Diese kennen die ganzen Programmierwerkzeuge (welche bekannterweise die Systemwindows nutzen) nicht. Sie sehen normalerweise nach dem Deployment der Spiele auch nicht mehr viel von Squeak und dessen IDE. Das einzige was sie kennen, um die gewünschte Funktionalität zu erreichen, ist normalerweise der Umgang mit den Halos. Von daher ist der Bedarf nach Standardfenstern für eure Spiele nicht so wichtig.
- Dennoch könnt ihr gerne natürlich versuchen eure Spiele in die Standardfenster einzubetten. Dies ist natürlich näher an bekannten Systemen und erlaubt eine leichtere Bedienung von Menschen die wenig Ahnung von dem Prinzip der Halos haben.
- Bei der Einbindung überlegt euch bitte gut, wie ihr das tun wollt.
Schaut euch dazu doch einmal an, wie die Klasse SystemWindow verwendet werden. Vergleicht zum Beispiel einmal die Subklassen von SystemWindow (Browser - "Hierarchy" Button) und die direkten Referenzen auf die Klasse SystemWindow (STRG + SHIFT + N nach Selektion des Klassennamens). Ihr werdet feststellen, dass es wesentlich mehr Referenzen (also benötigt für Instanzierung von Objekten) als Subklassen gibt. Ebenso sind alle Subklassen Spezialisierungen des SystemWindow aber keine eigenständige Programme. Nun versucht einmal zu verstehen, wie die Programme ihre SystemWindows erstellen und sich dann darin einbetten.
- Schaut euch doch einmal PluggableSystemWindow und ToolBuilder an.
Hier wird mit Hilfe des "Builder Design Patterns" ein Mechanismus beschrieben, wie Fenster und Widgets an Hand von Spezifikationen erstellt werden können. Zur Entwicklung von Werkzeugen, ist dies der eigentliche Weg in Squeak.
Was sollte ich bei der Abgabe beachten?
Checkliste zur Abgabe:
- Wir erwarten die Abgabe als sar-Archiv. Bitter erstellt ein sar-Archiv, dass sowohl euren Code, sowie alle benötigten Ressourcen und ggf. Bibliotheken beinhaltet. Wir ihr ein solches sar-File erstellt, erklären wir in der Squeak-FAQ.
- Bitte fügt das Spiel auch in den ObjectExplorer ein, damit es leichter zu starten ist. Wie das geht, erfahrt ihr ebenfalls in unserer Squeak-FAQ.
- Bitte gebt auch eine Dokumentation mit ab, die erklärt, wie wir euer Projekt starten und benutzen.
- Überprüft Kommentare. Eure Klassen sollten kommentiert sein. Dies sollte in ausführlicher Form gesehen. Wichtig ist, was die Klassen machen und wofür sie zuständig sind.
