Sponsorship is available! If you’d like to sponsor CodeOpinion.com and have your product or service advertised exclusively (no AdSense) on every post, contact me.Here are the things that caught my eye this week. I’d love to hear what you found most interesting this week. Let me know in the comments or on Twitter.
An exploration in the launching and supervision of processes. Written to scratch and itch where the primary use case is installing a single service (on windows) who then spawns other process as part of a multi-process application.A pretty cool project that I recently stumbled upon by Damian Hickey. I plan on experimenting with this soon for a current project. Link: https://github.com/damianh/LittleForker
Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of Kent’s original rules so that TDD practice bears little resemblance to Kent’s original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the ‘public interface’ have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk, we re-discover Kent’s original proposition, discover where key misunderstandings occurred and look at a better approach to TDD that supports software development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written.I’ve actually seen this talk a while ago by Ian Cooper, but I watched the newest iteration this week and thought it was worth sharing. https://www.youtube.com/watch?v=EZ05e7EMOLM
Event sourcing and CQRS gained a lot of popularity recently. The advantages are obvious and they share a very peculiar symbiosis with each other and with the current tech state of the art making them very relevant. However after working for several years with them in production there are several caveats that one should care for.Probably one of the better posts I’ve read in awhile about Event Sourcing. Link: https://email@example.com/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a
Sorry but we messed up. We tried to make .NET Framework 4.6.1 retroactively implement .NET Standard 2.0. This was a mistake as we don't have a time machine and there is a tail of bugs.— Immo Landwerth (@terrajobst) August 21, 2018
If you want to consume .NET Standard 1.5+ from .NET Framework, I recommend to be on 4.7.2. https://t.co/E7H2Ps9cLk
This isn’t overly shocking as I’ve had nothing but problems with 4.6.1 and binding redirects with things like System.Net.Http. This is a real bummer as all the previous documentation and guidance was that net461 would be netstandard2 compliant. Do yourself a favor if you can and move to 4.7.2 (although I’ve had success with same issues under 4.7.1).
The lesson learned here is simple: once shipped, a given version of a .NET implementation must not change the support level of .NET Standard. IOW, the supported .NET Standard number is an immutable property. Supporting a higher version requires shipping a new version.— Immo Landwerth (@terrajobst) August 21, 2018
Since its beginning, Bing.com has run on the .NET Framework, but it recently transitioned to running on .NET Core. The main reasons driving Bing.com’s adoption of .NET Core are performance (a.k.a serving latency), support for side-by-side and app-local installation independent of the machine-wide installation (or lack thereof) and ReadyToRun images.Link: https://blogs.msdn.microsoft.com/dotnet/2018/08/20/bing-com-runs-on-net-core-2-1/