Random Ravings of a Red Headed Code Monkey

F# Firestarter in Nashville, TN on 11/14/2009

2009-11-09T11:01:00.000-08:00

Checkout the upcoming F# Firestarter in Nashville, TN on 11/14/2009. It's going to be a great day of learning, exploring, hacking, and socializing.
We would very much like to launch a functional programming user's group out of this event, so come on out and share your thoughts and insights. You won't want to miss it.

You can register for the event at http://fsharpfirestarter.eventbrite.com/.

More information can be found at http://fsharpfirestarter.blogspot.com/.

Development Principles and Standards

2009-10-01T17:52:00.000-07:00

Several months ago I was asked to lead a fairly large development project that involved efforts from multiple consultant and offshore development groups. One of the first things that I did was draft a development principles and standards document to ensure that all groups were on the same page. The following is a slightly revised version of that document. This information is not new or extremly profound; however, I thought it might be beneficial to some.

Development Principles and Standards

There are several core principles and standards that are essential to the development of any solution. These principles and standards are necessary to ensure maintainability of the solution as well as successful, cost effective implementations of future customers that wish to take advantage of the product offering.

Reusability

Reusability is of prime importance as it relates to the development of the different aspects of a solution. The expectation is that all system functionality should be constructed so that new customers can be setup within the solution with no development. In addition, all functionality should be constructed in a manner that allows other systems to be able to interact with the solution with no internal system development.

Extensibility and Maintainability

There are multiple principles that should be followed to increase the extensibility and maintainability of the solution.

• Separation of Concerns (SoC) - This generally implies separation of UI, service, domain, and data access/persistence layers as well as abstraction of contracts/interfaces from implementation specifics. This allows for clear delineation of functionality and ensures that any type of updates to the solution can be accomplished quickly and with little to no unexpected ramifications.

• Single Responsibility Principle (SRP) – This principle states that each component, class, method, and/or function should only be responsible for a single piece of functionality. Another way to state this is that each distinct code block should only have a single reason to change. This reduces the potential for accidently causing an unexpected consequence when modifying a particular feature or piece of functionality.

• Don’t Repeat Yourself (DRY) – In order to make a solution extensible and maintainable, code and/or logic should not be duplicated. Failure to adhere to this principle increases both development time and the likelihood of errors.

• Self Documented Code – In order for a solution to be maintainable, it must be very easy to determine the intent of any specific piece of code. One of the best ways to accomplish this goal is to ensure that all code is as descriptive as possible by using identifier, method, function, and class names that clearly define intent.

Automated Tests and Testability

Functionality should be wrapped in automated tests. Ideally the solution would be developed using a test-first approach; however, it is acceptable to utilize a test-after approach as long as the majority of functionality is under test by the time of delivery. In addition to the “unit tests” (tests around each individual method), functional tests should be written to ensure that the overall behavior works as expected. Finally, all tests should be maintained during future development endeavors and run before “check-in” and before each deployment. These tests accomplish multiple goals:

1. They provide a form of documentation that shows the intent of the functionality and/or specific class/method.

2. They provide a quick regression testing strategy that allows confidence that any future code changes do not have unexpected, adverse ramifications.

3. A test-first approach has a general side-effect of a loosely coupled, highly cohesive, maintainable, and testable solution that greatly increases agility and significantly decreases bugs.

Consistency and Unity

The code should be consistent and unified. It should appear as though a single mind developed each bounded context. This can be accomplished by following various coding standards. It is important to point out that this relates to each bounded context and not the project as a whole. For example, any UI development should have a unified and consistent coding style. Likewise, any service/domain development should have a unified and consistent coding style (even if this style differs slightly from the UI development coding style). Conventions that promote consistency pertain to the standardization of layering, naming conventions, and consistent use of idioms. One great way to help ensure that these agreed upon standards are followed is to utilize a tool such as FxCop during development.

Versioning and Service Contract Management

In order for a system to be extensible, while continuing to support existing customers and functionality, a service contract versioning strategy must be followed. It is critical that unaffected consumers of the exposed services are not required to update/deploy changes to their systems every time that a modification/addition is implemented. This means that existing service contracts should only be modified when a non-breaking change is implemented (such as the addition of a new operation). It also implies that changes at the domain level should not automatically be propagated to the service layer (note: One strategy to prevent this issue is through the use of the DTO pattern). In the event of a required breaking-change, the service contract should be versioned using an agreed upon versioning strategy, while keeping everything as agnostic, reusable, and maintainable as possible.

Composability

The functionality exposed in the solution should be composable and expressive of agnostic logic. This means that the web services should be built as general services, which allow current business requirements to be met while allowing reusability for future consumers and/or business needs. This indicates that web services should rarely, if ever, be designed to support only a single client, consumer, or application.

Atomicity

The solution’s web services and functionality should be atomic. This means that all activity that occurs during the lifecycle of a service operation should be rolled back in the event of a failure. This ensures that the outcome of the operation is consistent with either a cancellation in conjunction with an error or a successful outcome with the expected response.

Fine-Granularity versus Course-Granularity

The solution should implement course-grained web services that act as a thin wrapper around a fine-grained domain model. The high level of abstraction provided by the web service interfaces allow consumers to depend on the exposed contract and receive maximum performance benefits associated with the course-grained services. The fine-grained domain model allows the solution to change whenever the business requires by providing maximum flexibility, while limiting chage to the interface(s) on which the consumers depend.

Logging and Error Handling

A logging strategy should be consistently utilized throughout the development of the overall solution. At a minimum, this strategy should include the logging of any user initiated action. Additionally, the ideal strategy should including logging at a method/function level indicating entry and exit of each specific method/function. An ideal approach to accomplishing this functionality, while still adhering to the DRY principle, is to utilize an Aspect Oriented Programming (AOP) approach (Note: A great example of a framework to help with this approach for C# development is PostSharp.) Finally, the verbosity of the logged information must be configurable during run-time. A collection of possible error codes and associated descriptions should be documented and made available for delivery to consumers. In addition, all errors should be logged in a persistent and searchable data store.

F# - Asynchronous Directory.GetFiles and File.Copy

2009-08-30T20:59:00.000-07:00

The Problem:
My wife recently decided to take on the task of ordering family photo albums. This primarily involved wading through the deluge of digital photos that have been piling up over the last three years, selecting the photos that were worthy to be placed in the album, uploading those photos to a certain web site, organizing the photos in the albums, and finally making the purchase. The particular imaging software, that was used to import/organize/modify the photos, stores the images in a directory structure that looks something like this ..\<Main Directory>\<Year>\<Month>\<Day>. While this would not normally be an issue, it made the task of uploading the images to the photo album creation site quite arduous.

This of course is a simple problem to solve in most programming languages. The following examples show how it could be solved with F# both synchronously and asynchronously. While this is definitely not production ready, it provides a few samples of how asynchronous workflows can be used in the wild.

The Synchronous Way:
(Note: A sleep statement has been added to emphasize the speed difference between the synchronous/asynchronous approaches.)

open System.IO
let destinationDirectory = @"C:\temp\picDest\"
let sourceDirectoryRoot = @"C:\temp\pic"
let searchPattern = @"*.jpg";
let getFileName sourceFile = FileInfo(sourceFile).Name
let getSourceImages = Directory.GetFiles(sourceDirectoryRoot, searchPattern, 
                          SearchOption.AllDirectories)
let getDestinationFileName sourceFile destinationDirectory = 
    destinationDirectory + getFileName sourceFile
let copyImage sourceFile destinationDirectory = 
    File.Copy(sourceFile, getDestinationFileName sourceFile destinationDirectory, true) 
    |> ignore  

do printfn 
    "Starting the image consolidation process with base directory: %s" sourceDirectoryRoot
for image in getSourceImages do
    System.Threading.Thread.Sleep(5000)
    do printfn "[.NET Thread %d] %s" System.Threading.Thread.CurrentThread.ManagedThreadId image
    copyImage image destinationDirectory
do printfn "The images have been consolidated into directory %s." destinationDirectory
do printfn "Press [Enter] close this command prompt." 
System.Console.ReadKey() |> ignore

The Asynchronous Way:
(Note: A sleep statement has been added to emphasize the speed difference between the synchronous/asynchronous approaches.)

open System
open System.IO

type Directory with
    static member AsyncGetFiles(path:string, searchPattern:string, searchOption:SearchOption) = 
        let fn = new Func <string * string * SearchOption, string[]>(Directory.GetFiles)    
        Async.BuildPrimitive((path, searchPattern, searchOption), fn.BeginInvoke, fn.EndInvoke)
type File with
    static member AsyncCopy(sourceFile:string, destinationFile:string, overwrite:bool) = 
        let fn = new Func<string * string * bool, unit>(File.Copy)
        Async.BuildPrimitive((sourceFile, destinationFile, overwrite), fn.BeginInvoke, fn.EndInvoke)   

let destinationDirectory = @"C:\temp\picDest\"
let sourceDirectoryRoot = @"C:\temp\pic"
let searchPattern = @"*.jpg";
let getFileName sourceFile = FileInfo(sourceFile).Name
let getSourceImages imageDirectory searchPattern searchOption = 
    async { return! Directory.AsyncGetFiles(imageDirectory, searchPattern, 
                searchOption) }
let getDestinationFileName sourceFile destinationDirectory = 
    destinationDirectory + getFileName sourceFile
let copyImage sourceFile destinationDirectory overwrite = 
    async {
        System.Threading.Thread.Sleep(5000)
        do printfn 
            "[.NET Thread %d] %s" Threading.Thread.CurrentThread.ManagedThreadId sourceFile
        return! File.AsyncCopy(sourceFile, 
            getDestinationFileName sourceFile destinationDirectory, overwrite) }

do printfn 
    "Starting the image consolidation process with base directory: %s" 
    sourceDirectoryRoot

let sourceImages = 
    getSourceImages sourceDirectoryRoot searchPattern SearchOption.AllDirectories
    |> Async.RunSynchronously

for image in sourceImages do
    copyImage image destinationDirectory true
    |> Async.Start
       
do printfn 
    "The images will be consolidated into the following directory: %s" destinationDirectory 
System.Console.ReadKey() |> ignore

CodeStock 2009 - The C# Developer's Guide to F#

2009-06-26T19:23:00.000-07:00

Thanks to all who came out to my session today at CodeStock 2009. The slide deck and code samples are provided below:

- Slide Deck
- F# Survey Provider Sample
- F# Script Samples

CodeStock 2009 Session: The C# Developers Guide to F#

2009-05-17T19:02:00.000-07:00

The CodeStock 2009 speakers/sessions were announced today and I am honored to say that I will be providing a session entitled "The C# Developers Guide to F#". Thanks to all who voted for this session and I can't wait to see you all there!

Upcoming Developer Events/Conferences

2009-03-24T17:10:00.000-07:00

There are several upcoming developer events/conferences of which I want to make sure that everyone is aware.

April 11 (tentative) - F# Fire Starter - Nashville, TN

This is going to be a great event full of presentations, demonstrations, pair programming, and open spaces. It's open to all levels of developers with all levels of F# experience. I'll be providing more information as it becomes available.

June 26-27 - CodeStock 2009 - Knoxvillle, TN

This is a great event where Open Spaces are mixed with a traditional conference. The cost is just $25 and registration will open on or after March 31st.

August 13-15 - devLink 2009 - Nashville, TN

DevLink features over 75 sessions of technical content intended to make you more knowledgeable and marketable. Registration opens April 1st and the early bird cost is $75. Note: This conference sells out every year, so get your ticket early!

Presentation: An Introduction to F# - Slides and Sample Code

2009-03-20T06:13:00.000-07:00

Thanks to all who came out to the Nashville .NET User Group last night. As promised, here are the slides and examples.

Click here for a zipped file containing the slides and sample script.

Click here for a zipped file containing the source code of the sample application.

Sample F# Application - A Simple Quiz Provider

2009-03-17T19:50:00.000-07:00

One of the things that we will be discussing at the Nashville .NET User Group Tomorrow night, March 19, 2009, is a sample application that has a service layer built in F#. To access the sample code click here.

A few notes:

- The code is broken out into two main layers: Service and Presentation.

- The service layer is built in F# and the presentation layer is build in C# with ASP.NET MVC RC1.

- The tests are written in C# (even in the service layer) to provide examples of language interoperability.

- To keep things as simple as possible, the data is stored in an XML file rather than a database. All interaction with the data is through Linq to XML.

- The intent of this example is to help existing object-oriented developers ease into the language. Because of this, many functional programming approaches are not utilized to the full extent.

- This uses the F# Sept. 2008 CTP.

F# Presentation at the Nashville .NET User Group

2009-03-16T18:43:00.000-07:00

I will be providing a presentation at the Nashville .NET User Group this Thursday, March 19, 2009. Here's the information:

Presentation: "An Introduction to F#"

Abstract :

What is F#? Why should you care? What advantages can F# provide for real world developers?

In this presentation we will answer these questions, cover the basic syntax of F#, and explore a sample F# line-of-business application.

Building a RESTful Service with WCF and F#

2009-01-18T11:56:00.000-08:00

There has been a lot of discussion recently, centered on the idea of making services RESTful. REST (Representational State Transfer) "is a key design idiom that embraces a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URLs." (1) This post will provide a simple example of creating a RESTful service with WCF and F#.

Creating the project:

The first step in building our example is to create a new F# Library project. I chose to name this project "FSharpWCF". The next step is to add references to System.Runtime.Serialization, System.ServiceModel, and System.ServiceModel.Web.

Building the contracts:

The code looks only slightly different than an equivalent in a language such as C#, though there are a couple of key things that should be pointed out. First, System.ServiceModel.Web has been opened. This is the namespace that allows us to use the WebGet attribute. The WebGet attribute allows us to set a UriTemplate that will be used for navigation to our service. Our UriTemplate is set to "temp/{value}", which indicates that navigating to the base URL/temp/{value} will return the result of the service. {value} associates directly with the parameter named value in our GetData operation. The last important thing to notice is the assignment of the name "value" to the request argument of the GetData operation (i.e. abstract GetData : value:string -> string). For more information on this, see this post by Ted Neward.

#light
namespace FSharpWCF

open System
open System.Runtime.Serialization
open System.ServiceModel
open System.ServiceModel.Web

[<ServiceContract>]
type IGetDataService = interface 
    [<WebGet(UriTemplate="temp/{value}")>]
    [<OperationContract>]
    abstract GetData : value:string -> string
end

type GetDataService() = 
    interface IGetDataService with
        member this.GetData value =
            sprintf "You entered: %s" value

Adding an app.config file:

Since an F# library doesn't have App.config as an option when adding a new item, you will need to create the file in the project directory manually, then add it as an existing item. The main thing to notice is the addition of the endpointBehaviors section and the association of this behaviorConfiguration to the endpoint.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="FSharpWCF.GetDataService" behaviorConfiguration="FSharpWCF.GetDataServiceBehavior">
        <host>
          <baseAddresses>
            <add baseAddress = "http://localhost:8080/FSharpWCF/GetDataService/" />
          </baseAddresses>
        </host>
        <endpoint binding="webHttpBinding" contract="FSharpWCF.IGetDataService" 
                  behaviorConfiguration="Web">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="FSharpWCF.GetDataServiceBehavior">
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
      <endpointBehaviors>
        <behavior name="Web">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Testing the service:

To test your new service, do the following:

1. Right click on the FSharpWCF project and select properties.
2. Navigate to the Debug tab, change the start action to "Start external program:" and locate the WcfSvcHost.exe on your development machine (i.e. C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\WcfSvcHost.exe).
3. Add the following "command line arguments:" /service:FSharpWCF.dll /config:FSharpWCF.dll.config
4. Set "Working directory:" to the directory of these DLLs.

You should now be able to launch the service by running the project from Visual Studio. This will host your service with WcfSvcHost and allow you to access your service from a browser. (Note: WcfSvcHost should only be used for testing purposes. You should never use this as a production host.)

To use the service, open a browser and navigate to http://localhost:8080/FSharpWCF/GetDataService/temp/2 and you should receive <string>You entered: 2</string> as a result.

Conclusion:

That's all there is to it. The service can now be viewed as a resource that can be identified by it's URL.

Resources:

1. http://java.sun.com/developer/technicalArticles/WebServices/restful/

Object Mocking in F# with Rhino Mocks

2008-12-20T14:17:00.000-08:00

Near the end of Oct. 2008, I posted an entry entitled Mocking F#. While that post may be helpful to some, others may be looking for an example of how to dynamically mock objects from tests written in F#. This post will attempt to provide that example. In addition, it will provide another example of a BDD approach using some of the functionality in SpecUnit (a previous example is here).

Since the types being tested have not changed from those provided in the Mocking F# post, I will not be re-posting them here.

#light
namespace FSharpMockExample.Services.Specs
open FSharpMockExample.Services
open FSharpMockExample.Entities
open FSharpMockExample.Data
open NUnit.Framework
open SpecUnit
open Rhino.Mocks

[<TestFixture>]
[<Concern("Customer Balance Calculation")>]
type behaves_like_context_with_customer_balance_calculation() = 
    inherit ContextSpecification()
    [<DefaultValue(false)>]
    val mutable customerService : ICustomerService
    [<DefaultValue(false)>]
    val mutable mocks : MockRepository
    override this.Context () = 
        this.mocks <- new MockRepository()
        ignore None

[<TestFixture>]
[<Concern("Customer Balance Calculation")>]
type When_calculating_balance_with_starting_balance_of_fifty_and_ten_percent_discount() = 
    inherit behaves_like_context_with_customer_balance_calculation()
    override this.Because () = 
        this.mocks <- new MockRepository()
        let cAgs = [||]
        let customerDao = this.mocks.DynamicMock<ICustomerDao>(cAgs)
        let customer = new Customer(1, "XYZ Company", 50.00M)
        Expect.Call(customerDao.GetById(1)).Return(customer) |> ignore
        this.customerService <- new CustomerService(customerDao) 
    [<Observation>]
    member this.should_have_a_calculated_balance_of_forty_five() = 
        this.mocks.ReplayAll();
        this.customerService.CalculateBalaceWithDiscount(1, 0.1M).ShouldEqual(45M) |> ignore
        this.mocks.VerifyAll();

Behavior Driven Development (BDD) in F# with SpecUnit .NET

2008-12-10T06:50:00.000-08:00

BDD Overview:

Behavior Driven Development (BDD) is a process that evolved from Test Driven Development (TDD). The differences are subtle and primarily focus on removing communication related confusion (Dan North-the founder of BDD-provides a nice introduction here). http://behaviour-driven.org/ describes BDD as a convergence of TDD and Domain-Driven Design (DDD) - (A good introduction to DDD can be found on Hanselminutes show #140 with Rob Conery). One of the foundations of DDD is the concept of removing complexity by creating a common language to help bridge the gap between business and technology . This common language is known as the ubiquitous language.

The first thing that BDD does to help accomplish the goal of a ubiquitous language is remove the central focus on "tests". Generally, when the word "Test" is mentioned to a business minded person, they will immediately think about a quality assurance process that is situated near the end of a project plan. By changing the termonology from "Test" to "Specification", the focus changes to something done near the beginning of the project plan that defines and drives the development of the solution. This small focal shift can make a big difference in how the project is driven.

BDD also has advantages for developers. When specifications are documented in code, that code is more likely to accomplish the business goals, be easier to understand, and be much more maintainable over the life of the solution. In addition, the specifications written to drive the development can then be used to prove that the final product meets all of the business requirements.

There are many additional benefits to BDD. For additional information, check out http://behaviour-driven.org/.

BDD in F#:

After reading Starting with BDD vs. TDD, I decided to checkout SpecUnit .NET. I pulled down the sample application (i.e. Banking) and did a quick and dirty port to F#.

Specification:

#light
namespace BankingFSharp.Specs
open NUnit.Framework
open SpecUnit
open BankingFSharp

[<TestFixture>]
[<Concern("funds transfer")>]
type behaves_like_context_with_from_account_and_to_account() = 
    inherit ContextSpecification()
    [<DefaultValue(false)>]
    val mutable fromAccount : Account
    [<DefaultValue(false)>]
    val mutable toAccount : Account
    override this.Context () = 
        this.fromAccount <- new Account(1m) 
        this.toAccount <- new Account(1m) 
        ignore None

[<Concern("funds transfer")>]
type when_transferring_between_two_accounts() = 
    inherit behaves_like_context_with_from_account_and_to_account()
    override this.Because () = 
        this.fromAccount.Transfer(1m, this.toAccount) |> ignore
    [<Observation>]    
    member this.should_debit_the_from_account_by_the_amount_transferred () =  
        this.fromAccount.Balance.ShouldEqual(0m) |> ignore
    [<Observation>]    
    member this.should_credit_the_to_account_by_the_amount_transferred () =  
        this.toAccount.Balance.ShouldEqual(2m) |> ignore

Code:

#light
namespace BankingFSharp
open System

type Account = class
  val mutable balance: decimal;
  new (balance) = {balance = balance}
  member this.Balance
      with get() = this.balance and set(v) = this.balance <- v
  member this.Transfer (amount,toAccount:Account) = 
      if amount > this.balance then
           let errorMessage = String.Format("Cannot transfer ${0}. The available balance is ${1}.", amount, this.balance)
           failwith errorMessage
      else   
          this.Balance <- this.balance - amount
          toAccount.Balance <- toAccount.Balance + amount
end

Result:

When NUnit was opened, it was exciting to see how much of the story was now being conveyed through the tests. While this is not completely ubiquitous, the output (i.e. " when transferring between two accounts" "should create the to account by the account transferred") is pretty close to what one would see in a requirements document.

Conclusion:

BDD is a positive step toward closing the gap between business and technology. Tools such as SpecUnit .NET make this process easier and it was refreshing to see out of the box support for F#. As more developers start to see the benefits of TDD and BDD, we will see the infamous divide between business and technology finally start to close.

Best F# Blogs and Feeds

2008-12-06T09:55:00.000-08:00

Here is list of some of the best blogs and feeds that often contain F# related content.

- http://blogs.msdn.com/dsyme/
- http://tomasp.net/blog/
- http://strangelights.com/blog/
- http://weblogs.asp.net/podwysocki/default.aspx
- http://feeds.feedburner.com/planet_fsharp
- http://lorgonblog.spaces.live.com/blog/
- http://blogs.msdn.com/lukeh/
- http://fsharpnews.blogspot.com/
- http://blogs.msdn.com/chrsmith/
- http://www.atrevido.net/blog/
- http://blogs.msdn.com/andrewkennedy/
- http://blogs.tedneward.com/
- http://www.pandamonial.com/

If you have other favorites, please post a comment with a link.

Using MSTest With F#

2008-11-29T11:38:00.000-08:00

Before creating this blog entry, I had always written tests against my F# projects in C#. I prefer this approach because it helps ensure optimal interoperability between the F# libraries and other .NET languages. However, it was always assumed that the tests could just as easily have been written in F#. While this assumption is accurate for some of the available unit testing frameworks, it is not correct for the MSTest framework.

This post will focus on my attempt to identify a convenient method of creating F# test fixtures using the MSTest unit testing framework. The following links provide examples using other unit testing frameworks (NUnit, FsTest library for xUnit).

Creating My First F# MSTest Test Fixture:

To create the MSTest test fixture, a new F# library project was created and a reference was added to Microsoft.VisualStudio.QualityTools.UnitTestFramework. Figure 1 shows the very simple MSTest test fixture.

Figure 1

#light
namespace FSharpTests
open Microsoft.VisualStudio.TestTools.UnitTesting

[<TestClass>]
type FSharpTestsInFSharp = class
    [<testmethod>]
    member this.FSharpTests_CanGetCustomerByIdFromDB =
       Assert.IsTrue(1=1)
end

This code compiled without issue and all seemed well until Ctrl+R,A was used to run all of the tests in the solution. The Test Results screen appeared and all of the C# TestFixtures were represented (the new F# project was added to an existing solution, which contained a C# test project); however, my new fixture was no where to be seen.

Off to the Command Line:

This was very puzzling, so I decided to dig a little deeper by launching the test from the command line. Figure 2 displays the basic syntax used (note: The actual location of the test project has been replaced with <project location>). This test resulted in a message stating "No tests to execute".

Figure 2:

MSTest.exe /testcontainer:"<project location="">\bin\Debug\FSharpSpecifications.dll"

Now to MSIL:

To get a better idea of what was going on, I typed ildasm, opened FSharpSpecifications.dll, and dumped all of the IL code to an ANSI file named FSharpSpecifications.il. After several minutes of review, it was discovered that though the TestMethodAttribute is defined in the property instance, it is not defined in the method instance. Figure 3 displays the original IL along with the new line that allows MSTest to locate the test (note: The actual location of the test project has been replaced with <project location>).

Figure 3

//  Microsoft (R) .NET Framework IL Disassembler.  Version 3.5.30729.1
//  Copyright (c) Microsoft Corporation.  All rights reserved.
// Metadata version: v2.0.50727
.assembly extern /*23000001*/ mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
}
.assembly extern /*23000002*/ FSharp.Core
{
  .publickeytoken = (A1 90 89 B1 C7 4D 08 09 )                         // .....M..
  .ver 1:9:6:2
}
.assembly extern /*23000003*/ Microsoft.VisualStudio.QualityTools.UnitTestFramework
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 9:0:0:0
}
.assembly /*20000001*/ FSharpSpecifications
{
  .custom /*0C000003:0A000001*/ instance void [FSharp.Core/*23000002*/]Microsoft.FSharp.Core.FSharpInterfaceDataVersionAttribute/*01000002*/::.ctor(int32,
                                                                                                                                                    int32,
                                                                                                                                                    int32) /* 0A000001 */ = ( 01 00 01 00 00 00 09 00 00 00 06 00 00 00 00 00 ) 

  // --- The following custom attribute is added automatically, do not uncomment -------
  //  .custom /*0C000004:0A000002*/ instance void [mscorlib/*23000001*/]System.Diagnostics.DebuggableAttribute/*01000003*/::.ctor(valuetype [mscorlib/*23000001*/]System.Diagnostics.DebuggableAttribute/*01000003*//DebuggingModes/*01000004*/) /* 0A000002 */ = ( 01 00 01 01 00 00 00 00 ) 

  .hash algorithm 0x00008004
  .ver 0:0:0:0
}
.mresource /*28000001*/ public FSharpSignatureData.FSharpSpecifications
{
  // Offset: 0x00000000 Length: 0x000003E2
  // WARNING: managed resource file FSharpSignatureData.FSharpSpecifications created
}
.mresource /*28000002*/ public FSharpOptimizationData.FSharpSpecifications
{
  // Offset: 0x000003E8 Length: 0x000000CE
  // WARNING: managed resource file FSharpOptimizationData.FSharpSpecifications created
}
.module 'F#-Module-FSharpSpecifications'
// MVID: {492AF409-0E8B-9CF0-A745-038309F42A49}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x00000001    //  ILONLY
// Image base: 0x01140000

// =============== CLASS MEMBERS DECLARATION ===================

.class /*02000002*/ public auto ansi serializable beforefieldinit FSharpTests.FSharpTestsInFSharp
       extends [mscorlib/*23000001*/]System.Object/*01000001*/
{
  .custom /*0C000005:0A000006*/ instance void [Microsoft.VisualStudio.QualityTools.UnitTestFramework/*23000003*/]Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute/*01000008*/::.ctor() /* 0A000006 */ = ( 01 00 00 00 ) 
  .custom /*0C000006:0A000007*/ instance void [FSharp.Core/*23000002*/]Microsoft.FSharp.Core.CompilationMappingAttribute/*01000009*/::.ctor(valuetype [FSharp.Core/*23000002*/]Microsoft.FSharp.Core.SourceConstructFlags/*0100000A*/) /* 0A000007 */ = ( 01 00 03 00 00 00 00 00 ) 
  .method /*06000001*/ public specialname rtspecialname 
          instance void  .ctor() cil managed
  // SIG: 20 00 01
  {
    // Method begins at RVA 0x2050
    // Code size       10 (0xa)
    .maxstack  3
    .language '{AF046CD3-D0E1-11D2-977C-00A0C9B4D50C}', '{994B45C4-E6E9-11D2-903F-00C04FA302A1}', '{5A869D0B-6611-11D3-BD2A-0000F80849BD}'
// Source File '<project location>\CustomerDaoTests.fs' 
    .line 31,31 : 13,15 '<project location>\CustomerDaoTests.fs'
//000031:     new() = {}
    IL_0000:  /* 02   |                  */ ldarg.0
    IL_0001:  /* 28   | (0A)000004       */ call       instance void [mscorlib/*23000001*/]System.Object/*01000001*/::.ctor() /* 0A000004 */
    IL_0006:  /* 02   |                  */ ldarg.0
    IL_0007:  /* 26   |                  */ pop
    IL_0008:  /* 00   |                  */ nop
    IL_0009:  /* 2A   |                  */ ret
  } // end of method FSharpTestsInFSharp::.ctor

  .method /*06000002*/ public instance void 
          get_FSharpTests_CanGetCustomerByIdFromDB() cil managed
  // SIG: 20 00 01
  {
    // Method begins at RVA 0x2068
    // Code size       13 (0xd)
    // This is the new line
    .custom /*0C000002:0A000003*/ instance void [Microsoft.VisualStudio.QualityTools.UnitTestFramework/*23000003*/]Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute/*01000006*/::.ctor() /* 0A000003 */ = ( 01 00 00 00 ) 
    .maxstack  4
    .line 39,39 : 9,27 ''
//000032:     [<TestMethod>]
//000033:     member this.FSharpTests_CanGetCustomerByIdFromDB = 
//000034: //        let customerDao = new CustomerDao() :> ICustomerDao
//000035: //        let customer = customerDao.GetByIdFromDB(2)
//000036: //        Assert.IsTrue(customer.Id = int(2))
//000037: //        Assert.IsTrue(customer.Name = "AABB, Inc")
//000038: //        Assert.IsTrue(customer.Balance = 29M)
//000039:         Assert.IsTrue(1=1)
    IL_0000:  /* 00   |                  */ nop
    IL_0001:  /* 17   |                  */ ldc.i4.1
    IL_0002:  /* 17   |                  */ ldc.i4.1
    IL_0003:  /* FE01 |                  */ ceq
    IL_0005:  /* FE14 |                  */ tail.
    IL_0007:  /* 28   | (0A)000005       */ call       void [Microsoft.VisualStudio.QualityTools.UnitTestFramework/*23000003*/]Microsoft.VisualStudio.TestTools.UnitTesting.Assert/*01000007*/::IsTrue(bool) /* 0A000005 */
    IL_000c:  /* 2A   |                  */ ret
  } // end of method FSharpTestsInFSharp::get_FSharpTests_CanGetCustomerByIdFromDB

  .property /*17000001*/ instance class [FSharp.Core/*23000002*/]Microsoft.FSharp.Core.Unit/*01000005*/
          FSharpTests_CanGetCustomerByIdFromDB()
  {
    .custom /*0C000002:0A000003*/ instance void [Microsoft.VisualStudio.QualityTools.UnitTestFramework/*23000003*/]Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute/*01000006*/::.ctor() /* 0A000003 */ = ( 01 00 00 00 ) 
    .get instance void FSharpTests.FSharpTestsInFSharp/*02000002*/::get_FSharpTests_CanGetCustomerByIdFromDB() /* 06000002 */
  } // end of property FSharpTestsInFSharp::FSharpTests_CanGetCustomerByIdFromDB
} // end of class FSharpTests.FSharpTestsInFSharp

.class /*02000003*/ private abstract auto ansi sealed beforefieldinit '<StartupCode$FSharpSpecifications>'.$CustomerDaoTests
       extends [mscorlib/*23000001*/]System.Object/*01000001*/
{
  .field /*04000001*/ static assembly native int _init
  .custom /*0C000001:0A000008*/ instance void [mscorlib/*23000001*/]System.Runtime.CompilerServices.CompilerGeneratedAttribute/*0100000B*/::.ctor() /* 0A000008 */ = ( 01 00 00 00 ) 
} // end of class '<StartupCode$FSharpSpecifications>'.$CustomerDaoTests

.class /*02000004*/ private abstract auto ansi sealed beforefieldinit '<PrivateImplementationDetails$FSharpSpecifications>'
       extends [mscorlib/*23000001*/]System.Object/*01000001*/
{
} // end of class '<PrivateImplementationDetails$FSharpSpecifications>'


// =============================================================

// *********** DISASSEMBLY COMPLETE ***********************

Running the Tests From the Altered DLL:

With the new line added to the IL file, I created a new dll using the command specificed in Figure 4 (note: The actual location of the test project has been replaced with <project location>), then ran the test using the command specified in Figure 2. This time the test was identified and successfully run.

Figure 4

ilasm "<project location>\FSharpSpecifications.il" /DLL

Conclusion:

The point of this little experiment was to find a convenient way to implement test fixtures in F# using the MSTest unit testing framework. Unfortunately, this goal was not reached, though a certain level of success was achieved. It is likely that full support will be provided when F# is officially shipped with VS, but until that time we can always continue to create F# test fixtures in NUnit/xUnit or use my prefered approach and write the tests in C#.

F# Tools and Libraries

2008-11-21T05:02:00.000-08:00

Since F# is still in infancy, the number of associated tools and libraries is minimal when compared to more mature languages. However, the list is growing and will continue to increase as more and more developers get introduced to the language.

The following, is a list of tools and libraries compiled through various Google searches. Since the line is sometimes blurred between a tool/library, I have generally relied upon the author's description to determine the correct category.

Tools:

fsunit - This is a testing (a.k.a. specifications) framework written in F# for F#.
F# SyntaxHighlighter Brush - This is an add on to SyntaxHighlighter, which allows F# code to be posted on a web page and displayed as it would in Visual Studio.
FS Web Tools - This is a set of tools to "author homogeneous client/server/database web applications".
AbsIL SDK - Allows manipulation of .NET files and binaries.
F# MPI Tools - This is a message passing interface (MPI) tool that can be used to develop distributed memory applications.
FsCheck - This is "a tool for testing F# code automatically".
PDF Toolkit - This is a command line tool that allows manipulation of PDF files.
fsc.exe - This is the compiler that comes with the F# CTP.
fsi.exe - This is the interactive tool that comes with the F# CTP.
fslex.exe - This is a tool used to create lexical analyzers that comes with the F# CTP.
fsyacc.exe - This is a tool used to create parsers that comes with the F# CTP.

Libraries:

STM for F# - This is a software transactional memory (STM) library for F#.
FParsec - This is an F# parser combinator library ported from Haskell.
Parallel Extensions Library - This library is not specific to F#, but lends itself nicely to the "immutable by default" approach. It provides "a managed programming model for data parallelism, task parallelism, and coordination on parallel hardware unified by a common work scheduler".

Conclusion:

One of the major advantages that F# has over other functional programming languages is the .NET framework. This allows almost any .NET tool/library to be compatible with F#. In addition, a number of tools/libraries have been created specifically with F# in mind and that number will continue to increase. Feel free to leave a comment linking to those that I have missed.

Linq to SQL in F#

2008-11-15T11:31:00.000-08:00

In the entry titled Linq to XML in F#, I walked through an example of how to use Linq to XML in F# to retrieve customer information from an XML file. In this post, I will show how this same functionality can be achieved with a database using the "experimental" Linq to SQL (a.k.a. FLinq) support found in FSharp.Powerpack.FLinq.dll that was released in the Sept. 2008 CTP. Don Syme states that this "is labelled experimental because some advanced SQL concepts are not yet handled (e.g. left-outer-joins)" (post by Don - Note: This post also contains several FLinq examples).

Path to Completion:
Since basic Separation of Concern (SoC) concepts were originally applied, only the data access layer will need to be updated to support the change from an XML repository to a SQL repository.

The following steps will need to be completed to accomplish this goal:
1. Create the test.
2. Create the database.
3. Generate the object model.
4. Implement the functionality.

Creating the Test:

This test is going to be similar to that which was written for the Linq to XML example. It will simply retrieve a customer object based on a specified Customer id. For example purposes only, I will be adding these methods/functions into the same projects that were created in the Linq to XML example.

        
[TestMethod]
public void CanGetCustomerByIdFromDB()
{   
    FSharpMockExample.Data.ICustomerDao customerDao = new FSharpMockExample.Data.CustomerDao();   
    FSharpMockExample.Entities.ICustomer customer = customerDao.GetByIdFromDB(2);      
    Assert.AreEqual(customer.Id, 2);   
    Assert.AreEqual(customer.Name, "AABB, Inc");        
    Assert.AreEqual(customer.Balance, 30);
}

Creating the Database:

The database for this example is very simple with a single table that contains three fields.

Here are the steps that were followed to create the database using the SQL Server 2005 Express Edition:

1. Create a database called FSharpSample.
2. Run the following script to create the table:

USE [FSharpSample]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[Customers](
    [CustomerId] [int] NOT NULL,
    [Name] [varchar](50) NOT NULL,
    [Balance] [decimal](18, 2) NOT NULL, CONSTRAINT [PK_Customers] PRIMARY KEY CLUSTERED (    [CustomerId] ASC)
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) 
ON [PRIMARY]) ON [PRIMARY]
GO
SET ANSI_PADDING OFF

3. Populate the table with the following script:

USE [FSharpSample]
GO
INSERT INTO dbo.Customers (CustomerId, Name, Balance)VALUES (1, 'ABC Company', 20.00)
INSERT INTO dbo.Customers (CustomerId, Name, Balance)VALUES (2, 'AABB, Inc', 30.00)
GO

Generating the Object Model:

The object model is generated using the code generation tool called SqlMetal.exe, which is often found in c:\program files\Microsoft SDKS\Windows\v6.0A\bin\. Since SqlMetal.exe does not yet support F#, the object model is generated in C#.

There are a lot of ways to generate the object model; however, for this specific example I did the following:

1. Open a command prompt and navigate to c:\program files\Microsoft SDKS\Windows\v6.0A\bin\.
2. Execute the following command: sqlmetal /server:".\SQLEXPRESS" /database:FSharpSample /namespace:FSharpSample /code:FSharpSampleDB.cs /language:csharp
3. This generates a file called FSharpSampleDB.cs and places it in the c:\program files\Microsoft SDKS\Windows\v6.0A\bin\ directory.
4. Create a new CSharp Class Library project within the solution and add FSharpSampleDB.cs to it.
5. Build the new project.

On to the F# Code:

The first step that is needed to support FLinq in a project is to add references to System.Data, System.Data.Linq, and FSharp.PowerPack.Linq. After that, it is simply a matter of adding a new member to the CustomerDao class.

Signature File:

The only change to the CustomerDao signature file is the addition of one new abstract member.

#light
namespace FSharpMockExample.Data
open FSharpMockExample.Entities
open System.Xml.Linq

type ICustomerDao = interface
    abstract GetById: int -> ICustomer
    abstract GetById: XElement * int -> ICustomer
    abstract GetByIdFromDB: int -> ICustomer
end

type CustomerDao = class
    new: unit -> CustomerDao
    interface ICustomerDao
end

Source File:

The first thing that should be noticed is the #nowarn "57" compiler directive. Since FLinq is still in the "experimental" phase, this directive is necessary to suppress the related warning. Next, you'll notice that the Microsoft.FSharp.Linq and FSharpSampleDB namespaces have been opened. The rest of the work is in the GetByIdFromDB member.

Here's a description of the GetByIdFromDB member:

1. The first identifier is set to the database connection string (note: This is hard coded for example purposes only. Normally the value would be stored in a config file.)
2. The second identifier is set to a new instance of the DataContext.
3. Finally we build and execute a Linq Query Expression. There are a few interesting things that should be noticed. First, the quoted expression identified by "<@" and "@>". These quotations cause the compiler to treat the syntax within them in a special way. Second, the Seq.hd function causes only the first element to be returned. Finally, the resulting object is cast to the ICustomerDao interface.

#light
#nowarn "57"
namespace FSharpMockExample.Data
open FSharpMockExample.Entities
open System.Xml.Linq
open Microsoft.FSharp.Linq
open FSharpSampleDB

module XLinqHelper = 
    let GetXName xname = XName.op_Implicit(xname)

type ICustomerDao = interface
    abstract GetById: int -> ICustomer
    abstract GetById: XElement * int -> ICustomer
    abstract GetByIdFromDB: int -> ICustomer
end

type CustomerDao = class
    new()={}
    interface ICustomerDao with
        member this.GetById id =
            let rawXml = "removed from this sample"
            let thisInterface = (this :> ICustomerDao)
            let xml = XElement.Parse rawXml
            thisInterface.GetById (xml, id)

        member this.GetById (xml, id) =
            let GetCustomer (customerElement:XElement) = 
                new Customer(int(customerElement.Attribute(XLinqHelper.GetXName "Id").Value), 
                    customerElement.Attribute(XLinqHelper.GetXName "Name").Value, 
                    decimal(customerElement.Attribute(XLinqHelper.GetXName "Balance").Value)) :> ICustomer

            xml.Elements() |> Seq.find(fun customer -> (int(customer.Attribute(XLinqHelper.GetXName "Id").Value) = id)) 
                           |> GetCustomer
        member this.GetByIdFromDB id =
            let connString = @"Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=FSharpSample;Data Source=.\SQLEXPRESS"

            let db = new FSharpSampleDB(connString)

            Query.query <@ seq { for c in db.Customers do
                                 if id = c.CustomerId then
                                     yield (new Customer(c.CustomerId, c.Name, c.Balance))} 
                   |> Seq.hd @> :> ICustomer

end

Conclusion:

With the help of Flinq and some basic SoC principles, switching our data access layer from an XML repository to a SQL repository is trivial. While Flinq is not yet ready for production, full support is likely in the not too distant future. With Flinq, the future looks bright!

Great F# Resources

2008-11-13T06:00:00.000-08:00

For those of you interested in F#, here are some great resources worth checking out.

- HubFS - Here you will find forums, announcements, and many other resources. Don Syme is often spotted here answering questions and posting examples.
- Don Syme's Blog - This is the blog of the creator of F# and one of the authors of the book Expert F#.
- Robert Pickering's Blog - Author of the book Foundations of F# and recent guest on Hansel Minutes show #76
- Ted Neward's Blog - Ted was recently on DNR show #377 discussing F# with Amanda Laucher. They are currently working on a book.
- Amanda Laucher's Blog
- Real World Functional Programming by Tomas Petricek
- F# MSDN Developer Center - This site has several great resources to get you started including links to the latest release, free chapters of Expert F#, announcements, and specification documentation.
- Examples on CodePlex - Contains links to additional resources including several listed on this blog entry.
- Matthew Podwysocki's blog - Contains great content and examples.

If you know of other great resources, let me know!

Linq to XML in F#

2008-11-08T07:12:00.000-08:00

Last week in the entry titled "Mocking F#", we walked through the creation of a customer service implementation in F# and explored how a dynamic mock object framework can be used to help quickly drive development with tests. In that entry, we implemented a DAO (Data Access Object) that simply creates a dummy customer class . This blog entry will focus on adding functionality to that CustomerDao class so that it retrieves the data from an XML file using Linq to XML.

First, Add References:

The first step that we must do is add a reference to System.Xml and System.Xml.Linq in both the test project and the F# project.

The C# Tests:

The goal of these tests is to verify that a specific customer can be retrieved from the XML source. Method "CanGetCustomerById" retrieves the customer from the actual XML source (which in this case is hard coded into the GetById member, but could have easily been retrieved from a file or database). Method "CanGetCustomerByIdWithXmlProvided" creates a fake XElement and passes it to the function for test purposes.

        
[TestMethod]
public void CanGetCustomerById()
{
    FSharpMockExample.Data.ICustomerDao customerDao = new  FSharpMockExample.Data.CustomerDao();
    FSharpMockExample.Entities.ICustomer customer = customerDao.GetById(1);
    Assert.AreEqual(customer.Id, 1);
    Assert.AreEqual(customer.Name, "ABC Company");
    Assert.AreEqual(customer.Balance, 20);
}

[TestMethod]
public void CanGetCustomerByIdWithXmlProvided()
{
    XElement xElement =
        new XElement("c",
            new XElement("Customer",
                new XAttribute("Id", "1"),
                new XAttribute("Name", "ABC Company"),
                new XAttribute("Balance", "20.00")),
            new XElement("Customer",
                new XAttribute("Id", "2"),
                new XAttribute("Name", "AABB, Inc"),
                new XAttribute("Balance", "30.00")));
    FSharpMockExample.Data.ICustomerDao customerDao = new FSharpMockExample.Data.CustomerDao();
    FSharpMockExample.Entities.ICustomer customer = customerDao.GetById(xElement, 2);
    Assert.AreEqual(customer.Id, 2);
    Assert.AreEqual(customer.Name, "AABB, Inc");
    Assert.AreEqual(customer.Balance, 30);
}

The F# Signature File:

The signature file looks very similar to that which was created during the last entry. The main difference is a new overloaded GetById function, which contains a tuple (a tuple is common F# data structure used to group data types) of type "XElement * int". Since XElement is used, we must also open System.Xml.Linq.

#light
namespace FSharpMockExample.Data
open FSharpMockExample.Entities
open System.Xml.Linq

type ICustomerDao = interface
    abstract GetById: int -> ICustomer
    abstract GetById: XElement * int -> ICustomer
end

type CustomerDao = class
    new: unit -> CustomerDao
    interface ICustomerDao
end

The F# Source File:

Most of the changes are found in this file. The first thing that an astute reader might notice is the XLinqHelper module. Modules provide a way to group and reuse identifiers and functions. The CustomerDao class encapsulates the majority of the changes. Member GetById xml retrieves, and in this sample actually creates, the source xml. It then casts the current class to the ICustomerDao interface, parses the raw xml into an XElement and calls the overloaded GetById XElement*int member. The overloaded GetById XElement*int member uses the Seq library to find the customer by the specified CustomerId, news up a customer object, casts it to an ICustomer, and finally returns the result.

#light
namespace FSharpMockExample.Data
open FSharpMockExample.Entities
open System.Xml.Linq

module XLinqHelper = 
    let GetXName xname = XName.op_Implicit(xname)

type ICustomerDao = interface
    abstract GetById: int -> ICustomer
    abstract GetById: XElement * int -> ICustomer
end

type CustomerDao = class
    new()={}
    interface ICustomerDao with
        member this.GetById id =
            let rawXml = "<Customers>
                              <Customer Id=\"1\" Name=\"ABC Company\" Balance=\"20.00\"/>
                              <Customer Id=\"2\" Name=\"AABB, Inc\" Balance=\"30.00\"/>
                          </Customers>"
            let thisInterface = (this :> ICustomerDao)
            let xml = XElement.Parse rawXml
            thisInterface.GetById (xml, id)

        member this.GetById (xml, id) =
            let GetCustomer (customerElement:XElement) = 
                new Customer(int(customerElement.Attribute(XLinqHelper.GetXName "Id").Value), 
                    customerElement.Attribute(XLinqHelper.GetXName "Name").Value, 
                    decimal(customerElement.Attribute(XLinqHelper.GetXName "Balance").Value)) :> ICustomer

            xml.Elements() |> Seq.find(fun customer -> (int(customer.Attribute(XLinqHelper.GetXName "Id").Value) = id)) 
                           |> GetCustomer
end

Conclusion:

As you can see from the example, adding basic data access functionality using Linq to XML is pretty easy. With the help of the Seq library and System.Xml.Linq, the possibilities of XML data manipulation are endless.

A special thanks goes out to Elijah Manor for adding F# support to Syntax Higherlighter. Very cool Elijah!!

Mocking F#

2008-10-31T13:27:00.001-07:00

The intent of this entry is to show how to do TDD (Test Driven Development) in F# with the help of a dynamic mock object framework such as RhinoMocks. Along the way, we will explore how to implement an object oriented design in F# with features including namespaces, classes, interfaces, properties, and members. This example includes several best practices, but is by no means production ready. Most specifically, it is missing error handling and validation. In addition, certain patterns and practices have been intentionally ignored in order to make the example a little easier to understand.

This is an implementation of a simplified customer service that might exist in any standard LOB (Line of Business) application. In the end, we have a service that allows the current balance of a customer to be returned with a specified discount applied.

As always, we write the tests first (Note: As is my usual style, the tests are in C# and the code is in F#):

C# Customer Entity Test:

[TestMethod]
public void CanCreateCustomer()
{
    FSharpMockExample.Entities.ICustomer customer = new FSharpMockExample.Entities.Customer(1, "ABC, Corp.", 20);
    Assert.AreEqual(customer.Id, 1);
    Assert.AreEqual(customer.Name, "ABC, Corp.");
}

[TestMethod]
public void CanCalculateBalanceWith10PercentDiscount()
{
    FSharpMockExample.Entities.ICustomer customer = new   FSharpMockExample.Entities.Customer(1, "ABC, Corp.", 20);
    decimal newBalance = customer.CalculateBalanceWithDiscount(.1M);
    Assert.AreEqual(newBalance, 18);
}

F# Customer Entity:

Signature File:

#light
namespace FSharpMockExample.Entities

type ICustomer = interface
    abstract Id: int with get
    abstract Name: string with get
    abstract CalculateBalanceWithDiscount: decimal -> decimal
end

type Customer = class
    new: int*string*decimal -> Customer
    interface ICustomer 
end

Source File:

#light
namespace FSharpMockExample.Entities

type ICustomer = interface
    abstract Id: int with get
    abstract Name: string with get
    abstract CalculateBalanceWithDiscount: decimal -> decimal
end

type Customer = class
    val id: int
    val name: string
    val balance: decimal
    new(id, name, balance) = 
        {id = id; name = name; balance = balance}
    interface ICustomer with
        member this.Id 
            with get () = this.id
        member this.Name
            with get () = this.name
        member this.CalculateBalanceWithDiscount discount =
            this.balance - (discount * this.balance)
    end
end

C# Customer Data Access Object Test:

[TestMethod]
public void CanGetCustomerById()
{
    FSharpMockExample.Data.ICustomerDao customerDao = new FSharpMockExample.Data.CustomerDao();
    FSharpMockExample.Entities.ICustomer customer = customerDao.GetById(1);
    Assert.AreEqual(customer.Id, 1);
    Assert.AreEqual(customer.Name, "ABC Company");
}

F# Customer Data Access Object:

Signature File:

#light
namespace FSharpMockExample.Data
open FSharpMockExample.Entities

type ICustomerDao = interface
    abstract GetById: int -> ICustomer
end

type CustomerDao = class
    new: unit -> CustomerDao
    interface ICustomerDao
end

Source File:

#light
namespace FSharpMockExample.Data
open FSharpMockExample.Entities

type ICustomerDao = interface
    abstract GetById: int -> ICustomer
end

type CustomerDao = class
    new()={}
    interface ICustomerDao with
        member this.GetById id =
            new Customer(id, "ABC Company", 20.00M) :> ICustomer
end

C# Customer Service Test:

[TestMethod]
public void CanCalculateBalance()
{
    var mocks = new MockRepository();
    var customerDao = mocks.CreateMock<FSharpMockExample.Data.ICustomerDao>();
    FSharpMockExample.Entities.ICustomer customer = new FSharpMockExample.Entities.Customer(1, "XYZ Company", 50);

    using (mocks.Record())
    {
        Expect.Call(customerDao.GetById(1)).IgnoreArguments().Return(customer);
    }

    using (mocks.Playback())
    {
        int customerId = 1;
        decimal discount = .1M;
        FSharpMockExample.Services.ICustomerService customerService = new FSharpMockExample.Services.CustomerService(customerDao);
        var balanceWithDiscount = customerService.CalculateBalaceWithDiscount(customerId, discount);

        Assert.AreEqual(balanceWithDiscount, 45);
    }
}

F# Customer Service:

Signature File:

#light
namespace FSharpMockExample.Services
open FSharpMockExample.Data
open FSharpMockExample.Entities

type ICustomerService = interface
    abstract CalculateBalaceWithDiscount: int*decimal -> decimal
end

type CustomerService = class
    new: unit -> CustomerService
    new: ICustomerDao -> CustomerService 
end

Source File:

#light
namespace FSharpMockExample.Services
open FSharpMockExample.Data
open FSharpMockExample.Entities

type ICustomerService = interface
    abstract CalculateBalaceWithDiscount: int*decimal -> decimal
end

type CustomerService = class
    val customerDao: ICustomerDao
    new (customerDao) = 
        {customerDao = customerDao}
    new () = 
        {customerDao = new CustomerDao()}
    interface ICustomerService with
        member this.CalculateBalaceWithDiscount (customerId, discount) =
            let customer = 
                this.customerDao.GetById(customerId)
            customer.CalculateBalanceWithDiscount(discount)    
    end
end

Hopefully, this example will inspire you to go out an give this amazing language a try.

F# Seq Module

2008-10-25T22:21:00.000-07:00

Many of the features that make F# so powerful, are the modules that make up the FSLib library. One of my favorites is the Seq module which can be found in Microsoft.FSharp.Collections namespace.

This simple example demonstrates how to use the "sum" function of the Seq module. In this example, four integers are added together. The result is then squared.

Note: I have chosen to write these sample tests in C# to help emphasis the interoperability of the languages. These tests could have just as easily been written in F#. For examples of this, check out the book Expert F#.

Test:

[TestMethod]
public void CanCalculateSeqExample()
{
List<int> numbersToCalculate = new List<int>();
numbersToCalculate.Add(1);
numbersToCalculate.Add(2);
numbersToCalculate.Add(3);
numbersToCalculate.Add(4);
int result = FSharpSample.CalculateSeqExample(numbersToCalculate);

Assert.AreEqual(result, 100);
}

.fs File:

#light
let CalculateNumberSquared x = x*x

let CalculateSeqExample args =
Seq.sum args |> CalculateNumberSquared

.fsi File:

#light
val CalculateNumberSquared: int -> int

val CalculateSeqExample: seq -> int

Explanation:

While this example is very simple, it provides a brief view into the power that some of these modules provides. This example also shows how functions can be chained together. The astute observer will have noticed the "|>" operator in the CalculateSeqExample function. This operator is known as the pipe-forward or forward operator. It allows the result of the preceding function to be forwarded on to the next function in the chain.

Comparing MSIL of F# Versus C#

2008-10-18T11:58:00.000-07:00

Comparing MSIL:

To get a good understanding of what is going on "under the covers" of our example from last week, a person can view the generated MSIL (Microsoft Intermediate Language). While there are several options for doing this, I chose to use Reflector.

Here's a review of the F# code as well as the C# equivalent:

F#:

Test:

[TestMethod]
public void CanCalculateNumberSquared()
{
int result = FSharpSample.CalculateNumberSquared(2);
Assert.AreEqual(result, 4)
}

Code:

#light
let CalculateNumberSquared x = x*x;;

Here's the C# code.

Test:

[TestMethod]
public void CanCalculateNumberSquaredInCSharp()
{
CSharpSample.CSharpSample cSharpSample = new CSharpSample.CSharpSample();
int result = CSharpSample.CalculateNumberSquared(2);
Assert.AreEqual(result, 4);
}

Code:

public class CSharpSample
{
public int CalculateNumberSquared(int numberToSquare)
{
return numberToSquare * numberToSquare;
}
}

Here is the managed code with comments explaining what is happening:

C#:

.method public hidebysig instance int32 CalculateNumberSquared(int32 numberToSquare) cil managed {     
.maxstack 2 // maximum number of elements that can be pushed to the valuation stack
.locals init (
[0] int32 CS$1$0000) // this is a local variable of type int32    
L_0000: nop // do nothing -- indicates compiled in debug mode
L_0001: ldarg.1 // push argument 1 onto the stack     
L_0002: ldarg.1 // push argument 1 onto the stack (multiplying a number by itself)    
L_0003: mul // multiply values
L_0004: stloc.0 // pop a value from the stack into a local variable 
L_0005: br.s L_0007 // go to labl L_0007
L_0007: ldloc.0 // push local variable at index 0 onto the stack
L_0008: ret // return the value from the stack (if there is one) and return from the method
}

F#:

.method public static int32 CalculateNumberSquared(int32 x) cil managed {     
.maxstack 4 // maximum number of elements that can be pushed to the valuation stack
L_0000: nop // do nothing -- indicates compiled in debug mode
L_0001: ldarg.0 // push argument 0 onto the stack     
L_0002: ldarg.0 // push argument 0 onto the stack     
L_0003: mul // multiply values
L_0004: ret // return the value from the stack (if there is one) and return from the method
}

This first thing that I noticed when comparing the managed code from each example, was that
the F# code is more succinct. Each is accomplishing the same goal, but the CIL generated from
F# is five lines less that that which was generated from the C# example. The second thing I
noticed was that the F# method is static while the C# method is not. To ensure that we are
comparing apples to apples, a new static method was generated in the C# example.

Here's the code:

Test:

[TestMethod]

public void CanStaticCalculateNumberSquaredInCSharp()

{
int result = CSharpSample.StaticCSharpSample.CalculateNumberSquared(2);
Assert.AreEqual(result, 4);

}

Code:

public static class StaticCSharpSample

{

public static int CalculateNumberSquared(int numberToSquare)
{
return numberToSquare * numberToSquare;
}
}

MSIL:

.method public hidebysig static int32 CalculateNumberSquared(int32 numberToSquare) cil managed {     
.maxstack 2 // maximum number of elements that can be pushed to the valuation stack
.locals init (
 [0] int32 CS$1$0000) // this is a local variable of type int32    
L_0000: nop // do nothing -- indicates compiled in debug mode    
L_0001: ldarg.1 // push argument 1 onto the stack     
L_0002: ldarg.1 // push argument 1 onto the stack multiplying a number by itself)    
L_0003: mul // multiply values
L_0004: stloc.0 // pop a value from the stack into a local variable 
L_0005: br.s L_0007 // go to labl L_0007
L_0007: ldloc.0 // push local variable at index 0 onto the stack
L_0008: ret // return the value from the stack (if there is one) and return from the method
}

As you can see, the MSIL is very similar to that which was generated in our first example.
While we could probably find a way to make the C# example generate the same managed
code as the F# example, it is clear that the F# example requires less work and less lines of code
to generate the more succinct result.

Breaking Down The Code

2008-10-18T11:04:00.000-07:00

Overview:

Last week we walked through creating our first F# application using TDD (Test Driven Development). Today we will break down that first example to identify what each of our commands are doing.

Here's a review of the extremely simple application that we wrote:

Test:
[TestMethod]
public void CanCalculateNumberSquared()
{
int result = FSharpSample.CalculateNumberSquared(2);
Assert.AreEqual(result, 4);
}

Code:

#light
let CalculateNumberSquared x = x*x;;

Breaking Down The Code:

So what does this all mean?

#light
The #light (pronounced "Hash" light) compiler directive provides various features that simplify the F# language. It also allows compatibility with the language OCaml. At the time of this writing, most experts recommend the use of this directive.

Identifiers:
The "let" keyword allows the programmer to associate any value or formulate to an "Identifier". Here's how Robert Pickering describes identifiers in his book "Foundations of F#". "To most people coming from an imperative programming background, this will look like a variable assignment. There are a lot of similarities, but there are key differences. In pure functional programming, once a value is assigned to an identifier, it never changes. This is why I will refer to them throughout this book as identifiers and not variables." If you have not read this book, I strongly recommend it.

In our example, we are setting up an identifier named "CalculateNumberSquared", specifying a parameter named "x", and finally providing instructions on what to do with that parameter. This identifier can then be passed around to other identifiers and/or functions.

This ability to pass around functions and identifiers is one of the great features in F#. While it may take some time to get use to this concept, you will soon wonder how you ever got along without it.

Getting Started With F#

2008-10-13T17:53:00.000-07:00

First retrieve and install the latest release of F# (the Sept. 2008 CTP can be found here).

I'm a believer in TDD (Test Driven Development), so our first step after installation of the CTP is to create a test.

Step 1: Creating the Test Project:

1. Open Visual Studio and type Ctrl+Shift+N to create a new project.
2. Create a Test project by selecting a project type of Visual C#\Test\Test Project. ( Note: I'm using a C# test project in VS2008, but any other test project will do.)
3. Set the location to any desired path with a new destination folder of "FSharpGettingStarted".
4. Change the Name to "FSharpTests".
5. Ensure that "Create New Solution" is selected and that "Create Directory For Solution" is checked.
6. Click OK.

Step 2: Creating the First Test:

1. Delete the default class that was generated in the test project.
2. Right click the FSharpTests project and select "Add\New Test...".
3. Select the Unit Test template and set the Test Name to "FSharpSampleTests.cs" then click OK.
4. In the newly generated class, locate the method "TestMethod1" and rename it to CanCalculateNumberSquared.
5. Remove the text that was generated in the method and type:
int result = FSharpSample.CalculateNumberSquared(2);
Assert.AreEqual(result, 4);

Step 3: Creating the F# project:
1. Type Ctrl+Shift+N and select the project type of Visual F#\F# Library.
2. Change the name to "FSharpSample".
3. Change the Solution option to "Add to Solution" and click OK.

Step 4: Adding the F# Function From Our Test:
1. Delete the "Module1.fs" file that was generated.
2. Right click on the FSharpSample project and select Add\New Item\F# Signature File.
3. Name the file "FSharpSample.fsi".
4. Right click on the FSharpSample project and select Add\New Item\F# Source File.
5. Name the file "FSharpSample.fs". (Note: if you add the ".fs" file before the ".fsi" file you may see an error message that states "An implementation of file or module FSharpSample has already been given. Compilation order is significant in F# because of type inference. You may need to adjust the order of your files to place the signature file before the implementation.". If you see this error, simply delete the ".fs" file and recreate it or manually edit the ".fsproj" file so that the ".fsi" file reference is above the ".fs" file reference in the ItemGroups.)
6. Open the FSharpSample.fsi file and type "val CalculateNumberSquared: int -> int" in the line directly below the line that states "#light".
7. Open the FSharpSample.fs file and type "let CalculateNumberSquared x = x*x;;" in the line directly below the line that states "#light".
8. Add the FSharpSample project as a reference to your Test project.
7. Run your test and it should now pass.

That's all there is to setting up your first F# library created with TDD. Next we will start talking about what some of this all means.

F# Versus C#, VB, and Other .NET Languages

2008-10-12T11:54:00.000-07:00

Why F#? What does F# provide that C#, VB, etc. does not?

1. By default, F# uses immutable types, which means that once a type is created, it will not change. This behavior makes the language inherently safe for concurrent operations. With an ever increasing need for concurrency support in enterprise applications, this behavior is becoming more and more desirable. With F#, concurrency related errors such as race conditions, synchronization issues, lock convoys, and deadlocks will be greatly reduced.

2. F# is built on the concept of functions rather than objects. While objects are supported, functions are also first class citizens. Functions can be and passed around like objects in C#/VB. This makes the language extremely well suited for algorithmic computations and makes it easier to achieve efficient processing of lists of data. Since everything compiles to IL, similar performance on these operations could conceivably be achieved with any .NET language, but F# allows optimal performance for specific operations with much less code. Note: In addition to the new abilities, you still have all functionality available in the .NET framework.

3. One of the features of F#, that I have found extremely useful, is the interactive scripting functionality. This allows the developer to select a subset of code and run it like a script. Anyone with a background it SQL will find this functionality very easy to understand and extremely useful for learning/experimenting with the language.

4. Finally, anyone with experience in C# will be thrilled to learn that the immutable aspects of F# will greatly reduce or eliminate the dreaded "Object reference not set to an instance of an object" error.

Note: F# should be added as an addition to an engineer's arsenal, not a replacement for the existing language of choice. My philosophy has always been, use the tool that is best suited for the task. Use F# in places where it can accomplish the task better and/or easier than the other available options.

Many of the points listed here are based on comments/documentation from the following:

http://msdn.microsoft.com/en-us/fsharp/default.aspx

Ted Neward: (http://msdn.microsoft.com/en-us/magazine/cc164244.aspx,
http://www.dotnetrocks.com/default.aspx?showNum=377)

The book "Expert F#" (http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=1590598504)

What is F#?

2008-10-11T17:34:00.000-07:00

What is F#?

F# is a functional programming language written by Don Syme from Microsoft. In addition to F#, Don has done extensive work on the CLR (Common Language Runtime) and is the main reason that we have generics in C# and VB.NET. F# was built on top of the CLR, which means that it compiles down to IL (Intermediary Language) and is interoperable with all of the other CLR based languages. The Sept. CTP Release is available here.

What is functional programming?

The first functional programming languages--IPL and LISP (which stands for List Programming)--were created in the 1950s. These languages, and all functional programming languages including F#, were built on the foundation of Lambda Calculus. There are many functional programming languages such as OCaml, Erlang, Haskell, and Eiffel. In addition, other languages such as XSLT
are built on some of the concepts from functional languages (note: XSLT is not a functional programming language).

We have functional programming languages to thank for many of the features that have been released in the .NET Framework such as generics, iterators, and LINQ.