Follow my new blog

Samstag, 31. Oktober 2009

TDD wofür? [OOP 2010] [endlich-clean.net]

Anlässlich einiger Code Katas, die ich in letzter Zeit gemacht habe, hier ein paar Gedanken zu Nutzen und Grenzen von TDD (Test-Driven Development oder Test-Driven Design):

Was leistet ein Test? Er prüft die Korrektheit der Funktionsweise einer Codeeinheit. Klingt selbstverständlich. Die Erkenntnis durch TDD liegt für mich aber in der Umkehrung: Nur, was als eigene Codeeinheit vorliegt, kann auch direkt auf Korrektheit geprüft werden.

Codeeinheiten sind mehr oder weniger kompliziert. Eine ganz einfache könnte so aussehen:

public int Add(int a, int b)
{
    return a-b;
}

Ist die korrekt? Das stellt ein genauso einfacher Test leicht fest:

[Test]
public void Adding_two_numbers()
{
    var sut = new MyMath();
    Assert.AreEqual(5, sut.Add(2, 3));
}

Wenn der Testbalken jetz rot ist, dann lokalisiert eine Codeinspektion schnell den Übeltäter.

Wie steht es aber mit diesem Code zur FizzBuzz Kata:

IEnumerable<string> FizzBuzz()
{
    for(int i=1; i<=100; i++)
    {
        if (i%3 == 0)
           yield return “Fizz”;
       else if (i%5 == 0)
           yield return “Buzz”;
       else if (i%3 == 0 && i%5 == 0)
           yield return “FizzBuzz”;
       else
          yield return i.ToString();
    }
}

Ist der korrekt? Wer kann das auf einen Blick sehen? Vor allem aber, wer kann ihn so einfach runterschreiben? Die Entwicklung geht ja eher schrittweise vor. Genügt da ein Test wie:

[Test]
public void Test_FizzBuzzer()
{
    var sut = new FizzBuzzer();
    string expectedValues = new[] string {“1”, “2”, “Fizz”, “4”, “Buzz”, …};
    int i;
    foreach(string v in sut.FizzBuzz())
        Assert.AreEqual(expectedValues[i++], v);
}

Mit dem kann man natürlich von Anfang an “draufhauen” auf das system under test (SUT). Aber wenn irgendwas nicht klappt, weiß man nicht so recht, wo es hapert. Die SUT-Codeeinheit ist unübersichtlich und damit der Test sehr pauschal.

Durch TDD entsteht ein Gefühl dafür, wenn es unübersichtlich wird. Dann testen die Tests nämlich nicht mehr nur eine Funktionalität, sondern mehrere. Im obigen Fall ist der Test sozusagen ein Integrationstest, der sowohl die Generierung von Zahlen wie auch die Transformation einer Zahl prüft. Ob es ein Problem mit den Zahlen gibt oder eines bei der Transformation lässt sich im Zweifelsfall nur schwer sehen. Für mehr Klarheit bietet sich dann der Debugger an.

Besser ist es jedoch, den Debugger in der Schublade zu lassen. Stattdessen lieber den Code in Teilfunktionen zerlegen. Denn: Nur, was als eigene Codeeinheit vorliegt, kann auch direkt auf Korrektheit geprüft werden.

Die Teilfunktionen hier im Beispiel: Zahlengenerierung und Transformation. Die könnten mit ihrer Signatur so aussehen:

IEnumerable<int> ErzeugeZahlenreihe() { … }

string TransformiereZahl(int n) { … }

Daraus folgen dann insgesamt drei Tests:

  1. Prüfe die Zahlengenerierung
  2. Prüfe die Transformation
  3. Prüfe die Integration von Zahlengenerierung und Transformation

Jeder Test ist nun sehr spezifisch und vergleichsweise einfach. Dass das zu etwas mehr Code führt, ist nicht so schlimm, wie sich gleich zeigen wird. Geht etwas schief, ist der Scope jedenfalls klein. Ein Debugger muss nur selten angeworfen werden, um den Fehler darin zu finden. Das erhöht die Entwicklungsgeschwindigkeit wieder.

Wieviel Rätselraten Sie betreiben wollen, wenn in Ihrem Code etwas schief geht, bestimmen also sie. Der Rätselspaß (oder –ärger?) ist proportional zur Größe Ihrer SUTs.

Zudem gilt: Die Integration einzeln getesteter und für korrekt befundener Codeeinheiten zu testen ist weniger aufwändig, als nur die Codeeinheiten verschmolzen zu einem Ganzen zu testen.

Und jetzt zur zweiten TDD-Erkentnis: Code in einer eigenen Einheit ist prinzipiell austauschbar. Nicht nur lässt er sich gezielt testen und damit kontrolliert verändert werden. Er lässt sich auch gezielt komplett ersetzen.

In Max Frischs “Andorra” steht – wenn ich mich recht erinnere: “Nur was verzapft ist, geht nicht aus dem Leim.” Ein Satz, der mir irgendwie aus dem Deutschunterricht im Gedächtnis geblieben ist, auch wenn die Lektüre ansonsten keinen bleibenden Eindruck bei mir hinterlassen hat.

Angelehnt an diesen Satz, möchte ich vor dem TDD-Hintergrund formulieren und hoffen, dass es sich bei Ihnen ebenso einprägt: “Nur was isoliert testbar ist, kann ersetzt werden.” Das ist der Grund, warum aus Test-Driven Development über die Zeit Test-Driven Design geworden ist. Denn TDD macht es nicht nur leichter, die Korrektheit von Code zu prüfen, weil es testbare Codeeinheiten “austreibt”. Indem es diese Codeeinheiten motiviert, erzeugt TDD Flexibilität.

Am Beispiel: Gibt es erstmal eine eigene Codeeinheit für die Zahlengenerierung und die Transformation, dann kann es dafür alternative Implementationen geben. Die Zahlengenerierung könnte heute die natürlichen Zahlen erzeugen und morgen nur Primzahlen oder nur Fibonacci-Zahlen. Die Transformation könnte heute Vielfache von 3 und 5 erkennen und morgen gerade Zahlen oder Primzahlen.

Direkt und isoliert testbare Codeeinheiten haben immer einen irgendwie gearteten Kontrakt. Für die Zahlengenerierung wäre das z.B. Func<IEnumerable<int>>. Solange eine Integration nur auf die Kontrakte der sie konstituierenden Codeeinheiten abhebt, ist sie also frei, jede Implementation, die ihn erfüllt, zu nutzen.

Ergo: TDD führt nicht nur zu einfacherer Testbarkeit aufgrund kleinerer Codeeinheiten, sondern auch zu größerer Flexibilität.

Doch damit nicht genug! Ebenfalls segensreich empfinde ich, dass TDD quasi sofort Ergebnisse liefert. Wer erst lange an einer Implementation rumschraubt und am Ende testen will, der verschiebt die Befriedigung eines grünen Testbalkens auf unbestimmte Zeit. Implementationsperioden ohne Testläufe sind Durststrecken. TDD ist also eine ganz zeitgemäße “Genuss sofort”-Technik. Warum sich die Befriedigung eines grünen Testbalkens versagen? Aber vor allem: Warum länger als unbedingt nötig im Nebel tappen? Denn je länger Sie ohne Testlauf implementieren, desto tiefer wandern Sie in einen Nebel der Ungewissheit hinein. Ist das, was Sie an Code schreiben, tatsächlich zielführend? Löst Ihr Code wirklich das Problem? Oder schreiben Sie überhaupt den Code, den Sie schreiben wollen? Implementieren Sie tatsächlich Ihr Konzept?

TDD führt also auch zu häufigem Realitätscheck. Das ist umso wichtiger, je unbekannter die Problemdomäne. Wie sich in CodingDojos auf dem .NET Open Space und der prio-Konferenz herausgestellt hat und auch Übungen während Clean Code Developer Trainings zeigen, lauert die Unbekanntheit überall. Kaum ein Problem ist so einfach, dass sich TDD erübrigen würde. Nehmen Sie dafür aber nicht mein Wort, sondern probieren Sie es aus. Die KataPotter ist dafür ein Beispiel, das schon so manchem einiges Stirnrunzeln gemacht hat. Oder versuchen Sie sich am Minesweeper. Auch schön ist der Umgang mit römischen Zahlen.

Apropos römische Zahlen: Hier sehe ich allerdings durchaus eine Grenze von TDD. TDD hilft, separate Funktionseinheiten in einer größeren zu erkennen. Wird die größere schwer zu testen, dann liegt eine Zerlegung nahe.

TDD hilft jedoch nicht weiter, wenn eine Codeeinheit quasi unteilbar ist. Das ist oft nur scheinbar der Fall – am Ende ist jedes Lösung ja aber ein endlicher Baum, dessen Blätter eben die “atomaren” Codeeinheiten sind. Wie solche “atomaren” Codeeinheiten intern aussehen, beantwortet TDD nicht. TDD ist ein Hilfsmittel zur Strukturierung, nicht für den Algorithmenentwurf. Ein Bubblesort-Algorithmus lässt sich mittels TDD vielleicht noch entwickeln, weil er sich in naheliegende Codeeinheiten zerlegen lässt; ein Quicksort-Algorithmus jedoch ist jenseits von TDD.

Die Kata zur Umwandlung von römischen Zahlen profitiert mithin nicht so stark von TDD wie z.B. FizzBuzz oder KataPotter. Sie ist eher algorithmischer, denn struktureller Natur.

Und so bin ich bei meiner abschließenden Erkenntnis zu TDD: TDD ist kein Ersatz für Kreativität, Nachdenken und Erfahrung. Auch mit TDD als Werkzeug im Programmierkoffer lohnt der Einsatz des Gehirns vor dem Programmieren. Nachdenken hilft und verkürzt die Lösungszeit. Angesichts von z.B. der Minesweeper-Kata müssen wir uns nicht dümmer stellen als wir sind. Wir müssen nicht reflexartig in die Tasten hauen und sofort einen Test schreiben. Es lohnt sich, einen Moment über das Problem nachzudenken. Welche Datenstrukturen sind im Spiel? Welche Algorithmen? Wie könnte eine Grobstruktur der Lösung aussehen, welche Codeeinheiten/Verantwortlichkeiten könnten wie zusammenspielen?

Wenn Sie dann einen gewissen Plan haben, dann erst legen Sie mit TDD los. Und zwar gehen Sie dann gezielt mit TDD auf die Grobstrukturen los, die Sie durch Nachdenken ermittelt haben. Das erspart unnötigen Refaktorisierungsfrust.

Zum Schluss eine offene Frage: Erzeugt TDD nicht nur testbare und flexible Strukturen, sondern auch evolvierbaren Code? Ist Testbarkeit bzw. Flexibilität mit Evolvierbarkeit gleichzusetzen? Oder könnte eine Zerlegung, die nicht durch TDD motiviert ist, noch evolvierbarer sein? Hm…

Einstweilen entscheide ich mich allerdings im Zweifel für den Glauben an TDD gepaart mit Nachdenken. Für die Strukturierung von Komponenten ist das ein sehr hilfreiches Vorgehen.

Sonntag, 25. Oktober 2009

Le manifeste du jour – Was will uns die SOA-Welt sagen? [OOP 2010]

Jetzt ist es wieder passiert: Ein Manifest hat das Licht der Softwarewelt erblickt. Dieses Mal ist es das SOA Manifest. 2001 hatte das Agile Manifest den Anfang gemacht, 2009 kam das Software Craftsmanship Manifest dazu und nun ebenfalls noch in 2009 die SOA-Fraktion. Was ist nur los? Was will uns die SOA-Welt sagen?

Die naheliegende Antwort findet sich natürlich im Manifest selbst. Doch darum geht es mir zunächst noch nicht. Mich interessiert erst einmal, warum es überhaupt ein SOA Manifest gibt.

Also: Wann schreibt “man” ein Manifest? Hier ist “man” eine Gruppe vor allem bestehend aus SOA-Beratern und SOA-Produktherstellern. Wikipedia sagt: “Ein Manifest (lat.: manifestus, ‘handgreiflich gemacht’) ist eine öffentliche Erklärung von Zielen und Absichten, oftmals politischer Natur.” (http://de.wikipedia.org/wiki/Manifest) Das heißt, diese Gruppe möchte sich mit dem Manifest für alle deutlich in ihren Intentionen erklären.

Im Umkehrschluss bedeutet es: Offensichtlich sieht diese Gruppe solch eine Profilierung durch eine manifestierte Erklärung als nötig an. SOA-Berater und SOA-Produkthersteller fühlen sich demnach irgendwie falsch wahrgenommen. Sie greifen zum Mittel des Manifests, um diese Wahrnehmung zu korrigieren. (Dass sie sich nicht wahrgenommen fühlen und mit dem Manifest einen Marketingcoup laden wollen, kann ich nicht glauben. Dafür ist der Kreis der ursprünglichen Unterzeichner zu illuster. Man kennt sie schon.)

Das finde ich nun spannend: Die SOA-Proponenten fühlen sich falsch wahrgenommen. Hm… sehr interessant. Wie kann das denn sein? Wer hat denn die Wahrnehmung beeinflusst? Woher kommt die Wahrnehmung von SOA in den Unternehmen (oder auch der Entwicklergemeinde allgemein)? Haben die Gruppenmitglieder sie nicht entscheidend mitgeprägt? Und jetzt brauchen sie ein Manifest, um diese mitgestaltete Wahrnehmung zu korrigieren?

Oder ist ihnen die Gestaltung der Wahrnehmung aus der Kontrolle geraten? Hat sie sich verselbstständigt? Sind die SOA-Proponenten selbst Opfer eines Hypes geworden? Zauberlehrlinge, denen die SOA-Geister, die sie riefen, nicht mehr gehorchen wollten? Und jetzt soll das Manifest die Geister bannen?

Aber mal den Spott beiseite: Es könnte natürlich auch sein, dass das Manifest sozusagen ein “refactoring to deeper insight” ist. Nach Jahren der SOA-Geschäftigkeit hat die SOA-Gemeinschaft nun herausgefunden, worum es wirklich, wirklich geht bei SOA. Das wollen sie nun mit einem Manifest kurz, knapp, präzise ausdrücken. Endlich.

Standen am Anfang technische Gesichtspunkte wie die “Four Tenets of SOA”, geht es jetzt um mehr: es geht ums Business, es geht um Strategie. Ach! Wer hätte das gedacht. (Sowas, jetzt werde ich wieder ein wenig spöttisch. Das wollte ich doch gar nicht.)

Nun bin ich nach der Frage der Motivation doch bei den Inhalten angelangt. Die sind:

  • Business value over technical strategy
  • Strategic goals over project-specific benefits
  • Intrinsic interoperability over custom integration
  • Shared services over specific-purpose implementations
  • Flexibility over optimization
  • Evolutionary refinement over pursuit of initial perfection

Im Stil des agilen Manifests gibt es wieder eine linke und eine rechte Seite. Rechts steht das, was bisher wichtig erschien, links das, was jetzt noch wichtiger erscheint. Und was bedeutet das, wenn links jetzt plötzlich wichtiger als rechts ist? Meine Interpretation:

  • Die SOA-Proponenten leiden darunter, dass sie in eine Technologieecke gestellt werden. Aus der wollen sie raus. Sie betonen also, dass es ihnen um ein besseres Geschäft des Kunden geht, wenn SOA eingeführt wird.
    Wenn es Beratern und Technologieherstellern um ein besseres Geschäft ihrer Kunden geht, ist das natürlich sehr löblich. Bedenklich allerdings finde ich, dass das herauszustellen ist. War es bisher anders? Sind die SOA-Proponenten nun endlich ethisch erwacht? Von den Beratern hätte ich das allemal immer schon gedacht (oder zumindest erhofft), von den Technologieherstellern kann ich es so ganz jedoch nicht wirklich glauben. Wenn IBM, Microsoft und Oracle sagen, es ginge ihnen bei SOA um “Business value” und nicht so sehr um die Technik, dann müssten sie sich schon sehr zusammenreißen in SOA-Beratungsgesprächen. Womöglich müssten sie sagen: “Ja, verzichtet mal auf unser Produkt, denn ‘Business value’ könnt ihr auch auf andere Weise herstellen.” Hm…
    Oder steht der “Business value” einfach nur an erster Stelle im Manifest, weil man wieder – wie schon so oft – versucht, den geplagten IT-Entscheidern klar zu machen, dass es keine technische Silberkugel gibt? Wäre möglich – fände ich nun aber gar nicht neu.
  • Die SOA-Proponenten scheinen auch darunter zu leiden, nicht von “ganz oben” in den Unternehmen eingekauft zu werden. Oder sie werden aus ihrer Sicht nicht breit genug eingesetzt. Sie fühlen ihre Bemühungen zu sehr auf einzelne Projekte konzentriert, statt dass man ihnen das große Ganze anvertraut.
    Das wundert mich, denn SOA hat doch quasi vom ersten Tag an immer klar gemacht, dass es ums Übergreifende geht, um die Strategie. Das soll missverstanden worden sein? Oder sehen sich Unternehmen eben doch nicht in der Lage, bei großen IT-Landschaften mit einer umfassenden Strategie alles auf SOA umzukrempeln? Gehen sie, wenn sie eine Projektbrille aufsetzen, eher einen pragmatischen Weg? “Towards SOA one project at a time” hört sich für mich zumindest nicht so schlecht an. Von großen Visionen, die dann scheitern, hatten wir schon genug.
    Allemal den Technologieherstellern unter dem Manifest kann es ja nur recht sein, wenn man sie (endlich) auf strategischer Ebene als Gesprächspartner sieht. Da lässt sich gleich viel besser ein Servicebus oder eine Datenbank durchs ganze Unternehmen treiben.
  • Interoperabilität von vornherein, Interop eingebaut: Das wünschen sich die SOA-Manifestler. Statt also auf einer “as needed” Basis zu integrieren, wollen sie vorausdenken. Das passt natürlich zur strategischen Bedeutung, die SOA haben soll.
    Ganz grundsätzlich ist gegen Offenheit oder Standards natürlich nichts zu sagen. Interoperable by design ist irgendwie ne gute Sache. Mich wundert nur wieder, dass das erstens überhaupt erwähnt werden muss. Stand Interoperabilität nicht vom ersten Tag im Kern von SOA? Warum muss man jetzt von einer Erkenntnis sprechen, dass Interop von vornherein mitgedacht werden soll (“Through our work we have come to prioritize…” [meine Hervorhebung])?
  • Was ist der Zweck eines SOA-Service? Dass er von möglichst vielen genutzt wird. So stand es am Anfang von SOA. So heißt es nun immer noch. Nichts Neues also in der SOA-Welt. Wie kann das ein Erkenntnisgewinn hingestellt werden?
    Doppelt berechtigt ist diese Frage, da einer der Unterzeichner – Nicolai Josuttis – schon deutlich erklärt hat, dass Wiederverwendbarkeit eben nicht der “Business case” von SOA sein kann, weil die Wiederwendungszahlen für SOA-Services so gering sind. Also was nun? “Shared services”, hohe Wiederverwendbarkeit, oder doch nicht?
  • Flexibilität – so die Manifesterkenntnis – ist wichtig bei SOA. Wer hätte das gedacht? Stand auch das nicht schon am Anfang allen Servicedenkens? Mir kommt es so vor, dass auch hier ein Lernprozess überflüssig war. Für mich gehört Flexibilität zum Kern von SOA.
    Vor allem ist merkwürdig, dass Flexibilität mit Optimierung verglichen wird. Das ist für mich ein Kategorienfehler. Denn Flexibilität ist nur eine Qualität neben Performance, Skalierbarkeit, Sicherheit, die ebenfalls optimiert werden kann. Wer “Flexibility over optimization” ausruft, der läuft für mich Gefahr, die Flexibilität zu überoptimieren. Sie ist jedoch genausowenig Selbstzweck wie Performance oder Robustheit – auch wenn Flexibilität zum Zweck von SOA gehört.
  • Der Evolvierbarkeit eine Stimme zu verleihen, finde ich natürlich wunderbar. Dem letzten Punkt des Manifests stimme ich voll zu. Nur finde ich diese Forderung weder neu – erinnert mich irgendwie auch an “Responding to change over following a plan” im agilen Manifest –, noch finde ich sie in einem SOA-Manifest besonders passend. Sie ist schlicht zu allgemein, zu unspezifisch. Sie hat nichts mit SOA im Speziellen zu tun. Warum sie also hier als etwas Hervorhebenswertes aufnehmen? Und wieder: Wie kann das eine neue Erkenntnis sein, die die SOA-Proponenten erst durch ihre spezielle SOA-Praxis gewonnen haben (“…we have come to prioritize…”)?

Mein Fazit: Das SOA-Manifest kommt nicht wirklich los von dem, was es wohl loswerden will: vom Hype. Wenn ich mal den günstigsten Fall annehme, dass das SOA-Manifest ein Versuch ist, durch den Hype-Nebel der letzten SOA-Jahre zu sehen und den Kern von SOA nun endlich herauszuschälen, dann geschieht das allerdings letztlich auf gleiche Weise, durch Hype. Vielleicht liegt das an Conway´s Law? Danach könnte eine essenziell auf Hype aufgebaute “Organisation” (wie die der SOA-Proponenten, die ja bei großen Unternehmen für den großen “Business value” die große Strategie mitbestimmen und deshalb große Aufmerksamkeit bei den CTOs und CEOs braucht) eben auch bei allem guten Willen nur wieder Hype-Produkte herstellen. Sie kann nicht anders. Wie tragisch.

Ganz unabhängig von jeder Intention finde ich die Inhalte des Manifests aber auch nicht spannend. Mir fehlt es an Überraschungswert. Wo ist der echte Erkenntnisgewinn? Ich fühle mich nicht zu Ahs und Ohs hingerissen. Entweder geht es bei den Statements um das, was von der ersten Minuten SOA ausgemacht hat. Oder es geht um Selbstverständliches, von dem verwunderlich ist, dass ein Erkenntnisprozess von mehreren Jahren dazu nötig war. Schade.

Vielleicht bin ich aber auch nur grummelig, weil ich selbst noch kein Manifest unterzeichnet oder gar erarbeitet habe? Hm… Ich muss mal die Clean Code Developer (CCD) Community befragen. In CCD schlummert bestimmt Potenzial für mindestens ein Manifest. Das wäre doch gelacht. Was die Software Craftsmen und die SOA-Welt können, das können wir auch. Noch in 2009 oder lieber warten auf 2010? Wäre doch gelacht… ;-)

Mittwoch, 14. Oktober 2009

Stirnrunzeln über das Neueste von Microsoft seit geschnitten Brot [OOP 2010]

Grad scheint Microsoft wieder mal “the best thing since sliced bread” erfunden, wie es scheint. Der Reactive Framework (Rx) zaubert jedenfalls einiges breites Grinsen auf Gesichter bei Microsoft, hier der Erfinder des Ganzen, Erik Meijer, in einem Interview über Rx.

image
(Achtung: Dieses Interview ist auf sehr hohem Abstraktionsniveau! Eine Beschreibung von Rx für Praktiker sucht man hier vergebens.)

Den schätze ich eigentlich sehr, nicht nur für sein früheres “brainchild” Linq. In der letzten Zeit zaubert Erik Meijer aber zumindest mir kein beseeltes Grinsen mehr auf Gesicht, sondern Stirnrunzeln. Da war zuerst das ganz unglückliche Project Volta, welches fundamentalen Erkenntnissen zu verteilten Anwendungen zuwiderlief und jetzt zurecht offline ist. Und jetzt kommt der Reactive Framework.

Was ist der Rx? Das kann man hier und hier recht gut lesen. Ich möchte das jedoch lieber nicht selbst wiedergeben. Denn für mich besteht das Problem darin, dass ich neues Vokabular für etwas Altes benutzen müsste. Meine Kritik am Rx ist: es ist eben keine tolle neue Erfindung seit geschnitten Brot, sondern etwas lange Bekanntes in aufgehübschtes Gewand kleidet.

Mit Rx ist Microsoft aus meiner Sicht nur über Complex Event Processing (CEP) gestolpert. Wenn Erik Meijer die Rx-Interfaces als komplementär zu IEnumerable/IEnumerator ansieht und damit Linq-Queries auf Strömen von Events visioniert, dann ist das nichts anderes als eben CEP: statt auf fixen Daten Queries zu fahren, liest man Ströme von Daten ein und verarbeitet sie mit Queries. Das ist nicht neu, das ist kein Hexenwerk.

Wer wirklich einmal ausprobieren will, was man mit einer Abfragesprache auf Event-Strömen tun kann, der kann mit NEsper spielen: http://esper.codehaus.org/. Das ist (zusammen mit seinem Java-Bruder Esper) ein enterprise ready Open Source CEP Framework. Hier ein kurzes Beispiel für die Ermittlung des Durchschnittspreises “vorbeirauschender” Bestellungen (OrderEvent) innerhalb von jeweils 30-Sekunden-Fenstern.

select avg(price) from org.myapp.event.OrderEvent.win:time(30 sec)

Das ist grundsätzlich nichts anderes tut Rx (s. dazu das Beispiel zur Generierung von Mouse Drag Events hier).

Oder nehmen wir einfach nur Datenflüsse (data flows). Wo ist denn der Unterschied zwischen Rx, das nun wundersamerweise z.B. Mausereignisse als abfragbare Ereignisflüsse sieht? Oder als Flüsse, auf denen man Ereignisbehandlungsroutinen notieren kann. Tut mir leid, da ist nichts neues für mich dabei. Wenn ich im etablierten Paradigma data flow denke, dann ist das etwas uraltes und kann mit heutigen Mitteln bewältigt werden.

Hier ein einfacher Event-Strom mit “Event-Handler”:

new[] {1, 2, 3}.Subscribe(Console.WriteLine);

Der “Event-Handler” braucht nur das altbekannte IEnumerable:

static class EnumExt

{

    public static void Subscribe<T>(this IEnumerable<T> eventStream,
                                    Action
<T> handleEvent)

    {

        foreach (T e in eventStream)

            handleEvent(e);

    }

}

Aber damit nicht genug! Man kann auch IEnumerable-Ströme zusammenstecken zu “Pipes and Filters”. Das ist dann ein Flow. Warum nicht aus einer Zahlenliste die ungeraden herausziehen und negieren?

Zahlen –> UngeradeZahl | ZahlNegieren –> Liste der negierten ungerade Zahlen

Die Formulierung in Code ist denkbar einfach:

new[] {1, 2, 3, 4, 5, 6, 7}
    .Where(n => n%2 != 0)
    .Transform(n => -n)
    .Subscribe(Console.WriteLine);

Und wenn noch ein Schritt dazukommen soll – z.B. die Quadratur der ungeraden Zahlen –, dann wird der einfach eingefügt:

new[] {1, 2, 3, 4, 5, 6, 7}
    .Where(n => n%2 != 0)
    .Transform(n => n*n)
    .Transform(n => -n)
    .Subscribe(Console.WriteLine);

Die Transformationsmethode ist straightforward eine Extension Method wie oben Subscribe():

public static IEnumerable<TOut> Transform<TIn, TOut>(
                 this IEnumerable<TIn> eventStream, 
                 Func<TIn, TOut> processEvent)

{

    foreach (TIn e in eventStream)

        yield return processEvent(e);

}

Wer will, kann sowas auch asynchron machen. Das habe ich schon in früheren Blogposts beschrieben:

http://ralfw.blogspot.com/2009/07/ccr-flows-asynchrone-prozesse-mit-der.html
http://ralfw.blogspot.com/2009/07/verstandnisvorteil-fur-flows.html

Flows habe ich aber natürlich nicht erfunden. Die sind alt. Hier eine Quelle, die das Paradigma schon in den 1970ern propagiert hat: http://jpaulmorrison.com/fbp/. Mainstream ist es aber nicht geworden, wie wir sehen. Schade. Denn in die Schritte in einem Flow steigern die Evolvierbarkeit von Software, finde ich.

Jetzt noch die Umsetzung von Mausbewegungen in einen Strom, den man abfragen kann:

public partial class Form1 : Form

{

    private readonly EventStream mouseMovements = new EventStream();

 

    public Form1()

    {

        InitializeComponent();

 

        this.MouseMove += this.mouseMovements;

    }

    …

Eine Klasse EventStream sorgt dafür, die Mausbewegungen (oder auch andere Events) in ein IEnumerable zu transformieren. Das kann man dann z.B. so durchlaufen:

this.mouseMovements.Events<MouseEventArgs>()
    .Where(args => args.X < 100 && args.Y < 100)
    .Subscribe(args => Console.WriteLine("{0}, {1}", args.X, args.Y));

Wie macht EventStream das? Die Windows Message Loop darf ja nicht aufgehalten werden. Es geht nur asynchron. Also rufe ich die Concurrency Coordination Runtime (CCR) zur Hilfe:

class EventStream

{

    public class Event

    {

        public object Sender;

        public EventArgs Args;

    }

 

    private Port<Event> events = new Port<Event>();

 

 

    private void EventListener(object sender, EventArgs args)

    {

        this.events.Post(new Event{Sender = sender, Args=args});

    }

 

 

    public IEnumerable<TEvent> Events<TEvent>() where TEvent : EventArgs

    {

        Event e;

        while (this.events.Test(out e))

            yield return (TEvent)e.Args;

    }

 

 

    public static implicit operator MouseEventHandler(EventStream stream)

    {

        return stream.EventListener;

    }

    …

}

Mit der impliziten Konvertierung kann ich den EventStream einfach an einen Eventhandler für die Mausbewegungen binden, ohne zu verraten, wer intern die Verarbeitung übernimmt.

Der Eventhandler schiebt dann jeden Event in einen CCR Port. Das ist sogar Thread-sicher. Und wenn ich die aufgelaufenen Events prozessieren will, dann hole ich sie mir über Events() als IEnumerable wieder heraus.

Alternativ könnte ich natürlich auch einen Eventhandler registrieren, der life auf neue Events reagiert und sie z.B. in einen asynchronen Flow einspeist. Dann könnte ich in einer Kette von asynchronen Schritten filtern, transformieren, reagieren. Auch da wären Where(), Transform() und Subscribe() wie oben in den synchronen Beispielen möglich.

Wo also ist das entscheidend neue beim Rx? Beats me. Ich kann nur die grübelnd die Stirn runzeln.

Ok, der Rx mag hier und da etwas einfacher machen, weil er schon Abstraktionen bietet, die ich vielleicht erst bauen muss/müsste. Das wäre ne nette Sache – aber deshalb hat Erik Meijer nun nicht gleich “the best thing since sliced bread” erfunden. Er steht nur in einer langen Tradition. Die zu erwähnen und weniger die Flügel zu schlagen, um nicht zuviel Hype-Staub aufzuwirbeln, das fänd ich angemessen.

PS: Oder übersehe ich hier die eigentliche Erfindung? Geht der brilliante Innovationshub an mir vorbei? Ich bitte um Erhellung.

Sonntag, 11. Oktober 2009

Fokussieren durch bezahlen [OOP 2010]

Wir zahlen zuwenig. Dieser Gedanke ist mir gestern gekommen. Ich hatte mit Google Reader meine RSS-Feeds durchstöbert, dann bei InfoQ geblättert und schließlich eine neue Zeitschrift zur Hand genommen, von der ich ein Probeexemplar bestellt hatte: NOVO argumente. Ganz normal hatte ich also im Überfluss an Lesestoff ein Bad genommen. Ganz normal hatte ich dabei cherry picking betrieben: nur, was mir auf Anhieb interessant erschien, las ich.

Hört sich doch eigentlich auch gut an, oder? Ist es nicht toll, wenn uns soviele Daten “at our fingertips” zur Verfügung stehen? Selbstverständlich. Das möchte ich auch nicht missen. Eine zivilisatorische Errungenschaft ersten Grades.

Und dennoch… Das Bad im Überfluss wollte mich nicht so recht erfrischen. Der Grund: Ich habe mich nicht fokussiert. Ich bin nicht tief gegangen. Ich habe mich nicht verstören lassen.

Meine Tochter hingegen hat nur eine sehr überschaubare Zahl an CDs und Kassetten mit Kindergeschichten wie Bibi & Tina oder Elea Eluander. Die hört sie wieder und wieder. Darin taucht sie tief ein, bis sie jede Einzelheit kennt und mit mir sogar arambolisch spricht. (Arambolisch ist die Sprache einer “Parallelwelt” bei Elea Eluander.)

Der Unterschied zwischen meiner Tochter und mir: Sie lebt im Mangel, ich im Überfluss. Sie taucht tief, ich schwimme an der Oberfläche.

Das ist natürlich eine verkürzte Darstellung. Der überzeichnete Kontrast hilft mir aber, meinen gestrigen Gedanken zu begründen: Ist der Überflüss an Daten vielleicht kontraproduktiv? Haben wir den falschen Wunsch, wenn wir uns noch mehr wünschen? Ist die “Umsonst-Kultur” des Internets nicht nur für Produzenten eine wirtschaftlich schwierige Sache, sondern auch für die Konsumenten?

Mich durchzuckte gestern jedenfalls beim Griff nach der Zeitschrift der Wunsch, es möge mehr kostenpflichtige Angebote geben. Die Zeitschriftenartikel kann ich im Internet kostenlos lesen – wie auch z.B. die der brand eins –, aber ich gebe für sie Geld aus.

Hatte ich zunächst gedacht, das täte ich nur, um in einem Heft bequemer als am Bildschirm lesen können, so sehe ich jetzt einen zweiten positiven Effekt: ich fokussiere mich mehr.

Lesestoff, für den ich bezahle, schenke ich mehr Aufmerksamkeit.

Das ist meine gestrige Erkenntnis. Der Volksmund weiß zwar schon lange, “Was nix kostet, ist auch nix wert”, doch gestern habe ich das echt gespürt, weil ich die Konsequenz gesehen habe. Meine Augen flogen über die kostenlosen Inhalte hinweg. War das Geschriebene zu holprig, bin ich gesprungen oder habe den nächsten RSS-Feedeintrag geöffnet. War ein Video zu langweilig, bin ich gesprungen oder habe das nächste gestartet.

Ohne spürbare Kosten gibt es keinen Anreiz, bei einem Inhalt zu verweilen.

Ist das schlimm? Ich würde sagen, ja, das ist aus mehreren Gründen “schlimm”:

  1. Wir verbrauchen die undiskutierbar endliche Ressource Zeit ineffektiv und ineffizient. Wohlgemerkt beziehe ich mich jetzt auf Zeit, in der wir etwas lernen wollen/sollen. Der Entspannung mag “Zappen” ja (gelegentlich) zuträglich sein.
  2. Wir geben Neuem/Unbekanntem weniger Chancen, weil wir schon genug damit zu tun haben, das Bekannte und Beliebte anzuklicken. Wenn wir hingegen gezahlt haben, tendieren wir dazu, auch mal das nicht unmittelbar Erfreuliche, Bekannte, Flauschige zu ertragen – und schließlich gar zu mögen und zu vertreten. Wir haben schließlich gezahlt, also nutzen wir auch die bezahlten Inhalte.
  3. Wir begünstigen die Abnahme der Qualität von Inhalten, weil die im Überfluss unter immer größeren Konkurrenzdruck geraten. Der könnte theoretisch zwar auch dazu führen, dass die durchschnittliche Qualität zunimmt – de facto scheint das aber nicht so zu sein. Überlebensfähiger scheint nicht inhaltlich Tiefgehendes zu sein, sondern schnelle Aufmerksamkeitsattraktionen und schnell Befriedigendes.
    Das bedeutet nicht, dass es keine “guten Inhalte” mehr gibt, aber sie sind schwerer als im Mangel zu finden.

Mein Fazit: Wir müssen mehr zahlen für Inhalte. Wieviel genau mehr und in welcher Form, weiß ich nicht. Dass aber Zahlungen nötig sind, scheint mir unausweichlich. Nur wenn wir zahlen, wenn Konsum insofern spürbar wird, kommen wir zu einem bewussteren Umgang mit unserer Zeit, mit unseren Ressourcen.

Welchen Schaden die Abwesenheit von Kosten anrichten kann, sehen wir jeden Tag an der wachsenden Spam-Flut (auch innerhalb von Unternehmen). Da Emails nicht kosten, gibt es kein Halten. Jeder verbreitet alles an alle, wenn ihm danach ist. Was ihm keine Mühe macht, belastet allerdings die Empfänger. Das ist umso schlimmer, da Email ein Push-Medium ist.

Ähnliches gilt für die Veröffentlichung in anderen Medien. Mit dem Internet ist es jedem jederzeit möglich auf jedem Niveau etwas zu veröffentlichen – sei es in Newsgroups, Blogkommentaren oder gar eigenen Blogs. Das kostet nichts beim Schreiben und nichts beim Lesen. Google bringt es in haltlos wachsender Menge vor meine Augen.

Wenn es aber noch vor dem Internet eine zivilisatorische Errungenschaft gab, dann ist es die Impulskontrolle. Sie ist sogar womöglich im Kern der Definition von Zivilisation. Wir sollten nicht jedem Impuls nachgeben. Warum preisen wir dann das Internet mit seiner Null-Kosten-Kultur so hoch? Ist das nicht merkwürdig. Dort leben wir jeden Impuls zur Äußerung und Konsumption einfach aus. Kost´ ja nix.

Zwar beschert uns das vorher ungekannte Freiheit und Datenfülle. Andererseits scheint es mir sowohl bei der Produktion wie der Rezeption Qualitätsmängeln Vorschub zu leisten.

Deshalb mein Gedanken, Produktion und Rezeption mit Geld zu steuern. Denn um nichts anderes geht es: Steuern von Zeitinvestitionen. Eine Latte, über die man springen muss, damit die knappe Ressource Zeit lohnenswert investiert ist.

Das ginge zwar auch irgendwie wohl mit mehr Selbstdisziplin und/oder Medienkompetenz. Vielleicht fehlt die mir ja schlicht als prä-Digital Native? Doch das gute alte Geld scheint mir ein einfacheres Mittel. Ich bin also im Allgemeinen dafür, mehr zu zahlen. Und ich bin auch bereit, selbst ganz konkret mehr zu zahlen und dadurch weniger Inhalte “at my fingertips” zu haben.

Dass das Bezahlen online anders als offline funktionieren muss, ist klar. Im Internet muss es Möglichkeiten zum kostenlosen Stöbern geben wie im Buchladen. Und Inhalte sollten in verschiedenen Granularitäten gekauft werden können. Am Ende tun wir uns aber, so glaube ich, alle einen Gefallen, wenn wir wieder für Inhalte zahlen.

Mehr, deutlich mehr kostenpflichtige Inhalte scheinen mir unausweichlich. Im historischen Rückblick werden deshalb wohl die ersten 15-20 Jahre “öffentliches Internet” mit seiner Null-Kosten-Kultur als Zeit der Verirrung angesehen werden. Schiere Datenflut ist eben nicht genug. Es braucht Hilfe beim Lenken und Fokussieren von Ressourcen. Und da ist Geld immer schon ein sehr probates Mittel gewesen.

Donnerstag, 8. Oktober 2009

Material zu meinen Vorträgen auf der ADC 2009

Die ADC 09 ist fast vorbei – nur noch morgen ein Workshop zum Thema Architektur. Hat wieder Spaß gemacht. Gute Gespräche, ein interessiertes Publikum, Sedgeway fahren :-) Und: die ersten CCD-Mausmatten haben den Weg in die Community gefunden.

Da ich in guter Tradition meine Vorträge ohne PPT-Folien gemacht habe, um den Aufmerksamkeitsfokus der Teilnehmer nicht vom Wesentlichen, dem Thema, auf irgendwelche Projektionen abzulenken, hier einige Hinweise für die, die sich damit weiter beschäftigen möchten:

  • Der Quellcode meiner CCR- und ApplicationSpace-Vorträge steht hier zum Download inkl. Microsoft CCR. Der CCR Space als Wrapper um die CCR ist ein Open Source Projekt bei Google: http://code.google.com/p/ccrspace. Der Application Space ist ebenfalls Open Source, aber bei CodePlex: http://xcoappspace.codeplex.com/
  • Die CCR ist Teil des Robotics Studio, dessen Nutzung einer Lizenz unterliegt. Wer die CCR produktiv einsetzen will – und das kann man tun, denn sie ist ausgereift –, sollte sich daher einmal anschauen, welche Lizenz passt. Mit einer MSDN Subscription “hat” man die CCR auch, wenn ich mich nicht irre; ansonsten kann man sie auch als sog. “CCR und DSS Toolkit” für kleines Geld kaufen.
  • Literatur zur CCR kann ich leider nicht so recht empfehlen. Es gibt versprengt im Netz einiges – aber das beleuchtet die CCR nur punktuell. Die CCR Doku ist nicht ausführlich. In der dotnetpro habe ich aber zwei Artikel im Jahr 2009 darüber geschrieben; die sind natürlich über das online Archiv hier und hier verfügbar.
  • Clean Code Developer ist ausführlich im Wiki beschriebe: www.clean-code-developer.de. Dort gibt es auch Hinweise auf Berichte über CCD inkl. Videos. Wer dann mitdiskutieren will, ist herzlich zu den Foren bei XING und Google eingeladen.
  • Über Agile Führung bzw. Soziokratie habe ich schon recht ausführlich hier im Blog geschrieben. Außerdem äußere ich gelegentlich Gedanken dazu in einem eigenen Blog: http://soziokratie.blogspot.com. Dort gibt es auch weitere Hinweise zu Quellen gleich in einem der ersten Beiträge. Und es gibt natürlich auch eine “offizielle Repräsentation” dieses Organisationskonzeptes; das ist in Deutschland das Soziokratische Zentrum: www.soziokratie.org.
  • Im Architekturworkshop ging es um die systematische Transformation von Anforderungen in wartbare “Grobstrukturen” und dann deren Übersetzung in konkreten Code. Das Softwareuniversum und Softwarezellen waren Thema. Dazu habe ich schon einiges über die Jahre geschrieben. Hier der Lesestoff in ziemlich chronologischer Reihenfolge:

Auf der ADC habe ich schon einige Fragen zu diesen Themen beantworten können. Doch es ergeben sich im Nachhinein bestimmt noch mehr. Bitte zögern Sie dann nicht, mich per Email (info (at) ralfw (dot) de) oder über die Kommentare hier im Blog zu kontaktieren. Ich bin gespannt auf Ihre Gedanken.