Jeremy Davis
Sitecore, C# and web development
Now that Sitecore 10 is out, I've been having a dig into the new Docker approach that's been released. There are some interesting differences here between Sitecore's official approach and the way the community scripts I'd experimented with worked – and I've learned a few interesting new things as a result of having a read of the examples provided. Here are the things that caught my attention:
I've got a project on the cards that I'd like to use docker containers for, but we're talking about using SolrCloud for search. Right now, there isn't a SolrCloud container in the Sitecore community container repo. So I started thinking about what would it take to make one.
We spend a lot of time worrying about the marketing content, and the general website text and images in Sitecore. A lot gets said about patterns for organising that content. But some projects have information that comes from external systems that needs to be rendered on the website. And plenty of sites choose to integrate that into their main content tree. Over the years I've bumped into a few problems because of this – usually because I find myself supporting something where poor decisions were made early in the design process for the integration. So here's some things to think carefully about if you're planning work that relies on back-end data:
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.
If you're looking for the simplest possible developer setup for Sitecore then creating an ASP.Net web project, dropping Sitecore over the top, configuring it for shared databases and checking it in to source control is the answer. Back in the day it was an accepted pattern to to work this way – so you could click "play" in Visual Studio to run your site. And I still find myself workig on projects running that way. But today this is considered a bad idea. So why do I keep finding projects set up this way, and why isn't it a good approach?
After I presented at a couple of user groups recently, some people asked me about how I organised the video demos in my deck. It's a question I've been asked a few times over the years, so I figured this might be a good time to answer it...
...it's easy to get your fingers burned. I was looking at an issue with personalisation recently, which reminded me that those little details in the docs, which change between versions can often be the most important ones.
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...
My moment of confusion from a while back came in the middle of a big chunk of client development work. The solution already used the generator-helix package, but the work needed to make use of TDS, rather than Unicorn. Since I was going to be involved in creating a set of new features, and potentially a load of TDS projects, I wondered what it would take to make the generator-helix package support TDS...
Symposium 2019 seems a loooong time ago now – but it was only last November. Back then, I did a session on understanding the basics of Solr and SolrCloud to help Sitecore developers with their production deployments.
