Sunday, June 12, 2011

NDC 2011

Last week some colleagues and I went to the NDC conference in Norway.



Apart from the weather, which was crappy, it was an awesome conference. I've seen some great talks and am looking forward to watching some of the talks I missed (because I was in another session) online. I also went home with some new great ideas for books I want to read:

  • Introducing HTML 5, by Bruce Lawson and Remy Sharp. They gave the HTML 5 talks during the second day of the conference in a small and very crowded room. They convinced me even more of the amazing things you can do for web pages with the new upcoming standard. It was a relieve as well to hear someone from the Opera browser team talking about HTML 5 instead of the standard Microsoft talks I heard thus far. 
  • Test-Driven JavaScript Development, by Christian Johansen. Too bad his talk was given simultaneously with Rob Ashton's (Document databases with ASP.NET MVC), Kevlin Henney and Anders NorĂ¥s's (Introducing The FLUID Principles) and Hadi Hariri's (Dynamic in a Static World). I went to this last session, which was very good. It gave me some ideas and examples of more things I can start doing with dynamic. I would really like to try to get a DSL written with it (I would probably start off by copying a Ruby example, since it is not easy stuff). The talk about the FLUID principles was very good as well, my colleagues went to that one and it is one of the talks to catch on rerun, once they put the videos up. I did follow the talk about the SOLID principles, which was nice to refresh again. I went to the RavenDB by Example talk on day  3 of the conference. It was a good thing the speaker also mentioned some of the problems he had with a document database, having to rethink the design of your data as opposed to relational databases.
  • The Joy of Closure, by Michael Fogus and Chris Houser. I didn't get to catch any of the Closure and F# talks and it would be nice to get up to speed with this. Also something to watch on rerun and see what we can do with it
  • 97 Things Every Programmer Should Know, by Kevlin Henney and 97 Things Every Software Architect Should Know, by Richard Monson-Haefel. I only went to Kevlin's talk about the 101 things he learned in architecture school, which was light, but enlighting. His other two talks apparently were very good as well, as my colleague went to those.
  • Specification By Example, by Gojko Adzic. His talk wasn't so good, but I think a lot can be learned from this book. One thing I will really remember from the conference is the multiple question marks that speakers had with BDD, DDD and agile. While they are all good techniques, they have their flaws and the software community really needs to figure out how we can do these things even better. Gojko's post on his blog about one of these talks really explains the problem a bit as well. He also mentioned our Cronos colleagues from iLean in his talk, which I think was pretty cool. And he is also one of the creators of cuke4ninja, a port of cucumber for .Net.


Apart from those books and talks I already mentioned, I also followed some of the talks on mobile development. The ones about multi platform development were really informative. The MonoTouch and MonoDroid projects have moved from Novell to Xamarin and are planning on a next release in the coming months. Biggest take-away there was: use the latest MonoTouch and MonoDroid builds for now and switch to the Xamarin builds once they are published. Jonas Follesoe's talk on this topic was great, if you're doing mobile, catch it on rerun! 

I also really liked the AOP talks given by the PostSharp people. They have a great framework for doing AOP, which is really powerfull and which gives you a lot of cool features for keeping your code nice and, well, sharp. They also mentioned some other AOP frameworks, which I think is a nice gesture, since they are not the only ones out there.

The CQRS talk by Fredrik Kalseth was inspiring as well, although he only mentioned one part of CQRS. It was explained really well and can be used as a basis on future projects. I also learned in his talk that JetBrains have a Ruby IDE which I didn't know about. As I look at their site now, I see they're also working on an Objective-C IDE. 



So, all in all, a very good conference, which I hope to catch again next year, and hopefully without the rain. I learned a lot and have now a whole lot of stuff to read and learn even more about. Too bad there's only 24 hours in a day (of which I really need 9 to sleep, since I'm a sleepy head).

Thanks as well to my colleague, Guy, for providing some very nice pictures. You can find the entire collection here.

Monday, June 6, 2011

More on DynamicObject: TryInvokeMember

I just came along another old example of DynamicObject, I would like to share with the world.

What I didn't mention in my last post is that DynamicObject has more methods you can override besides TryGetMember and TrySetMember. These two are very useful when working with properties you want to add on the fly. For methods the TryInvokeMember is a better choice to override. This method will get called on your DynamicObject when it can't resolve a method call.

Let's for instance write a very simple dynamic tracer class. First of all I will inherit again from DynamicObject. This time the class I am creating, DynamicTracer, will not hold an XML tree, but it will wrap another object.

Every time a method is called on this object we will print out (hence the name DynamicTracer) the operation that is being called.

 class DynamicTracer : DynamicObject 
 { 
   object theObject; 
   public DynamicTracer(object theObject) 
   { 
     this.theObject = theObject; 
   } 
   public override bool TryInvokeMember(InvokeMemberBinder binder, 
      object[] args, out object result) 
   { 
     try 
     { 
       Console.WriteLine("Invoking {0} on {1}", binder.Name, 
            theObject.ToString()); 
       Type objectType = theObject.GetType(); 
       result = objectType.InvokeMember(binder.Name, 
            System.Reflection.BindingFlags.InvokeMethod, null, 
            theObject, args); 
       return true; 
     } 
     catch 
     { 
       Console.WriteLine("Oops, cannot resolve {0} to {1}", 
            binder.Name, theObject.ToString()); 
       result = null; 
       return false; 
     } 
     return true;
   } 
 }  

The usage is quite similar to using TryGetMember and TrySetMember, only now are we getting a InvokeMemberBinder as parameter, together with the argument list that is being used and an out parameter for returning the result. I use reflection to invoke the method on the actual object.

To use this tracer, the only thing you need to do is wrap an object with it:

 FileInfo fi = new FileInfo("c:\\temp\\test.txt"); 
 dynamic tracedFI = new DynamicTracer(fi); 
 tracedFI.Create();  

When Create is called, there will be no matching method found in the DynamicTracer class, which will instead trigger the TryInvokeMember method. Although this seems pretty cool and useful, beware you loose all auto completion on any object you wrap this way, which is, for all things dynamic, a downside.

Doing the dynamic thing (Part V)

This will be the fifth and last part in this series. I will try and post some additional stuff concerning dynamic programming, but they will be standalone posts and will not be part of this series (the numbering is getting a bit out of hand).

In last post, you saw how to use the ExpandoObject. We will extend this now with the DynamicObject class. The difference between the ExpandoObject and the DynamicObject is that the first one gives you the ability to create dynamic types on the fly, with custom added properties, methods, ... for each object you create. The DynamicObject class however gives you the opportunity to extend the basic behaviour(s) you want your dynamic objects to have. You can also add some logic for adding dynamic behaviour.

You create your own dynamic objects by inheriting from DynamicObject. You can add extra methods to this class and you can override existing methods of the base class. it is by overriding the existing methods that you actually give your objects dynamic behaviour.

I will give you a practical example of this. A while back a colleague of mine was writing a Silverlight dashboard application on top of a TFS server, using the TFS APIs. This implied writing a WCF service the Silverlight application could use for quering the TFS server. Now, while the TFS APIs are quite extensive, they don't implement the ISerializable interface for all data type objects.

Facing this problem, my colleague started writing DTO classes for all of these types that weren't serializable. But I started thinking if it wasn't possible to just leverage the intrinsic capabilities of dynamic objects. After all, the only thing needed for these TFS objects to be send from and to the service were methods to serialize them to and from XML. And why not make these objects dynamic on the client side, hence excluding the need for referencing or redefining all these TFS objects on the server and client side.

First thing I needed for this, was a way to get any object on the server side serialized to XML. For this I will use the DynamicObject class. I want to be able to use my DynamicObject the same way I used the ExpandoObject class, by adding properties as needed. The DynamicObject for this has two important methods an inheriting class can override. These methods are TryGetMember and TrySetMember. The TryGetMember method gets called whenever you are accessing a property or method of your DynamicObject. The TrySetMember method gets called whenever you want to assign a value to a property or method of your DynamicObject.

I will explain this in more detail for you in a bit. I will start by getting information from our TFS server. I use a simple query and a couple of foreach loops to get information about all workitems in a certain project.

 TeamFoundationServer tfsServer = 
     new TeamFoundationServer("http://serverurl"); 
 WorkItemStore store = 
     (WorkItemStore) tfsServer.GetService(typeof (WorkItemStore)); 
 foreach (Project project in store.Projects) 
 { 
   foreach (WorkItemType wit in project.WorkItemTypes) 
   { 
     WorkItem theItem = new WorkItem(wit); 
     //dynamic code coming up 
   } 
 }  
Once I have a WorkItem from TFS, I want to be able to build a new DynamicObject, using it the same way as an ExpandoObject, adding properties as I go along.

 dynamic dyn = new DynamicElement(theItem.ToString()); 
 dyn.ChangedDate = theItem.ChangedDate.ToString(); 
 dyn.ChangedBy = theItem.ChangedBy; 
 dyn.Description = theItem.Description;  

The DynamicElement class is the class I have inherit from DynamicObject. It is this class that contains the TryGetMember and TrySetMember overrides. Every time I dynamically add a property to my DynamicElement object (like I do for ChangedDate, ChangedBy and Desciption in the example above), the TrySetMember override gets called. In this override I create a sort of dictionary of all the property names and property values the user of DynamicElement has thus far added. This is actually quite similar to what an ExpandoObject does out of the box. The difference is that I can now choose how I store these dynamically added properties and instead of using a dictionary, I use an XElement. I know I have to be able to serialize the entire object to XML, so better make my life simple.
Here you see part of the DynamicElement class that inherits from DynamicObject.
 public class DynamicElement : DynamicObject 
 { 
   public XElement actualElement; 
   public DynamicElement() 
   { } 
   public DynamicElement(XName name) 
   { 
     this.actualElement = new XElement(name); 
   } 
   public override bool TrySetMember(SetMemberBinder binder, object value) 
   { 
     string name = binder.Name; 
     if (actualElement == null) 
     { 
       actualElement = new XElement(binder.Name); 
       return true; 
     } 
     actualElement.Add(new XElement(name, 
       value)); 
     return true; 
   } 
   public override string ToString() 
   { 
     return actualElement.ToString(); //actualElement.Value; 
   } 
 }  
You can see I use an XElement datamember, which I use to build the XML to return from a WCF service call (I didn't make the datamember private, to keep the example short, I need access to it, later on in the example, you should never do this in real life). I also have a constructor overload I can use to set the root name of the XElement. The TrySetMember does nothing more than building the XML. The SetMemberBinder parameter can be used to see which property (or method) names the user of your DynamicElement used (in this example ChangedDate, ChangedBy and Desciption). Once the XML is build, the ToString method can be used to serialize the entire object to XML.
In using this DynamicElement for my WorkItems, I also want to add project info to them:

 dynamic dyn = new DynamicElement(theItem.ToString()); 
 dyn.ChangedDate = theItem.ChangedDate.ToString(); 
 dyn.ChangedBy = theItem.ChangedBy; 
 dyn.Description = theItem.Description; 
 dynamic dynProj = new DynamicElement("Project"); 
 dynProj.Name = theItem.Project.Name; 
 dynProj.Id = theItem.Project.Id; 
 dyn.Project = dynProj.actualElement.Descendants(); 
 return dyn.ToString();  

For the project I use a second DynamicElement. Once the project element is build, I add the entire XML tree to a new Project property of the dynamic workitem object. Eventually I call the ToString method which serializes the object to XML. This way of working makes my service methods quite simple.

 [ServiceContract] 
 public interface IService1 
 { 
   [OperationContract] 
   string GetWorkItem(); 
 }  

So far for the server side of things. We still need a client that can parse the generated XML. For this, again, I will use a DynaimcElement (actually the same one as above, but with extra code added). First of all the incoming XML needs to be understood. A simple solution for this is adding an extra constructor to our DynamicElement class that takes a XElement as a parameter (being the entire XML tree).

 public DynamicElement(XElement actualElement) 
 { 
   this.actualElement = actualElement; 
 }  

Every time now the code wants the value of one of the properties, the TryGetMember override of DynamicObject gets called, so lets add this.

 public override bool TryGetMember(GetMemberBinder binder, 
   out object result) 
 { 
   string name = binder.Name; 
   var elements = actualElement.Elements(name); 
   int numElements = elements.Count(); 
   if (numElements == 0) 
     return base.TryGetMember(binder, out result); 
   if (numElements == 1) 
   { 
     result = new DynamicElement(elements.First()); 
     return true; 
   } 
   
   return false; 
 }  

The code again uses the Name property of the GetMemberBinder, which gives us the name of the property we are trying to get the value of. Next we look for an element with this name in the XML tree. If we can't find this element, maybe the base class can find it (which it probably won't). If we find 1 element with this name, we return it as a DynamicElement. This way we can use the ToString method on it, which will return the Value of this element, and we can also dot further into subproperties of the object (eg. for the Project property of a workitem). We can now write source code like this:
 TFSService.Service1Client client = new TFSService.Service1Client(); 
 string result = client.GetWorkItem(); 
 dynamic workitem = new DynamicElement(XElement.Parse(result)); 
 Console.WriteLine(workitem.ChangedDate); 
 Console.WriteLine(workitem.ChangedBy); 
 Console.WriteLine(workitem.Description); 
 dynamic project = workitem.Project; 
 Console.WriteLine(project.Name);  
I can also add code to the service to return some random XML. I added another service method for this.

 public string GetSomeXml() 
 { 
   return "<test><child1>firstchild</child1>
    <child2>secondchild</child2><child3>
    <sub1>firstsub</sub1><sub2>decondsub</sub2>
    </child3></test>";  
 }  
The client can also print out the values of this XML:

 result = client.GetSomeXml(); 
 dynamic someXml = new DynamicElement(XElement.Parse(result)); 
 Console.WriteLine(someXml.child1); 
 Console.WriteLine(someXml.child2); 
 Console.WriteLine(someXml.child3); 
 Console.WriteLine(someXml.child3.sub1); 
 Console.WriteLine(someXml.child3.sub2);  
This way it is quite easy to build objects on both client and server without the need to provide classes for each one of them. You just take the 'one time effort' to write up a DynamicObject class and you are done.

What I still want to test with this code, is whether it is possible to get this code working together with a tool like AutoMapper (on the server side). It is just a bit cumbersome to copy over all the values of your dynamic objects.

At least I hope this gives you an idea of a practical use of dynamic objects in .Net. It is not the most obvious example and I expect most uses of dynamic lie in working together with COM and JavaScript for SilverLight applications. Other than that I haven't seen many practical examples popping up on the Internet (except for this one, of course).