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

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.

In order to simplify the access of the FSharpx type providers I separated them into their own nuget packages. From now on we have:

• FSharpx.TypeProviders.AppSettings which generates setters and getters for application settings files. [Read more]
• FSharpx.TypeProviders.Documents which allows strongly typed access to JSON, XML and CSV files. [Read more]
• FSharpx.TypeProviders.Excel which provides strongly typed access to Excel spread sheets. [Read more]
• FSharpx.TypeProviders.Graph which includes type providers for state machines and graphs. [Read more]
• FSharpx.TypeProviders.Math which contains a type provider for vector data structures. [Read more]
• FSharpx.TypeProviders.Regex which allows to access regular expressions in a strongly typed manner. [Read more]
• FSharpx.TypeProviders.Xaml which includes a type provider for XAML files and therefor enables to use Visual Studios’s WPF Designer from F#. [Read more]
• FSharpx.TypeProviders.Machine which provides strongly typed access to the Registry and the file system.
• FSharpx.TypeProviders.Freebase which allows to access the Freebase database with strong typing. [Read more]
• FSharpx.TypeProviders which installs all of the above type providers.

At the moment all type providers should work with .NET 4.0 and .NET 4.5 and F# 3.0.

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.

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.

After the official Visual Studio 2012 launch yesterday I think it’s a good idea to announce two new type providers which are based on the DGMLTypeProvider from the F# 3.0 Sample Pack.

Synchronous and asynchronous state machine

The first one is only a small extension to the DGMLTypeProvider by Tao. which allows to generate state machines from DGML files. The extension is simply that you can choose between the original async state machine and a synchronous version, which allows easier testing.

If you want the async version, which performs all state transitions asynchronously, you only have to write AsyncStateMachine instead of StateMachine.

State machine as a network of types

The generated state machine performs only valid state transitions, but we can go one step further and model the state transitions as compile time restrictions:

As you can see the compiler knows that we are in State2 and allows only the transitions to State3 and State4.

If you write labels on the edges of the graph the type provider will generate the method names based on the edge label. In the following sample I’ve created a small finite-state machine which allows to check a binary number if it has an even or odd number of zeros:

As you can see in this case the compiler has already calculated that 10100 has an odd number of zeros – no need to run the test .

This stuff is already part of the FSharpx.TypeProviders.Graph package on nuget so please check it out and give feedback.

In the last post I wrote about the PersistentVector which I ported from Clojure to .NET. It’s implemented as an immutable hash array mapped trie which optimizes the constant factors so that we can assume O(1) for count, nth, conj, assocN, peek and pop.

But for some applications Rich Hickey shows us that we can optimize the constant factors even further. If we are sure that we are only holding exactly one reference to the vector than we can mutate the underlying representation instead of copying the arrays on every change. This idea is implemented in the TransientVector which I also ported from Clojure.Core to FSharpx.

Let’s look at a small example. Here we want to convert a collection to a PersistentVector:

As you can see we iterate over the collection and conj the items to the current PersistentVector. But in every step we forget the reference to the last version. This is exactly the point where can use TransientVector:

Here are the results:

Most higher-order functions on vectors like map are also implemented with this trick.

Rich Hickey created a very nice set of persistent collections for Clojure. I started to port them to FSharpx and today I want to present the PersistentVector. The basic idea is that we want to have something like an array but immutable.

Vectors (IPersistentVector)

A Vector is a collection of values indexed by contiguous integers. Vectors support access to items by index in log32N hops. count is O(1). conj puts the item at the end of the vector.
     From http://clojure.org/data_structures

These vectors are very fast in practical applications since the depth of the underlying tree is not greater than 7. First performance tests show the following on my machine:

These results are not that far away from the Clojure/Java implementation (see below). The lookup seems to be a bit faster but assoc is slower. Maybe that has something to do with the internal array copy function of .NET:

After installing the FSharpx nuget package can use this Vector<T> from C# like this:

More samples can be found in the PersistentVectorTest.fs file.

Additional resources:

• Original implementation
• Data structures in Clojure
• Rich Hickey on "Persistent Data Structures and Managed References"
• Understanding Clojure’s PersistentVector implementation
• Hash array mapped trie

I’m happy to annouce a new nuget release of FSharpx.TypeProviders. The new version 1.5.3 allows to access JSON and XML in a strongly typed way. These new type providers are based on an XML type provider by Tomas Petricek. I added a write API and a JSON version.

Idea

Whereas XML allows different ways to define a schema, JSON has no schema. Nevertheless most documents have some kind of an implicitly defined schema. These new type providers try to infer the schema from a sample file and provide you types to access any file which is conform to this schema.

Let’s take a look at some of the new features.

JSON access

Consider this JSON sample from Wikipedia:

Let’s add this file to a new F# solution and reference the FSharpx.TypeProviders.dll via install-package FSharpx.TypeProviders. Enable the type provider in the following dialog:

Now that we have a sample data and the type provider ready we get full Intellisense:

In most cases you want to use the initial document only as a sample, therefore it’s also possible to load a different document at runtime which the type provider will treat with the same schema:

It’s even possible to modify properties:

Accessing XML

After adding a reference to System.Xml.dll and System.Xml.Linq.dll it’s also very easy to access XML. Since both type providers have the same features we will use yet another way to provide a schema sample. In this case we give the schema inlined:

Schema invalidation

One important aspect of type providers is the schema invalidation. For instance try to remove the line with the age property of WikiSample.txt and save the file. The type provider will detect this schema change and your code will no longer compile:

Enjoy your statically typed JSON/XML documents.

F# 3.0 brings the new type providers feature which enables a lot of different applications. Today I’m happy to announce that the FSharpx project brings you a WPF designer for F# in the Visual Studio 11 beta.

A big kudos to Johann Deneux for writing the underlying XAML type provider.

1. Create a new F# 3.0 Console application project
2. Set the output type to “Windows Application” in the project settings
3. Use nuget and install-package FSharpx.TypeProviders.Xaml
4. Add references to WindowsBase.dll, PresentationFramework.dll, System.Xaml.dll and PresentationCore.dll
5. Add a Xaml file to your project. Something like this:
6. Now you can access the Xaml in a typed way:
7. Start the project

Enjoy!

BTW: No code generation needed is for this. No more nasty *.xaml.cs files.
BTW2: Try to change the name of Button1 in the Xaml and press save.

This is yet another blog post in my Currying and Partial application series. This is what I have posted so far:

• Partial application in F# and C#
• Why do we need partial application? – Part 1 of n – Fluent interfaces and piping
• Currying and uncurrying in C# and F#

In this post I want to show you a way to simulate type classes in C# and F#. Type classes are this wonderful feature in Haskell which allow you to specify constraints on your polymorphic types. We don’t have this in C# nor F#.

Let’s start with the following problem: We want to compute the sum of the squares of arbitrary numbers. We want to write something like this:

The problem is we don’t have a generic * function and of course we’d also need a generic + operator and maybe a generic zero. Obviously we need a constraint on the generic parameter T since + might not be defined for any type. So let’s define an interface for numbers:

Nothing special here, so let’s get straight to the implementation for integers and doubles:

So far so good. With this in our pocket we rewrite SumOfSquares() into this:

The trick is that we pass the concrete implementation as the first parameter into our function. This works exactly like a type constraint or as Simon Peyton-Jones would say: the vtable travels into the function. Notice that we don’t have access to the definition of in nor double. There is no way for us to express that int or double implement a number interface.

Now let’s try this out:

As you can see, this is perfectly type safe. We now have a way for poor man’s type classes in C#. Yay!

Now what has this to do with partial application? Let’s look at the same thing in F#:

We’re using a lot of partial application here. Exercise: Try to spot all the places.

Ok, you’re right. This post might be a little bit far away from the partial application stuff, but it’s still related. Somehow.