Tony Edwards

Zurich JS took the roof off

Fri, 11 Sep 2026 00:00:00 +0000

Zurich. You rocked!

And nn a way most communities struggle to do after a few events. Let alone the first one.

Friday saw the inaugural ZurichJS conference happen in the Swiss capital, bringing together a handful of speakers from around the globe to educate and entertains hundreds of developers from central Europe and beyond. The crowd walked away with enough knowledge and insight into the depths of the JavaScript ecosystem to shape the next few months of development time.

But this is just the start.

It was the first large scale event from this community. But you wouldn’t have known it. The lineup was straight out of a A* conference. The level of polish exceeded even the biggest and most established community events of this ilk. Every touch point had a level of polish that we organisers would love to incorporate into our own gatherings, but fail to find the time for. And I’m sure the audience would agree for their interactions as well. Being trusted with one half of the hosting duties truly was an honor.

Zurich itself is a beautiful place, filled with friendly faces much like the event. As long as you don’t want to be singing the earworm that is baby shark late at night (I’m looking at you Salih 👀), you’ll have no problems as a stranger in the city. Great public transport combine with wonderful sightseeing opportunities, and people who will tolerate pigeon German with a smile on their face.

Its a wonderful culture to experience, and I learned a lot about from the stage and beyond:

3 minutes behind schedule is a much bigger thing to the Swiss than it is to most
The people are much less reserved than most audiences on the continent
Cheese is a way of life, not an ingredient

I’m fully on board with the latter 🧀

More importantly, the tech lessons dispensed from the stage are sure to have taken the rooms plans for the year ahead up a notch. With cutting edge CSS from Kevin Powell, deep debugging tips from Mark Erikson, and lessons in taste from Tejas Kumar to name a few of the sessions, we collectively walked away with knowledge you can’t simply summon from the depths of an LLM.

And that’s the whole point of conferences.

To learn what you didn’t know you needed to learn.

Whatever your training budget is for events is, invest it in this one and make the effort to take the trip. It was perfectly executed, with an abundance of friendly faces milling around the venue creating the buzz of a community that has been thirsting for something like this for a very long time.

Knowing the level of effort the organisers put into this one, the quality of talks they’ll look to curate again, and some spilled tea from Mummy Faris, the next edition is going to surpass this one by a long stretch.

That I’m sure of.

What I’m not so sure of is if we can surpass the noise level in the room at the end of the day. At 105db, it was litterally hazrdous to health.

Regardless, we will try.

Sorry to the audience if you walked away from the event with sore hands and throats from all the clapping and cheering. Consider it yet another contribution to your amazing community on the big day.

Awesome work Züri 🙌

Host photo by Alexander Brandt and noise warning photo by Tejas Kumar

Login with Passkeys in a .NET MAUI App

Sun, 23 Aug 2026 00:00:00 +0000

I’ve been digging through the .NET MAUI Preview 7 changes, and there’s one addition that deserves a bit more attention than a bullet point in some release notes.

.NET MAUI now has a cross-platform Passkeys API.

Not a wrapper around a web page. Not “open the browser, authenticate and come back”. It actually talks to the native passkey APIs on iOS, Android and Windows. Pleasingly, the API itself is tiny.

Passkeys.IsSupported
Passkeys.CreateAsync(...)
Passkeys.AssertAsync(...)

That’s pretty much the MAUI side of it.

Of course, anyone who’s implemented authentication before will immediately recognise the trap hiding in that sentence.

The client API might be tiny. Passkeys themselves are not.

So I went through the new MAUI sample and the accompanying ASP.NET Core server plus the API design to see what a real implementation actually looks like.

The good news is that the split is sensible. MAUI handles the awkward platform-specific bit. Your server handles the security-sensitive WebAuthn bit. That gives us something we can actually build with.

What MAUI is doing

The new API lives in:

using Microsoft.Maui.Authentication;

and is essentially a bridge between your server and the platform authenticator.

The overall registration flow looks like this:

MAUI app
   |
   | Ask server to begin registration
   v
Server
   |
   | WebAuthn creation options JSON
   v
MAUI Passkeys.CreateAsync()
   |
   | Native Face ID / fingerprint / PIN / Windows Hello UI
   v
Platform authenticator
   |
   | WebAuthn credential response
   v
MAUI app
   |
   | Send response to server
   v
Server verifies it and stores the passkey

Authentication is basically the same thing in reverse:

MAUI app
   |
   | Ask server to begin authentication
   v
Server
   |
   | WebAuthn request options JSON
   v
MAUI Passkeys.AssertAsync()
   |
   | Native authentication UI
   v
Platform authenticator
   |
   | Signed assertion
   v
MAUI app
   |
   | Send assertion to server
   v
Server verifies it and signs the user in

That JSON-in, JSON-out design is deliberate. MAUI doesn’t generate challenges, verify signatures or decide whether somebody should be allowed into your application. Nor should it.

The private key also stays with the platform authenticator. Your app is shuffling WebAuthn messages around, rather than becoming responsible for storing some exciting new authentication secret that we’ll all regret in six months.

Platform support

In Preview 7, the built-in implementation covers:

Android 14 / API 34+
iOS and iPadOS 16+
Mac Catalyst 16+
Windows 10 version 1903+

You can check that at runtime:

if (!Passkeys.IsSupported)
{
    // Show your normal login flow.
    return;
}

One important detail: IsSupported tells you that the OS has the necessary passkey support. It doesn’t tell you that you’ve configured everything correctly, as with other IsSupported properties.

Your app and your authentication domain still have to trust each other, which we’ll get to shortly.

Let’s actually implement it

I’m going to assume we already have:

a .NET MAUI application;
an HTTPS API, perhaps at https://auth.example.com;
users who can already authenticate;
some mechanism for issuing access/refresh tokens or sessions.

We’re adding passkeys to that rather than designing authentication from scratch. The MAUI sample uses ASP.NET Core Identity on its backend, so I’ll do the same here.

Step 1: configure the relying party on the server

The first thing your server needs to know is its relying-party ID.

If our authentication server is:

https://auth.example.com

then the RP ID would normally be:

auth.example.com

With ASP.NET Core Identity:

builder.Services.Configure<IdentityPasskeyOptions>(options =>
{
    options.ServerDomain = "auth.example.com";

    options.ValidateOrigin = context =>
    {
        var allowedOrigins = new[]
        {
            "https://auth.example.com",

            // Android's origin will also go here.
            "android:apk-key-hash:YOUR_APP_SIGNING_HASH"
        };

        return ValueTask.FromResult(
            allowedOrigins.Contains(context.Origin));
    };
});

That ValidateOrigin is worth noticing. A native application doesn’t have a browser page URL from which WebAuthn can derive its origin.

Apple effectively uses your associated HTTPS domain. Windows uses the RP HTTPS origin. Android identifies the application using an origin based on the hash of its signing certificate:

android:apk-key-hash:<base64url-sha256-signing-certificate>

The server therefore needs to accept the appropriate origin for each native application allowed to authenticate against it. You’ll also need the Identity schema capable of storing passkeys. The MAUI sample enables Identity schema version 3:

builder.Services.AddIdentityCore<ApplicationUser>(options =>
{
    options.Stores.SchemaVersion = IdentitySchemaVersions.Version3;
})
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddSignInManager();

Unlike the MAUI sample, your production database obviously shouldn’t be an in-memory SQLite database that disappears whenever somebody looks at the server funny. Use your normal persistent Identity store and migrations. Security practices are just as important with passkeys as they are with passwords.

Step 2: create the registration begin endpoint

A passkey normally gets added to an account that we already trust. So imagine somebody has logged into the app normally and tapped:

Add a passkey

The MAUI app first asks the server to start a registration ceremony.

app.MapPost("/passkeys/register/begin", async (
    HttpContext context,
    UserManager<ApplicationUser> userManager,
    SignInManager<ApplicationUser> signInManager) =>
{
    var user = await userManager.GetUserAsync(context.User);

    if (user is null)
        return Results.Unauthorized();

    var userId = await userManager.GetUserIdAsync(user);
    var userName =
        await userManager.GetUserNameAsync(user)
        ?? throw new InvalidOperationException("User has no username.");

    var optionsJson =
        await signInManager.MakePasskeyCreationOptionsAsync(
            new PasskeyUserEntity
            {
                Id = userId,
                Name = userName,
                DisplayName = userName
            });

    return Results.Content(
        optionsJson,
        "application/json");
})
.RequireAuthorization();

MakePasskeyCreationOptionsAsync() creates the standard WebAuthn PublicKeyCredentialCreationOptions that the authenticator needs. This contains things such as the challenge and relying-party details.

The important bit is that the server creates them. Don’t generate a challenge in your MAUI application and don’t try to manufacture this JSON yourself.

Step 3: ask MAUI to create the passkey

Back in the app:

using Microsoft.Maui.Authentication;
using System.Text;

public async Task CreatePasskeyAsync(
    CancellationToken cancellationToken = default)
{
    if (!Passkeys.IsSupported)
        throw new FeatureNotSupportedException(
            "Passkeys aren't supported on this device.");

    using var beginResponse =
        await httpClient.PostAsync(
            "/passkeys/register/begin",
            content: null,
            cancellationToken);

    beginResponse.EnsureSuccessStatusCode();

    var creationOptionsJson =
        await beginResponse.Content.ReadAsStringAsync(
            cancellationToken);

    var passkeyResponse =
        await Passkeys.CreateAsync(
            creationOptionsJson,
            cancellationToken);

    using var content = new StringContent(
        passkeyResponse.ToString(),
        Encoding.UTF8,
        "application/json");

    using var finishResponse =
        await httpClient.PostAsync(
            "/passkeys/register/finish",
            content,
            cancellationToken);

    finishResponse.EnsureSuccessStatusCode();
}

There’s one slightly subtle thing in there.

This:

passkeyResponse.ToString()

isn’t just a nice debugging representation of the response. It is the actual WebAuthn JSON that needs to go back to your server.

So don’t do this:

await httpClient.PostAsJsonAsync(
    "/passkeys/register/finish",
    passkeyResponse.ToString());

That would serialise your JSON string and leave your server with one big escaped JSON value. Send it as raw application/json. The MAUI API was deliberately designed so the result of CreateAsync() can effectively be passed straight back to the relying party.

At this point MAUI will invoke the platform UI.

Depending on the device, that’ll mean Face ID, Touch ID, fingerprint, PIN, Windows Hello or whatever authenticator the platform has available. There is no platform-specific code in our ViewModel, which is the point.

Step 4: verify and store the new passkey

Now we need /passkeys/register/finish.

The MAUI sample uses PerformPasskeyAttestationAsync() to validate the result:

app.MapPost("/passkeys/register/finish", async (
    HttpContext context,
    JsonElement credential,
    UserManager<ApplicationUser> userManager,
    SignInManager<ApplicationUser> signInManager) =>
{
    var user = await userManager.GetUserAsync(context.User);

    if (user is null)
        return Results.Unauthorized();

    var attestation =
        await signInManager.PerformPasskeyAttestationAsync(
            credential.GetRawText());

    if (!attestation.Succeeded)
    {
        return Results.BadRequest(new
        {
            error = attestation.Failure?.Message
        });
    }

    var userId = await userManager.GetUserIdAsync(user);

    if (!string.Equals(
        userId,
        attestation.UserEntity.Id,
        StringComparison.Ordinal))
    {
        return Results.BadRequest(
            "The passkey doesn't belong to the authenticated user.");
    }

    var result =
        await userManager.AddOrUpdatePasskeyAsync(
            user,
            attestation.Passkey);

    if (!result.Succeeded)
        return Results.BadRequest();

    return Results.Ok();
})
.RequireAuthorization();

There are two separate security checks happening here. First, Identity verifies the WebAuthn attestation. Then we’re making sure the identity represented by that ceremony matches the user who is currently authenticated.

Only after both of those things have happened do we store the credential. The stored record contains the public-key information needed to verify future assertions. The private key remains with the user’s authenticator.

Now we can get rid of the password. Or at least stop asking for it every five minutes.

Our login begin endpoint doesn’t even need a username:

app.MapPost("/passkeys/login/begin", async (
    SignInManager<ApplicationUser> signInManager) =>
{
    var optionsJson =
        await signInManager.MakePasskeyRequestOptionsAsync(
            user: null);

    return Results.Content(
        optionsJson,
        "application/json");
});

Passing null means we’re asking for a discoverable, username-less authentication.

The OS can show the user the passkeys available for this relying party and the credential itself gives the server enough information to work out which user is authenticating.

Your login screen can effectively become:

Sign in with a passkey

or

Sign in another way

rather than asking for an email address before we even know whether we need it.

Step 6: authenticate with the passkey in MAUI

The client side looks remarkably similar to registration.

public async Task<AuthTokens> SignInWithPasskeyAsync(
    CancellationToken cancellationToken = default)
{
    if (!Passkeys.IsSupported)
        throw new FeatureNotSupportedException(
            "Passkeys aren't supported on this device.");

    using var beginResponse =
        await httpClient.PostAsync(
            "/passkeys/login/begin",
            content: null,
            cancellationToken);

    beginResponse.EnsureSuccessStatusCode();

    var requestOptionsJson =
        await beginResponse.Content.ReadAsStringAsync(
            cancellationToken);

    var assertion =
        await Passkeys.AssertAsync(
            requestOptionsJson,
            cancellationToken);

    using var content = new StringContent(
        assertion.ToString(),
        Encoding.UTF8,
        "application/json");

    using var finishResponse =
        await httpClient.PostAsync(
            "/passkeys/login/finish",
            content,
            cancellationToken);

    finishResponse.EnsureSuccessStatusCode();

    return await finishResponse.Content
        .ReadFromJsonAsync<AuthTokens>(
            cancellationToken)
        ?? throw new InvalidOperationException(
            "The server didn't return authentication tokens.");
}

Again, AssertAsync() is where the native UI appears.

And again, the app doesn’t verify the result. It sends it back to the server.

Step 7: verify the assertion and issue your normal tokens

Here’s one place where I’d deliberately diverge from the MAUI sample.

The sample calls:

await signInManager.PasskeySignInAsync(...)

and uses an ASP.NET Core authentication cookie. That’s perfectly reasonable for a sample and also perfectly reasonable for a cookie-based web application. The PR itself points out that the sample’s cookie-based native authentication setup is there for convenience rather than being a recommendation for production mobile applications.

If our existing mobile API normally returns an access token and refresh token, I’d keep doing exactly that. ASP.NET Core Identity also exposes PerformPasskeyAssertionAsync(), which verifies the passkey without automatically creating the cookie-based login session.

That gives us something along these lines:

app.MapPost("/passkeys/login/finish", async (
    JsonElement credential,
    UserManager<ApplicationUser> userManager,
    SignInManager<ApplicationUser> signInManager,
    ITokenService tokenService) =>
{
    var assertion =
        await signInManager.PerformPasskeyAssertionAsync(
            credential.GetRawText());

    if (!assertion.Succeeded ||
        assertion.User is null ||
        assertion.Passkey is null)
    {
        return Results.Unauthorized();
    }

    // Persist any updated passkey data, including the
    // authenticator's updated signature counter.
    var updateResult =
        await userManager.AddOrUpdatePasskeyAsync(
            assertion.User,
            assertion.Passkey);

    if (!updateResult.Succeeded)
        return Results.BadRequest();

    // Run the same account/lockout/policy checks your
    // normal authentication flow performs here.

    var tokens =
        await tokenService.CreateTokensAsync(
            assertion.User);

    return Results.Ok(tokens);
});

That’s an important architectural point. Passkeys don’t need to replace your authentication system. They’re another way of proving who the user is. Once the server has successfully verified that proof, you can feed the resulting user into the same token/session machinery you already use.

ASP.NET Core’s lower-level assertion API is specifically available for cases where you need that extra control. It also requires you to persist the returned updated passkey information yourself.

One slightly annoying detail: keep the ceremony state

There is another bit in the sample that’s easy to overlook. The /begin and /finish calls belong to the same WebAuthn ceremony.

ASP.NET Core Identity stores temporary passkey state so that when the response comes back it can confirm it corresponds to the challenge that was originally generated.

The MAUI sample preserves that state using an HttpClient backed by a CookieContainer:

var handler = new HttpClientHandler
{
    CookieContainer = new CookieContainer(),
    UseCookies = true
};

var httpClient = new HttpClient(handler)
{
    BaseAddress = new Uri("https://auth.example.com/")
};

That doesn’t mean your application’s main authentication mechanism needs to use cookies. Your normal API requests can still use:

Authorization: Bearer ...

The cookie here can simply correlate the short-lived WebAuthn ceremony.

If your authentication infrastructure already has another mechanism for storing challenge state such as a server-side ceremony ID, you can use that instead. What matters is that /finish can securely recover the state created by the corresponding /begin.

Lose that and verification should fail.

Apple needs Associated Domains

We’re not quite done. This stuff deliberately won’t work just because you’ve pointed an app at a server. On Apple platforms, your application needs the Associated Domains entitlement:

<key>com.apple.developer.associated-domains</key>
<array>
    <string>webcredentials:auth.example.com</string>
</array>

And your server needs to expose:

https://auth.example.com/.well-known/apple-app-site-association

with something like:

{
  "webcredentials": {
    "apps": [
      "ABCDE12345.com.example.myapp"
    ]
  }
}

where the value is your:

<Team ID>.<Bundle ID>

The app must also be signed with a provisioning profile that includes Associated Domains. Apple then checks that the application’s entitlement and the domain’s association file agree before allowing the app to create or use a passkey for that domain.

Android needs Digital Asset Links

Android has a similar relationship. Your authentication domain needs:

https://auth.example.com/.well-known/assetlinks.json

containing the package and signing certificate allowed to use credentials for that domain:

[
  {
    "relation": [
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.myapp",
      "sha256_cert_fingerprints": [
        "AA:BB:CC:..."
      ]
    }
  }
]

The certificate fingerprint needs to be for the certificate actually signing your production application. Not your debug certificate.

That seems obvious when written down here. It’ll feel slightly less obvious when you’ve spent an afternoon wondering why the thing worked perfectly in development.

Also worth knowing: the MAUI implementation deliberately uses the OS-native Android Credential Manager path and doesn’t pull Google Play Services into Essentials. As a result, the built-in implementation starts at Android 14/API 34. Support for Android 9–13 can potentially be added by the application through the Play Services Credential Manager adapter, but MAUI doesn’t force that dependency on everybody.

A useful extra: keep the authentication local

There is one extra option in the new API that I quite like. Rather than using the convenient string overload:

await Passkeys.AssertAsync(requestOptionsJson);

you can construct the options yourself:

var options = new PasskeyRequestOptions(
    requestOptionsJson)
{
    PreferImmediatelyAvailable = true
};

var assertion =
    await Passkeys.AssertAsync(options);

PreferImmediatelyAvailable tells Android and Apple to only offer a credential that’s immediately available on this device rather than falling through into the cross-device flows involving QR codes or another nearby device.

If there isn’t one, the operation fails quickly.

I can see this being particularly useful when a passkey button is one option amongst several on a login screen and you don’t want pressing it to start an entire “find another device” adventure.

Handle cancellation properly

Passkey UI is also cancellable. I’d make sure your ViewModel doesn’t treat somebody closing Face ID as if the authentication server has exploded:

try
{
    await passkeyService.SignInWithPasskeyAsync(
        cancellationToken);
}
catch (TaskCanceledException)
{
    // The user cancelled. That's fine.
}
catch (FeatureNotSupportedException)
{
    // Fall back to your other login methods.
}
catch (ArgumentException ex)
{
    // Bad WebAuthn options from the server.
}
catch (InvalidOperationException ex)
{
    // No credential, association problem or
    // another platform ceremony failure.
}

MAUI deliberately normalises the platform-specific errors into normal .NET exception types, with TaskCanceledException representing both user and programmatic cancellation.

What I’d actually ship

Once you strip the sample plumbing away, the shape of this isn’t particularly frightening.

For registration:

Authenticated user
    ↓
POST /passkeys/register/begin
    ↓
Passkeys.CreateAsync()
    ↓
POST /passkeys/register/finish
    ↓
Server verifies + stores public credential

For authentication:

POST /passkeys/login/begin
    ↓
Passkeys.AssertAsync()
    ↓
POST /passkeys/login/finish
    ↓
Server verifies credential
    ↓
Existing access/refresh token flow

Then add the platform-domain association required by Apple and Android.

That’s it.

There is obviously security-sensitive machinery underneath all of this. WebAuthn challenges, signatures, attestation, credential IDs, origins, relying-party IDs and replay protection. . . but that’s precisely why I like the design.

The MAUI app isn’t expected to understand most of it.

It asks the server what the authenticator should do:

var options = await server.BeginPasskeyLoginAsync();

lets the operating system do it:

var response = await Passkeys.AssertAsync(options);

and asks the server whether the result is legitimate:

await server.FinishPasskeyLoginAsync(
    response.ToString());

That’s a pretty good abstraction. And perhaps more importantly, it means we can now put a genuinely native passkey login in a .NET MAUI application without writing separate integrations for AuthenticationServices, Android Credential Manager and Windows WebAuthn.

That’s the sort of Essentials API I like.

Small on the surface.

A frankly unreasonable amount of platform-specific faff underneath it.

And none of that faff needs to be in my my code.

Useful links

The implementation landed in .NET MAUI through PR #36837 — Passkeys (WebAuthn/FIDO2) Essentials API.

Microsoft has also published the full MAUI Passkeys sample README and the reference ASP.NET Core backend.

Recording Web Speech Synthesis

Sat, 08 Aug 2026 00:00:00 +0000

I usually remember that I need a recording of some synthesised speech shortly before giving each rendition of my Beats, Rhymes and Neural Nets talk.

By “shortly before”, I mean I’m sitting in a hotel room, playing speech through a browser and recording it as a voice note on my phone. I then have to transfer the file to my laptop over whatever the hotel considers Wi-Fi.

It’s not a distinguished workflow.

Given I’m trying to be a little more prepared for future talks, I decided to add recording directly to the app that goes with it. Type the line, choose a voice, press Speak and download the result.

That was the idea, anyway.

The awkward bit is that the Web Speech API’s speechSynthesis interface doesn’t give you an audio stream. You can ask it to speak, but you can’t take its output and pass it directly to MediaRecorder.

My first workaround appeared to succeed. Chrome produced a playable WebM file with a sensible duration and no errors.

But it was completely silent.

Why recording the Chrome tab didn’t work

I initially tried capturing the current tab’s audio with getDisplayMedia(). That seemed reasonable. The page starts the speech, the speech comes out of Chrome and Chrome records the tab.

Except that isn’t necessarily the route the audio takes.

Chrome voices commonly use the operating system’s speech engine. The page requests an utterance, but the resulting sound is produced outside the tab’s audio pipeline. Tab capture therefore records the tab perfectly while missing the voice I actually care about.

The solution was to record the operating system’s mixed audio through screen sharing, rather than recording only the Chrome tab.

Making speech synthesis awaitable

Before dealing with capture, I needed to know when an utterance had finished.

The normal speechSynthesis.speak() method starts speaking and returns immediately. Wrapping the utterance events in a Promise gives the recording code a clean boundary to work with:

export const speakAsync = (options) => {
  const utter = createUtterance(options);

  if (!utter) {
    return Promise.resolve();
  }

  return new Promise((resolve, reject) => {
    let settled = false;

    utter.onend = () => {
      if (settled) {
        return;
      }

      settled = true;
      resolve();
    };

    utter.onerror = (event) => {
      if (settled) {
        return;
      }

      settled = true;

      const reason = event?.error || 'synthesis-failed';
      const error = new Error(
        `Speech synthesis failed: ${reason}`
      );

      error.name =
        reason === 'canceled' || reason === 'interrupted'
          ? 'SpeechCancelledError'
          : 'SpeechSynthesisError';

      reject(error);
    };

    window.speechSynthesis.cancel();
    window.speechSynthesis.speak(utter);
  });
};

The important part is that the recording flow can now do this:

startRecording();
await speakAsync(options);
stopRecording();

Cancellation and interruption get their very own error type because pressing Stop isn’t really a failed recording. Nor is replacing one utterance with another.

Asking for system audio

The capture options now steer Chrome away from the current tab and towards an entire-screen share with system audio:

const buildDisplayMediaOptions = () => {
  const supported =
    typeof navigator.mediaDevices.getSupportedConstraints ===
    'function'
      ? navigator.mediaDevices.getSupportedConstraints()
      : {};

  const audio = {};

  if (supported.suppressLocalAudioPlayback) {
    audio.suppressLocalAudioPlayback = false;
  }

  if (supported.restrictOwnAudio) {
    audio.restrictOwnAudio = false;
  }

  return {
    video: true,
    audio: Object.keys(audio).length ? audio : true,
    preferCurrentTab: false,
    selfBrowserSurface: 'include',
    systemAudio: 'include',
    monitorTypeSurfaces: 'include',
  };
};

suppressLocalAudioPlayback: false allows me to keep hearing the speech while it’s recorded. restrictOwnAudio: false asks the browser not to remove the page’s own audio from the mix.

The remaining options are hints for Chrome’s sharing picker. They don’t let the application quietly choose a screen or enable system audio on someone’s behalf, which is probably for the best.

The user still has to select something along the lines of:

Entire screen → Share system audio

Choose “Chrome tab” and the result may still be silence.

Throwing away the video

Calling getDisplayMedia() gives me a display stream containing video and, if the correct option was selected, system audio.

I don’t need the video. Once permission has been granted, I stop and remove those tracks immediately:

const ensureAudioTracks = (captureStream, missingMessage) => {
  for (const track of captureStream.getVideoTracks()) {
    track.stop();
    captureStream.removeTrack(track);
  }

  const audioTracks = captureStream.getAudioTracks();

  if (!audioTracks.length) {
    stopMediaStream(captureStream);

    const error = new Error(missingMessage);
    error.name = 'TabAudioMissingError';
    throw error;
  }

  return new MediaStream(audioTracks);
};

Apart from doing less unnecessary work, this reduces the amount of the shared display that remains active.

The code keeps references to both the original capture stream and the audio-only stream. That matters later when capture stops, the component unmounts or the user starts a new session. Media tracks are quite happy to carry on until somebody explicitly tells them otherwise.

Starting the recorder first

The order of operations matters.

Starting speech and then creating MediaRecorder risks losing the beginning of the utterance. The recorder needs to be running before speechSynthesis.speak() is called:

const session = startAudioRecording(audioStream);
activeRecordingRef.current = session;
setIsRecording(true);

await speakAsync(options);

When the utterance ends, I wait another 120 milliseconds before stopping the recorder:

await new Promise((resolve) => {
  window.setTimeout(resolve, 120);
});

const result = await session.stop();

That small delay isn’t decorative. The utterance’s end event can arrive slightly before the final audio reaches MediaRecorder.

Picking a format the browser can record

The implementation also checks which MIME types are available instead of assuming every browser can create the same format:

const RECORDER_MIME_CANDIDATES = [
  'audio/webm;codecs=opus',
  'audio/webm',
  'audio/mp4',
];

export const pickRecorderMimeType = () => {
  if (
    typeof MediaRecorder === 'undefined' ||
    !MediaRecorder.isTypeSupported
  ) {
    return undefined;
  }

  return RECORDER_MIME_CANDIDATES.find((type) =>
    MediaRecorder.isTypeSupported(type)
  );
};

MediaRecorder emits chunks while it runs. I collect those chunks and turn them into a Blob when recording stops:

recorder.ondataavailable = (event) => {
  if (event.data && event.data.size > 0) {
    chunks.push(event.data);
  }
};

recorder.onstop = () => {
  const blob = new Blob(chunks, { type: mimeType });

  resolve({
    blob,
    mimeType,
    discarded: false,
  });
};

recorder.start(250);

The 250-millisecond timeslice encourages Chromium to flush chunks during longer utterances instead of keeping everything until the end. Depending on the selected MIME type, the download gets a .webm, .m4a or .ogg extension.

Detecting a recording full of nothing

My failed tab-capture experiment exposed another problem: checking that the Blob exists isn’t enough.

A WebM can have a header, timing information and plenty of bytes while containing no audible speech. To catch that, you need to decode each recording and calculates its root mean square amplitude:

export const looksSilentRecording = async (
  blob,
  rmsThreshold = 0.008
) => {
  if (!blob || blob.size < 256) {
    return true;
  }

  const Ctx = AudioContext || webkitAudioContext;
  const context = new Ctx();

  try {
    const buffer = await context.decodeAudioData(
      await blob.arrayBuffer()
    );

    let peakRms = 0;

    for (
      let channel = 0;
      channel < buffer.numberOfChannels;
      channel += 1
    ) {
      const data = buffer.getChannelData(channel);
      const step = Math.max(
        1,
        Math.floor(data.length / 40000)
      );

      let sum = 0;
      let count = 0;

      for (let i = 0; i < data.length; i += step) {
        sum += data[i] * data[i];
        count += 1;
      }

      if (count > 0) {
        peakRms = Math.max(
          peakRms,
          Math.sqrt(sum / count)
        );
      }
    }

    return peakRms < rmsThreshold;
  } finally {
    await context.close();
  }
};

For long recordings, it samples at most roughly 40,000 points per channel rather than inspecting every frame.

The threshold of 0.008 isn’t a universal definition of silence, but is a guard against accepting the near-empty files produced when the wrong capture source is selected. Very quiet intentional audio could fall below it, although that’s not going to happen for this use case.

If decoding isn’t available or fails, the implementation falls back to checking whether the Blob is suspiciously small. Less accurate, but still more useful than blindly accepting everything.

Previewing and downloading takes

Once a recording passes the silence check, URL.createObjectURL() gives me a local URL for it:

const url = URL.createObjectURL(result.blob);

const recording = {
  id: `rec-${Date.now()}-${recordingSeq++}`,
  blob: result.blob,
  url,
  mimeType: result.mimeType,
  createdAt: Date.now(),
};

setRecordings((previous) => [recording, ...previous]);

The same URL powers an <audio> preview and the download link. Nothing needs to be uploaded to a server. Blob URLs do need a little tidying up. The app revokes each URL when I discard a take and revokes anything remaining when the React component unmounts:

URL.revokeObjectURL(recording.url);

The hook also stops every media track, cancels active speech and discards unfinished recordings during cleanup.

The feature is primarily aimed at desktop Chromium browsers. Screen-audio support and sharing interfaces vary between browsers and operating systems, so I wouldn’t present this as a universal browser recording API. It’s a focused workaround for a focused problem.

It does solve my problem, though. I can now prepare the line, choose the voice, adjust its speed and pitch, and download the chosen one. . . all without reaching for my phone.

Getting the recording into Keynote is still a pain. If only it supported webm 🤦‍♂️

Still. Let’s solve one hotel-room problem at a time.

A quick guide to c# expressions in .net MAUI.

Thu, 23 Jul 2026 00:00:00 +0000

This post is part of the MAUI UI July community series of blog posts and videos, hosted by Matt Goldman. Take a look the other posts in this series!

I’ve written more Boolean converters than I’d care to admit. Not complicated ones, either. They work, but a convertor is a lot of ceremony for something so small.

C# expressions are coming to .NET MAUI in .NET 11, and they’re designed to remove a bunch of this sort of boilerplate. They let you write small C# expressions directly inside XAML attributes, which means conditions, calculations, formatting and simple event handling can live closer to the controls that use them.

<VerticalStackLayout IsVisible="{!IsLoading}" />

<Button
    Text="Save"
    IsEnabled="{IsValid && !IsSaving}" />

<Label Text="{$'{FirstName} {LastName}'}" />

This is a fairly substantial change to the way we can work with XAML. It doesn’t mean view models, converters, commands or normal bindings are going away, and it certainly doesn’t mean every bit of application logic should now be squeezed into an XML attribute. What it does mean is that a lot of the tiny pieces of supporting code we write around XAML may no longer be necessary.

What are C# expressions?

C# expressions let you use C# syntax inside XAML attributes. That includes property access, Boolean conditions, arithmetic, string interpolation, null-coalescing, ternary expressions, method calls and small event-handler lambdas.

The feature is being introduced as part of .NET MAUI in .NET 11 and is still experimental at the time of writing. Some of the syntax, behaviour and limitations may change before the final release, so this probably isn’t the moment to enthusiastically rewrite half a production application on a Friday afternoon.

The interesting part is that these expressions aren’t simply strings being interpreted at runtime. They’re understood by the .NET MAUI XAML source generator, which can inspect an expression, work out which types and properties it uses, and generate the required C# or binding code at build time. That means that they’re SourceGen only, and not available if using XamlC or Runtime inflation.

That makes this more than shorter syntax. It gives the compiler a much better understanding of what the XAML is trying to do. It gives you less code to grep.

Why is this happening?

XAML is very good at describing the structure of a user interface. It becomes less elegant when you need to add a small amount of presentation logic, particularly when that logic is too simple to deserve its own class or view-model property.

Suppose you have an activity indicator that should be visible while data is loading, and some page content that should be visible when it isn’t. A fairly typical approach looks like this:

<ContentPage.Resources>
    <toolkit:InvertedBoolConverter
        x:Key="InvertedBoolConverter" />
</ContentPage.Resources>

<ActivityIndicator
    IsRunning="{Binding IsLoading}"
    IsVisible="{Binding IsLoading}" />

<VerticalStackLayout
    IsVisible="{Binding IsLoading,
        Converter={StaticResource InvertedBoolConverter}}">

    <!-- Page content -->

</VerticalStackLayout>

There’s nothing especially wrong with this. Converters are useful, particularly when transformation logic is shared across several views. In this case, though, we’ve introduced a converter, registered it as a resource and referenced it from the binding simply to invert a Boolean.

With C# expressions, the same thing becomes:

<ActivityIndicator
    IsRunning="{IsLoading}"
    IsVisible="{IsLoading}" />

<VerticalStackLayout IsVisible="{!IsLoading}">

    <!-- Page content -->

</VerticalStackLayout>

The new version is shorter, but that isn’t the only benefit. The condition is right next to the element that uses it, and the intent is obvious without jumping around the project looking for a converter.

A tiny bit of logic stays tiny.

Simple property bindings

The most basic example is binding to a property.

Before

<Label Text="{Binding Username}" />

<Label Text="{Binding User.DisplayName}" />

With C# expressions

<Label Text="{Username}" />

<Label Text="{User.DisplayName}" />

At first glance, this looks like shorthand for removing the word Binding, but the source generator is doing more than that. When the page has an x:DataType, the expression can be checked against the binding context at build time.

<ContentPage
    x:Class="MyApp.ProfilePage"
    x:DataType="viewModels:ProfileViewModel">

    <Label Text="{Username}" />

</ContentPage>

If Username doesn’t exist on ProfileViewModel, the tooling has enough information to complain about it. That’s rather more useful than discovering a typo after navigating to the page and wondering why the label is empty.

Writable properties can still be used with controls that support two-way binding:

<Entry Text="{Username}" />

This isn’t throwing away data binding. It’s giving the compiler a more direct and strongly typed way to describe it.

Boolean expressions

Boolean expressions are probably where many developers will see the quickest win. Applications tend to collect converters and calculated properties for conditions such as “invert this value”, “check whether both values are true” or “show this control when a count is greater than zero”.

A view model might currently expose another property:

public bool CanSave => IsValid && !IsSaving;

The XAML then binds to it:

<Button
    Text="Save"
    IsEnabled="{Binding CanSave}" />

This works, but the view model must also raise a property-change notification for CanSave whenever either IsValid or IsSaving changes. That is easy to forget and can produce the sort of bug where the state is correct but the button remains stubbornly disabled.

Another option is a MultiBinding and converter:

<Button Text="Save">
    <Button.IsEnabled>
        <MultiBinding Converter="{StaticResource CanSaveConverter}">
            <Binding Path="IsValid" />
            <Binding Path="IsSaving" />
        </MultiBinding>
    </Button.IsEnabled>
</Button>

That is a lot of XAML for a condition that is perfectly readable in one line.

With C# expressions

<Button
    Text="Save"
    IsEnabled="{IsValid && !IsSaving}" />

Other conditions are equally direct:

<Label IsVisible="{ItemCount > 0}" />

<Button
    IsEnabled="{HasAcceptedTerms && IsFormValid}" />

<VerticalStackLayout
    IsVisible="{IsSignedIn || IsGuestAccessEnabled}" />

This is the sort of thing C# expressions are particularly good at. The logic is small, local to the view and understandable without extra context.

Word-based operators are also being explored to avoid some of the awkwardness caused by XML escaping:

<Button
    IsEnabled="{HasAcceptedTerms AND IsFormValid}" />

The available aliases include forms such as AND, OR, LT, GT, LTE and GTE. Whether you prefer those or the normal C# operators will probably come down to readability and how much XML complains about what you’re trying to type.

Calculated values

Calculated properties are another common piece of view-model furniture. Suppose you have a price and quantity and want to show the total.

Before

public decimal Price { get; set; }

public int Quantity { get; set; }

public decimal Total => Price * Quantity;

<Label Text="{Binding Total}" />

Again, Total needs to raise a change notification whenever Price or Quantity changes. Without that notification, the calculation may be correct in the view model while the UI continues showing an old value.

With a C# expression, the calculation can be written directly in the XAML:

<Label Text="{Price * Quantity}" />

The source generator can inspect the expression and work out which values it depends on. Because Price * Quantity isn’t something that can be assigned back to the view model, the generated binding is one-way, which is exactly what you would expect.

This works well for small presentation calculations. It doesn’t mean your pricing rules, discount logic and tax calculations should now live in a forty-line XAML expression. If the calculation has business meaning, is reused elsewhere or needs proper testing, keep it in C# and give it a useful name.

String interpolation

Formatting text in XAML has always been possible, but it isn’t always pleasant. You might use StringFormat, a calculated property or a FormattedString full of spans.

For example, displaying a full name might involve another property.

Before

public string FullName => $"{FirstName} {LastName}";

<Label Text="{Binding FullName}" />

With C# expressions

<Label Text="{$'{FirstName} {LastName}'}" />

The single quotes are used because the XAML attribute itself is already wrapped in double quotes. You can use the same approach for other bits of display text:

<Label Text="{$'Hello, {FirstName}'}" />

<Label Text="{$'{Quantity} × {ProductName}'}" />

<Label Text="{$'Total: {Price:C2}'}" />

Dates can be formatted in the same way:

<Label
    Text="{$'Arriving {ArrivalDate:dddd, d MMMM}'}" />

This should be particularly useful when the formatted text exists for one specific view. If several pages need the same formatting, or the formatting is part of the application’s behaviour rather than its presentation, a named property or formatter is probably still the better home.

Ternary expressions

Sometimes you need to choose between two values. A common way of doing this is to add another property to the view model.

Before

public string AccountTypeText =>
    IsPremium
        ? "Premium account"
        : "Standard account";

<Label Text="{Binding AccountTypeText}" />

With C# expressions

<Label
    Text="{IsPremium ? 'Premium account' : 'Standard account'}" />

You can also combine a ternary with interpolation:

<Label
    Text="{ItemCount == 1 ? '1 item' : $'{ItemCount} items'}" />

This is useful up to a point. One small ternary expression is easy to understand, but three nested ternaries and a method call will quickly make the XAML harder to follow.

At that point, give the condition a name and move it back into C#.

Null handling

Null fallback values are another good fit for expressions.

Before

public string DisplayName =>
    Name ?? "Unknown user";

<Label Text="{Binding DisplayName}" />

With C# expressions

<Label Text="{Name ?? 'Unknown user'}" />

You can also use null-aware property access:

<Label
    Text="{User?.DisplayName ?? 'Guest'}" />

This is useful when the fallback is specific to a particular element. If the application has a defined rule for how user names should be displayed everywhere, put that rule somewhere reusable rather than copying the same expression across six pages.

Method calls

Expressions can call methods:

<Label Text="{Name.ToUpperInvariant()}" />

They can also call helper methods:

<Label Text="{GetFormattedDate()}" />

Static methods are supported too:

<ProgressBar
    Progress="{Math.Min(Progress, 1)}" />

This comes with an important caveat: not every expression is automatically reactive. An expression generated as a binding can update when its dependencies raise property-change notifications, but a method called directly from the page may be evaluated once when the view is created.

If you write this:

<Label Text="{GetCurrentStatus()}" />

you shouldn’t assume it will rerun whenever some unrelated property changes. The expression needs a clear set of observable dependencies for the generated binding to know when it should update.

This is one of the areas worth testing carefully while the feature is still in preview.

Inline event handlers

C# expressions can also be used to handle events. Imagine a button that increments a counter.

Before

<Button
    Text="Add"
    Clicked="OnAddClicked" />

private void OnAddClicked(object sender, EventArgs e)
{
    Count++;
}

With C# expressions

<Button
    Text="Add"
    Clicked="{(sender, args) => Count++}" />

You can call a method in the same way:

<Button
    Text="Reset"
    Clicked="{(sender, args) => ResetForm()}" />

This is useful for genuinely tiny synchronous actions. It becomes less useful when the event handler contains validation, logging, navigation, cancellation, error handling and three service calls. At that point, give it a name and put it somewhere sensible.

Async lambdas aren’t currently supported, so asynchronous event handlers still need a normal method or command:

<Button
    Text="Save"
    Clicked="OnSaveClicked" />

private async void OnSaveClicked(
    object sender,
    EventArgs e)
{
    await viewModel.SaveAsync();
}

That limitation may feel inconvenient, but it also stops the XAML from becoming a hiding place for sizeable chunks of asynchronous application logic. Probably not a bad thing.

Existing XAML markup still works

C# expressions are being added alongside the XAML features that already exist. Normal bindings, static resources and x:Static all continue to work:

<Label Text="{Binding Name}" />

<Label Text="{StaticResource PageTitle}" />

<Label
    Text="{x:Static local:AppConstants.AppName}" />

The source generator needs to work out whether the contents of the braces are a markup extension or a C# expression. Where something is ambiguous, you can be explicit:

<!-- Explicit expression -->
<Label Text="{= SomeValue}" />

<!-- Resolve against the page -->
<Label Text="{this.Title}" />

<!-- Resolve against the binding context -->
<Label Text="{.Title}" />

The last two are useful when the page and its binding context contain properties with the same name. It’s one of those problems you may not have until you do, at which point you’ll be pleased the explicit syntax exists.

What could this replace?

C# expressions may remove the need for quite a few small pieces of supporting code, including inverted Boolean converters, simple comparison converters, some multi-value converters, presentation-only calculated properties, basic formatting properties, straightforward triggers and tiny synchronous event handlers.

A MultiBinding such as this:

<Label>
    <Label.IsVisible>
        <MultiBinding
            Converter="{StaticResource AllTrueConverter}">

            <Binding Path="IsLoggedIn" />
            <Binding Path="HasSubscription" />

        </MultiBinding>
    </Label.IsVisible>
</Label>

can become:

<Label
    IsVisible="{IsLoggedIn && HasSubscription}" />

That is fewer lines, but the more useful change is that the condition is visible immediately. You don’t need to inspect a converter to discover whether AllTrueConverter really means all values must be true, whether null counts as false or whether it does something surprising because someone changed it four years ago.

What shouldn’t go into an expression?

Just because C# can now be written inside XAML doesn’t mean every bit of application logic should move there. I’d avoid using expressions for business rules, network calls, database operations, complex state changes, reusable calculations, anything that needs focused unit testing or anything that requires a comment to explain what it does.

You could write something like this:

<Label
    IsVisible="{
        CurrentUser != null &&
        CurrentUser.Subscription != null &&
        CurrentUser.Subscription.ExpiresAt > DateTime.Now &&
        !CurrentUser.IsSuspended
    }" />

But a named property is much easier to understand:

<Label
    IsVisible="{CanAccessPremiumFeatures}" />

The second version tells me what the condition means. The first tells me how it is calculated and asks me to work out the meaning myself.

That is the line I’d use when deciding whether an expression belongs in XAML: use an expression when it makes the XAML more obvious, and use a named property or method when it makes the intention more obvious.

A complete example

Here’s a small page using several of the new expression types together:

<ContentPage
    x:Class="ExpressionDemo.MainPage"
    x:DataType="viewModels:MainViewModel">

    <VerticalStackLayout
        Padding="24"
        Spacing="16">

        <Label
            FontSize="24"
            Text="{$'Welcome, {FirstName}'}" />

        <ActivityIndicator
            IsRunning="{IsLoading}"
            IsVisible="{IsLoading}" />

        <VerticalStackLayout
            IsVisible="{!IsLoading}"
            Spacing="12">

            <Label
                Text="{$'{Quantity} × {ProductName}'}" />

            <Label
                Text="{$'Total: {Price * Quantity:C2}'}" />

            <Button
                Text="Place order"
                IsEnabled="{
                    Quantity > 0 &&
                    HasAcceptedTerms &&
                    !IsSubmitting
                }" />

        </VerticalStackLayout>

    </VerticalStackLayout>

</ContentPage>

There are no converters here, no calculated Total property and no CanPlaceOrder property that needs change notifications whenever three other values change.

The important question isn’t whether this version contains fewer lines. It’s whether someone opening the page can understand what it does.

In this case, I think they probably can.

When can I try it?

C# expressions are being developed for .NET MAUI in .NET 11. .NET 11 is scheduled for release in November 2026, but the feature can be tried using the .NET 11 preview SDK and the matching .NET MAUI workload.

It’s still experimental, so expect rough edges, incomplete tooling and behaviour that may shift between preview releases. I wouldn’t start converting a production application wholesale yet.

A better approach is to create a small test project or pick one isolated page containing a few obvious candidates: an inverted Boolean converter, a basic MultiBinding, a display-only calculated property, a formatted string or a one-line synchronous event handler.

Replace them one at a time and see what the resulting XAML feels like. Check whether it becomes easier to read, whether the expression updates when you expect it to, whether Hot Reload behaves and whether the compiler errors point you towards the problem when something goes wrong.

Those are the useful questions during a preview.

Give it a try

C# expressions won’t replace MVVM, converters, commands, view models or code-behind, and they shouldn’t. What they offer is a way to remove some of the faff around small bits of presentation logic.

That could mean fewer converters, fewer properties that exist purely for one label and less hopping between files to understand a simple condition.

Try them in a small page and see which bits of boilerplate disappear. More importantly, notice which bits are still clearer with a proper name in the view model.

Then tell the .NET MAUI team what worked, what didn’t and where the tooling got confused. Preview features improve when people use them for real things rather than admiring them from a release note.

Read the spec

User Needs Mapping by Rich Allen

Mon, 20 Jul 2026 00:00:00 +0000

I took some time out of the office today, releshing the opportunity to read a good book in the sunshine.

And it’s almost as good as the view!

User needs are difficult to pin down, whether the individual is internal or external to the business. Sometimes they’re masked by complexity. Sometimes they’re hidden behind user pains. And sometimes. . . just sometimes. . . no one actually knows what they need. . . only what they want.

All combined, they result in unaligned goals across a team/org, ill defined boundaries and responsibilities, and confusion between internal needs and the actual needs of the end user. (Developer experience is important. Honest boss!)

Thankfully, Rich Allen is here to save the day!

In User Needs Mapping, Rich draws from multiple Agile-esque processes to distill the core of User Needs Mapping. It gives you the language to talk about the issues to be solved with clients and the team around you, and breaks down the process step by step with really good illustrations to support the text.

My favourite thing about this book is the examples. They’re as deep as they need to be, exceptionally well written, and not the usual. After reading a few books of this ilk, it’s nice to not see the same examples being regurgitated in an effort to draw new insights.

Highly recommended 👍

If User Needs Mapping is something you’ve been meaning to look deeper at, pick up a copy of this book and learn EVERYTHING you need to know to do the job.

Making static Astro pages editable with Decap

Wed, 15 Jul 2026 00:00:00 +0000

I recently added Decap CMS to an Astro site that already had an ordinary collection of articles. That bit was straightforward enough: articles all share roughly the same shape, so they fit neatly into a folder-based content collection.

Then came the static pages.

The homepage had a hero and a short introduction. The About page had similar introductory content, plus a list of things the organisation stands for. The copy was hardcoded directly into the .astro templates, which meant every wording change needed a developer, a code edit and a deployment.

Less than ideal for changing a sentence.

The goal was to make those pages editable through Decap without turning the CMS configuration into a giant generic page builder. I also didn’t want About-specific fields appearing in the homepage editor simply because both happened to be pages.

The approach I settled on was:

one Markdown content entry for each static page
one Astro content collection for each page type
one Decap file collection containing the individual page editors
the existing Astro templates left largely intact

It’s a small amount of wiring, keeps the types useful and gives editors a clean form containing only the fields they actually need.

Why use a file collection?

Decap supports both folder collections and file collections.

Folder collections are a good fit for repeatable content such as articles, products or team members. Each entry has the same fields, and editors can usually create more of them.

A file collection works differently. Each entry points to a specific file and can define its own set of fields. Decap’s documentation specifically calls out custom landing pages and other uniquely structured files as a good use case.

That matched what I needed.

There is only one homepage. I don’t want an editor merrily creating homepage-2.md, however tempting the sequel might be.

The About page also has a slightly different content model from the homepage. Keeping it as a separate file definition means its list fields stay in its editor rather than leaking into every other page.

The resulting structure looked like this:

src/
├── content/
│   ├── articles/
│   ├── homepage/
│   │   └── index.md
│   └── about/
│       └── index.md
├── content.config.ts
└── pages/
    ├── index.astro
    └── about-us.astro

public/
└── admin/
    └── config.yml

1. Define the Astro content collections

Astro content collections let you define the expected shape of your content and then query it through APIs such as getEntry().

For local Markdown files, Astro provides a glob() loader. You give it a base directory and a pattern, then add a schema to validate the frontmatter. The schema also supplies TypeScript types and editor autocomplete when you use the content later.

Here’s a deliberately small example:

// src/content.config.ts
import { defineCollection } from "astro:content";
import { glob } from "astro/loaders";
import { z } from "astro/zod";

const homepage = defineCollection({
  loader: glob({
    pattern: "index.md",
    base: "./src/content/homepage",
  }),
  schema: z.object({
    pageTitle: z.string(),
    heroHeading: z.string(),
    introduction: z.string(),
  }),
});

const about = defineCollection({
  loader: glob({
    pattern: "index.md",
    base: "./src/content/about",
  }),
  schema: z.object({
    pageTitle: z.string(),
    heroHeading: z.string(),
    standForItems: z.array(z.string()).min(1),
  }),
});

export const collections = {
  homepage,
  about,
};

There are two collections even though each contains only one entry.

That might look slightly over-organised at first, but it gives each page its own schema. The homepage doesn’t need to know what a standForItem is, and the About page can require at least one of them.

You could create one enormous pages schema with a pile of optional fields:

standForItems: z.array(z.string()).optional()

Do that a few more times, though, and you end up with a schema that doesn’t properly describe any of your pages. Everything is technically allowed everywhere, and the types stop protecting you from much.

Separate schemas are a little more verbose but much clearer.

One small version-related detail: current Astro documentation imports Zod from astro/zod. Older projects and examples may use a different import, so follow the convention used by the Astro version installed in your project.

2. Move the page copy into Markdown

Next, create the actual content entries.

For the homepage:

---
pageTitle: Cornwall Self-Catering Collective
heroHeading: One voice for self-catering in Cornwall
introduction: We represent professional self-catering agencies across Cornwall.
---

Save that as:

src/content/homepage/index.md

Then create the About page:

---
pageTitle: About us
heroHeading: A collective voice for responsible self-catering
standForItems:
  - Professional standards
  - Responsible tourism
  - Strong local communities
---

Save that as:

src/content/about/index.md

The filenames matter because Astro derives the entry ID from the filename when using the glob() loader. In this case, both entry IDs are index.

That becomes important when we load them in the page templates.

The frontmatter names must also match the Zod schemas exactly. heroHeading and hero_heading may look like close relatives to a human, but they are not the same field to Astro.

3. Add the pages to Decap CMS

Decap’s main configuration normally lives in the admin directory, commonly as public/admin/config.yml in an Astro project. Collections define what appears in the editor and which files Decap updates.

Add a file-based collection for the static pages:

collections:
  - name: pages
    label: Pages
    files:
      - label: Homepage
        name: homepage
        file: src/content/homepage/index.md
        fields:
          - { label: Page title, name: pageTitle, widget: string }
          - { label: Hero heading, name: heroHeading, widget: string }
          - { label: Introduction, name: introduction, widget: text }

      - label: About us
        name: about
        file: src/content/about/index.md
        fields:
          - { label: Page title, name: pageTitle, widget: string }
          - { label: Hero heading, name: heroHeading, widget: string }
          - label: What we stand for
            name: standForItems
            widget: list
            field:
              label: Item
              name: item
              widget: string

The file value is relative to the root of the repository, not the admin directory.

Each page gets its own fields block. That’s the useful bit: the homepage editor contains only homepage fields, while the About editor gets its repeatable list.

Decap widgets control both the editing interface and the type of data that gets written. The string widget is suited to shorter values, while text provides a multiline field.

For standForItems, I used a list widget with one repeated string field. This lets the editor add, remove and reorder items without editing YAML by hand.

The name values in Decap must match the names in your Markdown frontmatter and your Astro schema:

Decap config
    ↓
Markdown frontmatter
    ↓
Astro schema
    ↓
Astro template

A mismatch anywhere along that chain will either produce a validation error or leave you wondering why your newly edited heading has disappeared into the void.

4. Load the content in the Astro page

The homepage previously contained hardcoded content:

<h1>One voice for self-catering in Cornwall</h1>

<p>
  We represent professional self-catering agencies across Cornwall.
</p>

Replace the hardcoded values with a content entry.

In src/pages/index.astro:

---
import { getEntry } from "astro:content";
import BaseLayout from "../layouts/BaseLayout.astro";

const homepage = await getEntry("homepage", "index");

if (!homepage) {
  throw new Error(
    "Missing homepage content at src/content/homepage/index.md"
  );
}

const { data } = homepage;
---

<BaseLayout title={data.pageTitle}>
  <h1>{data.heroHeading}</h1>
  <p>{data.introduction}</p>
</BaseLayout>

getEntry() takes the collection name followed by the entry ID. Astro exposes this function specifically for retrieving a known item from a build-time content collection.

Because the file is called index.md, the entry ID is index:

getEntry("homepage", "index");

Not:

getEntry("homepage", "homepage");

I added an explicit error when the entry is missing. You could use optional chaining and quietly render nothing, but that tends to turn a straightforward content problem into a slightly tedious layout investigation.

Failing with the exact missing path is much more useful.

5. Do the same for the About page

The About page follows the same pattern:

---
import { getEntry } from "astro:content";
import BaseLayout from "../layouts/BaseLayout.astro";

const about = await getEntry("about", "index");

if (!about) {
  throw new Error(
    "Missing about content at src/content/about/index.md"
  );
}

const { data } = about;
---

<BaseLayout title={data.pageTitle}>
  <h1>{data.heroHeading}</h1>

  <ul>
    {data.standForItems.map((item) => <li>{item}</li>)}
  </ul>
</BaseLayout>

The existing HTML structure, classes and components can stay as they are. You are changing the source of the copy, not rebuilding the page.

That distinction kept this change pleasantly contained. The CSS didn’t care whether a heading came from a string inside the template or from data.heroHeading.

6. Test the full editing loop

A successful build proves that the schemas and imports are valid, but it doesn’t prove that an editor can actually change the content.

I checked the entire loop:

Start the Astro development server.
Start Decap’s local development setup, if you use one.
Open /admin/.
Edit the homepage heading and save it.
Confirm that src/content/homepage/index.md changed.
Refresh the homepage and check the new text.
Edit the About page list.
Confirm that the list renders correctly.
Run a production build.

In this project, the commands were:

pnpm dev
pnpm cms
pnpm build

Your CMS command may differ depending on how local Decap development has been configured.

The important test is not merely that the CMS says “saved”. Check the underlying Markdown file. Decap writes content into the repository through its configured backend; it is not the system that renders the final website. Astro still needs to read that content and build the page.

A final production build is worth doing because Astro’s schema validation catches missing fields and incorrect content types before the site is deployed.

In my case, the build passed after the templates and collections were wired together. Happy days.

Adding another static page

Once the pattern is in place, adding another page is mostly repetition.

For a contact page, for example:

Create src/content/contact/index.md.
Add a contact collection to src/content.config.ts.
Add a Contact entry under collections.pages.files in Decap.
Load it with getEntry("contact", "index").
Replace the hardcoded template values with data properties.
Run the CMS and production build checks.

It isn’t a fully dynamic page builder, and that is quite deliberate.

Editors can change the content you have chosen to expose, while the Astro templates retain control over the markup, layout and design. For this site, that was a much better fit than allowing arbitrary sections to be assembled in the CMS.

A few easy mistakes

Using different field names

This is the most likely one.

These must all agree:

config.yml:          heroHeading
Markdown:            heroHeading
content.config.ts:   heroHeading
Astro template:      data.heroHeading

Pick a naming convention and stick to it.

Using the wrong entry ID

With an entry stored as index.md, the ID generated by the glob loader is index.

Use:

await getEntry("about", "index");

Forgetting that file entries must exist

A Decap file collection points to known files. Those files need to exist in the configured repository branch before Decap can edit them.

Create and commit the Markdown files rather than expecting Decap to invent them on first use.

Making one universal schema too early

A shared schema can make sense when several pages genuinely use the same content model.

It is less useful when it becomes a bucket of optional properties:

heroHeading: z.string().optional(),
standForItems: z.array(z.string()).optional(),
contactDetails: z.object({}).optional(),
mapLocation: z.string().optional(),

At that point the schema is mostly documenting that anything might be there.

Start with page-specific schemas. Pull shared parts out later when repetition becomes real rather than theoretical.

Was it worth it?

This approach adds a few files and a little configuration, but it gives the site a useful middle ground.

The content team can edit the pages through Decap. Astro still owns the templates and styling. Zod checks that the saved content has the shape the templates expect. Page-specific fields remain page-specific.

It won’t cover every possible CMS setup, particularly sites that need flexible visual page building or deeply nested content blocks. For a handful of designed static pages, though, a file collection backed by small Astro content collections is simple, typed and easy to extend.

More importantly, changing a homepage heading no longer requires opening a code editor.. . which was kinda the point.

Thank you re:connect conference

Fri, 10 Jul 2026 00:00:00 +0000

Community conferences are always the best.

And amongst them, re:connect is right up there.

Running in Bournemouth every summer, the event is the spearhead of the local tech meetup scene. Hosted at the CityGate centre, right next to the train station, the gathering brought together a mix of people from all corners of the software development discipline from around Europe.

So what made it a compelling conference?

There wasn’t a huge lineup. But every speaker brought their a-game, added something unique, and offered an insightful takeaway or two.

It wasn’t the hugest audience. But every attendee came to learn, chat, to meet their peers and add their input into the collective conversation.

But that’s true of a lot of events.

So. . . what was the differentiator, making this one rank towards the top of the pile?

Honesty.

It’s as simple as that.

Reconnect wasn’t trying to be something it’s not. No heirs, no graces, and no pretentiousness. Not trying to make things seem more that they were, in the best way possible. Just a bunch of people coming together to enjoy getting geeky about our common passion whilst learning about topics on the periphery of the day to day.

If you’re looking for a friendly community to be a part of, or somewhere to drop by and deliver a talk. . . look no further than re:connect conference, {dev.talk} and the ecosystem around the pair. Great event, in a fab location.

Thanks to everyone who came along to listen to me wax lyrical about hip-hop and .NET MAUI 🙌

Can’t wait for my next visit!

Entertainment is consumed. Fun is created.

Sat, 20 Jun 2026 00:00:00 +0000

One day. . . I'll go straight there.

Tue, 14 Apr 2026 00:00:00 +0000

See you soon-ish City JS!

MAUI Day and the stowaway ladybird

Fri, 06 Feb 2026 00:00:00 +0000

7 Talks + 2 nights away + a stowaway ladybird = another successful MAUI Day!

With almost 100 attendees in the room, how could it not be?

The gaggle of .NET MAUI developers had descended from around the globe on central London for a day of cross-platform knowledge sharing. Not only did we learn a whole bunch, but we also got to meet and mingle with the faces behind the avatars that we chat with day in and out.

Between Syncfusion providing the food, NewDay providing the venue, and the community providing the conversations, the room was in exceptionally high spirits.

Was it fun?

It sure was.

Did it run on time?

Hell no!

Will we do it again?

For sure!

Where?

Everywhere!

For as long as another group of speakers are willing to assemble to provide an excuse to get together, then we’ve got no excuse not to. Massive thanks to David, Stéphane, Mark, Matt, Shriram, and Clifford for giving the days conversations a focal point, plus allowing the conf to ✅ the 5 continents box.

Not sure how we’ll reach six!

In a distributed sector, within a distributed world, opportunities to connect in person and deepen the rapport built on top of hundreds of online chats is important. Both to the individual and the whole. Communities thrive based on the value of conversations, and judging by the buzz in the room last week the hashtag#dotnetMAUI community has never been so alive.

Just like the ladybird.

She’s part of the colony hibernating in the bedroom back home, although one of the family decided to come on the 580 mile round train trip.

Thankfully, Premier Inn rooms are hermetically sealed. . . meaning she could fly around the room in the evening without me having to worry about her escaping. Countryside bugs don’t deserve city life, although I’m sure she has some stories to tell the others!

We both have to be fair.

Overall, it was another successful trip to the UK capital for the hashtag#MAUIDay crew.

But multiple attendees on the day gave me feedback that there should be more focus on performance amongst the sessions.

Hopefully we’ll be able to arrange that for London 2027, and maybe even add a little performance to the panel 🤞

3 minutes to go. Stuck in the toilet 🤦‍♂️

Thu, 05 Feb 2026 00:00:00 +0000

3 mins left and I was stuck in the toilet

It was broadcast time.

Eat a Banana. Drink some water. Go to the bathroom.

Gran always said to never miss an opportunity, and this wasn’t the moment to defy such hefty wisdom.

Hearing the click of the door behind me, it didn’t cross my mind that this is the high security HQ of Microsoft. Doors have locks. A few minutes later I soon realised the consequences of this lapse in concentration.

The call was made.

I was rescued.

Everything worked out in the end. But it wasn’t the warm-up I’d imagined for my guest appearance on the dotnet YouTube channel.

I wouldn’t worry about watching.

My appearance amounts to just babbling about chocolate salty balls.

They are tasty tho.

Life - All about the bounce back

Wed, 28 Jan 2026 00:00:00 +0000

.NET MAUI - Toggle fullscreen for MacCatalyst desktop app

Fri, 23 Jan 2026 00:00:00 +0000

.NET MAUI Mac Catalyst apps run on macOS, but use UIKit (iOS frameworks) rather than AppKit (native macOS frameworks). To toggle full screen, the same behavior as clicking the green ”zoom” button in the window chrome, we need to bridge into AppKit’s NSApplication and NSWindow using the Objective-C runtime.

#if MACCATALYST

    var nsAppClass = ObjCRuntime.Class.GetHandle("NSApplication");
    var nsApp = ObjCRuntime.Runtime.GetNSObject(nsAppClass);
    var sharedApp = nsApp?.PerformSelector(new ObjCRuntime.Selector("sharedApplication"));
    var keyWindow = sharedApp?.PerformSelector(new ObjCRuntime.Selector("keyWindow"));
    keyWindow?.PerformSelector(new ObjCRuntime.Selector("toggleFullScreen:"), keyWindow);

#endif

If you want to see it in action, check out this demo project containing a Mac App.

Here’s how it works.

var nsAppClass = ObjCRuntime.Class.GetHandle("NSApplication");

Gets a handle (pointer) to the Objective-C class NSApplication. This is AppKit’s application singleton class that manages the macOS app lifecycle. Since Mac Catalyst doesn’t directly expose AppKit types to C#, we access it dynamically through the Objective-C runtime.

var nsApp = ObjCRuntime.Runtime.GetNSObject(nsAppClass);

Wraps the raw class handle in an NSObject that we can interact with from C#. This gives us a managed object representing the NSApplication class itself, which we get with the next line.

var sharedApp = nsApp?.PerformSelector(new ObjCRuntime.Selector("sharedApplication"));

This calls the sharedApplication class method on NSApplication, which returns the singleton instance of the running application.

var keyWindow = sharedApp?.PerformSelector(new ObjCRuntime.Selector("keyWindow"));

This retrieves the keyWindow property from the shared application, i.e. the window that will receive any keypresses. This returns an NSWindow instance. Then. . . finally. . .

keyWindow?.PerformSelector(new ObjCRuntime.Selector("toggleFullScreen:"), keyWindow);

Calls toggleFullScreen: on the NSWindow. This is the same method macOS invokes when you click the green full screen button. The method takes a sender parameter (we pass the window itself), and toggles between full screen and windowed mode. This mean you can call it again to revert the full screen.

And with that, you now have a fullscreen Mac app using .NET MAUI.

What about Windows?

If you want to implement the same functionality within MAUI for Windows, I highly recommend this blog post.

A MAUI example starter project

Wed, 17 Dec 2025 00:00:00 +0000

Setting a project up in the right way from day one is key to long term success. But with a myriad of different ways to achieve the same goal, it’s fairly easy to go down the wrong path. Especially as a learner. This is even more true with MAUI, given how much it’s changed in recent years.

Quite often example projects are created by experts in software engineering, who’ve internalised abstractions and know the APIs inside out. These abstractions and helper libraries might make complete sense to someone with years of experience in a field, but to a learner, they’re can be plain confusing.

To AI as well.

By setting up the basics of a project, and then handing off to AI to fill in the gaps, the end result is much better and quicker to get to. With a little prompting, an AI coding assistant will scan a project and pattern match what exists already, making the right setup even more foundational and key.

At the outset of a recent vibe Mac app, I created a boilerplate project to act as an example of a good starting point for a .NET MAUI app to grow from. It:

Uses view models via the community toolkit to allow for a clean separation of UI and business logic
Sets up dependency injection for services, and consumes them in the view models
Uses app settings to pull config from

It achieves these things in the simplest way possible, without abstracting the reader of the code from how it fits together. It also offers a great starting point to experiment with using something more fancy to achieve the same goals, and will work on any platform if you alter the platform identifiers.

Hopefully you’ll find it useful on your MAUI journey.

https://github.com/tonyedwardspz/maui-di-vm-settings-example

Festive friday at Sapphire House

Mon, 15 Dec 2025 00:00:00 +0000

34 people, 23 dishes, (only) 4 bottles of Prosecco, and 1 happy chef *.

That’s a festive Friday at Sapphire House.

To bring the team together before we start disappearing ahead of Christmas, the Sapphire Holidays IT team, joined up with parts of the Aspects Holidays and Classic Cottages teams to craft the ultimate office roast. Of course, this came shortly after giving out the presents.

The meal itself was both a success and tasty!

Honey glazed parsnips met crispy roast potatoes. Succulent beef collided with terrific turkey. Cute little piggies nestled in their blankets, with a trio of gravies smothering them all. It’s was one of those moments that having multiple full kitchens in the building became a major highlight of office life.

Unfortunately, expectations for 2026 are now super high.

I suspect we’ll only top 2025 by getting a visit from Santa himself. . . although Dan was a adequate stand-in come time for secret Santa.

Ok. There were actually two chefs. . . but only one of them regularly makes me bacon sandwiches so he’s getting all the credit

10 years of Digital Plymouth

Thu, 04 Dec 2025 00:00:00 +0000

10 year of bringing Plymouth’s digital community together!

Getting to come along for the journey has been an honor.

We’re too quick to say that something is life changing nowadays. So much so that its become a cliché. But for this meetup, the people around it, and those that attend, it is often true in the truest sense of the word.

Whenever I’m doing something amazingly fun professionally, in the farthest corners of Europe, I can ALWAYS trace the origin back to the encouragement and support that came from being a part of the Digital Plymouth / Plymouth Web / PlymouthJS communities 🙏

It been great to watch it grow over the past decade into something bigger, more diverse, and even more impactful to the city.

Here’s to 10 more years of the same 🥂

A response to https://www.linkedin.com/feed/update/urn:li:activity:7402436542780305408/.

Hanging up the wigs

Fri, 28 Nov 2025 00:00:00 +0000

I’ve hung up the wigs for 2025.

But be warned. . . they’ll be back on occasion in 2026.

In recent years, the two talks I’ve delivered the most have both had a gimmick. Something to create a photo opportunity as part of an event, and hopefully to put a smile on the audiences face.

It worked!

Well. . . most of the time.

Without giving away the moment, the wigs and hats were both an integral part of the talks. But you (or even the organiser) can only play the fool so often, and it’s time to be a little more serious with the content I deliver. So whilst they’ll both be back, they’ll be used mainly for meetups where things are a little more informal and expectations on takeaway learnings are a little lower.

But one of the projects behind the talk has changed a huge amount over the years. Plus it’s super fun to work on.

Back then it was little more that a clone of a platform demo with a changed h1 tag, a ton of showmanship, and a dash of hot bars. Today, it’s grown into a multi API backend encompassing locally hosted speech recognition, LLMs, and image recognition paired with either a website or .NET tMAUI desktop app as the interface. It’s even binging in the hot newness that is Aspire to both the web and .NET stacks.

Naturally, the software is a bit shaky. That’s part of the fun. However the learnings are solid and it keeps a mechanism for growing my hat collection a little more.

The trickiest part?

Fitting the details into a paragraph or two so I can submit to conferences!

Wish me luck 🤞

The value of user testing

Wed, 26 Nov 2025 00:00:00 +0000

At work, the project I head up is entering its final phase of development before release. To make sure that we’re making guests life easier, I’ve hosted a user testing session in recent days. The results are surprisingly unsurprising. Bugs have been flagged up, paths through the app were broken, and features were not used as expected.

It was enlightening!

Whilst we’re well past the prototyping phase, the Designing UX: Prototyping book by Dan Goodwin and Ben has been super useful in setting up this activity. It pushed me into the right mindset for testing in a high fidelity context, giving a great framework for asking the right questions and setting the right tasks for users to work though. Although some of the tooling in the book in out dated, the concepts are solid and will never not be relevant. It’s also a super easy read, and pairs up well with lessons withing ‘The Mum Test’. Both are highly recommended if you’re about to perform this type of task.

On the day, test users were provided with four groups of related tasks, the kind of things that guests will over the lifecycle of their stay. Feedback was gathered via both a form and conversation, plus observational notes to pair with screen and audio recordings. The perspective afforded by looking over a shoulder instead of testing yourself allows different elements of the product to jump out. E.g,

I never miss the hit box to open the account edit screen, but every single tester did.
Users consistently look for X as part of the search interface.
I think feature X is complete, but the people from within the brand think Y and Z are missing from it.

Talking with frontline staff, those on the end of the phone during both the booking process and during the stay, uncovered a bunch of easy wins for the product.

“20% of our calls are about X”
“Our life would be easier if guests had Y when they called up”
“99% of guests only have one booking at a time”

The process also threw me back to a conversation at the Product Task meetup in Köln. I was talking about testing with a fellow attendee, with the conversation continuing afterwards digitally. I highlighted that my test group will come from within the company. It was suggested that they’d use the product differently to actual guests due to institutional knowledge, whilst I exibited an undeserved level of hubris that they wouldn’t.

Surprise surprise. . . they did.

One of the tasks was to navigate to a booked property, effectivly the stay starting tomorrow. Everyone within the business checked to see if the textual directions were present in the app. Everyone outside of the business simply clicked the map to start navigation within their maps app. This really highlighted how institutional knowledge affects the was a user performs a task. Martin. You were right. . . but only one of us knew that at the time! To paraphrase Tim Herberg, the speaker on the night:

Gut feeling has a place in the discovery process. It can inform the direction in the early days, but should quickly be backed up or discarded due to data.

Unfortunatly, I’d forgotten that point in the sime since and neglected to get the data to back up my assumptions.

Overall this was an enlightening process, and one that reminded me of the value that the rapid feedback loop that often comes with an agile-esque development process. Whilst some of the things that were flagged up are solid suggestions, there’s not really enough time to both polish what exists and introduce the refined features before launch day.

Lesson learned.

This was a fun and very useful process to go through as a product developer. I’m now sitting on a pile of actionable feedback, insights from different levels of the business, and even a few ideas that can help make the wider teams life easier via minimal changes to existing products or a quickly vibed prototype.

Oh. . . and biscuits. We ate a lot of biscuits.

Looking around @ HalfStack London

Fri, 21 Nov 2025 00:00:00 +0000

Rings - Aesop Rock

Tue, 18 Nov 2025 00:00:00 +0000

Used to draw
Hard to admit that I used to draw
Portraiture and the human form
Doodle of a two-headed unicorn
It was soothin’, movin’ his arm in a fusion
Of man-made tools and a muse from beyond
Even if it went beautifully wrong
It was tangible truth for a youth who refused to belong
No name nuisance, stews in a bedroom
Oozing a brand new cuneiform
Barely commune with the horde
Got a whole gray scale ungluing his world

Might zone out to the yap of the magpie
Unseen hand dragging his graphite
Cross contour, little bit of backlight
Black ink after a Bristol to baptize
You can’t imagine the rush that ensue
When you get three dimensions stuffed into two
Then it’s off to a school where it’s all that you do
Being trained and observed by a capable few
Back in New York, five peeps and a dog
In a two-bedroom doing menial jobs
Plus, rhymin’ and stealin’ and being a clod
Distractions free to maraud

I left some years a deer in the light
I left some will to spirit away
I let my fears materialize
I let my skills deteriorate
Haunted by the thought of what I should have been continuing
A mission that was rooted in a 20-year affinity
In rickety condition with an ID crisis
Nap on the front lawn, look up in the sky, it’s…

Shapes falling out of the fringe
All heart, though we would’ve made cowardly kings
They will chop you down just to count your rings
Just to count your rings, just to count your rings
And there were colors pouring out of the fringe
All heart, though we would’ve made cowardly kings
They will chop you down just to count your rings
Just to count your rings, just to count your rings

Used to paint
Hard to admit that I used to paint
Natural light on a human face
Stenciled fire on his roommate’s bass
It was blooming addiction
Amiss in the pushing of pigment
Book like a tattooed pigskin, look
Pinhead kids of the minute
Drank Kool-Aid from a tube of acrylic
And it grew up into linseed oil over linen
Joy to the poison, voice of the resin
Capture a map of the gesture
Back up, add a little accurate fat to the figure

Redo that, move that inward
Zinc white lightning shoots from his fingers
Studio strewn with illusion and tinctures
Stay tuned for the spooky adventures
You can’t imagine the stars that align
When a forearm starts foreshortening right
Or a torso hung on a warping spine
In proportion reads as warm and alive
Routine day with a dirt cheap brush
Then a week goes by and it goes untouched
Then two, then three, then a month
And the rest of your life, you beat yourself up

I left some seasons eager to fall
I left some work to bury alive
I let my means of being dissolve
I let my person curl up and die
Eating up his innards, an unfeasible anxiety
Has brutally committed to relinquishing his privacy
Aligning with the trials of the anti-Midas
Nap on the back lawn, look up in the sky, it’s…

Tony Edwards

Zurich JS took the roof off

Login with Passkeys in a .NET MAUI App

What MAUI is doing

Platform support

Let’s actually implement it

Step 1: configure the relying party on the server

Step 2: create the registration begin endpoint

Step 3: ask MAUI to create the passkey

Step 4: verify and store the new passkey

Step 5: start a passkey login

Step 6: authenticate with the passkey in MAUI

Step 7: verify the assertion and issue your normal tokens

One slightly annoying detail: keep the ceremony state

Apple needs Associated Domains

Android needs Digital Asset Links

A useful extra: keep the authentication local

Handle cancellation properly

What I’d actually ship

Useful links

Recording Web Speech Synthesis

Why recording the Chrome tab didn’t work

Making speech synthesis awaitable

Asking for system audio

Throwing away the video

Starting the recorder first

Picking a format the browser can record

Detecting a recording full of nothing

Previewing and downloading takes

A quick guide to c# expressions in .net MAUI.

What are C# expressions?

Why is this happening?

Simple property bindings

Before

With C# expressions

Boolean expressions

With C# expressions

Calculated values

Before

String interpolation

Before

With C# expressions

Ternary expressions

Before

With C# expressions

Null handling

Before

With C# expressions

Method calls

Inline event handlers

Before

With C# expressions

Existing XAML markup still works

What could this replace?

What shouldn’t go into an expression?

A complete example

When can I try it?

Give it a try

User Needs Mapping by Rich Allen

Making static Astro pages editable with Decap

Why use a file collection?

1. Define the Astro content collections

2. Move the page copy into Markdown

3. Add the pages to Decap CMS

4. Load the content in the Astro page

5. Do the same for the About page

6. Test the full editing loop

Adding another static page

A few easy mistakes

Using different field names

Using the wrong entry ID

Forgetting that file entries must exist

Making one universal schema too early

Was it worth it?

Thank you re:connect conference

Entertainment is consumed. Fun is created.

One day. . . I'll go straight there.

MAUI Day and the stowaway ladybird

3 minutes to go. Stuck in the toilet 🤦‍♂️

Life - All about the bounce back