Jeremy Davis
Sitecore, C# and web development
I'm working on my first proper Sitecore 9 project at the moment, and got bitten by an annoying bit of confusion while doing some configuration work. If you're tweaking how xConnect works take note, and hopefully you can avoid making the same mistake I did...
Every so often I run up against an issue that's right there in the docs, but somehow has passed me by. This week that issue was Sitecore's new V9 forms implementation, and it's relationship with languages...
Recently I wrote about an issue I encountered where a client's website was missing its GeoIP data (and the related back-end analytics data) entirely. While the changes discussed in that post solved the problem of there being no MongoDB data for GeoIP lookups at all, I continued to see odd issues with many users not being located after those fixes were made. Sorting this out seems to suggest that some of the "common wisdom" about configuring GeoIP for analytics isn't right – so here are my latest findings:
Recently a colleague of mine told me about a suggestion they'd been given about setting up an instance of Sitecore. They were told that you should put your license file into a subfolder of your data directory because the license check enumerates files and folders in the directory containing the file. So if the folder contained other things, this would slow down the check. This sounded odd to me as you have to specify the exact path of the license in your config, so I thought I'd do some investigating, and see if I could prove or disprove the suggestion.
So, putting on my best beret at a jaunty "for science!" angle, here's what I discovered:
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...
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...
