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

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

using System.Threading.Tasks;
using SqsMessage = Amazon.SQS.Model.Message;

namespace JustSaying.Messaging.MessageHandling
{
    public interface IHandlerAsync<in T>
    {
        /// <summary>
        /// Handle a message of a given type
        /// </summary>

AnthonySteele

rem nukeeper release script

rem  in cmd: 

cd C:\Code\NuKeeper\NuKeeper
del C:\Code\NuKeeper\NuKeeper\bin\Debug\*.nupkg
dotnet build
dotnet pack
cd C:\Code\NuKeeper\NuKeeper\bin\Debug
dir

AnthonySteele

I have finally done a like-for-like benchmaerk on JustEat.Statsd version 2.1 versus version 3.1

In order to get a consistent measurement, it has to be on the same machine under the same conditions.

dotnet run -c Release --framework netcoreapp2.0

BenchmarkDotNet=v0.11.0, OS=Windows 10.0.17134.167 (1803/April2018Update/Redstone4)
Intel Core i7-4712HQ CPU 2.30GHz (Max: 2.20GHz) (Haswell), 1 CPU, 8 logical and 4 physical cores

AnthonySteele

using System.Net;

namespace JustEat.StatsD.EndpointLookups
{
    public class EndpointData
    {
        private readonly IPEndPoint _ipEndpoint;

        private readonly string _hostName;
        private readonly int _port;

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.

AnthonySteele

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

The git Pull Request is a powerful tool. But just because you have it, does not mean that you have to use it all the time.

I am thinking of a team that owns on a codebase and works on it regularly. Pull requests give outsiders a powerful thing that they did not have before: controlled access to apply changes that they need, with review by the owners. However it is not a good process to apply across the board to those same owners as a matter of course.

I always think of it as like a gate in an ancient walled city: A stranger can come in, if they pass inspection at the gate. Without the gate, they would be reduced to standing outside and shouting over the wall "We need this feature! And you need to update some urls!" and hope that it happens soon. So the gate allows them to come in and get business done, while res

AnthonySteele

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

Links

• The twelve-Factor app
• You need to be this tall to use micro services
• Microservice Prerequisites
• 10 Modern Software Over-Engineering Mistakes

Microservices have a dual nature: On the one hand, they give independence of code, testing, deploy times, versions, tools, techniques, etc. The ability for a team to work on and deploy an isolated unit of functionality when ready is great. It really is an archetectural style for the agile and Continous Deployment era.

AnthonySteele

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

About optimisation and benchmarks; bottlenecks and what difference optimisation will make.

ASP Kestrel Benchmarks

I heard that the ASP.NET core beta running on Kestrel Web server was capable of processing "over one million requests per second" though a simple benchmark Update: it's nearly 1.2 million now. The full benchmarks are at the bottom of this page

My thoughts were: