Things with code

Using queryServiceEndpoint Intro So, this is the reason for creating this blog. My frustration with not being able to find any documentation on how to use this feature. Checking the Azure DevOps REST API documentation , I can see this option is available, but there didn't seem to be anyone on the internet who had a working implementation. And the documents from Microsoft didn't help either. So in the end, after some trial and error, I figured this out and decided it might be useful for others to have an example to work from. Why this setup is needed Normally, you could connect the widget, which is running in the browser, directly to a REST API, have it consume the information and then show the values you extracted. However, this means you expose that REST connection and all details necessary to access that API in source code that is run in the browser. If this can be safely done, the party you are consuming your data from will have to set your domain as a valid locat

Ok, so this is a first, sort of. As a hobby photographer, I usually just publish on my own site, pictures, perhaps a few words, and that's it. Good enough for friends and family. In my professional work, being an IT engineer, I have written a few articles, but usually didn't feel the need to share. But I've spend the last couple of days working on a piece of code that should have been a breeze to build, but due to a complete lack of documentation turned into a real headache to make it work. My usual way of solving things is googling for answers because almost always someone else has run into the same challenge you're facing and the internet is your friend. Not this time. Diving into the source code of SDKs, APIs and with a lot of trial an error I got things to work. So perhaps this time, I'm supposed to be the one to write things down, so others can just Google the answer. Hence the blog. I'll be dumping stuff I run into and figure out here and might also

After some interesting discussions I had at a customer the last few days about the use of workitems to track progress and capturing requirements, I started to reflect on what experiences I've had in projects. One of the classic problems has always been the requirements process. Are non-functional requirements any different than 'normal' requirements, how do you capture requirements and keep them up to date as the needs of your customer change over the course of the project? The classic way of handling requirements is of course the 'big' design up front. Especially in waterfall, everything is written down to such a level that an estimate can be given about the development cost (and hopefully also about testing cost) and any new insights by the customer happen as a change. After the project has finished of course. Expect one or more quite thick Word documents with hopefully some diagrams and start building this. When changes happen, the word documents should b