Obwohl ich im Biblionetz eigentlich eine Liste ausgeliehener Bücher führe, vermisse ich derzeit mehrere Bücher, die entweder mir gehören oder - noch schlimmer - ich der Bibliothek zurückgeben sollte.

Darum meine Frage: Hat jemand die folgenden Bücher von mir ausgeliehen?

	Heidi Schelhowe: Technologie, Imagination und Lernen Biblionetz:b03147
	Joseph Weizenbaum: Die Macht der Computer und die Ohnmacht der Vernunft Biblionetz:b00030
	Alev Inan, Andrea König: Medienbildung - Medienalltag Biblionetz:b03787

---

Irgendein Buch von Joseph Weizenbaum hast du mir mal gegeben, als du mir von Bookcrossings erzählt hast. Ich habe das dann im Sinne des Prinzips zufällig irgendwo platziert. Ich weiss allerdings nicht mehr, ob es oben genanntes war.

-- Main.MatthiasDreier - 17 Nov 2009

---

Hoi Matthias,
danke für den Kommentar. Das Buch, das Du ausgesetzt hast, ist mit Sicherheit nicht das gesuchte. Du hast Sind computer die besseren Menschen Weizenbaum contra Haefner (Biblionetz:b00031) ausgesetzt. Davon hatte ich mehrere Exemplare. Die Macht der Computer... hatte ich vor kurzer Zeit noch in der Hand, Dich habe ich aber seit längerem nicht mehr gesehen...

In der Novemberausgabe der Communications of the ACM ist die Programmiersprache Scratch (Biblionetz:w02030) Titelthema. Unter dem Titel Scratch: Programming for All (Biblionetz:t09978) erläutern die Entwicklerinnen und Entwickler von Scratch die Ziele und Kernüberlegungen, die hinter der Programmierumgebung für Kinder und Jugendliche stecken.

Der Artikel betont die Bedeutung des Programmieren-Könnens für das Verständnis und Gestaltungsmöglichkeit in einer digitalen Welt. Diese Idee ist keineswegs neu, aber der Artikel enthält einige sehr schöne Aussagen in prägnanter Form, die sich wunderbar als Zitate eignen:

Sogenannte digital natives (Biblionetz:w01839) sind also aus Sicht des Scratch-Entwicklungsteams trotz eventuell vorhandener Web 2.0 Virtuosität eigentlich passiv Konsumierende: Sie nutzen nur bestehende Programme und Services, statt diese selbst (weiter) zu entwickeln.

Das Scratch-Team sieht deshalb Programmierkenntnisse (Biblionetz:f00114) als notwendigen Teil einer digital fluency :

Neben Designprinzipien und Grundsatzüberlegungen bietet der Artikel auch Zukunftsaussichten. Wohin soll Scratch gehen?

Cool: Ein Scratch auf mobilen Geräten und ein Scratch, das im Internet Daten austauschen kann. Sozusagen Scratch für mobile learning und Scratch für Web 2.0.

Das Scratch-Entwickler-Team sieht die Herausforderung weniger bei der Technik, sondern eher im Bereich Bildung und Gesellschaft:

Lesen! und Los-Scratchen!

---

Richtig lesen können sie auch nicht... http://www.zeit.de/2009/47/DOS-Analphabeten?page=all -- Main.TorstenOtto - 16 Nov 2009

Seit bald einem Jahr versuche ich meinen offenen Wikiserver mit einer Spambotfalle vor dem unerwünschten und Ressourcen benötigenden Abgrasen zu schützen (Details siehe hier).

Es ist noch schwierig, die Effizienz dieser Falle zu beurteilen: Nehme ich die blockierten IP-Adressen als Indikator, dann funktioniert die Falle bestens. Im vergangenen Jahr hat die Zahl der Blockierungen zugenommen, derzeit bleibt täglich mindestens ein Bot drin hängen. Umgekehrt sehe ich natürlich nicht, wie viele Bots die Falle unerkannt umschiffen, z.B. mit gezieltem, auf mehrere IPs verteiltem Crawlen.

Neben Spambots haben in letzter Zeit auch die automatisierten, URL-basierten Hacking-Angriffe zugenommen, sowohl im Wiki als auch im Biblionetz. Dort sind diese Angriffe eher chancenlos, denn das Biblionetz besteht nur aus zehntausenden von statischen Dateien, aber weder einer Online-Datenbank noch sonstigen Skripten (tiefstes Web 0.5 sozusagen). Aber das stört die Hackbots nicht, die meine Seiten zu Tausenden abrufen und versuchen, irgendwelche Exploits in phpBB oder Wordpress oder was auch immer auszunutzen.

Um auch mit diesen Bots kurzen Prozess zu machen, habe ich nun angefangen mit RewriteRule auch entsprechende Hackingsversuche der Spambotfalle zuzuführen und damit automatisch sperren zu lassen.

Tja, und nun werden halt pro Tag auch mehrere IP-Adressen gesperrt, die versuchen, ins Biblionetz einzubrechen.

Wieder ein schönes Beispiel für soft security (Biblionetz:w01915).

Da ich mich derzeit wieder etwas intensiver mit Scratch beschäftige (jaja, auch wenn man gegen aussen (noch) nichts sieht, wir arbeiten fleissig an http://iLearnIT.ch weiter), bin ich auf ein spannendes Ökosystem rund um Scratch gestossen.

Was ich bereits vorher wusste: Scratch (Biblionetz:w02030) baut auf Squeak (Biblionetz:w01597), was wiederum auf einem Smalltalk-Dialekt (Biblionetz:w01332) aufbaut.

Scratch ist Open Source, d.h. der Squeak-Quellecode kann frei heruntergeladen und verändert werden. Das MIT hat aber ein Interesse daran, dass möglichst viele mit der offiziellen Version von Scratch entwickeln, da nur so der Austausch von Programmen via Scratch sichergestellt ist. Entsprechend dürfen Scratch-Ableger weder den den Namen Scratch verwenden noch den Upload auf die Scratch-Community-Website ermöglichen.

Derzeit existieren mindestens folgende Scratch-Ableger:

• Chirp ist eine auf Scratch 1.2.1 aufbauende Scratch-Weiterentwicklung von Jens Moenig. Sie bietet unter anderem die Möglichkeit, Programme als XML zu exportieren und zu importieren, Scratch-Programme als direkt unter Windows lauffähige EXE-Programme zu speichern, Windows-Screensaver zu programmieren und Programmblöcke per Kontextmenu zu verändern.
• Mit BYOB (Build Your Own Blocks) bietet Jens Moenig eine weitere Scratch-Erweiterung an, die auf Scratch 1.4 aufbaut. Mit BYOB 2.0 ist es möglich, eigene Programmblöcke zu programmieren, d.h. Scratch wird um Funktionen und Prozeduren erweitert. Zudem ist es möglich, auf das darunter liegende Squeak zuzugreifen, womit sich ungeahnte Möglichkeiten (und Abgründe) auftun:
  
  
  Als dritte spannende Erweiterung ist die Zusammenarbeit in einem Mesh-Netzwerk möglich, womit Scratchprogramme via Netzwerk miteinander reden können.
• Streak: Erweiterung von Scratch 1.3.1 vorwiegend um Dinge, die im offiziellen Scratch 1.4 auch eingeführt worden sind (z.B. Frage-Block mit Antwort als Variable). Eine detaillierte Liste der Erweiterungen ist in der Versionsgeschichte zu finden.

Alles in allem spannende Ansätze, welche die Potenziale von Scratch erweitern. Es ist zu hoffen, dass die sich bewährenden Konzepte dieser Scratch-Erweiterungen in spätere, offizielle Scratch-Versionen Einzug halten werden.

Des weiteren taucht regelmässig die Frage nach Scratch auf verschiedenen (mobilen) Plattformen auf: Scratch für Playstation, Scratch für das iPhone, etc. Derzeitiger offizieller und halboffizieller Informationsstand: Aufgrund fehlender Entwicklungsressourcen sind derzeit vom MIT keine entsprechenden Entwicklungen möglich.

Als dritte Erkenntnis habe ich anlässlich meiner Recherche gemerkt, dass Scratch per TCP/IP kommunizieren und so mit anderen Programmen Daten austauschen kann. Unter Scratch Connections sind verschiedene Anleitungen und Beispiele zu finden, wie Scratch z.B. RSS-Feeds verarbeiten kann oder man mit Scratch einen Chat programmieren kann.

Auslöser unserer Recherche war die Frage, ob man in Scratch Variablen einfach umbenennen könne. Dieses Ansinnen taucht auf, wenn man Beispielprogramme auf deutsch und französisch anbieten will: Wie nennen wir die Variablen? Deutsch - dann müssen wir aber für die französische Version nicht nur die Texte, sondern auch das Programm selbst anpassen - in Scratch eine mühsame Handarbeit. Benennen wir die Variablen stattdessen auf englisch, so entfällt dieser Übersetzungsaufwand, dafür sinkt die Verständlichkeit des Programms inbesondere für Primarschüler. Es ist ja einer der Vorteile von Scratch als Programmiersprache für Kinder, dass sich die Sprache der Programmblöcke im laufenden Betrieb ändern lässt, so dass ein mit deutschen Programmierblöcken geschriebenes Programm mit einem Mausklick in Französich oder Türkisch darstellen lässt. Da ist es dann schade, wenn die Variablen englisch sind. Wir sind nicht die einzigen, die auf der Suche nach einer Lösung für dieses Problem sind, aber bisher haben wir keine wirklich effiziente Lösung gefunden.

Sachdienliche Hinweise nehmen wir gerne entgegen... ,

Vor circa einem Jahr gab es einen Streit zwischen dem Initiator der Open Source Wiki-Engine TWiki und den restlichen Hauptentwicklern. Hintergründe dieses Streits lassen sich bei Bedarf nachlesen, relevanter ist die Tatsache, dass ein Fork unter dem Namen Foswiki entstanden und seither weiterentwickelt wird.

Foswiki (steht für Free and Open Source Wiki, nicht sehr fantasievoller Name ) ist derzeit kompatibel mit TWiki, so dass einer Migration wenig im Weg stehen sollte. Ansonsten wird Foswiki aber fleissig weiter entwickelt, wie der Releas Plan zeigt. Es freut mich, dass die Wiki-Engine, die ich seit 2002 zwei privat und beruflich nutze, weiter entwickelt wird und somit eine Zukunft hat.

Auf der Website von Foswiki habe ich eine schöne Übersichtsdarstellung gefunden, welche die Kernpunkte von Foswiki aufführt:

Während das Wiki-Prinzip unterdessen weitherum verstanden wird, sehe ich bei der Kombination von Wiki + strukturierte Daten + programmierbare Seiten oft noch Erklärungsbedarf:

Ich habe damit den Fünfer und das Weggli, nämlich ein einfaches Wiki und daneben zwei mächtige Erweiterungen, um die sich aber Leute, die das nicht benötigen, auch nicht zu kümmern brauchen. Konkret: Wer keine strukturierten Daten und keine programmierbaren Seiten benötigt, kann TWiki und Foswiki nutzen, ohne dass er/sie je durch diese Möglichkeiten verwirrt wird. TWiki und Foswiki lassen sich auch als simpel einfache Wikis nutzen. Wer dann aber mehr will, kann Register ziehen, die ein simples Wiki eben nicht bietet.

(Michele Notari (Biblionetz:p01511) und ich haben im Paper Over-computing CSCL Macro scripts (Biblionetz:t09500) versucht zu zeigen, wie sich diese Features von gewissen Wiki-Engines bei CSCL nutzen lassen.)

Damit folgt TWiki / Foswiki dem wichtigen Designprinzip von guter Software für kreative Tätigkeiten:

low floor, wide walls und high ceiling:

• low floor: Geringe Einstiegshürde
• wide walls: Verschiedene Herangehensweisen möglich
• high ceiling: Gegen oben offen Komplexität möglich