2026 on Funky Si's Blog (Dev)

GitOps with Flux on my k3s cluster

funkysi1701@gmail.com (funkysi1701) — Tue, 18 Aug 2026 08:00:00 +0000

I already knew how to put things on a Kubernetes cluster. Helm packages the YAML. kubectl apply makes it exist. cert-manager mints the certificates. What I did not have was a boring answer to “what happens next week, when I have forgotten which laptop I ran that from?”

GitOps is that answer, at least for platform on my homelab. In practice, GitOps means keeping the desired cluster state in git and having an in-cluster controller continuously reconcile the live cluster back to that state. simon-cluster is the name I gave the k3s cluster I run at home — a small Kubernetes estate for shared ingress, certificates, monitoring, and the GitHub Actions runners this blog builds on. Flux CD on that cluster watches a private platform repo and keeps it in line with main.

The useful part is not “I put YAML in git.” It is the split. Flux owns MetalLB, Traefik, cert-manager, GitHub runners, the in-cluster registry, Cloudflare Tunnel, and monitoring. Application Helm releases in develop / main / test still come from their own repos and pipelines. Azure DevOps is still in that second column. Flux is not pretending to be the whole estate.

Pull, not push

A lot of “GitOps” talk is really CI with extra steps: a pipeline authenticates to the cluster and runs helm upgrade. That is a push. It works. I still do it for apps.

Flux is a pull. The cluster has a GitRepository pointed at a private platform repo on main. Child Kustomization objects apply paths under that repo on a schedule. If someone (or some leftover pipeline) changes a Flux-managed object by hand, the next reconcile puts it back.

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
 name: flux-system
 namespace: flux-system
spec:
 interval: 1m
 ref:
 branch: main
 url: https://github.com/example/example-config.git

Bootstrap is once: install the Flux controllers (gotk-components.yaml), give Flux a git credential and an age key for SOPS, apply gotk-sync.yaml. After that I mostly work in git rather than reaching for kubeconfig.

git add -A && git commit -m "…" && git push
flux get all -A
flux reconcile kustomization flux-system --with-source

I still keep kubectl for poking at pods. I try not to use it as the source of truth for anything Flux already owns.

How the repo is laid out

clusters/simon-cluster/ # Flux bootstrap + child Kustomizations
infrastructure/ # HelmRepositories, HelmReleases, CRs, SOPS

clusters/simon-cluster is the entry point Flux syncs. Each child Kustomization is a named slice of the platform with its own interval, dependsOn, and (where secrets live) SOPS decryption. infrastructure/ is the actual YAML those slices apply.

Order matters. Helm charts cannot install until the HelmRepository objects exist. cert-manager cannot come up until those sources do. A shortened version of the cert-manager slice looks like this:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: cert-manager
 namespace: flux-system
spec:
 interval: 30m
 dependsOn:
 - name: sources
 path: ./infrastructure/cert-manager
 prune: true
 wait: true
 decryption:
 provider: sops
 secretRef:
 name: sops-age

prune: true is the bit people skip and then regret. If you delete the manifest and Flux still has prune off, the live object sits there forever looking “fine.” wait: true plus dependsOn is the other half of that: cert-manager does not race Traefik because the Kustomization will not move on until the slice is healthy.

The Helm install itself is a HelmRelease, not a pipeline task:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: cert-manager
 namespace: cert-manager
spec:
 interval: 30m
 chart:
 spec:
 chart: cert-manager
 version: "v1.21.0"
 sourceRef:
 kind: HelmRepository
 name: jetstack
 namespace: flux-system

Same idea as deploying with Helm , except the cluster is the thing that runs helm, not me.

One change, end to end

A typical platform change is dull, which is the point.

Edit YAML under infrastructure/… (chart version, values, a ClusterIssuer, a runner replica count).
Open a PR, merge to main.
Wait for the Kustomization interval, or flux reconcile if I am impatient.
flux get hr,ks -A until the slice is Ready.

If it is not Ready, read the condition before assuming git and the cluster agree. That command is the homelab equivalent of a pipeline log.

I already wrote about Let’s Encrypt on this cluster when cert-manager was a kubectl apply of upstream YAML. That install now lives in git as the HelmRelease above plus ClusterIssuer manifests. The DNS-01 token is not in those files in plaintext; it is a SOPS-encrypted Secret Flux decrypts on the cluster.

Grafana followed the same path. I first ran it in Docker Compose for .NET metrics . The homelab copy now sits in the monitoring namespace, owned by Flux, with dashboards as ConfigMaps in the same repo. Compose taught me the product; GitOps is how it stays installed when I am not watching.

This blog is in the picture too, just not as a website on the cluster. Production is still Azure Static Web Apps. What Flux does provision for this repo is a pool of Actions Runner Controller runners labelled k8s, so GitHub Actions can build on the homelab instead of burning hosted minutes. The RunnerDeployment is YAML in that private platform repo. The workflows stay in this git repo. That is the split in miniature.

Secrets in git, not in chat

Platform secrets are *.enc.yaml files encrypted with SOPS and age . Flux has a sops-age Secret in flux-system (created once, not committed) and Kustomizations that need secrets set decryption.provider: sops.

What is in git: Cloudflare DNS-01, the ARC GitHub token, Grafana admin, registry pull secrets, tunnel token. What is not: the age private key. If you clone that private platform repo you get ciphertext and the public key in .sops.yaml. That is enough to add a secret if you have the private key locally; it is not enough to read the live ones.

This is not Azure Key Vault. A homelab cluster does not need a cloud HSM to stop me committing a PAT. It needs encryption at rest in git and a bootstrap secret that never hits GitHub. The repo documents how SOPS and age are wired up.

What Flux does not own

I keep an ownership map in that private platform repo because GitOps fails the moment two systems apply the same object. Deciding who is allowed to apply has been more useful than any controller version pin. The short version:

Owner	Examples
This repo (Flux)	Namespaces, MetalLB, cert-manager, Traefik, ARC, Zot, cloudflared, monitoring
App git + CI	Helm releases in `develop` / `main` / `test` (blog chart, TrekRanks, SQL, …)
k3s / the node	CoreDNS, local-path, metrics-server, disable bundled Traefik

Several apps still deploy from Azure DevOps. That is fine. It is push CI, and Flux will not “fix” a Deployment it does not declare. If an old pipeline and a HelmRelease both think they own Grafana, they will fight. I moved monitoring into Flux on purpose so there is one owner.

k3s itself is not GitOps in this repo either. Node join, versions, and “do not run the bundled Traefik” are documented and applied on the hosts. Flux cannot bootstrap the thing that runs Flux.

In-cluster Renovate is a small extra: it opens image-bump PRs against that private platform repo. Upgrades become git history too, not SSH-and-hope. One note on Renovate, the Renovate package itself is very noisy, with multiple update PRs raised per day. I have chosen to automerge these, but you may want to consider skipping this package or updating on a schedule.

I would not start a new cluster by SSHing in and applying twenty manifests. Ingress, certificates, runners, and monitoring are shared, so they belong in git from the start. I would still start a new app with a pipeline and a Helm chart in that repo — Flux HelmRelease is how those charts get onto the cluster, not a replacement for packaging.

I have not moved every Helm chart into Flux, and I am not pretending that is a moral failing. GitOps earned its place here by making the platform dull. Dull is the goal.

If you run Kubernetes at home — or you are weighing GitOps against push CI — how do you split platform from apps? Full pull, pipelines only, or a hybrid like mine? I would be interested to hear what works for you in the comments.

If this is your first step on the same path, these posts are where I started: learning Kubernetes , deploying with Helm , and Let’s Encrypt on the cluster . For a monthly email when I publish something new, subscribe to the newsletter .

Pairing with AI in VS Code and Cursor

funkysi1701@gmail.com (funkysi1701) — Fri, 07 Aug 2026 12:00:00 +0000

On a lot of days my pair programmer is not a person. It is Copilot finishing a method, or Cursor proposing a multi-file edit I still have to own.

Back in April I covered how I use ChatGPT, Cursor, and Copilot on side projects . That was mostly about which tool I reach for. Here I want to talk about what that looks like when the code is .NET—C#, Blazor, Azure Functions—and I am working in VS Code or Cursor.

I am not claiming a universal workflow. These are habits that have helped me in 2026.

A thin tools map (so we can move on)

I still use the same three buckets. The only change is which bucket I reach for when the stack is .NET-heavy.

Situation	What I reach for
Framing a design question or learning path	ChatGPT (browser)
Multi-file change across a solution	Cursor
Finish this method / test / YAML stanza	GitHub Copilot in the editor
“Build AI into the product”	Separate concern — see Using AI with .NET and Semantic Kernel

If you already read the April post, you can skim this table and skip ahead. The interesting part is not the brand names; it is what happens after a suggestion appears.

For vocabulary (RAG, LLM, Copilot, and friends), Common AI and Copilot Terms is still a useful glossary.

Scenario: unfamiliar code that is still “mine”

Episode Atlas grew the way hobby apps do: Blazor on the front, Azure Functions and Cosmos DB behind, enough moving parts that I forget my own choices. When I come back after a few weeks, I do not want a greenfield tutorial from a chat window. I want something that has seen the repo.

In Cursor I ask questions like “where does per-user progress get written?” or “what breaks if this Cosmos query assumes a different partition key?” The useful answers cite my folders and types. The useless ones invent a service layer I never wrote.

What I do next matters more than the first reply:

Open the files it named and confirm they are the real path.
Diff any proposed edit against how neighbouring code already looks.
Run dotnet build (and the bit of the app I touched) before I trust it.

The productivity win is not that the model “knows Episode Atlas.” It is that I spend less time remapping a codebase I already wrote.

Scenario: boring glue that still has to be correct

This blog is Hugo plus Azure Static Web Apps, with GitHub Actions and a pile of Node/Python checks. A lot of the work is glue: a layout partial, a workflow step, a Playwright selector after a theme tweak. Copilot is often enough when I already know the shape—finish the next YAML key, sketch a test that matches the one above.

Cursor earns its keep when the change spans files: “update this partial and the smoke test that asserts the heading,” or “align the SWA config check with what CI runs.” Those are exactly the edits where an incomplete suggestion is worse than no suggestion—half-applied config fails in ways that waste an evening.

On Blazor and Functions work the same pattern shows up as DTOs, mapping, and tests. Copilot is fast at the third similar test. Cursor is better when the DTO, the endpoint, and the client all need to move together.

Scenario: debugging when the model is too confident

I have let an assistant send me on a wild goose chase: wrong package version, an API that never existed, a “fix” that compiled and still left the bug. A human pair who is sure and wrong is more dangerous than one who says “I am guessing.”

When something fails, I try to feed the model the error text and a failing test, not a vague description of what I think is wrong. If the first patch does not change the symptom, I stop re-prompting the same story. I read the stack, check docs, or bisect—same as I would without AI.

Side projects are a forgiving place to learn that discipline. Production systems are not. Secrets, customer data, and employer code stay out of tools unless policy clearly allows them; I wrote about that boundary in the side projects post and I still follow it.

Guardrails that actually saved me time

These are the practices that keep AI pairing from becoming AI babysitting:

Read every diff you did not type. Especially NuGet names, HTTP routes, auth, and anything touching data.
Prefer project conventions over “cleaner” internet defaults. If my solution uses one DI style, I reject the rewrite that introduces another for a one-line fix.
Verify against official docs when the call looks unfamiliar. Models still hallucinate plausible APIs.
Keep the human review bar. I treat agent output like a junior’s pull request: helpful when it is right, never something I merge on trust alone.
Match depth of context to the task. Do not paste half a solution into a browser chat for a one-line rename; do not ask inline Copilot to redesign a Functions + Cosmos flow.

What “productivity” has meant for me

I am faster at first drafts and at navigating code I have not opened in a month. I am not faster at skipping judgment. If anything, the cost of a bad accept is higher because the broken change can look polished.

That lines up with the longer argument in AI Won’t Replace Developers, But It Will Redefine Us : the work shifts toward directing, reviewing, and verifying. I see that every time I open Cursor or Copilot on Episode Atlas, this blog, or whichever .NET side project I am tinkering with that week.

If you are doing similar work in C# or Blazor, leave a comment and tell me which tool you reach for first—and what you still refuse to hand to an assistant. I am always curious how other people draw that line.

HTTP QUERY: requests with a body

funkysi1701@gmail.com (funkysi1701) — Tue, 14 Jul 2026 07:30:00 +0000

For years, API designers have had an awkward choice when a search got too complex for a URL. Stuff it into a GET query string and hit practical URI length limits, or send a body with POST and pretend a read-only filter is a write. Neither option felt right.

In June 2026 the IETF published RFC 10008 , which defines QUERY — a new HTTP method that is safe and idempotent like GET, but carries request content like POST. That long-standing gap finally has a standard answer.

The problem QUERY solves

GET is the right semantic for “please return something, and I am not asking you to change state.” It is safe, idempotent, and cacheable. The catch is where the input lives: in the URI. Complex filters, GraphQL-style documents, Elasticsearch queries, or large multi-field search payloads do not always fit comfortably in a URL. RFC 9110 suggests supporting request targets of at least 8,000 octets, but browsers, proxies, and gateways vary — and overflowing those limits is a practical failure, not a theoretical one.

URI length is not the only issue. Request URIs — including query-string filters — are far more likely to appear in access logs, browser history, and bookmarks than request bodies. If your search payload contains personal data or other sensitive filters (think GDPR and PII), stuffing it into a GET URL is often a compliance headache. That is one reason many teams already use POST /search: the body is less exposed in everyday logging.

POST accepts a body with a clear media type, which is perfect for structured input. The catch is what the rest of the HTTP stack is allowed to assume. HTTP treats POST as potentially unsafe and non-idempotent: a particular search endpoint can be a pure read in practice, but intermediaries cannot tell that from the method alone. They cannot safely auto-retry a failed POST the way they can a GET, and shared caches cannot treat it as a normal repeatable read. Tooling that assumes “POST means mutate” often groups a catalogue search with create/update traffic — culturally understandable, even when your handler never writes.

People sometimes tried GET with a body. RFC 9110 is blunt about that: content on a GET has no generally defined semantics, must not change the meaning of the request, and some implementations reject it because of request-smuggling concerns. That was never the answer.

QUERY is the method that says what we meant all along: process this enclosed content as a query, safely and idempotently, and return the result.

What RFC 10008 actually defines

From the abstract:

A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing.

Compared with GET, you are not asking for a representation of the target URI by itself. You are asking the target resource to run a query within its scope, using the request body and Content-Type to define that query. Servers must fail the request if Content-Type is missing or inconsistent with the content.

Key properties:

Property	Meaning for QUERY
Safe	The client does not request or expect a state change on the target resource
Idempotent	The same request can be retried after a connection failure
Cacheable	Successful responses may be stored and reused for subsequent QUERY requests
Body required for the query	The query lives in the content, not forced into the URI

Safe here is the HTTP meaning: the client is not asking to change the target resource (for example /api/products). That does not ban every side effect on the planet. Your server can still increment metrics, write an audit row, or — as the RFC allows — create temporary resources behind Location / Content-Location so results can be fetched again with GET. What intermediaries can assume is that QUERY is a read against the resource you addressed, not a create or update of it.

Idempotent means repeating the same request does not cause additional side effects beyond what a single successful attempt would cause. If the connection drops after you send a QUERY, a client or proxy can send it again without worrying that the second attempt will “do something twice” — unlike a non-idempotent POST that might create two orders if retried. It does not mean the response is frozen forever, and it is not the same as “cache forever.” Like GET, two identical QUERY calls can return different results if the underlying catalogue changed between them.

A 200 OK means the query was processed successfully and the results are in the response content. That matches how people already think about search endpoints — now with HTTP semantics that intermediaries can trust.

How it compares to GET and POST

	GET	QUERY	POST (as a “search”)
Request body for the query	No (undefined)	Yes	Yes
Safe (assumed by intermediaries)	Yes	Yes	Not assumed
Idempotent (assumed by intermediaries)	Yes	Yes	Not assumed
Typically cacheable as a read	Yes	Yes	Not assumed
Fits large / structured input	Poorly (URI limits)	Yes	Yes
Keeps filters out of the URI (logs / bookmarks)	No	Yes	Yes
Auto-retry after failure	Safe	Safe	Risky

You still use GET when the URI alone identifies what you want — and when you are comfortable with that URI being logged. You still use POST when you are creating or changing something, or when you need a body today and cannot yet rely on QUERY end to end. QUERY is for the awkward middle: read-only operations whose input belongs in a body, with semantics intermediaries can trust.

Caching, Location, and Accept-Query

Caching QUERY is a bit more work than caching GET, because the cache key must incorporate the request content (and related metadata). Some caches may normalise insignificant differences when building that key; clients that care can send Cache-Control: no-transform as advisory guidance.

The RFC also gives servers a way to hand clients a simpler follow-up:

Content-Location — a URI for a resource that holds the results of this query (temporary storage of what you just got).
Location — a URI for an equivalent resource that repeats the same query via GET, without resending the body.

That last point matters for CDNs and clients that are still catching up: after the first QUERY, subsequent hits can become ordinary GETs against a stored-query URI.

Discovery uses the new Accept-Query response field. A resource can advertise which query media types it understands, for example:

Accept-Query: application/json, application/sql

If you send an unsupported type, expect 415 Unsupported Media Type, and you may use Accept-Query (or Accept on error responses) to learn what to try next.

CORS and security notes

QUERY is not a CORS-safelisted method. Browser fetch calls will trigger a preflight OPTIONS check, the same way PUT or DELETE do. That is intentional: you do not want a body-carrying cross-origin method sliding past CORS just because it is “read-like.”

Putting filters in the QUERY body already helps versus a fat GET query string — less sensitive material in URIs that get logged or bookmarked. That benefit disappears if you then mint temporary Location or Content-Location URIs that echo those filters into the path or query. The RFC warns those URIs should not include sensitive portions of the original request content.

Using QUERY with ASP.NET Core

You do not need to wait for .NET 11 to try QUERY on the server. ASP.NET Core routing already accepts arbitrary method strings via MapMethods, and recent releases expose HttpMethods.Query (with HttpMethods.IsQuery) so you do not have to sprinkle the literal "QUERY" everywhere:

app.MapMethods("/api/products/search", [HttpMethods.Query], (ProductSearchRequest request) =>
{
 var results = ProductCatalogue.Search(request);
 return TypedResults.Ok(results);
});

A thin helper keeps call sites readable:

public static class HttpQueryExtensions
{
 public static IEndpointConventionBuilder MapQuery(
 this IEndpointRouteBuilder endpoints,
 string pattern,
 Delegate handler) =>
 endpoints.MapMethods(pattern, [HttpMethods.Query], handler);
}

What landed later is OpenAPI documentation. QUERY became a first-class Path Item operation in OpenAPI 3.2. In .NET 11, ASP.NET Core’s document generator recognises QUERY when you opt into that version — so Swagger / client generators see a proper query operation instead of an oddball method string:

builder.Services.AddOpenApi(options =>
{
 options.OpenApiVersion = OpenApiSpecVersion.OpenApi3_2;
});

With OpenAPI 3.2, the operation appears as a sibling of get / post. On older document versions, generators may fall back to an extension such as x-oai-additionalOperations so the endpoint is not silently dropped. Until you are on that stack, you can still ship QUERY endpoints and document them by hand if needed.

Clients can call it with curl once the server understands the verb:

curl -X QUERY https://api.example.com/api/products/search \
 -H "Content-Type: application/json" \
 -d '{"category":"laptops","minPrice":500,"tags":["ultrabook","16gb"]}'

What to watch for in the real world

Standards land before the entire ecosystem catches up. Worth checking before you announce QUERY as your public search API:

Proxies, API gateways, and WAFs — some still allow-list only a handful of methods.
Browser and CDN behaviour — caching QUERY responses is more complex than GET; temporary Location URIs help.
Client libraries and OpenAPI codegen — support is improving, but pin versions carefully.
Logs and analytics — make sure QUERY is counted as a read, not lumped in with mutating POSTs.

For service-to-service APIs under your control, QUERY is already useful. For public browser-facing APIs, validate your edge stack and CORS setup first.

Why this matters

HTTP methods are how we communicate intent to every hop between the client and your app. When intent and method disagree — a read that intermediaries cannot assume from POST, or a body bolted onto GET — caches, retries, and security tooling all have to guess.

QUERY closes that gap with a small, carefully designed verb: safe, idempotent, cacheable, and allowed to carry a body. After more than a decade of drafts, RFC 10008 makes that contract official. If you maintain search or filter endpoints that never belonged in a URI, it is time to start planning for QUERY — especially on service-to-service paths you control, before you bet a public browser API on every gateway in the path understanding the verb.

.NET 5 to 10: features per release

funkysi1701@gmail.com (funkysi1701) — Mon, 29 Jun 2026 18:00:00 +0000

Every November, .NET Conf brings a new major release of .NET. If you have been building on the platform since the early 2020s, you have watched the ecosystem move from “.NET Core” to a single, unified .NET — and pick up minimal APIs, Native AOT, Blazor full stack, Aspire, and a steady stream of C# language improvements along the way.

This post is a guided tour of what landed in each major version from .NET 5 through .NET 10. It is not exhaustive — Microsoft ships hundreds of changes per release — but it should help you remember which version introduced what, and where to dig deeper.

Version	Released	Support type	C# version	Status (June 2026)
.NET 5	Nov 2020	STS (18 months)	C# 9	End of support
.NET 6	Nov 2021	LTS (3 years)	C# 10	End of support
.NET 7	Nov 2022	STS (18 months)	C# 11	End of support
.NET 8	Nov 2023	LTS (3 years)	C# 12	Supported
.NET 9	Nov 2024	STS (2 years)	C# 13	Supported
.NET 10	Nov 2025	LTS (3 years)	C# 14	Current LTS
.NET 11	Nov 2026	Preview	C# 15	Preview Until Nov 2026 then STS

For the full release schedule and patch versions, see the official .NET releases documentation.

.NET 5 — November 2020

.NET 5 was the first release after the “Core” branding was dropped. Version 4.x was skipped deliberately so nobody confused it with .NET Framework 4.x. The message was clear: this is the main implementation of .NET going forward, not a side project.

Platform and runtime

Unified vision — one BCL and runtime targeting cloud, desktop, web, mobile, and IoT (the full unification completed in .NET 6).
Single-file applications and improved app trimming for smaller deployments.
ClickOnce publishing for .NET (Windows).
ARM64 support on Windows.
Performance work across the runtime, GC, and networking stack.

C# 9

C# 9 shipped alongside .NET 5 and brought several features that are now everyday tools:

Records — reference types with value-based equality and with expressions for non-destructive mutation.
Init-only setters — immutable object initialisation without verbose constructors.
Top-level statements — less boilerplate in small console apps.
Pattern matching — relational patterns (>, <, and, or, not) and improved switch expressions.
Source generators — compile-time code generation (the foundation for later JSON and logging generators).

Libraries and frameworks

EF Core 5 — split queries, table-per-entity (TPE) mapping, and Cosmos DB improvements.
ASP.NET Core in the 5.x line — gRPC improvements, HTTP/2 and HTTP/3 groundwork, and Blazor WebAssembly performance gains.
System.Text.Json — constructor and parameterised constructor support, [JsonIgnore] on properties, and better options for ignoring cycles.

.NET 5 reached end of support in May 2022. If you still have projects on it, plan an upgrade — there are no security patches.

.NET 6 — November 2021 (LTS)

.NET 6 delivered on the unification promise: one SDK, one base class library, and one runtime across mobile, desktop, IoT, and cloud. It was an LTS release and became the baseline many teams standardised on.

Developer experience

Hot reload in Visual Studio 2022 and dotnet watch — edit code and see changes without a full restart.
Minimal APIs — build HTTP APIs with far less ceremony than traditional controllers.
SDK workloads — optional components (MAUI, Blazor WebAssembly AOT, and others) install via dotnet workload instead of bloating the default SDK.
Project templates modernised — top-level statements, file-scoped namespaces, nullable reference types, and async Main in new projects.

C# 10

global using directives
File-scoped namespaces
Record structs
Improved interpolated strings and constant interpolated strings
AsyncMethodBuilder attribute for custom async method builders

Runtime and libraries

DateOnly and TimeOnly — separate date and time types without carrying a full DateTime.
PriorityQueue<TElement, TPriority> — a built-in min-heap.
System.Text.Json source generator, writeable JsonNode DOM, and IAsyncEnumerable serialisation.
HTTP/3 preview support via QUIC.
OpenTelemetry metrics APIs in System.Diagnostics.Metrics.
FileStream rewrite for better async performance on Windows.
Arm64 support for macOS (“Apple Silicon”) and Windows, with side-by-side x64 and Arm64 installs.

ASP.NET Core 6

Minimal APIs as a first-class style for microservices.
Blazor components renderable from JavaScript; AOT compilation for Blazor WebAssembly.
Improved gRPC and SignalR performance.

.NET MAUI

.NET Multi-platform App UI arrived in preview with .NET 6 — one codebase for Android, iOS, macOS, and Windows native apps. GA followed in 2022.

.NET 6 LTS ended in November 2024.

.NET 7 — November 2022

.NET 7 was a standard-term support release focused heavily on performance, cloud-native patterns, and polishing the developer experience. I wrote about upgrading to .NET 7 at the time — mostly smooth, with a few surprises around AutoMapper and EF Core triggers.

C# 11

Raw string literals — multi-line strings without escape-character pain.
required members — enforce initialisation at compile time.
Generic math — static abstract interface members for numeric generics.
List patterns — if (list is [var first, .., var last]).
UTF-8 string literals — u8 suffix for byte-oriented APIs.

ASP.NET Core 7

Rate limiting middleware — built-in protection against abuse.
Output caching — cache entire responses at the framework level.
Minimal API improvements — route groups, typed results, and filters.
Native AOT for console apps — smaller, faster-starting binaries (ASP.NET Core AOT came in .NET 8).

Performance and tooling

Continued JIT and GC improvements; Native AOT publishing matured.
Regex source generator for compile-time pattern compilation.
Library multi-targeting and package validation tooling for NuGet authors.

.NET 7 reached end of support in May 2024.

.NET 8 — November 2023 (LTS)

.NET 8 is the current-generation LTS baseline for many production workloads (supported until November 2026). It is the release where cloud-native tooling, Native AOT for web apps, and modern C# really clicked together.

C# 12

Primary constructors — declare constructor parameters on the type declaration.
Collection expressions — [1, 2, 3] syntax for arrays, spans, and lists.
Alias any type — using Point = (int X, int Y);
Default lambda parameters — optional parameters in lambdas.

ASP.NET Core 8

Blazor full stack — server-side rendering, streaming rendering, and enhanced interactivity models in one framework.
Native AOT for ASP.NET Core — ahead-of-time compilation for web workloads.
Keyed dependency injection — register and resolve multiple implementations of the same interface by key.
Frozen collections — optimised read-only collections for hot paths.
TimeProvider — abstract time for testable code.

.NET Aspire (now just called Aspire)

.NET Aspire launched in preview with .NET 8 — an opinionated stack for observable, distributed applications. AppHost orchestrates dependencies; ServiceDefaults wire up OpenTelemetry, health checks, and resilience. I have been using it for local microservice development and it removes a lot of port-and-connection-string drudgery. In 2025 .Net Aspire was rebranded to Aspire and version 13 was released (don’t ask why 13, but I believe it was so it was no longer tied to .NET releases)

Other highlights

EF Core 8 — complex types, primitive collections, JSON column mapping, HierarchyId.
NuGet Audit — warnings when packages have known vulnerabilities.
Windows Forms and WPF improvements — DPI, data binding, and hardware acceleration.
Source generators for COM interop and configuration binding.

.NET 9 — November 2024

.NET 9 continued the annual cadence with performance, AI integration, and polish across the stack. I covered several highlights in my .NET 9 post when it shipped.

C# 13

params collections — params works with Span<T>, ReadOnlySpan<T>, and collection types beyond arrays.
lock on System.Object — the lock statement can use more types safely.
Partial properties and indexers — split declarations across files.
Escape sequence \e for the ESC character.

Platform and libraries

Performance — runtime, GC, and JIT improvements across the board; the team publishes detailed benchmark posts each release.
AI abstractions — Microsoft.Extensions.AI packages unify access to language models and embeddings from different providers.
NuGet Audit defaults to reporting transitive dependency vulnerabilities (opt back to direct-only with <NuGetAuditMode>direct</NuGetAuditMode>).
OpenTelemetry enhancements and better observability defaults.

ASP.NET Core 9 and Blazor

MapStaticAssets() — fingerprinted, cache-friendly static files replace UseStaticFiles() for Blazor and modern web apps.
Blazor component state persistence, improved form handling, and better WebAssembly performance.
.NET Aspire 9 — dashboard improvements, deployment tooling, and more community integrations.

.NET 9 is standard-term support until November 2026.

.NET 10 — November 2025 (LTS)

.NET 10 is the current LTS release (supported until November 2028). If you are choosing a version for a new project in 2026, this is the long-term bet.

C# 14

Field-backed properties — use the field keyword when you outgrow auto-properties.
nameof for unbound generics — e.g. nameof(List<>).
Implicit Span<T> conversions — less ceremony at API boundaries.
ref/out/in in lambdas without explicit parameter types.
Extension blocks — static extension methods and properties in a dedicated syntax.
Null-conditional assignment (?.=) and user-defined compound assignment operators.

Runtime and libraries

JIT improvements — better inlining, devirtualisation, and loop inversion.
AVX10.2 support for SIMD workloads.
Native AOT enhancements and improved struct argument code generation.
JSON — stricter serialisation options, PipeReader support, duplicate property handling.
Post-quantum cryptography — expanded ML-DSA and related APIs.
WebSocketStream — simpler WebSocket usage; TLS 1.3 on macOS clients.

SDK and tooling

dotnet test integrates Microsoft.Testing.Platform.
Container images from console apps without a separate Dockerfile in simple scenarios.
dotnet tool exec for one-shot tool runs.
Native shell tab-completion scripts for the CLI.

ASP.NET Core 10 and Blazor

Blazor WebAssembly preloading and automatic memory pool eviction.
Passkey support for ASP.NET Core Identity.
OpenAPI and minimal API improvements.

One breaking change caught me when upgrading a Blazor WebAssembly app: HttpClient response streaming is enabled by default, which broke synchronous Stream.Read calls in generated API clients. I wrote about the fix in Blazor and .NET 10 — either opt out with <WasmEnableStreamingResponse>false</WasmEnableStreamingResponse> or move to async reads.

EF Core 10, MAUI, and desktop

EF Core 10 — named query filters, Cosmos DB improvements, and LINQ performance work.
.NET MAUI 10 — multi-file MediaPicker, WebView interception, Android API 35/36 support.
Windows Forms and WPF — continued quality and Fluent-style updates.

How to choose a version in 2026

Scenario	Recommendation
New production app, minimise upgrade churn	.NET 10 LTS
Existing app on .NET 8 LTS with no pressing need	Stay on 8 until you are ready; both 8 and 10 are supported
Experimenting with the latest features	.NET 9 or .NET 10 — check STS/LTS dates
Legacy maintenance	Upgrade anything still on 5, 6, or 7 — they are all end-of-life

Microsoft’s guidance has shifted over the years: LTS releases (6, 8, 10) alternate with STS releases (5, 7, 9) on an annual November cadence. STS now lasts two years; LTS lasts three. Remember there is no difference in quality between a LTS and STS release, it is only the support window that is different.

Portfolio: Azure, AI, and dev tools

funkysi1701@gmail.com (funkysi1701) — Mon, 22 Jun 2026 21:00:00 +0000

Featured Projects

Three live Azure workloads I own end-to-end — CI/CD static delivery, AI-backed search on real content, and full-stack Blazor with actual users.

🔧 Episode Atlas

Track TV progress at scale with per-user state and cloud-backed data.

What it does: Per-user episode lists, “last watched” markers, and curated metadata links — so long-running franchises stay manageable.

Tech used: .NET Blazor, Azure Static Web Apps, Azure Functions, Cosmos DB, GitHub auth.

Why it’s impressive: Demonstrates scalable data modelling and cloud-first architecture for user-driven applications.

Deployed to AzureImplements authentication / APIs / caching

Outcome: Turned a personal “where was I in 900+ episodes?” problem into a maintainable multi-tenant pattern for identity, persistence, and UX for ongoing shows.

Links: episodeatlas.com

🔧 Semantic Search

AI-powered natural language search for discovering content beyond keywords.

What it does: Accepts conversational queries, retrieves meaningfully related posts, and surfaces them alongside the site’s JSON index search.

Tech used: .NET, Azure, Cosmos DB, OpenAI.

Why it’s impressive: Showcases practical LLM integration in .NET beyond basic chat interfaces.

Deployed to AzureDesigned with clean architecture

Outcome: Explored how vector-style retrieval and operational concerns (cost, latency, content freshness) fit next to a static Hugo site without compromising the authoring workflow.

Links: search.funkysi1701.com · linked from Search

🔧 Blog Platform

Technical blog on Azure with CI/CD—fast static pages, search, and comments without babysitting an app server.

What it does: Publishes posts, generates RSS and a JSON search index, integrates Giscus for discussions, and deploys on every merge.

Tech used: Hugo, GitHub Actions, Azure Static Web Apps, Giscus.

Why it’s impressive: Highlights modern static-first architecture with automated deployment pipelines.

Deployed to AzureCI/CD via GitHub Actions

Outcome: Demonstrates a production-shaped static pipeline — preview builds, repeatable deploys, and content-driven SEO — suitable as a reference architecture for docs and marketing sites.

Links: GitHub repository

💼 Cloud & Production Systems

The featured trio — Episode Atlas, this blog (Hugo on Azure), and Semantic Search (search.funkysi1701.com ) — is fully described in Featured Projects above and not repeated here. Below is the rest of the catalogue by category.

🔧 Thorne Pentecostal Church

Dependable church presence online—clear for newcomers, simple for volunteers to keep current.

What it does — Presents service times, beliefs, and visitor information with a simple structure so members and newcomers get answers in one place.

Tech used — HTML/CSS, Azure Static Web Apps.

Why it’s impressive — Demonstrates proportionate engineering: production-grade static hosting and clear information architecture for stakeholders who need reliability, not complexity.

Engineering signals: Deployed to Azure · CI/CD via GitHub Actions

Outcome: Delivered a first web presence focused on clarity and sustainability so non-developers can keep content current with minimal process overhead.

Links: Thorne Pentecostal Church

🛠 Tools & Utilities

🔧 Mandelbrot Generator

Interactive Mandelbrot exploration in the browser—smooth zoom, pure WASM, zero server-side rendering cost.

What it does — Renders the Mandelbrot set in the client with zoom for desktop and mobile, demonstrating CPU-bound UI work in WASM.

Tech used — .NET Blazor WebAssembly, Azure Static Web Apps.

Why it’s impressive — Demonstrates client-side compute discipline in Blazor WASM: rich, interactive UI with predictable cost because heavy work never hits the server.

Engineering signals: Deployed to Azure · Designed with clean architecture

Outcome: Built the tool to stress-test interactive Blazor WASM performance and touch UX patterns — a small codebase that still informs decisions about heavier client-side workloads.

Links: Mandelbrot Generator

💡 Ongoing exploration

Areas I keep hands-on with outside these shipped projects:

.NET Aspire — Cloud-native composition and local dev parity
Kubernetes — Orchestration and service boundaries
Elasticsearch — Search and analytics stacks
Azure Functions — Event-driven and serverless patterns
DevOps automation — CI/CD, IaC, and release hygiene

🤝 Collaborate With Me

Interested in collaborating on a project or discussing an idea?

Contact Me — Get in touch
GitHub — Code and experiments
LinkedIn — Connect professionally

📚 More resources

Tools & Resources — Recommended development tools
About Me — Background and experience
Blog Posts — Technical writing

Stay visible when made redundant

funkysi1701@gmail.com (funkysi1701) — Mon, 22 Jun 2026 12:00:00 +0000

Sadly earlier this year I was made redundant from my Software Developer job. Looking for a new job has not been fun, but a few common themes have emerged that I wanted to share. My hope is that these will help others to put things in place that may help them in the future.

Go to events and meet people

Something I have said often is that I enjoy going to events or conferences, like NDC London . These are great places to hear interesting talks, however that is not all they are good for. When you are at a conference or user group you are in a room full of like-minded people, each of them has unique experiences of being a software developer.

I am not very good at networking, I tend to stand in the corner or look awkward. However the more of these events I go to the better I get. Even if you only talk to one new person, that is one more person that you have spoken to. Want an advantage in meeting people? Volunteer. If you are a volunteer at an event, you will need to interact with other people, you may need to help direct people or assist one of the speakers. I have found this gives me a tiny bit more confidence to go and start speaking with someone or ask a question. Check out my Volunteering at NDC

User Groups often have the same people coming week after week, take advantage of this and be one of those people as well. You will start to get noticed and remembered even if you barely speak to anyone. For me I don’t have any really local user groups, however I am enjoying spending time at LeedsSharp .

If you genuinely had a good conversation with someone, find them on LinkedIn (or other social media) and send them a quick “It was nice chatting with you” message, this helps solidify the connection and helps you remember it.

So far during this job search I have met a recruiter who I would not have met without going to events, I have had jobs suggested to me to apply for that I would not have received otherwise, and one hiring manager is someone I have met previously at an event.

Build a blog and write about what you are learning

Almost every interview I have had has featured a comment about my blog. Now building a blog is for the long game. If you are unemployed now and don’t have a blog this won’t help you today, but if you start one and write about your experiences a few times a year it may help you tomorrow.

Back in 2014 when I started blogging I wasn’t even a Software Developer, I was just an IT guy at a small company and I wanted to write about some of the cool things I was learning. I kept writing, some years I wrote more than others, there have been some big gaps where I didn’t write anything. But somehow I keep coming back to it and writing a short piece about a new version of X or a conference I have been to, or a trend that is happening.

My blog is a great talking point during interviews, it helps me talk about why I think sharing information with the community is so important, what technology I have used over the years, some of the things I have learnt. My blog is featured at the top of my CV, and hiring managers have said they love it.

When redundancy hit, refreshing my CV and LinkedIn was one of the first practical jobs I did: update the headline, add recent projects, link to the blog and projects page, and make sure nothing still implied I was in my old role. Mundane, yes — but recruiters and hiring managers check both before they ever speak to you.

Today blogging isn’t the only way you can share your ideas. You could create videos, start a podcast, or have an active social media channel. I think the key is consistency, if you do a lot of it, it can easily look impressive if you look back after a few years. I personally prefer the well written blog post that I can refer back to, or search for again and again.

Some ideas to get you started (but there are loads more):

What have you learnt today/this week
What do you think about technology X
How do you solve problem Y
Compare two approaches to the same problem
Your experience at a conference or meetup

Build side projects

Side projects are a great way to learn. You can create a side project with the goal of learning technology X, you can also blog about your journey, what problems you solved and what insights you gained from it.

I personally feel there is a lot of value from getting your side project into the wild and letting users interact with it. Users will find your edge cases and ask questions you hadn’t considered. Publishing onto the internet is not free so consider your architecture carefully.

What you can deploy depends on what you build. For simple websites you can do a lot with Github Pages or Azure Static Web Apps. For example this website is built with Hugo which is deployed to an Azure Static Web App for pennies per month. If you have more complex needs small Linux VMs can be created for not a lot more.

I have learnt more from running a side project in production than I have the original idea. Things like DNS, SSL certificates, authentication, SEO are all very important for running a project but they would have been missed if you only ever ran your side project on localhost. I think having a rounded experience gives you a leg up when it comes to talking about your skills in an interview scenario.

If you are between jobs, it is tempting to start something ambitious — the next big SaaS idea, a full-stack app with every feature you can think of. I have fallen into that trap myself. A small project you actually finish is worth more than a grand one that never ships. Pick something you can complete in a weekend or two: a CLI tool, a simple API, a static site, even a useful script. You will have something concrete to talk about in interviews, and the momentum of finishing one thing often makes the next one easier.

My personal side projects can be found on my projects page. My inspiration came from various places, my hobbies and interests, problems I am facing or hear about, or just stuff I want to learn.

Keep learning deliberately

Between applications there is often more waiting than interviewing. Use that time deliberately: look at the job descriptions you are targeting, spot a recurring skill gap, and focus on one thing rather than trying to learn everything. I listen to development podcasts on the commute and dip into courses — I have written before about using Pluralsight while doing the washing up. You will not become an expert in a fortnight, but being able to talk about what you are learning still comes up in interviews. For more general advice, see Tips for Developing Yourself .

Closing thoughts

Being made redundant is not something I would wish on anyone, and I am still in the middle of finding my next role. Some days the job search feels slow and frustrating. On the better days, I remind myself that the things I have been doing for years — showing up at events, writing on this blog, shipping side projects, keeping my skills current — are not wasted effort. They are what give me stories to tell in interviews and reasons for people to remember my name.

None of this replaces the practical side of job hunting: refreshing your CV and LinkedIn, talking to recruiters, applying properly, and working through the admin that comes with redundancy. I went through redundancy before, in 2021, and wrote about recruiters, interview rounds, and the spreadsheet I used to keep track of it all in my 2021 story . Visibility helps people remember your name; applications still get you in the door.

But small, consistent habits compound. You do not need to do everything at once. Pick one thing you can start this month: a user group, a blog post, a course on something job ads keep asking for, or a side project you can actually finish — Start Here collects a short reading path if you want inspiration from this blog first. Community work counts too; running a Code Club taught me as much about showing up as any meetup talk. If you still have a job but worry the ground is shifting beneath you, even better — start now while you have a bit more energy and headspace.

If you are going through something similar, I hope this helps. If you have found other things that worked for you, I would love to hear about them in the comments.

If you have enjoyed this article and want a monthly email with my latest posts, please sign up for my newsletter . You can also get in touch if you have questions or just want to chat.

Episode Atlas: track your Trek rewatch

funkysi1701@gmail.com (funkysi1701) — Mon, 01 Jun 2026 12:00:00 +0000

If you have ever tried to rewatch Star Trek properly—not just dip into a favourite episode, but work through hundreds of instalments across multiple series—you will know the feeling. You pause Deep Space Nine for a few weeks, start something else, and suddenly you have no idea which episode you were on. Spreadsheets help for a while, then they do not. Notes on your phone get lost. Memory is unreliable when you jump between TNG, DS9, and whatever new show has just dropped.

That is the problem Episode Atlas exists to solve: search 900+ episodes and films, mark what you have watched, and always know what to watch next—without treating a rewatch like a project-management exercise.

Why I built it

I write about Star Trek on this blog from time to time—episode reviews, top-50 lists, thoughts on new series. The honest origin is simpler than that, though: I wanted a better way to track my own rewatches.

Generic TV trackers are fine if you watch a bit of everything. They are less helpful when you care about one enormous franchise with inconsistent stardates, films mixed in with series, and the urge to jump to “all the Borg episodes” rather than the next sequential instalment. Episode Atlas is deliberately narrow (if you can describe a database of over 900 episodes and films narrow!): all of Star Trek, in one place, with features shaped by how fans actually rewatch.

You can use Episode Atlas without creating an account. Search the catalogue, open episodes, browse collections, and spin the random picker—no signup required.

When you want your progress to stick, sign in and start your captain’s log. Mark episodes watched, and the site remembers where you left off across every series—even if you detour from DS9 to TNG and back again.

Your service record

Once you are logging watches, the homepage gives you a service record at a glance: how many of the 900+ episodes you have seen, your percentage through the franchise, and your current watch rank (from the early ranks up through Lieutenant, Commander, and beyond). The site shows how many more episodes you need for the next rank, so a long rewatch feels like progress rather than a vague “I think I am halfway through Voyager.”

You can also earn commendations and build an active duty streak—small nudges to keep visiting when you are in the middle of a serious rewatch. It is the same idea as a fitness streak, but for Star Trek.

Find any episode in seconds

Search is the front door. Most visits start with “I know roughly what I want” or “which episode was that again?” Filter by series and season to narrow the list; keywords catch titles and descriptions you only half remember. Every series and the films are in one catalogue.

Episode pages: context and next steps

Open any episode and you get what you need for a rewatch session: metadata, previous and next navigation within the series, season progress, and actions to mark the episode watched or jump to the suggested next episode. Your captain’s log ties it together—what you logged today, what you have already seen, and where to pick up when you return.

The flow the site describes is simple: search → open → mark watched → move on. Three gestures, no spreadsheet.

Collections when you want a mood, not a season

Collections answer a different question from search: “It is late; show me something good in this mood.” Each collection points at Borg stories, time-travel episodes, holodeck highlights, and similar lists—fan knowledge encoded as browseable sets, so you skip filler without digging through every season.

Random episode when you cannot decide

The random episode picker is for the evenings when you and the sofa have agreed on Star Trek but not on which Star Trek. One click, one suggestion—useful when commitment is the hard part.

How it compares to other sites

Episode Atlas is not trying to replace Memory Alpha for lore or IMDb for cast lists. It is built for progress: what you have watched, what rank you have earned, and what to play next. If you have ever bounced between a wiki, a ratings site, and a generic tracker and still not known where you were in DS9, this is the gap it fills.

Try it

episodeatlas.com — free to browse, sign in when you want your captain’s log saved. Search, mark your first episode, and see your rank climb.

How do you track long rewatches—spreadsheet, app, or pure memory? If you try Episode Atlas, I would genuinely like to know what works for you and what does not: features you love, gaps that annoy you, or anything that would make a rewatch easier. Leave a comment below, or use the feedback option on episodeatlas.com —both reach me, and both help shape what I build next.

AI on side projects: Cursor, Copilot

funkysi1701@gmail.com (funkysi1701) — Fri, 10 Apr 2026 12:00:00 +0000

There is no shortage of AI tools aimed at developers right now: chat assistants, IDE completions, agents that promise to run your tests, and new products every month with overlapping features. I am not going to argue which one is “best.” Instead, here is what I am actually using today on hobby code: ChatGPT for quick, low-context questions, Cursor when the work needs my repository in the loop, and GitHub Copilot for fast inline help while I type. That trio might change, but it reflects how I have learned to spend money and attention in 2026.

The through-line is simple: match the tool to how much context the problem needs. That stops me from dumping half a repo into a browser tab for a vague design question, or firing up an editor assistant when I only wanted a two-paragraph explanation of something I could read in the docs.

This is not a product review. It is a snapshot of how I work, using the projects on my projects page as concrete examples.

ChatGPT: questions that do not need my codebase

ChatGPT is still my first stop when I am trying to frame a problem. I use it when the answer is mostly portable knowledge: comparisons, vocabulary, “what should I read next,” and sanity checks that do not depend on the exact shape of my solution.

A few examples from things I have built:

This blog (Hugo + Azure Static Web Apps) — I might ask how people usually implement site search on static sites, or what the trade-offs are between generating a JSON index at build time versus leaning on a hosted search service. I am not looking for a drop-in patch to my theme; I want a short list of options so I can decide what fits a hobby budget.
Episode Atlas (Blazor, Functions, Cosmos DB) — good prompts sound like “patterns for tracking per-user progress through a large catalogue” or “when a tiny Blazor app might still justify a separate API layer.” Those are design conversations. The model does not need to see my episode containers to help me think about partition keys and stale data.
Mandelbrot Generator (Blazor WebAssembly) — I have used general chats to reason about why browser-side fractals feel CPU-bound, or what people typically do first when zoom performance tanks. Again, that is physics-of-the-platform stuff, not “line 40 of my render loop.”
Experiments — when I am poking at .NET Aspire , Kubernetes, Elasticsearch, or Azure Functions in my own time, ChatGPT is useful for learning paths: what to skim first, what terms I am mixing up, and what I am over-engineering for a toy.

Where ChatGPT falls down is predictable: anything that requires my wiring—pipeline YAML that only fails in CI, a Hugo partial that interacts with three others, a Blazor component that only breaks after publish. For that, context wins.

Cursor: when the answer is in the repo

Cursor (or any “chat with your codebase” style editor) is where I go when I need consistency across files and diff-shaped output. Side projects accumulate small decisions—naming, folder layout, how strict nullability is—and the model only respects those if it can see them.

Typical jobs:

Blog platform — adjusting a Hugo layout or partial, fixing warnings after a Hugo upgrade, or tweaking GitHub Actions / Azure Pipelines so the build still emits RSS and the JSON search index. Those changes are boring, fiddly, and easy to get subtly wrong if you guess from memory.
Episode Atlas — refactoring a Blazor page, aligning a Function endpoint with what the client expects, or tightening a Cosmos query once I know the access pattern. Here I want suggestions that match my project structure, not a generic sample from the internet.
Mandelbrot — iterating on rendering code where small mistakes show up as wrong colours or runaway iterations. Having the file in context beats describing the algorithm in chat.
Thorne Pentecostal Church site — simple HTML and CSS still benefit from repo context when the goal is “match what is already there” rather than “invent a new design system.”

I still treat Cursor as an accelerator, not an author. I read diffs, run the site or tests, and verify anything touching hosting or secrets. Side projects are a great place to learn when to trust an edit—and when the model confidently invents an API that never existed.

GitHub Copilot: the inline teammate

GitHub Copilot fills a different gap. Where Cursor often drives multi-file or exploratory edits, Copilot shines on local work: finishing a line, sketching a test, or repeating a pattern I have already established in the file.

I reach for it when:

I am writing repetitive Blazor markup or boilerplate DTOs.
I am editing YAML or shell and want a plausible next stanza that matches the block above.
I already know what I am doing and want speed more than architecture.

There is overlap between Copilot and Cursor in my workflow, and I am fine with that. If you only pay for one tool, you can still apply the same principle: shallow context versus deep context.

A quick decision table

Situation	What I use
“What are my options?” / compare approaches	ChatGPT
“Change this project to do X”	Cursor
“Finish this method / this pipeline step”	Copilot
Security, secrets, production incidents	Me, plus docs—AI optional and heavily verified

Boundaries, privacy, and verification

What I do not put in AI tools. I treat anything that could identify a person, anything contractual from work, and anything that unlocks production (passwords, API keys, connection strings, private certificates) as off-limits unless the product’s policy and my employer’s policy both say otherwise. For side projects that usually means personal repos only, secrets in environment variables or Key Vault—not in chat—and if I need help with a failing pipeline I redact resource names and paste error text, not the whole variable block. If you have a day job, your company’s acceptable-use rules beat anything you read in a blog post; when in doubt, use vendor docs and internal support channels instead of a model.

How I check output before it counts. I never merge a multi-file change on trust alone: I read the diff file by file, run hugo / dotnet build / whatever the project’s normal build is, and exercise the path I changed in the browser or with a quick manual test. If the assistant suggested a library call or HTTP API I do not recognise, I cross-check the official documentation or source before I rely on it—side projects are where I have been burned by plausible-but-wrong method names. For anything security-sensitive (auth callbacks, CORS, SQL, dependency upgrades), I assume the model is giving me a sketch and I still apply the same review I would give a junior’s pull request.

Learning paths are still verified. When I use ChatGPT to orient around Aspire, Kubernetes, or Elasticsearch, I use it to build a mental map and a reading list, then I confirm version-specific behaviour in Microsoft Learn, Kubernetes docs, or Elastic’s docs. The goal is to shorten where to look, not to skip looking.

Closing thought

AI tools have not replaced the fun of side projects for me. Projects like Episode Atlas exist because I wanted a better way to track Star Trek rewatches across hundreds of episodes; the Mandelbrot app exists because fractals are still cool; this blog exists because writing things down forces clarity. What has changed is how fast I can get through the glue work—if I pick the right assistant for the amount of context the task really needs.

If you are a developer experimenting with the same stack—.NET, static sites, Azure—how do you split tools today? I would be interested to hear what works for you in the comments.

AI will not replace us developers

funkysi1701@gmail.com (funkysi1701) — 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 London by 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 Programmer matters 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.

ACR vs ECR: Azure and AWS registries

funkysi1701@gmail.com (funkysi1701) — 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

funkysi1701@gmail.com (funkysi1701) — 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

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 CLI was 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 Rider team 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_Conferences for updates!

See you at NDC London 2027! 🚀

2025 in Review and Goals for 2026

funkysi1701@gmail.com (funkysi1701) — 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 parkrun and 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! 🚀

2026 on Funky Si's Blog (Dev)

GitOps with Flux on my k3s cluster

Pull, not push

How the repo is laid out

One change, end to end

Secrets in git, not in chat

What Flux does not own

Pairing with AI in VS Code and Cursor

A thin tools map (so we can move on)

Scenario: unfamiliar code that is still “mine”

Scenario: boring glue that still has to be correct

Scenario: debugging when the model is too confident

Guardrails that actually saved me time

What “productivity” has meant for me

HTTP QUERY: requests with a body

The problem QUERY solves

What RFC 10008 actually defines

How it compares to GET and POST

Caching, Location, and Accept-Query

CORS and security notes

Using QUERY with ASP.NET Core

What to watch for in the real world

Why this matters

.NET 5 to 10: features per release

.NET 5 — November 2020

Platform and runtime

C# 9

Libraries and frameworks

.NET 6 — November 2021 (LTS)

Developer experience

C# 10

Runtime and libraries

ASP.NET Core 6

.NET MAUI

.NET 7 — November 2022

C# 11

ASP.NET Core 7

Performance and tooling

.NET 8 — November 2023 (LTS)

C# 12

ASP.NET Core 8

.NET Aspire (now just called Aspire)

Other highlights

.NET 9 — November 2024

C# 13

Platform and libraries

ASP.NET Core 9 and Blazor

.NET 10 — November 2025 (LTS)

C# 14

Runtime and libraries

SDK and tooling

ASP.NET Core 10 and Blazor

EF Core 10, MAUI, and desktop

How to choose a version in 2026

Further reading

Official docs

On this blog

Portfolio: Azure, AI, and dev tools

Featured Projects

🔧 Episode Atlas

🔧 Semantic Search

🔧 Blog Platform

💼 Cloud & Production Systems

🔧 Thorne Pentecostal Church

🛠 Tools & Utilities

🔧 Mandelbrot Generator

💡 Ongoing exploration

🤝 Collaborate With Me

📚 More resources

Stay visible when made redundant

Go to events and meet people

Build a blog and write about what you are learning

Build side projects

Keep learning deliberately

Closing thoughts

Episode Atlas: track your Trek rewatch

Why I built it

Browse first, sign in to save

Your service record

Find any episode in seconds