We’ve just posted a new screencast at Rock Solid Knowledge. In this one I walk you through enabling WCF tracing to assist in diagnosing bugs in your services using the example of a serialization failure. You can find the screen casts here

http://rocksolidknowledge.com/ScreenCasts.mvc

Every year I speak at the excellent DevWeek conference in London. Eric Nelson, a Microsoft Developer Evangelist in the UK is also a regular attendee. This year Eric, Mike and Mike were recording interviews with people at the conference. Eric interviewed me about Workflow 4.0 (I was delivering a post conference day on WF 4.0, Dublin and Oslo). He’s just got round to published it online

http://geekswithblogs.net/iupdateable/archive/2009/05/20/devweek-2009-interview-with-richard-blewett-on-workflow-4.0.aspx

Soma has blogged that beta 1 has finally shipped. Lots of new stuff in here since PDC. His blog post is here

http://blogs.msdn.com/somasegar/archive/2009/05/18/visual-studio-2010-and-net-fx-4-beta-1-ships.aspx

We’ve started a library of screencasts at rock solid knowledge. I’ve created one on WCF Serialization and one on using SSL with Self hosted WCF services. Andy Clymer has recorded one on Visual Studio Tricks and Tips and Dave Wheeler has one on character animation in Silverlight 2.0. You can find the screen casts at

http://rocksolidknowledge.com/ScreenCasts.mvc

We’ll be adding to the library as time goes on so subscribe to the library RSS feed

Cliff Simpkins has just posted a blog entry detailing some of the changes between the PDC preview of WF 4.0 and what is coming in beta 1, due shortly.

Important information here not just about beta 1 but also about things you can expect and also things that won’t make it into RTM

I've just installed the latest Active* gems to move my Rails install to 2.3.2. When I ran a console I got the following error

Loading development environment (Rails 2.3.2)
/Library/Ruby/Gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:443:in `load_missing_constant':NameError: uninitialized constant ApplicationController 

I googled this and found a couple of posts on the issue but nothing obvious that I was doing. After generating a 2.3.3 app and comparing files the solution was obvious and easy. I 2.2.2 the ApplicationController class is in a file called Application.rb, in 2.3.2 this has changed to application_controller.rb. Changing the file name has fixed my problem.

I’ve been doing some work with the WCF REST Starter Kit for our website http://rocksolidknowledge.com. Preview 2 of the start kit has a bunch of client side plumbing (the original release concentrated on the service side)

The client side code looks something like this:

HttpClient client = new HttpClient("http://twitter.com");

HttpResponseMessage response = client.Get("statuses/user_timeline/richardblewett.xml");

Console.WriteLine(response.Content.ReadAsString());

As compact as this is I was a bit disappointed to see that I only had a few options for processing the content: ReadAsString, ReadAsStream and ReadAsByteArray. Now seeing as they had a free hand to give you all sorts of processing options I was surprised there weren’t more. However, one of the assemblies with the start kit is called Microsoft.Http.Extensions. So I opened it up in Reflector and lo and behold there are a whole bunch of extension methods in there – so why wasn’t I seeing them?

Extension methods become available to your code when their namespace is in scope (e.g. when you have a using statement for the namespace in your code). It turns out that the team put the extension methods in the namespaces appropriate to the technology they were exposing. So for example the ReadAsXElement extension method is in the System.Xml.Linq namespace and the ReadAsXmlSerializable<T> method is in the System.Xml.Serialization namespace.

Although I really like the functionality of the WCF Starter Kit, this particular practice, to me, seems bizarre. Firstly, it makes the API counter intuitive – you use the HttpClient class and then there is no hint in the library that there are a bunch of hidden extensions. Secondly, injecting your extensions into someone else’s namespace increases the likelihood of extension method collision (where two libraries define the same extension method in the same namespace). The same named extension method in difference namespaces can be disambiguated, the same named extension in the same namespace gives you no chance.

I think if you want to define extension methods then you should keep them in your own namespace – it makes everyone’s life simpler in the long run.

In Rails there is a mechanism by which you can mimic variadic methods (Ruby also supports true variadic methods) by treating the last parameter as a hash. I can write a function definition like this

def pass_a_hash(s, h) 
  puts s
  h.each { |key, value| puts "#{key} => #{value}"} if h.class == Hash  
end

and call it either like

pass_a_hash "kevin", {:a => "b", :c => "d"}

pass_a_hash "kevin", :a => "b", :c => "d"

kevin
a => b
c => d

The second style is much neater, it hides the use of the hash and instead makes it seem like we are using named parameters. This is used all over Rails, especially on web pages where you need to specify things such as controllers and actions. You will often see code like:

<%= link_to "Add", :action => :add, :controller => :students %>

Here we are calling the 'link_to' method passing a string and a hash of options, just like above

Microsoft (bless 'em) have tried to mimic this in ASP.Net MVC by letting you can write code similar to the 'link_to' Rails method. On an ASP.Net view you can do something like:

<%= Html.RouteLink("Add", new {action = "add", controller = "students"}) %>

And this adds a link to the page with the text "Add" and a url something like http://server.com/students/add. This is similar to ActionLink and they both eventually call into a method called GenerateRouteLink. In the ASP.Net case the second parameter is not a hash (oh for first class hashes in C#) but an instance of an anonymous class. Using Reflector we can see what this method does.

Internally RouteLink creates a RoutedDictionary passing the anonymous instance as a parameter to its constructor

    return htmlHelper.RouteLink(linkText, new RouteValueDictionary(routeValues));

The RouteValueDictionary constructor looks like this

public RouteValueDictionary(object values)
{
    this._dictionary = new Dictionary<string, object>(StringComparer.OrdinalIgnoreCase);
    this.AddValues(values);
}

and AddValues does this:

private void AddValues(object values)
{
    if (values != null)
    {
        foreach (PropertyDescriptor descriptor in TypeDescriptor.GetProperties(values))
        {
            object obj2 = descriptor.GetValue(values);
            this.Add(descriptor.Name, obj2);
        }
    }
}

public void Add(string key, object value)
{
    this._dictionary.Add(key, value);
}

So AddValues uses reflection to build a dictionary of name/value pairs

Just like in Rails, when the element is rendered this dictionary is interrogated and the values used to build the URL.

Neat, but still more ceremony than in Ruby!

Last week at DevWeek Tim Ewald and I tried to show some of the elegance of Ruby and I'd like to try and repeat that example here.

We started with a Lion class in honour of the news story that week about "Christian the Lion" (hey, look it up yourselves!). The class is very simple

class Lion

  attr_accessor :message, :name

  def speak
    @message
  end

  def to_s
    "#{self.name} says #{self.message}"
  end

  @@lions = {}

  def self.create message, name
    if @@lions[name] == nil
      @@lions[name] = Lion.new(message, name)
    end
    return @@Lions[name]
  end

  def initialize(message, name)
    @message = message
    @name = name
  end

end

The bit we care about is the self.create method. The idea here is that we provide a function to only allow the creation of one lion with any given name (this was a demo so it didn't need to make sense). To do this there is a class level dictionary (a static) in which to store new lions. We only add lions to this dictionary if they are unique, otherwise we return an existing lion. The code as it is written is not very Ruby-ish, it reads more like C++, C# or Java code than Ruby and that's what I'd like to change.

The first step is to remove the 'return' keyword. In Ruby the last statement in a method is the return value so we can change the code to look like this:

def self.create message, name
  if @@lions[name] == nil
    @@lions[name] = Lion.new(message, name)
  end
  @@Lions[name]
end

The 'if' statement isn't very idiomatic either and in Ruby this can be reduced to

def self.create message, name
  @@lions[name] = Lion.new(message, name) if @@lions[name] == nil 
  @@lions[name]
end

We're still not quite there though. Ruby (like C#) has a 'null co-alescing' operator, which lets me say "if 'x' is not null, use it, else do 'y'", and I can rewrite the above 'if' using this operator (|| in Ruby). It also means I can do away with the final return statement

def self.create message, name
  @@lions[name] || @@lions[name] = Lion.new(message, name)
end

Which says, if @@lions[name] is not null return the value, else assign Lion.new to @@lions[name] and return that value

One line to do what it would take four lines to do in other languages and no keywords. As my friend Stu Halloway would put it, essence over ceremony!