Following on from the previous post, I want to prove that I can define a schema for metadata and have that metadata returned with core type information in a Web API.

For this POC, I will define the core type (DataEntry) and then dynamic metadata (JSON encoded data). I want the Web API to correctly handle the type information for this metadata and return the correct wire formatting.

This POC uses DynamicObject to be the bridge between the DataType, its metadata and its metadata schema. It provides the type information for Web API so that it can be correctly returned over the wire.

I am looking at the possibility of using dynamic types in a Web API for my current client. They have a need to return data that mostly has the same structure. I want to run a few POCs to see if this is possible.

Rather than store each data type in it’s own data structure (such as a database table), storing core type information and then dynamic fields would be a very flexible outcome. Is it something that Web API will support though?

The first POC is to determine whether Web API will render dynamic types of differing structures. At the same time, can this be done with a Task based API. Here is the first test.

I’ve been running this blog on the Microsoft stack since way back in August 2001 with almost 900 posts. I think that might have even been before blogging was called blogging. My viewpoint on blog engines has changed substantially over the years to the point where the bells and whistles of the ‘modern’ blog engines are not as attractive as they once were.

I’ve now converted the blog over to Jekyll using GitHub pages to make my blogging life a lot easier. As part of this process, I have removed a whole lot of old posts and files that are no longer relevant to the current state of technology. This blog now has half the posts it once was and is much more technology focused.

I’ve been converting my code over to RequireJS and have been battling how to get this to work with the ReSharper test running which uses Jasmine. The main issue is that Jasmine runs the page on load of the browser document (the spec runner) before RequireJS has loaded dependencies. The reason for this is that RequireJS loads dependencies asynchronously. By the time they have loaded, the test run has already completed.

While this is stating the obvious, my JavaScript skills sometimes fail to appreciate that what works in one browser does not work in another. Classic example here is logging information to the console. I recently noticed that IE doesn’t play very nice with a script that does something like console.log. While it might seem strange that console output across browsers might be different, that is just how it is.

The primary issue here however is that scripts will still use the console but the script might not execute in a browser the supports it. This script might be something that you control, but could also be a third party script you import. In either case, there are two things that should happen here. Firstly and most importantly, the script shouldn’t fail because the browser doesn’t support console logging. Secondly, the console functionality should do its best attempt at getting console logging to work when at all possible.

The two go-to packages I use for unit testing are NSubstitute and FluentAssertions. NSubstitute is a wonderful package that solves all the pain points I had testing with RhinoMocks. Similarly, FluentAssertions is an awesome package for running assertions on data with very powerful evaluations. A great feature of both these packages is the really good feedback about failures. There is one scenario however that falls in the cracks of between the functionality of these two packages.

NSubstitute is really good at setting up stub behaviour using predicate or value argument matching and asserting received calls with the same argument matching. FluentAssertions is really good at asserting whether values satisfy specified criteria. The difference between these packages is that NSubstitute works with predicate expressions whereas FluentAssertions evaluates assertions and throws an exception if the assertions fail.

The gap in functionality here is where I want to use NSubstitute to evaluate received calls but the power of FluentAssertions evaluation in the argument matching. This doesn’t work because NSubstitute uses Arg.Is<T> (Expression<predicate<T>>) whereas FluentAssertions will throw an exception. We need the ability to bridge these two packages so that we can have the power of FluentAssertions executing within an NSubstitute argument matcher and allowing the test code to remain readable.

Developers generally like the LINQ syntax with all its lambda goodness. It is fluent and easy to write. Then you do something like dataSet.Intersect(otherData, OHNO!).

Signatures like the LINQ Intersect function seems to just get in the way of productive development. With so many things in a lambda syntax, we are now forced back into the world of IEqualityComparer. The easy fix is to drop in something like a generic equality comparer that will support a Func.

I have posted over the last couple of months about an adapter class that I have been using for using Azure table storage. The adapter has been really useful to bridge between Azure table entities and application domain models. There have been some interesting scenarios that have been discovered while using this technique. Here has been the history so far:

• Entity Adapter for Azure Table Storage
• Azure EntityAdapter with unsupported table types
• Using the EntityAdapter for Azure Table Storage
• Azure Table Storage Adapter Using Reserved Properties

I posted earlier this year about an adapter class to be the bridge between ITableEntity and a domain model class when using Azure table storage. I hit a problem with this today when I was dealing with a model class that had a Timestamp property.

While the adapter class is intended to encapsulate ITableEntity to prevent it leaking from the data layer, this particular model actually wanted to expose the Timestamp value from ITableEntity. This didn’t go down too well.

I’ve just hit a StorageException with Azure Table Services that does not occur in the local emulator.

Unexpected response code for operation : 5

The only hit on the net for this error is here. That post indicates that invalid characters are in either the PartitionKey or RowKey values. I know that this is not the case for my data set. It turns out this failure also occurs for invalid data in the fields. In my scenario I had a null value pushed into a DateTime property. The result of this is a DateTime value that will not be accepted by ATS.