Was kommt nach WCF? Gedanken über die Grenzen der Nachrichtenorientierung

Um es gleich vorweg zu sagen: Ich find WCF schon toll. Aber - und dieses aber ist mir wichtig - WCF lässt in mir kein Gefühl von "angekommen sein" entstehen.

Toll an WCF ist die Vereinheitlichung, die es erreicht hat. COM+/Enterprise Services, .NET Remoting, Web Services und MSMQ sind in WCF zu einem konsolidierten Programmier- und Kommunikationsmodell zusammengeflossen. Äußerlich ist der Unterschied zwar marginal - es werden wie seit der Erfindung von RPC immer noch entfernte Funktionen direkt aufgerufen. Doch die konsequente Nachrichtenorientierung ist der Natur entfernter Kommunikation wesentlich angemessener als die bisherigen Versuche der Objektorientierung, ihren Siegeszug bei der in-process Kopplung von Codeeinheiten auch auf die cross-process oder gar cross-platform Kopplung auszudehnen. Corba, EJB, .NET Remoting heißen diese letztlich gescheiterten Versuche. RIP.

Also: WCF ist toll. Und doch...

Es will sich bei mir kein wohliges Gefühl der Zufriedenheit einstellen. Die Vereinheitlichung ist mir irgendwie nicht genug. Vereinheitlichung war zwar ein wichtiges Ziel, ebenso der konsequente Abschied von "verteilten Objekten" - aber ist WCF deshalb gleich das Ideal? WCF ist vielleicht der beste vereinheitlichte nachrichtenorientierte API, den es gibt.  Aber wollen wir eigentlich Nachrichtenorientierung? Ist funktionsbasierte Nachrichtenorientierung als einziges Kommunikationsmodell zwischen verteilten Codeeinheiten wirklich das wünschenswerte Abstraktionsniveau?

Ich werde das Gefühl nicht los, dass "es" noch anders gehen könnte und sollte. Zumindest als Alternative, wenn nicht als pauschaler Ersatz für WCF. Um das Gefühl mal zu konkretisieren, hier einige Punkte, die mir bei WCF aufstoßen. Lobeshymnen hören wir ja häufig genug. Also:

• WCF ist unehrlich
• WCF ist anti-autonom
• WCF ist kompliziert
• WCF ist starr
• WCF ist unintuitiv

So ganz allein stehe ich mit meiner Meinung, dass WCF bzw. allgemeiner die Nachrichtenorientierung irgendwie noch nicht das Ende der Fahnenstange sein kann, wohl auch nicht. Das renommierte Portal "The Service Side" (TSS) hat gerade ein "Space Based Architecture Knowledge Center" eingerichtet und Amazon hat unlängst einen Tuple Space (SimpleDB) als Beta in sein SaaS-Angebot gehoben. (Mehr zum Thema SimpleDB in bei meinem Open Source Projekt NSimpleDB.)

Spaces - so die Botschaft von TSS (mithilfe des Infrastrukturanbieters Gigaspaces) und Amazon - sind eine Alternative zur Nachrichtenorientierung. Spaces und Räume statt der ewigen Röhren. Warum nicht? Dem Gedanken bin ich sehr zugetan. Deshalb bastle ich mit an einem "Space-Angebot" - das aber noch eine Weile bis zum großen Auftritt brauchen wird. Deshalb habe ich das SimpleDB Datenmodell mit NSimpleDB auf den Desktop gebracht, um es leichter für Experimente verfügbar zu machen. Denn Experimente sind noch nötig, um die Reichweite des Space-Paradigmas abzustecken. In dieser Linie sehe ich auch dieses Posting: Als ein lautes Nachdenken über Space Based Architecture (SBA) oder Space Based Computing (SBC) oder Space Based Collaboration (SBC), mit dem ich mir selbst wieder ein Stückchen klarer über Nutzen und Grenzen von SBC/SBA werde. Ein probater Anfang ist dafür wie immer, mal die "pain points" zu benennen, wo mich das Existierende sticht.

WCF ist aus meiner Sicht unehrlich, weil ich die Syntax des Methodenaufrufs für das falsche Mittel halte, um einen Auftrag an eine entfernte Codeeinheit zu übermitteln. Einer Anweisung wie

resp = service.TueEtwas(req);

kann ich nicht ansehen, ob der Service lokal oder remote läuft. Läuft er aber remote, dann leistet die Syntax den vielzitierten "Fallacies of Distributed Computing" massiven Vorschub. Das halte ich für essenziell nachteilig im Hinblick auf Wartbarkei und Verständlichkeit und womöglich auch Skalierbarkeit und Performance. Ausführlich habe ich diesen Gedanken in einem Beitrag [PDF] für "SOA Expertenwissen" dargelegt.

In dem Beitrag erkläre ich auch, warum diese Form der "Auftragsübermittlung" für mich grundlegend anti-autonom ist. Sie formuliert einen Befehl, dessen syntaktische Form danach heischt, sofort ausgeführt zu werden. Sofortigkeit steht jedoch zum Einen im Widerspruch zur physikalischen Realität der Verteilung von Client und Service, zum Anderen ist sie aber auch unvereinbar mit dem simplen Hauptgrund einer Verteilung überhaupt: Autonomität. Verteilte Codeeinheiten sind verteilt, damit sie möglichst autonom über ihre Prozesse und Ressourcen entscheiden können. Wer jedoch autonom ist, der will sich nicht vorschreiben lassen, wann und wie genau er einen Dienstleistungswunsch erfüllt. Solchen Freiraum bietet die Form der Nachrichtenorientierung in WCF jedoch nicht.

Nun mag man das alles für Haarspalterei halten. Das fände ich zwar schade, weil Form und Funktion, Syntax und Semantik in einem Gleichklang stehen sollten. Wenn sich die Funktionsweise in der Form widerspiegelt, wenn klar erkennbar ist, wie etwas funktioniert, dann ist das Bild kohärent und wirkmächtiger. Dann ist weniger Raum für Missverständnisse.

Aber sei´s drum. Deshalb hier zwei hoffentlich handfestere Kritikpunkte: Ich finde WCF recht einfach für Allereinfachstes, aber kompliziert für sehr Typisches. Typisch sind für mich z.B. die asynchrone Benachrichtigung über Ereignisse in einem Service, typisch sind für mich daraus folgende Aufrufe des Service. Beides ist natürlich mit WCF möglich. Aber ich finde es recht kompliziert. Für eine simple Notifikation muss ich plötzlich über Duplexkommunikation nachdenken und ein Rückrufinterface registrieren. Und wenn ich dann in so einem Event den Service aufrufen möchte, dann geht es plötzlich um Reentrancy. Das kann man alles lernen. Klar. Aber das ist so typisch, dass ich den Lernaufwand und damit die Gefahr, etwas falsch zu machen, für zu groß halte.

Kompliziert wird es auch, wenn meine Services nicht (nur) an einer Adresse zu erreichen sind. WCF verlangt ja, dass ich die Adresse einer Dienstleistung festlege. Das finde ich starr. Reicht das starre Schema aber nicht, weil ich Mobilität oder Fehlertoleranz haben möchte, dann muss ich Klimmzüge machen oder gar orthogonal zu WCF mit Infrastruktur wie Clusterservern anfangen. Geht alles - aber könnte einfacher sein, finde ich.

Kollaboration statt Kommandoton

Schließlich: Mit WCF kann ich Nachrichten zwischen zwischen Parteien austauschen. Aber ist das Leben denn immer Nachrichtenaustausch, direkter Nachrichtenaustausch? Wer gewohnt ist, im Kommandoton zu sprechen und sofortige Ausführung erwartet, der ist mit Nachrichtenaustausch von oben nach unten in der Befehlshierarchie sicherlich zufrieden. Doch selbst das Militär hat inzwischen erkannt, dass sich mit Gehorsam allein kein Krieg gewinnen lässt. Krieg und Geschäftsleben, beide sind so dynamisch, dass autonome Entscheidungen ohne expliziten Befehl ganz vorne an der Front wichtig sind. Und Kriegsführung wie Geschäftsführung setzen daher auf Kollaboration statt Kommandoton, wenn´s darauf ankommt, wirklich etwas gebacken zu bekommen.

Kollaboration, d.h. selbstständige Zusammenarbeit an etwas Gemeinsamem, ist auch die natürlichste Arbeitsform. Dabei zwingt nicht der eine Kollaborateur den anderen, ihm - hopp! - einen Dienst zu leisten, sondern wünscht sich das sozusagen indirekt. In der Kollaboration ist Asynchronizität der vorherrschende "Antwortmodus" und Aufgaben werden "ausgeschrieben". Kollaborateure stehen um ein (mehr oder weniger handfestes) Medium herum, auf das sie gemeinsam blicken. Das kann ein Arbeitsplan sein, eine Geländekarte, eine Bauwerk, ein Tisch voll mit CRC-Cards, eine Inbox auf dem Schreibtisch oder auch ein Spielbrett. An diesem Medium arbeiten die Kollaborateure gemeinsam, damit bzw. daran teilen sie sich Aufgaben zu. Jeder behält dabei seine Autonomität, beobachtet das gemeinsame Medium, manipuliert das gemeinsame Medium. Und die von allen anerkannten Regeln, wie mit dem Medium umgegangen werden darf, sorgen dafür, dass die Kollaborateure trotz ihrer Autonomität einem gemeinsamem Ziel zustreben.

Also: Wo die Aktivitäten von autonomen Einheiten koordiniert werden sollen, geschieht das oft über einen "runden Tisch", ein gemeinsames Medium, um das sich alle versammeln. Da WCF nun eine Technologie ist, die die Zusammenarbeit von Codeeinheiten befördern will, liegt deshalb die Frage nahe, ob WCF jenseits des Kommandotons entfernter Serviceaufrufe auf die Kollaboration mittels gemeinsamen Mediums beherrscht? Die Antwort lautet nein. Für WCF ist die Arbeit an gemeinsamen Datenstrukturen kein Thema. Und genau das halte ich für ein großes Manko. Das macht WCF nämlich unintuitiv für den Einsatz in vielen Verteilungsszenarien. Schon ein simpler Chat oder ein verteiltes Spiel sind dafür gute Beispiele: Chat und Spiel (z.B. TicTacToe) sind triviale Kollaborationsaufgaben, bei denen die Beteiligten an einfachen Datenstrukturen gemeinsam arbeiten. Beim Chat ist das eine Liste von Nachrichten, beim Spiel ein zweidimensionales Array (Spielfeld). Von einer Technologie, die die Entwicklung verteilter Anwendungen erleichtern will, erwarte ich nun, dass sie mich auch unterstützt, diese natürliche Sichtweise im Code abzubilden. Das tut WCF aber nicht. Für WCF gibt es keine gemeinsame Liste, kein gemeinsames Spielfeld. WCF sagt: "Sieh zu, wie du es mit gegenseitig zugerufenen Befehlen hinbekommst, dass jeder Beteiligter denkt, es gäbe die gemeinsame Datenstruktur."

Das ist natürlich absolut legitim. Wenn WCF sich mit gemeinsamen, verteilten Datenstrukturen nicht abgeben will, dann ist das eine klare Aussage. Aber es bleibt dadurch eben auch eine Lücke. Manche oder womöglich eine ständig wachsende Zahl von Anwendungen haben es trotz WCF schwer. Bei ihnen geht es "nur" um Kollaboration und gleich eine Datenbank als gemeinsame Struktur aufzusetzen, wäre für sie Overkill. Kollaborationsinformationen sind oft nur kurzzeitig relevant.

Mit mehr Abstraktion in die Zukunft

Für mich ergibt sich damit ein "Wunschbild" wie folgt:

Der Stack der Kommunikationstechnologien wäschst weiter. Muss weiter wachsen. Alte Technologien werden nicht einfach ersetzt, sondern in der Relevanz nur zurückgedrängt. Es wird weiterhin Anwendungen geben, die direkt via Sockets kommunizieren müssen. Und das ist ok. Auch wird es Szenarien geben, in denen .NET Remoting Stärken gegenüber WCF ausspielt, d.h. entfernte Objekte gegenüber der  Nachrichtenorientierung einfach Abstraktionsvorteile bieten. Und warum auch nicht? Nachrichtenorientierung mit WCF wird natürlich auch ihren Platz haben. Keine Frage. Aber ich glaube, Nachrichtenorientierung tut gut daran, ihren Alleinherrschaftsanspruch über die Kommunikation in verteilten Anwendungen aufzugeben. Nachrichtenorientierung ist nicht das Gipfelkreuz auf dem Abstraktionsberg, sondern allenfalls ein Lager in großer Höhe.

Und was kommt nach bzw. oberhalb von WCF? Mein Tipp: Space Based Collaboration. Spaces sind nach 20 Jahren Forschung und kommerziellen Anläufen reif für die breite Masse. Performance und Netzwerkverfügbarkeiten sind hoch genug, um ihre Ansprüche befriedigen zu können. Abstraktion kostet ja immer etwas.

Aber Abstraktion bringt vor allem immer etwas: weniger Kopfschmerzen. Das halte ich für erstrebenswert. WCF ist gut und notwendig. Aber verteilte Anwendungen der unterschiedlichsten Art und Größe - von cross-thread Kommunikation bis global cross-platform Kommunikation - dürfen gern noch viel einfacher zu bauen sein. Spaces bieten da, meine Meinung nach, ein schönes und überfälliges Daten-/Programmiermodell. Denken in Räumen und Datenstrukturen, statt in Nachrichten und Röhren.

Tuple Spaces, JavaSpaces, GigaSpaces, SimpleDB... das ist erst der Anfang. Stay tuned!

Kommentare weg :-(

An die fleißigen Kommentarschreiber zu diesem Blog: Durch unachtsames Herumspielen mit den Einstellungen des Blogs bin ich zunächst über neue Kommentare einige Wochen nicht informiert worden - und habe sie mir dann heute auch noch beim Veröffentlichen in letzter Sekunde durch einen einzigen falschen Klick weggeschossen :-( Sorry! Ich gelobe Besserung. Jetzt sollte der Prozess aber wieder funktionieren.

Auf ein Neues also? Ich würde mich freuen.

Amazons SimpleDB at your fingertips

Dass ich an einer Open Source Implementation (NSimpleDB) von Amazons SimpleDB Datenmodell und API sitze, hatte ich ja schon berichtet. Bisher lief das Ganze allerdings nur lokal. Aber das war ok, denn ich wollte ja zunächst auch nur eine lokale Version zum Herumspielen für diejenigen, die noch keinen Zugang zum SimpleDB Betaprogramm bekommen hatten bzw. die, die einen so einfachen Datenbank-API für die Persistenz einfach auch lokal einsetzen wollen.

Nun habe ich inzwischen jedoch selbst Zugang zur SimpleDB Beta bekommen. Deshalb war es mir natürlich ein Anliegen, den Umgang mit Amazons online Tuple Space in meine Implementation zu integrieren. Da mein eigenes API-Serviceinterface ISimpleDBService schon "serviceorientiert", d.h. für eine Benutzung als Remote-Schnittstelle ausgelegt war, stellte das nun auch kein Problem dar.

Über dasselbe Interface lassen sich also nun sowohl Daten lokal wie online nach dem Amazon SimpleDB Datenmodell speichern und abfragen. Bisher ging das so lokal:

ISimpleDBService ts;

ts = new NSimpleDB.Service.VistaDb.VistaDbSimpleDBService("hello.ts");

...

ts.Close();

 

Aber jetzt geht es auch so:

ts = new NSimpleDB.Service.Amazon.AmazonSimpleDBService("<accessKeyId>", "<secretAccessKey>");

Einfach die AmazonSimpleDBService Implementation instanzieren, die von Amazon Ihrem AWS-Konto zugewiesenen Keys übergeben, fertig. An den sonstigen Operationen auf ISimpleDBService ist nichts zu ändern. Noch etwas mehr dazu in meinem englischen Blog.

Ich finde mein Interface für das Amazon Datenmodell ziemlich gradlinig. Etwas objektorientierter könnte es zwar noch hier und da sein, aber dennoch leicht zu bedienen. Für einen remote service passt es aber erstmal so, würde ich sagen. Wer damit herumspielen mag, kann von meinem NSimpleDB Open Source Projekt bei Google Code auch eine fertig übersetzte Assembly inkl. Demoprogramm herunterladen.

OOP 2008: Die Datenbank in den Wolken - Amazons SimpleDB

Wir kennen alle die Vorteile der RDBMS-Schwergewichte in unseren lokalen Netzen. Aber das Bild ist nicht ungetrübt. Unternehmensweit zugängliche Datenbanken machen Deploymentaufwand, kosten viel in der Administration und sind in ihren Schemata vergleichsweise starr. Das wird in einer immer mehr auf Vernetzung und Dynamik setzenden Geschäfts-/Softwarewelt zunehmend zum Problem. Aber wo ist die Lösung?

Natürlich gibt es nicht nur eine Lösung, sondern viele für unterschiedliche Szenarien. Manchmal reicht eine embedded database wie TurboDb oder VistaDb, manchmal ist eine objektorientierte Datenbank wie db4o angebracht, manchmal bringt ein Data Warehouse die Lösung.

Und nun bietet Amazon, die schon lange nicht nur Bücher verkaufen, sondern auch Web Services im Programm haben, eine weitere Datenbankoption: SimpleDB.

SimpleDB ist eine online Datenbank, die Sie per Web Service ansprechen können. Jeder Deploymentaufwand entfällt also. Und bei 100 MBit-Internetverbindungen, wie sie heute schon Privathaushalten für kleines Geld zur Verfügung stehen, ist es vom Geschwindigkeitsaspekt her letztlich nicht mehr so wichtig, ob eine Datenbank im LAN oder "in the cloud" liegt.

Wenn Sie einmal überlegen, wieviel Aufwand Sie bisher betrieben haben, um nur eine simple Datenspeicherung irgendwie im Internet, also weltweit zentral verfügbar, zu realisieren, dann können Sie das Potenzial erahnen, das in SimpleDB steckt. Gerade für die gemeinsame Nutzung von Daten über LAN-/Unternehmensgrenzen hinweg sind SimpleDB und die anderen Amazon Web Services wie S3 (Speicherung großer Datenmengen/Blobs) und SQS (Kommunikation via Warteschlangen) a godsend.

SimpleDB ist derzeit allerdings nur als Beta-Version verfügbar. Das Featureset ist also noch im Fluss. Dennoch ist es schon jetzt vielversprechend und spannend. Denn Amazon bewegt sich abseits des üblichen RDBMS-Pfades. SimpleDB implementiert nicht das relationale Datenmodell, sondern einen Tuple Space. Darin gibt es keine Tabellen mit Datensätzen, sondern so genannte Domains mit Items als Tuple:

Und die Tuple innerhalb einer Domain müssen keinem festgelegten Schema folgen. Und ihre Attribute können sogar mehrere Werte enthalten.

Das alles ist ganz anders als die vertraute RDBMS-Welt. Aber es ist vielversprechend, weil es einen viel dynamischeren Umgang mit Daten erlaubt. Wenn Datenbanken Verträge zwischen Applikationen sind und Applikationen, die über das Internet verbunden sind, sich nicht synchron verändern, dann ist es wichtig, dass ihre Verträge elastisch sind. Sie müssen eine wachsende Zahl von Bedürfnissen befriedigen. Ein fixes Schema wäre da kontraproduktiv. Amazons SimpleDB ist daher eine "Klebstoffdatenbank", die heterogene und/oder stark fluktuierende Parteien verbindet. Ihr Fokus ist die Flexibilität, nicht die Effizienz.

SimpleDB im lokalen Netz

Angesichts einer limitierten Anzahl von Beta-Konten für SimpleDB und dem Wunsch, das SimpleDB-Datenmodell mit seinem API nicht nur im Internet nutzen zu können, habe ich entschlossen, SimpleDB in einer Desktopvariante zu entwickeln. Die .NET SimpleDB (NSimpleDB) ist das Ergebnis. NSimpleDB bietet die Leistungen von SimpleDB in Form einer "embeddable tuple space engine". Sie können mit NSimpleDB im lokalen Netz so umgehen, wie mit SimpleDB im Internet. Das ist performanter, das ist kostengünstiger (weil SimpleDB am Ende ein kostenpflichtiger, wenn auch sehr günstiger Service ist), das ist auch mobil möglich, das ist einfacher.

NSimpleDB ist ein Open Source Projekt entwickelt in C#. Ich hoste den Code bei Google. Wer ihn selbst übersetzen will, ist dazu herzlich eingeladen. Mit Subversion können Sie ihn herunterladen. Wer dagegen nur eine fertige Komponente nutzen möchte, kann das auch. Ich habe ein kleines Beispielprogramm zum Download bereitgestellt; darin ist NSimpleDB.dll enthalten. Nur die Assembly ist nötig, um mit dem SimpleDB Datenmodell zu experimentieren.

Mehr über SimpleDB und den Umgang mit NSimpleDB erfahren Sie in meinem englischen Blog. Dort finden Sie eine mehrteilige Artikelserie zum Thema.

Über Feedback jeder Art würde ich mich freuen.

OOP 2008: Kaffeehauskonsultation in München - Schnupperberatung kostenlos

Anlässlich der OOP 2008 in München

werde ich mich wieder einmal einen Tag in ein nettes Kaffee verfügen  und Ihnen mit Rat&Tat zur Seite stehen. Ganz kostenlos!

Diese Kaffeehauskonsultation findet statt im Café Rothmund in der Münchener Innenstadt

in der Rothmundstr. 5 am 24.1.2008 von 10h bis 17h.

Wenn Sie eine Frage zum Thema .NET-Softwarearchitektur haben oder sich über systematische Softwareentwicklung von der Anforderung bis zu Test und Produktion informieren möchten oder Rat in Sachen "menschlicher Schnittstellenoptimierung", d.h. der Kommunikation/Wissensvermittlung im Team und zwischen Abteilungen suchen - dann melden Sie sich einfach für eine 90minütige kostenlose Konsultationssitzung per formloser Email bei mir an. Ich freue mich auf Sie!

OOP 2008: Zurück zum Papier - Leseempfehlungen für 2008

Das gute, alte Papier hat mich wieder.

Ich habe gerade ein Abo der "Traditionszeitschrift" aller Softwareentwickler bestellt, dem Dr Dobb´s Journal. Nicht obwohl, sondern weil es nicht .NET-lastig ist.

 

 

 

Und dann habe ich heute gleich noch ein Abo des in Deutschland recht unbekannten, aber nicht minder guten CoDe Magazines drauf gelegt. Das bietet immer wieder sehr gute Artikel zum Thema .NET.

 Neulich hat es mich auch überkommen und ich habe endlich auch das MSDN Magazine, die Entwicklerpostille von Microsoft, geordert. Die gibt es zwar auch monatlich kostenlos im Internet - aber was soll´s? Der USD steht grad so günstig.

Und völlig im Rausch habe ich mir Ende 2007 dann auch noch - quasi als Weihnachtsgeschenk - eine Mitgliedschaft bei der "Association of Computing Machinery" (ACM) gegönnt. Die haben ein exzellentes online Archiv wissenschaftlicher Artikel zu allen Informatikthemen der letzten Jahrzehnte. Da findet sich immer mal wieder sehr interessantes Hintergrundmaterial. Damit lege ich sozusagen mein Ohr an die Grasnarbe der Informatik. Das ist der ultimative Blick über den Tellerrand in die Forschung hinein. Die ACM-Hauszeitschrift "Communications of the ACM" bringt mir jeden Monat einen bunten Blumenstrauß an Themen ins Haus, die ich in den anderen sehr praxislastigen Publikationen nicht finde.

Aber damit nicht genug! Das sind ja nur meine neuesten Zeitschriftenerrungenschaften. Ohnehin schiebt mir der Postbote jeden Monat die dotnetpro, das dot.net Magazin und das OBJEKTspektrum durch den Schlitz. Und um auch mal etwas ganz anderes zu lesen, lasse ich auch noch brandeins jeden Monat in meinen Postkasten brummen.

Puh. Ganz schön viel zu lesen. (Ganz zu schweigen von den Bücherbergen an meinem Nachttisch...) Aber so spannend, so interessant. Naja, nicht immer alles in allen Publikationen... Aber genug, um durchgängige alle zu beziehen.

Damit komme ich zu meiner neuen Lesegewohnheit Nr. 1 für 2008: Ich werde konsequent nur noch das lesen, was 1. für mich relevant ist, d.h. zu meinen Arbeitsschwerpunkten .NET-Softwarearchitektur/-Test/-Softwareproduktion und "Softwarekollaboration" gehört. Darüber hinaus lese ich dann noch das, was 2. mein Interesse auf den ersten Blick erregt. Und das meine ich so: auf den ersten Blick. Ich werde mich nicht reinknien und lange überlegen, ob ich etwas lesen sollte, sondern zur Abwechslung mal mein Gefühl entscheiden lassen ;-)

Daraus ergibt sich dann direkt meine neue Lesegewohnheit Nr. 2: Ich beende die Lektüre einer Zeitschrift, wenn ich alle Artikel gem. Lesegewohnheit Nr. 1 gelesen habe. Dabei ist es egal, ob das 2 von 20 oder 18 von 20 waren. Ich habe keine Skrupel mehr, fast ungelesene Zeitschriften wegzuschmeißen. Insbesondere die wunderbaren online Archive von dotnetpro, Dr. Dobb´s, MSDN Magazine, CoDe Magazine, CACM und brandeins machen es mir leicht, die Zeitschriften wirklich in den Müll zu tun, statt Regalmeter damit zu füllen.

So erklärt sich auch meine Lesegewohnheit Nr. 3: Falls ich aus irgendeinem Grund selbst die nach Nr. 1 ausgewählten Artikel nicht bis zur nächsten Ausgabe geschafft haben sollte, dann schmeiße ich die Zeitschrift trotzdem weg. In diesem Punkt habe ich lange mit mir gerungen. Es schien mir nicht respektvoll gegenüber den Publikationen, sie nicht zu lesen, wenn ich sie schon habe. Und ich hatte das latente Gefühl, etwas zu verpassen. Aber beide Gefühle habe ich nun aufgegeben. Sie entstammen einer langen Prägung durch Mangel, wie er im Grunde immer herrschte - bis heute. Noch bis Ende der 1990er haben wir an Informationsmangel der einen oder anderen Art gelitten. Aber das ist nun endgültig vorbei.

Weder bin nicht respektvoll gegenüber den Publikationen, denn sie sind ja auch, wenn das Papier schon im Mülleimer ist, immer noch online zugänglich. (Naja, alle bis auf zwei ;-) Ich schmeiße also nur eine Manifestation der Arbeit der Autoren in den Müll, nicht deren Arbeit. Auf die kann ich weiterhin zugreifen.

Und auch das Gefühl des Verpassens ist überflüssig. Denn erstens kann ich alles in den online Archiven dann doch noch lesen. Ich verpasse höchstens etwas auf Papier. Zweitens aber - und das ist die für mich viel wichtigere Erkenntnis - ist heute nicht mehr der Artikel A in Ausgabe N der Zeitschrift Z wichtig. Er mag interessant sein, aber nicht wichtig. Denn angesichts des Contentüberflüsses, in dem wir heute bis zum Hals stehen, sind Themen nicht mehr mit einzelnen Veröffentlichungen gleichgesetzt. Klar, es mag ein Thema besonders gut in einer bestimmten Veröffentlichung behandelt sein. Eine konkrete Veröffentlichung ist natürlich auch immer die erste, die ein Thema aufreißt. Aber durch die Veröffentlichungsflut ist gewährleistet, dass wirklich wichtige Themen (langsam, aber sicher) auch zu mehreren Veröffentlichungen führen. Ich kann sie also auf Dauer nicht übersehen.

Insofern lehne ich mich ganz beruhigt zurück und vertraue auf Lesegewohnheit Nr. 1. Damit bleibe ich zu meinen Themen auf dem Laufenden. Und ich habe die Garantie, auch auf Inspirationen zu stoßen. Wenn nicht in dieser Ausgabe, dann in der nächsten oder übernächsten... Es gibt keinen Mangel an Inspirationsquellen. Also muss ich sie nicht suchen und sammeln, sondern kann mich an ihnen laben, wenn mir danach ist. Und da vertraue ich mal auf mein Gefühl beim ersten Blick.

Jetzt noch zu Lesegewohnheit Nr. 4: Ich lese wieder mehr auf Papier. Am PC lesen ist nett für das ad hoc Lesen, z.B. von Email oder einen Überblick. "Lesen zwischendurch" tue ich gern am PC. In elektronischen Inhalten kann ich leichter suchen und ich kann mich mit Links durch Inhalte hangeln. So kann ich entweder sehr gezielt auf Stoff zugreifen oder genau das Gegenteil tun: mir ein Themenfeld grob erschließen, indem ich wie mit dem Finger auf der Landkarte das Terrain schnell und aus großer Höhe vorerkunde.

Um dann aber eine Publikation von mehreren Seiten wirklich zu lesen, brauche ich Papier. Ja, immer noch. So sehr ich ein Freund von online Publikationen bin (ich schreibe ja immerhin auch dieses Block), so ist das Lesen von Publikationen immer noch etwas anderes.

Erstens sind Texte auf Papier immer noch besser zu lesen, als am Bildschirm. Daran ändern auch Amazon´s Kindle und die hübsch wie funktional aufbereitete digitale Ausgabe der CACM nichts.

Zweitens sind Texte auf Papier immer noch mobiler. Sie sind leichter und in der Form flexibler. Ich kann sie in eine kleine Tasche stecken oder am Frühstückstisch lesen. Selbst mit meinem 12" Laptop wäre das mit elektronischen Texten nicht so leicht.

Beide Gründe zusammen genommen - dazu noch der vorteilhafte USD-Kurs - waren für mich nun genug Anlass, das Jahr 2008 mit einer "Abo-Manie" zu beginnen. Denn die Abos liefern mir ohne weiteren Aufwand Inhalte auf Papier für´s leichte Lesen. Ich muss mir keine Gedanken über´s Wegschmeißen machen, da (fast) alle Inhalte auch noch komplett online verfügbar sind. Dafür bezahlte ich auch gern die Abo-Gebühr. Und schließlich ist es angenehmer, eine Zeitschrift in der Hand zu halten, als die ewigen doppelseitigen FinePrint-Ausdrucke.

PS: Ach ja, bevor ich es vergesse, es gibt noch eine Lesegewohnheit Nr. 5: Mehr redaktioneller Inhalt. Ich abonniere in Zukunft weniger Blogs in meinem RSS-Reader. Ein paar werden übrig bleiben von Autoren, die ich schätze und die sich wirklich kontinuierlich Mühe geben. Dazu zähle ich z.B. Jeff Atwood, Joel Spolsky oder Martin Fowler. Für die ist ein Blog keine Nebensache. Sie kippen nicht nur Datenschnippsel ins Internet. Dort findet vielmehr öffentliches Nachdenken über unsere "Kunst" statt. Für "Tipps & Tricks" von einer Produktgruppe in Redmond oder auch zum Thema XYZ abonniere ich kein Blog mehr. Schön, dass es auch solche Blogs gibt - aber für mich ohne Abo. Wenn ich mal Bedarf habe an solchen Inhalten, dann stolpere ich schon mit Google darüber.

Je technischer also ein Blog, desto weniger "abowürdig" ist es für mich. Oder besser: je weniger unmittelbar relevant für meinen Arbeitsschwerpunkt ein Blog ist, desto weniger "abowürdig" ist es. Denn wenn ich den ganzen Tag WinForms-Programmierung machen würde, dann würde ich auch ein technisches WinForms-Blog abonnieren - sofern das Blog für den Autor keine Nebensache ist und er sich Mühe gibt.

Der bewusste Umgang bei der Produktion von Inhalten wird mir immer wichtiger. Der, der produziert, soll mir Arbeit abnehmen, indem er filtert. Das ist insbesondere bei den Zeitschriften der Fall. Also lese ich mehr davon, statt unredigiertes im Web. Dafür ist mir meine Zeit zu schade. Wirklich Wichtiges kann ich ja auch bei den Zeitschriften nicht verpassen (s.o.).

So, jetzt aber genug für heute. Die Abos sind bestellt... Upps, eines habe ich noch vergessen Microsofts Architektur-Journal zu ordern. Das gibt es kostenlos auf Papier. Vier Mal im Jahr. Da kann ich nicht Nein sagen, oder? ;-)

OOP 2008: Open Source mit kommerziellen Tools - Adé Gewissensbisse

In der letzten Zeit habe ich einige Projekte dank Google Project Hosting ganz einfach in die Open Source Welt einbringen können. Da gibt es zum Beispiel einen Microkernel oder einen Software Transactional Memory oder den Code zu meiner aktuellen dotnetpro Artikelserie über Mustervisualisierung.

Mit dem kostenlosen Subversion kann man den Quellcode von Google herunterladen. Mit dem kostenlosen NUnit kann man die darin befindlichen Unit Tests laufen lassen. Und mit dem kostenlosen C# (oder VB) Express von Microsoft kann man den Code auch übersetzen. Nein, sogar nur mit dem .NET Framework und MSBuild sollte das möglich sein. Insofern haben mich bisher keine Skrupel geplagt, selbst mit einer kostenpflichtigen Visual Studio Version zu arbeiten. Die Nutzung der Quellen ist ja auch mit kostenlosen Tools möglich.

Aber jetzt habe ich doch Gewissensbisse bekommen. Denn jetzt werden die Projekte so groß (oder meine Bequemlichkeitsansprüche sind gewachsen ;-), dass ich sie nach und nach mit einem automatischen Build-Prozess ausstatten will/muss. Den Anfang macht die dotnetpro Mustervisualisierung dnpPatViz. So sieht deren Quellcodebaum aus:

Diese vielen Projekte halte ich nicht in nur einer Visual Studio Solution/Projektmappe, denn das ist einer echt komponentenorientierten Entwicklung abträglich. Um schnell einen Überblick über die Gesamtkorrektheit meiner Quellen zu bekommen, kann ich daher nicht einfach F5 in Visual Studio drücken, sondern muss viele Solutions übersetzen und dann eigentlich auch noch alle Tests laufen lassen.

Ganz klar also, dass da ein automatischer Build- und Testprozess her muss. Aber womit den aufsetzen? Mit MSBuild oder NAnt wäre wohl die übliche Antwort aus der Open Source Welt. Die sind ja kostenlos.

Doch dazu kann ich mich wirklich, wirklich nicht überwinden. MSBuild- und NAnt sind kostenlos - aber erfordern geradezu ein Studium. Wie lange soll ich mich denn in deren XML-Dialekte einarbeiten? Wieviel soll ich denn tippen, um mal ein paar Projekte zu übersetzen, zu testen und dann noch zu deployen oder in ein Repository zu laden usw.? Ne, tut mir leid, für solche Klimmzüge ist mir meine Zeit zu schade.

Dabei gibt es doch Alternativen. Die Automatisierung von solchen Alltagstätigkeit und noch ganz anderer Prozesse (z.B. FTP-Upload oder Steuerung einer VM) kann auch viel einfacher sein. Viel einfach! Sie muss auch nicht aus Megabytes von XML-Verhauen bestehen. Sie kann nämlich aussehen, wie ein Workflow. Zum Beispiel so:

Das ist das Build-Script für die Mustervisualisierung. Hübsch visuell, intuitiv zu verstehen, leicht zu lesen und ohne eine Zeile Doku zu lesen in wenigen Minuten von der Übersetzung des ersten Visual Studio Projektes über die automatischen Tests bis zum abschließenden ILMerge zusammengesetzt.

Das (!) nenne ich Produktivität.

Und möglich ist´s mit FinalBuilder, einem wirklich coolen Tool. Das kostet zwar ein paar Euro - aber macht nix. Das Geld, was ich bei kostenlosen Tools spare, das habe ich mit FinalBuilder locker, ganz locker schon beim ersten größeren Einsatz wieder reingeholt. Ganz zu schweigen vom nervenschonenden Effekt eines grafischen Tools für "Build Workflows". FinalBuilder ist aus meiner Sicht für den Build-Prozess das, was VB 1.0 mal für die Windows-Entwicklung war. Aber genug des Schwärmens.

Wenn ich oben noch von Gewissensbissen gesprochen habe... dann sind die inzwischen verflogen. Ich habe mich von ihnen verabschiedet und mich entschieden, auch meine Open Source Quellen mit FinalBuilder Scripts auszustatten.

Open Source ist ja auch nur das: Open Source. Es sagt nichts darüber aus, mit welchen Werkzeugen die Open Sources zu bearbeiten sind. Die können von mir aus gern kostenlos sein. Aber wenn ich schon für meinen Entwicklungsaufwand in Form von freien Quellen kein Geld bekomme, dann will ich mich nicht auch noch für Admin-Angelegenheiten oder Organisatorisches verbiegen und durch aufwändige MSBuild-/NAnt-Programmierung draufzahlen.

Kostenlose Quellen: ja. Kostenlose Tools, um mit den Quellen zu arbeiten: nur, sofern der Aufwand den Nutzen nicht übersteigt. Und die Grenze ist aber beim Build-Prozess überschritten. Deshalb habe ich jetzt keine Gewissensbisse mehr. Ein schönes Gefühl.