Tag / .NET

by Leif

XPlot ‘hello world’ – Using Google Charts in Web Applications

In this post I will describe the very basics, in other words the 'hello world example', of how to create cool looking Google Charts using XPlot and integrate them into Web Applications.

The F# library XPlot is part of the FsLab data science package, which you can do very neat things with. But it is also possible to reference an XPlot stand-alone package to just use the Google Charts library.

What is XPlot?

XPlot is a cross-platform data visualization package for the F# programming language powered by popular JavaScript charting libraries Google Charts and Plotly. The library provides a complete mapping for the configuration options of the underlying libraries and so you get a nice F# interface that gives you access to the full power of Google Charts and Plotly. The XPlot library can be used interactively from F# Interactive, but charts can equally easy be embedded in F# applications and in HTML reports. --From XPlot Home Page

Creating the chart

There are only a few easy steps necessary to generate the HTML for let's say a simple bar chart.

First we need an F# library project that references the XPlot.GoogleCharts package via NuGet.

Here is a function that will use XPlot to create the HTML and JavaScript code for a simple bar chart:

namespace Charts

module BarCharts =
    open XPlot.GoogleCharts

    let statusCount () =

        let series = [("Open",23); ("In Progress",5); ("Resolved", 58); ("Closed",5)]

        let options =
            Options(
                title = "Status", 
                orientation = "horizontal")

        if series |> Seq.isEmpty then "no data" else
            let chart = 
                series
                |> Chart.Bar
                |> Chart.WithOptions options
                |> Chart.WithLabels ["Count"]

            chart.InlineHtml

The result can be used in any web application if the Google Charts libraries are loaded.

series can be any list of tuples of type (string * int). Off course, in a real project this list would be either passed to the function as an argument, or the function would have a data access dependency injected.

Here is the output of the statusCount() function:

<script type="text/javascript">
  google.charts.setOnLoadCallback(drawChart);
  function drawChart() {
    var data = new google.visualization.DataTable({"cols": [{"type": "string" ,"id": "Column 1" ,"label": "Column 1" }, {"type": "number" ,"id": "Count" ,"label": "Count" }], "rows" : [{"c" : [{"v": "Open"}, {"v": 23}]}, {"c" : [{"v": "In Progress"}, {"v": 5}]}, {"c" : [{"v": "Resolved"}, {"v": 58}]}, {"c" : [{"v": "Closed"}, {"v": 5}]}]});

    var options = {"legend":{"position":"right"},"orientation":"horizontal","title":"Status"} 

    var chart = new google.visualization.BarChart(document.getElementById('9af3e989-c37b-4257-b71f-5053b52f3b48'));
    chart.draw(data, options);
        }
</script>
<div id="9af3e989-c37b-4257-b71f-5053b52f3b48" style="width: 900px; height: 500px;"></div>

Displaying the chart in an ASP.NET MVC application

Now, as an example, we will see how to integrate this into an ASP.NET MVC application.

Loading the Google Charts Library

Load the Google Charts library by adding the following lines to the <head> section of the page e.g. in _Layout.cshtml. (Also see
Load the Libraries)

<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script>
<script type="text/javascript">
  google.charts.load('current', {packages: ['corechart']});
  google.charts.setOnLoadCallback(drawChart);
</script>

Initializing the View Model

Add a reference to the F# project that was created earlier and build the F# project.

Next add a reference to FSharp.Core.

Then initialize a View Model with the chart and pass it to the View:

public ActionResult Index()
{
    var vm = new BarChartVm
    {
        Chart = Charts.BarCharts.statusCount()
    };

    return View(vm);
}

Add the following code to the page at the position where the chart should be displayed:

<div>
    @Html.Raw(@Model.Chart)
</div>

When running the application, the chart should be displayed like this:

Here is the source code from this post.

by Leif

SQL Type Providers and Continuous Integration with FAKE

If you want to access a relational database from an F# (or C#) application, SQL F# type providers are commonly used. SQL type providers will provide all the types, properties and methods needed to access and interact with the tables of a SQL database, without having to write any extra boilerplate code. Everything is type checked and if the actual database schema gets out of synch with the database related code, compilation will fail. This is very valuable because it gives you high confidence in the application's data access code.

So at compile time the database has to be up to date and accessible. But how does this work in a continuous integration environment? Off course an option is to have the connection string of the type provider point to a development database on the network. Another solution would be to manually create or update a database on the build server before the build. But I don't really like this because I think the build server should be independent and self-sufficient. A solution to this scenario, that worked for me, is to deploy the database during the build process using Visual Studio database projects and FAKE - F# Make.

There might be other and maybe better solutions that I haven't come up with. I'd be curious to find out. Actually this might be one. The approach that I used, however, works out nicely, so I will give a quick walkthrough on how to set things up.

Continue reading →

by Leif

Functional error handling – parsing command line arguments in C#

This is the third part of the series Functional error handling in F# and C#. In this post we will see how the command line argument parser with functional error handling, that was shown here using F#, can be implemented in C#.

Continue reading →

by Leif

Functional error handling – parsing command line arguments in F#

In this post, which is the second part of the series Functional error handling in F# and C#, we will examine an application for parsing command line arguments with error handling.

The functional approach uses Applicative Functors. Applicative Functors and the basics of functional error handling, only with immutable objects and without the use of exceptions, are explained int the first post of this series: Error handling with Applicative Functors in F# and C#.

A complete solution with all the code samples from this series can be found here.

As a starting point I took this F# console application template and reimplemented it with railway oriented error handling in F# and C#. The original version writes error messages directly to the console, which is totally ok in many situations. However, the railway oriented approach offers a bit more flexibility and safety because it will let the caller decide on how to handle the failure cases.

Continue reading →

by Leif

Error handling with Applicative Functors in F# and C#

In an object-oriented context a typical way to do error handling is to use the Notification Pattern described by Martin Fowler.

In functional programming (FP) the approach to error handling is very different. Error handling has to be done without mutating state and without the use of exceptions. The concept that is capable of this, and that is commonly used in FP is called "Applicative Functor".

In this post, which is the first part of the series Functional error handling in F# and C#, we will cover all the basics that are needed to do functional error handling in F# and C#, and to understand Applicative Functors.

The F# and C# code samples from this post can be found here.

In the second part of the series we will look at a sample application for parsing command line arguments with error handling in F#.

Anyway, before we jump right into it, we will need some introduction.

Continue reading →

by Leif

Series: Functional error handling in F# and C#

Some time ago when I started learning functional programming I also started to follow functional programmers on twitter. Some day someone stated that error handling should be done with Applicative Functors.

Off course the Fowler way is a very typical, commonly used and approved approach. So what makes it so much better to use Applicative Functors instead? And what are they anyway?

This series of posts will answer these questions. It is the kind of article I was looking for back then but could not find. It is a compilation of all the pieces and resources that I found researching the topic.

In the first part we will cover all the basics that are needed to do error handling in a functional style, and to understand what is going on behind the scenes. We will see how error handling can be done only with immutable objects and without using exceptions.

In the second part of the series we will look at a sample application for parsing command line arguments with error handling in F#.

Content of this series:

  1. Error handling with Applicative Functors in F# and C#
    Basics of functional error handling

  2. Functional error handling - parsing command line arguments in F#
    Functional error handling in practice (F#)

  3. Functional error handling – parsing command line arguments in C#
    Functional error handling in practice (C#)

  4. Functional vs. imperative error handling
    A comparison of the functional vs. the imperative approach to error handling

by Leif

Viewmodel property to observable stream

When implementing a user interface in WPF/MVVM applications we frequently encounter situations where we want to be able to react on all changes made to a particular property.

One way to handle this is to create an observable sequence of values with Reactive Extensions (Rx). This is especially valuable if we have other event streams that interact with the property changed events.

There are several libraries around that can help with this like e.g. ReactiveUI or ReactiveProperty.

But if we want a lightweight, generic, reusable, and typesafe solution, we can consider just using the following extension method, which can be called on any instance that implements INotifyPropertyChanged. It retrieves the property name from the expression that is passed in, converts all PropertyChanged events into an observable sequence, and then finds the value of the right property using reflection.

Continue reading →

by Leif

Function composition in C#

Function composition is about the essence of programming. Complex problems can be solved by decomposing them into many smaller problems that each can be worked out easily. Finally those small pieces have to be put together to form the overall solution. One way of combining these small pieces is function composition.

Also function composition is a great tool that makes the code more compact and reduces noise. Because of the concise syntax there are fewer possibilities to make mistakes like mixing up parameters e.g.

In this post I will show how function composition can be implemented in C# and how it is related to currying and partial application. Also I will discuss the pros and cons of function composition in C# and point out an alternative. All C# source code from this post can be downloaded here.

Continue reading →

by Leif

Series: Reactive Extensions in theory and practice

Reactive Extensions is a library for composing event based programs using observable sequences and LINQ-style query operators.

I wrote a series of blog posts on Reactive Extension covering some theory and including some practical examples in C#:

Series: Reactive Extensions in theory and practice

  1. Short introduction to Reactive Extensions
  2. Visualizing sequences
  3. Drawing lines with Rx
  4. Twitter with Rx