Skip to main content


Stop using pull requests!

Yes, I know. A little bit of controversy in the title of this post could have triggered your attention. But hear me out. I think that the pull request model is a good fit for open source development where people are working in their spare time on projects and want to design, collaborate and review in the open before accepting changes. I don't want to go in too much detail, so if you want to learn more about this model, check out the documentation on Github or the Atlassian BitBucket website. Let me focus on the reason when and why I don’t like to use pull requests. I don’t think they are a good fit for dedicated software development teams working in close collaboration fulltime on the same codebase. In these teams I see pull requests used as a quality control mechanism allowing another (senior) developer to review the changes before approving them and pushing them to the master branch. Pull requests are not a good fit for dedicated software development teams working in c
Recent posts

Bootstrap 5 - Goodbye jQuery

Bootstrap 5 is the first Bootstrap version that no longer has a dependency on jQuery. Of course some plugins and components still require vanilla JavaScript to function but none of them require jQuery. The Bootstrap framework , originally developed and open-sourced by Twitter, has been an indispensable tool for web developers. It provides a ready-to-use set of UI components and a grid system essential for adaptive web pages that need to display well across PC and mobile browsers. Since its inception, Bootstrap has always had a dependency on the jQuery framework. The jQuery framework , originally created in 2006, is one of the most popular JavaScript frameworks of all time. It provides powerful language features and cross-browser compatibility in an era when web technologies are going through many challenges and experimentations to support a variety of use cases ranging from interactive web pages, single-page apps, AJAX requests, and mobile web apps. With JavaScript standards and

.NET Core–Monitor cache misses

Caching is an important tool in your toolbox as a developer. When used correctly in can vastly improve performance. However don't introduce caching blindly, it is crucial to monitor your cache usage to see if your caching strategy works and provides the benefits you expect. With .NET 7 this became a little bit easier, thanks to the introduction of MemoryCacheStatistics that holds cache hits, misses, and estimated size for IMemoryCache. You can get an instance of MemoryCacheStatistics by calling GetCurrentStatistics() on your IMemoryCache. instance when the flag TrackStatistics is enabled. If you construct the IMemoryCache instance yourself you can do this by specifying it through the MemoryCacheOptions object: Or if you are using Dependency Injection, you can do this: Now I can create my own EventSource implementation that reads the data from the MemoryCacheStatistics : I created a small console application that reads and writes some value to an IMemoryCache

Bootstrap 5 - Show/hide images on specific breakpoints

I'm working on upgrading an existing application from Bootstrap 4 to Bootstrap 5. I used the occasion to clean up the CSS logic. One thing I had in the original application was an image in the header that should be cropped on smaller screens. This how the header looks like on bigger screens: And this is on smaller screens: The trick I used originally was by using a media queries: However with the upgrade to Bootstrap 5 I would try to achieve the same thing using the built-in grid system and breakpoints. Breakpoints Breakpoints are the building blocks of responsive design in Bootstrap. You can use them to control when your layout can be adapted at a particular viewport or device size. Bootstrap includes six default breakpoints, sometimes referred to as grid tiers , for building responsively. These breakpoints can be customized if you’re using our source Sass files. Breakpoint Class infix Dimensions X-Small No

Visual Studio 2022 17.6–Http Endpoint explorer

I occasionally switch to Jetbrains Rider and Visual Studio Code, but my favorite IDE is and remains Visual Studio(especially with the Github Copilot integration ).  With the 17.6 release a new feature was introduced; the Endpoints explorer. With the Endpoints explorer, you can view and interact with the API endpoints defined in your solution. To use this feature go to View –> Other Windows –> Endpoint Explorer: You get an overview of all the API endpoints available in your solution and the available API calls that can be made: If you right click on an API call, you can choose between Open in the editor to jump to the implementation of the API call or Create Request . This will create a new HTTP file that can be used to execute the specific request on the endpoint: Nice!

Azure Artifacts–NU1301 error

I got contacted by a colleague who asked my help to fix the following error message he gots when executing his build pipeline using Azure Pipelines: error NU1301: Unable to load the service index for source This problem turned out to be similar to a problem I had before . Although the error message was not the same and we got less details about the root cause, I could apply the same solution. I had to uncheck the " Limit job authorization scope to current project " toggles in the Project Settings: To get all the details, check out the original post: Azure Pipelines error - User lacks permission to complete this action.

Writing asynchronous code in .NET

Over the years there have been multiple ways to write asynchronous code in .NET with async/await being the latest attempt to make it less error-prone and more developer friendly. We started the asynchronous journey in .NET 1.0 with the Asynchronous Programming Model where you had to write a Begin and End method following a specific pattern: This was improved in .NET 2.0 with the introduction of the Event-Based Asynchronous pattern(focussing mainly on client applications) in combination with the SynchronizationContext simplifying the scheduling of work on the UI thread: In .NET 4.0 the System.Threading.Tasks.Task type was introduced, a data structure that represents the eventual completion of some asynchronous operation: And finally we arrived at async/await where we use the power of iterators to generate a state machine that handles all the continuations and callbacks for us. This allows us to write asynchronous code in a way that almost feel as synchronous simplifying