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


"Every solution will only lead to new problems."

Category Veranstaltungen

Friday, 28. September 2012


NavTechDays 2012 Notizen Teil 2

Filed under: Dynamics NAV 2009,Navision,Veranstaltungen — Steffen Forkmann at 13:21 Uhr

Gestern habe ich schon den ersten Teil meiner Notizen hier auf dem Blog veröffentlicht. Jetzt geht es weiter mit Teil 2.

Scrum

Microsoft hat den internen Prozess auf Scrum umgestellt und ich finde das merkt man wirklich. Es sind zwar nur zwei Tage Konferenz, aber das Produkt fühlt sich tatsächlich “fertig” an. Es ist interessant zu sehen wie eine so konservative Organisation wie NAV auf einen agilen Prozess umstellt. Ich bin gespannt was mit diesen ganzen Wasserfall-Tools wie SureStep und Co. passiert. Hier auf dieser Developer-Konferenz hat jedenfalls keiner davon geredet.

  • 20 Scrum Teams mit zweiwöchigen Sprints
  • Verwaltung der User Stories im TFS (Source Control irgendwo anders)
  • ATDD wird eingesetzt aber kein TDD
  • Umstellung auf Kanban steht jetzt bevor

OData

  • OData Webservices aus NAV + Excel PowerPivot ist eine geniale Kombination für Auswertungen (Low Cost BI) – MSDN Walkthrough
  • OData ist im Moment nur read-only

Dimensionen

  • Völlig überarbeitet.
  • Viel weniger Kopien der Dimensionen – nur noch über einen Schlüssel referenziert

Datenzugriff

  • Neuer Data Access Stack angeblich schneller als Classic Client.
  • FIND und FINDSET sind gleich schnell
  • SETCURRENTKEY macht Abfragen jetzt nur noch langsamer (da Sortierung) keinesfalls schneller
  • SQL Call Stack Traces – Blog post
  • Es sind keine Writes in die Object und Company Tabellen mehr möglich
  • Security Filters überarbeitet. Erlaubt es Nutzern nur gefilterte Datensätze zu zeigen.
    • Neue Optionen um Probleme mit indirekten Rechten zu lösen
    • Security Filter Feature kann im C/AL direkt an Record-Variablen konfiguriert werden
    • Security-Einstellungen zeigen sofort Wirkung. Keine manuelle Synchronisation der Nutzer oder Neustarts nötig
    • Standard App wurde noch nicht nach möglichen Security Filter Problemen durchforstet
    • Validated Mode sollte möglichst nicht benutzt werden, da es langsamer als die anderen Optionen ist

Locks und Blocks

  • Alle Slides und Samples sind auf Stryks Blog downloadbar
  • SQL Server Lock Escalation sollte vermieden werden -> „always rowlock” benutzen (jedoch nicht auf 32bit und unter 8GB RAM)
  • LOCKTABLE erhöht das Transaction Isolation Level auf Serializable
    • Über einen DB switch kann auf Repeatable Read umgestellt werden (Unterschied wie Tag und Nacht)
    • Das ist sowieso der Standard bei NAV2013
    • Es können zwar Phantom Reads entstehen, aber das sind Probleme die in der Praxis nicht existieren (“habe ich noch nie gesehen”)
  • Block und Dead Lock Detection Tool auf seinem Blog
  • Job Queue von NAV2013 kann auch in älteren Versionen nachgebaut werden
  • Beispiel 1: In Document Dimensions den Clustered SQL Index fixen – Document No.,  Document Type nach vorne -> weniger Blocks da die gelockten Zeilen näher beisammen sind
  • Beispiel 2: In Codeunit 80 und 90 gibt es ein globales Lock auf die „GL Entry“. Das wird auch ausgeführt wenn gar keine Sachbuchungen passieren. Lock mit PostToGL Flag fixen (bereits in NAV2013 gefixt)
  • Beispiel 3: In Tabelle 36 gibt es einen „Warehouse bug“ – Selbst wenn die Warehouse Tabelle leer ist wird die Tabelle gelockt. Generell sollte immer über ISEMPTY geprüft werden ob überhaupt Datensätze im Filter sind bevor man ein DELETEALL oder MODIFYALL durchführt
  • Beispiel 4: Reservation Entry.Lock() hat ein ähnliches Problem. Einfach am Anfang der Funktion prüfen ob die Tabelle leer ist. Wenn ja dann mit EXIT aus der Funktion springen
  • Beispiel 5: No. Series Line Tabelle ist „zu klein“ für das Lock und es werden mehr als eine Zeile gelockt. Folge: Wenn jemand eine Rechnung erzeugt kann ein anderer u.U. keine Artikel erzeugen. Lässt sich leicht mit Dummy Feldern fixen. 😉

Reporting

  • Es gibt nur noch RDCL Reports
  • Classic Sections (und deren Trigger) fallen weg
  • Es gibt einen „Dataset designer“ als Ersatz für die Sections (analog Query designer)
  • Es wird nun RDLC 2008, Report Viewer 2010 und Visual Studio 2010 benutzt.
  • Reports erlauben „Save as Word“
  • “Heavy reports” über Background Session auf dem Server drucken (“Server side printing”)
  • Im Webclient gibt es “Preview” (nur IE) und „Save as PDF“ (alle Browser)
  • „Tray selection“ fixed – zusätzlich ein Codeunit 1 Trigger der es erlaubt die Papierfachsteuerung zu überschreiben
  • Upgrade Prozess
    • Hotfixes in NAV 5 und 6 erlauben Trigger in Codeunit 1 „OnBeforeRunReport“ (erlaubt zu zählen wie oft der Report tatsächlich genutzt wird)
    • Automatische Transformation hilft bei Upgrade von existieren NAV 2009 RDLC Reports (Tools/Upgrade Report)
    • Upgrade braucht ein technisches Upgrade auf NAV2013 als Zwischenschritt, da der Report kompilierbar sein muss um das Transformations-Tool zu benutzen
    • Automatisch vergebene Namen im Anschluss aufräumen
    • Doppelte Spalten entfernen
    • UI Guidelines auf MSDN befolgen
    • CreateTotals entfernen

Insgesamt war es ein sehr gute Veranstaltung mit vielen Informationen zu Dynamics NAV 2013. Vielen Dank an die Organisatoren und die Speaker.

Thursday, 27. September 2012


Notizen von den NavTechDays 2012 Teil 1

Filed under: Dynamics NAV 2009,Navision,Veranstaltungen — Steffen Forkmann at 14:04 Uhr

Microsoft Dynamics NAV 2013 wurde vorgestern released und so trifft es sich das gerade jetzt die NavTechDays 2012 in Antwerpen stattfinden. Hier meine Notizen nach fast einem Tag Konferenz.

Allgemeines

  • Das NAV Menü ist bekanntermaßen sehr umfangreich -> NAV2013 hat jetzt eine Suche dafür
  • Der Classic Client heißt jetzt Development Environment und ist kein echter Client mehr. Da es keine Forms mehr gibt wird auch gern als „Retired Client“ bezeichnet.
  • Die Administration der Service Tiere kann nun vollständig über Powershell gescriptet werden. Das geht auch von remote.
  • Der Page Designer wurde deutlich verbessert und erlaubt nun eine „Live Preview“. Damit kann man die Änderungen direkt betrachten – ohne zu kompilieren und NAV neu zu starten.
    • Gruppen können eingeklappt werden
  • NAV2013 unterstützt OData
    • Erlaubt Query Objekte nach außen über Webservices zu veröffentlichen.
    • Gut für Anbindung von externen (Reporting) Tools
  • Der Windows client (ehemals RTC) wurde verbessert
    • Row styles feature erlaubt es Zeilen je nach Bedingung unterschiedlich zu färben
    • Neue Shortcuts (copy & paste, ….)
    • Grids erlauben es aus der automatischen Anordnung der Controls auszubrechen
    • Addins können .NET Events nutzen
  • „Rapid Start“ soll alle Einrichtungsvorgange vereinheitlichen
    • Fragebögen erstellen
    • Am Ende entsteht ein Package das auf andere Datenbanken angewendet werden kann -> Fragebögen werden angezeigt und Daten werden eingerichtet

Unit Testing

  • MS nutzt das Ding jetzt endlich selber (und zeigt es sogar in der Keynote)
  • Die Testing Features von NAV 2009 wurden nochmal gezeigt
    • Konvention: // *** hinter jede Zeile die Daten füllt, die für den eigentlichen Test unerheblich sind aber aus anderen Gründen gefüllt werden müssen
  • Die neuen „Page Testing“ features erlauben „Scripted UI testing“ durch den neuen Datentyp TestPage.
    • Erlaubt es Pages zu öffnen: myPage.OPENNEW;
    • Kann Daten füllen: myPage.MyField.SETVALUE(value)
    • Ermöglicht es Buttons zu drücken: myPage.MyAction.INVOKE;
    • Alle Parts (auch Subpages) können abgegriffen werden
    • Felder können auf Inhalt, Sichtbarkeit, Editierbarkeit usw. geprüft werden
    • „Page traps“: Registriert sich auf ein Page und wenn die geöffnet wird dann wird zurück in den Test gesprungen
  • Page Tests dauern länger als Unit Tests aber erlauben es aus Usersicht zu testen
  • “Test Isolation” Fführt ein Change tracking durch und setzt die Datenbank nach einem Test wieder in den Ausgangsstand zurück. Teardown Funktionen sind jetzt nicht mehr nötig. Das funktioniert selbst dann, wenn der zu testende Code ein Commit enthält. Wie geil ist das denn? Hammer!
  • Recorder zur Aufzeichnung von Page Tests ist in Planung.

Debugger

  • Debugger ist in C/AL entwickelt und damit anpassbar. WTF?!
  • Erlaubt Remote NAS Debugging und zeigt den Code in C/AL an J
  • Alle Sessions können debuggt werden (auch noch nicht etablierte wie Webservice Sessions)
  • Sogar Endlosschleife können debuggt werden (ging mit altem Debugger natürlich nicht)
  • Conditional Breakpoints (z.B. nur anhalten wenn Variable > 10)
  • Man kann Breakpoints hinter das Ende von Funktionen setzen -> hält beim Verlassen der Funktion an. Egal welches EXIT genutzt wurde
  • Im Call Stack kann man auch in anderen Ebenen die Variablen inspizieren
  • „Debugger Breakpoint List“ erlaubt es die Breakpoints in Gruppen an und ab zu schalten
  • „Break on record changes“ erlaubt es bei jedem DB write anzuhalten.
  • Debugger hat Option um Codeunit 1 zu skippen
  • „Code Coverage“ Feature kann aus C/AL gestartet werden. Berührte Codezeilen können abgefragt und ausgewertet werden -> kommt ins Test Framework

Performance talk

  • Die Data Access Layer ist jetzt komplet neu in Managed Code geschrieben. Damit ist das Anlegen von Records jetzt deutlich schneller, da nicht zwischen C++ und .NET vermittelt werden muss.
    • Temp Records neu geschrieben. Haben jetzt selbe Sortierung wie normale Records.
    • Marked Records sind jetzt auch entsprechend richtig sortiert.
    • @-Operator funktioniert jetzt wieder richtig beim Filtern.
  • Query object
    • Erlaubt Joins (inner, outer,..) und Aggregations (sum, count, average)
    • Wird auf dem SQL Server ausgeführt -> Kein Netzwerktraffic zum NAV Server
    • Massive Performancegewinne möglich
    • Abgefragte Daten sind read-only -> aber dadurch kaum Locks
    • Programmiermodel analog wie Reports
    • Gut z.B. für alle Statistik Pages
    • Wird bereits in vielen Teilen des Standard genutzt
  • Background Sessions erlauben „Fire and Forget“-Tasks. Das funktioniert sogar in andere Mandanten.
    • Beispiel: Buch.-Blatt starten und die Buchungen werden asynchron auf dem Server ausgeführt. Der Client kann ganz normal weiter arbeiten. Wird bereits zum Buchen von Rechnungen verwendet.
    • Erzeugt allerdings eine komplett neue Session – samt Login usw.
    • Background Sessions kosten nichts für die Lizenz.
    • Die Tasks gehen in eine Job Queue. Die erlaubt dass die Tasks nicht alle parallel stattfinden. Durch diese Linearisierung gibt es weniger konkurrierende Locks.
  • CALCSUMS geht auch auf Feldern die nicht im SIFT sind. Wird dann auf dem SQL Server summiert -> schneller als manuelles Summieren auf dem NAV Server.
  • SETAUTOCALCFIELDS („Smart SQL“) ermöglicht es, dass FlowFields immer direkt beim Abrufen des eigentlichen Datensatzes mit abgerufen werden. -> Weniger Roundtrips zum SQL-Server.
    • Immer an bei Pages und Reports.
  • Connection Pooling zum SQL Server. Nur noch ein Account nötig. Das spart sehr viel Memory.
  • Data caching wurde verbessert. Jetzt werden Record API calls benutzerübergreifend gecached.
  • Security model wurde vereinfacht. „Synchronize all logins“ fällt weg, da Permissions nur noch im NAV Server geprüft werden.
  • Isolation Level wurde von SERIALIZABLE auf REPEATABLE READ geändert.
  • Locks wurden massiv reduziert bzw. es wird viel viel später gelockt (90% vs. 10% der Zeit beim Buchen)
  • Dimensionen wurden komplett überarbeitet (viel weniger Datensätze, weniger Writes).
  • „Buffered inserts“ werden jetzt viel öfter genutzt.
  • „SQL callstack trace“ erlaubt es heraus zu bekommen welche Codezeile ein bestimmtes (schlechtes) SQL statement erzeugt hat.
  • Es werden keine Cursors mehr für den SQL Server benutzt sondern Multiple Active Result Sets (MARS).
    • Folge: Kein SETCURRENTKEY mehr nutzen wenn man die Sortierung nicht braucht. (SETCURRENTKEY ist nur noch schlecht auf SQL Server da er sortieren muss.)

Morgen dann sicher mehr.

Tuesday, 18. September 2012


Dev Open Space 2012 – 19.-21.10.2012 in Leipzig

Filed under: Coding Dojo,F#,NaturalSpec,Veranstaltungen — Steffen Forkmann at 7:08 Uhr

Open Source. Open Space. Developer Open Space Nachdem es sich die letzten beiden Jahre mehr und mehr angekündigt hat, wurde der .NET Open Space in Leipzig nun in Dev Open Space 2012 umgetauft. Dies trägt dem Punkt Rechnung, dass die Themenwünsche der Teilnehmer immer breiter geworden sind und wir uns vor allem auch über git, Ruby, JavaScript, HTML5, node.js, CQRS und vieles mehr unterhalten haben. Weiterhin wird es natürlich trotzdem noch reine .NET-Themen geben.

Neu sind außerdem die kostenlosen Workshops die bereits einen Tag vor dem OpenSpace angeboten werden. Ich selbst werde einen zu F# und Test Driven Development halten:

“Test Driven Development (TDD) bringt viele Vorteile für den Code aber erfordert auch eine Menge Übung. Dieser Workshop zeigt, wie man TDD mit F# mittels NaturalSpec and NCrunch erfolgreich einsetzt. NaturalSpec ist ein F#-TDD- Framework, mit dem Unit Tests auf sehr intuitive Weise ausgedrückt werden können. NCrunch hilft, diese Tests ständig (bei jedem Tastendruck) auszuführen. Das zusammen ergibt einen sehr schnellen Feedbackzyklus und TDD wird deutlich schneller. Nach einer kurzen Einführung in die Tools werden im Workshop gemeinsam kleine Programmieraufgaben gelöst.”

Die Anmeldung ist bereits möglich.

https://inlineafarmaci.com
Tags: ,

Thursday, 13. September 2012


Skillsmatter “Progressive F# Tutorials 2012” session in London

Filed under: F#,NaturalSpec,Veranstaltungen — Steffen Forkmann at 15:54 Uhr

I’m happy to announce that I’m giving one of the “Progressive F# Tutorials 2012” in London this year. This event is going to be legendary. Abstract:

Test-Driven Development can give you a lot of benefits for your code but also needs a lot of practice. Come to this session and learn how to master TDD with F#, NaturalSpec and NCrunch.

NaturalSpec is a F# TDD framework which allows to express tests in a very intuitive way and NCrunch helps to execute these tests continuously on very key stroke. This gives a very fast feedback loop and helps to speed up your TDD coding.

After a short introduction of the tools we’ll try to solve a small coding problem together in a coding dojo. All skill levels are welcome and the session will give a lot of room to try out new ideas.

Book your tickets for this awesome event.

Tags: ,

Wednesday, 24. November 2010


Aufzeichnung meines Vortrages zu Higher-Order-Functions in C# verfügbar

Filed under: Informatik,Veranstaltungen,WebCasts — Steffen Forkmann at 15:12 Uhr

Letzte Woche habe ich im Rahmen der F# Gruppe der .NET Online User Group einen Vortrag zu “Higher-Order-Functions in C#” gehalten. Unter http://vimeo.com/17048170 ist die Aufzeichnung nun zu finden.

Funktionale Programmiersprachen nehmen seit geraumer Zeit einen hohen Stellenwert in der Wissenschaft ein. Mittlerweile ziehen viele der funktionalen Konzepte bereits in den Mainstream ein. Bei diesem Treffen wollen wir einen Einblick in funktionale Konzepte und deren Umsetzung in C# gewinnen. Insbesondere soll auf "Funktionen höherer Ordnung", "Pattern Matching", "Unveränderlichkeit" und parallele Programmierung eingegangen werden.

Vortragsabstract

Tags: ,

Wednesday, 10. November 2010


Dynamics NAV 2009 R2 Developer Day

Filed under: Dynamics NAV 2009,Veranstaltungen — Steffen Forkmann at 10:33 Uhr

Heute fand der “Dynamics NAV 2009 R2 Developer Day” statt. Bei diesem Event hat Microsoft mal wieder eine Konferenz in die Welt gestreamt. Da der Dynamics Bereich aber traditionell eher verschlossen ist, wurde der Stream nicht öffentlich gemacht, sondern nur in den jeweiligen Microsoft-Centern in 18 Ländern für eingeladene Partner gezeigt.

In diesem Blogpost verwalte ich meine eigenen Notizen zum Developer Day. Falls etwas zu knapp formuliert ist, kann gern über die Kommentare nachgefragt werden.

Als Release-Termin für Dynamics NAV 2009 R2 wurde der 15.12. angegeben.

What’s new in C/SIDE

Page Designer

  • Neuer Wizzard
  • Stärkerer Einsatz von Factboxes
  • “Strukturhighlighting” (= Gruppen werden fett dargestellt)

Go to Definition

  • Ctrl+F12 ==> Go to definition
  • Wenn die Definition nicht im selben Objekt ist, wird immer ein neues Designer-Fenster geöffnet, auch falls schon ein Fester des Objekts offen ist .
  • Momentan kein “Find References”

Multi-Developer Szenarien

  • Locking von Objekten
  • Öffnen von gelockten Objekten ist in Read-Only-Modus möglich
  • “Force unlock” ist für Superuser möglich
  • Meine Frage nach “Lock auch aus C/AL-Code” wurde mit Ja beantwortet.
  • Tools/Options/“Auto-lock on design”
    • Meine Frage nach “Auto-lock on first modification” wurde leider nicht beantwortet
How to use the application testability features
  • Vortrag war Low-Level-Einführung in automatisiertes Testen
  • Keine Verbesserungen zu NAV 2009 SP 1
    • also auch immer noch kein Mocking von Triggern
  • Jeder Test wird in eigener Transaktion durchgeführt
  • Code nach ASSERTERROR wird trotzdem ausgeführt
    • Transaktion wird jedoch zurück gerollt
  • Neues Application Test Toolset auf Partnersource (mit 226 Test Cases)
    • Meine Frage nach einer Erweiterung der Standardtestfunktionen wurde nicht beantwortet.
.NET Interoperability
  • Interop nur mit .NET 3.5 libs möglich
  • Nur auf NAV Server bzw. RTC
  • Anlegen von .NET Typen ist unglaublich umständlich
    • Warum schreibt man alle Typen in eine einzige Liste?
    • Keine einfache Möglichkeit über Namespaces zu browsen
  • Simple Datentypen (Double, Integer, Text) werden automatisch in ihre .NET-Entsprechungen gemappt
    • Options auf enums?
  • Format() mapped auf .ToString()
  • Achtung: Static classes werden über alle Client-Sessions geshared
  • NAV Scoping Regeln werden angewendet
    • Wenn lokale C/AL-Methode endet, wird das .NET Objekt disposed
    • Was ist mit Referenzen in noch lebenden .NET Objekten
  • .NET Variablen habe ein RunOnClient-Property
  • Deployment von Custom .NET Assemblies
    • Auf C/SIDE-Client für Development (Compile)
    • Auf die Tier wo der .NET Typ benutzt wird (siehe RunOnClient)
  • Client Warning bei erster Benutzung einer .NET Assembly
    • Keine Warnung bei SPN-Deployment
  • Kein try/catch/finally Exception handling
    • Exception wird als Textnachricht an den Client gesendet
  • Keine Events
Calling out to other Web Services from NAV

NAV Web Services

  • NAV 2009 SP1 führt Web Services immer in UTC-Zeit aus
  • NAV 2009 R2 führt WebServiceDefaultTimeZone ein (Default UTC)
  • Manuelles Change-Tracking immer noch nötig
  • Meine Frage nach “echtem” WCF noch unbeantwortet (aber Demo sah so aus)

Externe Web Services

  • Benutzt .NET Interop ==> Genauso wie in C#
  • Wenn WSL vorhanden, dann kann ein Proxy über svcutil erzeugt werden. Dieser muss dann als DLL auf den NAV Server deployed werden
  • Meine Frage nach asynchronem Aufruf wurde nicht beantwortet
    • Ich vermute unmöglich, da keine .NET Events unterstützt werden und ich noch keine Möglichkeit sehe Callbacks zurück ins NAV zu registrieren
    • Sicherlich möglich durch Publish eines Callback-Webservice (aber das ist irgend nicht schön)
CRM Integration
  • “Connector for Microsoft Dynamics“ für das Mapping
    • Hat NAV und CRM Adapter
    • Eigene 3-Tier-Applikation mit eigenem SQL-Server für Integrationsdaten
    • Integration ID – GUID hält NAV und CRM Datensatz zusammen
  • Neue Database Trigger in Codeunit 1 die IMMER bei INSERT, MODIFY, DELETE und RENAME feuern
  • Jede zu synchronisierende Tabelle muss auf NAV Seite als Page WebService veröffentlicht werden
  • Viele Synchronisationswege nur One-Way
    • Rechnungen sollten z.B. nur vom ERP-System verwaltet werden
  • Eindruck: Unglaublich kompliziertes System, da Mapping über Wizzard im Connector mit eigener kleiner Programmiersprache
    • Warum keine simple C# Projektvorlage mit ein paar Interfaces die man implementieren muss?
    • Warum extra SQL-Server-Instanz? Warum reicht nicht eine Message-Queue?
  • Backup und Restore muss zwischen allen 3 Datenbanken (NAV, CRM, Connector) synchronisiert werden
SSRS (RDLC) Reports in Microsoft Dynamics NAV 2009
  • Dataset kann refreshed werden ohne das Visual Studio geschlossen wird
  • Printer Selection funktioniert jetzt mit RTC über die Request Page
  • Transfooter und Transheader offenbar möglich (siehe http://blogs.msdn.com/nav)
  • Kein Druck auf dem NAV Server
    • Wie Archivierung von PDFs?
Developing Pages
  • Keine wirklichen Neuerungen in R2
Business Data Visualization Add-Ins for the RTC
  • Interessante neue Visualisierungsmöglichkeiten
    • Samples werden auf Beispiel-DVD mitgeliefert
    • Beispiel: Interaktive Zeitreihe
Ausblick auf Dynamics NAV 7
  • Forms Designer ist bereits ausgebaut – “There is no way back”
  • C/SIDE bleibt die Entwicklungsplattform – Keine Visual Studio Variante
    • Aussage in Hamburg: Entwicklung im RTC – Gezeigte Screenshots sagen etwas anderes
  • Offenbar integrierte Versionskontrolle geplant 😉
  • UI-Testing “könnte” kommen
  • .NET Interop mit Events
  • Rewrite vieler interner Funktionen um das .NET-Framework besser zu nutzen
    • Da es in NAV 7 keinen Classic-Client geben wird, ist dies auch problemlos möglich.
  • Keine Hybrid-Reports mehr. Entweder Classic Reports oder RDLC
    • 100% automatische Konvertierung in neuen Report Designer
Tags: , ,

Thursday, 4. November 2010


.NET Online User Group gegründet

Filed under: Coding Dojo,F#,Online User group — Steffen Forkmann at 19:24 Uhr

Nach einigen Diskussionen und Anregungen auf Twitter und einer konstitutionellen Skype-Session (zwischen DerAlbert, Björn Rochel und mir) wurde heute die “.NET Online User Group” gegründet.

Ziele und Einordnung der Gruppe

Unter dem Deckmantel dieser Gruppe wollen wir versuchen möglichst oft und regelmäßig Online-Treffen für .NET-Entwickler aus dem deutschsprachigen Raum zu organisieren.
Die Online User Group sieht sich damit keinesfalls als Konkurrenz zu den bereits bestehenden lokalen User Groups. Wir stellen uns dabei eher vor durch ein breites Angebot an Formaten und das große Einzugsgebiet auch in speziellere Themen tief reinschauen zu können, die bei den lokalen Gruppen aufgrund der heterogenen Interessen eher vermieden werden.

Gruppen

So ist es z.B. geplant Gruppen zu bilden, die sich zu bestimmten “Randgruppen”-Themen ganz intensiv austauschen können. Den Anfang machen wir mit einer F# Gruppe, deren Ziel es ist die Sprache F# im Speziellen und Funktionale Programmierung im Allgemeinen detailliert zu beleuchten. Beim ersten Treffen am 15.11. wollen wir uns mit “Funktionen höherer Ordnung” beschäftigen.

Jede der Gruppen wird min. einen Paten haben. Die Aufgabe des Paten ist es als Ansprechpartner zu fungieren und Termine zu koordinieren. Das soll aber nicht heißen, dass der Pate bei jedem Treffen selbst einen Vortrag halten soll.

Kurzfristige Treffen

In letzter Zeit ist es des Öfteren vorgekommen, dass einige Themen auf Twitter oder in Newsgroups plötzlich sehr intensiv diskutiert wurden. Wir wollen mit der User Group nun auch eine Kommunikationsplattform bieten, die in der Lage ist kurzfristig in einem direkteren Rahmen über solche Themen zu diskutieren. Wir können uns dabei gut vorstellen, dass spontan verabredet wird (z.B. über Twitter) sich am Abend zu einem bestimmten Thema über die Kanäle der User Group (insbesondere LiveMeeting) zu unterhalten.

Coding Dojo

Auch das bereits etablierte Online Coding Dojo mit Albert Weinert und Ilker Cetinkaya wird ab jetzt unter der Flagge der .NET Online User Group durchgeführt werden. Der erste Termin hierfür ist der 18. November.

Klassische Vorträge

Aber auch Vorträge wird es bei der .NET Online User Group geben. Zum jetzigen Zeitpunkt stehen bereits 4 Termine fest:

Weitere Schritte

Um die .NET Online User Group ordentlich anlaufen lassen zu können benötigen wir natürlich jede Menge Hilfe:

  • Bitte helft uns die User Group bekannt zu machen. Twitter, Email, Blogs, Briefe, Faxe, TV-Spots, persönliche Kommunikation usw.
  • Bitte registriert euch auf der Webseite der User Grouo
  • Bitte schlagt Vorträge vor
  • Bitte nennt uns Themenwünsche und Ideen
  • Bitte meldet euch freiwillig als Paten für bestimmte Untergruppen bzw. Themenbereiche
  • Bitte schlagt uns vor wie ihr sonst noch helfen könnt 😉
Tags: , ,

Sunday, 20. June 2010


CodingDojo in TDD – Die einfachste Lösung siegt

Filed under: C#,Coding Dojo,Kata — Steffen Forkmann at 18:27 Uhr

Auf dem .NET OpenSpace Süd in Karlsruhe hatte ich heute die Gelegenheit bei einem Coding Dojo mit Ilker Cetinkaya mitzumachen. Leider ist das Dojo nicht so richtig in Fahrt gekommen und wir haben es praktisch nicht geschafft auch nur eine einzige Regel der Kata.RomanNumerals zu implementieren. Der Grund dafür war (sicherlich nicht nur) aus meiner Sicht, dass es zwei starke Fraktionen innerhalb des Teams gab. Auf der einen Seite “Coder”, die sich tatsächlich von den Tests treiben lassen wollten und auf der anderen Seite eine Gruppe der “Knobler”, die sich nicht mit dem Test-first-Ansatz identifizieren können und lieber am Board einen Algorithmus entwickeln.

Aus meiner Sicht sind beide Ansätze für sich betrachtet auch völlig in Ordnung und können zu sehr guten Lösungen führen.

Wer z.B. nicht glaubt, dass der strikte Test-first-Ansatz für Kata.RomanNumerals funktioniert, der kann gern die Teilnehmer vom 2.ten Hamburger Coding Dojo fragen oder das github-Repository dazu durch browsen und die Entwicklung der Commits verfolgen.

Was aber offensichtlich überhaupt nicht funktioniert ist der Mittelweg. Wenn sich beide Gruppen nicht auf das Vorgehen einigen und im Zweifel immer nur der “lauteste” Änderungsvorschlag gewinnt, dann wird das Ergebnis mitunter unbefriedigend für beide Seiten. Beim Karlsruher-Dojo hatten wir am Ende nach einer gescheiterten Implementierungsphase und abrupten Abbruch sogar nur 7 rote und einen grünen Test vorzuweisen. Bei dem Grünen frage ich momentan sogar immer noch warum ausgerechnet dieser Test überhaupt gelaufen ist.

Um also eine solche Situation zu vermeiden sollte man sich also am Anfang entscheiden wie man sein Dojo gemeinsam durchziehen will. Im weiteren werde ich jetzt eher auf die von mir favorisierte Variante mit striktem TDD eingehen, auch wenn mich eine Knobler-Session mit ausgeprägter Analysephase auch mal als Vergleichswert interessieren würde.

Wie gesagt: Ich bin ausdrücklich davon überzeugt, dass beide Lösungswege funktionieren können – je nach Problem mal besser und mal schlechter.

Striktes TDD und der einfachste Lösungsvorschlag gewinnt

Ein oft genanntes Argument der “Knobler”-Fraktion am TDD-Ansatz ist, dass nicht vorrausschauend entwickelt wird. Hey Jungs – das ist doch genau der Trick. Solange ich keine Anforderung für irgendwelche Dinge habe (nicht im Kopf oder auf dem Papier, sondern als Test) wird keine Komplexität hinzugefügt. Es wird dann behauptet, dass bei Test-first am Anfang sinnfreie Implementierungen gewählt werden und dass man diesen Code am Ende ganz offensichtlich sowieso wieder wegschmeißen würde. Aber das stimmt einfach nicht. Auch wenn ich immer mehr Tests hinzunehme und meine Implementierung immer generischer wird, so wird die vorherige Lösung letztlich immer ein Spezialfall der generischen Variante sein und geht somit nie verloren.

Gerade der Fokus auf diese minimal mögliche Generalsierung der aktuellen Implementierung sorgt dafür, dass der Algorithmus am Ende korrekt herausfällt. Das Knobeln kommt an dieser Stelle natürlich wieder in den Ablauf herein. Allerdings knobeln wir so an wesentlich kleineren und damit leichteren Problemen  – selbstverständlich nun viel öfter und in kürzeren Zyklen.

Bei zukünftigen Coding Dojos würde ich also gern als Regel sehen, dass der einfachste Vorschlag, der zu Grün führt implementiert wird.

Temposteigerung durch gruppenweises Anlegen von roten Tests

Zu bestimmten Zeitpunkten und insbesondere auch am Anfang von vielen Katas sieht man jedoch oft Implementierungsmuster die gleich eine ganze Klasse an Tests abdecken könnten. Wenn man so eine Idee hat, dann sollte man die natürlich auch nutzen und so das Tempo steigern. Anstatt aber diese Idee einfach zu programmieren würde ich erst die komplette Gruppe von Tests schreiben und sicherstellen, dass alle neuen Tests auch wirklich "rot sind. Dieser Shortcut ist aus meiner Sicht methodisch völlig unproblematisch, da zu diesem Zeitpunkt nur neue Anforderungen im System dokumentiert werden und diese dann als Begründung für neue Komplexität herangezogen werden können.

Aber auch hier sollte die selbe Regel gelten: Die leichteste Implementierung gewinnt. Wenn also ein Teilnehmer eine einfachere Lösung anbieten kann, dann wird die genommen.

Training durch Wiederholung

Wie Ilker in der Auswertung bereits gesagt hat, würde ich auch gern nochmal in der selben Truppe ein Dojo machen. Vielleicht ergibt sich das ja sogar beim nächsten OpenSpace. Denn selbstverständlich geht es beim Coding Dojo nicht nur um Code sondern auch um die beteiligten Menschen.
Obwohl wir am Ende keine Lösung vorweisen konnten, habe ich in der kurzen Zeit sehr viel über die Entwicklungsmethodik anderer Teilnehmer gelernt – ich denke das hat mir wirklich eine Menge gebracht.

Training durch Wiederholung – Reloaded

Da ein wichtiges Element bei Katas auch die Wiederholung ist (und mir im Zug langweilig ist), habe ich zusätzlich für mich selbst und andere noch eine aufgeräumtere Variante der Kata mit minimalen Commits in das Repository hochgeladen. Unter http://github.com/forki/DojoHamburg/commits/Karlsruhe kann man die Änderungen von unten nach oben genau nachvollziehen. Wenn jemand ein Stelle findet wo ich zu viel implementiert habe oder wo die Änderung nicht sinnvoll und einfach erscheint, dann würde ich mich freuen darüber diskutieren zu können.

Tags: ,

Friday, 18. June 2010


Bericht vom 2.ten .NET Coding Dojo in Hamburg

Filed under: C#,Coding Dojo,Kata — Steffen Forkmann at 18:52 Uhr

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.

Tags: ,

Wednesday, 2. June 2010


Erstes internes CodingDojo bei der msu solutions GmbH in Halle

Filed under: Coding Dojo,Firmen,msu solutions GmbH — Steffen Forkmann at 14:37 Uhr

Gestern haben wir bei der msu solutions GmbH am Standort Halle unser erstes internes CodingDojo veranstaltet.

Ziele des internen Dojos

Da wir in der tagtäglichen Arbeit mit Microsoft Dynamics NAV entwickeln, wollten wir das Dojo auch mit Dynamics NAV und der Programmiersprache C/AL abhalten. Als wichtiges Ziel der Veranstaltung haben wir uns vorgenommen nach Test-Driven Development (TDD) zu arbeiten. Da TDD im NAV-Bereich (sicherlich mangelns Tools und Community) noch so gut wie unbekannt und unser selbstentwickeltes Test-Framework noch sehr jung ist, war diese Selbstverpflichtung für einige Team-Mitglieder in dieser strikten Form sicherlich noch Neuland.

Ablauf

Um die Messlatte für das erste Dojo daher nicht allzu hoch zu legen und mehr Fokus auf den Versionsverwaltung (git), die Test-Tools und die Kommunikation bzw. den Prozess selbst zu richten habe ich die relativ einfachen Katas FizzBuzz und DictionaryReplacer vorgeschlagen. Das Team hat sich dann für FizzBuzz entschieden.

Wie beim 1. NET CodingDojo in Hamburg gab es auch in Halle einige Startschwierigkeiten. Es scheint für viele Entwickler aufgrund der jahrelangen Entwicklungspraxis sehr schwer zu sein, tatsächlich zwischen Test und Implementierung zu unterscheiden.

Nachdem jedoch die ersten 3 Tests samt Implementierung geschafft und die explizite Trennung der Test- und Entwicklungsphasen erkannt wurden steigerte sich das Tempo des Teams enorm. So konnten wir dann auch Erweiterungen der Aufgabenstellung diskutieren und umsetzen.

Ich denke unser erstes msu Dojo war ein Erfolg und insbesondere die Wahl der Kata war für die erste Veranstaltung dieser Art ausgezeichnet. Für das nächste Mal wollen wir uns dann natürlich an eine schwierigere Kata wagen.

Randori-Stil

Da seit dem ”Dojo Deluxe” von und mit Ralf Westphal eine Diskussion über die Dojo-Formate aufgekommen ist, möchte ich hier auch noch meine Meinung dazu abgeben.

Da wir uns den Randori-Stil ausgesucht haben, gab es eigentlich vier verschiedene Rollen. Als erstes natürlich den Driver und den Co-Piloten, also eine Person, die die Tastatur bedient und eine die sagt “wo es lang geht”. Übrig bleiben dann in unserer Version noch der Rest des Teams als Publikum und ein Moderator. Da es die erste Veranstaltung dieser Art war, gab es noch sehr viele Hinweise vom Moderator. Bei nachfolgenden Veranstaltungen würde ich mir wünschen, dass der Moderator immer mehr in den Hintergrund rückt und die jeweiligen Co-Piloten deutlich aktiver werden. Das Publikum könnte noch mehr als das Kontrollorgan fungieren und auf Einhaltung der selbst auferlegten Richtlinien pochen. Als wichtigen Punkt für nachfolgende Veranstaltungen würde ich also noch eine klarere Trennung der Rollen sehen und dem Team mehr Eigenverantwortung auferlegen.

Randori-Stil vs. Tutorial

Die Befähigung des Teams den Entwicklungsprozess ohne starke führende Hand selbst zu kontrollieren ist für mich ein Kernziel bei einem CodingDojo. Ich denke hier unterscheidet sich der Randori-Stil (jedenfalls wie ich ihn bisher verstehe) stark von der Variante und den Zielstellungen die Ralf Westphal in seinem Dojo in München abgehalten hat. Wie Ilker Cetinkaya auch schon geschrieben hat ist Ralf’s Dojo-Variante wahrscheinlich näher am klassischen Workshop oder am Tutorial einzuordnen. Daran ist natürlich nichts falsch, ganz im Gegenteil: ich finde solche Workshops mit erfahrenen und charismatischen Sprechern extrem reizvoll. Insbesondere weil man bei einem Workshop aufgrund der intensiveren Vorbereitung des Sprechers in der kürzeren Zeit eine weit höhere fachliche Tiefe erreicht und man im Gegensatz zu klassischen Frontal-Vorträgen auch mehr Rückfragen stellen kann. Ralf hat sich dazu in seinem Blog ja auch intensiv und fundiert Gedanken gemacht.

“Einer weiß etwas und die anderen wollen es von ihm lernen”-Formate wie Ralf sie beschreibt sind also auch aus meiner Sicht sehr nützlich und bilden vermutlich sogar die Voraussetzung für ein Randori. Wenn nicht genug Leute im Raum bereits etwas über die zu benutzenden Techniken oder Methoden gehört haben, dann wird das Dojo bzw. das gemeinsame Lernen und Lehren vermutlich sehr zäh und der Moderator wird zum Hauptakteur. Es ist somit auch völlig einleuchtend, dass Ralf seine Event-Based Components natürlich nicht in einem Randori vorstellen kann. Das wäre dann wohl beim einem leeren FlipChart geblieben und ganz sicher auch eine Enttäuschung für alle Seiten.

Wenn jedoch hinreichend viele Leute bereits Erfahrungen mit der Materie gemacht haben, dann gibt es vermutlich auch unterschiedliche Interpretationen. Diese würde ich aber nicht so drastisch wie Ralf als “Unsicherheit” auslegen, sondern eher als Chance die Varianten gemeinsam zu diskutieren und Unklarheiten auszuräumen. Dabei muss es am Ende aber nicht zwingend einen Konsens geben.

Daher denke ich, dass auch ein Format mit weit weniger Moderation bzw. Anleitung wichtig ist, insbesondere auch um das bisher Erlernte in einer sicheren Umgebung zu testen und echtes TeamPlay zu trainieren. Den Begriff “Dojo” ausschließlich für solche freien Formate zu verwenden, ist wie Ralf beschrieben hat aus historischer Sicht wahrscheinlich eher ungeschickt. Dem stimme ich zu.

Ich denke hier hat Ralf hat meine Twitter-Kommentare evtl. auch etwas überbewertet (140 Zeichen sind natürlich oft auch missverständlich). Ich bin auch nicht dafür, dass alle Entwickler gleichgemacht werden sollen und es überhaupt keinen Lehrer gibt. Ganz im Gegenteil jeder soll sich einbringen, denn selbstverständlich sind immer unterschiedliche Wissengrade im Raum zu finden.

Dass alle etwas beisteuern klappt dann aber nur wenn die erfahreneren Entwickler sich auch mal darauf einlassen einen vorgeschlagenen “Irrweg” mit zu gehen und den Erkenntnisprozess so reifen zu lassen. Abgabe von Kontrolle ist zugegebenermaßen nicht gerade einfach, aber manchmal wird man vielleicht auch als alter Hase noch überrascht werden.

Tags: , ,