Gestern war ich auf der Suche nach einem Film – es sollte natürlich schnell gehen. Google spuckte Videoload als eine der ersten Platfformen aus, die auch eine Kaufoption anboten. Besonders wichtig war für mich dabei dieser Satz:

Sie können diese Flux-Datei auf DVD brennen, welche Sie auf jedem DVD-Player anschauen können.

Eine FluxDVD-Datei ist ein DRM-geschützter Container, mit dem sich erstmal wenig anfangen lässt – immerhin ist er mit dem Windows-Mediaplayer abspielbar, so dass man das Ding etwa über HDMI an einen Fernseher oder Beamer weiterreichen kann. Das funktioniert auch gut. Nebeneffekt dabei ist, dass der Container dabei hilft, die Downloadgröße zu begrenzen – nicht jeder hat schließlich z.B. einen Kabelinternetanschluss. Beim Brennen der DVD jedoch erlebte ich ein Drama mit mehreren Akten, das in der Katastrophe endete.

1. Akt

Ich benutze Windows ja nur in virtuellen Maschinen. Da galt es es vor dem Download zunächst einmal, eine spezielle Software von Videoload zu installieren. Die beschwerte sich dann darüber, dass kein AC3-Codec auf dem System zu Verfügung stünde, holte sich aber diverse Dateien aus dem Internet nach – hätte man nicht da auch gleich den fehlenden AC3-Codierer installieren können? Um die FluxDVD-Datei brennen zu können, musste sie natürlich wieder konvertiert (“dekomprimiert”) werden, was mit den Einstellungen für meine VM etwa 120 Minuten dauerte. Sie vergingen etwa 2,5 Stunden mit Konvertiererei und Installierorgien. Dann stellte ich fest, dass die VM den Brenner des Hostsystems nicht durchgereicht bekam. Ok – das hätte ich vorher mal prüfen können.

2. Akt

Auf meinem Arbeitsrechner habe ich die Windows7-Partition belassen und lediglich verkleinert, konnte also Windows nativ booten. Die Download-, Installier- und Konvertierorgie begann von Neuem, dauerte Dank Core i7-4-Kerner und 8GB RAM aber dann nur 1,5 Stunden, bevor ich auf “Brennen” klicken konnte. Das ging natürlich nicht, da ich dafür auf dem neuen Gerät keine Lizenz hatte – also rasch noch eine nachgekauft – musste ja schnell gehen und ich fand die Idee ja ganz nett. Was soll ich sagen? Der “Brennen”-Button erschien und die Fortschrittsanzeige des Programms sowie die Geräuschkulisse aus dem Brenner klangen hoffnungsfroh. Dumm nur, dass nach “erfolgreichem” Abschluss des Brennvorganges eine DVD ohne Inhalt ausgeworfen wurde. Ach ja – nochmal brennen geht natürlich nicht, da die Lizenz nur die Erstellung eines Datenträgers erlaubt – für das Programm war ja alles erfolgreich verlaufen…

3. Akt

Ich bestelle dem Film bei Amazon für 2 Euro günstiger inklusive Booklet und Bonusdatenträger. Um den Mindestbestellwert zu erreichen, habe ich gleich noch drei Filme mehr geordert.

Fazit

Der Dienst ist in dieser Form für mich unbrauchbar. Wenn ich einen Film online “kaufe”, erwarte ich:

1. dass ich ihn auf einem mir zugesagtem Medium abspielen kann
2. dass er günstiger ist, als die Vollversion mit Originalmedium
3. dass die Software, die mir aufgezwungen wird, funktioniert
4. dass nach Erstellung des Datenträgers die Integrität geprüft wird, bevor die Brennlizenz intern als “erfüllt” getaggt ist
5. dass der Vorgang unkompliziert verläuft

Ich frage mich, welche Erfahrungen reine Anwender mit so einem Dienst machen. Vielleicht liegt es ja auch allein daran, dass ich im normalen Leben nur Linux nutze und mir die “intuitiven” Prozesse unter Windows einfach ungewohnt sind. Vielleicht möchte mich die Filmindustrie auch genau zu Akt 3 hin erziehen. Einfacher dürfte es in jedem Fall sein, sich den Kram illegal als Torrent zu besorgen – oder den Stream eines Verleihvideos abzugreifen. Weniger Zeitaufwand wäre wohl auch erforderlich. Aber das ist weder erlaubt noch in irgendeiner Form fair.

Tatsächlich – im Internet ist mit Filmen so wahrscheinlich nichts zu verdienen. Liebe Filmindustrie: Menschen, die für Inhalte bezahlen wollen, sind doch für euch eigentlich die Guten! Denkt bitte an deren Zeit und technische Fähigkeiten.

Die IServ basiert auf einem normalen Debian-Trägersystem, welches durch ein passwortgeschütztes deb-Repository durch nicht freien Code ergänzt wird, der entsprechend der GPL sauber getrennt vom übrigen Systemcode abgelegt ist. Das macht das System so frei, dass nach wie vor Raum für eigene Basteleien bleibt – z.B. IServ-Module mit Schülern entwickeln. Gleichzeitig ermöglicht die Geschlossenheit des Codes in Verbindung mit einem Remote-Wartungsvertrag die externe Pflege des Systems – obwohl es sich weitgehend selbst durch automatisierte Scripten pflegt…

Abgesehen von unzähligen durchdachten Funktionen – z.B. die ferngesteuerte Rechnerwartung – fasziniert der IServ durch sein Bedienungskonzept, das sich auch unerfahrenen Nutzern intuitiv erschließt. Der IServ deckt etwa 90% der Funktionen (Forum, integriertes und vollwertiges Mailsystem, Dateiaustausch, Gruppenordner etc.) von einer Lernplattform ab, wie sie zurzeit an den meisten Schulen tatsächlich(!) genutzt werden dürften, so dass ich hoffe, unser bestehendes Schulmoodle (V.2.1+) außerhalb von größeren Projekten bald niemandem mehr zumuten zu müssen – am besten gleich Mahara oder so einführen. Nach vier Tagen Betrieb sind 2/3 der Lehrkräfte dort zumindest einmal angemeldet gewesen und bereits 15 Mobilgeräte für den Internetzugriff freigeschaltet. Die bisherigen “Ahs” und “Ohs” sind natürlich auch zu einem guten Teil unserer vorher bestehenden Struktur geschuldet, aber zunehmend auch als “Differenzreaktion” zum Bedienkonzept von Moodle zu sehen.

Die Bedienbarkeit im Hinblick auf die Bedürfnisse von Schulen ist natürlich kein Zufall: Das System ist an einer Schule als Projekt entstanden und ernährt jetzt immerhin einige Mitarbeiter. Der Spaß kostet natürlich etwas – aber weit weniger, als es an Wartungskosten vor Ort einspart. Die Migration von 1500 Nutzern (Schüler und Lehrer) auf IServ dauert zwar noch an, aber schon jetzt stehen wir fast schon besser als vorher da – nach nur vier Tagen Arbeit (…und keiner Stunde Unterrichtsausfall bei mir.).

Ungewohnt ist dabei meine veränderte Rolle: Ich bespreche und plane notwendige Tätigkeiten mit den Mitarbeitern der betreuenden Firma und spanne auch andere Beteiligte mit ein, obwohl ich eigentlich lieber selbst auf der Leiter stünde und den Accesspoint anschrauben… (aber dann hätte ich freigestellt werden müssen).

Ach ja – nochwas ist neu: Datenschutz und Nutzungsordnungen. Beides braucht man sehr dringend als Schule. Meine zuständiges Landesinstitut für Datenschutz hat mir dabei die Entwürfe von Lehrer-Online empfohlen. Durch ein Telefonat mit einem Freund aus alten Tagen, der beim ULD arbeitet, habe ich die Anregung bekommen, zusätzlich eine Verfahrensbeschreibung zur Gewinnung personenbezogener Daten aus dem Schulnetz zu erstellen. Ob man bei der geltenden, verworrenen Rechtslage damit auf der 100%-sicheren Seite ist, darf bezweifelt werden, aber man hat zumindest das “Laienmögliche” getan. Zumindest dürfte es ein Anwalt ein wenig schwerer haben, Verfahren aufgrund von Formfehlern erfolgreich anzufechten.

Jetzt kommt noch viel Kleinkram (zickende WLAN-Verbindungen, Druckereinbindung usw.), aber das Wesentliche ist geschafft und ich kann die ersten Qualifizierungsmaßnahmen jenseits vom Peercoaching zum neuen Schulnetz andenken.

Ich habe nur Nerds und Lehrer in der Timeline – schnüff. Und jetzt: Korrekturen…

Bei uns mangelt es nicht an Kupfer, das im Gebäude verlegt ist – es gibt sogar Glasfaserstrecken zwischen den einzelnen Gebäudeteilen. Es gibt in den Naturwissenschaften und in einzelnen Gebäudeteilen auch WLAN, jedoch längst nicht flächendeckend. In den PC-Räumen werkeln noch P4-2,8Mhz-Kisten mit 512MB RAM vor sich hin. Zur betreuenden Firma kann ich noch nicht viel sagen – so richtig habe ich noch nicht mit ihr zusammengearbeitet. Gut wäre auf lange Sicht sicher ein periodischer Termin zur Sichtung und Besprechung der anfallenden Aufgaben.

Ein wenig möchte ich das Netzwerk planen und seinen Aufbau koordinieren, werde in der Anfangszeit aber etwas selber zaubern müssen. Immer wieder mache ich die Erfahrung, dass sich dabei viel Gehirnschmalz und Arbeit am Anfang ungemein positiv für die langfristige Ausrichtung auswirken. Folgende Grundsätze halte ich für Schulnetzwerke mittlerweile für essentiell:

1. Eine zentrale Authentifizierung ist unbedingt notwendig. Ich nutze für meine Webservices dafür seit Jahren LDAP – kann auch ein AD (Windows) sein. Das ist quasi das Backend für alles weitere – am besten mit zumindest periodischer, nicht-physikalischer Anbindung (CSV, USB-Stick) an das Verwaltungsnetz der Schule. Dann kann man auch das mit der Datensparsamkeit realisieren.
2. PC-Räume sind sowas von eighties. Die Zukunft liegt in der Cloud, die man sich entweder selbst bastelt oder einkauft. Folgerichtig muss ein wesentliches Augenmerk auf WLAN und Uplink liegen, um mittelfristig viele mobile Geräte bedienen zu können.
3. Softwaredeployment ist der Schlüssel für Nachhaltigkeit. Software muss sich zwingend zentral verteilen lassen, am besten per PXE. So hat z.B. eine Firma einen zentralen Punkt, an dem neue Software eingepflegt wird – das spart Wartunsgkosten und öffnet gedankliche Räume für die Weiterentwicklung des Schulnetzwerks. Lösungen dafür gibt es viele, z.B. opsi, fog oder RIS.
4.  Ohne didaktisches Konzept ist jedes Schulnetzwerk wertlos. Die Technik muss die Freirräume schaffen.
5. Ohne Fortbildung des pädagogischen Personal ist jedes Schulnetzwerk wertlos. Die Technik muss die Freiräume schaffen.
6. Das System selbst muss didaktisches Potential und Partizipationsmöglichkeiten schaffen – Warum nicht Schülerinnen und Schüler mit in die Arbeit integrieren? Da gibt es viel zu lernen und zu erfahren. Also OpenSource. Zumindest auf dem Server.
7. Das Netzwerk muss Bandbreite liefern – Gbit ist Mindeststandard – vor allem bei den Switches.

Momentan habe werden unsere Clients mit dem schon nicht mehr erhältlichem Microsoft Shared Computer Toolkit so verrammelt, dass Änderungen an der lokalen Installation auch ohne Zusatzhardware nicht möglich sind. Ein Schulserver regelt Freigaben via Samba und fungiert gleichzeitig als Netzfilter – über den Ansatz lässt sich trefflich streiten, aber er funktioniert. Leider bringt er diverse Nachteile mit sich, die die Punkte 4+5 meiner Liste betreffen.

Eine Software auf allen unseren Clients zu installieren, dauert ungefähr 20 Arbeitsstunden, da nicht nur die Software eingespielt werden will, sondern auch die Rechner immer wieder aus der Domäne fliegen usw.. Das geht so nicht. Deswegen Deployment (Punkt 3) – image- (fog) oder systemdienstbasiert (opsi).  Das ist ein Muss – gerade auch in heterogenen Systemlandschaften mit verschiedenen Windowsversionen. Es gibt schicke Windowslösungen, z.B. RIS. Kostet. Summen.

Perspektivisch muss so oder so ein neuer Server her, der z.B. einem eventuellem Dienstleister die Grundlage für eine Wartungstätigkeit bietet. In Niedersachsen läuft das an vielen Schulen über iserv. Es ist die in meinen Augen zur Zeit ausgereifsteste Schulserverlösung überhaupt (neben paedML aus BW) – kostet aber. Bezeichnenderweise ist die Kiste an einer Schule entstanden, die Punkt 6 meiner Liste sehr ernst genommen hat. Dummerweise kann iserv von Hause aus keine Terminals bedienen – das hätte ich aber soooo gerne. Die Vorstellung, 0815-Hardware auch in öffentlichen Bereichen der Schule zur Verfügung stellen zu können, finde ich nett. Zudem können unsere bestehenden Clients PXE. Fürs Terminal reicht die Hardware dicke.

Wo will ich hin?

1. Kollege XY hat den Wunsch nach einer Software, die idealerweise frei verfügbar ist (sonst muss er die Lizenzen eben auftreiben). Ich oder ein Schüler oder ein Dienstleister modifiziert Remote das Basisimage. Ein Systemdienst weckt nachts die Clients via WOL auf und spielt das Image neu auf. Kollege XY kommt am nächsten Morgen und kann arbeiten.
2. Die Festplatte eines Notebooks an einem SMART-Board versagt. Der Techniker der Hardwarefirma kommt mit einem Ersatz, bootet via PXE und das Image wird ohne Nutzereingriff restauriert auf den letzten Stand.
3. Das Notebook in der Chemie ohne festen Netzzugriff wird durch einen Kollegen verkonfiguriert. Ich sage dem Schulassistenten Bescheid, der es zu sich in die Werkstatt nimmt und per PXE über einen GBit-Uplink zum Deploymentserver das Image restauriert und nach 30 Minuten wieder in die Chemie stellt.
4. Ein Mediaserver im Schulnetz versorgt nach Klärung von Lizenzfragen das Schulnetz per DLNA mit Audiofiles (Fremdsprachen-CDs) und Filmen (z.B. Merlin). Jedes Android-, iOS- oder Sonstwiegerät mit DLNA-Client spielt das im Klassenraum z.B. über WLAN ab. DLNA-Clients sind übrigens oft sehr schicke Apps, mit denen jeder Mausschubser zurechtkommt.

Technisch ist das alles möglich – heute, komplett mit OpenSource. Müsste das für unsere Schule umgesetzt werden, würde ich inkl. Migration bei einer fähigen Firma dafür drei Wochen mit ca. 120 Mannstunden ( 80,- Euro Stundensatz – soll ja eine fähige Firma sein) ansetzen. Dann wäre mit einem Kapitaleinsatz von ca. 20.000 Euro inkl. Hardware aber für einige Zeit Ruhe. Und: Man spart auf mittlere Sicht erheblich bei den Wartungskosten. Außerdem habe ich eigentlich das Unterrichten gelernt und sollte mich darauf konzentrieren. So – und jetzt Fundraising.

Kern ist das LTSP-Projekt. Ein schöner Einstig in das grundsätzliche Prinzip findet sich auf Wikipedia: Man degradiert sämtliche Schülerrechner zu reinen Anzeigegeräten. Festplatten und nicht erforderlichen RAM reißt man heraus, verrammelt das BIOS mit einem Passwort und lässt die Kisten per PXE vom LTSP-Server booten – das muss pro Tag einmal geschehen und dauert kürzer als ein WinXP-Start (Was nicht viel heißen will…).

Damit entfällt sämtliche Turnschuhadministration und auch die empfindlichsten Komponenten von PCs sind eliminiert. Software muss nur noch auf einem Gerät installiert werden und ist dann auf allen Clients verfügbar. Als Anzeigegerät ist ein Pentium I mit 133Mhz und halbwegs brauchbarer Grafikkarte ausreichend. Schön wären natürlich echte ThinClients, am besten in ein LCD-Panel integriert – so dürfte es leise und kühl im PC-Raum werden. Alle Anwendungen laufen auf einem zentralen Server, der natürlich ein Server und kein Spielzeug sein muss (Hexacore, 32GB RAM, RAID10, redundante Netzteile – die 4000-Euro-Klasse halt). Sound kann man bidirektional an die Clients weiterreichen, mit Video klappt es auch, wenn die Anbindung stimmt und man auf HD-Material verzichten mag.

Der Server kann allerdings nur Linux (Ubuntu). Damit kann man surfen, schreiben, Audio bearbeiten u.v.m. – das Wichtigste halt. Die meisten Dienste verlagern sich eh in die Cloud. Es ist nicht schwer, GNOME einen Windows7- oder XP-Look aufzuzwingen – aber das halte ich für eine Art Betrug. Die meisten “Windowsianer” kommen mit meinem Netbook erstaunlich gut klar und den Desktop kann man ja vorstrukturieren mit netten, einfachen Icons. Mit WINE habe ich bisher zusätzlich fast alle Software zum Laufen gebracht, die auf unseren jetzigen WinXP-Clients vor sich hinvegetiert. Hier sind vor allem mit den Herstellern lizenzrechtliche Fragen zu klären, da es WINE recht egal ist, ob eine Word2010-Instanz 25x von verschiedenen Nutzern gestartet wird…

Dateien lassen sich auf USB-Medien speichern, die LTSP von den Clients durchgereicht bekommt, oder man nutzt NFS (ist bei LTSP leider so) mit festem Quota für jeden Nutzeraccount (gefühlt 1GB, dann würde bei uns noch die 2GB-Platte für die ganze Schulgemeinschaft bei Vollauslastung reichen).

Die Nutzerverwaltung mache ich traditionell über LDAP. Dann kann man den Proxy darüber mit Anmeldung laufen lassen. Außerdem lässt sich das Ding so schön per Skript mit einem kastrierten Export der Schülerdatenbank füttern (inkl. Ordnung nach Klassen) – das Skript gibt es schon für die Anbindung unseres Webangebots. Das ist übrigens der härteste Teil der Geschichte. LDAP hat dafür aber auch den Vorteil, dass es mit RADIUS spricht – ein nettes Spielzeug (man kann in LTSP auch die Clientkonfiguration darüber machen). So meldet man sich per WLAN in der Schule mit den gewohnten Netzwerk-Logindaten an, jeder WLAN-Router kriegt sein eigenes Netz, (dann gehen die IPs so schnell nicht aus) man kann festlegen, wer sich wann anmelden darf (abends braucht man kein Netz, oder?) usw.. Dann noch ein AdHoc-Netz, um das ganze Schulgelände zu bestrahlen… (träum…). Aber das wird eh die Zukunft – mehr als der persönliche Desktop auf dem Schulserver.

Einige Dinge gehen partout nicht unter Linux. Dafür würde ich gerne einen WindowsServer2008RC2 hinstellen, der über 25 Accounts verfügt. Bei der Anmeldung am LTSP kann man sich dann entscheiden, ob man Windows möchte oder nicht und sowohl der Server als auch die Softwarelizenzen sind bei 25 Clients noch überschaubar teuer. Ob man nun einen RDesktop oder die die Ausgabe eines XServers an die Clients weiterleitet, ist wohl egal. Vielleicht lässt sich der WindowsServer sogar virtualisieren, wenn man den LTSP-Server noch dicker… .

Das Schöne an diesem Konzept ist seine Modularität: Man kann klein anfangen und sich dann steigern – allein der LTSP-Server mit seiner Hardware, den braucht man schon. Die Clients sind ja schon da. Wenn man völlig bekloppt sein will, verlegt man alle jetzigen Clients in virtuelle Maschinen und nutzt deren Lizenzen weiter.

Was kostet das Ganze? Im Vollausbau schätze ich eine Summe von 10000,- Euro (ohne Clients und wenn man es selbst macht: LTSP ist in Ubuntu sehr gut vorkonfiguriert und recht schnell aufgesetzt). Wenn man 50 Clients erneuern oder durch Notebooks ersetzen möchte, darf jedes nur 200,- Euro kosten, damit es “billiger” wird. Für den Anfang tut es auch nur der LTSP-Server und der VLAN-fähige Switch – dann kommt man wohl mit der Hälfte hin und hat recht aktuelle, leicht wartbare Systeme.

1. Jeden 0815-Webspace mit PHP, MySQL und mod_rewrite-Unterstützung – das bietet heute fast jedes Einsteiger-Paket.
2. Eine möglichst kurze Domain. Es gibt noch zahlreiche Dreibuchstaben-DE-Domains. Eine DE-Domain buche ich z.B. über meinen gemieteten Robot in Echtzeit für 3,90 Euro/Jahr.
3. Ein fertiges Script, z.B. Yourls.

lighttpd-User wie ich haben es nur unwesentlich schwerer, da die Rewrite-Engine etwas anders funktioniert. Für den entsprechenden vhost trägt man hier ein:

$HTTP["host"] == "domain.tld" {
        server.document-root = "/pfad/zu/yourls"
        url.rewrite-once = (
        "^/([0-9A-Za-z]+)?$" => "/yourls-go.php?id=$1",
        "^/([0-9A-Za-z]+)?\+$" => "/yourls-infos.php?id=$1" )
}

… und schon hat man nach ein wenig Doku den eigenen Kurz-URL-Dienst (leider klappt der Aufruf der Hauptdomain so noch nicht). Meiner hört auf

http://www.m9r.de

und ist genau wie Markus’ Installation nicht öffentlich zugänglich, um Ärger mit bestimmten Zeitgenossen zu vermeiden. Dass das klappt, lässt sich ganz gut mit meinem momentanen Lieblingsnachdenkartikel über Facebook zeigen: http://m9r.de/3 (mit Dank an Andreas Kalt).

Man handelt sich in der Grundversion wieder einige Datenschutzherausforderungen ein, die sich aber lösen lassen. Nebenbei weiß ich jetzt, wie oft meine Kurz-URLs auf Twitter tatsächlich geklickt wurden und es entsteht quasi nebenbei eine hübsche Linksammlung in der Datenbank. Jetzt noch ein paar Tags und schon braucht es obendrein auch kaum noch Bookmarks.

Müssen alle Online-Tests überwacht werden? (Nein) (!Ja) (!manche)

Findest du das Test-Interface von Moodle gut? (!Ja) (Nein)

Interessiert dich das Framework? (Ja) (!Nein)

Einleitung

Wenn ihr den oberen, natürlich per Quiz-Script erstellten Test bestanden habt oder auch nicht, dann ist vielleicht diese noch recht wenig bekannte Entwicklung von Felix Riesterer etwas für euch. Die Leute von zum.de haben die Möglichkeiten erkannt und das Quiz-Script mit in ihre Wiki-Plattformen integriert. Hier gibt es auch Anleitungen für den Einsatz. Die Anleitung zur Einbindung in Mediawiki ist in der dort skizzierten Form in meinen Augen allerdings unbrauchbar – daher unten meine Variante. Trotzdem bin ich darüber überhaupt erst auf die Idee gekommen.

Was ist das Quiz-Script-Framework?

Die Demoseite des Autors zeigt schonmal, was das Quiz-Script-Framework kann. Ich sehe den Einsatz vor in sprachlichen Fächern – endlich mal etwas für uns… Wer schon einmal mit Monolithen wie Moodle Tests erstellt und sich dabei totgeklickt hat, wird das Konzept begrüßen: Nicht der Webserver macht die Hauptarbeit, sondern der Browser, indem einfach im HEAD jeder beliebigen HTML-Datei drei einfache JavaScript-Aufrufe deklariert werden. Deswegen ist das Script prinzipiell auch in jeder Anwendung einsetzbar (z.B. in WordPress, s.o.), die euch ermöglicht, das Template (meist header.php) zu gestalten. Nicht geeignet ist es für den TinyMCE-Editor, da dessen Sicherheitsmechanismen auch im HTML-Modus die Tags zerhaseln, die das Script zum Erkennen einer Testsektion benötigt.

Beispiel – Einbindung in Mediawiki

Schritt 1:

Zunächst braucht ihr die Extension “Javascript”. Diese besteht nur aus einer einzigen Datei namens Javascript.php. Die legt ihr in einen neu erstellten Ordner mit dem Namen “Javascript”. Das muss ein Unterordner des Mediawiki-Ordners “extensions” sein. Ihr könnt natürlich den Datei- und Ordnernamen klein schreiben. 

Schritt 2:

In der Datei “LocalSettings.php” im Stammverzeichnis der Mediawikiinstallation ergänzt ihr ganz unten die Zeile:

include("$IP/extensions/Javascript/Javascript.php");

Schritt 3:

Das Quiz-Script-Framework könnt ihr hier gezippt herunterladen. Nach dem Entpacken entsteht ein Ordner “quiz”. Den Inhalt des Ordners ladet ihr nun in das Verzeichnis /extensions/Javascript. Da war es schon.

Beispiel – Einbindung in andere Scripten:

Alle anderen sorgen einfach dafür, dass im HEAD-Bereich folgende Zeilen auftauchen:

<script src="pfad_zu/quiz/quiz.js" type="text/javascript"></script>
<script src="pfad_zu/quiz/multilingual.js" type="text/javascript"></script>
<script src="pfad_zu/quiz/utf8-normalizer.js" type="text/javascript"></script>

… und schon steht auch dort die Funktionalität des Quiz-Script Frameworks zur Verfügung.Natürlich klappt das auch auf jeder simplen HTML-Seite.

Ausblicke

1. Ich experimentiere gerade damit herum, SuS selbst Online-Rechtschreibübungen innerhalb eines Wikis erstellen zu lassen. Das klappt auch mit der 6. Klasse – Drag&Drop – so komplex ist der Code nicht.
2. Man kann das Script natürlich entsprechend den eigenen Vorstellungen editieren, da es im Quelltext vorliegt.
3. Per Javascript lassen sich auch Input-Felder eines Formulars vorbelegen – und dann in eine Datenbank schreiben (z.B.) – dann rechnet der Client und nicht wie bei Moodle ein PHP-Monster. Baut wer mal ein Modul?
4. In der vorliegenden Form ist das Script zum Üben hervorragend – für Lehrer mit chronischer Kontrollitis uns Statistitis absolut ungeeignet (so stehen z.B. die Lösungen im Seitenquelltext – kann man aber ausblenden – weiter unten auf der Seite)… Die müssen doch wieder z.B. Moodle nehmen…

Einstellungen => Plugins

aktiviert werden und sorgt dafür, dass IP-Adressen grundsätzlich gekürzt gespeichert sind. Damit ist eine aussagekräftige Statistik immer noch möglich, ohne dass damit ein potentiell verkettbares individuelles Element verknüpft ist. Dieses Verfahren sieht sogar das ULD als unbedenklich an und es wurde gemeinsam mit den Piwik-Entwicklern erarbeitet.

Bei dem Thema Datenschutz wird meines Erachtens immer gerne vergessen, dass es zwei Arten von Daten gibt: Diejenigen, die ich von mir freiwillig in das Netz einspeise und diejenigen, die ich von Dritten absichtlich und unabsichtlich durch z.B. technische Inkompetenz weitergebe. Für die erste Art mag in meinen Augen die Postprivacy-Debatte mit Berechtigung geführt werden – für Leute, die unwissentlich über z.B. Apps meine persönlichen Daten an Facebook und Co. übermitteln, habe ich kein Verständnis – noch schlimmer, wenn das z.B. mit Schülerdaten passiert – schiefgehen kann immer etwas – aber so ganz regulär ohne vorherige Information, am besten noch unbewusst?

Deswegen erscheint mir dieser nun vollzogene Schritt von mir für mein Blog nur konsequent. Full SSL (https) könnte auch noch irgendwann folgen… Mal sehen. Dagegen sprechen zur Zeit noch die ganzen eingebundenen Objekte externer Seiten, die dann hübsche Warnmeldungen im Browser erzeugen…

Apropros Postprivacy – die Statistikdaten meines Blog sind hier öffentlich einsehbar – alle IPs haben eine schöne 0 im letzten dezimalen Triplett…

http://www.youtube.com/editor

Dort öffnet sich dann folgende Arbeitsoberfläche:

Oben links findet man die eigenen Videos, die man unten in die Timeline ziehen kann. Dort lassen sie sich schneiden (nur Keyframes!), indem man die Balken links und rechts vom Video verschiebt, oder auch drehen. Videos, die sich hintereinander in der Timeline befinden, werden aneinander gereiht. Die Übergänge lassen sich mit Effekten versehen, die sich ganz oben links neben dem Notensymbol zuweisen lassen. Auch Hintergrundmusik ist möglich (mit dem Notensymbol). Natürlich gibt es keine Echtzeitvorschau und das Einrechnen der Effekte dauert je nach Video schon 30-40 Minuten. Dafür ist mir noch kein Format untergekommen, welches YouTube nicht gefressen und in ein freies bzw. übliches konvertiert hätte. Für die meisten Anforderungen reicht es mit etwas Übung – gerade auch für schulische Zwecke.

Übrigens:

Sehr praktisch ist die Möglichkeit, bestimmte Zeitenindizes in YouTube-Videos direkt anzuspringen. Das funktioniert durch ein spezielles Linkformat – so muss man nicht ganze Videos verlinken, bzw. kann direkt zu den Stelle springen, über die man gerade bloggt. Wie das funktioniert, hat Gabriel so gut erklärt, dass ich es nicht besser könnte.

$HTTP["host"] =~ “^(.+\.)?etherpad.schuldomain.tld” {

auth.require = ( “” => ( “method” => “basic”,
“realm” => “Etherpad – Login mit Schulnetzwerkdaten”,
“require” => “valid-user” )
)

proxy.server = (
“” => (
“etherpad” => (
“host” => “127.0.0.1″,
“port” => 9000,
“fix-redirects” => 1
)
)
)

}

Mittels HTTP_AUTH, dass gegen den LDAP läuft, ist das System nur Netzwerknutzern der Schule zugänglich (auth.require-Sektion). Das Proxymodul von lighttpd (proxy.server-Sektion) sorgt dann dafür, dass der Browser ohne Portangabe direkt auf die Pads zugreifen kann und dafür, dass die Subdomains für die Teamsites funktionieren.

Ich habe die Pads für ein Webquest zur Regelfindung zur Getrennt- und Zusammenschreibung in Klasse 9 eingesetzt. Im ersten Teil der Doppelstunde haben wir eine Regel für eine Zusammensetzung (Adjektiv + Verb) anhand von Material selbst erarbeitet und formale Kriterien festgelegt. Im zweiten Teil der Doppelstunde habe ich je einer Gruppe einen Aspekt (z.B. Schreibung von Tageszeiten) zugewiesen, ein paar hilfreiche Seiten verlinkt und kollaborativ eigene Regelformulierungen im Pad erarbeiten lassen.  Die Aufgabenstellung und die Links befanden sich in einem Moodlekurs.

Am Folgetag haben wir die Ergebnisse – diesmal auf Totholz ausgedruckt – besprochen und anhand der Regeln, die sicher formuliert waren, kleine Übungssätz mit gehäuften Schwierigkeiten zur Getrennt- und Zusammenschreibung ersonnen. Diese Methodik war zumutbar, weil das Thema für die Klasse ein “Wiederholungsfall” ist, es also mehr um eine Reaktualisierung ging.

Etherpad verbrauchte bei 15 aktiven Clients ca. 200MB RAM und etwa 9% CPU-Zeit – beschaulich…