In any large organisation there is going to be friction between various competing dynamics; one of which is whether to decentralise certain functions or to centralise them. Sometimes it makes sense to centralise, sometimes it doesn’t. The desire for centralised control is massive, but it’s often better to let things happen organically as they need to.

Recently we purchased a watch; a purple affair with butterflies to be exact. Didn’t cost much, and we expected it to be perfectly functional until the battery ran out. As it turns out, after a day, we found out that if you press the dial knob in, the watch stops. It was a reputable high street retailer so you’d think the situation would have been quite easy to rectify.

For a number of reasons (some historical, some legacy, some just daft), the optional Interlok components live in various git providers. This isn’t a post that argues that git flow is great; it’s well understood so we use it to remove the friction of understanding a bespoke tagging/branching system. When we do a product release there’s a Jenkins pipeline that builds all the artefacts based on the release branch from git flow release. That means that when we decide that it’s time to prepare for a release, we have to do a git release start on every project and publish that branch; all of which is nice and scriptable.

One of the things that Vagrant (in Hyper-V mode) does if you sync folders with your linux machine is to attempt to mount them via SMB. This can lead to a few problems; you can work through them, but it’s always easier to cut and paste from someone else’s pain right?

Let’s suppose that you have an Interlok instance servicing HTTP requests and the data being transferred around is JSON messages. In the event that an exception happens what would normally happen is an exception is printed in the log file and a HTTP 500 error returned back to the client. What if we want to send more information such as the stack trace back to the caller as a JSON message.