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.

I recently had the problem to register a global hotkey, but my “old” Win32-API calls didn’t work with WPF. I looked around the web and found the “Managed Windows API”, but I didn’t want to add another external dependency to my project, so I extracted the core functions for registering hotkeys and condensed the code to a new version.

As the original “Managed Windows API” is licensed by the GNU Lesser General Public License (LGPL) I want to provide my modifications here.

First we need a Window which can dispatch the window messages to our event handlers:

Now we can write our global hotkey handler class:

Now we can easily register a global hotkey or use it as an observable in F#:

Friday I attended the .NET BootCamp “NHibernate vs. Entity Framework” in Leipzig and as always it was a pleasure for me being there. Afterwards I had a nice talk with my friend Alexander Groß about the Open/Closed Principle. I didn’t really care about this principle before, but now I think it’s really a nice idea:

“In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be modified without altering its source code.”

[Wikipedia]

If we follow this principle we get lot’s of small and testable classes. I want to demonstrate this with a simple spam checker for mails.

Let’s say our mail class has only a sender, a recipient, a subject and the mail body:

Now we want to know if a mail is spam or not. Of course we need some rules and some kind of “rule checker” to decide this. Here is a very naïve implementation for this:

It is obvious that this implementation breaks the Open/Closed Principle. Every time someone comes up with a new anti-spam rule or the rule priorities change I have to modify the code in CheckMail(). Another problem here is that I can’t test CheckMail() isolated from the concrete rules.

With the help of the Open/Closed Principle our implementation could look like this:

Now you could easily write isolated UnitTests for RuleChecker.CheckMail() and for every new rule.

You get the your concrete RuleChecker by calling the constructor with a list of rules:

Alex please correct me if I’m wrong, but I think this is what you had in mind Friday.

As stated before, we end up writing lot’s of very small classes – mostly with only one (public) method. I think this is some kind of functional approach, the only question is how we glue our code entities together. Let’s look at the corresponding F# implementation:

The signature of checkMail is (EMail -> SpamResult) list -> EMail –> SpamResult, which means it takes a list of rules (as above the order is important) and a EMail and returns the SpamResult. In addition I exchanged the explicit foreach loop with a tail recursion to make it look more functional.

If I want a concrete rule checker I could use partial application:

As you can see the F# implementation is nearly the same as the C# implementation, just without explicitly wrapping our public method in classes. If we would use Reflector we would see that the F# compiler is building the classes around our functions. One could say if we follow the Open/Closed Principle we come to functional code or the other way around if we write functional code we automatically apply the Open/Closed Principle. I think that’s why I really didn’t care about this before.

Appendix

After thinking about this implementation and the extra type hint (see mail:EMail) I came up with a slightly more generic implementation:

Here I deleted the enum value for SpamResult.Unknown and used the standard None option. As a consequence the signature changed to:  val checkRules : (‘a -> ‘b option) list -> ‘a -> ‘b option. The function still takes a list of rules and a element and returns a option value. Now the checkRules function works with every kind of rule result and takes arbitrary elements.

Yesterday I was talking about F# at the .NET Developer Group Braunschweig. It was my first talk completely without PowerPoint (just Live-Coding and FlipChart) and I have to admit this is not that easy. But the event was really a big fun and we covered a lot of topics like FP fundamentals, concurrency and domain specific languages (of course I showed “FAKE – F# Make”).

Now I have a bit time before I go to the next BootCamp in Leipzig. Today Christian Weyer will show us exciting new stuff about WCF and Azure.

In the meanwhile I will write here about another important question (see first article) from the F# BootCamp in Leipzig:

Question 4 – Try to explain “Currying” and “Partial Application”. Hint: Please show a sample and use the pipe operator |>.

Obviously this was a tricky question for FP beginners. There are a lot of websites, which give a formal mathematical definition but don’t show the practical application.

“Currying … is the technique of transforming a function that takes multiple arguments (or more accurately an n-tuple as argument) in such a way that it can be called as a chain of functions each with a single argument”

[Wikipedia]

I want to show how my pragmatic view of the terms here, so let’s consider this small C# function:

public int Add(int x, int y)
{
   return x + y;
}

Of course the corresponding F# version looks nearly the same:

let add(x,y) = x + y

But let’s look at the signature: val add : int * int –> int. The F# compiler is telling us add wants a tuple of ints and returns an int. We could rewrite the function with one blank to understand this better:

let add (x,y) = x + y

As you can see the add function actually needs only one argument – a tuple:

let t = (3,4)         // val t : int * int
printfn "%d" (add t)  // prints 7 – like add(3,4)

Now we want to curry this function. If you’d ask a mathematician this a complex operation, but from a pragmatic view it couldn’t be easier. Just remove the brackets and the comma – that’s all:

let add x y = x + y

Now the signature looks different: val add : int -> int –> int

But what’s the meaning of this new arrow? Basically we can say if we give one int parameter to our add function we will get a function back that will take only one int parameter and returns an int.

let increment = add 1      // val increment : (int -> int)
printfn "%d" (increment 2) // prints 3

Here “increment” is a new function that uses partial application of the curryied add function. This means we are fixing one of the parameters of add to get a new function with one parameter less.

But why are doing something like this? Wouldn’t it be enough to use the following increment function?

let add(x,y) = x + y       // val add : int * int -> int 
let increment x = add(x,1) // val increment : int -> int
printfn "%d" (increment 2) // prints 3

Of course we are getting (nearly) the same signature for increment. But the difference is that we can not use the forward pipe operator |> here. The pipe operator will help us to express things in the way we are thinking about it.

Let’s say we want to filter all even elements in a list, then calculate the sum and finally square this sum and print it to the console. The C# code would look like this:

var list = new List<int> {4,2,6,5,9,3,8,1,3,0};
Console.WriteLine(Square(CalculateSum(FilterEven(list))));

If we don’t want to store intermediate results we have to write our algorithm in reverse order and with heavily use of brackets. The function we want to apply last has to be written first. This is not the way we think about it.

With the help of curried functions, partial application and the pipe operator we can write the same thing in F#:

let list = [4; 2; 6; 5; 9; 3; 8; 1; 3; 0]

let square x = x * x

list
 |> List.filter (fun x -> x % 2 = 0) // partial application
 |> List.sum
 |> square
 |> printfn "%A"                     // partial application

We describe the data flow in exactly the same order we talked about it. Basically the pipe operator take the result of a function and puts it as the last parameter into the next function.

What should we learn from this sample?

1. Currying has nothing to do with spicy chicken.
2. The |> operator makes life easier and code better to understand.
3. If we want to use |> we need curryied functions.
4. Defining curryied functions is easy – just remove brackets and comma.
5. We don’t need the complete mathematical theory to use currying.
6. Be careful with the order of the parameter in a curryied function. Don’t forget the pipe operator puts the parameter from the right hand side into your function – all other parameters have to be fixed with partial application.

This post has been moved to http://fsharp.github.io/FAKE/customtasks.html

This article has been moved to http://fsharp.github.io/FAKE/assemblyinfo.html

This post has been moved to http://fsharp.github.io/FAKE/fxcop.html

This article has been moved to http://fsharp.github.io/FAKE/gettingstarted.html

"Implementing Microsoft Dynamics NAV 2009" is a new book by David Roys (MVP for Dynamics NAV) and Vjekoslav Babic (Dynamics NAV consultant). It shows the new features of Dynamics NAV 2009 in step-by-step explanations of real-world examples.

If you are interested in this book you can read the complete seventh chapter right here on navision-blog.de:

• Extending the Application using Microsoft Dynamics NAV 2009 (Part I)
• Extending the Application using Microsoft Dynamics NAV 2009 (Part II)

Chapter 6 (“Modifying the System”) is also available for download.

What the book covers

Chapter 1

The purpose of this chapter is a teaser introduction to get you excited about the product, what’s in it in general, and what’s in it as compared to previous versions, to give you a little taste of what’s coming up in the book, and explain what the fuss about this new release is all about.

Chapter 2

The RoleTailored client is the new user interface for users of Microsoft Dynamics NAV 2009, and it is completely different to the pervious versions. We’ll take you through the different components of the interface, introduce the terminology, explore the navigation components and page types, and teach you how to personalize the application to meet your own requirements using the extensive personalization features.

Chapter 3

Microsoft Dynamics NAV 2009 introduces a new paradigm to ERP. Instead of the system being focused on the forms that capture and present data and the functions the user can perform, the system is based around the individuals within an organization, their roles, and the tasks they perform. We cover how Microsoft researched the roles and explore the departments, roles, and tasks that have been identified in the Microsoft Dynamics Customer Model. We also show the reader how to assign the standard roles to users, how to create new roles, and how to allow departmental super users to configure the application for their role so that the change is applied to all users with the same profile.

Chapter 4

Microsoft Dynamics NAV is not a product with a Next-Next-Finish type of installation, and it takes a lengthy project to deploy it successfully. We focus on the six phases of the implementation process, and explain each phase with detailed dos and don’ts for a typical implementation. Based on the Dynamics Sure Step implementation methodology with advice liberally sprinkled throughout, special attention is given to new features of Microsoft Dynamics NAV 2009, and where the new capabilities must be taken into account to make most out of the implementation project.

Chapter 5

Every implementation of Microsoft Dynamics NAV 2009 will require the system to be configured to meet the needs of the business. This chapter tells the implementation consultant how to do this from a core financials perspective and provides valuable information that will allow developers to understand more about the application they are changing. We cover basic accounting for programmers, dimensions, and posting groups, and how to use the Rapid Implementation Methodology (RIM) Toolkit to speed things along.

Chapter 6

Hardly any standard system can fit the needs of a business out of the box. Either the customer must shape their processes to match the system, or the consultant must shape the system to match the processes, and usually the latter prevails. This chapter explains the process of modifying the system, how to design a viable data model, and how to design and develop a functional user interface for both RoleTailored and Classic clients, without writing any code.

Chapter 7

The three-tiered architecture of Microsoft Dynamics NAV 2009 and native Web Services Enablement open up a whole new world of possibilities for NAV implementations. We cover some of the many possibilities for extending the application, allowing the consultant and developer to understand the technologies that are available and their respective design considerations. Our practical examples introduce the NAV programmer to the world of .NET and show how you can use the information available on the internet to develop your own killer .NET add-ons.

Chapter 8

There’s much more to development than programming. It starts with understanding what customer really needs, and usually extends way beyond the system being deployed to a test environment. This chapter focuses on the development phase, and what it takes to get from a concept to a live and working solution.

Chapter 9

After the system goes live, or as it grows, there are periods when new problems may arise, and often their source is far from obvious. This chapter explores the tools and techniques available for detecting problems, pinpointing the source, and helping to remove them from the system quickly and painlessly. It explains how to debug the Service Tier, how to troubleshoot performance issues, what can be done to avoid problems, and how proper planning before design can help to get it right the first time.

Chapter 10

Our sample application focuses on requirements gathering, functional specification creation, solution design, and the eventual build of a prototype. We look at how a business problem can be explored using techniques such as interviewing, use-case modeling, and object-role modeling to create a solution design that can be molded into a working prototype.

If you want to get more information about the book visit: http://www.packtpub.com/implementing-microsoft-dynamics-nav-2009/book