Jeremy Davis
Sitecore, C# and web development
I've been involved in a few discussions about the scope of projects to upgrade existing Sitecore instances in the last few weeks, and quite a lot of that discussion has focused around the "development environment" aspects of the upgrade work. So I thought I would write down some of the things that have come up in my conversations.
It's school holidays as I type this, which means I've been out of the office keeping kids entertained rather than doing anything interesting with code. But all is not lost – because it leaves time for playing some games instead. That reminded me of a conversation I had at Sitecore's Symposium last year about "games I like because they appeal to me as a programmer" – so I thought I'd make a list of the stuff I've enjoyed wasting time with in the last few years (When I've not been playing Minecraft or Terraria with my eldest), in case they appeal to anyone else...
Something I've learned over the course of many years working in IT is that when you hit a difficult to explain problem it's very easy to say "it's the runtime's fault!" or "that's a compiler bug" to cover for the lack of explanation for your problem. The vast majority of the time, it's not true though. It's just a subtler bug in your own work that you can't see yet.
Every so often, however, it is true. And it turns out the issue I discussed the other week about Sitecore rendering a Razor error when you asked for a media item may well be an example of this.
I wasn't at SUGCON this year, but I followed the event on Twitter and have read a few of the write-ups that have been posted since the event. A popular topic this year has been applying machine learning to Sitecore in the quest for ever cleverer personalised experiences. It's fascinating stuff to read about, and I'm sure it has great potential for the future, but what I didn't see much discussion of was the possible down-sides of using "AI" for these tasks rather than people making choices. So allow me to put on some comedy horns and play devil's advocate for a bit...
If you spend your life working with software, you can't help but collect a few stories of issues that defied your understanding – and I came across a great example with Sitecore recently. I haven't managed to decide if this is an issue that can happen to others, or whether it was completely specific to the setup of this particular site. But since I got few useful results from Google when I was trying to solve this, I figure it's worth writing about it just in case someone else sees a similar problem in the future...
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?
It's easy to get distracted by all the shiny big features that get deployed in new releases of Sitecore, but every so often a little gem slips past almost without comment. Except in the release notes...
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?
Every so often you come across a small config change which does stuff you just did not expect. I hit an issue around this recently, which I figured I should document to try and prevent anyone else getting to spend time with diff, scratching their head for as long as I did...
A lot of projects I've worked on over the years have had requirements about consuming content feed data over the internet. Whether they're Sitecore projects or not, "we need to display the contents of an RSS Feed" is a fairly common requirement. It should be nice and simple. There are standards and schemas for feed formats like RSS and Atom, so the data should be predictable and easy to handle...
Unfortunately, back in the real world, this rarely seems to be the case. I still regularly come across feeds which don't match the schema, or in extreme cases feeds that aren't even well formed. Sadly some people still seem to think that string concatenation is the way to build XML...
So what are your choices for handling feed data, and how can you try and get around bad-data challenges?
