Monthly Archives: December 2010

Bookmark Backup

Today, TechCrunch reported about Yahoo shutting down the widely used bookmark  service del.icio.us.Right after this, a statement from Yahoo showed a possible alternate future of the service.

Many of you have read the news stories about Delicious that began appearing yesterday. We’re genuinely sorry to have these stories appear with so little context for our loyal users. While we can’t answer each of your questions individually, we wanted to address what we can at this stage and we promise to keep you posted as future plans get finalized.

However, who still wants to quick backup his/her boomarks could use curl following the tips from Martin Koser:

curl --user username:password -o DeliciousBookmarks.xml -O "http://api.del.icio.us/v1/posts/all"

Wo sind meine Signaturen in Outlook 2010 hin

Ein anscheinend weit verbreitetes Problem mit Outlook 2010 scheint eine Fehler mit dem Signatur-Editor Signatures & Stationary zu sein, der es eigentlich ermöglicht Signatur-Dateien für E-Mails zu erstellen und zu verwalten. Der Editor öffnet sich nicht und der Benutzer kann daher keine Signaturen anlegen oder gar auswählen. Speziell für den Geschäftsverkehr sind Signaturen jedoch unerlässlich. Dabei gibt es grundsätzlich zwei Wege an den Dialog zu gelangen.

In einer Nachricht kann über die Schaltfläche Signatures / Signatures… der Editor geöffnet werden.

Signaturen in Outlook 2010 aus Mails bearbeiten

Alternativ kann dies auch über das Backstage von Outlook unter dem Menüpunkt File / Options / Mail / Signatures … geschehen.

Signaturen in Outlook 2010 aus den Einstellungen bearbeiten

Aus unerklärlichen Gründen kann es nun passieren, dass trotz wiederholtem Betätigen der Schaltflächen nichts passiert. Es erscheint kein Dialog, keine Fehlermeldung kein Nichts. Warum? Man weiß es nicht. Muss die Signatur bei jedem Geschäftsbrief von Hand eingefügt werden, steigt der Frustfaktor recht schnell an und Outlook fällt schnell in Ungnade.

Überwiegend lässt sich dieses Phänomen auf Systemen mit einer 64-Bit-Version von Windows 7 und einer 32-Bit-Version von Office 2010 beobachten. Lösen lässt sich das Problem mit wenigen Handgriffen.

Zunächst öffnet man den Registry Editor (regedit.exe) und navigiert zu

HKEY_LOCAL_MACHINESOFTWAREClassesWow6432NodeCLSID{0006F03A-0000-0000-C000-000000000046}LocalServer32

hier ersetzt man den Wert für Schlüssel Default den Wert

C:Program Files (x86)Microsoft OfficeOffice14Outlook.exe

ein. Nun wiederholt man das gleiche für

HKEY_LOCAL_MACHINESOFTWAREClassesCLSID{0006F03A-0000-0000-C000-000000000046}LocalServer32

Nach einem Neustart von Outlook sollte dann der Dialog zum Editoren von Signaturen ohne Widersprüche starten und das Wochenende ist gerettet.

Signatures & Stationary Dialog von Outlook 2010

xUnit and xUnit.BDDExtensions using ReSharper 5.1

Wer von MSTest auf xUnit (derzeit 1.6.1.1521) und ggf. xUnit.BDDExtenions umsteigt wird schnell die integrierte Unterstützung innerhalb von Visual Studio vermissen. Mit ReSharper alles kein Problem, denkt man. Die aktuelle Version 5.1 von ReSharper (ich verwende derzeit Build 5.1.1727.12) macht hier allerding ein paar Probleme, die sich innerhalb weniger Minuten jedoch lösen lassen.

Laut der Plug-In-Seite von ReSharper bringt xUnit.net Contrib die gewünschte Unterstützung mit sich. Hier ist s jedoch erforderlich derzeit auf die Version 0.4.1 alpha auszuweichen. Dabei sollte man sich nicht davon abbringen lassen, dass die angegebene Version einen speziellen ReSharper-Build adressiert.

Die Installation bedarf es lediglich eine Reihe von Schritten aus der readme.txt zu befolgen. Zunächst muss der Inhalt des Ordners xunitcontrib.runner.resharper.5.1 aus dem Archiv in das Verzeichnis

C:Program FilesJetBrainsReSharperv5.0binplugins

oder auf 64-Bit-Maschinen

C:Program Files (x86)JetBrainsReSharperv5.0binplugins

kopiert werden. Wurden auf dieser Maschine zuvor noch keine ReSharper-Plug-Ins installiert, muss der Ordner plugins manuell angelegt werden.

Nun ist der die Datei xunit.xml aus dem Ordner resharper.external.annotations nach

C:Program FilesJetBrainsReSharperv5.0binExternal Annotations

bzw. dem entsprechenden Ordner auf 64-Bit-Maschinen

C:Program Files (x86)JetBrainsReSharperv5.0binExternal Annotations

zu kopieren.

Im letzten (optionalen) Schritt gilt es das Live Template zu importieren. Hierüber lassen sich xUnit-Code-Snippets nutzen. Dazu über das Menü ReSharper / LiveTemplates… den Templates Explorer starten und über das Import-Icon entweder die Datei xunit-ae.xml oder xunit-xe.xml aus dem Ordner resharper.live.templates auswählen.

Der Unterschied der beiden Live Templates ist lediglich  ist ob die Code-Snippets mit dem Buchstaben a oder x aufgerufen werden können.

ReSharper Live Templates

Nach der Installation (und einem Neustart von Visual Studio) lassen sich die xUnit-Tests direkt über den ReSharper Unit Test Explorer ausführen. Eine positive Überraschung war, das die xUnit.BDDExtenions ebenfalls sofort über den Unit Test Explorer ausgeführt werden konnten. Zuvor habe ich lediglich die xUnit.BDDExtensions gegen die aktuelle xUnit-Version (1.6.1.1521) kompiliert.

ReSharper Unit Test Explorer

Dem Testen mit xUnit innerhalb von Visual Studio steht damit nichts mehr im Weg.

Starting BDD

Immer wieder einmal taucht der Begriff Behavior Driven Development oder BDD auf. Obwohl das verhaltensgetrieben Entwickeln einige interessante Vorzüge fällt der Einstieg oftmals schwer. Dabei basiert BDD auf den Techniken im Test Driven Development. Das größte Problem scheint eine vor allem das Fehlen einer für Einsteiger verständliche Einführung in BDD zu sein. Im Folgenden werden daher einige Grundprinzipien des BDD zusammengetragen, die den Einstieg erleichtern sollen.

Test Driven Development (TDD) ist eine Entwicklungsmethode die seit einigen Jahren immer mehr Verbreitung findet. Dabei geht es hauptsächlich darum, Tests vor der eigentlichen Implementierung zu entwerfen und zu schreiben. Eine Möglichkeit stellen hierzu Unit-Tests dar, die i.d.R. auf die kleinste zu testende Einheit (Unit) angewendet werden. Da  das Konzept prinzipiell vielversprechend ist, haben sich Unit-Tests auch in der Clean-Code-Developer-Bewegung eingefunden. Das bekannteste Werkzeug zum Erstellen von Unit-Tests in der .NET-Welt ist derzeit NUnit, das ursprünglich von JUnit portiert und für die .NET-Plattform angepasst wurde. Ein noch immer gutes Buch für den Einstieg in die NUnit ist Pragmatic Unit Testing in C# with NUnit von Andy Hunt und David Thomas.

Während in der Theorie alles wunderbar klingt, hat sich bei zahlreichen Gesprächen mit Kollegen und Freunden immer wieder eine Reihe von Frage gestellt.

Wo fange ich überhaupt an zu testen?  Was soll ich jetzt testen? Wie soll das ich testen? Wann höre ich endlich auf zu testen?

Im Bestreben möglichst viele Tests zu schreiben und eine 100%ige Code-Abdeckung zu erreichen schleichen sich jedoch schnell Trivial-Tests (z.B. für einfache Properties) ein, denn diese sind einfach und schnell zu schreiben, schlagen nie (oder zumindest selten) fehl und erwecken den Anschein, dass der Code aufs Ausführlichste getestet sei.

Ein alternativer Ansatz, der zumindest einige der Fragen beantwortet, ist das Behavior Driven Development (BDD). Ein guter Einstiegspunkt ist der Artikel Introducing BDD von Dan North. Als Ausgangspunkt dient hierbei die Beschreibung einer User-Story.

As a [ROLE]
I want [GOAL]
so that [MOTIVATION]

Im Laufe des Artikels wird die Verhaltensbeschreibung der Implementierung weiter in ein Given-When-Then-Muster ausgebaut.

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

Bei BDD ist durchaus die richtige Wortwahl für entscheidend. Anders als beim reinen TDD stellt sich jedoch nicht die Frage, was getestet werden soll, sondern wie sich das System verhalten soll. Verwendet man Dan Norths Einstiegspunkt As-I-So, kann man das Verhalten aus Nutzersicht beschreiben, und dadurch Test auf Basis von User-Storys schreiben.

Konzentriert man sich darauf, nur die für den Test benötigte Funktionalität zu implementieren hilft das unter anderem dazu den Fokus nicht zu verlieren und Feature Creep zu vermeiden. Code der nicht benötigt wird um das Verhalten zu erreichen ist vermutlich nicht notwendig, egal wie viel Spaß es vermutlich macht ihn zu schreiben. In diesem Sinne unterstützt BDD das YAGNI-Prinzip. Im Artikel Getting started with BDD style Context/Specification base naming von Jean-Paul Boodhoo finden sich einige Spezifikationen, die einen ersten Eindruck geben, wie diese aufgebaut sein könnten.

Ein wenig verwirrend ist die Tatsache, dass nur wenig klare Beschreibungen bezüglich des Vorgehens bei BDD sind. Ein Blick beispielsweise in den Code Magazine-Artikel Behavior-Driven Development zeit einige der Grundkonzepte von BDD auf.

Eine gemeinsame Sprache (Shared Language/Ubiquitous Language) ist die Grundvoraussetzung zur Erstellung von Spezifikationen (Specifications) beispielsweise nach dem As-I-So Ansatz. Das Ergebnis hiervon ist eine Reihe von Akzeptanzkriterien die zur Abnahme der gewünschten Funktionalität zu erfüllen sind. Dabei könnte die Granularität der Spezifikation wie folgt verfeinert werden: User Story (Akzeptanzkriterium) –>  Kontextspezifikation –> Code (Ausführbare Spezifikation). Die Kontextspezifikation (Context Specification) besteht aus dem Tripel Concern – Context – Obersvation.

Die Beobachtung (Observation) beschreibt was der eigentliche Test überhaupt macht bzw. was überhaupt getestet wird. Die Organisation von Tests sollte dabei nach dem Concern erfolgen, wobei mehrere Beobachtungen pro Belange (Concern) möglich sind. Im dotnetpro Artikel Die Gleiche Sprache Sprechen von Stefan Lieser (Ausgabe 11/2009) findet sich ein recht gutes Beispiel, dass dies verdeutlichet. Der Kontext (Context) beschreibt Systemzustände (oder Voraussetzungen), die mehreren Beobachtungen gleich sind.

Im Gegensatz   zu TDD sollte die Benennung von Tests keine technischen Details kommunizieren sondern das gewünschte Verhalten auf Basis der gemeinsamen Sprache (Shared Language) wiederspiegeln. D.h. nach dem Hinzufügen des ersten Kunden in eine Kundenliste anstelle der Test-Methode IsNotNullTest könnte in BDD eine Beobachtung ContainsOneCustomer lauten.

Der Mechanismus dahinter (gleichgültige welche Werkzeuge verwendet werden) ist immer noch TDD, allerdings wird nicht mehr die kleineste Funktionseinheit getestet sondern (im optimalen Fall) ein in sich abgeschlossenes Teil-Verhalten des Systems. Natürlich schließt der Einsatz von BDD der Einsatz von TDD nicht aus.

Grundsätzlich kann jedes TDD-Framework für BDD genutzt werden. Dariusz zeigt diesem Artikel wie BDD mittels MSTest aussehen könnte. Vorteil ist ganz klar, dass alles innerhalb der Visual Studio-IDE stattfindet, die Code-Abdeckung berechnet werden kann und die Tests mit nur wenigen Handgriffen ausgeführt werden können. Reine TDD-Frameworks werden jedoch das Problem auf, das sich die Sprache der Spezifikation nicht ohne weiteres ändern lässt.

Eine Alternativen sind z.B. die auf xUnit.net basierenden  xUnit.BDDExtensions von Björn Rochel, die auch von Alex Zeitler in Behavior Driven Development (BDD) leicht gemacht mit ReSharper und XUnit.NET verwendet werden.

Deutsche Rechtschreibung im Windows Live Writer

Windows Live Writer dürfte auf der Windows Plattform derzeit eines der beliebtesten Blogging-Tools sein. Mit Anbindung an die meisten Blogging-Plattformen und zahlreichen Plug-Ins lässt das Tool kaum wünsche offen. Allerdings ist bisher keine deutsche Rechtschreibprüfung vorhanden. Anstelle dessen konnten unterschiedlichste English-Derivate (es gibt eben Englisch und Englisch) ausgewählt werden. Die Möglichkeit die deutsche Rechtschreibkorrektur zu aktivieren oder eine zusätzliche Sprache hinzuzufügen fehlt bisher gänzlich.

Die Lösung ist recht jedoch einfach. Vorausgesetz auf der betreffenden Maschine ist Office 2010 (32-bit) mit deutscher Rechtschreibkorrektur installiert. Ein Blick in den Ordner

C:\Program Files (x86)\Microsoft Office\Office14\PROOF

sollte Gewissheit verschaffen. Hier gilt es die Dateien

MSSP7GE.DLL
MSSP7GE.dub
MSSP7GE.LX

in den Ordner

C:\Program Files (x86)\Windows Live Writer\Dictionaries

zu kopieren. Nach einem Neustart von Windows Live Writer sollte nun unter Options / Spelling auch der Eintrag German (Reform).

Deutsche Rechtschreibung im Windows Live Write aktivieren

Fish’n’Chips No More

Following All Good Things… it was the day I choose to leave Microsoft Research in Cambridge for the sake of new challenges and adventures. England is not that bad, considering the weather, the living conditions, the food and the traffic…

The last five years with Microsoft Research have been very intense, exciting but also quite exhausting. Our dev team went twice to the Microsoft TechFest showing the Microsoft Computational Science Studio in 2008 even to the press.I met Alan Alda, known as Capt. Benjamin Franklin “Hawkeye” Pierce from the TV drama M*A*S*H, meanwhile presenting us TV show Scientific American Frontiers.

Ein Highlight bei der Entwicklung des Microsoft Computational Science Studio war zweifelsohne die Präsentation durch Craig Mundie während der Microsoft College Tour 2009. Nicht nur dass Craig Mundie hier meinen Code in den Händen hielt, er musste ihn auch gleich an einigen der Top-Universitäten in den USA vorzeigen (u.a. Cornell und Harvard). Das ist einmal eine ganz neue Art von Druck, bedenkt man, dass es sich dabei um einen Forschungsprototypen handelte. Auch hier gab es den einen oder anderen Artikel in der Presse, beispielsweise in der Seattle Times. Überraschend kam dann noch ein Channel 9 Video von dem niemand wirklich wusste, bis es plötzlich online war.

image

Nachdem ich für Coding4Fun 2005 bereits das erste Mal auf der PDC05 mit einem eigenen Stand vertreten war, konnten wir 2009 wir dann auch mit Vedea auf der PDC09 punkten.

Beide in Cambridge entwickelten Prototypen konnte ich Mitte diesen Jahres nochmals im kleinen Kreis bei der .NET User Group in Karlsruhe vorzeigen und habe mich dabei sehr über die interessanten Diskussionen gefreut. Zwei Mal auf der PDC, zwei mal auf dem TechFest ist keine üble Bilanz, die  mit einer Danksagung im Artikel Predictive Models of Forest Dynamics im Fachmagazin Science (Science, vol 30, 13. Juni 2008) noch “aufgewertet” wurde.

Zwischendurch gab es sogar ein Besuch von Bill Gates, dem einige der (Forschungs-) Arbeiten vorgestellt wurden (ich saß in dem Stuhl in dem Bill Gate saß). Aber auch das tägliche Leben ließ sich nicht Lumpen, ob eine Diskussion mit Don Syme (einer der brillantesten Köpfe und bekannt für Generics und F#) oder ein morgendliches “Hi Tony” zu Tony Hoare (jedem Informatikstudent aus dem ersten Semester aufgrund von Quicksort und dem Hoare-Kalküls wohlbekannt), das hat man nicht überall.

Letztendlich konnten wir die eine oder andere Entwicklung an verschiedene Produktgruppen in Redmond weitergeben, und so findet sich vielleicht manch Zeile Code bald wieder in einem der zukünftigen Microsoft-Produkte.