Jeremy Davis
Sitecore, C# and web development
There's been a lot going on with language development in C# over the last couple of years. But despite all the current change for things like record types and generic maths, there are some changes from older versions that I somehow missed. This week social media put me on to the concept of contextual filters for exception handling. What's that? Read on...
I've spent a bit of time looking at how Regular expressions are changing in the upcoming .Net 7 release. While they do have a bit of a reputation for making people's lives worse (so much there's a well known programmer joke about it) they do have a place in your developer toolbox. So what caught my eye in the new features, and how does code get better with this new version?
I realised recently that I've become quite used to way many web forms let you paste image data straight into a text field. The behaviour of "upload the image data, and insert the correct mark-up for the image" is a really helpful shortcut when you're editing DevOps tickets, or Stack Overflow answers. So I started wondering how easy it would be to add that to the text editing tool I use for writing these blog posts. Turns out, not too hard, because WPF has some helpful extension patterns...
There are bits of the C# language that we don't think about too much when writing websites – and implicit conversions are one of those things. But while I've been messing about with some ray-tracing code in evenings recently, I found a couple of examples they patterns they can be a help with...
I had an interesting discussion recently, about how some code could calculate a "random" but deterministic numeric value based on some data. This made me think of the classic old concept of "checksums" as a possible solution. Here's what I was thinking about:
Last time out I was looking at applying async/await patterns to some pipeline patterns for C#. After I came up with the initial solution I outlined in that post, there was some more back-and-forth in the discussion thread that prompted all this. And that discussion made me realise there was an interesting side effect of the code I wrote, which might lead to some confusing bugs. So back to the drawing board...
Ages ago I wrote some posts about an approach to pipeline-style code patterns for C# code. Recently I got a question on a gist I'd written to go with that article, because someone was having issues adding async code into pipeline components. Async patterns are much more common now, but this wasn't something I'd actually tried. Cue some interesting experiments...
I was tinkering with some C# code that uses
TcpListeners recently, and hit on a strange issue where my code would run fine on on machine, and fail on another. It took me a while to find an answer in Google, so here's a reminder to my future self:
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...
