An interesting diversion into procedural generation…

Outside of work I’ve been looking for non-Sitecore things to experiement with recently, and my eye was caught by a bit of interesting game development technology. I came across a discussion of using code to generate game data with a technique called “Wavefunction Collapse”. It’s a simple concept, but it has some interesting results, so I thought I’d have a go at an implementation myself.

A tool to help you build config patches

Recently, I caught sight of a discussion in Sitecore Slack where the lack of tooling for helping you build config patch files came up. For some reason that struck a chord with me, and having mulled over it a bit, I decided I’d have a go at making something to see if it could be done…

A subtle clash-of-namespace bug in Commerce

Recently I got the opportunity to do Sitecore’s “Implementing Experience Commerce” training course, and get certified in the details of how Commerce works these days. While I was doing the lab exercises for the course I hit an interesting bug, which seemed like just the sort of thing that others might encounter.

So if you’re extending the Commerce OData APIs, watch out:

Thinking about errors in code pipelines

A while back I wrote a couple of posts on the subject of how code pipelines can work in a more functional .Net world. I’ve made use of those patterns in some code of my own, and I’ve found these posts have generated quite a lot of questions from readers here and followers on twitter. But I’ve never been quite happy with the implementation in my own code…

Unit testing computed fields

Quick one today. I was writing some code for Sitecore Computed Index fields recently, and it took me more Google Effort than I felt it should have to work out how to write unit tests with FakeDB to verify the code worked. If you want to do that without spending a while searching, the answer is pleasingly simple:

Simple background scheduling

Every so often I come across the need for some simple code to schedule a bit of work in the background of an application. Sometimes because a service (for integration tasks, perhaps) needs to kick off processing every so often, or sometimes because some background part of a larger program needs to happen in parallel with the main execution. A common part of these requirements is that the task should run every so often, but two instances of the task should not overlap no matter how long the background processing takes.

A few times I’ve come across projects with subtly broken implementations of this requirement, so I thought I’d write down a simple approach that has worked for me. That way next time I need it, I won’t have to go digging through git repos…

Spotting common challenges when you’re doing performance tracing

I find myself doing quite a lot of work on performance for Sitecore websites at the moment. Whenever I do a similar job for a group of clients, I start to spot patterns in the sites I’m working on – and it struck me that there are some common performance issues that can be spotted just from the overview graphs you see when you collect trace data.

So to try and help you all improve the sites you ship, here are three that I’ve come across in a few projects recently:

An experiment with automatic tests

I spent some time working with some code recently, which had some annoying habits of failing oddly in scenarios where nulls got passed into constructors. While I was trying to work around some of these issues, it struck me that tests for parameter handling for constructors are one of those annoying things that tend to make unit testing frustrating. They’re annoying boiler-plate to write if you need them, and then a constructor signature changes, you end up with a lot of make-work test changes to do.

So as an exercise in “learning something new”, wondered whether I could automate them in a reasonable way…

Chasing down a browser detection bug

A colleague of mine recently hit upon an odd issue with the Sitecore integration for the 51Degrees browser detection service. It worked fine for most of his testing, but raised an exception in some circumstances. Trying to dig into this and create a test to demonstrate the bug kept us amused for a few hours – maybe it will help you to?

Those assumptions? You should validate them…

The one thing that is true of every aspect of IT is that it is always changing. And that change means that things you were confident of in the past may no longer hold true.

I was reminded of this while sitting in the pub with some developers recently, talking about querying for items by path in Sitecore. The debate about the best way to do this raged, but a common thread of the debate was that it is often said that the fastest way to find a set of items you needed is via a ContentSearch index. That assumptions has its roots in the time when most sites were using Lucene to run queries, and for queries with more complex matching rules. But does that hold true here?