Adventures in IT

Azure Active Directory is a great product and is invaluable in the enterprise space. In this article we'll be setting it up to provide tokens for the OAuth2 client credentials grant. This authorization flow is useful when you want to authorize server-to-server communication that might not be on behalf of a user. This diagram, by Microsoft, shows the client credentials grant flow. From Microsoft documentation  The flow goes like this: The client sends a request to Azure AD for a token Azure AD verifies the attached authentication information and issues an access token The client calls the API with the access token. The API server is able to verify the validity of the token and therefore the identity of the client. The API responds to the client Setting up Azure AD as an OAuth2 identity provider The first step is to create applications in your AD for both your API server and the client. You can find step-by-step instructions on how to register the applications o...

LXD logo from Ubuntu blog Selling a software package that is deployed to a customer data-centre can be challenging due to the diversity found in the physical infrastructure. It is expensive to make (and test) adjustments to the software that allow it to run in a non-standard manner. Maintaining a swarm of snowflakes is not a scalable business practice. More deployment variations means more documentation and more pairs of hands needed to manage them. Uniformity and automation are what keep our prices competitive. Opposing the engineering team's desire for uniformity is the practical need to fit our solution into the customers data-centre and budget. We can't define a uniform physical infrastructure that all of our customers must adhere to. Well, I suppose we could, but we would only have a very small number of customers who are willing and able to fit their data-centre around us. We are therefore on the horns of a dilemma. Specifying standard physical hard...

For something to be truly awesome, it must be "web scale" right? The rather excellent video just below shows how hype can blind us to the real values of a technology. It's quite a famous trope in some circles and I think is a useful parallel to the excitement about blockchain. In it an enthusiastic user of a new technology repeats marketing hype despite having no understanding of the technical concerns involved. Watch the video and you'll hear every piece of marketing spin that surrounds NoSQL databases. I usually get very excited about new technologies but I'm quite underwhelmed by blockchain. In the commercial context I see it as a great solution that really just needs to find a problem to solve. Lots of companies are looking for the problem that the blockchain solution will solve. Facebook has a blockchain group that is dedicated to studying blockchain and how it can be used in Facebook. They don't seem to have found a particularly novel use ca...

Image: Pixabay Breaking your application down into components can be a useful approach to a "divide and conquer" methodology.  Assigning specific behaviour to a component and then defining interfaces for other components to access it allows you to develop a service driven architecture.  I'm in the process of decomposing a monolithic application into services that will eventually become standalone micro-services.  Part of the task ahead lies in determining the service boundaries, which are analogous to software components for my micro-service application.  I want components to be modular to allow them to be developed and deployed as independently as possible.  I'm using the approach suggested by Eric Evans in his  book on domain driven design  where he describes the concept of "bounded contexts".  I like to think of a bounded context as being for domain models as a namespace is for classes.  These contexts are spaces where a domain mo...

Image: Pixabay SOLID is a mnemonic acronym for five object-oriented design principals that are intended to make software designs more understandable (see Wikipedia ). They were promoted by a chap called Robert C Martin who has been programming since before I was born and is an authority on writing clean code.  Laravel is a PHP framework that implements the model-view-controller (MVC) pattern. A lot of people think that their responsibility for OOP design ends with adopting a framework, but actually Laravel is relatively un-opinionated on your OOP design and you still need to think about writing code that is testable and maintainable.  The reason that SOLID principals matter becomes apparent when you work on a single project for a long time. If you're writing throwaway applications for clients that you never expect to work on again (presumably because the client won't hire you again) then the quality of your code doesn't matter. But if you're the guy stuck ...

I'm busy writing an Ansible script and want to test it locally before trying to deploy it anywhere.  The easiest way to try and make my local environment as close to my deployment environment was to set up a network of Virtualbox VMs. The problem was that I've always configured my VM's to use NAT networking.  I ssh onto them by setting port forwarding and have never really needed them to have their own address. The solution to this problem is pretty simple.  Just stop the machines and add a new network adapter of type "Host Only".  This adapter will handle communication between the guest and host machines. The trick is that you need to configure the guest OS network interface too. To do this SSH onto your VM and run "ip add" to list your network adapters.  If you're like me and started with NAT before adding "Host Only" as your second adapter the output should look something like this: You need to identify the adapter that is y...

Image: Pixabay Calling PHP a double-claw hammer is a bit of an in-joke in the PHP community .  A lot of people bemoan PHP as a language – it's fashionable to do so and it seems to be a way to look clever.   The joke came about from a blog post where somebody pointed out all of the problems with PHP (here's a rebuttal -  https://blog.codinghorror.com/the-php-singularity/   ) Anyway, PHP is a warty language that sucks in academic circles but it doesn't matter because it's really good at web stuff, there are lots of people who know it (so it's cheap to hire), there are lots of libraries and frameworks (so it's cheap and fast to develop in).  The commercial world is willing to overlook the academic warts. I'm busy helping to improve the performance of an API server.  As part of my effort I'm profiling calls to the endpoints.  I'm using Blackfire to generate call graphs and also logging the sql queries that the ORM is producing so that I can check...