Around the beginning of January, 2009, I began my experimentation with Azure. This meant installing the October 2008 SDK. Being a WCF geek, I tried writing a service a few minutes after I got Hello World working. Complete FAIL. No matter what binding I tried, I would get a message about having issues with config not allowing partially trusted assemblies. I tried all sorts of things to get the service working, and I eventually got something going by writing custom ServiceHostFactory (no config) that also stripped out the multiple HTTP endpoints appearing when the web site tried to create the service. Not exactly a happy experience. On January 14, a new version dropped. Now, I am reduced to using the basicHttpBinding, but I don’t need to use the custom ServiceHostFactory to diagnose things.

I needed a favicon.ico file for a web site I’m working on. I had the image that I wanted to use and needed a quick and dirty way to generate the correct icon file. Keep in mind, I’m a developer with limited artistic skills. After trying some icon editors (FAIL), I found a site that claims to make an icon based on a file you upload. Seemed to easy, but it was exactly what I needed. This is a great tool at a perfect price: http://www.favicon.cc/. It took my Twitter image:

and gave me a favicon.ico:

This article discusses a coding practice that I discovered while an undergrad a while back, maybe 1994. After doing some code reviews recently, I am reminded that this particular practice still needs more publicity. When writing code, a developer typically likes to worry about edge cases first, then handles the normal case. This practice has some benefits: the cases you worry about most get handled early. And, this practice creates maintenance nightmares. This practice has a some detrimental effects:

• Code readability is reduced
• Precious cycles are wasted on the uncommon cases
• Code complexity frequently increases

People remember and read positives easily. They have more issues with negatives. Consider the following C# code:

Consider what happened when a developer wrote the code above. They thought, "OK, if this file does not exist, then I can create it. However, if the file does exist, I want to make sure I start with a clean slate, so I’ll delete the file, then create it." The code above is confusing. The thoughts are equally confusing. While I wish this code were an anomaly, it isn’t. This is something I see on a regular basis: in support forums, in code that didn’t have time for a proper review, and elsewhere. Consider what would have happened if the developer had chosen to use positive logic instead of negative:

Here, the code is more readable and the intent is clearer: if the file exists, delete it. Then, open the file for read/write. Note that the code is now smaller and maintenance is easier too.

Here is another example, this one a PowerShell script from TechNet magazine. Here, we have an example where readability is diminished thanks to negative logic. Line 15 just bugs me. Read the code:

1. function Get-WmiInventory {
2.  param (
3.  $wmiclass = "Win32_OperatingSystem"
4.  )
5.  PROCESS {
6.   $ErrorActionPreference = "SilentlyContinue"
7.   $computer = $_
8.   trap {
9.    $computer | out-file c:errors.txt -append
10.    set-variable skip ($true) -scope 1
11.    continue
12.   }
13.   $skip = $false
14.   $wmi = Get-WmiObject -class $wmiclass -computer $computer -ea stop
15.   if (-not $skip) {
16.    foreach ($obj in $wmi) {
17.     $obj | Add-Member NoteProperty ComputerName $computer
18.     write $obj
19.    }
20.   }
21.  }
22. } 

OK: If I should not skip then I should do work. With a little better naming, we could make this all more readable. How about this instead:

1. function Get-WmiInventory {
2.  param (
3.  $wmiclass = "Win32_OperatingSystem"
4.  )
5.  PROCESS {
6.   $ErrorActionPreference = "SilentlyContinue"
7.   $computer = $_
8.   trap {
9.    $computer | out-file c:errors.txt -append
10.    set-variable shouldWriteComputerInfo ($false) -scope 1
11.    continue
12.   }
13.   $shouldWriteComputerInfo = $true
14.   $wmi = Get-WmiObject -class $wmiclass -computer $computer -ea stop
15.   if ($shouldWriteComputerInfo) {
16.    foreach ($obj in $wmi) {
17.     $obj | Add-Member NoteProperty ComputerName $computer
18.     write $obj
19.    }
20.   }
21.  }
22. } 

Here, readability goes up because I can now see exactly why we DO go into the loop instead of seeing why we do NOT.

If you write negative logic, do a pass after writing things to fix up the code. Do that pass immediately. I frequently write code like:

I immediately turn around and rewrite this code as:

I have found that I can read this kind of code long after writing it and remember what I meant. I have difficulty doing the same thing with negative logic paths.

January Meeting: NHibernate

Every so often, I get into a discussion about whether Add Service Reference is required in an application if the application owns both the service and one consumer. The short answer is No. But, you probably want to know Why? To understand that, we need to look at what Add Service Reference actually does and why you can do the same for yourself.

For the purposes of our discussion, the work actually being done by the service is unimportant. Let us assume the following interface:

The implementation of the interface is then

So, nothing terribly complex going on. To be able to discover information about this service, we will also add a metadata endpoint (the configuration is at the end of this article). With the metadata endpoint exposed, we can point Add Service Reference at the endpoint and generate a consumer. Add Service Reference does not necessarily know that the other endpoint is implemented in Java, .NET, or some other language. It generates a bunch of bookkeeping files so that the client can be regenerated at will. If you click on Show All Files in your VS project, you will see many files under the reference you just added.

• configuration.svcinfo: Contains a snapshot of the configuration generated for the client service endpoint for the local (app|web).config 
• configuration91.svcinfo: For each property in config, contains an XPath to the setting and the original value stored in config.
• *.wsdl: Copies of the WSDL files exposed by the WSDL endpoint.
• *.xsd: Copies of any schema files exposed by the WSDL endpoint.
• Reference.svcmap: Pointer to the service and pointers to any svcinfo, wsdl, and xsd files in the project. This file also stores any special settings selected by the user from when the ServiceReference was first generated. All of this is used when the user chooses to regenerate the reference.
• Reference.(cs|vb): Contains a WCF compatible interface of the contract, a client channel capable of communicating with the contract, and a proxy class that can be instantiated.

All these files are needed to create and refresh a client when you do not control the client. When you do control the client, none of this is needed. You can share the configured binding in between the client and the service. However, you must put the service contract on an interface– that’s the only real requirement. If your client and service are in different binaries, I would recommend putting the Service and Data contracts into yet another class library that can be referenced from the service and the consumer. This reduces the coupling of the interface its implementation. Furthermore, you need to define the WCF contract on an interface, not on the implementation class. WCF cannot construct a client implementation based on a class definition. This is due to a number of details associated with how the CLR allows code to intercept method calls. The general rule is that you can intercept method calls on interfaces but not on classes.

To consume the service, WCF needs to know the address, the binding, and the contract, nothing more. WCF class libraries know nothing of the .svcmap file and its cohorts. Using this mechanism, we then talk to the service using code that many of us have seen before. If you own the service implementation, none of this is necessary. Instead, you can use stuff you know to create the client on your own. I’m going to show you some code that I have for a console application. This code will work no matter the context (Web, service, Windows app). The code shows three variations: reading the ServiceEndpoint from the ServiceHost, running the client from pure code, or reading the client from configuration. This is just a demonstration of what is possible.

Config for the service:

The project for this weekend is to create something that I can share with the rest of the web allowing one to create Web projects with F#. Part of doing this the right way is to include that handy dandy litany of assembly level attributes indicating things like assembly name, version, description, configuration, company, etc. In a C# project, this information appears in AssemblyInfo.cs. For my F# project, I figured that AssemblyInfo.fs is as good a place as any to start. So, how do you do this? Like in C#, assembly level attributes occur at file scope and have the word assembly: in front of the attribute. They wind up going into a file like so:

Now, AssemblyInfo.fs wasn’t going to have any types, and this frustrated the F# compiler a bit. After some tweaks, it coughed up a hint to use do(). So, I went ahead and put in:

What is that do for? Looking at the spec, this is something called a do binding.do binds an expression and asserts that expression is equal to unit. Here, I’m binding to an empty tuple, so the dimension in unit. This is sufficient for the compiler to be happy and allow the attributes to be evaluated and added to the assembly at compile time.

I spent a large portion of my career working with WS-*/SOAP. So, once I understood how F# attributes worked, I thought it would be cool to see if I could write a WCF service. Nothing complex– I just wanted to see if I could get HelloWorld up and running. Given that one can get a class running as a service with the right config and .svc file, this seemed like an easy task. First, I’ll present the solution, then I’ll talk about a couple of issues I ran into along the way to the solution. In F#, one adds attributes by placing a [<Attribute>] before the type or member. For WCF, we need the ServiceContractAttribute and OperationContractAttribute on the type and any exposed functions. The HelloWorld service can be written like this:

Following the path most folks take, hosting in IIS, we next write a .svc file with the following content:

<%@ ServiceHost Service=”Service.MyContract”  %>

This just tells the ServiceHostFactory to instantiate an object of type Service.MyContract whenever a request comes in. Finally, we go into web.config and add the following markup:

Finally, I wrote a client application in C#, using Add Service Reference in VS2008 to generate the client code.

And it all worked just fine. I know– it’s all .NET and that’s the way things should work. I’m most impressed by the terseness of F#.

OK, so what did I learn while doing this? First off, F# does NOT create a default, empty constructor for classes. WCF barked at me when I tried to access the SVC file, stating that it couldn’t create the object because the object lacked a default constructor. So, I dug into the F# spec and learned that a default, do nothing constructor looks like

I also tried doing this in the traditional way, with an interface definition first and then an implementation of the interface. That didn’t work so well. In F#, the interface looks like this:

That little bit on HelloWorld states that the input is a single string that yields a string. The input parameter does not have a name, and that’s a problem. No name means no name, null, in F#. When System.ServiceModel does its reflection thing to figure out what the name of the parameter in the message should be, it sees a null and throws up its hands. I was able to name the parameter only when applying the attributes on the named parameter in the implementation. So, I ditched the interface. Maybe I missed something that would allow me to name the parameter, but I’m not too sure what it could be. For now, I’ll assume that this was a legitimate issue. I’ll update this post if I learn otherwise.

F# is clearly gearing itself for science and math. Well, most functional languages do since they frequently make it easy to express mathematical formulas naturally. One thing it does well is allow for measurements to be expressed using units. For example, let’s say that we need to compute the velocity of an object falling towards Earth. Things fall towards Earth at 9.8 m/s^2. To compute the speed of an object falling towards Earth after falling a fixed distance, we would find that we can simply multiple distance * velocity and wind up with m^2/s^2. To find speed, we take the square root of the product.

A common cause of bugs when performing this kind of calculation results from losing track of the units. How do we make sure that we at least know what the units are? For this kind of problem, F# introduces the Measure attribute. Measure allows a given, empty type to represent some type of unit. To represent meter and second, we would write:

Using these measures, we can then express Earth’s gravity as a value in meters/second^2

We can then express speedOfImpact against these values:

Then, we can do something like find the speed after falling 100.0 meters. Pulling everything together, we have this:

This prints out

31.320920

Oh, if you forget to cast the result to a float, the compiler will tell you something like this:

The unit of measure ‘m/s’ does not match the unit of measure ‘1’

m/s– that’s a speed measurement! Note: the units of measure must appear immediately after the value represented. Any white space will give you this error on the next line:

incomplete construct at or before this point in expression

Now, before you write off F# as something that you could never use in a line of business application, consider the use of Measure for sales forecasting and other forms of capacity management. Items leave warehouses with a ‘velocity’ of widgets/unit of time. Here is a trivial example:

You can use more sophisticated logic to determine to salesVelocity and so on. My goal isn’t to belabor the point. widgets/case, defects/hour, phone calls/second, all are units that you will use in your non-scientific, line of business applications. I sense something that may allow for better accuracy and remove another class of error from applications. I haven’t seen this example used yet by others talking about Measure. I’m trying to look beyond science and see the benefits in other types of calculations.

To allow a few of you out there to avoid the same time waster I experienced, let me state this one quickly: if you want to develop applications for Azure, you cannot run the DevFabric on Windows 7 Beta. The bug has been confirmed by Microsoft and has no known workarounds. I hit the issue exactly 5 minutes after I had finished a system rebuild to get Win 7 + VS 2008 up and running. Thankfully, I also run Windows Home Server elsewhere in the house and was able to get back to a happy place within an hour.

I know a few of you may have seen Microsoft folks running this scenario; Ron Jacobs did it at the MSDN DevCon in Chicago on Tuesday, Jan 13. Guess what: FOLKS LIKE RON AREN’T RUNNING THE BETA. They have access to internal builds that, apparently, allow one to debug Azure locally. The build we got for the beta probably last had a code update sometime in early December, if not before Thanksgiving. So, if you are digging into that awesome sauce that is Azure, don’t set up a Win 7 dev box.

When reading through the F# spec, you will see plenty of references to it’s inspiration language, Objective Caml, aka OCaml. If you want to learn more about OCaml, and by extension F#, you may find the OCaml book from O’Reilly handy. This appears to be the complete, English translation of the book… all 757 pages. I was a little curious about what OCaml is and why it exists. Fortunately, Google knew the answer. It pointed me to A History of Caml. Briefly:

“Caml” was originally an acronym for Categorical Abstract Machine Language. It was a pun on CAM, the Categorical Abstract Machine, and ML, the family of programming languages to which Caml belongs. The name Caml has remained throughout the evolution of the language, even though the present implementation has no relation with the CAM.

Apparently, OCaml was released in 1996. The fact that we are seeing it appear in .NET today as F# is nothing short of amazing. I wonder if F# projects will ever qualify for the OCaml Success Stories page.