Bewerbung einmal anders - .NET-Job in Hamburg

Im schönen Hamburg wartet eine .NET-Herausforderung. Die Softwareschmiede Keep IT Simple (KITS) hat eine .NET-Entwicklerposition zu besetzen. Aber das allein wäre natürlich noch nicht Grund genug für ein Posting in meinem Blog. Zum einen ist KITS die Firma meines Mitgesellschafters Oliver Schmidt beim Professional Developer College. Zum anderen aber - und das ist viel wichtiger - sucht KITS Bewerber für sein Stellenangebot auf ungewöhnliche Weise!

KITS schreibt die Stelle nämlich nicht einfach aus und wartet dann auf eine Flut fingerdicker Bewerbungsmappen. Stattdessen stellt KITS einen Fragebogen ins Internet und bittet Interessenten für das Stellenangebot, ihn auszufüllen - und sich ansonsten weiterer Postsendungen zu enthalten.

Hier der Link zum Fragebogen:

http://www.prodevcollege-jobs.net/Angebote/KITS_Oktober2007.aspx

Was das? Der Fragebogen ist Teil der Dienstleistungen, die unser Professional Developer College im Bereich Recruitement anbietet. Wir machen ja nicht nur Rhetoriktrainings, sondern haben auch noch andere Ideen, die wir in kleinen Schritten implementieren. Und eine dient der Erleichterung der Bewerberauswahl für Softwarestellenangebote.

Unserer Meinung hat das traditionelle Verfahren der Bewerbung mit Bewerbungsmappen drei gravierende Nachteile:

1. Bewerbungsmappen kosten den Bewerber viel Zeit und Geld.
2. Bewerbungsmappen kosten den Stellenanbieter viel Zeit.
3. Bewerbungsmappen sind schwer vergleichbar.

All diese Nachteile lösen sich nun durch eine Bewerbung per Fragebogen in Luft auf:

• Der online Fragebogen kostet den Bewerber zwar einen Moment für´s gewissenhafte Ausfüllen, aber darüber hinaus kein Geld. Aber auch die Mühe ist nicht vergebens ausgewandt, selbst wenn der Bewerber die Stelle nicht bekommt. Denn die Bearbeitung des Fragebogens ist eine wertvolle Reflektion über die eigenen Fähigkeiten. Der Bewerber betrachtet sich für einen Moment von außen, durch die Brille des Stellenanbieters, und lernt so etwas über sich.
• Der Stellenanbieter muss sich nicht durch Seiten und Seiten gut gemeinter Bewerbungen wühlen, um hier und da für ihn relevante Informationen zu extrahieren. Stattdessen sieht er auf einen Blick in den ausgefüllten Fragebogen, wo ein Bewerber welche Qualifikationen in Bezug auf die Stelle hat. Durch den Fragebogen bekommt die Bewerbung eine übersichtliche Struktur, die dem Stellenanbieter dient.
• Da die von mehreren Bewerbern ausgefüllten Fragebögen dieselbe Struktur haben, kann der Stellenanbieter sie nebeneinander legen und sehr einfach vergleichen. Er bekommt sie sogar als XML-Dateien zugeschickt und kann sie mit einer speziellen Software aus- und bewerten lassen.

In größeren Unternehmen mit eigener Personalabteilung kann durch solche online Fragebögen auch die Bewerberauswahl effektiver als bisher auf die verschiedenen Schultern verteilt werden. Hatte bisher die Software-Abteilung eine zu besetzende Stelle gemeldet und die Personalabteilung den Rest gemacht und oftmals erst sehr spät den Stellenanbieter wieder in den Auswahlprozess einbezogen, so hat die Fachabteilung jetzt wieder mehr Kontrolle. Statt nur die zu besetzende Stelle zu melden, definiert die Software-Abteilung jetzt gleich einen für sie (!) relevanten Fragebogen. Die Personalabteilung kann ihn dann ergänzen und stellt ihn online.  Trudeln Bewerber, d.h. ausgefüllte Fragebögen ein, leitet die Personalabteilung die einfach zu einer fachlichen Vorauswahl an die Software-Abteilung weiter. Die muss sich dann nicht durch Bewerbungsmappenberge quälen, sondern nur hübsch strukturierte Fragebögen vergleichen und sich diesen oder jenen Bewerber für ein Telefonat oder persönliches Gespräch wünschen.

Wir - also Oliver und ich, d.h. das Professional Developer College - meinen, dass diese "Lastumkehr" für alle Stellenangebote, die konkret benenn- und durchaus auch quantifizierbare Kompetenzen suchen, eine enorme Vereinfachung des ersten Schrittes der Bewerberauswahl darstellt. Alle Beteiligten können nur Gewinnen.

Wer Interesse hat, heute schon seine Stelle mit so einem Fragebogen auszuschreiben, melde sich einfach kurz bei mir (s. Impressum von www.ralfw.de). In den nächsten Wochen werden wir diese Möglichkeit aber auch noch offizieller anbieten. Dazu gehören dann eine Applikation zur Definition von Fragebögen, das Hosting der Fragebögen und eine Auswertungsanwendung.

Wir freuen uns auf Feedback. Und Oliver freut sich über viele Bewerber :-)

Gesetze der Softwareentwicklung II

Das erste Gesetz der Softwareentwicklung ist scheinbar trivial und doch sehr wichtig. Nach ihm können wir nur eine "gute Software", d.h. eine Software mit wartbaren Strukturen für Anforderungen entwickeln, die wir kennen. Trivial ist das, weil es sich nicht nur selbstverständlich anhört, sondern im Grunde auch ist. Wichtig ist die explizite Formulierung dieses Gesetzes aber dennoch, weil die gängige Praxis in vielen Projekten im nicht Rechnung trägt. Denn da die Softwareentwicklung quasi schon sprichwörtlich nie alle Anforderungen kennt, sind die Softwarestrukturen immer suboptimal. Suboptimale Strukturen machen die Pflege von Software schwer und schwerer, also - so sollte man denken - investieren Projekte immer wieder Zeit, um die suboptimalen Strukturen zu verbessern. Sie würden dann quasi innehalten und für die implementierten Anforderungen die Strukturen verbesseren (Refaktorisierung), bevor weitere Anforderungen erfüllt werden. Dieses Innehalten kommt jedoch nur selten, sehr selten vor. Es scheint gegenüber dem Kunden (oder dem Chef als Vertreter der Kundschaft) keinen Wert zu haben. Deshalb wird dafür nicht systematisch Zeit eingeplant. Das Resultat: Die Struktur der Software verfällt über die Zeit. Die Entropie in ihr nimmt ständig zu, die Unordnung wächst (siehe auch Gesetz 4 der Softwareentwicklung).

Aber lassen wir diese Entwicklung von Qualität für einen Moment außer acht. Nehmen wir Gesetz 1 mal einfach nur als trivial hin. Nehmen wir auch einfach mal an, wir würden alle Anforderungen für eine Software kennen. Schaffen wir es dann wirklich, eine optimale Struktur für unsere Software zu planen? Nein.

Gesetz 1 definiert die entscheidende Voraussetzung für optimale Softwarestruktur, d.h. langlebige Software. Gesetz 1 sagt, ohne die Kenntnis aller Anforderungen kommen wir zu keiner langfristig guten Struktur. Anforderungskenntnis ist aber nur eine notwendige Voraussetzung, keine hinreichende. Denn leider gilt nicht nur Gesetz 1, sondern auch...

Gesetz 2: Optimale Strukturen lassen sich nicht aus Anforderungen ableiten

Selbst also, wenn wir die Anforderungen an Funktionalität, Performance, Wartbarkeit usw. kennen, dann können wir immer noch keine optimale Struktur für die Implementation ermitteln. Dafür gibt es zwei Gründe:

a. Auch wenn wir meinen, die Anforderungen zu kennen, kennen wir sie nicht wirklich. Wir kennen sie nicht wirklich, weil entweder der Kunde sie (noch) nicht wirklich kennt; er weiß also selbst nicht, was er will bzw.  braucht. Oder der Kunde hat die ihm tatsächlich bekannten Anforderungen - natürlich unwissentlich und ungewollt - nur unvollständig mitgeteilt. Oder es gab schlicht Übermittlungsfehler, die Anforderungen sind bei uns nicht verlustfrei angekommen; wir meinen sie zu verstehen, missverstehen sie aber in Wirklichkeit. Auf die eine oder andere Weise kann es also leicht passieren, dass wir zurück bei Gesetz 1 sind: Wir kennen die wahren Anforderungen nicht, sondern nur eine Untermenge. Damit lässt sich kein optimaler Start machen.

b. Selbst wenn wir nun aber die Kundenanforderungen wirklich, wirklich kennen sollten - was selten genug der Fall ist -, dann gibt es immer noch ein Problem bei ihrer Umsetzung: unsere Tools und Technologien. Unsere Branche ist wie kaum eine andere geprägt von ständigen Neuerungen. Materalien (APIs) und Werkzeuge (IDE, Sprachen usw.) sind in ständig wachsendem Fluss. Wir haben immer weniger Zeit, sie wirklich solide zu erlernen. Das bedeutet aber, dass wir immer wieder auf unangenehme Überraschungen bei ihrem Einsatz stoßen. Sie funktionieren nicht wie angenommen. Strukturen lassen sich aber nur für Bekannte Einsatzformen von Materialien und Werkzeugen planen. Wenn wir unseren Werkzeugkasten aber immer weniger beherrschen, er ständig wächst, dann können wir für ihn und mit ihm keine optimalen Strukturen entwerfen. Beispiel: Wer meint, der neue O/R Mapper funktioniert so und so und darauf aufbauend eine Architektur plant und dann stellt sich bei der Implementation heraus, der O/R Mapper funktioniert leider nicht so... der verlässt sehr schnell die scheinbar optimale Struktur und begibt sich in den Wald der ad hoc Anpassungen. Die widersprechen aber selbstredend jeder optimalen Struktur.

Wenn Gesetz 1 trivial erscheint, dann sollte Gesetz 2 zumindest bescheiden machen. Wir sollten nie annehmen, überhaupt die triviale Anforderung von Gesetz 1 erfüllen zu können. Es gibt genügend Gründe, warum wir entgegen jeder Annahme eben doch nicht alle Anforderungen kennen. Und selbst wenn... dann beherrschen wir unsere Materialien und Werkzeuge, die sich quasi immer im Vorläufigen bewegen, nicht wirklich. Wenn wir ein Problem nicht schon 2-3 Mal mit durchaus unterschiedlichen Technologien gelöst haben, oder wenn wir neue Probleme nicht schon 2-3 Mal mit derselben Technologie gelöst haben, dann können wir überhaupt keine optimalen Strukturen planen.

Optimale Strukturen sind nur dort möglich, wo wir sichere Kenntnis haben. Wer die Problemdomäne aber nicht 100% kennt oder wer seine Werkzeuge nicht 100% kennt, der kann nur suboptimale Strukturen entwerfen. Teams, die Auftragsentwicklungen machen, kennen die immer wechselnden Problemdomänen nicht, da ist Suboptimalität gar nicht zu vermeiden. Andere Teams machen jahrelang dasselbe; sie kennen die Problemdomäne aus dem Effeff. Sie leiden dann zumindest darunter, dass sie bei wachsenden Anforderungen keine wirkliche Konstanz in den Implementierungstechnologien haben.

Gesetz 1 und Gesetz 2 machen also deutlich, dass optimale Strukturen kaum geplant werden können. Kommunikationsschwierigkeiten und ewige technologische Unerfahrenheit stehen dem allemal im Wege.

Aber was, wenn wir mal träumen? Was, wenn wir mal ganz naiv annehmen, dass wir die Anforderungen doch wirklich, wirklich kennen und auch noch die Meister unserer Technologien sind? Dann tritt Gesetz 3 in Kraft.

.net kommt ins Kino! Wer kommt mit?

Endlich ist es soweit: Das Professional Developer College lädt zum ersten Mal zu einer Vortragsveranstaltung ein. Unter dem Titel ".net at the movies" - oder kurz: .net@movies - sollen Themen für .NET-Entwickler und -Architekten in ungewöhnlichem Rahmen und persönlicher Atmosphäre vermittelt und diskutiert werden.

Denn bei .net@movies ist der Titel Programm: Die Vortragsveranstaltung findet im ehrwürdigen Streit´s Kino in Hamburg statt. Moderne Technologie trifft Unterhaltungstradition. Stars aus der .NET-Community zum Anfassen für Teilnehmer in Kinosesseln, in denen schon Stars aus Hollywood gesessen haben. Das Streit´s ist ein Premierenkino, das schon Dustin Hofmann, Sophia Loren, Jürgen Prochnow Platz geboten hat.

"Facts & Fun" kommen bei .net@movies also zusammen:

Harte Fakten liefern am 17. Dezember 2007 ab 9h Dominick Baier und Christian Wenz zum Thema Web Security. Ein immer noch heißes Thema, von dem das College meint, dass es mit .net@movies in einem kleinen Rahmen auf den Punkt gebracht werden kann. Denn klein ist der Rahmen, da die Teilnehmerzahl auf 25 beschränkt ist, um wirklich allen ein Maximum an persönlichem Kontakt und Intensität zu bieten.

Mehr Infos zur Veranstaltung im Blog des Professional Developer College:

http://prodevcollege.blogspot.com/2007/10/netmovies-episode-i-web-security.html

Wir freuen uns sehr, noch in diesem Jahr, die episode I von .net@movies "herausbringen" zu können. Eine Veranstaltung in diesem Rahmen hat College-Mitgründer Oliver Schmidt und mir schon lange am Herzen gelegen. Und jetzt ist es soweit! Zwar bietet der Herbst schon einige Events zum Thema Web-Programmierung - aber davon lassen wir uns nicht schrecken. Wir glauben fest, dass ein so wichtiges Thema im Rahmen einer so klar kontourierten und fokussierten Veranstaltung auch im Dezember noch Entwickler interessieren wird. Welche größere Freude zum Jahresabschluss bzw. kurz vor einem neuen Jahr könnte es denn auch geben, als endlich mehr Sicherheit für die eigenen Anwendungen zu bekommen?

Es wird ein kleiner und daher sehr persönlicher und intensiver und langer Event zu einem zentralen Thema für Web-Applikationen - mit starken Experten "zum anfassen".

.net kommt also wirklich ins Kino. Kommen Sie mit!

Harmonie pur auf der Wies´n - Es traf sich das Vanatec EAC

Es gibt das reale, normale Leben und es gibt die Wies´n. Denn wie anders ist zu erklären, dass Menschen und Beziehungen in einem Festzelt in München auf dem Oktoberfest so anders aussehen können als gewohnt? Sehen Sie selbst...
Die Chefredakteure der Konkurrenzmagazine dot.net Magazin (links: Peter Monadjemi) und dotnetpro (rechts: Tilman Börner) prosten sich in trauter Eintracht zu:

(Bild entfernt auf Wunsch eines Abgebildeten.)

Oder hier: Peter Monadjemi und ich haben es mehrere Stunden lang sehr gut nebeneinander ausgehalten. Das Schunkeln ist kaum mit jemand anderem so schön wie mit Peter ;-) Und das, obwohl ich doch gar nicht für sein Magazin schreibe und nicht auf der Entwicklerveranstaltung seines Chefs auftreten darf. Auf dem Oktoberfest ist das aber nebensächlich:

(Bild entfernt auf Wunsch eines Abgebildeten.)

Aber nicht jedem bekommen die Getränke dort gleichermaßen. Bei aller guten Laune, die dotnetpro-Autor Jörg Neumann hatte...

...ist ihm das Kirschwasser nicht so recht bekommen. Schade.

Aber vielleicht hat es ja nur daran gelegen, dass Jörg keine ordentliche Grundlage gelegt hatte. Auswahl genug gab es dafür nämlich und Neno Loje - mit dem ich am Tag vorher noch eine dotnetpro.tv Folge gedreht hatte - bewies Voraussicht, sie zu nutzen:

Anlass für diese Zusammenballung von Medien und bekannten Experten aus dem .NET-Bereich das jährliche Treffen des Vanatec Expert Advisory Councel (EAC). Vanatec (www.vanatec.com) ist Hersteller eines der führenden O/R Mapper für .NET. Hier Chefentwickler Jan Blessenohl, der sich von der Arbeit an seinem Tool OpenAccess auch einmal ausruhen muss:

Um die Qualität von OpenAccess kontinuierlich zu verbessern und dabei so nah am Markt wie möglich zu bleiben, hatte Vanatec schon im Gründungsjahr das EAC bestehend aus einer Handvoll Experten ins Leben gerufen. Und so trifft sich das EAC jährlich mindestens einmal, um aus erster Hand zu erfahren, was sich bei OpenAccess/Vanatec getan hat, was die nächsten Pläne sind - und natürlich, um Feedback aus der Praxis zu geben.
Aber das strengt natürlich an. So ein ganzer Tag mit einem Haufen .NET-Experten am runden Tisch in hitzigen Diskussionen muss deshalb ein Gegengewicht bekommen. Das schafft Vanatec dann mit einem gemeinsamen Besuch beim Oktoberfest. Was könnte auch naheliegender sein, da Vanatec ja in München angesiedelt ist. Und so lösten sich auch in diesem Jahr wieder die eventuellen fachlichen Differenzen vom Tage in oktoberfestlicher Harmonie auf. Schön war´s!
PS: Hier noch der Beweis, dass ich auch da war :-)

Prosit!

Gesetze der Softwareentwicklung I

Ja, ja, ich weiß, bei der Softwareentwicklung ist immer alles immer wieder anders. "Es kommt darauf an!" ist die Antwort auf fast jede Frage nach Einsatz einer Technologie oder eines Konzeptes. Grundsätzlich stimmt das natürlich auch. Meistens. Oft. Wie auch sonst so im Leben.

Aber es lässt sich nicht leugnen, dass wir uns alle nach Gewissheiten und Regeln sehnen. Irgendwo muss es doch mal feste Standpunkte geben, oder? Absolute Ansatzpunkte für Hebel, mit denen wir die Welt aus den Angeln heben können.

Und tatsächlich, die gibt es. Bei mehreren Beratungsterminen in der letzten Zeit sind sie mir klar geworden. Heute während eines online Unterrichts zur Einführung in den .NET Framework (ja, damit experimentiere ich; wer Interesse an einem solchen ".NET Basics Personal Training" hat, melde sich gern bei mir per Email) ist mir dann noch ein weiterer "Baustein" eingefallen, der mich nun auch veranlasst, mal darüber zu schreiben.

Also bin ich mal so kühn und behaupte, dies seien fünf grundlegende Gesetze der Softwareentwicklung:

1. Strukturen können immer nur optimal für bekannte Anforderungen sein.
2. Optimale Strukturen lassen sich nicht aus Anforderungen ableiten.
3. Optimale Strukturen werden nie verlustfrei implementiert.
4. Strukturen, die für bekannte Anforderungen aus schon existierenden weiterentwickelt werden, sind nie optimal in Bezug auf die gesamte Anforderungsmenge.
5. Anforderungen werden durch implementierte Strukturen beeinflusst.

Der Begriff "Struktur" steht in den Gesetzen sowohl für die grobe wie die feine Organisation. Er bezieht sich also sowohl auf Auswahl und Anordnung von Anweisungen, Methoden, Klassen, Komponenten, Prozessen, Dienste usw. Gemeint sind auch nicht nur Bausteine auf unterschiedlichen Abstraktionsebenen, sondern ebenfalls ihre Anordnung, d.h. wie sie in Beziehung zueinander gesetzt sind.

"Optimale Strukturen" sind dann Strukturen, die nicht nur die funktionalen und nicht-funktionalen Anforderungen erfüllen, sondern auch etwas Luft lassen für neue Anforderungen bzw. unvermeidliche Fehlerbehebungen. Optimale Strukturen sind verständlich und wartungsfreundlich, flexibel und testbar. Bei ihrem Anblick sollen Sie ausrufen "Toll! Einleuchtend! Ideal!". Optimale Strukturen haben insofern auch immer etwas von einem Kunstwerk. Sie sollen auch "schön" sein. Aber nur "auch", denn ihr Hauptzweck ist ja die Erfüllung von knallharten Anforderungen.

Aber ich möchte mich auch nicht an der Optimalität festklammern. Statt "optimal" können Sie auch "gut" oder "sehr gut" oder ein noch weniger wertendes "angemessen" lesen.

Was bedeuten nun aber suboptimale Strukturen? Ist es schlimm, wenn eine Software nur eine suboptimale Struktur hat? Suboptimal bedeutet ja nicht, dass die Software nicht funktioniert. Sie erfüllt die "platten", gut greifbaren funktionalen und nicht-funktionalen Anforderungen des Kunden. Aber: Suboptimale Strukturen machen es schwerer als nötig, Änderungen einzuarbeiten. Seien es Fehlerbehebungen, Änderungen an Features oder ganz neue Features. Änderungsfreundlichkeit aber ist - so finde ich - ein hohes Gut - auf das viele Projekte leider de facto zuwenig Wert legen. Direkt nach dem Wert von Änderungsfreundlichkeit gefragt, finden Projektteams sie zwar womöglich wichtig. Aber wenn man dann in den Code schaut, spiegelt sich diese Wertschätzung nicht wider. Sie ist - sorry to say - oft ein Lippenbekenntnis, dass man - soviel zur Entlastung der Softwareentwickler - gern in die Tat umsetzen würde, aber nicht zu können glaubt, weil "eine höhere Macht" (Kunde, Chef) das nicht zulässt.

Insofern mögen die folgenden "Gesetzeserklärungen" oder "Erklärungen der Gesetze" auch helfen, "höhere Mächte" eine andere Sicht auf Software zu vermitteln.

Gesetz 1: Optimale Strukturen für bekannte Anforderungen

Dass optimale Strukturen nur für bekannte Anforderungen ermittelt werden können, ist eigentlich kaum der Erwähnung wert. Interessant ist hingegen der Umkehrschluss: Zu unvollständigen oder schwammigen Anforderungen lassen sich keine optimalen Strukturen finden. Das bedeutet nämlich für die Softwareentwicklung, deren Projekte notorisch unterspezifiziert sind, dass ihre Strukturen quasi notwendig immer suboptimal sind.

Das Wasserfall-Vorgehensmodell hat versucht, sich dagegen zu stemmen. Es basierte auf der Annahme, Anforderungen ließen sich vollständig ermitteln. Wie die Agilitätsbewegung inzwischen ja aber hinlänglich klar gemacht haben sollte, ist das allermeistens eine Illusion. Sie können die Anforderungen an eine Software nie vollständig erheben. Anforderungen sind ständig in einem mehr oder weniger schnellen Fluss. Jedes Release Ihrer Software implementiert also nur eine vorläufige Menge von Anforderungen, einen Schnappschuss.

Dazu kommt noch, dass Projekte so groß sein können, dass die schiere Menge der Anforderungen Sie zwingt, sie in mehreren Schritten zu implementieren, die jeweils nur eine Untermenge abdecken. Selbst also bei grundsätzlich bekannten Anforderungen können Sie nicht immer all diese Anforderungen auch zur Strukturierung heranziehen. Es würde schlicht zu lange dauern, bis der Kunde ein erstes Ergebnis erhält.

Das bedeutet: Da zu einem bestimmten Zeitpunkt entweder nicht alle Anforderungen bekannt sind oder nur eine Untermenge von Anforderungen berücksichtigt werden kann, hat Software immer eine suboptimale Struktur auf das "große Ganze" bezogen:

• Wenn nicht alle Anforderungen bekannt sind, dann muss die Implementierung der bekannten Anforderungen suboptimal in Bezug auf die erst später bekannte gesamte Anforderungsmenge sein. Das gilt auch, wenn die Struktur für die implementierten Anforderungen optimal ist! Siehe dazu auch Gesetz 4.
• Wenn Sie nur eine Untermenge bekannter Anforderungen implementieren, dann mag die Struktur in Bezug auf die Untermenge optimal sein - aber nicht gleichzeitig für alle Anforderungen.

Ohne weiteren Aufwand hat Software also immer eine suboptimale Struktur. Sie ist damit weniger als möglich und nötig änderungsfreundlich. Und das wird nicht besser, wenn Sie weitere Anforderungen implementieren. Zumindest nicht, wenn Sie nicht explizit etwas dagegen tun.

Gesetz 1 beschreibt etwas Unvermeidliches: Suboptimalität. Die Qualität von Software ist immer geringer als sie sein könnte, weil wir nie alle Anforderungen im Blick haben können. Wer Software entwickelt, sollte sich also vom Gedanken der Perfektion verabschieden. Die mag sich vielleicht noch für einen Sortieralgorithmus erreichen, aber nicht mehr für eine ganze Anwendung.

Allerdings ist Gesetz 1 keine Entschuldigung für schlechte Qualität! Es macht nur klar, das wir uns nach hoher Qualität immer strecken müssen. Es gibt dabei kein Ankommen. Zwischen dem, was ist, und dem, was am besten wäre, ist immer eine Lücke. Hoffentlich wird die immer kleiner im Verlauf eines Projektes, doch schließen können Sie sie nicht.

Insgesamt hohe Qualität oder vor allem Änderungsfreundlichkeit als Grundlage für ein langes Softwareleben ergibt sich damit nicht einfach so, sondern erfordert bewussten Energieeinsatz. Akzeptieren Sie Suboptimalität, aber stemmen Sie sich gleichzeitig dagegen.

Mehr dazu im nächsten Posting.

Mein aktuelles Steckenpferd: Software Transactional Memory

Früher hatte Vati die elektrische Eisenbahn als Steckenpferd. Und heute? Heute hat Vati einen Windows Media Edition PC, der ihn nicht mehr zur Ruhe kommen lässt ;-) Nur ich tanze da wohl aus der Reihe. Aber ich habe ja auch kein Auto. Die Media Edition interessiert mich nicht, dafür aber Software Transactional Memory (STM). Das (!) ist cool. Viel cooler als an einem PC rumzuschrauben :-)

Und was soll so ein STM? Der macht z.B. die Programmierung mit mehreren Threads einfacher. Statt den Zugriff auf gemeinsame in-memory Ressourcen durch ausgeklügelte Sperren zu synchronisieren, arbeiten Sie einfach mit Transactionen. Genau: Transactionen wie bei Datenbanken - nur eben nicht auf persistenten Daten, sondern im Hauptspeicher!

Wem das aber noch nicht cool genug erscheint, der kann damit auch ohne Multithreading Undo-Lösungen basteln. Und das nicht nur auf einer Ebene, sondern auch echt geschachtelt. Das kann nicht mal SQL Server :-)

Und wer das noch nicht cool findet, der kann auch verteilte Transaktionen fahren: Mit System.Transactions eine Transaction öffnen, auf SQL Server zugreifen und Veränderungen im STM vornehmen - und am Ende alles zusammen committen oder zurückrollen.

Hier das kanonische Beispiel für Transaktionen mit dem .NET Software Transactional Memory (NSTM) realisiert: Überweisung eines Betrags von einem Konto auf ein anderes.

    1 INstmObject<double> myAccount;

    2 INstmObject<double> yourAccount;

    3 

    4 myAccount = NstmMemory.CreateObject<double>(1000);

    5 yourAccount = NstmMemory.CreateObject<double>(500);

    6 

    7 using (INstmTransaction tx = NstmMemory.BeginTransaction())

    8 {

    9     double amountToTransfer = 150;

   10 

   11     myAccount.Write(myAccount.Read() - amountToTransfer);

   12     yourAccount.Write(yourAccount.Read() + amountToTransfer);

   13 

   14     tx.Commit();

   15 }

   16 

   17 Console.WriteLine("My account balance: {0}", myAccount.Read());

   18 Console.WriteLine("Your account balance: {0}", yourAccount.Read());

In Zeile 16 hat der Transfer entweder komplett geklappt oder gar nicht. Inkonsistenzen, die durch einen Fehler in der Verarbeitung (Zeilen 9 bis 12) auftreten könnten, haben keine Chance, nach außen "durchzulecken". Wie gesagt: das ist wie mit Transaktionen bei Datenbanken. Wer sich den Code genau ansieht, wird das feststellen und auch sehen, dass er sehr dicht an Code ist, den man mit "normalen" Variablen geschrieben hätte.

NSTM ist mein Versuch der Implementation von STM, nachdem ich von dem Konzept neulich gehört hatte. Da war ich fasziniert und hab ne Menge drüber gelesen. Aber dann musste ich es einfach ausprobieren. Allemal, da die verfügbaren Implementationen alle irgendwie hinken. Entweder in Java realisiert oder unter Zuhilfenahme von Unmanaged Code oder nur für Haskell oder irgendwie nicht dem "normalen" Programmiermodell entsprechend, das wir von Transaktionen kennen. Also hab ich das gemacht, was alle Entwickler gern tun: ich habe meine eigene Infrastruktur gebastelt. Und es hat Spaß gemacht :-)  Aber dafür ist ein Steckenpferd ja auch da.

Wer mehr über NSTM erfahren will, kann in meinem englischen Blog eine ausführliche Darstellung lesen. Das Thema hab ich für international interessant gehalten und deshalb dort zuerst darüber geschrieben. Man sehe es mir in der deutschen Community nach.

WCF Literaturhinweise

Der ganze Indigo-Hype ist an mir früher genauso vorbeigegangen wie es heute der Orcas-Hype tut. Ich habe einfach keine Zeit, mich mit Technologien zu beschäftigen, die so wenig real sind und noch so unbestimmt weit in der Zukunft liegen. Vielen von Ihnen wird es nicht anders gehen.

Jetzt aber ist Indigo real und heißt Windows Communication Foundation (WCF) und ist echt cool geworden. Und jetzt lohnt es sich auch, sich damit näher auseinanderzusetzen. Auch ich habe mich deshalb auf den Weg durch das WCF-Labyrinth gemacht. Wie bei Jules Vernes "Reise zum Mittelpunkt der Erde" stellt sich dabei allerdings die Frage: Wo einsteigen in die unterirdischen Gänge? Was ist der Snaeffellsjökull für die Reise durch WCF? Welche Gänge sind anschließend zielführend? Was gibt es überhaupt zu entdecken? WCF ist ja so groß, so groß.

Nachfolgend finden Sie quasi meine Expeditionsaufzeichnungen, d.h. die Literaturstationen, die ich auf meiner Reise durch WCF als hilfreich empfunden habe. Vielleicht helfen sie Ihnen ja auch beim Einstieg in das Thema. Google macht am Ende zwar recht glücklich bei der Wegfindung - aber braucht viel Zeit. Ich würde mich also freuen, wenn Ihnen diese Quellenliste Zeit sparte.

Aber Achtung: Meine kleine Landkarte für WCF erhebt keinen Anspruch auf Vollständigkeit. Sie ist subjektiv, d.h. geprägt von meinen persönlichen Interessensgebieten in Bezug auf WCF. So bekümmere ich mich z.B. nicht um Aspekte der plattformübergreifenden Kommunikation. Aber auch zu meinen Interessengebieten sind natürlich nicht alle Quellen zu finden, weil es erstens eine unüberschaubare Vielzahl gibt und zweitens nicht alle lesenswert sind.

Wenn Sie nun mit diesen Einschränkungen leben können oder - positiver ausgedrückt - meinen Fokus teilen, dann wünsche ich viel Spaß beim Lesen:

WCF Ressourcen

• Windows Communication Foundaton, MSDN
• Windows Communication Foundation, MSDN Library
• .NET 3.0 Community
• .NET 3.0 Download
• MSDN Magazine "Service Station" Kolumne
• Christian Weyers Blog "Smells like service spirit"

WCF Einführungen und Überblicke

Bücher

• Juval Löwy, Programming WCF Services, O'Reilly 2007
  Scheint mir derzeit die umfassendste Darstellung von WCF zu sein. Sehr detailreiche Darstellung, für einen ersten Einstieg im Grunde zuviel. In jedem Fall aber ein must-have als Nachschlagewerk. Gut gefallen hat mir der Versuch am Ende des Buches, "WCF Coding Standards" aufzustellen, d.h. knackige Dos and Donts zu formulieren.
  Die Kehrseite der Medaille ist, Juvals Darstellung ist zu einem großen Teil feature fucking. WCF wird weitestgehend ohne Anwendungszusammenhang dargestellt; der Leser wird mit dem Transfer in die Praxis, d.h. mit dem Abwägen der vielfältigen Optionen alleingelassen. Auch kann man geteilter Meinung darüber sein, ob Juval das Thema konzeptionell optimal angeht. Seine Beschreibungen lassen eine, hm, gewisse Verhaftung mit der guten alten COM+/Enterprise Services Welt vermuten. Die Andersartigkeit echt nachrichtenorientierter Kommunikation im Gegensatz zum RPC-orientierten Umgang mit verteilten Objekten wird nicht wirklich thematisiert.
  Insofern ist Juvals Buch vielleicht nicht das beste, aber zumindest derzeit das kleinste Übel. Ich habe es jedenfalls gern gelesen.
  
• Ralf Westphal, Christian Weyer, .NET 3.0 kompakt, Spektrum Akademischer Verlag 2007
  Mein eigenes Buch, das ich zusammen mit Christian geschrieben habe, empfehle ich nicht, weil es eben unser Buch ist, sondern weil es mir wirklich beim Einstieg in WCF geholfen hat. Ich hatte für meine ersten Gehversuche nach Beispielen gesucht, die kleinschrittig sind - und sie bei Christian gefunden. Darüber hinaus bietet das Buch aber natürlich noch mehr... ;-)

Andere Darstellungen in Buchform zu WCF habe ich auch durchgesehen (z.B. von MSPress, Apress, Wrox), war aber nicht überzeugt. Den Detaillierungsgrad von Juvals Buch erreichen sie nicht. Und sie gefallen mit vom Layout her auch nicht genauso gut wie Juvals. Oft ist die Schrift groß und die Informationsmenge pro Seite klein. Das macht auf mich dann den Eindruck, der Verlag hätte vor allem ein dickes Buch im Auge gehabt, um einen hohen Preis verlangen zu können, und nicht unbedingt ein inhaltsreiches.

Artikel

• Laurance Moroney, The Windows Communication Foundation: A Primer, DevX.com 10/2005
• Aaron Skonnard, Learn the ABCs of Programming Windows Communication Foundation, MSDN Magazine 2/2006
• Clemens Vasters, Introduction to Building Windows Communication Foundation Services, MSDN Online 2005
• Dennis van der Stelt, WCF Part 0: Introduction, Dennis´ Blog 10/2006
• Ralf Westphal, A truely simple example to get started with WCF, Ralf´s Sudelbücher 5/2007
• Christian Weyer, Windows Communication Foundation, dotnetpro 1/2006
• Christian Weyer & Ralf Westphal, dotnetpro.tv #16 - Windows Communication Foundation, dotnetpro 6/2006

WCF Details

• Juval Löwy, WCF Transaction Propagation, MSDN Magazine 5/2007
• Juval Löwy, What you Need to Know About One-Way-Calls, Callbacks, And Events, MSDN Magazine 10/2006
• Juval Löwy, Discover Mighty Instance Management Techniques For Developing WCF Apps, MSDN Magazine 6/2006
• Aaron Skonnard, WCF Addressing in Depth, MSDN Magazine 6/2007
• Aaron Skonnard, WCF Messaging Fundamentals, MSDN Magazine 4/2007
• Aaron Skonnard, Serialization in Windows Communication Foundation, MSDN Magazine 8/2006

BizTalk Connectivity Services [home]

• Clemens Vasters, TweetieBot - A BizTalk Services Experiment, Clemens Vasters´ Blog 5/2007
• Clemens Vasters, Some fun with the BizTalk Services ISB, Clemens Vasters´ Blog 5/2007
• Christian Weyer, Cannot get latest BizTalk Services SDK (May 2) working?, Christians Weyers Blog 5/2007
• Christian Weyer, When you think things are not possible: WCF duplex callbacks through NATs and firewalls - safe and secure, Christian Weyers Blog 4/2007

Themen im WCF Umfeld

• Juval Löwy, Volatile Resource Managed in .NET Bring Transactions to the Common Type, MSDN Magazine 12/2005
• Sahil Malik, System.Transactions: Implement Your Own Resource Manager, codeguru 11/2005