Jeremy Davis
Sitecore, C# and web development
I spent some time this week looking at a client site whose analytics data was missing GeoIP information. Since they had a valid license for Sitecore's GeoIP lookup service, this was a bit confusing. So, continuing my battle to write up all the unexpected scenarios...
I've been reinstalling some PCs recently, and one of them is the machine I play games on in front of the TV. My eldest child still enjoys a bit of Minecraft every so often, so I needed to put that back on my freshly formatted machine – but this proved more difficult than I was expecting.
I'm pretty sure I must have encountered this issue before, but since googling failed to find my blog, I seem to have failed to write the solution down last time 😉 So, in order to save my future self working this out for third time...
I read a blog post earlier this week that talked about the benefits of compiling your View files to increase performance in Sitecore applications. Reading that post (which
I stupidly failed to keep track of the link to, so can't reference it now
the comments pointed me back to) reminded me of an interesting issue that came up on a project I was looking at recently. If you're interested in the raw performance of your Sitecore sites, you might want to consider this as well when you're planning your views:
A few weeks back I wrote about spotting site performance challenges in the patterns you might see in trace data. But over the years I've noticed another set of repeating patterns that can be relevant here: Those of how a development team can find itself thinking and acting in the run up to a project hitting problems.
If any of these resonate with you and your team, maybe it's time to take a step back and think about how you can improve things?
Sitecore's config patch files are great. But sadly it's entirely possible to cause yourself headaches with them. I've written before about how it's possible that small typos can cause big issues. In that style, a colleage brought an issue to me recently which was an interesting new variation on this fun...
News stories about hacking and malware are depressingly common these days. Here in the UK I think we've not really dealt with all the fall-out from last May when parts of our health service (along with many other businesses) were hit by the "Wannacry" ransomware worm. Yet another security incident happened the other day which will get less press coverage (since it's nowhere near as dramatic) but has bigger implications for us as web develelopers...
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:
It's a pretty common requirement that deploying instances of Sitecore will require slightly different configuration on different servers. Different roles, like content management and content deployment, will require different settings and features to work. So it's not surprising that there are a variety of approaches to how you manage this configuration in your projects.
In the past I've often made use of separate config files, where you have a file for "config changes needed on all servers" and then further files for "config changes needed for CM servers", and even down to the level of "config changes needed on server CD01" if necessary. This works fine if your deployment process understands which files should go on which servers.
Recently, however, Sitecore have started to offer a "role based configuration" approach in the configuration of v9 – so you can deploy a single config file and the server can pick and choose sections of its configuration based on what role it is performing. But back in the real world, most of us are still supporting V8 (and older) sites, so is it possible for them to adopt something similar to this idea? Here's one approach that achieves something similar:
I've been doing some work with Release Management in Visual Studio Online recently. Overall it's been a pretty positive experience, but there was one face-palm inducing moment I came across which needs writing down so I don't fall into the same trap next time I have to do this. When you're working with local release agents, you mustn't forget the security settings that your agent's server is configured with...
A challenge I've come across a number of times while working with PowerShell scripts for Sitecore is that scripts sometimes have other files they depend on. Making sure that your scripts and their dependencies stay in sync can be a challenge at times, especally when scripts get reused across an organisation. So what approaches can you use for this?
