In den letzten Monaten und tatsächlich sogar Jahren versuche ich, eine neue Vertretungsplan-App zu erstellen, die wesentlich funktionaler und universeller (d.h. vor allem auf iOS, Android und Web/Desktop nutzbar) sein soll, als die bisherige Vertretungsplan-App für iOS.
Im Wesentlichen hat es drei Anläufe für die Entwicklung der Beta-Version gebraucht, bis klar war, welche Plattform für diese Fullstack-Anwendung am geeignetsten ist.
Verschwendete Zeit?
Im Sommer 2019 ging es los. Der erste Ansatz stand unter dem Motto: „Schuster, bleib bei deinen Leisten.“ Da ich selbst Anfang der 2000er Jahre mit zwei Kollegen und einer eigenen Firma Webseiten auf Basis von PHP und MySQL entwickelt hatte, startete ich meinen ersten Versuch für eine eigene App auf dieser Basis. Ohne Framework, „completely from scratch“. Das Projekt wurde sehr schnell sehr komplex und damit auch unübersichtlich. Nach 6 Monaten Entwicklungszeit wurde das Projekt Anfang 2020 eingestampft.
Den zweiten Versuch startete ich nach ein paar Wochen Pause und eine langen Lese-Phase auf Basis des Laravel Frameworks. Das basiert zwar auch auf PHP und MySQL, bring aber die wesentlichen Komponenten (API Routen, Objekt-Relationaler Mapper, Pub-Sub, Frontend Framework — hier habe ich auf VueJS gesetzt) bereits mit. Man muss das Rad also nicht immer wieder neu erfinden.
Die grundlegende Idee für den zweiten Anlauf war: Erst die API, dann das Frontend. Die API habe ich zunächst vollständig mit OpenAPI v3 dokumentiert und dann nach und nach in einem Laravel Projekt implementiert. Danach folgte das Frontend, zunächst als WebApp. Die Apps für iOS und Android waren noch nicht angefangen. Und hier lag das Problem: Die Entwicklung dauerte schon 5 Monate an und die Apps waren noch lange nicht in Sicht. Außerdem war das Framework aufgrund der vielen verschachtelten DB Abfragen recht träge (z.B.: Der Import von 2-3 Vertretungstagen dauerte mehrere Minuten). Durch die zunehmend akuten Herausforderungen durch die Lockdown- und Homeschooling-Phasen wurde das Projekt Juli 2020 eingestellt.
Nach diesen Fehlversuchen war klar, dass ein komplexes und reaktives System nicht auf Basis eines SQL Backends zu realisieren ist. Begeistert war ich jedoch von der Idee, ein JS basiertes Frontend-Framework zu nutzen, und das in Kombination mit einem Pub-Sub System; das hatte ich in Form von Redis für Datenbank-basierte Events und Queue Management eingesetzt. VueJS wurde dabei aufgrund seines Event-Handlings jedoch auch sehr bald sehr unübersichtlich.
Bei einer schnellen Entwicklung auch hinderlich war das mühsame Durchlaufen der verschiedenen Layer: Um ein neues Feature einzubauen musste man sich „von unten nach oben“ durcharbeiten: Datenbank-Entwurf anpassen, DB-Migration und Seeds für Testdaten anpassen, API Dokumentation aktualisieren und ggf. Testumgebung in Postman anpassen, API Routen und Policies aktualisieren, API Logik implementieren, Frontend Abfragen der eigenen API aktualisieren, Frontend aktualisieren. Konkret: Das Implementieren einer Möglichkeit, zu einer Klasse einen Klassenlehrer einzutragen, dauerte Stunden oder Tage.
Inspiration
Nachdem Anfang Februar diesen Jahres unsere Chat-App (https://rocket.sgscloud.de) auf Basis der quelloffenen Lösung Rocket.Chat erfolgreich gestartet wurde und seitdem sehr stabil und performant läuft, wurde ich auf das von Rocket.Chat genutzte Meteor Fullstack Framework aufmerksam.
Als Backend arbeitet eine Mongo noSQL Datenbank, was die Datenbankebene gut horizontal skalierbar macht. Mit Cordova gibt es die Möglichkeit, Apps für alle Plattformen mit sehr wenig Zusatzaufwand mitzuentwickeln.
Da es mit React Native ein Meta-Framework gibt, das im Wesentlichen auf Basis von JS Code in OS-nativen Code für iOS und Android rendert, lag zunächst die Wahl von React als Frontend-Framework in Kombination mit Material UI nahe.
Nach erfolgreichem Absolvieren des ToDo-Listen Tutorials von Meteor war klar: Das ist das richtige Framework. Nachhaltig beindruckend war und ist für mich dabei die Reaktivität. Die ToDo-Listen App zeigte Einträge aus der Datenbank an, und es konnten neue Einträge hinzugefügt oder alte Einträge gelöscht werden. Nicht weiter spektakulär. Aber: Wenn ich direkt über die DB Konsole Einträge löschte, aktualisierte sich die Client Ansicht ohne weiteres Zutun unmittelbar!
Highspeed Development
Nach Beginn des dritten Projekts im Februar 2021 steht nun, nach nur dreimonatiger Entwicklungszeit, die erste BETA (zunächst im Web und unter iOS) zur Verfügung.
Features:
- Schneller XML Import von Vertretungs- und Kursdaten von MacStupas5
- Individuelle Planansicht für Schüler (Kurswahl) und Lehrer (Kürzelwahl)
- Push-Benachrichtigungen bei Änderungen im eigenen Vertretungs- oder Stundenplan
- Wochenansicht für Lehrer-, Klassen- und Raumpläne, mit Berücksichtigung tagesaktueller Änderungen
- Eintragung fehlender Schüler (durch Admins)
- Klausurpläne
- Pausenaufsichtsplan und automatischer Einsatz von Reserveaufsichten über den VPlan
- Material-Reservierung von z.B. Medien für den eigenen Unterricht
- Für den Planer: Dashboard mit Einsatz- und Ausfallstatistiken und Übersicht zu ungeregelten Vertretungen und fehlenden Räumen
- Planexport für Kurs42 (Untis Schnittstelle)
- Aus aktuellem Anlass: Inzidenzwerte über die API des RKI.
- Ansteuerung von Displays (mit Raspberry Pi), zur Plandarstellung in der Schule (z.B. im Lehrerzimmer) über eine gesicherte Verbindung.
- Lehrer können für ihren Unterricht den Raum wechseln. Alle Schülerinnen und Schüler der Lerngruppe werden automatisch benachrichtigt.
- Übersicht über die eigenen Vertretungen in den letzten Wochen / Monaten.
Die Implementierung neuer Features benötigt nun mittlerweile nur noch wenige Stunden, bis ein erster Entwurf lauffähig ist. Geplant sind noch:
- Untis Import
- iCal Export der eigenen Plandaten