Erste Ideen für DASgo
„DAS“1 ist die Software zum Agilen Studieren. Sie soll Lehrende helfen, sich auf die Arbeit mit den Gruppen konzentrieren zu können, ohne zu sehr mit Verwaltung der Abgaben beschäftigt zu sein. Studierende soll sie helfen, die Arbeit in den Lerngruppen zu vereinfachen.
„DASgo“ ist die Neuimplementierung dieser Software. Die bisherige, noch funktionierende Version („DASpy“), ist mit Hilfe von Python implementiert worden. Aus Gründen, die ich hier beschrieben habe, muss ich die Software neu implementieren.
Was sind die ersten Entscheidungen?
Die Software wird in Go implementiert.
Ich habe mit dem Zettelstore sehr gute Erfahrungen mit Go gemacht. Sie ist auch für Studierenden recht leicht zu erlernen, besonders wenn diese vorher Python erlernt hatten.
Als Datenbank verwende ich SQLite.
In DASpy habe ich noch PostgreSQL verwendet. Das ist ein sehr stabiles, skalierbares Datenbankmanagementsystem. Ein langes Wort. Bedeutet auch, dass der Administrationsaufwand allein für PostgreSQL nicht unerheblich ist. Zudem läuft so nicht nur eine einzige zu betreibende Software, nämlich DASpy, sondern auch noch PostgreSQL.
SQLite ist das am verbreitetste Datenbanksystem. In so gut wie jedem Mobilgerät, jedem Web-Browser, in eingebetteten Systemen. Es läuft sehr stabil und ist auch für mittlere bis große Lasten geeignet. SQLite ist nur eine Bibliothek, d.h. es wird in die nutzende Software eingebunden. Es läuft nicht nebenläufig / parallel zur nutzenden Software.
Während viele Programme gleichzeitig auf von PostgreSQL verwalteten Datenbank zugreifen können, sollte auf eine SQLite-Datenbank nur ein Programm zugreifen. Das ist hier der Fall. DASgo wird das einzige Programm sein, dass auf die Datenbank zugreift.
DASgo ist wie DASpy eine web-basierte Software.
Dies hat sich in der Vergangenheit bewährt. Allerdings werde ich versuchen, die Software etwas einfacher bedienbar zu machen. In DASpy wird (fast) nur HTML und CSS verwendet. Lediglich für das Eingabefeld von Lösungsvorschlägen war etwas JavaScript notwendig. JavaScript ist eine Sprache, in der ich mich nicht besonders wohl fühle.
DASgo wird natürlich ebenfalls HTML und CSS verwenden. Für die Eingabefehler für Lösungsvorschläge wird immer noch das gleiche / ähnliche JavaScript verwendet. Ansonsten versuche ich, htmx einzusetzen. Damit muss ich weniger JavaScript-Code erstellen, und erhalte trotzdem eine ansprechende Bedienung.
Als Softwarearchitektur nutze ich die hexagonale Architektur.
Mit dieser Architektur habe ich bei der Entwicklungs des Zettelstores und einer weiteren Software (zur Gruppeneinteilung) gute Erfahrungen gemacht. Sie benötigt zwar einigen initialen Zusatzaufwand, bietet aber später eine sehr gute Wartbarkeit.
Als Web-Routing-Software verwende ich zunächst Chi.
Langfristig möchte ich die für Go 1.22 angekündigte Routing-Software verwenden. Allerdings kommt diese Version wahrscheinlich frühestens Februar 2024 heraus. So lange möchte ich nicht warten.
Nach einiger Recherche habe ich mich für Chi entschieden, weil diese Software die geringsten Unterschiede zum Go-Routing aufweist. Der Umstellungsaufwand sollte gering sein, so hoffe ich. Andere Bibliotheken / Frameworks waren entweder unnötig komplex, unnötig mächtig oder zu speziell.
Für die Generierung von HTML nutze ich meine eigene Software SxHTML.
Mit SxHTML habe ich im Zettelstore sehr gute Erfahrungen gemacht2. Es basiert auf einem kleinen LISP-Interpreter namens Sx, der für diesen Zweck sehr leistungsfähig ist.
Da Sx dann sowieso integriert ist, kann ich es auch für andere Zwecke nutzen. Zum Beispiel für Konfigurationsdateien. In einer möglichen Ausbaustufe könnte DASgo sogar auf einen Zettelstore zugreifen, in dem die Aufgabenstellungen und das initiale Lernmaterial abgelegt sind.
Ein erstes Domänenmodell habe ich schon erstellt. Neugierige finden diesen und den restlichen Quelltext unter https://t73f.de/r/das-go. Noch ist nicht zu viel da, aber das wird sich in Zukunft hoffentlich ändern.