Jeremy Davis
Sitecore, C# and web development
A while back I wrote a couple of posts on the subject of how code pipelines can work in a more functional .Net world. I've made use of those patterns in some code of my own, and I've found these posts have generated quite a lot of questions from readers here and followers on twitter. But I've never been quite happy with the implementation in my own code...
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...
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?
Have you ever needed to write code that detects if the current computer has an internet connection or not? Having recently tried this, it turns out it's not quite as easy as I expected it would be. So since I've banged my head against the challenge, here's one approach to solving the problem that you might find useful:
In my last post I was thinking about a more functional approach to defining pipelines, after having heard about some interesting new code that Sitecore had been working on. Since writing that I've had a few conversations where the topic "but what about if I want a pipeline to come from configuration?" has come up. I've been away from work for the last week doing my civic duty on Jury Service, but I've had some time in between court sessions that I've spent thinking about how last weeks ideas and configuration files might be combined.
So here's one way it could work:
There was a lot of exciting new stuff on show at the Sitecore's recent MVP Summit and Symposium the other week. Plenty of others have written up the general goings on at those events (have a google – there's lots to read), so I thought I'd focus on something more specific that piqued my interest: the novel approach that's being taken to pipelines in some of the new code Sitecore are producing.
One of the things that the masters of Unit Testing say is that tests should always be repeatable and deterministic. No matter when, or how many times you run a test, if the System Under Test stays the same, the results of the test should stay the same. So I found myself a bit confused recently when some tests went from reliable to unreliable results. Turns out the tests were right, and they were pointing out a silly bug I'd introduced by accident...
Most of the time when you need to cache things in Sitecore, it's handled for you with the built in frameworks for data and UI layer caches. Usually your problems are solved by tuning the sizes of the caches and configuring the right caching settings on your UI components. But what happens when you've got bits of data which you want to cache that are neither components or items?
I was having a conversation with a programmer new to C# recently, who was rather confused by something similar to the following bit of code. He'd been looking at the source for a library on GitHub, and he didn't understand why this could run without errors:
To him, it seemed to be risking a
NullReferenceException, as you can't call a method on a null object.
Spending a lot of time developing websites with Sitecore means I've reported my fair share of bugs to support. One particular issue that I came across in 6.6 a while back stands out as my "favourite" issue I've reported – just because the error stops a lot of developers in their tracks thinking "how on earth can this happen?". If you wrote this code, would you think it could crash?
Well it can crash. And to a less experienced developer it can be a very confusing error:
