My team, along with a couple of other teams, recently released a new feature at work. This is a cause for celebration! The release was marked with some internal comms that thanked the people who worked on it: project and product management, marketing and customer people.

Engineers? Nah, they did nothing!

This got me thinking about my days working as a dev in digital agencies in London. There were a few massive campaigns that we worked on. Some of them won awards or were featured in industry publications. The same thing happened. The creatives would get a mention. The project manager would get a mention. The account manager would definitely get a mention. The technical director? Possibly. But the three or four devs who worked to meet a seemingly impossibly tight deadline that was agreed to by someone who didn't even ask them how long it might take? Nothing.

I think it's normal practice that the people who manage the teams that deliver work to get the public credit for it. A good manager will pass those congratulations onto their reports who did the work. And that's what happened in this recent case at work, so we're all good there!

But if the managers deserve direct public praise for the work they delivered with the help of their team, why don't the team members themselves? There seems to be no good reason, other than there are usually a lot of them.

Going back to that agency example, what struck me at the time was that it wasn't just senior managers getting that public attention. The designers that designed the work were mentioned. The devs that implemented those designs were at the same level on the hierarchy. That just seemed unfair.

If you look at the audience for these types of message, and the authors of the messages, you can begin to see why the technical teams that delivered the work might get missed out. For the internal comms about a product release, they focus, quite rightly, on the changes to the product and how they improve the customer's experience using it. And the first people you think about when you're thinking about the product and customers are product and customer people!

In agency world, maybe it comes down to the fact that they have awards for creative arts, but they don't give out any awards for configuring Akamai to set a cookie using its directives, rather than overloading the single Windows Server 2003 box that serves all your clients' microsites, so that you can personalise banner ads featuring space hoppers in order to sell more mobile phones.

What do you think? Are we, as an industry, giving credit where credit's due, or are we guilty of unconscious bias when thinking about how work got done?

It's been a busy week at Hang Five. I've written about this a little in the Hang Five newsletter (yes, there's a Hang Five newsletter, please subscribe) but I've got more of a behind-the-scenes take here.

We have been trying to figure out a way to approach media to spread the word about Hang Five. We took a bit of a break over Christmas, and hadn't really gotten back onto the promotion track. But the promotion track found us!

A while back, one of my friends shared Hang Five with a group of her friends. One of them subscribed to Shit You Should Care About, an immensely popular (although unknown to me at the time) newsletter and Instagram account that digests news and culture to a primarily gen Z audience. Luce, who writes the newsletter and runs the independent media company, has been playing it with her family for the last wee while and decided to share it with her Close Friends list on Instagram.

So my friend saw that Story, and shared it with me. I checked all our dashboards and we started to see an uptick in traffic. This was last Thursday.

I emailed Luce and thanked her for playing and for sharing. And said she could suggest a topic if she wanted. She immediately came back with the BEST topic for her audience. It was a coincidence (or was it) that we're both NZ-based as well.

Fast forward to this Thursday, and the unofficial Hang Five x Shit You Should Care About collab went live. And traffic skyrocketed! Over 4,000 played yesterday's game. That's insane!

Our new audience is a bit different to our traditional one. Most people who have arrived at Hang Five have found it from a personal recommendation. Friends who play it and have recommended it. There's a real social aspect to it. There's a Share button, and around 20% of players tend to click it each day.

On Thursday that share rate dropped to 8%! And I think that's due to the relationship between the person that recommended it and the new player not being as strong as if it were someone you saw every day.

We're eagerly awaiting the next few days to see how many of those 4,000 people stick around and keep playing!

We've run test ads on LinkedIn, Facebook and Google in the past. Retention of those groups is nowhere near as good as the retention of the word of mouth players. I expect that retention of our new SYSCAhood players will be somewhere in the middle.

Some other experiments I've been looking at are to do with new user onboarding. I noticed this with the ads, that a lot of people weren't finishing their first game. I built a little walkthrough to see if it would make a difference.

It did. But not much. I've still got it running in an A/B test, but it's probably time to switch off the little tooltips because they don't make too much difference. The funnel is Start game -> Choose first letter -> Finish game. I've found that the first step conversion is better with the tooltips, but the whole funnel's conversion is almost the same.

Next time (not sure when that will be) I'll write a bit more about the technology behind Hang Five.

Have a great weekend!

Arun

I thought I'd quickly share some stats about Hang Five.

We are now at game #100. It's actually our 101st game, because we started at 0!

In the past 100 days, over 2,900 people have played over 22,000 times!

People love it. 50% of yesterday's players played it 4 times or more in the past week. 23% of them have played 7 days in a row!

The easiest game so far was actually yesterday, #99 ("... and chips"), with 97.61% of people solved it. The hardest one was #19 ("Backstreet's Back, alright", back in August) when only 9.09% of people solved it.

In the past month, 24% of people have clicked the "Share" button to share with their friends.

And if you search for Hang Five, in New Zealand at least, we're the number 1 result on Google.

We're about to start our media blitz, both in New Zealand and overseas. If you're a journalist or influencer who might be interested in sharing Hang Five with your audience, please get in touch!

My wife Amy and I recently went to Indonesia on a trip around Bali, Flores and Lombok. Amy bought a few word puzzle books at the airport in Wellington. We needed something to occupy our time during our 6 hour layover in Darwin. We played them every now and then. But we thought, could we invent our own game? Something that's sticky, and weirdly competitive, like Wordle?

We came up with an idea while we were in Indonesia, and when we got home, set about making the game. And thus, Hang Five was born!

We tested it with friends for a couple of weeks before getting the game mechanics right. It started off too easy, then too hard, and now, we think, it's just right!

Check it out at playhangfive.com. Let me know how you get on! And if you become addicted, you'll have to wait till midnight till the next puzzle's available.

On Friday at 2am (NZT), we'll get to see Meta's not-that-long-awaited Twitter killer, called Threads. It's already available for pre-order on the App Store, and there's a Google Play listing as well. It seems it had the code name "Barcelona" internally.

Its home on the web will be threads.net, which is currently a countdown with a 3D animation of the Threads logo, in Instagram colours, that you can rotate.

There's also an easter egg of sorts in the Instagram app. If you search for "threads" a little ticket icon will appear in the search bar. Click that and you'll get your personal invitation to the launch.

But will it be successful?

Well, the timing of the launch can't be a coincidence. The rate limiting fiasco over the last weekend caused a lot of discontent amongst the people that I follow. And the people I don't, for that matter - even the algorithmically-generated "for you" section had a lot of Twitter hate in it. People have been looking for a place to go for a while. Mentions of people wanting Blue Sky invitations were going up.

Since news of the Threads launch started surfacing over the past 24 hours, one thing that has caught people's eye is the privacy policy on the App Store listing. It has a list of "Data Linked to You" but it's actually the same as the list for the Facebook and Instagram apps. Yes, a concern, but no more a concern than it already has been. Admittedly, Twitter has a smaller list here.

Apparently Threads will use the ActivityPub spec, which is what Mastodon is based on. If they federate, it might finally be an easy way for the masses (me included) to get onto the fediverse.

I was a very early adopter of Instagram, being able to nab the @arun username. That means I get to keep it for Threads as well. And your followers will also come along for the ride. For some reason (and I should try and figure out how this came to be the case) I have over 17,000 followers on Instagram. I get to keep them. They were probably pretty disappointed Instagram followers, given the content I posted. They'll be even more disappointed reading my text-only content I'm sure.

I expect that there are a lot of people on Twitter who aren't on any Meta properties, so it will be interesting to see whether they join this one. Instagram skews young, as well, so will Threads be the same?

I will give it a go, and see if I can capitalise on the 17k followers that I'll bring with me. Surely some of them will be massive nerds that have a vague interest in what I say!

What about you? Are you going to sign up? Let me know in the comments, on Twitter or, once it's launched, on Threads. I'm assuming I'll be at https://threads.net/arun.

We've been living in a post-LLM world for about 6 months now. Some are saying that the hype is dying down. Search trends for ChatGPT are dropping the same way that searches for NFTs dropped off (thankfully).

When thinking of topics when as I was starting out this newsletter a few months ago, one that was near the top of my list was this one: will AI kill factual writing? I was drawn to it because I thought that a lot of the prose around writing about technical topics could probably artificially generated, and be correct. Or at least, correct with minor edits required.

What I mean by factual writing is the human author coming up with the facts about something, and letting AI figure out how the present them nicely for the reader. Obviously I'm coming at this from a technical standpoint, but perhaps the same could apply to an investigative journalist writing a summary of their findings and having AI write the article.

Last week I learnt something new at work. I shared my findings with my team in Slack, and joked that I could probably get AI to write a blog post about it.

See for yourself. I put Bing into "More Creative" mode and entered this prompt:

Write a blog post in the style of Arun Stephens (arunstephens.com) about this: I wanted to find out which other repos reference MyProduct.Business.Contracts.MyContract  and the GitHub web UI wasn't cutting it. So I installed the gh command line app, auth'd using gh auth login and then ran gh api --paginate search/code?q=MyProduct.Business.Contracts.MyContract | jq .items[].repository.full_name | sort | uniq Gave me a sorted list of repos that mention that in the code!

I've put the result in its own post. It's not bad at all. It's probably something that I might have written. It's also correctly expanded the context as to why wanted to find references to that class. I would have not concentrated on it being "a specific contract" though, as the search could be much wider than that.

To be fair, this isn't a particularly complex thing to write about. It's also not particularly novel. There's also a very strong argument that the original Slack post was better because it was more concise. You definitely get to the answer quicker. Maybe it wasn't necessary to expand this into an explainer blog post at all.

Could AI kill factual writing?

Certainly!

Will it?

No.

It may well reduce it, but there will definitely be space for novel writing to continue. And I think, well, hope, that society will still value human-written content, even if the machine-generated kind may not be distinguishable from it.

So here's what Bing (which is GPT behind the scenes) turned my little Slack post into:

How to find all the repos that reference a specific contract using GitHub CLI

🤖This article was written by AI. For more context, see the post I’m about to put up. If you work with a large codebase that spans multiple repositories, you might have encountered the problem of finding all the places where a certain contract or interface is used. For example, I

Arun StephensArun Stephens

What do you think? Let me know in the comments, on LinkedIn or on Twitter.

If you work with a large codebase that spans multiple repositories, you might have encountered the problem of finding all the places where a certain contract or interface is used. For example, I wanted to find out which other repos reference MyProduct.Business.Contracts.MyContract and the GitHub web UI wasn’t cutting it.

Sure, you can use the web UI to search for code, but it has some limitations. You can only see 10 results per page, and you have to click through each result to see the repository name. Also, you might get some false positives from forks or archived repos that are not relevant.

So I decided to try a different approach: using the GitHub CLI tool. The GitHub CLI is a command-line interface that lets you interact with GitHub from your terminal. You can do things like create issues, pull requests, releases, and more. But you can also use it to query the GitHub API and get JSON data back.

One of the commands that the GitHub CLI supports is gh api, which allows you to make arbitrary requests to the GitHub API. You can pass in any endpoint and parameters, and get the response as JSON. You can also use the --paginate flag to automatically fetch all pages of results.

So I installed the gh command line app, auth’d using gh auth login and then ran this command:

gh api --paginate search/code?q=MyProduct.Business.Contracts.MyContract | jq .items[].repository.full_name | sort | uniq

This command does the following:

• It uses the search/code endpoint to search for code that matches MyProduct.Business.Contracts.MyContract.
• It pipes the JSON output to jq, a command-line tool for processing JSON data.
• It extracts the full_name property of each repository from the items array using jq .items[].repository.full_name.
• It sorts the results alphabetically using sort.
• It removes any duplicates using uniq.

The result is a sorted list of repos that mention that contract in the code. Here’s an example output:

arunstephens/MyProduct.Api
arunstephens/MyProduct.Client
arunstephens/MyProduct.Common
arunstephens/MyProduct.Service

This way, I can quickly see all the repos that depend on that contract, and make any changes or updates accordingly. I can also use other filters or modifiers in the query string, such as language, user, org, etc.

I hope you found this tip useful. If you want to learn more about the GitHub CLI, check out their documentation. And if you have any questions or feedback, feel free to leave a comment below or reach out to me on Twitter.

Will AI kill factual writing?

We’ve been living in a post-LLM world for about 6 months now. Some are saying that the hype is dying down. Search trends for ChatGPT are dropping the same way that searches for NFTs dropped off (thankfully). When thinking of topics when as I was starting out this newsletter a

Arun StephensArun Stephens

Before code written by a programmer can be executed by a computer, it needs to go through a process called compilation. It takes what a human (well, some of us) understands, and turns it into something the computer understands.

In .NET, there are technically two steps in this compilation. The first is when the source code (in C#, say) is compiled in to Intermediary Language (IL). The second occurs at runtime, when the Common Language Runtime (CLR), the framework that your code runs on top of, translates it into the machine code that the computer can understand. This last step happens just before it needs to be run by the computer. It is called Just In Time compilation, or JIT.

Another approach is to translate it the whole way up front, before you need to run it. This is Ahead Of Time compilation, or AOT. AOT is not new. Languages like C and Pascal are compiled ahead of time.

Native AOT is now here for .NET. What does it bring to the table?

• You don't need to have the .NET runtime installed to run your app. Just package up your app and it will run.
• Native AOT apps can also run in environments that don't allow JIT, typically embedded systems.
• They are supposed to use less memory and be faster to start up. This can make a difference with applications that scale out to have multiple instances.

Writing a simple AOT app

There's a decent list of things that can't be done with Native AOT, one of which is using ASP.NET MVC, so our first AOT app will have to use minimal APIs.

We'll start by creating a new app. We'll just start with the standard Hello World app generated by the dotnet command.

PS C:\src> dotnet new web -o AotMinimal
The template "ASP.NET Core Empty" was created successfully.

Processing post-creation actions...
Restoring C:\src\AotMinimal\AotMinimal.csproj:
  Determining projects to restore...
  Restored C:\src\AotMinimal\AotMinimal.csproj (in 99 ms).
Restore succeeded.

This creates our base project. The Program.cs file looks like this:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

That just returns a simple string. Can't be simpler than this, can it?

Let's make it a bit more complicated, and add this endpoint:

app.MapGet("/object", () => new { message = "Hello World!" });

We've now got a simple app. If we run it with dotnet run we can hit our / endpoint and receive Hello World! as a string. If we hit /object we'll get a JSON string {"message":"Hello World!"}.

Building and publishing

We're going to deploy our application into a containerised environment like Docker or Kubernetes.

Building the JIT version

Let's start with a standard JIT configuration.

FROM mcr.microsoft.com/dotnet/sdk:8.0-preview AS build-env
WORKDIR /App

# Copy everything
COPY . ./
# Restore as distinct layers
RUN dotnet restore
# Build and publish a release
RUN dotnet publish -c Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:8.0-preview
WORKDIR /App
COPY --from=build-env /App/out .
ENTRYPOINT ["dotnet", "AotMinimal.dll"]

This is a standard .NET Dockerfile. It sets up a build environment using the SDK image, copies the source code into the container, restores NuGet packages, and builds the project, placing the output into the out directory.

It then creates the rutime image, taking the aspnet image as a base, copies the out directory from the build environment, then sets the entry point to run the application.

We can build this by running:

docker build . --tag minimal:jit

And run it by running:

docker run -it --rm -p 8080:8080 minimal:jit

You can then hit http://localhost:8080 to receive the basic Hello World message, or http://localhost:8080/object to receive the JSON object.

Building the AOT version

First up, we'll need to edit the csproj file to enable AOT. We do this by adding this setting:

<PropertyGroup>
    <PublishAot>true</PublishAot>
</PropertyGroup>

If we try building it using the existing Dockerfile, we get errors. There are a few, but the important one for now is:

#0 16.10 /root/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.0-preview.5.23280.8/build/Microsoft.NETCore.Native.Unix.targets(178,5): error : Platform linker ('clang' or 'gcc') not found in PATH. Ensure you have all the required prerequisites documented at https://aka.ms/nativeaot-prerequisites. [/App/AotMinimal.csproj]

The build environment doesn't have everything it needs to build AOT applications. We'll need to change the Dockerfile like so:

FROM mcr.microsoft.com/dotnet/sdk:8.0-preview AS build-env
WORKDIR /App

# Install NativeAOT build prerequisites
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       clang zlib1g-dev

# Copy everything
COPY . ./
# Restore as distinct layers
RUN dotnet restore
# Build and publish a release
RUN dotnet publish -c Release -r linux-x64 -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/runtime-deps:8.0-preview
WORKDIR /App
COPY --from=build-env /App/out .
ENTRYPOINT ["/App/AotMinimal"]

This one uses the same base image as the build environment, we first need to install the clang and zlib1g-dev packages. This installs the C compiler and the zlib compression library.

The second change is to the  run dotnet publish command. Note the -r linux-x64 option. That's telling it to build for the linux-x64 runtime. AOT apps have to be build for the specific architecture they're running on - that's the whole point!

Finally, the runtime image has changed. It's not the .NET runtime anymore, but the (much smaller) .NET runtime deps image. This image doesn't contain the .NET runtime, just the things that .NET AOT apps need to run, which is a fairly standard Linux installation. We also need to change the entry point to be simply run the AotMinimal command. We don't need to run it with the dotnet command, because it doesn't need it. It's a runnable Linux executable.

We can build this by running:

docker build . --tag minimal:aot

We still get warnings here, but it is successful. Let's ignore the warnings for now (mainly because by default they get hidden in the output of the docker build comand), and try running it by running:

docker run -it --rm -p 8080:8080 minimal:aot

It seems to start well, but what if we hit http://localhost:8080/?

Oh no! We get an error!

fail: Microsoft.AspNetCore.Server.Kestrel[13]
      Connection id "0HMRGDSJK9IOC", Request id "0HMRGDSJK9IOC:00000001": An unhandled exception was thrown by the application.
      System.InvalidOperationException: JsonSerializerOptions instance must specify a TypeInfoResolver setting before being marked as read-only.

And this brings us to the main thing I've discovered about .NET Native AOT! You're not going to be able to use AOT using all the tools and techniques you use today.

Why isn't it working?

Remember those compiler warnings I mentioned before? Let's take a look at them now. To make them stick around after your build completes, add --progress plain to the end of your docker buildcommand. The errors are extensive!

The key message here is These types may require generated code and aren't compatible with native AOT applications. It turns out that JSON serialisation uses source generation, which is a thing that Native AOT does not support.

The / endpoint doesn't use source generation. If you omit the /object endpoint, it builds without warnings and runs fine. This is likely because the EndpointRoutingMiddleware, which is throwing that exception, needs to figure out all the routes, and just can't.

As mentioned earlier, there's a significant list of things that can't be done with .NET AOT. Key ones include:

• You can't do runtime code generation, which is the problem with the JSON serialisation here
• You use dynamic loading, like using Assembly.LoadFile
• LINQ expressions always use the slower interpreted form

Some new performance optimisations, like on-stack replacement, which I wrote about in February, also rely on the JIT nature of the runtime, where the runtime figures out a better way to run your code. If your code is already in machine code, it's not going to be able to be optimised on the fly. These features are also not able to be used with AOT.

So, what's next?

Waiting.

Current ASP.NET APIs can't really take advantage of .NET Native AOT. You could limit yourself to using language and framework features that do work with it, if you need the performance improvements that this new technology brings.

For most workloads, though, I think you're better of sticking with what works well now. But I'll definitely be keeping an eye out on what you'll be able to do with AOT in the future.

My first recorded chat with ChatGPT was on 9 December 2022. I asked it to "Write a prequel to Humpty Dumpty". It was pretty good, telling me that:

Humpty Dumpty had a great desire to see the world beyond the castle walls, but he knew that his round, egg-like shape made it impossible for him to venture out on his own. So he spent his days dreaming of far-off lands and adventures...

This one wasn't particularly useful for me at work, but not long later, I was clearly having a bit of trouble with PowerShell, and asked it "unset env var in powershell". Sure enough, it gave me the answer. In probably about the same amount of time as a Google search would have.

I got a bit more ambitious. I had just had my work machine rebuilt, and was getting frustrated with IIS sites shutting down in the middle of the day, so I wanted to increase the idle timeout. I found some instructions on how to do it using the UI, but I have a lot of sites running, so I pasted in those instructions with the prefix "Write me a powershell script to achieve the following:" and sure enough, it gave me what I almost wanted.

And that's the trick with ChatGPT. You need to take its answers with a grain of salt. I asked ChatGPT to write me a LinkedIn post about this very thing. I think that, at the moment at least, generative AI tools like ChatGPT are great at helping you if you already know what you're doing. Code examples don't often work first time, and you need a bit of experience to troubleshoot the problem. That's not to say, though, that the technology won't improve.

If I'm stuck and think my AI friend can help, my workflow depends on the problem. When what I'm asking about isn't so specific to a problem with existing code, I'll just ask a question. Other times I might think giving ChatGPT the code I'm having trouble with will help. If that's the case, I do my best to anonymise it, so I'm not breaching any confidentiality obligations I have. A big concern companies have is that these AIs can then use that information as part of their training, and your confidential material may well end up in a future response to someone else's prompt.

It's still early days with tools like ChatGPT. As services start to have commercial terms that are more appealing to businesses, and users' inputs are ringfenced so they don't end up being returned other users, the need to anonymise inputs will be a thing of the past.

But for now, I will often try to pare it back to just the thing that's giving me problems, much the same was as you might do when asking on Stack Overflow, or writing a blog post. This is where your own skill and experience becomes important. You need to know enough about your code in order to form a good prompt around it.

It's fairly well known that ChatGPT is not always right. Sometimes this is because it will just make things up (although arguably everthing it says it makes up), and other times it might be because its training data is misleading it. Knowing that it's wrong is another aspect of ChatGPT usage that relies on your own expertise.

Sometimes when I'm reading a response, it will be clear to me that something is wrong. In these cases, I'll just say, for example, "method doSomething does not exist on class Foo" and it will invariably reply with an apology for the mistake, and a new solution. Maybe that solution will also have a problem, so I'll point out the mistake again. I might also help it by telling it what the solution it - "doSomething doesn't exist but doThisThing does" - and it might save us a bit of back and forth in coming up with the answer.

There might be times where I can't see the mistake. In these cases, I can just paste the error (or a description of it) that I get when it compiles or runs, and it will do the same thing.

My job is not just about writing code. I've used it to help me formulate arguments for and against certain plans. I have given it a user story (which I anonymised first) and got it to give me a set of acceptance criteria. It's quite good at these. For non-work purposes, I've pasted a whole lot of text in, and asked for it to rewrite it to read better.

I'm really looking forward to the day that I can safely input private company data. I could send it a meeting transcript and get it to give me a summary of the key points. It could take all our Slack conversations and give me answers to questions about our sprint.

ChatGPT isn't a threat to my job yet. But it can definitely be a very useful tool.

What do you think? Have you used ChatGPT and friends in your day-to-day work? Let me know in the comments.

A recent introduction to the C# language is pattern matching. It was added in C# 7.0, which came out in March 2017, along with Visual Studio 2017 and .NET Framework 4.7. So it's a pretty well-established concept. But one I haven't used very much at all.

The feature I want to write about today was introduced with C# 8.0, in September 2019 (around the time that .NET Core 3.0 came out). It is pattern matching using switch expressions.

A quick intro if you're not a coder. A lot of programming is about making decisions. If something is true, do this, otherwise, do that. Sometimes it's not a binary choice. You might want to do different things depending on 3 or 4 or 10 different cases. This is where switch comes in. You specify each condition you're testing for, and what should happen if that condition is true. The usual way is a switch statement but there's a new way of achieving a similar thing, calls a switch expression.

I recently found an occasion to a switch expression in a recent piece of work. I am working on the API that serves a business web application. There is a backend API that could return an error as part of its regular operation, and that error is of an error type enum.

My API needs to return that error in the way the frontend will understand. I need to translate it.

This is what comes from the backend API:

enum ErrorType
{
    Good,
    Bad,
    TooBig
}

class BackendApiResult
{
    ErrorType ErrorType { get; set; }
    string Message { get; set; }
}

My API's response needs to look like this:

{ 
    "result": "GOOD" | "BAD" | "TOO_BIG",
    "maxSize": 1000 // only present if result is TOO_BIG
}

One way to do this would be:

switch (apiResponse.ErrorType)
{
    case ErrorType.Good:
        return new { Result = "GOOD" };

    case ErrorType.Bad:
        return new { Result = "BAD" };

    case ErrorType.TooBig:
        return new { Result = "TOO_BIG", MaxSize = GetMaxSize(apiResponse) };

    default:
        return new { Result = apiResponse.Message };
}

It's quite verbose. But to use pattern matching:

return apiResponse.ErrorType switch
{
    ErrorType.Good => new { Result = "GOOD" },
    ErrorType.Bad => new { Result = "BAD" },
    ErrorType.TooBig => new { Result = "TOO_BIG", MaxSize = GetMaxSize(apiResponse) },
    _ => new { Result = apiResponse.Message },
};

Less wordy, possibly easier to follow, assuming you know the new syntax.

It should be mostly self-explanatory. The _ is the discard pattern, a catch-all, similar to the default in a switch statement.

What is different from a switch statement is that the compiler will warn you if you don't cover all the cases. If I hadn't included the discard pattern at the end, I'd have received

Warning CS8524: The switch expression does not handle some values of its input type (it is not exhaustive) involving an unnamed enum value. For example, the pattern '(ErrorType)3' is not covered.

The compiler knows that other values could be provided in the ErrorType property, and lets me know. To be fair, in this example, if I didn't have the default case, the compiler would tell me that not all code paths return a value, but it's not as explicit as to what was missing.

What does it look like behind the scenes? I loaded the code into dotPeek, and looked at the low-level C# view of the IL. They are very similar.

The switch statement implementation looks like this:

[NullableContext(1)]
[CompilerGenerated]
internal static object \u003C\u003CMain\u003E\u0024\u003Eg__GetThingTheOldWay\u007C0_1(
  BackendApiResult apiResponse)
  {
    switch (apiResponse.ErrorType)
    {
      case ErrorType.Good:
        return (object) new \u003C\u003Ef__AnonymousType0<string>("GOOD");
      case ErrorType.Bad:
        return (object) new \u003C\u003Ef__AnonymousType0<string>("BAD");
      case ErrorType.TooBig:
        return (object) new \u003C\u003Ef__AnonymousType1<string, int>("TOO_BIG", Program.\u003C\u003CMain\u003E\u0024\u003Eg__GetMaxSize\u007C0_2(apiResponse));
      default:
        return (object) new \u003C\u003Ef__AnonymousType0<string>(apiResponse.Message);
    }
}

The pattern matching implementation looks like:

[NullableContext(1)]
[CompilerGenerated]
internal static object u003C\u003CMain\u003E\u0024\u003Eg__GetThing\u007C0_0(
  BackendApiResult apiResponse)
{
  ErrorType errorType = apiResponse.ErrorType;
  if (true)
    ;
  object thing00;
  switch (errorType)
  {
    case ErrorType.Good:
      thing00 = (object) new \u003C\u003Ef__AnonymousType0<string>("GOOD");
      break;
    case ErrorType.Bad:
      thing00 = (object) new \u003C\u003Ef__AnonymousType0<string>("BAD");
      break;
    case ErrorType.TooBig:
      thing00 = (object) new \u003C\u003Ef__AnonymousType1<string, int>("TOO_BIG", Program.\u003C\u003CMain\u003E\u0024\u003Eg__GetMaxSize\u007C0_2(apiResponse));
      break;
    default:
      thing00 = (object) new \u003C\u003Ef__AnonymousType0<string>(apiResponse.Message);
      break;
  }
  if (true)
    ;
  return thing00;
}

Apart from assigning the property to a variable at the start (which in some languages is more efficient because the expression will be evaluated for each case - but this isn't how it works in .NET) and saving the result in a variable and returning it at the end, they are the same.

Which is faster? My hypothesis is that the one that the switch statement will be. After all, it's doing less work.

Looking at the graph above, you can see it's slightly faster to use the switch statement. My test involved calling a switch statement/expression 100,000,000 times. I ran it 1,000 times for the expression and 1,000 for the statement and recorded the time tacken (in ticks). It test wasn't very scientific and the computer was doing other things while it was running!

So the statement appears to be about 5% faster. Again, the test isn't that scientific so I wouldn't base any decision on whether to use an expression or statement on this alone!

What do you think? Do you use switch expressions? Let me know in the comments!

Hi!

I've decided to give the blog a revamp, and actually relaunch it as a newsletter. I'll be writing about software development and general technology things that interest me and that I think might interest you.

Why a newsletter? A few reasons. First, newsletters are cool these days. Much cooler than blogs. They also allow you to have a bit more control over how your content gets to people. Which pretty much means you aren't at the mercy of Zuck's algorithms or Elon's whims.

I also want to write more. I was thinking of topics to write about and I realised I've been in this game for a long time now, and have some good stories to tell. Having a newsletter, and eventually having people who I know are going to at least have what I've written end up in their inboxes, will (hopefully) encourage me to write more frequently.

From a professional point of view, I'd like to get better at technical (and non-technical) writing. As an engineering leader, a big part of my job is to explain technical things to people from all around the business. Practice makes perfect, so thank you, guinea pigs!

And of course, there's a dream that one day I might feel like I can become a thought leader that can charge for my most premium thoughts. That day is a long way off, if it ever comes at all.

Everything that used to be on my blog is still here, including when it was less focussed and whatever came from my mind. I might still write like that from time to time.

So, if this sounds like something you might vaguely want to read, please subscribe!

Arun

.NET 7 was released a few months ago, and it brought many exciting new features. As a .NET developer, I am particularly interested in the changes that affect my work . In this article, I will go through some of the new features in .NET 7 that I think are worth highlighting.

The features I want to go through are in the following areas:

• Performance
• C# 11
• JSON serialisation/deserialisation
• Rate limiting
• Output caching

You can read more detail about all of the new features on Microsoft’s detailed what’s new page, which was my starting point for this article.

Runtime performance improvements

One of the main focuses of .NET 7 was performance. This has the potential to give your users a better experience, improving load times. It can also potentially mean lower running costs for your business, as you’ll be able to squeeze a bit more out of the compute resource you have allocated. And you should be able to get this benefit with very little development effort!

If the runtime figures out a faster way to run your code, while your application is running, on-stack replacement (OSR) lets it switch to that faster way. OSR is used when a method has long-running loops. So, after a few iterations, the runtime might find a better way to do the next ones. It will use that better way on the following iteration. It is turned on by default.

Related to OSR is a feature you need to turn on to take advantage of. Dynamic profile-guided optimisation is the way that the runtime decides if there’s a better way to run your code. It collects data on how your application is running, and uses that to optimise future executions. One benchmark saw a 33% improvement in execution speed with dynamic PGO turned on.

I don’t think there is a way for the runtime to keep track of its more optimised ways of running your code if you need to restart your application. But even if it did, when running in Kubernetes, when spinning up new pods, it will never have run before.

C# 11

There are a few changes to C#, but one that I am glad is finally here is raw string literals, Python-style. You can now do this!

var myString = """
    This is a string that has \ in it and also " and also ' and
    it can go on multiple lines. Also this 
    <--- whitespace gets stripped because it is the amount 
    of whitespace to the left of the quotes on the 
    final line
    """;

The indent is removed automatically, and the size of the indent is determined by the indent of the closing """ of the string. If any line in your literal has an indent less than that one, the compiler will give you an error.

You can also combine it with string interpolation. The number of $ you put to open your literal is the number of { you need to surround your expression with, e.g.:

var myString = $$"""
    This needs another brace around {DateTime.UtcNow} to put the date in, see: {{DateTime.UtcNow}}.
    """;

Value of myString:

This needs another brace around {DateTime.UtcNow} to put the date in, see: 15/02/2023 20:47:10.

There’s also a new required modifier for fields and properties on classes. This tells the compiler that the object initialiser must set that field or property. If you don’t, there will be a compiler error.

If you have this class:

public class HasRequired
{
    public required string Name { get; set; }

    public HasRequired()
    {
        // I don't set the name
    }
}

Then this initialiser:

var obj = new HasRequired();

will not compile because it needs to set the Name property, like this:

var obj = new HasRequired { Name = "my name" };

If you had a constructor:

public HasRequired(string name)
{
    Name = name;
}

Then you would still get the same compiler error. You can prevent this by using the [SetsRequiredMembers] attribute on the constructor. You are telling the compiler that if the consumer uses this constructor, all required members will be set. The docs say “Use it with caution”.

JSON serialisation and deserialisation

System.Text.Json is acknowledged to be more performant than what was effectively the de facto industry standard, Newtonsoft.Json. But it does lack some features. This is beginning to change.

There is now contract customisation which lets you write functions that change how the serialisation process works. Using this feature, you can distinguish between null and not-present values in a JSON payload. I can see this being useful if you, for example, define your API to not update a field if it’s not present in the payload, and setting it to null if it’s set to null in the payload. You can also use it to serialise private fields and properties (you would need to use reflection to get the values, though) or ignore properties by name, value or type.

If you are using inheritance in your data model (and there are strong opinions that you shouldn’t in product development; I haven’t formed my own on that yet) then this next one could be useful. You can now serialise properties of derived classes. This is something that Newtonsoft did out of the box, and that System.Text.Json decided not to do to prevent you from accidentally sending private data over the wire.

Take this model:

public class Bar
{
    public string BarValue { get; set; }
}

public class Foo : Bar
{
    public string FooValue { get; set; }
}

In .NET 6, if you were to serialise this:

Bar foo = new Foo { FooValue = "foo", BarValue = "bar" }

You would end up with:

{ "barValue": "bar" }

You might have expected:

{ "barValue": "bar", "fooValue": "foo" }

This feature was there to prevent you from accidentally exposing something that’s public in your code, but private in terms of whether it should be sent down the wire.

You can now explicitly declare that Foo is a derived type of Bar, and the serialiser will know that you want to include all of Foo if one is passed as Bar:

[JsonDerivedType(typeof(Foo))]
public class Bar
{   
    ...
}

Rate limiting

There is a new System.Threading.RateLimiting package as part of .NET. There is also rate limiting middleware built into ASP.NET Core. There are several rate limiting methods available:

• Fixed window
• Sliding window
• Token bucket
• Concurrency

They are very easy to set up.

The documentation gives very good examples on how they work, so I won’t repeat them here. It is also very explicit that you should perform load testing, and gives some examples of using JMeter. Another common load testing tool is k6.

This is probably my favourite feature, as someone who builds scalable systems.

Output caching middleware

You can now cache the output of your app. These days I’m more concerned with API controllers, but it works for all types of ASP.NET Core apps: minimal API, MVC, and Razor pages as well. Once you’ve added the middleware to your application, if you simply add a [OutputCache] attribute to your action method, the system will cache the entire output of your response. The default cache key uses the whole URL, but you can customise it.

You can also evict cache entries. This is done by tag. When adding the [OutputCache] attribute, you can group methods together by tag, and then cache eviction will affect all methods with that tag.

It’s worth noting that this works regardless of what the client sends down in its Cache-Control header, in contrast to response caching, which was already part of .NET 6.

Summary

This is just a small taste of the new features available in .NET 7. Bear in mind that .NET 7 is a standard term support release, so if you move to it, you’ll need to upgrade to .NET 8 by May 2024. .NET 6 has support until November 2024. But these features may be worth the effort of doing two upgrades over the next year and a bit.

When they were talking about how vaccine passports might work, I had an idea of how I’d make such a system. A QR code with some information about each person and their vaccination status, a signature signed with the private key of the issuer, and a way for people to verify that signature with the issuer’s public key.

It turns out that it’s exactly what they’ve done. And it’s very similar to what happens every day on the web with OAuth2 and JWT.

I wanted to decode and verify my COVID pass so I can see how it works. So that’s what I did.

The spec for the system is public, at https://nzcp.covid19.health.nz/. (It’s actually a GitHub Pages site.)

First up, I have to decode my QR code:

NZCP:/1/2KCE3I...KLCMJQ

(Most of it omitted for what should be obvious reasons.)

The first thing the spec says is:

Check if the message received from the QR Code begins with the prefix NZCP:/, if it does not then fail.

Yes, it is. It starts with NZCP:/

Next:

Parse the character(s) (representing the version-identifier) as an unsigned integer following the NZCP:/ suffix and before the next slash character (/) encountered. If this errors then fail. If the value returned is un-recognized as a major protocol version supported by the verifying software then fail. NOTE - for instance in this version of the specification this value MUST be 1.

Tick. It is NZCP:/1/.

With the remainder of the message following the / after the version-identifier, attempt to decode it using base32 as defined by RFC4648 NOTE add back in padding if required, if an error is encountered during decoding then fail.

Now things get a bit trickier, as I can’t decode base32 in my head. So I’ll need to write some code. Base32 isn’t part of the .NET standard library either. So I found something on NuGet that had lots of downloads. Maybe it will work.

var decodedBytes = SimpleBase.Base32.Rfc4648.Decode(messageBase32);

I appear to have an array of bytes. (Actually it’s a Span<byte>.)

Next step:

With the decoded message attempt to decode it as COSE_Sign1 CBOR structure, if an error is encountered during decoding then fail.

CBOR stands for Concise Binary Object Representation and it is essentially a binary version of JSON. The System.Formats.Cbor package can decode them.

var message = new CborReader(decodedBytes);

I’m not sure if this is a COSE_Sign1 structure though. RFC8152 tells me that COSE means CBOR Object Signing and Encryption. CBOR Tag 18 is the one for COSE_Sign1, and it appears that my message has that tag.

Now:

With the headers returned from the COSE_Sign1 decoding step, check for the presence of the required headers as defined in the data model section, if these conditions are not meet then fail.

The message itself is an array. The first element is the header:

var arrayLength = message.ReadStartArray();
var headerBytes = message.ReadByteString();
var headerMessage = new CborReader(headerBytes);

This code decodes the header.

var headerLength = headerMessage.ReadStartMap();

int algValue = 0;
string kidValue = null;

for (var i = 0; i < headerLength; i++)
{
    var headerKey = headerMessage.ReadInt32();

    if (headerKey == 1)
    {
        // it's alg
        algValue = headerMessage.ReadInt32();
    }
    else if (headerKey == 4)
    {
        // it's kid
        var headerValueBytes = headerMessage.ReadByteString();
        kidValue = Encoding.ASCII.GetString(headerValueBytes);
    }
}

headerMessage.ReadEndMap();

It is a map with two key-value pairs. COSE has some well-known keys with IDs. We have keys here identified by 1 and 4 which represent alg and kid respectively.

The value of the alg is a single byte: -7. This represents the algorithm ES256. The value of kid is a byte string, which I’ve decoded as ASCII:

WriteLine($"Header decoded. Alg = {algValue}, Kid = {kidValue}");

Output:

Header decoded. Alg = -7, Kid = z12Kf7UQ

I’m not sure if that’s a valid key ID yet. We will check that later.

So far, we’ve got a valid alg and kid. There are other headers in the rest of the message that we still need to validate.

The second element of message is an empty map. Skip it!

var mapLength = message.ReadStartMap();
message.ReadEndMap();

The third element contains the actual payload, as a byte string:

var payloadBytes = message.ReadByteString();
var payloadMessage = new CborReader(payloadBytes);
var payloadLength = payloadMessage.ReadStartMap();

There are some well-known keys, identified by an integer, and keys can also be strings. We have both in our payload. The integer keys are the standard headers. The final element is @vc which is our actual COVID Pass.

for (var i = 0; i < payloadLength; i++)
{
    var nextOne = payloadMessage.PeekState();

    if (nextOne == CborReaderState.TextString)
    {
        var keyString = payloadMessage.ReadTextString();
        if (keyString.ToString() == "vc")
        {
            var vcLength = payloadMessage.ReadStartMap();

            for (var j = 0; j < vcLength; j++)
            {
                var key = payloadMessage.ReadTextString();

                switch (key)
                {
                    case "@context":

                        pass.Context = ReadStringArray(payloadMessage);

                        break;

                    case "version":
                        pass.Version = payloadMessage.ReadTextString();
                        break;

                    case "type":
                        pass.Type= ReadStringArray(payloadMessage);
                        break;

                    case "credentialSubject":
                        pass.CredentialSubject = ReadCredentialSubject(payloadMessage);
                        break;

                    default:
                        break;
                }
            }

            payloadMessage.ReadEndMap();
        }
    }
    else
    {
        var payloadKey = payloadMessage.ReadInt32();

        switch (payloadKey)
        {
            case 1:
                issValue = payloadMessage.ReadTextString();
                break;

            case 4:
                nbfValue = payloadMessage.ReadInt32();
                break;

            case 5:
                expValue = payloadMessage.ReadInt32();
                break;

            case 7:
                jtiBytes = payloadMessage.ReadByteString();
                break;
        }
    }
}

At the end, we get this:

Key (int) Key (description) Value 1 iss (Issuer) did:web:nzcp.identity.health.nz 4 exp (Expiry date) 1652702400 (Monday, 16 May 2022 12:00:00 UTC) 5 nbf (Valid from) 1637060400 (Tuesday, 16 November 2021 11:00:00 UTC) 7 jti (Token identifier) ByteString, which is a UUID according to the spec (not shown) vc Verifiable credential object

The vc is an object containing all the claims:

Key (string) Description Value @context Array of strings with URLs version Version number 1.0.0 type Array of types [ "VerifiableCredential", "PublicCovidPass" ] credentialSubject Map of name { "givenName": "ARUN", "familyName": "STEPHENS", "dob": "yyyy-MM-dd" }

Of note is that your NHI number is not part of the payload, nor is there any information about your specific vaccine status. The only thing that matters to operate the traffic light system is that you have a pass - it could be because you are vaccinated or it may be because of an exemption. The pass doesn’t care.

Also of note is that the jti claim is a UUID, but you can’t just pass the bytes in that order into the constructor for a .NET Guid structure, because Guid expects a different byte order for some segments. To turn it into a UUID URN, I have this very ugly code:

var jtiUuid = new byte[][]
{
    jtiBytes.Skip(0).Take(4).ToArray(),
    jtiBytes.Skip(4).Take(2).ToArray(),
    jtiBytes.Skip(6).Take(2).ToArray(),
    jtiBytes.Skip(8).Take(2).ToArray(),
    jtiBytes.Skip(10).ToArray()
};

var jtiString = $"urn:uuid:{Convert.ToHexString(jtiUuid[0])}-{Convert.ToHexString(jtiUuid[1])}-{Convert.ToHexString(jtiUuid[2])}-{Convert.ToHexString(jtiUuid[3])}-{Convert.ToHexString(jtiUuid[4])}".ToLower();

We now know everything the holder of this pass is claiming. But are their claims valid?

Validate that the iss claim in the decoded CWT payload is an issuer you trust refer to the trusted issuers section for a trusted list, if not then fail.

The value was did:web:nzcp.identity.health.nz and we trust this issuer. Although I would argue that if it had a .govt.nz domain it would seem more trustworthy.

Following the rules outlined in [issuer identifier(https://nzcp.covid19.health.nz/#issuer-identifier)] retrieve the issuers public key that was used to sign the CWT, if an error occurs then fail.

We can retrieve the public key from the DID configuration at https://nzcp.identity.health.nz/.well-known/did.json.

{
    "id": "did:web:nzcp.identity.health.nz",
    "@context": [
        "https://w3.org/ns/did/v1",
        "https://w3id.org/security/suites/jws-2020/v1"
    ],
    "verificationMethod": [
        {
            "id": "did:web:nzcp.identity.health.nz#z12Kf7UQ",
            "controller": "did:web:nzcp.identity.health.nz",
            "type": "JsonWebKey2020",
            "publicKeyJwk": {
                "kty": "EC",
                "crv": "P-256",
                "x": "DQCKJusqMsT0u7CjpmhjVGkHln3A3fS-ayeH4Nu52tc",
                "y": "lxgWzsLtVI8fqZmTPPo9nZ-kzGs7w7XO8-rUU68OxmI"
            }
        }
    ],
    "assertionMethod": [
        "did:web:nzcp.identity.health.nz#z12Kf7UQ"
    ]
}

You will note that the key ID from above (z12Kf7UQ) is present in the DID document. So it must be a valid key.

We need to extract the JWK from there, and then validate the entire original message with that key.

With the retrieved public key validate the digital signature over the COSE_Sign1 structure, if an error occurs then fail.

Up until now we have just been parsing a CBOR object. Now we have to validate the signature. Microsoft doesn’t provide anything that is specific for COSE. So we will leave that for the next post, along with an explanation of how this is very similar to a lot of authentication that happens on the web.

For as long as I can remember, every now and then, all my Docker containers restart. I had no idea why.

I am running Ubuntu 16.04 LTS (Xenial).

I got the exact start time of my containers like so:

docker inspect --format='{{.State.StartedAt}}' <CONTAINERID>

(Thanks to Tim Robinson for that bit of magic.)

Then I looked in the syslog for entries around that date. (I used lnav to make that a bit easier to do.)

This is what I found:

Oct  7 06:09:52 jandell systemd[1]: Starting Daily apt upgrade and clean activities...
Oct  7 06:10:04 jandell systemd[1]: Stopping Docker Application Container Engine...

It looks like apt does stuff every morning, and as part of it, if it deems it to be required, restarts Docker. This is likely because things Docker has been using have been upgraded. Sometimes when I install or upgrade, I’ll get a full screen prompt asking which services to restart because dependent libraries have been updated. Docker is often one of the candidates.

So how do I stop this? Do I want to?

The main problem is that my nginx + docker-gen container don’t properly restart after Docker does. If I’m in charge upgrading Docker, then I can live with this and just make sure all my services are running after I do my upgrade. I don’t want the system automatically upgrading itself.

Based on the Gist “how to disable apt-daily.timer”, I’ve determined I can disable the automatic upgrade task apt-daily-upgrade.timer:

$ systemctl stop apt-daily-upgrade.timer
$ systemctl disable apt-daily-upgrade.timer
$ systemctl daemon-reload

This should hopefully stop apt from restarting things when I don’t know about it.

As to why nginx-gen doesn’t restart when it should, that’s for another time.