Deutsch: Kreative Geschichten von SuS besprechen lassen

Ich probiere gerade etwas mit Eigenverantwortlichkeit im Unterricht herum. In meiner Unterstufenklasse gestalten wir gerade Geschichten zum Thema: „Erlebnisse im Internet“ – etwas im Fahrwasser unserer Schulungen zur Medienkompetenz.  Da ich jetzt öfter eine Doppelstunde zur Verfügung habe, sind auf einmal ganz andere Methoden möglich, weil ich eine faire Chance habe, mit den Lernprozessen auch zu einem runden Abschluss zu kommen.

Die Geschichten sollten in einer Lesekonferenz besprochen werden. Ich mag immer Kriterien, anhand derer ich bespreche. Deswegen haben wir zunächst eine Mindmap erstellt. „Zufälligerweise“ ist im Methodentraining der Klasse gerade auch dieses Thema dran, warum also das nicht gleich im Deutschunterricht verwursten?

Unsere Mindmap sah so aus:

Dazu muss man sagen, dass die SuS auch schon am Schuljahresanfang ein Bildgeschichte gestaltet haben und während des Zusammentragens natürlich auch ihre Aufzeichnung aus ihren Regelheften verwenden durften – sonst wäre die Map in einer Unterstufenklasse kaum so vollständig. Bei der Kategorisierung und dem Finden der Oberbegriffe habe ich natürlich ein wenig geholfen – ist also teilweise geschummelt mit der Schülerzentrierung.Diese Mindmap bestand in ihrer Ursprungsform „in Kreide“. Lässt sich natürlich auch bei entsprechender Ausstattung der Klassenraumes gleich auf http://www.mind42.com erstellen – dann entfällt das Abschreiben.

Das weitere Vorgehen ist hier beschrieben (den freien Stuhl habe ich in dieser Klasse weggelassen) – die Auswertung des Fishbowls hat mich ziemlich umgehauen – ein paar Eindrücke:

  1. Beobachter hatten den Eindruck, dass die Gruppe im Fishbowl sehr bald ihre Umgebung vergessen hatte
  2. Beobachter sagten deutlich, dass stille Naturen auch in der Kleingruppe still waren und dass man als Gruppe darauf achten muss
  3. Beobachter sagten deutlich, dass immer jemand die Kleingruppe dominiert und dass man darauf achten muss
  4. Beobachter hatten den Eindruck, dass sich der Kommunikationsprozess oft festfährt, sie hätten gerne eingegriffen (Mist – den freien Stuhl hatte ich weggelassen, um das Setup nicht zu komplex werden zu lassen)
  5. Beobachter beschrieben, dass es hinderlich ist, wenn man sich nicht traut, den fremden Text zu kritisieren(!)
  6. Tja – ich musste irgendwie wenig sagen. Eigentlich recht erholsam.

Was werde ich zukünftig bei Lesekonferenzen verändern?

Ich möchte gerne ein Spezialistensystem in der Lesekonferenz einführen. Jeder schaut auf einen anderen Aspekt („folgt einem anderen Ast der Mindmap“). So sinkt der Reflexionsanspruch und jeder kann etwas in den letzten beiden Phasen beisteuern, weil er auf seinem Gebiet eben einmalig in der Gruppe ist. Gleichzeitig müsste der Zeitbedarf mit der Reduzierung der Komplexität eigentlich sinken, sodass mehr Ressourcen auf die letzten beiden Phasen verwandt werden können.

Moodle und Reverse Proxies

Heute wird es sehr technisch – aber wofür sind Ferien denn da… Ich hatte einmal mehrere Moodlesysteme hinter einem Reverse Proxy laufen – das wird den meisten nicht viel sagen, daher eine kurze Erklärung.

Das Problem

Moodle ist extremst resourcenhungrig und kann unter hoher Last einen schlecht konfigurierten Webserver in die Knie zwingen, besonders auf schwachbrüstigen Maschinen (die man privat so finanzieren kann). Da liegt daran, das für Moodle vom Webserver ein sogenannter PHP-Interpreter aufgerufen werden muss, der dann aus zahlreichen Scriptvorgaben eine stinknormale HTML-Seite baut und über den Webserver an den Browser des Benutzers ausliefert. Erschwerend kommt hinzu, dass die Scripten von Moodle zusätzlich viele Datenbankabfragen erzeugen und so durch den erforderlichen Datenbankserver (meist MySQL) Last erzeugen. Ein gut konfigurierter Moodleserver wird also dafür sorgen, dass möglichst wenig Last beim PHP-Interpreter und bei der MySQL-Datenbank ankommt – man sagt: Das Backend (PHP&MySQL) muss „geschützt“ werden.

Reverse Proxy als Lösung

Dafür führt kein Weg an einem Reverse Proxy vorbei. Was macht dieser genau? Der PHP-Interpreter und die Datenbank bauen ja eine stinknormale HTML-Seite zusammen – das kann z.B. die Startseite eines Moodlekurses sein. Immer wenn der gleiche Nutzer die gleiche Seite aufruft, muss diese wieder und wieder gebaut werden. Ein Reverse Proxy speichert diese Seite im HTML-Code zwischen und liefert sie bei zweiten Aufruf direkt an den Browser ohne den Webserver, den PHP-Interpreter oder die MySQL-Datenbank zu bemühen. Ein Reverse Proxy ist sehr schlank und braucht nur wenige Resourcen. Selbst wenn ein Opcode-Cache wie eaccelerator oder xcache die PHP-Seite direkt bedienen kann, sind vorher zwei Instanzen mit viel höherem RAM-Verbrauch beteiligt (bei Apache ein kompletter Thread, bei lighty der Webserverprozess und ein fastCGI-Thread) – das ist in Lastsituationen nach meiner Erfahrung immer suboptimaler als gleich per Proxy auszuliefern. Der Opcode-Cache ist trotzdem eine wichtige zusätzliche Vorkehrung.  Der Reverse Proxy löst gerade bei mehreren Moodleinstanzen auf dem gleichen Server noch einige  weitere Probleme, aber dazu weiter unten mehr.

Weiterlesen