Andy Butland

On a current project I've been looking to employ a cloud design pattern known as queue based load levelling , and to implement it using Azure storage components and functions. The Queue based load levelling pattern The pattern is useful in a range of situations where there's a need for timely and reliable integration between different software systems. In short, the pattern utilises a queue service as a buffer for messages from one system to the other, allowing them to be passed to the destination system for processing in a controlled manner, and at a rate that won’t overwhelm available resources. It can be adopted where one software system must send messages to another but for various reasons we want to avoid a direct connection between the two. One good reason we might want to do this is simply to reduce coupling – the two systems will need to agree on a message format, but ideally we don’t want to tie them to each other’s implementation details any further than that. ...

I spent a partially frustrating but ultimately reasonably successful day recently looking to extend a Sitecore editorial control to add some functionality that would be of benefit to our editors. Our starting point was the built in TreeList control that we were using to allow editors to select images for a carousel. With this we can set a source to limit the selections to an appropriate location in the media library tree. That did the job for the initial release of the feature but we then had to handle some additional requirements, as follows. We need to allow editors to select from two locations, not just one. Specifically they were selecting images for display on a page on a house-builder's website, with the page showing a house that's of a particular type and found on a particular site. So images for the site and the house type were appropriate, and these were stored in different folders. We needed to dynamically set the source of these locations, so they were pic...

Following the previous post on this blog involving an issue we ran into upgrading a Sitecore project from 8.2 to 9, this one is also on the same subject. The issue this time was some unit tests that make use of the FakeDb  library began to fail following the upgrade. Noticing that it was just tests that involved checking the status of layout related fields, with the help of some de-compilation, it was clear that a change had occurred in the Sitecore.Data.Fields.LayoutField.GetFieldValue method that now involve the use of a pipeline components. I found it was possible to resolve this by adding the following to the app.config file, within the &lgt;sitecore&ggt; element, for the test projects containing the failing tests: <pipelines> <getLayoutSourceFields> <processor type="Sitecore.Pipelines.GetLayoutSourceFields.GetFinalLayoutField, Sitecore.Kernel" /> <processor type="Sitecore.Pipelines.GetLayoutSourceFiel...

Working on a project currently with Sitecore CMS, which is currently undergoing an upgrade to version 9. We had this piece of code, used in the context of unit testing classes that inherit from HttpRequestProcessor , such as custom page resolvers. To use these classes you override a method Process() that takes an instance of HttpRequestArgs . Constructing these classes from a unit test isn't straightforward and up to now had relied on a method detailed by James-West Sadler on his blog here . public static HttpRequestArgs CreateHttpRequestArgs(string url) { var httpRequest = new HttpRequest(string.Empty, url, string.Empty); var httpResponse = new HttpResponse(new StringWriter()); var httpContext = new HttpContext(httpRequest, httpResponse); var requestArgs = new HttpRequestArgs(new HttpContextWrapper(httpContext), HttpRequestType.End); // Reflection used to call the private Initialize method on the HttpRequestArgs obj...

Cross-posting an article written for my company blog , looking into different options and technologies available for building web applications suitable for mobile - touching on Xamarin, Cordova, PWAs, AMP and architectural patterns.