So, immerhin habe ich jetzt vermutlich den Grund gefunden, warum dieser Weblog immer langsamer geworden ist:

Untechnische Erklärung: Die Wiki-Version 4 bietet neue Möglichkeiten, die aber bei grösseren Wiki-Bereichen zum Teil sehr ineffizient sein können. Ich kann eine Auflistung von Wikiseiten nicht nur nach Änderungsdatum, sondern auch nach Erstellungsdatum sortieren lassen. Für eine Weblog-Funktion ist das ganz nützlich, denn ich will ja die x zuletzt erstellten Beiträge anzeigen und nicht die x zuletzt geänderten. Wie Beispiel zeigt, kann das aber quälend lange dauern.

Beginn der technischen Erklärung: Das Datum der letzten Änderung einer Wiki-Seite wird bei TWiki in den Metadaten der entsprechenden Seite gespeichert, kann also mit vergleichsweise geringem Aufwand ausgelesen werden. Nicht so das Datum der Erstellung einer Wikiseite. Diese Information ist nur via Versionsverwaltung zugänglich. Was bedeutet das nun für mein Weblog: Ruft man die Startseite des Weblogs auf, so sucht TWiki alle Seiten, auf denen steht. Danach versucht TWiki diese Treffermenge zu sortieren. Zu diesem Zweck muss es jetzt bei jeder Seite in der Versionsverwaltung die Version 1 hervorkramen und dort das Datum der letzten Änderung auslesen. Bei derzeit 867 Blogeinträgen dauert das halt eine Weile...

Lösung: Tja, ich ändere den Suchparameter wieder auf modified. Schreibt dann jemand einen Kommentar zu einem Blogeintrag, dann rutscht dieser Eintrag wieder ganz nach oben.

Hmm, ich könnte dieses Verhalten ja als gewünschtes Feature bezeichnen  

%STARTBLOG%Seit heute ist in diesem TWiki auch das TWiki.DirectedGraphPlugin installiert, welches das Integrieren von mit GraphViz (Biblionetz:w01582) gezeichneten Graphen ermöglicht:

<dot>
  digraph Beispiel { Ursache -> Wirkung }
</dot>

wird zu

Naja, alleine noch nicht umwerfend, spannend wird's erst zusammen mit dem TWiki.DirectedGraphWebMapPlugin, welches klickbare Sitemaps von TWiki-Bereiche zeichnet:

%WEBMAP{web="Cohep" lr="1" size="6,8"}% ,

Ein wunderschönes Bild, dass statt mit tausend Worten erklärt, warum das Zusammenarbeiten mit Wiki Zeit spart:

Erfunden hat diese Darstellung Chris Rasmussen von der "US National Geospatial Intelligence Agency", darum das für ungeübte Augen nach US-Militär wirkende Logo...

via Wikinomics-Blog , IsaVisutalisierung

Seit mehr als fünf Jahren (September 2002) betreibe ich meinen Wiki-Server ohne Lesebeschränkungen. Jedermann kann weltweit alle Wikiseiten lesen. Diese Offenheit (Biblionetz:w01882) ist mir wichtig, denn ich bin der Meinung, dass wir bei eLearning immer noch am Anfang stehen und voneinander lernen können sollten. Learning Management Systeme, bei denen ich nicht über den Login-Screen hinaus komme, ermöglichen mir aber kein Lernen an anderen Beispielen.

Die Inhalte dieses Wikiservers sind aber meist nur für Personen interessant und relevant, die den Kontext ihrer Entstehungsgeschichte einordnen können. Wenn Schüler/innen den zweiten Weltkrieg bearbeiten, dann sind ihre Gedanken für sie selbst, die Lehrperson, ihre persönliche Umgebung und andere eLearning-Interessierte relevant, nicht aber für den Rest der Welt. Aus diesem Grund ist es nicht sinnvoll, dass die Seiten dieses Wikiservers von Suchmaschinen gefunden werden. Darum schliesse ich mit der Datei robots.txt von Anfang an alle Suchroboter aus. Die grossen Suchmaschinen wie z.B. Google halten sich an diesen Hinweis und verzichten darauf, Seiten dieses Wikiservers zu indexieren.

Nicht an diesen Hinweis halten sich hingegen Spambots, d.h. bösartige Suchroboter auf der Suche nach E-Mailadressen oder der Möglichkeit, Werbung auf einem Wiki zu deponieren. In den letzten Monaten musste ich eine Zunahme solcher Spambots feststellen, die teilweise mit der gesamten zur Verfügung stehenden Bandbreite die Inhalte dieses Wiki-Servers abgegrast haben.

Um keine Lesebeschränkungen für Besucherinnen und Besucher einführen zu müssen, musste ein anderer Schutz gefunden werden. Gestern hat nun Benedikt eine Spambot-Falle installiert, die folgendermassen funktioniert: Auf allen Wikiseiten ist ein für den Menschen unsichtbarer Link platziert. Dumme Spambots, die allen Links nachgehen, werden auch diesen Link abrufen. Dies löst jedoch eine sofortige Sperre ihrer IP-Adresse aus. Somit sollten Spambots vom Abgrasen des gesamten Wikis abgehalten werden, während normale Wikiuser nichts von dieser Massnahme bemerken sollten.

Bevor nun ein schlauer Schüler auf die Idee kommt, das Wiki seiner Schule durch den Abruf dieses verbotenen Links aus dem Schulnetz lahmzulegen und damit eine Wikistunde zu sabotieren, hier noch folgende Hinweise: Gesperrte IP-Adressen erhalten als Antwort eine Erklärungsseite mit Captcha (Biblionetz:w01616) zurück, auf der sie die Sperre durch Eingabe von nur menschenlesbaren Zahlen wieder aufheben können. Zudem kann ich einzelne IP-Adressen auch in eine Whitelist eintragen, so dass das Abrufen des verbotenen Links von dieser IP-Adresse aus wirkungslos bleibt.

Ein letzter Hinweis für Techies: Bitte die Spambotfalle nicht an meinem Wiki testen: Erstens erhalte ich jeweils ein Mail, wenn sich ein Spambot in der Falle verfängt und zweitens will ich eine unverfälschte Statistik, wie viele Spambots wir fangen konnten. Wer die Funktionsweise testen will, ist eingeladen, dies auf der Website der verwendeten Software zu tun: http://www.spider-trap.de/

Why do I blog this:

• Naja, einerseits damit die User dieses Wikis von diesem Feature wissen. Dieser Blog dient auch als Announcement-Board für das Gesamtwiki.
• Andererseits, weil diese Massnahme ein schönes Beispiel für soft security (Biblionetz:w01915), die zeigt, dass man mit dem notwendigen technischen Know-how nicht nur die Wahl zwischen sicher und brauchbar hat, sondern dass differenzierte Lösungen möglich sind.

Patrick Lambe verweist in einem Blog-Posting auf eine Präsentation von Benjamin Greenberg der non profit Organisation Physicians for Human Rights, der die mailflutsenkende Wirkung von Weblogs vorrechnet:

Eine ähnliche Rechnung gilt für die Aussage Wiki kann die E-Mailflut verringern (Biblionetz:a00731)