Samstag, November 22, 2014

Was mich am Inverted Classroom bzw. Flipped Classroom nervt

Mich nervt die Begeisterung für den "Umgedrehten Unterricht" -- im Englischen als Inverted oder Flipped Classroom bezeichnet --, die durch die Hallen der Hochschulen und Universitäten geistert. Die Idee: Statt einer Vorlesung werden Videos produziert, die die Studierenden im Selbststudium konsumieren. So kann die eigentliche Vorlesungszeit in effektive Übungszeit gewandelt werden.

Der Ansatz ist simpel. Und er scheint einen Reiz auszuüben. Seit drei Jahren treffen sich in Marburg Schul- und Hochschullehrer(innen) aus dem deutschen Sprachraum auf der ICM-Konferenz. Man ist gewillt, sich von der Idee anstecken zu lassen und Erfahrungen auszutauschen. Es gibt einige sehr engagierte Produzenten von Lehrvideos, allen voran Jörn Loviscach, Hochschullehrer in Bielefeld. Er schneidet jede Vorlesung und jeden seiner Vorträge mit. Nicht ganz 2.000 Videos listet seine Homepage aktuell auf. Seinen Youtube-Kanal haben über 41.000 Menschen abonniert, fast 15,5 Millionen Aufrufe seiner Videos hat es bisher gegeben. Damit ist Loviscach so etwas wie der "Popstar" der deutschsprachigen ICM-Szene.

Dabei sind es nur Videos! Der Eifer eines Loviscach, seine Traute aber auch sein Können öffentlich dokumentierter Lehre ringen mir Bewunderung ab. Loviscach kann erklären, der Gute hat was auf dem Kasten. Er macht meinem Berufsstand alle Ehre. Allein, es sind und bleiben nur Videos.

Loviscach weiß es und eigentlich weiß es auch jeder andere (Hochschul)Lehrer und jede andere Hochschullehrerin: Videos können Freiräume schaffen, ohne Frage, aber die Lehre revolutionieren können sie nicht. Weil Lehre weit mehr ist als ein Buch, als ein Video, als ein Professor, als eine Vorlesung oder eine Übung. Da Lernen individuell ist, muss auch die Lehre irgendwann beim Individuum ankommen, dort etwas auslösen, Wissen verankern, Erfahrungen einfließen lassen. Als Produktionsfaktor muss Lehre zu einem gewissen Grad massentauglich sein, aber sie muss das Denken, Leben und Fühlen eines einzelnen Menschen erreichen und verändern. Das ist ein interessanter Spannungsbogen, und die Suche nach einem Brückenschlag bleibt eine stete Herausforderung. Die Lebenswelten der Menschen ändern sich permanent, digitale Technologien durchsetzen eindringlich den Alltag, Wertesysteme sind im Wandel, vieles ist im Fluss. Lehrer(innen) werden allein schon benötigt, um diesen steten Wandel und den Transformationsbedarf zu bedienen, wenn es um die Lehre und das Lernen geht. Es gibt immer wieder aufs Neue einen Bedarf an didaktischen und pädagogischen Konzepten, Ideen, Methoden, Techniken.

Ich will die Absurdität der "Umgedrehten Vorlesung" einmal auf die Spitze treiben. Nehmen wir ein Beispiel aus meinem Hochschulalltag an der Technischen Hochschule Mittelhessen (THM) in Gießen. Dieses Semester bietet meine Veranstaltung "Objektorientierte Programmierung" 270 Informatik-Studierenden im 1. Studiensemester eine Einführung in die Programmierung. Es ist nahe liegend, die Veranstaltung zu "flippen" oder zu "invertieren", nicht wahr? Bei der Masse muss man ja regelrecht Videos produzieren. Warum sollte man sich unten in den Hörsaal stellen und über das Mikro 270 Menschen beschallen? Interaktivität ist ohnehin kaum möglich in so einem Setting. Gut, produzieren wir also Lehrvideos für 14 Semesterwochen. Übungen mit 270 Studierenden im Hörsaal sind auch nicht sehr ergiebig. Also werden wir auch die Übungen auf digitalem Zelluloid bannen! Und dann? Ja dann haben wir im Grunde das Material für einen MOOC, einen Massive Open Online Course, beisammen. Die Videos sind schnell hochgeladen. Lehre im neuen Jahrtausend ist online. Weil es noch an der Interaktivität mangelt: Quizzes dazu, ein Diskussionsforum aufsetzen, fertig. Wir richten noch eine Sprechstunde ein, in der sich Studierende an Tutoren wenden können. Es ist anscheinend alles Menschenmögliche getan, damit jeder Student und jede Studentin am Ende programmieren kann. Dann gibt es am Ende des Semesters nur noch die Klausur.

Ich behaupte, das ist keine Lehre! Videos sind so wenig Lehre wie es Texte in Büchern sind. Es macht keinen Sinn, ein Kind vor ein Video zu setzen, damit es dann Fahrrad fahren oder Schwimmen lernt. Da braucht es das Vorbild, die Demonstration, auch einmal die führende Hand, das ermutigende Wort, Rückmeldung und ermunternden Applaus, wenn erste Erfolge zu sehen sind. Die Lehre im digitalen Jahrtausend soll gerne alles nutzen, was digital zur Hand ist. Videos sind ja nicht per se schlecht. Und eine gamifizierte Lerneinheit am Computer auch nicht. Wenn sich Lehre jedoch entfremdet von den Sorgen und Ängsten junger Menschen. Wenn sie beim Lernen alleine lässt, wenn sie um den Preis der Orientierung an Masse am Individuum vorbei zielt. Wenn sie keine Orientierung und vor allem: keinen Lehrer bzw. keine Lehrerin mehr hat. Dann, so glaube ich, findet keine Lehre statt.

Kommen wir auf mein Beispiel zurück. Was beschäftigt mich, wenn ich 270 Studierende an das Programmieren heranführen will? Das letzte, woran ich denke, sind Videos! Es beginnt mit einem Leitsatz: "Lernzentrierte Lehre". Und das heißt für mich: Vom Ende, von der Klausur her denken. Wie bekomme ich meine Studierenden fit für die Programmierung in Java, wobei ich das Prüfungsformat nicht ignorieren kann. Einen Studierenden interessiert, wie er oder sie die Klausur nicht nur bestehen, sondern es soll auch klar sein, wie man mit einer Bestnote abschließen kann. Und darauf muss ich vorbereiten. Es muss Übungen und Tests geben, die Training sind für die Klausur. (Außen vor lassen möchte ich die Diskussion, ob eine Klausur die adäquate Prüfungsform ist. Das ändert nichts an dem Leitsatz und der Implikation: Wie gestalte ich Lehre aus Sicht der Studierenden?)

Was mich beschäftigt:

* Wie kann ich meinen Studierenden das Programmieren vereinfachen? Visuelle Orientierung und Interaktivität bringen abstrakte Konzepte an die sichtbare Oberfläche und gewährleisten schnelles Feedback beim "Sprechen" mit dem Computer. Das sind gute Voraussetzungen für selbstbelohnendes Lernverhalten. Darum fiel meine Wahl auf Processing. Das ist ein wunderbar verpacktes Java. Und zu Processing gibt es sehr gute Lernvideos! (Und wer mag, findet da großartige Unterstützung beim Lernen.)

* Ein anderer Leitsatz: "Programmieren ist ein Handwerk". Darum programmieren die Studierenden mit mir im Hörsaal. Das wird zweimal in der Woche angeboten für jeweils rund 120 Studierende. Das ist wie gemeinsames Fahrrad fahren, Schwimmen gehen oder Schreinern. Hier muss keiner fürchten, etwas falsch zu machen. Man bespricht gemeinsam Programme, tippert sie, probiert aus. Spielräume sind geschaffen.

* Wie erreiche ich den einzelnen Studierenden? Es gibt sieben Termine, die sich eine Assistentin und ein Assistent zusammen mit vier Tutoren teilen. So erreichen wir eine Gruppengröße von fast 40 Studierenden. Es herrscht Teilnahmepflicht, es gibt Übungsaufgaben und Tests. Betreuung ist in der Nähe, Hilfestellung wird gegeben. Jetzt macht jeder seine eigenen Erfahrungen im Sprachwasser der Programmiersprache.

Noch gibt es eine Vorlesung. Und ich überlege in der Tat, Teile davon als Videos zu produzieren, um stattdessen eine weitere Übung anzubieten. Aber die Videos sind nur ein Baustein. Es soll in Zukunft auch ein Skript geben. Papier als Nachschlagemedium ist dem Video weit überlegen. Und noch wichtiger: Lernkarten!!! Lernkarten (am besten digital) und Quizzes sind so mit das Beste, was es gibt, um Wissen in die Hirne zu befördern.

Was mich am "Umgedrehten Unterricht" bzw. an der "Umgedrehten Lehre" nervt? Es ist kein Lernkonzept! Vielleicht sollte das die 4. ICM-Konferenz in Marburg thematisieren.

Freitag, Juni 27, 2014

Let me tell you a story: I'm a Prisoner of the JVM


In JVM prison we live in a totalitarian system. You are not allowed to do something unless you are called to do something.

You can call someone else to ask for assistance. But that's no fun either. You have to stand still and wait for the other to complete your call.

Some poor guys call themselves to experience the joy of activity. If you call yourself too often, guards will step in and brutally silence you.

Whenever you do not behave properly, an alarm goes on. The guards try to manage exceptional situations one way or the other. They hate to face a situation they are not prepared to handle.

There are instructions we have to follow when called for action. Very often the instructions are carelessly written and buggy. We get punished if we misbehave and guards yell at us.

Life in JVM is full of shit. A lot of us are dying. When they bury the dead, they call it "garbage collection". Can you imagine that?

Fight for a better JVM. Fight for programmers who care about objects. 
Fight for objectivity. 

Know what you are doing when programming in Java, Clojure or Scala!

Remark: While thinking about a nice way to explain object-orientation, I suddenly found myself inventing this story about "The dark side of the JVM". It's just a story. Don't worry, keep on and enjoy programming, they are just objects ;-)

Sonntag, Juni 22, 2014

"Weniger schlecht programmieren"

Gestern hing ich mit Kathrin Passig und Johannes Jander in der Pause in Marburg ab. Anbei: Das Straßencafe "Die Pause" in der Oberstadt ist ein Geheimtipp, und ich hatte den Eindruck, dass es Kathrin und Johannes hier sehr gut gefallen hat. Ein gemütlicher Ort, an dem man ein wenig die Zeit verlieren und sich ausführlich über das Programmierleben unterhalten kann. Software-Testing, ja das ist wichtig, aber man muss es nicht übertreiben. Wir waren uns mal wieder einig. Das muss einen nicht daran hindern, Warstories aus Softwareprojekten zum besten zu geben. Ich, zum Beispiel, kannte einen Software-Tester, dessen Gespür für Softwarefehler geradezu unheimlich war -- so ein Uri Geller, der mit ein paar Tests zeigte, dass an der Software so gar nichts richtig und gerade war. Der führte einem vor, welche Codezeilen alle "verbogen" waren. Wahnsinn.

Zuvor hatten mir Kathrin und Johannes im Zug von Gießen nach Marburg von ihren Ansichten über das Testen erzählt. Das Schöne: Beide blieben auf dem Teppich, die Softwarebranche hat sie geschliffen. Sie wissen, was wichtig ist, wo es drauf ankommt, ohne dogmatisch zu sein. Gerade das sind beide nicht: Dogmatiker. Gesunde Pragmatiker eher. Daher kann man mit den beiden auch so unkompliziert seine Zeit verbringen. Sie wissen viel, sind unglaublich herumgekommen in der Softwarewelt, und bringen ihr Wissen solide und hübsch auf den Punkt!

Ich habe mit beiden seit einiger Zeit meinen Spaß. Kathrin, Johannes und ich, wir treiben uns seit zwei Monaten an wechselnden Orten herum. Mal in Gießen, mal in Marburg, mal in meinem Büro, mal zuhause. Natürlich -- ich gestehe -- kenne ich Kathrin und Johannes nicht persönlich. Sie sprechen über ihr Buch "Weniger schlecht programmieren" mit mir. Das Buch ist derart informell und gleichzeitig grundsolide, dass es wie ein Plausch unter Freunden anmutet. Unter guten Freunden sogar. Niemals hebt wer den Zeigefinger, es geht um das Programmieren unter menschlichen Bedingungen. Der Mensch ist ein Mängelwesen. Aber das weiß jeder selbst -- kein Grund, sich dafür fertig zu machen und abzustrafen. So erklärt sich der Titel. "Besser programmieren" wäre so anmaßend, so besserwisserisch. "Weniger schlecht programmieren" hat Verständnis für Dich und mich als Programmierer(in) und erinnert bestenfalls mit einem Augenzwinkern an die eine oder andere Episode, manch einsamen Tag vor der Tastatur, der hätte ganz anders verlaufen können, hätte, ja hätte man das Buch "Weniger schlecht programmieren" schon vor 10 oder 20 Jahren gelesen.

Oh, welche Blessuren hätte ich mir ersparen können, wären Kathrin und Johannes nicht solche elenden Prokrastinierer -- das Buch hätte schon vor Jahren erscheinen sollen. Andererseits: Es macht sie doppelt sympathisch, die beiden wissen, wovon sie reden und leiten das Buch so wunderbar ein im ersten Teil mit einem Kapitel "Zwischen Hybris und Demut". Es sind Menschen, die Computer programmieren.

Im zweiten Teil geht es um Themen wie: Konventionen, Namensgebung, Kommentare, Code lesen, Hilfe suchen, Lizenz zum Helfen, Überleben im Team -- all das unter dem klarsichtigen Titel "Programmieren als Verständigung". Kein Lehrbuch bringt es so realititätsnah auf den Punkt.

Teil 3 widmet sich dem "Umgang mit Fehlern". Da geht es ums Debugging, Refactoring, Testing und um Warnhinweise. Worte der Weisheit! Ich wünschte, auch das hätte mal auf dem Lehrplan meines Studiums gestanden.

Der vierte und letzte Teil, überschrieben mit "Wahl der Mittel", trägt Weisheiten, Techniken und Werkzeuge zusammen, die das Tagwerk eines Programmierers bzw. einer Programmiererin prägen sollten. Die Themen: Mach es nicht selbst, Werkzeugkasten, Versionskontrolle, Command and Conquer -- vom Überleben auf der Kommandozeile, Objektorientierte Programmierung, Aufbewahrung von Daten, Sicherheit, Nützliche Konzepte, Wie geht es weiter.

Das Buch lohnt sich. Die Zeit mit Kathrin und Johannes ist ein echter Gewinn. Nicht alles ist für den erfahrenen Programmierer bzw. die erfahrene Programmiererin neu, "aber gut, dass wir nochmal darüber geredet haben". Reflektion, Bewusstwerdung, das Erinnern an Techniken, Werkzeuge, Weisheiten aus dem Werkzeugkasten der Softwaretechnik, all das wird helfen, beim "Weniger schlecht programmieren." Es macht Dich besser!

Das Buch ist nichts für Programmieranfänger(innen). Aber man sollte das Buch im Regal stehen haben. Damit es in Reichweite ist für die Momente, wenn man ein wenig Beistand und Verständnis bei Kathrin und Johannes braucht. Am Abend, in der Programmierpause, im Cafe oder unterwegs. Und diese Momente sind häufiger als man denkt.

Kathrin Passig, Johannes Jander: Weniger schlecht programmieren, O'Reilly, 2013, http://www.oreilly.de/catalog/wenschleprogger/

[Hinweis zum Interessenkonflikt: Der O'Reilly-Verlag hat mir ein kostenloses Rezensionsexemplar zukommen lassen. Ich würde mich sehr freuen, wenn O'Reilly der "Für Dummies"-Serie eine "Weniger schlecht"-Serie entgegensetzen würde. Den Anfang haben Kathrin Passig und Johannes Jander gemacht. Weiter so!]

Dienstag, März 04, 2014

2 Programmiertipps: Bring Kopfwelt und Programmierwelt in Passung

Wenn es eine oder zwei Empfehlungen gibt, die ich einer Programmiererin oder einem Programmierer mit auf den Weg geben möchte, dann diese zwei:
  • Visualize what you don’t see
  • Express your understanding of your code
Beide Tipps drehen sich um ein und denselben Punkt: Stimmt das, was ich da programmiert habe, mit meinen Vorstellungen überein, was der Code wirklich tut? Habe ich ein korrektes Abbild dessen im Kopf, was sich zur Laufzeit meines Programms abspielt? Gerade in einer OO-Sprache ist die Gefahr sehr groß, dass man nicht wirklich überblickt, wie sich Objekte untereinander verknüpfen, ob die Objektstrukturen auch das abbilden, was man wollte. Man muss eine lebhafte Phantasie haben, um zu sehen, welche Auswirkungen der Programmcode in Form von Klassen und Methoden bei seiner Ausführung auf die Ebene der Objekte hat.
Beide Tipps seien an einem Beispiel erläutert.
In den letzten Tagen implementierte ich eine besondere Variante der binären Bäume: AVL-Bäume. AVL-Bäume achten beim Hinzufügen oder Entfernen von Knoten darauf, dass der Binärbaum balanciert bleibt — die englischsprachige Wikipediaseite erklärt AVL trees sehr gut. Als kleine Herausforderung kam dazu, dass der AVL-Baum als persistente Datenstruktur umgesetzt werden sollte. Man braucht persistente Datenstrukturen in der funktionalen Programmierung. Bei einer persistenten Datenstruktur werden Daten niemals verändert (Immutabilität), das Hinzufügen oder Entfernen von Daten erzeugt eine neue Datenstruktur, wobei so viele Anteile der “alten” Struktur wie möglich wiederverwendet werden.

Tipp 1: Visualize what you don’t see

Ich startete mit einer persistenten Implementierung eines Binärbaums — das ist in Python rasch geschehen. Dann folgte der Ausbau zum AVL-Baum, was ein wenig Arbeit und vor allem Verständnis erforderte. Wenn nach dem Einfügen eines Knotenelements der Baum seine Balance verliert, dann müssen Teilbäume rotiert werden, damit der Baum wieder ausgewogen ist.
Nachdem ich fertig war, stellte sich die Frage aller Fragen: Macht mein Code, was er soll? Erste Gehversuche mit dem Code an der Python-Konsole verliefen gut und ohne Probleme. Doch sind die Bäume wirklich ausbalanciert? Ich will nicht nur Sonderfälle testen, sondern auch sehen, dass die Verlinkung der Knoten stimmt. Visualisierung als vertrauensbildende Maßnahme ist nicht zu überbieten!
Zum Glück gibt es ein wunderbares Werkzeug zur Darstellung von Graphen aller Art: Graphviz. Schnell war die __str__-Methode der Node-Klasse angepasst und ich konnte mir mit Hilfe einer Funktion gviz eine passgerechte Ausgabe für eine Graphviz-Ausgabe erzeugen. Und die brachte das Unglück an den Tag.
n1 = Node(3).insert(4).insert(2)
n2 = n1.insert(1)
n3 = n2.insert(0)

print(gviz(n3))
Der sich ergebende Baum war alles andere als balanciert. Ab einem Höhenunterschied von mindestens 2 muss der Baum neu ausgerichtet werden. Blau eingefärbt ist jeweils der Verweis auf den “linken” Teilbaum eines Knotens, in Rot der “rechte” Teilbaum. Die Angabe im Knoten entspricht dem Schlüsselwert, dem key des Knoten.
Der Fehler im Code war schnell gefunden. Die “Höhe” eines Knoten wurde falsch berechnet, ich hatte die Addition um + 1 am Ende von max( ... ) vergessen. So ein Fehler passiert schnell und ist leicht behoben.
        self.height = max(left.height  if left  else 0,
                          right.height if right else 0) + 1
Und siehe da, jetzt stimmt es!
Die Visualisierung der ansonsten verborgenen Verlinkungen von Node-Objekten hilft außerdem dabei, die schrittweise Entstehung der Baumstrukturen zu beobachten, wobei die Immutabilität gewahrt bleibt. Es werden keine Referenzen “verbogen”, sondern gegebenenfalls neue Knoten mit neuen Referenzen erzeugt. Wann immer möglich, wird auf vorhandene Teilstrukturen verwiesen. Ein
print(gviz(n1,n2,n3))
liefert mir die Darstellung von drei Bäumen mit jeweils n1, n2 bzw. n3 als Wurzelknoten.
Links sieht man den durch n1 aufgespannten Baum, der mit der Ergänzung um einen Schlüssel 1 einen neuen Wurzelknoten, n2 liefert, der die rechte Teilstruktur beibehält (die roten Verweise auf den Knoten mit dem Schlüsselwert 4), jedoch links einen neuen Teilbaum mit dem zusätzlichen, neuen Knoten mit dem Schlüssel 1 aufbaut. Die Ergänzung um einen Schlüssel mit dem Wert 0 liefert den Knoten n3, der nun im linken Baumteil eine Rotation durchführen muss, um den n3-Baum zu balancieren.
Ohne eine solche Visualisierung hätte ich meinem Code kaum getraut. Vor allem sind große Baustrukturen rasch auf ihre Balanciertheit hin visuell inspiziert. Visualization builds trust in code!

Tipp 2: Express your understanding of your code

Natürlich gehören zu jedem guten Stück Code ein paar Testfälle. Was ich mit diesem zweiten Tipp jedoch meine, greift noch viel unmittelbarer: Überprüfe — beispielsweise mit Unit-Tests — ob der Code auch das tut, von dem Du glaubst, dass er es tut. Im Beispiel: Hat ein instanziierter Node tatsächlich die ihm zugewiesenen Eigenschaftswerte, insbesondere die berechneten Eigenschaftswerte. Wie ich feststellen musste, was schon die erste und einfachste meiner Annahmen nicht korrekt. Ein Knoten ohne jegliche Nachfolger sollte die Höhe 0 haben — hatte er aber nicht.
    def test_oneNode(self):
        n = Node(3)
        self.assertTrue(n.key == 3)
        self.assertTrue(n.height == 0)
        self.assertTrue(n.left == None)
        self.assertTrue(n.right == None)
Der obige Code zur Berechnung von self.height hatte tatsächlich noch einen Fehler! Er konnte niemals 0 werden, was von mir gar nicht beabsichtigt war. Dieser Widerspruch zwischen Annahme und tatsächlich berechneter Knotenhöhe fiel nicht weiter auf, da es für die Berechnung der Balance zwischen zwei Teilbäumen keine Rolle spielt, ob ein konstanter Wert konsistent dazugerechnet wird oder nicht. Erst die kleine Korrektur von self.height brachte die Welt wieder in Ordnung.
        self.height = max(left.height  if left  else -1,
                          right.height if right else -1) + 1

Zusammengefasst

Wer programmiert, baut Kunstwelten aus Objekten auf. Und dabei ist vor allem wichtig, dass die Ideen und Vorstellungen im Kopf übereinstimmen mit den erschaffenen Objektwelten. Sonst weiß man nicht wirklich, was man da programmiert hat, was da abläuft und was sich da tut.
Kopfwelt und Programmwelt müssen unbedingt in Passung gebracht werden. Und dazu gibt es zwei Techniken:
  • Visualisiere die Welt Deiner Objekte, damit Du Deine Erwartungen und Vorstellungen abgleichen kannst. Graphiz ist dafür ein sehr elegantes Werkzeug.
  • Formuliere Deine Vorstellungen an die Objektwelt, so dass Brüche in der Objektwelt sofort zutage treten. Assertions und TestCases sind hier ein gutes Hilfsmittel.

Freitag, September 06, 2013

Was darf ein eBook kosten?

Die ein, zwei Euro, die ein eBook gegenüber der Papiervariante oft nur billiger ist, sind ein schlechter Handel für seinen Käufer. Mit dem Buch kann ich machen, was ich will -- mit dem eBook nicht! Ein eBook verkaufen, nein, das geht nun wirklich nicht und hat der Leser des Buches auch nicht beabsichtigt, so sieht es das Landgericht in Bielefeld [siehe kLAWtext]. Lassen wir einmal dahingestellt, ob diese Rechtsauffassung bestand haben wird. Fakt bleibt: Nach derzeitiger Lage sind eBooks nur geringfügig billiger als Papierbücher, ohne dass ich das gleiche Verfügungsrecht über ein eBook habe wie über ein "normales" Buch.

Machen wir also die ökonomische Rechnung auf: Das Papierbuch kann ich nach Gebrauch wieder verkaufen, das eBook nicht. Also darf ein eBook nicht teurer sein als Neupreis minus Verkaufspreis des gebrauchten Buchs. Die Rechnung ist schnell gemacht dank des Trade-In-Angebots bei Amazon. Dort kann ich meine gebrauchten Bücher wieder loswerden. Teils zu lachhaften Preisen, aber wir wollen uns einmal an der aktuellen Bestseller-Liste des SPIEGELs (36/2013) orientieren.

Wer mag, kann meine Fleißarbeit hier einsehen; die Trade-In-Preise sind vom 6. September. Die Ergebnisse:

Ein Hardcover-Buch der Beststellerliste kostet rund 20€, der Wiederverkaufspreis liegt bei fast 9€. Das eBook dürfte dann nicht mehr als 11€ kosten, es ist mit durchschnittlich 16€ (Kindle-Preise bei Amazon) überteuert. Hardcover-Sachbücher sind gegenüber der Belletristik etwa 1€ günstiger.

Ein Paperback kostet im Schnitt 15€, es ist für knapp 7€ wieder verkaufbar. Die Belletristik ist nur geringfügig teurer als das Sachbuch. 8€ sollte das eBook höchstens kosten. Die Kindle-Ausgabe verlangt um die 12€. Das ist zuviel!

Für 10€ bekommt man Taschenbücher, die man wieder für knapp mehr als 3.50€ im Schnitt verkaufen kann. Ein eBook-Preis von etwa 6€ wäre demnach angemessen. Das eBook zum Belletristik-Taschenbuch ist mit ca. 9.50€ kaum günstiger als die Papierversion, das eBook zum Taschensachbuch kommt mit 7.50€ der Sache schon näher. Dennoch ist das eBook überteuert!

Ein eBook sollte also nur 11€, 8€ oder 6€ kosten -- je nachdem, ob das Gegenstück in Papier als Hardcover (20€), Paperback (15€) oder Taschenbuch (10€) erschienen ist. Die digitale und die Papierwelt stehen in einem kuriosen Bezug zueinander: Die ökonomisch vernünftigen Kosten des eBook-Preises sind relativ stabil gekoppelt an den Papierbuchpreis; ein angemessener Preis für das eBook liegt bei 60% der Papierfassung. Der Preis eines eBooks orientiert sich an Herstellungskosten für ein Buch, das digital nicht existiert?

Setzen wir dieser kuriosen Logik ein Ende: Für Bestsellerbücher der Kategorie Belletristik und Sachbuch ist nicht verargumentierbar, warum man die derzeitigen eBook-Preise zahlen sollte. Der Autor soll gut entlohnt sein, das Lektorat auch -- und Gewinn darf ein Verlag freilich auch machen. Aber ohne eine digitale Tausch-, Verleih- und Verkaufsbörse für eBooks wird sich kein ökonomisch nachvollziehbares Preisniveau für eBooks einstellen.

Es ist fast sicher, dass der eBook-Markt bei diesen unsinnigen Preisen die eine oder andere Wandlung erfahren wird. Man darf gespannt sein, was z.B. Sascha Lobo mit Sobooks im Schilde führt.





Dienstag, April 16, 2013

Freies Clojure-Buch: Funktionale Programmierung mit Clojure

Lisp und Scheme haben mich schon vor vielen Jahren fasziniert und begeistert. Kein Wunder, dass Clojure sich nicht viel Mühe geben musste, meine Sympathien für diese Sprache zu wecken. Und da ich Lust auf diese ungewöhnliche, funktionale Sprache wecken möchte, begann ich ein Manuskript zu schreiben, das Clojure-Neulingen einen leichten Einstieg bieten möchte.

Das Buch "Funktionale Programmierung mit Clojure" steht Ihnen zum Download zur Verfügung; es steht unter einer Creative Commons-Lizenz, und Sie dürfen es gerne weitergeben. In der nächsten Zeit werde ich das Buch samt LaTeX-Sourcen auf Github zur Verfügung stellen. Wenn Sie das Werk verbessern oder fortschreiben möchten, Sie sind herzlich dazu eingeladen. Auch Kommentare und Feedback sind natürlich gerne willkommen.

Viel Spaß beim Lesen!


Donnerstag, Februar 28, 2013

Die Vorlesung auf den Kopf gestellt: Die "Inverted Classroom Model"-Konferenz ICM 2013 in Marburg

Warum hält heutzutage noch ein Dozent bzw. eine Dozentin eine Vorlesung? Gemeint ist der "Lehrmonolog", in dem einer spricht und viele zuhören und sich das dialogische Moment des Austauschs auf ein Minimum beschränkt. Damit mich niemand falsch versteht: notwendig ist diese Lehrform unbedingt. Es gibt Dinge, die wollen gewusst und erklärt werden. Aber das Format des "Lehrmonologs" ist als Lernform zu wenig. Machen, tun, erfahren, begreifen, explorieren, hinterfragen, ausprobieren, experimentieren -- all das ist nötig, um zu lernen, um Neues beim Lernenden zu verankern. Und das braucht Zeit. Viel Zeit. Zeit, die man nicht hat, wenn man zu viele "Lehrmonologe" hält. Und Lernen braucht den Dialog, die Auseinandersetzung.

Warum also nicht den "Lehrmonolog" auslagern, als Video aufzeichnen, auf Youtube (oder woanders) hochladen und den Studierenden vor der "Vorlesung" zur Verfügung stellen? Genau das ist die Idee des Inverted Classroom Model (ICM), gerne auch Flipped Classroom Model oder Flip Teaching genannt. So kann die "Vorlesung" -- nun befreit vom zeitraubenden "Lehrmonolog" -- genutzt werden für die Aktivierung und die Gestaltung von Lernprozessen. Da der "Lernstoff" ja nicht von sich aus aktiv und dialogisch ist (zum Beispiel sind die Newton'schen Gesetze oder die Maxwell'schen Gleichungen erst einmal nur Formeln), ist nun die Zeit da, den "Lernstoff" in Formen zu gießen, die aktiven Umgang und dialogische Auseinandersetzung mit dem Stoff zulassen und fördern. Und dazu braucht es immer noch den Lehrer bzw. die Lehrerin (das Wort passt nun weit besser als Dozent/Dozentin), der dialogische Lernszenarien entwickelt aber auch als einspringt als Vermittler, wenn die dialogische Auseinandersetzung mit dem Lernstoff ins Stocken geraten ist. Dann besteht eine echte Chance, dass Lernen stattfindet.

Für diese Betrachtungen zur Lehre gab es wunderbare Anregungen auf der Konferenz zum Inverted Classroom Model (ICM 2013) in Marburg, die ich am 27. Feb. besucht habe. Jörn Loviscach, FH-Prof aus Bielefeld und unumstrittener ICM-Star mit seinen Lehrvideos auf Youtube, erläuterte, wie er Videos produziert und welche Erfahrungen er damit gemacht hat (Link zum Vortragsvideo). Brian E. Bennett, Schullehrer aus den USA, zeigte mit Bezug auf Dan Meyer sehr eindrucksvoll, wie man Lehrinhalte in hochgradig dialogische Formen bringen kann; teils lässt sich das sehr schön mit Videos oder Fotos machen, die aber alles andere als "Lehrmonologe" sind. Daniel Bernsen, Lehrer aus Koblenz, ergänzte das mit interessanten Erfahrungen aus dem Geschichtsunterricht.

Im Workshop mit Christian Spannagel (Prof an der PH Heidelberg) war sehr schön zu erfahren, mit welchen Werkzeugen ein "Methodenkoffer" zur Lehre gefüllt werden kann, wenn denn der Lehrinhalt zuvor per Video vermittelt wurde (Folien-Link). Beispiele sind Audience Response-Systeme, das "Listen, Think, Pair, Share"-Modell von Lyman und die Idee des "Aktiven Plenums". Sehr interessant war auch der Workshop zu Audience Respone-Systemen (ARS) von Leonie Wiemeyer und Andrea Röhr. Die Möglichkeiten der ARS sind ganz neue geworden, seitdem die Studierende Laptops, Tablets oder Smartphones in die Vorlesung mitbringen. Wer ein ARS ausprobieren möchte: ars.thm.de der Technischen Hochschule Mittelhessen.

Natürlich ist das ICM ein Baustein auf dem Weg zu anderen Lehrkonzepten, aber es ist keine Lösung für alles. Herr Loviscach lässt es an Deutlichkeit nicht Mangeln. Seit einigen Semestern straucheln seine Mathe-Studierenden bei einfachsten Grundlagen: es hapert schon bei der Bruchrechnung. Neu im vergangenen Semester sei die Unkenntnis von "Punkt- vor Strichrechnung". Er ist mit solchen Beobachtungen nicht allein, ich mache sie auch -- nur gesprochen wird darüber kaum. Was ist los mit unserem Bildungssystem in Deutschland?

Und wenn wir schon dabei sind: Warum müssen wir den Studierenden nun Videos präsentieren? Leistet das Lehrbuch oder das Manuskript zur Vorlesung nicht ebenfalls beste Dienste? Auch darauf antwortete Herr Loviscach einmal in einem gänzlich anderen Vortrag: Würde er auf das Lesen der Texte zur Vorbereitung bestehen, er würde noch mehr Studierende abhängen? Armes Deutschland: Hat der Verfall der Lesekultur begonnen?

Vielleicht. Vielleicht auch nicht. Ich glaube, den Streit um den Verfall der Lesekultur muss man an dieser Stelle nicht führen. Unbestreitbar ist der "Lehrmonolog" in Textform nicht zu verachten. Aber es gibt auch gute Gründe für das Video. Es ist, wie der Text, ein lineares Medium, dabei aber deutlich weniger geeignet für schnelles, ungenaues "drüberlesen" und bedient zwei Kanäle gleichzeitig: man höhrt zu, sieht Geschriebenes und Zeichnungen. Das bindet Aufmerksamkeit und Konzentration. Wenn man dann geschickt Pausen einbaut mit z.B. kurzen Testfragen, dann nutzt man eine "Lerndramaturgie", die dem Textmedium abgeht.

Das "Inverted Classroom Model" baut ein Spannungsfeld auf, das überdeutlich die Notwendigkeit von gut ausgebildeten Lehrenden einfordert: Die Wissensvermittlung per Video skaliert hin zu beliebig vielen Studierenden. Das ist "Massenlehre" genauso wie das Fernsehen oder Youtube Massenmedien sind. Praktisch, quadratisch, gut! Das Lernen selbst bleibt jedoch ein individueller Vorgang. Und noch sind wir in der Lehre meilenweit davon entfernt, gescripted (will sagen: automatisiert) Lernprozesse zu inszenieren, die massentauglich und individuell zugleich sind. Das ICM fordert noch mehr als zuvor nicht nur medien- sondern auch methoden-kompetente Lehrende ein.

Wobei wir bei einem weiteren Problem sind: Die Klausur als Messinstrument von Bildungsleistungen zeigt sich nur begrenzt kompatibel mit einem Lehrmodell, das die dialogische Auseinandersetzung mit Lernstoffen einfordert. Wenn es am Ende doch nur noch darum geht, stumpfe Rechenaufgaben zu lösen oder vorgefertigte Lösungstexte in einem geschickten Remix zu reproduzieren, dann bremst das erheblich die Motivation, sich als Student(in) auf aktivierende und zeitraubende "Lernspielchen" einzulassen. Prüfungs- und Lehr- und Lernformen müssen kohärent sein, aufeinander passen.

Zum Schluß der Konferenz fragte Jürgen Handke, Linguistik-Professor und Organisator der ICM 2013: Warum treiben Pädagogen Lehrmethoden wie das ICM und deren Verbreitung nicht voran? Und mich betrübt, als sich eine Lehramtstudentin zu Wort meldet und sagt: sie habe in ihren bisherigen vier Semestern eigentlich keine Pädagogik erlernt -- und Schule zeige sich sehr resistent gegenüber neuen Lehrformen; sie dürfe dort Experimente wie das ICM nicht ausprobieren.

Sehr gefreut an der Konferenz hat mich die offene Atmosphäre. So habe ich nicht nur nette Gespräche mit Matthias Uhl und Gesine Torkewitz geführt. Besonders gefreut hat mich auch der gemeinsame Abend mit Christian Spannagel im Cafe Barfuß. Wir haben lange über Consize und die Möglichkeit der Gamifizierung in der Informatik-Ausbildung gesprochen.

Donnerstag, Januar 17, 2013

Der 4HWW-Starprogrammierer

Der Bestseller "The 4-Hour Workweek" (4HWW) von Tim Ferriss (zu deutsch erhältlich unter dem Titel "Die 4-Stundenwoche") hat einen Trend der IT-Szene, das Outsourcing, aufgegriffen und zum persönlichen Lebensthema gemacht. Die Befreiung von einem festen Arbeitsort und festen Arbeitszeiten und die Delegation einfacher, fest umrissener oder klar definierter Aufgaben an persönliche Agenten aus Billiglohnländern, das scheint gerade Menschen mit Bezug zur IT-Szene anzuziehen. Denn in kaum einem anderen Bereich lässt sich diese Vision von einem frei bestimmten aber dennoch finanziell ertragreichen Leben so pointiert verkaufen. Die Idee von Tim Ferriss gipfelt darin, eine profitable und hochgradig selbstgesteuerte Geschäftsidee umzusetzen, die einen kontinuierlichen Einkommensstrom bei geringstem Betreuungsaufwand generiert; damit sind die im Buchtitel proklamierten 4 Stunden pro Woche gemeint.

Diese Vision hat offenbar viele Menschen fasziniert und zum Kauf des Buches animiert -- auch mich hat das Buch von Tim Ferriss in den Bann gezogen und vieles überdenken lassen. Alleine die Frage, wie man die eigene tägliche Arbeit so organisiert, dass sie fast beliebig skaliert, hat einen unternehmerischen Produktivansatz, der nicht zu verachten ist! Wo die -- um es betriebswirtschaftlich auszudrücken -- Wertschöpfungsketten im (Arbeits-)Leben liegen, wo man Prozesse einführen und delegieren kann, wie man mit Verantwortung und Entscheidungsfindung umgehen möchte, wie man ein Mehr bei gleichem Aufwand bewältigen kann, welche Vision einen umtreiben, was man eigentlich will -- all das sind Fragen, bei denen einen allein die Suche nach Antworten ungemein bereichern kann.

Doch es gibt auch Menschen, die mit der Idee der 4-Stunden-Arbeitswoche ernst machen. Dieser Tage geisterte ein Bericht von einem "Starprogrammierer" einer Firma durchs Netz, dessen Starkult auf den Leistungen eines Entwicklers aus China beruht. Er ließ sein Tagwerk in China erledigen und verbrachte seine Arbeitszeit mit ausgiebigen Streifzügen im World Wide Web.

A security audit of a US critical infrastructure company last year revealed that its star developer had outsourced his own job to a Chinese subcontractor and was spending all his work time playing around on the internet.

Der beschriebene Fall ist in "The Register" derart überzeichnet dargestellt (von dort stammt auch das Zitat, auch heise.de berichtet davon), dass ich mir nicht sicher bin, ob nicht gar die ursprüngliche Meldung von Verizon Fiktion und Non-Fiktion vermischt. Doch selbst wenn: Das Szenario ist mehr als denkbar, es ist gar nicht mal so unwahrscheinlich, dass irgendwo auf der Welt jemand genau das getan hat oder gerade tut.

Natürlich ist es ein Unding, dass jemand ohne das Einverständnis seiner Firma einen Subkontraktor mit der übertragenen Arbeit beauftragt. Es sollte allerdings einer Firma zu denken geben, dass ein Mitarbeiter offenbar durch eine deutlich billigere (und vermutlich qualifiziertere) Arbeitskraft ersetzt werden kann. Vielmehr noch: Der "Starprogrammierer" selbst hätte sein Arbeitsmodell auch als Geschäftsmodell realisieren können und sich damit nicht strafbar gemacht. War da jemand zu geldgierig?

Wenn Sie die Idee der 4-Stunden-Arbeitswoche fasziniert, dann machen Sie's richtig und nicht so stümperhaft wie unser Fallbeispiel mit anschließender "Dauerfreizeit" in der Haftanstalt. Ein Beispiel finden Sie in brand eins 08/2012: "Die Freigeister".


Montag, Dezember 17, 2012

Softwarebau und Storytelling

Wenn Software-Entwickler über Software reden, dann übertragen sie die Welt der Klassen, Objekte, der Methoden in die Welt der Geschichten. Wir Menschen können nicht anders. Wir erzählen Geschichten, wenn wir uns erklären, was diese Klasse oder jenes Framework tut. Wir betreiben Storytelling, um uns die formale Welt eines Rechners erklärbar und beschreibbar zu machen. Wir müssen es in den Worten unserer Welt tun.

Das Problem? Die Welt eines Rechners ist eine formale Welt, ähnlich der Mathematik. Die Welt des Storytellings, des Geschichtenerzählens könnte nicht gegensätzlicher sein: Geschichten müssen nicht logisch sein, sie müssen nicht einmal stimmig sein, solange sie unsere Phantasie nicht überstrapazieren. Praktisch jedes Buch und jeder Film ist ein Beleg dafür, wie sehr wir bereit sind, uns auf selbst abstruse Geschichten einzulassen.

Und so versagen wir oft kläglich, unsere Stories zurück zu übertragen auf die strenge Welt eines Rechners. Die Inkonsistenzen unserer Vorstellungen straft die Software mit Fehlermeldungen ab. Das ist der Urgrund dessen, warum das Testing so notwendig und dringende Pflicht ist: Es geht um den Abgleich unserer Stories mit dem, was eine Software wirklich macht. Das hat erst einmal nichts mit Qualitätssicherung zu tun. Warum wir uns trotzdem so schwer mit dem Testen tun, ist psychologisch einfach erklärt: Wir sind auf einen Erhalt unserer Selbstbilder und Vorstellungswelten aus. Wir sind Wesen, die nur bedingt auf Empirie setzen, denen aber die Bewahrung der lieb gewordenen Meinungen, Ansichten und Stories so viel wert ist, dass wir sie ungern erschüttern lassen.

Das Drama des Software Engineering spitzt sich noch um einen weiteren Aspekt zu: Zwar arbeitet ein Rechner nach formalen Prinzipien, aber das Prinzip basiert letztlich auf einem sehr einfachen Gesetz: Dem Gesetz des nächsten Befehls! Die nächste Anweisung im Rechner wird kommen. Und sie wird tun, was sie tun muss. Ob darüber hinaus das Tun des Rechners sinnhaft, schlüssig und logisch ist, ist nicht im geringsten gewährleistet.

Und so prallen zwei Welten aufeinander -- die Welt des Rechners als formale, die Welt des Menschen mit seinem Storytelling als informale --, die eines eint: beide Welten erlauben das absolute Chaos. Rechner müssen außer dem Gesetz des nächsten Befehls keine Physik und keine Logik beachten, keine Plausibilitäten und keine Konsistenzen -- genauso wenig wie jede Story.

Daraus gibt es einiges zu lernen:

Erstens: Software Entwickler müssen es lernen, ihre informelle Ausdrucksformen in eine formale Form zu bringen -- und sie sollten diese Übertragungen stets auf Fehlannahmen etc. hin testen. Dafür gilt es psychologische Barrieren zu durchbrechen.

Zweitens: Da weder die Software noch die Story konsistent, plausibel und logisch sein muss, tun sich Menschen einen Gefallen, die formale Welt im Rechner auch zur Konstruktion formal-logischer Welten zu nutzen, die mehr einfordern, als nur das Gesetz des nächsten Befehls. Das kann zum Beispiel in Grenzen geschehen durch domänenspezifische Sprachen (DSLs), Kernel-Ansätze und ein konsequentes Schichtenmodell, durch den Einsatz logischer Sprachen wie Prolog etc. Oder, und das ist ein großes, sehr großes Korrektiv, die Software interagiert mit der physikalischen Welt (wie embedded Systems) und muss die dort vorzufinden Gesetze und Eigenschaften strengstens berücksichtigen.

Erst wenn das gegeben ist, bauen wir Software von der Qualität mit der auch Ingenieure ihre Werke erschaffen: Ingenieure werden von den Gesetzen der Natur optimiert. Das Gesetz des nächsten Befehls allein optimiert nichts. Und unsere Stories auch nicht.

Montag, Dezember 10, 2012

Brauchbare Klassendiagramme

Mich überrascht immer wieder, wie sehr Klassendiagramme in einer undefinierten Grauzone schweben zwischen Modellbeschreibung einer Problemdomäne und Dokumentation der Implementierung. Das ist nicht nur ein "Problem" von Studierenden, sondern auch von Profis.

Ein Klassendiagramm kann zwei Zwecken dienen, die sich an zwei Fragen festmachen lassen:

Dient das Klassendiagramm zur Erfassung einer gedanklichen, logischen Zerlegung einer fachlichen Problemdomäne (Modellierung)? Oder dient es zur Dokumentation der Klassenbezüge im Code einer Implementierungssprache (Realisierung).

Meist "hängt" ein Klassendiagramm genau zwischen diesen Welten und ist am Ende weder ein ausdrucksstarkes Modell (da es Ausdrucksmittel der UML ungenutzt lässt), noch eine korrekte Beschreibung der Realisierung, die in aller Regel das Klassendiagramm nicht einmal sauber umsetzt.

Um es konkreter zu machen:

Oftmals wird in Klassendiagrammen keine Mehrfachvererbung verwendet, obwohl sie bisweilen sehr elegante Zerlegungen und Wiederverwendungen von Modellanteilen erlaubt. Warum? Weil die Implementierungssprache (z.B. Java, C#) Mehrfachvererbung nicht kennt. -- Das sollte zwar kein Grund sein, sich in den Ausdrucksmöglichkeiten zurück zu halten, ist es aber faktisch immer wieder! Interessanterweise eben genau bei dem Thema "Mehrfachvererbung".

Andererseits sehe ich sehr oft, wie die Komposition und bisweilen auch die Aggregation in Klassendiagrammen verwendet wird. Dabei bietet keine mir geläufige OO-Sprache ein Sprachkonstrukt für die Komposition/Aggregation an -- vom Hörensagen ist eventuell Eiffel die große Ausnahme. Merkwürdigerweise scheint das Fehlen von Komposition und Aggregation in der Zielsprache den wenigsten Modellierer(inne)n Sorgen zu machen, ganz im Gegensatz zur Mehrfachvererbung. Dabei habe ich -- und das ist das Kuriose daran -- (fast) noch nie Implementierungscode gesehen, der die Komposition oder Aggregation korrekt umsetzt. Die wenigsten Programmierer(innen) wissen, wie Komposition in Code geht, und auch die gängigen Modellierungswerkzeuge versagen mit ihren Code-Generatoren an dieser Stelle oftmals kläglich.

Damit sind Klassendiagramme merkwürdige Artefakte: Sie sind oft halbherzige Modellbeschreibungen mit einem sehr implementierungszentrischen Blick. Und gleichzeitig versagen sie als Dokumentation des Programmcodes, der die vom Klassendiagramm geforderten Strukturbeziehungen nicht wirklich einlöst.

Darum halte ich es für sinnvoll, sauber und klar in zwei Klassendiagrammen zu denken, die den Unterschied zwischen fachlichem Modell und Implementierungsdokumentation offen legen und bewusst machen, statt ein Klassendiagramm mit unklarem Bezug und fraglichem Nutzen zu erstellen. Da viele IDEs wie z.B. Eclipe immerhin einfache Klassendiagramme aus der Implementierung abzuleiten vermögen, sollte der Fokus auf zwei Punkten liegen:

  1. Gute Klassendiagramme zu entwerfen, die die Problemdomäne versuchen ausdrucksstark zu modellieren -- ohne auf die Implementierungssprache zu schielen.
  2. Zu dokumentieren, wie das Klassendiagramm in die Zielsprache übertragen wird, so dass deutlich ist, wo Programmierdisziplin mit Blick auf das Modell eingefordert werden muss, und wo der Programmcode das Modell sauber umsetzt.