Random Ravings of a Red Headed Code Monkey

Fog 0.1.3.0 Released

2012-05-23T17:09:00.000-07:00

A new release of Fog is now available. The primary enhancement included in this release is support for Windows Azure Caching. Several bug fixes have also been included.

The caching functions are available in the Fog.Caching module. You can use them with code such as the following:

[<DataContract>]
type TestRecord = 
    { [<DataMember>] mutable Id : Guid
      [<DataMember>] mutable Name : string }

let testRecord = { Id = Guid.NewGuid(); Name = "Dan" }

let key = testRecord.Id.ToString()  
Put key testRecord |> ignore

let result = Get<TestRecord> key

Fog is available via NuGet as ID Fog and the full source can be found on my GitHub.

Two Books in the Making

2012-05-20T16:46:00.000-07:00

A few weeks ago I mentioned that my blog has been suffering due to a few other ongoing activities. Today, I'm going to tell you about what I've been working on.

A few months ago I had the opportunity to start working on a few different books:

The first is called jQuery Mobile Cookbook. This book is a collaborative effort between appendTo, O'Reilly, and the jQuery community. The effort is coming along nicely and from what I've seen so far, you're going to love it!

The second is a book on building web, cloud, and mobile solutions with F#. I've partnered with O'Reilly to create this collection of examples, tips, guidance, architectural approaches, functional+OO patterns and practices, and more. Subjects that are expected to be covered include, but are certainly not limited to, ASP.NET MVC 4, ASP.NET Web API, other frameworks for building HTTP services, using F# to build Windows Azure web and worker roles, WebSharper, and Pit.

If there is something that you would really like to see in either of these books, let me know!

Introducing Fog: A Library for Interacting with Azure from F#

2012-05-13T18:59:00.001-07:00

Fog is a library that makes it easier to use F# to interact with Windows Azure through the Windows Azure SDK for .NET. It provides functions for many of the common activities related to table storage, blob storage, and queue storage as well as service bus queues and topics. Provided functions include both course and fined-grained approaches that remove boiler plate code and make it easier to use various functional patterns and techniques. The course grained functions currently use config settings with specific names to allow most operations to only require a single function call.

The syntax of Fog is pretty straight forward. The following examples use the course grained approach. To see how to use the fined-grained functions, which match almost one to one with the Azure SDK for .NET methods, see the Fog integration tests.

Blob Storage

With Fog all you have to do to interact with Azure blob storage is to add the connection string information in the config with a name of "BlobStorageConnectionString". Once that is done, you can use syntax like the following:

UploadBlob "testcontainer" "testblob" "This is a test" |> ignore 
DeleteBlob "testcontainer" "testblob"

UploadBlob "testcontainer" "testblob" testBytes |> ignore 
DownloadBlob<byte[]> "testcontainer" "testblob"

Table Storage

The simplest way to interact with Azure table storage is to add the connection string information in the config with a name of "TableStorageConnectionString". Once that is done, you can use syntax like the following:

[<DataServiceKey("PartitionKey", "RowKey")>] 
type TestClass() = 
    let mutable partitionKey = "" 
    let mutable rowKey = "" 
    let mutable name = "" 
    member x.PartitionKey with get() = partitionKey and set v = partitionKey <- v 
    member x.RowKey with get() = rowKey and set v = rowKey <- v 
    member x.Name with get() = name and set v = name <- v 

let originalClass = 
    TestClass(PartitionKey = "tprt", RowKey = Guid.NewGuid().ToString(), Name = "test") 
CreateEntity "testtable" originalClass |> ignore 

let newClass = originalClass 
newClass.Name <- "test2" 

UpdateEntity "testtable" newClass |> ignore 
DeleteEntity "testtable" newClass

Queue Storage

For queue storage, add the connection string configuration value with setting name "QueueStorageConnectionString".

AddMessage "testqueue" "This is a test message" |> ignore 
let result = GetMessages "testqueue" 20 5 
for m in result do 
    DeleteMessage "testqueue" m

Service Bus

There are a few service bus related config entries. Here's the list of expected names: ServiceBusIssuer, ServiceBusKey, ServiceBusScheme, ServiceBusNamespace, ServiceBusServicePath

To send a message do this:

type TestRecord = { Name : string } 
let testRecord = { Name = "test" } 

SendMessage "testQueue" testRecord

To receive a message, pass the queue name, a function to handle successful message retrieval, and another function to handle errors.

HandleMessages "testQueue" 
    <| fun m -> printfn "%s" m.GetBody<TestRecord>().Name
    <| fun ex m -> raise ex

To use topics in a pub/sub type of scenario, use something like the following to subscribe:

Subscribe "topictest2" "AllTopics4" 
    <| fun m -> printfn "%s" m.GetBody<TestRecord>().Name 
    <| fun ex m -> raise ex

Message publishing can be accomplished like this:

Publish "topictest2" testRecord

A few other handy functions include Unsubscribe and DeleteTopic:

Unsubscribe "topictest2" "AllTopics4" 
DeleteTopic "topictest2"

How to get it

The easiest way to get Fog is to install the Fog NuGet package. You can also find the full source as well as integration tests on the Fog GitHub site.

F#, MSTest, and FsUnit 1.1.0.0

2012-04-23T05:12:00.001-07:00

I've been very busy with a few side projects that I plan to talk more about soon. Sadly, my blog has suffered due to these other activities, but I wanted to take a few minutes to talk about a new MSTest project template available on Visual Studio Gallery as well as some activity going on with FsUnit.

MSTest Project Template:

In the first week of March I released a new project template that helps in the creation of unit tests with MSTest and VS11. You can find it at http://visualstudiogallery.msdn.microsoft.com/51ebe64a-899b-4959-8c24-b0148ed6b264 or by searching for "fsharp mstest" in the Visual Studio Gallery online templates.

FsUnit:

FsUnit has also had a few enhancements.

1. Support for MsTest has been added for VS11 and made available through a new NuGet package named Fs30Unit.MsTest.

2. A few new assertions have been added for NUnit including NaN, instanceOfType, and unique.

3. FsUnit has long supported a function named "not". While this is a nice feature, the fact that it overwrites an F# operator is not ideal. Because of this, version 1.1.0.0 renames this function to not'. For the purpose of backward compatibility, you can open the module named FsUnitDepricated to make the "not" function available.

One last thing. If you're using FsUnit with NUnit, MbUnit, or xUnit in VS11 Beta, you will need to add binding redirects from previous versions of FSharp.Core to version 4.3.0.0. The easiest way to do this is to use the Add-BindingRedirect PowerShell cmdlet provided by NuGet (http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference). Here are the steps:

1. After installing one of the FsUnit NuGet packages, create an App.config file (if one doesn't already exist).

2. In the NuGet Package Manager Console, run the following command "Add-BindingRedirect projectname" after replacing projectname with the name of your test project.

A Nice Addition to the Empty WPF F# Template

2012-03-26T04:48:00.000-07:00

A few days ago Steffen Formann announced a Xaml type provider that he and Johann Deneux have created that makes writing WPF apps in F# very easy. This type provider allows strongly typed access to the XAML, effectively providing the missing piece to allowing full F# WPF designer support. I've now updated the Empty WPF F# Template to include this type provider.

To use it, all you have to due is download/install the latest version of the F# Empty Windows App (WPF) template in VS11. This will generate an F# project with all the needed WPF assembly references. It also automatically installs the FSharpx.TypeProviders NuGet package and provides the starting point for creating WPF apps with the new Xaml type provider.

Here's a screenshot that's pretty similar to what Steffen showed in the announcement post. Note: The button and label were manually added after creating the project from the updated template.

One other piece that can be helpful when creating WPF apps in F# is the XAML related item templates (i.e. Page, User Control, Window, etc). Item templates are provided via the F# XAML Item Templates extension found at http://visualstudiogallery.msdn.microsoft.com/06c6ece1-2084-4083-a0f7-934fce9d22fb.

Presentation - CoffeeScript: Good, Bold, and with Sugar

2012-03-17T04:56:00.001-07:00

Thanks to all who came out to my talk yesterday at Code PaLOUsa. As mentioned, the slides for the presentation are provided below. You can find the slides + examples at https://github.com/dmohl/CoffeeScriptGoodBoldAndWithSugar and navigate the deck at Slides

F# and ASP.NET Web API

2012-03-05T04:42:00.000-08:00

A few weeks ago the ASP.NET team announced the release of ASP.NET MVC 4 Beta. You can read about it here. One of the exciting features that was announced is ASP.NET Web API. ASP.NET Web API provides an excellent programming model for building HTTP services.

One of the sweet spots for F# is in the services layer and this makes ASP.NET Web API + F# great friends. To make it easy to get started with F# and ASP.NET Web API, I've added an ASP.NET Web API template to the already existing F#/C# ASP.NET MVC 4 Visual Studio extension. Note: The template requires that ASP.NET MVC 4 Beta is installed.

To install the template, do the following:

1. Launch the project creation wizard (Ctrl+Shift+N), select Online in the left hand nav, search for "fsharp mvc4", and click OK. In VS11 Beta, it looks something like the following. Note: It may take a few seconds to download.

2. After clicking OK and installing the extension, you will see a dialog that allows the creation of a new ASP.NET Web API solution with an F# project that contains the server-side code.

3. Once the project has been created, you can run it however you desire and hit the service via http://localhost:###/api/values.

Razor Added to the F#/C# ASP.NET MVC 3 Internet Project Template

2012-02-27T04:54:00.000-08:00

There's a new version of the F#/C# ASP.NET MVC 3 internet Project Template. This version allows you to choose between the ASPX and Razor view engines.

Here's how to use it:

1. Install version 1.6+ of the project template by searching for it on Visual Studio Gallery and/or updating a version that you had previously installed.

2. Create a new project.

3. You will now see a dialog box similar to what is shown below:

While it's certainly not required in order to use this template, you can see the full source on my GitHub.

ExpectThat with CoffeeScript, Zombie, Mocha, and Node

2012-02-20T05:01:00.000-08:00

A few posts ago, I showed how to use ExpectThat with Mocha and Node.js. Today, I'll show a simple example of using ExpectThat with Zombie.js--a full-stack testing framework.

Zombie.js

Zombie.js is a fast, headless testing framework that provides various functionality to write tests that hit your full technology stack. While I generally prefer to write more fine-grained, isolated tests, it's important to also have a few smoke tests and/or integration tests to verify end-to-end functionality. Zombie makes these kinds of tests easy, while allowing me to still use ExpectThat and Mocha.

The Example

Here's a simple example that populates two input elements and then verifies that the values of those input fields contain the expected text.

You can find the full example here.

After a few commands such as " coffee --output lib/ specs/ " and " mocha 'lib/example.spec.js' --reporter spec ", you should see an output that looks something like this:

To learn more about ExpectThat, visit https://github.com/dmohl/expectThat.

Another Way To Kick-start F# WPF Apps

2012-02-06T04:54:00.000-08:00

Over the last few years I've announced a number of project templates that are available on Visual Studio Gallery. A few of these have provided ways to kick-start F# WPF apps. I talked about one of these templates here. While these are nice for getting acquainted with building WPF apps in F# and/or F#+C#, the files needed for the included sample app may become a bother once you have a few of these apps under your belt. Because of this, I've released an F# only Empty WPF project template (an F#/C# Empty WPF template will likely be coming soon).

To get the new template, do the following:

1. In Visual Studio 2010 or 11, navigate to File -> New and select Online Templates (or just Online if using VS11).

2. Search for "Daniel Mohl" or "F# Empty Windows App" as shown below:

3. Select the template, click OK, and agree to the install.

While it's certainly not required to use the template, you can find the full source on my GitHub.

Testing a jQuery Plugin with ExpectThat and Mocha

2012-01-30T04:15:00.000-08:00

A couple of weeks ago, I announced a CoffeeScript/JavaScript assertion library called ExpectThat. In this post, I'll provide a more real-world example of how ExpectThat can be used. For this example, I'll be using the jQuery plugin and tests from one of Josh Bush's posts entitled "Testing jQuery Plugins with Node.js and Jasmine".

The jQuery plugin

The code that follows is a re-write (in CoffeeScript) of the simple jQuery plugin that Josh provided in his post.

This jQuery plugin provides a basic watermark type of feature for an input box.

The specs

Since Josh has already done the work of writing the specs for this jQuery plugin, all that I need to do is port this to CoffeeScript and add in ExpectThat. To mix things up a bit, I've chosen to use Mocha instead of Jasmine (though ExpectThat works just as well for Jasmine). For simplicity, I've combined the spec files from Josh's post.

Apples to apples

Here's a quick before and after comparison (with both examples in CoffeeScript):

Before ExpectThat:

    describe "when calling placeholder plugin", ->
      it "should show placeholder value", ->
        expect(input.val()).toEqual("foo")

After ExpectThat:

    describe "when calling placeholder plugin", ->
      expectThat -> input.val().should equal "foo"

Josh's tests are already very readable, but by adding ExpectThat, I'm able to eliminate 1 line from every test and allow each to be self-documenting.

An example of the result of running the specs in the browser is shown below:

Wait, what about Node?

"So", you say, "this is great, but Josh's post was all about using the same code and specs from the browser in Node.js". Ah, yes, thanks for reminding me. It's pretty simple to run these same specs in Node.

Here are the steps:

1. Use NPM to install mocha at a global level (i.e. npm install mocha -g) then install jsdom, jquery, and expectThat.mocha at the local level (i.e. npm install <package name>).

2. Create a file called runspecs.coffee with the code shown below and compile it however you choose (i.e. "coffee --compile --output lib/ specs/").

3. Run the tests with a command such as "mocha 'lib/runspecs.js' --reporter spec" and you should see something like the following:

In future posts, I'll show how to do similar testing with other tools such as Jasmine-Node and Zombie.js. To learn more about ExpectThat, get involved, and/or keep an eye on its progress, go to https://github.com/dmohl/expectThat.

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.