Life Through a Lens – When to use Glass Mapper

This post is one that there is less of a right or wrong answer on, but it is my approach on how and when I look to use Glass Mapper in my solutions.

Continue reading


100% Code Coverage for Unit Testing is attainable (even in Sitecore)

This should hopefully be a short and probably quite marmite post.

As the unit testing debate rages on with should we / shouldn’t we? How much does it cost? How long does it take? How much of it should we test? I have continued developing my skills as a developer, lead and designer of solutions. During this time I have learned a lot about approaches to unit testing and how I could achieve better ways to test my solutions.

I do qualify what I am about to say with the following: I have been doing automated testing in some guise or other since the middle of the last decade. As such, I have been through multiple generations of the pains that developers now face in the modern era (believe me when I say, the record / replay model for early mocking frameworks was far from the ease of the current NSubstitute / Moq we have now). Also – code coverage is a metric, like all metrics – it has it’s place and I believe that it is a very worthwhile one to isolate out untested (and often potentially flawed or unknown) area’s of your codebase. As a metric, it has to have some intelligence applied the other side of it to see what it is that is untested and refactor / test accordingly.

The Common Arguments & Questions
I am going to set aside the should we (not) unit test our code. My belief is very simple – we should and we should also achieve 100% test coverage. Below are listed some of the most common ones which I will cover.

  • It has no logic – why should I test it?
  • It is too difficult to test.
  • It takes too long to write tests

Continue reading

Developer Isolation – the mushroom cupboard should see the greenhouse

A slightly strange title, but let me explain. First of all – it’s possibly self evident, but for those who don’t see it – developers in so many industries are treated similar to mushrooms – keep them sustained in a dark room and they will produce useful material. On the other hand – we have marketers / designers / project managers. The former two of which are (and rightly so in many instances) considered to be the driving forces in their field and thus are exposed to the sun (the clients / world) by virtue of glass walls & ceilings.

I have for many many years been both a developer and a social person. I enjoy interacting with clients / fellow developers & others – be them from media agencies or ‘end’ clients (ie: Sitecore Customers) and I have found distinct differences between the way different organisations interact with their own developers and (from a personal point of view) what I consider to be a disparity in how productive the developers can be directly linked to how close they are to the problem.

In this post I will explore why developers (mushrooms) should be allowed out to see the wider picture (greenhouse) more regularly.

Continue reading

Life Through a Lens – ORM Mythology & Glass Mapper Relative Performance

Recently I read this set of posts:

A post from Konstantin Cherkasov claiming Glass to be 2000 times slower than the Sitecore API

A post from Kam showing Synthesis to be 3x slower than the Sitecore API

and finally a post from Richard Seal showing Fortis performance:

In this post I look more into what makes this a fairly useless test in the real world and debunk the idea that Glass Mapper is actually 2000x slower than the Sitecore API.

Continue reading

Life Through a Lens – Mappers and Wrappers

Mike Edwards (at SUGCON 2015) did an awesome presentation on data modelling (I would highly recommend you check it out if he re-runs it) on the pros and cons of how to model data. Glass Mapper (unlike wrapping frameworks – Synthesis / Fortis) is uses the Data Mapper pattern to represent data. He also wrote a great post here –

This gives distinct advantages in the functionality it can provide in terms of its exposure of native .net types, its ability to be able to read / write between databases, control of serialization, non-reliance on code generation, mocking, testing, caching etc.

It does also have the downside of being heavier on instantiation in comparison to simply wrapping the item and performing casts on demand. It is also further away from the originating record. This also means that unlike wrapping frameworks, the number of mapped properties will actually also impact the overall performance.

Continue reading

Sitecore 8 dialogs not working?

Recently I’ve seen Sitecore fail to load the JavaScript files for Speak and so break using the Sitecore desktop by failing to load dialogs in the content editor and in the control panel. This can happen in a couple of ways and the reasons behind it are pretty subtle. The issue I found for this post was that the SPEAK javascript files were not loading.

The SPEAK system relies on a set of config files in the App_Config/Include folder and client libraries inside the sitecore/shell folder. To ensure that the configuration is loaded correctly and the JavaScript files are returned, you need to check:

  1. ‘/App_Config/Include/.Sitecore.Speak.Important.Config’ – make sure this doesn’t have the hidden attribute set. If you need to, remove the ‘.’ prefix to force a refresh
  2. Double check that all the client assets also don’t have the hidden attribute set.

To test that everything is ok, visit the following URL: <Your_Host>/-/speak/v1/assets/main-1.2.js

You should see the require.js calls setup and loading the libraries necessary for the Sitecore desktop. In another post I’ll cover how you can turn on minification and etags!

Hope this saves you some time!


Unit testing with test harnesses

One thing I have noticed from many developers when setting up unit tests is that they like their Setup() methods. This is fine for example (shameless plug) if you are looking to integration test against something like Glass Mapper for Sitecore and want to initialise the configuration before you run your test. However, all too often, I see it used to set up things like mocks, and its this that I disagree with. So I guess for want of a better term – I created what I will (I think it’s probably technically a Builder pattern really) a ‘Test Harness’ pattern.

Continue reading

Did you really mean .Controller() in Sitecore MVC?

Real short post this one, but I have seen this a few times from different developers, so I am now considering that this is a common mistake and can be disastrous for performance.

The mistake is this – developers using code like the following:

@Html.Sitecore().Controller("ControllerName", "MethodName");

This code is fine and dandy IF you want to execute a controller with frills. HOWEVER, the number of times I have seen it used on the Layout to bring in Metadata, Header, Footer or any other statically bound rendering. This WILL BYPASS Sitecore’s output caching mechanisms altogether, so every page of your site (potentially) execute every controller added in this manner.

In the code below, I have simply created a controller rendering in Sitecore (though could be any) and used its ID to display the statically bound rendering using @Html.Sitecore.Rendering().

@Html.Sitecore().Rendering(RenderingConstants.MetaData, new { Cacheable=true, Cache_VaryByData=true })

Note also the EXPLICIT caching, at the time of this post, Sitecore still has an MVC based bug that means the rendering items caching settings are ignored altogether (there is a patch and I hope it will become core)

Continue reading

Thoughts from an opinionated developer: API design, mocking and sitecore

A few thoughts for the weekend in my usual opinionated way. Please take these with a measure of whimsy!

Lets kick things off and poke about with the topic of API design. Now if we’re fair this topic has been done to death. That said, any topic like this is well worth re-visiting too. In any form of programming, there are always going to be best practises but our application of these should always be on a ‘well it depends’ nature.

We see this quite often in how an API is designed. Good practise tells us that it should be SOLID but the steps to achieving that in the confines of your
project can vary quite a bit. Its here that rigid adherence to ‘best practise’ without allocating a good helping of common sense and experience can stunt or even ruin an API for general use.

Continue reading