Kevin Wilson

My Claude Team

Wed, 01 Apr 2026 11:54:00 GMT

As I've been leveraging AI tooling more and more for dev work, I've been iterating on what works and doesn't work for me and the kind of results I'm happy with.

I spent a good chunk of time working with a custom agentic loop that would iterate through a PRD and tackle one item at a time before passing it through a review cycle with a lower model. This was working quite well, but it was difficult to get the model to only work on one item at a time while retaining the larger context of everything else — and all within the limited context budget allowed to that agent.

Dev Teams

Agent team support in Claude Code fixed this. Being able to spin up a team of agents to tackle bigger problems means I don't need that loop anymore — I can just tell the main agent to orchestrate a team and pass tasks off to sub-agents, each working within their own context budget, before handing off to another agent for review.

They can take on a big task (or list of tasks) and work it out amongst themselves.

Skills

With that, here's the current version of the skill I've been using to invoke this — saved as a custom slash command (/review-team) in Claude Code:

Define a team to implement this plan. Include at least 1 reviewer using Sonnet
and working as devil's advocate who uses /simplify to review code.

You are the orchestrator for this work.

Process tasks using this flow:

1. Task is assigned to Agent
2. Agent works on task
3. When Agent has completed the work, pass to a Reviewer for review with /simplify
4. If the Reviewer accepts the changes, commit and move onto the next task
5. If the Reviewer requests changes, pass back to the original agent
6. If the Agent agrees with the suggestions, the Agent makes the
    changes then GOTO 4 and repeat
7. If the Agent disagrees with the suggestions, note the reason for
    disregarding, then commit and move on to the next task

Commit changes in logical groups. Try to be more granular if possible.

If you are working in a worktree, make sure to run tests/formatting/linting etc.
within that worktree.

As orchestrator, you need to proactively monitor the status of the team. If 
an Agent disconnects or goes idle, you are responsible for either
recovering them or killing them and replacing them with a new team
member. Do not just sit and wait endlessly for an unresponsive team member
to awaken.

My typical workflow is to go through a planning phase with the agent to produce a detailed plan, then invoke /review-team to kick off execution.

This allows multiple agents to work in parallel where tasks support it. By letting Claude figure out the dependency graph itself, it'll usually identify which tasks can be done in parallel and which need to be linear and spin up an N-agent team accordingly.

Using the /simplify plugin for reviews — an official Anthropic plugin, not something you need to build — means each change is checked against multiple criteria. The reviewer uses Sonnet specifically for the cost and speed tradeoff; you want reviews to be fast and cheap, not another heavyweight agent.

Allowing the agent worker to accept or reject reviewer suggestions helps weed out nitpicky feedback or anything that becomes invalid given a wider context.

The one recurring problem I've hit with Claude teams is agents falling offline or failing to respond — hence the strongly worded instruction for the orchestrator to monitor the team and deal with it proactively. It still occasionally needs a nudge, but it does help.

This skill is ever-evolving as I hit new edge cases. Give it a go and let me know how it works for you.

AbortController: the Swiss army knife of JavaScript

Sat, 21 Feb 2026 00:00:00 GMT

Most people know AbortController as the thing you use to cancel fetch requests. That's fair enough — it was literally designed for that. But AbortController has quietly become one of the most versatile tools in the JavaScript standard library. Its signal mechanism plugs into event listeners, streams, Node.js APIs, and even your own custom code.

Let's go through the ways you can use it, starting with the obvious one.

Aborting fetch requests

The classic use case. You create an AbortController, pass its signal to fetch, and call abort() when you want to cancel:

const controller = new AbortController();

fetch('/api/data', { signal: controller.signal })
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((err) => {
    if (err.name === 'AbortError') {
      console.log('Fetch was cancelled');
    } else {
      throw err;
    }
  });

// Cancel the request
controller.abort();

This is essential for any situation where a request might become irrelevant — navigating away from a page, a user typing in a search box (where each keystroke triggers a new request), or imposing a timeout.

Fetch with a timeout

AbortSignal.timeout() creates a signal that automatically aborts after a given number of milliseconds. No manual controller needed:

fetch('/api/slow-endpoint', {
  signal: AbortSignal.timeout(5000),
})
  .then((response) => response.json())
  .catch((err) => {
    if (err.name === 'TimeoutError') {
      console.log('Request timed out after 5 seconds');
    }
  });

Note that a timed-out signal throws a TimeoutError, not an AbortError. This lets you distinguish between explicit cancellations and timeouts.

Cleaning up event listeners

This is where AbortController starts to get interesting. You can pass a signal as an option to addEventListener, and when the signal aborts, the listener is automatically removed:

const controller = new AbortController();

element.addEventListener('click', handleClick, {
  signal: controller.signal,
});
element.addEventListener('keydown', handleKeydown, {
  signal: controller.signal,
});
window.addEventListener('resize', handleResize, {
  signal: controller.signal,
});

// Remove all three listeners in one call
controller.abort();

No more keeping track of every handler reference so you can call removeEventListener later. One abort() call tears down everything attached to that signal.

In React effects

This pattern is a perfect fit for React's useEffect cleanup. Here's a comparison.

Without AbortController, you need to hold a reference to every handler and remove them individually:

useEffect(() => {
  const handleResize = () => {
    setWidth(window.innerWidth);
  };
  const handleScroll = () => {
    setScrollY(window.scrollY);
  };
  const handleKeydown = (e) => {
    if (e.key === 'Escape') {
      setOpen(false);
    }
  };

  window.addEventListener('resize', handleResize);
  window.addEventListener('scroll', handleScroll);
  document.addEventListener('keydown', handleKeydown);

  return () => {
    window.removeEventListener('resize', handleResize);
    window.removeEventListener('scroll', handleScroll);
    document.removeEventListener('keydown', handleKeydown);
  };
}, []);

With AbortController, the cleanup collapses to a single line:

useEffect(() => {
  const controller = new AbortController();
  const { signal } = controller;

  window.addEventListener('resize', () => setWidth(window.innerWidth), {
    signal,
  });
  window.addEventListener('scroll', () => setScrollY(window.scrollY), {
    signal,
  });
  document.addEventListener(
    'keydown',
    (e) => {
      if (e.key === 'Escape') {
        setOpen(false);
      }
    },
    { signal },
  );

  return () => controller.abort();
}, []);

The signal-based version is shorter and harder to get wrong. You can't accidentally forget to remove a listener — if it's attached to the signal, it gets cleaned up.

This also works nicely for combined fetch + event listener cleanup in a single effect:

useEffect(() => {
  const controller = new AbortController();
  const { signal } = controller;

  // Fetch data
  fetch(`/api/items/${id}`, { signal })
    .then((res) => res.json())
    .then(setItems)
    .catch((err) => {
      if (err.name !== 'AbortError') {
        throw err;
      }
    });

  // Listen for live updates
  window.addEventListener(
    'focus',
    () => {
      fetch(`/api/items/${id}`, { signal })
        .then((res) => res.json())
        .then(setItems)
        .catch((err) => {
          if (err.name !== 'AbortError') {
            throw err;
          }
        });
    },
    { signal },
  );

  return () => controller.abort();
}, [id]);

One controller, one cleanup line, and both the event listener and any in-flight fetches get cancelled together.

Composing signals with `AbortSignal.any()`

Sometimes you want to cancel an operation if any of several conditions are met. AbortSignal.any() combines multiple signals into one:

const userController = new AbortController();
const timeoutSignal = AbortSignal.timeout(10000);

const combinedSignal = AbortSignal.any([userController.signal, timeoutSignal]);

fetch('/api/data', { signal: combinedSignal }).catch((err) => {
  if (err.name === 'TimeoutError') {
    console.log('Timed out');
  } else if (err.name === 'AbortError') {
    console.log('User cancelled');
  }
});

// User can cancel manually at any time
cancelButton.onclick = () => userController.abort();

This is especially handy in React for combining a component-level abort signal with a user-triggered cancellation or a timeout.

Cancelling streams

AbortController works with both readable and writable streams. If you're consuming a streaming response, aborting the signal tears down the stream:

const controller = new AbortController();

const response = await fetch('/api/stream', {
  signal: controller.signal,
});

const reader = response.body.getReader();

try {
  while (true) {
    const { done, value } = await reader.read();
    if (done) {
      break;
    }
    processChunk(value);
  }
} catch (err) {
  if (err.name === 'AbortError') {
    console.log('Stream cancelled');
  }
}

// Call this from anywhere to stop the stream
controller.abort();

This is the right way to handle "stop generating" buttons for streaming AI responses, or cancelling large file downloads midway through.

Using the signal in your own APIs

AbortSignal isn't locked to built-in APIs. You can accept a signal in your own functions and respond to it:

function pollForUpdates(url, interval, { signal } = {}) {
  return new Promise((resolve, reject) => {
    const timer = setInterval(async () => {
      try {
        const res = await fetch(url, { signal });
        const data = await res.json();
        if (data.complete) {
          clearInterval(timer);
          resolve(data);
        }
      } catch (err) {
        clearInterval(timer);
        reject(err);
      }
    }, interval);

    // Stop polling when the signal aborts
    signal?.addEventListener('abort', () => {
      clearInterval(timer);
      reject(signal.reason);
    });
  });
}

// Usage
const controller = new AbortController();

pollForUpdates('/api/job/123/status', 2000, {
  signal: controller.signal,
});

// Stop polling
controller.abort();

By following the { signal } convention, your APIs compose naturally with AbortSignal.timeout(), AbortSignal.any(), and anything else that speaks the signal protocol.

In Node.js

Node.js has adopted AbortSignal across its core APIs. A few examples:

`setTimeout` / `setInterval`

const controller = new AbortController();

const timeout = setTimeout(
  () => {
    console.log('This might never run');
  },
  5000,
  { signal: controller.signal },
);

// Cancels the timer
controller.abort();

Child processes

import { exec } from 'node:child_process';

const controller = new AbortController();

exec('long-running-command', { signal: controller.signal }, (err) => {
  if (err?.name === 'AbortError') {
    console.log('Process was killed');
  }
});

// Kill the child process
controller.abort();

`fs.readFile` and `fs.writeFile`

import { readFile } from 'node:fs/promises';

const controller = new AbortController();

readFile('/path/to/huge-file.csv', {
  signal: controller.signal,
}).catch((err) => {
  if (err.name === 'AbortError') {
    console.log('File read cancelled');
  }
});

controller.abort();

Event emitters

import { on } from 'node:events';

const controller = new AbortController();

// Async iteration over events
for await (const [message] of on(chatSocket, 'message', {
  signal: controller.signal,
})) {
  console.log(message);
}
// Loop exits when controller.abort() is called

Wrapping up

AbortController started life as a way to cancel fetch requests, but the underlying pattern — a signal that broadcasts "stop what you're doing" — turns out to be useful everywhere. Event listeners, streams, timers, child processes, your own async functions... anywhere you need cooperative cancellation, AbortSignal is the standard way to do it.

The key takeaways:

{ signal } on addEventListener removes listeners automatically on abort — use it in React effects.
AbortSignal.timeout() creates a self-aborting signal after a delay.
AbortSignal.any() lets you combine multiple abort conditions.
Accept a signal option in your own async functions to make them cancellable.
Node.js supports signals in setTimeout, child_process, fs, events, and more.

If you're still writing manual removeEventListener cleanup or rolling your own cancellation booleans, give AbortController a proper look. It's already everywhere.

Publish Your Mastodon Posts to Astro

Mon, 29 Apr 2024 18:40:04 GMT

I'm a big fan of hosting your own content. Partly because I like keeping control over what I've posted, partly because platforms like ~~MySpace~~ some older video sharing sites will just lose all of your content that you hadn't backed up anywhere else because you were young(er) and stupid(er).

Since the implosion of The Site Formerly Known as Twitter, I've been using Mastodon to post infrequent nonsense that crosses my mind. With the Fediverse, it's certainly possible to run your own instance and own your content that way, but I was looking for a simpler solution to just copy the posts into the site here.

Anyway — whatever your reason — let's look at automatically importing Toots into Astro.

The General Workflow

How this is going to work is:

Make a post/toot on Mastodon
Trigger a webhook to grab the content of that toot as JSON
Write that JSON file directly into an Astro repository on GitHub
Trigger a build and deployment of the site

Easy, right? Let's get things set up to work.

Examining the Toot Structure

Getting the JSON representation of a Toot is pretty simple — copy the URL of a single post and add .json to the end of the URL. Doing that with a test toot gives us something like this:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "ostatus": "http://ostatus.org#",
      "atomUri": "ostatus:atomUri",
      "inReplyToAtomUri": "ostatus:inReplyToAtomUri",
      "conversation": "ostatus:conversation",
      "sensitive": "as:sensitive",
      "toot": "http://joinmastodon.org/ns#",
      "votersCount": "toot:votersCount",
      "blurhash": "toot:blurhash",
      "focalPoint": { "@container": "@list", "@id": "toot:focalPoint" }
    }
  ],
  "id": "https://mastodon.social/users/kwilson81/statuses/112357239872765151",
  "type": "Note",
  "summary": null,
  "inReplyTo": null,
  "published": "2024-04-30T00:03:42Z",
  "url": "https://mastodon.social/@kwilson81/112357239872765151",
  "attributedTo": "https://mastodon.social/users/kwilson81",
  "to": ["https://www.w3.org/ns/activitystreams#Public"],
  "cc": ["https://mastodon.social/users/kwilson81/followers"],
  "sensitive": false,
  "atomUri": "https://mastodon.social/users/kwilson81/statuses/112357239872765151",
  "inReplyToAtomUri": null,
  "conversation": "tag:mastodon.social,2024-04-30:objectId=696705597:objectType=Conversation",
  "content": "\u003cp\u003ePenny clearly excited to find out if this Cloudflare pipeline thing actually works... 🤞\u003c/p\u003e",
  "contentMap": {
    "en": "\u003cp\u003ePenny clearly excited to find out if this Cloudflare pipeline thing actually works... 🤞\u003c/p\u003e"
  },
  "attachment": [
    {
      "type": "Document",
      "mediaType": "image/jpeg",
      "url": "https://files.mastodon.social/media_attachments/files/112/357/232/898/119/052/original/14e0ac3b6bcebf12.jpg",
      "name": "Small Chorkie dog looking pensive.",
      "blurhash": "UHD93Kj;Na?F~U%1Ip%1^%%1xHbF%LoMRoWV",
      "width": 2499,
      "height": 3319
    }
  ],
  "tag": [],
  "replies": {
    "id": "https://mastodon.social/users/kwilson81/statuses/112357239872765151/replies",
    "type": "Collection",
    "first": {
      "type": "CollectionPage",
      "next": "https://mastodon.social/users/kwilson81/statuses/112357239872765151/replies?only_other_accounts=true\u0026page=true",
      "partOf": "https://mastodon.social/users/kwilson81/statuses/112357239872765151/replies",
      "items": []
    }
  }
}

For the setup I'm going for (at the moment), I'm only really interested in a subset of this data:

id
published
url
content
attachment

So that's what we'll be using inside Astro.

Creating a Toot Collection in Astro

Collections in Astro are stored under ~/src/content, so let's create a mastodon folder under there that will host the content.

We can now add a definition for that collection using Zod inside our ~/src/content.config.ts file. We'll just ignore attachments for now.

So that gives us this:

const mastodon = defineCollection({
  loader: glob({ pattern: '**/*.json', base: './src/content/mastodon' }),
  schema: z.object({
    id: z.string(),
    published: z.coerce.date(),
    url: z.string(),
    content: z.string(),
  }),
});

Looking at the JSON of the Toot, the ID is just the URL:

https://mastodon.social/users/kwilson81/statuses/112357239872765151

If we want to be able to have a local URL pointing at that content (something like mywebsite/notes/[tootId]) then we'll need to pull the numeric ID from the end of that so we have something specific that we can use to grab it.

We can do this at a collection level using a Zod transform:

const mastodon = defineCollection({
  loader: glob({ pattern: '**/*.json', base: './src/content/mastodon' }),
  schema: z
    .object({
      id: z.string(),
      published: z.coerce.date(),
      url: z.string(),
      content: z.string(),
    })
    .transform((data) => ({
      ...data,
      tootId: /(?<tootId>[A-z0-9]+$)/.exec(data.id)?.groups?.['tootId'] ?? null,
    })),
});

Now we've got a collection set up, let's look at pulling the data into the repo.

Cloudflare Worker

Cloudflare Workers are easy to use, fast, and free. So that makes them a good candidate for running our grabbing pipeline.

How we want this to work is:

Worker receives a POST with the Toot URL
Worker grabs the JSON data of the Toot
Worker uploads any image attachments to Cloudinary
Worker creates a new commit with the JSON file directly into the collection folder we created above

Again, let's break this down step-by-step.

The Basic Worker

Creating a basic worker with npm create cloudflare@latest will give us something like this:

export default {
  async fetch(
    request: Request,
    env: Env,
    ctx: ExecutionContext,
  ): Promise<Response> {
    return new Response('Hello World!');
  },
};

Now running npm run deploy will take you through the wizard to get that deployed into Cloudflare. I'm not going to go into the specifics of that, but you'll need to create an account and decide where your worker is going to be deployed to. This is all free though and a pretty simple process.

Here's a quick look at what that looks like for me:

Got that deployed somewhere? Okay, take a note of the URL and let's continue.

We want to validate that we can receive a POST with data such as { "uri": "https://the-toot-url/id" } so let's use Zod again (npm i zod) to set up validation for that:

import { z } from 'zod';

const schema = z.object({
  uri: z.string(),
});

export default {
  async fetch(
    request: Request,
    env: Env,
    ctx: ExecutionContext,
  ): Promise<Response> {
    const { uri } = schema.parse(await request.json());
    return new Response(uri);
  },
};

If we now POST to the URL of your worker, we should get that uri value echoed back to us:

> curl -d '{"uri":"http://test.invalid"}' \
       -H "Content-Type: application/json" \
       -X POST https://YOUR-WORKER-URL/

http://test.invalid

Now that we have a worker that can accept the URL as an input, let's grab the content from Mastodon.

Fetching the Toot

Remember how we could get the JSON for any toot by appending .json to its URL? That's exactly what we'll do here. We'll fetch the toot data, then validate it with another Zod schema:

const documentSchema = z
  .object({
    mediaType: z.string(),
    url: z.string(),
  })
  .passthrough();

const mastodonSchema = z
  .object({
    id: z.string(),
    published: z.string(),
    attachment: z.array(documentSchema).optional(),
  })
  .passthrough();

Using .passthrough() means the schema will validate the fields we care about while keeping all the other ActivityPub data intact. This is handy because the JSON structure is quite verbose — we don't need to define every field, just the ones we want to validate.

Now we can fetch and parse the toot inside the worker:

const { uri } = schema.parse(await request.json());

const response = await fetch(`${uri}.json`);
const postData = mastodonSchema.parse(await response.json());

Handling Image Attachments

If the toot has images attached, we need to deal with them. The attachment URLs point to Mastodon's file server, but we can't rely on those URLs being stable forever (which kind of defeats the purpose of archiving our content). So we'll upload them to Cloudinary and reference them from there instead.

First, we need a stable identifier for each image. The Mastodon URL itself is long and messy, so let's generate a SHA-256 hash of it:

import crypto from 'node:crypto';

const hashedAttachments = postData.attachment?.map((file) => ({
  ...file,
  urlHash: crypto.createHash('sha256').update(file.url).digest('base64url'),
}));

This gives us a short, URL-safe string we can use as both a Cloudinary public ID and a way to reference the image later in our Astro components.

Now we need to upload the images to Cloudinary. To do that, we'll use Cloudinary's Upload API with a signed request:

async function uploadImageToCloudinary(
  imageUrl: string,
  imageName: string,
  env: Env,
) {
  const timestamp = new Date().getTime();
  const api_key = env.CLOUDINARY_API_KEY;
  const api_secret = env.CLOUDINARY_API_SECRET;
  const folder_path = env.CLOUDINARY_UPLOAD_FOLDER_PATH;
  const cloud_name = env.CLOUDINARY_CLOUD_NAME;

  const signatureInput = [
    `folder=${folder_path}`,
    `public_id=${imageName}`,
    `timestamp=${timestamp}`,
  ].join('&');

  const signature = crypto
    .createHash('sha1')
    .update(`${signatureInput}${api_secret}`)
    .digest('hex');

  const parameters = [
    `api_key=${api_key}`,
    `file=${imageUrl}`,
    `folder=${folder_path}`,
    `public_id=${imageName}`,
    `timestamp=${timestamp}`,
    `signature=${signature}`,
  ].join('&');

  const response = await fetch(
    `http://api.cloudinary.com/v1_1/${cloud_name}/image/upload`,
    {
      method: 'POST',
      body: parameters,
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
      },
    },
  );

  return response;
}

The Cloudinary signed upload API requires you to create a SHA-1 hash of the upload parameters (alphabetically sorted) concatenated with your API secret. It sounds more complicated than it is — the key thing is that Cloudinary can then verify the request is legitimate without you needing to expose your API secret.

We can then upload all attachments in parallel:

await Promise.all(
  hashedAttachments?.map((attachment) => {
    return uploadImageToCloudinary(attachment.url, attachment.urlHash, env);
  }) ?? [],
);

Committing to GitHub

Now for the clever bit. Rather than having a server pull the repo, make a commit and push, we can use the GitHub API to create a commit directly. This is perfect for a serverless worker where we don't have a filesystem to play with.

We'll use Octokit, GitHub's official API client:

npm i @octokit/core base-64 utf8

The GitHub Contents API expects the file content to be base64-encoded, so we need to encode our JSON:

import { Octokit } from '@octokit/core';
import utf8 from 'utf8';
import base64 from 'base-64';

const octokit = new Octokit({
  auth: env.GITHUB_ACCESS_TOKEN,
});

const hashedPostData = {
  ...postData,
  attachment: hashedAttachments,
};

const contentBytes = utf8.encode(JSON.stringify(hashedPostData));
const encodedContent = base64.encode(contentBytes);

await octokit.request('PUT /repos/{owner}/{repo}/contents/{path}', {
  owner: 'YOUR-GITHUB-USERNAME',
  repo: 'YOUR-REPO-NAME',
  path: `src/content/mastodon/${postData.published}.json`,
  message: `new post - ${postData.published}`,
  committer: {
    name: 'Mastodon Post',
    email: 'mastodon@example.com',
  },
  content: encodedContent,
  headers: {
    'X-GitHub-Api-Version': '2022-11-28',
  },
});

A few things to note here:

The file path uses the toot's published timestamp as the filename (e.g. 2024-04-30T00:03:42Z.json). This gives us unique, chronologically sortable filenames for free.
You'll need a GitHub Personal Access Token with repo scope to write to your repository.
The committer can be whatever you like — I set it to something identifiable so I can see at a glance which commits were automated.

Environment Variables

The worker needs a few secrets to be configured. You can set these using the Wrangler CLI:

npx wrangler secret put GITHUB_ACCESS_TOKEN
npx wrangler secret put CLOUDINARY_API_KEY
npx wrangler secret put CLOUDINARY_API_SECRET

For the non-secret values, you can set them in your wrangler.toml:

[vars]
CLOUDINARY_CLOUD_NAME = "your-cloud-name"
CLOUDINARY_UPLOAD_FOLDER_PATH = "mastodon/images"

We also need to enable the nodejs_compat compatibility flag in wrangler.toml so we can use the crypto module:

compatibility_flags = ["nodejs_compat"]

The Full Worker

Putting it all together, the complete worker looks like this:

import { Octokit } from '@octokit/core';
import { z } from 'zod';
import utf8 from 'utf8';
import base64 from 'base-64';
import crypto from 'node:crypto';

const schema = z.object({
  uri: z.string(),
});

const documentSchema = z
  .object({
    mediaType: z.string(),
    url: z.string(),
  })
  .passthrough();

const mastodonSchema = z
  .object({
    id: z.string(),
    published: z.string(),
    attachment: z.array(documentSchema).optional(),
  })
  .passthrough();

export default {
  async fetch(
    request: Request,
    env: Env,
    ctx: ExecutionContext,
  ): Promise<Response> {
    const { uri } = schema.parse(await request.json());

    const response = await fetch(`${uri}.json`);
    const postData = mastodonSchema.parse(await response.json());

    const octokit = new Octokit({
      auth: env.GITHUB_ACCESS_TOKEN,
    });

    const hashedAttachments = postData.attachment?.map((file) => ({
      ...file,
      urlHash: crypto.createHash('sha256').update(file.url).digest('base64url'),
    }));

    const hashedPostData = {
      ...postData,
      attachment: hashedAttachments,
    };

    const contentBytes = utf8.encode(JSON.stringify(hashedPostData));
    const encodedContent = base64.encode(contentBytes);

    await Promise.all(
      hashedAttachments?.map((attachment) => {
        return uploadImageToCloudinary(attachment.url, attachment.urlHash, env);
      }) ?? [],
    );

    const result = await octokit.request(
      'PUT /repos/{owner}/{repo}/contents/{path}',
      {
        owner: 'YOUR-GITHUB-USERNAME',
        repo: 'YOUR-REPO-NAME',
        path: `src/content/mastodon/${postData.published}.json`,
        message: `new post - ${postData.published}`,
        committer: {
          name: 'Mastodon Post',
          email: 'mastodon@example.com',
        },
        content: encodedContent,
        headers: {
          'X-GitHub-Api-Version': '2022-11-28',
        },
      },
    );

    return new Response(JSON.stringify(result));
  },
};

Triggering the Pipeline with IFTTT

We've got a worker that can process a toot — but we still need something to trigger it when we actually post something. This is where IFTTT (If This Then That) comes in.

Mastodon provides an RSS feed for every user at https://mastodon.social/@YOUR-USERNAME.rss. IFTTT can monitor this feed and fire a webhook whenever a new item appears.

Here's the setup:

Create a new IFTTT Applet
For the "If This" trigger, choose RSS Feed → New feed item
Set the feed URL to your Mastodon RSS feed (e.g. https://mastodon.social/@kwilson81.rss)
For the "Then That" action, choose Webhooks → Make a web request
Configure the webhook:
- URL: Your Cloudflare Worker URL
- Method: POST
- Content Type: application/json
- Body: {"uri": "{{EntryUrl}}"}

The {{EntryUrl}} is an IFTTT ingredient that gets replaced with the URL of the new RSS item — which is exactly the toot URL that our worker expects.

Auto-Deployment

The final piece of the puzzle is getting the site to rebuild when a new toot is committed. If you're hosting on Cloudflare Pages (or Netlify, Vercel, etc.) and have it connected to your GitHub repository, this happens automatically — any new commit triggers a build and deployment.

So the full flow ends up being:

Post a toot on Mastodon
IFTTT detects the new post via the RSS feed
IFTTT sends the toot URL to the Cloudflare Worker
The worker fetches the toot JSON, uploads any images to Cloudinary, and commits the JSON file to GitHub
Cloudflare Pages detects the new commit and rebuilds the site
The toot appears on the site

All fully automated — post and forget.

Switching to Astro

Wed, 27 Mar 2024 17:30:00 GMT

This blog has been neglected for about 5 years and has been burning away compute cycles on an old Wordpress install and MySql DB. And I've been too ~~lazy~~ busy to update it to something that's not needlessly costing me £10/month.

But no longer. Now we're on Astro, taking advantage of static site generation and servicing everything through Cloudflare. Complete overkill for something like this, but it's a nice framework.

Split your cmder window into multiple panels

Sun, 26 May 2019 18:33:34 GMT

cmder is my go-to shell for Windows. Up until recently, I was unaware that it could be split into multiple panels.

There doesn't seem to be a menu option to do it, but it’s easily done with these commands (which, yes, I need to look up every time).

Split the window horizontally (left/right split):

cmd -new_console:s cmd /k ""%ConEmuDir%\..\init.bat" "

Split the window vertically (top/bottom split):

cmd -new_console:sV cmd /k ""%ConEmuDir%\..\init.bat" "

You can also sub-split the panels into whatever format works best for you.

Fix Error 0x80072EE7 on Windows 10

Thu, 04 Oct 2018 12:41:31 GMT

I just installed the Windows 10 October 2018 update and was hit with an issue that Microsoft Store and Edge wouldn't connect to the internet. Dreaded error 0x80072EE7.

Tried repairing etc. as suggested around the web, but the issue for me turned out to be that I didn't have IPv6 enabled in my network adaptor settings. I'm pretty sure it’s enabled by default, but I'd turned it off while trying to fix something else.

This setting here:

Enabled that and all working again.

It’s very probable that your issue is unrelated, but this fixed it for me.

UX Snippets: Avoid mismatching instructions and actions

Thu, 29 Sep 2016 18:46:28 GMT

Money Dashboard is an excellent app. Apart from when it’s telling me that I've gone over my monthly coffee budget.

Or when it gives instructions that don't match what you see on screen.

It’s not a huge deal since it’s pretty obvious what the intention is, but it’s just one more little mental leap that the user has to make to do something.

And we know that we shouldn't force users to think.

The horrible UX of the National Lottery website messaging system

Sun, 04 Sep 2016 17:59:46 GMT

Yes, I'm one of those fools that plays the lottery. Seeing as there’s no way I'm going to queue at the supermarket to get a paper version of my could-be-worth-millions lottery ticket, that means I have to suffer the official website if I want to play.

There are a fair few issues with it but I'm going to be concentrating on the messages system because it’s been driving me mad today.

1. I don't need messages on the site

Before we even get to the website, any messages are already emailed to me so 99% of the time (actually probably 100%) I've already read them by the time I get to the site so I've got no inclination to click through and read them again.

2. The message notifications get in the way

When I visit the site, I'm usually trying to accomplish something (like, y'know, buy a ticket). This isn't useful:

Even more galling is that not one of those messages has any more useful information in the body of the message than they have in the title.

3. The message notifications break scrolling

Okay, so the notifications take up at least 50% of the visible screen – I can still scroll past them, right?

Not really.

The 89 requests and 1.2Mb of content take about 4 seconds to load on my machine (and a couple of click trackers never load – thanks, AdBlock!). The main JS file (min.main-[someguid].js) is the last to load. When it does, the site jumps back to scroll position 0.

So, if you start scrolling down to the action buttons when the page loads, you get about 4s until you're thrown back up to the top.

4. There’s no option to mark all as read/delete all messages

Messages are so important that, when you go to the messages page (My Account > Messages [no direct link from home]) then there’s no way to click something to mark them all as read.

Also note that it is possible to win sometimes.

5. Links a click-jacked so you can't just bulk-open them all as read

By the time I got to this stage, I thought “Right, I'll just open all the messages in new tabs and that'll mark them as read“. Typical foolish optimism of a lottery player.

My plan was to middle-click (non-context click) each of the message links so that it would look as if I'd read them. But, alas, it seems that there’s a (poorly coded) click listener on the message links so using the middle-click opens a new tab with the message and also opens it in the current tab. Awesome.

Defeat

So here I sit – defeated and broken, clicking on each message in turn so that I can clear the notifications.

It almost makes it not worth winning anything…

Death of a Team

Fri, 11 Mar 2016 12:00:06 GMT

Q: What’s the fastest way to run a project into the ground?
A: Ask the team how long it'll take, then give them a shorter amount of time to complete it.

Recursive Failure

Once upon a time, I worked on a project that had the stink of death about it. It was old code, had dozens of hacks scattered throughout, known bugs that were not easily fixable, and dependencies on a buggy internal DLL library for which the source code was missing.

Prime candidate for a rewrite.

Since this was all consultancy based work, everything had to be chargeable to a client. When a new tender was released that the powers that be thought that this software could be applied to, the development team would be asked to put together estimates for the effort required to customise the software for the client and, from this (presumably), a bid would go in.

So, we'd get together and work out what was required.

Generally, our estimates would include the time to refactor some of the code that badly needed it – the goal was to have this software be something that could be easily configured for dozens of (eventually hundreds of) clients with little effort. Due to the various hacks and nonsense in the code, it'd take a couple of months to pull together something that mostly worked. I have to say “mostly” because, of course, the test coverage was 0%. So, it made sense to include refactoring time since it'd improve the workflow going forward.

An estimate would go in, something like:

15 days refactoring
25 days client specific
5 days technical debt
5 days testing
10 days contingency

About 12 weeks work to do a good job.

So, the bid would go in, and we'd win the work. Then we'd be told the budget was lowered to win the work, and we only had 6 weeks to deliver.

Refactoring and technical debt would be the first to go since it was important to show the client stuff working. Contingency? Haha – no.

Discussion around tasks would also be a “waste of time” since any time not coding “isn't productive”.

So everyone would jump into building stuff as fast as possible. The client would see updates, suggest changes (because the functionality wasn't quite what they wanted) and project managers would then argue with them because there wasn't enough time to redo stuff and the code that had been thrown together matched the vague requirements that had been signed off.

With two weeks of budget remaining, we'd likely have about a month of work still to do – the one consistent thing about working on broken code is that random small tasks will blow up occasionally and eat up days.

So, the last two weeks of the project, everyone will be working 14 hour days, including weekends (for no extra pay), just to get everything done.

And we'd meet the deadline.

The code would be low quality, the software would be buggy, the cumulative technical debt would loom ever higher, the client would be unhappy at some of the functionality, but we'd hit the deadline and ship.

And then another tender would come in. Rinse and repeat.

Out of that six person team, four quit within a year, and one requested to be taken off all work for that team. One poor soul is still there.

Nails

As a developer, I don't like to check in hacks or knowingly broken code. Sometimes it can't be helped – hotfixing code in production, last minute changes for a demo etc. – but it should never be the norm.

I also don't like to work long days regularly. In general, it’s bad for your health and your relationships.

Sometimes it’s fine. Hell, sometimes I'll get caught up in some problem and you'd have to fight me to take my laptop away at 3am. But that’s different. Developers are problem solvers and sometimes the problem becomes and all-consuming monster that will be on your mind until you beat it into submission. In those situations, it makes sense to work on the solution as long as it feels necessary.

I don't like to be working at 3am solely because there isn't enough time to meet the arbitrary deadline imposed for a piece of work.

In one of the cycles I mentioned above, my manager told me he didn't want me working long hours. I said that was great and asked if the deadline had moved. He said no. The deadline remained the same and had to be met, the amount of work was the same, and the team size was the same. He just didn't want me working long hours. I think that was my last cycle.

Diminishing Replacements

On projects like this, developers will start to look around for other jobs, maybe go on a few interviews.

Unless you're paying way above market rates (in which case, why are you penny-pinching with budgets?) or have amazing perks, your best developers are going to leave. And then you're going to have to try and hire quality replacements quickly since you have no contingency in your project budget. And that’s neither cheap nor easy. And just piles pressure onto the remaining team members.

Again, I've worked in places where a high percentage of developers who could leave, did. So what you mostly get left with are the devs who nobody else wants to hire, and the ones who don't care. That’s not a fun working environment. Believe me: I know. Ask me for horror stories sometime.

Solutions

So, as a manager, what can you do? When planning out work, keep this in mind:

time = features x quality of work

If your budget or deadline isn't big enough, you have to lose either features or quality. The alternative is artificially increasing time by overworking your developers and that’s going to lead to morale drops and team members quitting.

If you find that developers are working long hours regularly, have a look at the causation. Do you need more developers? Are your deadlines too short? Are you miscommunicating the importance of the work? Can you offer time in lieu or paid overtime to compensate?

(as an aside, I once worked three 90+ hour weeks in a row, then got given 2 days in lieu as thanks – oh how I laughed)

Is there a culture of overwork? Are the senior developers/managers/CEO seen to be working late night most nights? If so, they're setting a bad precedent for your company culture.

A good work/life balance is important, and that has to be pushed from on-high. Otherwise you're going to end up with a team of zombies.

Authorize Your Azure AD Users With SignalR

Thu, 25 Feb 2016 09:00:09 GMT

As with pretty much everything in the ADAL packages, this is something that seems like it should be pretty straight-forward, but isn't.

Before we go on to SignalR, we need to have a look at how we access a Web API endpoint that requires authentication from JavaScript. If you're already familiar with AD and bearer tokens, you can skip this bit.

It’s Easy in WebAPI

Okay, let’s say we have an OWIN app already set up to use Azure Active Directory for authorisation.

app.UseWindowsAzureActiveDirectoryBearerAuthentication(
  new WindowsAzureActiveDirectoryBearerAuthenticationOptions
  {
    Tenant = AppSettings["ida:Tenant"],
    TokenValidationParameters = new TokenValidationParameters
    {
      ValidAudience = AppSettings["ida:ClientId"]
    }
  });

This means that, in our controllers, we can do things like this:

[Authorize]
public abstract class UsersController : ApiController
{
  [HttpGet]
  public async Task&lt;IHttpActionResult&gt; GetUserName()
  {
    return Ok(ClaimsPrincipal.Current.Identity.Name);
  }

and only authenticated users will be able to hit that endpoint.

Including Authorize is enough to force users to authenticate to get through, and to populate ClaimsPrincipal.Current with the user credentials.

Connecting from JavaScript

Now we have our API endpoint, how do we access it from JavaScript?

Microsoft provide an Azure AD library for JS as part of the general Azure library. The example code only shows samples for using it with Angular. If you want to go down a less masochistic route and just use something like JQuery, then there’s also an annoyingly hard to find library of sample code for ADAL without using Angular.

The ADAL library provides a wrapper through which we can grab a bearer token to attach to any requests.

I don't want to go into this in too much detail since there are two full libraries of code samples linked above, but we'll end up with something like this:

namespace Security {
  var authContext;

  export function init(config) {
    const authConfig = {
      instance: config.instance,
      tenant: config.tenant,
      clientId: config.clientId,
      postLogoutRedirectUri: window.location.origin
    };

    authContext = new AuthenticationContext(authConfig);

    const isCallback = authContext.isCallback(window.location.hash);
    authContext.handleWindowCallback();

    if (isCallback && !authContext.getLoginError()) {
      window.location = authContext._getItem(authContext.CONSTANTS.STORAGE.LOGIN_REQUEST);
    }

    if (!authContext.getCachedUser()) {
      authContext.config.redirectUri = window.location.href;
      authContext.login();
      return false;
    }

    return true;
  }

  export function logOut() {
    if (authContext) {
      authContext.clearCache();
    }
  }

  export function acquireAuthToken() {
    var deferred = $.Deferred();
    authContext.acquireToken(authContext.config.clientId, (error, token) => {
      if (token) {
        deferred.resolve(token);
      } else {
        deferred.reject(error);
      }
    });

    return deferred;
  }
}

Once have have something like that set up, we can initialise then get bearer tokens from our client. Then we can add that token into our AJAX request and pass through to our Users API (from above).

// Auth config
if (!Security.init(config)) {
  // Stop app init if there is no user
  return;
}

Security.acquireAuthToken()
  .done((token) => {
    const jqSettings = {
      url: '/api/users/getusername',
      method: 'GET',
      beforeSend: (xhr) => {
        xhr.setRequestHeader('Authorization', `Bearer ${token}`);
      }
    };

    $.ajax(jqSettings)
      .done((username) => {
        console.log('username', username);
      });

So now that’s out of the way, how does that fit in with SignalR?

It’s Not Easy in SignalR

It’s not as simple to wrap up calls to a SinglaR hub to include a bearer token as it is with a raw AJAX request. But, we do have a simple method to append things to the query string.

$.connection.hub.qs = { key: value };

So, we'll use that to append the current bearer token to the hub connection when we have one. With our helper code from above, this becomes as simple as:

Security.acquireAuthToken().done((token) => {
  $.connection.hub.qs = { access_token: token };
  $.connection.hub.start();
});

(You may be concerned that the query string isn't a secure place to store the bearer token but, even using with an API call, the token is still stored unencrypted on the client side and sent with every request so this isn't much different. Bearer tokens are also transient so they'll be refreshed periodically.)

We now need to show the Hub how to get the bearer token.

Setting Up The Hub With AD

As with the Web API code above, the set-up for using AD with SignalR comes from the Microsoft.Owin.Security.ActiveDirectory NuGet package.

app.Map("/signalr", map =>
{
  map.UseWindowsAzureActiveDirectoryBearerAuthentication(new WindowsAzureActiveDirectoryBearerAuthenticationOptions
  {
    Provider = new QueryStringOAuthBearerProvider(),
    Tenant = AppSettings["ida:Tenant"],
    TokenValidationParameters = new TokenValidationParameters
    {
      ValidAudience = AppSettings["ida:ClientId"]
    }
  });

  map.RunSignalR(hubConfiguration);
});

This is pretty much the same as for Web API, with the exception of line 5 specifying a custom bearer token provider. It’s this class that will pull the bearer token from the query string value we injected on the client, and insert it into the AD pipeline.

There are a bunch of implementations of this around the web, but the version I ended up with is this:

public class QueryStringOAuthBearerProvider : OAuthBearerAuthenticationProvider
{
  public override Task RequestToken(OAuthRequestTokenContext context)
  {
    var value = context.Request.Query.Get("access_token");

    if (!string.IsNullOrEmpty(value))
    {
      context.Token = value;
    }

    return Task.FromResult&lt;object&gt;(null);
  }
}

All this is doing is pulling the token from the request query string and inserting it into the context. The ADAL helpers then process it as normal.

Authorizing the Hub

Now that’s done, we can add an Authorize attribute to our code to authenticate. The ClaimsPrincipal for the authorised user is stored in the Context.User property of the hub.

So, using these together, we get:

[Authorize]
public class UsersHub : Hub
{
  public async override Task OnConnected()
  {
    var user = this.Context.User as ClaimsPrincipal;
    Clients.All.newUserHasConnected(user.Identity.Name);
  }
}

And everything else Hub-related should continue to work as normal.

Get Your Web API Playing Nicely With SignalR on OWIN with Autofac

Thu, 18 Feb 2016 17:02:40 GMT

Niche, right? Yes. But this has caused me a day of headaches so posting here to save anyone else from the pain.

WebAPI

Say we already have Autofac set-up with your WebAPI. So we have something like this:

var builder = new ContainerBuilder();
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterAssemblyModules(Assembly.GetExecutingAssembly());

// Register the Autofac middleware FIRST, then the Autofac Web API middleware,
// and finally the standard Web API middleware.
app.UseAutofacMiddleware(container);
app.UseAutofacWebApi(config);
app.UseWebApi(config);

This is fine.

If we then follow the Autofac docs, we'll end up with something pretty similar for SignalR:

var builder = new ContainerBuilder(); // same as the one used for WebAPI
builder.RegisterHubs(Assembly.GetExecutingAssembly());

and then the Hub configuration:

// Get your HubConfiguration. In OWIN, you'll create one
// rather than using GlobalHost.
var config = new HubConfiguration();

// Register your SignalR hubs.
builder.RegisterHubs(Assembly.GetExecutingAssembly());

// Set the dependency resolver to be Autofac.
var container = builder.Build();
config.Resolver = new AutofacDependencyResolver(container);

// OWIN SIGNALR SETUP:

// Register the Autofac middleware FIRST, then the standard SignalR middleware.
app.UseAutofacMiddleware(container);
app.MapSignalR("/signalr", config);

Run this and (if you just have a default WebAPI set-up) we'll probably get a 404 for our SignalR hub. So we need to get WebAPI to ignore anything relevant to SignalR.

Ignore Routes

Before we map our main routes, we can tell the router to ignore anything under the SignalR path:

// Ignore anything to do with SignalR
config.Routes.IgnoreRoute("signalr", "signalr/{*pathInfo}");

// Rest of the routes
config.Routes.MapHttpRoute(
    "Default",
    "{controller}/{action}/{*id}",
    new {id = RouteParameter.Optional});

Here, we're just telling the WebAPI router to ignore anything that starts with ‘signalr‘. Now our hub paths should return properly.

But what about the dependency config?

Path Matching Config

You might have noticed that we have two calls to app.UseAutofacMiddleware(container) – which one do we use?

Rather than configuring everything directly onto the app object, we can use path matching to only inject the required Autofac dependency settings for SignalR.

Using this syntax, we can set up our code with a scoped middleware call:

app.Map("/signalr", map =>
{
    map.UseAutofacMiddleware(container);

    var hubConfiguration = new HubConfiguration
    {
        Resolver = new AutofacDependencyResolver(container),
    };

    map.RunSignalR(hubConfiguration);
});

(this replaces app.MapSignalR from above)

Note that we're setting the SignalR path explicitly as /signalr. We could change this if we wanted, but we'd need to also update our ignored routes above to match.

With that done, we can inject whatever we need from our container. The Autofac docs suggest injecting an ILifetimeScope into the Hub constructor so child objects can be disposed of properly (we do not want a memory leak) so it’s worth reading that if you haven't already.

public class MyHub : Hub
{
    private ILifetimeScope _hubLifetimeScope;

    public MyHub(ILifetimeScope scope)
    {
        _hubLifetimeScope = scope;
    }

    public void Ping(string text)
    {
        var clock = _hubLifetimeScope.Resolve&lt;IClock&gt;();
        Clients.Caller.Pong(clock.GetTime());
    }

    protected override void Dispose(bool disposing)
    {
        // Dispose the hub lifetime scope when the hub is disposed.
        if (disposing && _hubLifetimeScope != null)
        {
            _hubLifetimeScope.Dispose();
        }

      base.Dispose(disposing);
    }
}

An Email To Revolut Customer Services

Mon, 28 Sep 2015 13:26:28 GMT

Hi,

Just some background for context:

My partner and I got Revolut cards to come to the US last week. We'd both tried to use the cards online to verify they'd work (to pay for the ESTA fees) and all seemed to be well.

At the airport, I tried to use the card to pay for food and it failed due to an incorrect PIN. My partner tried hers and had the same issue. We'd both changed PINs using the app so thought there might be some issue with that.

I contacted customer services through the app and was told time and time again that my card was fine and we must be using the wrong PIN. By this time we were at the departure gate, so my partner called in to customer services while I continued to use text. The person she talked to had no ideas for what we could do so, worried that we'd run out of money on holiday, she transferred the money back to her account, being told it would take 3-5 working days.

After landing, I persisted with the text support and eventually was told that I needed to use the card in an ATM first after changing the PIN. Nowhere in the app does it warn you that this is required. So, that sorted, I now had a working card.

Today was the 5th working day since my partner transferred the money to her account but there’s still no sign of it. She contacted customer services again and was told there had been a problem with the payment service and nothing had been processed till Thursday 24th and she should wait till 5 working days from then. She’s asked repeatedly that someone help but just keeps being told there’s nothing Revolut can do.

We're in America and are running short on money because of your support staff’s continued misinformation and lack of help. This is ruining our holiday.

Why wasn't the payment processed till the 24th? And why were we not told this?

What can you do to help?

Switch Out Your Raygun API Key Depending on Web API Cloud Configuration

Thu, 13 Aug 2015 09:00:17 GMT

Raygun is an excellent tool that lets you know about more errors in your app than you would ever dare to fear were present.

Configuration is easy: install the NuGet package, add a couple of lines to your web.config and you’re ready to go.

When done, your config file will include:

<section name="RaygunSettings"
         type="Mindscape.Raygun4Net.RaygunSettings, Mindscape.Raygun4Net"/>

and

<RaygunSettings apikey="YOUR_APP_API_KEY" />

But, what if you want to install it within something like a Web or Worker Role on Azure? With these, you have ServiceConfiguration.Local.cscfg and ServiceConfiguration.Cloud.cscfg for configuration and they don’t support custom config sections.

App Registration

When you register the Raygun handler with your app, the default code looks like this:

var config = new HttpConfiguration();
RaygunWebApiClient.Attach(config);

This uses the API key from your config file to create a RaygunWebApiClient to report on errors. But, as we already know, we don’t have a config section.

To deal with this, the RaygunWebApiClient.Attach method has an overload that lets us provide an instance of the client. So we can use this to generate a new client using our cloud settings.

var config = new HttpConfiguration();

// Get a reference to whatever we use to pull cloud config
var configManager = container.Resolve<IConfigurationManager>();

// Get the API key for this config
var raygunApiKey = configManager.GetSetting("Raygun_api_key");

// Overload attach with a new client
RaygunWebApiClient.Attach(config, () => new RaygunWebApiClient(raygunApiKey));

Here, we’re pulling in a config manager instance to read out cloud settings (this example is using an Autofac container, but anything could be used) and then using the key value to construct a new instance (line 10).

Then, all we have to do is add the setting to our service definition file:

<ConfigurationSettings>
    <Setting name="Raygun_api_key" />
</ConfigurationSettings>>

and then the correct values for Local

<ConfigurationSettings>
    <Setting name="Raygun_api_key" value="my-local-api-key" />
</ConfigurationSettings>

and Cloud

<ConfigurationSettings>
    <Setting name="Raygun_api_key" value="my-cloud-api-key" />
</ConfigurationSettings>

Extended Information

If we’re using something like Azure AD to manage users, we can also add the user information to the constructor.

var config = new HttpConfiguration();

// Get a reference to whatever we use to pull cloud config
var configManager = container.Resolve<IConfigurationManager>();

// Get the API key for this config
var raygunApiKey = configManager.GetSetting("Raygun_api_key");

// Overload attach with a new client
RaygunWebApiClient.Attach(config, () =>
{
    var client = new RaygunWebApiClient(raygunApiKey);

    if (ClaimsPrincipal.Current != null)
    {
        client.UserInfo = new RaygunIdentifierMessage(ClaimsPrincipal.Current.GetUserId())
        {
            FullName = ClaimsPrincipal.Current.GetUserName(),
            Email = ClaimsPrincipal.Current.GetUserEmail(),
            IsAnonymous = !ClaimsPrincipal.Current.Identity.IsAuthenticated
        };
    }

    return client;
});

ClaimsPrincipal Get methods (lines 16–19) are using extensions to pull through valid data using null checks; those methods don’t exist on the raw object.

One important thing to note is that the constructor is called every time an instance is required, so it’s best to keep things like config value lookups outside of the Attach method.

Now we can look on in horror as the errors start flooding in.

Get Bluetooth Working on Windows 10 on Mac Book Pro

Wed, 05 Aug 2015 11:33:46 GMT

This worked for me; it might not work for you. Remember I'm just same random guy on the internet so I take no responsibility for anything that happens to your machine. Okay?

The Problem

As yet (5th Aug 2015) there’s no official support from Apple for Windows 10 running through Boot Camp. So, when I upgraded from Windows 8.1 to 10, I was expecting there to be a couple of issues. One of these was a lack of Bluetooth. Also getting the fn key working.

But, it turns out to be easy to fix.

Get the Driver

The driver for Windows 8.1 works with 10, so you just need to grab that.

Go to https://support.apple.com/en-us/HT204048 and find your machine in the list. You want to look for the zip file download of the Boot Camp Assistant software.

For me, it was this one:

Download that file (it’s pretty big – 882Mb for my one) and unzip that once done.

Install the Driver

Inside the unpacked folder, go into the BootCamp folder and then into the $WinPEDriver$ folder under that.

The driver needs to be installed via device manager so just confirm that the AppleBluetoothBroadcom64 folder is there for now.

In Windows, open up device manager (the easiest way to do this is just hit the Windows key and type ‘device manager' – it'll be the first result).

Expand other devices and you should see an unknown device.

Right click it and select Update driver software.

Chose the second option on the pop up to browse your computer for the driver software.

Browse to the $WinPEDriver$ from your downloads and select that. Make sure Include subfolders is checked and then click Next and Windows will install the Bluetooth driver for your Mac Book.

Get the FN Key Working on Windows 10 on Mac Book Pro

Wed, 05 Aug 2015 11:11:45 GMT

This worked for me; it might not work for you. Remember I'm just same random guy on the internet so I take no responsibility for anything that happens to your machine. Okay?

The Problem

As yet (5th Aug 2015) there’s no official support from Apple for Windows 10 running through Boot Camp. So, when I upgraded from Windows 8.1 to 10, I was expecting there to be a couple of issues. The main one for me was that the fn key wasn't working.

But, it turns out to be easy to fix.

Get the Driver

The driver for Windows 8.1 works with 10, so you just need to grab that.

Go to https://support.apple.com/en-us/HT204048 and find your machine in the list. You want to look for the zip file download of the Boot Camp Assistant software.

For me, it was this one:

Download that file (it’s pretty big – 882Mb for my one) and unzip that once done.

Install the Driver

Inside the unpacked folder, go into the BootCamp folder and then into the Drivers folder under that.

The keyboard is an Apple device, so go into the corresponding folder and you'll find AppleKeyboardInstaller64.exe. Run this installer and you get updated drivers and a working fn key.

Mushroom, Whisky & Mustard Steak Sauce

Sun, 12 Jul 2015 11:11:18 GMT

Ingredients

6 button mushrooms, sliced
1 clove garlic, crushed
1tbsp olive oil
2tbsp whisky
2tsp wholegrain mustard
120ml/8tbsp double cream
salt and pepper

Method

Heat the oil over a high heat then fry the sliced mushrooms for about 5 minutes or until golden.
Reduce the heat and add the crushed garlic, stirring all the time. Fry for a minute but be careful not to burn it.
Add the whisky and cook until most of it has evaporated.
Stir in the cream, then the mustard and simmer for 3-4 minutes until it's reduced enough to coat the steak.
Taste and season.

Enjoy.

Kevin Wilson

My Claude Team

Dev Teams

Skills

AbortController: the Swiss army knife of JavaScript

Aborting fetch requests

Fetch with a timeout

Cleaning up event listeners

In React effects

Composing signals with AbortSignal.any()

Cancelling streams

Using the signal in your own APIs

In Node.js

setTimeout / setInterval

Child processes

fs.readFile and fs.writeFile

Event emitters

Wrapping up

Publish Your Mastodon Posts to Astro

The General Workflow

Examining the Toot Structure

Creating a Toot Collection in Astro

Cloudflare Worker

The Basic Worker

Fetching the Toot

Handling Image Attachments

Committing to GitHub

Environment Variables

The Full Worker

Triggering the Pipeline with IFTTT

Auto-Deployment

Switching to Astro

Split your cmder window into multiple panels

Split the window horizontally (left/right split):

Split the window vertically (top/bottom split):

Fix Error 0x80072EE7 on Windows 10

UX Snippets: Avoid mismatching instructions and actions

The horrible UX of the National Lottery website messaging system

1. I don't need messages on the site

2. The message notifications get in the way

3. The message notifications break scrolling

4. There’s no option to mark all as read/delete all messages

5. Links a click-jacked so you can't just bulk-open them all as read

Defeat

Death of a Team

Recursive Failure

Nails

Diminishing Replacements

Solutions

Authorize Your Azure AD Users With SignalR

It’s Easy in WebAPI

Connecting from JavaScript

It’s Not Easy in SignalR

Setting Up The Hub With AD

Authorizing the Hub

Get Your Web API Playing Nicely With SignalR on OWIN with Autofac

WebAPI

Ignore Routes

Path Matching Config

An Email To Revolut Customer Services

Switch Out Your Raygun API Key Depending on Web API Cloud Configuration

App Registration

Extended Information

Get Bluetooth Working on Windows 10 on Mac Book Pro

The Problem

Get the Driver

Install the Driver

Get the FN Key Working on Windows 10 on Mac Book Pro

The Problem

Get the Driver

Install the Driver

Mushroom, Whisky & Mustard Steak Sauce

Ingredients

Method

Composing signals with `AbortSignal.any()`

`setTimeout` / `setInterval`

`fs.readFile` and `fs.writeFile`