Forem: Sue Smith

Transform web pages at the edge

Sue Smith — Mon, 03 Nov 2025 16:57:50 +0000

Edge computing apps allow you to enhance the behavior of a website by manipulating the request and response at the network edge, near the user. You can now transform your web page content at the Fastly edge more easily with the HTML Rewriter in your JavaScript Compute apps. Ideal for customizations like personalization and A/B testing, the rewriter uses familiar DOM manipulation patterns.

Let's run through how to switch up your page HTML with a Fastly Compute app in just a few steps.

Start a new project

In your terminal, create a new directory:

mkdir htmlrewrite && cd htmlrewrite

Initialize a new Compute app:

npx @fastly/cli compute init

Accept the defaults, choosing JavaScript and selecting the empty starter kit.

Enter project metadata

In your new project, open the package.json and change the Compute JS SDK dependency as follows:

"@fastly/js-compute": "^3.35.1"

Run npm install to get your environment ready.

In the fastly.toml file, add the details for the website you want to transform at the edge (changing the addresses to use your own or using the included demo site):

[local_server]

  [local_server.backends]

    [local_server.backends.website]
      override_host = "www.goldengirls.codes"
      url = "https://www.goldengirls.codes/"

[setup]

  [setup.backends]

    [setup.backends.website]
      address = "www.goldengirls.codes"

Write your logic

In src/index.js we'll be writing our Compute logic to transform the HTML at the edge.

Start by importing a couple of dependencies:

import { getGeolocationForIpAddress } from "fastly:geolocation";
import { HTMLRewritingStream } from 'fastly:html-rewriter';

We're going to build geolocation into our processing.

Inside the handleRequest function, add try catch blocks:

try {

  //rewriter processing here

} catch (error) {
  console.error(error);
  return new Response("Internal Server Error", { status: 500 });
}

Grab geolocation info

Inside the try block, let's first get some info from the request:

let ip = new URL(event.request.url).searchParams.get("ip") || event.client.address;
let geo = getGeolocationForIpAddress(ip);

We're going to use the time of day at the user location to tailor the display:

let displayTime = new Date().getHours();
let offset = geo.utc_offset;
displayTime += offset / 100;

let emoji =
  displayTime > 4 && displayTime < 12
    ? " 🌇"
    : displayTime >= 12 && displayTime < 18
    ? " 🏙️"
    : " 🌃";

We'll insert this daft emoji into the page to personalize it to the user.

Specify rewrite behavior

Still inside the try block, use an HTMLRewritingStream to specify what you want your Compute app to do to the HTML from your origin website. In this example we append the emoji to the h1 element and replace every second image with a different one – change yours to suit your website!

let transformer = new HTMLRewritingStream()
  .onElement("h1", (e) => e.append(emoji) )
  .onElement("div.code:nth-child(even) img", (e) =>
    e.setAttribute("src", "https://shadypinesmiami.github.io/sophia.jpg"));

You can use standard CSS selectors to indicate the elements you want to transform.

Fetch the response from the website specified as a backend in your toml and carry out the transformation on it:

let backendResponse = (
  await fetch("https://www.goldengirls.codes/", { backend: "website" })
).body.pipeThrough(transformer);

Finally, return the new response to the user:

return new Response(backendResponse, {
  status: 200,
  headers: new Headers({ "content-type": "text/html" }),
});

Your script should now look something like this:

/// <reference types="@fastly/js-compute" />

import { getGeolocationForIpAddress } from "fastly:geolocation";
import { HTMLRewritingStream } from "fastly:html-rewriter";

addEventListener("fetch", (event) => event.respondWith(handleRequest(event)));

async function handleRequest(event) {

  try {
    let ip =
      new URL(event.request.url).searchParams.get("ip") || event.client.address;
    let geo = getGeolocationForIpAddress(ip);

    let displayTime = new Date().getHours();
    let offset = geo.utc_offset;
    displayTime += offset / 100;

    let emoji =
      displayTime > 4 && displayTime < 12
        ? " 🌇"
        : displayTime >= 12 && displayTime < 18
        ? " 🏙️"
        : " 🌃";

    let transformer = new HTMLRewritingStream()
      .onElement("h1", (e) => e.append(emoji) )
      .onElement("div.code:nth-child(even) img", (e) =>
        e.setAttribute("src", "https://shadypinesmiami.github.io/sophia.jpg")
      );

    let backendResponse = (
      await fetch("https://www.goldengirls.codes/", { backend: "website" })
    ).body.pipeThrough(transformer);

    return new Response(backendResponse, {
      status: 200,
      headers: new Headers({ "content-type": "text/html" }),
    });
  } catch (error) {
    console.error(error);
    return new Response("Internal Server Error", { status: 500 });
  }
}

Test your app

Time to run your app! In the terminal, enter the start command:

npm run start

With any luck you'll see a local address to try the app at.

You might notice that the time of day emoji doesn't actually match the time of day at your location.. 🤔 That's because your app is just running locally on your computer – you'll need to deploy it to the edge to see that functionality working reliably.

Deploy your app

Everything working the way you want it to? Great, time to deploy to Fastly.

Grab an API token from your account:

Go to Account > API tokens > Personal tokens
Click Create Token:
- Name: anything you like
- Type: Automation
- Role: Engineer
- Scope: Global (deselect the Read-only access box)
- Access: All services
- Expiration: Never expire
Copy the token value and save it on your computer

In your terminal, create a Fastly profile, entering the API token you copied from your account:

fastly profile create

Now you can go ahead and enter the deploy command:

npm run deploy

Accept the defaults and let the CLI create a new service for you, confirming the backend details from your toml. Once it's deployed, the output will include the address to try your new app at, which will end edgecompute.app:

Open your app in a browser to see the correct time of day indicator:

It is indeed afternoon where I am!

Keep going

Add more processing to your Compute app! You can use the HTML Rewriter to make all sorts of changes through DOM manipulation, like adding attributes to your elements to change the site behavior.

If you get stuck please feel free to post on the Fastly Community Forum. 🛟

Enabling developers in GitHub Codespaces

Sue Smith — Tue, 07 Oct 2025 14:09:43 +0000

Over the last few months I’ve been exploring GitHub codespaces for developer enablement. I needed to replace our Fastly onboarding projects that had been hosted on Glitch, and ideally wanted to avoid the need for learners to install local tooling or even sign up for an account before trying our Compute platform. In this post I’ll run through what I’ve discovered about using codespaces for dev product learning.

Here’s an overview of what our codespace projects do:

Install dependencies and automatically run an app
Open previews of the app UI in the codespace
Deploy apps at the click of a button using bash scripts
Hide UI elements to minimize distractions
Use an extension to show custom buttons in the editor for actions like splitting views, sharing app previews, opening the terminal, formatting code

This daft video runs through how they work:

Wait, what is a codespace?

A codespace is a web editing environment you can open in the browser from a GitHub repository. Codespaces use a version of the VS Code editor, so you can specify editor settings much like you would in a local VS Code installation. Using codespaces lets you carry out development activities without downloading or installing anything onto your local machine – it all happens in the cloud.

You can access codespaces from the homepage of a GitHub repo, using the Code button to open an environment for editing the codebase on a specific repo branch.

Edits made in a codespace are automatically kept for a limited period of time you can set in your GitHub account – you’ll receive a warning if a codespace is about to be deleted and you can export your changes to a branch if you aren’t ready to lose them.

Containers

A codespace runs in a Docker container, and you can specify requirements in the repo devcontainer.json file. I usually include system features like Node (mostly I’m targeting JavaScript projects in the Node ecosystem), but the codespace will guess some dependencies based on the repo content.

Here’s an example container spec I’m using for edge computing projects: ~learn-edge-computing/devcontainer.json

You can attach commands to container lifecycle events – these run when the codespace opens, so you can use them to carry out setup tasks and get the codespace in the state you want for your learners when they open the project. I’ve been using the updateContentCommand and postAttachCommand events to install NPM packages and run package.json scripts I want to execute straight away.

📚 The devcontainer metadata reference lists the options.

This is part of a container config I used for projects originally developed on Glitch that I’d exported to GitHub:

"updateContentCommand": "npm install",
"postAttachCommand": "npm run start || npx --yes serve"

Previews and ports

You can run apps “locally” in the codespace and they’ll be exposed through specific ports. With the Simple Browser you can automatically open these apps right inside the editor at an app.github.dev address. The PORTS area in the Terminal at the bottom of the editor provides access to port settings, so you can open previews, change visibility, and share URLs with collaborators.

In the container config, I include a section specifying that specific ports should automatically open in the preview. For my edge compute learning experience, it sets both the origin website and edge apps to open from their default ports, with custom labels making them more obvious to the learner:

"portsAttributes": {
  "3000": {
    "label": "🚧 Origin",
    "onAutoForward": "openPreview"
  },
  "7676": {
    "label": "🌎 Compute",
    "onAutoForward": "openPreview"
  }
}

I also use a custom 🔗 Share button to set a port to public and provide the URL so that the user can copy it to share with collaborators – they can see the preview as long as they’re logged into GitHub.

💡 If your project is a fully static site and doesn’t use a framework, you can still run a preview using npx serve.

Extensions

You can list required VS Code extensions in your codespace container config and they’ll automatically be installed when someone opens the project. I include ESLint because my projects typically use JavaScript, and the extension for custom buttons then runs the format command.

Custom buttons

I’ve found the VS Code Action Buttons extension extremely helpful when it comes to customizing the UI for my learning projects. The extension lets you specify buttons that appear along the bottom of the editor. Your buttons can call VS Code editor commands and CLI commands, so I use them to give users an easy way to toggle views, and run bash scripts or Terminal processes.

Here’s an excerpt of one of my button lists:

"actionButtons": {
  "commands": [
  {
    "name": "🌈 Prettify",
    "singleInstance": true,
    "useVsCodeApi": true,
    "command": "editor.action.formatDocument",
    "tooltip": "Tidy up your code"
  },
  {
    "name": "🚀 Publish",
    "singleInstance": true,
    "command": "bash helpers/publish.sh",
    "tooltip": "Publish your content to Fastly Compute"
    }
  ]
}

You can include whatever Terminal commands you need for your target frameworks – I tend to separate them into bash scripts so that the user can tweak them more readily if they like.

📋 Here are the commands you can run on button clicks: Built-in Commands

Bash scripts

With the projects I’m working on being experimental, I wanted users to be able to see and tailor the CLI code that automates processing. For that reason I included the bash scripts in a helpers folder, calling those scripts from the container config and button clicks. The Fastly CLI commands have a little bit of control flow complexity that really needs a lot of testing, so I need to be able to make changes easily.

Here’s a more basic bash script I use for projects users have imported (and I therefore don’t know for sure which scripts they have in their package.json):

# We're making some guesses about the package scripts lolol

if [ ! -f package.json ]; then
  printf "\n🤔 No package.json found – try the Open button instead!\n\n"
else 
  OOPS="\n🤬 hmm maybe check what's in your package.json scripts and try "npm run script-name"?\n\n"
  npm install || printf "${OOPS}"
  npm run start || printf "${OOPS}"
fi

I also use scripts like this to write out instructional information to the user in the Terminal.

Deployment

The Fastly projects support deployment to the edge, so I typically use a 🚀 Publish button that runs the Fastly CLI tooling and deploys the app. Here's publish script for our Compute Static Publisher: publish.sh

Codespaces make a great editing environment for simple static website projects, and you can publish from the editor, for example if you have a blog. You can deploy to GitHub Pages at the click of a button by including the gh-pages package in your project, and a script in your package.json, like this Vite example:

"scripts": {
    "start": "vite",
    "build": "vite build",
    "serve": "vite preview",
    "deploy": "gh-pages -d dist"
}

To publish using a button, just call the deploy command from the custom button extension covered above. I’m using this flow for my own blog and static site projects that I migrated from Glitch.

Environment variables

If your platform requires an API key, you can instruct users to acquire and add one inside the codespace. In the README I include links and steps for grabbing a Fastly API key and adding it using the command palette. When a user adds an environment variable, the codespace will prompt them to reload, which they’ll need to do in order to use the variable in subsequent commands.

File and feature visibility

You can specify settings for the VS Code editing experience in your container config just like you would in a local environment. I tend to hide some features to minimize distractions, like the minimap, and files / folders like node_modules, so that the learner can focus on the core parts of the project I’m trying to familiarize them with.

You can include these in the settings object in your container JSON:

"settings": {
    "files.exclude": {
        "package-lock.json": true,
        "node_modules/": true
    },
    "editor.minimap.enabled": false,
}

Source control

Although a codespace automatically stores your edits until it’s deleted, it’s a good idea to encourage users to regularly commit their changes to the underlying repo in case they lose them. You can do this in the Source Control area on the left.

Things can get a bit confusing depending on whether your users have started the codespace from your repo or from a fork of it – I encourage users to create their own fork so that it’s clearer where their changes should be saved.

🤔 Something that gets a bit messy with codespaces for dev product onboarding is that the flow seems to be primarily optimized for devs making contributions to a repo rather than forking it to make their own project. If you don’t plan to publish changes you want your users to be able to sync their forks with, you can use template repos instead. This is one place I’ve felt the tension of what I was able to support users to do on Glitch vs this workflow.

Optimizing your repos for codespaces

When you first open a codespace with a custom container config, it can be pretty slow to start up. You can reduce this with prebuilds that target specific regions you expect your users to be in. Although the free tier is generous, you might want to keep an eye on the costs for storage and compute associated with your codespaces, and definitely set spending limits in your GitHub account.

📝 Some of the setup for codespaces can translate to users cloning your repos locally and opening them in VS Code on their computers – this is something I want to explore soon, as well as supporting other web based VS Code environments.

Learn more

I found this post from Rizèl Scarlett super helpful when I was figuring out what I could do: How to run a frontend workshop in Codespaces 🙌

Some official docs:

Some of my codespace-optimized projects:

One I used for people migrating from Glitch: ~glitchy-editing
Publishing an 11ty blog to the edge: ~11ty-to-compute
Edge computing intro: ~learn-edge-computing

Develop an edge computing app in the browser

Sue Smith — Fri, 19 Sep 2025 09:22:44 +0000

When I try a new web technology, I really want to play around with it upfront before installing anything locally or setting up a developer environment. Over the last few months I’ve been exploring GitHub Codespaces for this purpose, working on a set of projects that guide you through building and deploying apps to the network edge straight from the browser. In this post I’ll introduce our new Fastly Compute learning experience that you can try out in seconds.

With a Compute app, you can enhance the user experience for a website at the edge. The app can manipulate the request from the user and the response from the origin website. You can write your code in various languages and the Fastly SDKs will compile it into Web Assembly (WASM) that can run at the edge, between your users and your website host. In this guide we’re writing our edge application logic in JavaScript.

Read on for a more detailed walkthrough of the flow but here’s the gist:

You fork a GitHub repo
Open your fork in a codespace
The app runs and automatically opens a preview
The project includes a sample origin website that runs too
You tweak the Compute app code and see the preview update as you work
When you’re ready, you grab a Fastly API key, copy it into your project, and publish

Fork the project

Getting your own app running takes a couple of clicks:

Sign into GitHub and visit the ~learn-edge-computing repo.
Fork the repo into your account (best to leave the name unchanged)
Open your fork in a codespace by clicking Code and creating a codespace on your main branch

When the codespace opens it’ll attempt to do a few things automatically:

Build, run, and open a preview for your example origin website
Build, run, and preview your initial Compute app
You’ll find some buttons along the bottom of the editor to make the process easier
- Use the 🔎 Split button to separate your preview from your code so that you can edit and see the results at the same time

Get to know your new app

🚧 Your project includes a demo origin website – the code for it is in the origin folder.

🌎 The logic for your Compute app is in the src folder. Check out the content of the index.js file.

In the Terminal area, select PORTS to see the origin and edge versions of your site – use the buttons to toggle between them in the preview. Check out the differences in functionality:

The style is different because the Compute app switches the stylesheet at the edge.
There’s a cookie written into the page that includes geolocation information passed in at the edge.
The ohno link returns a synthetic HTML page at the edge instead of a default server error.
The data link also returns a synthetic page instead of raw JSON.

Develop in the browser

Make a change to your Compute app. In the README you’ll find a suggested edit you can copy and paste right into the index.js file. With any luck your app will automatically rebuild and update in the preview. The edit adds information to the geolocation cookie indicating the time of day at the user location.

Note that the geolocation info won’t be accurate until you deploy to the edge, because your app is initially running “locally” inside the codespace which is running in a container hosted by GitHub.

Make changes to your origin app too in the origin folder, like changing the HTML and CSS.

You can share your draft app with collaborators using the 🔗 Share button at the bottom of the editor – they’ll just need to be signed into GitHub to see it.

Deploy to the edge

Sign up for a free Fastly account and grab an API key. Pop your key into your codespace with the name FASTLY_API_TOKEN.

Click the 🚀 Publish button at the bottom of the editor and follow the prompts. A few things will happen at this point:

The Fastly tooling will build your app and package it for deployment
It’ll create a new service in your Fastly account and upload the package
The scripts in the codespace will also deploy your origin website to a GitHub pages site for your repo
The GitHub pages site will be set as the origin for your Compute app

When everything’s ready, you’ll see an edgecompute.app address in the Terminal output. Go ahead and click it to check out your deployed app. How does it behave differently at the edge?

You can carry on making edits to your app and hit that 🚀 Publish button whenever you want to go live with them.

Remember to commit your changes to your fork of the GitHub repo if you want to keep them – use the Source Control area on the left of the codespace editor.

Keep going

Curious how the app works? Check out the helpers and .devcontainer folders!

Publish your website without a host

Sue Smith — Fri, 29 Aug 2025 10:17:26 +0000

When you use a CDN, cached copies of your website’s static assets are stored at the network edge for fast delivery to your visitors. Well, if your website is just those assets, why not just dump the whole thing at the edge and serve it directly from there instead of storing it on a web hosting service in the first place?

That's what the JavaScript Static Publisher for Fastly Compute does. It delivers your static site straight from the network edge using a serverless app to handle user requests, and an edge data store for your content. This kind of originless setup is well suited to generated static sites made up of HTML, CSS, and client side JavaScript, like blogs and react apps.

You can deploy existing sites to Fastly Compute using a few simple commands in your IDE. You can also create a new site, edit, and publish it without installing a thing on your computer by following a guided experience in a GitHub codespace – fork a demo project, open it in the browser, pop in an API key, and publish at the click of a button.

Try a simple static site

The ~website-to-compute project demonstrates how to publish a simple static site to the edge from a GitHub codespace.

The steps are in the repo README, here’s the TL;DR:

Fork the repo
Open your forked version for editing in the browser by clicking Code > Codespaces and creating a new codespace on your main branch
- The codespace config will run a few setup tasks when it first opens, it might take a couple of minutes
Your website preview will open in a tab – click the 🔎 Split button at the bottom to see the site side by side with your code
- Edit your site HTML and CSS! Your preview will update in the editor… 👀
- Share your draft site with collaborators by clicking 🔗 Share and copying the URL to your clipboard 📋
When you’re ready to publish to Fastly, sign up for an account and grab an API key, copying it into your codespace project
- Click the 🚀 Publish button along the bottom of the editor and follow the prompts
Your edgecompute.app address will appear in the terminal output
Make sure you save your edits to GitHub using the Source Control area on the left of the editor

Publish a project from your computer

If you already have a static site on your computer that you want to deploy, open it in an IDE.

Import the Static Publisher and pass it the root directory to scaffold a Compute app for your site:

npx @fastly/compute-js-static-publish@latest --root-dir=./_site  --kv-store-name=site-content

Set up dependencies:

cd compute-js && npm install

🧪 If you want to test your site locally before deploying, use npm run dev:publish and npm run dev:start then open it in the browser.

When you're ready to publish, grab a Fastly API key and set it as the value of the FASTLY_API_TOKEN environment variable.

Deploy your app:

npm run fastly:deploy

Open the edgecompute.app address in the terminal output – it won't show the content yet so don't worry if you see an error message. 😅

Publish your content to the KV Store:

npm run fastly:publish

Reload your edgecompute.app URL in the browser and with any luck your content will be there!

💡 Each time you have new content to publish, just run the fastly:publish command again.

📚 For more detail check out the tutorial.

Write and publish a blog from a codespace

The ~11ty-to-compute project publishes an Eleventy blog to the edge. You can draft new blog posts in the codespace and publish whenever you’re ready to share them with the world.

Check out the README for steps but here's the gist:

Fork the repo and open it in a codespace
Make changes and add blog posts
Grab a Fastly API key and add it in the codespace
Hit the 🚀 Publish button
Tell the world!

🔗 You can share your WIP blog posts for feedback from collaborators using the button at the bottom of the editor.

Next steps

Point your own domain at your new site
Learn about edge computing
Find out more about the JavaScript Static Publisher for Fastly Compute
Learn more about the publication flow in the static site publisher tutorial

🛟 Need help? Post on the Fastly Community forum!

Understanding that app you vibe coded

Sue Smith — Fri, 11 Jul 2025 19:44:57 +0000

Dealing with a project you generated using an AI tool? If you don’t have programming skills and need to understand the code for an application it can be hard to know where to begin. Perhaps you're discovering that generating the code is just one of many steps in making a successful software application!

In this guide we’ll outline some places to get started learning about a codebase you need to troubleshoot, fix, or extend. We'll start by opening and running the app in a developer environment.

We’ll assume you’re working with a web application, like a website or app users access in the browser – for other types of app the steps here will not work.

Export your code

Well be working in GitHub so if your code isn't already on there you'll need to import it. Most tools provide the ability to download or export your code straight to GitHub. If you download your code, you’ll need to install developer tooling (IDEs like VS Code and dependencies) to actually run your app on your computer. You can alternatively work with your code in the browser, which is a lot easier, so that’s what we’ll focus on here.

Get your code onto GitHub – if the service you’re using doesn’t offer a GitHub export function, you can upload your files straight into a GitHub repository instead.

Add some helper code

We’re going to open the project in a GitHub codespace – this will let you work with it without installing anything on your computer. We'll do this using containers, which let you use a dev environment on the web instead of locally on your own machine.

⚠️ The helper code is based on some assumptions about your project, for example that it’s a web application with a user interface and that it uses a package.json file. If this is not the case, for example if you’re working with a mobile app, you will encounter errors!

To make the process more likely to work for you, add a file to your repo. Click Add file > Create new file.

Enter .devcontainer/devcontainer.json as the file name.

Paste the following in as the file contents:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the  
// README at: https://github.com/devcontainers/templates/tree/main/src/ubuntu  
{  
  "name": "Ubuntu",  
  "image": "mcr.microsoft.com/devcontainers/base:noble",  
  "features": {  
    "ghcr.io/devcontainers/features/node:1": {}  
  },  
  "portsAttributes": {  
        "3000-9000": {  
            "label": "App",  
            "onAutoForward": "openPreview"  
        }  
  },  
  "updateContentCommand": "npm install",  
  "waitFor": "updateContentCommand"  
}

This tells the codespace to install the necessary dependencies for your project and automatically open it when it runs.

Click Commit changes… > Commit changes to save your new file.

Open your project

From your GitHub repo homepage, open your app in a codespace by clicking Code > Codespaces, and creating a new codespace on your main branch.

⏳ The codespace will attempt to provide what we asked it to in the container config file we added, and it might take a few minutes to open.

Take a look around

If you’ve never used an IDE (Integrated Development Environment) before it might look a bit overwhelming, but you’ll get used to it. Codespaces on GitHub use VS Code, which is the most popular IDE around, so if you plan on digging into code more, this is a tool you’ll benefit from getting familiar with.

The files in your project will appear on the left, and you can access other tools in there too. In the middle you’ll see your code editor, which will display the README for your project by default if it has one. You can also open your other files by selecting them from the list on the left. At the bottom you’ll see the Terminal and other tools that help you work on your project.

Does your app have a README file? If so take a look in there in case it includes helpful information on running and developing your code.

Prepare your environment

Check your project for a file named package.json. In most cases web apps use frameworks that rely on the Node.js ecosystem, in which case your project will have this file and you can learn how to run and build it from there.

The package.json file indicates dependencies and scripts for your app. The dependencies are coding resources your app is pulling in from the web – these are utilities your app depends on to deliver its functionality. That’s code developed by other people and organizations, accessed through a registry like NPM.

📝 Dependencies are not the only way your app uses code written by others, if you generated your project using an AI tool, it was most likely trained on data from open source projects, for example on GitHub. The developers who contributed that code didn’t consent to their data being used for this purpose, which is why a lot of them are not happy about it!

In order to run your app, you need to install the necessary dependencies. We set the container config to do that automatically when the codespace opens. With any luck the codespace will install everything you need. If you see any errors in the Terminal area at the bottom, read the output for tips on moving forward. If that doesn’t work, try a web search for the error text.

Run your app

Your README or package.json will indicate how to run your app locally. Check the package.json for a scripts section. Scripts can include start, dev, build, serve, preview, and more depending on the frameworks your app uses.

In your Terminal, try running the scripts as follows. First try either start, or dev. If you don’t have either of those, try build.

npm run start

Watch the Terminal output for updates, checking any errors for further information.

🚧 If your app is using a data source, like a database, you might need to carry out additional steps to run it outside the environment you built it in.

Hopefully your app will run and open a preview on a port. The container config we added will attempt to open it automatically. Most web frameworks use ports to run your app locally while you develop it. Forwarding it to a port means you can open the app at a local address (meaning not accessible over the web, just in your environment) in the web browser.

You can also access your running app using Ports in the Terminal section at the bottom of the editor.

Once your app is open, you can use the split button at the top right and drag the website preview tab over into it.

This lets you see the code as well as the app itself.

Try changing your app code and see what happens! You can always undo your changes.

If you continue working on the app, you’ll need to build and deploy it. Your package scripts will include whatever you need to run in the Terminal to build your app. Once you have a build, you’ll need to deploy it somewhere to share it with your users at an address they can access, unless you’re taking your changes back into the platform you used to generate the code in the first place.

Save your changes

When you’re ready to save any changes you’ve made, click the Source Control button on the left.

Enter some text in the box and click Commit.

Click Yes in the pop up notification, then Sync changes.

Your edits should sync with your GitHub repo. If you’re importing your code back into the platform you started from you can do that now.

Debug your app

Is your app not doing what you want it to? You can debug it in the codespace too. Use the Problems and Debug Console tabs in the Terminal area at the bottom.

To use the VS code debug tools, click into the top text box again and enter >debug then select an option. Choose an option based on the error you’ve been seeing in the output when your app runs, like Debug npm script, choosing the script you entered to run your app (start, or dev).

To open the debug controls in your codespace, choose View: Show Run and Debug.

Click Run and Debug, choosing Node.js. Watch the Debug console for output.

To try the JavaScript Debug Terminal, click the button then run your npm command to start the app again. For best results you'll want to dig into your code and add breakpoints to use in your debugging flow.

Debugging is a whole skillset in itself! There are also lots of extensions you can install in your codespace to help you debug your app. Check out these VS Code tutorials for more:

Get help 🛟

Here’s the thing, learning to code is something you’ll do best with help. There are lots of resources and communities online. Here are a few pointers:

Does the platform you used to generate your app have a community? Post in there!
Which frameworks is your app using? They most likely have dedicated community spaces online you can connect to.
There are also great developer and learning communities, like here on DEV, and over on freeCodeCamp.

If you get really stuck, need your app finished, and have the budget – hire a freelance developer to help you with it!

📻 Later in this series we'll get into learning about your app logic, which will most likely be written in JavaScript or TypeScript if the steps in this tutorial worked for you.

We should still teach coding

Sue Smith — Mon, 31 Mar 2025 13:28:22 +0000

Software written using generative AI is all over the web. Performance and security issues abound. Open source projects are being overwhelmed by bot traffic. There's a lot of harm being caused, but as an educator who cares about lowering barriers to software creation, I can't ignore the democratizing potential of these tools either.

In this post I’d like to explore the opportunities for learning that this paradigm shift presents – from how to make your projects more efficient and secure, to learning about the intellectual property and labor exploitation that might have gone into training the models you used.

Understanding incentives

One thing I have learned working in education is the value of accepting people’s motivations – having a goal that a skill will help you achieve is the most effective motivator for learning. Clearly many people are finding ways to use AI to help them achieve goals.

Motivations are determined by complex socioeconomic factors beyond our ability to reason away. Let’s instead keep the door to the good internet open by empowering people to make responsible choices, equipping them with knowledge of the technical systems they’re creating within.

Gen AI might help you spin up an MVP, but eventually you will have to dig into the code. You’ll either learn software engineering skills, or have to bring in the experts. Far from making engineers obsolete, I worry that less investment in these skills will make the barriers around the profession more extreme. A select few having insight into how critical systems work is not a future I’m enthusiastic about. Instead I’d like to find learning paths that these new ways of building software present.

The conditions for learning are in place

Projects developed using gen AI can support a range of good practices in education, including some key activities that we often neglect in both formal learning and the workplace:

Personalization: We can work on something meaningful to the learner rather than dragging them through a one-size-fits-all experience.
Fast feedback loops: Automation can fuel adaptive learning through short iterative cycles.
Reflection: Reflecting on an experience helps you internalize skills you’ve acquired and reapply them in different contexts.

Code generated using LLMs enables and requires these perhaps more than “traditional” ways of making software. There are also some coding pedagogy techniques that gen AI projects can lend themselves to:

Reading before writing – code comprehension is a crucial software engineering skill, consider an experienced engineer performing code reviews and mentoring junior teammates.
Starting from a functioning application instead of a blank slate.
Running an app to see what it does, then investigating how it did it.
Taking gradual ownership of a project by making a first edit, then turning it into something new.

⚠️ Generative AI is not an appropriate substitute for the many interpersonal aspects of effective learning IMO. “Mentoring” powered by biased LLM content is incredibly dangerous.

Encouraging inquiry and independent thought

I wonder about a gen AI coding exercise that gives you a broken project to fix, or prompts you to explore where the code came from – this kind of inquiry is being used in the humanities to support the development of critical thinking skills, especially important since these tools might by default erode those very skills.

Then we have the wealth of problems that arise when people deploy applications with little to no understanding of their implementation. What happens over the long term, what happens if your project becomes a real thing people depend on, what happens when it breaks, what happens when it causes harm, how do we navigate the obfuscation of accountability? These are learning opportunities we’ll embrace if we want people to make more informed choices about how they use technology.

Software engineering is a very privileged profession, largely because it requires access to education. Vibe coding creates new paths into building with tech. The starting point may be different, but we might even manage to invite more people into the spaces where we shape the future of the web.

Learn how Fastly is making AI more sustainable.

Cover image is The March of Intellect by Robert Seymour.

Enhance an 11ty site at the edge

Sue Smith — Fri, 21 Mar 2025 14:01:26 +0000

In this post we're going to customize the UX in an Eleventy site with a Compute app running on the Fastly network at locations near your users around the world. We'll use the Eleventy Base Blog deployed to GitHub Pages, with some tweaks to its RSS feed to let us do some fun stuff at the edge. We'll write a JavaScript app that we'll compile into Web Assembly (Wasm) that can run securely on the Fastly network.

The website and feed

Eleventy (11ty) generates your website in the form of a bunch of HTML files and some CSS. This makes it a super fast, performant experience for the user – it also makes it perfect for playing with edge computing. You can do lots of cool things with 11ty plugins, like exposing an RSS feed of the posts in your site. We'll set our feed to return JSON so that we can mess with the data at the edge before sending it back to the user.

Set up your site

Our fork of the Eleventy Base Blog includes a change in eleventy.config.js to make the feed return JSON instead of the Atom format.

You can use the example site for your Compute app if you like, but later in this series we'll also try editing the site in conjunction with our edge functionality, so fork your own copy if you plan to follow along:

Fork the repo
Follow the steps in the README to edit and deploy to GitHub Pages – tl;dr:
- Edit the eleventy.config.js feedPlugin section to set metadata base to your own GitHub IO domain
- Change the references to my-site in package.json to your repo name
- Change .github/workflows/gh-pages.yml.sample to .github/workflows/gh-pages.yml
- Create a gh-pages branch
- In your repo Settings > Pages section, choose Deploy from a branch and select gh-pages
- Watch the Actions for your deploy status

Grab the URL for your new site, as you'll need it in your Compute setup.

Set up your Fastly account

Grab an API token from your account:

Go to Account > API tokens > Personal tokens
Click Create Token:
- Name: anything you like
- Type: Automation
- Role: Engineer
- Scope: Global (deselect the Read-only access box)
- Access: All services
- Expiration: Never expire
Copy the token value and save it on your computer

Set up your developer environment

We'll use the Fastly CLI to spin up a Compute service, so get it installed on your computer:

Create a new directory:

  mkdir 11ty-edge && cd 11ty-edge

Install the Fastly CLI – see the docs if you aren't using NPM:

  npm install -g @fastly/cli

Create a Fastly profile, entering the API token you copied from your account:

  fastly profile create

Start a Compute app

We're going to use Expressly, which lets us build our Compute app using a similar structure to Node.js server frameworks like Express. We'll listen for user requests, manipulating the request and response we send back to the user.

Initialize your Compute app using the Expressly starter kit:

  fastly compute init --from=https://github.com/fastly/compute-starter-kit-javascript-expressly

You can set the name, description, and author if you like, or accept the defaults.

💡 Include --accept-defaults with your Fastly commands if you don't want to respond to every prompt.

Run npm install when prompted.

Check your app is installed correctly by running it locally and opening it in your browser:

npm run start

The local site will just return OK.

Explore the app

Take a minute to explore the files in the Compute app.

The src/index.js file contains our Compute logic including the Expressly routing structures
The fastly.toml file contains our app setup

We'll be making changes to both of these files, and the Fastly tooling will change the TOML when we deploy our app.

💡 The bin and pkg directories include the compiled assets the CLI will use to deploy your app to Fastly.

Set up your origin

At the moment the app doesn't do much, it just returns a default response to the user. Let's get it to return the response from our 11ty website.

Open fastly.toml and add the following at the end of the file, changing the domain to your own GitHub IO subdomain if you're using your own version of the site deployed to GitHub Pages:

[setup]

  [setup.backends]

    [setup.backends.blog]
      address = "glitchdotcom.github.io"

In src/index.js, add a variable near the top of the script:

let backendResponse;

Change the router.use function to fetch the response from the origin site, making it async:

router.use(async (req, res) => {
  res.set("x-powered-by", "expressly");
  backendResponse = await fetch(req.url, {
    backend: "blog"
  });
});

We set the blog backend in the TOML, so Fastly will make the request to our origin website.

Delete the router.get('/'... and router.post("/submit" functions, replacing them with one to respond to all requests with the response from the origin site:

router.all("(.*)", async (req, res) => {
  res.send(backendResponse);
});

Your script should now look something like this:

/// <reference types="@fastly/js-compute" />

import { Router } from "@fastly/expressly";

const router = new Router();
let backendResponse;

router.use(async (req, res) => {
  res.set("x-powered-by", "expressly");
  backendResponse = await fetch(req.url, {
    backend: "blog"
  });
});

router.all("(.*)", async (req, res) => {
  res.send(backendResponse);
});

router.listen();

Deploy your app

In the terminal, exit from your local server with CTRL+C if necessary. Run the deploy command:

npm run deploy

Let the CLI create a new service, accepting the default options or changing any you like. The tooling will build and compile your app, upload the package to Fastly, and activate the service it's attached to. When it's ready, you'll see an edgecompute.app address in the terminal output – open it in your browser, adding the path for your GitHub repo name (my-site if you're using the example), like:

informally-one-shrimp.edgecompute.app/my-site/

Right now all the app will do is return the response from the origin website, but we're going to change the behavior for certain requests.

Build a synthetic feed page

Click the Feed link in the site header for your deployed app (at the edgecompute.app address – it just returns a JSON list of the posts in the site, which is what we get from the origin.

Let's turn this into a page. Back in your app, in the src/index.js file, add a new variable near the top of the script, changing the value to the name of your forked 11ty repo if you're using your own version:

let root = "/my-site/"; //change to your repo name

Add a new endpoint before the router.all("(.*)" section:

router.get(`${root}feed/feed.json`, async (req, res) => {
  let originData = await backendResponse.json();
  let posts = ``; // change to your repo name
  for (const pst of originData.items) {
    let date = new Date(pst.date_published);
    date = date.toDateString();
    let linkUrl = new URL(pst.url);
    posts += `<p><a href="${linkUrl.pathname}"><strong>${pst.title}</strong></a> – ${date}</p>`;
  }
  let page = `
  <!DOCTYPE html>
  <html>
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1" />
      <title>${originData.title} – Feed 🗞️</title>
      <!-- 🚧 Change CSS location to suit your site 🚧 -->
      <link rel="stylesheet" href="${root}css/index.css"/>
    </head>
    <body>
      <header><a class="home-link" href="${root}">My Website</a></header>
      <h2>${originData.title} – Feed 🗞️</h2>
      <div>${posts}</div>
    </body>
  </html>`;

  res.withStatus(backendResponse.status).html(page);
});

The code parses the JSON feed response and builds it into HTML.

Deploy your app again:

npm run deploy

It may take a minute or so for your changes to update, but when your new service version is up, open the feed page again at the edgecompute.app address, like:

informally-one-shrimp.edgecompute.app/my-site/feed/feed.json

And we have a web page instead of the JSON data... 🎉

🧰 You can access a complete example of the app code in the 11ty-feed starter kit and Fiddle if you want to try running the code in the browser.

Next steps

⏳ Stay tuned for the next part of the series we'll add some edge data to the functionality – we can access information about the user, like their location, so we'll build that into our app processing to customize the site behavior.

In the meantime, check out how you can build edge data into your apps

Get edge certified with new Fastly credentials

Sue Smith — Tue, 17 Dec 2024 16:01:18 +0000

Whatever path you took into tech, continuous learning and development will always help keep your career moving in the right direction. Also, learning is fun! Our new Edge Computing 101 badge recognizes learners who successfully set up a Fastly Compute service that carries out a little bit of processing on a website at the network edge. The best part is that it's completely free, and you can follow the steps to achieve it inside an interactive Glitch project.

TL;DR Jump over to Glitch and earn your Edge Computing 101 badge 🎏🏅

We've spent part of 2024 building Fastly's first developer certification program. We initially trialed our new credentials as part of employee training, with coworkers from all over the company successfully completing the steps to get up to speed with the edge. We made the certification available for public use recently, with community members earning their badges and giving us valuable feedback on the experience. We're now ready for more of you to get stuck in!

Why learn about edge computing?

Edge computing is used by many of the biggest sites on the web, so these skills are valued by employers and organizations working on large scale applications with emergent technologies. Fastly Compute is an edge computing platform that enables you to make instant experiences at global scale – we've barely scratched the surface of what this technology can do. Edge engineering knowhow is still pretty rare, so if you want to get ahead of where the web is going, this is it.

📚 Learn what the edge is all about in our edge computing intro series!

The Fastly Edge Computing 101 badge

The Edge Computing 101 badge is an intro level certification – it's easy to earn! You'll submit the link to a Glitch website you remixed, and a Fastly deployed app that changes the UX for the site at the edge. You don't need any prior knowledge to complete the steps – the app uses some JavaScript, but you'll be able to grab example code from the docs inside the project. Building at the edge is a lot easier than you might think!

If you want to get into edge computing for the web more deeply, we'll have you covered later in 2025 when we extend this program to support more intermediate and advanced learning, so stay tuned if that's you.

How to earn your certification

You'll need (free) accounts on both Fastly and Glitch – if you already have them, sign in, otherwise:

To get your hands on your Edge Computing 101 badge, just remix the project and jump in:

~learn-edge-computing 🎒🏆

The README will guide you through the steps:

You'll set up your Fastly account and grab an API key
With your API key in your Glitch project, you'll deploy an edge app to Fastly Compute
The Glitch project contains both the website code and the edge app code, but unlike the website which you can preview immediately inside Glitch, you'll need to deploy each time you want to publish a change to your Compute code
The README includes an example edit you'll make to extend the Compute code and deploy again to see the changes

You'll find more info in our tutorial on building your own edge computing app.

Your Compute app sits between the user and your website, so it can manipulate the request and response. The example app will enhance the behavior of the site at the network edge, personalizing the display using geolocation information. It'll pass data back to the browser with the response to the user, where the client side code will write the info into the page HTML.

You'll find the link to submit your badge application at the end of the README.

We'll aim to process your submission within 2-3 weeks.

🎓 We're using the Badgr platform for these credentials. Badgr supports Open Badges, an open source credentialing standard. This will let us build out our learning program to issue badges, and many platforms around the web integrate with Open Badges, so you can share yours on networks like LinkedIn.

How to get support

If you get stuck, want to give feedback, or just connect to others who are also learning about the edge – pop into the Fastly forum where team and community members are around to help.

🎄 Responses will be a little slower than normal over the festive season.

Ready for more?

If you're ready to extend your Compute proficiency, check out the ~fastly-compute-starter project, which does a little more processing at the edge. You can also follow along with our video and tutorial on enhancing your site UX in the Fastly docs.

Show off your badges! 📣

Don't keep quiet about your learning achievements, boast about your expertise – humility is a scam! Share your badges on your social networks, link to them in the comments, post them in the forums, tell the world!

Autopost to Bluesky and Mastodon by API

Sue Smith — Fri, 13 Dec 2024 16:14:14 +0000

Last time we learned how to verify our accounts using a domain with a free Glitch website – this time let's set up a simple app to crosspost some automated content to Bluesky and Mastodon using their APIs.

We'll set up developer credentials for both platforms, pop them into Glitch, and post some daft text including random emoji. We'll also discover a more complex example that posts links and images, in case you want to continue building!

Remix the Glitch project

We're using a Glitch project with a lot of the code setup already so go ahead and remix it to get your own copy:

~social-poster

⚠️ Glitch project hosting shuts down on 8th July 2025 so you won't be able to remix this project anymore – you can find the source code on Github if you'd like to deploy it somewhere else!

The app uses Node.js and Axios to make connections to the Bluesky and Mastodon APIs, but don't worry if you aren't familiar with these frameworks, you'll be able to pop in your details and get postin' easily!

If you like you can take a minute to browse the project. There are instructions in the README as well. We'll mainly be working in these files:

.env where we include our credentials
src/client.js where we connect to the APIs
server.js where we call our client methods and manage scheduling

The content we post by default is in the postTxt variable in src/client.js so change it if you want to post something different – the code initially only supports plain text content, but you'll find detail on posting media below.

These example posts demonstrate the default content:

Get your developer credentials

To post from somewhere outside the official Bluesky and Mastodon apps, we're going to use the APIs. APIs are interfaces platforms provide to allow you to access their features using code. In order to gain this access, we'll need to authenticate with both platforms – this keeps the user data on the apps and websites we use safe.

Bluesky app setup

For Bluesky, we need an app password for the account we want to post to. In your Bluesky account, navigate to Settings > Privacy and Security > App Passwords:

Click Add app password
Enter a Name for your app password, like "Glitch poster"
Copy the password and click Done
Paste the password into your Glitch remix in the .env file as the APP_PASSWORD variable
While you're in the .env, enter the handle for the Bluesky account you want to post to

Mastodon app setup

For Mastodon, you'll need a token to authenticate your requests. Log into your account (you'll need to be in a browser rather than a mobile app). Navigate to Preferences > Development, and click New application.

Give your application a name, like "Glitch poster"
For Application website, include the URL of your Glitch website, which will end .glitch.me
Leave the Redirect URI with the default content
For scopes, make sure you check write:statuses and write:media if you want to be able to post images
Submit your application
Copy the value of Your access token
Paste it into your Glitch project .env as the MASTODON_TOKEN variable

💡 You can also add your Glitch website as a verified link in your Mastodon profile – include a link in index.html back to the Mastodon account, with rel="me" in the anchor.

In your Mastodon account, it's also a good idea to check This is a bot account in Settings > Profile.

Post!

That should be you all set to post! Your Glitch remix includes code to run the posting on a schedule, but you can also post manually. In the preview, click into the address bar and enter one of the following:

postBsky to post only to Bluesky
postMasto for Mastodon only
postAll for both

Open the Logs to find any details or errors.

Check your accounts to find the posts.

Examples posts on Bluesky

Example posts on Mastodon

Check out the code

The code for Bluesky and Mastodon is slightly different, so let's break it down so that you can tweak and use it elsewhere. We'll be exploring src/client.js for the API connections.

For Bluesky, we need to start a session and save the token:

const session = await bskyClient.request({
  url: "/com.atproto.server.createSession",
  method: "post",
  data: {
    identifier: process.env.HANDLE,
    password: process.env.APP_PASSWORD,
  },
  headers: {
    "Content-Type": "application/json",
  },
});
bskyToken = session.data.accessJwt;

We can then use the token in subsequent requests. Next we post the post:

const post = await bskyClient.request({
  url: "/com.atproto.repo.createRecord",
  method: "post",
  data: {
    repo: process.env.HANDLE,
    collection: "app.bsky.feed.post",
    record: {
      $type: "app.bsky.feed.post",
      text: postText,
      createdAt: date,
    },
  },
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer " + bskyToken,
  },
});

It's a bit more complicated if you need more than plain text – to include links you need facets, and to include media you need embeds. You'll find examples of both in ~wtf-poster.

For Mastodon we need just one request:

let data = {
  status: postText,
};
const postResponse = await mastoClient.request({
  url: "/v1/statuses",
  method: "post",
  data: data,
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer " + mastoToken,
  },
});

Mastodon handles links automatically, but you'll need more processing if you want to upload images – the media endpoints let you add and link to uploaded files. Check out ~wtf-poster for an example.

Schedule posts

In your Glitch project server.js file, you'll find scheduling code around line 25. Uncomment the code out if you want your account to post automatically on a schedule – you can tweak the timing!

Ready for more automation? Remix or copy from ~wtf-poster to post links, images, and content from a third party API... 🎢🎡🛸

🪩🛼🌈 Share your cool autoposters in the Glitch forum!

Verify your Bluesky or Mastodon account on your own domain, with a free website!

Sue Smith — Tue, 03 Dec 2024 17:46:38 +0000

Setting up your own domain for a website and social media is easier than you might think! I love domains, I have a few pointing at Glitch sites and in my social profiles. In this post I'm going to run through setting up another website and domain, and add it to Bluesky as a handle for a new account, and Mastodon as a verified link.

Grab a Glitch remix

We're going to make a website in a few minutes:

Remix ~my-social-website!

⚠️ Glitch project hosting shuts down on 8th July 2025 so you won't be able to remix this website anymore – you can find the source code on GitHub if you'd like to deploy it somewhere else!

The project will open in the Glitch editor.

Click Preview at the bottom and Open preview pane.
That's your new website! It's already on the web at your-project-name.glitch.me – you'll find the link above the preview.

You can make changes now or later, but personalizing the site literally takes minutes.

Open index.html to change the content of the page.

Edit the heading in the h1 element.
Add text to display in the page like the <p> content.
Add other content like images and links – check out the tips in the HTML..!
Change the site style in style.css.

If you like you can change your Glitch project name in Settings > Edit project details which will change your site address on Glitch.

You can keep going in your Glitch project or come back to it later – it's a lot of fun!

Get a domain

Here's the thing, you could just use your .glitch.me website address as your handle and verified link on both Bluesky and Mastodon, but it's much better to have your own domain and is easier than most people think.

Use Domainr to find a domain by searching for keywords like your name or a project you're working on.
When you find a domain that you like, click it to see the available registrars. Check a few to find out the prices they're offering – you can get domains for a few dollars a year.
You can go ahead and buy the domain from here, or if you already have a preferred registrar, just search the domain on their site and buy it there (I find myself using Porkbun a lot because I like the experience even though I am a vegetarian lolol).

Once you have your domain, your registrar will provide access to the DNS records for managing it. You'll need these to point the domain at your Glitch website.

Point your domain at your site

Now you have a domain you can use to send people to your content on the web and to verify your identity on social platforms. To point it at your Glitch site you'll also need TLS to keep it secure. We're going to use Fastly to get this for free – we go over these steps in a lot more detail in this other tutorial, below is the TL;DR version.

Set up a Fastly service

Sign up for a free Fastly developer account (that's right, you're a developer now whether you knew it or not 🚀).
In your new account, click Create service and choose CDN.
Enter any Name you like.
Enter your new domain, with www. at the start, like www.sue.wtf.
For your Origin > Host enter your Glitch website address – grab it from the Glitch editor by clicking the three dots above your preview and copying it. It should look something like this (no https or slashes): suewtf.glitch.me
Click Activate!

Get a free TLS certificate

Now let's grab a TLS certificate for the domain:

In Security choose TLS Management then click Manage certificates and Get started to secure your domain.
Enter the www version of your domain and click Add.
Leave Certainly selected.
Submit your new certificate.

Fastly will provide the details to verify that you own the domain – click Verification options.

Copy the ACME DNS challenge CNAME – it will be _acme-challenge followed by your domain name.
In the account where you bought your domain, navigate to your DNS settings. Add a new record, with CNAME as the type, and the value you copied from Fastly as the Host (usually the first text entry).
Back in Fastly, grab the verification address by clicking the little clipboard – it'll be some letters followed by fastly-validations.com.
In your DNS, add the value you copied as the second text entry in your new record (usually called address, data, or content).
Save your new record.

It'll look a little different depending on your registrar, but here's an example in Squarespace:

Back in Fastly, your domain should soon pass verification, then your certificate will be issued within a few minutes.

Point your DNS at your service

OK now it's time to point the domain at your site through Fastly.

In Fastly, browse to Security > Domains and find your certificate. Under TLS configuration and DNS details click View / Edit.
Copy the CNAME record address which will end .sni.global.fastly.net.
Back in your DNS account, add another new record, CNAME again, this time with the www version of your domain, and the sni text you just copied as the value.
Save your new record.

It may take a while to update but with any luck (usually within an hour) you'll be able to visit your domain and land on your new Glitch website.

💡 I usually set my DNS to redirect the apex version of my domain (the one without a subdomain) to the www version – steps vary by registrar but it's usually pretty straightforward.

Use your domain for your social profiles

I'm going to use my new domain as a handle on a Bluesky account and a verified link on my Mastodon account. Luckily the Glitch remix already has some of this set up for me.

Bluesky

Let's do Bluesky first (you'll need to set up an account with a default handle before you can switch to using your own domain):

In your Bluesky account, choose Settings > Account > Handle.
Click I have my own domain.
Enter your domain, like www.sue.wtf.
You can set it up by adding another DNS record with the values in the popup, or you can set it up inside your Glitch project as follows:
- Choose No DNS panel.
- Copy the did value.
- In your Glitch project, create a new file by clicking the + icon on the left above the filetree and entering .well-known/atproto-did.
- Paste the value from Bluesky into this new file.

Bluesky will verify your domain and update it as your new handle.

More detailed guide to using your own domain in the Bluesky docs

💡 Remember to update the link to your Bluesky profile in your Glitch project HTML!

Mastodon

Now for Mastodon, we'll use the domain to add a verified link to our profile:

In your Glitch project, update the link to Mastodon near the end of index.html to your own Mastodon profile.
The link already has rel="me" in it – you need this to verify it on Mastodon.

In your Mastodon account, edit your profile, adding a link to your new domain that you have pointed at your Glitch site. It should verify fairly quickly!

You can see the example accounts I used for this tutorial here:

That's it!

🚀 Next try remixing an app that automates Bluesky and Mastodon posting..

🛟 If you hit any issues ask for help on the Glitch forum!

Let's talk about algorithms and social media

Sue Smith — Thu, 14 Nov 2024 12:22:53 +0000

We're having another, bigger wave of folk moving from Twitter to platforms like Bluesky and Mastodon right now. There's a lot of talk about algorithms and feeds. Let's break it down, find out what algorithms are, and what to know about the information you discover in your favourite social media apps.

Algorithms are everywhere, and that's (mostly) ok!

📣 OK first of all, every social media feed uses an algorithm, even if it's just a list of posts from people you follow in chronological order – that is the algorithm!

The problematic part was that apps started presenting feeds assembled using different algorithms that we couldn't see or understand. Using a different algorithm isn't necessarily a problem in itself – sometimes it's good to see something beyond that timeline from people you already know about. The problem was that the algorithm was mysterious and hidden, and sometimes you couldn't opt out of it.

What is an algorithm?

An algorithm is a series of instructions we give a computer to create the functionality you use in a software program, like presenting a list of posts in a social media app. An algorithm is like a recipe for a meal, or a manual for assembling a piece of furniture.

Algorithms can get really complex, and use structures that determine the control flow of an app, like conditionals. A conditional tells the computer to do something if some condition is in place. Like not showing a post to someone if they've blocked the person posting it. Algorithms use lots more structures that change the behaviour of the apps you use, and they can be hard to predict!

Algorithms also use data, like the user details indicating they'd blocked that other person. The data on a social media app is dynamic, meaning it's constantly changing, because people are joining, posting, interacting, and all sorts of events are happening in the world. The combination of these control structures and large amounts of data makes the experience of social media often radically different between users.

Algorithmic feeds

Over time, many social media feeds shifted from that list of posts from folk you follow to an algorithmic feed that was created by some mechanism you couldn't see or control. Sometimes they would push content that was popular with others even though you didn't follow the people posting. Sometimes they would just push content the owner of the platform wanted to promote. Why?

Most social media apps are free to use, but they cost money to provide. Software services are funded a few different ways, but typically the funders want a return on their investment – in the case of VC funding, which was prevalent in the tech industry for many years, they want an extreme return. This is why platforms use ads, promoted posts, and sometimes paid accounts giving you additional features.

Follow the money, always

Social media providers have struggled to come up with business models that don't destroy the experience they give users. If you're generating revenue from ads or promoted posts, you might charge by impressions – the number of times a post appears in someone's feed. Even if you aren't making money this way, it's common for software companies to report on metrics around engagement as a predictor of future success. Engagement means users spending time in the app and interacting with it.

Software platforms are therefore incentivised to increase engagement, in order to generate revenue, or to keep the funding coming in so that they can continue operating. The consequence is programming your algorithm to push content that gives those engagement numbers a bump. Unfortunately the posts that have this effect aren't always good for community health, like hate content.

Building these levers into your algorithm gives you the mechanism to push whatever content you like at people. This is part of how social media platforms have contributed to the spread of misinformation that aligned with the political interests of their owners.

Emerging platforms and user choice

There is good news. A raft of new social media platforms are attempting to decentralise and democratise your experience, by giving you choices over the algorithms that assemble your feeds, and making those feeds more transparent.

For example, in Bluesky you can choose feeds that only show you posts from mutuals, or posts that are popular with people you follow – you can also create your own custom feeds. Mastodon is open source, which means people can see and contribute to the code, and even host their own version of it. How these platforms are going to be funded in a sustainable way remains to be seen. And idk what to tell you about Threads lol I'll leave it at that.

Catch me on:

How I make learning experiences

Sue Smith — Mon, 30 Sep 2024 11:44:39 +0000

I make things to help people learn coding skills. Most of my work is is closer to building edtech software than authoring education content, but I hesitate to identify what I do as edtech because, well a lot of that is basically surveillance tech which is not what I'm about lol.

A conversation at work prompted me to describe how I approach teaching a topic. I've been doing this for quite a long time now, so thought I might have some tips that could be useful to others looking to help folk learn.

Learn the thing myself first

This might seem obvious, but typically I'm teaching things I don't already know how to do, so I have to learn them first. The best time to teach something is right after you learned it imo, it puts you closer to the learner perspective, and you make fewer assumptions about what they already know.

It's worth noting any places you find particularly challenging or awkward, bearing in mind that these are highly subjective and won't necessarily be representative of what your learners find hard – they are still likely places you can make the experience easier for some.

Consider the conceptual elements

Often when you're trying to acquire a tech skill, there are both conceptual and practical elements you need to grasp. Abstraction, analogies, and mental models can be helpful here, but first you need to frame whatever you think those conceptual components are.

💡 Example: This year I've been teaching edge computing. The notion of client and server in web development is relatively well known, but adding a third thing called the edge poses a conceptual challenge. It affects your understanding of what happens when people visit a website, and what the development process looks like in that context.

🧰 Toolkit: When it comes to teaching the conceptual elements, varying the levels of abstraction in your learning experience can help – like using semantic waves.

Consider the practical barriers

With software development, we often have frustrating, time-consuming setup processes to get our environments in a state where we can begin learning. This friction reduces the number of people who manage to successfully engage, so I always consider removing barriers, at least for a first learning experience on a subject.

💡 Example: This is why I use Glitch so much, you can build applications without downloading or installing anything. I can also abstract a lot away behind the plumbing of a Glitch project and focus the experience on the core learning gains I'm trying to help people access.

There is a trade-off here between clearing the path of unnecessary obstacles and not glossing over understanding the learner will need to apply what they've learned in the real world – this can be a hard balance to strike and often takes multiple iterations.

Design the experience

I always try to teach hands-on, in context, in a developer environment. Editors like Glitch are great for this because there are multiple places you can include guiding information that the learner can follow at their own pace – they can also see the results of their edits live.

🧰 Toolkit: My goal is for people to come away from an experience with skills they can reapply in different settings. This can be hard to measure depending on the relationship you have with the learners, but I find the Raspberry Pi coding pedagogy research and practices like PRIMM super helpful for guiding design decisions – ideally, start with a working example and walk the learner through making a change to it.

Make it meaningful

Framing learning experiences in terms that are valuable and meaningful to the learner is a great motivator. Make it about what they gain by learning this skill, perhaps for a project or goal they care about, rather than just teaching it for its own sake. Putting the task or skill in its technological or cultural context helps.

💡 Example: I've recently been teaching people about using their own domains for their sites and applications, and explained why it's a good idea to do this as a supporting resource.

Community situated learning often provides additional motivation too – if you can encourage people to share reflections on what they've learned that'll help them retain their new skills.

Test it with humans

Whenever I'm working on a self-serve learning resource, I like to use it as a supporting asset for live training. Testing an experience with people in real time helps to reveal any implicit knowledge, anything I've inadvertently assumed people would already know but that they don't. I can then work to cover that knowledge in the experience, or at least indicate it as a prerequisite.

💡 Example: Earlier in 2024 I tested public facing learning materials for my company's products by running internal employee training.

When people attend a live training, giving them something they can take away, refer back to, and continue developing is ideal, so this one's a win-win.

🛼 That's about it! Check out my developer learning talk from 2023 for more tips.

Forem: Sue Smith

Transform web pages at the edge

Start a new project

Enter project metadata

Write your logic

Grab geolocation info

Specify rewrite behavior

Test your app

Deploy your app

Keep going

Enabling developers in GitHub Codespaces

Wait, what is a codespace?

Containers

Previews and ports

Extensions

Custom buttons

Bash scripts

Deployment

Environment variables

File and feature visibility

Source control

Optimizing your repos for codespaces

Learn more

Develop an edge computing app in the browser

Fork the project

Get to know your new app

Develop in the browser

Deploy to the edge

Keep going

Publish your website without a host

Jump to:

Try a simple static site

Publish a project from your computer

Write and publish a blog from a codespace

Next steps

Understanding that app you vibe coded

Export your code

Add some helper code

Open your project

Take a look around

Prepare your environment

Run your app

Save your changes

Debug your app

Get help 🛟

We should still teach coding

Understanding incentives

The conditions for learning are in place

Encouraging inquiry and independent thought

Enhance an 11ty site at the edge

The website and feed

Set up your site

Set up your Fastly account

Set up your developer environment

Start a Compute app

Explore the app

Set up your origin

Deploy your app

Build a synthetic feed page

Next steps

Get edge certified with new Fastly credentials

Why learn about edge computing?

The Fastly Edge Computing 101 badge

How to earn your certification

How to get support

Ready for more?

Show off your badges! 📣

Autopost to Bluesky and Mastodon by API

Remix the Glitch project

Get your developer credentials

Bluesky app setup

Mastodon app setup

Post!

Check out the code

Schedule posts

Verify your Bluesky or Mastodon account on your own domain, with a free website!

Grab a Glitch remix

Get a domain

Point your domain at your site

Set up a Fastly service