In der Sorting Sandbox schreibst du Sortieralgorithmen in Dart, Python, JavaScript oder Java und siehst dann zu, wie dein eigener Code arbeitet. Du lässt Verfahren gegeneinander antreten, misst ihren Aufwand und findest heraus, warum zwei richtige Algorithmen trotzdem sehr unterschiedlich gut sein können.
Deine Klasse hat ein gemeinsames Repository, in dem alle eure Algorithmen liegen. Was du veröffentlichst, erscheint ohne Neustart bei allen anderen und muss sich dort im Rennen und in der Messung bewähren.
Dein Algorithmus ist ganz gewöhnlicher Code: Es gibt keine Befehle zum Zeichnen und keine Hilfsfunktionen, die du aufrufen musst, damit etwas sichtbar wird. Ein vollständiger Insertion Sort in Dart sieht so aus:
import 'package:sorting_sandbox_api/sorting_sandbox_api.dart'; class InsertionSort extends SortingAlgorithm { String get name => 'Insertion Sort'; String get color => Colors.purple; void sort(Elements list, Elements scratch) { for (int i = 1; i < list.length; i++) { final current = list[i]; int j = i; while (j > 0 && list[j - 1] > current) { list[j] = list[j - 1]; j--; } list[j] = current; } } }
Eine Besonderheit: Die Zahlen selbst sieht dein Algorithmus nicht. Elemente lassen sich nur vergleichen, lesen, schreiben und vertauschen. Jeder Algorithmus in der Sandbox sortiert also nur durch Vergleichen. Für Verfahren wie Merge Sort steht eine zweite, gleich lange Liste scratch als Zwischenspeicher bereit.
Du arbeitest mit zwei Git-Repositories. Im Workspace ist ~ dein Ordner /workspace.
| Ordner | Inhalt | Wer ändert es? |
|---|---|---|
~/sorting-sandbox/ |
die App | nur deine Lehrkraft |
~/sorting-sandbox/algorithms/ |
das Klassen-Repository mit euren Algorithmen | ihr, jede und jeder im eigenen Ordner |
Die Karten auf dieser Seite schauen in deinem Workspace nach und sagen dir, was sie finden. Sie ändern nichts.
Mit einem SSH-Schlüssel meldet sich dein Workspace beim GitLab-Server an, ohne dass du jedes Mal ein Passwort eingibst. Melde dich zuerst auf git.nhcham.org an. Prüfe dann im Terminal, ob du schon einen Schlüssel hast:
ls ~/.ssh/id_ed25519.pub
Erscheint No such file or directory, erzeugst du einen neuen. Bestätige den vorgeschlagenen Speicherort mit Enter; die Passphrase darfst du im Workspace leer lassen und noch zweimal Enter drücken:
ssh-keygen -t ed25519 -C "Vorname Nachname"
Zeige nun den öffentlichen Schlüssel an und kopiere die ganze Zeile, die mit ssh-ed25519 beginnt:
cat ~/.ssh/id_ed25519.pub
In GitLab gehst du oben rechts auf dein Profilbild und dann auf Edit profile → Access → SSH keys → Add new key. Füge die Zeile bei Key ein, gib als Titel zum Beispiel Workspace an und speichere.
Die Datei ~/.ssh/id_ed25519 ohne .pub ist dein privater Schlüssel. Den kopierst du nie und lädst ihn nirgendwo hoch.
Teste die Verbindung. Beim ersten Mal fragt SSH nach, ob du dem Server vertraust; antworte mit yes. Danach begrüßt dich GitLab mit deinem Benutzernamen:
ssh -T git@git.nhcham.org
Meldet SSH Permission denied (publickey), fehlt der Schlüssel in GitLab, oder du hast eine andere Zeile kopiert als die aus id_ed25519.pub.
Dein öffentlicher SSH-Schlüssel liegt in ~/.ssh/id_ed25519.pub.
~ ist im Workspace /workspace. ls ~/.ssh zeigt, was dort liegt.
Jeder Commit trägt einen Namen und eine E-Mail-Adresse. Trage deinen echten Namen und die E-Mail-Adresse deines GitLab-Kontos ein:
git config --global user.name "Vorname Nachname" git config --global user.email "deine.mail@example.org"
Das ist in jedem Workspace nur einmal nötig. Ohne diese Angaben weigert sich Git zu committen.
Git kennt deinen Namen und die E-Mail-Adresse deines GitLab-Kontos.
Klone die App in dein Home-Verzeichnis:
cd ~
git clone https://github.com/specht/sorting-sandbox.git
Wechsle in ihren Ordner und klone dort das Klassen-Repository:
cd sorting-sandbox
git clone git@git.nhcham.org:specht/sorting-sandbox-algorithms-2026.git algorithms
Das Klassen-Repository muss in der App liegen und genau algorithms heißen. Gibt es algorithms/ schon, klone es nicht noch einmal, sondern hol mit git pull darin den aktuellen Stand.
Die App liegt in ~/sorting-sandbox, das Klassen-Repository darin in algorithms.
algorithms ist ein eigenes Git-Repository und weiß, wohin es pushen kann.
Starte die App in einem Terminal und lass es offen. Für Git öffnest du ein zweites Terminal.
cd ~/sorting-sandbox
./run
Hol im zweiten Terminal zuerst den Stand der Klasse und lege dann im Ordner der App deinen Algorithmus an. Ersetze DEIN_NAME durch deinen Ordnernamen:
cd ~/sorting-sandbox/algorithms git pull cd ~/sorting-sandbox ./new-algorithm DEIN_NAME --lang python
Das legt algorithms/DEIN_NAME/bubble_sort.py mit einem Bubble Sort als Ausgangspunkt an, mit Absicht noch nicht optimiert. Statt python geht auch dart, javascript oder java. Vorhandene Dateien werden nie überschrieben.
Im Reiter Explore steht links dein Quelltext; du kannst ihn direkt im Browser bearbeiten, formatieren und speichern. Rechts läuft der Algorithmus Schritt für Schritt: Die aktuelle Zeile ist markiert, darunter stehen die lokalen Variablen, und Indexvariablen wie i und j erscheinen als Zeiger unter der Liste. Auf Wunsch leuchten gelesene Elemente orange und geschriebene rot auf. Mit der Zeitleiste spulst du jederzeit zurück.

i und j danach? Nach ein paar Runden kommt die eigentliche Frage: Muss die innere Schleife wirklich jedes Mal bis ganz nach hinten laufen? Und muss die äußere Schleife weiterlaufen, wenn in einem Durchgang gar nichts mehr getauscht wurde?
Fehler sind kein Drama, du siehst sie nur deutlich: Ein Übersetzungsfehler erscheint mit Zeilennummer unter dem Editor, ein Laufzeitfehler (etwa ein Index außerhalb der Liste) in der Konsole, und eine Endlosschleife wird nach wenigen Sekunden gestoppt. Ausgaben mit print(...) landen ebenfalls in der Konsole.
Im Reiter Race treten zwei bis vier Algorithmen mit genau derselben Eingabe gegeneinander an. Jede Bahn macht pro Takt gleich viele Schritte; wer zuerst fertig ist, gewinnt. Als Eingabe gibt es zufällige, sortierte, umgekehrt sortierte und fast sortierte Listen sowie Listen mit wenigen verschiedenen Werten.

Das Rennen zeigt Arbeitsschritte, keine Laufzeit auf echter Hardware. Unter jeder Bahn stehen deshalb auch die gezählten Lese-, Schreib- und Vergleichsoperationen. Schritte, Lesen, Schreiben und Vergleichen können zu unterschiedlichen Ranglisten führen. Was heißt dann eigentlich »schneller«?
Analyze lässt alle Algorithmen der Klasse auf Listen mit 32 bis 2048 Elementen laufen, alle mit denselben Eingaben, und zeichnet den Aufwand als Kurve. Gezählt werden Lesen, Schreiben und Vergleichen; ihre Summe heißt in der App Sandbox-Score. Die Kurven lassen sich durch n, n log n oder n² teilen und logarithmisch skalieren. Nebenbei prüft Analyze jeden Algorithmus auf Korrektheit und Stabilität.

Check testet einen Algorithmus auf vielen Eingaben und zeigt bei einem Fehler die Liste, an der er scheitert. Außerdem prüft er die Stabilität: Behalten gleiche Werte ihre ursprüngliche Reihenfolge? Die Sandbox merkt sich im Hintergrund, woher jedes Element kommt; dein Code braucht dafür keine zusätzliche Zeile.
Hier hat jemand einen Selection Sort in Python geschrieben. Er sortiert richtig, ist aber nicht stabil:
from sorting_sandbox import Colors, Elements, SortingAlgorithm class SelectionSort(SortingAlgorithm): name = "Selection Sort" color = Colors.ORANGE def sort(self, elements: Elements, scratch: Elements) -> None: n = len(elements) for i in range(n - 1): smallest = i for j in range(i + 1, n): if elements[j] < elements[smallest]: smallest = j elements.swap(i, smallest)

Mehr zur App steht in ihrer Anleitung.
Deine Klasse und deine Lehrkraft sehen deinen Algorithmus erst, wenn er committet und gepusht ist. Das machst du im Ordner algorithms, nicht im Ordner der App:
cd ~/sorting-sandbox/algorithms git pull git add DEIN_NAME/ git commit -m "Bubble Sort von DEIN_NAME" git push
Nach dem Push bekommen alle anderen deinen Algorithmus mit git pull; er erscheint ohne Neustart in ihrer App. Mehrere Varianten (rekursiv und iterativ, in zwei Sprachen …) legst du einfach als weitere Dateien in deinem Ordner an; ein fehlerhafter Algorithmus stört die anderen nicht.
Im Klassen-Repository arbeiten alle. Mit welchem Befehl nimmst du nur deine eigenen Dateien in den nächsten Commit auf?
Deine Arbeit ist committet und gepusht. Erst dann sieht deine Lehrkraft
sie in »Class progress« und die anderen nach git pull in ihrer App.
Prüfe das am Ende jeder Stunde.
In einem Klassen-Repository veröffentlichen viele. Hat jemand kurz vor dir gepusht, lehnt Git deinen Push mit rejected ab, weil dir dessen Commits fehlen. Hol sie zuerst und push dann noch einmal:
git pull git push
Öffnet git pull einen Editor für eine Commit-Nachricht, speichere sie unverändert und schließe den Editor. Meldet Git einen Konflikt, hat jemand dieselbe Datei geändert wie du. Dann gilt: nichts löschen, nichts überschreiben, nach Hilfe fragen. Solange du nur Dateien in deinem eigenen Ordner änderst, passiert das nicht.
cd ~/sorting-sandbox && git pull cd algorithms && git pull cd .. && ./run
Und am Ende der Stunde: Aufgabe 5 noch einmal prüfen.