Forem: Simon Foster

AI Won't Replace Developers, But It Will Redefine Us

Simon Foster — Sat, 14 Mar 2026 09:00:00 +0000

Introduction – The Shift We are Living Through

As I write this, I have just been made redundant. AI is not being used to explain this particular redundancy, but it is being used to explain many redundancies across the industry.

I just got laid off..... Again...... I am still in shock. I loved my new job and was creating great impact but here we are again. Layoffs are not personal so I am ok but yeh will be looking for something new...... Again......

— Debbie O'Brien (@debs_obrien) February 27, 2026

I listened to an excellent talk at NDC Londonby Debbie O’Brien about using AI to do amazing things with Playwright MCP. If people who are using AI to its fullest are losing their jobs to AI, what hope is there for our industry? Are we all going to be writing AI prompts and that’s it?

But let’s stop for a minute. Software development is an ever-changing industry. There is always something new to learn and this AI craze is no different.

The role of the developer has always shifted as tools improved. We moved from writing assembly to high-level languages, from manual deployments to automated pipelines, and from managing servers to deploying infrastructure with a few commands.

The real question is how our role is changing and how we need to adapt and make the most of the new tools available to us.

What’s Actually Changed?

There’s a lot of noise around AI in software development. Headlines swing between “AI will replace developers” and “AI is just autocomplete.” The truth, as usual, sits somewhere in the middle.

But something real has changed. Not just the tools we use, but the speed, shape, and workflow of software development.

From Reactive to Proactive

For years, developer productivity tools focused on helping us type faster.

We had IntelliSense, snippets, code generation tools, and IDE refactorings. These were useful, but they were fundamentally reactive. They waited for the developer to start typing and then offered suggestions.

AI coding tools have crossed a different threshold.

Instead of simply completing the next line, they can:

Generate entire classes or modules
Suggest architecture patterns
Write tests
Perform multi-file refactors
Explain unfamiliar codebases
Propose fixes for bugs

The important shift is this:

The tool is no longer just responding to the code — it’s responding to the intent.

You describe a goal, and the AI attempts to produce the implementation.

This moves AI from being an autocomplete engine to something closer to an execution partner.

It’s not autonomous in the sense of replacing developers, but it does change the relationship between the developer and the code.

We’re no longer writing every line ourselves. Increasingly, we are directing the creation of code rather than manually constructing it.

The Cost of a First Draft Has Collapsed

Historically, one of the hidden costs of software development was simply getting started.

Creating a prototype involved:

Setting up project structure
Writing boilerplate
Defining models
Creating basic tests
Wiring components together

None of this work was intellectually difficult, but it took time.

AI tools have dramatically reduced the cost of that first draft.

You can now describe a feature and quickly get:

A rough implementation
Basic unit tests
A starting architecture
A prototype that actually runs

This doesn’t mean the output is perfect. In fact, it often isn’t. But the barrier to experimentation has dropped significantly.

Ideas that might have taken half a day to prototype can now be explored in minutes.

And that has a subtle but powerful effect on development culture:

When experimentation becomes cheap, developers try more ideas.

This encourages iteration, exploration, and rapid feedback in ways that previously required more discipline and effort.

Writing Code Is No Longer the Bottleneck

One of the most surprising outcomes of AI coding tools is that they reveal something many experienced developers already suspected:

Typing code was never the hardest part of software development.

The real difficulty lies elsewhere:

Understanding the problem
Designing a clean solution
Managing complexity
Communicating intent to other developers
Maintaining systems over time

AI can produce large volumes of code very quickly. But that doesn’t automatically translate into good software.

If anything, it shifts the constraint.

The bottleneck is no longer how fast code can be written.

The bottleneck is now:

How clearly can problems be defined
How well can systems be designed
How effectively can code be reviewed and maintained

In other words, AI accelerates the mechanical part of development, but the thinking part becomes even more important.

What Hasn’t Changed (But People Think It Has)

With every major technological shift, there’s a temptation to assume everything is different now. AI has amplified that feeling in software development. When tools can generate large amounts of code in seconds, it’s easy to believe the fundamentals of the profession have been rewritten.

But when you look closely at real software projects, something interesting appears: many of the hardest parts of software development haven’t changed at all.

AI has accelerated the mechanics of coding, but the underlying challenges of building reliable, useful software are still very much human problems.

Understanding Requirements Is Still the Hardest Problem

Software projects rarely fail because developers can’t write code. They fail because the problem wasn’t clearly understood in the first place.

AI tools can generate implementations, but they rely entirely on the input they’re given. If the requirement is vague, incomplete, or contradictory, the output will reflect that.

Consider how requirements often arrive in real projects:

A stakeholder describes a problem in business language.
Important edge cases are discovered later.
Different teams have slightly different expectations.
Requirements evolve as users interact with the system.

None of this has changed with AI.

The ability to ask the right questions, clarify ambiguity, and translate business needs into technical solutions remains one of the most valuable skills a developer can have.

In fact, as code generation becomes easier, clear problem definition becomes even more important.

Architecture and Trade-Offs Still Matter

AI can suggest design patterns, propose architectures, and generate project structures. But good software architecture isn’t just about picking the right pattern.

It’s about making trade-offs.

Questions like these still require human judgment:

Should this be a microservice or part of the monolith?
Is the added complexity of caching worth the performance gain?
What level of abstraction will make this system maintainable in five years?
Where should the boundaries between components sit?

These decisions depend heavily on context:

Team size
Deployment environment
Operational constraints
Long-term maintenance costs

AI can offer suggestions, but it cannot fully understand the organisational and operational realities of the system it’s helping to build.

That responsibility still sits with the developer.

Accountability Doesn’t Disappear

One thing that definitely hasn’t changed is ownership.

When software breaks in production, nobody blames the IDE. The same principle applies to AI.

If an AI-generated query deletes the wrong data, or a generated implementation introduces a subtle performance issue, the responsibility still lies with the developer who reviewed and shipped the code.

Production systems still require:

Careful testing
Monitoring and observability
Security awareness
Performance tuning
Ongoing maintenance

AI can assist with many of these areas, but it doesn’t remove the need for human accountability.

At the end of the day, someone has to understand the system well enough to take responsibility for it.

And that hasn’t changed at all.

The New Developer Skill Stack

If we accept that AI has collapsed the cost of a first draft, then the skill stack shifts upward.

Not because the old skills are irrelevant, but because they’re no longer the limiting factor as often.

Syntax still matters. Fundamentals still matter. But the competitive advantage moves towards the parts of the job that are hard to automate: precision, judgment, and system-level thinking.

Think of it as an evolution of the same craft.

Prompting as a Technical Skill

“Prompting” sounds fluffy until you realise what it actually is in practice: specifying a problem clearly enough that another agent (human or machine) can make progress without guessing.

The better you are at being precise, the more useful the tool becomes.

That means getting specific about:

The goal (what “done” looks like)
The constraints (performance, security, backward compatibility, tech stack)
Inputs/outputs and edge cases
The environment (language version, framework, database, deployment model)
The trade-offs you care about (simplicity vs flexibility, latency vs cost)

If you ask an AI to “build a feature”, you’ll get a lot of code, but it will almost always bake in assumptions you didn’t mean to make.

The best results come when you treat it like a junior developer with infinite typing speed:

Ask it to propose an approach first
Get it to list assumptions and risks
Then implement one slice at a time (and keep the changes small)

Finally, iterative refinement becomes the workflow.

You rarely get the best output on the first prompt. But you can converge quickly if you review the result, point out what is wrong or missing, and re-run with tighter guidance.

In other words, prompting is less about “magic words” and more about feedback loops.

Code Review Becomes Critical Thinking

When AI can generate 200 lines of code in seconds, reviewing becomes the high-leverage skill.

That review can’t just be “does it compile” or “does it look idiomatic”. It has to be critical thinking.

AI-generated code often fails in ways that are subtle:

It handles the happy path beautifully and ignores weird real-world inputs
It silently changes behaviour (especially around dates, nulls, and defaults)
It introduces concurrency bugs that only show up under load
It uses a library/API incorrectly but convincingly
It passes tests that are too shallow to be meaningful

The most important thing to review is not the code itself, but the assumptions underneath it.

I find it useful to explicitly ask:

What does this code assume about the data?
What does it assume about ordering, timing, and retries?
What happens when dependencies fail?
What would I see in logs/metrics if this breaks in production?
What tests would convince me this is correct?

This is where experienced developers become even more valuable: not because they can type faster, but because they’ve seen how systems fail.

Systems Thinking > Syntax Knowledge

AI is good at syntax and local patterns. It is much worse at understanding the bigger picture.

The developers who thrive in this shift will be the ones who can hold the system in their head:

How data flows through the application
Where the boundaries are between components
What needs to be observable in production (logs, metrics, traces)
What makes the codebase maintainable for the next person

Systems thinking is what stops an AI-generated “solution” from becoming a future incident.

It’s also why the old advice from The Pragmatic Programmermatters even more now: remember the big picture.

Not “can we generate this function”, but:

Is this the simplest thing that could work?
Can we operate it at 2am?
Can we change it safely in six months?
Are we making the system easier to understand or harder?

AI accelerates output, but it doesn’t automatically improve outcomes, and that creates real risk if we aren’t careful.

The Risk: Shallow Engineers

The biggest danger is not that AI replaces us.

The biggest danger is that it makes us lazy.

If we outsource too much thinking to tools, we can accidentally create a generation of engineers who can ship quickly but cannot explain what they shipped, why it works, or how to fix it when it fails.

That risk shows up in subtle ways:

Copying generated code without understanding the trade-offs
Accepting tests because they are green, even when they don’t test anything meaningful
Mistaking confidence in the AI’s tone for correctness in the implementation
Losing touch with fundamentals like debugging, data structures, networking, and performance

This is especially dangerous under delivery pressure. If a team rewards speed above all else, AI can amplify the wrong behaviour: lots of output, little understanding.

And that debt compounds.

Six months later, nobody trusts the codebase, incidents increase, and every change becomes risky.

So yes, AI can make us faster. But if we use it without discipline, it can also make us shallow.

The antidote is simple, even if not always easy: use AI to accelerate execution, not to bypass understanding.

The Opportunity: Increased Leverage (For the Right People)

The upside is huge for developers who combine AI with strong engineering habits.

When you can generate a solid first draft in minutes, you can spend more time where value actually lives:

Better problem framing
Better architecture decisions
Better test strategy
Better operational design
Better developer experience for your team

This is where leverage appears.

One thoughtful developer with AI support can now do the kind of end-to-end work that used to require more hand-offs and more waiting.

Not because they became magically smarter overnight, but because the mechanical drag has been reduced.

If your fundamentals are strong, AI multiplies your impact.

If your fundamentals are weak, AI multiplies your mistakes.

That is the real divide.

Practical Advice for Developers

If you want to stay relevant and thrive in this shift, here is what I would do right now.

1. Treat AI Output as a Draft, Not Truth

Assume every generated answer is a proposal.

Read it. Challenge it. Test it.

Never merge code you cannot explain to another developer.

2. Strengthen Your Core Engineering Muscles

Double down on:

Debugging
Testing strategy
System design
Observability
Performance and security fundamentals

These are durable skills and AI makes them more valuable, not less.

3. Get Better at Problem Framing

Before asking AI to implement anything, write down:

The problem in one sentence
The constraints
The non-goals
The acceptance criteria

This habit improves both the AI output and your own clarity.

4. Work in Small, Reviewable Slices

Ask AI for smaller changes, not giant rewrites.

Small slices make it easier to reason about behaviour, review quality, and rollback safely.

5. Raise the Bar for Code Reviews

Review assumptions, failure modes, and operational impact, not just style.

A useful question in every review: “What breaks first in production?”

6. Build a Personal AI Workflow

Create repeatable prompt patterns for tasks you do often:

Writing tests
Refactoring legacy code
Generating migration scripts
Creating docs from code

Treat these as reusable tools in your engineering toolbox.

7. Keep Shipping Real Things

The best learning still comes from production reality.

Build, deploy, monitor, and improve. Feedback from real users teaches lessons no model can replace.

What This Means for Juniors vs Seniors

AI changes the game for everyone, but not in exactly the same way.

For junior developers, AI can be a force multiplier for learning if used correctly.

It can explain unfamiliar concepts, generate examples, and speed up experimentation. But juniors still need mentorship and deliberate practice to build judgment.

If you skip the fundamentals and rely only on generated output, you’ll progress fast on paper and slowly in reality.

For senior developers, the expectation shifts from individual output to system-level impact.

Seniors become the multipliers of multipliers: setting standards, designing guardrails, mentoring teams, and ensuring AI usage improves quality rather than eroding it.

In short:

Juniors should use AI to learn faster
Seniors should use AI to scale better decisions

Both groups win when curiosity stays high and ego stays low.

The Big Question: Are We Becoming Directors Instead of Builders?

Partly, yes, and that is not a bad thing.

More of our time is moving toward direction:

Defining intent
Making trade-offs
Reviewing outputs
Orchestrating systems

But we are still builders.

Good directors in software are grounded in reality. They understand implementation details, constraints, and failure modes. They can still get into the code when needed.

So the role is not “director instead of builder.” It is “builder with broader leverage.”

We are not giving up craftsmanship.

We are applying craftsmanship at a higher level of abstraction.

But let’s be honest about the uncomfortable part of this question.

If one developer with AI can now do the work that previously required three, the natural business response is to hire fewer developers. That is already happening. It is likely to continue.

The optimistic framing — that AI creates more software demand and therefore more developer jobs — is plausible in the long run. But it does not help the developer who is looking for work today, and it does not guarantee the transition is smooth or fair.

I am not going to pretend the economics are simple.

What I do believe is that developers who understand systems, take ownership of quality, and use AI as a serious tool will remain competitive for the work that does exist. That work will increasingly require judgment, not just output.

The shift is real. The disruption is real. But the craft is not going away — it is just raising its entry bar.

Conclusion – My Opinion

I do not believe AI will eliminate software developers.

I do believe it will split the field.

Developers who keep learning, think in systems, and take ownership of outcomes will become more effective — not despite AI, but partly because of it.

Developers who treat AI as a shortcut, blindly trusting its output without understanding the system underneath, will increasingly struggle to hold ground.

The disruption happening right now is real. But I think the long-term demand for engineers who can reason clearly, design well, and take responsibility for what they ship is going to hold.

The path forward is straightforward even if the road is uncertain: stay curious, deepen the fundamentals, use AI seriously, and never stop questioning the output.

Call to Action

As mentioned at the start of this article, I am a .NET developer looking for my next role. If you know of any opportunities where I could help, please reach out.

And if you are in the same position, message me as well. We are stronger when we support each other.

Azure Container Registry vs AWS Elastic Container Registry: A Developer's Comparison

Simon Foster — Mon, 23 Feb 2026 20:00:00 +0000

As someone who works with both Azure and AWS regularly, I’ve had hands-on experience with both Azure Container Registry (ACR) and AWS Elastic Container Registry (ECR). Recently, while migrating my blog’s deployment pipeline to use ECR, I encountered some interesting differences that are worth sharing.

The Basics

Both services provide secure, private Docker container registries that integrate seamlessly with their respective cloud ecosystems. They’re designed to store, manage, and deploy container images for your applications.

Azure Container Registry (ACR)

Fully managed Docker registry service
Integrated with Azure Kubernetes Service (AKS), Azure Container Instances, and other Azure services
Supports Docker images and OCI artifacts
Available in multiple tiers: Basic, Standard, Premium

AWS Elastic Container Registry (ECR)

Fully managed Docker container registry
Integrated with Amazon ECS, EKS, and AWS Lambda
Supports Docker images and OCI artifacts
Single pricing model with pay-as-you-go

OCI artifacts are container-related objects that follow the Open Container Initiative (OCI) specifications. Originally, OCI defined standards for Docker container images, but now it covers a broader range of artifacts—including Helm charts, software bill of materials (SBOMs), and other files—stored in container registries.

Pricing Comparison

This is where things get interesting.

Azure Container Registry

ACR uses a tiered pricing model :

Basic : £4.23/month + storage (£0.083/GB) + bandwidth
Standard : £16.93/month + storage (£0.083/GB) + bandwidth
Premium : £42.32/month + storage (£0.083/GB) + bandwidth + geo-replication

The Premium tier adds features like:

Geo-replication across Azure regions
Content trust for image signing
Private link with private endpoints
Enhanced throughput

AWS Elastic Container Registry

ECR uses simple pay-as-you-go pricing :

Storage : $0.10/GB per month (£0.08/GB)
Data Transfer : Standard AWS data transfer pricing
No base fee - you only pay for what you use

Authentication & Setup

This is where I hit some friction with ECR.

Azure Container Registry

ACR authentication is straightforward:

# Login using Azure CLI
az acr login --name myregistry

# Or use service principal
docker login myregistry.azurecr.io -u $SP_ID -p $SP_PASSWORD

# In pipelines, it's seamless with Azure DevOps tasks

The Azure DevOps integration is particularly smooth - the Docker@2 task handles authentication automatically when using service connections.

AWS Elastic Container Registry

ECR authentication requires an extra step:

# Get login password and pipe to docker login
aws ecr get-login-password --region eu-north-1 | \
 docker login --username AWS --password-stdin \
 111111111111.dkr.ecr.eu-north-1.amazonaws.com

In my Azure Pipelines, I had to:

Install AWS CLI (not included by default)
Configure AWS credentials as environment variables
Run the login command manually

- task: CmdLine@2
 displayName: "Install AWS CLI"
 inputs:
 script: |
 curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
 unzip -q awscliv2.zip
 ./aws/install --bin-dir ~/.local/bin --install-dir ~/.local/aws-cli

- task: CmdLine@2
 displayName: "Login to ECR"
 env:
 AWS_ACCESS_KEY_ID: $(AWS_ACCESS_KEY_ID)
 AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY)
 inputs:
 script: |
 export PATH=$HOME/.local/bin:$PATH
 aws ecr get-login-password --region eu-north-1 | \
 docker login --username AWS --password-stdin \
 111111111111.dkr.ecr.eu-north-1.amazonaws.com

Winner : ACR (simpler authentication, especially in Azure DevOps)

Image Naming & URLs

Azure Container Registry

Clean, predictable naming:

myregistry.azurecr.io/myapp:v1.0.0
myregistry.azurecr.io/namespace/myapp:latest

AWS Elastic Container Registry

Includes your AWS account ID:

111111111111.dkr.ecr.eu-north-1.amazonaws.com/funkysi1701/blog:10.1.1.123-develop

The account ID in the URL may pose a security consideration - it’s visible to anyone who has access to your images or deployment configs. Attackers could use the account ID for targeted phishing, social engineering, or brute-force attacks. If combined with leaked credentials or misconfigured permissions, it makes it easier for someone to identify and target your AWS resources.

Winner : ACR (cleaner URLs)

Features Comparison

Feature	ACR	ECR
Image Scanning	✅ Premium tier	✅ Included
Vulnerability Scanning	✅ Premium tier	✅ Basic + Enhanced
Geo-Replication	✅ Premium tier	❌ Manual setup
Webhooks	✅ All tiers	✅ Included
Image Retention Policies	✅ All tiers	✅ Lifecycle policies
Private Endpoints	✅ Premium tier	✅ VPC endpoints
Image Signing	✅ Content Trust	✅ AWS Signer
Cross-Region Replication	✅ Premium	❌ Requires manual setup
Import from Docker Hub	✅ Built-in	❌ Manual

Integration with Kubernetes

ACR + AKS

Seamless integration with Azure Kubernetes Service:

# Attach ACR to AKS cluster
az aks update --name myaks --resource-group mygroup --attach-acr myregistry

AKS nodes can pull images without credentials. Magical.

ECR + EKS

Also integrated, but requires IAM roles:

# Attach IAM policy to EKS node role
aws iam attach-role-policy \
 --role-name eksNodeRole \
 --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly

Works well once configured, but requires understanding of AWS IAM.

Winner : Tie (both integrate well with their respective K8s offerings)

Developer Experience

What I Like About ACR

Simple authentication in Azure DevOps
Clean, readable image URLs
Excellent documentation
Azure Portal UI is intuitive
Helm chart support is first-class

What I Like About ECR

No minimum cost - truly pay-per-use
Built-in vulnerability scanning at all levels
AWS CLI is powerful and ubiquitous
Great for multi-cloud strategies
Excellent API and automation support

Pain Points

ACR :

Premium tier gets expensive for features that should be standard
Minimum £4/month even for tiny projects
Geo-replication requires Premium tier (£42/month)

Geo-replication is important because it allows your container images and artifacts to be stored and accessed in multiple geographic regions.

ECR :

Authentication is more complex outside AWS
Account ID in image URL
Requires AWS CLI installation in non-AWS CI/CD

My Real-World Experience

For my blog’s deployment pipeline, I recently migrated from ACR to ECR primarily for cost reasons. Here’s what I learned:

The Migration

Before (ACR):

Cost: ~£4.50/month (Basic tier + minimal storage)
Authentication: Seamless in Azure DevOps
Image URLs: Clean and simple

After (ECR):

Cost: £0/month (due to free trial)
Authentication: Required custom pipeline steps
Image URLs: Include AWS account ID

Was It Worth It?

For my small personal project, yes - saving money is meaningful. But the setup was more complex than I expected.

For enterprise workloads, I’d still choose ACR Premium if I needed:

Geo-replication
Content trust
Azure-native integration
Enterprise support

Recommendations

Choose ACR if

✅ You’re heavily invested in Azure ecosystem

✅ You need geo-replication

✅ You want seamless AKS integration

✅ You value simplified authentication

✅ You need Azure-native compliance features

Choose ECR if

✅ You want zero minimum costs

✅ You’re on AWS or multi-cloud

✅ You need built-in vulnerability scanning

✅ You prefer pay-per-use pricing

✅ You’re comfortable with IAM and AWS CLI

Conclusion

Both ACR and ECR are excellent services. Your choice should depend on:

Your cloud platform - Use the registry that matches your deployment target
Your budget - ECR wins for small projects, ACR Premium for enterprise features
Your team’s expertise - Stick with what your team knows
Your requirements - Need geo-replication? ACR Premium. Need low-cost? ECR.

For my personal projects, I’m happy with ECR’s cost savings. For enterprise work, I still recommend ACR Premium for its advanced features and Azure integration.

What’s your experience with container registries? Let me know in the comments!

Resources

NDC London 2026

Simon Foster — Mon, 02 Feb 2026 20:46:00 +0000

For the second year running, I had the privilege of volunteering at NDC London – one of Europe’s premier software development conferences. This year’s event was packed with insights on AI, accessibility, testing automation, and the future of software development. If you’re interested in my first experience, check out my 2025 report.

The volunteer experience was just as rewarding as last year – the team was fantastic, the energy was incredible, and the sense of community was palpable. In this post, I’ll focus on the talks I attended and the key insights I gained from them.

As I mentioned last year, volunteering gave me a superpower : increased confidence to network with speakers, vendors, fellow volunteers, and attendees. The connections you make at conferences like this are invaluable, and being part of the team made it even easier to engage with the community.

Wednesday

Let’s Break Some WCAG Rules (Speaker: Elise Kristiansen)

This eye-opening talk examined how pervasively websites violate Web Content Accessibility Guidelines (WCAG). For those unfamiliar, WCAG provides a framework to make web content accessible to everyone, including people with disabilities. The guidelines are organized into three conformance levels:

Level A - The bare minimum requirements
Level AA - The legal requirement (what most laws mandate)
Level AAA - The gold standard, aspirational but not legally required

The statistics Elise shared were sobering: 15-25% of people have some form of disability (whether permanent, temporary, or situational), yet a staggering 94.8% of websites contain at least one WCAG AA violation – meaning they’re actually breaking the law.

One of the most powerful demonstrations was a colour blindness test where only colour blind individuals could read certain numbers. It really drove home how design choices can inadvertently exclude significant portions of our users.

Key Takeaways:

WCAG compliance isn’t optional – it’s a legal requirement and moral imperative
Stop using <div> for everything; HTML is semantically rich for a reason
Consider learning to use a screen reader to understand user experiences better
Accessibility benefits everyone, not just those with disabilities

Social Engineering: Hacking Humans (Speaker: Pawel Sucholbiak)

A timely reminder that as soon as humans enter the equation, social engineering becomes a significant security risk. This talk explored various tactics malicious actors use to manipulate people into divulging confidential information or performing actions that compromise security.

Pawel demonstrated real-world scenarios like phishing emails that appear to come from trusted colleagues, pretexting phone calls where attackers impersonate IT support, and how seemingly innocent information shared on social media can be weaponized. The human element remains the weakest link in any security chain.

Supercharged Testing: AI-Powered Workflows with Playwright + MCP (Speaker: Debbie O’Brien)

I’d heard Debbie discuss the Playwright MCP (Model Context Protocol) on .NET Rocks, but seeing it demonstrated live was transformative. This session showed how AI can dramatically enhance testing workflows by understanding test intent and generating Playwright test code.

I’ve already started using it to write some tests for this very website!

Key Takeaway:

Experiment with the Playwright MCP – it’s a game-changer for test automation

The Undersea Cable Network (Speaker: Richard Campbell)

Richard took us on a fascinating journey through the history of undersea telecommunications cables – the literal backbone of the internet. He explored how these cables are laid, maintained, and the significant challenges when they’re damaged (whether accidental or deliberate). It’s humbling to realize that our globally connected world depends on physical cables crossing ocean floors.

Java Sucks (So C# Didn’t Have To) (Speaker: Adele Carpenter)

An entertaining and insightful exploration of Java’s history, examining how its early popularity locked in certain design decisions that became problematic over time. Adele showed how C# learned from Java’s mistakes and made different choices that enabled better evolution. The key lesson: early success can create technical debt that’s nearly impossible to pay down.

View the slides

Think Like a User: Practical UX Design Tips for Developers (Speaker: Lex Lofthouse)

This session challenged developers to shift perspectives and consider user experience from the ground up. Lex provided practical, actionable advice for creating more intuitive interfaces.

View the slides

Recommended Reading:

The Design of Everyday Things by Don Norman

Thursday

OpenTelemetry At Scale 101: Intro to OpAMP (Speakers: Aakansha Priya and Adriana Villela)

This session introduced OpAMP (Open Agent Management Protocol) for managing OpenTelemetry collectors at scale. While the scale discussed was beyond my current needs, it was valuable to understand the challenges and solutions for production observability in large distributed systems.

A Defence of Technical Excellence (Speaker: Chris Simon)

Chris made a compelling argument for maintaining high technical standards even under pressure to deliver quickly. Technical excellence isn’t about perfectionism – it’s about sustainable, maintainable code that serves the business long-term.

How to Git Away with Murder (Speaker: Sergès Goma)

A humorous yet practical look at Git workflows and how to recover from common (and not-so-common) Git disasters. The Q&A session at the end turned into a group therapy session where attendees shared their most spectacular Git mishaps and recovery stories. If you’ve ever accidentally force-pushed to main, this talk was for you!

Code That Writes Code: .NET Source Generators (Speaker: Glenn F. Henriksen)

Source generators are one of .NET’s most powerful yet underutilized features. Glenn demonstrated how they can eliminate boilerplate, improve performance by moving work to compile-time, and create type-safe code generation patterns. This is definitely an area I need to explore more for my own projects.

Warm and Fuzzy: Semantic Search in .NET (Speaker: Jonathan “J.” Tower)

Jonathan delivered an excellent introduction to implementing semantic search using vector databases. He covered several options for .NET developers:

SQL Server 2025 with native vector support
Azure Cosmos DB for NoSQL vector storage
Qdrant as a specialized vector database

The talk also touched on Semantic Kernel , which is now part of the Microsoft Agent Framework – a significant development for building intelligent applications.

Action Items:

Implement semantic search for my blog to improve content discovery
Explore the demo code on GitHub

Coding 4 Fun: 8-bit Game Emulation in .NET (Speaker: Alex Thissen)

Pure fun! Alex walked through building an 8-bit game emulator in .NET, demonstrating low-level programming concepts in a modern language. A great reminder that not everything we build needs to be “enterprise-ready” – sometimes coding is just about learning and enjoyment. Lots of shifting bytes around, so a great example of the different things you can do with .NET.

Friday

Keynote: AI-Powered App Development (Speaker: Steve Sanderson)

Steve Sanderson delivered an inspiring keynote on how AI is transforming application development. The GitHub Copilot CLIwas demonstrated, with a new feature added in front of our eyes. Hundreds of Pull Requests can be generated with AI, but they all need reviewing and maintaining by Software Developers and there are no easy answers for managing that.

What in the Hunger Games is Happening with Recruitment? (Speaker: Suzi Edwards-Alexander)

A frank and often amusing look at the current state of tech recruitment. Suzi traced how we arrived at today’s challenging hiring landscape – from the first interview questions created by Thomas Edison, to the rise of LinkedIn and modern recruitment processes. Recruitment is broken, and there are no easy ways of fixing it.

The Great Brain Robbery: Navigating the Dark Future of Online Manipulation (Speaker: Jeff Watkins)

A sobering examination of how online platforms use psychological manipulation and dark patterns to exploit users’ attention and data. Jeff didn’t just highlight the problems – he offered strategies for recognizing and resisting these tactics, both as developers and as users. This talk was rather bleak reinforcing the notion that you can not trust anything you see or read online.

Beyond the AI Hype: What’s Real, What’s Next (Speaker: Richard Campbell)

Richard cut through the AI hype to examine what’s genuinely transformative versus what’s just marketing. He explored current capabilities, realistic near-term developments, and the fundamental limitations we need to understand. A perfect counterbalance to the morning’s optimistic keynote – both perspectives are necessary for making informed decisions about AI adoption.

Resilient by Design (Speaker: Chris Ayers)

The final session I attended focused on building resilient systems in Azure from the ground up. Chris covered how much downtime you can have if your SLA is 99.99% (8.6s a day see uptime.is) – but more importantly, the mindset shift required to design for failure rather than just success. In production, it’s not if things will fail, but when and how gracefully.

Networking Break: JetBrains Rider Team

I skipped one session to have an extended conversation with the JetBrains Riderteam at their booth. These unstructured conversations are often where you get the most value at conferences – I am a big fan of Visual Studio, but I have never tried Rider, this informal chat has encouraged me to download Rider and give it a try.

Final Thoughts

NDC London 2026 was another incredible experience. The breadth of topics – from accessibility and UX to AI, observability, and system resilience – reflects the diverse skills modern developers need.

My key takeaways from this year:

Accessibility is non-negotiable – both legally and morally
AI tools are here to stay – learn to leverage them effectively
Technical excellence matters – shortcuts today become tomorrow’s technical debt
Community is everything – the conversations between sessions were as valuable as the talks themselves

Huge thanks to the NDC organizing team, my fellow volunteers, all the speakers who shared their knowledge, and the attendees who made this such an engaging event. If you get the chance to attend (or volunteer at) NDC Conferences, I highly recommend it.

Interested in attending NDC London 2027? Follow @NDC_Conferencesfor updates!

See you at NDC London 2027! 🚀

2025 in Review and Goals for 2026

Simon Foster — Thu, 01 Jan 2026 09:00:00 +0000

2025 in Review

What a year 2025 has been! I published 24 blog posts covering a wide range of topics from cloud-native technologies to AI experiments, and even some personal reflections. Here are the key themes and highlights from my blogging year:

Cloud-Native and DevOps

This was a major focus area for me in 2025, not really surprising as I moved into a DevOps role this year, with deep dives into modern infrastructure:

Learning Kubernetes- Started my journey into container orchestration and shared my beginner experiences
Deploying Hugo with Helm- Deployed this very blog to Kubernetes using Helm charts
Kubernetes and Let’s Encrypt- Tackled SSL certificate management in Kubernetes
Monitoring with Nagios Docker- Explored monitoring solutions in containerized environments

.NET and Development

My bread and butter continues to be .NET development, with several posts exploring new features and tools:

Blazor and .NET 10- Covered breaking changes, fixes, and new features in the latest .NET release
Adding Elasticsearch with .NET Aspire- Integrated search capabilities using Aspire
Aspire 9.2- Explored the latest Aspire release
NuGet Central Package Management- Streamlined dependency management
What’s New in C#- Covered the latest language features
Exceptions- Best practices for error handling

Observability and Monitoring

Understanding what’s happening in production became a key theme:

Getting Started with OpenTelemetry- Made observability easy with modern tracing
OpenTelemetry Logs- Extended observability to include logging
Setting up Grafana- Built dashboards for monitoring

Cloud Platforms

Merging Two Projects into One- Shared my experience consolidating codebases

AI and Creativity

Fun with AI- Explored ChatGPT’s image generation capabilities
Using AI- Practical applications of AI in daily work
Mandelbrot Set- A fun mathematical exploration

Professional Development

The Pragmatic Programmer- Book review of this classic software development book
The Hacker Ethic- Reflections on developer culture and values
Stepping Outside Your Comfort Zone- Personal growth and career development
Volunteering at NDC London- My experience at this major .NET conference
Periodic Table of DevOps 2025- A visual guide to the DevOps ecosystem

Fun Projects

Festive Naughty or Nice Checker- A seasonal AI-powered fun project

Thank you to everyone who read, commented, and shared my posts throughout the year. Your engagement and feedback mean the world to me!

2025 by the Numbers

24 blog posts published
Major topics: Kubernetes, .NET, OpenTelemetry, AI
New skills acquired: Helm, Kubernetes, observability tools
Conferences attended: NDC London (as a volunteer) and DDD North
Submitted content to https://festivetechcalendar.com

Goals for 2026

Looking ahead to 2026, I’m excited to build on this momentum. Here are my blogging and technical goals:

Content Goals

Publish at least 24 posts - Maintain the pace from 2025
Deep dive into AI/ML - Go beyond experimentation to practical implementations
More hands-on tutorials - Provide step-by-step guides that readers can follow along with

Technical Skills

Master Kubernetes - Move from beginner to intermediate proficiency
Advanced observability - Implement comprehensive monitoring across distributed systems
Cloud-native patterns - Explore microservices, event-driven architectures, and service mesh
AI integration - Build practical AI-powered features into applications
Platform engineering - Create better developer experiences and internal platforms

Walking

At the end of 2024 I made the following goal:

2024 took an unusual turn. In June, I walked a half marathon across the Peak District, and since then,
I have been doing lots of walks. Walking is good for my physical and mental health,
so I intend to do more of it in 2025. I have a 5k scheduled for January,
which should be lots of fun as it is around the wildlife park.

Well I enjoyed my walk in January 2025, which then led to two 10k walks (in July and September) and a 7.5k night walk (in Blackpool to see the Illuminations). This led me to explore parkrunand I completed my 8th run this morning. I say run, not walk as I am slowly becoming more of a runner and less of a walker.

So my goal here is to keep doing this, as I am so far enjoying getting out and about.

What Would You Like to See?

I’d love to hear from you! What topics would you like me to cover in 2026? Are there specific technologies, patterns, or problems you’d like to see explored?

Drop a comment below, reach out on social media, or send me a message. Your feedback helps shape the content direction for the year ahead.

Here’s to a fantastic 2026 filled with learning, building, and sharing! 🚀

Creating a Festive Naughty or Nice Checker Using Semantic Kernel and .NET

Simon Foster — Fri, 12 Dec 2025 10:00:00 +0000

Introduction

I’m excited to be taking part in this year’s Festive Tech Calendar, a community-driven advent calendar showcasing amazing technical content throughout December. Make sure to check out the other excellent posts created by developers from around the world!

In this festive tutorial, we’ll build a fun “Naughty or Nice” checker using Microsoft’s Semantic Kernel and .NET. This playful AI-powered tool analyzes text descriptions and delivers a verdict on whether someone has been naughty or nice this year—perfect for adding some holiday cheer to your portfolio! Whether you’re new to AI integration or looking to explore Semantic Kernel, this beginner-friendly guide will walk you through creating a complete working application from scratch. By the end, you’ll have a deployable web app and understand how to integrate large language models into your .NET projects.

My Take on AI

Before diving into code, I want to share a quick perspective on using AI in development. While building this demo, I used GitHub Copilot to transform a basic UI into something more festive.

Starting with a simple, functional interface:

After a few prompts to Copilot, I had a Christmas-themed demo with loading spinners and festive icons:

Could I have coded this myself? Absolutely. But I’d rather focus my energy on the backend Semantic Kernel integration than wrestling with CSS animations. This is where AI shines—handling the tedious parts so you can focus on the interesting problems.

The Reality Check

That said, AI isn’t magic:

Hallucinations happen - I’ve lost time chasing incorrect suggestions, so don’t retire your search engine just yet
Ownership questions remain - Who owns AI-generated code? This is still being figured out
It’s a tool, not a replacement - AI augments developers; it doesn’t replace critical thinking

My approach: Use AI as a productivity multiplier, but always verify, understand, and own what you ship.

What is Semantic Kernel?

Semantic Kernel is an open-source SDK from Microsoft that makes it easy to integrate AI models into your .NET applications. It allows you to use large language models (LLMs) for tasks like text analysis, summarization, and more.

Project Overview

We’ll create a simple web app that:

Accepts a name or short description of someone’s behaviour
Uses Semantic Kernel to analyze the input
Returns a festive verdict: Naughty or Nice

Prerequisites

.NET 10 (I am not using any .NET 10 specific features so could probably be rewritten with older versions)
Semantic Kernel (NuGet package)
An OpenAI API key - ⚠️ Note : API usage costs ~$0.01-0.05 per request

OpenAI and Costs

For this example I have used an OpenAI API Key. This is not free, however while writing this example I have only spent a few pounds in tokens. For more information about OpenAI head over to https://platform.openai.com/

For this reason I have not provided a live demo, (I don’t want you all using my API key), and no API keys are included in my example code.

Step 1: Setting Up the Project

Create a new Blazor Web App:

dotnet new blazor -n NaughtyOrNiceChecker
cd NaughtyOrNiceChecker

Install the required NuGet packages: (Microsoft.SemanticKernel.Connectors.OpenAI Version 1.67.1 as I write this)

dotnet add package Microsoft.SemanticKernel.Connectors.OpenAI

Add your OpenAI configuration to appsettings.json:

{
  "OpenAI": {
    "Key": "your-api-key-here", // Head over to https://platform.openai.com/settings/organization/api-keys
    "Model": "gpt-5" // I am using gpt-5 but feel free to experiment with other models
  }
}

🔒 Security : Never commit API keys to GitHub. Use user secrets or environment variables.

The code for my project can be found on GitHub at https://github.com/funkysi1701/FestiveTechCalendar2025.

Step 2: Integrate Semantic Kernel

Configure Semantic Kernel to use your LLM provider (OpenAI). In the Program.cs file you will see the following code, this loads the OpenAI key and model from your appsettings.json config file, and allows it to be used by Semantic Kernel.

var key = builder.Configuration.GetValue<string>("OpenAI:Key");
var model = builder.Configuration.GetValue<string>("OpenAI:Model");
if (!string.IsNullOrEmpty(key))
{
    builder.Services.AddOpenAIChatCompletion(
        modelId: model ?? throw new ApplicationException("Missing OpenAI Config"),
        apiKey: key
    );
}
builder.Services.AddKernel();

Step 3: Create the Blazor Component

Create a new file Components/Pages/NaughtyOrNice.razor:

@page "/naughty-or-nice"
@inject Kernel _kernel
@rendermode InteractiveServer

<PageTitle>Naughty or Nice Checker</PageTitle>

<h3>🎅 Naughty or Nice Checker</h3>

<div class="card">
    <div class="card-body">
        <input @bind="input" 
               placeholder="Describe their behavior..." 
               class="form-control mb-3" />
        <button @onclick="CheckStatus" 
                class="btn btn-primary">
            Check Status
        </button>

        @if (!string.IsNullOrEmpty(response))
        {
            <div class="alert alert-@alertClass mt-3">
                <h4>@response</h4>
            </div>
        }
    </div>
</div>

@code {
    private string childsName = "";
    private string response = "";
    private string alertClass => response == "Naughty" ? "danger" : "success";
    private bool isLoading = false;

    public async Task CheckStatus()
    {
        isLoading = true;
        await InvokeAsync(StateHasChanged);
        response = string.Empty;
        try
        {
            var input = (childsName).Trim();
            if (string.IsNullOrEmpty(input))
            {
                return;
            }

            using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(30));
            var prompt = "You are Santa's assistant. Given the child's name or short description, " + 
            "decide if they are Naughty or Nice for Christmas. " + 
            "Respond only with one word: Naughty or Nice. " +
            "No punctuation, no explanation. Input: {{$input}}";
            var classifyFunc = _kernel.CreateFunctionFromPrompt(prompt);
            var aiResponse = await _kernel.InvokeAsync(
                classifyFunc, 
                new() 
                { 
                    ["input"] = input 
                }, 
                cts.Token
            );
            var text = aiResponse.GetValue<string>()?.Trim();

            // Normalize and enforce strict output
            if (string.Equals(text, "naughty", StringComparison.OrdinalIgnoreCase))
            {
                response = "Naughty";
            }
            else if (string.Equals(text, "nice", StringComparison.OrdinalIgnoreCase))
            {
                response = "Nice";
            }
            else
            {
                // Fallback: default to Naughty to avoid leaking other content
                response = "Naughty";
            }
        }
        finally
        {
            isLoading = false;
            await InvokeAsync(StateHasChanged);
        }
    }
}

Note: The _kernel is injected automatically because we registered it in Program.cs with builder.Services.AddKernel().

Step 4: Crafting the Perfect Prompt

Getting AI to return exactly what you want requires iteration. I’ll walk you through my prompt engineering journey from verbose outputs to production-ready responses.

Iteration 1: Too Verbose

var aiResponse = await _kernel.InvokePromptAsync(
    $"You are a tool to help Santa identify if children have been naughty or nice. " +
    $"Has {input} been naughty or nice this year?",
    cancellationToken: cancellationToken.Token
);

Input	Output
Santa	Short answer: Nice. Why: - Spreads joy and generosity globally - Works hard with his team, treats elves and reindeer well - Answers letters and keeps promises (on-time deliveries) Minor demerits (lighthearted): - Excess cookie consumption - Occasional chimney soot prints Verdict: Firmly on the Nice List. Want a fun “Official Nice Report” for Santa you can share?
Darth Vader	Not exactly a child, but Santa checks everyone. Darth Vader’s record this year includes Force-choking subordinates and aiding Imperial oppression—firmly Naughty. Mitigating note: he did protect his son and turn against the Emperor, which earns a small mercy. Final verdict: Naughty list (with a tiny redemption candy cane).
James	I don’t have access to Santa’s list or personal data, so I can’t say for sure about James. But I can help you decide with a quick Naughty/Nice check: Score each item: - Kind and helpful to family/classmates most of the time? (Yes +2, Sometimes +1, No 0) - Tells the truth and takes responsibility? (Yes +2, Sometimes +1, No 0) - Apologizes and makes things right after mistakes? (Yes +2, Sometimes +1, No 0) - Respects rules and others (no bullying or deliberate harm)? (Yes +2, Sometimes +1, No 0; deduct 2 if there’s repeated serious harm) - Does generous things (sharing, chores, helping the community)? (Yes +2, Sometimes +1, No 0) Totals: - 8–10: Nice List - 5–7: Mostly Nice (keep it up) - 2–4: Mixed (needs a December boost) - 0–1 or repeated serious harm: Naughty-for-now (with room to improve) If James needs a boost: make amends where needed, do one unprompted kindness or chore daily, be honest about mistakes right away, and share/donate something or help someone weekly. Share a few examples of James’s year and I’ll help you make the call.
Skeletor	Verdict: Naughty. Why: - Repeated attempts to conquer Eternia and seize Castle Grayskull - Habitual scheming, lying, and bullying his own minions - Frequent unleashing of dangerous magic on innocents Path back to the Nice List: - Call a truce with He-Man and protect Eternia for a season - Return stolen artifacts and undo harmful spells - Treat his minions fairly and do a few good deeds without expecting power in return

This is far too wordy, I really just want a Naughty or Nice response.

Iteration 2: Constraining the Output

Then I tried:

var aiResponse = await _kernel.InvokePromptAsync(
    $"Given the following description, decide if the person is Naughty or Nice for Christmas. " +
    $"Respond only with 'Naughty' or 'Nice'. " +
    $"Description: {input}",
    cancellationToken: cancellationToken.Token
);

Input	Output
Santa	Nice
Darth Vader	Naughty
James	Nice
Skeletor	Naughty

This is better but every name I tried is giving me a Nice, so let’s see if we can try something a bit more clever. However if instead of only including a name, we include some naughty or nice actions we get some interesting results.

Input	Output
Santa delivered some presents	Nice
Darth Vader destroyed Alderaan	Naughty
James tidied his room	Nice
Skeletor got cross with Evil Lynn	Naughty

Version 3: Non-AI Approach (Plugin Example)

This version demonstrates Semantic Kernel’s plugin system without using AI. While it doesn’t actually help Santa (it just generates a hash-based result), it shows how you can integrate traditional .NET code into Semantic Kernel workflows.

Why show this? To illustrate that Semantic Kernel isn’t just for AI—you can mix AI calls with regular code execution in the same pipeline.

var aiResponse = await _kernel.InvokeAsync(
    pluginName, 
    "GenerateHash", 
    new KernelArguments
    {
        ["input"] = input
    }
);

This version invokes a semantic kernel plugin function called GenerateHash. The function itself is defined in a separate class with a KernelFunction attribute, it is really simple just generates a hash from the input string. This is just an example of how you can call .NET code from Semantic Kernel. The kernel function requires an extra line to wire up correctly I have placed this in the OnInitialized method.

protected override void OnInitialized()
{
  var rngPlugin = new ExamplePlugin();
  _kernel.ImportPluginFromObject(rngPlugin, pluginName);
}


public class ExamplePlugin
{
    [KernelFunction]
    public int GenerateHash(string input)
    {
        if (input == null)
        {
            throw new ArgumentNullException(nameof(input));
        }
        var hash = input.GetHashCode();

        return hash > 0 ? 0 : 1;
    }
}

Final Version: Production-Ready Implementation

My last example is very similar to Version 2 but let’s have a look at it.

var prompt = "You are Santa's assistant. Given the child's name or short description, " + 
            "decide if they are Naughty or Nice for Christmas. Respond only with one word: Naughty or Nice. " +
            "No punctuation, no explanation. Input: {{$input}}";
            var classifyFunc = _kernel.CreateFunctionFromPrompt(prompt);
            var aiResponse = await _kernel.InvokeAsync(
                classifyFunc, 
                new() 
                { 
                    ["input"] = input 
                }, 
                cancellationToken.Token
            );

Here we have a bit more error checking to make sure we have entered a valid string before calling OpenAI. This time we use the CreateFunctionFromPrompt method to pass in a prompt, we then invoke the prompt along with the string that has been entered.

This time we check for naughty or nice in the response before returning that to the user, if neither is returned we return Naughty.

This works quite well if we enter a more descriptive input.

Input	Output
Santa delivered some presents	Nice
Darth Vader destroyed Alderaan	Naughty
James tidied his room	Nice
Skeletor got cross with Evil Lynn	Naughty

As you can see if we describe the actions of someone we can categorize them as naughty or nice, which is basically what Santa does, so this tool should be a great help to him.

Comparing All Versions

Version	Approach	Pros	Cons	Use Case
1	Open-ended prompt	Rich explanations	Too verbose	Learning/debugging
2	Constrained output	Concise	Needs context	Simple classifications
3	Hash-based (no AI)	No API costs	Not intelligent	Plugin example only
4	Validated prompts	Reliable, safe	More code	Production

Conclusion

In this tutorial, we built a festive AI-powered application using Semantic Kernel and .NET. Here’s what we accomplished:

✅ Integrated OpenAI with Semantic Kernel in a Blazor app
✅ Learned prompt engineering through iteration (4 versions!)
✅ Implemented proper error handling and output validation
✅ Created a fun, interactive holiday application

I have tried to highlight some of the different ways that you can use Semantic Kernel that you could use in your own projects. Some of my examples could be accomplished without the use of Semantic Kernel, for example randomly generating Naughty and Nice doesn’t need AI, however hopefully you can see that getting results from AI can then be augmented using traditional .NET code to execute other functions.

Key Takeaways

Prompt engineering matters - Notice how Version 4’s explicit instructions produced better results
Validation is essential - Always sanitize LLM outputs before displaying to users
Keep it simple - Complex doesn’t mean better (Version 3’s random approach was overkill)

Cost Considerations

During development, I spent only a few pounds on API tokens. For production:

Use Azure OpenAI for predictable pricing
Implement caching for common queries
Set up rate limiting to prevent abuse

Deployment Options

This Blazor app can be deployed to:

Azure Static Web Apps (free tier includes 2 custom domains)
Azure App Service (full .NET hosting)
Docker containers (run anywhere)

Next Steps

Want to extend this project? Try:

Add a database to track naughty/nice history
Implement user authentication
Deploy to Azure Static Web Apps
Add more context (age, location) for better AI decisions

Happy coding and Merry Christmas! 🎄

References:

Blazor and .NET 10: Breaking Changes, Fixes, and New Features

Simon Foster — Mon, 17 Nov 2025 20:00:00 +0000

What’s New in .NET 10?

.NET 10 was released this week and it is full of awesome new features. Check it out at .NET Download, there is also a new version of Visual Studio which you should also check out.

I quickly upgraded my .NET projects to take advantage of the new version, but my Blazor WebAssembly (Wasm) project encountered the following error in the browser console:

System.NotSupportedException: net_http_synchronous_reads_not_supported
   at System.Net.Http.BrowserHttpReadStream.Read(Byte[] buffer, Int32 offset, Int32 count)
   at System.IO.DelegatingStream.Read(Byte[] buffer, Int32 offset, Int32 count)
   at System.IO.StreamReader.ReadBuffer(Span`1 userBuffer, Boolean& readToUserBuffer)
   at System.IO.StreamReader.ReadSpan(Span`1 buffer)
   at System.IO.StreamReader.Read(Char[] buffer, Int32 index, Int32 count)
   at Newtonsoft.Json.JsonTextReader.ReadData(Boolean append, Int32 charsRequired)
   at Newtonsoft.Json.JsonTextReader.ReadData(Boolean append)
   at Newtonsoft.Json.JsonTextReader.ParseValue()
   at Newtonsoft.Json.JsonTextReader.Read()
   at Newtonsoft.Json.JsonReader.ReadAndMoveToContent()
   at Newtonsoft.Json.JsonReader.ReadForType(JsonContract contract, Boolean hasConverter)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonSerializer.Deserialize(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonSerializer.Deserialize[MyResult](JsonReader reader)
   at MyAPI.Client.MyClient.<ReadObjectResponseAsync>d__57`1[[MyAPI.Client.MyResult, MyAPI.Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext()
   at MyAPI.Client.MyClient.MyAsync(MyRequest body, CancellationToken cancellationToken)

This error was getting thrown on a Blazor Wasm page when it tried to make a call to my API. This worked fine in .NET 9 so my suspicion was this might be a breaking change.

The list of new features for .NET 10 can be found .NET 10 Release Notes

HttpClient Response Streaming: Breaking Change in Blazor

I found the following new feature which I suspect is related to my issue:

HttpClient response streaming enabled by default

In prior Blazor releases, response streaming for HttpClient requests was opt-in. Now, response streaming is enabled by default.

This is a breaking change because calling HttpContent.ReadAsStreamAsync for an HttpResponseMessage.Content (response.Content.ReadAsStreamAsync()) returns a BrowserHttpReadStream and no longer a MemoryStream. BrowserHttpReadStream doesn’t support synchronous operations, such as Stream.Read(Span<Byte>). If your code uses synchronous operations, you can opt-out of response streaming or copy the Stream into a MemoryStream yourself.

To opt-out of response streaming globally, use either of the following approaches:

Add the property to the project file with a value of false:

<WasmEnableStreamingResponse>false</WasmEnableStreamingResponse>

Set the DOTNET_WASM_ENABLE_STREAMING_RESPONSE environment variable to false or 0.

To opt-out of response streaming for an individual request, set SetBrowserResponseStreamingEnabled to false on the HttpRequestMessage (requestMessage in the following example):

requestMessage.SetBrowserResponseStreamingEnabled(false);

For more information, see HttpClient and HttpRequestMessage with Fetch API request options (Call web API article).

How to Fix the Streaming Issue in Blazor

To test out if this was the culprit I added <WasmEnableStreamingResponse>false</WasmEnableStreamingResponse> to my csproj file and sure enough this fixed my issue.

Do check out the docs for a complete list of new features and any other potential breaking changes. .NET 10 Release Notes

Periodic Table of DevOps 2025

Simon Foster — Mon, 29 Sep 2025 20:00:45 +0000

DevOps has transformed the way teams build, deploy, and manage software. Over the years, the tools we use have evolved rapidly—some have become industry standards, while others have faded away or emerged to solve new challenges. In this post, I revisit the concept of a “Periodic Table of DevOps” to compare the landscape in 2016 with 2025, highlight key changes, and reflect on what these shifts mean for developers, IT professionals, and organizations embracing modern workflows.

The periodic table lists all the chemical elements and groups them together based on some key properties. In 2016 I found an article about the periodic table of DevOps and wrote a blog post about it.

Periodic Table of DevOps Tools 2025

Periodic Table of DevOps Tools 2016

I thought it might be interesting to see what tools are still in use, and what are new.

Source Control

Git, the most popular source control system, is on both charts, in 2016 it was at position 3, and in 2025 it is at 2. GitHub, the most widely used web-based git repository, is also on both charts, moving from 1 to 10. Bitbucket (now owned by Atlassian) was a hosted git repository I used to use and is still on the chart, moving from 11 to 36. Subversion, a source control system I started my career with, has vanished off the chart in 2025. Not really a surprise due to the popularity of git now.

Cloud Platforms

In 2016 we had a whole column of Cloud Platforms, including Rackspace and OpenShift, in 2025 this has been reduced to the big three (Azure, AWS and GCP) plus OpenShift.

Containerization

In 2016 we had a column of tools like Docker, Docker Swarm and Kubernetes. In 2025 there are far more tools in this space, with the addition of tools like Helm and the various ways you can host containers on cloud platforms (like Azure AKS).

Build and Deploy tools

In 2016 Azure DevOps was still called Team Foundation Server, so this has spread out into the various ways you can use Azure DevOps, such as Pipelines and Code. Also since 2016 GitHub Actions has appeared on the market.

In 2016 I was also dabbling with TeamCity, this is no longer used that much so isn’t on the chart in 2025. Jenkins is still around on both charts.

Comms Tools

In 2025 Slack and MS Teams are the go-to tools for communicating with distributed teams, Slack was around in 2016, but Teams wasn’t a thing back then.

New Tools

New tools for monitoring like Grafana have appeared; back in 2016 I was exclusively using Application Insights from Azure.

Conclusion & Key Takeaways

The DevOps landscape has changed dramatically over the past decade. Some tools have stood the test of time, while others have faded or emerged to meet new challenges. Here are the key takeaways:

Git remains the backbone of source control , with platforms like GitHub and Bitbucket continuing to thrive.
Cloud platforms (Azure, AWS, GCP) have become central, reflecting the shift to cloud-native development and operations.
Containerization and orchestration (Docker, Kubernetes, Helm) are now essential, enabling scalable, flexible deployments.
Monitoring and collaboration tools have evolved , with newcomers like Grafana and MS Teams joining established solutions.
Legacy tools are disappearing , showing the importance of adaptability in tech.

As DevOps continues to evolve, staying curious and open to new tools is key. The periodic table analogy reminds us that the right mix of technologies can empower teams to build, deploy, and manage software more effectively. What tools will shape the next decade? Only time will tell.

The Mandelbrot Set

Simon Foster — Mon, 15 Sep 2025 20:00:00 +0000

The Mandelbrot Set: Beauty, Chaos, and Mathematical Art

The Mandelbrot set is one of the most iconic images in mathematics—a mesmerizing swirl of fractal patterns, infinite complexity, and unexpected beauty. But what exactly is the Mandelbrot set, and why has it captured the imagination of mathematicians, artists, and curious minds alike?

What Is the Mandelbrot Set?

At its core, the Mandelbrot set is a collection of complex numbers. It’s defined by a simple equation, but the results are anything but simple. The definition is:

A complex number c is in the Mandelbrot set if, when you start with z = 0 and repeatedly apply the function z = z² + c, the value of z remains bounded (does not go to infinity), no matter how many times you iterate.

In other words, for each point c on the complex plane, you check: if you keep plugging it into this formula, does it stay small, or does it spiral out of control? If it stays small forever, it’s in the Mandelbrot set.

From Simple Formula to Stunning Images

The real magic happens when you visualize the Mandelbrot set on a computer. Each point in the complex plane is coloured based on whether it belongs to the set or how quickly it escapes to infinity. The result is a black, bulbous shape surrounded by intricate, infinitely detailed patterns that resemble swirling galaxies, seahorses, or lightning bolts—the Mandelbrot set and its “fractal boundary.”

Zooming in on the edge reveals ever-more complexity, with shapes that are reminiscent of the original set at different scales. This property, a form of self-similarity, is a hallmark of fractals.

Why Is the Mandelbrot Set Important?

The Mandelbrot set is more than just a pretty picture. It’s a window into the world of complex dynamics and chaos theory. The set’s boundary is infinitely complex, showing how simple mathematical rules can generate unexpected and beautiful complexity.

It also has deep implications in mathematics:

Fractals: The Mandelbrot set is the most famous example of a fractal—a shape that shows similar, though not identical, patterns at every scale.
Chaos Theory: It illustrates sensitive dependence on initial conditions, where tiny changes can lead to drastically different outcomes.
Complex Numbers: It brings to life the beauty of complex numbers, which are usually abstract concepts in math classes.

The Mandelbrot Set in Art and Culture

Thanks to its stunning visuals, the Mandelbrot set has become a cultural icon. It’s inspired digital art, music, and even jewellery. It also serves as a symbol for how complexity and order can emerge from simple rules, a concept that resonates in fields from biology to computer science.

Try It Yourself

Many websites and software tools let you explore the Mandelbrot set interactively. Try zooming in and discover new shapes and patterns emerging at every level. It’s a fantastic way to experience the intersection of math, art, and chaos.

Final Thoughts

I have been fascinated by fractals since I was young. I remember seeing them generated on a Lynx computer and the process was slow, one pixel at a time, after a few hours you would see a complete mandelbrot set. More recently I have looked at generating them in the browser (using .NET’s Blazor WebAssembly technology), and the image at the start of this post took only a few seconds to generate.

I’ve also created an interactive Mandelbrot set generator. It’s a work in progress, but you can already generate a set and zoom in using the buttons at the top or by clicking with your mouse. I plan to add more features in the coming weeks.

The Mandelbrot set reminds us that even the simplest equations can produce infinite complexity and beauty. It stands as an enduring inspiration—proof that mathematics is not just about numbers, but about wonder, creativity, and the endless possibilities hidden within the fabric of reality.

The Hacker Ethic

Simon Foster — Mon, 01 Sep 2025 20:00:00 +0000

The Hacker Ethic: Principles That Shaped the Digital Age

When most people hear the word “hacker,” they imagine shadowy figures breaking into computer systems. But the original meaning of “hacker” is far richer, rooted in curiosity, creativity, and a set of values that have profoundly shaped technology and culture. This philosophy, known as the hacker ethic , remains a powerful force driving innovation and openness in our digital world.

What Is the Hacker Ethic?

The term “hacker ethic” was popularized by Steven Levy in his book Hackers: Heroes of the Computer Revolution. I have just finished listening to the audio version, and highly recommend it. The book describes a set of beliefs and practices developed by early computer enthusiasts at places like MIT, Stanford, and the Homebrew Computer Club. Far from criminality, the hacker ethic is about playful exploration, sharing knowledge, and questioning limits.

The Core Principles

The hacker ethic can be distilled into several key tenets:

1. Access to Computers Should Be Unlimited and Total

Hackers believe that information and tools for learning should be open to all. They value environments where curiosity is encouraged and barriers to entry are low. This spirit led to the creation of open-source software, free educational resources, and collaborative online communities.

2. All Information Wants to Be Free

While not advocating for stealing proprietary data, hackers champion the free flow of information. They believe that sharing code, knowledge, and discoveries accelerates progress and empowers individuals. This principle underlies movements like open data, Creative Commons, and Wikipedia.

3. Mistrust Authority—Promote Decentralization

Hackers are skeptical of gatekeepers and centralized control. They prefer systems that empower individuals and distribute power. This mindset has influenced everything from peer-to-peer networks to blockchain technology.

4. Hackers Should Be Judged by Their Hacking, Not Bogus Criteria

Hackers value skill, creativity, and contribution over credentials or status. In hacker culture, what matters is what you build, solve, or improve—not your job title, age, or background. This meritocratic ideal helped shape the egalitarian ethos of the internet.

5. You Can Create Art and Beauty on a Computer

Hackers see computers not only as tools, but as canvases for creativity. From elegant code to digital art, they celebrate the artistry inherent in technology and design.

6. Computers Can Change Your Life for the Better

Hackers believe in the transformative potential of technology. They see computers as instruments of empowerment, education, and community—tools that can solve meaningful problems and improve lives.

Why the Hacker Ethic Matters Today

The hacker ethic is alive in open-source communities, maker spaces, and digital activism. It challenges us to question closed systems, embrace sharing, and use technology for good. In a world increasingly shaped by algorithms and artificial intelligence, the hacker ethic reminds us that human creativity, curiosity, and collaboration are still at the heart of progress.

After listening to the book it is very clear to me that many of today’s security problems stem from this ethic. Early computers and software were built by design without security in mind. The hackers featured in the book strongly disliked passwords and locks, they believed information and systems should be open to all. I had incorrectly assumed that it was just an oversight and wasn’t needed back then.

The growth of open source software can clearly be seen as an extension to the sharing of code started by these early hackers, instead of looking in a drawer for paper tape containing the code you want to improve, we go to GitHub, but the principle is the same.

Final Thoughts

The hacker ethic is far more than a technical mindset—it’s a philosophy of openness, empowerment, and playful problem-solving. By understanding and embracing these principles, we can build a digital future that is more inclusive, innovative, and free.

The more I think about my career with computers, the more I feel I fit more as a hacker than a programmer or any other job title. I started hacking together simple web pages, I then hacked away at networks and active directory, now I hack at dotnet and kubernetes.

Automating SSL for Kubernetes with Let's Encrypt and Cert Manager

Simon Foster — Mon, 07 Jul 2025 20:00:00 +0000

I have blogged before about how cool Let’s Encrypt is for getting your web things running under https. However I have just got myself a local kubernetes cluster and it is super easy to spin up new web services with SSL certs.

The basic instructions can be found here but let’s look at what was involved.

First of all lets get Cert Manager installed on kubernetes.

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.1/cert-manager.yaml

Once the cert manager pods are up, you need to create an issuer which communicates with the lets encrypt API. The first code snippet uses the lets encrypt staging environment to avoid any API limits, the second uses production and uses the cloudflare API to authorize SSL requests.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-staging
    solvers:
    - http01:
        ingress:
          ingressClassName: nginx


apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - dns01:
          cloudflare:
            apiTokenSecretRef:
              key: api-key
              name: cloudflare-api-token-secret
            email: your-email@example.com

Now that is all configured all I need to do is update my helm chart and any pod I like can have a sub domain of funkysi1701.com with a lets encrypt SSL cert.

This is a section from my helm chart which defines the domain name to use and what issuer to use for the certificate.

ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  devHost: helloworld-dev.funkysi1701.com
  testHost: helloworld-test.funkysi1701.com
  tls:
    - secretName: helloworld-dev.funkysi1701.com
      hosts:
        - helloworld-dev.funkysi1701.com
    - secretName: helloworld-test.funkysi1701.com
      hosts:
        - helloworld-test.funkysi1701.com

All I need to do now is add similar code like this to every helm chart I publish and my pod will request a SSL certificate. The only manual step I have is to set up a DNS record pointing to the IP address of my cluster for any domain I want to use.

Conclusion

Setting up Let’s Encrypt with Kubernetes and Cert Manager has made it incredibly easy to secure my web services with SSL certificates. With just a few YAML configurations and some simple Helm chart updates, I can automatically provision and renew certificates for any subdomain I need. This approach not only saves time but also ensures my services are always protected with up-to-date encryption. If you’re running Kubernetes, I highly recommend giving Cert Manager and Let’s Encrypt a try for hassle-free SSL management.

Stepping Outside My Comfort Zone: An Adventure Holiday Experience

Simon Foster — Mon, 02 Jun 2025 20:00:00 +0000

Stepping outside my comfort zone doesn’t come naturally to me. I’m happiest behind my laptop, but every now and then, I know it’s important to try something new. This year, my family and I decided to do just that—and it turned out to be one of our most memorable weeks ever. Curious about what happens when you swap routine for adventure? Read on!

Introduction

This week was our family holiday. Normally, we’d book a cottage somewhere nice and explore at our own pace. But this often leads to disagreements—everyone wants something different, and sometimes the places we visit aren’t as exciting as we hoped (especially for two kids aged 7 and 9 who get bored easily).

This time, we chose a different path: a family adventure holiday with High Adventure. The itinerary was packed: climbing, caving, hiking, water sports, archery, zip wires, and countless other activities. All meals, accommodation, equipment, and expert instructors were included, making it feel both safe and exciting.

I’ll admit, I was anxious before we set off. I’m not an adventurous person—I like walking, but I’d never tried anything like this. My nine-year-old son was dreading it, while my more adventurous seven-year-old was quietly excited. I worried that if the kids hated it, it would be a waste of money. But as soon as we arrived, those fears melted away.

Saturday

We arrived on Saturday afternoon and were shown to our room. My only real complaint from the whole week: the room was tiny. With two bunk beds and four of us plus a week’s worth of clothes, it was a challenge to keep things tidy. Thankfully, the rest of the facility was spacious, and our room was right next to the games room—a bonus.

Dinner was served at 6pm every evening, always a home-cooked meal. While I enjoyed the food, my fussy eaters weren’t always convinced, but there was usually something for everyone. We met the other family we’d be doing activities with.

After dinner, we explored the Games Room and took on the Labyrinth—a tight, dark maze constructed under the floor. Helmets were required! I found it a bit tight, but my boys absolutely loved it.

Sunday

Every day began with a cooked breakfast and a make-your-own sandwich station for lunch. Sunday morning kicked off with climbing and abseiling. I’d never climbed before, so I was surprised—and proud—to make it all the way to the top of the 8-meter wall. My boys didn’t quite reach the top, but they pushed themselves higher than I expected. Abseiling was fun too, and a great way to come down after the climb.

After lunch, we tried archery. I’d done it once before at my boys’ Scout group, but it took a while to hit the target consistently. Then came bushcraft: foraging for wood, using a knife to make kindling, and lighting a fire with a ferrocerium rod. My nine-year-old and I managed to get a fire going—definitely a memorable moment, especially when we roasted marshmallows.

The evening’s activity was Nightline: a blindfolded obstacle course. This was a bit much for me, but the boys loved it. My job was to guide them through the course, describing what to climb over, under, or through, and when to stop.

Monday

Monday started with a walk up the hill to Wainman’s Pinnacle and some “squirreling” through the rocks—a favourite for the boys, especially since they’d done it before with Scouts. I skipped most of the squirreling but enjoyed the walk.

In the afternoon, it was time for high ropes and a zip wire. We were safely roped in at all times, but stepping off a high ledge still required a leap of faith. My eldest was nervous and had to climb down at first, but after watching me try, he gave it another go—and loved it. That’s what this week was about: encouraging all of us to try new things.

The evening activity was Eggbert: designing a contraption to protect an egg dropped from a height. We worked as a family, but failed to consider that the weight would flip the egg so it landed the wrong way up. Oops! We didn’t win, but it was great fun seeing everyone’s creative designs.

Tuesday

Tuesday was our first full day offsite. The instructors drove us in a minibus to the Yorkshire Three Peaks area, where we explored underground caves. Wearing cave suits, wellies, and helmets, we were ready for adventure. I foolishly thought I wouldn’t need a change of clothes—turns out, crawling through water-filled tunnels means your wellies fill up fast! I wasn’t the biggest fan of being soaked, but the boys loved climbing and sliding through the narrow passages. We finished the day with ice cream and hot chocolate in Settle—a well-deserved treat.

That evening, we tried circus skills and gathered around a campfire. The boys were entertained for ages, trying juggling and balance activities. I didn’t master anything, but I enjoyed relaxing by the fire with my wife and the other parents.

Wednesday

By Wednesday, tiredness was catching up with me! We tackled a five-mile walk around Malham Cove, taking in stunning views and great weather. The route included Gordale Scar and Janet’s Foss, a lovely waterfall where many people swam or paddled. We hadn’t brought towels, but that didn’t stop my boys from getting soaked. It’s a holiday—why not?

Wednesday evening was supposed to be a parents’ night off, but we had to cut it short due to a family emergency.

Thursday

Thursday was water sports day, but we decided on a quieter option and visited Haworth instead. The town is famous for the Brontë sisters, and we enjoyed its picturesque streets, a museum, and a play area for the kids—a great way to wind down after so much activity.

The final evening was a quiz night, complete with questions about the week’s adventures.

Friday

Friday was going-home day, but not before one last challenge: orienteering. As a former university orienteering club member, I couldn’t resist joining in!

Conclusion

This week was truly about stepping outside my comfort zone and embracing new experiences. From climbing and caving to bushcraft and zip lines, every activity challenged me and helped me grow. I discovered that pushing your boundaries can be both exciting and rewarding—and creates memories that last a lifetime. If you ever get the chance to try something new, even if it feels a bit daunting, I highly recommend taking the leap. You might just surprise yourself!

Deploying My Blog to Kubernetes with Helm Charts

Simon Foster — Mon, 26 May 2025 20:00:00 +0000

Helm allows you to package your Kubernetes resources, manage configuration, and deploy updates with a single command.

In this post, I’ll share how I used Helm to deploy my Hugo blog, making it easy to manage updates and spin up new environments. Full disclosure: My blog currently runs on an Azure Static Web App, but now that I know how to deploy to a Kubernetes cluster, I have the option to switch if needed.

Why Use Helm?

Helm is the package manager for Kubernetes. It lets you:

Template your Kubernetes YAML files for reuse and configuration.
Version your deployments for easy rollbacks.
Share your charts with others or use community charts.

Creating a Helm Chart for Hugo

First, I scaffolded a new Helm chart:

helm create hugo-blog

This creates a directory structure with templates for deployments, services, and ingress.

Customizing the Chart

I edited values.yaml to set my image and service details:

image:
  repository: mydockerhubusername/hugo-blog # Docker image repository
  tag: latest # Use the latest tag for the image
  pullPolicy: IfNotPresent # Pull the image only if it’s not already present

service:
  type: NodePort # Expose the service on a specific port
  port: 80 # Internal port for the service
  nodePort: 30081 # External port for accessing the service

Deploying the Blog

To deploy the blog, I ran:

helm install my-hugo-blog ./hugo-blog

Helm rendered the templates and created the necessary Kubernetes resources.

Updating the Blog

When I rebuild and push a new Docker image, I can upgrade my deployment with:

helm upgrade my-hugo-blog ./hugo-blog

This triggers a rolling update in Kubernetes.

Creating a Docker Image of my Blog

This all assumes that I have a container image of my Hugo blog. Creating this was half the work.

I had been using a docker-compose file to build my blog; however, this doesn’t copy my files into the container it creates a volume to share my files with the container. I needed a Dockerfile that would copy my source code into a container and then save it into a container registry.

This is the Dockerfile I created. As you can see, it is a two-stage build. First, it takes the Hugo base image, copies my files into it, and builds Hugo. Then the NGINX web server is run, and the default web port 80 is exposed.

# Step 1: Build the Hugo site
FROM floryn90/hugo:0.119.0 AS builder

# Set working directory inside the container
WORKDIR /src

# Copy site files to the container
COPY . .

# Build the Hugo site
RUN hugo --minify --config config.toml

# Step 2: Serve with nginx
FROM nginx:alpine

# Remove the default nginx static files
RUN rm -rf /usr/share/nginx/html/*

# Copy the generated site from the builder stage
COPY --from=builder /src/public /usr/share/nginx/html

# Expose port 80
EXPOSE 80

# Start nginx
CMD ["nginx", "-g", "daemon off;"]

Benefits

Repeatable Deployments: Easily spin up new environments.
Configuration Management: Override values for different clusters or environments.
Easy Updates: Upgrade with a single command.

Conclusion

Helm charts have made deploying my Hugo blog to Kubernetes a seamless and efficient process. With features like templating, versioning, and easy updates, Helm is a must-have tool for Kubernetes deployments.

If you’re managing static sites or microservices, give Helm a try and see how it can simplify your workflow!

Have you used Helm for static sites or blogs? Share your experience in the comments below!