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


"Every solution will only lead to new problems."

Thursday, 20. May 2010


Bericht vom Ersten .NET Coding Dojo in Hamburg

Filed under: C#,Veranstaltungen — Steffen Forkmann at 6:37 Uhr

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.

Erklärungen

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.

Das Publikum

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

Guter Rat ist teuer

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.

Tags: , , ,

Wednesday, 12. May 2010


“FAKE – F# Make” 1.20.0 released

Filed under: F#,FAKE - F# Make — Steffen Forkmann at 12:26 Uhr

Today I released a new bugfix release for “FAKE – F# Make”. We fixed some path and logging issues and as a new feature we introduced the @@ operator which allows to combine paths.

Tags: , ,

Friday, 7. May 2010


Using a MailboxProcessor to speedup “FAKE – F# MAKE”

Filed under: F#,FAKE - F# Make — Steffen Forkmann at 11:37 Uhr

Earlier today I released “FAKE – F# Make” version 1.10.0. This new release contains a lot path issue fixes for Mono and a new architecture for logging and tracing.

A guy named Joel Mueller had an awesome idea and sent me some patches. He noticed that TraceHelper.fs writes all messages synchronously to the console and/or a XML output file, which means the actual build operations must wait on the writing of hundreds of trace messages, slowing down the actual build.

His idea was to use a MailboxProcessor to buffer up the trace messages and write them out asynchronously, so that the actual build can proceed at full speed.

type Message =

    { Text      : string

      Color     : ConsoleColor

      Newline   : bool

      Important : bool}

 

/// ….

 

let buffer = MailboxProcessor.Start (fun inbox ->

    let rec loop () =

        async {

            let! (msg:Message) = inbox.Receive()

            match traceMode with

            | Console -> logMessageToConsole msg

            | Xml     -> appendXML msg.Text

 

            return! loop ()}

 

    loop ())     

Now all internal logging and tracing functions can post their their messages to the inbox of the MailboxProcessor:

/// Logs the specified string (via message buffer)

let logMessage important newLine message =

    match traceMode with

    | Console ->

        { Text = message;

          Important = important;

          Newline = newLine;

          Color = ConsoleColor.White }

          |> buffer.Post

    | Xml     ->

        { defaultMessage with

            Text = sprintf "<message><![CDATA[%s]]></message>"

                     message }

          |> buffer.Post

This idea reduces the build time of FAKE’s self build from 3 min. to 2 min. Which is really amazing, since I didn’t have to change anything in the build script. This version is compatible to the last released version.

Please download “FAKE – F# Make” version 1.10.0 and tell me what you think.

Tags: , , ,

Monday, 3. May 2010


Erstes .NET Coding Dojo in Hamburg

Filed under: Coding Dojo,Kata — Steffen Forkmann at 14:42 Uhr

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.

Tags: , ,