A while ago we noticed a performance problem with Seq and the other applications that run on the same server. As it turned out, Seq allocated all the memory and left next to nothing for the other applications. A restart of Seq will only be a temporary solution, for a more durable one we need to restrict the memory consumption of Seq. Luckily, we can do that with a simple change in the configuration.
We use AsciiDoc as the format for our documentation for the user group project. AsciiDoc is a bit like Markdown, but it supports multi-file documents out of the box and without any quirks.
We use the Ruby app Asciidoctor to turn our AsciiDoc files into a PDF as part of our build job. Since building the whole application takes time, it is not the fastest way to get feedback when we write the documentation. To shorten the feedback cycle, we put Asciidoctor into a development container to create the PDF whenever we want to check something.
I was a happy user of the Moq library for the last 12 years. I liked the simplicity of Moq and how it allowed me to write tests first and then incrementally build the functionality.
Unfortunately, the creator of Moq is currently doing his best to kill the project. As he declared, either his spyware SponsorLink strong-arms enough individual developers into sponsoring him, or he will quit developing Moq. This leaves us in a lose-lose situation and for me it is time to move my private projects to another mocking library.
I played with a few alternatives and finally settled with NSubstitute. It covers all my use cases and offers an even simpler syntax than what I know from Moq.
My Ubuntu machine nagged me with notifications like this one:
Pending update of chromium snap: Close the app to avoid disruption (5 days left)
On this day 10 years ago, I was putting the finishing touches on the first blog posts I was going to publish on this blog. What started with a 12 posts series on RavenDB continued for much longer than I had anticipated. Including this post, I published 580 posts on various topics covering .Net, Python, SQL, and Testing:
As the final post of the series on our .Net 6 migration, we look at our experience of running our new .Net 6 application in production. You can find the other parts of the mini-series here:
While our migration from .Net 4.8 to .Net 6 worked better than expected, we found a lot of annoying incompatibilities that took us hours to figure out. In this post I collect the 10 most frustrating differences to give you an overview on what to expect when you upgrade your applications to .Net 6.
This is part 2 of the mini-series on the .Net 6 migration:
For our most important application, the migration from .Net 4.8 to .Net 6 was an adventure. Now that it successfully runs in production, I take the opportunity to share our experience with the migration of our biggest application and the obstacles we run into.
This is part 1 of the mini-series on the .Net 6 migration:
If I run into tasks that I must repeat countless times, I try to automate them as much as possible. Since we always add the same dependencies to our test projects, we thought it would be a great idea to create a project template that has all the necessary settings already in place. Let us figure out how little effort it takes to create our own project templates for dotnet, Visual Studio and Rider.
While updating to Bootstrap 5, I had a few elements that did not look as they should. The Chrome Developer Tools are great to show you all the different styles and where they are from, but if you need to figure out what part exactly is missing, the Developer Tools do not help that much.