Andy Butland

Today I've published two new versions of the Umbraco Mapper package , a package that supports the use of view models, by mapping Umbraco content to custom view model classes (original thinking was Automapper for Umbraco I guess). They are available on our.umbraco.org for download or can be installed via NuGet . I was surprised to see that it's been over 5 years since this package was originally built by myself and some colleagues at Zone - a long time in technology. We're still making use of it though, and as I had some popular demand - well, two people(!) - for a version compatible with the latest Umbraco release, thought it would be good to prepare one. I've taken an approach of restructuring the solution such that there's a common project, containing non-Umbraco dependent core set of functionality, and then created two Visual Studio projects within the solution, one referencing the Umbraco 7 binaries and one the Umbraco 8 ones. That way, I can suppor...

Recently I had reason to condense an approach to decisions around the value versus the effort of testing - specifically unit testing, but likely it applies at higher levels - and came up with the following diagram that I think illustrates it quite well. On it we see two axis: one being the value of the tests and the being how difficult it is to write the tests. We can consider here that code that's complex, expresses business logic etc. is something that's going to be high value, but very trivial code down to the level of property getters and setters likely won't add much, if any. Code that's easy to test will have little or no dependencies that may require mocking or stubbing. Sometimes though code can be is particularly difficult to test, often when tied to platform components that prove troublesome or even impossible to treat in this way. The graph then breaks down into four quadrants: Bottom right - easy to test and high value . This is the sweet-spot wh...

Cross-posting Reviving ZoneBot: rebuilding using V4 of Microsoft Bot Framework

Like most development teams working on modern, Sitecore projects of reasonable complexity, at the agency where I work we've followed the Helix design principles and conventions for Sitecore development in structuring the solution. This means we have 3 groups of projects: Foundation - at the lowest level, these projects may depend on each other but don't depend on any in the higher levels. Modules in the Foundation layer are business-logic specific extensions on the technology frameworks used in the implementation - e.g. Sitecore itself - or shared functionality between feature modules that is abstracted out. Feature - these are projects in the middle layer, which may depend on Foundation projects but not on any in the higher Project level and, importantly, not on each other. Projects here should map to a business domain concept or feature. We've extended the feature level in a small way by introducing the concept of sub-features. For example, for a data import ...

When working with Azure Table Storage and needing to bulk insert a number of records, it's more efficient and reliable to do so by inserting a batch of records in one step, rather than one at a time. On a recent project we've been using table storage as a location to record the log for an import operation migrating information from one content management system into another. As each field was imported a couple of log lines of information were recorded - which were useful for auditing and debugging. Rather than inserting each log line as it was generated, we've batched them up, and then loaded them into table storage in the finally part of a try/catch that sits around the import logic. In this way, we store all the log information in one go. For a few imports though, we found this error being recorded in the application logs: Error processing message, message: An error has occurred. Exception message: The maximum number of operations allowed in one batch has been ...