Jeremy Davis
Sitecore, C# and web development
I've written a few things about diagnosing memory issues in Sitecore over the years, but one topic I've not covered in detail is anything around "how to spot when it's not piles of your own objects that's causing the issue". Problems like leaking handles can have an obvious link back to the custom code that you can spot fairly easily in diagnostic data. But not all memory issues do. I was discussing a possible example of this with a colleague recently, and it seemed like another thing to write down...
When I was writing about dealing with memory analysis for Sitecore recently I focused on a site running under Auzre PaaS. But what if you're working in Docker locally? A good question it turns out...
Recently I got a fun question from a fellow dev: After pulling some changes and doing a sync of serialised data they were expecting to see some forms in the Experience Forms editor so they could work on them. But nothing was showing up... The root cause here is a bit of a classic issue that many people will have seen before, but it still seemed worth writing it up. Even if just to emphasise that this has been around for a while and it's still a thing even if you're using containers.
I wrote about diagnosing some issues with static event bindings in a previous post, and talked about finding these issues of "subscribing more than you unsubscribe" with memory dumps. But finding this sort of a problem before it becomes an issue is better if you can, so what techniques might we use for that?
Over the festive break I spent a bit of time trying some of the challenges in this year's Advent of Code. I wrote the logic for my answers using LINQPad, and it struck me that this has become one of my favourite developer tools. So here are a few of the reasons why it's become a key part of my toolkit, and why it might be a useful thing to add to yours too.
A while back I wrote a bit about how you might integrate Extra External ID with Sitecore to provide a very minimal IDAM integration for login. But in the follow-ups to the internal discussions that gave me the idea for that post, my project started talking about alternatives to Entra. So what might you be able to do if you chose Ping Identity instead?
After my recent delve into memory optimisation for non-work code, I spent some time recently investigating a memory issue in a production Sitecore site. The outcome of that was an issue which can be a common problem for .Net code. So in the hope of seeing it less in the future, here are some notes on what I saw and how you can avoid the same trap...
I spend most of my working life building website code at work, and sometimes I get involved in performance work with that sort of system. In fact I've written and presented on that topic for Sitecore in the past. But some code I've been working on in my own time needs much more focus on code performance than that - the maths-heavy code for ray tracing. I've been looking at some optimisiations for that recently. And one thing that this has reinforced for me is how "easy to write" code can have some performance challenges...
I've wanted to add some logic to this site to display article headings as navigation for a while. And I've also been thinking it would be helpful if you were able to link directly to headings. Pleasingly the Statiq engine makes doing this pretty simple, so here's how my attempt works:
Symposium is over for another year. I have mostly recovered from the jet-lag now and I've wrestled my inbox into submission at work. So it's time to write up my thoughts on the conference. I took about 35 pages of notes over the course of the week, plus countless photos of slides. So from all that what stuck out as interesting to me?
