.NET tech blog by Jukka

I bought this video card recently. Here’s a mini review.

Fast and quiet GPU. Performance is good enough for any game. I’m playing mostly with 4k resolution, making use of FSR (resolution scaling), especially when FSR4 is supported. 16 GB VRAM is good for the future. FSR4 is a big upgrade over the previous version. Fans are almost inaudible. I wanted the 3 fan version, so it would be quieter. The lowest end “Pulse” has only 2 fans, which should be ok too. There’s LED lights, which I just disabled right away (I don’t care about LEDs). Pure is factory overclocked. Basically, it runs at the same clocks as stock RX 9070 XT, although with less cores it’s still a bit slower. On the other hand, TDP is lower as well. I actually wanted to see if I can underclock it back to “stock” 9070 levels, but that was not possible at least with the official tools.

Main drawback: there’s a little bit of coil whine, depending on FPS. It’s inaudible under 100 FPS. It gets more noticeable at 150 FPS and very noisy at 200 FPS. I tend to limit FPS to 120, so it’s usually not a problem, but I would be careful buying this video card for high FPS monitors (above 200).

I really like creating custom value types for encapsulating behavior and additional type safety. Recently, I started adding strongly-typed entity IDs. However, the method I took is slightly different from that other blog post. I figured most of the IDs are going to be the same, only the associated entity type is different. For example, OrderId and UserId, the only difference should the associated Order or User type. Additionally, it’s useful if we can create IDs in generic methods, such as GetNewId<TEntity>().

There are many ways to organize your automated tests. You can write unit tests, integration tests, end to end tests. The requirements depend on the product, of course, but I believe that the optimal solution is usually a mix of multiple methods.

I’ve been using the null object pattern recently to clean up some legacy code. It works really well with nullable reference types in C# and strict null checks in TypeScript.

There are many ways to classify software developer skill levels. Often you see developers being referred to as “junior” or “senior”. But these terms are not very well defined.

Recently I’ve heard comments that developers want to simplify and remove abstractions, and ORM (object-relational mapper) is one of them. Having an ORM, usually Entity Framework in .NET, has been pretty much standard for years. But is this good or bad?

We’ve been doing pair programming daily for almost 6 months. Here are my general thoughts.

I recently got excited about structured logging and decided to migrate from old log4net to Serilog. Adding more classification data to log events is something that will definitely benefit many applications. I tried to search for pros and cons, but it’s difficult to find a real world comparison for a large, complicated web application. Here are my experiences and opinions.

I’ve used the builder pattern a lot recently for writing unit test setups, filling data into in-memory database. It can be used with nice fluent syntax too.

var document = new DocumentBuilder()
  .WithName("My document")
  .WithIcon("mydoc.png")
  .Build();

But what I’ve been trying to figure out, what’s the preferred way to do nested objects (or parent-child-relationships). Let’s say that I’m trying to build a document folder tree. I have folders, inside folders I have documents and sub-folders.