Dan Clarke

The Many Use Cases of AI Coding Agents

2026-04-24T00:00:00Z

I've been using AI coding agents a lot lately - tools like Claude Code, GitHub Copilot CLI, and OpenCode. And the more I use them, the more I keep discovering new use-cases and ways they can be used.

Most people think of AI coding tools as just that - tools that write code. And yes, they do that, and they do it really well - but they also do much more than that.

Writing Code

First, let's start with writing code, before we dig into other use-cases. Watching the speed at which AI generates code might initially be seen as terrifying. But now, what I'm genuinely finding terrifying - is that I used to write all that myself by hand! The sheer amount of time I spent writing code that just did small, mundane things. Boilerplate, plumbing, wiring things up - all of it. Looking back, it's crazy how much time that took!

I rarely write code by hand any more. I describe what I want, and the agent generates the code. And the code it produces is genuinely good - often much better than what I'd have quickly thrown together myself. And I'm also no longer restricted to just languages I know - I recently created a Garmin app for my watch that used Monkey C!

And when I say "code", I mean all of it - application code, infrastructure-as-code, CI/CD pipelines, Dockerfiles, Kubernetes manifests, Terraform, the lot. From the agent's perspective, there's no distinction between "application code" and "infrastructure code" - it's all just text and tools. No more hand-writing YAML! 🎉

AI also doesn't have the mental resistance that a human has - for example, when faced with various time and business pressures, it's common for a human developer to skip "just a few" of those automated test cases. "Let me just write enough test coverage to get it through the PR review" (sound familiar?). AI doesn't have that constraint - it can generate a lot of test coverage without the mental fatigue / resistance, and also in a fraction of the time. Why wouldn't you take advantage of that?

The Agentic Loop

There's a concept that underpins a lot of what makes AI coding agents so effective, and it's worth calling out explicitly - the agentic loop.

When an AI agent is working on a task, it doesn't just have one go and hand you the result. It tries something, then verifies its own work. If the build fails, it reads the errors and fixes them. If the tests fail, it looks at the failures and iterates. It keeps going round this loop - try, verify, fix, repeat - until the task is done.

Using AI is no longer "type a prompt into a textbox, then manually copy code snippets out of the response" - then the typical back and forth, complaining about AI hallucinating. Hallucination is still a thing - but we just see less of it thanks to this hands-off self-correcting agentic loop.

Calling CLI Tools You Already Have

This one is huge, and I think it's massively underappreciated.

Your machine is already full of powerful command-line tools - kubectl, docker, az, dotnet, terraform, PowerShell, the Aspire CLI, and countless others. You probably use a handful of them regularly, but let's be honest - how many of us actually remember the syntax for anything beyond the basics? And even if you do - it takes time to type - so you're focusing on that, rather than what you're actually trying to achieve.

AI coding agents have access to those commands, and for most of them they'll already know all the syntax and tricks anyway. If it doesn't - it can quickly find out. Then it can just run these tools directly for you - they become an implementation detail, rather than something you have to worry about. You don't need to remember the syntax - you just tell the agent what you want to achieve, and it figures out which commands to run.

A few weeks ago, my Kubernetes cluster was reaching capacity. Rather than manually inspecting deployments and working out what was over-provisioned, I just told Claude Code to use kubectl to explore the cluster and see if anything could be optimised. I also pointed it at the code for the projects I was hosting. It inspected resource requests/limits across all my deployments, identified things that were over-provisioned, and made a bunch of suggestions to clean things up. The whole process would have taken me ages - it took the agent minutes. It also meant I didn't need to increase my cluster's capacity - so immediately saved me money.

Similarly, the Aspire team have recently ramped up what the Aspire CLI can do - it can now pull logs, traces, and metrics. This means your AI coding agent can just call the Aspire CLI to get all of that observability data. Combine that with the fact that the agent also has access to your code, and it can connect the dots between what's happening at runtime and what's in the codebase. That's incredibly powerful.

Debugging and Investigating Issues

Because the agent has access to logs, traces, and metrics - whether that's via the Aspire CLI, a Grafana MCP, or just reading log files - and it also has access to the code itself, it can investigate issues far faster than I can. It can trace a problem from the symptoms in the logs right through to the offending line of code, all in one flow.

But it's not just code bugs. A few weeks ago, my machine was running slowly. I couldn't figure out why. So I told Claude Code to investigate it. The agent used a whole bunch of command-line tools to look at event logs and system diagnostics. It found that my network driver was outdated and was raising a huge number of error events, which was dragging the whole system down. I would never have found that myself - at least not without a lot of frustration and wasted time.

Same goes for CI pipeline failures - I quite often just give the build id to the agent and tell it to investigate and fix the issue. It'll grab the build logs from either the gh CLI if in GitHub Actions, or the Azure DevOps MCP if in Azure DevOps (those are the two I use) - and do the rest itself!

Throwaway Scripts

There are tasks that come up from time to time where you could write a script to automate it, but the effort of writing, testing, and debugging that script just isn't worth it for a one-off job. So you end up doing it manually, which is tedious and error-prone.

AI agents completely change that. They can knock out a throwaway script in seconds, use it, and then you just delete it.

Here's a real example: I wanted to export my newsletters from Beehiiv and convert them into Markdown files so they could be source-controlled. The Beehiiv export gives you CSVs full of HTML - completely unreadable. I told Claude Code to take the CSV and convert all the newsletter issues into individual Markdown files. I also told it to use the Playwright CLI to verify that the converted output matched the original.

The agent then created a Python script full of regular expressions to bulk-convert the HTML. It ran Playwright to verify the output, found mistakes, went back and modified the Python script, and kept iterating until everything matched up perfectly - all without my involvement. Once it was done, we just deleted the script. Job done.

In the past, writing that script by hand - with all the edge cases and verification - just wouldn't have been an option. But with an AI agent, I'm now able to do things that I previously couldn't have justified spending the time on.

Custom Skills and Commands

Most AI coding agents support some form of custom skills or commands - reusable prompts that you can trigger with a shortcut. In Claude Code, for example, you can create skills and invoke them with a slash command.

This has been a game-changer for me. Here are a few I use regularly:

Podcast show notes - I've got a skill that creates new show notes for my podcast, following my exact format and structure.
Newsletter editions - A skill that creates a new newsletter edition and researches news items for me. (note that I still manually cherry pick what news items I want, and more often than not, hand-write the descriptions - my newsletter is certainly not AI slop!)
Git commits - When I run /commit, it asks me if I want to include "Closes #123" for a GitHub issue, and whether I want to push afterwards. It's a small thing, but it's exactly how I want my workflow to work.
Jira tickets - I've got a skill that creates Jira tickets and fills out all the custom fields that my client requires, asking me questions along the way. No more fighting with Jira's UI, and remembering that client's various custom fields I need to set.
Plus many others.

Creating these skills is surprisingly easy - it's just a directory with a markdown file called SKILL.md, plus any other additional files you want to include (images, PDFs, etc). Claude Code even has a skill creator skill that helps you build, improve, and verify them. If you don't use Claude Code, you can still use that skill - as skills are just portable markdown, following a standard format.

Tickets, PRs, and Collaboration Tools

Thanks to tools like the GitHub CLI (gh), the Azure DevOps MCP server, and similar - your agent can read and write across all the collaboration tools you use day-to-day. Tickets (JIRA, Azure DevOps, GitHub Issues, etc), PR comments, the lot.

I often get the agent to query a ticket to pull out the description and acceptance criteria before starting work. It's an amazing context primer, and gives the agent a good checklist to work against. As mentioned above, I also use a skill that writes JIRA tickets for me.

On the PR side, the agent can read comments that reviewers have left and either fix them directly, or suggest reasons to push back. Technically, you can also get it to reply in the comments for you - but I probably wouldn't recommend that if the reviewer is expecting a human response. Unless of course it's an accepted practice within the team.

As an aside, GitHub does have native cloud-based AI code reviews too - but those are out of scope/context of this post.

Standard disclaimer!

Before you go and let your AI agent loose pointing at all your production environments - obviously ensure you take the necessary precautions. If you're giving it access to a prod Kubernetes cluster for example - ensure its authentication has the necessary authorisation restrictions - eg. readonly.

It's easy to anthropomorphise these AI agents - and yet, people are happy to only anthropomorphise certain traits, and still expect AI to not make mistakes. AI does make mistakes, just like humans do. The problem is that if AI makes mistakes - it makes them MUCH FASTER. So do be careful.

Personal projects

On a personal note, I'm currently using Claude Code to build lots of stuff that I wouldn't have previously been able to justify...

An entire fitness product that I'm planning to productise. Before AI, this project would have needed a team of developers doing years of work. Now I'm able to build it in my spare time without having to quit my job, or it impacting my family-time or fitness training. That's how much of a difference this makes.
Plus so many small utility apps - from a desktop pomodoro timer, to a time blocking app. Things I never would have been able to justify the time creating previously.

Also, lots of non-code stuff - a few examples...

I coach kids' athletics and have recently been managing a series of competitions that our club was competing in. This is a real pain to do, as there are various activities with limited slots, and I get various requests from parents. There's also a bunch of forms to fill in, etc. Claude Code has made this WAY easier - especially working out the allocations, which can get complicated.
I wanted a personal-finance long-term forecast solution - which takes into account income, pensions (including future draw-down over time), inflation, future big spends, etc, etc. I just threw all my info into Claude Code, and it generated a system for me, which shows charts and projections, doing all the tax calculations, etc. It's amazing!

Plus many more things that I won't bore you with - but the point is, the use-cases for AI coding agents go way beyond just writing code.

Wrapping Up

I've covered a lot of use cases here, but honestly, this barely scratches the surface. Every week I seem to discover a new use-case that I can use an AI agent for. The combination of being able to write code, run any CLI tool on your machine (or use MCP Servers), generate throwaway scripts, and iterate on their own work through the agentic loop - it all adds up to something that totally changes the way we work.

I should probably briefly touch on cost. Personally, I pay for the Claude Max 5x plan. It's not cheap if you compare it to a subscription like Netflix or Spotify. But if you compare it to having a team of developers at your disposal, it's an absolute bargain. The amount of time it saves me, and the amount of stuff it enables me to build - both personally and professionally - is worth way more than the cost.

If you're using AI coding tools but only for writing code, I'd really encourage you to explore what else they can do. I'd love to hear about the different use-cases you're using AI for! Please let me and the other readers know in the comments below! 👇

Developers are System Thinkers, not Code Monkeys

2026-04-11T00:00:00Z

There's a lot of concern amongst developers at the moment that AI is going to take our jobs. And I get it - things are moving fast. But I think a lot of this fear comes from a misunderstanding of what we actually do. We're not typists. We're not "code monkeys". We are system thinkers.

First of all though - I'm going to be blunt. If you're not heavily leveraging AI right now - learning it, playing with it, embracing it - then you're going to get left behind. And not just by other developers - by non-developers who are! That should be a wake-up call.

Right, let's talk about systems. As developers, we are very good at systems. Think about it - we work with them all day long...

Your code is a system (consisting of functions, classes, modules, and so on)
A database is a system
A message broker is a system
Your CI/CD pipeline is a system
Git is a system
JIRA is a system
Those automation scripts you wrote to save yourself time? Systems.

And all of these things combine together in different ways to make bigger systems.

We've spent our entire careers taking complex problems, breaking them down into smaller pieces, and building systems to solve them. We understand how to integrate different components together. We understand how things fit together.

Make no mistake - AI is going to dramatically change our industry. It already is. The way we build software, the way we work, the tools we use - none of this is going to look the same in a few years. But at its core, AI is still a system. A very powerful system that's evolving at a frightening pace - but still a system. And who better to understand, integrate, and leverage a new system than the people who've been doing exactly that for years?

The developers who will thrive are the ones who recognise that this is their real skill. Not typing code - but understanding systems and how to orchestrate them. If you can design how an AI agent fits into a larger architecture, break down what it should and shouldn't do, and integrate it alongside your existing systems - you're in a really strong position.

So don't be the developer who's afraid of AI. Be the developer who treats it as the latest system to learn. Play with it. Experiment. Build things with it. The more you understand how it works, the better you'll be at leveraging it - and that's exactly what we've always done.

Year in Review: 2025

2026-01-02T00:00:00Z

Happy New Year everyone! 🎉

Let's start off with a few small confessions...

It's been quite a few years since my last blog post!🙈
I intended to get more into my YouTube channel, but didn't publish a single video! 😬 (though I did publish one on Nick Chapsas's channel! - more on that later)
I only published 10 podcast episodes

The first two are definitely on my list of new year's resolutions to do something about in 2026. The podcast one too - but, to be honest, I'm happy if I do one a month - it's the YouTube channel I want to focus more on this year.

For the blog - one of the things I did do in 2025, was a re-write of this website! (see below). So given that, I should really start getting back into blogging! So let's start that new years resolution with another "year in review" post...

Website re-write

I wanted to move this website to a be a statically-generated site (not using a database, etc). This makes it more manageable, and all in one place. I went with 11ty.

I also wanted to change the home page to be a place that I can send people to for links to all my things (social links, podcast, newsletter, courses, etc).

I'm really pleased with how it's turned out - and AI certainly made the rewrite a lot easier too! If you have any thoughts or feedback, please do let me know.

Podcast

There were 10 podcast episodes released this year. Which doesn't actually sound that much when I look at that number! I would have guessed more than that. There were 20k downloads in 2025. I had some really amazing guests on - checkout the website for more details: unhandledexceptionpodcast.com

My newsletter has continued to go out each month - with a steady growth in subscribers. Each episode has a list of hand-picked new items from the past month, a dev tip, a dev comic pick, and more.

I must admit, whilst the number of subscribers is growing over time - it's not growing as much as I would have hoped. Which I find a bit surprising, given the news items are such a great way for developers to keep up to date with the latest happenings in our industry. And it's only monthly, so not a big inbox hit either.

If you haven't signed up yet, you can do so here: danclarke.beehiiv.com. If you have signed up - thank you! I really appreciate it. If you get value from it, please do share it with your friends and colleagues - it really does help.

Everstack

With my company, Everstack - I've continued working with my current two main clients. One of which, I've finally got to the end of the backlog, which will free up a bit of my time for more content creation, which I really want to focus more on in 2026.

Dometrain

Earlier in 2025, I released my 4th course on Dometrain - Getting Started with .NET Aspire. This was a really fun course to create, and I've had some great feedback. I'm strongly aware that the technology has moved on a bit since I created the course, and I really want to update it in 2026 to reflect the latest changes.

The previous courses (Docker, Kubernetes, and JetBrains Rider) have all continued to do well, and I've had some great feedback from those too.

YouTube

Each time I finish a course, which gives me tons of practice with creating videos - I say to myself, "right, now I'm all warmed up with video creation, I must do more on YouTube!". But then I never seem to get around to it! So 2026 is the year I really want to focus more on my YouTube channel. If you can all be my accountability partners and nag me if I don't - that would be amazing! 😄

*In fact - at the start of this post, when I said I didn't publish a single YouTube video. That isn't technically correct, as I did have the honour of being asked by Nick Chapsas to publish a video on his channel! I created one on Getting Started with MCP (Model Context Protocol).

.NET Oxford

We had three in-person .NET Oxford meetups in 2025, and it was great to catch up with everyone again. Our meetups are quarterly, and we unfortunately missed the first (March) one due to me being a bit rubbish. The June and December ones were our usual lightning talk format, and for the October one we held an "unconference", which is no set agenda, no prepared talks, no slides. We used Slido to gather topics from the attendees, and then everyone voted on what to discuss. We picked the top ones, and time-boxed group discussions about them. It was really nice doing that rather than our usual "speaker in front of everyone just watching" format. We'll definitely have to try that another time.

Personal life

On the personal side of things, 2025 was a really good year. My family and I went on a few different holidays, and have already planned more for this year. My boys are growing up so fast now - my eldest is almost as tall as me! I feel incredibly lucky and fortunate to have such an amazing family, a job I love, and great friends.

New Years Resolutions

To wrap up this post, here's a list of my new years resolutions (some mentioned above).

Get back into creating content on my YouTube channel
Start blogging again
Start playing the guitar again
Get into running (I train a lot at the gym with weights, but am really unfit cardio-wise)

I plan to continue as I am, for other areas - eg. podcast, gym, family, client-work, etc. So whilst not technically 'new years resolutions' - they're definitely things I need to continue focusing on.

I'm also very excited to see what happens in 2026 with AI. There was so much progress in 2025, and I can't see it stopping soon. We certainly have interesting times coming up, and I for one, am so glad to get to see this within my lifetime!

Happy New Year everyone, and happy coding (vibing?)!

Source-controlling Config files in Git (dotfiles?)

2022-10-08T00:00:00Z

I've recently setup some of my various config files to be source-controlled in a Github repository. Here are some examples of what I mean by config files...

My .gitconfig file - which includes various aliases and settings
My Powershell profile - which likewise, includes various aliases and environment variables, etc
OhMyPosh theme - customised command line setup (see screenshot below)
Windows Terminal config
Chocolatey packages
NeoVim config files
K9s config

There are more configs I want to add - eg. my Visual Studio Code config files; my Rider config, etc.

Why?

I've found a ton of benefits to doing this, which I'll try and detail in this post...

Confidence in not losing my setting

In the past when I've done things like customise my terminal - I would have no idea how to get it back exactly as it was if I lost all my settings. Even with my .gitconfig setup - there are aliases in there which I've fine-tuned over time, which I really wouldn't like to lose! And Vim... ha! Any Vim user who loses their config - good luck recreating that if you've been tweaking over time! Having all of these things in Github backed up takes a massive weight off my mind.

My changes are intentional and deliberate

Every time I tweak a configuration - I create an explicit commit for that change with a meaningful commit message. No changes are accidentally made, and I'm free to play with my configuration temporarily. I can see those changes in my pending changes, and choose whether to revert or make them official with a commit.

Increased motivation to tweak

Because this is a Github repository that contains all of my config files - it's now become quite important to me. They're not just random individual config files on my computer any more. Because of the above two points (confidence and intentional changes) - I've found that I'm now much more motivated to improve them and make more tweaks and customisations, to get an even more awesome setup!

Transferable between machines

Another obvious advantage is that I can share them between multiple machines. I have a desktop, laptop, and multiple VMs. If I make a tweak on one machine - I'll push those changes, and periodically pull when I'm on the another machines.

Github issues!

Because this is a Github repo, I can create issues against it. Quite often I'll be in the middle of something, and have an idea for a config tweak I'd like to do to improve my workflow - but I don't have time to do it at that moment. Eg. I mentioned earlier that I'd like to add VSCode and Rider config to it. Or it might be Vim tweak that I'll need to look up how to do. Github issues are perfect for capturing those ideas, so I don't forget!

How does it work?

Obviously each application has its config files in different locations - whereas a Git repo is just in one place. Symlinks solve this problem nicely! I have a Powershell script called Setup.ps1 in the same repository, which ensures my symlinks are all setup (code is below). The script is idempotent, so I can run it anytime I want to make sure my system is up to date with any symlink changes I might have made on another of my machines.

Then I have folders for each app...

To pre-empt the obvious question of whether my repo is public - I'm afraid, it's not. I don't want to have to worry about what I push to it. Mostly, there's nothing sensitive in there - but there are a few directory aliases that point to client folders which include their project names. It's just easier to keep it private.

However, here's a Gist with my Setup.ps1 in it to get you started...

The above script and the folder structure in the screenshot above, should give you a good starting point and idea of how it works, for your own config files.

What are 'dotfiles'?

After I started doing this - I was talking about it with someone, and they asked if I was using 'dotfiles'. I had heard the term, but wasn't sure what it was. So I Googled it, and found this and a few blog posts. The name comes from the fact that quite a few config files start with a dot - eg. .gitconfig, .vimrc, etc. Whilst there seems to be a community around creating helper scripts around 'dotfiles' - from what I gather - it looks like this isn't an actual thing - but rather just a term for what I was already doing anyway. Ie. Leveraging symlinks to make config files source-controllable.

Who should mark PR comments as resolved?

2022-05-27T00:00:00Z

Before reading this post - note that when I say "resolving", I'm only talking about clicking the "Resolve" button for that particular comment thread. I am not talking about actually fixing the issue that the comment is describing.

The TLDR; version is that the person who started the PR comment should be the person to mark it as resolved.

Also note that I'm talking about PRs within a team - not open source projects.

The reason I'm writing this post, is that it's something I keep on seeing come up. I leave a PR comment, and the PR author makes a change to fix it, then they resolve my comment before I have a chance to review that fix/change.

What's wrong with this? It means changes can be merged into the main branch that haven't been reviewed at all. Which kindof defeats the purpose of a PR!

Take this scenario...

Bob creates a PR for a feature he's been working on
Both Frank and Jane are reviewing the PR
Jane spots a bug, and adds a comment
Frank doesn't spot the bug and approves the PR
Bob fixes the bug, marks Jane's comment about the bug as resolved, and then completes the PR

However, Bob misunderstood the bug fix, and didn't fix it correctly. Jane, who spotted the bug hasn't had chance to review/accept the new changes, as Bob wrongly completed the PR comment on her behalf. Unreviewed code has now made it into the main branch, which could well be CI/CDing straight to production!

If the author of the PR comment is always the person who has the responsibility of marking that comment as resolved - this gets rid of this problem, and all changes will have had by at least two people's eyes on them.

Redefining the term '10x Developer'

2022-05-12T00:00:00Z

TLDR; - The term "100x Development" is better because it focuses more on the nature of software development, not an individual. And the 10x is just too small of a multipler.

I was recently honoured to be a guest on The .NET Core Podcast to chat with Jamie Taylor about developer productivity. The full episode can be found here, or in your favourite podcast app.

In it, I asked Jamie what he thought of the term "10x developer" - which is a term I hear thrown around quite a lot. Here was his reply...

"If I'm honest, right hand on heart, I hate the phrase. 10x when compared to what, right? You can't say 10x when you haven't described what a 1x is, right? I think that is used by people to sort of say I'm better than you. And in a team, you don't want a superstar, you want a bunch of people who are all working together. And so if I was working in a team with someone who was a self-proclaimed 10x developer, I would try to avoid them as much as possible."

I found this a really interesting angle, and as I thought about it afterwards - I realised that the problem with the term, is the word "developer". Okay, that's not the only problem - eg. productivity isn't a linear sliding scale, so what does 10x even relate to - but let's ignore that for now.

The thing I do like about the term is the 10x bit. Or 100x. Or 1000x. And I'm not talking about an individual developer being 10x either. I'm talking about the nature of tasks in our industry being 10/100/1000x depending on how you go about that said task.

Here are a few examples...

You need to fixup namespaces across your entire solution. Do you do it manually in each file? Or do you hit a keyboard shortcut so your IDE does it for you in seconds? How many X is that? 100+ maybe?
You spend 2 months building a feature. Or you discover a library that does it for you. 2 months vs 1 hour? 300x.
You have a process that's repeatable and needs doing often. You manually do this process each day for the next few years. Or you automate it to get all that time back. 1000x?
You have a performance issue in your app. You manually try to work it out by putting logs and timers in code. Or you've previously learnt how to use a profiling tool which very quickly gives you a detailed analysis of what's going on.

As you can see - in software development, there are massive multipliers to be had depending on how a task is done. A developer who knows more of these things, will be more productive - but I think the term "10x developer" focuses on the wrong thing. It focused on the individual, rather than the tasks themselves. So I think "10x development" is a much better term, which focuses more on the act of software development, rather than an individual. The "10" bit could perhaps be changed too, as it can be way more than that. So let's change that to 100x - as the point is that it highlights the very high standard-deviation in time taken to complete a task based on how that task is done.

Basically, work smarter to be more productive. I don't know where the term "work smarter, not harder" originally came from - but if there's one industry where this applies to more than any other - it's software development. As developers, we have so much opportunity and power to automate tasks, leverage IDEs and tooling, and complete tasks WAY faster.

Raising Awareness of Aphantasia

2022-01-21T00:00:00Z

Last year, whilst browsing the web on my phone, I learnt something that blew my mind. I can't remember exactly what (or why) I googled about 'visualisations', but some of the results said things like "Did you know that some people can't see images in their mind's eye?!". I read that, and thought - "Wait? What! Some people can?!".

So it turns out that ~3-5% of the population have something called Aphantasia, which means they have a blind mind's eye. There's also some research that suggests that people with Alphantasia are more likely to get into a career in IT - meaning in our industry, the percentage could well be higher. So this post isn't completely off-topic!

Based on those stats - most of you reading this will be surprised that some people can't see things in their minds eye...

But some of you will be reading this, and be as blown away as I was. After all - how we percieve our thoughts isn't something that crops up in every-day converstion. I'm in my 40s, and have only just learnt that other people can see images in their heads. There must be so many people out there who, like me, have Aphantasia but don't know it. This is the purpose of this blog post - to raise awareness of it. I'd love to hear your experiences in the comments - especially if you've only just discovered you have Aphantasia!

In a recent podcast episode about UX, I mentioned about my Aphantasia, and coincidentally enough, the guest said that she also had it too. And also a listener, who I also know through .NET Oxford, Tweeted...

Listening to @dracan podcast I found out I have Aphantasia. Had no idea this was a thing.
— Tom (@tomduttonuk) January 1, 2022

Since then, I've chatted quite a bit with Tom about this. We've both wondered if developers without this use their visualisation to help them with coding. If you're a non-Aphant programming reading this - I'd love to hear your experiences about this.

Do you have Aphantasia?

If you read the next sentence, but don't read any further until you've tried what it says...

Close your eyes, and imagine a ball on a table. Imagine pushing the ball off the table, and it falling onto the floor.

I'm assuming you've now opened your eyes again, otherwise you wouldn't be able to continue reading this! :) What colour was the ball? What colour was the table? Describe both. From what I've read, most people with Alphantasia would probably say that it didn't have a colour (that would be my answer). For me, whilst I can imagine it - I can't actually see anything, and I didn't even concider that it would have a colour.

Another common test is to just try and imagine a red star in your mind's eye. Which of these is closest to what you see?...

(source: https://www.reddit.com/r/Aphantasia/comments/aioyga/simple_aphantasia_test/)

For me - it's #1.

And here's another one...

Think of a horse 🐴

No, really. Close your eyes and think of a #horse. Which image best describes your #experience?#Imagine #NoHorse #Aphantasia #AphantasiaTest #Extreme #Imagination #BlindMind #AphantasiaLife #MindsEye pic.twitter.com/iNokhjMY9A
— Aphantasia Network (@_aphantasia) January 6, 2020

I've always thought terms like "picture X in your minds eye" were expressions, and not actually meant literally. When people meditate and say "imagine yourself on a beach" - I had no idea people actually saw the beach. When people say to count sheep to try to fall asleep - I had no idea that people actually saw sheep. In those memory-training books, where it describes having "mind palaces" having a scene in your mind where you mentally place things to help you remember them. Again - I had no idea people actually saw their mind palaces!

How do I imagine things then?

Let's pretend the word 'imagine' doesn't derive from 'image'! If I imagine that I'm, for example, at my parents' house - I still have a mental model of the scene. I have a position in the scene, and walls/objects also have 3-D positions in that mental model. I just don't see anything. No colours. No edges. Nothing. Chatting with my dad, he doesn't understand how I can imagine scenes, without being able to see them. It's at this point that I realise it's very hard to describe what I experience. The closest word I can find to describe it is that it's a feeling of the scene. Albeit, a very spacial feeling. It's a conceptual mental model.

Is this a disability?

When I first found out about this - I felt like I had just discovered I had a brain disability and my brain wasn't functioning properly. Everyone else has this super-power that I hadn't even known they'd had.

However, the more I read about it, and the more I speak to other people about what they experience - the more I realise that this isn't the case. Everyone's brains work very differently (much more so than I had ever thought). Speaking with my dad, it sounds like his thoughts are very dependent on his being able to see stuff in his mind's eye - which feels very limiting to me. Speaking with my brother - who is on the oppositive end of the spectrum having Hyperphantasis (see below), he says he hates it and wishes he was like me. I've never understood meditation, and never needed to. Perhaps having a quieter mind is the reason why.

In a Twitter DM conversation with Tom (see Tweet above), he said...

"Sounds like Sydney uni are doing lots of research into it. One professor said he thinks he could make someone visualise with stimulation and training but comes with the cost that you couldn't undo it once you acquire visualisation. I wouldn't want to change the more I think about it."

I think I agree. I suspect that the difference is much more than just seeing vs not seeing. And it's more that the way different people think is fundamentially very different. I'm not sure I'd want to mess with that! But, I'd love it if there was a magically way to experience it, but revert if I didn't like it.

Hyperphantasia

I mentioned above that my brother is on the opposite end of the spectrum. And it sounds like my eldest son also has this. Basically people with Hyperphantasia have extremely vivid mental imagery. Apparently this is more common than Aphantasia, and has been described as as vivid as real seeing. (wikipedia)

So, this is basically a spectrum. From people with Aphantasia, who can't see anything - to people with Hyperphantasia, who have extreme imagery. And lots of people somewhere in the middle.

Other senses

Whilst Aphantasia/Hyperphantasia refers to the minds eye. It turns out that other people can also experience sound, smell, taste in their mind too. Sadly, I don't have any of these. I can sort-of hear my own inner voice (although, I wouldn't describe it has hearing exactly, but it's certainly using the spoken language). If I have a song stuck in my head, it's my own inner-voice humming it. My mum says that if she thinks of a song, she actually hears the artist's voice singing it. A friend, who's a fellow guitarist, who also has Aphantasia, says he can hear music quite vividly.

I wonder how people sleep at night with all these sights and sounds going on in their mind!

I'd love to hear your experiences!

I find this topic of conversation fascinating - and since finding out about this, I've quizzed lots of different people about their experiences. Regardless of where on the spectrum you are, I'd love to hear how you experience your thought!

Useful Links and Resources

Year in Review: 2021

2021-12-31T00:00:00Z

It's New Year's Eve, and I've just remembered that I haven't done a 'year in review' blog post this year - so I'm quickly knocking this out now! In fact, I'm sorry to say, I haven't blogged much at all this year - with my primary focus being on the podcast. This will only be my second blog post of the year! Hopefully, the podcast content makes up for the lack of blog content! So let's start with that...

The Unhandled Exception Podcast

I started The Unhandled Exception Podcast near the end of last year, and spoke about it a bit in my last yearly update, and also in a dedicated post about starting it. I'm now up to 29 episodes, and have thoroughly enjoyed chatting with plenty of awesome guests about various software development topics. I've also learnt a ton about podcast editing, which I also enjoy - although, it's certainly the most time-consuming part of podcasting! I took a bit of a break in December so I could catch up on other stuff - but will definitely be back in the new year with more episodes!

.NET Oxford

.NET Oxford is also still going strong. Still virtual for the time being, but that's given us the advantage of being able to welcome members from all over the planet!

We will at some point return to physical events - perhaps even this coming year. But we'll have to ensure that however we do it - we retain some form of virtual presense, so that we don't exclude our new members that are too remote to physically attend. This won't happen in the first quarter of 2022 at least though.

Everstack

With my company, Everstack - I've started working with another big client - where I've been really enjoying helping the team start to migrate their monolith codebase over to a new micro-service architecture running in the latest .NET, Azure, and Kubernetes. This has also involved a lot of mentoring, which I also really enjoy.

On top of that, I've also continued working with another of my main clients, where I've been building the new version of their original software (which I also wrote many years ago), but instead of it being a desktop app - it's now web-based, multi-tenant, and can support their clients. This is also built on .NET, Azure, and Kubernetes.

Since the pandemic started, I haven't been back to a clients' office to work - with just two in-person meetings in total. What the pandemic has done to our industry regarding remote work, is perhaps one of the few positives that have come out of it. I'm certainly very happy working remotely, and have no intention to go back to an office that isn't my home office. But given I'd like to expand Everstack and grow in the future - the fact that remote is now the new norm, makes this a lot easier too. I'd always expected to have to get physical premises (which are obviously very expensive, and limited to a local team). Now I've experienced working with remote teams, and can see that it works well - the barrier to entry for me expanding Everstack has now been dramatically lowered, and Everstack will most certainly be a remote company when it expands.

Family life

Nothing particularly new to report on the family front - both boys are still getting bigger by the day. We've been very lucky with how well they get on with each other - they're best friends, which is perhaps rare for brothers of their age. My wife's also still working part-time remotely, which has worked really well.

I've also started regularly playing the guitar again. I used to play, but haven't picked it up much. I've now started making sure I play/practice daily, and (touch wood), I seem to be sticking at it this time!

Snapshot Testing with Verify

2021-12-10T00:00:00Z

This post is part of two awesome advent calendar initiatives - the .NET Advent Calendar 2021, and the C# Advent Calendar 2021. Check out both links for awesome community blog posts!

In a recent episode of my podcast (The Unhandled Exception podcast), I was joined by Simon Cropp to chat about a form of testing called snapshot testing - which has completely changed the way I now write my tests!

Simon is the author of the Verify .NET snapshot testing library, and also a maintainer of ApprovalTests, which is also a snapshot testing library.

I'd heard of snapshot testing before, but hadn't really used it. In the week leading up to recording the podcast, I started to play around with it, and have quickly become an avid fan. This is going to save me so much time writing tests, and the more I use it, the more I wonder why this isn't more of a commonly used testing methodology. Most developers I ask, haven't even heard of snapshot testing. I think that's a big mistake, given both how powerful it is, and how much time it can save.

What is snapshot testing?

Simon said near the start of the episode that perhaps the term "snapshot testing" is badly named, and it should instead be called "snapshot assertion". This is because it's the assert part of your test that this relates to.

A simple example...

// Arrange
var sut = new MySystemUnderTest();
// Act
var result = sut.DoSomething();
// Assert
await Verifier.Verify(result);

It's only the last line that relates to snapshot testing. This will serialise result in some form or another (depending on what it is), and write it to disk. This is known as the "received" file - ie. that's the output from the current test execution's verify. This gets compared to another file on disk called the "verified" file. If they're different, then your test fails. If they're the same, then your test passes.

If you're paying attention, you might now be asking what creates that "verified" file in the first place. How does my test ever pass? The answer is - the first time you run it - it will always fail. The act of copying the "received" file as the "verified" file is your way of saying "I approve this version", and this verified version goes into your source control system, alongside your changes. Note that the act of copying the file, sounds very manual - but I haven't yet once had to manually copy that file across, as my diff tool does this for me...

Diff-tool integration

How many times have you had a failing test, where the assertion is comparing JSON, and you've had trouble working out what is different based on badly formatted JSON in the test output window? I quite often end up manually copying and pasting the JSON into vscode so I can format the JSON - then copying both sides into WinMerge to compare.

With Verify, not only do I not have to generate the expected data in the first place (more on that shortly) - I automatically have my diff tool of choice, popup as soon as the test fails, showing me exactly what has changed!

If I'm happy with those changes, I just use my diff tool's UI or keyboard shortcut to copy those changes from left to right, and that's it! The saved right-hand side becomes the new 'truth', which then gets committed to source control alongside my main code changes.

Note that my example above is talking about .NET objects being serialised to JSON. But Verify also works with tons of other content types (eg. images, PDFs, etc) - and it also integrates into tons of other libraries (eg. Playwright, Entity Framework, Blazor, ImageSharp, etc).

Multiple diff tools are supported - and if you have more than one installed, you can configure which ones it should use with the DiffEngine_ToolOrder environment variable.

How much time does this save the developer?

Okay, before we go on - let's stop for a minute and contemplate how much time this actually saves...

A lot of the tests I write are asserting against non-native objects - eg. DTOs or a collection of DTOs. Sometimes they might be nested. So without snapshot testing - I need to manually write code to generate the expected data to assert against. For example...

// Arrange
var expectedData = new List<Order>
{
    new Order()
    {
        PriceNet = 100m,
        PriceGross = 120m,
        OrderItems = new List<OrderItems>
        {
            new OrderItem
            {
                Sku = "test-sku-1"
                ...etc..
            },
            new OrderItem
            {
                Sku = "test-sku-2"
                ...etc..
            },
        }
        ...etc..
    },
    ...etc...

    // yawn! it is hometime yet?
};

var sut = new MySystemUnderTest();

// Act
var result = sut.DoSomeThing();

// Assert
result.Should().BeEquivalentTo(expectedData);

Now let's compare this to Verify...

// Arrange
var sut = new MySystemUnderTest();

// Act
var result = sut.DoSomeThing();

// Assert
await Verifier.Verify(result);

Need I say more? ;)

When you run that Verify test for the first time - it'll pop up your diff tool...

I can review it to make sure it's what I expect. Then I can just use the diff tool's native way of copying from left to right. In WinMerge's case, it's this button...

Save the file, and that's it! The test will now pass! You'll also have a new file, in this case, called DemoTests.VerifyDemoTest.verified.txt, that can (and should!) be source controlled alongside your code changes.

A few weeks roll by... and a bug gets introduced in some tax calculation code, which causes the test to fail. When running the failing test locally, it'll automatically pop up your diff tool...

That's so much more clear than messy unformatted JSON in the output window. In the output window - the two sides of the comparison aren't even side by side!

Guids and Timestamps

Sometimes in your test data, you have guids and timestamps that will be different each time your code is run. Verify automatically detects this, and replaces them with DateTime_1..DateTime_n for timestamps, and Guid_1..Guid_n for guids. Where the same GUIDs have the same n value.

{
  Id: Guid_1,
  OtherId: Guid_2
  SomeValueThatIsTheSameGuidAsTheFirstId: Guid_1
}

These are called scrubbers, and you can also write your own too.

DiffEngineTray Tool

Simon insisted that I really need to be using the DiffEngineTray tool. This is basically a system tray tool (Window only at the moment) that aids you when approving changes - also allowing you to accept in bulk...

(screenshot taken from the project's readme)

You can install it just by using the dotnet cli...

dotnet tool install -g DiffEngineTray

I must admit, when I was just using Snapshot testing for .NET Objects that get serialised to JSON (as I described above) - I didn't see much use for this. I was quite happy accepting changes in WinMerge. But... playing around a bit further, I'm soon discovering that this is very useful when dealing with other types of files - eg. images or screenshots. Let's delve into an example of this using the Playwright UI testing tool and Verify Playwright extension...

Playing with Playwright

A simple example that just browses to the podcast website, and verifies the results...

public static class Initialisation
{
    [ModuleInitializer]
    public static void Run() => VerifyPlaywright.Enable();
}

[Fact]
public async Task PlaywrightTest()
{
    using var playwright = await Playwright.CreateAsync();
    await using var browser = await playwright.Chromium.LaunchAsync();
    var page = await browser.NewPageAsync();
    await page.GotoAsync("https://unhandledexceptionpodcast.com/");
    await Verifier.Verify(page);
}

The first run of that test, will pop up two instances of my difftool. One with a screenshot...

And another with the HTML...

Note that because this is the first run - both the screenshot comparison and the HTML diff are empty on the right.

The point here is that it opened multiple types of diff from a single Verify command against the Playwright page - one for the screenshot, and another for the HTML itself. I can now just right-click on the system tray tool, and choose 'Accept all'...

...and life is green :) ...

Perhaps stop and take a moment to think about how little code is in that Playwright test above - and how much value both Playwright and Verify gave us out of the box. It's very impressive.

Recording

Before wrapping up this post, I just want to cover another pretty awesome thing that Simon discussed in the podcast episode. Whilst the concept of "recording" isn't just limited to Entity Framework and its generated SQL statements - this is something that piqued my interest, so I thought I'd have a play...

[Fact]
public async Task EfTest()
{
    // Arrange

    VerifyEntityFramework.Enable();

    var builder = new DbContextOptionsBuilder<DataContext>();
    builder.UseSqlServer(ConnectionString);
    builder.EnableRecording();
    var db = new DataContext(builder.Options);

    // Act

    EfRecording.StartRecording();

    await db.MyTables.AddAsync(new MyTable { Id = Guid.NewGuid() });
    var count = await db.SaveChangesAsync();

    // Assert

    await Verifier.Verify(count);
}

Which on the first run, gives me this...

That's a super-simple example - but you can see how easy it is to get Verify to generate a snapshot of the SQL that Entity Framework outputs. And other than calling .EnableRecording() on the options builder that gets passed into your DataContext, no changes to your code are required. And bear in mind you'd normally pass this in from your tests anyway - even in an integration test.

A lot of the tests I write are integration tests where I spin up a real database in Docker, and write tests against my APIs themselves (not each individual C# class). Verify is great because I can quickly verify the HTTP response and any data my tests query from the database to ensure the SUT did what was expected. However, thanks to this recording concept - for free with just a couple of lines of code in the test - there's now the added benefit that I can also snapshot any SQL statements that my Entity Framework code has made, so every time it changes, tests fails, and I can review why it's different. Bear in mind that it might not just change because my code has changed... it might change when updating to a new version of Entity Framework. Good to know if a new version of EF has changed your SQL (for better or for worse)!

A swath of extensions!

I've touched on a couple of extensions in this blog post - but there are a ton more. From Blazor verifiers, to ImageSharp! And from speaking to Simon, he's very keen for people to get in touch with use-cases for different extensions. He spoke in the podcast episode about how it was important to him that Verify was composable and extendible from the start. And that's clear in the list of extensions he has.

Summary

The more I look into this and use it - the more I honestly don't understand how this isn't a more widely used way of asserting in tests. It saves a massive amount of time, makes diagnosing failing tests far easier, and fulfils multiple different use-cases and scenarios. It's certainly a tool that has been permanently added to my toolbox moving forward, and I'll now be introducing it to all teams that I consult for.

Year in Review: 2020

2020-12-23T00:00:00Z

This year has obviously been a lot different than everyone expected. I feel extremely fortunately and lucky to be in an industry that naturally makes it easy to work from home. In fact, remote work is something I've wanted to try full-time for quite some time, and this year has not only forced it to happen, but also made it more normal in our industry (hopefully now moving forwards). It's just a shame it took something so terrible as what's happening for this to become a thing.

Azure Oxford on hold for the time being

It feels like a life-time ago thinking back to pre-March this year, but I guess that's still part of 2020, ergo this post. I mentioned in last year's update that I'd started Azure Oxford together with James World. On-top of some great events in 2019, we also had two in 2020 - January and February before the lockdown hit. We happened to be a bit behind planning our March event, when news of the Coronavirus hit, so we decided to wait to see what happened. Sadly, we all know what happened, and we then decided to put Azure Oxford on hold. I don't want to say Azure Oxford has been stopped for good, but James and I haven't as of yet discussed bringing it back. A large part of it not coming back virtually (like we did for .NET Oxford) has been time. With the kids being at home for the lockdown (so lunch breaks where I normally got things done were spent with them) and my new contract (see below) being an 8-hour day rather than previous 7.5 (so 2.5 hours more each week) - I just didn't have time to run two user-groups.

.NET Oxford goes virtual

As for .NET Oxford, because this has been going for quite a few years and has quite a decent community around - we decided to attempt to keep this going virtually. And this actually worked really well! Thanks to technologies like Zoom, this has just worked. In-fact, far more people are now able to attend than they could have done in person. Obviously it's not quite the same as an in-person event - but it's still working surprisingly well. We still also get the regulars attending the virtual pub session afterwards (we used to meet in the physical pub after in-person meetups). It's obviously bring your own drinks - but it works! Being virtual, we've also had the opportunity to have speakers where there's no way we could have gotten otherwise - for example, in June we had Scott Hunter join us, and in September we were joined by Scott Hanselman! There is a down-side though with famous speakers being able to talk at user-groups all over the world from their own homes... it's become harder for newer speakers to start getting into public speaking. We've had a couple of lightning-talk events where some of the speakers have been first-time speakers, but I'm quite keen in the new year for our next lightning-talk event to be primarily for new speakers to help encourage developers who fancy giving speaking a go, so dip their toes in!

Starting my own podcast!

I've been an avid podcast listener for many years, and have even vaguely wondered what it might be like to start my own. But I never would have actually done it if it hadn't have been for all the other changes that this year has brought. When I started working remotely full-time, knowing that I'd also be hosting .NET Oxford virtually - I decided to invest in a decent microphone. A new contract (see below) had me pair-programming remotely all day, so I quickly got very used to talking 'programming' all day into the mic. When I first invested in the mic near the start of the lockdown, giving podcasting a go was also in the back of my mind - but due to the kids being at home all the time, I just didn't have the time. Then in October, I started The Unhandled Exception podcast, and ended the year eight episodes in! I've had great feedback, and at the time of writing this, have had 1,134 downloads! I've really enjoyed all aspects of it - from planning the episodes, to chatting and geeking out with the guests, and have also really enjoyed editing and learning all about audio!

Blog post: Starting 'The Unhandled Exception' podcast

Sad news: Sharp Life Science becomes a victim of the pandemic

In last year's update, I spoke about my company Everstack's primary contract/client at the time - Sharp Life Science. This was a medical company building hardware and software to help automate genomic and proteomic applications. It was a fantastic company and team of people to work with, some of those people I'm now fortunate enough to consider good friends. In March, naturally more and more staff moved to remote working, which actually suited me quite well - but then sadly, it became apparent that the parent company was planning to wind down the company. It was a startup that was investment backed - and the parent company had to focus on the pandemic.

New Contract

After finishing at SLS, I did a little bit of consulting for a couple of other companies before finding a longer term client. This is a 100% remote team anyway, even before the pandemic, and I've had the opportunity to work with a lot of really cool technologies! .NET Core, Docker, Kubernetes, Azure, React, etc. They also do TDD, which is the first project I've worked on that has been properly TDDed from the start. It's been quite eye-opening, and has certainly shown me the true value of doing TDD! It's also a really great team, that I really enjoy working with.

Remote working

I've mentioned a couple of times above about remote working. And this is something most of us have had to get used to this year. It's actually something I've wanted to try full-time for quite some time to see if I got on with it. And it turns out that I quite enjoy it, and I'm quite keen to continue doing this, and not go back to an office. I love my home office, and have it set up with decent audio/video equipment, a standing desk... It's home.

I miss the commute where I could listen to podcasts, but have replaced it instead with daily walks or runs where I listen to podcasts instead. It perhaps helps a lot though that I pair-program a lot with the team I'm currently working with, so it's a lot less isolating. It's possible that in the future I might change my mind about remote work, if I'm working with a team that's in the office, and I'm the only person working remotely. Time will tell!

MVP renewed!

I'm also very honoured to say that my Microsoft MVP status was renewed in July this year! I'm very proud to be considered part of this amazing group of people! I was really looking forward to attending my first MVP Summit in Redmond in March, but sadly that wasn't to be. Maybe in a year or so I'll have the opportunity again.

Public speaking

I haven't really done that much public speaking this year. There's been the .NET Oxford intro talks, and I also did a couple of lightning talks. One of the JetBrains Rider IDE, and the other on the MediatR library. Details (inc videos) can be found on my public speaking page.

Home and Family life

From a non-tech point of view, nothing much has changed really. The boys are continuing to get bigger every time I turn around! Mason, my youngest, started school (reception year), and Jack's now in year two. My wife's work has luckily been extremely flexible over the lockdown period, and she was able to take the brunt of childcare duties whilst I worked during the day. The downside of being a contractor is that if you don't work, your company doesn't get paid!

Taking a moment to think about those less fortunate

I feel extremely lucky and privileged during this year that I have such an amazing family at home for company. If I think back to when I first moved down to Oxford and was living in a tiny house on my own, and imagine that it was then that the pandemic hit - things would have so different. But even then, whilst I would have been very lonely and isolated, I'd still have been in an industry where I most likely would have been in work. If you're in a similarly fortunate situation, it's important that we take a moment and really appreciate how lucky we are. I can't even imagine what this year has been like for those that have lost their jobs, can't afford to feed their families, are completely on their own, lost and depressed; or have lost loved ones. For a lot people in our industry, jumping on a Zoom call and using computers to communicate is effortless and makes the world a smaller place, whilst lessening the impact of the pandemic. Not everyone is computer literate, or wants to be. Most people need other people, and using a computer as a medium for that social interaction just isn't the same. This year has been pretty shit for so many people, and we can only hope that 2021 improves. Stay safe everyone.

Starting 'The Unhandled Exception' podcast

2020-11-01T00:00:00Z

I have some exciting news! As you may already know if you follow me on Twitter, I've recently started my very own podcast!!

TLDR; - If you're not interested in the whys or hows, and just want to listen, then head over to The Unhandled Exception Podcast website. This includes show notes, and also links to the major podcast apps, so you can listen using your favourite podcast app (and hopefully subscribe!).

If you're interested in reading more about not just why I've started it, but also my learning and experience so far, then read on...

Why start a podcast?

I've been an avid listener of podcasts for many years, and I've learnt a huge amount about various programming topics over time because of this. The great thing about podcasts, is that you can listen whilst doing other things - eg. your commute (pre-covid that is!); walks or runs; doing stuff around the house; mowing the lawn, etc. I find video content much more difficult to find time to consume.

The benefit to listening to podcasts for me also hasn't just been about learning either. Hearing the passion the hosts and guests have about both our industry and the wide range of technologies that we're lucky enough to have to play - is one of the reasons I've grown to become so passionate about software development myself, and got into blogging, started .NET Oxford, and public speaking, and now this podcast.

I love chatting with people about programming technologies, and have quite often found myself thinking, when at user-groups or conferences, that an indepth conversation I'm in with one or more people would have made an awesome podcast episode if only it had been recorded! Through .NET Oxford and going to conferences, I've met so many amazing people. I really enjoy the tech talks at these events, but quite often find that the conversations inbetween the talks, or afterward are just as valuable. These aren't a one-way "one-to-many" talks, and can quite often go in different directions. This is what I want to try and capture in this podcast.

The rest of this blog post will focus on my initial setup, what tools I'm using, and some of the things I've learnt so far...

Hosting

One of the first things I looked into was how to host the podcast. Being a developer, I can easily knock up a website and throw the mp3s onto something like Azure Storage. However, there are plenty of other things - eg. registering with all the major podcast services; generating stats; making sure the RSS feed is setup correctly, etc, etc. So I decided to go with one of the popular podcast hosting platforms, so all that stuff has been done for me, is tried and tested, so I can focus on the podcast.

After a bit of research, I chose BuzzSprout, which seemed to tick all the boxes, and was well spoken about in my research. I'm quite happy with this choice so far. It's been very easy, and was effortless to add my podcast to all the major providers.

Here's a screenshot of the management toolbar...

The Episodes tab is obviously where you manage all your episodes.

The Players tab gives you embeddable HTML that you can put on websites, etc. You can embed players for single episodes (like I do on the website, which I'll talk about shortly), or you can create players for multiple episodes.

The Website tab allows you to create a website. The preview for this looks pretty much what you'd expect. I decided to create my own site though. Not because there was anything wrong with the Buzzsprout generated site - but more because I had been looking for an excuse to play with Hugo and GitHub Actions! It also gives me more scope to expand and improve the site how I want over time.

The Directories tab gives you a list of the main podcast services (Apple Podcast, Spotify, Stitcher, etc), and allows you to click each to register. It was super-simple to register on each, and it just worked.

Monetization allows you to add sponsors. I haven't used this yet. Currently, the Podcast's current only sponsor is my own company, Everstack.

The Stats tab gives you charts and numbers about downloads...

The first bump you see there is the day I first announced the podcast on Twitter, and the second is when I mentioned it on LinkedIn.

You also get various other stats - breakdowns per episode, podcast app, locations, devices, etc.

Remote Interview platforms

With all that in place - how do we do remote interviews? I wanted to ensure that each persons' audio was recorded to a separate channel (the importance of which was confirmed when I was editing the first guest episode!). Also, it's better to have audio recorded on each persons' computer locally, rather than me recording everything on my end. You can do this manually and ask guests to record their audio themselves and send it to you. Or you can use a service to do this for you. Two popular ones are Squadcast and ZenCastR. They record each guest locally in high quality wav format, then automatically upload it to your account. Both have high praise when reading about them online. I went with Squadcast because they also support video during the call. Recording the video isn't support, but it's still nice to be able to see the other person during the interview. ZenCastR does have a video in beta, but when I went to try it, I had to go on a waiting list. This was my deciding factor, as I wanted to use it straight away, and Squadcast worked really well during my first guest episode with Derek Comartin! So I'm going to stick with this for the time being.

Microphones

At the start of lock down I invested in a Blue Yeti X microphone. This has served me really well, as I've been remotely pair programming all day, so it gets used all the time. It's also great when I'm in meetings, as I can walk around the room and my voice still gets picked up almost as if I was right next to it. However, I'm finding for podcasting, this is a big disadvantage. It literally picks up everything - from room echo, to my kids shouting upstairs.

My first couple of episode were recorded with the Blue Yeti, and whilst you couldn't call it an echo as such - there's definitely an 'in a box' kind of sound to it. I've heard of people doing all sorts of things to get around this - eg. putting pillows and blankets all over their walls, even recording under a duvet! Doing a bit of reading on this, it turns out that there are two types of microphones - condenser and dynamic. The Blue Yeti is a condenser mic, which due to the way it works, picks up everything (as I've found out). For dynamic mics, you want to be much closer to the microphone and it picks up a lot less background noise. I don't regret getting the Blue Yeti, as it's certainly had a lot of use over the past seven months, and it's probably a great mic for podcasting if you're in a treated quiet room with no background noise. But it's not really working for me and my home-office setup as far as podcast recordings are concerned. I wanted to try out a dynamic mic, and coincidentally I found a very old Behringer XM8500 budget mic in one of my cupboards (£15!). According to Amazon, I bought this in 2013. This would have been when I was playing the guitar a lot more and tried a bit of singing whilst playing (probably a good job I didn't continue with that!). Either way, this is a dynamic microphone (albeit quite a cheap one). It's XLR, meaning I also needed an audio interface or mixer - so last week I ordered a Focusrite Scarlett 2i2 audio interface, and did a few test recordings with the XM8500. And I found that there's a huge difference in lack of background noise compared to the Blue Yeti! Remember this is a £15 mic! Although, obviously there's the additional cost of the external audio interface, which the Blue Yeti doesn't require. Whilst the XM8500 sounds pretty good for a £15 mic - given I've now invested in the audio interface, I've decided to upgrade to the Rod Podcaster, which is also a dynamic mic, and should hopefully sound better than the XM8500. I'm looking forward to this arriving next week so that I can compare all three mics - the Rode, XM8500, and the Blue Yeti! Either way - the moral of the story is that if you're buying a mic for podcasting and you're not in a treated studio - do some research on dynamic vs condensor mics. It's too early for me to say I recommend a dynamic mic over a condenser mic - but from what I've experienced so far (and my various readings), it definitely feels that way.

Audio Editing

Another part of all this is the audio editing. This is actually something I'm quite enjoying. So far I've been using Audacity, which is a fantastic open-source cross-platform application. It's super-easy to modify multiple tracks, chop out bits, and move stuff around. I'm finding it amazing how easy it is to tidy up audio without being able to tell when listening back. Eg. removing erms, and ums, pauses, etc. Also because each speaker's audio is recorded to a separate channel, it's easy to clean up cross-talk where both speakers start to talk at the same time, and make it sound seamless. Once used to using Audacity, especially if you learn a few of the keyboard shortcuts - it becomes very efficient to do this editing.

I'm also currently trialing Adobe Audition to see which I prefer. I've quite often found that it would be useful to have some of Adobe's other apps - eg. Photoshop, Illustrator, etc. But couldn't really justify the ongoing subscription cost. However, having all of those, plus now having Adobe Audition for podcast editing - it's probably going to be enough to warrent the all-apps subscription.

The website

As mentioned above, I could have just used the automatically generated Buzzsprout website. But I decided to create my own to (a) give me greater flexibilty to grow and change it over time, but also (b) to have an excuse to play with the Hugo static site generator, and also GitHub Actions! The details of these are best saved for a different blog post, but I've been very impressed with both! Hugo makes it very easy to create these sites (The UEP website source code can be found here), and GitHub actions build/deploy time is insanely quick! I normally use Azure Pipelines, but GHA seems to deploy so much faster. But that might be a Hugo thing too.

The show notes will appear both on the website, and also in your podcast app. This will include all relevant links from each show.

I also plan on adding support for comments to the website fairly soon.

https://unhandledexceptionpodcast.com/

Guests

A huge part of podcasting is the guests. Whilst I'll do some episodes solo, I'll try to keep them short, as a big part of this is the conversational aspect - eg. it's not just someone doing a talk. I have a list in my notes of people I'd love to have on, including a couple I've asked already and have agreed to join me for an episode.

I was extremely lucky in that for my first guest episode, Derek was extremely helpful and supportive, and made it super-easy. That was the first time I've ever done something like that, and I quickly learnt an awful lot through doing it. Enough that I can hopefully at least sound like I know what I'm doing next time! So a huge thank you to Derek for being such an awesome first guest!

Looking forwards

I hope this post has been useful if you've been considering doing similar yourself. Or even if you've not, but are interested in my initial experiences.

This is early days yet, but I'm really enjoying this so far. Feedback has been positive so far too. I have some great guests in the pipeline which I'm really looking forward to recording episodes with.

The more popular this becomes, the more content I'll be able to create - so if you can help me out by sharing on social media, and rating the podcast in your favourite podcast app, that would be amazing!

Happy listening! :)

Standing desk: Part 1 - Initial thoughts

2020-10-04T00:00:00Z

As an industry, we spend far too much time sat down. A quick Google search will show plenty of research suggesting that this is very bad for you in many different ways. I've very recently invested in a standing desk, and thought I'd share what led up to me buying it, which one I chose, and also my initial experiences using it. This will be a 'part 1', with a follow up in about 6 months.

I work remotely, and a month or so ago I decided to start standing up during daily standups and meetings. I was strongly aware that I had a very sedentary lifestyle - sitting down ~8-9 hours, five days a week. In my current contract, we pair pair-program remotely pretty much all day - so as well as standing up in meetings, I also tried standing up when the other person was 'driving'.

When doing this, I immediately found myself listening more intently during standups and meetings, and generally getting less distracted. I also found myself walking around the room and stretching whilst listening. Standing up didn't mean I was just going from a stationary sit to just a stationary stand. When stood up, I found myself naturally moving around a lot more!

The problem was that my monitors were still at sitting height. So I was looking down a lot - which isn't good for your upper spine. I also had to sit when I was typing. This is when I decided I was going to invest in a standing desk...

My desk choice

The frame...

After a bit of research, and a few conversations on Twitter - I choose a Flexispot E7 desk. I knew I wanted a motorised desk that supported presets, so I could save my preferred heights. As a bonus, it also has a child-lock - which has turned out to be really useful, as my two kids think my new desk is a shiny new toy! Well, it is - but not their toy! ;)

It was a bit of a wait, taking just over a month to arrive once I ordered it. But once it arrived, it was very easy to assemble - I did it during my lunch break. I know someone who has ordered the same desk since, and theirs arrived much faster - so they must just have been out of stock when I ordered mine.

The desktop

The desktop is also from Flexispot, and I ordered it together with the frame...

This image is from their website (product page here). I got the black one. I find that that having this curved contoured edge makes a big difference. I guess this also applies to sitting down desks too - where using my old desk, I noticed my wrist resting against the square edge. Whereas with this desk, my wrist naturally rests and the contoured edge and feels much more comfortable.

Initial experience standing throughout the day

Short-lived back pains (largely due to an old back injury)

My desk arrived on a Wednesday, and I used it on the Thursday and Friday. Over the weekend, my back was really sore. Speaking to people on Twitter, it sounds like I probably did too much too quickly, as I pretty much did most of those days stood up straight away. I also have an old lower-back injury that reoccurs from time to time, and causes me issues for a couple of days, then goes back to normal. Those two initial days of standing did trigger my bad back - but, luckily it only lasted a few days, then I found I could go back to standing - taking it a bit easier this time. It's only a couple of weeks later that I'm writing this now, and I'm already finding I can stand for most of the day and it's no longer an issue.

Moving around much more

As mentioned earlier in this post, I'm finding that I'm not just standing still, but moving around much more than I would have been when sat down. When listening in a meeting, I walk around my office whilst listening. I find myself stretching out more too. Over the course of months and years - the accumulative effect of this must be massive.

Stepping back from the screen

Another thing I find myself doing, is stepping back from the screen much more. If I'm looking at code and thinking something through, but not typing - I'm finding that I naturally step back to ponder. Much further back than I'd be if I was sat down. So this isn't only good for your back, legs, cardiovascular system, etc - but also your eyes too!

Bonus: Much easier to clean underneath too!

When I removed my old desk - it was pretty disgusting behind it. Getting the hoover under the new standing desk is much easier, as I can just raise it to full height and walk under it! It goes surprisingly high!

Accessories

There are a few different accessories you can get as part of your move to standing. Below are the ones I went with...

Anti-fatigue mat

After speaking with people I know who have standing desks, and also asking on Twitter, I decided to get an anti-fatigue mat. The idea is that it's more cushioned and reduces pressure on your feet, legs, and back.

I must admit, that when I first got it, it didn't feel that much different to the carpet I have in my study anyway. However, using it more - I can definitely notice a difference. It just goes to show how a seemly small difference in floor, can make a big difference for prolonged periods of time!

I went with the Flexispot anti-fatigue mat.

Wobble board

Whilst researching the anti-fatigue mats, I also came across something called a wobble board...

(photo on left taken from Amazon - those are *not* my socks ;))

I ordered both the mat and the board at the same time, as I correctly suspected that being able to swap between different standing surfaces would make a difference when standing for long periods of time. When using this, I tend to have my feet much wider apart than in the image above, and do rocking motions. I'm naturally quite fidgety anyway - and this board seems to work quite well for that. When on the mat or floor, I walk around more and pace - and when on the board, I find myself slightly bending each leg and rocking to and fro. It also feels very good for my lower back and knees, and the rocking motion really engages your core.

Wobble stool

The final accessory I got was a wobble stool...

Quite often I find that I want a break from standing just for 5 minutes. I don't want to move the desk all the way down to the low seating position and drag my chair in. I just want a short break perching for a bit. This is where a standing stool comes in. It takes up a lot less space than a full-on chair, and it can be adjusted in height, so you're still effectively standing, but just taking the load off your back for a bit.

This works well, and because it not only rocks from side to side, but also can swivel vertically along the y-axis - you get a different type of movement. So even when perched, I'm finding I'm not as stationary as when sitting in a normal office chair.

Summary

I'm really pleased with this desk, and if I could go back in time, I wouldn't change any of my choices - this includes the frame, desktop, and the accessories.

As I mentioned at the start - this is a part 1 post, as I've only had the desk for a couple of weeks. I intend to write a follow-on post in about 6 months.

Coincidentally, a few days after getting the desk, I happened to be having a health check, and discovered that my blood pressure was very high. This surprised me, as I eat healthily, don't smoke, only drink infrequently in moderation, exercise, have hardly any body fat, and never really get stressed. I'm generally very happy in life, and feel very healthy. So really wasn't expecting to have high blood pressure. They do call it the silent killer for this reason though! The only thing I can associate this to is my very sedentary (up until now) lifestyle. I immediately ordered a blood pressure monitor so I can keep an eye on it. Hopefully my new standing desk will help improve things.

Hopefully this blog post has made you think about how much we as an industry spend sitting down. If you're in a position to upgrade to a standing desk, then I'd highly recommend it. If you're not though - then think about standing up in meetings. A lot of us are working from home at the moment, so even meetings are at our computers - we don't even get the walk from our desk to the meeting room.

If you already have a standing desk, I'd love to hear your experience with it. Feel free to comment below.

Happy standing!

Git: Dealing with unrelated changes whilst working on a feature branch

2020-09-27T00:00:00Z

How many times have you been working in a Git feature branch, and come across something in code that you want to change, but isn't related to the feature your on? Perhaps a code tidyup, or fixing some unrelated warnings?

What do you do?

The long way

You could do it the very long way and interrupt your workflow... Stash/commit all your current changes; switch to the main branch; make these unrelated changes; commit them; switch back to your feature branch; rebase your feature branch back onto the main branch; unstash your changes if you stashed them in step 1; try to remember what you were doing before all this started.

The messy history way

Or you could just include it in your feature branch, and leave it as that. The downside of this, is that this change is then part of your feature branch, not its own dedicated commit in your main branch.

A better way

A better option is to tidy up afterwards. This achieves the same as option 1, but doesn't interrupt your workflow at the time of doing the work...

Just commit the unrelated changes into your feature branch. Make sure they're in dedicated commits.
Carry on with your feature.
Once feature is complete - switch to the main branch, and cherry-pick any unrelated commits (ie. commits that shouldn't be part of your feature branch). At this point, those commits will be duplicated in both branches.
Rebase your feature branch onto the main branch. This will remove those duplicate commits from your feature branch.

This will leave you with a nice clean graph where your unrelated changes are on your main branch, and then your feature branch will branch off after those unrelated commits.

In step 4 - the rebase will remove those duplicate commits from your feature branch because a rebase is just a "replay" of commits. It's "replaying" your feature branch commits on top of the main branch commits. So when it tries to replay the duplicate commits, there are no changes to replay because those changes are already in the code - so those duplicate commits will get discarded.

If all commits have to go in a feature branch...

Your company's Git policy might be that all changes have to come from feature branches (perhaps you use PRs for everything). If this is the case, you can create your new unrelated feature branch in step 3 and do exactly the same against this branch rather than the main branch.

Summary

The reason behind this blog post is that for a long time, I've been doing the first option (ie. the long way). I'm fairly quick with Git, so it didn't take that long, but it was still more of an interruption to my workflow than I'd have liked. I very recently realised that it's much faster to tidy up afterwards with the cherry-pick and rebase technique I describe in this post. At that point, I no longer have my head in the feature I'm working on. And also if there are multiple unrelated changes/commits in the feature branch, then they'll all get tidied up in one go as part of the same cherry-pick/rebase commands.

If you're a Git user, but haven't got your head around rebasing - definitely spend time trying to understand it. It's not as complicated as it sounds, and once you get it, it's actually quite simple. And is one of the most powerful features of Git.

Comparing .NET Mocking Libraries

2020-09-20T00:00:00Z

There are quite a few different mocking libraries in .NET. Moq and NSubstitute seem to be by far the main ones I hear that developers use. I've used both of these in different projects, and really like them both. Whilst my preference leans towards NSubstitute, I'd be happy using either. Out of interest, I posted a Twitter poll to see what other people preferred, and the results and replies were really interesting!...

What's your favourite mocking library for .NET and why? (reply for 'other' - Twitter didn't allow enough poll options)
— Dan Clarke (@dracan) August 8, 2020

The winner of the poll is clear - but interestingly, a lot of the replies indicated that they used Moq just because it was the most well known / used, and they hadn't tried anything else. There was certainly a lot of love for NSubstitute in the replies, commenting that the API is much cleaner.

I thought it would be interesting to compare some of the leading libraries like for like. So I picked the top three in the poll - namely, Moq, NSubstitute, and FakeItEasy. And I'll go through some code snippets for some of the more common requirements of a mocking library. Note that I can't possibly cover every thing in this blog post, but I'll focus on the features I find myself mostly using.

But first, what does a mocking library actually do?...

What is a mocking library?

When writing a test, quite often you want to only test one particular class and method. But that method might call a dependency that calls into a database, or calls an external service. When writing an integration test, you may want to include those dependencies in your your test - perhaps using a real database span up in Docker, or an in-memory database. But what if you're only writing a unit-test (or the integration can't simulate a particular dependency)? How do you call the method you want to test, without it calling into the dependency and therefore making that database call?

Quite often in .NET codebases, you'll quite often see classes implement an interface - especially those which call into databases or make external API/service calls. For example, you might have a class called EFStockChecker which has Entity Framework code that talks to a database to check stock level. This contains implementation details - ie. it uses the Entity Framework library. This might then implement an interface called IStockChecker.

It is this interface that the rest of the codebase ideally should use - not the concrete type (implementation). The key point here is that the interface has no concept of Entity Framework, or whatever database technology we might be using. All it does is describe the intent. This is known as dependency inversion. When programming in this manor, your business logic isn't concerned with the implementation details of its dependencies. It also means that those dependences are really easy to replace with another implementation when testing.

Let's continue with the IStockChecker example...

interface IStockChecker
{
    bool IsProductInStock(string sku);
}

Nothing in the above interface indicates a database or database technology. It's just about the requirement, not how that requirement is fulfilled.

Then I might have some code in my business logic that does this...

public class OrderHandler
{
    private readonly IStockChecker _stockChecker;
    private readonly IOrderRepository _orderRepository;

    public OrderHandler(IStockChecker stockChecker, IOrderRepository orderRepository)
    {
        _stockChecker = stockChecker;
        _orderRepository = orderRepository;
    }

    public void ProcessOrder(string sku)
    {
        if (_stockChecker.IsProductInStock(sku))
        {
            _orderRepository.Create(...);
            ...
        }
    }
}

Because this code only knows about abstractions (ie. the interfaces), it's easy to run this code without using the production implementation of those interfaces. I could just create another implementations just for the test that implements those interfaces, but doesn't call the database. These test implementations are known as 'stubs'.

A mocking library allows you to simulate an interface or abstract type's implementation. You instantiate a 'mock' object of the interface, and tell that mock object what it should return if a method/property is called against that mock. You can also assert that a method/property was or wasn't called.

Some people prefer sticking to stubs over mocking libraries, but I personally prefer to avoid creating additional classes when a mocking library can do it for us. A mocking library also adds additional functionality, like as mentioned above - being able to assert/verify that a mocked method was called. You could obviously implement this yourself in your test implementation - but a mocking library can do this for you, so why reinvent the wheel?

The basic scenario we'll be using as an example

Let's start with a very simple scenario. Imagine we're testing the above-mentioned ProcessOrder method. Two interfaces are injected into the constructor. The implementation of both of them call out into a database or API (but we don't care about the data source or implementation), as we're not testing this. We only care about the logic in our ProcessOrder method. Eg. How does our ProcessOrder handle the having stock vs being out of stock.

Below is an example test to ensure that an order isn't created if there's not enough stock (using the Moq mocking library)...

[Fact]
public void GivenInsufficientStock_DoNotCreateOrder()
{
    // Arrange

    var mockStockChecker = new Mock<IStockChecker>();
    var mockOrderRepository = new Mock<IOrderRepository>();

    mockStockChecker.Setup(x => x.IsProductInStock()).Returns(false);

    var sut = new OrderHandler(mockStockChecker.Object, mockOrderRepository.Object);

    // Act

    sut.ProcessOrder();

    // Assert

    mockOrderRepository.Verify(x => x.CreateOrder(It.IsAny<int>()), Times.Never);
}

As you can see, the dependencies are mocked out. The real implementation would have called out to a database, but the class we're testing doesn't know or care about this - it just cares that whatever "IsProductInStock" is, we get a boolean back. It doesn't care where that comes from, as that's not it's responsibility. What is it's responsibility is that if IsProductInStock returns true, the class we're testing will execute ProcessOrder. And likewise, if it returns false, it does not execute ProcessOrder.

The above example shows how simple it is to tell the mock object to return false if IsProductInStock is called. This bit is just like a stub, but created for you by the mocking library.

You can also see how we can leverage the mock to verify that CreateOrder was or wasn't called. This bit is like a 'spy', but again, done for you by the mocking library.

(for a description of the different types of test-doubles - eg. dummies, fakes, stubs, spies, mocks - Martin Fowler has a post with a short description of each).

In fact, on the NSubstitute homepage, they even try to move away from these specific definitions, and state: "Mock, stub, fake, spy, test double? Strict or loose? Nah, just substitute for the type you need!".

Comparing Mocking library syntax

Okay, now we know what a mocking library does - let's move onto some syntax comparisons...

Mock creation and simple 'Returns' Setup with no parameters

Let's start with how we create a mock, then declare a return value for a method or property in a mocked object...

// Moq
var mockStockChecker = new Mock<IStockChecker>();
mockStockChecker.Setup(x => x.IsProductInStock()).Returns(true);
var sut = new TheClassIAmTesting(mockStockChecker.Object);
sut.DoSomething();

// NSubstitute
var mockStockChecker = Substitute.For<IStockChecker>();
mockStockChecker.IsProductInStock().Returns(true);
var sut = new TheClassIAmTesting(mockStockChecker);
sut.DoSomething();

// FakeItEasy
var mockStockChecker = A.Fake<IStockChecker>();
A.CallTo(() => mockStockChecker.IsProductInStock("")).Returns(true);
var sut = new TheClassIAmTesting(mockStockChecker);
sut.DoSomething();

NSubstitute certainly seems the cleanest here, not requiring .Object or a .Setup call and lambda. Note that Moq also has another syntax, where you don't need to use .Object to get at the mocked object, but if you do this - you have the inverse problem, where you have to do Mock.Get(myMock) to do any setup.

Moving forward, I'll omit the mock instantiation and the SUT call for brevity.

'Return' Setup with explicit parameters

What about if your method takes parameters? Eg, we know our IsProductInStock method does take a 'sku' parameter...

// Moq
mockStockChecker.Setup(x => x.IsProductInStock("banana")).Returns(false);

// NSubstitute
mockStockChecker.IsProductInStock("apple").Returns(true);

// FakeItEasy
A.CallTo(() => mockStockChecker.IsProductInStock("orange")).Returns(true);

This is very similar to the previous example - you just specify the parameter value when setting it up.

'Return' Setup regardless of parameter values

And what if your method takes a parameter, but you don't care what values are passed to it by the code you're testing?...

// Moq
mockStockChecker.Setup(x => x.IsProductInStock(It.IsAny<string>())).Returns(true);

// NSubstitute
mockStockChecker.IsProductInStock(Arg.Any<string>()).Returns(true);

// Or NSubstitute can also do this to specify that all arguments can be ignored
mockStockChecker.IsProductInStock(default).ReturnsForAnyArgs(true);

// FakeItEasy
A.CallTo(() => mockStockChecker.IsProductInStock(A<string>.Ignored))).Returns(true);

They all have similar syntax here. Moq uses It.IsAny<>() syntax, NSubstitute uses Arg.Any<>(), and FakeItEasy uses A<string>.Ignored. In NSubstitute, you can also use ReturnsForAnyArgs and the parameters will be ignored. In the above example, I've used the default keyword when doing this to make it more clear that these values are ignored - I could have put "", or any other value, but I think using default makes it more clear.

Throwing exceptions

Quite often you want to have tests testing how your code handles a dependency throwing an exception. Mocks allow you to simulate exceptions being thrown...

// Moq
mockStockChecker.Setup(x => x.IsProductInStockAsync("")).Throws(new NullReferenceException());

// NSubstitute
mockStockChecker.IsProductInStock("").Throws(new NullReferenceException());

// FakeItEasy
A.CallTo(() => mockStockChecker.IsProductInStock("").Throws(new NullReferenceException());

All of these are very similar to their Returns counterpart. Just replacing Returns with Throws.

Verifying a mocked method is or isn't called

Another really useful feature of mocking libraries is that you can spy on whether a mocked method was called or not. We saw an example of this in the GivenInsufficientStock_DoNotCreateOrder code snippet earlier in this post, where we verified that CreateOrder wasn't called when there was insufficient stock.

// Moq
mockOrderRepository.Verify(x => x.CreateOrder()); // Defaults to Times.AtLeastOnce
mockOrderRepository.Verify(x => x.CreateOrder(), Times.Never);
mockOrderRepository.Verify(x => x.CreateOrder(), Times.Once);
mockOrderRepository.Verify(x => x.CreateOrder(), Times.Exactly(2));
mockOrderRepository.Verify(x => x.CreateOrder(), Times.Exactly(3));

// NSubstitute
mockOrderRepository.Received().CreateOrder();
mockOrderRepository.DidNotReceive().CreateOrder();
mockOrderRepository.Received(1).CreateOrder();
mockOrderRepository.Received(2).CreateOrder();
mockOrderRepository.Received(3).CreateOrder();

// FakeItEasy
A.CallTo(() => mockOrderRepository.CreateOrder()).MustHaveHappened();
A.CallTo(() => mockOrderRepository.CreateOrder()).MustNotHaveHappened();
A.CallTo(() => mockOrderRepository.CreateOrder()).MustHaveHappenedOnceExactly();
A.CallTo(() => mockOrderRepository.CreateOrder()).MustHaveHappenedTwiceExactly();
A.CallTo(() => mockOrderRepository.CreateOrder()).MustHaveHappened(3, Times.Exactly);

I've included a few examples above showing how to check for different numbers of calls to a mocked method. This particular method I've verifying has no parameters, but all the libraries support verifying the a call was made with specific parameter values, or any parameter values.

Summary

I certainly haven't touched on all the functionalities that exist in mocking libraries - but rather focused on the features I tend to mostly use. There is plenty of other functionality - eg. working with events, verifying the order of method calls, etc, etc. If there are any comparisons or examples you feel really belong in this post, please do let me know.

The aim of this post isn't to say one library is better than another, as when it comes down to it, they all pretty much do the same thing. The purpose of this post is just to provide a side-by-side comparison of some of the syntax, to hopefully give the you a feel of what mock creation and setup looks like across these different libraries.

Multi-page login screens, hidden username fields, and LastPass!

2020-08-23T00:00:00Z

I've just recently had an issue where I'd created two accounts for the same website - one for myself and one for my wife. I quickly hit a very strange issue where if I logged into my wife's account, I would end up in my own account! I must admit, I initially jumped to thinking that the website must have some appallingly terrible authentication code. It turns out I was wrong, and it's something that might be quite common amongst multi-page login screens.

The website was 'Legal and General' life insurance. Yes, I'm at that age now where I have a family and finally realise that I'm not invincible like I used to think when I used to jump out of aeroplanes and ride around on fast motorbikes!

IMPORTANT: Given that I'm explicitly naming the company here - I want to point out that this IS NOT a security issue, as you'll see below. It's just a gotcha that could stop users from being able to log into their accounts. And it's one that is probably quite a common one amongst multi-page logins.

So first of all, I assumed our accounts were linked somehow and there was a bug in their login code (it was the same insurance broker who set up the policies, so it was reasonable to assume there was a link between the accounts). This wasn't the case after I found out the issue - but it was my first thought.

I also tried logging into my wife's account in an incognito window to rule out a browser storage or caching issue. This didn't fix it either - I still ended up in my account!

Interestingly, it worked fine from my mobile phone, or from a different browser, or different Chrome profile.

Then, I hit a big clue! The only browser extension I have enabled in incognito mode is LastPass. So I tried disabling this, and this fixed it!

Their login pages are as follows...

However, inspecting the HTML of the last page, shows that there's a hidden "username" textbox. Which makes sense, as you've already entered your username in a previous page - so the username you're seeing in the last screenshot is just an HTML label. However, an HTML FORM requires an input, not a label. Examining the FORM's HTML, here is a very simplified version of what it's doing...

<form>
  <input name="username" value="anna" type="text" style="display: none" />
  <input name="password" type="password" />
  <input type="submit" value="Log in" />
</form>

Note the username textbox is hidden! If I unhide it, I see this...

The text in that screenshot sort of gives away the problem! As you can see, LastPass has populated the hidden field with my username! And it's this field that gets submitted to the server for authentication, not the label showing Anna's username!

I should point out that the reason this actually logged me into my account, rather than just showing an invalid credential error - is because I was using the same password for both my account and Anna's. Albeit a VERY strong LastPass generated password. If they had been different passwords, then this would just have shown me an invalid password error because the username and password wouldn't have matched. Either way, this issue would cause a valid username/password combo to not let the user sign into their account.

Whose Bug is it anyway?

So is this a Legal and General's bug, or LastPass?

I'd argue that LastPass is at fault here. They shouldn't be auto-populating hidden fields. But given that they are - as web developers, it's worth knowing this little gotcha.

How can a website fix this?

The fix is simple - either don't use hidden fields in this way, or call them something different than username, so they don't get auto-populated.

Cleaner tests with XUnit's IAsyncLifetime and expression-bodied members

2020-08-01T00:00:00Z

When writing tests, sometimes it can be tempting to dump a bunch of asserts into the same test to avoid duplication across multiple tests...

public class MyTests
{
    [Fact]
    public void SomeTest()
    {
        var sut = new SystemUnderTest();

        var result = sut.DoSomething();

        result.StatusCode.Should().Be(Okay);
        result.Amount.Should().Be(123);
        result.UserName.Should().Be("Bob");
    }
}

This is a very simplistic example. Quite often you'd also have to inject mocks into the SystemUnderTest constructor, and do various other setup logic. You wouldn't want to duplicate that in each test, as your test class would quickly become huge, with lots of duplicate logic.

Fortunately, in XUnit, the constructor is called once per test, so you can put the setup logic there, and not duplicate it per test.

Note that other testing libraries have similar ways to run something once per test - eg. with nunit you can create a setup method. XUnit is my goto - so this post will focus on that.

To clarify, before I get swamped with comments - this blog post is not insisting that every test can only ever have a single assert. I think it's nice if they do - but in some scenarios is does make sense for a single test to have multiple asserts. Either way - this post is just showing a nice pattern I like to use when writing tests.

Expression-Bodied Methods for the tests

If you read my recent post about Writing More Succinct C#, you'll know that I'm a big fan of Expression Bodied Methods. If your tests are only doing a single assertion (because the 'arrange' and 'act' are in the setup) - then you can use them to make your tests quite succinct...

public class MyTests
{
    private readonly MyResult _result;

    MyTests()
    {
        var sut = new SystemUnderTest();
        _result = sut.DoSomething();
    }

    [Fact]
    public void StatusCodeShouldBeOkay() =>
        _result.StatusCode.Should().Be(Okay);

    [Fact]
    public void AmountShouldBe123() =>
        _result.Amount.Should().Be(123);

    [Fact]
    public void UserNameShouldBeBob() =>
        _result.UserName.Should().Be("Bob");
}

Whilst this is more code than the single test with multiple assertions - each test is still pretty succinct, and you get the benefit that each test is testing a single specific thing, so any test failures are very clear.

Async Setup using IAsyncLifetime

Quite often, our methods are async, and we can't make constructors async. This is where XUnit's IAsyncLifetime comes in. Making your test class implement IAsyncLifetime will force you to implement two methods: InitialiseAsync and DisposeAsync. So taking the above example, if sut.DoSomething() was actually sut.DoSomethingAsync() - then we could do this...

public class MyTests : IAsyncLifetime
{
    private MyResult _result;
    private SystemUnderTest _sut;

    MyTests()
    {
        _sut = new SystemUnderTest();
        // ...Other initialisation...
    }

    public async Task InitializeAsync() =>
        _result = await _sut.DoSomethingAsync();

    public Task DisposeAsync() => Task.CompletedTask;

    [Fact]
    public void StatusCodeShouldBeOkay() =>
        _result.StatusCode.Should().Be(Okay);

    [Fact]
    public void AmountShouldBe123() =>
        _result.Amount.Should().Be(123);

    [Fact]
    public void UserNameShouldBeBob() =>
        _result.UserName.Should().Be("Bob");
}

Summary

To give credit where credit's due - I discovered this pattern from a fellow contractor I'm currently working with - Lewis Henson.

Combining putting setup in constructor/InitializeAsync, and using expression-bodied-methods - really makes the tests nice and succinct, as you can see in the above examples.

This pattern is a nice way of organising your tests if you have a bunch of assertions based on a shared setup ('arrange' and 'act'). It doesn't apply in all circumstances - if you have a single 'arrange', 'act', 'assert' - then that could just go into the test itself. Or if you have a different setup for each, that's similar but not the same - you can either create a helper method that takes parameters to abstract out the duplication - or use parameterised tests.

Also for completeness - in case anyone's wondering and hasn't seen the Should syntax before - this uses an amazing library called Fluent Assertions. It makes writing asserts so much nicer. Definitely worth looking into if you've not seen it before! There's a lot of different extensions methods in this library which make various different types of assertion very clear and readable.

Finally, something I discovered recently from a blog post by Adam Storr - "C#8 Using Declarations With FluentAssertions"... If you do want to have multiple asserts in the same test, and you want a test failure to show all of the failing asserts in one go - then you can wrap them in Fluent Assertion's 'Assertion Scopes'...

using var scope = new AssertionScope();

result.StatusCode.Should().Be(Okay);
result.Amount.Should().Be(123);
result.UserName.Should().Be("Bob");

Happy Testing!

DevOps Tooling for Developers - we're so spoilt!

2020-07-05T00:00:00Z

Last week I had a catchup meeting with a client about the progress of a platform I'm building for them, and showed them how the "devops" side of things works. Demoing it really struck me how insanely awesome all the tooling we have nowadays is, and also how much I take it for granted!

I tweeted about it, but quickly realised as I was writing the multi-tweet Twitter thread, that a blog post would be a better fit for what I was trying to say. So here it is!...

First, let's start by defining what I mean by the "devops side of things". It initially started off with me showing some Terraform work I'd been doing to deploy the Azure infrastructure in a repeatable manner across environments (dev, UAT, prod). Because both this, and code changes, are triggered by Git pushes - the demo/conversation then evolved into me showing them the whole workflow...

Ie...

Briefly showing Git
How pushing to Git triggers Azure DevOps Pipelines
Deployment approval gateways, allowing acceptance at the click of a button of UAT->Prod staged deployment
Traceability - ie. hyperlinks from Azure Board work-items (which I use as a ticketing system and backlog), to Git commits, deployments, etc.
Terraform Infrastructure deployment
Azure Application Insights
Azure Dashboards

You don't have to be a big team

Before going into more detail about the above bullet-points, I want to point out that it's just me working on this client's project, and I only work for them 1 day each week. I'm a developer, and the main focus of my time is building the software, not the above-mentioned devopsy stuff. Luckily, you get a lot of the above mostly out of the box, and also at zero-cost for small teams! We're pretty spoilt as developers nowadays!

This isn't just about Microsoft stuff

I'm strongly aware that a lot of what I talk about in this post is Microsoft, and very Azure related. The reason for this is because I happen to use Azure DevOps for CI/CD and Azure for cloud hosting. The aim of this post isn't to market Microsoft products though, and all the technologies I mention have non-Microsoft alternatives - which I do also reference in places in this post. I talk about Terraform, which can just as easily deploy to AWS rather than Azure. There are other CI/CD solutions if you don't want to use Azure DevOps - eg. TeamCity, CircleCI, Jenkins, and others. There are other diagnostics solutions, which I also discuss below.

The point I'm trying to make in this post - is that it's struck me how amazing all this tech is that even one-man bands can leverage. And we have so much choice too!

Git -> Automated Builds and Deployment

It all starts at Git. Aim to keep everything in source-control. Obviously primarily this is your codebase, but should ideally also include your infrastructure and deployment setups. This means that you have the history of any changes you make to infrastructure and deployments in source-control alongside your code changes. For example, I mentioned I use Terraform - these files should be in source-control. Azure DevOps Pipelines supports YAML files, which should also be in source control. If you're using Docker, Kubernetes, etc - put the Dockerfiles, K8S YAML files, in source control. Try to avoid creating your infrastructure by clicking 'Create' in the Azure Portal (or whatever hosting platform you use), and assuming you'll remember how to recreate it in the future. You don't have to use Terraform, that's just my preference - you have ARM Templates if using Azure, Pulumi, or other options.

Then when pushing these changes, you can have automated processes take over the rest. You've probably heard the terms 'continuous integration' and 'continuous delivery'. This is what this refers to.

So pushing code changes, can kick off builds and deployments. Infrastructure file changes (in my case Terraform .tf files) can kick off infrastructure updates. Azure Pipelines YAML file changes, can update the deployment workflows (ie. how to build/deploy stuff automatically).

As you can see - Git really is the trigger point for things being built/deployed.

Traceability

I touched upon traceability in the bullet points list above. For this project, I use Azure Boards to manage work that needs doing. So all features, bugs, etc get a work-item (also known as a ticket in some platforms). I have a backlog of items and even though it's just me, and I'm only working for this client one day a week - I still use sprints, having one sprint per month (ie. 4-5 days). This allows me to plan a vague roadmap to the go-live date. The client has already seen how this works, can create work-items, and we use this for each of our progress catchup meetings.

In this recent meeting, given I was showing them the Git and CI/CD pipeline, I also then showed how work-items, Git commits, builds and deployments are all hyper-linked to each other. We're not using Pull Requests for this project, but if we were, the PRs would also be linked. This is so useful if you need to go back and either see why changes were made and what those changes affected, or what work has been done against a particular work item.

To automatically link a Git commit to a work item, just mention the work item in the commit message. Eg. "#123" in the commit description. Whilst I use Azure DevOps, most other similar solutions work the same way. Eg. GitHub, etc.

Monitoring

Monitoring is of course very important in your application. Work doesn't end when you hit the 'go-live' date and declare your app is "in production". Is your app erroring? Are web and database queries performing as expected? Are you just waiting for the end-user to tell you about issues, and assuming everything is hunky-dory if you don't hear anything? Ideally, you need dashboard, alerts, and logs in place. Dashboards to give you a general "at a glance" overview of the state of your system; alerts to notify you as soon as something goes wrong or isn't how it should be; and logs to help you drill down and diagnose problems when they arise.

Sounds complicated? Well yes it can be - but certainly not as complicated as you may think!

Application Insights

I'm calling out Application Insights because I use Azure and this is my go-to for website telemetry, and it's pretty mind blowing. However, the point of this blog post isn't about specific technology stacks, and me saying you should be using X, Y, and Z. There are plenty of other options - eg. DataDog, Retrace, Splunk, New Relic, RayGun and more. The point of this blog post is to highlight how spoilt we as developers really are with all this amazing tech.

But given I use App Insights, let's talk about that! With minimal work required, you get tons of logs, charts, error and diagnostic information out of the box.

This is an example from this blog's monitoring. You can see there's a bunch of 404s, which are just bots, but there's also some SQL failures. Clicking on the count (ie. 114 on the bottom-right) drills in and shows you various information about that failure - including the call stack in the code, SQL queries, etc...

Notice the "Related Items" on the bottom-right of that screenshot. Clicking on those options allows to you see more information about what was happening around the error.

You can easily write powerful queries against your logs, that both filter and drill down on your logs, or even render custom visualisations...

Notice the query panel in that screenshot with a SQL-like query? This is insanely powerful, and the intuitive intellisense make it even easier to write queries against your logs. You can dump out tables of trace log data, or render charts as in the above screenshot. These charts can easily be pinned to your dashboards (see below).

All of this pretty much out of the box. All you need to do after creating the App Insights service in Azure, is install a nuget or npm package into your app, and reference the instrumentation key for your App Insight instance. The rest is done for you.

Dashboards

I mentioned above, dashboards are a great way to give you a general overview of the state of your system. And you have quite a few options here. Obviously, using the built-in dashboarding solution will give you more flexibility, but will also mean you have to have different dashboards in different places. This might be okay though - it depends on your scenario.

Azure DevOps Dashboards

Azure DevOps supports creating custom dashboard for everything in your DevOps environment. For example, you can create dashboards containing your sprint burndowns and progress; status of builds and deployments; and more.

Azure Dashboards

Where you can use Azure DevOps Dashboards for DevOps information, you can also use Azure Dashboards for your Azure services information. This can give you at at a glance view of your cloud infrastructure. This includes information from your Application Insights (as mentioned above). Infact, most charts you see anywhere in the Azure Portal have a 'pin' icon to pin that chart to a dashboard!

Grafana

Grafana is an open-source dashboarding solution that can pull data from lots of different places. And Grafana dashboards look SO GOOD! Where the above-mentioned dashboards are very specific - with Grafana, you create 'data sources' which can pull data from various sources - eg. SQL Server, Postgres, Azure, Prometheus, time-series databases like InfluxDB, and much much more. Obviously depending on what you're dashboarding, you might not get the full power and flexibility of using native dashboards - eg. whilst you can dashboard data from Azure Monitor (including App Insights), you won't be able to drill into error information within Grafana. I tend to use a combination of both depending on what I'm doing. Because Grafana can pull from different data sources, you can create dashboards combining stuff from Azure, SQL, Prometheus instances, Google Analytics, DataDog, New Relic, etc and view it all in one place.

You can host Grafana in various ways. Spinning it up in Docker is one way. Which fits nicely if you're using Kubernetes. But even if you're not, you could put it on a VM or use Azure Container Instances, etc. They also have a hosted version, which has a free tier for basic usage.

I'm currently starting playing around with using Grafana to monitor personal stuff, like my todo list counts over time, home broadband usage, Strava stats, Google Analytics all in one place for various sites (eg. this blog, .NET Oxford and Azure Oxford websites), etc, etc.

Pricing

You'd have thought all this would be really expensive wouldn't you? Well, for a small team like I am, other than the Azure hosting itself, it costs nothing. You didn't mishear that - it doesn't cost me anything at all! You start to pay when you have a team of over 5 people (and still the first 5 remain free), and/or you need extra build agents, more space for packages, or the Test Plan functionality.

Oh, and automating your infrastructure deployment with ARM, Terraform, Pulumi, etc. - means you can destroy your dev/UAT environments automatically overnight and at weekends, then have them automatically spin up before everyone starts work. This can save you a ton on Azure hosting fees.

Summary

Imagine showing all this stuff to a developer from 10 years ago! I was finding I was taking this stuff completely for granted. Then when I had the meeting I discussed earlier where I was demoing it - it really stuck me - this is insane! Sure, there might be a lot to learn, but most of it isn't project-specific, and you can leverage this stuff for any of your projects. Then after that initial learning curve - you'll then be able to setup a 'devops' pipeline/process in less than an hour. Especially when you have all configuration as code - copy a few Azure DevOps YAML files, a few Terraform .tf files, etc - and away you go!

Pair Programming

2020-06-20T00:00:00Z

I've recently started a new contract where we do 100% pair-programming. This is the first time I've done pair-programming on anywhere near this level. In the past, I've only ever paired on an ad-hock basis either to help someone else solve an issue, or vice-versa. This is an 8-hour per day contract, where other than meetings, we're pairing for all of those 8 hours. Sounds full-on? Well, actually so far, it seems to be working pretty well! Obviously, it makes a huge difference who you're working with, and I've been lucky that I seem to be getting on well with both developers that I've paired with, and we seem to think in the same way and haven't hit any conflicts so far!

It's worth pointing out that this is a 100% remote team, regardless of the current COVID situation. I'll compare this with the limited experiences I've had pairing 'in-person' later in the post. I'll also discuss some tooling that we use.

I'm going to start by talking about the benefits, which I'm finding, far outweigh the cons...

Knowledge Share and Bus-Factor mitigation

I've worked with a lot of companies during my career, but I've never worked for one where there hasn't been large areas of code solely known by just one developer. This is obviously bad if/when that developer leaves, either making their code a no-go zone, or causing a lot of lost time whilst other developers have to pick up the code with no context of reasons some decisions were made.

When work is done in pairs, there's always more than one person who understands each area of code.

Discussions around everything bring better solutions

Pair programming takes rubber-duck debugging to the next level! Rubber-duck debugging is where a developer explains the problem to someone else (even if it is just to a rubber duck!), and the mere act of articulating the problem helped them realise the issue. With pair-programming, everything is articulated! Not just bugs and issues, but all code decisions.

As part of these discussions, architecture will most certainly come into it. All developers have different backgrounds and ideas, and the discussions around different possible solutions can create much better, more thought-through architectures - saving a lot of time in the future.

Two eyes are better than one

Two eyes (brains) looking at code being written are far more likely to spot mistakes and potential bugs, than a single developer just typing away. I'm seeing many changes a day being made due to one of us picking up something that the other didn't spot or think about.

Much faster onboarding of new developers

Being a new member of the team, it's really been apparent to me just how much faster pair programming has helped me pick up both the architecture and codebase. Anything I'm unsure about, I can just ask as part of the conversation we're already in anyway. I'm not interrupting anyone to ask questions as we're pairing together anyway. And it's so important to ask questions. Always remember, questions create far deeper understanding. Never ever be afraid to ask questions!

If new developers are just given tasks and left to it - there's a high chance that it might not conform to the standard design patterns that the team tends to adopt. Unless the codebase really enforces the chosen design patterns, then an codebase that isn't brand new, is quite likely to be a bit of a mess with various different ways of doing things. This is something that pair-programming can help mitigate against. A new developer can be introduced to the patterns and practices that the team has adopted whilst pair programming. Even if you decide that pair-programming long-term isn't a good fit for your team - it's definitely worth doing initially with new starters.

Pairing Remotely

I mentioned at the start of this post that I'm now working with a 100% remote team. So all the pairing I'm doing is obviously also 100% remote. Has this been an issue? To be honest, I've actually found it easier than pairing in person. Whilst in past companies, I've only paired ad-hocly, so perhaps not the same as an official in-person pairing setup - it has always involved one of the pair not being at their own computer. I don't know about you, but my setup is quite customised. From the hardware where I'm used to my own keyboard/mouse, to software - I use Vi; have various tools and utilities I jump to improve my productivity; my hotkeys are setup how I like them, etc, etc. If I'm using someone else's machine - it's a very unproductive experience. Remotely, each developer is using their own machine, and is free to lookup related stuff on the internet, navigate the code separately if they need to, etc.

Microsoft Teams

We use Teams for communication, where we primarily use it just for calls rather than text. We take turns "driving" and sharing our screens, which seems to work quite well when pairing.

I mentioned in a recent blog post about working from home about the importance of having decent audio. Near the start of the lockdown, I invested in a decent microphone (Blue Yeti X), and am so glad I did! I made the investment because I knew I would be working remotely for some time, and would be hosting .NET Oxford virtually for some time too. I'm also planning to start a podcast, so this was the ideal opportunity to invest in decent hardware. However, I didn't realise at the time, I would be literally talking all day long through it for pair programming. When working remotely, audio quality makes a huge different - so is definitely worth the investment.

VS Live Share

If you're a Visual Studio or VSCode user, then Visual Studio Live Share is definitely worth looking into. My primary IDE is Rider, which sadly doesn't support it - it would certainly be nice if the protocol became an open standard that could work across other IDEs!

For those that don't know what Live Share is - it allows one person to host a session, which others can join. You can then all edit the same code, and you can see what the other person is doing. Think of Google Docs collaboration, but in your editor when coding.

(image taken from Microsoft's website)

You can even toggle whether you're 'following' another user, which will automatically navigate your view as they move around the codebase.

Whilst this is amazing tech, there are downsides. My biggest problem is that as the participant (ie. not the host), you lose a lot of the IDE functionally. Especially if you use Resharper. I find that intellisense no longer works, and navigation shortcuts stop working, etc. Another issue is that you lose some context of what the other person is doing - you can't see their intellisense or popup dialogs. So for example, if the other person has a dialogbox up to rename something, and is thinking about what to rename it to - the participant can't see that dialog. Also, if the other person switches to another application - eg. OneNote, SSMS, LINQpad, etc, you obviously can't see that either.

I do find it useful to have vscode with live-share in a secondary monitor though - so I can see the screenshare in my main monitor, giving me full context of what the other person is doing, whilst still being able to edit code in vscode via live-share.

I think the biggest benefit I get from Live Share rather than screenshare, is that I can scroll around the modified code independently of the driver. When pairing, we tend to take turns driving and being the main person coding. Obviously the person driving, is scrolling up and down and moving around the codebase. This makes it hard to follow along, if I'm trying to read the code. I quite often want to be able to scroll around independently. Whilst I can navigate already pushed code locally on my machine anyway - I obviously can't see modified code that the other person hasn't yet pushed. But through Live Share, I can.

Another advantage to LiveShare over screenshare, is that you can choose font-sizes, etc. Sometimes I find screenshare can be a little bit blurry - especially when our screen aspect-ratios aren't identical. Looking at the code in VSCode via LiveShare much clearer.

Stand up!

Another nice advantage of pair programming is you can standup when the other person is 'driving'. Of course, if you have a standing desk, you can do this anyway! If you don't though - it's worth standing up for a bit when you're not using the keyboard. Stretch out a bit too whilst you're stood up. It's amazing how much of a difference standup up for a bit can make. Do this in meetings too where you're mainly listening rather than typing. I find when listening in morning standups, if I stand up, I find myself listening far more intently and getting distracted less.

The negatives of pair programming

I've talked a lot about the positives of pair programming so far, so here are a few negatives...

Loss of 'The Zone'

When solo-programming, I have my headphones on with music, and really get into the zone and find I can focus quite deeply. When pairing, I'm never really getting into this state. That's not as bad as it sounds, as it's been replaced by a state of discussion which has plenty of other benefits as described above - but I do miss having periods of time where I can code to music and get into a state of deep work.

Not all pairs gets on with each other

I've been quite fortunate in this new contract. Both developers I've paired with so far have not only been really good developers, but also great to get on with too. It certainly hasn't felt like a long day pairing for 8-hours solid with them. However, if you were forced to pair all day with someone you didn't get on with - after all, some personalities do clash - I can see that not ended well at all. Managers, please bear this in mind when deciding who should work with who!

But doesn't this cost twice as much in resources?

When first explaining pair-programming to someone, the usual reaction/question is "but doesn't this cost twice as much in resources?". Hopefully after reading this post, the clear answer is 'no'. The quality improvement you get from all the things I've discussed; plus mitigating against someone leaving without anyone else knowing their area of code; plus the team bonding, and additional consistency of design patterns you get in the codebase - more than outweigh the cost of two devs working together on work items.

Summary

A couple of years ago, I wrote a blog post about using Pull Requests in the workplace (link). I wrote that post because I had recently started working with a team that used PRs, and this was the first time I'd worked for a company that did this. I'd used PRs for open-source, but not in the workplace itself. It feels like pair-programming takes the benefits I describe in that post to the next level!

I'm enjoying pairing in this new role, and feel I've learnt the architecture, codebase, and the team's 'ways of doing things' much faster than I otherwise would have done. Plus, I feel I've gotten to know the team much better than if I'd been working solo on tasks from a backlog (remember, this is a 100% remote team).

One thing I would say, is that I'd recommend having at least half-an-hour a day soloing. This allows you to be free to browse the code-base and digest other areas of code.

I'd love to hear your experiences!

Do you have experience in pairing? Has it been positive or negative? I'd love to hear your thoughts and experiences on this, so please do comment below, or feel free to reach out to me directly.

Writing More Succinct C#

2020-05-10T00:00:00Z

When looking at a lot of C# code nowadays, I find myself thinking "wow, that code could be made SO MUCH SMALLER!". C# is a very flexible language, allowing you to write clean and functional code, but also very bloated code.

There are a lot of things in the C# language that can help writing more succinct code - some older (like LINQ), and some which have been added in newer versions of C#. In this blog post, I'll talk through some of them. But let's start with a side-by-side example to add a bit of context to what I mean by smaller code...

Both of the above two methods do the same thing. This is obviously a fabricated example to make a point, but I do see code like this all the time in real codebases. Look at the right-hand version, and imagine getting this kind of compression, not just in one method, but across your entire codebase. It's also much more readable. If you don't find the right-hand version more readable, then I suspect you're new to LINQ, and I'd highly recommend learning it if you're a .NET developer. It's not new, it has been around since .NET 3.5 (release in 2007), and it is genuinely one of the main reasons I love .NET so much!

This example covers some of the topics I'll discuss in this blog post - eg. LINQ, ternary-if, and expression body members. But I'll also highlight some other nice ways you can make code more compact - especially if you're using C#8!

Now that we've looked at an example that adds a bit of context to what this blog post is striving for, let's dig in...

Embrace LINQ!

LINQ is AMAZING! It really is one of the main reasons I love .NET so much! It's been around since .NET 3.5, and the amount of code and complexity that it removes is incredible. The screenshot at the top of this blog post is probably one of the simplest examples of LINQ there is - and yet, look how much code it saved!

It's easy to add conditional predicates; sort order; and much more in minimal lines of codes.

myList
    .Where(x => x.SomeProperty > 10)
    .OrderBy(x => x.SomeOtherProperty)
    .ToList();

You can even easily do GroupBy and manage aggregate queries.

I'm not going to delve into LINQ here, as that's out of the scope of this blog post - however, if you're using .NET, and not comfortable with LINQ, then definitely spend a bit of time getting good at it. It'll make a massive difference to your code.

One caveat is that LINQ might not be a good fit in performance-critical code, as it can cause more allocations. So be mindful of where you use it. If you're writing performance-critical code that gets run a lot (eg. in a loop), it's worth using something like Benchmark.NET to measure the performance of that code and know where you allocations are regardless of whether you're using LINQ or not.

Expression body members (C#7)

I'm a big fan of expression body members, which allows you to do this...

int GetSomething() => 123;

instead of this...

int GetSomething()
{
    return 123;
}

Note that we've not only removed the braces, but also the return keyword. This is because this is an expression, rather than a statement. A statement is a command - ie. "return me a value", where an expression is just something that evaluates to a value. It might be a single value as it is in the above example, or it could be an algorithm, or it could be the results of a LINQ expression...

IEnumerable<OrderItem> GetOrderItems(int orderId) =>
    _orderRepository.GetOrderItems()
        .Where(x => x.OrderId == orderId)
        .ToList();

Notice the lack of braces and return keyword? Notice how compact and succinct it is, but still very readable.

I find myself trying to turn as many methods as possible into expression-body members. And thanks to the other things I mention in this post, it's surprising by how many methods end up being condensed down to a single expression that can be turned into an expression-body member.

Ternary if (?:)

Ternary if, also known as an inline-if, allows you to say "if something ? then do this : else do this".

For example, this..

string foo;

if (bar != null)
{
    foo = bar
}
else
{
    foo = "default"
}

...can be made much smaller with the ternary if...

var foo = bar != null ? bar : "default";

(and this can be made even small, see next section)

Null coalescing operator (??)

The above shortened example, can be made even smaller still with the null coalescing operator...

var foo = bar ?? "default";

This says if bar is not null, then use it, otherwise continue evaluating to the right of the ?? operator.

Null-coalescing assignment operator (??=) (C#8)

If you're using C#8, then there's also the ??= operator, which will only evaluate and assign the right-hand value, if the value on the left is null.

So this...

if (_myValue == null)
{
    _myValue = InitialiseMyValue();
}

...can be shortened to this...

_myValue ??= InitialiseMyValue();

If _myValue isn't null, then it'll be left alone, and InitialiseMyValue() won't even be called. This is really useful for initialisation.

Null conditional operator (?.) (C#6)

This is a nice bit of shorthand added into C#6, meaning that you can change this...

if (a != null && a.b != null && a.b.c != null)
{
    a.b.c.DoSomething();
}

...into this...

a?.b?.c?.DoSomething();

It basically says if the code to the left of the ?. is null, then stop evaluating anything to the right. So in the example above, if either a, b, or c is null, then it won't do anything, and won't call DoSomething(). If you were assigning the above statement to a variable, and either a, b, or c was null - then the null will be assigned to that variable.

C#8 switch expression

Another C#8 one here. I've pinched the below example from the documentation...

var orientation = direction switch
{
    Directions.Up    => Orientation.North,
    Directions.Right => Orientation.East,
    Directions.Down  => Orientation.South,
    Directions.Left  => Orientation.West,
};

This is a lot cleaner than the typical switch statement we're used to. And when you start adding the power of pattern matching into the mix, it gets even better!

Removing Braces from single-line blocks???

First of all, this one is obviously highly controversial! I'm not saying you should be omitting braces, and there are a lot of people who would find it a cardinal sin. But more and more recently, especially as I look into other languages that don't require braces - I'm finding them more and more redundant. I mean, we all indent our code don't we? If not, why not? So why do we need braces at all? Well, for single-line statements - you don't.

Omitting the braces in single-line if statements, foreach, where, using, etc. can make code much more compact. Take this example...

When you get used to this, it's amazing how stretched out the code on the left looks. It's really started to make me dislike the concept of braces at all in C#.

This is now where a lot of C# devs will now be screaming at their monitors, saying things like "But what about the Apple bug?!", or "But what if a Python dev who's used to not having braces, comes in and does this..."

if (something)
    doSomething();
    doSomethingElse(); // New method call added by Python dev

If you do this, your IDE/Editor is going to SCREAM at you. Unless of course, you're coding in notepad. Also, most editor's default setup is to autoformat on ; or } - so this'll be very quickly auto-indented. Obviously, you'll get the rare exception where someone has disabled all this functionality, or someone's using an editor that doesn't lint - but in the most case nowadays, you'd have to program blindfolded to get caught by this.

Re. the Apple bug, I struggle with the fact that one person wrote a bug a long time ago - and from now on, everyone has to pad out their code like shown in the screenshot above. If we had to change the way we write code every time someone writes a bug - we wouldn't be allowed to touch the keyboard.

Many years ago, I was a C/C++ developer, where it was good practice to always wrap single-line blocks in braces. There was good reason for this though. C/C++ has a concept called macros. When macros are used in code, it might look like a single-line if statement, however, when expanded out by the preprocessor, it might actually be a multiline if statement. So it can be dangerous if you don't wrap all your blocks in braces. This isn't the case in C# though.

Whilst I prefer omitting braces and find them redundant (after all, we indent our code anyway, so why do we need braces?!) - I have recently found a genuine reason why this perhaps isn't a good idea. In fact, I found it whilst writing this blog post...

(source)

The two comments at the bottom of that screenshot pretty much echoed my thoughts. Most other arguments against this felt like the issue was sloppy indentation, not an issue with omitting the braces. However, the above example isn't lazy programming, because it looks like it's indented correctly.

Even so, as I mentioned above - your IDE/editor is most likely going to bark at you and probably even fix the indentation for you automatically.

So yes, this makes a big difference in code size, but you have to be careful not to introduce the above-mentioned bug. So this section isn't advice on either way - it's just my thoughts on the pros and cons. As you can see from the screenshot at the start of this section, it does make quite a difference - just be careful if you decide to do this. Using some of the other techniques in this blog post can help eliminated if-else blocks altogether anyway.

Also, remember that switch case blocks do not require braces even for multi-line blocks.

Remove unnecessary local variables

Another one I see a lot is code like this..

There are a lot of unnecessary local variables here. We can already see what each method-call is doing from the method names, and the next method-calls are then just members of the previous method. These can be nicely chained together instead of introducing local variables...

It's much cleaner - especially when you get used to using fluent syntax. And as a bonus, we were then able to turn it into an expression-body-method, removing the braces and the return keyword!

Although do bear in mind that neither of these examples have error checking, and rely on exceptions being caught by calling methods. It might be that you need to store a local variable to do error checking, or to write log entries. So I'm certainly not saying to always avoid local variables - just do it intentionally, rather than blindly assigning every single method call to a local variable. The above is just an example to make a point.

Use var

Spot the duplication...

Dictionary<int, string> myVariable = new Dictionary<int, string>();

Isn't this much better?...

var myVariable = new Dictionary<int, string>();

Remember that var is still statically typed. There's no difference in what the two lines above get compiled down to.

The only argument against using var I've heard is that it's less clear. However, I've used it everywhere for years, and have never once wished I'd been more clear and used an explicit type. It's pretty much always clear from the context, and if not, just hover your mouse over it to find out what type it is.

Moving towards Functional Programming

It's clear that as the C# language evolves, we're moving more and more into a functional style of programming. LINQ was added in .NET 3.5 - and the later versions of C# are adding more and more ways to help us write code in a more functional manner, as you can see from the examples above. As we start to think in this style of programming, it becomes easier to adopt other parts of functional programming. For example, pure functions. A pure function is a function that for each input (ie. function arguments), it'll always have the same return value. A pure function itself with have no side-effects, and not change state outside of the function (eg. no database or API calls, no changing external properties, etc). With smaller, more compact expression-body methods, this becomes easier. And also easier to write tests against.

Debugging

One downside to more compact and functional code, is that it can sometimes be harder to debug. There's less code to put breakpoints against, and you can't add watches to variables that you don't have because you've avoided local variables. However, I'd much rather have a nice compact readable codebase throughout the entire codebase, and very occasionally have to add a temporarily variable assignment whilst I debug something. This is much more favourable than the entire codebase being massively bloated. Besides, modern debuggers do help, allowing you to debug into LINQ expressions and lambdas anyway.

You'll probably also find that you have less reason to debug, as a more functional codebase is likely to have fewer bugs and is easier to reason about. More pure functions also means that it's easier to run your code via a test instead, or just copy that method into a REPL where you can run it standalone.

Summary

I've given a lot of different examples in this blog post of how to make your code much more succinct and compact, whilst still being very readable (in some cases, gaining far more readability!). It's when these techniques get combined, not just in one method, but across your entire codebase, that you really start to see big differences. Everywhere I look at the moment, I'm seeing C# code that could be made so much smaller than it is. Hopefully after reading this blog post, you join me in quest to vanquish bloated C# from your codebases!

There's an interesting slideshow by Scott Wlaschion about a made-up language called C# Light, where he discusses some of the bloat in the C# language. As he warns in the initial slides, it's only for those of you who are open-minded! I certainly ended the slides thinking that we were just left with F# - which isn't a bad thing! Learning F# is what made me start to notice how bloated C# was in the first place!

The First Virtual .NET Oxford meetup

2020-04-27T00:00:00Z

This week we had our very first attempt at a virtual .NET Oxford event! And it seemed to go pretty well! We were joined by Mark Rendle to talk all about Roslyn! We also had a 10-minute lightning talk by Megan who works at our sponsor company, Corriculo Recruitment talking about the state of the the job market due to COVID-19.

So I thought I'd write this blog post to talk about it, as well as the decisions made and the reasons behind those decisions.

One of the key things that was very important to me, was that it felt like a physical meetup, and not a one-way stream, or everyone individually watching a YouTube video. For me, the whole point of a user-group is the social interaction with like-minded people. Also, getting to meet and chat the speaker in person (even if it is via a video-conferencing medium).

So because of this, here are a few decisions I made...

Not live-streaming to YouTube

A few user-groups I've seen have used Zoom and set it up to live-stream to YouTube. I can understand the appeal of this, potentially opening it up to more people. However, for me, if someone wants to attend the event, I want them to attend and actually be there. Joining via Zoom feels much more like people are attending rather than invisibly watching in secret via YouTube.

It was recorded anyway, and I edited it and published it to YouTube. So anyone that couldn't make it live in Zoom, will still be able to watch the content.

Another issue I see with live streams to YouTube, is you get all the chat at the start before the meetup officially begins. Because I edited the recording, I was able to get rid of everything but the main talks, add transitions, etc. I even considered overlaying the messages from the group chat window onto the video at the times they were made - but didn't get the time to do that.

Nagging everyone to turn on webcams

I also tried to persuade everyone to turn on their webcams - both in my group emails about the event, and also the intro-talk. And I was very impressed with the number of people that did! In a physical meetup, everyone can see everyone else - no-one is invisible. The speaker can engage with their audience. And the audience engage with the speaker, and get involved. Whilst the audience can still get involved via typing in the chat window or via audio - it's much better with both webcams and mics turned on, feeling far more 'in person'.

And the speaker even tweeted afterwards saying how much of a difference this made...

For @dotnetoxford most of the attendees turned their webcams on and it was so much better being able to see people's faces while I was talking!
— Mark Rendle \n (@markrendle) April 21, 2020

Zoom as the platform of choice

There were a few platforms I could have gone with - Zoom, Microsoft Teams, Twitch, etc.

I haven't used Twitch, but from what I gather, it's more for one-way live streaming. The audience can participate via a chat window - but not to the extend that I wanted with webcams and gallery views. If I've got this wrong, please let me know!

Another option was Microsoft Teams. I really like Teams within a work environment. It also has something new called Teams Live Events, and you can find a good video from James Montemagno demoing this. So Teams would have been my second choice. I haven't played with the Teams Live yet - and I'm not sure whether you get the same level of audience participation as with Zoom, or if it's more like Twitch - it's certainly on my list of things to look more into!

I've seen Teams used for bigger events like the MVP Summit, which very quickly switched from a physical event to an online event due to COVID-19. This didn't use the Teams Live functionality, and definitely felt very collaborative, and it was really impressive the speed that Microsoft turned everything around and made this big event virtual. I did see lots of MVPs having issues getting access though - which is something I was concerned about - I didn't want to have to do IT support trying to work out why people couldn't access the meetup. I believe Teams Live shouldn't have this issue as you can view anonymously. So basically, this might work well, but I need to do more investigations and play around with it.

I'd already used Zoom for meetings, and knew it would work well. There's also functionally in there that I wanted to try out that Teams doesn't have - for example, Breakout Rooms (see below).

Note that I wrote the above before we had had the meetup. And after having the event, I can say that Zoom worked perfectly! We'll probably stick with Zoom for the near future, as we have no reason to change. To move to something else, would be changing platform for the sake of changing.

Also, whilst the default max attendee limit is 100, our sponsors, Corriculo Recruitment are paying for a Pro licence with an additional guests add-on, allowing up to 500 participants.

The only small issue I had with Zoom is the inability to 'react' to group messages. Ie. like, thumbsup, etc. This would be a really useful addition.

Recording

There were a few options for recording - Zoom local recording, Zoom cloud recording, or streaming to another platform like YouTube. As mentioned above, I didn't want to live stream, but I assume I could have streamed privately to YouTube. I ended up just going with the Zoom cloud recording, hoping that it didn't go over the 1GB limit. The final video ended up being 1.7GB, but luckily Zoom didn't stop recording, or even stop me from downloading it. I just got an email saying that I'd exceeded my limit. Next time, I might look into streaming privately to YouTube.

After the event, I then downloaded the mp4 from Zoom, and edited it in Camtasia. I removed the chat before the event started, but decided to keep the chat during the break and afterwards, as there was some really good conversation in there!

Camtasia also has a nice feature when publishing to YouTube to automatically generate a table of contents based on markers. So whilst the same video includes my intro talk, Mark's talk, Megan's lightning talk, and the chat during the break and after the event - there's a nice clickable table of contents in the YouTube description to jump to each section.

Prize Draw app

When .NET Oxford first started over 3 years ago, I wrote a WPF prize-draw app which connected to the Meetup.com API to pull down RSVPs to draw from. I've recently added Zoom integration to this (see my blog post with details). Given that my integration involves writing webhook events to Azure Table Storage - I thought after the event, that it might be interesting to dump out a chart of the number of people in the meeting throughout the course of the event. So I wrote a small bit of code in LINQPad to generate a chart...

On the night, the prize-draw app worked perfectly. Although, I need to add a black-list, as a couple of staff from our sponsors were drawn, so we had to redraw! As I write this, another meetup (.NET South West) will be trialling my prize draw app tonight using the Zoom integration. Looking forward to seeing how it goes at another user-group!

Breakout Rooms

During the break, we trialled using Zoom's Breakout rooms functionality. This allows the host to create X number of rooms, and have Zoom automatically divide everyone into those rooms. Joining is optional for the participant - they can stay in the main room if they choose (or go back and forth between the main room and their breakout room). This is great because in a room of 100+ people, there'll probably only be a handful of people getting involved in the conversation. Having smaller rooms of 5-10 people more simulates a physical event where everyone "breaks out" into smaller groups to mingle.

We got good feedback about this - however interestingly, I created a Zoom poll at the end to see what everyone wanted to do for the "virtual pub" afterwards...

So out of the 13 people who said they were staying, only 2 wanted to use breakout rooms. Bear in mind that at the time, no-one knew that only 13 people were hanging around, so breakout rooms probably wouldn't have made sense anyway. But this poll might have looked very different if it had been asked about the break, rather than the after-event chat. I think I might send out a Survey Monkey poll asking for feedback on both this, and the event in general.

Zoom Invite Link and Meetup.com

One final point to mention for those that are doing similar, is once the event starts, attendees can no longer RSVP on Meetup. Which means that they won't be able to see the Meetup online Zoom invite URL! We experienced this first-hand with none other than the speaker himself! Oops! I hadn't twigged that he might not have RSVPed, and wouldn't have the invite link. Luckily, in the chat beforehand, someone pointed out that he had asked on Twitter for it - so I quickly DMed him the invite link. So it's worth making sure that even with all the other things you have to think about when kicking off your very first virtual meetup - ensure the speaker knows the address of the venue!

Summary

So, in summary - it worked really well! Everyone seemed to have a great time, and we got really good feedback! We even got feedback from a couple of people who live abroad, saying that they hope we keep up a virtual presence in some form after the lock-down ends, so they can continue participating!

Dan Clarke

The Many Use Cases of AI Coding Agents

Writing Code

The Agentic Loop

Calling CLI Tools You Already Have

Debugging and Investigating Issues

Throwaway Scripts

Custom Skills and Commands

Tickets, PRs, and Collaboration Tools

Standard disclaimer!

Personal projects

Wrapping Up

Developers are System Thinkers, not Code Monkeys

Year in Review: 2025

Website re-write

Podcast

Newsletter

Everstack

Dometrain

YouTube

.NET Oxford

Personal life

New Years Resolutions

Source-controlling Config files in Git (dotfiles?)

Why?

Confidence in not losing my setting

My changes are intentional and deliberate

Increased motivation to tweak

Transferable between machines

Github issues!

How does it work?

What are 'dotfiles'?

Who should mark PR comments as resolved?

Redefining the term '10x Developer'

Raising Awareness of Aphantasia

Do you have Aphantasia?

How do I imagine things then?

Is this a disability?

Hyperphantasia

Other senses

I'd love to hear your experiences!

Useful Links and Resources

Year in Review: 2021

The Unhandled Exception Podcast

.NET Oxford

Everstack

Family life

Snapshot Testing with Verify

What is snapshot testing?

Diff-tool integration

How much time does this save the developer?

Guids and Timestamps

DiffEngineTray Tool

Playing with Playwright

Recording

A swath of extensions!

Summary

Year in Review: 2020

Azure Oxford on hold for the time being

.NET Oxford goes virtual

Starting my own podcast!

Sad news: Sharp Life Science becomes a victim of the pandemic

New Contract

Remote working

MVP renewed!

Public speaking

Home and Family life

Taking a moment to think about those less fortunate

Starting 'The Unhandled Exception' podcast

Why start a podcast?

Hosting

Remote Interview platforms

Microphones

Audio Editing

The website

Guests

Looking forwards

Standing desk: Part 1 - Initial thoughts

My desk choice

The frame...