Rash thoughts about .NET, C#, F# and Dynamics NAV.

Am Mittwoch hat die .NET User Group Hamburg das zweite .NET Coding Dojo in wunderbarer Lage im Neuen Wall durchgeführt. Der Dank gilt diesmal Computer Futures, die uns freundlicherweise Raum, Beamer und Getränke zur Verfügung gestellt haben.

Ablauf

Nach einer kurzen Reflektion des letzten Treffens und Klärung der aufgetretenen Syntaxprobleme hat sich das Team dafür entschieden, die Kata.RomanNumerals zu implementieren. Wie beim ersten Treffen haben wir diese relativ einfache Kata auch wieder im Randori-Stil durchgeführt. Da das Team relativ gleich geblieben ist, konnten wir den Ablauf jedoch leicht erweitern. Um etwas mehr Schwung in die Test-Phase zu bringen, habe ich vorgeschlagen immer in der Rot-Phase zu rotieren. Zusätzlich haben wir git als Versionskontrollsystem im Einsatz gehabt und bei jeder Grün-Phase sowie nach Refactorings commited. Das Ergebnis kann auf meinem Github-Account bewundert werden.

Kata

Aus meiner Sicht bildet die Kata.RomanNumerals eine ideale Fortsetzung zur Kata.StringReplacer, die wir beim ersten Treffen hatten und ist praktisch perfekt mit Test-Driven Development lösbar. Insbesondere das nachträgliche Implementieren der scheinbar komplizierten Subtraktionsregel ist wunderbar anhand von wenigen Sonderfällen (= UnitTests) lösbar.

Was lief gut?

• Die Rotation der Teilnehmer klappte wieder problemlos – Danke Jungs 🙂
• TDD wurde als sehr erfolgreich für die Kata angesehen
• Nahezu alle Teilnehmer waren überrascht wie einfach sich die Subtraktionsregel in TDD implementieren lässt
• Die Randori-Form mit Rotation bei Rot sorgt für Aktivität
• Es wurde immer versuchen die einfachste Lösung zu wählen
• Die Rollen Driver, Co-Pilot und Publikum wurden klarer getrennt
• Es wurde nach jedem implementierten Test in das git Repository commited
• Ganz wichtig: Es hat wieder viel Spaß gemacht!

Was wollen wir besser machen?

• Noch mehr Wert auf das Naming legen
• Überraschenderweise hat sich kein Team getraut die Namenskonvention des ersten Teams zu verbessern
• Insbesondere auch die Commit-Kommentare sind noch nicht sehr aussagekräftig
• In den Refactoring-Phasen sollten die Tools (Resharper) besser genutzt werden
• Die Refactorings könnten noch ausführlicher diskutiert werden
• Von Anfang an externe Tastatur und Maus für den Laptop bereit stellen
• Internetverbindung um Syntaxfrage schneller klären zu können
• Parametrisierte Tests benutzen um weniger Test-Codierungsaufwand zu haben

Vielen Dank an alle Teilnehmer – wir sehen uns dann beim nächsten Dojo.

Gestern fand das erste .NET Coding Dojo in Hamburg statt und es war aus meiner Sicht ein voller Erfolg. Als erstes möchte ich mich an dieser Stelle bei der Firma masters of arts für die Räumlichkeit und natürlich bei allen Teilnehmer für die aktive Mitarbeit bedanken.

Durchgeführt haben wir das Dojo im Randori-Stil, d.h. es gab einen Entwickler, einen “Co-Piloten” und das Publikum. Nach jeweils 5 Minuten bzw. jedem neuen Testfall wurden die Positionen mit neuen Teilnehmer aus dem Publikum getauscht.

Nach einer kurzen allgemeinen Einführung in das Thema “Coding Dojo” habe ich die Aufgabenstellungen der Kata.FizzBuzz und Kata.DictionaryReplacer vorgestellt. Durch kurze Abstimmung haben wir dann (vermutlich durch meine Wortwahl beeinflusst) die Kata.DictionaryReplacer gewählt.

Mit der Wahl dieser Kata war ich nicht ganz unglücklich, da wir DictionaryReplacer schon im Online Dojo durchgenommen haben und ich deshalb die Fallstricke schon etwas einschätzen konnte.

Kata.DictionaryReplacer

Create a method that takes a string and a dictionary,
and replaces every key in the dictionary pre and suffixed with a dollar sign,
with the corresponding value from the Dictionary.

Tests

input : "",
          dict empty
output: ""

input : "$temp$", 
           dict ["temp", "temporary"]
output: "temporary"

input : "$temp$ here comes the name $name$",
           dict ["temp", "temporary"] ["name", "John Doe"]
output : "temporary here comes the name John Doe"

[codingdojo.org]

Nach kurzer Einführung in die Vorgehensweise des Test-Driven Developments (TDD) und Diskussion über sinnvolles Naming ging es dann auch richtig in die Entwicklung. Die Kata eignet sich in dieser Form auch sehr schön um tatsächlich “Test first” zu arbeiten. Die Implementierung folgt quasi als logische Konsequenz.

Interessant und ungleich komplizierter wurde es dann als wir eine zusätzliche Anforderung eingebaut haben. Da es sich bei der Kata um eine Art Templatesystem handelt liegt es nahe auch in den Values des Wörterbuchs neue Keys zu erlauben und somit eine beliebige Ersetzungstiefe zu erreichen. Diese Anforderung ist ein wunderbares Beispiel dafür wie sehr man mit Aufwandsabschätzungen daneben liegen kann. 😉

Die rekursive Ersetzung wurde noch sehr schnell gelöst, aber richtig schwer haben wir uns dann mit der Erkennung von zyklischen Ersetzungen und der daraus folgenden Endlosschleife getan. Nach und nach wurden immer kompliziertere Lösungsmöglichkeiten genannt, die aber in der gegebenen Zeit nicht fehlerfrei umgesetzt werden konnten. Als Folge haben wir immer noch einen Test “rot”. Wer Lust hat kann sich also die Quellen vom github Repository ziehen und als Hausaufgabe den verbleibenden Test “grün” machen.

In der Nachbetrachtung haben wir noch einige Sachen festgestellt:

Was lief gut?

• Die Rotation der Teilnehmer klappte problemlos
• Lösungsideen sprudelten förmlich aus dem Publikum
• Interessante Edge-Cases wurden gefunden
• Viele kleine Tipps (z.B. Resharper Shortcuts) wurden ausgetauscht
• TDD wurde als erfolgreich für die Kata angesehen
• Die Randori-Form sorgt für Aktivität
• Ganz wichtig: Es hat Spaß gemacht!

Was wollen wir besser machen?

• Schneller den ersten Test schreiben
• Intensivere Diskussion des Interfaces
• Noch mehr Wert auf das Naming legen
• Versuchen die einfachste Lösung zu wählen
• Mehr Wert auf Refactoring legen
  • wurde etwas vernachlässigt, da wir viel Zeit an der Endlosschleife verbraucht haben
• Die Rollen Driver, Co-Pilot und Publikum klarer trennen
• Nach jedem implementierten Testcase bzw. jeder Rotation der Teilnehmer in das git Repository einchecken
• Von Anfang an externe Tastatur und Maus für den Laptop bereit stellen
• Internetverbindung um Syntaxfrage schneller klären zu können

Als möglichen Termin für das Dojo haben wir jetzt grob jeweils den 3. Mittwoch im Monat vorgeschlagen. Über die Xing-Gruppe der .NET User Group Hamburg werden wir natürlich auch wieder entsprechende Einladungen verschicken.

Inspiriert von Coding Dojos in München und Berlin veranstaltet die .NET User Group Hamburg am 19.5. das erste .NET Coding Dojo in Hamburg.

1. .NET Coding Dojo Hamburg

19.05.2010 – 19 Uhr

Masters of Arts Anwendungsentwicklung GmbH
Johannes Brahms Platz 9
20355 Hamburg

Anmeldung über Xing

Hintergrund

Bei einem Coding Dojo treffen sich Software-Entwickler um ihre Fähigkeiten beim gemeinsamen Lösen einer Programmieraufgabe (der sogenannten Code-Kata) zu verbessern. Dabei soll vor allem der Spaß im Vordergrund stehen. Folgende Grundsätze gelten:

• Das Dojo ist nicht konkurrenzbetont sondern gemeinschafts- und spaßorientiert.
• Vom Einsteiger bis zum erfahrenen Softwareentwickler ist jeder willkommen.
• Lösungen werden im Team erarbeitet, gemeinsam umgesetzt und gemeinsam präsentiert.
• Zur Lösung müssen Tests geschrieben werden.
• Es gibt keine Musterlösung! Die Lösungsmöglichkeiten sind bewusst offen und geben Raum für unterschiedlichste Entscheidungen. Interessant ist insbesondere das gegenseitige Anleiten und Lehren.

[nach http://codingdojo.org/ und http://www.altnetberlin.de/]

RandoriKata

Es gibt verschiedene Möglichkeiten ein Coding Dojo abzuhalten. Für unser erstes Treffen wollen wir die sogenannte RandoriKata-Version probieren. Dabei wird die Problemstellung wird von einem Entwickler-Duo gelöst (Driver und Copilot). Alle anderen Personen sind jedoch eingeladen sich aktiv an der Lösung zu beteiligen und dem Entwickler-Duo Hilfestellungen und Hinweise zu geben. Nach einer gewissen Zeit (ca. 7 Minuten) wird das Duo ausgetauscht und die nächsten Entwickler haben die Chance die Lösung voranzutreiben.

Die Anmeldung ist über Xing möglich.

Last week I talked about F# and functional programming at .NET User Group Paderborn. Here are the dates for my upcoming F# talks:

• 20.10.2009 – 19:00 Bonn – F# talk at Bonn-to-Code.NET
• 18.11.2009 – 19:00 Hamburg – F# talk at .NET User Group Hamburg
• 11.02.2010 -          Bad Homburg – F# talk at .NET Usergroup Frankfurt

Abstract (in german):

Funktionale Programmiersprachen nehmen seit geraumer Zeit einen hohen Stellenwert in der Wissenschaft ein. Demnächst könnte es eine dieser Sprachen sogar aus dem Forschungsbereich direkt in den Mainstream schaffen. Visual Studio 2010 wird neben C# und VB.NET die funktionale Programmiersprache F# als dritte Hauptsprache anbieten. Der Vortrag soll einen Einblick in funktionale Konzepte und deren Umsetzung in F# geben. Insbesondere soll auf “Funktionen höherer Ordnung”, Typinferenz, Currying, Pattern Matching, “Unveränderlichkeit” und parallele Programmierung eingegangen werden.