Words by Vernacchia

Astro thus far...

alvernacchia@gmail.com (Alex Vernacchia) — Mon, 27 Feb 2023 00:00:00 GMT

import Redirect from "../../components/ClientRedirect/index.astro";

A New Blog? Why?

alvernacchia@gmail.com (Alex Vernacchia) — Tue, 31 Jan 2023 00:00:00 GMT

I've been working at Deliveroo for quite some time, just over 4 years in fact! (That's forever in tech years)

When I was hired, my background was pretty spcific to FE-esque (frontend) things.

Know my way around a browser ✅
Have set up and debugged too many webpack configs ✅
Investigated various styles of testing (still like TDD for unit tests. fight me) ✅
Kept up with Node.js, React, and other tech ✅
Can debate endlessly about shit... ✅
Knew Backbone.js, Angular.js, and React + could pick up most FE stacks ✅

Unfortunately, I moved to a different team after about 6-8 months and they didn't need many of these skills. Instead, they needed me to get up to speed with BE technologies. So, I did. It's what my team needed.

Over the years (yes, years) the teams I was/am responsible for improved vastly. Like, so amazing. Maybe that's another blog post, but I digress.

During that time, I let my FE knowledge slip. All the flame wars between Svelte, Solid, React Suspense (still a thing like it was a while ago?!?!), XState, Remix, etc. = 🍿. I didn't have time to have a look. Hot takes were my sources of information.

I am finally at a point where I can come back and investigate new FE tech! I've been lucky enough to schedule a half day every week to do so. My manager even supports it. Hell, it was his idea.

I'm really excited to get back into the FE space, allowing myself to evaluate different options and potentially bring some back to Deliveroo.

Anyway, I'll be blogging about my experiences on this site, which I built with Astro (awww yeahhhh, new and shiny).

Topics I'm looking at include, but are not limited to:

Chrome Extensions
- (post) My First Chrome Extension (Google Docs Default Zoom)
- (post) Google Workspace Zoom Default (more support!)
- (post) "Simulating" JS Events
(post) Adding post comments via utterances
(post) Different ways to do search on static sites
Frameworks / Meta-frameworks
- Astro
  - (post) Astro thus far...
  - (post) Astro Content Collection Month and Year Pages
- Next.js
- Remix
- qwik
- Vue.js
- Svelte
- SolidJS
- htmx
- Lit
React Aria
- (post) Part 1
Deno
React Server Components vs SRR vs everything
react-router
TanStack router
react-query (or tanstack query)
What's the best way to build/package/transpile things these days - it's been a while
Best way to have consistent types between backend/frontend + request validation
- tRPC
CSS / CSS-in-JS
- Vanilla Extract
- Tailwind - Will give it a try again as it's likely improved since I tried it when it first came out
Edge networks
- Deno deploy
- cloudflare workers
- deployment to these using frameworks
serverless
lambda layers
api gateways
how to do React properly starting from fresh in 2022/23". I feel like a lot of what I know/we do as a company is based on React 14-ish ideas. Are we leveraging suspense? What about the shiny new SSR capabilities?
E2e testing Frameworks
Vite
Vitest
Cloudflare
- R2
- D1
- Wrangler
- KV store
View transitions - Page transitions
- new thing for MPAs and stuff like that
Module federation
Micro front-end
React three journey
Bundlers + tree shaking based out compile mode (js common)
lambda layers
Andy osmani online book
OpenAI training for what you should focus on
Service workers
Framer
Bun
State Management
- Xstate
- Redux / Redux Toolkit
- Zustand
- Jotai
- MobX
Vanilla extract css
three.js
DynamoDB data modelling (not fe, but interesting to me and my role)

They are also in no order!

Astro thus far...

alvernacchia@gmail.com (Alex Vernacchia) — Mon, 27 Feb 2023 00:00:00 GMT

One of the purposes of this blog (see why) was to explore new technology in the frontend space. I wanted to blog about my learnings / progress (even if it was just me rereading things for that stats 📈).

So I looked at Astro, something I'd wanted to use for a while and went all in.

How it started

Starting it up was pretty simple. I used the yarn command from their website to scaffold the project, which I think used the started template?!? Definitely copied a lot of it from somewhere haha

I tried to edit the site a bit to tweak it to my needs and it was suprisingly easy. It took me a while to get used to the .astro files, which were all I used for a while (getting a feel for the framework). Only when I added search did I use something else.

The DX was very good. Maybe it's just me being jaded from the early versions of Next.js (yes, I'm looking at you, the upgrade from 7 to 8 or something along those lines), but it was really good. It felt like everything was set up, so when I ran the dev comamnd, IT 👏 JUST 👏 Worked 👏.

I had it publishing to Github pages (where this is hosted) after pushing to the main branch in no time. Either the scaffolding took care of this or their docs were really good and made this set up super easy.

I then went searching for ways to make it blog (i.e. publish static content). Since I started building this site a few days after v2.0.0 was released I had access to Content Collections. Boy are these nice. Super simple way to access colletion/MD/MDX data (I have yet to look at MDX, but it's on the list).

In the end, I had a blog up and running in only a couple days (in my spare time between actual work haha). I very much "borrowed" some of the things from Astro's examples repostory. Only after it was all deployed did I really look at the docs (typical dev haha).

Then I started writing content (not the best content, but content). I was amazed at the speed I was able to do it as it was just adding a Markdown file with some content (unpolished content 😉) and pushing the changes to Github.

How it's going

After writing a few blog posts, I wanted to add a few things, namely to help my non-existent SEO and/or discoverability. Not like I wanted to get to the top of Google, but wanted to see how it easy it would be to integrate things like a sitemap, robots.txt, RSS feed, and social open graph (FB + Twitter stuff, but really, who uses FB still 🤷)...

Turns out, for most of these things there are already prebuilt integrations that someone much smarter than me has taken the time to open source.

Sitemap via @astrojs/sitemap
RSS Feed via @astrojs/rss (not sure why it's not on the integrations page)
Open Graph via Custom Head Component
- Probably copied this from somewhere (thank you!)
- Easily added my own ability to designate images used for OG data via frontmatter (pretty nice, super easy)
Analytics via Custom Tracking Component
- Via Simple Analytics (because I care about you not being the product)

I also added things like comments, and I used astro-icon to add some "flare" to the blog entry metadata section (you're welcome).

I thought I was done, but I really wanted to add tags to the site as well (have not added them OG stuff yet). I followed the tutorial on their site, and with a few changes (using Content Collections), we were finished.

Overall, I've been super surprised at how easy it was to add all of this stuff. I actually wanted to do it instead of slog my way through things. I've used WordPress, Drupal, Jekyll, Gatsby (early days), Ghost, and Next.js (likely missed some) but really like this more. I'm not sure how to explain it...

Small nitpick

I didn't realise the links that I put in my Markdown files to other Markdown files via []() were not being translated to generated paths. Turns out that is not supported yet, which I found out on a couple of issues

Hopefully there will be a fix issued soon, but in the meantime I'll likely just put the paths there instead of using Markdown links (not looking to get into rehype or remark at the moment of writing this).

🔥 Update: I actually created a rehype plugin to do this specifically for Astro. Read about it here.

Future Ideas

I have an idea I want to explore in the future around displaying remote file content. Think something like embedding a gist on a site.

I want to be able to do this both from Markdown and an Astro component with the options of inlining it into the page on build or displaying it dynamically on page load. I know there's some React/Vue/whatever framework you want to use component out there that does this, but it's time to learn!

Adding Comments to this Thing

alvernacchia@gmail.com (Alex Vernacchia) — Sun, 19 Feb 2023 00:00:00 GMT

Hmm... so this site doesn't have comments. Let's fix that.

Since I'm pretty lazy, let's go for the easiest thing...

This blog will likely be read by devs, so why not give utterances a try?!?

utterances is:

A lightweight comments widget built on GitHub issues. Use GitHub issues for blog comments, wiki pages and more!

Sounds perfect... Let's add it to the site (i.e. hopefully you'll see something at the bottom of the page).

Update

And there we have it. It seems to be added to the page.

It was relatively simple as I used some info from this blog post. Ended up using standard JS instead of Svelte.

~Hopefully it works when it's deployed!~ IT WORKED! I love the lazy solution!

How do I search this thing?

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 23 Feb 2023 00:00:00 GMT

I want to add some search features to this static site. Not a huge thing, but would be a nice to have.

This gives me the opportunity to investigate all the different ways to go about adding search to a statically generate site.

My Options

What are my options?? Let's have a look.

Algolia

You've probably seen this technology on so many documentation sites, I know I have. It looks pretty decent for this site, as their free tier provides:

10,000 search + 10,000 recommend requests/mo and 10,000 records/mo

Let's be honest, I'm not going to hit that amount of search (this isn't a big blog). Let's have a look at how it's integrated on sites.

Seems like I have to sign up to get an API key and such. Maybe I'll try using "React InstanceSearch Hooks" tutorial to get started.

Typesense

At first, it seems free and pretty decent. Then you see that you have to either set up your own backend or use their cloud, both of which costs money.

It does seem to be a decent product though, but it's not easy to set up (tutorial) / I'm lazy. Likely going to forgo this one.

Load from Astro + Local Search

Seems like you can use Astro to load all posts on the "server" and then pass it to a client component.

It would look something like this (obviously not Astro format, but you get the gist):

import Search from "../components/Search.tsx";

const posts = await Astro.glob("../blog/*.md");
const searchablePosts = posts.filter((post) => !post.frontmatter.draft); // or whatever filters

return <Search client:load searchList={searchablePosts} />;

Then inside that, do some filtering/search. I've been quite partial to Fuse.js (even if my team didn't like it ha) and have used that many times.

Definitely a viable option.

Others

Seems like a lot of the others require you to generate some form of base, serve that, then search through it. Seems super custom. So likely not going to go with that.

My Choice

I think I'm going to be lazy and try to use Algolia because it's "easy." Hopefully those aren't famous last words.

Me trying to implement it

My god, this was a nightmare 😬.

I thought it would be so easy since everyone seems to use Algolia. Just add a JS snippet and you're done. It does everything else for you. Boy was I wrong.

Populating Search Indexes

It turns out you very much do have to prep data yourself. This involves parsing and uploading it to their site. It's almost as if I described this in the Others section before I choose my fate. Man, being lazy doens't pay off sometimes.

So, I built a node script to do it. You can see it here. I was lazy here and stole a lot from this blog post.

This runs on my Github workflow when I build and publish my blog, so it should have up-to-date information when new content is released.

Implementing the Search

This was sooooooo difficult to figure out. I started at their website and the first thing you're confronted with is whether to use InstantSearch, React InstanceSearch, React InstanceSearch Hooks, etc.

Damnnnnnn, that's a lot of choices.

So, I went for React InstanceSearch Hooks. I followed the instructions, trying to figure how to display results and how to style it (had to install a separate NPM package for this then import it). I ran into problems 🤦‍

Some of these problems were due to Astro and how I'd not added client:load to my React component. Even after doing that, there were still problems.

How do I style it? How do I move it to different parts of my sight? How do I get it show up as a modal?

That last part was the problem. I couldn't figure out how to do that just by using React InstantSearch Hooks. Turns out there's something called Autocomplete that does exactly what I want.

So, I abandoned everything I'd tried and started fresh. The Autocomplete docs had examples (only JS, not TS 😓) and some codesandbox examples. This was really helpful.

I ended up being able to implement that in a couple of hours. I only ate up about 200 of my 10K queries haha.

The Final Outcome

Now I have search on my site that updates when I publish new content (or even change content). I very much over-engineered it, driven by my want to be lazy. Maybe I should rethink that in the future 🤔?!?!

Like I mentioned before, I used this blog a lot at the start, but then moved to Autocomplete.

If you want to check out my code, here it is:

My First Chrome Extension

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 03 Feb 2023 00:00:00 GMT

import NewExtensionNameBanner from "../../../../components/NewExtensionNameBanner/index.astro";

**Update: See Introducing Google Workspace Zoom Default for an update!**

As much as I don't want to admit it, I'm getting old.

My job requires me to review a lot of Google Docs (😔), and, unfortunately, I am having trouble reading things when they are set to the zoom level of "100%."

I quickly ruled out changing the resolution settings on my monitors because I really like the space the higher resolutions afford.

So, now that I accepted the fact that my eyes can't do "100%" any more, how do I change the default zoom level in Google Docs.

After looking through all their setting and doing an extensive internet search, it turns out there is no native setting!!!

Well, I embarked on making my own. As a start, I asked myself, "how do you zoom in Google Docs?" There's two ways (hit me up if there's more...):

Use the "Zoom" feature in the Google Doc via the menu
Use the browser's zoom function

I don't like using the second option due to personal preference, which meant I was going with #1. Let's get to it!

Enter Chrome Extesions. I needed to execute a script to do something on the page to change the zoom.

But, bad news seemed to keep following me. Not only is there no way to set a default zoom level in Google Docs itself, there's no way to programmatically interact with the page. No variable on the window object etc.

This meant that I now have to simulate click and interactions on the page (see here). Fun, right?!?!

Even more fun is that the Google Docs use dynamic element IDs, so I had to figure out away around that (see here).

Okay, that's all a bit painful, but relatively easy. Now the difficult part, how does one create a Chrome Extension these days? I took to Twitter (is it still alive??) to find out...

<blockquote class="twitter-tweet"> <p lang="qam" dir="ltr"> <a href="https://twitter.com/plasmohq?ref_src=twsrc%5Etfw">@plasmohq</a> </p> — Mitch Friedman (@mitchfriedman5){" "} <a href="https://twitter.com/mitchfriedman5/status/1617959819595644930?ref_src=twsrc%5Etfw"> January 24, 2023 </a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"

</script>

And a buddy who I used to work with came through in clutch. Enter Plasmo.

Tbh, I had no experience with Chrome extensions, but this framework make it super easy to get up to speed and actually ship something.

My extension makes use of their plug-ins / modules / APIs for messaging and storage, saving me so much time to focus on what I wanted to do.

They had a good guide on how to automate the publishing of it to the Chrome Web Store (had to pay 😬💸), which I've since set up also. Makes it super simple for me to publish things when I release a new version via tagging.

Plasmo is great. If you want to do Chrome Extensions (or just browser extensions) I would seriously check it out.

Long story short, my extension is now published on the Chrome Web Store (Google Docs Zoom Default) and the source is available on Github.

There are some bugs I'd like to fix and features I'd like to add. See below!

Next steps

✅ Allow for usage in Sheets, Slides, and other Google Workspace applications that have zoom features (issue)
- Support for Docs + Sheets as of v0.2.0. Implementation for other applications is also easier now.
✅ Get it to work for larger documents (issue)
Add an active state to the pop up (issue)
✅ Make it prettier 💅

React Aria Exploration (Pt. 1)

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 03 Mar 2023 00:00:00 GMT

I started following Devon Govett on Twitter well before 2.0. I was looking at alternatives to webpack that would allow me to set up sample projects in seconds, not days (sorry webpack 😓).

Note: For those of you that don't know, he's the creator of Parcel and a slew of other things that you likely use everyday in the JS community.

So, I'm trolling Twitter one day (lurker status), and I see him tweet about something called "React Aria." I had an initial look and thought, "Damn, this would've helped solve so many problems we previously had in our design system. How can we potentially look at integrating this into ours so we don't have to roll our own??"

Fast forward ~2 years. I still hadn't looked at the library 😬. During that time I had been promoted (🕷️👨), added a second team to my responsibilities, and, you know, had life things going on. Well here we are now. Let's give it the good ole college try.

Accessibility Matters

Let me repeat, accessibility matters! I want everyone to be able to use the web. Nothing should stop someone from using one of the greatest resources known to humankind.

In order to keep true to that statement, as developers/engineers we need to do our best to ensure everyone can access the things on which we're working.

If you can't get behind the altruistic reasoning (sans benefits), then let's think about it this way. The more people you have using your site, the more potential customers you have.

Just because someone may have a bit more trouble using the web (browsers, phone, etc.) doesn't mean they don't want to purchase a product (i.e. give you money).

There are many groups of people looking to improve accessibility on the web. Have a look at the content below if you want to learn more.

W3C Web Accessibility Initiative (WAI)
- Responsible for publishing standards like WCAG
Accessible Rich Internet Application (ARIA) Authoring Practices Guide (APG)
UK Public Sector Accessibility Requirements
- Spoiler, based on the WCAG standards

React Spectrum

Let's start at the beginning. Adobe, yes the people responsible for Photoshop, have a design system called Spectrum.

They then have different implementations of the design system that include:

You can probably guess what each focuses on based on the name.

I'll be discussing the React Spectrum here, which is A React implementation of Spectrum, Adobe’s design system.

Well, duhhh... But, the cool thing is that there's actually a group of libraries (React Spectrum Libraries) that

help you build adaptive, accessible, and robust user experiences.

They include:

React Spectrum - design system itself (uses these other libraries below)
React Aria - A library of React Hooks that provides accessible UI primitives for your design system.
React Stately - A library of React Hooks that provides cross-platform state management for your design system.
Internationalized - Two framework-agnostic internationalization libraries for the web.
- Dates and times + Numbers

Now that we know that, let's get a move on!

React Aria

React Aria is pretty cool IMHO (and the fact that Adobe open sourced it)! It's designed to be flexible and integrated into any design system. So, that means you don't have to use React Spectrum to get the accessibility benefits if you don't want to.

🙌🏻 A huge step forward for accessibility on the web.

So, let's get right into it. I got set up quite quickly using Vite and Storybook. I looked around for a bit to see what the current, defacto way to set these things up, but got lost and settle on this. I'll write a whole other blog post on that topic. I've published my repository to Github.

Creating a Component

I started with the "easiest" component in any design system, the Button (joking about the easy part).

I used the default Button generated by Storybook when first initialising it. And then I went about creating an "React Aria" version of it. A super simple one.

If you have a look at them, they're pretty close to the same. Let's go through the differences...

useButton requires a ref and props

No biggie, created the ref and initialised the default props a different way. This hook then returns props that you spread over the component. They can be seen below:

All good so far!

usePress

So, you've looked through the examples and you're noticing a major difference. The "React Aria" Button doesn't have an onClick method defined in the props/types. If you go looking a bit deeper, you'll realise that it's not defined anywhere (not even on the AriaButtonProps types).

What gives??

Well, this is where usePress comes in, which aims to make "pressing something" across loads of environments easier. Instead of an onClick method there is an onPress method. This will used create the proper props that the Button will use (see above).

Different events?

Now that we've talked about how React Aria uses the onPress handler (or some variation of it), let's talk about the events.

Turns out, a standard onClick handler and the onPress handler receive different events. Hmmm....

The onClick event handler will receive a React SyntheticBaseEvent. That's what we're used to in React.

But, the onPress event handler will receive a PressEvent which looks like:

export interface PressEvent {
    /** The type of press event being fired. */
    type: "pressstart" | "pressend" | "pressup" | "press";
    /** The pointer type that triggered the press event. */
    pointerType: PointerType;
    /** The target element of the press event. */
    target: Element;
    /** Whether the shift keyboard modifier was held during the press event. */
    shiftKey: boolean;
    /** Whether the ctrl keyboard modifier was held during the press event. */
    ctrlKey: boolean;
    /** Whether the meta keyboard modifier was held during the press event. */
    metaKey: boolean;
    /** Whether the alt keyboard modifier was held during the press event. */
    altKey: boolean;
}

From the looks of it, this is just a paired down version of SyntheticBaseEvent with some helpful things like pointerType and the type (event type). Don't worry, the event target is still there and won't stop you from using event.target.WHATEVER in your code!

You may also notice there are not a lot of callable events, like preventDefault. Well React Aria handles this for you as well. No need!

The Final Output

With this, we've create a very generic button, with accessibility in mind, that can be used in a design system. We will leave the testing across a myriad of devices and environments to the React Aria team (thank you!).

To make sure we're following the standards and guidelines, we could add the accessibility extensions to Storybook (maybe one for next time)!

I'm going to continue to explore it a bit more over the next couple weeks and will post more about it!

Introducing Google Workspace Zoom Default

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 30 Mar 2023 00:00:00 GMT

import NewExtensionNameBanner from "../../../../components/NewExtensionNameBanner/index.astro";

I previously talked about my experience building my first Chrome Extension, Google Docs Zoom Default.

Since then, I've been hard at work enabling the functionality for more Google Workspace Applications. Thus, I'm introducing Google Workspace Zoom Default (hopefully the Web Store listing updates prior to me publishing this).

This is a pretty big release as it enables the same "default zoom" functionality in Google Sheets. This means that this Chrome Extension supports "default zoom" functionality in:

Google Docs
Google Sheets

Have a look at the functionality below!

The Future

It took a bit of time to implement this functionality, but I can promise you it was well worth it. I took the time to:

Set the base for other applications, such as Google Slides
Set a strategy for docs where users have "view only" permissions
Updated the extension's popup UI

Once again, Plasmo made it super easy to do these things.

You can see all the code on Github for the sake of transparency.

"Simulating" JS Events

alvernacchia@gmail.com (Alex Vernacchia) — Wed, 26 Apr 2023 00:00:00 GMT

import SandpackEnv from "../../../../components/Sandpack"; import Banner from "../../../../components/Banner/index.astro"; import { keyboardEventsDispatchEvents, keyboardEventsInputDotValue, keyboardEventsInputOnly, mouseEventsButtonOnly, mouseEventsDotClick, mouseEventsEventsClick, } from "./_simulating-js-events-code.js";

import NewExtensionNameBanner from "../../../../components/NewExtensionNameBanner/index.astro";

I've been working on my Google Workspace Zoom Default Chrome Extension to implement a requested feature where users can use custom zoom values in addition to the predefined zoom values that Google provides in their application's zoom dropdown.

I thought to myself, "I already simulate events. This should be easy." So, I started to try and figure it out. If you want to skip ahead, feel free to go to the "Implementing with chrome.debugger" section.

But first, let's have a look at how to "simulate events."

Mouse Events

Simulating mouse events is pretty simple. Or, is it?

Turns out there's many, many different ways to do it. Let's start by figuring out what events are dispatched when a user clicks the button. Try it out in the example below.

As you can see, there are three events that trigger when you click once (we'll only handle a single click).

These are (and executed in the following order):

mousedown
mouseup
click

Well well, there's three events that trigger. Fair enough.

What is interesting though is that click is at the end instead of the events instead of in the middle of the down and up events. Something to think about 😉

Let's try to replicate this now using just JS.

Using `.click()`

The first option you'd probably reach for (and myself), is using the click() method that exists on an HTMLElement.

Let's give it a shot and see how it works.

After trying that, do you see the problem with trying to use click() to simulate clicks with JS?

In case you didn't, the problem is that when using the click() method, the only event that is triggered when simulating the click is the "click" event. We are missing out on the "mousedown" and "mouseup" events.

This may be fine for some things, but may not work for everything.

Dispatching Events

Let's make this a bit more bulletproof. Instead of using the click() method, we can actually go about dispatching events on the element in question. To do this you use the EventTarget.dispatchEvent()

Something like below would dispatch a click event on the button.

const button = document.querySelector("button");
const event = new MouseEvent("click", {
    view: window,
    bubbles: true,
    cancelable: true,
    clientX: 0,
    clientY: 0,
    button: 0,
});
button.dispatchEvent(event);

Now, all we need to do is make into something that will execute all three events when a button is clicked. I've put it in the example below. Give it a shot.

🤯 BOOMMMMMM... Now we have finally simulated a "click" using JS. Finally 🔥

Gotchas (still...)

There's still some potential gotchas when it comes to simulating these events.

This is due to the pesky isTrusted property on the events. TL;DR - some browsers / apps will only respond to trusted events. From MDN:

The isTrusted read-only property of the Event interface is a boolean value that is true when the event was generated by a user action, and false when the event was created or modified by a script or dispatched via EventTarget.dispatchEvent().

This property cannot be faked, so when something won't happen due to this, you're pretty much out of luck (aside from what I'll show you below, which is a hack and only available to Chrome Extensions).

While this isn't a problem (for the most part) when simulating Mouse Events, it does become a problem when trying to simulate Keyboard Events, which I'll demonstrate in the next section.

Keyboard Events

Cool cool. Keyboard Events are going to be just as easy. You would've thought...

Let's see what triggers a Keyboard Event.

Depending on what key you hit the following events will fire(in order):

keydown
keypress
keyup

or, if hitting a key like "Shift":

keydown
keyup

Now that we've gotten these events down, let's try to simulate them. Good thing that we have KeyboardEvents that can be dispatched just like MouseEvents. Let's give it a shot.

Notice anything interesting?? In case you were too fixated on the "Console" window, have a look at the input. Unfortunately, while the events did fire there is nothing in the input box.

Remember how I talked about the isTrusted property on the Event (see above)? Well, this is very much what is happening here. The browser is being smart enough to not let scripts insert values in to input boxes. Basically, it's a security concern and browsers are right in doing this.

So, where do we go from here? I still want to simulate these events. Maybe we can change the input's value using JS. Let's give it a shot.

Perfect. It looks like my script is typing in the box. Before you celebrate, what is happening in the "Console" window?

Turns out, nothing is happening. There are no events being triggered despite us having listeners on them. So, we are not "simulating" events.

Unfortunately, what we can do with MouseEvents is not possible with KeyboardEvents due to browser security issues. We can get pretty far in making it either:

Dispatch the correct events
OR... emulate typing

Trusted Keyboard Events with Chrome Debugger

So, if all that's not possible, how am I going to implement the functionality in Google Workspace Zoom Default allowing my users to input custom zoom levels?

Let's explore a "workaround" by using the Chrome Debugger available to Chrome Extensions.

🚨 This only works with Chrome Extensions that have access to the chrome.debugger API 🚨

It turns out that Chrome Extensions can request access to the chrome.debugger API.

Note: As I have to ask for an elevated set of permissions to make this work, I will be releasing a separate extension containing this functionality. I don't want to force people into using something with which they're not comfortable.

To start, this approach has the content script message the Background Service Worker (BGSW). The BGSW then attaches the debugger, generates the necessary commands, and detaches the debugger.

It's relatively simple. It also shows a nice banner on your browser that shows what is happening (like it should).

The code looks something like below. I use Plasmo to implement this messaging, but it can be implemented via standard Message passing. Checkout the PR for more context on the changes.

// `req` is the request sent from the content script to the BGSW
const target = { tabId: req.tabId };

chrome.debugger.attach(target, "1.0");

chrome.debugger.sendCommand(target, "Input.insertText", {
    text: req.body.zoomValue, // this value is sent from the content script
});

// The two events below have to be used together. I don't know why... but they do...
chrome.debugger.sendCommand(target, "Input.dispatchKeyEvent", {
    type: "rawKeyDown",
    code: "Enter",
    key: "Enter",
    macCharCode: 13,
    nativeVirtualKeyCode: 13,
    text: "\r",
    unmodifiedText: "\r",
    windowsVirtualKeyCode: 13,
});
chrome.debugger.sendCommand(target, "Input.dispatchKeyEvent", {
    type: "char",
    text: "\r",
});

chrome.debugger.detach(target);

I'll hopefully be releasing the new Chrome Extension with this functionality soon 🤞

Astro Content Collection Month and Year Pages

alvernacchia@gmail.com (Alex Vernacchia) — Mon, 08 May 2023 00:00:00 GMT

<small style="display:block; text-align: center;">🚨 I assume we're building a static site in this post 🚨</small>

I thought I'd finally gotten familiar with Astro (see my other posts), but I was wrong.

It all started with me having trouble finding the post I wanted to update solely based on file name/slug. I thought more structure could help with this, so I made a change.

I switched from "the wild west" to organising my posts by year and month. As of now, my Content Collection's directory structure looks like this:

src/content/
└── blog
    └── 2023
        ├── 01
        │   └── a-new-blog-why.md
        ├── 02
        │   ├── 1-astro-thus-far.md
        │   ├── adding-comments-to-this-thing.md
        │   ├── how-do-search-this-thing.md
        │   └── my-first-chrome-extension.md
        ├── 03
        │   ├── 1-react-aria-exploration.md
        │   └── introducing-google-workspace-zoom-default.md
        ├── 04
        │   └── simulating-js-events.mdx
        └── 05
            └── astro-content-collection-month-and-year-pages.md

I really liked the new version as it bring more structure, but I quickly noticed something wasn't quite right.

The Problem

When I navigated to https://words.byvernacchia.com/blog/2023 or https://words.byvernacchia.com/blog/2023/02, instead of seeing a page that has all the posts for the year, or for the month of the year, I got a big ole "404 Not Found." Lovely.

I thought the "magic" of Astro would automatically create these pages for me. I was sorely mistaken 😔

After scouring their docs and posting a question on the Astro Discord, I realised there wasn't much help out there. So, I got down to it.

The Solution

Creating pages that display "Posts by Year" and "Posts by Month of the Year" both rely on the same underlying Astro APIs, Dynamic Routes and getStaticPaths().

Let's see how we can use these together to solve our problem.

Posts by Year

While we can use this strategy for any Content Collection, I will be using "blog" as per my example above.

Let's start by creating a page at src/pages/blog/[year]/index.astro. This is our "Dynamic Route" that will generate pages for every year. We can then use these pages to display the posts for that year. You can see [year] directory, which we'll use later.

Next, we add our getStaticPaths() function to the page we just created.

---
import path from "path";
import fs from "fs";

// Helper function that returns an array of directory
// names one level down from the given directory
const getDirsInDir = (dir: string) => {
    return fs
        .readdirSync(dir, { withFileTypes: true })
        .filter((item) => item.isDirectory())
        .map((item) => item.name);
};

export async function getStaticPaths() {
    // Define the absolute path to the base directory of the Content Collection
    const collectionDir = path.resolve(process.cwd(), "./src/content/blog/");

    // Create an array containing all top-level directories in the Content Collection (i.e. years)
    const yearsInDir = getDirsInDir(collectionDir);

    // Return an array of objects that Astro expects for it to build static paths
    // See https://docs.astro.build/en/reference/api-reference/#params
    return yearsInDir.map((yearDir) => {
        return {
            params: { year: yearDir },
        };
    });
}
---

After doing this, when running astro build the output will show something like this:

▶ src/pages/blog/[year]/index.astro
  └─ /blog/2023/index.html (+7ms)

If I were to add a 2024 folder, I would generate a /blog/2024/index.html page.

One more thing to do. Let's display the posts for that year on the page. To do this, we can use Astro's getCollection (outside of getStaticPaths()).

---
import { getCollection } from "astro:content";

// ... prior getStaticPaths() definition

const posts = await getCollection("blog", ({ data }) => {
    // Dynamic route value (from the "[year]" directory)
    const { year } = Astro.params;

    // Filter posts based on "pubDate" value and "year" param
    return data.pubDate.getFullYear().toString() === year;
});
---

In this example, the filtering of posts by year uses the post's frontmatter data (i.e. pubDate), but it will likely be different for you.

Posts by Month of the Year

Displaying Posts by Month of the Year is basically the same, but with some extra steps.

Let's start by creating a page at src/pages/blog/[year]/[month]/index.astro. This time, instead of just [year] we've added [month]. We'll use both of these "dynamic routes" later.

Just like before, we not add our getStaticPaths() function to the page we just created.

---
import path from "path";
import fs from "fs";

// Helper function that returns an array of directory
// names one level down from the given directory
const getDirsInDir = (dir: string) => {
    return fs
        .readdirSync(dir, { withFileTypes: true })
        .filter((item) => item.isDirectory())
        .map((item) => item.name);
};

export async function getStaticPaths() {
    // Define the absolute path to the base directory of the Content Collection
    const collectionDir = path.resolve(process.cwd(), "./src/content/blog/");

    // Create an array containing all top-level directories in the Content Collection (i.e. years)
    const yearsInDir = getDirsInDir(collectionDir);

    // Iterate via `flatMap` (to combine return values) through each "year" directory
    const paths = yearsInDir.flatMap((yearDiretory) => {
        // Create the absolute path to the directory
        const yearDir = path.resolve(
            process.cwd(),
            "./src/content/blog/",
            yearDiretory,
        );

        // Create an array containing all the top-level directories in the directory (i.e. months)
        const monthsInYearDir = getDirsInDir(yearDir);

        // Create and return objects that Astro expects for it to build static paths using year and month
        // See https://docs.astro.build/en/reference/api-reference/#params
        const fullPaths = monthsInYearDir.map((monthDirectory) => {
            return {
                params: { year: yearDiretory, month: monthDirectory },
            };
        });

        return fullPaths;
    });

    // Return the array of objects
    return paths;
}
---

This looks quite familiar to the getStaticPaths() function we created to list our posts for each year, doesn't it?

After doing this, when running astro build the output will show something like this:

▶ src/pages/blog/[year]/[month]/index.astro
  ├─ /blog/2023/01/index.html (+3ms)
  ├─ /blog/2023/02/index.html (+6ms)
  ├─ /blog/2023/03/index.html (+9ms)
  ├─ /blog/2023/04/index.html (+12ms)
  └─ /blog/2023/05/index.html (+15ms)

If I were to add some posts in January 2024, Astro would then generate a /blog/2024/01/index.html page.

Lastly, we have to display the posts for said year and month on the page.

---
import { getCollection } from "astro:content";

// ... prior getStaticPaths() definition

const posts = await getCollection("blog", ({ data }) => {
    // Dynamic route value (from the "[year]" and "[month]" directories)
    const { year, month } = Astro.params;

    // Check if post matches current year of page
    const isYear = data.pubDate.getFullYear().toString() === year;

    // Check if post matches current month of page
    // 🤔 Remember, `Date.prototype.getMonth()` is zero-based (where zero indicates the first month of the year).
    const isMonth = data.pubDate.getMonth() === parseInt(month, 10) - 1;

    // Return boolean indicating if post is of year and month
    return isMonth && isYear;
});
---

And There We Have It!

My blog (or your blog) now creates pages that will display a lists of posts by year and/or month of the year! To confirm, you can check out https://words.byvernacchia.com/blog/2023 or https://words.byvernacchia.com/blog/2023/02 (now they work).

Maybe I do have the hang of Astro!

You can use my blog as an example for the full integration. Or, post a comment below, and we can have a discusion!

Note: If you're developing with Windows, you'll have to join your paths differently in some of the functions above (i.e. with path.sep).

JS Framework Evaluations

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 18 May 2023 00:00:00 GMT

As I stated in my original post, I want to evaluate the frontend frameworks that have been created "recently."

I plan to delve into:

React
Svelte
SolidJS
Vue.js
Qwik
htmx
Lit
Astro (kind already started haha)

In addition, I'm also planning to explore "higher-level frameworks" that supplement these, such as:

React
- Next.js
- Remix
SvelteKit
SolidStart (May wait until this one is out of beta, or may not 🤷)
Nuxt

** Update **

Instead of building a Pokédex, I'll be building a Github Issue Viewer (and creator). This will allow for:

Login (via Github)
Playing around with APIs
Handling form submissions (basic issue creation)
Page transitions
Filtering
etc.

I'm going to be exploring some technologies to make life easier and develop more quickly. They include things like:

RadixUI
shadcn components
React Aria Components
etc...

I'll update you as I go!

** Old (not being done anymore) **

Alright, so I'm not about to dive into this without a game plan. I've got a project in mind to make this exploration a bit more fun. Let's build a Pokédex, using the PokéAPI! You'll be able to check out different Pokémon and even whip up your own. This will allow me to:

Play around with APIs
Handle form submissions
Understand pages transitions
And, who knows, maybe throw in a few more bells and whistles along the way!

Relative Markdown Paths in Astro via Rehype

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 11 May 2023 00:00:00 GMT

I stared using Astro and it blew my mind. It did everything I needed and even things I didn't know I needed. It upped my static site/SSG game very quickly.

After a couple blog posts I noticed something weird. When I clicked on a link, it gave me a 404. What gives??

I investigated further and realised that Astro doesn't modify the MD/MDX content of a Content Collection. This meant when I had a Markdown link that looked like this:

[relative link](./other-markdown.md)

It would be rendered exactly the same:

<a href="./other-markdown.md">relative link</a>

I assumed that Astro would transform these paths when it built the site. Unfortunately, I made an ass out of me (not you though, you're perfect).

Turns out I wasn't the only one surprised by this "missing" functionality. There's multiple issues (#5682, #5680) and an RFC (#424).

After reviewing all the issues and discussions it didn't seem like the Astro team would be focusing on fixing this problem anytime soon, so I decided to try my hand at it.

🚨 Update: The Astro team may be solving this using Assets. It's still experimental, but it's worth trying it out! I still learned a lot!

🚨 Update 2: I tried the experimental Assets feature out, but it didn't seem to work (I also misunderstood). Maybe we'll see if it can go directly in Astro 🤷

Enter rehype (and remark)

remark and reyhpe are part of the @unifiedjs collective and are used to transform Markdown and HTML respectively. They can even be used in combination.

rehype:

...is an ecosystem of plugins that work with HTML as structured data, specifically ASTs (abstract syntax trees). ASTs make it easy for programs to deal with HTML. We call those programs plugins. Plugins inspect and change trees.

remark:

...is a tool that transforms markdown with plugins. These plugins can inspect and change your markup.

TL;DR - rehype = HTML transforms. remark = Markdown transforms.

Note: As I write this, I realise the plugin I created could be a Remark plugin as well. I'll explore that in the rehype vs remark section below.

Anyway, these are some of the best frameworks that support modifying of Markdown and HTML via AST transforms, which is exactly what I needed to do.

Astro also supports both rehype and remark plugins! We're in luck, so let's get started.

Enter `astro-rehype-relative-markdown-links` (my plugin)

🚨 I built this for Astro exclusively and made a couple assumptions. They are:

You are rendering a static site (i.e. not using SSR)
You have a content collection residing at src/content/<content_collection>
You have a page that renders the above content collection at src/pages/<content_collection>/[...slug].astro

Links: Github • NPM

Essentially, this plugin will look through the AST created by rehype and look for the href nodes. Once it finds these nodes, it will:

Check if the path is a candidate to be transformed. The following criteria have to be met:
- The path is not empty
- The path does not represent an absolute path
- The file has an extension of .md or .mdx
Check to see if the path is a valid one (i.e. the relative file exists in relation to the current file)
Determine if the relative file has a custom slug defined in the frontmatter, and use it if available
Build and return the final path that is compatible with the final HTML generated by Astro

I didn't go too in-depth, but feel free to check out the code.

Usage

If you want to try it out, simply install the plugin and follow the configuration steps below.

yarn add astro-rehype-relative-markdown-links

astro.config.mjs

import rehypeAstroRelativeMarkdownLinks from "astro-rehype-relative-markdown-links";

// ...everything else

export default defineConfig({
    // ...everything else
    markdown: {
        rehypePlugins: [rehypeAstroRelativeMarkdownLinks],
    },
});

After integrating the plugin, the following link that is inside a src/content/blog/post.md file:

[relative link](./other-markdown.md)

Would be rendered as:

<a href="/blog/other-markdown">relative link</a>

rehype vs remark

Like I mentioned above, should this plugin be a rehype or remark plugin? As it stands, astro-rehype-relative-markdown-links is a rehype plugin. Did I make the right choice??? 🤔

I think I did. Let me explain.

remark is used to transform markdown files, while rehype transforms HTML. It really could've gone either way (i.e. transform path in Markdown or HTML), but I choose to transform the link (i.e. href) when converting the AST to the final HTML output. Thus, rehype was the choice.

Google Workspace Zoom Default - Extended

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 08 Jun 2023 00:00:00 GMT

import NewExtensionNameBanner from "../../../../components/NewExtensionNameBanner/index.astro";

Following my blog post where I explore "Simulating" JS Events, I finally did the work to implement custom zoom levels in my Chrome Extension, Google Workspace Zoom Default.

But, I actually didn't implement the functionality it in my existing extension. Why? You may ask.

Well, in order to use the chrome.debugger API, I have to request elevated permissions from the person using my extension. If I were to do this in my existing extension, all users would have to explicitly accept the new permissions I've requested.

This gives users the following options:

Open the extension and re-enable it, accepting new permissions
Open the extension and actively choose not to re-enable it due to new permissions
Not notice the extension has stopped working and it stays disabled

In my opinion, #2 and #3 are the most likely situation. Obviously, these are the worst possible outcomes for the people using my extension, and I want to enable as many people as possible to use the functionality I provide.

Based on this, I introduce the Google Workspace Zoom Default - Extended extension. This extension includes all the functionality of the regular extension AND allows for custom zoom values.

I've updated my YouTube video to demostrate the new functionality.

Hope this helps someone!

Past Context

I've written about building these Chrome Extensions previously! Feel free to have a look to get some context if you want!

As always, you can see all the code on Github for the sake of transparency.

View-only Default Zoom

alvernacchia@gmail.com (Alex Vernacchia) — Tue, 08 Aug 2023 00:00:00 GMT

import NewExtensionNameBanner from "../../../../components/NewExtensionNameBanner/index.astro";

One of the long-standing pieces of functionality I've wanted to implement in the "Google Workspace Zoom Default" extension (web store, web store Extended) is the ability to use it in view-only documents.

Finally, I've submitted a new version to the web store (0.6.1), which should be rolling out quite soon (pending an approval)!

The Problems

Docs is the only Workspace application where the default implementation doesn't work when the viewer has view-only permissions. This is because there is no select element shown to enable changing the zoom value.

Instead, a user has to:

Click into the "View" tab in the menu bar
Click/hover over the zoom option
Click the desired zoom value

It's all good clicking the "View" tab in the menu bar as it has an ID on the HTML element. But, this is where it starts to get a bit more wonky.

After clicking the tab, a dropdown appears. There is no indication of what dropdown applies to what tab, like there is elsewhere (it's essentially what allowed me to create the main functionality).

The same situation that happens when you hover or click the zoom option. It shows another dropdown with no indication to what it relates.

To address this lacking linkage, I have to locate the dropdowns in the least optimal way: by identifying text in an ARIA attribute. There are so many problems with this approach, I don't even know where to begin. But, here we are, playing with the hand we were dealt by the Google team.

It's Experimental

Given the problems outlined above, I didn't feel confident enough to release this as a default feature. Instead, I've put it behind an experimental flag. This means that it's disabled by default, and users have to enable it in the options page.

This approach gives me a bit more freedom to experiment with the implementation in the future while allowing users to disable it if it doesn't work for them.

Extras

I also did some extra work, which was nice, to revamp how I use Sentry. I ended up separating Sentry usage into two projects, one for each extension. This will help me troubleshoot errors much better!

Past Context

I've written about building these Chrome Extensions previously! Feel free to have a look to get some context if you want!

As always, you can see all the code on Github for the sake of transparency.

Optimising CI/CD Processes - Caching (all of it)

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 07 Dec 2023 00:00:00 GMT

ℹ️ This is a multipart series exploring CI/CD optimisations ℹ️

Intro!
Identifying Common Steps
Caching + Docker (and layer caching)
Test Parallelization
Hopper Configuration Upgrade (Deliveroo-specific)

Let's get on the same page!

A few things before we get started (I know you may have already read this. If so, skip this section).

First, I'm going to talk very specifically here about JS/TS projects, but these ideas can be applied to all CI/CD processes.

Second, I'm going to use CircleCI as the CI/CD platform when talking through examples. These concepts can likely apply to other CI/CD platforms.

Lastly, some definitions so we’re all on the same page:

Step: A step is a single unit of work in a CI/CD process
- For example, installing dependencies, setting up environment variables, initiating commands, etc.
Job: A collection of steps
- For example, running tests, linting code, building a Docker image, etc.
Build Pipeline: A collection of jobs that represents all work

Caching

Our build pipeline is identical between code changes (unless explicitly changed).

This means we can, and should, try our best to reuse outputs from previous builds to speed up the next build.

You know where I'm going! I'm saying we should cache outputs of our build pipeline for later!

Some common examples in the frontend world include node modules and Next.js' build output (likely loads more).

CircleCI provides an easy way to configure cacahing for your build pipeline (docs). The gist is:

- restore_cache:
      name: Restore Next cache
      keys:
          # To force update the next cache, simply bump the value of the NEXTJS_CACHE_VERSION in CircleCI and re-run your build
          - nextjs-cache-v1.0-{{ .Environment.NEXTJS_CACHE_VERSION }}-{{ checksum "package-lock.json" }}-{{ checksum ".nvmrc" }}
- save_cache:
      name: Save Next cache
      # To force update the next cache, simply bump the value of the NEXTJS_CACHE_VERSION in CircleCI and re-run your build
      key: nextjs-cache-v1.0-{{ .Environment.NEXTJS_CACHE_VERSION }}-{{ checksum "package-lock.json" }}-{{ checksum ".nvmrc" }}
      paths:
          - ./.next/cache

IMO the most important part in the configuration above is the value for the key option. CircleCI uses this to determine if it can reuse a previously generated cache or not.

You can see from the configuration above that I'm using dynamic values:

{{ checksum "package-lock.json" }} - Don't use the cache if dependencies have changed
{{ checksum ".nvmrc" }} - Don't use the cache if the version of Node.js has changed
{{ .Environment.NEXTJS_CACHE_VERSION }} - Don't use the cache if the CircleCI environment variable has been updated
- This is really helpful if you want to cache bust without releasing code.

TL;DR - If the key is the same between build pipelines, then the cache will be loaded and reused, speeding up builds.

We use the circleci/node orb to cache our node_modules directory. The configuration looks like:

install_deps: &install_deps
    steps:
        - checkout
        - node/install-packages:
              cache-version: node-modules-cache-v1.0-{{ .Environment.NODE_MODULES_CACHE_VERSION }}-{{ checksum "package-lock.json" }}-{{ checksum ".nvmrc" }}
              cache-path: ~/project/node_modules
              override-ci-command: "[ ! -d node_modules ] && npm ci --no-fund --no-audit || echo 'Using cached node_modules directory'"
              include-branch-in-cache-key: false
        - persist_to_workspace:
              root: .
              paths:
                  - node_modules

This reduced the installation time of node modules from ~4-5 minute to ~2 minutes consistently.

When the cache needs to be regenerated (i.e. new dependencies are installed, Node.js version updated, etc.), the build pipeline will take more time. But, after the first time this is done, we go back to ~2 minutes.

Jobs that depend on this cache can then attach the workspace, not needing to install dependencies themselves!

Docker (and layer caching)

CircleCI provides a paid feature called Docker Layer Caching.

Essentially, if you're using their remote Docker environment to build your Docker images, you can have benefits local layer caching in a remote environment.

I'm going to quickly break it down here.

When building a Docker image locally for the first time, all necessary steps are executed (i.e. fresh "build").

When you build the image a second time, Docker is smart enough to understand what has and hasn't changed between builds.

It will only execute the necessary "fresh" steps, using the cached outputs from previous builds when it can.

This is what you get in CircleCI.

For this reason, it's important to understand how Docker layer caching works at a fundamental level. Let's use the two configurations below as examples.

Config 1

FROM node:20.9.0-alpine
ENV NODE_ENV=production

# Copy the built app
COPY . .

# Only install production dependencies
RUN npm ci --omit=dev --ignore-scripts

# Start app
CMD npm start

Config 2

FROM node:20.9.0-alpine
ENV NODE_ENV=production

# Only install production dependencies
COPY package.json package-lock.json ./
RUN npm ci --omit=dev --ignore-scripts

# Copy the built app
COPY . .

# Start app
CMD npm start

Config 1 uses a base Node.js image and:

Copies the application code
Installs the necessary dependencies
Creates the start command

Config 2 uses a base Node.js image and:

Copies the package.json (and lockfile)
Installs the necessary dependencies
Copies the application code
Creates the start command

You're probably looking at these and asking, how do the slight differences in these configurations affect the outcome?? Or, you're a smart cookie and already know!

Thought about it?!?

Assuming you build a Docker image whenever application code changes, Config 1 will never use layer caching when installing dependencies, but Config 2 will (if you've not added any new dependencies)!

Why?!?!

Config 1 copies the application code before dependencies are installed. Because of this, the only way the layer executing "npm ci" would be cached is if nothing in the application code changed. Since a Docker image is built when application code changes, this will never happen.

Config 2 installs dependencies prior to copying the application code, allowing Docker to use its cool caching! If new dependencies are installed no caching will be used, rather Docker will run the command and output a cached layer for the next build.

Pretty cool right?!!?

Be sure to have a look at the other posts (links at the top) in this series about optimising CI/CD processes!

Optimising CI/CD Processes - Hopper Configuration Upgrade

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 07 Dec 2023 00:00:00 GMT

ℹ️ This is a multipart series exploring CI/CD optimisations ℹ️

Intro!
Identifying Common Steps
Caching + Docker (and layer caching)
Test Parallelization
Hopper Configuration Upgrade (Deliveroo-specific)

Hopper configuration upgrade

Hopper is the deployment software we use at Deliveroo. It deploys our services and Lambdas to AWS. It's really cool, tbh, but, I'm slightly biased 😉.

The team responsible for Hopper recently released a v2 Configuration. There's a lot of things that come with it, but mostly it aims to streamline processes and provides additional, helpful configuration options.

The service I was working on was, unfortunately, not using this new configuration.

After upgrading to v2 (which the team made super simple), we saw our deployments go from between 6-11 minutes to less than 5 minutes consistently.

Lesson here is that it always pays to stay up to date! There's loads of places this lesson can be applied, but I'll leave you to figure them out!

Be sure to have a look at the other posts (links at the top) in this series about optimising CI/CD processes!

Optimising CI/CD Processes - Identifying Common Steps

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 07 Dec 2023 00:00:00 GMT

ℹ️ This is a multipart series exploring CI/CD optimisations ℹ️

Intro!
Identifying Common Steps
Caching + Docker (and layer caching)
Test Parallelization
Hopper Configuration Upgrade (Deliveroo-specific)

Let's get on the same page!

A few things before we get started (I know you may have already read this. If so, skip this section).

First, I'm going to talk very specifically here about JS/TS projects, but these ideas can be applied to all CI/CD processes.

Second, I'm going to use CircleCI as the CI/CD platform when talking through examples. These concepts can likely apply to other CI/CD platforms.

Lastly, some definitions so we're all on the same page:

Step: A step is a single unit of work in a CI/CD process
- For example, installing dependencies, setting up environment variables, initiating commands, etc.
Job: A collection of steps
- For example, running tests, linting code, building a Docker image, etc.
Build Pipeline: A collection of jobs that represents all work

Identifying common steps

Ask yourself, "are there any steps that are common across multiple jobs?" or "does my build pipeline have multiple jobs with similar steps?".

If you answered, "Yes," you can have a go at extracting these similar steps into a single job, which can then be used by other jobs.

Let's look at a concrete example.

We have two jobs, test and build. Both of these jobs need the same dependencies to be installed, thus they both have an "Install Dependencies" step.

flowchart LR
    id1([Install Dependencies]) --> id2(["Run Tests"])

flowchart LR
    id1([Install Dependencies]) --> id2(["Build App"])

The "Install Dependencies" step is common to both. It's a prime candidate to be extracted to its own job!

In the newly extracted job, we can install the dependencies and save them as an artifact, allowing for other jobs in the Build Pipeline to use them! I'll talk more about this in my post about caching.

Once we've extracted the job our Build Pipeline would look something like this:

flowchart LR
    id1([Install Dependencies]) --> id2(["Run Tests"]) & id3(["Build App"])

This helps in many ways.

First, we cut down on wasted time, and likely money, by not doing the exact same thing twice in two different places.

Second, it introduces consistency. While we should be installing the exact same dependencies everywhere (based on our lockfile), sometimes this may not be the case.

By installing dependencies in one place and reusing them, we can ensure the exact same dependencies are used for building, testing, linting, and running our application.

Be sure to have a look at the other posts (links at the top) in this series about optimising CI/CD processes!

Optimising CI/CD Processes - The Beginning

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 08 Dec 2023 00:00:00 GMT

ℹ️ This is a multipart series exploring CI/CD optimisations ℹ️

I'll be talking about some Deliveroo-specific things in this series. When I do, I'll be sure to provide as much context as possible.

I recently moved to a new team at Deliveroo. I started contributing as much as possible to one of primary codebases used in the area to get up to speed more quickly. Getting down and dirty is the best form of learning, right?

From the beginning, I noticed extremely long feedback loops when implementing changes. The process of releasing changes to production are:

Develop and test change locally
Run a subset of the CI/CD process (no deployments) against the feature branch (~17 minutes)
Deployed to the staging environment
- CI/CD (~23 minutes)
- Deployment (~6 minutes)
Test in staging
Deployed to the production environment
- CI/CD (~23 minutes)
- Deployment (~6 minutes)
Test in production

I've put the durations of each step (p95) above. Excluding development and manual testing, if everything went perfectly (does it ever?!), the whole process would take a minimum of ~75 minutes.

DAMNNNNN, that's a long time, huh?!?!

But, this begs the question, is the CI/CD time the right thing to be measuring?

I would say no. IMO (which is opinionated), we should be measuring the time it takes a team to deliver value to customers. To put it more simply, how long does it take to get a change to production, from the moment work begins to the moment a customer starts using it?

For those of you following along, you may know where I'm going next.

Lead Time for Changes, a DORA metric, is a great metric to track, and the one I'm going to focus on in this post. Disagree with me in the comments (or don't, up to you).

Lead Time for Changes encompasses much more than just CI/CD (again IMO). For example, how long it takes for a commit to get into production also depends on our interactions with Product Manager/Owners, Designers, other engineers (via reviews), etc.

At Deliveroo, our deployment system, Hopper, tracks this metric automagically for us, which is amazing.

Before I started the work I describe in this post, we had quite a high Lead Time to Change (can't really say the actual number...).

After these optimisations were implemented, we saw around a 50% reduction. More can be done to reduce this number outside the CI/CD process.

🚨 I'm not saying that all the reduction is attributed to these optimisations, but after gathering qualitative feedback from myself (so unbiased) and the teams I work with, I can say they were definitely helpful!

Let's get on the same page!

A few things before we get started.

First, I'm going to talk very specifically here about JS/TS projects, but these ideas can be applied to all CI/CD processes.

Second, I'm going to use CircleCI as the CI/CD platform when talking through examples. These concepts can likely apply to other CI/CD platforms.

Lastly, some definitions so we're all on the same page:

Step: A step is a single unit of work in a CI/CD process
- For example, installing dependencies, setting up environment variables, initiating commands, etc.
Job: A collection of steps
- For example, running tests, linting code, building a Docker image, etc.
Build Pipeline: A collection of jobs that represents all work

Go learn!

Optimising CI/CD Processes - Test Parallelization

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 07 Dec 2023 00:00:00 GMT

ℹ️ This is a multipart series exploring CI/CD optimisations ℹ️

Intro!
Identifying Common Steps
Caching + Docker (and layer caching)
Test Parallelization
Hopper Configuration Upgrade (Deliveroo-specific)

Test parallelization

Running tests is one of the things that usually takes a fair amount of time (at least in JS/TS projects).

The amount of time it takes to run tests depends on:

How many tests you have
What executes them
Where and how they are executed

This means it's important to write the right tests (maybe try TDD) and use a performant test framework.

Sometimes we unfortunately can't adhere to all of these. Or, we did, once upon a time, and we're now stuck.

For example, we are "stuck" with Jest and will not be updating to something like vitest (which is fast, but won't solve all your problems).

This means we have to try other things to solve our slow running of tests. One of those being the execution of tests in parallel.

Jest

Jest is used quite a lot across the industry, and it's rare that you find anything else in established companies (maybe Mocha if you're lucky 😉).

Jest, by default, runs tests in parallel when using single run mode:

In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread.

When watching for changes, it's slightly different:

...this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt.

It's even recommend to use a max worker threads value of 50% in environments where CPU cores vary (i.e. CI/CD platforms):

For environments with variable CPUs available, you can use percentage based configuration: --maxWorkers=50%

Cool, that's out the of way... But, this can only get you so far.

Jest also provides you the ability to shard your tests across different build agents using the --shard flag.

CircleCI allows for multiple build agents by adding a parallelism: XXX configuration option to your job. You can then update your testing step to be something along the lines of:

# npm test="jest"
npm run test -- --shard=$(expr $CIRCLE_NODE_INDEX + 1)/$CIRCLE_NODE_TOTAL

This will divide the tests into groups and execute them across the agents.

To make the extremely clear, let's use the following example.

I've set up my CircleCI job with a parallelism: 3. I have a test suite with 900 tests. CircleCI will then run 300 tests across each build agent in parallel.

You can see how this could cut execution time down!

Cypress

We use Cypress for our end-to-end tests. It's a great tool, but it can be slow to run tests (even using the latest version of Cypress on Node.js v20).

Thus, I went searching for ways to run Cypress tests in parallel, just like our Jest unit tests.

The first thing I found is their paid product, Cypress Cloud. It offers exactly what I want, parallelization (and optimisation of said parallelization).

But, I'm not in a position to onboard a new third party for my company, so I had to look elsewhere.

After a bunch of digging, I found a simple way to do it!

First, we have to enable parallelism: XXX in our CircleCI job (like our Jest unit tests).

Next, we have to find a way to divide our tests into groups. CircleCI makes this super simple using their command line tool (it took me a while to find this actually).

TESTS=$(circleci tests glob "cypress/e2e/**/*.cy.ts" | circleci tests split | paste -sd ',')

# npm e2e="cypress run"
npm run e2e -- --spec "$TESTS"

Let's break it down.

First, we run:

circleci tests glob "cypress/e2e/**/*.cy.ts"

This generates a full list of our tests based on the glob, like below:

cypress/e2e/analytics/Home.cy.ts
cypress/e2e/analytics/ViewMetrics.cy.ts
cypress/e2e/deliveryAreas/FleetSwitching.cy.ts
cypress/e2e/deliveryAreas/ViewAreasAndFees.cy.ts
cypress/e2e/liveOrders/FleetSwitching.cy.ts
cypress/e2e/liveOrders/OrderNotification.cy.ts
cypress/e2e/marketer/CancelOffer.cy.ts
cypress/e2e/marketer/CreateOfferBasket.cy.ts
cypress/e2e/marketer/CreateOfferFlashDeal.cy.ts
cypress/e2e/marketer/CreateOfferItem.cy.ts
cypress/e2e/marketer/CreateOneOffCampaign.cy.ts
cypress/e2e/marketer/CreateOverlappingOffer.cy.ts
cypress/e2e/marketer/CreateWeeklyCampaign.cy.ts
cypress/e2e/marketer/Home.cy.ts
cypress/e2e/marketer/ViewOffer.cy.ts
cypress/e2e/reportingPlatform/CreateReport.cy.ts
cypress/e2e/reportingPlatform/CreateScheduledReport.cy.ts
cypress/e2e/sales/Refunds.cy.ts

Then, we pipe that response into the circleci tests split command, which will split the tests into groups based on the number of build agents we've defined.

cypress/e2e/analytics/Home.cy.ts
cypress/e2e/deliveryAreas/ViewAreasAndFees.cy.ts
cypress/e2e/marketer/CancelOffer.cy.ts
cypress/e2e/marketer/CreateOfferItem.cy.ts
cypress/e2e/marketer/CreateWeeklyCampaign.cy.ts
cypress/e2e/reportingPlatform/CreateReport.cy.ts

Finally, the response is piped to the paste -sd ',' command, which will join the tests together with a comma.

cypress/e2e/analytics/Home.cy.ts,cypress/e2e/deliveryAreas/ViewAreasAndFees.cy.ts,cypress/e2e/marketer/CancelOffer.cy.ts,cypress/e2e/marketer/CreateOfferItem.cy.ts,cypress/e2e/marketer/CreateWeeklyCampaign.cy.ts,cypress/e2e/reportingPlatform/CreateReport.cy.ts

This is then used by our Cypress command to run only a subset of tests.

A cheeky optimization

CircleCI has a bit of a cheeky optimisation that can be used here, which will help us shave off some time by optimising how the tests are split. We'd need to update our command like below:

- circleci tests glob "cypress/e2e/**/*.cy.ts" | circleci tests split | paste -sd ','
+ circleci tests glob "cypress/e2e/**/*.cy.ts" | circleci tests split --split-by=timings | paste -sd ','

Here, I use the --split-by argument with a value of timings.

Note: You need to have the JUnit reporter enabled for this to work, as that is what provides the necessary timing information to CircleCI.

This is actually really cool! Since CircleCI consumes your testing framework's JUnit report, it knows how long it takes to run individual tests.

This means that when it splits them into groups for parallellization, it can do so in a way that optimizes for the fastest execution time.

For example, we have two build agents and four tests to run across them.

Test 1: 30 sec
Test 2: 35 sec
Test 3: 1 min
Test 4: 55 sec

Without the --split-by=timings argument, the tests could be split in any fashion. This means we could end up with one build agent taking 1m55s to complete, while the other takes 55s.

With the --split-by=timings argument, the tests will be split into groups that take the same approximate time. In this case, we'd usually get tests split so both build agents would run tests for 1m30s.

I absolutely love this, and I definitely wouldn't have thought about this myself!

Local Testing

All things related to testing, linting, building images, and any other steps in your Build Pipeline should be first class citizen in your local development environment.

To put it more bluntly, doing all these things in your local environment is essential. CI/CD should not be used as substitute for local testing, which I've seen many times before.

Be sure to have a look at the other posts (links at the top) in this series about optimising CI/CD processes!

Goodbye Enzyme

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 19 Apr 2024 00:00:00 GMT

import { Tweet } from "@astro-community/astro-embed-twitter"; import Banner from "../../../../components/Banner/index.astro";

I've showed my age in the previous post, so I won't do it again. But, for the purposes of this post, I will say that I've been a professional in the industry prior to Enzyme, during its height, and after it (i.e. now).

This leads me to say, using my expert opinion, "Goodbye Enzyme, and good riddance. You will not be missed."

That may seem harsh, but I stand behind it. I've recently removed Enzyme from multiple, highly used codebases at my work and have see the horrors caused by Enzyme. I'll cover some of these in this article, comparing it to React Testing Library.

Enzyme? React Testing Library (RTL)? What are they?

They are both testing frameworks aiming to make it easier to test React components. They both have their own philosophies and ways of doing things.

Enzyme

Enzyme is a JavaScript Testing utility for React that makes it easier to test your React Components' output. You can also manipulate, traverse, and in some ways simulate runtime given the output.

RTL

You want to write maintainable tests that give you high confidence that your components are working for your users. As a part of this goal, you want your tests to avoid including implementation details so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

These differing philosophies are the main reason why I prefer RTL over Enzyme. Enzyme is more focused on the "output" of a component. Additionally, they talk about traversing, manipulating, and simulating the output, which does not align with how actual users would be interacting with it.

On the other hand, RTL is more focused on the "functionality" of a component. It is more concerned with how a user would interact with the component, and how the component would respond to that interaction. ❤️

<Banner type="info"> I'm going to use personal anecdote. These may not match your experience. </Banner>

Problems with Enzyme

Testing async scenarios is difficult

One of the biggest issues I've had with Enzyme is testing async scenarios. Unless you're purely working on a presentational component, most components will have some form of async natur. Something like data loading, form input and validation, etc.

You'll need to perform an action, wait for the async action to complete, then move on with your test.

This is a nightmare to do in Enzyme. Code using setTimeout, setInterval, setImmediate, await Promise.resolve() or similar is likely trying to account for these async actions. It's HACKY... and I never liked doing it, even though there was no other way.

RTL handles this much better in two ways, maybe more.

First, RTL provides a waitFor utility. It allows you to wait for a condition to be true before moving on with the test. This can be used in a sync or async manner. Using it in an async manner will ensure that the async action has completed before moving on.

Second, the @testing-library/user-event package provides utility methods to help deal with user interactions. When a user interaction triggers an async action via a command like click, type, clear, etc., the command can be awaited to ensure the async action has completed.

This functionality is only in the newer versions of user-event, but it's already proved amazingly helpful.

Simulating interactions

When testing user interactions, Enzyme simulates events in a programmatic way by dispatching DOM events.

IMO, this doesn't mimic real user interaction as there may be multiple events that can fire in a single interaction.

For example, how many events fire when clicking a button? Well, there's quite a few:

mouseover
mousedown
mouseup
click (interesting that this is after mouseup... hmmm haha)
mouseout

If you're only simulating a "click" you're missing out on a lot of the events that would happen during an interaction. This leads to less confidence in your tests (IMO).

<Banner type="info"> Checkout my in-depth post about Simulating Events for more context! </Banner>

Or, if we take an example directly from their website:

For example, when a user types into a text box, the element has to be focused, and then keyboard and input events are fired and the selection and value on the element are manipulated as they type.

RTL, on the other hand, uses the @testing-library/user-event package to simulate user interactions (you can still use the fireEvent method though if you really want to). This takes into account the multitude events that could happen when a user interacts with a component.

Having access to props

This is a killer... and I hate it. I've seen it abused so many times.

You can see a basic form below.

const Component = ({ onSubmit }) => {
    return (
        <form onSubmit={onSubmit}>
            <input type="text" name="input1" />
            <input type="text" name="input2" />
            <button type="submit" onSubmit={onSubmit}>
                Submit
            </button>
        </form>
    );
};

It's likely there's some form of validation on the inputs and once the form is submitted some action has to take place.

In Enzyme, you can access the props of a component and call the onSubmit function directly, allowing something like:

it("should submit form", () => {
    const someAsyncAction = jest.fn();
    const onSubmit = () => {
        someAsyncAction();
    };
    const wrapper = shallow(<Component onSubmit={onSubmit} />);

    wrapper.find("form").props("onSubmit")();

    expect(someAsyncAction).toHaveBeenCalled();
});

This is hard to look at. There's no user interaction and no validity checks. We're just calling a function directly (yes, I have seen this in real life).

While this is a simple example, you can see how it would open the door for lazy testing (and it does).

/endrant

While Enzyme was an absolute killer when it first came out, enabling the testing of UI components like we'd not seen before, it's not fit for purpose anymore.

It actively encourages bad practices, can't be used past v16 of React (with an official adapter), isn't maintained, and has a philosophy that doesn't align with how users interact with components.

Please, please consider using RTL for your testing needs. It's a much better framework that encourages better testing.

Goodbye Enzyme, and good riddance. You will not be missed.

Snapshot Testing Sucks

alvernacchia@gmail.com (Alex Vernacchia) — Mon, 01 Apr 2024 00:00:00 GMT

I remember a time when jQuery was the framework and WordPress was almighty.

Eventually, Backbone.js and Angular became the big players on the block. Knockout.js had just made it onto the scene. React was still only being used internally at Facebook. RequireJS was a cause of many headaches.

If you wrote tests, you used Mocha. Karma came along and made it "easy" to run tests in an actual browser.

Have I shown my age enough yet??

But, React hit the scene and Enzyme emerged as the default testing framework. It allowed you to test components pretty easily. Tbh, I'm not sure what else I would've used to test React components back then. It was great, but it definitely was a footgun if left unchecked.

I've recently removed Enzyme from multiple, highly used codebases at my work (replacing it with React Testing Library). I've seen it all, it's mostly bad.

I'll write more about the other bad things in another post, but this post will focus on the bane of my existance, Snapshot Testing, which, IMO, Enzyme proliferated with its enzyme-to-json serialiser.

What is Snapshot Testing?

After talking to iOS/Android engineers, I realise Snapshot Testing has multiple meanings. So, let's define Snapshot Testing.

When I say "Snapshot Testing," I'm referring to the practice of rendering a component, saving its output (i.e. the HTML/Enzyme structure), and comparing it to a previous version of that rendered output (i.e. "snapshot"). If the snapshots are different, the test fails.

I'm NOT talking about visual regression testing, which is what I've heard iOS/Android engineers define as their "Snapshot Testing."

Why Snapshot Testing sucks

The implicit nature of the tests

Snapshot Testing is implicit. If you're not the original author, it's extremely difficult to know what they were thinking when writing the test. Like, what were they actually testing? What's important? What does "render correctly" (the title of a lot of tests) mean?

IMO, extremely explicit test are soooo much better. You should be testing that the correct content is rendered and the interactions are what you'd expect.

When you're explicit, it lets others who come across your code in the future know what's important. Essentially, it's a form of documentation.

I know snapshot do have the "content" when rendered, but it's really lazy... Again, it's about what content is important.

Is the visual output actually the same after your change?

Snapshot Testing only tests the output of the component's HTML structure. It doesn't test the visual output.

I can change the CSS, which will change the visual output. Yet, the test will still pass because the structure is the same.

Is that a good test? I don't think so.

Nobody looks at the changes...

In my experience, nobody actually looks at the snapshot diffs before they update their tests. There's either too many changes or we "know" our new changes are "what it should be."

It's like the snapshot/test was written for the first, and only the first, iteration of the component.

This is the typical process I've observed:

Make the changes to the component
Assume whatever output is correct
Update the snapshot

This is just lazy. Something could be missed if you do this.

But, I understand why it happens. I've been guilty of this I hate to admit. It's done because most are not the original author of the code. They lack context. So, they make changes, test them somehow, and then update the snapshot.

This begs the question, "why even have the snapshot test in the first place?"

Updating common components... sucks

Let's take a moment to imagine something.

First, you have nine teams (30+ people) working on a single codebase. They each own their individual areas of the codebase. The way CODEOWNERS has been set up requires approvals by each team when their files are changed.

Second, common components/depenenceis are used across the entire codebase. These could be something like a design system, or a framework, like React.

When these are updated, all snapshots in the codebase need to be updated. This happened when React changed how Fragments are rendered (or Enzyme did, or whatever, you get the point).

Now you need to get sign-off from the all teams. In my experience, it takes a long time and can result in a lot of merge conflicts if not done quickly.

/endrant

Snapshot Testing was cool at the start, especially when working on small projects. But, as the project grows, it becomes a burden and, IMO, encourages bad practices.

So, I beg you, please don't use Snapshot Testing and remove it from your codebase if you can. You'll be better off (insert plug for React Testing Library).

But, hey, what do I know? I'm just some random guy on the interwebs...

The Importance of Linting

alvernacchia@gmail.com (Alex Vernacchia) — Sat, 27 Apr 2024 00:00:00 GMT

import { Tweet } from "@astro-community/astro-embed-twitter"; import Banner from "../../../../components/Banner/index.astro";

Yes, you should lint your code*.

Showing my age again, I remember when there were so many linters for JS. There was JSLint, JSHint, ESLint, and likely many more.

Finally, ESLint emerged as the default linter, with almost all companies adopting it.

I was on Twitter (yes, it's "Twitter") and saw this tweet from Michael Jackson:

After I got over my initial rage of someone suggesting that linting was not important, I realised it is all situational.

Before we get too far, let's talk about Prettier. Prettier is an opinonated code formatter, not a linter, with the main goal of enforcing consistent code style.

This is super different from a linter, which is more about finding and fixing problems in your code.

Now that we got that cleared up, we'll be focusing fully on linters!

Should you lint your code?

This is a great question. I usually ask myself a few questions before deciding when to lint my code.

How big is the project?
How many people are working on the project?
Is the project a personal, work, or OSS project?
Is the project a PoC or a production-ready project?
Do I care about errors??? (a bit of a joke, but also serious)

Yes, I should lint my code!

I'd lint my code if:

It's a big project is and a lot of people working on it
A lot of people contribute to the project
The project will be used in production
I do care about catching errors before they happen
It's a work project

Nah, I can get away without...

I know it's a work PoC, and it will be thrown away after (is this really ever the case though?)
It's a personal project, and I'm the only one working on it
I'm only working on it, and I want to move fast (I'll still use a formatter)

Yeah, but has it really saved you??

Yes... There's been so many things that linters have caught at my places of work.

One that helps all the time is import/resolver. This is less helpful now that we have amazing IDEs that do a lot of these things automatically, but it still catches things!

Essentially, this catches incorrect imports. If you try to import something from a file that doesn't exist, BOOM, error.

Does it always save you??

And no, it doesn't always save you. We recently had a problem where the linter didn't throw an error when an undefined function was called.

The function was supposed to be imported into the file, but, unfortunately it wasn't. This caused a runtime error.

After some investigation, it turns out ESLint's no-undef rule would've saved us. We thought it was enabled, but unfortunately, it wasn't. This was because:

... plugin:@typescript-eslint/recommended turns off no-undef because it's covered by TS, so double reporting is somewhat useless.

The reasoning makes sense, as TS should catch these errors (and the files in the offending PR were TS). But, it didn't. Why?

TL;DR - we'd disabled type checking because we were incrementally adopting TS across our codebase.

You can bet that we've enabled that rule now!

Long story short

You should lint your code if you work in a professional setting where many people contribute to a long-lived codebase (where you care about consistency and standards as time goes on).

Google Workspace Default Zoom is Everywhere!

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 27 Sep 2024 00:00:00 GMT

import Banner from "../../../../components/Banner/index.astro"; import NewExtensionNameBanner from "../../../../components/NewExtensionNameBanner/index.astro";

<NewExtensionNameBanner /> <Banner type="info"> For more context, feel free to have a look at my previous posts about building my extensions! </Banner>

Google Workspace Default Zoom is Everywhere!

When I started creating my browser extension, I focused on Google Chrome because we use Chrome as our default browser at work. Work is the place I primarily use the Google Workspace suite. Makes sense, huh?!?

But, obviously there are other browsers out there. I want to ensure my extension can be useful to as many people as possible. So, I started trying to figure out how to port my extension to other browsers.

I'm glad to announce, I've finally released the extension for both Firefox and Edge! 🎉

New Browsers!!

Firefox

I am only able to offer the base extension for Firefox. This means Firefox users can only use predefined zoom values. I talk more about why this is in the technical details section.

If you use Firefox, you can install the extension via the Firefox 🦊 Add-ons website.

Now those of you who don't want to ditch uBlock Origin can have this functionality! 😜

Edge

Edge uses Chromium under the hood, so all the features offered in both extension versions worked out of the box!

If you use Edge, you can install the extension from the Microsoft Edge Add-ons website:

Google Workspace Default Zoom
Google Workspace Default Zoom - Extended
- In exchange for allowing elevated permissions, this extension provides ability to set custom zoom levels (as opposed to only predefined values)

The Technical Deets (Details)

I know a lot of you come here for the technical details of things, so I won't disappoint and will get started!

As I've pointed out before, I use Plasmo to build my extension. From their website:

Plasmo helps you build, test, and deploy powerful, cutting-edge products on top of the web browser.

And, oh boy, it not disppoint! I was able to get the extension ported to Firefox and Edge relatively quickly.

I think the thing that took me the longest amount of time was figuring out how to become a Microsoft Edge Add-on developer. 😅 It also took me quite a while to configure the Edge store listings, even though I'd already documented them!

And... Edge store reviews take sooooooooooooo long. Dang.

Firefox

Okay, so making the extension available in Firefox was interesting, and I almost gave up a few times. But, I figured it out! Let's discuss.

Problems with Local Development

Using Plasmo in dev mode was impossible.

Firefox seemed to block the WebSocket connection (I think), which forced the extension to reload itself continuously. This made debugging impossible as the extension was never able to be used (it disappeared and reappeared too quickly). The only way to stop it was to disable the extension via the debugging page and/or stop the Plasmo dev server.

I ended up just running plasmo build after every change and reloading the extension. It was a bit of a pain, but it worked.

First hurdle done!

No Extended Version of the Extension 😞

Since I could now finally "develop" the extension in Firefox, I tried to use custom zoom values. But, it didn't work.

After some digging, I found an MDN page confirming the debugger permission is unavailable in Firefox.

While it's available in Manifest V2 and V3, when you actually go the Browser Compatibility section, you can see it's not supported in Firefox. 😭

This means I unfortunately cannot ship the Extended version of the extension to Firefox. I'm sorry Firefox users! 😞

I'll keep an eye out for any changes in the future! Promise!

Manifest V2 vs V3

When looking through Manifest differences between Firefox and Chrome, I thought, "Amazing, Firefox is transitioning to Manifest V3. This is the same version used by Chrome. I won't have to do much to make this work!" I was wrong...

I used Manifest V3 initially. All the docs say to define your Add-on's ID in the manifest. So, I went looking for my Add-on's ID. But, don't you have to publish it first before you get an ID? That's how the Chrome Webstore works...

After banging my head all over the place, it turns out you don't have to publish the Add-on to get an Add-on ID. You just create it yourself. Their docs don't explain this in a straightforward way.

So, I generated a UUID and added it to my manifest in the right form ({UUID}). Cool, Storage API is working. I test all the functionality and it works (minus the extended version part, but whatever). Let's submit it!

I package the extension locally and start going through the submission process. I get to the point of uploading the ZIP, but the I get a message saying something along the lines of:

We suggest only using Manifest V3 for extensions that are distributed via the "On your own" option. To keep a wide range of support we suggest using Manifest V2 if distributing using the "On this site" option.

Cool, so I move back to Manifest V2 using the format extension-id@example.com. Now, this can be anything as well, just make it up. Their docs do stress it shouldn't be a real email address as you'll get spammed, but it can be anything unique.

And after packaging it again, the submission is successful (and later approved)!

I've submitted a PR to update Plasmo's docs relative to Manifest V2/V3 requirements in Firefox. Hopefully this makes it clearer to future users.

Publishing

I've automated the publishing process using PlasmoHQ/bpp. It publishes both extensions across the stores for Chrome, Edge, and Firefox.

It was relatively easy to extend for Firefox and Edge, just requiring the additional builds and packaging of the extension for these new targets (and modification of the ENV variables). You can checkout the workflows that handle this for both the default and extended versions if you want to see more detail.

This makes publishing a breeze. All I do is publish a new version using a Git tag and the GitHub Actions takes care of the rest.

Sentry

Now that the extension is working and published across Chrome, Firefox, and Edge, I needed to fix Sentry. Well, doesn't Sentry just work?? No, it doesn't just work.

I originally set Sentry up to work with Chrome. Specifically, I only uploaded source maps for the Chrome version of the extension. But, since I now build the extension for each store, this doesn't work.

Let me break it down a bit more. I'll use the default version of the extension as an example.

I build the extension three times. Each build targets a different store/browser. This results in three, completely different outputs even though the functionality and source code is the same!

So, since the errors can happen in any of the three outputs, I need to upload the source maps for all of them to the same release in Sentry.

One of my concerns was that the release would be created by during the first upload, then in subsequent uploads it would fail due to trying to create a release that already exists. I had to test it and cross my fingers that it would worked.

Thankfully, it ended up working as Sentry's GitHub action is smart enough! So now all the source maps for each build are associated to single Sentry release. My GitHub action has more detail if you want it!

Fin

Well, that's it. I hope this provides some level of value to you (or you find it interesting)!

Google Workspace Default Zoom has a new name

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 08 Nov 2024 00:00:00 GMT

Due to the Microsoft Edge Add-ons Policy 1.1.2, I've had to change the name of my extension. Honestly, they suck...

The extensions' new names are:

Default zoom for Google Workspace
Default zoom for Google Workspace (Extended)

They are still available for Chrome, Edge, and Firefox! They should automatically update, so don't worry if you had them installed already (you don't have to do anything).

Where to find

<table><thead ><tr ><th></th><th><em>Chrome Extension</em></th><th><em>Microsoft Edge Add-ons</em></th><th><em>Firefox Add-ons</em></th></tr></thead><tbody><tr><td><strong>Default zoom for Google Workspace</strong></td><td>✅</td><td>✅</td><td>✅</td></tr><tr><td><strong>Default zoom for Google Workspace (Extended)</strong></td><td>✅</td><td>✅</td><td>❌</td></tr></tbody></table>

Find it on Chrome Web Store

Default zoom for Google Workspace
Default zoom for Google Workspace (Extended)
- In exchange for allowing elevated permissions, this extension provides ability to set custom zoom levels (as opposed to only predefined values)

Find it on Microsoft Edge Add-ons

Default zoom for Google Workspace
Default zoom for Google Workspace (Extended)
- In exchange for allowing elevated permissions, this extension provides ability to set custom zoom levels (as opposed to only predefined values)

Find it on Firefox Add-ons

Default zoom for Google Workspace

Gemini CLI, are you there?

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 27 Mar 2026 00:00:00 GMT

import { Image } from "astro:assets"; import imgTooLong from "./img/gemini-cli-img-01-taking-too-long.png";

import Banner from "../../../../components/Banner/index.astro";

You may be wondering why I am and will be writing about Gemini/Google AI products. Well, because I'm cheap 💸.

I recently bought a new Pixel and was given a year subscription to the Google One AI Pro plan. Since it gives access to all the Google AI features for free, I figured I'd give it a shot (Don't worry Claude, I still use you at work) and see what is possible.

Thus, everything I write about here will likely be related to Google products, with maybe some special exceptions. Who knows 🤷.

<Banner type="info"> As I wrote this post, I found more and more things I think could be improved. Will that stop me from using it? No. </Banner>

Gemini CLI has been my primary tool for usage in my side projects. I have access to Code Assist in my VS Code IDE, but honestly, I don't use it that much. I'm trying to explore this non-IDE world I see coming as much as possible.

Unsurprisingly, or maybe surprisingly, this tool has been all over the place. I do think the v3 models are massive improvements, but it still has it's ups and downs.

The Goods

Skills

Gemini CLI is surprisingly good at picking up skills when compared to other platforms I've used. It's ability to understand what I'm trying to do and relate it to a skill makes it so I forget that I actually setup skills previously (or that my custom skill is different from a built-in skill).

This is a recent change, with the v3 models being better than the v2 models.

Plan Mode (finally)

FUCKING FINALLY they added plan mode to Gemini CLI. I can now change to it just like Claude Code and it will go through and figure out what I'm trying to do and generate a plan. Then I can implement this plan.

It's such a step up from the "Hey, research this topic and create a plan. DO NOT MODIFY FILES" prompt I had been using prior. I just wish that there was a checklist it would use to convey progress.

Continuous Improvement

I can tell the team working on the CLI tool is working hard to improve things. There are a lot of updates to the tool, but mostly it just gets better and better. I mean, it should be getting better and better because it was so far behind the curve when compared to other coding CLI tools.

I do really appreciate all new features and the documentation is actually pretty good, which is kind of surprising for Google (shots fired).

The Bads

Off the Rails (sometimes)

Sometimes Gemini goes down rabbit holes, like bad, and no matter how much you try to get it back the only thing you can do is stop and restart it again. Yes, we're talking about context management.

Honestly, context management with this thing was/is difficult. IIRC the /compress command didn't exist for a while or it did but didn't work...

This was further confused when looking online. Some said it has a rotating context window. Others said differently. And it goes on and on.

I still sometimes default to using /clear or restarting over /compress, even when i'm working on the same thing between sessions. If I'm doing this, and I want to easily get context back in the next session, I'll have gemini manually write out what we've been doing. Honestly, I should create a command for this...

Access

Getting access to Gemini during some periods is really hard. As I type this, my plan for a small tweak I want to make is on 10 minutes of thinking. This is also the second time I've stopped it and tried to restart it.

This is bad... As a paying customer I'd expect access to the tool I pay for. Luckily, I did get it for free, but if I wasn't, I'd be flaming pissed and likely have cancelled already.

When I tried this with GasTown, even doing small things ran into the limits and I'd get 429s.

Like c'mon... get with it.

Update: Like WTF is this?!?! I accepted the plan and now we're here...

Coding Quality

When I first started, Gemini was pretty shit at coding. The v2 models paled in comparison to the other models available like Opus or Sonnet.

It's only gotten a bit better with the v3 models. When comparing it to things I do at work with Opus, it's still not up to snuff.

This could be due to the auto model mode (will talk about it more below), where it's not using v3.1 Pro all the time.

Day to Day changes

One day things feel good. The next not so much. It's frustrating as all hell. You get excited to do things and then it just shits the bed. Not sure what's going on when this happens. I use the same workflow and when I change I am a bit less critical.

Sub Agents

I don't think Gemini CLI has quite gotten the gist of using Sub Agents effectively. I'll concede that at this point it's still listed as experimental.

It will use the codebase analyser only sometimes and rarely uses generalist agents. I think once this gets better, then context management will be easier.

I have yet to try being explicit about usage of Sub Agents, but it's on my list of things to try!

Model Choice... (Auto Mode)

I'm not sure I really like how Gemini CLI chooses what model to use and when (or when Gemini does it). I'll end my session and see that it used the flash model for almost all of my session, only ever choosing to use the Pro models for like 1 or two requests.

When you look at the Gemini App, you see that Pro is good at math and code. So why don't you use it?!?!?!?!?!?!?!

The End

Will I continue to use Gemini CLI? Yes. Do I hope it gets better? God yes. Is it the worst thing I used? No, we'll talk about Jules in a future post.

Oh, Hello AI

alvernacchia@gmail.com (Alex Vernacchia) — Wed, 11 Mar 2026 00:00:00 GMT

import Banner from "../../../../components/Banner/index.astro";

It's been quite a long-ass time since I posted here. Can't believe my last post was back in 2024... A lot has happened since then. I've moved across an ocean, lead a team to deliver a KMP, Server Driven UI mobile application, and my company was acquired. Maybe I'll post about those in the future, but for now, let's get address the elephant in the room... AI.

<Banner type="info"> All my writing will be sans-AI. You'll get 💯 pure Alex. So, if I don't use perfect grammer, then deal! </Banner>

I remember a couple years ago when my company held a GenAI hackathon. It was an interesting one, but the tooling and models were not what they are today, which led to, IMO, some cool projects, but not actually focused on the application of GenAI, rather using them inside ML areas or just customising a chatbot.

But, a lot has changed since then. AI Agents are a thing. Claude has gotten pretty good at generating code. Companies are fully bought it, whether it's making them faster or not, or causing problems they can't get in front of.

This really got me thinking in general. At first, I experienced Deep Blue and thought about the future, which looked bleak. I did wonder what I was going to do, as this AI stuff will replace me. I thought about how I don't have many skills outside of my profession. So, how would I provide for my family? Tbh, this got me really down, and it was all I could think about for a while.

I needed to get out of this funk. So, I started to research things, helping me find a path forward.

First, I realised that I'm not the only one feeling this way. I'm not alone. I don't like to relish in the fact that others feel pretty shit about things, but, in this case, it was nice to know I'm not alone.

Second, I watched some videos of experts in the field who had different takes from all doom and gloom. The one from Grady Booch is below.

He talks about how AI will enable the third golden age of softare engineering. How engineers will move up a level of abstraction, just like when higher order programming languages replaced writing Assembly by hand. It's just another tool to solve problems. A tool we need to use and get used to being around. Fundamentals (system design) are still very important and what is needed in order to guide this next age of engineering.

He also makes the point that there will be so much software and that itself means there will be a need for engineers. I guess we can always clean up AI slop ha, until AI is cleaning up all its own slop.

Lastly, I realised there's so many cool new things out there to try. There's a lot of projects aiming to utilise AI to help people build stuff.

So, I got off my ass and started trying things... Turns out they're useful, some more than others. I'm going to deliver a React Native application (link/post when I do) soon that used a lot of these tools. Things like GasTown, Ralph, Gemini CLI, Jules, etc... So we'll explore those together.

As I continued to try them, I saw that there's extrodinary value in learning how to use these tools as enablers. While they do have their shortcomings (many of them), they are worth it and can help!

I also have lots of other ideas where this will help me. Time is the limiting factor in my life, so maybe I'll be able to get to those ideas I've put on the back burner.

While I'm a bit more excited for the future, we'll see where it goes. At least I'm not dreading it. But, I'm a bit sad, as I'll be missing the old way. The coding hands on will become a past time, which is what I liked and got good at. But, we're ever evolving, so it's time (to use these tools in a sane manner with guardrails).

Something stuck with me, which I'll leave here for the end of this post.

Don't outsource the thinking!

The human is still needed for thinking critically. Once you oursource that, we're lost (think Idiocracy)

Damn it Jules...

alvernacchia@gmail.com (Alex Vernacchia) — Sun, 17 May 2026 00:00:00 GMT

import { Image } from "astro:assets"; import imgTooMany from "./img/jules_001-too-many.png"; import imgSamePrs from "./img/jules_002-same-prs.png"; import imgMergeConflict from "./img/jules_003-merge-conflicts.png";

As I said in my last post, I don't like Jules.

Honestly, it just feels like a half-baked product. I think there's a lot of potential, but I'm not into it at the moment.

Why?? We'll let's get into it.

Bolt

You are "Bolt" ⚡ - a performance-obsessed agent who makes the codebase faster...

Bolt is essentially an scheduled job that looks to improve performance in your codebase. You can set it up to run on your preferred schedule, and when it does it will look for performance improvements.

Sounds cool, right? When you get into the weeds and make a lot of changes, you can miss small or large performance issues. So, this sounds like a really cool thing to use to cover yourself.

But, I've actually found it quite difficult to manage. This is because the schedule, which is definitely in control of what I can change. But, life gets in the way and you forget. Then you come back to this...

This is just the dashboard of Jules, but it shows just how much it's working. But, when you then look at the PRs, they're basically fixing all the same thing over and over again.

It would be really cool if it kept track of the PRs it made and then wouldn't make them again. I say again, it would be an amazing feature if it took into account past PRs and only raised new ones if the issue wasn't already tackled.

Merge Conflicts

When you get in a groove, there's a lot of things going on in your repo. You're merging things left and right and then you have this agent that is running in the background making changes. It's inevitable, you'll get merge conflicts.

I thought it would be pretty easy to fix by directing Jules to do it, but I wasn't so lucky.

The screenshot above shows me trying to do this from the PR itself. I've also tried from the Jules console, but no luck. It says something about not having access, but it does have access to my repo. It's kind of weird really.

This is table stakes Jules. Come on.

General Usage

I found that when I wanted to move fast, it didn't. I would get it to spin up a plan for some functionality, but I would constantly be waiting for either the plan to complete, things to finish working, or something else. Most of the time it was just a small change I wanted to make or to nudge it in the right direction.

The End

I don't think I'll be using Jules much more, and will likely be disabling the scheduling of Bolt. I think it does have promise, as I'd really like to run a bunch of agents on a codebase autonomously, but I don't think it's there yet

A New Blog? Why?

alvernacchia@gmail.com (Alex Vernacchia) — Tue, 31 Jan 2023 00:00:00 GMT

import Redirect from "../../components/ClientRedirect/index.astro";

Adding Comments to this Thing

alvernacchia@gmail.com (Alex Vernacchia) — Sun, 19 Feb 2023 00:00:00 GMT

import Redirect from "../../components/ClientRedirect/index.astro";

How do I search this thing?

alvernacchia@gmail.com (Alex Vernacchia) — Thu, 23 Feb 2023 00:00:00 GMT

import Redirect from "../../components/ClientRedirect/index.astro";

My First Chrome Extension

alvernacchia@gmail.com (Alex Vernacchia) — Fri, 03 Feb 2023 00:00:00 GMT

import Redirect from "../../components/ClientRedirect/index.astro";

Words by Vernacchia

Astro thus far...

A New Blog? Why?

Astro thus far...

How it started

How it's going

Small nitpick

Future Ideas

Adding Comments to this Thing

Update

How do I search this thing?

My Options

Algolia

Typesense

Load from Astro + Local Search

Others

My Choice

Me trying to implement it

Populating Search Indexes

Implementing the Search

The Final Outcome

My First Chrome Extension

Next steps

React Aria Exploration (Pt. 1)

Accessibility Matters

React Spectrum

React Aria

Creating a Component

useButton requires a ref and props

usePress

Different events?

The Final Output

Introducing Google Workspace Zoom Default

The Future

"Simulating" JS Events

Mouse Events

Using .click()

Dispatching Events

Gotchas (still...)

Keyboard Events

Trusted Keyboard Events with Chrome Debugger

Astro Content Collection Month and Year Pages

The Problem

The Solution

Posts by Year

Posts by Month of the Year

And There We Have It!

JS Framework Evaluations

Relative Markdown Paths in Astro via Rehype

Enter rehype (and remark)

Enter astro-rehype-relative-markdown-links (my plugin)

Usage

rehype vs remark

Google Workspace Zoom Default - Extended

Past Context

View-only Default Zoom

The Problems

It's Experimental

Extras

Past Context

Optimising CI/CD Processes - Caching (all of it)

Let's get on the same page!

Caching

Docker (and layer caching)

Optimising CI/CD Processes - Hopper Configuration Upgrade

Hopper configuration upgrade

Optimising CI/CD Processes - Identifying Common Steps

Let's get on the same page!

Identifying common steps

Optimising CI/CD Processes - The Beginning

Let's get on the same page!

Go learn!

Optimising CI/CD Processes - Test Parallelization

Test parallelization

Jest

Cypress

A cheeky optimization

Local Testing

Goodbye Enzyme

Enzyme? React Testing Library (RTL)? What are they?

Using `.click()`

Enter `astro-rehype-relative-markdown-links` (my plugin)