Head in the Cloud

Customer-First. Team-Focused. I like to take a customer-first approach to architecture and software design. A system architecture should always deliver value to the customer. Either directly--features, user experience--or indirectly by enabling teams to deliver value. If a team is going to be able to deliver value, the system needs to be easy to reason over, easy to maintain, easy and safe to extend, and easy to operate. Every architecture or design decision should answer: How does this deliver value to my customer? How does this deliver value to my team? Competing Styles. The Swinging Pendulum. It seems the big debate lately is monolith vs microservices. Academically, each at the opposite end of the spectrum: the massive, single deployable unit monolith on one end and the highly decomposed highly distributed microservices on the other. Each come with their pros and cons and serve teams better depending on team size, skill level, and goals. Notice I didn't include the customer in t...

After playing with Rider for a while, I decided to play around with Linux again to see what .Net development is like on Linux rig in 2020. So I fired up an Ubuntu 20.04 LTS VM and started installing. .Net Core After updating the OS with all the latest patches, I installed both .Net Core 2.1 LTS and 3.1 LTS following Microsoft's instructions . wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb sudo apt-get update; \ sudo apt-get install -y apt-transport-https && \ sudo apt-get update && \ sudo apt-get install -y dotnet-sdk-3.1 dotnet-sdk-2.1 JetBrains IDEs I have a JetBrains Ultimate subscription, so my next setup was installing JetBrains Toolbox. There is zero documentation on doing so, but it's pretty simple. Just download the tar ball from JetBrains, extract it to a directory of your choosing, and run it. Using the ToolBox, I installed my IDEs--Rider, In...

Disclaimer: This is an OpEd and mostly anecdotal. Performance wasn't measured, just perceived based on whether it left like the IDE was hanging a lot or productivity was impacted. I'll start off by saying: there is no replacement for Visual Studio. None. That's my opinion anyway. That said, JetBrains Rider is a decent .Net IDE, especially if you are a ReShaper fan (I am not) or IntelliJ fan (I am). What made me decide to give it a go? Well, I started work at Linedata as a Cloud Solution Architect and Application Architect. They are heavy users of ReSharper, and use it to enforce code formatting, quality, standards, and test coverage ( dotCover ) as part of their CI builds. It only took a few hours of me getting fed up with ReSharper crippling Visual Studio for me to install Rider and give it a go. I've been using it at work since. Some take-aways After using Rider as my primary C# IDE for a few months, here's my impression... Good Impressions P...

I have always considered it a best practice to use  static readonly  instead of  const  in C#. Here’s why… The  const  keyword tells the compiler to replace the constant token in your code with the literal value you have defined for the constant. You can see this if you look at the IL: The C# code… const string HELLO = "Hello" ; ... Console . WriteLine ( HELLO ); Console . WriteLine ( HELLO ); Compiles to the IL… .field private static literal string HELLO = "Hello" ... IL_0001: ldstr "Hello" IL_0006: call void [System.Console]System.Console::WriteLine(string) IL_000b: nop IL_000c: ldstr "Hello" IL_0011: call void [System.Console]System.Console::WriteLine(string) Notice that the literal  "Hello"  is loaded twice. Using  static readonly  provides us similar semantics–a global value that cannot be changed–but rather than references being replaced with literals by the compiler, it remains ...

Most of the time, your solution will have more than one project and a test unit project for each of those. Azure DevOps only, as of this writing, only allows you to update a single code coverage summary. If you upload more than one, each overwrites the next and only the last one remains. To accomplish this, we can use the merge functionality in Coverlet . I use the MSBuild extension, because it is better suited for CI pipelines. In your test project XML, add the package... <PackageReference Include="coverlet.msbuild" Version="2.7.0">     <PrivateAssets>all</PrivateAssets>     <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> </PackageReference> Then, in your dotnet test command or msbuild command, tell it to use Coverlet and to merge results. If you're using Azure DevOps, your test task looks this... (line wrapped for read ability in the article) - task: DotNetCoreCLI@2 displayName: Test i...

I ran into a scenario where my solution had libraries targeting netStandard2.0 and/or net461. For the libraries targeting just net461, I created a “MSTest Unit Test Project (.Net Framework)” project–the “old” project system. The tests ran fine in Visual Studio, but in my CI build, I wanted to keep it simple and run all the tests with dotnet test. However, this tooling cannot see/run the old test project. So, as an experiment, I tried creating a test project in the new project system, and changing the target moniker from NetCoreApp to net461.  It worked! both dotnet test and Visual Studio can run the tests. It’s worth noting that the library is also the new project system. I haven’t tested if that matters. Test Project XML <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net461</TargetFramework> <IsPackable>false</IsPackable> </PropertyGroup> <ItemGroup> <PackageReference Include="Mic...

Automate all the things! The same goes for security checks in our application. Continuous Security is the automation of these checks as part of the continuous delivery pipeline. The type of check determines where the check can, or should, go. Static testing (SaST), for example, should happen outside of, but be triggered by, CI. Dynamic Testing (DaST) happens outside of, but triggered by, deployment. Another scan we can, and should, perform is a security analysis of packages we’re pulling into our applications. This can happen during CI, and the build or pull request can be rejected if packages with known vulnerabilities are used. There are several tools emerging in this space, one of which is  Snyk.io . These tools compare your imported packages and versions to those listed in various CVE databases to determine if a package has a known vulnerability, and, if applicable, report the version you should upgrade to in order to patch the vulnerability. Some tools, like Snyk or eve...