AnthonySteele

A microbenchmark on the new message context store in JustSaying. The last one, ReadWriteNewMessageContext is probably the most realistic.

So we have an overhead of around 50 nanoseconds (5×10-5 ms). This is good. And I suggest that we don't bother with ways to opt in or out of this, just have it on all the time, regardless of if it is used by handlers or not.

// * Summary *

BenchmarkDotNet=v0.11.3, OS=Windows 10.0.17134.112 (1803/April2018Update/Redstone4)   
Intel Core i7-8750H CPU 2.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores   
.NET Core SDK=2.2.101 

AnthonySteele

/*
 * Example code for my blog post on function shims for NancyFx request handlers
 * Blog post is here: http://anthonysteele.co.uk/more-patterns-for-web-services-in-nancyfx
 */
 
using System;
using System.Collections.Generic;
using System.Threading.Tasks;

using Nancy;

AnthonySteele

When we started coding on NuKeeper, things were different - there were automated update tools for other ecosystems, but not for .NET, and I was working with a lot of services with a lot of dependencies. Most (but not all) of these at my work were solutions in .NET full framework version 4.6.2 or the like.

I tried to find the .NET support on "Greenkeeper" before realising what the docs didn't even feel the need to spell out: this was for node.js and NPM, only. So there was a gap and a need for .NET package automation.

Well, things changed. Most notably, Dependabot got .NET Core support, and was acquired by GitHub, which was in turn acquired my Microsoft.
Automated package update management is a win for developers, so this is good for people working in .NET.

AnthonySteele

This document has moved to: https://anthonysteele.github.io/AsyncBasicMistakes

I see a lot of code lately that makes some simple mistakes using the async ... await construct.

TL;DR

• A Task is a promise of a value.