Cantoni.org

The Case for "Eventually Consistent" Management

2026-02-08T00:00:00Z

People often panic when two managers give slightly different answers. The instinctive reaction is "something is wrong" or "we're disjointed." But in distributed systems, we accept temporary mismatches as a necessary trade-off for speed—a concept known as eventual consistency. Instead of treating every management inconsistency as a failure, what if we viewed leadership teams like distributed databases that sometimes just experience latency before reaching a unified state?

Examples

The simplest examples come when someone asks me or my manager the same question (e.g. status of a project). We might give two different answers if we haven't synced yet, but that's fine because we will eventually be consistent. A momentary mismatch in answers isn't necessarily dysfunction; it's often just latency. Adopting an eventually consistent mindset lets us keep moving forward even knowing that occasionally we won't all have the same current information.

For example, an engineer asks you: "Are we prioritizing X or Y this quarter?" They ask your manager the same question. They get two answers that are directionally aligned but not identical. Both answers may be correct given the information available at that moment. Neither response is malicious or incompetent. The system is temporarily inconsistent, but still healthy. When in doubt, explicit communication reduces the error rate: 'This is my current understanding, but I need to sync with [peer] to confirm.'

Where does this approach not work? Anywhere you really need to provide accurate answers without speculation or later clarification. (In other words, you need strong consistency.) Two situations that come to mind for me are any customers or internal executives (more than a layer or two above my manager). In those cases, I prefer to get synced on the accurate information to avoid sending people off with the wrong understanding.

Origin in distributed computing

The Wikipedia definition is a good starting point:

Eventual consistency is a consistency model used in distributed computing to achieve high availability. An eventually consistent system ensures that if no new updates are made to a given data item, eventually all read accesses to that item will return the last updated value.

I first learned about eventual consistency in my last job working at DataStax. Our system was built with the distributed database Apache Cassandra which has tunable consistency levels for reads and writes:

Consistency level (CL) determines how many replicas must acknowledge a read or write for it to be considered successful. Higher levels (more replicas in agreement) yield stronger consistency guarantees at the cost of latency, whereas lower levels favor speed and availability at the risk of stale data.

This is a helpful Reddit post from a couple years ago with several good examples: What is eventual consistency good for?

Note: I wrote this post but credit to ChatGPT for good suggestions for illustrating this metaphor.

Why Feature Reviews Matter (and How We Ran Them at Palm)

2026-01-17T00:00:00Z

At Palm Computing, we worked against hardware manufacturing schedules that made software deadlines absolute. To avoid the dreaded "black box" of development where stakeholders only see the result at the bitter end, we implemented Feature Reviews. These regular check-ins did more than just report status; they forced transparency, mitigated risk, and became a crucial tool I still use with my teams today.

Origins at Palm

First, a little background on the origin story. [Palm][] was a hardware company which meant most projects were driven by the manufacturing schedule. In this environment, one key learning for software teams like mine was that schedule is not going to slip. It was a good forcing function though; whatever software was ready by the cutoff date, that's what we shipped with. We could do patches later, but everything really had to be done.

This meant we were essentially following a waterfall process even for software and even with our attempts to make our project more incremental (pre-agile). Our solution was to add some intermediate progress updates which we'd share across teams and with our engineering and product leadership. We wanted to combat this waterfall idea of a long development time being a "black box" until the result popped out at the end:

It's a simple concept - just add Feature Reviews as intermediate checkpoints along the way:

These reviews were useful for bringing together the right set of peers and leaders, to report in a sense "here's what we're building." I remember we fine-tuned them to just cover the most impactful or risky projects, especially those that had both desktop and handheld components. Hosting these reviews regularly also helped in cases where we needed to make course corrections or scope reductions to ensure we would achieve the deadlines.

Fun fact #1: While writing this up I remembered something about life on a software team at a hardware company. All our project end milestones were "GM" (Gold Master), because our code was literally going to be cut to a master CD-ROM or master device ROM. Everywhere I've worked since has really called it "GA" (General Availability).

Fun fact #2: My team owned the desktop applications including Palm Desktop, and we liked to include easter eggs in the product to list all the people who built it. We even got our names into some official product marketing screenshots!

How to run a feature review

Even in an agile enterprise software environment like Tableau, feature reviews can still be valuable. Most agile teams already have sprint reviews, but feature reviews can include a broader audience, look at a longer horizon, and be more feature-centric.

Here's my suggested outline for holding a feature review, including the audience and what you should cover:

Owner - Prepared and led by the feature team (engineering & product).
Audience
- Stakeholders (including leadership, architects, field)
- Peer and related teams
- Other interested people in the company; looping in those who are interested in what you're building that you want to keep informed and query for feedback
Contents
- What are you building (setting context for those who aren't familiar)
- What's the status, show live demos
- What work is remaining (schedule discussion)
- What open questions or potential risks should be discussed
Frequency - This will depend on your overall project timeline, but we found every 4 or 6 weeks to be about right. So out of a roughly 12-week release cycle, we'll meet 2 or 3 times.
Logistics - Pay attention to the usual important details for a meeting like this, including advertising in advance, keeping the conversation focused, and capturing recording/slides/actions to share afterwards.
Outcomes - The team should agree ahead of time whether the purpose is mostly sharing status, or whether there are any specific decisions you need. If the right stakeholders have been included, decisions and adjustments can be made during the review or at a minimum captured for offline resolution.

The review contents will likely change a bit as you make progress. The first review can focus more on requirements and planning, but the big value in future sessions is to show off what has been built so far. For one project I'm leading, our first review was more top-down (requirements, design, dates, who's working on it, etc.) with the demos at the end. Then we flipped it (bottom-line up-front style) and jumped right into the demos first with project status/logistics to follow.

As an engineering manager, there's a bonus for me here which is giving your team the spotlight and encouraging them to participate and drive the demos. Presenting your work is a great skill to have and these feature reviews can be safe spaces to practice.

Comparison to the movie business

I had a random thought comparing this idea of feature reviews for software projects to the "dailies" that are used in the movie business. AI chatbots tended to agree with me, no surprise there!

Copilot wrote this comparison:

Feature reviews in software projects and dailies in movie production both serve as regular, structured opportunities to review progress, engage stakeholders, and mitigate risks. The main differences lie in their frequency, scope, and the nature of what's being reviewed. Feature reviews are broader and less frequent, supporting complex, multi-phase software development. Dailies are immediate and focused, supporting the fast-paced, high-stakes environment of film production.

Comparison Table: Feature Reviews vs. Dailies

Aspect	Feature Reviews (Software Projects)	Dailies (Movie Production)
Purpose	Share progress, surface risks, gather feedback, and keep stakeholders informed	Review footage for technical/artistic quality, spot issues early
Frequency	Periodic (every 4–6 weeks, or as fits project timeline)	Daily (after each day of filming)
Audience	Broad: feature team, leadership, architects, related teams, interested stakeholders	Core creative/technical team: director, cinematographer, producers
Content	Demos, status updates, remaining work, risks, questions, action items	Raw, unedited footage from the day’s shoot
Focus	Holistic project status and cross-team communication	Immediate technical and creative review of filmed material
Format	Meetings with presentations, live demos, Q&A, and documentation	Screening sessions, often informal, focused on viewing footage
Outcome	Feedback, action items, risk mitigation, improved transparency	Decisions on reshoots, technical fixes, or creative adjustments
Skill Development	Opportunity for team members to practice presenting and communicating	Opportunity for crew to refine filming techniques and performance

And ChatGPT nailed it with this generated visual comparison ☺

Palm

A Modern Manager for Browser Bookmarklets

2025-12-30T00:00:00Z

While often overshadowed by full browser extensions, bookmarklets remain a powerful, privacy-friendly tool for automating repetitive web tasks. However, writing and formatting the necessary JavaScript can be tedious. I recently built a simple bookmarklet manager — using AI to speed up the process — that makes creating, identifying, and sharing these scripts much easier.

What is a bookmarklet?

First, what exactly is a bookmarklet? It's a browser bookmark that runs a small bit of JavaScript code rather than containing a web link. The code will run in the context of your current browser page and can be useful for reading or modifying that content. Bookmarklets need to be formatted a specific way to safely run when clicked.

For example, you might have a simple code snippet that displays a pop-up dialog:

alert('Hello, world!');

It needs to be formatted as a single-line function and properly encoded like this:

javascript:(function()%7Balert('Hello%2C%20world!')%3B%7D)()

Next you create a browser bookmark using a title like "Hello" and the location set to the formatted bookmarklet code string. Now clicking on the "Hello" bookmark will execute the code you defined. (In this example, a simple pop-up.)

How are bookmarklets useful? Here are a few good ideas I've used myself:

Copy page link in markdown format (probably my #1).
Copy selected text as Markdown quote.
Tweet this (send this link to the Twitter/X interface to share it; similar for LinkedIn or any social network).
Highlight all links (outlines tags to see what’s clickable).
Show all images with alt text (flags missing or empty alt attributes).
Disable all CSS (removes stylesheets to inspect raw HTML).

Here are some more detailed explanations of bookmarklets:

An important note about bookmarklets: like browser extensions, they have access to everything in your browser. Don't install anything without reading and understanding the code yourself to make sure it's safe.

Bookmarklet manager

As you can see from the example above, JavaScript needs to be converted into the proper format to be used as a bookmarklet. For anything beyond simple examples, this is kind of a pain. Inspired by some online tools like Bookmarklet Maker, I decided to build my own manager. I wanted a simple editor to convert between plain JavaScript and bookmarklet format, and to save a list of bookmarklets I've made.

Here's the result:

Live site: https://bcantoni.github.io/bookmarklets/
GitHub source: https://github.com/bcantoni/bookmarklets

Just like my last project, I used Claude Code (with Opus 4.5) and followed a spec-driven process:

I wrote the initial SPEC.md with the basic concept and some specific functional requirements I had in mind.
I prompted Claude to review the spec, give suggestions, clarify the requirements, and update the document.
I gave Claude the go signal and the initial working version was ready in a couple minutes!
I tested and iterated on a few tweaks to get to the first release.

I was impressed with the simple UI design that Claude implemented. (I had not given any specifics about the design.) And the solution worked on the first iteration. I suggested using local browser storage but Claude suggested adding the import/export as JSON which is really handy for sharing across multiple computers.

The manager can generate bookmarklets from JavaScript code, load or save them, and provides a drag-and-drop link to easily install them into your browser.

Can AI help you create bookmarklets?

You can probably guess the answer is Yes. AI tools know about browser bookmarklets. You can prompt an AI like Claude or ChatGPT with the details of what you want and then copying and pasting the resulting code into the bookmarklet manager.

Here are a couple examples:

Prompt:

create javascript I could use in a bookmarklet that found all headings
(h1, h2, etc) on a page and reversed the characters in the string

Result:

document.querySelectorAll('h1,h2,h3,h4,h5,h6').forEach(h => {
  h.textContent = h.textContent.split('\').reverse().join('\');
});

Prompt:

create a javascript bookmarklet to copy the web page title and URL and 
put them in the clipboard; display a toast near the page top (centered)
for 2 seconds saying \"markdown link copied\"`

Result:

// Build the Markdown link
const markdownLink = `[${document.title}](${location.href})`;

// Copy to clipboard
navigator.clipboard.writeText(markdownLink).then(() => {
  // Create toast element
  const toast = document.createElement('div');
  toast.textContent = 'markdown link copied';

  // Style the toast
  Object.assign(toast.style, {
    position: 'fixed',
    top: '20px',
    left: '50%',
    transform: 'translateX(-50%)',
    padding: '10px 14px',
    background: '#333',
    color: '#fff',
    fontSize: '14px',
    borderRadius: '6px',
    zIndex: 999999,
    boxShadow: '0 2px 6px rgba(0,0,0,.3)',
    opacity: '0',
    transition: 'opacity 0.2s'
  });

  // Add to page
  document.body.appendChild(toast);

  // Fade in
  requestAnimationFrame(() => {
    toast.style.opacity = '1';
  });

  // Fade out after 2 seconds, then remove
  setTimeout(() => {
    toast.style.opacity = '0';
    setTimeout(() => {
      toast.remove();
    }, 200);
  }, 2000);
});

In the future it might be nice to integrate an AI agent into the bookmarklet manager where the result could be dropped directly into the code editor. But for now, a little tabbing back and forth is still pretty easy.

My First Electron App: ImageLinks

2025-12-29T00:00:00Z

I wanted a simple app to extract links from screenshots and used Claude Code to create a simple desktop application that did exactly that. This was my first time creating anything with the Electron cross-platform app platform and it worked quite well.

My idea originated at work where I spend a lot of time in meetings and often people will be presenting Tableau dashboards or other documents without remembering to share the links. My usual workaround is to take a quick screenshot so I can find that content later. Instead of doing that manually, what if I had a Mac app that could analyze an image and show all the web links automatically?

See my ImageLinks project at https://github.com/bcantoni/imagelinks to see all the source code and give it a try.

For this project I wanted to try Claude Code to build something from scratch and using something I wasn't already familiar with -- in this case, the Electron platform. I started with a basic spec for Claude to follow and iterated on that with Claude's help. These were the key points:

Two modes of operation: drag and drop an image file, or use the image from the clipboard.
Supported platforms: Mac, Windows, Linux (getting Mac working as the first priority).
In the image, look for URLs and QR codes (which should be decoded).
Technology: use electron and electron-builder; use only popular/common Node libraries.
Started with 5 test images and expected results.

After some quick iterations I had the final SPEC.md ready and I prompted Claude Code to build it per the spec. ☺

Claude quickly got to a working application, and we iterated on a few specific areas:

Adding to the library of tests for different combinations of URLs and QR codes and some lower resolution difficult tests.
Improving the speed for the image detection code. The original version from Claude was good but it was too complex. For example, it created all 4 rotated versions of an image and ran each through the image detection loop. My use case is simpler, and everything is normally in the upright orientation.
Improving the detection quality for images. This was some iteration with more complicated test images and adjusting the algorithm.
Creating GitHub workflows for CI builds and an automated release process.
Creating the project README.md which includes a summary of the app, how to install, and developer notes.

Overall, this simple project was a success, and I do use it on my work laptop. In cases where I have an image that doesn't come through correctly, I can add it as a test with the expected result and just ask Claude Code to fix the detection. I've tested and used both the Mac and Windows installers, and everything just works. The only tricky part on the Mac side is these are "unsigned," so I need to remove the Apple quarantine attribute after install. (The command is: xattr -cr /Applications/ImageLinks.app.) If I ever have other reasons for a paid Mac developer account, I could officially sign these.

Downsizing My Flickr Library to the Free Tier

2025-12-12T00:00:00Z

My Flickr photos account was a fun snapshot in time when I worked at Yahoo and before mobile phone cameras took over. This week I used AI to create a couple of scripts to help me get back down to the free account limit. Here's a quick explanation of the process I followed along with a few Flickr memories.

My time with Flickr

I started using Flickr in late 2004 which was just prior to their acquisition by Yahoo in spring 2005. (I worked at Yahoo - not on Flickr - from 2004 to 2011).

Here's a summary dashboard of my Flickr uploads (courtesy of Claude):

I think I had used other photo sharing sites like Yahoo! Photos and later Google Photos, but Flickr was great for several reasons:

All of the social aspects were there including groups to join, people to follow, photos to favorite and comment on
It had simple but useful controls for posting family or private photos
Tags were quite popular
Search combined with content licensing made it easy for people to use your photos in different contexts
It was the first site I recall that clearly showed the camera model and settings front and center
It was part of Yahoo :)

This was my first exposure to the Creative Commons license. I marked all my public photos with the permissive CC BY license which in summary means:

This license enables reusers to distribute, remix, adapt, and build upon the material in any medium or format, so long as attribution is given to the creator. The license allows for commercial use. CC BY includes the following elements: Credit must be given to the creator.

With the CC license in place, it was fun to see all the places my photos would be used. I have a bunch that people have used on Wikipedia, including this one on Taylor Swift's page visiting the Yahoo campus in 2007 promoting her debut album (full album on Flickr):

Here are a few more fun ones: a remote with the Netflix button (my #1 most viewed photo), my 1997 Dodge Ram just after I got it repainted, and racer Robby Gordon signing an autograph for my wife at a Phoenix race:

A long time ago I set up a Google Alert for my name and when people used an image and properly gave me credit, I'd get a hit. This Coast Guard boat was a popular one for news articles describing any kind of rescue:

I even had a few people contact me for specific permission, including my Scantron image being included in Scott Berkun's How Design Makes the World book which came out in 2020:

Flickr download scripts

Now to today's problem: I had a Flickr paid (Pro) plan for quite a while but dropped back to Free at some point when I was less active. Since the Free plan limits were tightened up in 2022, I've been getting periodic reminder emails reminding me I was over the limit:

Reminder: Some of your photos are at risk of deletion.

This is a reminder that your account is still in violation of Flickr’s free account limits. Photo deletions are underway, so now is the time to act to protect your photos.

As of November 3, 2025 you have 1393 uploads to your free account. The current limit is 1,000 uploads for free accounts. As soon as possible, please subscribe to Flickr Pro OR download excess non-public photos and remove them from your Flickr account

The Free account limits I was exceeding were: 1) having more than 50 non-public photos; and 2) more than 1000 photos in total. The new pricing structure seems fair to me. The Pro level account is a pretty good deal if you use it a lot - currently $82/year for unlimited photos and a bunch of other benefits. The 1000 photo limit is still a lot, and in spite of the warning emails I never did lose any of my content. But since I really don't use the site much any more, it made sense to prune my uploaded photos, including all the private and friends/family ones.

Earlier this year Flickr changed the API key policies such that only Pro accounts can create and use API keys. My workaround was to raise my subscription from Free to Pro for a month (similar to what I needed to do when closing out my Evernote free account).

With Claude Code ready to help, I created a set of scripts that use the Flickr API to help manage my content:

Backup - download a mirror backup of all photos, including photo metadata and organized into album folders
Stats - find and view the most popular photos
Stats CSV - download all the interesting metadata for all photos (this is what I used to create the dashboard at the top of the post)

For all of these scripts, Claude Code did quite well. I really didn't make any edits myself but just relied on prompting to adjust the scripts including adding a retry mechanism and gracefully handling rate-limiting responses.

Once I had everything backed up, I used the Flickr Batch Organize feature to remove all the private albums and prune a bunch of less interesting photos. The Organize feature is kind of old school like most of Flickr, but it works quite well.

The result: I backed up my whole photostream, removed all my non-public images, and reduced the overall count from 1400 down to 750 (all under the Free limit). Next I returned my account to the Free level and now I'm all set!

All the source code for this project is on GitHub: bcantoni/flickrbackup.

An easier way

Part way through this project I realized / remembered that Flickr has support for viewing and downloads stats and for downloading all your photos.

This was still a fun experiment to build a script that uses the API directly. If you were an active Flickr user you could automate a lot of your photo workflows with the API.

Vibe Coding a Website on my Phone Waiting at the Barbershop

2025-11-02T00:00:00Z

Is it possible to "vibe code" a website from my phone while waiting for my turn at the barbershop? The answer as you might guess is yes! I recently created an event countdown website completely from my phone (no Wi-Fi) and got it launched in the 45 minutes while I waited for my turn in the chair!

I've been wanting to create an "event countdown" style website for an upcoming wedding and picked it as a good simple target to see if everything could be done from the phone. While this is not ground-breaking, several components are involved, including GitHub Pages for hosting, my domain provider for the domain name, GitHub Copilot for the code repository and AI help. Also my current barber does not take appointments, so on a recent Friday I was 3rd in line, so I had about 45 minutes to crank this out.

The plan worked!

Now, how did we get here? This is everything I used:

GitHub Mobile This is actually quite powerful especially for the most common tasks including managing issues, pull requests, and code changes. I did need to log in to github.com for a couple things.
ChatGPT Mobile Worked great, no notes!
Unsplash I'm pretty sure they have a mobile app but I just used the website.
DNS provider No mobile app, but the website worked well enough.

Here is the rough sequence of steps I went through, including just the most interesting bits:

First I registered the domain name with my existing provider. Then in GitHub mobile I create the project repo with the initial commit and CNAME file. I started here just to make sure the new domain name had time to percolate across the internet a bit.

Next to the key step where AI was helpful: using ChatCPT with a single prompt to create the countdown website (just a single HTML file):

This was the text of the prompt:

How to create a fun event countdown web site with a big months, day, hour, minute, second countdown floating on top of a background image that rotates periodically?

(Writing this post now, I notice I started with "How to create..." rather than a more imperative like "Create...". That's probably a nuance that doesn't matter; ChatGPT answered my question by doing the thing anyways.)

I brought that index.html file into the GitHub app, adjusted the event title and date/time, and added a few Lake Tahoe image links from Unsplash. I also had to adjust to make sure the event and countdown were in Pacific time, and ChatGPT helped with me a code snippet for that.

Next I found a couple photos from my phone I wanted to include. I tried Copilot inside GitHub mobile and it worked very well; it created a pull request which I reviewed and merged.

The final step was turning on GitHub Pages for this domain and making sure everything worked. (This was the trickiest part of this whole experiment.) For most of this I had to log in to github.com because these settings aren't available in the mobile app. After a few rounds of custom DNS and GitHub settings, it worked! Even the custom domain SSL support worked after a short time.

So in the end, can you create a website while waiting for your barber? Yes of course.

Simple Lossless Image Compression

2025-10-14T00:00:00Z

During the migration from WordPress to Eleventy, I decided against the Eleventy standard image transform plugin and decided to just implement the pieces I needed. One remaining piece was automating the compression of images for better web performance. I usually prepare images before adding to the blog by adjusting to the right size and image type. That means in this script I'm sticking with lossless compression to save a few more bytes.

Because this blog system is built by JavaScript, I started by implementing the imagemin package and plugins. The script was quickly put together by Copilot and gave great results. However, I noticed the additional npm package dependencies contained quite a few security vulnerabilities. It turns out that much of the imagemin ecosystem is quite old.

Next I switched to ImageMagick and set up to run locally just on my Mac and just on command. (I might try something more automated in the future). With a little research and a few trial runs, I settled on some good settings for the types of PNG and JPEG files I have on the blog:

magick input.jpg -quality 85 -strip output.jpg
magick input.png -quality 00 -strip output.png

The resulting improvements:

JPEG files optimized: 85/126
PNG files optimized: 158/273
Total files optimized: 243/399
Original total size: 25.0 MB
Optimized total size: 22.8 MB
Total bytes saved: 2.1 MB (8.6%)

Solving my Image Dimension Problem with an Eleventy Transform

2025-08-18T00:00:00Z

When migrating from WordPress to Eleventy, I wanted to automatically add width and height attributes to my images for better performance and layout stability. The official Eleventy image plugin felt overcomplicated for my needs, so I built a simple transform that inspects image files and adds dimensions to HTML img tags during the build process.

Eleventy Image Handling

When I migrated this site from WordPress to Eleventy, the image transform plugin was already included in the starter blog template I cloned. This plugin does a lot including outputting multiple sizes and formats. I think it was doing too much for what I needed. I really struggled trying to bring over my WordPress posts and images in a way that retained the old links. Even referencing a local image from Markdown wasn't working. I decided to pull out the 11ty image transform and manage images myself.

I wanted to start with automatically adding height and width attributes, so this is what I tried:

Image plugin -- too complicated, removed
Inspect the image plugin source to possibly copy just the height/width code -- too complicated
Write my own plugin -- seems doable but probably overkill
Write a transform -- this is starting to look the best path!

Eleventy transforms are run late in the build cycle ("postprocessing") and allow any transformations of the built page content. I had a good outline of how I would approach writing this, so I wrote a short spec for Copilot to help. I should have saved that prompt, but I could not get this code to work even with a bunch of adjustments and iterations I made.

After an overnight break I decided to go up a level and just ask Copilot for what I wanted :) This was the simple prompt, focusing just on the outcome:

write an eleventy transform that will automatically add height and width attributes to any image found in the HTML source

This worked and with only minimal adjustments got me exactly what I needed!

Image Dimensions Transform

This is my solution for adding height and width attributes to image tags in the HTML output files. A few quick notes:

This transform examines the DOM to find all the images, inspect the image file to find the height and width, then add those attributes to the image element
We're only interested in .html output files
If the page doesn't have any images, skip it (importantly for transforms: they need to just return the original unmodified content)
Also skip any images hosted elsewhere (we're only processing local images)

To use this script, include this snippet in your eleventy.config.js file:

/**
 * Eleventy transform to add width and height to <img> tags
 */
eleventyConfig.addTransform(
  "img-dimensions",
  async function (content, outputPath) {
    if (!outputPath || !outputPath.endsWith(".html")) return content;

    const dom = new JSDOM(content);
    const imgs = dom.window.document.querySelectorAll(
      "img[src]:not([width]):not([height])",
    );

    // If no images, return the original content
    if (imgs.length === 0) return content;

    for (const img of imgs) {
      try {
        let src = img.getAttribute("src");
        if (src.startsWith("http")) continue; // Skip remote images

        // Remove leading slash if present
        let imgPath = src.replace(/^\//, "");
        let filePath = `./public/${imgPath}`;
        let buffer = await promisify(readFile)(filePath);
        let dimensions = imageSize(buffer);

        if (dimensions.width && dimensions.height) {
          img.setAttribute("width", dimensions.width);
          img.setAttribute("height", dimensions.height);
        }
      } catch (e) {
        console.log(
          `Error processing image ${img.getAttribute("src")}: ${e.message}`,
        );
      }
    }

    return dom.serialize();
  },
);

Also add these imports at the top of eleventy.config.js:

import { promisify } from "util";
import { readFile } from "fs";
import { imageSize } from "image-size";
import { JSDOM } from "jsdom";

Finally, install the new library dependencies:

npm install jsdom image-size

Example

Here's an example from my Summarizing YouTube Videos with LLMs post. In the Markdown source file, the image is included with this markup:

![Thumbnail for the Honey Influencer Scam YouTube video](/images/honey-scam-thumbnail.jpg)

After the build process and the image dimensions transform, the HTML has the alt text preserved and the newly calculated width and height attributes added:

<p><img src="/images/honey-scam-thumbnail.jpg" alt="Thumbnail for the Honey Influencer Scam YouTube video" width="300" height="180"></p>

One thing I need to look at is the build time. It's not doing any caching, so each build needs to process the 400+ images. Right now my img-dimensions is taking up 23% of the time which isn't horrible but could be better:

[11ty] Benchmark   2668ms  23%   706× (Configuration) "img-dimensions" Transform
[11ty] Benchmark   5770ms  50%   661× (Configuration) "gitLastModified" Nunjucks Filter
[11ty] Copied 453 Wrote 696 files in 11.48 seconds (16.5ms each, v3.0.0)

How to Add Playwright Automated Tests to an Eleventy Static Blog

2025-08-17T00:00:00Z

Now that this blog has moved to the Eleventy system, I wanted to add some simple smoke tests to make sure the build process is working correctly and catch me if I break anything. I decided to go with Playwright because we use it at work and it's been on my to-learn list. Everything worked well, and I achieved good test coverage with 10 different tests, each containing multiple assertions. The trickiest part was making it all run correctly in the GitHub Actions pipelines.

Learning Playwright

The Playwright docs are very good so I started there. Getting set up, writing some initial tests, learning about assertions and locators were my starting points.

Once I had the basic structure running, I created an outline of the tests I wanted to create. These are all pretty simple for this static site, with a focus on making sure everything was built correctly.

For each test I dropped the outline into a code comment like this:

/*
test home page
- go to home page
- confirm <title> is set to "Brian Cantoni"
- confirm <h1> heading is set to "Brian Cantoni"
- confirm exactly 10 blog posts are listed
*/

Then I would select the comment and ask Copilot to implement it. It did very well at this, particularly when using Agent mode and asking it to implement the test and then run it, iterating until it worked.

From the above outline, Copilot and I created the Playwright test:

test("Home page", async ({ page }) => {
  await expect(page).toHaveTitle(/Brian Cantoni/);
  await expect(
    page.getByRole("heading", { name: "Brian Cantoni" }),
  ).toBeVisible();
  await expect(page.locator("li.postlist-item")).toHaveCount(10);
});

This approach worked well unless I tried creating and selecting multiple comment blocks like this. Copilot got confused and started adding code in random locations in the JavaScript file and then reported the file as "corrupted" :) Another good reminder for having frequent git commits of your work in progress.

Playwright with Netlify Preview Builds

Beyond running tests locally, I wanted them to run against the Netlify preview builds as well. I have Netlify deploy previews configured against my private GitHub repo and every pull request creates a unique "preview" build that goes with it. I'm not using Netlify for the production build, but these preview builds are very helpful especially for checking any tricky changes.

To run tests against the preview build, the GitHub action workflow needs to wait for the preview deploy to finish before running the tests. Luckily there are a few published actions that do this, including JakePartusch/wait-for-netlify-action.

Incorporating this as an action step is quite simple:

- name: Wait for Netlify Deploy Preview
  id: waitForDeployPreview
  uses: jakepartusch/wait-for-netlify-action@v1.4

And then a later step uses the unique preview URL to run the tests:

- name: Run Playwright tests
  run: npx playwright test
  env:
    PLAYWRIGHT_BASE_URL: $

In the end it's a clean solution which works well, but it took so many incremental pushes to test the actions, it was frustrating. It didn't help that I trusted some Google AI search results which gave me a .yml workflow file that looked great but was far from a working example.

One thing I learned that really helped: Copilot very good at reviewing a workflow file and either pointing out improvements or actual problems (some of which were just dumb mistakes on my part).

Playwright with GitHub Build

Once I got the Netlify preview tests running, I realized I should also handle the simpler case of just building and testing on GitHub.

Doing this doesn't require any custom actions. Instead, it's just a sequence of starting the local server, waiting for that server to finish, and then running the tests:

- name: Start local server for Playwright
  run: npx http-server _site -p 8080 &

- name: Wait for server to start
  run: |
    timeout 30 bash -c 'until curl -f http://localhost:8080; do sleep 1; done'
    echo "Server is ready"

- name: Run Playwright tests
  run: npx playwright test
  env:
    PLAYWRIGHT_BASE_URL: http://localhost:8080

Right now, my smoke test coverage is pretty good and should catch any build issues. Also, now that the tests are part of the automatic build pipeline, it will be easy to add incremental tests for any issues that pop up.

Added: Just after publishing this blog post, I realized I had a problem with my .htaccess files (for Apache server redirects). With my new test framework in place, it was easy to add a set of checks to ensure that file is properly deployed.

The Playwright test report is uploaded as a zip file, but I want to adjust that to be viewable online.

This test setup is simple because the static blog is simple. (Really the only interactive part is the search box.) I want to learn and use Playwright for some actual applications too. This would have been great for end-to-end testing of my retired Tweetfave project.

Copilot is my Copilot

2025-07-24T00:00:00Z

Migrating this blog to Eleventy has been a good project for learning GitHub Copilot with some real-world scenarios and problem solving. We're currently using Cursor and other in-house AI tools at work, so playing with Copilot here has been a nice comparison. Here's a sample of several ways I used Copilot and how well it worked.

Overall experience with this blog project: Overall Copilot has been very helpful and it's been fun to learn how to get the most out of it. I believe my choice of popular technologies here (JavaScript, Python, Nunjucks templates, Eleventy blog system) have helped Copilot give good answers because there's a ton of existing knowledge out there. Ask mode, edit mode and inline suggestions have really improved even as I've just been using Copilot for a few months now. sentiment_satisfied

Agent mode: This was my first steps into letting the AI run in Agent mode and it showed how effective it can be. I haven't had it do anything super complicated, but for any type of "fix or improve this" task, just giving it the ability to iterate by making a change and then running a build was really helpful. For any new changes I'm most likely to start with Agent mode. sentiment_satisfied

Contextual questions: I like selecting something in a file and asking "explain this" or "why is this JavaScript file imported this way?". A great example was a weird-looking regular expression which it helpfully explained -- it was something I had implemented a few weeks ago but promptly forgot! Comments can be a gift to your future self. sentiment_satisfied

Creating scripts from a short spec: Copilot does very well when given even a short definition of what you want to accomplish. It tends to be pretty verbose and implements things the long simple way, but that's kind of my habit too. A great example was a markup change I needed made in all 600 blog post Markdown files. Originally I had Copilot running in Agent mode to find and modify these files, but it would either get stuck or pause after a few files. Instead I asked it to write the equivalent Python script which I then ran myself and it was quickly finished. Scripts also let you try one first to make sure it's right, then let it loose. sentiment_satisfied

Eleventy and Nunjucks templates: Just using straight Ask mode, Copilot was pretty knowledgeable about the Eleventy blog system and Nunjucks templates, but would sometimes get stuck on simple things or would suggest things that were incorrect. Adding custom instructions for Copilot helped a little bit (I think), but switching to Agent mode where it could check its own work really helped. (See above.) sentiment_neutral

Print stylesheets: Print stylesheets is something I've always found really helpful. Even if I'm the last person who still prints things, even printing to PDF comes through a lot cleaner. It's a nice touch for visitors to your site. For my WordPress site I had hand-crafted a print stylesheet, so I asked Copilot to do the same for the new Eleventy blog. I used a pretty simple prompt: "In this CSS file please create a print media stylesheet that will adjust styles to make everything look clean when printed. The index.html file is an example output page from this blog. I'd like the print output to include the page title, date and the content section." The results were pretty good, if not a bit verbose. It really liked the !important attribute and used it liberally :) I made a couple of manual tweaks but overall it worked pretty well. sentiment_neutral