Steeds weer kom ik Mermaid tegen als het gaat om het maken van diagrammen. Persoonlijk werk ik graag met (Plant)uml maar meestal moet ik diagrammen dan exporteren naar een afbeelding voordat ik het in de documentatie kan gebruiken.
Microsoft DevOps heeft ondertussen ondersteuning voor Mermaid, Github heeft nu ondersteuning voor Mermaid en aangezien dat twee platformen zijn die ik veelvuldig gebruik lijkt het me tijd om me eens te gaan verdiepen in Mermaid.
Dit artikel is eerder gepubliceerd op de website van Team Rockstars IT. Grote, online services zoals Netflix en Amazon doen het al jaren: Chaos Engineering, het in productie testen van bottlenecks en single point of failures met behulp van chaos. Dit kan op veel verschillende manieren: van het fysiek lostrekken van kabels tot het inbrengen van random gedrag in de code. De mate waarin je dit toepast is natuurlijk afhankelijk van veel factoren en heeft onder andere te maken met de gevolgen van downtime, of slechts deels werkende applicaties.
There are a lot of static site generators around and I have been using quite a bunch of them. While I used most of them for this (personal) blog, I have also used some for professional purposes like documenting software and for team and company-wide documentation. Especially Sphinx has proven itself to be quite useful.
I want to create an environment with the following requirements:
- Hosting in an Azure Web App
- Protected by Azure Active Directory
- Every project has it’s own documentation (no merge conflicts between teams)
- Use Sphinx but using other generators is possible
In this post I will show how to create a documentation platform which implements the requirements above with only a few lines of code.
It can be a challenge to implement new frameworks or tools in your daily life. Often it takes time to find out the quirks and best practices which can take time and even lead to doubts and abandoning frameworks. I have been using SpecFlow for a while now and I keep finding new ways to tackle issues and get cleaner code behind the specs (I am still having trouble creating clean & clear functional requirements though).
One of the things I keep bumbing into is using settings and sharing code between different specs. In the following example I will explain my latest find: using xUnit fixtures to get test settings and reusable api clients for multiple tests.
My employee has developed an application which “scrapes” data from systems, processes it and sends it to a central database. This is a WinForms application with a few screens for configurations and inspections. I was looking into different approaches for a new version and dived into the options of using a Windows Service.
I forgot where the exact idea came from but at a certain point I thought: what if I can install Blazor as a UI for a Windows Service. I could configure, start and stop, basically do all kind of things with this service if I have a Blazor Interface. I read something about systemd services with .NET too, so I could even create a cross-platform version (not that there is any need for Linux, but just because I can).
Well, after a few hours, I got it working so, in this post I will show you how to create a cross-platform service that can be installed on Windows (Service) and Linux (systemd) and be managed with Blazor.
SpecFlow is a tool which can be used to describe test scenarios and automate the tests. Although I have been using SpecFlow for a while now I never used it for advanced examples where time might be an issue. Lets show a simple example scenario first. A scenario, written in Gherkin, looks like this: Scenario: Add simple item with due date Given the user enters "wash my car" And the user adds a due date of "1-1-2022" When the user saves the item Then the item "wash my car" is added to the list And the due date is "1-1-2022" This scenario is easy to implement, the item will be added and stored.
update (2019-11-08): added a bonus contribution from Bob, written in prolog Just recently I had to work on a huge flow-chart to determine farm types based on the animal transports to and from farm locations. I started out with a small proof of concept but didn’t like the way it turned out. I did some research and learned I was basically creating a so called arrow head (“Arrowhead” anti-pattern ).
In this blog I will try to explain how one can create clean and effective policies to retry API calls and have fallbacks when requests are failing. With Polly it is possible to create complex and advanced scenarios for error handling with just a few lines of code. This week I was connecting an eCommerce web application to an ERP system with REST APIs. There are multiple endpoints, all authenticated with OAuth.
My plan was to write a quick post about some cool things I found and learned this week but I just learned too much (as I do every week). Below are just the highlights, I will try and write more posts like this, especially if I get some cool comments :)
Read about a REST Client, Unit Testing, TFS and more in this post!