RavenDB, Docker and F#


Here is a little F# application which connects to a RaveDB database, adds an entry and reads them. I used this application to play with RavenDB running inside a Docker container.

open Raven.Client.Documents

type Customer = {
    FirstName: string
    LastName: string
}

[<EntryPoint>]
let main argv =
    printfn "Hello RaveDB!"

    use store = new DocumentStore ()
    store.Urls <-  [|"http://10.0.75.1:8080"|]
    store.Database <- "RavenDB1"
    use store = store.Initialize ()
    
    use session = store.OpenSession ()
    let customer1 = { FirstName = "Guy"; LastName = "Montag" }
    session.Store customer1
    session.SaveChanges ()

    let customers = query {
        for customer in session.Query<Customer>() do
        select customer
    }

    customers |> Seq.iter (printf "%A")

    printfn "Done!"
    0

You can download the full project from my GitHub repository.

https://github.com/chuchu/sandbox/tree/master/ravendb/raven1

From the code you can see that the database runs on 10.0.75.1 which is the IP address of my Docker bridge.

To execute a RavenDB Docker container you need to download the image first. You can do this by executing the command:

docker pull ravendb/ravendb

This will download the latest ubuntu based version. To run the image its best to use the run-ubuntu1604.ps1 powershell script which is provided by the RavenDB project.

ubuntu1604.ps1 -AuthenticationDisabled -PublicServerUrl "http://10.0.75.1:8080"

Disabling authentication is good for testing purposes. So there is no need to deal with certificates. Why it is necessary to provide the PublicServerUrl is something what I don’t really understand completely. But this article explains it a little bit.

https://ayende.com/blog/178819/bug-stories-how-do-i-call-myself

Now you can open your browser, go to http://10.0.75.1:8080 and create the database RavenDB1. When the database is up and running the application can be executed.

dotnet run

When everything works as expected the F# application can be deployed in a container too. Before the image can be created you need to make a release build.

dotnet publish -c release -o app

The docker file is available in the repository. So you just need to type

docker build -t hello-ravendb .

Have a look for the line

Successfully built 388344c214f3

Your ID is surely different, but you need it to run your image.

docker run 388344c214f3

You should see the same output as when the application was executed directly.

Advertisements

Avoid subscribing to events in constructors


While adopting a unit test I found a piece of code which looks pretty much like this one:

public Subscriber(Printer printer, string message)
{
    printer.Print += OnPrint;

    if (message == null)
    {
        throw new ArgumentNullException("message");
    }

    myMessage = message;
}

This is the constructor of a class called Subscriber. In the first statement it subscribes an external event. Afterwards it checks a message parameter and might throw an exception. The following question comes to my mind. What happens to the event when the exception is thrown? Is there some zombie object assigned to the Print multicast delegate? Indeed it is! When you have the following code:

var s = new Subscriber(printer, null);

You will get an exception, but the instance was created somehow. The assignment to the s variable did not happen because of the exception but it is there. Typically the instance would be deleted with the next garbage collector run, but not when someone keeps a reference. In case of the Subscriber the Printer class keeps a reference with its Print event and so it cannot be garbage collected. What makes it even worse is, that the event handler of the zombie instance is called when the Print event is raised.

So be very careful when subscribing to events in constructors. If anything they should appear as last statement.

File System Redirector


Wenn man aus einem 32 Bit Prozess heraus versucht eine Anwendung zu starten die unter C:\Windows\System32 liegt, wird der Pfad direkt zu C:\Windows\SysWOW64 übersetzt. Der Grund dafür ist, dass unter System32 die 64 Bit files liegen und unter SysWOW64 die 32 Bit Versionen. Für die Umleitung ist der File System Redirector verantwortlich. Das ist zwar alles ganz praktische, aber was wenn man aus dem 32 Bit Prozess wirklich die 64 Bit Anwendung starten möchte?

Dieses Problem hatte ich zum Beispiel mit Visual Studio. Ich wollte ein Powershell Script per external Tool einbinden, welches alle Prozesse beendet, die eine bestimmte DLL geladen haben. Die 32 Bit Powershell kann aber scheinbar nicht die Module eines 64 Bit Prozesses auflisten. Deshalb muss man die 64 Bit Version verwenden. Also habe ich im VS C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe als external Tool angegeben. Seltsamerweise hat dann mein Script aber nicht funktioniert. Nach etwas Suchen habe ich im process explorer gesehen,  dass immer die 32 Bit Powershell gestartet wird. Obwohl ich extra die 64  Bit Version angegeben habe. Stackoverflow brachte mich dann auf den File System Redirector und die Lösung für mein Problem. Man muss %windir%\sysnative als system Pfad verwenden. Dieser wird dann auch nicht geändert. Es muss also %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe als external Tool angegeben werden.

dodned Usergroup Franken


Gestern war ich zum ersten Mal auf einem Treffen der dotned Usergroup Franken und habe auch zum ersten Mal an einem coding dojo teilgenommen.

Es war wirklich sehr Witzig das FizzBuzz „Problem“ mittels TDD und mit pair programming zu lösen. Trotz der einfachen Natur der Aufgabenstellung ist es interessant wie viele Diskussionen es  über die Implementierung der Lösung gab. Das zeigt eines ganz deutlich: Kein Problem ist so einfach, als dass man es mit VHIT (vom Hirn ins Terminal) lösen sollte.

Beim nächsten Treffen bin ich auch wieder dabei 😉

Enumerations als bit fields verwenden


Als ich letztens einen Unittest schrieb, fiel mir auf, dass ich in vielen Tests immer wieder die selbe Methode des Testees aufrief. Alles was sich änderte waren die Stubs und die Mock Objekte. Das Ganze sah ziemlich schlecht aus. Es musste sich doch irgendwie vereinfachen lassen. Ich versuchte also den Code in eine neue Methode auszulagern. Diese könnte ich dann von meinen Tests aus aufrufen. Aber wie konnte ich die Parameter so gestalten, dass die Signatur übersichtlich blieb? Da fiel mir ein, dass ich schon mal irgendwo gesehen hatte wie man enumerations als bit fields verwenden kann:

Ausgangspunkt soll folgendes enum sein:

public enum Colors
{
    None,
    Red,
    Green,
    Blue
}

Da enumerations eine Art name/value pair collection sind, kann man jeden Eintrag auf eine Zahl mappen. Die folgende Schleife tut dies für die Werte 0 bis 7 und gibt den Namen aus:

for (int i = 0; i < 8; i++)
{
    Console.WriteLine("{0,3} - {1}", i, ((Colors)i).ToString());
}

Das enum von oben liefert folgendes Ergebnis:

0 – None
1 – Red
2 – Green
3 – Blue
4 – 4
5 – 5
6 – 6
7 – 7

Das ist recht unspektakulär. Der C# Compiler hat einfach für jeden Eintrag im enum einen Zahlenwert vergeben. Von 0 beginnend, bis 3. Wenn man die Enumeration um das Flags Attribut ergänzt, ändert sich die Ausgabe noch nicht wirklich. Eigentlich traurig, weil man das enum dann immer noch nicht als Bitfeld verwenden kann.

Bei einem binären wert von 0011 ist nicht klar ob hier Rot und Grün oder nur Blau gemein ist. Deshalb müssen wir das enum noch ein wenig ändern:

[Flags]
private enum Colors
{
    None = 0,
    Red = 1,
    Green = 2,
    Blue = 4
}

Hier wurden jetzt neben dem Flags Attribut noch die Nummern von Hand vergeben. Damit kann man verhindern, das Bau anstelle der 3 die 4 bekommt. Binär sieht das dann so aus:

0000 – None
0001 – Red
0010 – Green
0100 – Blue

Wenn nun wieder die Schleife von weiter oben ausgeführt wird, sieht das Ergebnis ganz anders aus:

0 – None
1 – Red
2 – Green
3 – Red, Green
4 – Blue
5 – Red, Blue
6 – Green, Blue
7 – Red, Green, Blue

Das liegt daran, dass zum Beispiel die 7 binär eine 111 ist. Es ist also das bit für Rot, Grün und Blau gesetzt.

Nun könnte man sich eine Methode mit folgender Signatur bauen:

public void SetColors( Colors color )

Das schöne ist jetzt das man nicht nur eine sondern mehrere Farben vergeben kann. Zum Beispiel Rot und Grün:

SetColors( Colors.Red | Colors.Green  )

Rot und Grün wird mit einem binären ODER verknüpft das ergibt dann den Wert: 0011. Dieser wird an die Methode übergeben.

Innerhalb von SetColors kann man dann mit folgendem Code prüfen, welche Farben aktiv sind:

public static void SetColors(Colors colors)
{
    if (IsColorSet(colors, Colors.Red))
    {
        //Do something
    }

     // ...
}

private bool IsColorSet(Colors colors, Colors colorToCheckFor)
{
    return (colors & colorToCheckFor) == colorToCheckFor;
}

Der kombinierte Wert wird also mit einem logischen UND mit dem zu prüfenden Wert verknüpft. Dadurch werden alle Bits gekippt, die nicht im zu prüfendem Wert 1 sind.
Bei Rot und Grün haben wir zum Beispiel 0011. Nur Rot ist die 0001. Und aus 0011 & 0001 wird 0001. Also wieder Rot.

Enumerations sind zusammen mit dem Flag Attribut also sehr gut geeignet um Optionen weiterzugeben, bei den auch verschieden Kombinationen möglich sind.