Chaos Engineering is a hot topic and very cool to dive into. But knowing where and how to start can be a challenge. In this series, I want to demonstrate different sides and technologies you can use. In the first post: Simmy, a package to inject different kinds of chaos in a .NET project.
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.
- OLDER POSTS
- page 1 of 2