Working with a legacy codebase using NUnit and .NET Framework, I've found that there is a mix of NUnit assertions and assertions using the Should library. This library is rather old and, frankly, limited compared to Shouldly and FluentAssertions. These newer two frameworks are significantly more expressive, with APIs that cover myriad situations elegantly. Questions in front of me:

1. Are any of these libraries really worthwhile compared to simply using NUnit's built-in assertions - either traditional or Assert.That style?
2. If using any independent framework, which is the best choice for this code base?
3. If selecting Shouldly or FluentAssertions, ought we to upgrade the old asserts?

My conclusion: favor Shouldly. Upgrade old asserts opportunistically for consistency, but no need to go out of the way.

According to Amazon Web Services (AWS) CEO Andy Jassy, at his keynote Wednesday morning, I am one of around 53,000 people from all over the world who have come out to the annual AWS re:Invent conference in Las Vegas. We come together from myriad industries and with interests that span the full range from product development to operations to account management. My personal learning objectives for the week are to deepen my understanding, and think about implications for the Ed-Fi tech stack, of four concepts:

• Data lakes
• Serverless
• Business intelligence
• .NET on AWS

continue reading on ed-fi.org...

Have you ever tried to write a query using the Ed-Fi ODS for reporting or analytics? To say that it is challenging is to use the mildest language. The Data Standard documentation in Tech Docs is top notch. Nevertheless, going from diagrams and definitions to actual query code for, let’s say, each student’s average math grade during a grading period, is not a trivial exercise.

Originally posted on www.ed-fi.org

Continuing from Upgrading safnet-directory, part 1, it is time to improve the solution's unit testing. At the outset, the controllers cannot be unit tested effectively due to their direct dependence on Entity Framework and ASP.NET Identity Framework classes. With application of an in-memory database, they could be integration tested, but not unit tested as I understand and apply the term.

In 2014 I built a quick-and-dirty web application using ASP.NET MVC5 and AngularJS 1.0.2. There are probably millions of web applications, large and small, that are "stuck" on some older tech, often because people are afraid of the work it will take to modernize them. In this series of blog posts, I'll refactor away the tech debt and polish it up this little app to make it something to be proud of... as much as one can be proud of a simplistic proof-of-concept, anyway.

First up: basic and trivial cleanup of the solution, bringing it up to .NET 4.7.2. Future: improved testing; ASP.NET Core; Entity Framework Core and better separation of concerns; UI libraries / frameworks.

It is 2018, and I have only just learned about the fantastic FluentAssertions framework. Seems like a nice time for a quick review of unit testing tools for .NET. Personal preferences: NUnit, FluentAssertions, Moq.

There is a positive a trend of developers doing more of their own testing, going beyond unit testing. However, if independent testers are cut out of the loop, then surely many applications will suffer. Case in point: a user unexpectedly entering a decimal temperatures and military time in a citizen science data collection application.

The TERN data collection application supports the Texas Estuarine Research Network's citizen science efforts on the Gulf coast of Texas and has been in operation since 2016. The code and testing were 99% all on my own, in spare time on weekends. I had tried to recruit some help with this open source project, but other than a couple of early code commits, I was unsuccessful in that regard.

Packer is a cross-platform tool for scripting out virtual machine images. Put another way: use it to create new virtual machines with fully automated and repeatable installations. No clicking around. Some of the benefits:

1. Startup fresh virtual machines from a pre-created, Packer-based image in seconds instead of hours.
2. Use the same scripts to create a local VM, a VWMARE instance, or a cloud-based virtual machine.
   • in other words, you can test your virtual machine creation process locally
3. Helps you maintain a strategy of infrastructure-as-code, which can be version-conrolled.

Recently I installed MongoDb using Chocolatey, and was surprised to notice that the executables weren't placed into the Chocolately path. Chocolatey uses a shimming process to automatically add executes to PATH. This is really quite nice.

I can imagine scenarios where I have command line executables that weren't installed by Chocotely that I would like to add to my path easily. Or a scenario like this where I want to address something that someone forgot to build into the choco package. Thankfully manually calling the shimgen executable to create a new shim is quite trivial:

c:\ProgramData\chocolatey\tools\shimgen.exe `
  --output=c:\ProgramData\Chocolatey\bin\mongodump.exe `
  --path="..\..\..\Program Files\MongoDb\Server\3.6\bin\mongodump.exe"

The only key thing to notice is the relative path constraint.

One of my very first technical blog posts was about running OpenSSH on Windows - written over 14 years ago. Recently I was playing around with Microsoft's port of OpenSSH, which has officially achieved version v1.0.0.0 beta status. Installation was pretty easy, but I ran into a little problem: needing to set "user" group permissions. This little gist has my final script. For reasons of my own I didn't feel like running the chocolatey install, so I don't know if it has this permission problem.