…und plötzlich sind Herbstferien!

Wow, gerade eben war doch noch Juli, zumindest hier im Blog. Und auf einmal… Herbstferien. Ohne ein Lebenszeichen von mir bislang im Schuljahr 2013/14. Was ist los? Woran liegt’s?

Ich bin jetzt ein richtiger Lehrer in seinem ersten richtigen Jahr mit richtig viel Unterricht — daran liegt’s wohl.

Was ich gerade erlebe, müssen wohl alle Lehrer am Anfang durchstehen: Jedes Fach, jede Klasse, jede Stunde ist neu.  In den Stoff muss man sich erst einarbeiten*. Aus der Schublade holen kann man auch noch nichts.  Selbst, wenn man sich von den Kollegen Materialien besorgt, muss man diese sichten, überlegen ob und, wenn ja, wie man sie einsetzen könnte.  Oft genug merkt man erst spät, dass etwas vielleicht für den Kollegen passen mag, aber für einen selbst? Irgendwie doch nicht.

Und so steht vor jeder zu haltenden Stunde die Frage: Versuche ich, „nachhaltig“ vorzubereiten – damit ich eben beim nächsten Mal etwas in der Schublade habe, auf dem ich aufbauen kann? Oder improvisiere ich mich irgendwie durch?

Improvisieren kann ich eigentlich ziemlich gut — wenn ich weiß,

  • wovon ich rede,
  • was ich zu tun habe,
  • wer mein Gegenüber ist.

Momentan sind diese Voraussetzungen leider oft noch nicht gegeben. Vor allem der letzte Punkt ist entscheidend: Mir fehlt oft noch die Intuition dafür, was Schüler wissen (bzw. nicht wissen), können (bzw. nicht können), nachvollziehen (bzw. nicht nachvollziehen) können, d.h. letztlich, was sie von mir brauchen und was nicht. Diesen Mangel an Intuition kann ich im Augenblick nur versuchen durch Vorbereitung wenigstens teilweise zu kompensieren: Wenn ich beim Durchdenken einer Stunde, eines Themas, auf die potentiellen Stolpersteine stoße, kann ich noch eine vorbereitende Aufgabe vorschalten, eine erklärendes Beispiel suchen, eine Warnung geben. Entdecke ich die Stolpersteine erst während des Unterrichts, lerne ich einiges (z.B. hoffentlich die Stolpersteine beim nächsten Mal zu vermeiden), aber meine Schüler habe ich überfordert, frustriert und verwirrt.

(Ich rede hier nicht davon, Inhalte weichzuspülen und den Schülern die Herausforderungen zu nehmen. Ich rede einfach davon, ihnen nicht mit konfusem Unterricht unnötige Hürden in den Weg zu legen.  Mathe und Informatik in der Oberstufe — und nur das unterrichte ich im Augenblick — ist für sie anspruchsvoll genug, auch ohne einen Anfänger an der Tafel.)

Damit ich also irgendwann an den Punkt kommen kann, wirklich flexibel zu sein, reagieren und improvisieren zu können, versuche ich jetzt eben so nachhaltig wie möglich arbeiten.Und so verlasse ich den Schreibtisch nur selten vor Mitternacht**. Aber trotz der späten Uhrzeit gehe ich meistens zufrieden ins Bett — und das zeigt mir, dass der Wechsel an die Schule richtig war.

 

* Für uns Seiteneinsteiger gilt das sicher in besonderem Maße. Ich habe mich in den fast 20 Jahren seit meinem eigenen Abi natürlich sehr viel mit Informatik und Mathe beschäftigt, aber eben nicht auf Schulniveau. Das ist bei der Vorbereitung natürlich ein Nachteil. Aber ganz oft bringt es mir auch Glaubwürdigkeitspunkte im Unterricht, wenn ich den Schülern anschaulich machen kann, dass man Ableiten und Integrieren, Vererbung und Polymorphie sehr gut brauchen kann, wenn man mal einen intelligenten Roboter bauen will!

** Das hat aber auch ganz viel damit zu tun, dass ich privat in einer Lebensphase bin, die sich (um es mal vorsichtig zu formulieren) mit einer kompletten beruflichen Neuorientierung nicht so richtig gut verträgt. Drei kleine Kinder im Haus und nur zwei Erwachsene — da kann sich nicht einer von beiden einfach zwischen, sagen wir, 17 Uhr und 20:30 Uhr aus dem Abendprogramm ausklinken. Wenn derjenige aber oft erst um 16 Uhr aus der Schule kommt, muss er wohl oder übel am Abend noch mal an den Schreibtisch.

Advertisements

Mehr Expressivität wagen

(Dieser Post schließt sich an den letzten zum Thema Snap! an.)qs

In der funktionalen Programmiersprache Haskell gibt es eine berühmte Implementierung des Quicksort-Algorithmus, die nur zwei (!) Zeilen lang ist. Wem Haskell zu exotisch ist, der kann die Idee z. B. in Python so umsetzen:

def qsort(list):
  if not list:
    return []
  else:
    pivot = list[0]
    less = [x for x in list[1:] if x < pivot]
    more = [x for x in list[1:] if x >= pivot]
    return qsort(less) + [pivot] + qsort(more)

In der Nacht vor dem Workshop in München fiel mir ein, dass man diese Implementierung fast direkt nach Snap! übertragen kann, nämlich so:qsHier kann ich leider nicht die schönen list comprehensions aus Haskell oder Python verwenden, sondern nutze die klassische higher-order Funktion filter (in Snap! heißt sie keep items such that). Filter wird mit einer Liste und einem Prädikat (= Funktion, die einen Wahrheitswert berechnet) als Argumenten aufgerufen und liefert eine neue Liste zurück, die nur diejenigen Werte enthält, für die das Prädikat wahr wird — es werden also nur diejenigen Listenelemente „gefiltert“, die eine Bedigung erfüllen. In unserem Fall ist die Bedingung bzw. das Prädikat ein kurzer Lambda-Ausdruck, der prüft, ob das jeweils an die Leerstelle* im grau umrandeten Puzzleteil eingesetzte Element der Liste kleiner als das Pivot-Element ist.

Mir ist schon klar, dass jemand, der sich noch nie mit funktionaler Programmierung beschäftigt hat, das nicht unbedingt sofort intuitiv finden wird — auch mir gefällt gerade deshalb die Python-Version noch besser, weil sie so nahe an der vertrauten mathematischen Mengennotation ist. Aber dass es sich auch beim Snap!-Code um eine ganz direkte Umsetzung des oben umgangssprachlich beschriebenen Prinzips handelt, sollte offensichtlich sein.

Wie wäre es in Java? Natürlich ebenso möglich, aber viel, viel umständlicher. Es fehlen einfach die mächtigeren Werkzeuge zur Manipulation von Listen. Dadurch wird die Umsetzung von Quicksort in Java zwangsweise auf einem wesentlich niedrigeren Abstraktionsniveau stattfinden müssen als in Haskell, Python und Snap!, wo die fünf Schritte des umgangssprachlichen Algorithmus direkt in Code übertragen werden können. Ich glaube, dass es für Schüler schon schwer genug ist, die Grundidee von Quicksort zu verstehen. Ihn bei der Umsetzung in ein Programm dann auch noch sofort „herunterbrechen“ zu müssen auf explizite Schleifen und Anweisungen zum Erstellen und Verändern von Listen, das kommt mir noch viel schwerer vor.

„Stopp mal!“ wird jetzt vielleicht mancher rufen. „Der Algorithmus, so wie du ihn präsentiert hast, ist aber furchtbar ineffizient. Die Liste wird da unnötigerweise zweimal durchlaufen (in beiden Aufrufen von keep items such that). Ich mache das alles in einer Schleife; geht viel schneller.“

Wer das ruft, hat sachlich recht — liegt aber meiner Meinung nach pädagogisch falsch. Schüler müssen zuerst sehen, wie ein Verfahren überhaupt in Code umgesetzt werden kann, und das möglichst high-level. Dann und erst dann sollen sie sich über die Effizienz Gedanken machen. Idealerweise führt die Suche nach einer effizienteren auch zu einer eleganteren Lösung. In Python z.B. sähe die erste Fassung mit nur einem Listendurchlauf vielleicht so aus:

def qsort(L):
  if not L:
    return []
  pivot = L[0]
  less, more = [], []
  for x in L[1:]:
    if x < pivot:
      less.append(x)
    else:
      more.append(x)
  return qsort(less) + [pivot] + qsort(more)

Die Liste wird also nun mittels einer Schleife in zwei neue Listen partitioniert. Aber der Code ist (finde ich) viel schwerer verständlich geworden. Und ist es für den Algorithmus denn wichtig, auf welche Weise die Partitionierung durchgeführt wird? Natürlich nicht! Verstecken wir die Details also in einer Funktion:

def partition(L, pivot):
    less, more = [], []
    for x in L:
        if x < pivot:
            less.append(x)
        else:
            more.append(x)
    return less, more

def qsort(L):
    if not L:
        return []
    pivot = L[0]
    less, more = partition(L[1:], pivot)
    return qsort(less) + [pivot] + qsort(more)

So, jetzt sieht qsort richtig aufgeräumt aus; sogar kürzer als die ursprüngliche Fassung mit den zwei list comprehensions.  Die spezielle Aufgabe der Partitionierung wurde schön isoliert und in eine eigene Funktion partition ausgelagert. Und wenn man sich das so ansieht, kommt plötzlich eine entscheidende Erkenntnis: So etwas wie partition kann man eigentlich öfter brauchen, z.B. wenn man gerade und ungerade Zahlen von einander trennen will oder Worte, die mit Großbuchstaben beginnen, von denen, die es nicht tun, oder Datensätze von weiblichen und männlichen Mitarbeitern. Man könnte dafür eine Reihe von Funktionen schreiben, die jedesmal eine gegebene Liste in zwei neue aufteilt. Diese Funktionen glichen sich komplett — nur der Test zur Entscheidung, wohin ein Listenelement sortiert wird, wäre immer ein anderer.

„Lauter Funktionen, die fast gleich sind… Kann man da nicht etwas zusammenfassen?“ fragt sich da vielleicht der eine oder andere aufgeweckte Oberstufenschüler, der Ähnliches schon bei der Einführung von Funktionen, deren Parametrisierung, der Vererbung, womöglich dem einen oder anderen Design Pattern oder allgemein dem DRY-Prinzip gesehen hat. Und wir antworten: „Aber ja doch — Higher-order functions to the rescue!“

def partition(L, fn):
    falses, trues = [], []
    for x in L:
        if fn(x):
            falses.append(x)
        else:
            trues.append(x)
    return falses, trues

def qsort(L):
    if not L:
        return []
    pivot = L[0]
    def ist_kleiner(x):
        return x < pivot
    less, more = partition(L[1:], ist_kleiner)
    return qsort(less) + [pivot] + qsort(more)

Hier gibt’s nun natürlich einiges zu sehen: Funktionen als Parameter von Funktionen (hier: fn).  Eine Funktion (ist_kleiner), die innerhalb einer anderen Funktion (qsort) definiert wird und dabei Bezug nimmt auf eine Variable außerhalb ihrer eigenen Definition (pivot).*** Trotzdem: Ich glaube, wenn man — anders als wir mit C, Pascal, Java groß Gewordenen — noch gar nicht verinnerlicht hat, dass Funktionen keine Variablenwerte sein dürfen, tut man sich damit gar nicht so schwer.

Diese Version des Algorithmus gefällt mir nun sehr gut: Wir haben einerseits die Effizienz eines einzigen Listendurchlaufs pro Rekursionsionschritt, andererseits haben wir eine neue, vielseitig einsetzbare Funktion partition und wieder eine kurze, knackige Funktion qsort, die nur das enthält, was wirklich nötig ist.

Noch kürzer-knackiger, aber unnötig verwirrend für Schüler wäre qsort mit einem Lambda-Ausdruck, d.h. einer Funktion, die so klein und unwichtig ist, dass sie nicht einmal einen Namen bekommt:

def partition(L, fn):
    falses, trues = [], []
    for x in L:
        if fn(x):
            falses.append(x)
        else:
            trues.append(x)
    return falses, trues

def qsort(L):
    if not L:
        return []
    pivot = L[0]
    less, more = partition(L[1:], lambda x: x < pivot)
    return qsort(less) + [pivot] + qsort(more)

Egal in welcher Version, wir haben nun ein Programm, dass nicht nur effizienter ist als das Ursprüngliche, sondern auch modularer, flexibler, allgemeiner****.  Wenn man dahin kommen könnte, dass Schüler verstehen, warum so etwas gut und erstrebenswert ist…

Nur der Vollständigkeit halber kommt jetzt noch eine eher funktionale Version von partition, ohne Schleife, dafür mit Rekursion.  Kann man so machen, muss man aber überhaupt nicht. Lehrreich — und irgendwie schön — ist diese Version aber vielleicht doch.

def partition(L, fn):
    if not L:
        return [], []
    first, rest = L[0], L[1:]
    falses, trues = partition(rest, fn)
    if fn(first):
        return [first] + falses, trues
    else:
        return falses, [first] + trues

Nun aber zum Titel dieses Artikels: Ich weiß, dass Kollegen, die das Glück haben, einen vierstündigen Informatikkurs in der Oberstufe anbieten zu können, durchaus auf diesem Niveau unterrichten — auch in Java. Ich bin in einer anderen Situation: Meine Oberstufenschüler haben in ihrer gesamten Schulkarriere nur zweimal ein halbes Schuljahr zwei Wochenstunden lang Gelegenheit zu erfahren, was Programmieren überhaupt ist. Das macht insgesamt 80 Schulstunden in ihren letzten beiden Schuljahren, in einem Fach, das für diese Schüler im Abitur minimale Relevanz hat. Für mich ist also jede Minute kostbar, in der ich diesen Schülern ein bisschen das informatische, problemlösende, abstrahierende Denken vermitteln kann.  Jedesmal, wenn ich erklären muss, was void oder static oder public oder float oder int bedeutet (oder den Schülern vermittle, dass sie das zwar dauernd tippen, aber sowieso nicht verstehen müssen/können), verlieren ich und die Schüler Zeit, die sie damit verbringen könnten, an der Lösung eines Problems zu knobeln. Bei so wenig Zeit wünsche ich mir, eine Sprache benutzen zu können, die maximal anfängerfreundlich ist (so wenig und so intuitive Syntax wie möglich) und gleichzeit so ausdrucksstark, dass sie die Schüler nicht beim Denken behindert!

Ich bin ich mir noch nicht sicher, ob Snap! diese Sprache ist. Andererseits: Was für die Studenten der UC Berkeley hervorragend funktioniert, sollte eigentlich auch für deutsche Schüler gut genug sein, oder?

P.S. Warum habe ich eigentlich in meinem Snap!-Quicksort das Pivot-Element zufällig ausgewählt? Wer das weiß, bekommt nen Ball!

P.P.S. Man kann ja in Snap! eigene Kontrollstrukturen programmieren (s. Bild im letzten Post).  Wenn das geht, dann kann man sich doch sicher auch eigene list comprehensions bauen. Vorschläge, anybody?

** Ist diese Leerstelle nicht visuell wunderbar anschaulich dafür, dass dieser Block noch nicht ausgeführt werden kann, weil ihr das Entscheidende, ein Argument, noch fehlt?

*** Übrigens will ich hier gar nicht so tun, als könnte man Ähnliches nicht auch in Java tun.  „Anonyme innere Klassen“ heißt hier das Stichwort. Als ich die vor über 10 Jahren kennenlernte und verstand, was ich in Java damit anfangen kann, war ich sowas von begeistert — und bin tatsächlich, glaube ich, dadurch ein besserer Programmierer geworden. Heute kenne ich aber auch ein paar Sprachen, in denen die zugrundeliegende Idee (closures) so viel einfacher umgesetzt werden kann (z.B. in unserem Python-Beispiel die Funktion ist_kleiner) als in Java.

**** Eigentlich sollte man sollte man qsort nun aber noch mit der Vergleichsfunktion parametrisieren, so dass man z.B. mit qsort(L, ist_groesser) absteigend sortieren könnte.  Aber das überlasse ich als Hausaufgabe euch Lesern.

Snap!

Letzte Vorletzte Woche Vor drei Wochen habe ich in München einen Workshop zur graphischen Programmiersprache Snap! gehalten, beim Tag der Informatiklehrerinnen und Lehrer, organisiert u.a. vom geschätzten Kollegen Herrn Rau.

„In zwei Stunden von der Grundschule ins Informatikstudium“ war das Motto, d.h. es ging mir darum, den Teilnehmern in kurzer Zeit einen Einblick über die das breite Spektrum von Themen zu geben, die man mit Snap! abdecken kann — angefangen mit dem Zeichnen einfacher geometrischer Figuren (à la LOGO und Scratch) bis hin zu Lambda-Ausdrücken und dem Programmieren eigener Kontrollstrukturen*.  indexIch bin v. a. deshalb von Snap! so angetan, weil man auch komplexe Konzepte wie Rekursion oder first-class Funktionen ganz ohne Syntaxbarriere vermitteln kann.

Wer schon einmal mit Scratch gearbeitet hat, weiß, wie sehr das „Zusammenpuzzeln“ von Programmen die Schüler zum schnellen Experimentieren einlädt. Snap! geht in dieser Hinsicht nochmal einen kleinen Schritt weiter, denn um losprogrammieren zu können, muss nun nicht einmal mehr eine Software installiert werden:   Snap! läuft komplett im Browser, d.h. man braucht als Benutzer nichts zu installieren, sondern geht einfach auf http://snap.berkeley.edu/snapsource/snap.html (oder sucht im Web nach „run snap“) und legt los.

Selber loslegen sollten auch die Teilnehmer des Workshops; deswegen habe ich versucht, ihn so interaktiv wie möglich zu gestalten.  Das kann ich in einem Blogartikel so natürlich nicht machen.  Ich habe aber hinterher meine Präsentation so überarbeitet, dass sie — hoffentlich — auch für sich allein einigermaßen lesbar ist.  V.a. enthält sie nun ganz viele Links zu meinen Beispielprogrammen in der Snap!-Cloud. Einfach einen Programmlink anklicken, Programm ausprobieren und dann das Symbol mit den beiden Pfeilen drücken, um den Source-Code anschauen.

Zur Präsentation

Zum Beispiel findet ihr dort diesen hübschen Baum und diese Animation (bitte Maus im Fenster bewegen). Und noch vieles mehr… also viel Spaß bei Lesen und Mitprogrammieren!

In der Nacht vor dem Workshop fiel mir noch ein schönes Beispiel ein… was dazu führte, dass ich mich um 2 Uhr früh in München nochmal an einen fremden Rechner gesetzt und programmiert habe. (Dabei war es natürlich ganz großartig, dass ich weder die Software noch meinen eigenen Code auf dem Laptop oder einem Stick dabeihaben musste.) Was mir da einfiel, war der Quicksort-Algorithmus, das klassische Beispiel für ein Divide-and-Conquer-Verfahren.**

qs

Wer mag, darf sich als Hausaufgabe gern selbst an der Umsetzung in Snap! oder der Programmiersprache seiner Wahl versuchen.  Eine (erste) Snap!-Lösung findet ihr in der Präsentation.  Ich werde das Quicksort-Beispiel noch sehr ausführlich in einem weiteren Artikel diskutieren, in dem es um die Expressivität von Programmiersprachen für die Schule geht.

Für heute soll’s hiermit aber gut sein! Ich weiß selbst noch überhaupt nicht, ob und wie ich Snap! weiter einsetzen werde.  Vieles daran ist orthogonal zu den Lehrplänen, nach denen ich unterrichten werde, und vielleicht auch manchmal zu dem, was Schüler und spätere Arbeitgeber von Informatikunterricht erwarten.

Was denkt ihr? Wie findet ihr Snap!? Würdet ihr es im Unterricht einsetzen?*** Ich freue mich sehr über (positive wie kritische) Rückmeldungen zu Snap!, dem Workshop und den Materialien.

* Versucht das mal in Java!

** Wir haben das damals noch im Grundkurs Informatik, Klasse 13, nach 2 Jahren Informatikunterricht gelernt. Kommt mir heute durchaus anspruchsvoll vor. Und ist natürlich auch so gar nicht objektorientiert…

*** Das Thema „Snap! und Objektorientierung“ haben wir im Workshop diskutiert. Hier nur ganz kurz: In der aktuellen Version von Snap! kann man durchaus objektorientiert programmieren, es ist aber alles andere als natürlich im Vergleich zu Sprachen, die explizit für OOP entworfen wurden.  Dass es überhaupt geht, ist ein Beweis für die Ausdrucksstärke der Sprache (Zitat aus dem Reference Manual: „Snap! is Scheme disguised as Scratch“).  Ich kann überhaupt die Lektüre dieses Manuals nur empfehlen.  Ihr werdet mit den Ohren schlackern!

Vi Hart: Twelve Tones

Oh, the awesomeness:

(Unbedingt bis zum Ende ansehen!)

Ich behaupte ja immer, ich sei kein Nerd/Geek.  Aber dieses Video ist so eindeutig Teil einer bestimmten Kultur und gleichzeitig für mich so großartig, dass ich wohl doch einer sein muss.

Wie viel Arbeit und Liebe in die Entstehung des Videos geflossen ist, kann man hier nachlesen.

Goldene Zeiten, in denen Menschen so etwas produzieren und allen anderen zugänglich machen, einfach so!

Nachtrag: Salon.com schreibt zurecht: „30 minutes might seem like an eon in Internet time, but I’ve watched it twice in the last twelve hours and I don’t regret a second. ‚Twelve Tones‘ is the most deliriously and delightfully profound thing you can find on YouTube, until the next amazing video from Vi Hart comes along.“

Jenes und dieses

Bevor ich hier gar nichts mehr schreibe, schreibe ich lieber wenigstens ganz kurz mal auf, warum ich hier gar nichts mehr schreibe:

1. Dem Baby geht’s gut, danke der Nachfrage. Es benimmt sich so, wie es sich für ein drittes Kind gehört, d.h. es gewöhnt sich schnell an den konstant hohen Gesangs- und sonstigen Lärmpegel hier.  Gerne (v.a. nachts) leistet es auch schon seinen Beitrag dazu.

2. Ich habe korrigiert und korrigiert und korrigiert.  Insb. über 50 Zweitkorrekturen bei Prüfungsarbeiten aus einer über dreistündigen Mathe-Klausur.  Kein Abi, aber Fachhochschulreife. Ich bin nicht sicher, ob Abi noch mehr Aufwand ist — ich werde es in den nächsten Jahren sicher herausfinden.  Ich habe ungefähr 30 Zeitstunden in diese Zweitkorrekturen investiert.  Wie lange ich für die Erstkorrektur gebraucht hätte, mag mir gar nicht ausmalen.
Dafür weiß ich jetzt recht gut, wohin ich meine Schüler im nächsten Schuljahr bringen muss. Auf in den Kampf, Torero!

3. Wir Referendare haben, seit unsere Lehrproben und Prüfungen rum sind, an der Schule relativ viel Ruhe.  Deshalb sind wir die natürlichen Kandidaten für Abi-Aufsichten und das Führen des Protokolls bei mündlichen Prüfungen.  Nächste Woche z.B. habe ich zwar statt meiner normalen 12 nur 8 Stunden Unterricht, bin zum Ausgleich aber 10 Stunden Protokollant!  Ich würde lieber unterrichten, hänge nämlich in zwei Klassen ganz schön hinterher.  Aber das, scheint mir, ist das Los des Lehrers: Fürs Kerngeschäft zu wenig Zeit, dafür ganz viel nerviger anderer Kram!

4. Um hier nicht nur rumzujammern, auch mal etwas durchweg Positives: Es hat geklappt! Ich darf nächstes Jahr einen wöchentlichen Kurs für „besonders befähigte“ Schüler anbieten, die aus dem ganzen Landkreis kommen.  „Programmieren kreativ“ hab ich den Kurs mal genannt — und freue mich natürlich wie wahnsinnig darauf!  Es gibt an diesem sogenannten „Seminar“ Kurse in Mathe, verschiedenen Naturwissenschaften und eben Informatik* — die seien sogar besonders beliebt**, sagt man mir, so dass dieses Jahr gleich drei davon angeboten werden.  Ich habe — schluck — gleich den für „fortgeschrittene Oberstufenschüler“ bekommen, d.h. ich muss denen richtig Futter geben.  Sehr spannend, sehr herausfordernd.

5. Die Lehrerband.  Der große Auftritt beim Schuljahresabschlusshock rückt näher.  Die letzten vier Auftritte (Sommerfest 2012, Schulweihnachtsfeier 2012, Lehrerweihnachtsfeier 2012, Rock am Ring 2013) haben wir dermaßen gerockt, dass die Erwartungshaltung im Kollegium — insb. beim OStD — ins Unermessliche gestiegen ist. Werden wir das noch toppen können? Ich behaupte bescheiden: Ja!

Speaking of which…

6. Meine Serie „Musik mit Embee“ wird natürlich fortgesetzt, versprochen.  Ich habe ganz viel schönen Code schon lange fertig. Musikbeispiele von Bach bis Beatles sind bereits ausgewählt.  Aber: Ich muss den Code noch didaktisch reduzieren und pädagogisch sinnvoll organisieren, die Tonbeispiele präparieren und das Ganze am Schluss anschaulich präsentieren. Sowas braucht Zeit.  Und die fehlt mir gerade etwas, nicht nur wegen Punkt 1-3, sondern weil ich an den letzten Wochenenden des Schuljahres ständig unterwegs sein werden.  Z.B.:

7. Ende nächster Woche besuche ich Herrn Rau! Ja, da staunt ihr. Ich fahre zum Tag der Informatik-Lehrerinnen und -Lehrer, den er organisiert, nach München und halte da einen Workshop zu Snap! Auch das wird spannend und herausfordernd für mich; für die Teilnehmer hoffentlich eher anregend und kurzweilig.  Ach was, für mich wird es anregend und kurzweilig!
Vielleicht treffe ich ja den einen oder anderen hier Mitlesenden dort. (Ingo?)

Damit lasse ich’s für heute mal gut sein. Mehr als 7 Sachen kann sich sowieso keiner merken.  Nicht, dass ihr am Ende wieder vergessen habt, was #1 war. (Tipp: Es ist klein, soooo süß und schläft jetzt endlich.)

* Wo sind bei sowas eigentlich die Geisteswissenschaften? Ich höre von Freunden immer mal wieder von beeindruckenden SchülerInnen, die auf höchstem Niveau über Shakespeare-Sonette diskutieren.  Wo gehen die dann hin? Trotzdem in das Chemie-Begabtenseminar?

** Wenn ich das höre, könnte ich natürlich gleich wieder anfangen, über den Zustand der Schulinformatik in BW zu lamentieren.  Oder soll ich mich freuen? Offensichtlich gelingt es immer noch jungen Leuten, sich für Informatik zu interessieren, obwohl das Fach am Gymnasium ein Schattendasein fristet und wohl auch weiterhin tun wird.  Aber das dürfen heute mal andere bedauern, wenn die Interessierten dann bei mir im Kurs landen 😉  (Wahrscheinlich jammere ich dann aber doch wieder, wenn ich sehe, dass der Kurs zum 100% aus jungen Männern besteht.  Ich wollte doch immer die Mädchen für das Fach begeistern… Ob ich das erleben darf?)

3 Prüfungen und ein Baby

…und alles innerhalb der letzten sechs Tage.  Ich finde, die Bezeichnung „ereignissreiche Woche“ ist durchaus angebracht!

Trois-Hommes-Et-Un-Couffin-19505-4eb9366f7b9aa144a5001ca2-1321062048

Aber ich hab’s geschafft!

Es lief sogar alles ganz toll, erstaunlicherweise. Und damit ist der offizielle Teil meines Referendariats zu Ende.  Meine Noten stehen.  Ich bin durch.  Wie schnell das ging… verrückt!

Jetzt noch zwei Tage schulinterner Rundumdieuhrstress — dann kann ich mal ein bisschen Durchschnaufen und der Familie die Zeit widmen, die ihr zusteht…

Familienmathematik

Ein Rätsel

Herr Embee: Hurra! Gestern war unsere Familie noch 20 Prozent kleiner als heute.

Frau Embee: Hurra! Seit gestern ist unsere Familie um 25 Prozent gewachsen.

Wer hat recht?  Und warum ist uns das an diesem 4. Mai 2013 sowas von egal?