Pass the fork

Teams often work on shared code, shared resources and in shared time. We have ways of managing this, such as source control, one of the first requirements for software development maturity (falling within Levels 2 to 3 of the CMM for Software). However, not everything is easily integrated into such a process.

Developing on the example of source control, source control presents challenges that the mature team will be able to identify and overcome through the use of best practices or their own devised and agreed processes. Shared assets such as legacy systems, premium-licensed resources or even databases often exist outside of source control leaving the team requiring confidence that one developer’s work on that shared asset won’t affect others.

Meet the fork.

The DB Token of Power ("The Fork")

With the fork, a team member can wield power of access to a contended or non-source controlled asset such as database schema changes, SharePoint server configuration, leverage of a single-user licence service or other lock-required activity. The fork acts as a physical action and visual cue in the physical world, representing the reality within the virtual or abstracted world of source code, databases and servers. As a team member reaches for the fork, their wishes are explicit (“I have the fork”) and may be “blocked” by any other team member (“Oi, hang on, I need to do something first”). Without the fork, no changes may be made – or would be expected to have been made by the rest of the team.

Use of a token in this manner is predicated on the collaborative capabilities of the team, perhaps requiring that the team are co-located, small and cohesive. Such team environments aren’t always possible or available. Teams that are not co-located, are perhaps too large (spanning more than one pod of desks) or lack a cohesiveness that is conducive to casual conversation would inhibit the use of such a token; though in this case, one must answer much larger questions about why are these people working on contended assets?

There are alternatives. Use of a shared chat channel for the team such as Slack with an agreed protocol (even descending to the “claim” protocol introduced in The Walking Dead TV Show) would overcome the overly-large, distributed and communication-inhibited team; though this would require a level of buy-in or enforcement by a commonly accepted leader.

We’ve used the fork to great effect. Merging of sensitive assets such as Entity Framework .edmx files (this project has not yet made it to Code-first) can result in a whole world of pain if two developers tackle two work items that are either contradictory or contended. It’s simple and promotes added cohesiveness within the team. Our token was chosen based on what was sitting in one of our drawers and this remains a shared experience within the team and contributes to our mutual social credit.

Of course, you don’t need to use a fork, any token will do, so long as the understanding across the team is consistent and mutual. Such tokens have been in use for years. Ever since the 19th century, and remaining in use even amidst today’s modern computer-controlled signalling, railways have used the token to guarantee safe access to controlled sections of track to prevent collisions.

 

 

 

Using an anti-pattern still enhances your maturity

Programming has approached a level of professionalism that suggests we now spend a lot of time meta-programming, naval-gazing and writing a whole lot of complex code just to avoid smells.

Meta-programming could be described as programming about programming. As our tools get more advanced and our systems get faster, we can now write code that writes code and write code that analyses code. What’s the point? Visual Studio has finally integrated the Roselyn Compiler-as-a-Service feature which brings the compiler in as a first-class citizen so you can generate code and analyse it from within your own program. But wait, the last time I looked, it was an anti-pattern to dynamically generate code.

This self-analysis of code has otherwise been a manual process, supported by burgeoning communities of self-aggrandising architects such as those gaining increased scores on sites like Stack Overflow. Thou shalt not code in JavaScript in an imperative fashion, though shalt not use global variables, and it goes on. We’ve got to the point of intellectualism that we are able to create arbitrary levels of maturity and compare ourselves and others against them with little consideration of “why?”.

In order to leverage new features, avoid the judgement of our peers or even ourselves, we’ll go to great lengths to create patterns of best practice which decouples concerns, increases testability and complies with the latest guidance of our peers – however much work that may take. We must avoid the Anti-pattern, lest we be judged.

But the Anti-pattern is still a pattern, so suggests some level of thought and maturity.

I’m reminded of the Capability Maturity Model (CMM), which is a model of maturity applied to organisations to identify whether their processes are chaotic or structured so are repeatable, measurable, testable and therefore able to be improved. Of course, the software industry hasn’t allowed itself to avoid its own naval gazing and has come up with various mirror models. Many of these are arbitrary and perhaps form an extra string to a consultant’s bone, such as the Software Development Maturity Model, the Software Assurance Model, and of course there would be an Agile Maturity Model developed by … a consultant.

We’re perhaps too quick to judge software code and not understand why it is what it is.

As a developer, one of my struts for my professionalism is the decoupling of concerns. This is simplified such that no module ultimately depends (or even knows) about any other module. You sort of “wire it up” during a bootstrapping process. At the moment. We used to think that modules should know about each other, but perhaps on a more restricted scale, so the database would be “known” by the behaviour, but not the presentation. Now, technology has come so far and developers’ minds have grown so large that we now realise this is bad practice. So we use Dependency Injection whereby a single element of the code performs the wiring up, invisibly, automatically and somewhat magically. You don’t need to know how, just why. Wait … what?

Dependency Injection develops on the previous best practice, the Service Locator – which is now an anti-pattern. But I know how and why with that pattern. But it was a pattern. A Service Locator could be regarded as a central authority for identifying what modules in your code did what. You’d go to this and ask for the code to access the database or perform a particular process. It was, in effect, a global variable which itself had developed from previous practices.

Last night, about 2am, I found myself writing a service locator Anti-pattern, direct from Microsoft’s evangelists, no less. This is the NavigationService (the clue’s in the name, I realise) which was passed around as a property in view models within Windows 10 apps using the Template10 project. I immediately recoiled. Sure, they’re passing it around as a property, but it is still a Service Locator. But it is also 2am. A pattern’s a pattern. And I went with it.

The fact that there is a scale of these practices, each time evolving to improve their perceived professionalism based on a fad or a consultant’s USP, suggests maturity. Using the Service Locator, I deliberately considered the risk (code smell, limited decoupling, global variable in all but name) with the benefits (it’s 2am) and strategically decided on an outcome. According to the ubiquitous CMM this at least puts me at level 3 – it’s a defined process that is documented and can thus be improved.

Best practices avoid code smells and become themselves anti-patterns. You just need to look to spot this moment and switch tactic at the right time.

The maturity here is the consideration of the time, the rapid delivery that is so craved by Agile techniques and the enthusiasm to get to the next problem and using an anti-pattern – but knowing why and committing myself to returning and improving my own process later. I come across anti-patterns regularly, after all, no developer ever said “wow, the previous developer’s code is certainly better than my own.” But I stop and think. Considering how busy I am now, could this not be where my predecessor found himself? Was that the best practice at the time?

So my Service Locator Anti-pattern is justified. Publicly. Deal with it.

WCF -> JSON Serialization woes and a solution

I’m working on improving the performance of my current web application project at various points. As I had already planned for a WCF interface for third-party use, I thought I’d utilise that, exposing objects as JSON-serialized strings usable by jQuery/ASP.NET AJAX.

Little did I realise that when I was coming up with my Data Framework (I chose Entity Framework) I should have thought about aspects at the other side of my project such as the User Interface as well as the more obvious aspects of scalability, performance in relation to a pragmatist view of what is needed in the “real world” (therefore, nHibernate is out).

My WCF service had an exposed service that would return a Client object (actually, an interface IClient) and return it as JSON. Simple.

No, I hit a number of issues with this.

1/ Investigations at StackOverflow indicated that Interfaces cannot be exposed through serialization. Makes sense, really, but dents my idealistic view of presenting interfaces and no conncrete objects to third-parties via my API. So I was going to have to either return my concrete object or reduce my return value to a JSON string, thereby bringing serialization “in house” and not relying on WCF to serialize it for me.

From:

[OperationContract]
[WebInvoke(Method="POST",BodyStyle=WebMessageBodyStyle.Wrapped,ResponseFormat=WebMessageFormat.Json)]
IClient GetClientJson(int clientId);
I went to:
[OperationContract]
[WebInvoke(Method="POST",BodyStyle=WebMessageBodyStyle.Wrapped,ResponseFormat=WebMessageFormat.Json)]
string GetClientJson(int clientId);

2/ This actually dodged the issue of the attribute configuration on the service itself, which was becoming a nightmare. Tweak it at the server and it breaks at the client, and vice versa. What was:

From:

[OperationContract]
[WebInvoke(Method="POST",BodyStyle=WebMessageBodyStyle.Wrapped,ResponseFormat=WebMessageFormat.Json)]
string GetClientJson(int clientId);
I went to:
[OperationContract]
[WebInvoke(Method="POST",BodyStyle=WebMessageBodyStyle.Bare,ResponseFormat=WebMessageFormat.Json)]
string GetClientJson(int clientId);

3/ Next was serializing the object into JSON. I was getting the “The type ‘xxx’ cannot be serialized to JSON because its IsReference setting is ‘True’. The JSON format does not support references because there is no standardized format for representing references. To enable serialization, disable the IsReference setting on the type or an appropriate parent class of the type.” exception. As I was essentially getting this at the client, it suggested my WCF endpoint configuration was wrong. Looking deeper, it turns out that Entity Framework objects are marked with IsReference=True, meaning the native DataContractJsonSerializer of WCF cannot serialize Entity Framework objects. I proved this by doing a manual serialization:

string jsonClient;
IClient client = GetClient(7);
DataContractJsonSerializer ser = new DataContractJsonSerializer(client.GetType());
using (MemoryStream ms = new MemoryStream())
{
    ser.WriteObject(ms, client);
    jsonClient = Encoding.Default.GetString(ms.ToArray());
}
return jsonClient;

4/ I needed to serialize using a different serializer, so thought I’d use the ASP.NET AJAX Serializer, which also didn’t work, this time falling over the exception “A circular reference was detected while serializing an object of type xxx’.” The type it was complaining about wasn’t in the object so it was clearly navigating deeper into other objects to find that particular Type anyway.

5/ So now I am left with no other option but to either do it myself or use a third-party library. I’m using Json.NET, which I spotted on Scott Hanselman’s blog and seems to be robust enough and simple enough for most purposes. So my code now looks like:

string jsonClient=null;
IClient client=GetClient(1);
JsonSerializer jsonSerializer = new JsonSerializer();
jsonSerializer.Converters.Add(new JavaScriptDateTimeConverter());
jsonSerializer.NullValueHandling = NullValueHandling.Ignore;
jsonSerializer.MissingMemberHandling = MissingMemberHandling.Error;
jsonSerializer.ReferenceLoopHandling = ReferenceLoopHandling.Error;
try
{
     using (StringWriter sw = new StringWriter())
     {
          using (JsonTextWriter jtw = new JsonTextWriter(sw))
          {
                 jsonSerializer.Serialize(jtw, client);
          }
     }
}
catch (Exception ex)
{
       ex = ex; // have a breakpoint here so can inspect exception
}
return jsonClient;

Notice I have set ReferenceLoopHandling to ReferenceLoopHandler.Error. This is to try and catch the same Reference Count issue that ASP.NET AJAX JSON Serialization catches. (Actually this was added after realising I had StackOverflows occurring). Sure enough, I have another Reference Count issue as the Exception does get caught and the error is related to possible infinite recursion.

The JSON.NET Framework allows me to disable serializing potentially problematic objects, but this would require applying these changes to elements of code “Bhind the wall” of my API – and essentially add Web-specific functionality into a domain that is supposed to be platform agnostic. This is not an option for me.

So I appear to be stuck. Other than rendering the JSON myself through a StringBuilder, I’m pretty much stuck on this now. Maybe something will hit me in a flash of inspiration. Until then, it’s good ol’ StringBuilder for me.

Update: The Solution:

Thanks again due to StackOverflow, (John Saunders and Craig Stuntz) I’ve figured out how I’m going to do it. It’s not as pretty as I would have liked, but pragmatism wins out again.

Here it is from start to finish. My UI generates an event that is picked up by some JavaScript. This runs:

var wcfProxy = new serviceProxy("../api/wcf/ClientBroker.svc/");
wcfProxy.invoke("GetClientJson", { clientId: 7 }, updateClient, updateClientError);

serviceProxy is RickStrahl’s WCF wrapper, which has two callbacks, success and error (the last two parameters, respectively). The Invoke method invokes the WCF service and obtains the result. The WCF service is exposed via the Interface:

[ServiceContract(Namespace = "xxxWCF")]
public interface IClientBroker
{
     [OperationContract]
     [WebInvoke(Method="POST",BodyStyle=WebMessageBodyStyle.Wrapped,ResponseFormat=WebMessageFormat.Json)]
     string GetClientJson(int clientId);
}

Note that the Body STyle is Wrapped. I couldn’t get it working in Bare mode at all. (Despite telling me it had logged messages in the Windows Event Log, no events were to be found).

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class ClientBroker : IClientBroker 
{
     public string GetClientJson(int clientId)
     {
            string jsonClient=null;
            IClient client = GetClient(clientId);
            var j = new { ID=client.ID, BusinessName=client.BusinessName };
            JavaScriptSerializer s = new JavaScriptSerializer();
             jsonClient=s.Serialize(j);
      }
      return jsonClient;
}

Notice I am using Anonymous Types to create a new type which is free of Entity Framework idiosyncracies.

This generates a wrapped JSON string:

{"GetClientJsonResult":"{\"ID\":7,\"BusinessName\":\"XYZ Ltd\"}"}

When returned to the client, the success callback is called:

function updateClient(o) {
         eval('var z=' + o');
         alert('BusinessName=' + o.BusinessName);
}

And the Business Name of the requested client is displayed.

It just goes to show that Microsoft may put all the features they like into C#, and you might very well know they are there. But you’re not going to use them until you need to use them, and then you need to know that you need to use them! Variant types are, to me, an uncomfortable throwback of those bad VB days but sometimes they can prove useful when it comes to the crunch, I’m just keen on restricting my use of them to the absolute minimum so the very premise of a type-strong language is not lost.

Another stone passed.