Wunderlist für Personal Kanban

Ein Tool ist kein Selbstzweck, sondern soll dienlich sein. Das trifft auf Software zu wie auf Methoden.

Um meine Arbeit zu organisieren, wenn es mal wieder etwas mehr wird, habe ich vor einiger Zeit Personal Kanban eingeführt. Naja, “einführen” kann man da nicht viel ;-) Ich habe also angefangen, nicht nur eine Aufgabenliste zu führen, sondern die Aufgaben über ein Brett zu ziehen.

Das funktioniert - aber irgendwie, irgendwie fand ich es zu aufwändig. Die Software KanbanFlow stand mir im Weg. Es fühlte sich umständlich an. Und so schlief die Methode immer wieder ein.

Doch nun bin ich wieder dabei. Neues Tool, neues Glück. Hier fühle ich mich freier. Irgendwie. Und das eherne Gesetz des Personal Kanban “Transparenz” wird immer noch erfüllt.

Mein neues Tool heißt Wunderlist. Das gibt es auf allen Geräten und im Browser, selbstverständlich synchronisiert.

Es ist viel einfacher. Nix Kanbanbrettspalten. Keine Kärtchen. Einfach nur Listen.

Aber genau das macht den Unterschied für mich. Die Bedienung ist mehr auf den Punkt, finde ich.

Mein “Backlog”, das, was zu tun ist, pflege ich in verschiedenen Listen. Hier eine als Beispiel geöffnet, weitere sind darunter links zu sehen:

Das, was ich gerade tue, markiere ich als wichtig, so dass es herausgestellt in einer eigenen Liste steht:

Das ist mein WIP (work in progress). Wunderlist bietet da zwar keine WIP-Begrenzung, aber das ist auch nicht so wichtig. Es ist halt meine Verantwortung, nicht mehr als 1–2 Einträge über die Listen hinweg jeweils bis zur Erledigung als wichtig zu markieren.

Und am Ende kommen alle Aufgaben ins Archiv. Sie sind dann done:

Termine, Notizen, Teilaufgaben, Kommentare… das alles gibt es auch. Gelegentlich nutze ich es. Für den häufigsten Fall jedoch, die Abarbeitung von ständig einfließenden Aufgaben, reicht es mir völlig, schnell einen Eintrag in einer Liste machen zu können.

Wer sich noch überwältigt fühlt von zu erfüllenden Wünschen, der kann ja mal versuchen, mit Wunderlist etwas Systematik reinzubringen.

Smarter Entwurf mit smartem Tool

Software mit Flow-Design zu entwerfen, finde ich smart. Die Ergebnisse sind leicht verständliche, leicht in Code zu übersetzen und evolvierbar. Papier und Bleistift reichen eigentlich aus. Naja, eine Digitalkamera darf es dann auch noch sein, um die Entwürfe ins Repository legen zu können.

Jetzt waren Stefan Lieser und ich allerdings eine Woche bei einem Kunden zu einer Entwurfssitzung und haben uns von einem Tool begeistern lassen. So ein SMART Board von www.smarttech.com ist echt cool.

Grundlegen technisch gesehen ist ein SMART Board ein virtuelles Whiteboard. Man kann auf dem, was ein Beamer projiziert rummalen. Das gibt es in verschiedenen Ausführungen am Markt.

Im Detail aber macht eben ein SMART Board den Unterschied zum Whiteboard. Man kann nämlich nicht nur auf einem virtuellen Blatt herummalen, sondern auf allem, was projiziert wird. Der Beamer an der Decke sorgt dabei dafür, dass man sich nicht im Licht steht:

Hier zum Beispiel in einem Visual Studio Projekt oder in einem PDF-Anforderungsdokument:

  

Was immer in der Weise annotiert wird, kann zu einem Dokument ähnlich einer PPT-Präsentation ganz leicht zusammengefasst werden. So ergibt sich ein lückenloses Protokoll des Arbeitsfortschritts über Medien hinweg: vom weißen virtuellen Arbeitsblatt über Textdokumente, Spreadsheets bis zur Entwicklungsumgebung oder schließlich der laufenden Anwendung.

Ja, genau, Arbeitsergebnisse mit dem SMART Board vorgeführt, können sofort vom Kunden annotiert werden. Das Abnahmeprotokoll muss dann nicht lange “übersetzt” und getippt werden, sondern besteht aus Schnappschüssen, die “am Objekt” zeigen, was wie anders sein sollte.

Am Ende der Entwurfssitzung haben wir dann die SMART Board “Foliensammlung” als PDF gespeichert und ebenfalls ins Repository getan:

So lag sie jedem Entwickler auch bei der verteilten und asynchronen Entwicklung vor. Und niemand musste Zusatzaufwand treiben für ein Protokoll.

Zum Schluss noch ein besonderes Schmankerl: Was man da so malt am SMART Board ist Vektorgrafik. D.h. die Bildelemente lassen sich gezielt selektieren und verändern. Damit sind auch bei handschriftlichen Notizen sehr komfortable Umgestaltungen möglich.

Für Stefan und mich ist das Fazit: Softwareentwurf ohne SMART Board ist eigentlich nicht mehr zeitgemäß. Ad hoc, flexibel, informell, schnell, medienübergreifend – so geht das mit dem SMART Board. Wir wollen jetzt auch eins…

IronMQ – Simple Warteschlangen in den Wolken

Wie können Sie Anwendungsteile kommunizieren lassen, wenn sie allemal über Netzwerke verteilt sind. Klar, irgendwie geht das mit WCF und Azure… Aber warum so kompliziert?

Stefan Lieser und ich verbringen gerade einige Tage in unserem jährlichen Clean Code Advisors Retreat, um das vergangene Jahr zu reflektieren und das nächste zu skizzieren. Neben viel Zeit zum Reden und Denken darf da aber natürlich auch die Programmierung nicht zu kurz kommen. Also haben wir uns eine Application Kata ausgedacht: AppZwitschern. Dabei geht es darum, Tweets mit einem Desktop (oder Mobile) Client zu erfassen und erst zu einem späteren Zeitpunkt zu versenden. Selbstverständlich muss der Client dafür nicht offen gehalten werden. Die terminierte Versendung übernimmt ein Server.

Das ist eine schöne Aufgabe, in der wir die neue Flow Runtime NPantaRhei einsetzen. Macht Spaß, funktioniert gut. Darüber hinaus kommen einige Technologien zum Einsatz, z.B. Twitter, bit.ly, NCron und auch eine Kommunikationstechnologie. Die Clients müssen ja dem Server die Tweets zur späteren Versendung schicken.

Zuerst haben wir dafür Amazon SQS benutzt. Das ist Cloud Queue-Service. Der funktioniert. Unsere verteilte App zwitschert damit verlässlich und skalierbar. Alle Clients schreiben in dieselbe SQS Queue. Und beliebig viele Server-Instanzen verarbeiten die Versandaufträge. Perfektes scale-out.

Aber Amazon SQS hat einen recht umständlichen API. Und interessanterweise sichert SQS nicht zu, die Nachrichten in einer Warteschlange in der Reihenfolge abzuliefern (dequeue), in welcher sie eingestellt wurden (enqueue). Das ist zwar für unser Szenario nicht so wichtig, dennoch irgendwie merkwürdig. Lohnt sich da wirklich eine nähere Beschäftigung mit diesem Service?

Auch wenn wir für AppZwitschern nicht mehr Leistung brauchen, habe ich dann aber mal geschaut, ob es Alternativen gibt. Und tatsächlich, die gibt es. Hängengeblieben bin ich ganz schnell bei IronMQ von iron.io.

Attraktiv war deren Anspruch an Einfachheit:

• Einfache Anmeldung ohne Kreditkartenangabe, da 250.000 Nachrichten pro Monat ohnehin frei sind. Sie wollen es Interessenten also leicht machen, IronMQ auszuprobieren.
• Einfacher API auf für .NET. Der ist als Quelle bei github zu finden: iron_mq_dotnet. Unter downloads findet sich allerdings auch eine binäre Version.

Und IronMQ bietet, was SQS nicht hat: echte FIFO-Semantik.

Also habe ich alternativ zu unseren SQS-Operationen für die AppZwitschern-Flows welche für IronMQ aufgesetzt. Das war in 20 Minuten gemacht. Hier unser IronMQ-Adapter, der simples Enqueue und Dequeue so anbietet, das es leicht bei der Flow Runtime zu registrieren ist:

public class IronMQOperations
{
    private readonly Client _client;
    private readonly Queue _queue;
 
    public IronMQOperations(string queueName, string projectId, string token)
    {
        _client = new Client(projectId, token);
        _queue = _client.queue(queueName);
    }
 
 
    public void Enqueue(string data)
    {
        _queue.push(data);
    }
 
 
    public void Dequeue(Action<string> onDataReceived)
    {
        do
        {
            var msg = _queue.get();
            if (msg == null) break;
 
            onDataReceived(msg.Body);
 
            _queue.deleteMessage(msg);
        } while (true);
 
        onDataReceived(null);
    }
}

Ich würde sagen, einfacher gehts kaum. Mit den paar Zeilen ist eine verlässliche Kommunikation via Cloud möglich. Die braucht ihre Zeit; Performance wie mit TCP im lokalen Netz ist da nicht zu erwarten. Aber das spielt für unser Szenario und viele andere keine Rolle. Es geht darum, serverseitig skalieren zu können.

Der SQS-Adapter hat knapp doppelt soviele LOC – und bietet eben nicht das, was man von einer Queue erwartet.

Nun bin ich gespannt auf die .NET Bindings für die anderen iron.io Dienste: den Key-Value-Store (Cache) und serverseitige Prozesse (Worker). Einstweilen habe ich in meinem Köcher einen no-brainer für die Verteilung von Arbeitspaketen.

PS: Der Support bei iron.io ist gut. Ich habe ein paar Fragen gehabt und den angebotenen Live Chat benutzt. Da war zu jeder Tageszeit jemand zu erreichen, der entweder Auskunft geben konnte oder dafür gesorgt hat, dass mir später geholfen wurde. I like that.

Mit dem Teppichmesser gegen Verlagsträgheit

Buchhandel und Verlage sind nicht die Schnellsten, was neue Technologien angeht. Ideen aus meiner Sicht als Leser, was der stationäre Buchhandel tun kann, um nachzuziehen und sich zu erhalten, um für mich attraktiv zu bleiben, habe ich schon geäußert.

Für die Verlage gibt es natürlich auch Ideen. Hier nur eine, wie ein cooles Buch 2.0 aussehen könnte.

Das scheint mir Lesen auf der Höhe der Zeit. Wie krude ist dagegen ein Kindle-Book oder ein Hörbuch.

Bis Verlage solche Produkte herstellen, wird allerdings noch einige Zeit vergehen. Auch nicht alle heutigen Verlage werden das schaffen. Andere werden an ihnen vorbeiziehen und die Gunst der Leserschaft erringen. Die Schnellen fressen die Langsamen.

Einstweilen wäre ich ja schon zufrieden, wenn Verlage ganz selbstverständlich jedes Buch auch als eBook herausbrächten. Für Romane und Fachbücher fährt der Zug in diese Richtung langsam los. Bei Sachbüchern und Schulbüchern scheint mir da aber noch einiges im Argen zu liegen.

Case in point: Das Französich Lehrwerk Découvertes von Klett, mit dem nun meine Tochter in der 6. Klasse beginnt. Der Verlag bietet keine eBook-Version an. (Warum nur? Weil Kinder keinen Computer haben? Das Gegenteil scheint mir der Fall. Alle haben ein Handy, fast alle haben einen Computer zuhaus. Meine Tochter – naja, wie könnte es anders sein ;-) - sogar zwei und noch ein eigenes iPad.)

Ich möchte nun mit meiner Tochter einen erneuten Anlauf nehmen, Französich zu lernen – aber natürlich auf meine Weise. Das heißt ich werde die Vokabeln mithilfe von FlashCards Plus Pro auf iPad und iPhone lernen. Und ich werde das Lehrbuch auf dem iPad und iPhone studieren – ob der Verlag das will oder nicht.

Wie das? Er bietet doch kein eBook an.

Ganz einfach mit roher Gewalt :-)

Bauanleitung – Aus einem Papierbuch wird ein eBook

Wenn der Verlag es nicht schafft auch nur das einfachste eBook herzustellen, dann schaffe ich das halt selbst: mit einem Teppichmesser, ScanSnap S1500, Abbyy FineReader, iPhone, pdfasm, Dropbox und GoodReader.

Schritt 1: Ich zerschneide das Lektionsbuch und das Grammatik-Beiheft mit dem Teppichmesser.

Schritt 2: Ich scanne die Seiten mit ScanSnap “Schnappi” S1500. Ein Hoch auf das papierlose Büro! Das Resultat sind PDF-Dateien. Da die Seiten als Bilder gescannt wurden, sind die Dateien natürlich sehr groß. 30 KB für 76 Seiten Grammatik-Beiheft. Deshalb zerlege ich das Lektionsbuch in Blöcke (Kapitel 1-3, Vokabeln + Index usw.).

Schritt 3: Ich lasse die Abbyy FineReader als OCR Texterkennung über die PDFs laufen, damit aus den Bildern echte Texte werden und ich in den PDFs suchen und markieren kann. (Abbyy liegt übrigens dem “Schnappi” bei.)

Schritt 4: Ich fotografiere noch einige Seiten des Lektionsbuches mit dem iPhone, die ich nicht durch den Scanner schieben konnte. Ist halt ein Hardcover, das Schulalltag standhalten muss. Die Photo-App meiner Wahl: Camera+

Schritt 5: Ich bündele einige PDFs mit den fotografierten Seiten, damit der Look hübsch einheitlich ist. pdfasm ist mein Freund – auch wenn die Bedienung etwas intuitiver hätte sein können. Da waren wieder mal Techniker die Gestalter der Benutzeroberfläche.

Schritt 6: Ich lege die PDFs in meine Dropbox, um von allen Devices (Laptop, iPad, iPhone) darauf zugreifen zu können. (Hoppla, aufpassen, damit die PDFs nicht ins öffentliche Verzeichnis geraten und ich durch Unachtsamkeit einen Link darauf in die Welt sende, auf dass auch noch andere Schüler, Eltern, Lehrer ein elektronisches Découvertes in die Hand bekommen.)

Schritt 7: Schließlich werfe ich den GoodReader auf dem iPad an, um mit der Lektüre der ersten Lektion zu beginnen.

Zeitaufwand für diese Aktion? Hm… ich habe es nicht gestoppt, aber ich schätze mal, dass es in Summe 2 Stunden gedauert hat. Zeitaufwendig war dabei allerdings nur die Texterkennung. Hat mich aber nicht gestört. Abbyy hat ja still vor sich hingepusselt im Hintergrund, während ich am Rechner weiterarbeiten konnte.

Fazit

Das war gar nicht so schwer. Den Verlag hätte es kaum mehr Aufwand gekostet bei besserem Ergebnis (kleinere PDFs, weniger Stückelung des Inhalts). Der hat den ganzen Content ja in Quark Xpress oder so und könnte ihn ganz leicht nach PDF exportieren.

Warum tut man das nicht? Ich kann nur einen Grund erkennen: ängstliche Unsicherheit. “Oh, mein Gott, was alles passieren könnte, wenn erstmal so ein PDF auf einer CD – nein, zu teuer! – oder im Internet auf unserer Homepage verfügbar wäre. Kriminelle Kinder könnten es verbreiten! Unsere Schulbuchverkaufe würden ins Bodenlose fallen. In 2 Jahren wären wir pleite. Arrghhhh! Das darf nicht passieren!” (Besonders verständlich ist so eine Denke natürlich bei Schulbuchverlagen, die garantierte Verkäufe dadurch haben, dass ihre Lehrwerke verbindlich durch Schulen oder Eltern in Papierform angeschafft werden müssen.)

So stelle ich mir die Verlagsredaktion vor – bis mir jemand plausibel macht, dass es ganz andere, mir als Leser total verständliche Gründe gibt, meine Lesegewohnheit nicht zu bedienen, obwohl es technisch möglich ist. Wenn dies also ein Verlagsmitarbeiter lesen sollte, möge er mich über solche Gründe bitte ins Bild setzen.

Nun, gut: Wie ich festgestellt habe, kann mir das Verhalten der Verlage ziemlich egal sein. Mit relativ wenig Aufwand habe ich mir mein eBook in “good enough” Qualität selbst hergestellt. Nächstes Mal mache ich das mit meiner Tochter zusammen. Daraus wird dann ein kleiner Event, die jährliche “School Book Slashing Party” oder so :-) (Vielleicht eine Anregung für Pädagogen, um Kindern eine Möglichkeit zum Ausagieren von Aggressionen zu bieten? Mit Teppichmessern auf Schülbücher statt auf Mitschüler oder später Flugzeugpiloten?)

In jedem Fall habe ich schon ein zweites Buch geordert, das ich mit dem Teppichmesser und den anderen Werkzeugen in ein eBook transformieren werde. Diesmal ist es ein Philosophiebuch: Das Prinzip Verantwortung. Suhrkamp verweigert hier die Veröffentlichung als eBook. Ob man meint, eine Existenz als eBook sei einem solchen Inhalt oder dem Klassiker-Status nicht würdig? Hm…

Naja, mir egal. Das Teppichmesser liegt schon bereit. Bei dem Buch wird es auch einfacher. Ist ein Paperback. Vielleicht kann ich das sogar komplett in Text umwandeln.

Aber nun kommen erstmal Sie: Machen Sie mit bei der großen Buchtransformation! Welchen Titel “rippen” Sie, um ihm die ewige Jugend als eBook zu schenken?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Fit für FitNesse

FitNesse ist ein hübsches Framework für Akzeptanztests. Ist zwar Java-basiert mit seinem eigenen Web-Server, aber der Einsatz ist auch für .NET möglich. Gojko Adzic hat dazu schon vor längerer Zeit ein Buch geschrieben – Test Driven Development with FitNesse -, dass auch kostenlos als eBook verfügbar ist.

Leider hat sich der Einstieg dann aber doch nicht so flüssig gestaltet, wie ich es gern gehabt hätte. Die grundsätzliche Installation ist simpel:

1. Java VM installieren; Download von http://www.java.com/de/download/
2. FitNesse Server herunterladen von http://fitnesse.org/FrontPage.FitNesseDevelopment.DownLoad. Er kommt als .jar-Datei, für das Sie am besten ein FitNesse-Verzeichnis anlegen, z.B. C:\FitNesse
3. FitSharp herunterladen von http://fitsharp.github.com/. Das ist ein Framework wie NUnit, mit dem Sie .NET-Klassen zu FitNesse-Fixtures machen können. Die FitSharp Assemblies legen Sie am besten im FitNesse-Verzeichnis ab, z.B. unter C:\FitNesse\FitSharp.
4. FitNesse-Server starten. Ich habe mir dazu einen einzeiligen Batch gebastelt, der im FitNesse-Verzeichnis liegt und den Server auf Port 8888 startet:
   
   java -jar fitnesse.jar -p 8888

Das Ergebnis einer soweit erfolgreichen Installation ist ein laufender Server:

Auf den können Sie über den Browser mit Adresse localhost:8888 zugreifen:

Soweit lief bei mir auch alles gut. Knifflig wurde es, als ich dann eine C# Testfixture aufrufen wollte. Ich hatte sie nach Gojkos Beispiel wie folgt geschnitzt:

Die FitSharp Assemblies fit.dll und fitSharp.dll musste ich referenzieren (am besten aus einem projektlokalen Verzeichnis) und die Fixture-Klasse von ColumnFixture ableiten. Weitere Details entnehmen Sie am besten Gojkos Buch.

Ein FitNesse-Test war ebenfalls einfach aufgesetzt:

Nur leider zeigte der nicht den gewünschten Erfolg. Nach Start über das FitNesse-Dashboard passierte schlicht nichts :-( Nicht mal eine Fehlermeldung erschien. Der Test war angestoßen worden… aber “kam nicht zurück”. FitNesse schien zu hängen.

Tip #1: Um mehr Infos über einen (abstürzenden) Test zu erhalten, nicht mit dem FitSharp Runner.exe starten, sondern mit RunnerW.exe:

!define TEST_RUNNER {fitsharp\RunnerW.exe}

Der Grund für das Hängen war, dass durch eine Security Policy Änderung bei .NET 4 der Runner-Prozess Libraries nicht einfach so laden konnte. Ob es daran lag, dass meine Test-Assembly nicht auch im FitSharp-Verzeichnis lag (wie in Gojkos Beispiel), weiß ich nicht. Diesen Grundsatz wollte ich jedenfalls nicht aufgeben.

Tip #2: Um das Laden der nötigen Assemblies für den Runner zu ermöglichen, einfach zwei App.Config-Dateien im FitSharp-Verzeichnis anlegen. Runner.exe.config und RunnerW.exe.config:

<configuration>
   <runtime>
      <loadFromRemoteSources enabled="true"/>
   </runtime>
</configuration>

Mit der Konfigurationsdatei lief dann der Runner, meldete aber, dass er meine Testklasse nicht finden können. Dafür die Ursache zu finden, hat mich dann einige Zeit gekostet. Google war keine Hilfe. Ich hatte ja auch alles Formal richtig gemacht.

Am Ende stellte sich heraus, dass FitNesse oder FitSharp ein Problem mit dem Namespace der Testklasse hatte. Dessen Name lautete ursprünglich “spike_fittest”. Als ich ihn dann nach “fittest” umbenannt hatte, lief der Test durch.

Tip #3: Sonderzeichen in Namen von Namensräume oder Testklassen vermeiden, allemal einen Unterstrich “_”. (Umlaute scheinen allerdings kein Problem zu machen und sogar falsche Groß/Kleinschreibung wird toleriert.)

Schließlich noch ein Hinweis auf FitSharp Suite-Dateien. Zwischendurch schien es, dass “etwas” besser wurde, als ich eine solche testspezifische Datei mit Runner-Konfigurationsdaten im Test referenzierte. Meine Suite-Datei suite.config.xml sah so aus:

<suiteConfig>
    <ApplicationUnderTest>
        <addNamespace>fitlibrary</addNamespace>
    </ApplicationUnderTest>
</suiteConfig>

Eingebunden hatte ich sie in den Test so:

Heute, beim Schreiben dieses Artikels, konnte ich allerdings keinen Vorteil mehr darin erkennen. Auch ohne Referenz dieser Suite lief der Test problemlos. Merkwürdig… Aber egal. Ich denke, ein Hinweis auf Suite-Dateien ist trotzdem nützlich.

Ich hoffe, mit diesem kleinen Erfahrungsbericht mache ich Ihnen den Einstieg in FitNesse mit .NET ein bisschen einfacher. Mir gefällt der Framework als Grundlage für Softwareprüfstände. Bevor Sie einen Prüfstand komplett selbst aufsetzen, schauen Sie sich einmal FitNesse an. Damit können Sie auch mal einen Kunden auf Ihren Code loslassen.

Getting Things Done - ganz anders und ganz einfach [OOP 2009]

Ja, auch ich habe den Zeitmanagement-Klassiker "Getting Things Done" ("Wie ich die Dinge geregelt kriege") von David Allen gelesen. Und ich habe daraus auch etwas gelernt:

1. Habe einen (!) Platz, an dem du alle Aufgaben bzw. Hinweise darauf, sammelst.
2. Nutze diesen Platz konsequent und regelmäßig, um die nächste Aufgabe "abzuholen" bzw. zukünftige Aufgaben zu hinterlegen.
3. Erledige Kleinstaufgaben sofort, plane größere Aufgaben ein.

Ziel dieser Praktik sind mentale Entlastung und Kontrolle. Aufgaben, die man nicht gerade erledigt, sollen die Konzentration im Hier und Jetzt nicht behindern. Äußere Umstände beherrschen nicht, sondern werden durch aktive Planung beherrscht.

That´s it.

Mehr hat mir David Allen nicht gebracht - außer einem schlechten Gewissen, sein ausgefeiltes System nicht genauso ausgefeilt zu benutzen.

Naja, in einem Punkt habe ich es noch angepasst: Wo er empfiehlt, "Abteilungen" für Aufgaben anzulegen, die mit bestimmten Orten oder Gelegenheiten zu tun haben (z.B. "Wenn ich das nächste Mal beim Faxgerät bin"), da nutze ich diese Orte selbst. Habe ich eine Aufgaben, die mit dem Faxgerät oder dem Lebensmitteleinkauf zu tun haben, dann lege ich mir Aufgabenzettel genau dorthin, also zum Faxgerät und zur Wohnungstür (durch die ich zum Einkauf gehe). So "stolpere" ich über meine Aufgaben. Ich muss sie also nicht im Hinterkopf halten.

Ansonsten aber... da grüble ich eher darüber nach, was mich an David Allens gutgemeinten Ratschlägen stört. Und meine Erkenntnis ist inzwischen:

"Getting Things Done" (GTD) ist keine Lösung, sondern ein Symptom.

Das Buch ist ein Symptom für eine Kultur oder auch nur Arbeitshaltung, in der man soviel "auf dem Zettel hat", dass man überhaupt ein ausgefeiltes System braucht, um es zu bewältigen. Es scheint geradezu eine Tugend zu sein, sich soviel aufzuladen, dass man sich nur mit modernen Hilfsmitteln organisieren kann. Eine Aufgabenliste, ein Kalender, eine Wiedervorlagemappe oder auch (im fortgeschrittenen Stadium) eine Assistenz reichen nicht mehr. Nein, es muss ein mehrdimensionales Verwaltungs- und Erinnerungssystem sein.

Seit ich das erkannt habe, geht es mir besser. Ich brauche GTD nicht. Ich brauche nur Mut, mein Leben/meine Arbeit so einfach zu halten, dass ich gar nicht erst in eine organisatorische Überlastungssituation komme. Wenn ich an soviel denken muss, dass ein simpler Kalender und eine Aufgabenliste nicht mehr reichen, dann (!) habe ich ein Problem. Denn dann bin ich sehr wahrscheinlich auch so unter Druck, dass mir als Softwareentwickler schlicht Spielräume fehlen und der Raum für Kreativität begrenzt ist.

Dass GTD mir dann ja gerade helfen würde, diese Räume wieder zu eröffnen durch gute Planung... nun, das halte ich für eine Empfehlung wie "Putz die Zähne öfter, damit die ganzen Süßigkeiten ihnen nicht schaden."  Hier ist die Wurzel des Übels ein übermäßiger Zuckerkonsum, dort ist es eine Hypertrophie des Verantwortungsbewusstseins. Denn nur wer sich für viele Dinge verantwortlich fühlt, der hat auch viele Aufgaben, um diese Dinge geregelt zu kriegen.

Die wahre Lösung des Problems, mit dem sich GTD beschäftigt, lautet daher: Reduktion und Delegation. Weniger tun müssen und/oder andere an der Bewältigung beteiligen.

Wenn die zu regelnden Dinge soviel werden, dass man überhaupt merklich Zeit für ihre Regelung aufwenden muss, wenn also auch die Regelung zu regeln ist... dann ist Gefahr im Verzug. Soviel mal zur Abwechslung ins Stammbuch der ewig geschäftigen Manager geschrieben - zumindest derjenigen, die sich über ihre Aufgabenlast bewusst beklagen oder körperliche/psychische Symptome der Überlastung zeigen.

GTD hat nun einen Platz bei mir im Schrank als Mahnung, mich nicht von den Dingen beherrschen zu lassen und in eine Situation zu kommen, wo ich sie mit "normalen Mitteln" nicht mehr im Griff habe.

So freue ich mich auch, dass es Literatur gibt, hinter denen ein anderes Menschenbild steht und die aus der Regelung von Dingen nicht noch eine weitere, umständlich zu erwerbende Kompetenz machen. Wer bisher an GTD geglaubt hat, der versuche es doch mal zur Abwechslung mit einer anderen Einstellung:

oder ganz simplen Werkzeugen, die sich viel eher auch von Fall zu Fall einsetzen lassen:

Ein bisschen Papier in Form von Notizblock, Notizbuch oder Post-It Zetteln reicht oft in Kombination mit dem Willen zu Überschaubarkeit von Verantwortlichkeiten und Aufgabe von Kontrolle.

Die Dinge geregelt kriegen ist dann ganz einfach. Viel einfacher, als GTD meint.

NETZ it! - Komponentenorientierte Software ausliefern leicht gemacht

"Soooviele Assemblies???" ist der ungläubige Ausruf, den ich oft höre, wenn ich ich über Komponentenorientierung spreche. Denn damit komponentenorientierte Entwicklung wirklich ihre Vorteile ausspielen kann, ist es nötig, Software nicht nur logisch in Komponenten zu zerlegen, sondern die auch noch physisch getrennt zu implementieren. Das bedeutet, jeder Komponentenkontrakt und jede Komponentenimplementation wird zu einer eigenen Assembly. Die Zahl der Assemblies einer Anwendung ist also immer mindestens doppelt so groß wie die ihrer Komponenten.

Das hört sich viel an. Oder zumindest ungewohnt. Schon bei 3 Komponenten kommen 5 oder 6 Assemblies zusammen, wie die nebenstehenden Beispielanwendung zeigt. Und größere Anwendungen bestehen schonmal aus 50 oder 100 Komponenten und damit 100 oder 200 Assemblies.

Einen "materiellen" Nachteil hat das jedoch nicht. Der .NET Framework kommt damit ganz gut zurecht. Nur Visual Studio nicht. Es macht keine Freude, in einer Visual Studio Projektmappe mehr als vielleicht 10 Projekte zu verwalten. Aber das soll man ja auch nicht.  (Insofern entspricht die Abbildung links nicht dem Ideal; ich habe die Projekte nur für eine einfachere Darstellung so zusammengefasst.)

Echte Komponentenorientierung bedeutet vielmehr, dass alle Komponenten in je eigenen Projektmappen entwickelt werden. Wenn Sie an einer Komponente arbeiten sollen Sie nicht abgelenkt werden durch Implementationsdetails anderer Komponenten, die in derselben Projektmappe liegen.

Doch auch wenn es keinen "materiellen" Nachteil hunderter Assemblies für eine Anwendung gibt, verstehe ich, dass sie dazu angetan ist, den Überblick zu verlieren. Vor allem wollen Sie womöglich dem Kunden gegenüber solche Detailfülle nicht offenlegen. Die Abbildung rechts zeigt, wie ich die Beispielanwendung eigentlich ausliefern müsste: als "Sack von Assemblies". Das ist zwar einfach, aber mag sich eben zumindest merkwürdig anfühlen.

Krücke ILmerge

Nun habe ich aber noch nie behauptet, dass die Zahl der Assemblies zur Entwicklungszeit der zur Zeit der Auslieferung gleich sein müsse. Immer schon habe ich auf die Möglichkeit hingewiesen, sie mit Microsofts ILmerge zusammenzufassen. Aus den 7 zur Anwendung gehörenden Assemblies (inkl. DI Framework Infrastruktur) rechts im Bild könnte mit ILmerge ganz leicht eine werden.

Sie anders zusammenfassen, wäre allerdings nicht unproblematisch. Zum Beispiel könnten Sie nicht nur alle Kontrakt-Assemblies vereinigen, weil Sie damit die Referenzen darauf in den Komponentenimplementationen invalieren würden. Die beziehen sich ja auch konkrete Assemblynamen, die es dann nicht mehr gäbe.

ILmerge funktioniert zwar grundsätzlich. Ist aber letztlich nur eine Krücke, weil es nicht genügend Freiheitsgrade bietet. Außerdem mag es nicht jedem schmecken, dass ILmerge den IL-Code "anfasst". Zugegebenermaßen ein Vorgang, bei dem mehr falsch laufen könnte, als wenn man Assemblies, so wie sie sind, irgendwohin kopiert.

NETZ to the rescue

Aber diese Zeit der Krückenlösung ist nun vorbei! Durch einen News-Schnippsel in einer Entwicklerzeitschrift bin ich auf das Open Source Tool NETZ gestoßen. Das ist echt cool für die komponentenorientierte Entwicklung! Und es ist auch noch eines aus deutschen Landen - ein seltener Umstand bei Softwareentwicklungstools.

Was bietet NETZ? Zusammenfassung und Kompression von Assemblies. Mit NETZ können Sie Assemblies wie mit ILmerge zusammenfassen, allerdings ohne Eingriff in den IL-Code. NETZ verpackt die Assemblies einfach nur als Ressourcen in eine von ihm generierte.

Für die Komponentenorientierung unwichtig, aber für Sie dennoch vielleicht interessant, komprimiert NETZ die Assemblies während der Zusammenfassung auch noch. So kann der in den Ressourcen steckende IL-Code nicht mehr so einfach decompiliert werden. Ohne Obfuscation erhalten Sie also einen ersten Schutz gegen beiläufige Ausspähung von Implementationsdetails.

Die obige Beispielanwendung in eine Assembly zusammenzufassen, ist mit NETZ ganz einfach. Eine Kommandozeile wie diese reicht (sie ist nur der Lesbarkeit wegen hier in mehrere Zeilen geteilt):

netz -z -s
  frontend.exe
  -d logic.dll dataaccess.dll
       contracts.logic.dll contracts.dataaccess.dll
       Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll

Mit ihr verpackt NETZ alle Assemblies in eine neue Assembly (-s), die auch eine DLL zur Dekompression enthält (-z). Alle Assemblies können auch dynamisch geladen werden (-d) - das ist für die Nutzung eines DI Frameworks nützlich sein mag. Das Resultat: eine Assembly mit Namen frontend.exe und einer Struktur wie in der nachstehenden Abbildung. Der Start-Code wurde komplett durch NETZ generiert (Methoden auf der linken Seite), die Anwendungsassemblies sind zu Ressourcen geworden (rechts). Der NETZ-Code sorft dafür, dass beim Laden einer Assembly, die die CLR nicht selbst findet, die Ressourcen herangezogen werden.

Schon bis hierhin bietet NETZ also mehr als ILmerge. Nicht nur Zusammenfassung von Assemblies, sondern gleichzeitig Kompression - und das ohne Eingriff in den Assembly-IL-Code.

NETZ kann aber noch mehr! NETZ kann die Assemblies auch in externe Ressourcen verpacken. So können Sie sie beliebig gruppieren. Auf die Referenzen hat das keinen Einfluss. Bilden Sie also beliebige Gruppen von Assemblies. Die Beispielanwendung habe ich z.B. einmal so zusammengefasst wie rechts zu sehen. In frontend.exe steckt die ursprüngliche EXE mit den Microsoft Unity DI Infrastruktur-Assemblies. Die contracts-Ressourcen enthalten die Kontrakt-Assemblies, die components-Ressource die Implementationen. Ganz einfach ist damit einem Batch wie diesem:

netz -z -s frontend.exe Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll
netz -xr contracts contracts.logic.dll contracts.dataaccess.dll
netz -xr components dataaccess.dll logic.dll

move *-netz.resources frontend.exe.netz

Der -xr Switch weist NETZ an, die Assemblies nicht zu einer EXE, sondern zu einer externen Ressource zusammenzufassen. Der NETZ-Start-Code sucht in solchen Ressourcendateien im selben Verzeichnis sogar zuerst nach Assemblies.

Lassen Sie sich durch 50 oder 100 Assemblies nicht in Bockshorn jagen. Fassen Sie sie für´s Deployment mit NETZ einfach so zusammen, wie Sie es möchten: alle zu einer großen Assembly oder Kontrakte und Implementationen getrennt oder Kontrakte zusammen mit ihren Implementationen oder alle Assemblies einer Kategorie (z.B. alle Domänenlogik-Assemblies getrennt von allen Aspekt-Assemblies). Mit NETZ ist das alles sehr einfach möglich. Und kostenlos dazu! Mein herzlicher Dank gilt Vasian Cepa, dem Entwickler! (Der ist übrigens sehr bemüht; innerhalb eines Tages hatte er eine Verbesserung eingebaut, auf die ich ihn angesprochen hatte.)

Ich arbeite jetzt nicht mehr ohne NETZ in meinen komponentenorientierten Projekten.

Photosynth - Rundumblick ganz einfach

Den Eindruck zu verewigen, den man als Mensch mit einem Blick oder gar einem Rundumblick hat, ist schwer. Eine Videokamera ist nicht immer zur Hand, ein "Photo Stitcher" recht umständlich zu bedienen, ein 360° Objektiv teuer. Also was tun?

Microsoft Photosynth nutzen!

Ein echt cooles Tool aus dem Forschungslabor von Microsoft, das nun den Weg in die breite Öffentlichkeit gefunden hat.

Mit Photosynth ist der Rundumblick ein Kinderspiel:

1. Einfach Fotos schießen nach Belieben. Sie im Kreis drehen für einen 360° Blick oder um das "Objekt der Begierde" fotografierend herumwandern. Egal.
2. Fotos zu Photosynth hochladen.
3. Photosynth macht daraus eine "Galerie", in der man sich mit der Maus bewegen kann: sich in der Szene drehen, nach oben/unten blicken, heranzoomen.

Ja, heranzoomen geht auch, denn man kann Totale und Close-Up mischen. Photosynth erkennt das und macht die Szene "tiefer", wo mehr Details verfügbar sind.

Ich habe das grad mal mit einem Blick von meinem Balkon ausprobiert. Hier das Ergebnis:

Die Detailbilder sind leider etwas unscharf, weil die Belichtung nicht optimal war. Aber der Gesamteffekt und -nutzen wird schon deutlich, denke ich. Am Wochenende werde ich daher mit meiner Frau losgehen und für ihren Beruf relevante Szenerien einfangen. Daraus machen wir dann Synths und stellen sie auf ihre Homepage (die wir gerade einem Redesign unterziehen). Dann können sich ihre Kunden einen viel besseren Eindruck davon machen, was sie erwartet.

Meine Frau ist Bestatterin :-) Die Szenerien werden also Friedhofskapelle, Ruhewald oder Anonymes Feld auf dem Ohlsdorfer Friedhof sein. Photosynth macht da keinen Unterschied ;-)

Zusammenwachsen - Wie die Wiesn Frontend und Backend verbindet

O/R Mapping (ORM) ist mehr als LINQ to Sql oder NHibernate. Die ORM-Welt ist vielfältiger - und wird nun auch noch bunter. Denn ein Hersteller von "bunten Steuerelementen" für WinForms, ASP.NET, WPF und Silverlight will jetzt Farbe in die manchmal recht schwarz/weiß gezeichnete ORM-Welt bringen.

Telerik - noch immer eher ein Newcomer, wenn auch ein starker, und noch nicht so bekannt in Deutschland - hat den ORM-Hersteller Vanatec in sein Portfolio integriert. Vanatecs O/R Mapper OpenAccess, der einer der ersten für die .NET- und Java-Plattform war, schließt nun die Klammer, die Telerik mit seinen Steuerelementen um .NET-Anwendungen geöffnet hatte.

Die offizielle Verlautbarung findet sich hier. Inoffiziell wurde die Entscheidung jedoch schon beim jährlichen Treffen des Vanatec Expert Advisory Council (EAC) bekannt gegeben. Vanatec hatte sich schon vor Jahren den Kontakt zur Community auf die Fahne geschrieben, um möglichst dicht am Markt zu entwickeln. So wurden alljährlich Entwicklungsfortschritte und "Communitybefindlichkeiten" auf einem EAC-Treffen diskutiert - das nicht zufällig während der Münchener Oktoberfestzeit statfindet ;-)

 
v.l.n.r.: Jörg Neumann, Tilman Börner, Neno Loje, Ralf Westphal

Die Freude der hier abgebildeten EAC-Mitglieder ist deshalb aber nicht nur der guten Stimmung und Wiedersehensfreude zuzuschreiben. Eher wird umgekehrt ein Schuh draus: Auslöser für gute Stimmung und lachende Gesichter ist der Gewinn für die Entwicklergemeinde, den der Zusammenschluss von Telerik und Vanatec bedeutet.

Der ist zum einen finazieller Art, da die Telerik Suite ohne Preisaufschlag (!) nun auch noch OpenAccess enthalten wird, also einen ORM, der hier und heute mehr bietet als LINQ to SQL und den Kinderkrankheiten, unter denen Microsofts Entity Framework noch länger leiden wird, lang entwachsen ist.

Zum anderen besteht der Gewinn für die Community darin, dass Telerik nun versuchen wird, zusammenwachsen zu lassen, was zusammengehört: Frontend und Backend, Darstellung und Objekte, View und Model. Denn da gibt es noch einiges in punkto Datenbindung zu tun. Relationale Daten in Objekte wandeln (mapping) und dann auch noch mit ihrer Beziehungsvielfalt leicht editierbar anzuzeigen (data binding): das ist immer noch eine Herausforderung. Da muss immer noch zuviel Infrastrukturcode geschrieben werden, der vom eigentlich Wichtigen, der Geschäftslogik, ablenkt.

Wir dürfen also gespannt sein auf die Ideen, die Telerik+Vanatec in den nächsten Monaten umsetzen. Auf dem EAC-Treffen wurde dazu schon leidenschaftlich diskutiert... worunter am Ende zum Glück die Eintracht nicht gelitten hat:

Pro sit! - möge uns allen der Zusammenschluss nützen.

PS: Die Telerik Geschäftsführung aus Bulgarien war natürlich auch mit auf dem Oktoberfest. Aber es schien, als sei deutsche Ausgelassenheit - oder besser: oktoberfestige - deren Sache nicht so ganz. Ist ja auch gewöhnungsbedürftig, selbst für mich als Nordlicht.

Peter Brunner (rechts), der Geschäftsführer von Vanatec, war dafür umso besser gelaunt :-)

Wer würde das nicht verstehen? Es werden besonders spannende Monate für ihn und seine Jungs bis zum nächsten Oktoberfest :-)

Lieber grün freuen als schwarz sehen - Zufriedener mit Unit Tests

Grad habe ich den Code für meinen nächsten dotnetpro-Artikel fertiggestellt. Zuerst wollte ich ihn einfach nur so runterprogrammieren. Zwar bin ich ein Freund solider Planung und automatischer Tests, aber ich hatte den Chor der Entwickler im Ohr, die da singen "Aber muss denn das immer sein?" So hatte ich mich entschieden, auf Contract-First Design zu verzichten, keinen DI-Framework einzusetzen und eigentlich auch keine großartigen Unit Tests anzulegen.

Aber: Selten so gelacht. Diese Vorsätze konnte ich keine Stunde einhalten. Echt. Ich konnte nicht. Ich musste eine Architektur zumindest auf 2-3 Blättern skizzieren und Kontrakte andeuten. Die Last, das alles nur im Kopf zu versuchen, war mir einfach zu groß: ich hätte mich dafür anstrengen müssen und ich wäre in Sackgassen bei der ad hoc Implementierung gelaufen, die mich Mehraufwand gekostet hätten.

Das hat mir schonmal gezeigt, dass Architektur eine Gewohnheitssache ist. Am Anfang kann man ohne, weil man sich ihres Wertes nicht so bewusst ist. Dann macht es Mühe, sich auf sie einzulassen. Es tut weh, seine Gewohnheiten zu ändern. Man muss sich schon dazu zwingen. Aber wenn man am Ende dieses Tals der Tränen herauskommt, dann ist der Prozess ganz natürlich. Dann kann man - oder zumindest ich - nicht mehr anders. Dann ist Architektur ein Muss. Sonst fehlt einfach etwas.

Um den Beispielcode aber nicht mit Details zu überfrachten, habe ich trotzdem die Kontrakte nicht in eigene Assemblies gesteckt und auch kein DI-Framework benutzt. Soviel dann doch als Zugeständnis an den Entwicklerchor ;-)

Dann das Testen. Eigentlich wollte ich nicht. Aber dann konnte ich doch nicht anders. Die Architektur einfach so zu implementieren und dann durch das kleine Frontend zu testen... nein, das ging nicht. Ich habe es echt versucht. Aber ich hab es dann nicht ausgehalten, so lange auf Feedback zu warten. Um herauszufinden, ob eine Infrastrukturfunktionalität des Beispielcodes funktioniert, hätte ich irgendwie künstlich einen Durchstich vom Frontend dorthin machen müssen. Wasfürein Aufwand! Oder ich hätte einfach weiter programmieren müssen, bis irgendwann man ein Durchstich da ist. Welch frustrierende Wartezeit!

Und so habe ich doch wieder alle Bereiche mit Unit Tests abgedeckt. Schritt für Schritt, eine Methode nach der anderen. Das hat sich einfach gut angefühl. Eine Erleichterung war es, nach ein wenig Programmierung mich beim Testen entspannen zu können.

Zweierlei ist mir dabei aufgefallen:

1. Proaktives Testen geschieht in einem positiven Gefühl. Ich bin ganz aufgeregt, wenn ich den Test schreibe, weil ich ja sehen möchte, ob meine Idee vom Code richtig ist. Wenn ich hingegen auf einen solchen sofortigen Test verzichte und darauf warte, dass irgendwann mal eine Nutzung durch das Frontend auf einen Fehler stößt, dann ist mein Gefühl negativ. Dann teste ich nicht proaktiv, sondern debugge, d.h. ich befinde mich in einem Problemmodus. Schlechte Laune garantiert.
2. Ein häufigerer Rollenwechsel zwischen Programmierer und Tester schafft Abstand zu Code. So entsteht Raum für Reflektionen. Das kann nur positiv sein, denn dann sehe ich plötzlich Dinge, die ich beim unausgesetzten Programmieren "im Flow" übersehen würde. Solcher Rollenwechsel entschleunigt auch in gewisser Weise. Auch das ist gut: für die Seele und den Code.

Also mal abgesehen von den Vorteilen automatischer Tests in punkto Refaktorisierbarkeit von Code habe ich für mich gemerkt, dass der Gewinn schon davor in einem guten Gefühl, in Entspannung liegt. Positive Einstellung und Entschleunigung machen einfach Spaß. Ich habe mich sozusagen grün gefreut angesichts der wachsenden Zahl kleiner grüner, also positiver Rückmeldungen vom Unit Testing Framework in ReSharper 4.0 (s. Bild oben).

So richtig zufrieden haben mich die grünen Rückmeldungen aber erst werden lassen, als ich zusätzlich noch auf die Codeabdeckung der Tests geachtet habe. Fehlerfreiheit lässt sich ja nicht nachweisen. Also sagt ein grüner Test nicht, dass Code ohne Fehler ist. Tests überprüfen nur Erwartungen. Um ein gutes Gefühl zum Code zu bekommen, muss ich mehr als eine Erwartung haben; jeder Teil des Codes - jede Verzweigung, jede Methode - sollte meine Erwartungen erfüllen. Also müssen meine Tests möglichst viel Code abdecken. Meine Wunschmarke ist 90% Codeabdeckung. 100% sind natürlich noch besser - wenn auch nicht immer ausreichend -, aber ab und an lasse ich mal den Code für einen exotischen Fehlerfall ungetestet.

Mit der Integration von TestDriven und NCover habe mein gutes, grünes Gefühl dann gefestigt. Wie das nebenstehende Bild zeigt, decken meine Tests 97% der Codebasis ab. Das finde ich für den Zweck des Beispielcodes ausreichend.

Und so habe ich mich denn wirklich gut gefühlt, ganz grün vor Spaß, statt vor lauter Bugs schwarz geärgert. Architektur und Testen sind Gewohnheiten. Wenn man sie sich zum Nutzen der Codequalität einmal angeeignet hat, dann ist´s schwer, sie wieder abzustreifen. Aber es sind ja keine schlechten Gewohnheiten. Und sie haben mir ein gutes Gefühl verschafft. Was will ich mehr?

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: 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.