DEV Community: Anthony Humphreys

Anvil

Anthony Humphreys — Sat, 20 Jun 2026 11:37:18 +0000

Building Anvil

Anvil did not start as a 'stack'. It still isn't, really, it is three independent projects that have a bunch in common and compliment each other quite nicely, so I decided to bundle them in a monorepo. This also makes it easier to keep the shared pieces in sync, and to make sure the projects are actually useful together.

The Anvil app started as a custom agentic coding harness inspired by T3Code: a practical way to run agents
inside real projects without pretending a chat window was the whole development environment. I wanted something that
could understand a repository, stay attached to a work item, preserve context across a delivery
loop, and help me move from intent to implementation without scattering the important details
across terminals, tabs, issue trackers, and whatever note I had optimistically named
plan-final-2.md.

That first version was deliberately narrow. It was built around the job I needed it to do: help
agents work inside software projects with enough grounding to be useful and enough structure to be
reviewable.

Over time, that narrow tool started pulling in more of the surrounding workflow. Not scope creep for the fun of it,
but because the lines between what counts as workflow, productivity and context all blurred into one, so having one place
where the work is planned, defined, implemented, checked, and reviewed became more useful than a tool that only ran agents.
I also really liked seeing the development of Claude's code review and codex similar features too. Only...they felt a bit lacking?
And in Claude's case, extremely expensive. So I built things like the code review feature which runs customisable rubrics against the codebase,
a PR or a commit, and has a pleasant UI to either post the feedback to the PR or action it.

Code does not happen in isolation. It sits inside tickets, docs, branches, pull requests, design
notes, deployment constraints, production incidents, and the tiny archaeological record of decisions
that live in a repo. If an agent only sees the current prompt, it is under-informed. If a developer
has to manually reconstruct context every time, the tool is not carrying enough weight.

From harness to ADE

The name I keep coming back to is an ADE: an agentic development environment.

That sounds a bit grand, so the useful definition is simpler: Anvil is becoming the place where the
work item, repository, agent session, and development context sit together.

The original harness was about running agents. The ADE shape is about supporting the whole path from
problem to reviewed change:

understand the work item
inspect the relevant repository state
plan the change against real constraints
make the implementation
run checks
review the diff
capture the reasoning
connect the output back to the work item system

That loop is useful for developers, obviously. But the target is wider than developers.

A product person should be able to understand what changed and why. A tester should be able to see
the acceptance criteria, the affected area, and the risks worth checking. A technical lead should be
able to review the work without piecing the story together from five separate systems. A support
person should be able to connect a customer issue to the code path that actually changed.

The point is not to make everyone write code. The point is to make the development context less
fragmented.

Repository awareness is the grounding layer

The most important Anvil idea is still repo awareness.

Agentic coding gets much better when the agent can read the project before making claims about it.
That sounds obvious, but a lot of AI tooling still behaves as if a confident answer is roughly
equivalent to an inspected codebase. It is not. Confidence without repo context is just a well-lit
guess.

Anvil treats the repository as the grounding layer. The agent should know the file tree, current
diff, conventions, scripts, tests, docs, and local project rules. It should understand whether a
change belongs in an existing module or whether the new abstraction it is about to invent is solving
a real problem.

That grounding matters because the work item alone is not enough. Tickets are useful, but they are
usually compressed versions of reality. The repo contains the real constraints: the old migration,
the wrapper nobody wants to touch, the half-finished test helper, the auth boundary that has to
remain a real boundary.

Anvil works best when the work item and repository context are held together. The ticket says what
the change is for. The repo says how it can actually fit.

The workspace idea

The workspace concept borrows heavily from VS Code.

That is intentional. VS Code got something very right: a workspace is not just a folder. It is the
local operating context for a piece of work. Files, settings, extensions, terminals, tasks, source
control, and developer habits all gather around that boundary.

Anvil uses a similar idea, but aims it at development context rather than only editing context. A
workspace can hold the repo, linked work items, agent sessions, notes, checks, and eventually more
of the surrounding SDLC state.

That matters because software teams rarely work on "a repo" in the abstract. They work on a
workspace shaped by the current project, product area, branch, issue, environment, and release
target. If Anvil can preserve that shape, agents can do more than answer prompts. They can work
inside the same frame as the people around them.

Then came Anvil Registry

Anvil Registry came from a different but related concern: supply-chain security.

npm install is a lot of trust hidden behind a short command. It can run lifecycle scripts. It can
pull hundreds of packages into a project before anyone has looked at what changed. It can turn a
typo, a compromised maintainer account, a package-confusion mistake, or a suspicious new release
into executable code on a developer machine or CI runner.

That problem exists with or without agents. Most teams already rely on a huge amount of third-party
code, and the install path is one of the places where trust becomes execution very quickly. Anvil
Registry started as a set of countermeasures for that problem: put a deliberate control point in
front of dependency installs, make package decisions inspectable, and avoid treating upstream
registry traffic as harmless just because it is normal.

Anvil Registry puts a controlled gateway between package managers and upstream registries. The
gateway speaks the npm registry shape that existing tools already understand, then applies policy
before tarballs are handed over. In practical terms, it is trying to solve a few connected problems:

make install traffic inspectable instead of invisible
cache package metadata and tarballs so decisions are tied to the artefact that was actually seen
apply deterministic policy before code reaches the project
queue deeper analysis outside the hot install path
give humans explainable decisions, reports, and override controls
provide a safer local path for unknown repositories through the Node Base devcontainer image

The architecture is deliberately boring in the places where boring is a virtue. Package managers
ask Registry for metadata and tarballs. Registry checks policy and package identity, proxies and
caches upstream artefacts, records decisions, and hands work to an analysis worker. The worker can
inspect manifests, package contents, provenance signals, file trees, lifecycle script usage, and
other risk indicators. The CLI and admin surfaces then give people a way to explain a decision,
scan packages, warm caches, review reports, and manage overrides.

The important line is authority. AI-assisted review can help summarize suspicious patterns or point
at things worth checking, but it does not get to be the enforcement layer. Deterministic policy owns
the gate. Humans own the judgement.

That makes Registry useful on its own, even if there is no agent anywhere near the repo. It gives
developers and teams a more inspectable install path, a place to encode policy, and a way to review
exceptions without pretending every dependency decision can live in someone's head.

That project pushed Anvil beyond "how do agents edit code?" into "what infrastructure does agentic
development need around it?"

The agentic angle is a bonus, but it is a real one. Agents can move quickly through unfamiliar
repositories, which means dependency changes can become part of a larger automated edit loop. In
that world, having a checkpoint in front of install traffic matters even more. "The model probably
noticed" is not a security boundary.

It was also the first time I built a substantial project using Codex /goal. That became its
own post because the process mattered: write the spec first, let Codex work against a concrete
target, keep running checks, and keep the human decision-making where it belongs. I wrote more about
that build in Building Anvil Registry With Codex.

Registry is part of the same larger bet as Anvil Desktop: better delivery requires better context.
Sometimes that context is a work item and a diff. Sometimes it is package identity, provenance,
tarball contents, and install policy.

Now Anvil Cloud

Anvil Cloud is the piece I was slowest to describe properly, because it sounds like a hosted-agent
story if you say it too quickly.

It is not that.

The motivation is more specific: agents work best when the world they are editing is small,
explicit, and inspectable. Cloud infrastructure is usually the opposite. A useful app quickly runs
into auth, data, files, jobs, logs, queues, environment variables, deploy state, gateways, IAM, and
provider-specific defaults. Those are awkward enough for humans. They are a very sharp surface for
generated code.

There are a few interesting projects circling this problem from different directions. SST
makes full-stack infrastructure much more approachable by defining app resources in code and keeping
those resources linked to the application. Lakebed pushes toward an
agent-native shape: small TypeScript apps with a CLI/runtime that an agent can create, inspect, and
deploy without wandering through a cloud console.

I found SST to be amazing, but agents constantly trip over nuance as soon as you get to any sort of level of
complexity. Lakebed is a very interesting approach, and I really love the pitch of 'a shitty cloud for shitty apps'.
But I wanted something that could be used for production apps, not just a playground. I wanted a shape that could be used
for real work, but still small enough to be inspectable, testable, and reviewable before it becomes real infrastructure.

Anvil Cloud is my version of that problem space, built around the Cell contract rather than
raw infrastructure.

An Anvil Cell is a small TypeScript app unit. It can contain server handlers, client UI, schema,
endpoints, jobs, workflows, services, mounted agents, and declared capabilities. The important bit is
the boundary: Cell code should use Anvil runtime primitives like ctx.db, ctx.files, ctx.env,
ctx.log, jobs, and workflows. It should not import AWS SDKs, SST, CDK, Terraform, Pulumi, or raw
provider resources just to build a small app.

The platform pieces exist to make that boundary useful:

Runtime runs the same request contract locally, in tests, and behind deployment adapters.
Builder emits the server bundle, client bundle, manifest, generated client metadata, and build output.
Guard checks imports, direct environment access, outbound fetches, and undeclared capabilities before the app turns into provider work.
Lens and the CLI expose manifests, logs, auth state, database state, workflows, services, and diagnostics in forms humans and agents can inspect.
Deployment adapters map the Cell's capabilities to provider resources. AWS is the first adapter, but AWS is not the app contract.

Cloud's job is not to "run an agent somewhere". It is to give agents and developers a smaller
application model that can become real infrastructure without making the app author hand-roll the
provider machinery.

Cloud is early alpha. The local runtime, builder, Lens, CLI, auth, workflow, service, agent, and AWS
preview work are moving together, but the important thing is the contract. If a Cell can
be built, checked, inspected, and planned before it touches a provider, the system has a fighting
chance of being useful without becoming a very confident infrastructure accident. This feels like a solved
problem with terraform and SST, but those tools are not designed for agentic development. How many times have
you deployed using terraform only to later find your lambda is missing a permission that is only needed at runtime?
Or your SST app is failing because the agent generated a resource that is not actually supported by the provider?

Where this is going

The direction is clear enough now.

Anvil started as an agentic coding harness because that was the immediate problem. It is becoming an
ADE because the real problem is broader: development with agents needs clear boundaries around the
work, the code, the dependencies, and the runtime.

Anvil Registry added a boundary around dependency ingress.

Anvil Cloud adds a boundary around the apps agents and developers build: the Cell contract, the
runtime, the manifest, the checks, the inspection surface, and the adapter path to real providers.

Together, they point at a more complete environment for building software with agents involved, but
not with judgement outsourced to them. Developers should get deeper repo-aware assistance. Product,
QA, support, and technical leadership should get clearer context. Teams should get a delivery loop
with fewer mystery steps and more things you can inspect before they matter.

The aim is to keep the useful parts of agentic development grounded: tied to the repo, checked
against the work, explicit about risk, and boring enough to review before it reaches production.

[Boost]

Anthony Humphreys — Sat, 03 Jan 2026 16:36:20 +0000

I Built an AI Tool to Practise GMing — Because “Prep” Isn’t the Same as “Practice”

Anthony Humphreys ・ Jan 3

#webdev #ai #vercel #rpg

I Built an AI Tool to Practise GMing — Because “Prep” Isn’t the Same as “Practice”

Anthony Humphreys — Sat, 03 Jan 2026 15:43:05 +0000

I love TTRPGs. The storytelling, the improvisation, the moment when a table really clicks. However, I've only recently started GMing, and I love it.

But I also noticed something odd:

GMing is a performance role, and we’re expected to perform… without ever really being able to rehearse.

Actors rehearse. Musicians rehearse. Developers practise in sandboxes.
Game Masters? We just… show up and hope for the best.

That gap is why I built GMprentice.

Prep ≠ Practice

There are plenty of tools for GMs:

Worldbuilders
Encounter generators
NPC name generators
AI tools that spit out lore or dialogue

They’re all about prep.

But prep doesn’t teach you how to:

Handle players going off-script
Make rulings under pressure
Manage spotlight and pacing
Recover when an encounter falls flat
Improvise when the party surprises you (which they always do)

Those are performance skills, And performance skills need practice.

The Real Problem: There’s No Safe Place to Fail

Most GMs I know don’t struggle with rules knowledge.

They struggle with confidence.

You can’t really practise:

Emotional scenes
Awkward rulings
High-stakes moments

…without real people at the table, and failing in front of friends can feel awful.

So most of us just learn by doing — publicly, imperfectly, sometimes painfully.

I wanted a private, judgement-free space where GMs could practise first.

Why AI (and not just “ChatGPT for D&D”)

GMprentice isn’t a single chatbot.

The core idea is:

Simulate a party, not an assistant.

That means:

Multiple AI “players”
Distinct personalities and playstyles
Disagreements, misunderstandings, bad ideas
The kind of chaos that makes GMing… GMing

The goal isn’t to generate content for you.

It’s to push back, derail plans, and force you to react.

In other words it is a sandbox for training, not shortcuts to running a campaign.

What GMprentice Is (and Isn’t)

It is:

A rehearsal space
A sandbox to test encounters, rulings, and roleplay
A way to build confidence before game night

It isn’t:

A replacement for real players
A replacement for the real creativity and art which is created in a real session
A rules engine
A content mill

If anything, it’s closer to a flight simulator than a writing tool.

Building It as an Indie Maker

From a technical perspective, the interesting challenge wasn’t “AI output quality”.

It was:

Maintaining consistent personalities across multiple agents
Balancing unpredictability without turning things into nonsense
Making failure feel useful, not frustrating
Keeping the GM firmly in control

I’ve been deliberate about avoiding the trap of “AI does everything”.

GMprentice works best when it resists you a little.

I built this app using Cursor, with extensive use of GPT 5.2 in 'Plan Mode' in Cursor, and Opus 4.5 for implementation and iteration of features.

I made extensive use of the Cursor Browser feature to work on finer details of styling and layout, with implementation assistance from Opus 4.5 working as a pair programmer.

This is the first time I've truly been shocked by coding LLMs. GPT 5.2 was planning for edge cases and scenarios that I had not initially considered and that would've only emerged in end-to-end testing. Opus 4.5 implemented features and styling changes almost flawlessly. The only major missteps were around Auth0 configuration and creating a middleware.ts instead of the newer proxy.ts expected in a NextJS 16 app.

This was a genuinely awe inspiring build, and I urge anyone cynical about AI coding agents, or who doesn't believe in their abilities to give them a try. You won't be disappointed.

I have also found the cognitive load of building an app like this is like nothing else I have experienced. I'm no longer laser focused on styling and feature execution, but I'm thinking about the core user experience more, I'm thinking about user journeys, conversion opportunities, and product vision more than nuanced detail which is really just noise. Using LLM coding agents this way frees you and empowers you to ship faster than ever, and deliver real production code that without LLM involvement - I probably wouldn't have had time to build something like this.

Why I Think This Matters

Tabletop RPGs are growing faster than ever.

More people want to GM — but GMing is still intimidating.

If we want more confident, inclusive, creative tables, we need better tools for learning the craft, not just preparing notes.

Practising privately shouldn’t be a luxury.

It should be normal.

What’s Next

GMprentice just launched, and it’s very much a work in progress.

I’m especially interested in:

Feedback from experienced GMs
How different playstyles feel in simulation
Where AI helps — and where it absolutely shouldn’t

If you’re curious, you can check it out here:

👉 https://gmprentice.app

And if you’re a GM:

What’s the one thing you wish you could practise before a session?

Advent of Code 2025: Human vs AI

Anthony Humphreys — Wed, 03 Dec 2025 08:51:37 +0000

❄️ What I’m Doing

Every day I’ll solve the Advent of Code puzzle in:

JavaScript
Rust
Python

Then I’ll ask a lineup of current AI coding models to produce their own solutions in the same three languages:

GPT-5.1 Codex
Gemini 3 Pro
Composer-1
Opus-4.5
Sonnet-4.5

So for each puzzle, there will be:

My human solutions (in three languages)
Five AI solutions (also in three languages each)

It’s essentially a coding “showdown,” but not a competition. The real aim is to explore how different kinds of reasoning appear in code, how approaches vary from model to model, and how my own thinking compares.

Methodology

Not a lab-grade study, just a consistent, lightweight workflow so the comparison stays fair.

For each challenge, after solving the problem manually, I will drop the challenge text into a txt file in the prompts folder, prepended with a brief prompt:

You are a developer taking on the Advent of Code Challenge 2025.
Create a solution for this problem.
This puzzle has two parts, solve both in the same solution. The program output should just be the two answers on separate lines.

I will aim to keep this prompt consistent across the days, only varying on the output format as needed. I then drop the input file into the inputs folder. In cursor, I select the model under test and then @ the file, the prompt, and the target directory, then hit run. No MCPs, no MAX mode, or anything else to avoid any confounding variables, and to minimise context bloat.

I then run the run_solutions.py python script to verify the output and review the "thinking" of the model. I'll improve this and the reporting as I progress - but this works as a starting point.

Once I've verified the output, I add the model directory to the .cursorignore

Note: The model solves for all three languages and is able to reference its own prior solutions, e.g. it can start in Python and then translate that to JS and Rust. I appreciate it would be interesting to see how it stacks up when the model can only work in one language at a time, and I may run that as a second iteration of this experiment. However - the prompt does not instruct the model to execute in a particular language first, and I too can reference my own solution in other languages - so I thought this would be interesting in itself.

🎁 Why This Experiment?

To understand how AI actually solves problems

Advent of Code puzzles are a perfect testbed: small enough to be self-contained (and not burn too many tokens/£!), but clever enough to require genuine reasoning and creativity. Watching how different models break them down is already proving fascinating, and analysing the end results may yield some interesting insights.

To improve my own fluency

Solving each puzzle three times in three different languages forces me to think more deeply about patterns, algorithms, and idioms. It’s a great way to keep my skills sharp, and explore some different languages to what I use day to day.

To observe differences in style and structure

Where a model chooses brute force, I choose planning and analysis.
Where I focus on solving the problem and don't worry about failure modes (as the code is only run with known inputs in a known environment, AI may be much more defensive and write more flexible code.
Where AI might use packages to solve a problem, I may avoid it and stick to language features and standard lib. These contrasts say a lot about how “AI thinking” manifests in code.

To build a dataset of human + AI approaches

By the end of AoC, even with only 12 challenges this year, that still gives me dozens of solutions across languages and models — plenty to analyse! I’ll have dozens of solutions that all answer the same questions from different angles. That’s an interesting resource in itself.

🤖 What I’ll Be Sharing

As the month goes on, I’ll post insights on things like:

patterns the AIs gravitate toward
performance of the output code (hey, perf stats can be fun)
common mistakes or blind spots
whether models one-shot solutions or needed some handholding
places where models outperform my first instincts or develop more novel solutions
language-specific quirks (Rust borrow checker vs AI… pray for it)
what it feels like to “pair” with multiple coding models
other random thoughts and musings on AI, Cursor and model nuances

The goal isn’t to crown a winner. It’s to understand the landscape of coding in 2025, where AIs shine, where they show their limitations, and how the two complement each other. Will the models one-shot all the solutions or will it pivot into re-prompting or "pair-programming"?

🌟 Follow Along

If you enjoy Advent of Code, programming language experiments, or the evolving relationship between developers and AI tooling, stick around. I’ll be posting reflections and curiosities throughout the month, followed by a round-up at the end of the challenges.

Here’s to a December full of puzzles, head-scratching, learning, and some very weird debugging moments.

Happy coding, and an even happier Advent. 🎅🔥

Introducing Edon

Anthony Humphreys — Sun, 17 May 2020 01:29:49 +0000

What is Edon?

Edon is the name I'm giving to a little corner of the internet, over on GitHub for the JavaScript community to engage in Deno development. I'll be keeping this repo up to date with the upstream repository, and will be regularly opening Pull Requests from this repo into Deno. Edon is founded on the idea that everyone should feel safe, supported and encouraged to contribute to open source. There is no space for any discrimination of any kind, or any behaviour which deters anyone from contributing. I believe in Learning in Public, mentoring and lifting others up, not bringing them down.

Why does this exist?

Mainting a separate repo and all that merging sounds like a nightmare, right? Well, I'll archive the repository once Deno has a solid Code of Conduct and the core contributors are seen to be taking their role in supporting a community more seriously.

The Deno team has, so far, seemed reluctant to take the issue of not having a Code of Conduct seriously.

Very early in the project someone opened an issue regarding the lack of a CoC
CLOSED

Soon after, [once again(https://github.com/denoland/deno/issues/670), someone suggested adding a CoC. This time it was dismissed, preferring to focus on functionality, and code style.
CLOSED

A little over a year later, an incident occurs in discussing an issue, and a CoC is once again suggested.
CLOSED

Next another user suggested a CoC, this was dismissed with a link to another issue, with a comment

I certainly agree that we should all be professional. But I don't like having all these non-necessary files in the root directory. If you want to add a section in the manual linking to a code of conduct that would be ok. Feel free to email me if there has been some problem (?) ry@tinyclouds.org Closing without merge.
This is a little bit of progress, recognising something is needed, but dismissing a CoC for cluttering the repo seems...misguided.
CLOSED

As 1.0 launch approached, someone proposed a CoC once again.
LOCKED OFF TOPIC

Yet another attempt was made to add a CoC
CLOSED

Finally a link is added to a CoC... but wait it isn't Deno's CoC, but Rust's! Close enough right? Not really. Took a further commit to add an email address for concerns. Although this is sufficient to express expectations, it still feels like the least amount of effort being put into this issue.

Unsurprisingly, issues, keep coming

Why does it matter?

I feel like I really shouldn't need to answer that question, but I expect I'll probably draw some flak for this post. This is an important issue, not only close to my heart, but a common issue in Open Source today.

Please see the Contributors' Covenant FAQs for more information.

Please also check out these studies looking at the efficacy of Codes of Conduct in OSS.

Code of Conduct in Open Source Projects

Why modern open source projects fail

Open Source Software Community Inclusion Initiatives to Support Women Participation

Diversity and decorum in open source communities

Patterns for regulating behavior in innovation communities

Emotional Labor of Software Engineers

Discovering community patterns in open-source: a systematic approach and its evaluation

Why Modern Open Source Projects Fail

Adopting a Code of Conduct is not a magic bullet solution and should not be seen as such. It is instead a social contract, signalling to a community that a certain set of standards are expected, and signalling to potential contributors that they are engaging in a safe and supportive community. Building a community takes hard work, commitment, and above all, empathy.

So what next?

Deno is a promising project. But it doesn't bode well if issues like this are flaring up and being dealt with in this manner at such an early stage.

Deploying a Gatsby site to Google Cloud Run

Anthony Humphreys — Fri, 15 May 2020 21:47:29 +0000

Building the Gatsby site

You don't need to do anything particularly special to build a Gatsby site for deployment to Cloud Run, but there are some steps between building the project and seeing it live.

For this tutorial (and for my blogs) I'll use gatsby-starter-hero-blog starter.

Getting up and running is simple (make sure you have the gatsby cli installed correctly first)

gatsby new anthonyhumphreysdev https://github.com/greglobinski/gatsby-starter-blog,

then you can run your site locally with

gatsby develop.

After customising the template to your liking (have a poke around, check out the gatsby & starter docs for more guidance!), setting up some content and an initial post, it's time to deploy a test build.

I decided to use GitHub Actions and Cloud Run to do this. GitHub actions is the new kid on the block for CI/CD, but it's such a nice experience, especially being so closely coupled to your actual source repo. I use Cloud Run for Lexio and love its ease of use and general developer experience.

You'll need to set up some environment variables for the gatsby starter and for the GitHub action workflow. These should be clear from the starter's docs, and from the source below. You can set secrets in the GitHub repo

You can checkout the full action YAML here:

I simply use the Node action to install dependencies and build the site.

- name: Setup NodeJS
  uses: actions/setup-node@v1
  with:
    node-version: "10.x"
- name: Install dependencies
  run: |-
    yarn global add gatsby-cli
    yarn
- name: Gatsby Build
  run: yarn build

That's all there really is to it as far as building the site goes - no different to building on your own machine...but we still need a few bits and pieces yet.

Cloud Run

Before continuing, you'll need to provision a new service in Cloud Run (assuming you have a Google Cloud account and Project set up!). Make a note of the Service Account Email Address, Project ID, Service Name, as you will need these later.

Building and Deploying the Docker Image

I had a few issues with the Gatsby Docker image so rolled my own...probably should've stuck with it and resolved my issues, but it worked so that's just a // TODO: Use gatsby image instead!

Dockerfile

FROM nginx:latest

COPY public /usr/share/nginx/html
COPY nginxconf/nginx.conf /etc/nginx/nginx.conf

EXPOSE 8080

If you're not familiar with Docker - all that's happening here is I use the latest version of the nginx image from dockerhub. I copy the files built in the previous step, which are in the public directory, to the /usr/share/nginx/html directory in the container, and then copy the nginx.conf file from the project to the container too. The last thing I do is EXPOSE 8080 which opens up port 8080 for the container.

Nginx Config

I won't go into Nginx as a reverse proxy, there are plenty of blog posts about that around already. You can however find the config I used below:

events {}
http {
    server {
        listen 8080;
        server_tokens off;
        location / {
            include /etc/nginx/mime.types;
            autoindex on;
            root   /usr/share/nginx/html;
            index  index.html index.htm;
            try_files $uri $uri/ /index.html;
        }
    }
}

Before I can push the image I need to setup GCloud in order to talk to Google's Cloud Registry:

- name: Setup GCloud
  uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
  with:
    version: "286.0.0"
    service_account_email: ${{ secrets.RUN_SA_EMAIL }}
    service_account_key: ${{ secrets.GCLOUD_AUTH }}
    project_id: ${{ secrets.RUN_PROJECT }}

Then I build the image

- name: Build Docker Image
  run: docker build . -t "eu.gcr.io/$PROJECT_ID/$SERVICE_NAME:$GITHUB_SHA"

Now, I authenticate and publish the image

- name: Authenticate for gcr
  run: gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://eu.gcr.io/$PROJECT_ID
- name: Push Docker Image to gcr
  run: docker push eu.gcr.io/$PROJECT_ID/$SERVICE_NAME:$GITHUB_SHA

The final step is to deploy a new revision of the service to Cloud Run

- name: Deploy
  run: |-
    gcloud run deploy $SERVICE_NAME \
      --quiet \
      --region $RUN_REGION \
      --image eu.gcr.io/$PROJECT_ID/$SERVICE_NAME:$GITHUB_SHA \
      --platform managed \
      --allow-unauthenticated

Adding a post

Simply add a new post under content/posts following the naming convention, commit your changes and push - when your changes hit the master branch, the Action will run and update your site. Magic, right?

Hopefully you can now browse to the url for the service and see your brand new site! If I have skimmed over any steps or if anything isn't clear, hit me up on Twitter and I'll clear things up!

useSyncedState

Anthony Humphreys — Fri, 15 May 2020 21:45:58 +0000

Synced State Experiment

After working on useLocalStorage, I wondered how hard it would be to sync state to persistent, distributed storage. For my 5th Day of 100 Days of code I decided to make a first attempt at this idea.

I followed the same pattern as for building the useLocalStorage hook, extending the useState API, and triggering a useEffect on the state update to handle the state synchronization...asynchronously8.

Without further ado, here's the code...I'll be working more on this. At the moment, this might be useful for a use case such as building a user profile. A common poor experience is filling out some information and boom you've hit refresh, or swiped back on the trackpad...this scenario is already resolved by the localStorage hook, but I thought it would be cool to explore binding state to an API. The current implementation is geared around a REST API, so next steps will be to look at passing a query/mutation to the hook.

I'm also thinking about how to hook this up to a useReducer, passing in the reducer function to determine how to manage state.

import { useState, useCallback, useReducer, useEffect } from "react";

type State = {
  success: boolean;
  loading: boolean;
  error: boolean;
};

type Action = {
  type: "loading" | "success" | "error";
  syncedState?: object;
};

const initialState: State = {
  success: false,
  loading: false,
  error: false,
};

const reducer = (state: State, action: Action): State => {
  switch (action.type) {
    case "success":
      return { success: true, loading: false, error: false };
    case "loading":
      return { success: false, loading: true, error: false };
    case "error":
      return { success: false, loading: false, error: true };
    default:
      return state;
  }
};

const SYNC_URL = "https://localhost:3000";

export const useSyncedState = (
  key: string,
  initialValue: string,
  delay: number = 1000,
  syncUrl: string
): [State, any, Function] => {
  const [state, dispatch] = useReducer(reducer, initialState);

  const syncToServer = useCallback(async (valueToStore: object) => {
    dispatch({ type: "loading" });
    const response = await fetch(SYNC_URL, {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      body: JSON.stringify(valueToStore),
    });
    response.ok ? dispatch({ type: "success" }) : dispatch({ type: "error" });
  }, []);

  const syncToClient = useCallback(async () => {
    dispatch({ type: "loading" });
    const response = await fetch(SYNC_URL, {
      method: "GET",
      headers: new Headers({ "Content-Type": "application/json" }),
    });
    response.ok
      ? dispatch({ type: "success", syncedState: await response.json() })
      : dispatch({ type: "error" });
    return response.json();
  }, []);

  const [syncedValue, setSyncedValue] = useState<object>(async () => {
    try {
      const syncedState = await syncToClient();
      return syncedState ?? initialValue;
    } catch (error) {
      console.error(error);
      return initialValue;
    }
  });

  const setValue = (value: any) => {
    try {
      const valueToStore =
        value instanceof Function ? value(syncedValue) : value;
      setSyncedValue(valueToStore);
    } catch (error) {
      console.error(error);
    }
  };

  useEffect(() => {
    const timeout = setTimeout(() => {
      syncToServer(syncedValue);
    }, delay);
    return () => clearTimeout(timeout);
  }, [syncedValue, delay, syncToServer]);

  return [state, syncedValue, setValue];
};

Would be curious to hear anyone's thoughts on this, I can imagine lots of questions about the motivation and to be perfectly honest...it just seemed like a cool thing to put together 🤷‍♂️

useProgressiveLoading

Anthony Humphreys — Fri, 15 May 2020 21:45:09 +0000

If you've ever worked with a slow moving API that you just can't work around, you've probably written something along these lines already. I thought it would be handy to have this as a hook, to drop into loading components and not have to rewrite the same piece of logic umpteen times.

There are definitely better UX patterns than this, and I am in no way advocating this as a good practice for loading behaviour, but sometimes you can't avoid unsavoury bits of UI like this.

const text = useProgressiveLoading([3, 10, 15], ['Loading your profile is taking a litle longer than normal, please wait',
    'Still loading, please wait a while longer...',
    'Still loading your profile, thank you for your patience...']);

return (
  ...
  <LoadingText>{text}</LoadingText>
  ...
)

The hook takes two parameters, the first is an array of times in seconds, the second is an array of strings. The principle is really simple, the hook creates a timeout for each timing passed, and will update the text value each time the timeout fires. The two arrays must be 'balanced' in terms of length, or the hook will throw an error.

import { useEffect, useState } from 'react';

export const useProgressiveLoading: Function = (
  timings: number[] = [5, 15, 30],
  strings: string[] = [
    'Still loading, please wait...',
    'Still loading, please wait a while longer...',
    'Still loading, thank you for your patience...',
  ]
): string => {
  if (timings.length !== strings.length) {
    throw new Error(
      `You passed ${timings.length} times and ${strings.length} - there should be the same number of each.`
    );
  }
  const [text, setText] = useState<string>('');
  const [timers, setTimers] = useState<number[]>([]);

  useEffect(() => {
    timings.forEach((delay: number, index: number) => {
      const timer: number = window.setTimeout(
        () => setText(strings[index]),
        delay * 1000
      );
      setTimers(oldTimers => [...oldTimers, timer]);
    });
    return () => {
      timers.forEach(timer => window.clearTimeout(timer));
      setText('');
    };
  }, [timings, strings]);

  return text;
};

That's all there is to this one, its pretty simple!

You can install this from npm or check out the repo on GitHub

As always, suggestions, improvements etc all welcome!

This post was for day 4 of my #100DaysOfCode challenge. Follow me on Twitter for more.

useBrowserStorage

Anthony Humphreys — Fri, 15 May 2020 21:43:51 +0000

For day 3 of my #100DaysOfCode challenge I thought I would expand and polish a hook I previously wrote (adapted from several examples online such as this one) which wraps the useState hook and persists state in localStorage or sessionStorage depending on use case.

The hook conforms to a mix of the localStorage and useState API.

const [state, setState] = useBrowserStorage("key", "value", StorageType.LOCAL_STORAGE)

This is so simple to use, virtually a drop in replacement for useState and gives you state persistance and restoration. You can use state as an ordinary state variable, and call setState with either a string or a function, just like the setter for useState.

That's it! Full hook code below, and published over at npm with the code available on GitHub

import { useState } from 'react';

enum StorageType {
  LOCAL_STORAGE = 'LOCAL_STORAGE',
  SESSION_STORAGE = 'SESSION_STORAGE',
}

export const useBrowserStorage = (
  key: string,
  initialValue: string,
  type: StorageType
) => {
  const storageProvider =
    type === StorageType.LOCAL_STORAGE
      ? window.localStorage
      : window.sessionStorage;

  const [storedValue, setStoredValue] = useState<string>(() => {
    try {
      const storedItem = storageProvider.getItem(key);
      return storedItem ? JSON.parse(storedItem) : initialValue;
    } catch (error) {
      console.error(error);
      return initialValue;
    }
  });

  const setValue = (value: string | Function) => {
    try {
      const valueToStore =
        value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      storageProvider.setItem(key, JSON.stringify(valueToStore));
    } catch (error) {
      console.error(error);
    }
  };

  return [storedValue, setValue];
};

UPDATE

This was originally published as 'useLocalStorage' - but then I realised using session storage in a hook called that wouldn't make much sense. Naming things is hard!

useFakeAsync

Anthony Humphreys — Fri, 15 May 2020 21:42:02 +0000

You can see the hook takes a few simple parameters, including the familiar pairing of a callback function and a delay in milliseconds. This follows the shape of JavaScript's setTimeout and setInterval methods.

import { useEffect, useState } from 'react';

enum FakeAsyncState {
  PENDING = 'PENDING',
  COMPLETE = 'COMPLETE',
  ERROR = 'ERROR',
}

export const useFakeAsync: Function = (
  callback: Function,
  delay: number = 3000,
  shouldError: boolean = false,
  chaos: boolean = false
) => {
  const [state, setState] = useState<FakeAsyncState>(FakeAsyncState.PENDING);

  useEffect(() => {
    let timer: NodeJS.Timeout;
    const fail = chaos ? Math.random() <= 0.5 : shouldError;
    if (fail) {
      timer = setTimeout(() => {
        setState(FakeAsyncState.COMPLETE);
        callback();
      }, delay);
    } else {
      setState(FakeAsyncState.ERROR);
    }
    return () => clearTimeout(timer);
  }, [delay, callback, chaos, shouldError]);

  return [state];
};

The hook also takes a 'shouldError' parameter so that an error condition can be forced.

The fourth parameter is a little more interesting, 'chaos'. I added this to randomise a success or error condition.

The state returned by the hook mimics a promise, it can either be pending, complete or in an error condition.

Hopefully this will help testing behaviour across components, and avoiding those inevitable bugs that creep in when integrating a UI with an API, like stutters between loading and success states, for example.

That's all! Go checkout the code on GitHub or install my handy hooks library from npm

This post was for day 1 of my #100DaysOfCode challenge. Follow me on Twitter for more.

useTSDX

Anthony Humphreys — Fri, 15 May 2020 21:41:13 +0000

Publishing hooks

One of the main outcomes I wanted from building this blog was to maintain a companion library of useful hooks. I'm writing most things in TypeScript these days (yeah I jumped on that hype train pretty hard, and haven't looked back...)

Publishing a custom hook is as easy as publishing a component for react. That being said, I'd never published a library built with TypeScript so wasn't entirely sure what was needed. That's when I remembered Jared Palmer's amazing TSDX CLI, I think I first heard about it on the SyntaxFM podcast.

I simply ran npx tsdx create hooks, dropped my code in the src directory, modified the github action included and hey presto, I've got a library live.

I'll certainly be making more use of this tool, for libraries and React Components.

useGeolocation

Anthony Humphreys — Fri, 15 May 2020 21:39:53 +0000

One of the first custom hooks I wrote was to grab the user's location using the Geolocation API. I wrote it for a project with two requirements - to get a user's location on a button press, and to 'watch' a user's location to keep a map preview up to date.

Let's cut straight to the code:

Usage (Single Location):

  const [position, error] = useGeolocation(GeolocationMode.SINGLE);

Usage (Watch Location):

  const [position, error, locationHistory] = useGeolocation(GeolocationMode.WATCH);

The hook is super simple to use. The first call returns a position object or an error, the second call will update 'position' every time the underlying hook receives an updated position from the Geolocation API, and will maintain an array of all positions observed in 'locationHistory'.

You can check out the code over at GitHub or install it from npm

The design of the underlying hook allows you to seamlessly switch between 'modes' too - so you could seamlessly transition between displaying a user's initial location and showing a user's journey as they follow directions, for example.

Its that simple. This is one of the most attractive value propositions offered by hooks - abstracting away logic in an easily reusable and easy to consume manner.

The full hook code

This is still a work in progress, types are incomplete etc.

  import { useCallback, useEffect, useState } from 'react';

  export enum GeolocationMode {
    SINGLE = 'single',
    WATCH = 'watch',
  }

  type GeolocationCoordinates = {
    accuracy: number | null;
    altitude: number | null;
    altitudeAccuracy: number | null;
    heading: number | null;
    latitude: number | null;
    longitude: number | null;
    speed: number | null;
  };

  type GeolocationResponse = {
    coords: GeolocationCoordinates;
    timestamp: number;
  };

  type GeolocationError = {};

  type GeolocationConfig = {};

  interface IPositionState {
    position: GeolocationResponse | null;
    positionError: GeolocationError | null;
    positionLoading: Boolean;
    previousPositions: Array<GeolocationResponse | null> | null;
  }

  const defaultGeolocationConfig: GeolocationConfig = {
    timeout: 12000,
    maximumAge: 60000,
    enableHighAccuracy: true,
  };

  export function useGeolocation(
    mode: GeolocationMode = GeolocationMode.SINGLE,
    stop: Boolean = false,
    config: GeolocationConfig = defaultGeolocationConfig
  ) {
    const [positionState, setPositionState] = useState<IPositionState>({
      position: null,
      positionError: null,
      positionLoading: true,
      previousPositions: [],
    });

    const onGeolocationSuccess = useCallback(
      position => {
        if (!stop) {
          setPositionState(oldState => ({
            ...oldState,
            position,
            previousPositions:
              mode === GeolocationMode.SINGLE
                ? [oldState.position]
                : [
                    ...(oldState.previousPositions
                      ? oldState.previousPositions
                      : []),
                    oldState.position,
                  ],
          }));
        }
      },
      [setPositionState]
    );

    const onGeolocationError = useCallback(
      error => setPositionState(oldState => ({ ...oldState, error })),
      [setPositionState]
    );

    useEffect(() => {
      if (mode === GeolocationMode.SINGLE) {
        navigator.geolocation.getCurrentPosition(
          onGeolocationSuccess,
          onGeolocationError,
          config
        );
      } else if (mode === GeolocationMode.WATCH) {
        navigator.geolocation.watchPosition(
          onGeolocationSuccess,
          onGeolocationError,
          config
        );
      }
    }, [mode, stop]);

    return positionState;
  }