Modul-planner
Die Berufsschule, an der ich unterrichte, plant ihren Unterricht in wöchentlich rotierenden Modulen — ein System, für das es schlicht keine Software gab. Der Semesterplan entstand tagelang von Hand in Excel. Der Modulplanner macht daraus Minuten und ist heute produktiv im Einsatz.
- catalog
- PRJ-25-α
- bayer
- α Horologium
- spectral
- class G
- magnitude
- 3.2
- erstes licht
- 2025
das Uhrwerk - ruhiges Leuchten im Süd-Quadranten der Karte.
RolleSolo-Entwicklung (Konzept, Algorithmus, Full-Stack, Deployment)
StackFastAPI · React · PostgreSQL
StatusGekauft von Campus Berufsbildung · produktiv seit 2025
Ich unterrichte an der Campus Berufsbildung, einer privaten Berufsschule mit einem besonderen Unterrichtssystem: Der Stoff ist in Module gegliedert, die die Klassen in wöchentlichen Blöcken durchlaufen. Für klassische Stundenpläne gibt es etablierte Planungssoftware - für dieses Blocksystem gab es nichts. Der Plan entstand deshalb jedes Semester von Hand in einer über Jahre gewachsenen Excel-Tabelle: rund 600 Platzierungen, im Kopf abgeglichen gegen Lehrkraft-Verfügbarkeiten, Modulreihenfolgen, Raumbelegungen und Ferienfenster. Das kostete mehrere Tage Arbeit pro Semester - und jede nachträgliche Änderung konnte unbemerkt neue Konflikte erzeugen. Mir war früh klar: Genau hier ist eine Lücke, die sich automatisieren lässt.
Der Grundansatz ist recht simpel und davon inspiriert, wie ein Mensch intuitiv planen würde: Bei einem Konflikt versucht man zuerst, einzelne Module zu tauschen, um ihn aufzulösen. Führt das nicht zum Ziel, tauscht man längere Ketten am Stück. Und weil auch das nicht immer ausreicht - der Plan steckt dann in einem lokalen Minimum -, muss man manchmal Änderungen machen, die den Zustand erst einmal verschlechtern, um in eine bessere Ausgangslage zu kommen. Genau das formalisieren Simulated Annealing und zyklische Permutation.
Move-Vorschlag
Strategie wird gewichtet gesamplet; Zielslots werden nur aus der Menge mit potenziellem Score-Beitrag gezogen.
Delta-Evaluation
ΔE wird inkrementell über die sieben Konflikt-Komponenten berechnet - vollständige Re-Scores sind nur bei Chain-Swaps nötig.
Metropolis-Akzeptanz
Verbesserungen werden immer übernommen, Verschlechterungen mit Wahrscheinlichkeit exp(−ΔE/T) - anfangs großzügig, später kaum noch. Die Temperatur sinkt nach jedem Schritt geometrisch.
Polish-Pass
Nach dem Auskühlen wird die Move-History rückwärts durchgegangen und jeder Zug ohne Score-Verbesserung verworfen - der Plan bleibt so nah wie möglich am Ausgangszustand.
Snapshot-isolierte Planungsdomäne
Stammdaten (Module, Klassen, Lehrkräfte, Bildungsgänge) und Planungsdaten sind strikt getrennt. Jedes Semester arbeitet auf einem eigenen Snapshot - aktive Planung kann keine produktiven Stammdaten zerstören, abgeschlossene Semester bleiben reproduzierbar. Der Optimizer läuft im FastAPI-Prozess und streamt Zustandsänderungen über WebSockets ans Frontend; Undo-Management hält Move-Deltas im Speicher und erlaubt Replay bis zum Initialzustand.

Semester-Dashboard
Einstiegspunkt pro Planung: aktives Semester, Konflikt-Zusammenfassung und Sprung ins Grid oder in die Stammdaten.

Planungs-Grid
Das eigentliche Arbeitstool. Zellen sind Platzierungs-Slots, Konflikte werden farblich markiert, manuelle Korrekturen und Optimizer-Runs laufen gemeinsam mit Live-Update.

Bildungsgang-Editor
Semester-Grid mit Voraussetzungs-Kanten. Zirkuläre Abhängigkeiten werden beim Speichern erkannt, nicht erst zur Laufzeit.
- React 19
- TypeScript
- Vite
- Ant Design
- Refine
- Zustand
- dnd-kit
- Python 3.11
- FastAPI
- SQLAlchemy
- Pydantic
- WebSockets
- Simulated Annealing
- PostgreSQL
- Tailscale
- Netlify
- Render
Aus mehreren Tagen Handarbeit pro Semester ist ein Optimierer-Lauf von unter einer Minute geworden - null harte Konflikte, weiche Ziele gewichtet heruntergefahren, der Feinschliff weiterhin bequem von Hand. Campus Berufsbildung hat das System gekauft; seitdem wird dort jede Winter- und Sommerplanung damit gemacht.