Asynchronizität und Verteilung üben - Szenarien für verteilte Anwendungen

Wer was Neues lernen will, tut das am besten zunächst mit Übungen. Chirurgen lernen neue Techniken erst an toten und/oder nicht menschlichen Lebewesen, Piloten lernen im Simulator. Und ich will den neuen Application Space ausprobieren oder allgemeiner asynchrone und verteilte Architekturen üben. Was sind aber Übungsaufgaben, an denen ich mich versuchen kann? Einen asynchronen und verteilten Service aufzusetzen ist ja trivial. Von dem Service dann auch noch Notifikationen zu bekommen oder Pub/Sub einzurichten, das ist auch trivial. Jeweils für sich genommen sind diese Dinge einfach - aber wie füge ich diese Bausteine zu etwas Größerem, Realistisch(er)em zusammen? Erst in einem umfassenderen Szenarion, das nicht von der Technik ausgeht, sondern von "Kundenanforderungen" kann ich auch feststellen, was einer Technologie wie dem Application Space noch fehlen mag (oder wo sie besonders geeignet ist).

Hier möchte ich nun einige Szenarien zusammentragen, die mir als Übungen für Verteilung und Asynchronizität erscheinen. Sie sind mehr oder weniger komplex, aber immer irgendwie "zum Anfassen". Jedes bietet für die zu übende oder evaluierende Technologie eine andere Herausforderung. Ich werde sie mit dem Application Space implementieren, wer mag, kann aber natürlich WCF pur oder mit Azure oder Jabber pur oder MassTransit oder NServiceBus oder Rhino Service Bus oder MSMQ pur oder TCP Sockets pur oder noch ganz andere Technologien damit ausprobieren. Ganz im Sinne der School of .NET Diskussion sehe ich diese Szenarien auch als Chancen für ganzheitliches Lernen. Clean Code Development, Komponentenorientierung, .NET Framework Grundlagen, TDD... all das und mehr kann man auch einfließen lassen.

Szenario 1: Stammdatenverwaltung

Aller Anfang sollte einfach und typisch sein. Deshalb ist mein erstes Szenario eines, mit dem viele Entwickler immer wieder konfrontiert werden: die Stammdatenverwaltung oder "forms over data". Ein Anwender verwaltet mit seinem Client Daten in einer Datenbank mit den üblichen CRUD-Funktionen: Create, Read, Update, Delete. Zusätzlich kann er einen serverseitigen Datenimport anstoßen.

Ob sich für dieses Szenario eine Verteilung überhaupt lohnt, sei einmal dahingestellt. Allemal, wenn aus anderen Gründen eine Anwendung verteilt werden soll, muss auch die Stammdatenverwaltung auf eine solche Architektur abgebildet werden.

Um das Datenmodell einfach zu halten, reicht es aus, wenn das Szenario sich nur um Personen mit ihrer Adresse dreht.

Datenmodell:

• Person(Nachname, Vorname, Straße, PLZ, Ort, Land, Tel, Soundex)

Featureliste:

• Der Anwender kann nach Personen suchen; der Server liefert eine Liste von passenden Personen zurück.
• Der Anwender kann eine gefundene Person bearbeiten und speichern.
• Der Anwender kann eine neue Person anlegen.
• Der Anwender kann eine Person löschen.
• Der Anwender kann gefundene Adressen in eine CSV-Datei exportieren. Der Export kann clientseitig erfolgen.
• Der Anwender kann den Import von Personen aus einer CSV-Datei veranlassen. Dazu muss er dem Server mitteilen, in welcher Datei die Daten liegen. Der Server importiert, meldet zwischendurch den Fortschritt und liefert am Ende ein Importresultat.
• Dublettenprüfung: Jede Person soll nur einmal in der Datenbank stehen. Mehrere Sätze mit denselben Daten sind zu vermeiden, um bei Mailings nicht mehrere Briefe an dieselbe Person zu senden. Um den Vergleich von Personen zu vereinfachen, können sie mit einem Soundex-Wert ausgestattet werden. Wannimmer eine Person gespeichert werden soll (nach Bearbeitung, nach Neuanlage, beim Import) und schon mit einem anderen Datensatz in der Datenbank vertreten ist, wird die Operation verweigert und der Anwender informiert. Die Dublettenprüfung kann in Schritten implementiert werden:
  • Dubletten bei Neuanlage prüfen
  • Dubletten beim Import prüfen
  • Dubletten nach Bearbeitung prüfen

Klingt doch einfach, oder? Hat aber natürlich seine Tücken, denn es gilt ja, diese Funktionalität asynchron und verteilt zu realisieren. Wie kommunizieren Client und Server im Sinne einer solchen Stammdatenverwaltung miteinander?

Herausforderungen:

• Wie werden asynchrone Operationen wie Speichern oder Import im UI repräsentiert?
• Wie meldet der Server den Fortschritt beim Im/Export an den Client (Notifikationen)?

Szenario 2: Referentenfeedback (Heckle Service)

Christian Weyer hat ein schon älteres Szenario in seinem dotnetpro-Artikel "Schnuppern an Azure" (5/2009)mit den aktuellen Technologien neu implementiert. In der dotnetpro 7/2009 greife ich das auf und realisiere es mit dem Application Space.

Die Idee ist einfach: Zuschauer eines Vortrags auf einer Konferenz sollen dem Referenten live Feedback geben können. Sie sollen sozusagen elektronisch zwischenrufen können (engl. to heckle). Dazu hat jeder Teilnehmer einen Client, mit dem er kurze Textnachrichten an den Referenten senden kann, der sie in einem eigenen Frontend auflaufen sieht.

Datenmodell:

• Nachricht(Absendername, Nachrichtentext, Eingangszeitstempel) - Jede Nachricht gehört natürlich zu einem Referenten. Ob das allerdings in der Nachricht vermerkt werden muss, soll hier nicht festgelegt werden.

Featureliste:

• Teilnehmer senden Zwischenrufe an den Referenten.
• Teilnehmer sehen sich die Liste der letzten n Zwischenrufe an.
• Der Referent bekommt jeden Zwischenruf automatisch angezeigt.
• Falls der Referent sein Frontend - aus welchen Gründen auch immer - neu startet, bekommt er die Liste aller bisher eingegangenen Zwischenrufe angezeigt.
• Der Referent identifiziert sich irgendwie, so dass die Teilnehmer ihm und keinem anderen ihre Zwischenrufe senden. Die Teilnehmer müssen einen Referenten also beim Zwischenrufen adressieren. Potenziell kann die Heckle-Anwendung ja gleichzeitig in vielen Vorträgen zum Einsatz kommen.
• Der Veranstalter der Vorträge kann die Zwischenruflisten aller Referenten jederzeit einsehen.

Herausforderungen:

• Wie nehmen Teilnehmer mit dem Referenten Kontakt auf? Direkt, indem sie seinen Rechner adressieren oder indirekt via eines Discovery-Servers?
• Wo werden die Nachrichten vorgehalten, damit vor allem Teilnehmer und Veranstalter sich jederzeit einen Überblick verschaffen können?
• Wie wird insb. der Referent automatisch über neue Nachrichten informiert?

Szenario 3: Tic Tac Toe

Es ist zwar kein typisches Geschäftsanwendungsszenario, aber es macht Spaß: ein Spiel realisieren. Bei Tic Tac Toe (TTT) sind die Regeln simpel, so dass man sich auf die verteilte Implementation konzentrieren kann.

Zwei Spieler spielen gegeneinander auf einem TTT-Brett. Jeder sitzt an seinem PC und sieht den gemeinsamen Spielstand.

Datenmodell:

• Spielfeld mit 3x3 Spielfeldern in den Zuständen O, X und leer. Zusätzlich sollte das Spielfeld noch einen Spielzustand haben wie Spiel begonnen, Spiel beendet, Gewinner ist Spieler 1, Gewinner ist Spieler 2.

Featureliste:

• Ein Spieler bietet sich zum Spiel an.
• Ein Spieler nimmt Kontakt mit einem anderen auf und sie beginnen eine Partie.
• Spieler machen Züge.
• Ob und welcher Spieler gewinnt, wird automatisch festgestellt.
• Ein Spieler beendet eine Partie vorzeitig.

Dies ist während des Spiels natürlich ein Peer-to-Peer-Szenario. Ob intern die Rollen aber auch gleich sind oder nicht vielleicht doch ein Spieler ein Partienserver ist, hängt von der Implementation ab.

Herausforderungen:

• Wie nehmen die Spieler Kontakt miteinander auf?
• Wo wird der Partienzustand gehalten?
• Wie erfahren die Spieler über den nächsten Zug?
• Wie wird den Spielern das Spielende mitgeteilt?

Szenario 4: Starbucks

Gregor Hohpe hat in einem Blogbeitrag deutlich gemacht, wie wenig praktikabel die bisher so beliebten 2-Phase-Commit-Transaktionen in der realen Welt, d.h. in asynchronen (und verteilten) Szenarien sind. MassTransit und Rhino Service Bus haben das aufgenommen und versucht, mit ihren Mitteln das Szenario abzubilden. Es ist einfach eine schöne Fingerübung für jeden, der in die verteilte und asynchrone Programmierung einsteigen will.

Bei Starbucks kommen Kunde, Kassierer und Barista zusammen. Der Kunde bestellt ein Getränk, der Kassierer nennt den Preis und nimmt das Geld entgegen. Währenddessen bereitet der Barista schon das Getränk zu und serviert es, wenn die Zahlung geklappt hat.

Datenmodell:

• Bestellung(Getränkeart, Bechergröße, Menge)
• Zahlungsaufforderung(Gesamtpreis einer Bestellung)
• Bezahlung(Betrag, Zahlmittel) - Zahlmittel könnten Barzahlung oder Kreditkarte sein

Featureliste:

• Kunde bestellt ein Getränk beim Kassierer. Variation: Kunde bestellt mehrere und verschiedene Getränke beim Kassierer.
• Kassierer nennt den Gesamtpreis
• Kunden bezahlt
• Kassierer nimmt Bezahlung entgegen und prüft den Betrag. Wenn ok, dann schließt er die Bestellung ab.
• Barista bereitet bestellte Getränke vor.
• Wenn Bezahlung abgeschlossen, stellt der Barista die Getränke zur Abholung bereit.

Der Kunde kann hier als interaktiver Client realisiert werden. Kassierer und Barista hingegen sind automatische Dienste. Um die reale Welt nachzustellen, können ihre Funktionen über Pausen (Thread.Sleep()) eine wahrnehmbare Dauer bekommen.

Herausforderungen:

• Wie nehmen die Beteiligten Kontakt miteinander auf?
• Wie wird der Dialog zwischen Kunde und Kassierer geführt?
• Wie erfährt der Kunde über das fertiggestellte Getränk?
• Was passiert mit einem schon zubereiteten Getränk, wenn die Zahlung nicht erfolgreich ist?

Szenario 5: Arbeitsteilung

Das MSDN Magazine Juni/2009 beschreibt in "A Peer-To-Peer Work Processing App With WCF" ein Szenario, dass sich auch zur Übung zu realisieren lohnt. Mehrere sog. Worker stehen da bereit, um Aufträge von sog. Usern anzunehmen. Der Artikel nutzt zur Arbeitsverteilung das P2P-Protokoll von WCF - aber man kann es auch anders machen.

Datenmodell:

• Arbeitsauftrag(Id, Dauer)

Featureliste:

• User vergeben Aufträge in einen Pool von Workern hinein.
• Worker übernehmen einen oder mehrere Arbeitsaufträge.
• Worker können dem Pool beitreten oder ihn verlassen.
• Ob ein Worker Aufträge annimmt hängt von seiner Last ab. Die gesamte Auftragslast soll natürlich möglichst gleichmäßig auf die Worker verteilt werden.
• Wie die Arbeit "so läuft" können sog. Spectators beobachten; sie dienen der Instrumentierung des Systems.

In dieser Featureliste fehlen einige Aspekte, die der Artikel beschreibt, z.B. "Work Item Backup" oder "Work Sharing". Ich habe sie nicht aufgenommen, weil sie mir abhängig scheinen vom gewählten Lösungsweg (hier: P2P-Kommunikation). Meine Szenarien sollen aber keine Lösungswege oder Technologien nahelegen (z.B. Einsatz eines Busses oder Sagas oder P2P-Kommunikation).

Die schlanken Aufträge habe ich ebenfalls deshalb übernommen. Es geht ja nicht um eine konkrete Problemdomäne. So müssen die Aufträge nur eine Dauer haben, um Lastverteilung beobachten zu können.

Herausforderungen:

• Wie wird die Auftragslast möglichst gleichmäßig (oder "gerecht") auf die Worker verteilt?
• Wie werden weitere Worker möglichst unmittelbar in die Auftragsbearbeitung einbezogen? Oder allgemeiner: Wie kann der Worker-Pool "atmen"?
• Wie werden User über Auftragsergebnisse (oder gar Fortschritte) informiert?
• Wie kann ein Spectator die Arbeit(sverteilung) beobachten?
• Müssen Aufträge nach Vergabe noch "gesichert" werden können, falls Worker noch nicht zu ihrer Verarbeitung gekommen sind?
• Wie können die Worker möglichst ortsunabhängig verfügbar gemacht werden?

School of .NET - Stakeholderverträgliches Lernen

Stefan Lieser hat ihn nun entworfen: einen Rahmen für neues Präsenzlernen. In 3 Blogeinträgen haben wir laut (oder besser: sichtbar und öffentlich) darüber nachgedacht, wie Lernen in Zeiten von Web 2.0 und einer wieder mal geplatzten Wunschblase aussehen könnte. Das übliche Kochrezept - nimm ein Thema, biete 2, 3, 4, 5 Tage Kurs an, fertig - schien uns nicht mehr so unzweifelhaft zeitgemäß. Es setzt einfach den Willen voraus, bei knapper Personaldecke wie heute üblich auf Entwickler über längere Zeit zu verzichten. Die Kompaktheit des Lernen mag zwar auch ihre Vorteile haben - doch die wahrzunehmen fühlen sich nicht alle, die es wollen, in der Lage. Also liegt der Gedanke nahe, Lernen mehr an die Bedürfnisse der Lernenden anzupassen.

Aufbauend auf dem Rahmen von Stefan konkretisiere ich deshalb mal eine School of .NET:

• Semesterlänge: 3 Monate
• 1 Tag Unterricht pro Woche
• Semesterbeginn mit einer Blockveranstaltung von 2 Tagen zur Gruppenbildung - genannt Semester.Ctor ;-)
• Semesterende mit einer Blockveranstaltung als intensiver Abschluss mit Retrospektive - genannt ~Semester oder Semester.Finalizer ;-)

Das sind dann zusammen 14 Unterrichtstage mit 11 Wochen zwischen den 12 Terminen. Zu den Präsenztagen kommen also noch ausgedehnte Gelegenheiten für Hausaufgaben. Die finde ich so wichtig wie Stefan, denn damit kann sich das Wissen setzen, das man in den Präsenztagen erwirbt. Im normalen Blockunterricht wird zuviel gestopft - und die Fragen kommen erst hinterher, wenn alle wieder auseinandergelaufen sind.

Wird der Unterricht aber über 3 Monate verteilt, kann das neue Wissen schrittweise schon in die Praxis überführt werden und wirft Fragen auf, die gleich am nächsten Unterrichtstag gestellt und diskutiert werden können. Die School of .NET ist damit viel praxisnäher als jedes übliche Training. Sie bietet sogar quasi während des Semesters Zugriff auf Consultants (die "Lehrer"), denn die "Schüler" können ja jederzeit Problemstellungen aus ihren Betrieben mitbringen.

Die Hausaufgaben involvieren die Teilnehmer auch viel mehr als jede Übung, die innerhalb des Unterrichts gemacht wird. Dann sind die nämlich auf sich allein gestellt. Insofern ist jedes berufsbegleitende Lernen letztlich tiefergehend als ein Blockunterricht.

Aber nicht nur für die Teilnehmer hat die School of .NET Vorteile. Auch Kunde und vor allem Chef können nur davon profitieren. Als Stakeholder wollen sie ja eigentlich beides: einen kompetenten Entwickler, der schon alles kann, und einen, der morgen auch noch mehr kann, also ständig lernt. Berufsbegleitend ist das möglich. 1 Tag in der Woche lernen die Entwickler und 4 bringen sie ihre Kompetenz im Projekt ein. Sie werden schlauer ohne störend lange abwesend zu sein. Zudem können sie - wie oben schon erwähnt - in den Unterricht Probleme aus dem Projekt einbringen. Auch der Unterricht bringt ihnen also etwas für das Projekt und sie lernen von anderen etwas über deren tägliche Probleme.

Lernt der Entwickler was, freut sich der Stakeholder ;-)

Ja, ich denke, ein solches Lernangebot werden Stefan und ich mal schneidern: School of .NET oder kurz SoN. Und dann bieten wir das in Hamburg und Köln mit regionalem Einzugsgebiet an. Da kann dann keiner, der lernwillig ist, mehr Nein sagen ;-) Der Unterrichtsort ist erreichbar und der Unterricht nimmt nicht zuviel Raum im Tagesgeschäft ein.

Solche Lerngelegenheit ist dann besonders interessant für alle, die um- oder aufsteigen. Dann geht es nämlich nicht darum, dass gleich morgen irgendwas gekonnt werden muss. Entwickler, die auf .NET umsteigen oder eine Brownfield-Anwendung uptodate bringen sollen, haben meist einen weiteren Zeithorizont. Da ist es klar, dass sie erstmal Erfahrung mit der Plattform sammeln müssen. Dito Neueinsteiger, die aus ihrer Erstausbildung kommen und noch nicht fit mit dem .NET Framework sind. Als Junior Programmer haben sie 1 oder 2 Jahre, um sich einzufuchsen. Da ist berufsbegleitendes Lernen ideal. Und auch wer heute fitte .NET Programmierer, aber am Markt nicht findet, der bekommt mit einer School of .NET eine Hilfestellung. Er kann sich eher auf einen "smart and getting things done" Entwickler einlassen, der noch kein .NET-Spezialist ist.

Ja, ich finde, das ist ein rundes Bild für eine School of .NET. Das machen wir, Stefan. Auch wenn das Format zu jedem Thema passt, fangen wir am besten mit .NET-Grundlagen und CCD an. Tüfeln wir mal ein Curriculum aus...

Schulbank statt “Druckbetankung” – Berufsbegleitendes Lernen gerade jetzt

Auf mein Posting mit der Frage, wie Präsenzlernen anders, attraktiver aussehen könnte, hat Stefan Lieser geantwortet – und auch laut nachgedacht. Wir stimmen also in der Analyse überein. Doch was tun? Wohin kann es gehen mit dem Lernen?

Vielleicht lohnt es, einen Begriff, den er ins Spiel gebracht hat, weiter zu verfolgen: Schule. Für Stefan ist es wichtig, Lernen effektiver zu machen durch “Mischung” und durch “Lernen durch Lehren”. Anfänger und Fortgeschrittene lernen zusammen und voneinander. Je nachdem um welche Lerninhalte es geht, sind unterschiedliche Mischungen förderlich. Geht es um Fachkompetenz, dann mögen unterschiedliche Fortschrittsgrade zusammen lernen, geht es um soziale Kompetenz, dann vielleicht unterschiedliche soziale Gruppen oder behinderte Menschen mit gesunden.

Das ist schon mal ein guter Gedanke, finde ich. Die üblichen Kurse legen ja eher Wert auf Homogenität. Und da sie meist vollgepackt sind mit Stoff, wird der Austausch nicht gefördert und auch kein Raum zum Lernen durch Lehren geboten. Dann ist das Training zwar kurz (2-3 Tage) – das freut den Chef. Aber das Ergebnis ist, naja, oft nicht nachhaltig.

Damit haben die üblichen Kurse natürlich immer noch Zweck. Aber der ist womöglich ein anderer als der intendierte. Nützlich sind sie als Impulsgeber. Oder sie helfen zu motivieren. Einen Überblick können sie auch geben. Aber viel mehr ist nicht drin. Am Ende ist der Teilnehmer schnell wieder allein. Und dann oft ratlos. Wie war das doch gleich im Kurs? Da funktionierte es doch noch…

Mit dem Clean Code Developer Camp bemühen wir uns nun schon, das ein wenig besser zu machen. Gerade bei den 2 x 5 Tagen gibt es Raum für´s Lehren durch die Teilnehmer. Und eine Pause von 1-2 Wochen zwischen den Blöcken lässt Zeit zur Reflexion. In den nächsten Block kommen die Teilnehmer dann schon gleich mit Fragen aus der Praxis. Zusätzlich gibt es ein Diskussionsforum nur für die Teilnehmer, in dem sie jederzeit Fragen stellen können. Auch nach dem Kurs. Dort können sie sicher sein, dass man sie versteht, weil die Forenmitglieder durch dieselbe Erfahrung des Camps gegangen sind.

Aber wie gesagt: 5 Tage oder noch länger hören sich für manchen wie eine Drohung an. Den “Kickstart”, den so ein kompaktes Training bietet, kann und will nicht jeder bekommen.

Woher kommt denn überhaupt das “Training en bloc”? Wer will das? Es ist so weit verbreitet, dass es wie “gottgegeben” aussieht.

Einer, der es sich wünscht, ist sicher doch der potenzielle Teilnehmer. Der sucht “Erkenntis sofort”. Am besten alles in 1-2 Tagen. Leider funktioniert das nicht mit allen Themen. Und mit dem Lernen funktioniert es eh nicht so gut. Lernen ist Veränderung. Veränderung braucht Zeit. Doch erstmal zählt der Wunsch, die Nachfrage. Wenn die da ist, dann gibt es eben auch ein Angebot dazu.

Der andere, der sich en bloc Trainings wünscht, ist allerdings auch der Anbieter. Mit einem Blockangebot ist er mit größerer Reichweite attraktiv. Für 1, 2, 3 Tage reisen Teilnehmer auch mal von weiter her an. Das Training wird also mit weniger Mühe voll.

Die Parameterwerte des üblichen Lernens sind also: Zuhören (und ein wenig Übung), Homogenität der Lerngruppe, einmaliger Blockunterricht, Überregionalität.

Wenn ich nun auf der Suche nach neuen, effektiven und attraktiven Lernformen bin, um die nötigen Veränderungen in der Softwareentwicklung in die Betriebe zu bringen, wie wäre es, einfach mal diese Parameterwerte zu negieren? Sozusagen frei nach Nietzsche: Umwertung aller Werte.

Dann würde “modernes Lernen” so aussehen:

• Viel Übung, viel selbst erarbeiten, viel selbst weitergeben – statt Zuhören;  also Aktivität statt Passivität. Das beschreibt für mich auch die Atmosphäre, von der Boas Enkler in einem Kommentar zu meinem vorherigen Posting spricht: eine Atmosphäre, “in der Fehler gemacht werden dürfen und dennoch jeder danach strebt sich zu verbessern.”
• Heterogene Lerngruppe, in der die Interaktionen zwischen den Lernenden gefördert werden. Die Lerngruppe homogenisiert sich sozusagen selbst. Das schafft Vertrauen untereinander und erweitert den Horizont. Die Herausforderung an den Unterricht ist dann natürlich, dass er für jeden etwas bietet. Niemandem soll langweilig werden, niemand soll abgehängt werden. Jeder kann in seiner Geschwindigkeit lernen. Dazu sind auch Pufferzeiten nötig, denke ich, in denen Langsamere wieder etwas aufholen können.
• Abschied vom Blockunterricht. Stattdessen findet der Unterricht in mehreren “Sitzungen” statt. Warum nicht jede Woche 1 Tag Unterricht? Damit wäre über längere Zeit auch die Forderung des CCD-Wertesystems nach 20% Fortbildungszeit erfüllt. Zwischen den Unterrichtstagen wäre dann Pause, so dass weiter mit Hausaufgaben gelernt werden könnte. So ergeben sich auch die eben erwähnten Pufferzeiten ganz natürlich. Zudem ergeben sich in diesen Pausen sicherlich Fragen aus der Praxis an den Lernstoff, so dass der Unterricht viel praxisbezogener sein kann.
• Wenn Unterricht nicht mehr in Blöcken stattfindet, ist er quasi notwendig auch nicht mehr überregional. Denn wer würde schon über z.B. 5 Wochen jeweils 1 Tag von Berlin nach Frankfurt reisen, um dort an einem Kurs teilzunehmen? Wochenweises Lernen wäre also regional. Das hätte auch den Vorteil, dass sich im Unterricht Menschen treffen, die auch anschließend noch einen Kontakt halten könnten (z.B. durch Begegnungen in User Groups oder bei “Alumni-Veranstaltungen”).

Hm… irgendwie finde ich diese Vision charmant. Schulbank drücken statt “Druckbetankung”. Berufsbegleitendes Lernen. Jede Woche ein Lernhäppchen. Ich glaube, das hätte für alle Beteiligten Vorteile.

Lernpräsenz in Zeiten der Krise – aber wie?

Na, schön, wenn alle von der Krise reden, dann frage ich mal, wie denn in Zeiten derselben gelernt werden soll? Oder ist Lernen in der Krise gar kein Thema. Ja, so mag es scheinen. Die Ausbildungsetats vieler Firmen sind dieser Tage sehr, sehr klein geworden. Das ist natürlich komplett kontraproduktiv. Genauso wie Entlassungen.

Die Krise kommt, die Leute gehen, das Wissen bleibt stehen. Hinterher ist man dann dümmer als Unternehmen.

Aber schon recht, so ganz ignorieren kann man die Krise auch nicht. Wie könnte also beides überein gebracht werden: das Arbeiten und das Lernen. Insbesondere, wenn es viel zu tun gibt beim Lernen.

Das Clean Code Developer (www.clean-code-developer.de) Wertesystem mit seinen Bausteinen ist da ein Modellfall, würde ich sagen. Da gibt es eine ganze Menge zu lernen. Nicht nur Technologie, wie es die meisten gewohnt sind, sondern vor allem neue Gewohnheiten, neues Denken stehen bei CCD auf dem Programm.

Eine erste Hilfestellung geben die Grade. Sie teilen die Bausteine in Häppchen ein, die man als Lernpillen besser schlucken kann. Wenn man dann aber mehr will, was dann? Wenn man schneller mit CCD starten will, was dann? Denn der selbstgeführte Weg durch die Bausteine – gerade wenn man ihn allein gehen will oder muss – ist steinig. Bau-steinig sozusagen ;-) Ob man WCF oder einen O/R Mapper richtig einsetzt, dazu bekommt man beim autodidaktischen Lernen recht gut Feedback von der Anwendung. Die funktioniert oder nicht, die ist schnell genug oder nicht.

Bei CCD ist es aber anders. Das Feedback ist nicht so klar. Der Code gibt nur schlecht Auskunft darüber, ob er änderbar ist. Metriken könnten befragt werden – aber die sind oft recht pauschal. Am Ende kann eigentlich nur Erfahrung Feedback geben. Für die braucht es aber entweder viel Zeit, um sie selbst zu gewinnen – oder einen Partner.

Insofern liegt die Frage nahe, wie es mit einer CCD-Ausbildung aussieht. Kann man schneller zu CCD-Erfahrung und neuen CCD-Gewohnheiten kommen, mit Hilfe von außen. Klar. Das CCD Camp beweist es. Das Feedback der Teilnehmer war und ist immer noch einhellig positiv.

Allerdings: Einige Projekte der Teilnehmer begleite ich und sehe, wie schwer es ist, selbst das, was man im Verlauf von 2 x 5 Tagen gelernt hat, unter Projektdruck einzusetzen. Der Druck presst es schnell raus aus dem Projekt und die Einschätzungen in Bezug auf die angemessene Anwendung der Bausteine ist noch nicht sicher.

So frage ich mich denn, wie kann Lernen noch effektiver sein? Lernen in Präsenz anderer, also nicht rein online, durch Buch und autodidaktisch, ist schon eine gute und wichtige Sache. Die Krise macht Chefs demgegenüber aber sehr sensibel. Solche Lernen in Präsenz führt dazu, dass Mitarbeiter nicht am Arbeitsplatz sind. 2 x 5 Tage scheinen da schnell zuviel. Und das verstehe ich durchaus auch.

Ich meine allerdings, dass die Lösung nicht lauten sollte, auf Lernen in Präsenz zu verzichten. Die Herausforderung muss vielmehr darin liegen, es geeignet aufzubereiten. Erfolge stellen sich nur beim Präsenzlernen wirklich schnell ein. Herausforderung 1: Sie müssen dann nur noch nachhaltiger gemacht werden. Herausforderung 2: Sie müssen in diesen Zeiten ohne massive Abwesenheit vom Arbeitsplatz erreichbar sein. Aber wie?

Inhouse Schulungen halte ich für keine Lösung. Sie holen den Mitarbeiter auch vom Arbeitsplatz weg – aber nicht richtig. Da kann keine wirklich fokussierte Lernatmosphäre entstehen. Die meisten sind mit einem Ohr immer am Telefon.  Außerdem lernt man da nur mit den Kollegen. Der Blick über den Tellerrand ist gering und eingefahrene Verhältnisse behindern womöglich zusätzlich.

Also: Wie denn aber sonst? Ich bin überzeugt, dass es nötig und möglich ist, Lernen in Präsenz besser und attraktiver zu machen. Auch und gerade für all die, die sich in der Krise fühlen.

Willen zur Softwarequalität bekunden – Erste CCD Commitments [OOP 2009]

Die YooApplications AG in Basel tut es. Und die G-TAC IT-Beratung tut es auch. Beide bekunden öffentlich ihren Willen zu mehr Softwarequalität durch Arbeit nach dem Clean Code Developer (CCD) Wertesystem (www.clean-code-developer.de):

Das finde ich sehr cool! Denn durch solch ein Zeichen verändert sich die Welt schon ein Kleinwenig zum Besseren. Ein Kunde hier, eine Kunde da stolpert darüber und merkt, dass man zu Softwarequalität überhaupt einen Willen haben kann. Dass es scheinbar irgendwie etwas Besonderes bzw. Unterscheidendes ist, seine Arbeitsweise herauszustellen. Dann fragt er nach, dann denkt er nach, dann sucht er hoffentlich ähnliche Hinweise auch bei anderen Softwareanbietern. Dann steigt hoffentlich sein Bewusstsein in Bezug auf die innere Qualität von Software. Dann will er hoffentlich in Zukunft nicht mehr weniger als Software, die dem CCD-Wertesystem entspricht.

Mutig finde ich diese Bekundung aber auch. Denn wenn solcher Wille erstmal öffentlich gemacht ist, kann einer daherkommen und nicht nur interessiert fragen, worum es denn bei CCD ginge, sondern am Ende womöglich mehr wissen wollen. Vielleicht möchte er die “Auswirkungen” von CCD-gemäßer Arbeitsweise gar “sehen”? Wer sich so zu CCD bekennt, kommt also nicht umhin, CCD auch zu leben. Nicht perfekt, aber stetig strebend sich bemühend. Selbst wenn das mal lästig sein mag. Man hat´s ja aber bekundet, dass man es tut. Also muss man der Bekundung auch Taten folgen lassen. Das wird nicht jedem schmecken – und so werden sich auch nie alle zu solch einem Commitment hinreißen lassen.

Meine Hoffnung ist jedoch, dass das Beispiel der beiden Unternehmen Schule macht. Jetzt sind es zwei, morgen vielleicht drei, dann 4, 5, dann 10 dann 50 Unternehmen oder Abteilungen, die aufstehen und in solcher Weise öffentlich machen, dass sie keine Lust mehr auf “Crap” (Schrott) haben, sondern Qualität produzieren wollen und können. Dann wird Nicolai Josuttis hoffentlich doch noch widerlegt.

Auf ins Raumzeitalter! - Asynchron und verteilt mit dem Application Space

Software verteilen ist keine leichte Sache. Muss das so sein? Nein, ich glaube nicht. Wir machen es uns nur selbst unnötig schwer, indem wir immer wieder und weiter versuchen, in verteilten Systemen genauso zu kommunizieren, wie in lokalen. Corba, DCOM, .NET Remoting, Webservices, WCF: sie stehen alle in derselben Tradition. Sie alle favorisieren die synchrone, methodenbasierte Kommunikation zwischen entfernten Funktionseinheiten. Ihr Credo: Wenn service.TueEtwas() lokal der Ausdruck eines Servicewunsches ist, dann sollte das auch in verteilten Systemen so sein.

Bei aller Nachrichtenorientierung, in der inzwischen WCF angekommen ist, halte ich das jedoch für falsch. Darüber habe ich auch schon ausführlich hier im Blog geschrieben. Nur wie können wir es anders machen?

Klar, es gibt Alternativen. Es gibt Technologien für asynchrone, nachrichtenorientierte, event-driven Architekturen. MSMQ/System.Messaging gehört dazu und aufbauend darauf z.B.  Mass Transit oder NServiceBus. Von größeren und teureren Werkzeugen will ich gar nicht reden.

Trotz dieser Ansätze bin ich jedoch nicht zufrieden gewesen. Denn Messaging - obwohl das für die Verteilung  "ehrlichere" Konzept als der Methodenaufruf - ist irgendwie auch einschränkend und immer etwas schwergewichtig. Die Einschränkung liegt im Fokus auf den "Röhren" zwischen Funktionseinheiten. Die halte ich aber für einen Sonderfall. Und die Schwergewichtigkeit liegt im API. Messaging ist eben eng verbunden mit MSMQ. Und Messaging konzentriert sich auf die Verteilung.

Nun bin ich froh, sagen zu können, dass meine Zufriedenheit gerade sehr gestiegen ist. Denn ein Projekt, an dem ich schon einige Zeit beteiligt bin, trägt nun erstmalig öffentliche Früchte. Zusammen mit der TU Wien kann ich im Rahmen der Xcoordination Unternehmung (www.xcoordination.com) bekannt geben, dass wir die erste CTP unseres Xcoordination Application Space (AppSpace) bei CodePlex veröffentlicht haben: http://xcoappspace.codeplex.com.

Nach Vorversuchen und Andeutungen ist nun live, wovon wir meinen, dass es das Verteilen von Software sehr viel einfacher machen kann. Der AppSpace ist damit einerseits tatsächlich als Ersatz für z.B. WCF gedacht - auf der anderen Seite lieben wir aber auch WCF.

WCF ist cool. WCF ist breit und tief und universell. Das ist super! Aber wir glauben nicht, dass WCF einen API bietet, den der Durchschnittsentwickler direkt nutzen sollte, um seine Software zu verteilen. Der Preis für WCFs Mächtigkeit ist schlicht Komplexität und damit geringe Usability.

Der AppSpace verbirgt diese Komplexität nun. Er bietet aufbauend auf WCF und anderen Kommunikationstechnologien einen API für die lokale wie die verteilte asynchrone Programmierung. Er abstrahiert von den Feinheiten der WCF.

Wir meinen, dass damit ein Sprung in der Verteilung von Software geschafft werden kann wie vom Win16/Win32 API zu VB1.0. 1990 konnte man Windows programmieren - aber es war sauschwer, mit dem Windows API in C direkt umzugehen. Nur Experten konnten also das Potenzial graphischer Benutzerschnittstellen ausnutzen.

Dann kam VB1.0 und alles wurde anders. Mit VB1.0 konnten plötzlich Millionen von Entwicklern graphische Benutzerschnittstellen programmieren. Dazu mussten Sie zwar gegenüber den bisherigen umdenken - Stichwort "Event-Driven UI" -, aber das war nicht so schlimm.

Ähnlich sehen wir den AppSpace. (Ein bisschen Größenwahn kann nie schaden, oder? ;-) Mit dem Programmiermodell des AppSpace hoffen wir auch, die Verteilung von Code einer viel größeren Gruppe von Entwicklern zugänglich zu machen.

Dazu ist zwar auch ein Umdenken nötig - Stichwort "Asynchrone Kommunikation" -, aber das wird hoffentlich nicht so schlimm. Vor allem ist der Gewinn doppelt, wenn man sich auf diesen Paradigmenwechsel von synchron nach asynchon einlässt. Nicht nur wird die Verteilung einfacher, man bekommt auch noch die lokale Parallelverarbeitung gleich dazu.

Und warum soll nun der AppSpace der Bringer sein gegenüber anderen Messaging-Technologien? Weil sich der AppSpace eben nicht nur um Messaging dreht. Messaging ist für ihn ein Sonderfall. Oder Messaging passiert für ihn "unten drunter".

Das zentrale Konzept beim AppSpace sind vielmehr Dienstleistungskomponenten. Er bleibt also so dicht wie möglich an der Objektorientierung und der synchronen Komponentenorientierung. Deshalb bietet er auch eine DI Container Schnittstelle. Er holt die Entwickler da ab, wo sie heute stehen: bei den synchronen Komponenten. Und dann bietet er ihnen schrittweise mehr. Zuerst unterstützt er sie auf der Basis der Microsoft Concurrency Runtime dabei, von lokal synchron auf lokal asynchron umzusteigen. Und dann unterstützt er sie beim Umstieg von lokal asynchron zu entfernt asynchron.

Das halten wir für eine natürliche Progression im Denken und in der Codierung. Wer gelernt hat, lokal asynchron zu programmieren, der hat viel weniger Probleme, wenn es dann an die Verteilung von Code geht. Mit dem AppSpace bekommt er die Verteilung dann sozusagen geschenkt.

Für die, die nun ganz gespannt darauf sind, wie denn der API des AppSpace aussieht, hier ein Codeschnippsel. Mehr gibt es bei CodePlex und demnächst in der dotnetpro. Auch Beispielprojekte werden wir bei CodePlex einstellen.

So sieht der Kontrakt eines ganz simplen asynchronen Dienstes aus, der z.B. eine Zeichenkette empfängt und serverseitig ausgibt. Das ist trivial von der Funktionalität her. An dieser Stelle möchte ich aber nur zeigen, wie schlank der AppSpace API ist.

Asynchrone Komponenten haben keine Methoden, die man direkt aufrufen könnte, sondern definieren einen Satz von Nachrichten (Message Contract), die sie über typisierte Microsoft CCR Ports empfangen.

using Microsoft.Ccr.Core;
using XcoAppSpace.Core;

public class PPingContract : Port<string>
{}

Das ist die Implementation dies Kontraktes. Eine Klasse vom Kontrakt ableiten und für jede Nachricht eine Behandlungsroutine definieren:

public class PingService : PPingContract
{
    [XcoConcurrent]
    void ProcessPing(string text)
    {
        Console.WriteLine("processing: {0}", text);
    }
}

Und jetzt der Host für die Serviceimplementation. Zwei Zeilen Code reichen aus. Die asynchrone Dienstleistung "läuft" in der Instanz eines Application Space:

using(XcoAppSpace host = new XcpAppSpace("tcp.port=9001"))
{
    host.RunWorker<PPingContract, PingService>("pingservice");
    Console.ReadLine(); // keep the host running while waiting for connections
}

Der Client ist dazu symmetrisch! Das ist einer der Vorzüge des AppSpace. Das macht ihn einfach zu bedienen, weil die Zahl der zu lernenden Konzepte so überschaubar ist:

using(XcoAppSpace client = new XcoAppSpace("tcp.port=0"))
{
    PPingContract p = client.ConnectWorker<PPingContract>("localhost:9001/pingservice");

    p.Post("hello, world!");

    Console.ReadLine(); // keep client alive
}

Das ist´s so ziemlich. Wenn Sie den Code verstanden haben (und die CCR Grundlagen kennen), dann können Sie mit dem AppSpace lokal asynchron oder verteilt asynchron arbeiten. Rückhabewerte, Notifikationen, Publish/Subscribe... das alles ist mit den immer gleichen Mitteln leicht zu realisieren. Schauen Sie mal bei CodePlex vorbei, wo ich dieses Beispiel noch etwas ausgebaut habe.

Laden Sie den AppSpace aus dem Download-Bereich herunter und spielen Sie mal damit. Ich freue mich über jedes Feedback. Bei allem Anspruch ist der AppSpace ja nicht fertig. Er ist erst am Anfang. Wir bei Xcoordination glauben aber, dass die Richtung stimmt. Wenn Sie wollen, gehen Sie in diese Richtung mit. Erste kommerzielle Projekte sind schon vorausgelaufen und melden zurück, dass es sich lohnt. Bei CodePlex und www.xcoordination.com gibt es viel Platz zum Diskutieren. Und außerdem ist der Application Space eine Open Source Software. Die können Sie aber sogar kostenlos in Ihren kommerziellen Closed Source Projekten einsetzen.

Also, auf ins Raumzeitalter mit dem Application Space! Verteilung die einfach funktioniert.

Lass wachsen! Ein Bild für die Softwareentwicklung heute [OOP 2009]

So abstrakt und virtuell Software wie ist, fällt es oft schwer, darüber zu denken und zu reden. Schnell stellen sich unterschiedliche Bilden in den Köpfen der Gesprächspartner ein. Dann ist es hilfreich, konkret zu werden, um das Denken zu synchronisieren. Dabei helfen Analogien: eine Klasse ist z.B. wie ein Stempel, mit dem man viele Stempelabdrücke/Instanzen erzeugen kann.

Aber was, wenn es komplexer wird? Wie ist das mit einer ganzen Software? Hier ein Bild, über das ich gerade gestolpert bin:

 
Quelle: http://ecotopian.blogspot.com/2008/04/tree-shaping-tree-house.html

Das ist ein Haus. Und da wir in der Softwareentwicklung auch von Architektur sprechen, erlaube ich mir, es als Analogie für Software zu benutzen. Die Entwurfsmuster-Bewegung verweist ja auch ausdrücklich auf die Inspiration durch bauarchitektonische Konzepte.

Warum aber dieses Haus als Analogie? Weil es besonders ist: es ist nämlich nicht gebaut worden, sondern gewachsen. Dieses Haus besteht aus Bäumen, die "in Form gebracht" wurden. Tree Shaping nennt man das auch. Bonsais sind dagegen trivial. Hier ein weniger komplexes Beispiel für "Baumformung":

 
Quelle: http://indianblogger.com/2009/04/05/learn-growing-amazing-furniture-arborsculpture/

Häuser wachsen lassen, statt sie zu bauen. Das ist ein interessanter Gedanke aus ökologischer Sicht. Solche "Baumhäuser" sind nachhaltig und kostengünstig. Man braucht vor allem Zeit. "Leben in der Natur" bekommt dann eine ganz andere Bedeutung.

Aber zurück zur Softwareentwicklung: Warum ist ein solches gewachsenes Haus für mich eine Analogie für Software? Weil es sehr schön zeigt, wie Softwarearchitektur bzw. Softwarebau wirklich sind.

Die gewöhnliche Analogie "Hausbau" hinkt nämlich sehr schnell. Der Hausbau ist tausende Jahre alt und sehr effizient. Häuser sind heute hochmodular und werden extrem arbeitsteilig gebaut. Beides gilt für Software nicht.

Aber mit dem "Baumhaus" passt die Analogie wieder. Denn das "Baumhaus" ist nicht so arbeitsteilig errichtet worden, das "Baumhaus" hat eine wörtlich zu nehmende gewachsene Struktur, das "Baumhaus" ist rigide, es ist monolithisch. Schön anzusehen, funktional, aber im Grunde nicht mehr zu ändern. Und das sollte Ihnen bekannt vorkommen in der Softwareentwicklung.

Unsere Programme lassen wir auch wachsen. Wir haben eine Idee davon, wie sie aussehen sollen - und dann formen wir ihr Wachstum dahingehend. Wie beim "Baumhaus". Was dann rauskommt erfüllt die bei Beginn erkennbaren Anforderungen, ist jedoch starr. Die gewachsenen und weiter wachsenden Verflechtungen machen es immer schwerer, die Software zu ändern. Wie beim "Baumhaus".

So kommen Gebäude-Analogie und Software besser zusammen, finde ich. Wir können unsere Software wertschätzen für das, was und wie sie ist. So wie wir ein "Baumhaus" wertschätzen können.

Aber wir sehen auch ganz klar die Grenzen des "Baumhauses". Es ist nicht transportabel, es zu "bauen" dauert sehr lange, es ist absolut inflexibel. Und so werden uns im Umkehrschluss auch die Grenzen unserer "gewachsenen" Software deutlich.

Der Hausbau kann anders bauen. Warum sollten wir in der Softwareentwicklung das nicht auch können. Wir sind nicht auf "gewachsene Software" festgelegt. "Bonsai-Programme" müssen nicht sein. Wir können vom Hausbau und anderen Branchen noch einiges in Bezug auf Flexibilität und Effizienz lernen.