19. .NET Coding Dojo

Das Thema des 19. .NET Coding Dojos war ein Thema das wir schon mal hatten. Wir haben uns noch mal die Game of Life Kata angesehen um heraus zu bekommen wie wir die Dojos in Zukunft besser moderieren können. Ziel ist für alle Beteiligten einen größeren Lerneffekt raus zu holen.

Wir haben uns bei Computer Futures getroffen und dort bei großartigen Gastgebern in kleiner Runde Verbesserungsvorschläge gesammelt.

19. Coding Dojo

Wir haben besprochen wie man die kommenden Treffen am besten ankündigen kann und neuen Teilnehmern vielleicht ein bisschen den Einstieg vereinfacht. Auch dir Struktur während des Dojos wollen wir etwas stärker vorbereiten damit man zumindest zusammen auf dem gleichen Weg bleibt.

Hier die Punkte die wir uns überlegt haben:

Coding Dojo Verbesserungen

Vor dem eigentlichen Dojo, Bekanntgabe und Vorbereitung der Moderatoren:

  • In der Beschreibung sollten wir ausformulieren wie ein solches Treffen abläuft.
  • Was ein Coding Dojo ist und welchen Modus (Randori Modus) setzen wir ein.
  • Was für eine Aufgabe versuchen wir gemeinsam zu lösen. Eventuell mit Link oder einem Erklärungsvideo.
  • Definieren der Ziele für das Dojo, was soll minimal erreicht werden.

Während des Dojos wollen wir versuchen dem ganzen etwas mehr Struktur zu geben:

  1. Kleine Einleitung, mündlich wie das Treffen ablaufen wird. Es sollte allen klar werden was der Randori Modus ist und welche Aufgabenstellung wir lösen wollen.
  2. Logische Aufgabe des ersten Tests ist vorgeben. Das soll nicht heißen das man eine API vorschreibt sondern das der/die Erste einen Start hat bei dem man auf ein klares Ziel zulaufen kann.
  3. Brainstorming zur Aufgabenstellung, wir wollen zusammen eine Idee von einer Lösung produzieren.
  4. Während der Phasen in denen die Teilnehmer wechseln verstärkt drauf achten das sich nicht ewig “um die Logik gedrückt wird”.
  5. Nach einem Red/Green Cycle nicht den wichtigsten Punkt weglassen: Refactor. Eventuell auch während der Pilotwechsel ansprechen was ein Problem werden könnte.
  6. Nach 3-4 Pilotwechseln wollen wir eine Pause machen und reflektieren. Sind alle noch im Boot? Hat sich die Lösungsidee verändert?

Somit war dieses Treffen sehr konstruktiv und ich freue mich schon auf das nächste Coding Dojo bei dem wir diese neuen Ideen umsetzen wollen.

Posted in Coding Dojo, Termine | Comments Off on 19. .NET Coding Dojo

.NET User Group Treffen März 2015 – No mocks / Functional Architecture

Im März wird Mark Seemann http://blog.ploeh.dk bei uns zu Besuch sein mit folgendem Thema: No mocks / Functional Architecture

A Functional architecture with F#

F# is a Functional language in the .NET framework; while most people still regard it as a niche language, it’s a Turing complete, general purpose language, so you can build almost any sort of application with it. However, with its strong focus on immutability, programmers used to Object Orientation struggle with creating a proper architecture for a Functional system.

One way to approach Functional architecture is to separate the system into abstractions for writing data, and abstractions for reading data.

A set of design patterns collectively known as Pipes and Filters provide a model for receiving and persisting data, while a programming model known as Map/Reduce addresses the concerns of reading (persisted) data and transforming it into useful boundary constructs.

Look, no Mocks! Functional TDD with F#

Test-Driven Development (TDD) is supposed to be about feedback, but a recent criticism has been that it tends to cause ‘test-induced damage’, because the design resulting from TDD is worse than an alternative design one could produce without kowtowing to testability.

The counter-argument is that this may indicate a failure in API design, rather than a failure on the part of the TDD process.

Often, the problem with TDD is an over-reliance on Mocks, which again causes an over-emphasis on mutation. Functional Programming, with its emphasis on immutability, can help significantly pull the tests away from relying on Mocks, leading to a better overall design, and more maintainable unit tests.

This session uses F# to demonstrate how to use Functional design with TDD to remove the need for Mock objects.
Die Treffen der User Group sind wie immer kostenlos und eine Mitgliedschaft in der User Group ist nicht notwendig. Allgemeines Ziel der Treffen sind soziales Networking und direkter Austausch. Kollegen und Interessierte sind herzlich willkommen.

Treffpunkt am 3. März 2015 um 18 Uhr

Microsoft Deutschland GmbH
Gasstraße 6
22761 Hamburg

Wichtig: Anmeldung per XING oder per Mail an info@dotnet-usergroup-hamburg.de

 

Posted in Termine | Comments Off on .NET User Group Treffen März 2015 – No mocks / Functional Architecture