Random Ravings of a Red Headed Code Monkey

Making F# Windows Phone Development a Little Easier

2012-01-23T05:18:00.000-08:00

About a month ago, I announced that most of the existing F# project templates on Visual Studio Gallery had been updated to include support for Visual Studio 11. In that post, I mentioned some new item templates that had been included in the update to the F# XAML Item Templates extension. This post provides a bit more information related to that update.

The F# XAML Item Templates extension was designed to make working with F# + WPF and Silverlight a little eaiser. I provided a brief overview of these features back in June. However, Windows Phone XAML related development was still lacking. The previous approach to adding XAML files was to either create a blank file, change the extension, and manually add the appropriate starting XAML or create the XAML from one of the C# item templates, remove the code-behind files, and tweak the resulting XAML. While neither of these options is extremely time consuming, it can quickly become annoying.

The latest update to this Visual Studio extension reduces this annoyance by providing F# Windows Phone 7 XAML item templates. Once this VSIX is installed, you can add a Windows Phone 7 XAML file by doing the following:

1. In a Windows Phone F# project, proceed with adding a new item as you normally would (i.e. Ctrl+Shift+A).

2. The resulting wizard (shown below) includes several new item templates starting with "F#..." that match the C# versions, but that do not generate C# code-behind files.

While you still have to write the small amount of F# code to wire this up, it makes life a little bit easier.

developerFusion Article: An Introduction to FSharpx

2012-01-16T08:24:00.000-08:00

My article entitled "An Introduction to FSharpx" was published a few days ago. You can find it at http://www.developerfusion.com/article/136179/an-introduction-to-fsharpx.

As mentioned in the article, FSharpx is continually evolving and several new features have been added since I submitted this article. Be sure to head over to the FSharpx GitHub site to see what's new.

Introducing ExpectThat: A CoffeeScript Assertion Library

2012-01-08T09:29:00.000-08:00

I'm a big fan of automated testing. In fact, on the rare occasions that I don't write tests, I find that I can't shake the thought that something has been missed.

As with all aspects of my coding efforts, I am constantly looking for ways to improve the process, make tests more readable, and reduce room for error. With these goals in mind, I'd like to introduce ExpectThat.

What is ExpectThat?

ExpectThat is an expressive, self-documenting, assertion library for CoffeeScript, that seeks to improve testing efforts with your favorite testing framework. It does this by providing a syntax similar to FsUnit (a library for F#) that makes assertions more readable and then automatically translates that readable code into descriptive test output. This ensures that your test names always stay in sync with your tests and allows your code to speak for itself. ExpectThat currently supports Pavlov, QUnit, and Jasmine. Overtime, support for additional testing frameworks will be added.

Let's See it in Action

The following example shows how to write tests with ExpectThat for Pavlov in CoffeeScript:

pavlov.specify "Example Specifications", ->
    foo = "bar"
    describe "When testing 'should equal'", ->
        expectThat -> foo.should equal "bar"
    describe "When testing 'shouldnt equal'", ->
        expectThat -> foo.shouldnt equal "baz"
    describe "When testing for 'true'", ->
        expectThat -> (foo is "bar").should be true
        expectThat -> (foo is "baz").shouldnt be true
    describe "When testing for 'false'", ->
        expectThat -> (foo is "baz").should be false
        expectThat -> (foo is "bar").shouldnt be false
    describe "When testing 'greater than'", ->
        expectThat -> (9.1).should be greaterThan 9
        expectThat -> (9.1).shouldnt be greaterThan 10
        expectThat -> 10.shouldnt be greaterThan 10

Here's a screenshot of the result:

Other Testing Frameworks

As I mentioned, ExpectThat currently supports QUnit and Jasmine in addition to Pavlov. The following are examples for each of these.

QUnit:

module "Example QUnit Specifications"

foo = "bar"

module "When testing should equal"

expectThat -> foo.should equal "bar"

module "When testing shouldnt equal"

expectThat -> foo.shouldnt equal "baz"

module "When testing for true"

expectThat -> (foo is "bar").should be true
expectThat -> (foo is "baz").shouldnt be true

module "When testing for false"

expectThat -> (foo is "baz").should be false
expectThat -> (foo is "bar").shouldnt be false

Jasmine:

describe "Example Jasmine Specifications", ->
    foo = "bar"
    describe "When testing should equal", ->
        expectThat -> foo.should equal "bar"
    describe "When testing shouldnt equal", ->
        expectThat -> foo.shouldnt equal "baz"
    describe "When testing for throw", ->
        expectThat -> (-> throw "test exception").should throwException
        expectThat -> (-> throw "test").should throwException "test"
    describe "When testing for less than", ->
        expectThat -> 10.should be lessThan 11
        expectThat -> (10.1).shouldnt be lessThan 10

Getting Started with ExpectThat

There are a couple of ways to get started with ExpectThat. First, head over to the ExpectThat GitHub site and browse through the documentation. You can then clone the repo and grab any of the examples from the example folder. If you are writing an ASP.NET app in Visual Studio, another option is to install one of the available NuGet packages.

Available Assertions

ExpectThat currently provides the following assertions:

- equal
- stictlyEqual
- false
- true
- greaterThan
- greaterThanOrEqual
- lessThan
- lessThanOrEqual
- throwException
- 'to' and 'be' can be used in most cases to make tests more readable.

In addition to the out-of-the-box assertions, ExpectThat allows for the creation of custom assertions. Examples of this for each of the supported testing frameworks are available in the example folder on GitHub.

ExpectThat in JavaScript

While the syntax of ExpectThat works best with CoffeeScript, you can certainly use it in JavaScript as well. Simply add in the missing braces, parens, semi-colons, function keywords, etc. The following provides a simple example for Pavlov:

pavlov.specify("expectThat Specifications", function() {
    describe("When testing should equal", function() {
        var foo = "bar";
        expectThat(function() {
            foo.should(equal("bar"));
        });
        expectThat(function() {
            (foo + "test").should(equal("bartest"));
        });
    });
});

Getting Involved

There are a lot of things left to do for ExpectThat and I'd love to hear your thoughts on direction, enhancements, etc. as well as have any help that anyone would like to offer. If you want to get involved, fork me on GitHub.

Announcing FsUnit 1.0

2011-12-25T13:31:00.000-08:00

A couple of weeks ago I announced a few enhancements to FsUnit. Today, I'm proud to announce the release of FsUnit 1.0. Version 1.0 includes support for additional testing frameworks, a new assertion function, and more...

New Testing Framework Support:

All previous releases of FsUnit provided support for only NUnit; however, the goal for FsUnit has always been to provide support for other major testing frameworks as well. This release largely accomplishes this goal by adding support for MbUnit version 3.3.454.0 and xUnit.NET version 1.8.0.1549. While the majority of functions provided for NUnit are also provided for these two testing frameworks, there are a couple of features that are not available. Each of these missing features can easily be worked around and the FsUnit unit tests provide examples of this.

NuGet Packages:

The easiest way to get started with FsUnit is to install one of the following NuGet packages.

- FsUnit for NUnit can be installed via the original NuGet package ID of FsUnit.

- FsUnit for xUnit.NET can be installed via the FsUnit.xUnit package ID.

- FsUnit for MbUnit can be installed via the FsUnit.MbUnit package ID.

Additional Assertion:

In addition to support for MbUnit and xUnit.NET, the equalWithin function has been added. Thanks to erdoll for requesting this enhancement and for providing much of the code for the NUnit implementation. The equalWithin function allows an equality assertion with a specified tolerance. Examples are provided below:

NUnit Example:

module Test.``equalWithin assertions``

open NUnit.Framework
open FsUnit

[<Test>]
let ``should equal within tolerance when less than``() =
    10.09 |> should (equalWithin 0.1) 10.11

[<Test>]
let ``should not equal within tolerance``() =
    10.1 |> should not ((equalWithin 0.001) 10.11)

xUnit.NET Example:

module Test.``equalWithin assertions``

open Xunit
open FsUnit.Xunit

[<Fact>]
let ``should equal within tolerance when less than``() =
    10.09 |> should (equalWithin 0.1) 10.11

[<Fact>]
let ``should not equal within tolerance``() =
    10.1 |> should not ((equalWithin 0.001) 10.11)

MbUnit Example:

module Test.``equalWithin assertions``

open MbUnit.Framework
open FsUnit.MbUnit

[<Test>]
let ``should equal within tolerance when less than``() =
    10.09 |> should (equalWithin 0.1) 10.11

[<Test>]
let ``should not equal within tolerance``() =
    10.1 |> should not ((equalWithin 0.001) 10.11)

Now on GitHub:

Last but not least, an FsUnit GitHub site is now available at https://github.com/dmohl/FsUnit. FsUnit has had several contributors with submissions ranging from inception and NUnit implementation by Ray Vernagus, to major and minor enhancements, to examples and documentation. I hope that this move to GitHub will spur additional collaboration. The GitHub site will now act as the primary place for development and collaboration, while the CodePlex site will house major releases. We would love to have additional features and contributors, so jump on over and submit a pull request.

On to the Next One...

We are already working on the next release of FsUnit. Rodrigo Vidal has submitted a few new NUnit assertions--which will be ported to the MbUnit and xUnit.NET implementations where possible. Additionally, there have been discussions of pulling in Phillip Trelford's F# friendly Mocking library.

Where would you like to see FsUnit go? We'd love to hear from you!

Porting Bryan's Erlang Function to F#

2011-12-10T09:18:00.001-08:00

A week or two ago, Fresh Brewed Coder Bryan Hunter posted a video to explain how to debug Erlang apps. In the tutorial, he stepped through a recursive function to display the various concepts. I thought it would be interesting to take that simple example and explore a few ways to write it in F#. Let's start by reviewing Bryan's example (which calculates the average of a provided list of number).

Here's what his average.erl source file looks like:

-module(average).

-export([calculate/1]).

calculate(X) ->
     calculate(X,0,0).

calculate([H|T], Length, Sum) ->
     calculate(T, Length+1, Sum+H);

calculate([], Length, Sum) ->
     Sum/Length.

Porting the Code to F#:

So how would you write this in F#? As with any language, there are several options. A fairly straight forward port might look like this:

let calculate x =
    let rec calc list length sum =
        match list with
        | head :: tail -> calc tail (length+1) (sum+head)
        | [] -> sum/length
    calc x 0 0
printfn "Value is %O" (calculate [10;22])

Breaking it Down:

The above code defines the calculate function that takes a list of integers as a single argument.

Next, a recursive function (the "rec" keyword indicates that it is recursive) named calc is defined (line 2). This function takes a list of integers as the first argument, the current length as the second argument, and the current sum as the last argument.

At the heart of this recursive function is a pattern match against the provided list (line 3). Using something known as the cons pattern, the first pattern (line 4) attempts to decompose the provided list into a "head" (the first element in the list) and "tail" (the rest of the elements).

If the first pattern is a match, the calc function is called with the "tail" list as the first argument, the length value incremented by 1 as the second argument, and the result of the sum value combined with the first value from the list (i.e. the head) as the third argument. This continues until the list is empty, at which point the cons pattern no longer results in a match and the second pattern is evaluated.

By the time the second pattern (line 5) is evaluated, the match will succeed due to the list now being empty. This causes the average to be calculated (i.e. sum/length) and returned.

Line 6 kicks off the initial call to the calc recursive function with the initial list as the first argument and default length and sum values of 0.

Finally, the last line (line 7) kicks off the whole thing with the call to calculate the average of the numbers 10 and 22 (as used in Bryan's demo).

Another Approach:

While the approach above is pretty compact, F# provides a library that contains a high-order function that makes this even easier. The following line of code will also calculate the average of the values in a list of integers:

[10;22] |> List.averageBy (fun number -> float number)

Enhancements to FsUnit (version 0.9.1.1)

2011-12-01T21:21:00.001-08:00

A new version (0.9.1.1) of FsUnit -- a DSL for writing unit tests in F# -- is now available on the NuGet gallery.

This version includes the following improvements:

- Libraries for frameworks 3.5 and 4.0.
- Support for NUnit version 2.5.10.11092.
- Several new functions including: greaterThan, greaterThanOrEqualTo, lessThan, lessThanOrEqualTo, shouldFail, endWith, startWith, and ofExactType.

Examples of the functions mentioned above are shown below:

module FsUnit.``Given a bunch of random tests``

open NUnit.Framework
open FsUnit

[<Test>]
let ``When 11 it should be greater than 10``() =
    11 |> should be (greaterThan 10)

[<Test>]
let ``When 11 it should be greater than or equal to 10``() =
    11 |> should be (greaterThanOrEqualTo 10)

[<Test>]
let ``When 10 it should be less than 11``() =
    10 |> should be (lessThan 11)

[<Test>]
let ``When 10 it should be less than or equal to 11``() =
    10 |> should be (lessThanOrEqualTo 11)

[<Test>]
let ``When an empty List it should fail to contain item``() =
    shouldFail (fun () -> [] |> should contain 1)

[<Test>]
let ``When fsharp it should end with rp``() =
    "fsharp" |> should endWith "rp"

[<Test>]
let ``When fsharp it should start with fs``() =
    "fsharp" |> should startWith "fs"

[<Test>]
let ``When 1 it should be of exact type int``() =
    1 |> should be ofExactType<int>

An example of what this looks like when run in Resharper's Test Runner is shown below:

A Side Note: If you haven't written many tests in F#, the lack of spaces in the test names may surprise you. This is a feature of F# that allows almost any sequence of characters to be enclosed in double-backtick characters (i.e. ``) and consequently treated as an identifier.

I hope you enjoy the latest enhancements to FsUnit. You can find the full source at http://fsunit.codeplex.com/.

Building an ASP.NET MVC 4 Solution with F# and C#

2011-12-01T17:05:00.001-08:00

There is a new project template available on Visual Studio Gallery for creating ASP.NET MVC 4 solutions with F# and C#. The current release of this project template allows creation of an empty ASP.NET MVC 4 web application (either ASPX or Razor), a F# project for controllers/models/etc., and an optional F# project that can be used to contain unit tests. The project creation wizard dialog box is shown below:

In the future, this template will be extended to include at least one additional project type.

To get the template, do the following (Note: Visual Studio 2010/11 Professional (or above) is required to use this template.):

1. In Visual Studio, navigate to File | New and select Online Templates.

2. Search for "fsharp mvc" and select the F# C# MVC 4 project template (see below):

The solution that was used to build this template can be found at https://github.com/dmohl/FsCsMvc4Template.

Getting Setup for JavaScript Testing with Pavlov

2011-11-29T18:48:00.001-08:00

I've talked about testing CoffeeScript with Pavlov in a previous post. Today, I'm going to talk about a couple of ways to quickly get started with Pavlov--a BDD API that sits on top of QUnit--in an ASP.NET web app.

In the past, whenever I wanted to start creating Pavlov specs, I would go out to the Pavlov GitHub site, grab the appropriate files, and add them to my web app. While this process isn't all that time consuming, there is now a better way. Now I can simply install the Pavlov NuGet package using the NuGet Visual Studio Extension. This package adds a folder named Specs under the Scripts folder that includes a barebones html file and pavlov.js.

An example of what the file structure looks like after this package is installed is shown below:

If I prefer to have a simple example to start with, I can alternatively install the Pavlov.Sample package. This adds the same files as the Pavlov package, but also includes an example.specs.js file with the code from the example on the Pavlov GitHub site.

Lastly, I've been writing a fair amount of CoffeeScript lately, so I may prefer to have the sample specs written in CoffeeScript. All that is needed for this is to make sure that Mindscape Web WorkBench Visual Studio Extension is installed (this is a onetime install) and then install the Pavlov.Coffee NuGet package. The files are then added to the project including a example.specs.coffee file that looks like this:

Building F# Solutions in Visual Studio 11

2011-11-24T18:44:00.001-08:00

I love to learn about new technology, seek to continually improve, and always look for ways to make things easier. I then do all that I can to share the knowledge, code, and/or tools that help to achieve these goals. With these goals in mind, I've joined with several friends in the creation of a new blogging community named Fresh Brewed Code. I'd strongly recommend keeping a close eye on the other Fresh Brewed Coders, as they will be producing some awesome content. You can see the announcement at http://freshbrewedcode.com/blog/2011/11/23/welcome-to-fresh-brewed-code/.

One of the other ways that I have attempted to achieve the goals mentioned above is through the creation of a number of Visual Studio project and item templates. Over the last several days, there have been updates to almost all of these templates. In this post I'll describe the changes that have been made--most of which have been implemented to allow support for the Developer Preview of Visual Studio 11 and F# 3.0.

I'm sure that you have used Visual Studio Gallery by now, but just in case you haven't yet had the chance, see http://bloggemdano.blogspot.com/2010/08/f-templates-now-on-visual-studio.html for how to get started. A screenshot of the Online templates view from the Developer Preview of Visual Studio 11 is shown below:

ASP.NET MVC:

F# and C# ASP.NET MVC3 - This project template generates the standard ASP.NET MVC 3 template output with separate projects for the view (ASPX in a C# project) and controllers/models (in a F# project). The latest release (version 1.3) adds support for Visual Studio 11 and F# 3.0. You will need to install the ASP.NET MVC 3 Tools Update (see http://www.asp.net/mvc/mvc3 and make sure to download/install the correct version for Visual Studio 10 or Visual Studio 11) to use this template.

F# C# MVC 3 - This is a dynamic project template that generates an empty ASP.NET MVC 3 solution with separate projects for view (C# - either ASPX or Razor), core (F#), and an optional F# project for unit tests. The template is based on the MSDN Magazine article entitled "Authoring an F#/C# VSIX Project Template" which can be found at http://msdn.microsoft.com/en-us/magazine/hh456399.aspx. You will need to install the ASP.NET MVC 3 Tools Update (see http://www.asp.net/mvc/mvc3 and make sure to download/install the correct version for Visual Studio 10 or Visual Studio 11) to use this template. Version 1.1 adds support for Visual Studio 11 and F# 3.0.

WPF:

F# Windows App (WPF, MVVM) - This project template generates a F# WPF solution with logical separation between View, ViewModel, Model, and Repository. The latest release (version 1.8) resolves a few bugs and adds support for Visual Studio 11 and F# 3.0.

F# and C# Windows App (WPF, MVVM) - This is a project template that generates a WPF solution with separation between View (C#), ViewModel (F#), Model (F#), and Repository (F#). The latest release (version 1.7) resolves a few bugs and adds support for Visual Studio 11 and F# 3.0.

Web Service:

F# and C# Web Service (ASP.NET, WSDL) - This is a project template that generates a Web Service (WSDL) solution with separate projects for web (C#), services (F#), and contracts (F#). The underlying technology is Windows Communication Foundation. Version 1.5 adds support for Visual Studio 11 and F# 3.0.

Silverlight:

F# C# Web App (Silverlight) - This project template generates a Silverlight solution with separate projects for View (C#) and Core (F#). The Core project includes logical separation between ViewModel, Model, and RemoteFacade. You should install the Silverlight 4 developer tools and/or the Silverlight 5 developer tools plus the April 2011 F# CTP. Version 1.2 adds support for Visual Studio 11 and includes a template wizard dialog that allows selection of Silverlight version 4 or 5. The determination of whether to display the wizard dialog is triggered off of the installed F# Silverlight client version. It will only display if both 4 and 5 are installed. Note: There are not yet F# 3.0 Silverlight DLLs. Because of this, the current version only support F# 2.0.

F# Web Application (Silverlight) - This F# project template generates a Silverlight project with logical separation between View, ViewModel, Model, and RemoteFacade. You should install the Silverlight 4 developer tools and/or the Silverlight 5 developer tools plus the April 2011 F# CTP. Version 1.4 adds support for Visual Studio 11 and includes a dialog that allows selection of the desired Silverlight Version 4 or 5 (depending on installations). Note: There are not yet F# 3.0 Silverlight DLLs. Because of this, the current version only support F# 2.0.

F# Empty Web Application (Silverlight) - This project template is similar to the F# Web Application (Silverlight) template; however, it does not include all of the example code. You should install the Silverlight 4 developer tools and/or the Silverlight 5 developer tools plus the April 2011 F# CTP. Version 1.1 adds support for Visual Studio 11, removes the C# host application, adds support to generate an HTML test file, and provides functionality to select the desired Silverlight version 4 or 5 (depending on the installation). Note: There are not yet F# 3.0 Silverlight DLLs. Because of this, the current version only support F# 2.0.

F# 2.0 Silverlight Library (for Visual Studio 11) - This is a project template that generates a F# 2.0 Silverlight project. It targets Visual Studio 11 only and will only be needed temporarily. You can read more about this template at http://bloggemdano.blogspot.com/2011/11/f-silverlight-library-template-in.html. Note: There are not yet F# 3.0 Silverlight DLLs. Because of this, the current version only support F# 2.0.

XAML Item Templates:

F# XAML Item Templates - This Visual Studio Extension provides a number of item templates that make working with F# XAML based projects (i.e. the WPF, Silverlight, and/or Windows Phone 7 project templates) much easier. Without these item templates adding new XAML files to one of these projects is a bit of a pain. You have to create a text or xml file, change the extension to .xaml, manually add the default XAML code, and change the Build Action for the .xaml file to Resource. Version 1.1 adds item templates for Windows Phone 7 (I'll talk more about this in a future post) and adds support for Visual Studio 11.

Project Templates That Do Not Currently Support Visual Studio 11:

Since the Developer Preview of Visual Studio 11 does not currently support Windows Phone 7 development, the Windows Phone 7 templates (i.e. C# WP7 with Caliburn.Micro, F# and C# Win Phone App (Silverlight), F# and C# Win Phone List App (Silverlight), and F# and C# Win Phone Panorama) have not yet been updated to support Visual Studio 11. This will be added as soon as a release of Visual Studio 11 is provided that does include this support.

F# and C# Web App (ASP.NET, MVC 2) - There is not currently an ASP.NET MVC 2 install for Visual Studio 11 and I don't anticipate one to ever be provided. Because of this, I have not (and do not intend to) add support for Visual Studio 11 to this project template.

A Pinch of CoffeeScript Sugar - Part 1

2011-11-15T10:00:00.001-08:00

In this series, I plan to point out and provide a few examples of some cool syntactic sugar provided by CoffeeScript. In this post, I'll talk about destructuring assignment and splats.

I've shown how to write a jQuery plugin in CoffeeScript in a previous post. In the following example, I take that simple jQuery plugin and add a little more sugar.

The above example is based on the recommendations defined in the jQuery Plugins/Authoring documentation. There are a couple of interesting aspects of this code.

Line 10 (i.e. [_, args...] = arguments) is using two cool CoffeeScript features. The first is something called destructuring assignment. This feature allows you to take data from arrays or objects and place that data into something more wieldy. In this case, we are taking the JavaScript arguments object, destructuring it, and assigning all of the arguments except the first one to an array named args. This eliminates the need for me to type Array.prototype.slice.call(arguments, 1). If I had not used a splat (i.e ...), this would have assigned only the second argument to args. Note: Destructuring assignment has been added to JavaScript 1.7.

The second thing of interest on this line (which I've already briefly mentioned) is the use of the splat. The splat allows you to easily work with anything that involves a variable number of arguments. Since line 10 potentially involves more than 2 passed arguments, this is a perfect place to use a splat. As I mentioned before, the use of the splat in this case will generate JavaScript to slice the arguments array i.e. Array.prototype.slice.call(arguments, 1).

Lines 11 and 13 also use a splat, but the reasoning behind its use on these lines is slightly different. While this is still related to a varying number of arguments, it has to do with the passing of those arguments to a function rather than retrieval of the additional argument values. The splat in this case will generate JavaScript that uses the Function.apply method.

A little bit of sugar can make things much sweeter (ug...that was bad). I hope you find this post helpful and that you find lots of uses for the described features.

F# Silverlight Library Template in Visual Studio 11

2011-11-12T09:57:00.001-08:00

If you have played with Visual Studio 11 much, you may have noticed that there isn't a F# Silverlight Library template out-of-the-box. This is presumably due to the fact that the current release of Visual Studio 11 is just a developer preview and there doesn't appear to be a version of F# 3.0 for Silverlight just yet. However, this doesn't stop you from creating Silverlight projects that target F# 2.0 in Visual Studio 11. In order to help you do this, I've created a project template that allows you to create a F# 2.0 Silverlight Library in Visual Studio 11. You can download the VSIX from here.

The following prerequisites exist for using this library:

1. Download and install the VS2011 Preview with F# 3.0 (see http://blogs.msdn.com/b/fsharpteam/archive/2011/09/14/f-3-0-developer-preview-now-available.aspx for more information).

2. Download and install the Microsoft F#, April 2011 CTP from http://www.microsoft.com/download/en/details.aspx?id=11100.

New F# Windows Phone Library Project Template

2011-11-09T14:05:00.000-08:00

There is a new F# Windows Phone Library project template now available on Visual Studio Gallery. This project template allows you to add a new F# library project to a Windows Phone solution rather than having to start with one of the solution templates that is initialized with both a C# and F# project.

As an example, you could easily build the F# and C# Win Phone App (Silverlight) solution by doing the following:

1. Create a new C# Windows Phone Application (Silverlight).
2. Add a new F# Windows Phone Library project to the solution.
3. Add a new XML file to the F# project named MainPage.xaml.
4. Add content to the MainPage.xaml file as shown here (also change the Build Action option to Resource and the Copy to Output Directory option to Copy always).
5. Add the code from here to the File1.fs file.
6. Delete the MainPage.xaml and associated code-behind file from the C# project.
7. Change the App.xaml.cs code in the C# project to what is shown here (Note: You'll likely need to change the namespace).
8. Change the App.xaml code in the C# project to what is shown here (Note: You'll likely need to change the namespace).
9. Edit the properties of the C# project and change the Startup object drop down to the *.AppHost object.
10. Edit the WMAppManifest.xml file and change:

11. Finally, add a reference to the F# project, build, and test.

A Coder Interview with Dan Mohl

2011-11-07T05:13:00.000-08:00

A Coder Interview With Dan Mohl by Terrence Dorsey (@tpdorsey) was recently published in the articles section of The Code Project site. In it, I talk about tools, technology, and frameworks that interest me (F#, CoffeeScript, Node.js, etc.), my background, how the community has influenced my coding, and much more.

You can find the article at http://www.codeproject.com/KB/interviews/Interview-Dan-Mohl.aspx.

Calling F# Libraries from Metro Style Apps

2011-10-30T18:56:00.000-07:00

This weekend, I finally got around to trying to build a polyglot Metro style app (C# front-end + F# back-end). This post will talk about the project file changes that were required and the one outstanding issue that I'm still working. Additionally, a VSIX package is provided that provides the F# Metro Library project template as it exists today.

Note: This approach has only been tested with the simplest of examples.

Getting Setup:

1. In order to create a Metro style app, you need to install Windows 8 Developer Preview with Developer Tools.
2. To also have F#, you'll then need to install Visual Studio 11 Developer Preview.
3. Now create a new C# Windows Metro style application (I chose the Application template).

Adding F#:

If you have installed the VSIX that is linked at the bottom of this post, you can simply add the F# Metro Library, write some code, wire it up, and test. If not, you'll need to add a standard F# Library project and modify the project file.

Modifying the F# Project File:

To allow a F# Library project to be called from a Metro app., the project file must be modified so that it imports the Microsoft.Windows.UI.Xaml.Common.targets. While this small adjustment allows the project to be interacted with, the reference shown in the Metro style project will provide a warning indicating that something isn't quite copacetic. This warning can be eliminated by adding the following elements to the property group:

<TargetFrameworkIdentifier>.NETCore</TargetFrameworkIdentifier><TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Unfortunately, adding these elements causes some sort of conflict with the F# targets, which I am still working to resolve. ~~I have not yet run into an issue (other than the unsightly warning display) that is caused by leaving out these two elements, so for the moment only the common Xaml targets import has been added.~~

Conclusion:

While there is still a lot of work to do, adding the import of the common Xaml targets to the F# project file will allow you to start using F# projects from Metro style apps (Note: In simple cases only--for now). Once the remaining issues are identified and resolved, I'll add the F# Metro Library VSIX to Visual Studio Gallery. Until then, you can find the F# Metro Library VSIX (with the known issues) here.

Two New F# 3.0 Type Provider Related NuGet Packages

2011-10-16T16:25:00.000-07:00

There are two new NuGet packages available that can help you get started with authoring or consuming custom type providers. Both NuGet packages depend on the FSharpx.TypeProviders library that I wrote about in my last post and that Mauricio introduced in his most recent post.

FSharpx.TypeProviders.Sample:

The FSharpx.TypeProviders.Sample package provides an example of how to consume the custom type providers included in the FSharpx.TypeProviders library. The package adds a Test.config file as well as a F# source file that contains example code for using the TypedAppSettings type provider.

FSharpx.TypeProviders.DslSample:

The FSharpx.TypeProviders.DslSample package makes it easy to quickly get started with authoring a custom type provider. The package adds a F# source file that contains the source for a very simple custom type provider, a F# script file that can be used to test the custom type provider, and a batch file that makes it easy to do manual test/debug activities.

You may be curious about the commands in the batch file and why they are needed. Section 5.6 of the document on Writing F# 3.0 Type Providers that was provided by the F# team on 09/24/2011 includes development tips that make this more clear:

5.6.1 Run Two Visual Studio Instances. You can use one Visual Studio to develop the type provider. You can test it in another, since the test IDE will take a lock on the DLL preventing it being rebuilt. Thus, the second instance of Visual Studio must be closed while the provider is built in the first instance, and then reopened.

5.6.2 Debug type providers by using invocations of fsc.exe. Type providers are invoked by

- fsc.exe (The F# Command Line compiler)
- fsi.exe (The F# Interactive compiler)
- devenv.exe (Visual Studio)

Debugging type providers can often be easiest using fsc.exe on a test script file (e.g. script.fsx). This is because

- You can launch debug using a command-line prompt devenv /debugexe fsc.exe script.fsx - You can use print-to-stdout logging

I have tried both approaches and agree that the second is definitely the easiest. The .fsx and .bat files provided in this NuGet package make this approach even easier. Simply modify the code of the type provider, then test/debug by launching the batch file. Note: If/when changes to the Test.fsx file are required, it is recommended that these changes be made in an editor outside of Visual Studio.

Authoring Type Providers with the TypeProviderDSL from FSharpx

2011-10-07T05:03:00.000-07:00

Several days ago, I submitted my AppSettings Type Provider to the FSharpx project. FSharpx is an open source library that adds a number of useful "functional constructs on top of the core F# library". I strongly encourage checking it out.

One of the many things in FSharpx that I find useful is the TypeProviderDSL. This is a DSL that sits on top of the ProvidedTypes module provided in the F# 3.0 Sample Pack. With this DSL and a few other helpers in FSharpx, the code from the AppSettings Type Provider that I showed in a previous post becomes easier to read. Plus, a few lines of code are shaved off in the process.

Let's look at a few of the features of the TypeProviderDSL that are used by the AppSettings Type Provider.

1. The erasedType function provides a simple way to create a ProvidedTypeDefinition.
2. The staticParameter function encapsulates the code needed to define a static parameter.
3. The literalField function makes it slightly easier to create a ProvidedLiteralField.
4. The addXmlDoc function provides a common way to add XML documentation.
5. Lastly, the |+> operator makes it very easy to add members.

Here's the end result:

You can get FSharpx.TypeProviders from the NuGet Gallery at http://www.nuget.org/List/Packages/FSharpx.TypeProviders and find the source on GitHub at https://github.com/fsharp/fsharpx/tree/TypeProviders.

MSDN Magazine Article: Authoring an F#/C# VSIX Project Template

2011-10-03T04:53:00.000-07:00

My MSDN Magazine article entitled Authoring an F#/C# VSIX Project Template is now available in the October 2011 issue of MSDN Magazine.

A big thanks to Elijah Manor, Rick Minerich, and Chris Marinos for reviewing the article!

You can find the online version at http://msdn.microsoft.com/en-us/magazine/hh456399.aspx, the full code samples at http://fsharpmvc3vsix.codeplex.com/, and an enhanced version of the associated VSIX on Visual Studio Gallery at F#/C# ASP.NET MVC 3 Empty Web Application Template (see this previous post for more information about the extension that is available on Visual Studio Gallery).

New F#/C# ASP.NET MVC 3 Template

2011-10-01T17:07:00.000-07:00

There is a new F#/C# ASP.NET MVC 3 template now available on Visual Studio Gallery.

This template requires the ASP.NET MVC 3 Tools Refresh to be installed on the target machine and it provides functionality slightly similar to that which the Tools Refresh adds for C#/VB. Information on installing the ASP.NET MVC 3 Tools Refresh can be found at http://www.asp.net/mvc/mvc3.

With this project template, you will be able to create an empty ASP.NET MVC 3 Web Application. During the creation process, you will see a screen similar to the following with options that allow selection of ASPX or Razor view engine. Additionally, you can optionally choose to include a project which can be used to contain unit tests.

As usual, you can find the full source on my GitHub. Note: This template is an enhanced version of a template that is described in the MSDN Magazine article entitled "Authoring an F#/C# VSIX Project Template". I will be posting something about this article very soon.

A Simple AppSettings Type Provider

2011-09-29T20:58:00.000-07:00

With the F# 3.0 Developer Preview now available, I've been spending a decent chunk of my free time playing with Type Providers. With the announcement of the introductory guide and samples for authoring type providers I've had a hard time putting down the computer to sleep (let alone eat).

After a fair amount of experimentation, I've written my first type provider. It is admittedly quite simple and isn't production quality, but it has been a fun exercise. The basic idea is to read the appSettings elements from a config file, parse the values appropriately, and interact with them in a type safe way.

The sample config file looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings>
        <add key="test2" value="Some Test Value 5"/>
        <add key="TestInt" value="102"/>
        <add key="TestBool" value="True"/>
        <add key="TestDouble" value="10.01"/>
    </appSettings>
</configuration>

Here's the TypeProvider code:

Lastly, here's an example of how to use it.

#r "System"
#r @"bin\debug\AppSettingsTypeProvider.dll"

open System
open AppSettingsTypeProvider

type settings = AppSettings<"App.config">
printfn "Test2 String: %s" settings.test2 
printfn "Test Int: %i" settings.TestInt 
printfn "Test Bool: %b" settings.TestBool  
printfn "Test Double: %f" settings.TestDouble

Presentation: Dialing Up with F# and Windows Phone 7

2011-09-21T17:00:00.000-07:00

A big thanks to Onorio for having me speak for the MIGang FSharp Special Interest Group tonight.

The slides that accompanied this presentation are shown below (use the mouse or the left and right arrow keys to navigate the slides):

Additionally, these slides and the associated examples can be found on my GitHub at https://github.com/dmohl/DialingUpWithFSharpAndWP7_Presentation.

F# Type Providers - Querying StackOverflow

2011-09-16T20:48:00.000-07:00

If you haven't yet heard, the F# 3.0 preview bits were released to the wild a couple of days ago. Congrats to the F# team for this huge accomplishment!

One of the most anticipated features of F# 3.0 is Type Providers. Type Providers make F# the best available option for working in an information-rich world. Even though the preview has only been available for a few days, there is already quite a bit of content covering Type Providers. Here are a few examples:

http://msdn.microsoft.com/en-us/library/hh156509(v=VS.110).aspx
http://blogs.msdn.com/b/fsharpteam/archive/2011/09/14/f-3-0-developer-preview-now-available.aspx
http://fsharp3sample.codeplex.com/

Here's a simple example of querying the StackOverflow OData feed using a Type Provider:

How Do I Get It?

To start playing with F# 3.0, install the VS2011 dev preview and follow any of the step-by-step instructions provided at http://msdn.microsoft.com/en-us/library/hh156509(v=VS.110).aspx.

Advantages of CoffeeScript When Working with jQuery Templates

2011-09-13T18:41:00.000-07:00

Working with jQuery Templates in CoffeeScript is very similar to working with them in JavaScript. However, there are a couple of CoffeeScript features that can make it even easier.

Here's a simple example (based on an example in the jQuery Template documentation):

As you can see, it's pretty similar to its JavaScript counterpart.

How can CoffeeScript make this better?

Enter Heredoc and String Interpolation...

Heredoc: Heredocs allow you to specify multi-line, formatted text. This can be useful when defining the template markup.

With heredocs, the markup from the previous example changes to this:

String Interpolation: CoffeeScript also provides Ruby style string interpolation. Here's an example of the markup after taking advantage of the string interpolation feature (Note: String interpolation only occurs within double-quoted strings and double-quoted heredocs):

Want to see it in action?

Go to http://tinkerbin.com/w0QoscT9, change the JavaScript Format drop down to CoffeeScript, then click the Run button.

WP7 AccelerometerProxy in F#

2011-09-11T19:34:00.000-07:00

With the release of the Windows Phone 7.1 SDK RC, there is now an easy way to use the emulator to simulate sensor data (such as data from the accelerometer). Unfortunately, I'm doing WP7 development in a VM and haven't yet had any luck getting the new SDK functionality to work in that environment.

I am however able to run the emulator using the WP7 Developer Tools RTW, but of course that version did not include functionality to simulate sensor data. There are a couple of options that people have identified for simulating accelerometer data (see Example using a mouse, Example using a Wiimote, Example using external app). For my needs, I decided to go with the mouse-driven approach.

While I could have easily used the C# library from the previously mentioned example, I decided instead to port that example to F#. The result is show here:

You can find the full example at https://github.com/dmohl/FsWP7Accelerometer.

Getting Started with the F# PowerPack - Part 4

2011-09-06T05:36:00.000-07:00

In this series, I'm walking you through various features provided by the F# PowerPack.

Here are the links to the previous posts:

- Part 1
- Part 2
- Part 3

In this post, I'll briefly talk about Lexing, Parsing, SI (Metric) Units of Measure, Physical Constants, and Native Array.

Lexing and Parsing:

The FsLex and FsYacc documentation provides a good overview of how to get started with the lexing and parsing functionality offered by the PowerPack. As mentioned in this documentation, Jomo Fisher's Parsed Language Parser Template provides a great place to start from a code point of view. Note: Lexing and Parsing currently require the F# PowerPack to be installed with the MSI rather than with just the NuGet package.

SI (Metric) Units of Measurement:

Units of Measure are available in F# out-of-the-box (see http://cvslab.di.unipi.it/vslab/blog/post/2011/09/05/Ammeter-interface.aspx for a recent example of this feature in use); however, the PowerPack contains several useful predefined units of measure. Chris Smith speaks of the F# PowerPack in his Programming F# book and SI units of measure is one of the highlighted features. Additionally, Andrew Kennedy has a great post on this topic: http://blogs.msdn.com/b/andrewkennedy/archive/2008/09/02/units-of-measure-in-f-part-two-unit-conversions.aspx.

Here's a list of the SI Units that are provided:

Meter (m), Kilogram (kg), Second (s), Ampere (A), Kelvin (K), Mole (mol), Candela (cd), Hertz (Hz), Newton (N), Pascal (Pa), Joule (J), Watt (W), Coulomb (C), Volt (V), Farad (F), Ohm (ohm), Siemens (S), Weber (Wb), Tesla (T), Henry (H), Lumen (lm), Lux (lx), Becquerel (Bq), Gray (Gy), Sievert (Sv), Katal (kat)

PhysicalConstants:

The PowerPack also comes with a few useful predefined physical constants.

Here's the full list (note: these are basically straight from the code comments):

- Speed of light in vacuum
- Magnetic constant
- Electric constant
- Newtonian constant of gravitation
- Planck constant
- Dirac constant (a.k.a. the reduced Planck constant)
- Elementary charge
- Magnetic flux quantum h/2e
- Conductance quantum
- Electron mass
- Proton mass
- Fine-structure constant
- Rydberg constant
- Avogadro constant
- Faraday constant
- Molar gas constant
- Boltzmann constant R/N_A
- Stefan-Boltzmann constant
- Electron volt
- Unified atomic mass unit

NativeArray:

NativeArray.fs provides several modules and types that can be useful when doing native interop.

The NativeOps and Ref modules provide functions for pinning an object.

The types that are defined include PinnedArray, PinnedArray2, NativeArray, and FortranMatrix. There are a few examples of these types in use in the NativeArrayTests.fs file in the FSharp.PowerPack.Unittests project.

Unit Testing a jQuery Plugin with CoffeeScript and Pavlov

2011-09-01T04:41:00.000-07:00

If you search the web, you'll find a handful of good examples of jQuery plugins written in CoffeeScript, but there seems to be few examples of writing unit tests/specs in CoffeeScript. In this post, I'll show a very simple jQuery plugin with Pavlov specs.

Simple Plugin

This plugin simply wraps the jQuery UI dialog (http://jqueryui.com/demos/dialog/).

do ($ = jQuery) ->
  methods = 
    init: (options) ->
      dialogElement = $(options.dialogSelector)
      dialog = dialogElement.dialog autoOpen: false, modal: true, resizable: false 
      $(options.inputSelector).click -> dialog.dialog 'open'
  
  $.fn.simple = (options) -> 
    settings = dialogSelector:'.dialog', inputSelector:'.input'
    if options 
      $.extend settings, options
    methods.init settings

Pavlov Specs

QUnit is a JavaScript testing framework (learn more about it at http://docs.jquery.com/Qunit) and Pavlov (https://github.com/mmonteleone/pavlov) extends QUnit with several features that promote Behavior-Driven Development (BDD). Here's the example:

pavlov.specify "Simple Plugin", ->
  describe "Given default options", -> 
    before -> $(this).simple()
    describe "when executing a click event", ->
      before -> $('.input').click()
      it "it should open the dialog", ->
        assert($('.dialog').parents('.ui-dialog:visible').length).isTrue()
      after ->
        $('.dialog').dialog('close')
    describe "When the click event has not been executed", ->
      it "it should not have an open dialog", ->
        assert($('.dialog').parents('.ui-dialog:visible').length).isFalse()
      after -> 
        $('.dialog').dialog('close')

  describe "Given all custom options", -> 
    before -> 
      $(this).simple dialogSelector:'.customDialog', inputSelector:'.customInput' 
    describe "when executing a click event", ->
      before -> $('.customInput').click()
      it "it should open the custom dialog", ->
        assert($('.customDialog').parents('.ui-dialog:visible').length).isTrue()
      after ->
        $('.customDialog').dialog('close')

  describe "Given only a custom dialogSelector", -> 
    before -> $(this).simple dialogSelector:'.customDialog'
    describe "when executing a click event", ->
      before -> $('.input').click()
      it "it should open the custom dialog", ->
        assert($('.customDialog').parents('.ui-dialog:visible').length).isTrue()
      after ->
        $('.customDialog').dialog('close')

  describe "Given only a custom inputSelector", -> 
    before -> $(this).simple inputSelector:'.customInput' 
    describe "when executing a click event", ->
      before -> $('.customInput').click()
      it "it should open the dialog", ->
        assert($('.dialog').parents('.ui-dialog:visible').length).isTrue()
      after ->
        $('.dialog').dialog('close')

The Output

Once we have this in place and create a simple test runner page, we end up with the standard QUnit output that looks like the following: