Andy Butland

There's a fair bit of information a Google search away about configuring Umbraco back-office authentation with providers such as Azure Active Directory, but things change, information gets outdated or doesn't quite apply - so mostly as a note to self, but maybe useful if anyone comes across it, here's a few notes and links I've used in setting this up at the end of 2020 and Umbraco 8.8. First step was to follow the instructions in Shannon's blog post found here , to create an application registration in Azure AD and install the necessary NuGet packages into the Umbraco website project. Having done this, and signed in as normal using the default administrator account, there's an option to link the account with Azure AD. First time I tried that, I got the error: Error: "OpenIdConnectMessage.Error was not null, indicating an error. Error: 'unsupported_response_type'. Error_Description (may be empty): 'AADSTS700054: response_type 'id_token

Cross-posting an article written for my company's blog, on my experiences as part of the Umbraco .NET Core transition team .

About 5 years ago, I wrote a series of short articles on the SOLID principles, shared by email to my colleagues as a weekly, Monday morning read. They were then archived for reference to our internal knowledge base. That's getting a revamp and re-platforming now, and given their age, I'm not sure these pieces will be making the cut. Given it's fairly timeless stuff, seems a shame for them to disappear into the virtual ether, so I'll save them for posterity here. The SOLID Principles The SOLID principles are a well established set of tenets intended to guide software design toward a maintainable solution. They are widely applicable and operate at a high level, so are well worth considering for almost any type of application we are looking to build, using any framework or language. For the full set of articles in the series, see: S is for Single Responsibility Principle O is for Open/Closed Principle L is for Liskov Substitution Principle I is for I

About 5 years ago, I wrote a series of short articles on the SOLID principles, shared by email to my colleagues as a weekly, Monday morning read. They were then archived for reference to our internal knowledge base. That's getting a revamp and re-platforming now, and given their age, I'm not sure these pieces will be making the cut. Given it's fairly timeless stuff, seems a shame for them to disappear into the virtual ether, so I'll save them for posterity here. The SOLID Principles The SOLID principles are a well established set of tenets intended to guide software design toward a maintainable solution. They are widely applicable and operate at a high level, so are well worth considering for almost any type of application we are looking to build, using any framework or language. For the full set of articles in the series, see: S is for Single Responsibility Principle O is for Open/Closed Principle L is for Liskov Substitution Principle I is for I

About 5 years ago, I wrote a series of short articles on the SOLID principles, shared by email to my colleagues as a weekly, Monday morning read. They were then archived for reference to our internal knowledge base. That's getting a revamp and re-platforming now, and given their age, I'm not sure these pieces will be making the cut. Given it's fairly timeless stuff, seems a shame for them to disappear into the virtual ether, so I'll save them for posterity here. The SOLID Principles The SOLID principles are a well established set of tenets intended to guide software design toward a maintainable solution. They are widely applicable and operate at a high level, so are well worth considering for almost any type of application we are looking to build, using any framework or language. For the full set of articles in the series, see: S is for Single Responsibility Principle O is for Open/Closed Principle L is for Liskov Substitution Principle I is for I

About 5 years ago, I wrote a series of short articles on the SOLID principles, shared by email to my colleagues as a weekly, Monday morning read. They were then archived for reference to our internal knowledge base. That's getting a revamp and re-platforming now, and given their age, I'm not sure these pieces will be making the cut. Given it's fairly timeless stuff, seems a shame for them to disappear into the virtual ether, so I'll save them for posterity here. The SOLID Principles The SOLID principles are a well established set of tenets intended to guide software design toward a maintainable solution. They are widely applicable and operate at a high level, so are well worth considering for almost any type of application we are looking to build, using any framework or language. For the full set of articles in the series, see: S is for Single Responsibility Principle O is for Open/Closed Principle L is for Liskov Substitution Principle I is for I

About 5 years ago, I wrote a series of short articles on the SOLID principles, shared by email to my colleagues as a weekly, Monday morning read. They were then archived for reference to our internal knowledge base. That's getting a revamp and re-platforming now, and given their age, I'm not sure these pieces will be making the cut. Given it's fairly timeless stuff, seems a shame for them to disappear into the virtual ether, so I'll save them for posterity here. The SOLID Principles The SOLID principles are a well established set of tenets intended to guide software design toward a maintainable solution. They are widely applicable and operate at a high level, so are well worth considering for almost any type of application we are looking to build, using any framework or language. For the full set of articles in the series, see: S is for Single Responsibility Principle O is for Open/Closed Principle L is for Liskov Substitution Principle I is for I

When working with ASP.NET core one of the features now front and centre is dependency injection, built into the framework. Whether you're familiar with the pattern from using an IoC container from an external library, or are new to it with .NET core, the situations where you can't seem to make use of it start to stick out. In the post I'm going to share a few ways of tackling dependency injection with attributes and filters . These require a parameterless constructor and as such you can't use the typical pattern of constructor injection. I've prepared a tiny GitHub repository with the three examples discussed here. 1. Using service location This first approach isn't for the purists, and you'll risk other developers muttering "anti-pattern" at you, but it'll work. The idea is to use service location, in the constructor to retrieve the required services and set them to class level variables, where they can be used in the various method

Cross-posting an article published on Medium for Zone where I've discussed various features of Azure Durable Functions that I've found useful having come back use to the workflow framework for a recent feature on a project. Click here for a read.

Just thought I'd share a "developing in lock-down" tip, which I inadvertently invented (well, let's say discovered) last week. I'm going to call it recorded rubber ducking . The idea of rubber ducking being that if you talk out a problem, even to yourself, you may hit upon the answer. That wasn't working for me, so instead I felt I needed to ask my colleagues to see if someone could see what I couldn't. Importantly though - and really I was just trying not to waste people's time - I took the trouble to clearly write out the issue. What it was, what I'd found, and what still puzzled me. I planned to then post this in Slack, in one hit with all the information, rather than starting with a "@here, anyone know about X?" type of message and follow up from there. And, as you've probably guessed, the act of doing that was sufficient to see the solution to problem* without even bothering anyone. Clearly the action of writing, and

Another cross-post, writing for my employer Zone, on the benefits of code reviews toward developer productivity, software quality and a supportive and learning-focused team culture.

Cross-posting an article written for the agency I work for, Zone , on moving away from "CMS as a platform" , a concept I first came across in the Thoughtworks tech radar , warning against building too much directly into the CMS/web application, and considering external services, data sources and asynchronous processes.

I took a recommendation from the blog of Gergely Orosz on a recently released book on software architecture, "A Philosophy of Software Design" by John Ousterhout , purchased and have just finished reading it. In short, I'd second the recommendation - it's not a long book, but is packed with good, practical advice presented from the perspective of an academic, mostly based on his views of many implementations of projects by his students. What I particularly enjoyed about it was that it's a book that makes you think as you go... you aren't simply ticking off a list of things you agree with already. Gergely had a few reservations that he outlined in his post , most of which I also agree with, and I also had some of my own - but all in a postitive way as it made me think and question some practices I've used up to now and consider them from a different viewpoint. In the appendix, John lists 15 design principles that he describes fully in the book, whi