Flominator's Kruschtelecke

Mein Ansatz, Gute Nachrichten in einer Gruppe bei YiGG oder einer Gruppe bei Webnews zu sammeln, brachte leider nicht den gewünschten Erfolg.

Nach weiteren Fehlversuchen über ein Delicious-Tag und den RSS-Aggregator feedonfeeds, bei denen ich immerhin glücklicherweise Kontakt zu @Sumomi bekommen habe, stelle ich daher das Projekt ein.

Ein weiterer Grund war die Tatsache, dass es mittlerweile ausreichende Quellen für gute Nachrichten im Web gibt:

• @positives
• weSmile
• theSunshine

Das Ende dieses Projekts ist dennoch eine gute Nachricht für mich: Mehr Zeit für Wikipedia

Gestern Abend war ich mit meiner Freundin zum zweiten Mal auf einem P!nk-Konzert in Freiburg, zu dem ich hier gerne ein paar Worte verlieren will:

• Vorband: Die Vorgruppe Evermore hatte es mit dem Publikum nicht leicht. Trotzdem gelang es ihnen am Ende ein wenig Stimmung zu machen. Das lag nicht zuletzt an der kurzen Black-Eyed-Peas-Einlage: ''I Gotta Feeling''.
  
  
• positiv: gute Show, bunte Kostüme, gut gelaunte Künstlerin die „ihren Kater von Vorgestern bezwungen hatte“, Platz mit guter Sicht, erschwingliche Posterpreise und die Bohemian Rhapsody.
  
  
• negativ: sehr abruptes Ende (nicht einmal die Drumsticks wurden geworfen), der Power-Song Trouble als Klavierversion, ein mir nicht bekanntes Cover von Led Zeppelin und zu viel Sex in Show und Kostümen (oder dem, was davon übrig war).
  
  
• enttäuschend: Das Publikum. Um mich herum sang bei vielen Songs des aktuellen Albums Funhouse kein Mensch mit. Von Klatschen und Hüpfen brauche ich da gar nicht zu reden. Bei den Balladen sah ich nur Digitalkameras und Fotohandys und lediglich ein weiteres Feuerzeug. Hat sich das Verhalten bei Konzerten in den letzten Jahren so verändert oder bin ich einfach verwöhnt von den Toten Hosen?
  
  
• Fazit: Die depressive Grundstimmung des Albums brachte sie glücklicherweise nicht herüber, daher waren Show und Musikauswahl durchaus gelungen. Mit diesem lahmen Publikum und dem merkwürdigen (an anderer Stelle ja durchaus passenderen) Finale finde ich es allerdings gar nicht so „Schwer vorstellbar, dass jemand unzufrieden die Rothaus-Arena verließ“, wie das die Badische Zeitung heute schrieb.

Update vom 28. November 2009: Mittlerweile hat die Vorgruppe Evermore ein Bild vom Publikum getwittert.

Als ich in meinem neuen Job anfing, wollte ich mir natürlich sofort meine GTD-Werkzeuge einrichten. Dazu gehört auch, dass Mails, die von mir im CC an mich geschickt werden, in den Ordner @WARTEN verschoben werden. Per Filter war das kein Problem. Schwieriger wurde es da schon, diese Mails in Outlook 2000 als gelesen zu markieren. Google verriet mir, dass das in Outlook 2000 standardmäßig nicht über eine Regel möglich ist. Daher war ich gezwungen, ein Makro hierzu zu erstellen.

Dies geschah über die Menüeinträge Extras => Makro => Visual-Basic-Editor. Dort wählte ich links im Dropdown-Menü Application aus und erzeugte rechts eine neue Methode beim Ereignis NewMail. Diese ersetzte ich mit folgendem Code:

Damit wurde die einkommende Mail nach einer Sekunde als gelesen markiert. Ehrlich gesagt, werden alle Mails im Ordner als gelesen markiert, aber das sind Details ...

Was mich dann allerdings noch störte, war die Benachrichtigung im System-Tray (rechts in der Ecke), dass ich eine neue Nachricht habe. Um sie loszuwerden, überlegte ich mir, was ich normalerweise per Maus täte, um sie auszublenden. Ich würde einfach die besagte Mail kurz öffnen und wieder schließen, um ein Lesen vorzutäuschen. Das habe ich anschließend ebenfalls per VBA umgesetzt und unten an die Methode angehängt:

Als ich dann noch die Sicherheitseinstellungen für Makros herabgesetzt hatte (Extras => Makro => Sicherheit => Hoch), konnte ich damit beginnen, nachverfolgbare Mails zu verschicken.

Wie ihr natürlich alle wisst, bin ich ein großer Fan des Open-Source-Editors Notepad++. Dieses Programm erfüllt einfach alle Wünsche, egal ob man nur schnell etwas notieren möchte oder doch ein etwas längeres Skript bearbeiten will.

Kurzum: Notepad, der Editor aus dem Standardlieferumfang von Windows hat ausgedient. Notepad++ sollte als Standardeditor eingerichtet werden. Doch wie? Hier wird erklärt, welche Dateien man ersetzen und welche Änderungen man an der Registry vornehmen müsste. Für alle, denen das zu aufwändig ist, habe ich ein kleines Skript für Windows XP geschrieben (ratet mal in welchem Programm ...), das die Bearbeitungen übernimmt:

Gebrauchsanweisung
Einfach NPPLauncher herunterladen und zusammen mit obigem Batchskript als _replacenp.bat in den Installationsordner von Notepad++ packen.

Disclaimergedöhns
Natürlich übernehme ich keinerlei Haftung für eventuelles unvorhersehbares Fehlverhalten meines Skriptes. Falls es Probleme gibt, freue ich mich aber trotzdem über Feedback.

Viel Spaß damit!

Nach der Session Clean Code Developer und einem weiteren leckeren Mittagessen, folgte die letzte Session, die ich noch besuchen konnte: Christian Binder informierte darin über Neuheiten zur kommenden Version der Entwicklungsumgebung aus dem Hause Microsoft. Da wir im Unternehmen "nur" Visual Studio und kein Team System einsetzen, war es für mich stellenweise ein wenig schwer, den Ausführungen zu folgen. Hier sind die Punkte, die ich (zumindest ansatzweise) verstanden habe und die mir notierenswert erschienen:

• UI-Automation-Testing (Coded UI-Test/ Test Edition)
  • Elemente aus UI greifen und automatisieren
  • unterstützt werden sollen Win32, WinForms, WPF und Document Object Model von Internet Explorer und Firefox
  • später auch Silverlight (Community Technology Preview nach RTM von VSTS 2010)
  • nutzt Accessabillty-Frameworks wie UIA von Anwendungen zur Barrierefreiheit (Screen Reader etc.)
  • Controls von Drittanbietern müssen gewisse Schnittstellen implementieren, damit auch sie erfasst werden
• Tools für manuelles Testen
  • Anlegen eines Work-Items "Testcase", das an Requirement/UserStory hängt
  • spezielle UI für Tester, die keine Entwickler sind (Manual Test Runner/Test Edition oder Test Essentials)
  • Tester klickt durch und nimmt dies ggf. per Rekorder auf
  • Screenshots und Videoaufzeichnung des manuellen Tests möglich
  • Bugs können direkt aus dem Manual Test Runner erzeugt werden
  • Integration mit Team Test Lab
  • Umwandlung in einen kodierten Test (C#) möglich
• Team Test Lab
  • Environment (derzeit als Hyper-V evtl. später auch als virtuelle Maschine per vmWare-Schnittstelle) aus Buildprozess heraus erzeugen und Build nach dort deployen
  • Verbindung mit Requirements
  • kann in Verbindung mit dem Manual Test Runner verwendet werden, um Tests gegen diese Test Environments auszuführen
  • Screenshot bei Verletzung eines Requirements
  • ggf. Erzeugung eines neuen Bugs mit der virtuellen Umgebung im Anhang (sehr schnelle Reproduktion möglich)
• Test Impact Collector
  • feststellen, welche Tests überhaupt von einer Änderung betroffen sind und durchlaufen werden sollten
  • Unit-Tests und manuelle Tests
• Oberfläche der neuen IDE ist komplett in WPF geschrieben
  • bei Microsoft intern von über 3000 Anwenden genutzt
• durch Extensibility API stark auf Erweiterbarkeit ausgelegt
• UML/DSL-Designer in Architect Edition (Arc Edition)
  • Kommunikationslinien zwischen den einzelnen Architekturschichten können mit Code verglichen werden -> unzulässige Kommunikationen im Code finden (oder auch zwischen Namespaces)
  • keine veralteten Architektur-Flipcharts mehr
  • erlaubt Reverse Engineering: Methodenaufrufe -> Sequenzdiagramm
  • Analyse von Codeabhängigkeiten
• Profiler (Developer Edition)
  • besonders hilfreich bei Threading-Problemen
  • während der Entwicklung von Windows 7 genutzt, um Performace-Probleme zu lösen
  • Hotpath zeigt an, wo meiste Rechenzeit liegen gelassen wird
  • Testcase-Profiler kann Auswirkungen von Änderungen auf die Rechenzeit zeigen
• komfortableres Reporting, daher können Entscheider sich zukünftig selbst ihre Zahlen ziehen und entlasten damit die Entwickler
• langsame Anwendungen können bald nicht mehr durch neue Rechner beschleunigt werden, wenn sie Single-Threaded arbeiten und nur wenige der Multiprozessoren dadurch belastet sind
• Verfolgen von Veränderungen in (Changesets) in Branches

Fazit: Es scheint ein sehr umfangreiches Entwicklungssystem zu werden, das den Entwickler und alle restlichen Beteiligten eines Softwareprojektes in großem Maße unterstützen wird. Da solche Qualität ihren Preis hat, bleibt jedoch fraglich, welche Unternehmen sich das leisten können, leisten wollen und leisten werden ...

Update: Dank geht an Christian Binder für das Feedback. Bitte schaut euch seine kurzen Videos zur Beta 1 an.

Die vorletzte Session auf dem Open Space, die ich nach Testen/Getting Things Done besucht habe, drehte sich um das Programm Clean Code Developer von Ralf Westphal und Stefan Lieser. Letzterer war höchstpersönlich anwesend, um uns in die Geschichte und die Details von CCD einzuweisen:

• guter Entwickler erzeugt Qualität -> hält seine Werte ein
• Analogie dazu: (Guter) Arzt wäscht sich vor Operation die Hände und lässt sich das nie nie nie ausreden
• Werte für Codequalität
  • Korrektheit (funktional, optisch, leistungsfähig, ..)
  • Evolvierbarkeit (Einbau desselben Features kostet zu jedem Zeitpunkt gleich viel)
  • Produktionseffizienz
  • Reflexion
• Ergebnis: 40 Bausteine zum Erreichen von mehr Codequalität
• Aufteilung in fünf Grade
• zur Festigung wird jeder Grad mindestens 21 Tage gehalten
• am Ende wird wieder von vorn begonnen, da man immer noch besser werden kann
• Dokumentation des aktuellen Grades über ein Armband
• Armband bringt Leute ins Gespräch und hilft, die Idee zu verbreiten
• nicht alle Entwickler interessieren sich für sauberen Code
• häufig ist keine Zeit zur Einarbeitung vorhanden.
• Ist das Erlernen neuer Fertigkeiten zu Erhaltung der Arbeitskraft in der täglichen Arbeitszeit erhalten oder muss man dafür in der Freizeit investieren? Es hängt vom Lohn ab
• These: es dauert nicht länger, Clean Code zu schreiben, als Crappy Code (zumindest langfristig gesehen)
• Python und Ruby on Rails liefern bereits beim Anlegen eines neuen Projektes ein Verzeichnis für Unit-Tests, warum nicht auch Visual Studio?
• Grenze zwischen PHP (unsauberes Skripting, bä bä bä) und Java (ganz toll objektorientiert mit Unit-Tests und so) ist deutlich. Bei C# sind die ganzen VB-Pfuscher durch .NET auch im Boot.
• Microsoft vermarktet häufig nur Tools, die dem Benutzer mit viel Klickibunti das Leben erleichtern. Codequalität scheint ein wenig vernachlässigt zu werden.

Fazit: Bei uns im Büro erfuhr ich bereits Ende letzten Jahres von dieser Initiative. Ich hatte sie mir auch bereits auf "vielleicht/irgendwann" notiert, aber bisher noch keinen konkreten Einstiegspunkt für mich gefunden. Nun scheint es mir, dass man auch ohne den Kauf des Buches aktiv loslegen kann. Vermutlich werde ich daher in den nächsten Wochen die Seite zum roten Grad in Angriff nehmen ...

Nachdem man den Eingangskorb durchgearbeitet hat und den nächsten Schritt beschlossen hat, wird jede Aufgabe erledigt, die in weniger als zwei Minuten zu schaffen ist. Doch was passiert mit dem Rest der nächsten Schritte?

Hier kommen David Allens Kontextlisten ins Spiel: Die einzelnen nächsten Schritte werden dem Kontext zugeordnet, in dem sie erledigt werden können. Denn, was nützt einem die Information, dass man neue Batterien für die Taschenlampe kaufen muss, wenn man gerade im Zug sitzt? Befindet man sich nun in einem Kontext mit Liste, kann man je nach Zeit, Energie und Priorität (in dieser Reihenfolge!) Punkte daraus abarbeiten. Störende Punkte, die man gerade sowieso nicht erledigen kann, finden sich auf anderen Listen und verschwenden daher keine unnötige Suchzeit.

David allen schlägt bereits eine Menge potentieller Listenkontexte vor, die jeder an seine Bedürfnisse anpassen kann und dies auch tun sollte. Bei mir sieht das folgendermaßen aus:

Listen auf Papier

• @Daheim: Schritte ohne PC
• @Freundin: Schritte mit oder bei der Freundin
• @Oma: quasi siehe @Freundin
• @Besorgungen: Einkäufe etc. die quasi überall möglich sind
• @Oben: Besorgungen, die "oben" im Schwarzwald erledigt werden müssen
• @Freiburg: Besorgungen, die nur erledigt werden können, wenn ich mal wieder dort bin
• @Garage: Schritte am oder im Auto (Ölmessung, Staubsaugen, Winterreifen)
• @Entwicklungsrechner: zweiter PC im Büro (kein Outlook verfügbar)
• @Phone: zu tätigende Anrufe (mittlerweile in @Daheim enthalten)

Listen am PC

• @Online: Ordner in Mozilla Thunderbird für Schritte, die daheim am PC zu erledigen sind. Liste wird bei Bedarf (Reisen) mit Tags für @daheim und @online versehen, um filtern zu können.
• @Work: Outlook-Aufgaben, die im Büro und nicht am Entwicklungsrechner geschehen müssen
• @saugen: getaggte del.icio.us-Links für größere Downloads
• @bandwidth_needed: getaggte del.icio.us-Links für Online-Schritte mit größeren Datenaufkommen (Videos, ...)
• @Leerlauf: Explorer-Ordner am Heimrechner für Schritte mit Bedarf an keiner Aufmerksamkeit, aber größerer Rechenzeit (Panorama-Stitches, zu brennende CDs und DVDs, ...)
• @Reinhören: Audio-Dateien zum Durchhören (Songs, Alben, Podcasts, ...)
• @DSL: Uploads für Wikipedia und Flickr (vgl. @saugen)

Stoffliche Listen

• @Lesen: Mappe mit Material zum Lesen (gedruckte Blogartikel, Literatur für Wikipedia-Artikel, Gebrauchsanweisungen neuer Geräte, ...) für unterwegs
• @Lesen: Ablagekorb im Büro
• @TV: Videos und DVDs (aufgenommen oder ausgeliehen) zum Anschauen

Erfahrungen zum Umgang mit nächsten Schritten und Listen

• Meist bringt das Suchen nach dem nächsten Schritt schnelle Entscheidungen. Hinterher finden sich manchmal effizientere Wege, wie man es besser hätte machen können - na und?
• Bei komplexen Projekten kann auch "nächster Schritt bestimmen" ein nächster Schritt sein
• Wichtig ist die gute Vorbereitung nächster Schritte: Bevor man zum nächsten Punkt im Eingangskorb wechselt, sollte man sich immer fragen, was man alles für die Erledigung des gerade beschlossenen Schrittes benötigt. Kann man vielleicht schon eine Telefonnummer heraussuchen, Daten aus dem Internet herunterladen etc.? Ist es dann soweit, kostet es weniger Überwindung, den Schritt durchzuziehen.
• Schritte müssen konkret formuliert sein: Bei einem Nachmittag in Freiburg bekam ich quasi alle Schritte erledigt, abgesehen von "Geschenk für Jenny". Warum? Ich hatte eigentlich keine Ahnung, was ich ihr schenken wollte oder wo ich suchen sollte.
• Schritte mit Deadlines notiere ich zudem im Kalender, um sie nicht doch aus Versehen einmal zu vergessen.

Fazit
Mit dem Kontextbezug gelang es mir bereits kurz nach der Einführung von GTD, ewig aufgeschobene Dinge umzusetzen: Monate lang lagen zwei Hörbücher herum. Ich kann mich zuhause einfach nicht hinsetzen und konzentriert zuhören. Es war eindeutig der falsche Kontext. Kaum hatte ich die CDs ins Auto befördert, hatte ich sie auch schon angehört.

Auch einen Film aus der alten Kamera hatte ich nie zum Entwickeln gebracht. Kaum hatte ich ihn vor Tür gelegt und ihn daher ins Büro mitgenommen, stand er auch schon auf @Besorgungen. Beim nächsten Drogeriebesuch hatte ich ihn auch schon abgeben. Die Tatsache, dass sich der Film als leer erwies war ... überraschend. Aber: Ich hatte es endlich getan und der Film lag nicht lange daheim herum!

Offene Fragen
Leider gibt es ein paar Dinge, die sich mir im Buch nicht wirklich erschlossen haben:

• Was passiert, wenn übernächster Schritt auch nur zwei Minuten dauert?
• Was ist, wenn man erkennt, dass ein Schritt doch länger dauert, man aber schon angefangen hat?
• Wohin mit Zeug für einen nächsten Schritt ohne Projekt?
• Wie verwalte ich die übernächsten Schritte?

Wie bereits beschrieben, hatte ich in meinem Erfassungsprozess bisher immer ein Problem: Ich konnte in der Dusche keine Notizen machen. Mittlerweile ist auch dieses Problem gelöst:

Als ich vor ein paar Wochen mit meiner Freundin in Heidelberg war, musste sie mich ja unbedingt in den dortigen Butlers ziehen. Zum Glück hat sie das gemacht!

Testing
Die erste Session am Sonntag hatte mit "Testen" ein etwas zu umfangreiches Themengebiet. Daher ging die Diskussion nicht ganz in die Richtung, die ich mir gewünscht hätte. Trotzdem gab es ein paar erwähnenswerte Infos:

• UI-Tests lohnen sich vermutlich nur für Standardarbeitsschritte, sonst zu hohes Preis-Leistungs-Verhältnis
• Webtests sind meist trivial und finden keine richtigen Fehler
• Visual Studio (in welcher Edition?) erlaubt Klickreihenfolge im Browser abzuspielen und als Lasttest mehrfach auszuführen
• Lasttests bei ERP-Systemen heißt, einmal die Weihnachtszeit nachzuspielen
• Tester stumpfen bei häufiger Wiederholung ab und sehen Fehler nicht mehr => Vorteil von UI-Tests
• bestes Preis-Leistungsverhältnis haben Unit-Tests für Rechenfunktionen

Getting Things Done
Nachdem mich das klingelnde Handy aus dem Raum geholt hatte, entdeckte ich eine kleine, aber eine Diskussionssrunde zum Thema Getting Things Done. Obwohl es nicht direkt um das Buch ging, gab es auch dort ein paar Anregungen:

• alle Mails nach dem Urlaub löschen -> wer etwas will, der kommt schon wieder
• (wirklich) dringende Sachen sollten per Telefon geschehen, dort ist auch Rausreißen aus der aktuellen Tätigkeit legitim
• Was ist schon wirklich dringend?
• Abteilungsleiter veröffentlicht seinen Wochenplan, damit seine Untergebenen sehen, was er die Woche über tut
• Corporate-Mikroblogging wie Yammer kann ebenfalls dabei helfen, zu sehen, was die Leute um einen herum so tun

Nachdem zu Inversion of Control und Dependency Injection auf dem Open Space in Ulm keine Fragen mehr kamen, handelten wir spontan noch zwei andere Themen ab:

Mocking

• "normale" Frameworks wie z.B. Rhino Mocks nutzen Proxy-Mechanismusmit Vererbung
• Problem: statische Klassen sind nicht mockbar
• Typemock erlaubt Nutzung der Profiler-API; dadurch auch Mocking statischer Objekt möglich (Date.Now trotzdem nicht)
• Frameworks mit Automock-Funktionalität ermöglichen es, dynamisch zu mocken, was gerade benötigt wird
• RhinoMocks nutze früher Record-Replay-Modus, heutiges Prinzip ist Arrange-Act-Assert
• siehe auch: Einfacheres Mocken von Eigenschaften eines Objektes

Interfaces

• Interfaces verhindern, dass man "virtual" vergisst
• abstrakte Basisklassen können bereits Funktionalitäten implementieren
• Methoden abstrakter Basisklassen können ggf. überschrieben werden, MÜSSEN sie aber nicht
• Interfaces erfordern bei Erweiterung neue Methoden in allen von ihnen abgeleiteten Klassen
• Methoden von Interfaces müssen nicht implementiert werden, wenn die Basisklassen sie bereits implementieren
• Kommentare zu Methoden des Interfaces sollten per Konvetion dort im Interface geschrieben werden, nicht in der Implementierung
• alternativ können mit ghostdoc Kommentare von beerbten Objekten kopiert werden

Fazit
Mein Highlight der zweiten Hälfte der Session waren das Beispiel für das neue Arrange-Act-Assert-Schema bei RhinoMocks sowie der Verweis auf ghostdoc. Dieses Tool kann ich nur wärmstens empfehlen, um automatische Dokumentationskommentare zu generieren. Meist sind sie relativ treffend, falls nicht, sind sie dann zumindest lustig.