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.


Donnerstag, Dezember 06, 2012

Denkspuren auf Google+ und Facebook

Seit wenigen Wochen gibt es mich auch unter Google+ und Facebook. Ich will verstehen lernen, wie sich die sozialen Medien anfühlen, ob sie für mich eine Bereicherung sind oder nicht, ob ich sie als wertschöpfend erlebe oder nicht. Tatsächlich hat mich der Vortrag von Lars Lehne motiviert, mich auf diese Welt einzulassen. Auch geht es mir darum mitzubekommen, was meine Studierenden mit diesen Welten verbinden.

Eines habe ich bislang festgestellt: Facebook scheint nichts für mich zu sein, ganz anders als für meine Studierenden. Vielleicht liegt es daran, dass ich nicht wirklich einen Bedarf habe, die Kontaktpflege mit "Freunden" über Facebook zu betreiben. Google+ hingegen spricht mich an. Das Format ist niederschwellig genug, so dass ich angefangen habe, öfter etwas zu posten. Und dass ich nicht gleich mit jedem Freund sein muss, sondern nur Kontakt-Kreise aufbaue, das scheint auch mehr zu mir zu passen.

Darum: Wenn Sie Lust haben, "besuchen" Sie mich auf Google+. Auf meiner Facebook-Seite passiert dagegen kaum etwas.


Sonntag, November 18, 2012

"if" in statisch und in dynamisch typisierten Sprachen


Ein "if" realisiert eine binäre Entscheidung. Bei statisch typisierten Sprachen wird abhängig von einem Booleschen Wert im "true"-Fall entweder das eine oder im "false"-Fall das andere gemacht. Auch wenn eine dynamisch typisierte Sprache die Booleschen Werte "true" und "false" kennt, ist das Verhalten für ein "if" meist anders definiert: Für jeden beliebigen Wert außer "false" tue dieses, für den Wert "false" jenes. Manchmal heißt es sogar: Für jeden Wert außer "false" und "nil" tue dieses, sonst jenes. Wissen Sie, warum statisch und dynamisch typisierte Sprachen sich so unterschiedlich verhalten?

Statisch typisierte Sprachen nutzen die Typüberprüfung vor der Ausführung des Codes, um festzustellen, ob die "if"-Entscheidung tatsächlich binär ist. Das ist durch den Booleschen Datentypen garantiert, wenn die Typüberprüfung erfolgreich ist.

Dynamisch typisierte Sprachen überprüfen die Typen zur Laufzeit. Wenn bei einem "if" kein Boolescher Datenwert genutzt wird, könnte eine Ausnahme (Exception) geworfen werden -- dann würde ein "if" jedoch eine ternäre und keine binäre Entscheidung mehr treffen: Mache dieses im "true"-Fall, jenes im "false"-Fall und was gänzlich anderes, wenn ein sonstiger Wert vorliegt. Um das binäre Entscheidungsverhalten aufrecht zu erhalten, muss man ein, zwei Werte wie ein logisches "false" und alle anderen Werte wie logisch "true" interpretieren.

Dass "nil" oft ebenfalls als "false" zählt, hat einen Grund: Vielfach hat "nil" bei dynamisch typisierten Sprachen die Sonderfunktion, "Nichts" als Wert zurückzugeben, wenn es keine andere Lösung gibt, statt einen Fehler per Exception zu werfen. Dynamisch typisierte Sprachen halten so die Ausführung eines Programms so lange wie möglich aufrecht, ohne durch Exceptions aus dem Ausführungsfluss geworfen zu werden.

Donnerstag, November 08, 2012

Google-Director Lars Lehne in Heilbronn


Eines ist Lars Lehne, Google Director bei Google Deutschland, wirklich gelungen. Sein Vortrag hat mich mitgerissen und begeistert. Dabei war es, wenn man ehrlich ist, eine einzige Werbeveranstaltung für Google. Aber das muss man Lehne wirklich lassen: Er ist sehr gut darin, sein Unternehmen "zu verkaufen". Nett, charmant und humorvoll ist er. Und er weiß, dass man ihm zuhört -- zuhören muss.

Warum der Vortrag "Die digitale Zukunft ist bereits Realität" heißt, bleibt bis zum Schluss ein ungelöstes Rätsel. Egal. Die Einladung von Lars Lehne ist Grund genug für deutlich über 200 Gäste, am Mittwoch, 6. November 2012, den Saal der IHK Heilbronn-Franken zu füllen. Lehne, übrigens FH-Absolvent -- er hat BWL in Düsseldorf studiert --, ist seit 2009 bei Google. Er startet seinen Rechner, alle sehen über die Projektionswand seinen Desktop ... ich bin verblüfft: Ist das wirklich wahr?

Der Google Director hat doch tatsächlich ein iBook mit Mac-OS laufen. Später wird er auf Nachfrage des Moderators das Publikum aufklären, dass viele Googler einen Apple-Rechner haben, aus Sicherheitsgründen. Apple-Rechner gelten bei Google als sicherer als Windows-Rechner. Sein Smartphone ist aber kein iPhone -- das wäre ein echter Skandal gewesen ;-) Sicher ist es ein Nexus, auf die Ferne ist es nicht klar zu erkennen.

Lehne hält dankenswerter Weise keinen Powerpoint-Vortrag. Er macht einen Streifzug durch die fast 15jährige Geschichte von Google, wobei er sich weitgehend auf die Google-Suche beschränkt. Und so füllt Lehne 60 Minuten lang den Abend mit kurzen Youtube-Videos und live durchgeführten Google-Suchen. Er erzählt viele nette Anekdoten, die das Publikum begierig aufsaugt. Das alles bringt Lehne so unaufgeregt rüber, dass es die Bedeutung von Google nur unterstreicht.

Ich möchte den Vortrag von Lehne nicht zusammenfassen, sondern mit ein paar Schlaglichtern ein wenig nachzeichnen, wovon er gesprochen hat.

  • Wussten Sie, dass Google rund 35.000 Angestellte (ohne Motorola) hat? Mehr als 50% sind Ingenieure. 3.000 bis 8.000 Menschen werden pro Jahr bei Google eingestellt, bei 2 Mio. Initiativbewerbungen. (Ich hoffe, ich habe mich nicht verhört, die Zahl ist so unglaublich.) Am aussichtsreichsten ist es, wenn Sie ein Googler (ein Google-Mitarbeiter) empfiehlt.
  • Larry Page und Sergey Brin (die Gründer von Google) sind hochintelligente Schnelldenker, so Lehne -- er habe des öfteren mit ihnen Kontakt. Das Credo von Page ist: "Jedes Problem kann mit Mathematik gelöst werden." Und er leistet sich einen "Streichelzoo" (so Lehne) von 50 Ingenieuren, die tun dürfen, was immer sie wollen.
  • "Jedes Problem kann mit Mathematik gelöst werden", so zitiert Lehne Larry Page. Was ist das für ein Geek! Und nun dürfte Ihnen auch klar sein, warum man sich besser um Mathematik kümmert -- auch wenn man "nur" Informatik studiert. Ohne Mathematik keine Algorithmen für die Indizierung und Suche von Webseiten, und ohne Mathematik kein autonom fahrendes Auto. 
  • Noch so eine Frage für Neugierige: Woher kommen die bunten Farben im Google-Logo? In den Anfangstagen haben sich die Googler die Racks für Ihre Server aus Legosteinen gebaut! Die bunten Farben sind eine Erinnerung an die Lego-Zeit!
  • Google verarbeitet jeden Tag 4 Milliarden Suchanfragen, Tendenz steigend. Deutschland ist daran mit 350 Millionen Anfragen beteiligt. Große Unternehmen haben Google schon dreistellige Millionenbeträge angeboten, um auf der "weißen" Seite mit der Suchmaske Werbung zu schalten. Google lehnt das ab.
  • Google verdient sein Geld mit den Clicks auf eingeblendete Anzeigen zur Suche. Verbleiben Sie mehr als 3 Sekunden auf der angebotenen Werbeseite, dann klingelt der Geldbeutel bei Google. Die Preise für einen Click reichen von 10 Cent bis 50-70€ (z.B. bei Versicherungen oder Winterreifen, wo eine sehr hohe Abschlusswahrscheinlichkeit für ein Geschäft besteht). In Deutschland verdient Google im Schnitt 12,7 Cent an Clicks auf Links von Werbeanzeigen. Lehne stellt die einfache Rechenaufgabe: Wenn es 1 Mio. solcher Clicks gibt bei 365 Tagen im Jahr, dann kommt da einiges zusammen. (Es sind übrigens etwas mehr als 46 Mio. Euro. Wenn dieser Wert für Deutschland gilt, dann sollte der weltweite Umsatz bei 500 Mio. Euro liegen. Das liegt weit unter den 9,7 Mrd. US-Dollar Reingewinn, die Google 2011 erzielt hat.)
  • "Suchanfragen sind komplex, Maschinen sind saudoof", so Lehne. Wenn er von komplexen Suchanfragen spricht, meint er aber auch die saudoofen Anfragen, die Google verstehen muss und will. Google erkennt 860 falsche Schreibweisen des Namens "Britney Spears"! Das Schlagwort, das Lehne mehrfach erwähnt, lautet "Datenaggregation". Google muss die Suche und die tatsächlich angeklickten Seiten zusammenführen, um herauszufinden, was der Nutzer will. Wenn ein Nutzer das Wetter abfragt, dann will er in 99,99% der Fälle das Wetter an seinem Standort erfahren. Auch hier aggregiert Google Daten, um Ihnen das vermutlich gewünschte Ergebnis zu liefern.
  • "Youtube ist die zweitgrößte Suchmaschine der Welt." Von diesem Blickwinkel aus, sagt Lehne, war die Aquisition von Youtube für Google nur folgerichtig. Gleichzeitig sei Youtube auch ein soziales Netz
  • Lehne: "Brauchen wir ein zweites Facebook? Nein! Das wollen wir auch gar nicht sein." Für Google hat Google+ (kurz G+) eine ganz andere Bedeutung: Das soziale Miteinander, die "Freunde" und der (mit)geteilte Inhalt gehen in die Suche mit ein und sollen helfen, die Suchergebnisse zu verbessern. Google geht davon aus, dass unser soziales Treiben in G+ eine Relevanz hat bei dem, was wir suchen. So werden Inhalte aus unserem sozialen Netzwerk mit durchsucht und angezeigt. Die Logik scheint mir nachvollziehbar: Facebook hat eine Wand im Internet aufgezogen, Facebookler(innen) bleiben unter sich. Alles außerhalb dieser Wand, will Google auffindbar machen und dabei die sozialen Aspekte berücksichtigen. Übrigens: Laut Lehne wird Google niemals Werbung in G+ schalten!
  • Warum heißt Google eigentlich "Google"? Der Name kommt von "googol", was eine riesengroße Zahl bezeichnet: 1E100 (einmal Zehn hoch Hundert, sprich, eine Eins mit 100 Nullen). Eine Anspielung auf die unglaublichen Datenmengen, die Google verarbeitet. Das muss den Gründern Page und Brin schon vor rund 15 Jahren bewusst gewesen sein.
  • Für Google hat die Sprachübersetzung eine immense Bedeutung: Was, wenn die Antwort meiner Frage in einer Fremdsprache vorliegt? Google vermag Webseiten sofort zu übersetzen, fast in Echtzeit. Lehne betont es immer wieder an dem Abend: Alles werde getan, um den Endbenutzern bessere Suchergebnisse zu liefern. Eine Strategie dahin ist, den Suchraum auf fremdsprachliche Webseiten zu erweitern.
  • "Wir wollen Fragen beantworten bevor sie gestellt werden." Das hat, laut Lehne, Larry Page gesagt. Was ist damit gemeint? Herr Lehne bringt ein Beispiel: In seinem Google-Kalender ist der Rückflug eingetragen samt Flughafen und Flugnummer. Nun kann Google die Daten aggregieren und eine Frage beantworten, die noch nicht gestellt ist: Google weiß dank GPS, wo man ist, aus dem Kalender wo man wann sein möchte und wann der Flug geht (da im Netz nachgeschaut). Daraus ergeben sich Fragen wie: Wie ist die Verkehrslage, um zum Flughafen zu kommen? Wie ist die Route? Geht mein Flieger pünktlich oder hat er eine Verspätung? All das nimmt Google vorweg und erinnert den Nutzer rechtzeitig: "Pass auf, Du solltest Dich innerhalb der nächsten 15 Minuten ins Auto setzen, die Verkehrslage ist kritisch. Anbei die Route samt Umleitung, der Stau kann umfahren werden. Dein Flieger geht 10 Minuten später als geplant." Das ist die Antwort auf eine Frage, bevor der Anwender sie stellt.

Interessant, nicht wahr?! Die anschließende Podiumsdiskussion war ebenfalls sehr erhellend. Ein Beitrag von Lehne aus der Diskussion: Social Media funktioniert nicht in hierarchisch geführten Unternehmen. "Soziale Führung" verlangt und fordert Transparenz ein. -- Die junge Generation wird das einfordern, so ergänzen auch die anderen Teilnehmer der Runde, da sie nicht verstehen und einsehen werden, warum Social Media innerhalb der Mauern eines Unternehmens tabu ist. Es wird die Unternehmen und die Führungsstile verändern.