My main project is using OData a lot and one of the requirements was to ensure that certain properties should not be updatable via PATCH - this is to ensure the integrity of the object e.g. audit fields should not be changeable post-hoc. There’s a couple of possibilities, depending on your use case… You want to exclude the changes if they are supplied You want to throw an error if non-editable fields are updated.

I’ve released a little project Meerkat.NameParser which assists in splitting up personal names into their component parts. This code has been around in one form or another since around 1988 when I wrote the first version in Informix 4GL as part of a project for a client. Subsequent versions were written in Clipper, Visual Basic and this one in C#. It’s not perfect by any means but on projects I’ve used it on we were getting error rates of ~2 per 100K.

One of my current projects is using SpecFlow for testing some complex security logic; there are lots of scenarios so the BDD style of testing is well suited to the problem. I wanted to use the same style of testing for some integration testing where the client is talking to my API but hit a problem of how/where to construct the container as even the client library uses dependency injection to construct itself.

Couple of changes released today, one to Meerkat.Security and the other to Meerkat.Caching. The first was to introduce handling for grant/deny of actions for unauthenticated users. I’d missed this use case before as to date, the project was just used in a corporate Windows environment and so everyone was authenticated by the time we saw them. As I’m now working on a project using Azure B2C Active Directory we are now back to the point where users need to authenticate, so you want to filter the actions they can see/perform before and after they authenticate, e.

I’ve just started blogging again and decided to adopt MiniBlog, a minimal modern blog engine written by Mads Kristensen who also wrote BlogEngine.NET, as SubText has died. It only has a small set of features and Mads intends to keep it like this, the concept is that you make your own fork on GitHub, adding the features you want and publish from there; this has a few consequences… Your blog credentials are visible in your GitHub fork Potentially your content is there as well How to test out new features written by yourself and/or from other forks.