DEV Community: Abbey Perini

Surviving Cancer Doesn't Suck

Abbey Perini — Tue, 06 Jan 2026 19:45:01 +0000

My post-treatment recovery has been a period of joy, connection, and rest.

It's been ten months since I finished radiation. I meant it when I said I leapt back into life. Since treatment, I've given seven conference talks, including my first international one. I showed up to film an episode of the Web Dev Challenge with almost no eyebrows and even fewer eyelashes than I left Atlanta with.

Most importantly, there have been days when I didn't even think about cancer.

After radiation ended, people began asking about remission. Turns out, it depends on which doctor you're talking to. Since I could have been cured by surgery, my remission either started after surgery in July 2024 or after chemo in December 2024. Since there was no proof that my cancer had spread beyond the tumor, the rest of my treatment after surgery served to kill anything that might have escaped. Cancer treatment is often frustratingly grey instead of black and white.

By the end of March, my hair was still the first thing people mentioned every time they saw me. I had kept about 40% of my hair, but my scalp was still tender and healing. As a result, I couldn't use a hair dryer long enough to get it fully dry. I was still out-shedding my Shiba Inu. Tumbleweeds of long blonde hair followed me everywhere. They stubbornly stuck to my clothes through the washer and dryer. It felt like I was suffocating and that I should be grateful to have any hair simultaneously.

My hair has never been straight, but the new growth I started to see was extremely curly. They call it the Chemo Curl. The new curls and shedding hairs formed mats. Dealing with the mats was painful and often resulted in more shedding. I tried keeping my hair braided, but the same tension every day pulled out more hair at the top of the braid. I began to feel like a fraud when people complimented my hair.

Once I cut it, I feel free. More like me. A few months later, the inch-long ringlets made it impossible to style. I cringed when I saw it in photos. Now, I'm starting to get the hang of it. My hairstylist and a friend helped me navigate curly styling products. Some of my new ringlets are now three to four inches long. I wait to see if my chemo curl is temporary or permanent. Only time will tell.

By April, the rest of the hair on my body made me feel like I was experiencing squirrel pattern baldness.

Every time I looked in the mirror, I noticed new body hair. My brain didn't know what to do with the peach fuzz on my face growing straight out. I was covered in patchy and itchy stubble. Some of it temporarily and dramatically changed color or texture. As I approached normal, I took comfort in being hairy.

During radiation, I could tell my scar tissue was changing. As I healed, I noticed changes in the surrounding healthy skin and muscle, as well. My range of motion decreased. I learned that the combination of surgery and radiation on my lymphatic channel (the tubes that hold your lymph nodes) was causing it to shrink. The shrinking pinched blood vessels and nerves, so I started getting nerve pain and circulation issues. I started physical therapy (PT) at a rehabilitation center.

For a long time, my weekly PT appointments and daily self-administered PT were just fighting the radiation still working its way through my system. I was manually breaking up scar tissue as fast as it formed. Four months after radiation ended, I started seeing progress. My range of motion returned to normal. Everything started softening back up.

And while all this was going on, I was living my best life. I'll never forget my week in Paris. I was still affected by feelings about the changes in my body, but I was so glad to be free from daily hospital rooms.

At our first dinner in Paris, I befriended a fellow tourist and cancer survivor who was finishing up the same drug I had just started. Her group whisked us away to the Eiffel Tower for its last sparkle of the night. My favorite song came on the radio on the way back. It felt like a movie.

Most of all, I was relieved to see my husband relax. He had worked himself into knots making sure he was supporting me to the best of his ability. But as my need for support returned to close to normal, his stress level didn't. The joy, relaxation, delicious food, and forty-four miles of walking put my husband and I on a better path. It was also very special that he got to watch me speak at the historic Folies Bergère about a topic that affects both of us.

Back in the States, the rehabilitation center was the first cancer center in which no one acted like it was weird that I was so young. After a handful of individual counseling sessions, I agreed to join the Young Survivors support group. For the first time, I had found people that were going through the same things. I finally wasn't alone.

We complained about the people who hadn't faced treatment with us and now expected us to satisfy their curiosity by re-living our medical trauma. We lamented that they wouldn't ask the questions they actually want to ask. (They just keep saying "How are you? No really, how are you?") We commiserated about the uncertainties, especially around having kids. I learned why so many of my doctors had reacted so dramatically to the name of the drug I'll be on for five years. The possible side effects can greatly affect your quality of life. Time and time again I have learned that it all could have been much worse.

No one will ever be able to tell me what caused my cancer. No one will ever be able to tell me if it will come back. In September 2024, this knowledge triggered an anxiety spiral in me, so I made the choice to not dwell on that. I had to believe treatment would work. I'll panic if there's something concrete to panic about. The more I interact with cancer survivors and their loved ones, the more I realize that reaction isn't the most common one.

Doctors often ask me to complete questionnaires designed to catch anxiety and depression. I remember when it was challenging to pick an answer. No anxiety or depression would have been abnormal. Now, filling them out is a breeze.

Every once in a while, I catch notes of jealousy and pain in the voice of a fellow cancer survivor who is trying to be happy for me while still struggling with the weight of it all. To be fair, I think I'm pretty good at hiding the jealousy I feel when I talk to people who are even luckier than me - the people who get to avoid chemo and radiation. I am amazed at the resilience of the survivors who supported me emotionally through treatment. Thankfully, we've never lost sight of the fact that we're all in a really cool, elite club that none of us wanted to be in.

On the anniversary of my diagnosis, I was in the same building and attending the same conference where I got the call. I felt raw and vulnerable. I was surrounded by a big part of my support network. Instead of a very sad, difficult time, it felt like the final step of learning to trust my village.

My nerves about my first scan post-treatment were about the logistics rather than the result. In the waiting room, I had a visceral reaction when they pulled out a wristband for me. Because I had never had a normal result from one of these scans, I had to ask the hospital staff to repeat the result. It felt surreal to get to leave without any fuss.

I know I'm out of the woods because the system has begun to move slowly again. (You know it's bad when the U.S. healthcare system starts moving quickly.) For the foreseeable future, I'll be getting a scan every six months and an oncology appointment every three. It's common to have anxiety about the scans and lengthening the time between appointments. This still feels like a lot of appointments to me. I'm happy to spend less time in wristbands.

Most of the feelings I still wrestle with are related to being a patient. I get nauseous if I think about chemo for too long. I used to laugh at how many supplements my parents took. Now we compare our daily regimens and studies we've read. I've had a needle phobia since I was six, and now I'm so experienced with needles that I give tips on how to find my veins.

I try not to think about how many hours I've spent in medical waiting rooms. I debate making a medical resume to make doctors' forms easier. Often, other patients ask me about the knitting or crocheting project I'm working on to pass the time. I don't tell them that it's to prevent me from fleeing the waiting room. I don't mention that I'm glad to be done with the project I took to chemo and radiation.

As I run into people who haven't kept up with me, they often unwittingly remark on things that touch a nerve. Usually, about how my attitude or body has changed. I lament that most types of cancer treatment cause weight loss and I got one of the kinds that causes a lot of weight gain. I love that I put down many of the worries and obligations that no longer served me. I hate that I was forced to miss out on 5 months of regular life.

Doctors tell me I'm stoic, a trooper, and a good patient. People tell me how strong I am. I don't know how to describe the river of tears I'm finally leaving behind. I can't put into words what it's like to learn that time can slow down until you're not just living day to day, but minute by minute. I deflect, calling it "stubborn persistence," and friends remind me that that's a kind of strength. I know that well is there deep within me and hope I don't need to draw from it again.

I've realized that being able to understand everything I went through - what treatment does and why I needed to do it - is a large part of what kept me sane. There were only a few times where it was not enough - my body didn't want to do it anymore. Until you've had to willingly poison yourself, you don't know what tricks you'll have to play on your own brain to keep poisoning yourself. Still, for a long time, it felt like I had no agency - like cancer was the thing deciding my course.

Now, I'm almost done recovering from what was hopefully my final surgery. This time, it was my choice. I was surprised by how much that sense of agency mattered to me. It was cosmetic and I'm very happy with the results. It wasn't magic - I'll always have scars. The surgeon reported that my radiation scar tissue was way better than average, so all that PT was worth it. Which was a good thing to hear before I had to start a new round of post-surgery PT.

This time, I practiced spite-driven rest. (Not a single person believed I would rest, so I had to prove them wrong.) Between that rest and the two weeks I took off for the holidays, I had a lot of time to see family and friends, reflect, and set goals for the coming year.

It finally feels like the fresh start a doctor promised me a year and a half ago.

Someone recently asked me "What's one thing you're doing today that you weren't doing a lot of a year ago?" and then we laughed and laughed. A year ago I could barely get out of bed. A year ago, I still had a long slog ahead of me. A year ago, I wondered how other people made it through longer treatment regimens. A year ago, I wondered if I would be able to do it without breaking.

I'm glad I learned to bend more easily.

Decisions that would have been difficult for me two years ago are now easy. I cry and feel love more freely. I find joy in even littler things. I trust myself and others. I try to avoid plot lines and ads about cancer patients. I collect stories from fellow survivors about being in remission for years and years.

I'm taking it a day at a time because I want to, not because I have to.

Gang of Four Design Patterns in Memes - Creational

Abbey Perini — Thu, 14 Aug 2025 23:22:42 +0000

The Gang of Four (GoF) are Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They wrote Design Patterns: Elements of Reusable Object-Oriented Software. In it, they documented 23 classic software design patterns.

There are five creational design patterns - they cover the instantiation of objects.

Singleton

There can only be one instance.

Useful for when more than one copy of an object or class would break your system.

Factory Method

A factory is an interface for creating an object. Its subclasses determine the shape of the instantiated object.

Useful for when the creation of some objects is complex enough to be abstracted and those objects have overlapping implementation details.

Abstract Factory

Essentially a factory of factories - a list of creation methods for a group of factories.

Useful for factories need to be grouped together.

Builder

A list of methods for constructing parts of an object.

Useful for when you have so many optional parameters that passing them through a factory is error-prone.

Prototype

New objects are created by copying an existing object, inheriting characteristics from the parent object.

More efficient for complex object creation. JavaScript uses prototypical inheritance.

State Management in Front-end Web Development: Actions, Dispatch, and Reducers

Abbey Perini — Sat, 12 Jul 2025 19:38:28 +0000

In State Management in Front-end Web Development: State 101, I covered when you need which state management tools and how they're implementations of the observer pattern. This part of the series assumes that you need a state tool that uses the actions, dispatch, and reducers pattern. This pattern is useful when you need to consume and update the same state in multiple unrelated components. React Context, and global state management libraries like Redux for React and ngRx for Angular use it.

React Context is a dependency injection solution, an alternative for prop-drilling. It's appropriate for simple state, like a boolean that represents whether the user is logged in. Conveniently, it's also the simplest, least abstracted example of the actions, dispatch, and reducers pattern.

Once your state grows more complicated, then it's time to reach for a global state management library. A common example used in the docs for these libraries is an array of songs in a playlist and multiple API calls to get, add and remove songs from the playlist.

This pattern has a lot of moving parts. I'll start by defining the parts, building towards a synchronous Context example. I'll rewrite that example in Redux and then add API calls. Finally, I'll recreate the same example with ngRX.

You can find the React examples in the react-state GitHub repo and the Angular example in the angular-state GitHub repo. I'm using React 19.1.0, Redux Toolkit 2.8.2, Angular 19.2.14 and ngRx 19.2.1.

Immutability
Actions
Dispatch
Reducers
A Synchronous Example with React Context
A Synchronous Example with Redux
An Asynchronous Example with Redux
A Synchronous Example with ngRx
An Asynchronous Example with ngRx
Conclusion

Immutability

The actions, dispatch, and reducers pattern treats state as immutable. A JavaScript object is mutable. If I change part of the object, I have mutated it.

const person = { firstName: "Paul", lastName: "Posey", id: 12 };
// mutation
person.firstName = "Pauline";

To treat a JavaScript object as immutable, I replace the entire object with an updated copy.

const person = { firstName: "Paul", lastName: "Posey", id: 12 };
// not a mutation
function updatePerson(key, value, person) {
  // make a copy
  const newPerson = person;
  // apply the update to the copy
  const newPerson[key] = value;
  // return the copy
  return newPerson;
}
person = updatePerson("firstName", "Pauline", person);

This doesn't just apply to objects. The forEach array method will mutate your array. The filter() array method will not mutate your array - it returns a copy.

A lot of times, you'll see immutable state updates written with the spread syntax.

const tasks = [
  dishes,
  laundry,
  dusting
];
function addTask(tasks, newTask) {
  return [...tasks, newTask];
}

function updatePersonName(person, newName) {
  return {
    ...person,
    firstName: newName,
  }
}

The spread syntax creates a copy and adds all of the old stuff that isn't being updated at the same time.

Immutability sets the foundation for pure state update functions. Pure functions always return the same output when given the same inputs. Pure functions are free from side effects - they don't cause unintended consequences beyond the scope of the function. So state update functions should only update state, always update state the same way, and shouldn't affect things outside state.

Actions

An action is an event that triggers changes to the state in the store. In the observer pattern, it'd be the notification to the observer that the subject has updated. You write the notifications that trigger effects now.

I want to build an app that allows the user to click a button to pet a shiba. It'll also show the shiba's reaction to the number pets. I'm not getting the pets from an asynchronous API call, you can't take away pets, and I'll only be giving one pet at a time. So to start, I only need one action - "PET".

Actions are represented by strings. To prevent errors caused by misspelling a string, use a constant or enum for action strings.

export const actions = {
  pet: "PET",
}

In some cases, a string may provide all the information the store needs to update the state. Often, an action needs to contain additional information. When it does, the action string is the value of the type property in an object. Any additional information is passed as the value of the payload property.

If I wanted to add more than 1 pet at a time, my action would look like this:

{
  type: actions.pet,
  payload: 5,
}

Dispatch

In programming, dispatch is a synonym for send. In stores that use actions and reducers, you dispatch the action to the reducer. Thus, it is the name for the method that sends the action (notification) to the store.

store.dispatch(actions.pet)
store.dispatch({
  type: actions.pet,
  payload: 5,
})

Reducers

When the store receives the action, what does it do with it? The reducer handles all the logic for setting/updating state.

A reducer is a function that reduces a set of values to a single value. You may be familiar with JavaScript's reduce. A reducer in the context of a store is similar, but not recursive.

A store may have many possible actions. The reducer decides which action triggers which effect. In the observer pattern, it'd be the list registering effects to subjects. It can update state itself or call other functions.

function reducer(action, payload) {
  if (action === actions.create) state = [...state, action.payload];
  if (action === actions.remove) handleRemove(payload);
  if (action === actions.update) handleUpdate(payload);
  if (action === actions.delete) handleDelete(payload);
}

That's a lot of ifs! Which is why you'll often see reducers written with a switch statement.

function reducer(action, payload) {
  switch (action) {
    case actions.add:
      state = [...state, action.payload];
      break;
    case actions.remove:
      handleRemove(payload);
      break;
    case actions.update:
      handleUpdate(payload);
      break;
    case actions.delete:
      handleDelete(payload);
      break;
    default:
      throw new Error("Not a valid action!")
      break;
}

The switch statement also provides an easy way to catch malformed actions.

The shiba petting app only has one action, so one if statement will do.

function petsReducer(pets, action) {
  if (action === actions.pet) return ++pets;
}

Side note: I'm using a pre-fixed increment operator here so that the value will be returned after it's been incremented. If I used return pets++, I'd get the value before it's been incremented.

A Synchronous Example with React Context

For dependency injection alone, you can use a context without writing state management logic. My shiba petting app will have two components - Pets, a counter with a button, and Shiba, which will display the shiba's reaction to the pets. Since the Shiba component doesn't update state, I can use dependency injection alone to pass the number of pets to it.

The createContext hook creates a context component that holds a value.

// PetContext.jsx
import { createContext } from 'react';

export const PetContext = createContext(0);

Consumer components are children of the provider component. They use useContext to consume the state in the context.

// PetContext.jsx
import { useContext } from 'react';

// reusable wrapper function for useContext with a unique name
export function usePets() {
  return useContext(PetContext);
}

Consumer components can be deeply nested and completely unrelated and still access the context in <PetContext>. This would work:

  return (
    <PetContext value={1}>
      <div>
        <div>
          <div>
            <div>
              <Pets />
              <div>
                <div>
                  <Shiba />
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </PetProvider>
  );

// Shiba.jsx
import { usePets } from '../PetContext.jsx';

export function Shiba() {
  const pets = usePets();

  // img tags and imports omitted for brevity
  if (pets < 1) return (sadShiba)
  if (pets >= 1 && pets <= 10) return (happyShiba)
  if (pets > 10) return (goodbyeShiba)
}

Now the number of pets is passed to consumer components using a context, but the value is essentially hardcoded. I want the user to be able to update the number of pets with a button click, but right now it can only access the number of pets.

// Pets.jsx
import { usePets } from '../PetContext.jsx';

export function Pets() {
  const pets = usePets();
  return (
    <div>
      <p>{ pets }</p>
      <button onClick={() => ???} >Pet the Shiba</button>
    </div>
  )
}

The next step is writing the state management logic (getters and setters) with useReducer. It's like manually writing the observer pattern on top of a dependency injection solution.

useReducer returns two things - the current state and a dispatch method. A second context will hold the dispatch. useReducer takes two arguments - the initial value for the state and a reducer. Both contexts, the action, and the reducer can all go in the same file.

// PetContext.jsx
import { createContext, useReducer, useContext } from 'react';

// create the contexts
export const PetContext = createContext(null);
export const PetDispatchContext = createContext(null);

export const actions = {
  pet: "PET",
}

// a wrapper component for both contexts
export function PetProvider({children}) {
// pass the reducer and initial value to useReducer and get state and dispatch from the call
  const [pets, dispatch] = useReducer(petsReducer, 0);

  // pass the state and dispatch to the providers
  return (
    <PetContext value={pets}>
      <PetDispatchContext value={dispatch}>
        { children }
      </PetDispatchContext>
    </PetContext>
  ) 
}

// instantiate the reducer
function petsReducer(pets, action) {
  if (action === actions.pet) return ++pets;
}

export function usePets() {
  return useContext(PetContext);
}
export function usePetDispatch() {
  return useContext(PetDispatchContext);
}

Now wrapper component holds the state value and provides it and the update method (dispatch) to the consumer components.

// PetsApp.jsx
import { PetProvider } from '../PetContext';

export function PetsApp() {
  return (
    <PetProvider>
      <Pets />
      <Shiba />
    </PetProvider>
  );
}

The Pets component can access both contexts, so the user can update the number of pets with a button click.

// Pets.jsx
import { usePets, usePetDispatch, actions } from '../PetContext.jsx';

export function Pets() {
  const pets = usePets();
  const petDispatch = usePetDispatch();
  return (
    <div>
      <p>{ pets }</p>
      <button onClick={() => petDispatch(actions.pet)} >Pet the Shiba</button>
    </div>
  )
}

Any update within a context will trigger a re-render in every component consuming it - even if you're only updating one property and the consumer component isn't using that one property.

A Synchronous Example with Redux

This time, I want to build an app that counts shibas. I want the user to be able to add any number of shibas, not just one at a time.

// ShibaCounter.jsx
import { useState } from 'React';

export function ShibaCounter() {
  const [count, setCount] = useState(0);

  function handleIncrement(event) {
    event.preventDefault();
    setCount(parseInt(event.currentTarget.elements.number.value));
  }

  return (
    <div>
      <span>Shibas: {count}</span>
      <form onSubmit={(event) => handleIncrement(event)}>
        <label htmlFor='number'>Number</label>
        <input id='number' type="number"/>
        <button type="submit">Add Shibas</button>
      </form>
    </div>
  )
}

Now that I've got my form, I want to move count out of local state and into global state. Why? In the next example, when the user updates the count, I want to trigger an API call to fetch that many shiba images. I need to get the synchronous half working first.

I start by installing Redux Toolkit. Then, I need to instantiate a store for all of my global state. Redux creates one store. Like a pizza, one store can have many slices. Each slice holds a piece of state and its actions, dispatch, and reducers.

// store.js
import { configureStore } from '@reduxjs/toolkit'
import { shibaCountReducer } from "./shibaCounterSlice"

export default configureStore({
  reducer: {
    shibaCounter: shibaCountReducer,
  }
})

Like Context, Redux uses a provider component to pass the store to consumer components with dependency injection. Where you'd want to keep your context as close as possible to the consumer components, a Redux store is meant to be global, so the provider is added at the root and wraps the whole app.

// root.jsx
<Provider store={store}>
  <Outlet />
</Provider>

Unlike Context, Redux uses a package called Immer to handle keeping state immutable. I no longer have to handle copying the object to manually maintain the state I'm not updating.

// context
return {
  ...oldValue,
  key: newValue,
}

// redux
state.key = newValue;

Next up, I need to create my first slice.

// shibaCounterSlice.js
import { createSlice } from '@reduxjs/toolkit'

export const shibaCounterSlice = createSlice({
  name: 'counter',
  initialState: {
    shibaCount: 0
  },
  reducers: {
    incrementByAmount: (state, action) => {
      state.shibaCount += action.payload;
    }
  }
})

export const { incrementByAmount } = shibaCounterSlice.actions;

export default shibaCounterSlice.reducer;

Woah! That looks a bit different - what happened to the big switch statement? Because Redux is a state management library, it has syntax for creating actions and reducers. I don't have to write them manually.

createSlice returns an object I've named shibaCounterSlice. When I call createSlice, I'm passing initial state and state update functions in the reducers option object. createSlice builds an actions object with action creators made from those update functions. I then access those action creators by destructuring the actions object.

// context
if (action === actions.pet) return ++pets;
// pass the action to dispatch
dispatch(actions.pet);

// redux
pet: state => ++state.pets;
// creates an action creator
function pet() {
  return { type: actions.pet };
}
// consumer component passes the action creator to dispatch
dispatch(pet());

The action creator consumes the action and automatically unpacks the payload.

// context
dispatch({
  type: actions.pet,
  payload: 5,
})

// redux
dispatch(pet(5));

The useSelector hook selects a state from the store similar to how useContext accessed the context. The useDispatch() hook replaces the dispatch context. Now I can hook up the form to use the slice instead of local state.

import { useSelector, useDispatch } from 'react-redux';
import { incrementByAmount } from '../shibaCounterSlice';

export function ShibaCounter() {
  const count = useSelector(state => state.shibaCounter.shibaCount);
  const dispatch = useDispatch();

  function handleIncrement(event) {
    event.preventDefault();
    dispatch(incrementByAmount(parseInt(event.currentTarget.elements.number.value)));
  }
}

Unlike useContext, this component will only re-render when the state that is returned from useSelector updates (e.g. shibaCount). Even if I could update other properties within the same slice, the component only listens for updates to what it's actually consuming. You can also leverage this to create derived state to further improve performance.

An Asynchronous Example with Redux

Now, every time the user updates the count, I want to use the Dog API to show shiba pictures. You may be thinking "wait, an API call is definitely a side effect." And that's right! The reducers will still only update state. The state update will trigger middleware. The middleware will be an observer watching for updates to state. It's just a function that handles API calls and dispatches a new action with the fetched data.

API calls can be pending, resolved, or rejected, so I'll need pending, success, and failure actions. Components can watch for these states and display a loading spinner, error, or the successfully fetched data. If you need to fetch data when the page loads, you can use an idle/initial state to indicate that the data hasn't been fetched yet.

If I wrote this in redux alone, I'd start with my actions and reducers.

// shibaCounterSlice.js
const statusStrings = {
  shibasPending: "SHIBAS-FETCH-PENDING",
  shibaSuccess: "SHIBAS-FETCH-SUCCESS",
  shibaFailure: "SHIBAS-FETCH-FAILURE",
}

export const shibaCounterSlice = createSlice({
  name: 'counter',
  initialState: {
    shibaCount: 0,
    shibas: [],
    status: statusStrings.shibaSuccess,
    error: null,
  },
  reducers: {
    incrementByAmount: (state, action) => {
      state.shibaCount += action.payload;
    },
    shibaFetchPending: (state, action) => {
      state.shibas = [];
      state.status = statusStrings.shibaPending;
      state.error = null;
    },
    shibaFetchSuccess: (state, action) => {
      state.shibas = action.payload;
      state.status = statusStrings.shibaSuccess;
    },
    shibaFetchFailure: (state, action) => {
      state.error = action.payload;
      state.status = statusStrings.shibaFailure;
    }
  }
})

export const { incrementByAmount, shibaFetchPending, shibaFetchSuccess, shibaFetchFailure } = shibaCounterSlice.actions;

The reducer still only updates state! Next I need a middleware function that handles the API call and dispatches the appropriate actions.

// shibaCounterSlice.js
export async function fetchShibas(count) {
  dispatch(shibaFetchPending());
  try {
    const shibas = await fetch(`https://dog.ceo/api/breed/shiba/images/random/${count}`);
  } catch (error) {
    // use error action and bail out before a success is dispatched
    dispatch(shibaFetchFailure(error.toString()));
    return;
  }
  dispatch(shibaFetchSuccess(shibas));
}

I could also write this with chaining.

export async function fetchShibas(count) {
  dispatch(shibaFetchPending());
  await fetch(`https://dog.ceo/api/breed/shiba/images/random/${count}`).then(
    response => dispatch(shibaFetchSuccess(response.data)),
    error => dispatch(shibaFetchFailure(error.toString()))
  );
}

Writing the same middleware with the exact same pattern for every fetch call gets tedious. That's why Redux Toolkit comes with redux-thunk middleware installed.

A basic thunk is a wrapper function that consumes dispatch and a getState function.

function thunk(dispatch, getState) {
  const state = getState();
  if (state.count === 5) dispatch(pet(5));
}

createAsyncThunk creates a thunk wrapper that handles the repetitive async logic.

// shibaCounterSlice.js
export const fetchShibas = createAsyncThunk(
  "shibaCounter/fetchShibas/",
  async (count) => {
    const response = await fetch(`https://dog.ceo/api/breed/shiba/images/random/${count}`);
    return response.data;
  }
)

createAsyncThunk automatically defines pending, fulfilled, and rejected action strings for me. The first argument I passed is a string that will prepend them. So fetchShibas.pending will be set to "shibaCounter/fetchShibas/pending".

Now that createAsyncThunk is creating my actions and dispatching them for me, I need to let create createSlice know. The extraReducers essentially creates event listeners for the actions created outside of createSlice.

// shibaCounterSlice.js
export const shibaCounterSlice = createSlice({
  name: 'counter',
  initialState: {
    shibaCount: 0,
    shibas: [],
    status: statusStrings.shibaSuccess,
    error: null,
  },
  reducers: {
    incrementByAmount: (state, action) => {
      state.shibaCount += action.payload;
    }
  },
  extraReducers: builder => {
    builder
      .addCase(fetchShibas.pending, (state, action) => {
        state.status = statusStrings.shibasPending;
        state.shibas = [];
        state.error = null;
      })
      .addCase(fetchShibas.fulfilled, (state, action) => {
        state.status = statusStrings.shibaSuccess;
        state.shibas = action.payload;
      })
      .addCase(fetchShibas.rejected, (state, action) => {
        state.status = statusStrings.shibaFailure;
        state.error = action.error.message;
      })
  }
})

export const { incrementByAmount } = shibaCounterSlice.actions;

Finally, I'm ready to update the shiba counter component to call fetchShibas when the count is updated. I use useEffect (with all dependencies in my dependency array) to watch for an update and register the API call as an effect.

// ShibaCounter.jsx
import { useEffect } from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { incrementByAmount, statusStrings, fetchShibas } from '../shibaCounterSlice';

export function ShibaCounter() {
  const count = useSelector(state => state.shibaCounter.shibaCount);
  const shibas = useSelector(state => state.shibaCounter.shibas);
  const shibaStatus = useSelector(state => state.shibaCounter.status);
  const error = useSelector(state => state.shibaCounter.error);
  const dispatch = useDispatch();

  function handleIncrement(event) {
    event.preventDefault();
    dispatch(incrementByAmount(parseInt(event.currentTarget.elements.number.value)));
  }

  let shibaImages = shibas.map(shiba => {
    return (
      <img src={shiba} alt="shiba" key={shiba}>
      </img>
    );
  })

  useEffect(() => {
    if (count > 0) dispatch(fetchShibas(count));
  }, [count, dispatch])

  return (
    <div>
      <span>Shibas: {count}</span>
      <form onSubmit={(event) => handleIncrement(event)}>
        <label htmlFor='number'>Number</label>
        <input id='number' type="number"/>
        <button type="submit">Add Shibas</button>
      </form>
      { shibaStatus === statusStrings.shibasPending && <p>Pending</p>}
      { error && <p>{error}</p> }
      { shibaImages }
    </div>
  )
}

In this example, I am counting shibas and displaying shiba images in the same component. In the real world, the benefit of using a global state solution is I could count in one component and display in a completely unrelated component.

A Synchronous Example with ngRX

Now I want to build the exact same example in Angular's ngRX. The concepts are the same, but the syntax is different. Once again, I'm going to start by getting the synchronous part working and then add in the API calls.

After installing @ngrx/store I need to provide the store to my app.

// app.config.ts
import { provideStore, provideState } from '@ngrx/store';
import { provideEffects } from '@ngrx/effects';
import { shibasReducer } from './state/shibas.reducer';

export const appConfig: ApplicationConfig = {
  providers: [provideStore(), provideEffects(), provideState({ name: "shibas", reducer: shibasReducer })]
};

The action creator method is aptly named createAction. I have to define my action payload as props.

// shibas.actions.ts
import { createActionGroup, createAction, emptyProps, props } from "@ngrx/store";

export const incrementByAmount = createAction("Increment by Amount", props<{ number: number }>())

I need to write a selector to get the shiba feature out of my store - a store can have many features. To do that, I use createFeatureSelector and pass the name I passed to provideState in my app config. Once I have the whole feature, I can use createSelector to get the value that I need.

// state/shibas.selector.ts
import { createSelector, createFeatureSelector } from '@ngrx/store';
import { ShibaData } from './dogApi.model';

type Count = {
  count: number;
}

export const selectFeatureShibas = createFeatureSelector<Count>('shibas');

export const selectShibaCount = createSelector(selectFeatureShibas, (state: Count) => state.count);

Then, I import and instantiate the store in my top level App component. In my template, I pass the state value to the ShibaCounter component. I also set up an event listener. When my ShibaCounter component emits the incrementByAmount event, my event listener will will access dispatch off of the store object and dispatch my incrementByAmount action.

// app.component.ts
import { Component } from '@angular/core';
import { Store } from '@ngrx/store';
import { selectShibaCount } from './state/shibas.selectors';
import { incrementByAmount } from './state/shibas.actions';
import { ShibaCounter } from './shibas/shiba-counter';
import { AsyncPipe } from '@angular/common';
@Component({
    selector: 'app-root',
    template: `
      <main class="main">
        <shiba-counter [count]="(count$ | async)!" (incrementByAmount)="onIncrementByAmount($event)" />
      </main>
    `,
    imports: [ ShibaCounter, AsyncPipe ],
})
export class AppComponent {

  title = 'state-angular';

  count$;

  onIncrementByAmount(number: number) {
    this.store.dispatch(incrementByAmount({number}));
  }

  constructor(private store: Store) {
    this.count$ = this.store.select(selectShibaCount);
  }
}

Then, I need a reducer. I pass two arguments to createReducer. The first is initial state - 0. The second argument is an on function. It creates an event listener! The first argument is the action to listen for and the second is a state update function.

// state/shibas.reducer.ts
import { createReducer, on } from "@ngrx/store";
import { incrementByAmount } from "./shibas.actions";

export const initialState = { count: 0 };

export const shibasReducer = createReducer(
  initialState,
  on(incrementByAmount, (state, { number }) => {
    return { count: state.count + number }
  })
);

Finally, I want to consume and update the store from my ShibaCounter component. I get count as an input from my App component and use output to create the incrementByAmount event listener.

// shibas/shiba-counter.ts
import { Component, EventEmitter, Input, Output } from '@angular/core';
import { FormControl, ReactiveFormsModule, FormsModule } from '@angular/forms';

@Component({
  selector: 'shiba-counter',
  template: `
    <span>Shibas: {{ count }}</span>
    <form (ngSubmit)="onSubmit()">
      <label for='number'>Number </label>
      <input id='number' type="number" name="number" [formControl]="number"/>
      <button type="submit">Add Shibas</button>
    </form>
  `,
  styleUrl: './shiba-counter.css',
  imports: [FormsModule, ReactiveFormsModule],
})
export class ShibaCounter {
  @Input() count = 0;
  @Output() incrementByAmount = new EventEmitter<number>();
  number = new FormControl(0);

  onSubmit() {
    this.incrementByAmount.emit(this.number.value!);
  }
}

An Asynchronous Example with ngRx

Now it's time to add the API call to get shiba pictures to the previous example. First, I need to install @ngrx/effects. Then I need to update my app config providers. I need to provide the http client, effects, and new reducer. You can use meta-reducers to combine all of your reducers.

// app.config.ts
import { provideHttpClient } from '@angular/common/http';
import { provideEffects } from '@ngrx/effects';
import { dogApiReducer } from './state/dogApi.reducer';
import * as ShibaEffects from './shibas/shibas.effects';

export const appConfig: ApplicationConfig = {
  providers: [provideHttpClient(), provideStore(), provideEffects(ShibaEffects), provideState({ name: "shibas", reducer: shibasReducer }), provideState({name: "shibaData", reducer: dogApiReducer })]
};

I'm made a type for my data, because it's not a primitive, and I don't want to type it out repeatedly.

// state/dogApi.model.ts
export interface ShibaData {
  shibas: ReadonlyArray<string>,
  pending: boolean,
  error: string | null,
}

Next, I need pending, success, and failure actions for my API call. Since I have multiple actions this time, I use createActionGroup. I'll be able to access them like DogApiActions.shibaFetchPending.

// state/dogApi.actions.ts
import { createActionGroup, emptyProps, props } from "@ngrx/store";

export const DogApiActions = createActionGroup({
  source: "Dog API",
  events: {
    "Shiba Fetch Pending": emptyProps(),
    "Shiba Fetch Success": props<{shibas: ReadonlyArray<string>}>(),
    "Shiba Fetch Failure": props<{error: string}>(),
  }
})

Now I need my selector. You can also use selectors and feature creators to combine multiple pieces of state.

// state/shibas.selectors.ts
import { ShibaData } from './dogApi.model';

export const selectFeatureShibaData = createFeatureSelector<ShibaData>('shibaData')
export const selectShibaData = createSelector(selectFeatureShibaData, (state: ShibaData) => state);

Next up, the reducer.

// state/dogApi.reducer.ts
import { createReducer, on } from "@ngrx/store";
import { DogApiActions } from "./dogApi.actions";
import { ShibaData } from "./dogApi.model";

export const initialState: ShibaData = {
  shibas: [],
  pending: false,
  error: null,
};

export const dogApiReducer = createReducer(
  initialState,
  on(DogApiActions.shibaFetchPending, (_state) => { 
    return {
    shibas: [],
    error: null,
    pending: true,
    }
  }),
  on(DogApiActions.shibaFetchSuccess, (_state, { shibas }) => { 
    return {
    shibas,
    pending: false,
    error: null,
    }
  }),
  on(DogApiActions.shibaFetchFailure, (_state, { error }) => {
    return {
    shibas: [],
    pending: false,
    error
    }
  })
);

Since my reducer should only update state, I need a service to handle the API call.

// shibas/shibas.service.ts
import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Observable } from 'rxjs';
import { map } from 'rxjs/operators';

@Injectable({ providedIn: 'root' })
export class ShibasService {
  constructor(private http: HttpClient) {}

  getShibas(count: number): Observable<Array<string>> {
    return this.http
      .get<Response & { data: string[] }>(
        `https://dog.ceo/api/breed/shiba/images/random/${count}`
      )
      .pipe(map((response) => {
        return response.message || []
      }));
  }
}

Now, I'm going to use I'm using @ngrx/effects and rxjs to write the observer pattern. rxjs is an Observables library for JavaScript that Angular uses. The effect returned from createEffect will watch for the DogApiActions.shibaFetchPending action. When it happens, exhaustMap will pass the action to the getShibas service, so I can grab the updated count from its props. Based on the result of the API call returned from getShibas, pipe will then dispatch the result in the appropriate action (DogApiActions.shibaFetchSuccess or DogApiActions.shibaFetchFailure).

// shibas/shibas.effects.ts
import { inject } from '@angular/core';
import { Actions, createEffect, ofType } from '@ngrx/effects';
import { of } from 'rxjs';
import { map, exhaustMap, catchError } from 'rxjs/operators';
import { ShibasService } from './shibas.service';
import { DogApiActions } from '../state/dogApi.actions';

export const getShibas = createEffect(
  (actions$ = inject(Actions), shibasService = inject(ShibasService)) => {
    return actions$.pipe(
      ofType(DogApiActions.shibaFetchPending),
      exhaustMap((action) =>
        shibasService.getShibas(action.count).pipe(
          map((shibas) => DogApiActions.shibaFetchSuccess({ shibas })),
          catchError((error: { message: string }) =>
            of(DogApiActions.shibaFetchFailure({ error: error.message }))
          )
        )
      )
    );
  },
  { functional: true }
);

Now I can add a subscription in my app component constructor that dispatches the DogApiActions.shibaFetchPending action when count updates. This is another way to write the observer pattern. If I wanted to fetch data on load, I would remove the value > 0 check. If I wasn't making the call based on an update to another state variable, I would dispatch an idle/initial action in ngOnInit.

// app.component.ts
this.count$.subscribe((value) => { 
  if (value > 0) return this.store.dispatch(DogApiActions.shibaFetchPending({count: value}))
});

I also need to pass shibaData to my ShibaCounter component in my template.

// app.component.ts
<shiba-counter [count]="(count$ | async)!" [shibaData]="(shibaData$ | async)!" (incrementByAmount)="onIncrementByAmount($event)" />

In my ShibaCounter component, I grab shibaData and display the shiba pictures, pending, and error states.

// shibas/shiba-counter.ts
import { Component, EventEmitter, Input, Output } from '@angular/core';
import { FormControl, ReactiveFormsModule, FormsModule } from '@angular/forms';
import { ShibaData } from '../state/dogApi.model';

@Component({
  selector: 'shiba-counter',
  template: `
    <span>Shibas: {{ count }}</span>
    <form (ngSubmit)="onSubmit()">
      <label for='number'>Number</label>
      <input id='number' type="number" name="number" [formControl]="number"/>
      <button type="submit">Add Shibas</button>
    </form>
    @if (shibaData.pending) {
      <p>Pending</p>
    }
    @if (shibaData.error) {
      <p>{{ shibaData.error }}</p>
    }
    <div class="shiba-group">
      @for (shiba of shibaData.shibas; track shiba) {
        <img [src]="shiba" alt="shiba" />
      }
    </div>
  `,
  styleUrl: './shiba-counter.css',
  imports: [FormsModule, ReactiveFormsModule],
})
export class ShibaCounter {
  @Input() count = 0;
  @Input() shibaData: ShibaData = {
    error: null,
    pending: false,
    shibas: [],
  };
  @Output() incrementByAmount = new EventEmitter<number>();
  number = new FormControl(0);

  onSubmit() {
    this.incrementByAmount.emit(this.number.value!);
  }
}

Conclusion

The actions, dispatch, and reducers pattern is difficult to wrap your head around at first. There are a lot of moving parts. My hope is that starting with the smallest possible example and slowly adding in concepts made the pattern easier to understand.

The next part of the series will cover the mutator pattern used by global state management libraries like Zustand for React and Pinia for Vue (coming August 2025).

State Management in Front-end Web Development: State 101

Abbey Perini — Mon, 02 Jun 2025 19:31:50 +0000

Learn where to keep your variables to improve your app design, performance, and readability.

What is State?

In programming, state refers to all the variables within a program. Variables represent data held in memory.

Global state refers to variables that are globally scoped. They can be accessed from anywhere within the entire app.

Local state refers to variables that are locally scoped. They can only be accessed within the file, component, or function where they are declared.

Derived state refers to variables that are calculated based on other variables.

const person = { firstName: "Paul", lastName: "Posey", id: 12 };
// displayName is derived state
const displayName = person.lastName + ", " + person.firstName;

When people talk about state in a front-end web app, they are typically referring to reactive state. Reactive state tracks updates and triggers effects when they happen. Reactive state management tools exist in all frameworks. Within them, a state variable is essentially a set of getters and setters. When you access the value, you're getting it. When you reassign the value, you're setting it. Tools that create reactive state will also have methods for instantiating the state variable, updating it, accessing its previous value, and more.

Local State Management

When you are creating a local state variable, as yourself:

Does this variable need to be updated repeatedly?
Do updates to this variable need to trigger updates somewhere else?

If not, a regular let or const should suffice. Reactive state management tools are more powerful and will consume more resources. Why maintain a Ferrari when a bicycle will suit your needs?

If you do need to update the variable and trigger effects based on updates, you'll want to create reactive state.

React: useState
Vue: ref
Angular: signals

In all three frameworks, you pass an initial value to a method. When you change the value, effects will be triggered. Anything that uses these reactive state variables will be notified when there's an update. So if you're displaying the value of a reactive state variable, the new value will be displayed.

Frameworks also provide ways to trigger complex effects after an update. For example, a user clicks the "next page" button, so the value of your pageNumber state variable is incremented, and you need to make an API call to get the next page of results. You'd use useReducer or useEffect in React, watchers in Vue, and effects in Angular.

In Angular, you can create reactive state using signal.

const person = signal({ firstName: "Paul", lastName: "Posey", id: 12 });

If you just want to assign a new value, you can use set() to update your signal. If you want to compute a new value based on the old value, you use update().

In Vue, you can create reactive state using ref.

const person = ref({ firstName: "Paul", lastName: "Posey", id: 12 });

A ref maintains a reference to the original value and creates a Proxy. You access and reassign the value within the Proxy using .value.

if (person.value.firstName === "Paul") {
  person.value = { firstName: "Pauline", lastName: "Person", id: 14};
}

In React, you create a state value and an update function using the useState hook. (A hook is a function that let you “hook into” React features within a functional component.)

const [person, setPerson] = useState({ firstName: "Paul", lastName: "Posey", id: 12 });

Derived State Management

React: const
Vue: computed
Angular: computed signals

When possible, keep derived state in the least powerful state tool.

In React, it is more performative to declare derived state with const. An update to a reactive state variable will trigger a component re-render. If you update one variable declared with useState and trigger an update to another variable declared with useState, the component will re-render twice. If you just use const, the value will re-compute during the first re-render anyway.

// Triggers a second re-render
const [person, setPerson] = useState({ firstName: "Paul", lastName: "Posey", id: 12 });
const [displayName, setDisplayName] = useState(() => person.firstName + " " + person.lastName);

// Doesn't trigger a second re-render
const [person, setPerson] = useState({ firstName: "Paul", lastName: "Posey", id: 12 });
const displayName = person.firstName + " " + person.lastName;

In Vue and Angular, this is when you'd use computed().

const displayName = computed(() => {
  return person.value.lastName + ", " + person.value.firstName;
});

Put simply, whenever person is updated, displayName will update.

Vue and Angular use the observer pattern and keep track of which reactive variables trigger which effects. Instead of re-rendering the entire component, only the things that need to update will update.

In observer pattern terms, the reactive variable person is the subject. When we use person in the callback function passed to computed(), the function is added to a list of observers. When the subject updates, the observers are notified, and the function will run again. This should sound familiar - addEventListener() also uses the observer pattern. With addEventListener(), the subject is an event and your listener (the event handler callback function you pass) is the observer/effect.

Dependency Injection

The more complex your application gets, the more prop-drilling becomes a problem. In a small application, it's fine to pass state down to child or even grandchild components. As a rule of thumb, if you have to pass state as a prop to a great-grandchild component, it's time to re-evaluate the design. It's common to run into this problem when multiple components need to use the same data from an API call.

Before you reach for global state, consider an in-between solution - dependency injection. It's still local state, but instead of using props, parent components provide the state, and their children can consume it. That's why "dependency injection" and "provider/consumer" are used interchangeably.

This pattern isn't just for reactive state. If you have derived state or a complex calculation, you can use dependency injection as a type of memoization. You only have to call an expensive function once and then you can inject the result.

In Vue, a component uses the provide method to make a key value pair. Then, any child component can use the inject method to access that value.

// Parent component
const isLoggedIn = ref(false);
provide("key", isLoggedIn);

// Child component
const isLoggedIn = inject("key");
if (isLoggedIn) showData();

You can inject update functions into consumer components. To avoid unintended side effects, updates should stay in the provider component.

Angular also has an inject method for dependency injection. It provides multiple ways to create a provider. A common pattern is creating a class service, but you can also use values like a string, boolean, or Date. If you need to trigger updates from a consumer, your service class can define getters and setters.

Dependency injection in React involves three hooks - useReducer, createContext, and useContext. Writing a context requires understanding concepts that are used in global state management libraries. I'll explain how to write one in the next part of this series.

Basically, createContext creates a component to hold your state and createContextDispatch creates a component with methods for updating your state.

To use a context you've written, you need to wrap your components in a provider tag.

<PersonContext.Provider value={person}>
  <PersonDispatchContext.Provider value={dispatch}>
    <WelcomeBanner />
    <MainContent />
    <Footer />
  </TasksDispatchContext.Provider>
</TasksContext.Provider>

These days (v19.1), you no longer have to use .Provider when using your context provider component.

<PersonContext value={person}>
  <PersonDispatchContext value={dispatch}>
    <WelcomeBanner />
    <MainContent />
    <Footer />
  </TasksDispatchContext>
</TasksContext>

Consumer child components use the useContext() hook to access the state. Before the useContext() hook was added, you had to use a consumer component to access your context.

return (
  <PersonDispatch.Consumer>
    {(person) => (
     <p>{ person.firstName }</p>
    )}
  </PersonDispatch.Consumer>
)

Global State Management

React: Redux, Zustand
Vue: Pinia
Angular: ngRx

What if you need to consume the same data and trigger the same API call to update that data in two unrelated components? It's common to run into this problem with auth (e.g. checking if the user has logged in). Global state is for variables that are used and updated in multiple unrelated files.

Technically, you could make the argument that putting variables and update functions in your main file and using prop-drilling is global state management.

When we're talking about front-end web development, global state management usually refers to a library that makes your data available without the parent/child relationship required to prop-drill or use dependency injection. You should only use a global state management library when it's worth the performance trade-off.

A global state management library typically creates a store. This pattern is so ubiquitous that sometimes global state management libraries refer to themselves as "a store." You store your state in a store. A store can maintain complex data structures. A store provides a standard way to make changes to your global state, making state changes predictable.

There are a couple common patterns for writing stores and triggering updates in global state management libraries. I'll cover them in the next two parts of this series:

State Management in Front-end Web Development: Actions, Dispatch, and Reducers
State Management in Front-end Web Development: Mutators (coming August 2025)

BenQ Programming Monitor Review

Abbey Perini — Wed, 14 May 2025 22:22:09 +0000

My first experience with a BenQ programming monitor was a hectic few hours filming the Web Dev Challenge. The main things I noticed during that time were the rare 3:2 aspect ratio, lack of glare, and the convenient option to power my laptop with the monitor. I typically use my terminal in VS Code, so the aspect ratio allowed me to see more of my code while my terminal was open. The lack of glare was super important for filming.

It's been about 8 weeks since I received my RD280UA monitor for my home office. Its adjustable arm mount was easy to attach to my desk. I like the fact that the Allen wrench has its own place in the mount, so you can't lose it. Immediately after setting it up, I noticed how bad the glare from the morning sun on my existing monitor had gotten.

The next thing I noticed was the plethora of settings. There are several color modes and more color settings within them. You can even adjust the amount of red and green for red/green color blindness. If you can't choose a color mode, you can use two with DualView Plus.

And then I got to the Eye Care menu. I've got special eyes.

Many developers love dark mode because it helps with their eye strain. Thanks to an astigmatism, I see halation and get headaches when I use a lot of dark modes. That's where this monitor shines - I have every tool I could possibly need to combat eye strain, not just a dark color with light text.

It starts with the MoonHalo - it's a much better backlight than the one I've been using. The Brightness Intelligence will auto adjust and turn on Night Hours Protection based on ambient light. Low Blue Light Plus allows you to adjust the blue light to your preference. The Eye Reminder sends regular "take a break" notifications, something I have an app downloaded for. When I first set it up, I could feel my eyes relaxing as I adjusted everything. After a few days, I noticed my eyes were less tired at the end of the day.

Right now, I've got three profiles setup - dev dark mode, dev light mode, and mbook (presumably MacBook). Using the Coding HotKey on the function bar, I can quickly switch between them. The main differences are brightness and temperature - mbook has none of the eye care settings turned on in case I need to evaluate colors.

The main reason I chose the RD280UA over the RD280U was its adjustable arm. In addition to the special eyes, I've got special joints - ergonomics are a big deal for me. The adjustable arm is so easy to move and rotate. I can easily push it around, flip it, and tilt it to find the right position whether I'm sitting, standing, having to use my chair neck support a lot that day, or whatever.

My setup requires flexibility beyond ergonomics too. My other monitor is a 34" ultrawide monitor. I use the same desk for my work MacBook Pro, my personal MacBook Pro, and my custom gaming PC. Luckily, this monitor is very flexible. You can daisy-chain multiple monitors with Multi-Stream Transport, multiple computers with the KVM switch, and multiple peripherals with the dedicated USB ports. I have a hub that I connect to several peripherals including a mouse, keyboard, external speakers, headphones, and more. Even though the monitor works with my hub, it has so many options that I'm still playing around with optimizing my setup, 8 weeks later.

The only feature on the monitor itself that doesn't work as expected is the EcoPrivacy setting. It's supposed to turn the monitor off when you step away. It doesn't seem to sense me and immediately turns the monitor off.

While double-checking some things for this review, I discovered Display Pilot 2. It adds an on screen display with various shortcuts. It also allows you to set up things like Display Partition and keyboard shortcuts. I like the idea of the flow feature. It's supposed to open up applications and perform various other actions on a schedule. I haven't tested it out yet. Display Partition only works on my M4 Pro MacBook and not my M2 Pro MacBook. The software crashed twice when I was initially setting it up on the M2 Pro MacBook. I haven't seen what will happen when settings are backed up from two different computers. Focus jumps randomly around a lot when using the software with a mouse, and it's unusable with just a keyboard or screen reader. Clearly, it's not integral to the monitor as I just discovered it.

Conclusion

If you want an incredibly configurable monitor with a rare aspect ratio, anti-reflection nano matte coating, and lots of anti-eye strain features, this is the monitor for you. The auto power off setting works fine in lieu of EcoPrivacy and I happily used it for 8 weeks without realizing there was companion software.

What the First Rule of ARIA Really Means

Abbey Perini — Mon, 14 Apr 2025 14:00:51 +0000

I am not an accessibility auditor, but I am frequently asked to give feedback on websites. When that happens, the first thing I do is check basic accessibility things. Multiple times, I have suggested an aria-label, and heard "I thought I was never supposed to use ARIA."

ARIA, the Accessible Rich Internet Applications Suite, is a huge topic and full of hard concepts. A lot of times, accessibility concepts are hard because the "right answer" is more grey than black. What may make something more accessible for one group of people may make things worse for another group. ARIA is hard because you need to learn those grey accessibility concepts, HTML in-depth, how to test the desired user experience with assistive technology, and ARIA.

Learning it becomes even more intimidating when you hear "the first rule of ARIA is don't use ARIA". This common adage doesn't mean ARIA will literally never make your webpage more accessible. It means two things - there's probably an HTML element for that and no ARIA is better than bad ARIA.

ARIA Roles Are Semantics
There's Probably an HTML Element for That
No ARIA Is Better Than Bad ARIA
When to Use ARIA
- Landmark Roles
- Label, Labelledby, or Describedby?
- Icons and Images That Convey Information
- Icon and Images That Don't Convey Information
- When HTML Elements Aren't Enough
- Announcing Additions to the Page
- Grouping Interactive Elements Outside of a Form
Learning Resources
Conclusion

ARIA Roles Are Semantics

Semantic HTML elements have semantic ARIA roles. The <button> element will expose the role button to the accessibility tree. Elements with the role button will be announced by a screen reader.

A generic HTML element, like a <span> or <div>, has the ARIA role generic. This role is not semantic. When exposed to the accessibility tree, it communicates "this is a nameless container element with no meaning." Unless it is focusable, an element's semantic role can be removed using role="presentation" or role="none". Screen readers will not announce generic elements.

So even an ARIA role that has no meaning is communicating something. Think of elements with the roles generic, presentation, and none as metadata on a text document. The person reading the document doesn't need to know about the metadata for the text content of the document to make sense. In the same way, a screen reader user doesn't need to know that three elements are grouped together visually by a meaningless <div>.

The role of an element can even affect what information is communicated by the elements associated with it. The <footer> element has a role of contentinfo. If the browser sees an <address> element as a child of an element with the contentinfo role, it will be exposed to the accessibility tree as the contact address for the owner of the site.

There's Probably an HTML Element for That

If you're adding an onclick handler to a generic element, a semantic element probably exists with all the functionality you want to build (and a lot more you haven't thought about). If you aren't very familiar with how the HTML element works, replacing it with an ARIA role will rob you of functionality you didn't even know you needed.

<button>Save</button>
<div role="button">Save<div/>

These things are true for the semantic <button> element:

It is focusable.
A focus outline will show when it is focused.
It will activate on click, space, and enter.
When activated and inside a form element, it will trigger a submit event (if it has no type attribute or type="submit").

This is true for both the semantic <button> element and the generic element with a button role:

The role button will be exposed to the accessibility tree.
A name for the element ("Save") will be exposed to the accessibility tree.
A screen reader will announce "Button Save".

What you'd have to add to the generic element to make them equal:

JavaScript handling click, space, and enter events
tabIndex="0" to make it focusable.
If it's in a form element, JavaScript creating all the functionality you'd get from a submit event.
Focus outline styling

If you just use <div role="button">, a screen reader will announce the element as a button, but the user will get none of the functionality that comes with a <button> element.

No ARIA Is Better Than Bad ARIA

Until you learn how to use ARIA correctly, using it will likely make things worse. ARIA attributes come with requirements. If you don't know those requirements, you'll start cluttering up your code with useless attributes and creating invalid elements that cause headaches for users.

Many roles require specific attributes and children elements be used with them. Returning to the button example - the spec requires that you write onclick and onkeydown handlers when you use role="button". We should use <input type="checkbox">. But if we used role="checkbox", we'd also have to use aria-labelledby and aria-checked. Then we'd have to build all the functionality the <input> element already has and keep the value of aria-checked up to date.

Some roles' requirements prohibit you from using certain attributes and elements as children. You can't use any element as a child of the <ul> element - it has to be a <li>, <script> or <template> element. Interactive content can't be a child of the <button> element. The values you can pass to aria-checked depend on the element on which it's used. You can't use aria-checked on a button, and you can't use aria-pressed on a checkbox.

If you've been learning semantic HTML, some of this should sound familiar. A lot of the rules you learn about how to use HTML elements are ARIA under the hood.

When to Use ARIA

Landmark Roles

If you only learn one part of ARIA, it should be the special subset of roles called landmark roles. Assistive technologies expect these roles in a page and generate a page summary based on them. Screen readers provide users with multiple ways to navigate a page - like a list of landmarks.

The typical website layout uses <header>, <main>, and <footer> because they have the landmark roles banner, main, and contentinfo. These three roles can't be duplicated - you can only have one per page. Additionally, you have to keep them separate - a <header> element loses the role banner if it is a child of an element with another landmark role, like <main>.

The <nav> element has the landmark role navigation. If you provide a <form> with a name, it gains the form landmark role. Some landmark roles, like navigation and form, can be used multiple times per page. But if you use more than one, screen readers users need to know how they are different. Don't make them read every link in your navigation menu to find out. Use aria-labelledby or aria-label to provide them with unique names. The same concept applies to other elements with landmark roles like <section> and <aside>.

If you use HTML elements with landmark roles appropriately, a screen reader user can use the list of landmarks like a skip link. With very little effort, you save them from the tedium of navigating through the same header content every time they navigate to one of your pages. Using the list of landmark roles, they'll be able to jump right to your named forms without having to skim the entire page. Once they're done filling out your form, they can jump right back to the navigation menu the same way.

Label, Labelledby, or Describedby?

The attributes aria-label and aria-labelledby are used to give an element a name that can be read by a screen reader. They can't be used on some elements, including those with role presentation or none. You can't provide a name for an element that has a role that by definition doesn't have a name. Read Sarah Higley's What's in a name? for a full explanation of element names.

Elements that need a name typically generate that name themselves from associated text content. So every time you reach for ARIA to add a name to an element, ask yourself why you aren't using text inside the element or an associated <label> element.

If you can't use either of those, but there is text already on the page, use aria-labelledby. You just pass it an ID Reference List (one or more IDs separated by a comma). Any ID in the ID Reference List should correspond to the id attribute of an element containing the text you want to use.

<h3 id="color-heading">Favorite Color</h3>
<input type="text" aria-labelledby="color-heading" />

As a last resort, you can pass a name as a string to aria-label.

<button aria-label="expand menu"><svg>Right Chevron Icon Code</svg></button>

You also pass an ID Reference List to aria-describedby, but it doesn't provide the element with a name. Instead, it provides a description. A name should be concise - a few words. A description can be multiple sentences. This attribute is a way to link pertinent text information from another element. Use aria-describedby in situations where helpful text is near the element. If you find yourself putting an icon next to an interactive control and expecting a user to know to hover or click to learn more, that's the perfect time to use aria-describedby.

<button type="button" aria-describedby="warning">Self Destruct</button>
<p id="warning">Only click this button if you don't want an account anymore.</p><svg aria-hidden="true">Warning Icon Code</svg>

In the (extremely rare) situation that you need to pass a description as a string instead of an ID, you'd use aria-description.

Let's say you have so much information about the element that the user would have to interact with another element or elements to get the information (e.g. clicking a link, expanding a <details> element, or reading text in multiple <p> elements).

<button aria-details="explanation">Self Destruct</button>
<a href="/self-destruct-explanation" id="explanation">Learn more about self destruct</a>

By passing the ID of the <a> element to the aria-details attribute, we associate the <a> element with the button. In other words, screen reader users won't get text, they'll be pointed towards the link itself. Assistive technologies will even use the role of the elements referenced in the ID Reference List to provide more information to the user.

Icons and Images That Convey Information

If you're using icons to convey information, you need to give screen reader users access to that information. For example, an icon that tells users that the link opens in a new tab. If the icon is a static image, you can use the alt attribute. If it's an SVG and you can't edit or dynamically update the SVG code, that could be an appropriate time to use role="img" to give it a role so that you can use aria-label to give it a unique name.

<!--Link with "external link" icon-->
<a>Check out the GitHub Repo<svg role="img" aria-label="opens external link">External Link Icon Code</svg></a>

There are many solutions for this problem. This is a good a place as any to note - robust testing inclusive of people with disabilities is the only way to determine that your website has an accessible user experience.

It's always better to have a visible label for interactive controls. Still, we often see buttons and links with an image or SVG icon and no text. Those elements generate a name based on text content and ARIA attributes - not images. You can use aria-label to give them a unique name.

<button aria-label="expand menu"><svg aria-hidden="true" >Right Chevron Icon Code</svg></button>

Links must always have content, so the aria-label has to go on the image.

<a href="https://github.com/repo" target="_blank" rel="noreferrer"><svg role="img" aria-label="open Github repository in a new tab">GitHub logo code</svg></a>

Icons and Images That Don't Convey Information

On the flip side, a screen reader user probably doesn't need to hear about every icon on your page. (You may have noticed the aria-hidden attribute in the previous button example.) If a static image doesn't communicate information, use alt="". If it's an SVG, you can use aria-hidden="true".

<!--"Add +" button-->
<button>Add<svg aria-hidden="true">+ Icon Code</svg></button>

When HTML Elements Aren't Enough

If you are building an interactive element for which no HTML exists, then you want to use ARIA. This is rarer than people think. It's one of the main reasons why the first rule of ARIA is don't use ARIA. "The <select> element looks ugly" doesn't fall into this category. Developers are constantly reinventing the wheel when it comes to interactive elements.

Still, it does happen. I have had to build a tree view with NodeIterator and Treewalker, and tablists are pretty common. If you're building a component functionality triggered by user actions, use ARIA to tell screen reader users about the actions available to them.

The simplest, most common example is a checkbox that checks or unchecks all the checkboxes below it.

<fieldset>
  <legend>Dogs</legend>
<label><input type="checkbox" aria-controls="dog1,dog2,dog3,dog4" aria-checked="mixed">Select All</label>
  <ul class="checkboxes">
    <li>
      <label><input type="checkbox" id="dog1">Shiba Inu</label>
    </li>
    <li>
      <label><input type="checkbox" id="dog2" checked="">Corgi</label>
    </li>
    <li>
      <label><input type="checkbox" id="dog3">Husky</label>
    </li>
    <li>
      <label><input type="checkbox" id="dog4">Mutt</label>
    </li>
  </ul>
</fieldset>

How do you communicate to a screen reader user that the "select all" checkbox controls the other checkboxes? You pass an ID Reference List to aria-controls.

How do you communicate to a screen reader user that only some of the checkboxes controlled by the "select all" checkbox are checked? aria-checked="mixed".

Announcing Additions to the Page

How does a blind user know when new text has been added to the page or they get a notification or when you show an error banner? You'll need to use live regions created with aria-live

To learn more, read Sara Soueidan's extensive guide to ARIA live regions and my quick primer on using them in React.

Grouping Interactive Elements Outside of a Form

Within a <form> element, a <fieldset> element gives you useful functionality. Paired with a <legend> element, you automatically format your form data and get a semantic name.

<!--Will have a border-->
<fieldset>
  <legend>Themes</legend>
  <input type="radio">Light</button>
  <input type="radio">Dark</button>
  <input type="radio">Rainbow</button>
</fieldset>

Outside of a <form> element, you don't need that functionality and often have to override the styling that comes with a <fieldset> and <legend>. Instead, you can use the role group.

<!--Won't have a border-->
<div role="group" aria-labelledby="styling">
  <div id="styling">Text Styling</div>
  <button type="button">Bold</button>
  <button type="button">Italics</button>
  <button type="button">Remove Formatting</button>
</fieldset>

You'll have to remember to use aria-labelledby or aria-label, but you won't have to override the styling. This can be helpful if you have to build interactive components like toolbars, menus and menubars.

Learning Resources

This is by no means an exhaustive lesson in ARIA. If you'd like to learn more, here are a few places to start:

Conclusion

I hope this helps some people get over their fear of ARIA. Accessibility advocates say "The first rule of ARIA is don't use ARIA" because they constantly have to fix the giant mess caused by developers using ARIA attributes that they don't understand.

If They'll Adopt It, It's Right

Abbey Perini — Fri, 28 Mar 2025 19:33:07 +0000

It's no secret Andy Bell, Alex Riviere, and I love CSS. Alex recently wrote Grid First, Flex Third. (I found the part about how some of us are rewriting display: block with display: flex especially interesting.) Then Andy wrote a response eschewing absolutes and talking about how some people will always prefer flex over grid. (His CUBE system is similar to how I write CSS when left to my own devices.)

Neither of them are wrong. Both of them have many years of experience and enjoy thinking about how the stylesheets cascade. If you enjoy thinking about the same kind of thing, you should go read both articles.

Andy's main point is absolutely correct.

If it works, it's right. - Rachel Andrew

His CUBE CSS article touches on another important point - the challenge is getting people to use whatever system you come up with. He mentions how people often think a single tool, like Tailwind, will be the silver bullet for a styling system for a large project.

Alex is my boss so I know anger and frustration are typically what drive him to write. I also know what code he's angry about. Alex and I have been repeatedly hitting a point where we can't update something without completely restyling it. We've been trading off ripping out components and page structures and rewriting them. The main issue is that there are tools (e.g. Tailwind and component libraries), but no system. Everything is copy and pasted ooze. (I propose ooze as a term for something that's less organized than soup.)

<!-- ooze -->
<div class="flex flex-col">
  <div class="flex gap-2 w-full">
    <div class="flex flex-col flex-1 w-4/5">
      <div class="flex gap-2 flex-2">
       <button class="border border-blue bg-grey flex rounded-lg">
         View More
         <img src="~/assets/down-caret" class="w-24 h-24" />
       </button>
      </div>
      <button class="border border-blue bg-[#cccccc] flex rounded-lg">
        Cancel
      </button>
      <div class="flex gap-2 flex-2">
        <div class="flex gap-4">
         <button class="border border-blue bg-blue flex rounded-lg">
           Apply
         </button>
        </div>
      </div>
    </div>
  </div>
</div>

To Andy's point, he'd still be angry if it was CSS grid ooze.

In past articles (From Idea to Design for Non-Designers and Tips on Extensible and Maintainable Components article that I wrote with Andy), I've talked about how any software project is a living system. Every tool has trade-offs. Updates and new requirements will happen. You need to be able to jump back into it even if you haven't touched it 6 months or years.

I agree with Andy and Alex - we should be thinking about how to use CSS (or any tool) most effectively. It seems to me that developers are often keen to examine trade-offs, refactor, and measure things like readability with most programming languages. When it comes to CSS, many panic and throw that out the window. Part of it is that CSS works differently than any other programming language they've used. But a lot of it is the lack of intentionality most teams have with their styling tool of choice. This isn't the first codebase I've worked in where I've had to overhaul the styling just to get some work done.

I'm sure the developers before us could have made a useable styling system with Tailwind. I do think Tailwind and other CSS frameworks add extra hurdles when you're trying to style intentionally for large projects. The way they are written encourages developers to copy and paste their styling unintentionally. And to make an intentional, easy to adopt system with them requires the same work you'd do with CSS on top of wresting with the framework itself. (Even on a small project, you'll need to override inaccessible choices, which means you'll still need to know CSS.)

Early in my career, I had already fallen in love with CSS before I was told I should hate it. I also had the honor of working with one of the smartest people I'll ever work with. He was mainly a back-end developer who didn't want to think about CSS. Usually, we would pair and I would build the front-end portion. On one project we worked on together, I logged in hours before a deadline to see that a PR had been merged with a brand-new, full-stack feature. I rushed to look at how he had styled it. It was exactly how I would have styled it. Later that day, he told me "That was so easy to style." I've been chasing that high ever since.

What made it so easy to style? I'd love to say it was that we were using grid, block, and flex in CSS in the right amounts. In reality, it was the same kinds of things people recommend for any other programming language.

If we found it was repeated 3 times, we'd make a reusable class.
We gave classes concise, human-readable names.
Our stylesheets were heavily commented.
Our stylesheets were grouped by functionality.
We tried to keep our styling consistent across pages.
We tried to avoid overriding styles, !important, or anything that generated inconsistent results.
We tried to use local scope over global scope where possible.

It's the right styling system if someone who doesn't want to know CSS can adopt it easily. Use every tool in your toolbox intentionally and effectively. Write your code so that you in 6 months or the back-end dev will immediately understand it.

If they'll adopt it, it's right.

Cancer Treatment Sucks

Abbey Perini — Tue, 18 Mar 2025 15:31:30 +0000

When we left off, I had just met with the first of three oncologists. I did end up with a specialist because there are so few patients like me. When you take into account my existing connective tissue disorder, I'm even rarer.

And that's the common thread throughout my cancer treatment journey. Patients like me are so rare that healthcare professionals struggled to hide their surprise. They sincerely and reflexively blessed my heart. (If you're not from the South, a sincere "bless your heart" is when you know it's really bad.) My rarity stemmed mainly from my age. I joked receptionists kept looking for the grandmother I had to be accompanying. Cancer statistics usually end at 15 years after diagnosis. That'll get me to 47. The first two oncologists wanted to treat me like I was 47.

My rarity also stemmed from not having worse cancer. I was on a (relatively) light regimen. I struggled in cancer group settings - I learned too much about how much worse it could be. I felt obligated to give support instead of receiving it. I was more comfortable navigating doctors and jargon and pain than most. Doctors were surprised by my energy and questions and ecstatic about how well I was healing compared to most (older) patients.

While I navigated an egg retrieval for onco-fertility preservation, I felt truly alone. Most people who brave the onslaught of needles and invasive tests and intense hormones are planning on having a kid as soon as possible. I was freezing embryos just in case treatment affected my fertility. If I choose to use them, I'll be pausing my treatment. It wouldn't increase the chances my cancer will come back, but the chances will never be 0. A doctor told me no one had a good answer for a question I never asked - how can I bring a kid into this world knowing my cancer might come back? I tried not to feel guilty about being able to afford it (with the help of grants like Team Maggie's Dream).

A friend assured me that feeling like doom for exactly three hours was a normal reaction to one of the drugs. On the way to an appointment, I found out that my uncle had suffered a stroke. I stood in the fertility wing of the hospital and watched the sun rise further over the surrounding woods. I ordered flowers for my aunt. He passed away soon after. I cried about many things on that ten day hormonal roller coaster.

At the end of the process, I vibed with my pregnant friends who would give birth a week later. However, they knew their bundles would bring joy. The end of my journey was the beginning of chemo. It was ironically easier to get to my procedures from my con hotel room. So as I stripped off my Stupid Sexy Gandalf costume to let my husband stab me with the final dose, I felt alone in a crowd of about 80,000. I woke up frequently that night - apparently a possible side effect of that last shot is extreme anxiety.

The procedure went extremely well. I returned to con that night, feeling on top of the world. A few weeks later, I spoke at Netlify Compose. Both events helped me get a little distance from the cancer and make friends who would help me through the next part.

I've had plenty of mental health struggles in my life, but navigating chemo while going through menopause was harrowing. The hot flashes alone threatened my sanity. In about four months, my body went through two years worth of egg making and then three months without hormones. The steroids and chemo only added weight, bloat, and face-swelling. A doctor asked me why I gained weight and why I was masking. I cried in my car. I threw out his referral and called a doctor a fellow radiation patient recommended instead.

People told me I looked great (for a cancer patient). I struggled with hair loss and could barely shower. I kept a normal amount of hair, thanks to cold capping and having extremely thick hair to begin with. I could be a cold capping brand ambassador.

As a result, people had no concept of how much hair I lost. It's like my hair was my enemy and a friend I was losing at the same time. While my scalp froze during and after infusions, I reminded myself that having hair gave me a sense of normalcy. Laying on the couch at home, my hair parting ways with my aching scalp by the handfuls felt anything but normal. Constantly tangled in it, I rivaled Wesley, the shiba inu, in creating fur dust bunnies around the house. I'm still pulling clothing covered in hair out of the dryer.

The hair around your eyes is on a longer growth cycle. A month after chemo ended, I felt I had adjusted to the hair loss. Then, my eyebrows and eyelashes fell out. I bought a bunch of makeup. I began following video tutorials by people with alopecia to draw on my eyebrows. We all missed our eyelashes the most.

Now, I'm watching all my hair grow back in, but slightly different. It feels like I shaved my entire body and the stubble is growing back in at a snail's pace.

Every infusion, I thought "I have to do this again" in terror. Every infusion, I thought "This is a light regimen." in despair. Every infusion, I wondered if the horrible nerve pain or bone pain would start. In three out of four infusions, they struggled to get an IV in me. I learned about inter-departmental needle drama. I almost considered a port.

I had to think this would work. I couldn't think about doing it again if the cancer came back. I began to feel nauseous in cars, elevators, and when I thought about the next infusion. My husband and I joked about "double milk milkshakes." We both wondered if I would be so unable to eat at some point that I would need them.

I explained the procedures to my loved ones - full of cancer "fun" facts. I became a lightning rod for people's cancer feelings and news. I drowned in paperwork and bills, unmedicated for ADHD for the first time in years. I languished in pain and a myriad of discomforts, each one robbing me of a little more dignity than the last. I hyperfocused on birds and everyone thought that seemed healthy.

After the first infusion, I travelled to Raleigh for All Things Open. It was there, struggling to give my talk, that I realized I was going to have to reckon with my pride and internalized ableism. My sister basically did everything but walk me through the TSA line to get me on the plane home. In the line, I debated whether she should have walked me through it. It took me 40 minutes to wind my way through the infinity symbol shaped path, and I wondered what would happen if I passed out.

At home the next day, I was happy to be able to hand out candy on Halloween, my favorite holiday. After word got out about my cancer, my neighbors had dropped off care packages. The houses around me had more Halloween decorations than previous years. People loved our Mothman and lightbulb costumes. I almost felt normal.

A few weeks later, I managed to make it to Connect.Tech for a few hours. Immediately, it was palpable that people knew I was a cancer patient. I hated the sad looks, but not people offering me chairs and insisting I let them fetch things for me.

While I was struggling with feeling left out and unable to celebrate Christmas like I normally would, my grandmother fell and injured herself badly. She would be in and out of the ICU for the next two months. I reckoned with yet another layer of grief wrapped in complicated family history.

Eventually, I succumbed and began doing whatever I wanted. I learned who dug in when the going got tough and who expected me to still cater to them. I leaned into relationships with the people who dug in. I learned to trust, relax, and prioritize myself - skills which had historically evaded me. Slowly, the brain fog prevented me from thinking. The fatigue became so heavy that I struggled to wake up. Once awake, I regretted not being asleep.

That winter, everything felt wrong. I was a rock, stuck in the silt, as the river of everyone else's life moved around and past me. I watched, helpless, as my husband swam against the current to pull me a centimeter or two forward. 2/2 counselors agree we navigated it well. We were together and alone in our struggles.

As I rang the bell signaling the end of my chemo treatment and the ward cheered, I felt like a sack of emotion and poison. The day of my last infusion was the day the radiation treatment planning began. Each time they lined me up in the radiation machine, they applied more and more permanent marker and stickers. "Instead of tattoos!" the told me cheerfully. If x marks the spot, I was covered in treasure. It's a good thing I didn't run into any pirates. Showering acquired another level of difficulty.

As my energy returned, I still felt overwhelmed by the daily appointments. As I got used to them, my energy began to wane again. The laser beam didn't hurt. The subsequent sunburn did. Despite the radiation, my overall health slowly improved. I could walk the dog without feeling like I was going to pass out.

In the patient-only waiting room in the back, we discussed how many appointments we had completed and how many we had yet to complete. I heard about people driving 2 hours one way because this location was the only option their insurance gave them. Many had to stay in the Hope Lodge. (I try not to feel guilty about receiving cutting-edge care so close to my home.) Fellow patients looked relieved when I brought up my age first. Everyone complimented my hair.

Every Friday during most of chemo and all of radiation, I wore my new blanket coat to the other hospital to get acupuncture. It didn't not help when intimidating security guards complimented it. I reasoned with my needle phobia that these were stabby needles, like tattoos. I used my honed ability of Not Thinking About It when it asked what happens if one breaks.

The best visit was when my husband had time to visit the hospital aviary with me. His work urged him to make up the hours he was spending taking me to appointments. The burnout prevented him from caring. State law protected his right to use his sick time. Through MealTrain, I was finally able to take some of the burden off of him.

I made cookies for the staff whose sarcastic banter and smiles helped me through radiation. Even though the laser beam doses were over, it did not feel over. I still had daily doctors appointments. I hoped the fatigue wouldn't get much worse. Two days later, my husband and I went out to dinner for Valentine's Day. I dressed up. It was nice. At home, I peeled the clothes off my abused skin gingerly. Like right after chemo, congratulations poured in. Like right after chemo, I wondered when it would feel over.

Six days after radiation ended, I was in a meeting when I found out my grandmother had passed away. For once in my life, I cancelled everything and let myself feel. Well, everything but getting pretty nails again. I chose a design that felt hopeful. I'd missed my nail artist. We watched Jurassic Park and I almost felt normal.

After a couple weeks, the fatigue began to lift again. I leapt back into life. I cling to the little good things. I Don't Think About the statistics. I take the new symptoms, like scar tissue forming from radiation, as they come. I contemplate plastic surgery and kids. My relationship with my body, myself, and everyone in my life is different. It feels like it is over and it isn't. I got a week's respite before I started the drug I'll be on for five to ten years. So far, it seems like I'm tolerating it well.

My veins are still bruised and scarred from chemo. It's now been long enough that I can say I probably won't get the horrible nerve pain side effect. I plan on cutting my hair short next week. I'm a little softer around the edges and little harder in other places.

We've Been Here Since the Beginning: 2025 Edition

Abbey Perini — Fri, 07 Mar 2025 18:39:34 +0000

This is a submission for the WeCoded Challenge: Echoes of Experience

Last time, I was tired. This time, I'm angry.

I'm Angry
The Black Women Who Made Margaret Hamilton's Work Possible
Molly Holzschlag
Alan Emtage
Mary Ann Horton
Roy Clay Sr.
Edith Windsor
Conclusion

I'm Angry

Today, doublespeak about DEI (diversity, equity, and inclusion) is all the rage in America. According to those in power, it's the cause of plane crashes and inefficiency. They crow that it needs to be pulled out by the roots so merit-based hiring is possible.

In reality, civil rights are inconvenient if you want to consolidate wealth in one combination of race, class, and gender. DEI has been an often slow and painful effort to move the needle a little bit towards merit-based hiring. This is especially obvious when you notice how much of the attack on DEI is focused on erasing history.

People feel safe telling me that I had an easier time getting a job because of DEI. They believe the quotas myth. When it works, DEI gives us small benefits that aim to level the playing field - like having to interview more job candidates than just the hiring manager's fraternity brothers. Usually, it doesn't work. Thanks to the DEI efforts of those who came before me, I've actually had a job where I wasn't the only femme-presenting technical person in the room. Now, many companies are openly trying to reverse that trend.

My anger grows when I think about how I have it pretty easy. Though I am queer, I pass as cishet. People are socialized to see my lack of melanin as non-threatening. Generational wealth and connections give me more opportunities and a safety net. I've had support whenever I've had to stand up for myself in the face of discrimination and harassment.

Diversity and inclusion don't stop at race, gender, and class, so accessibility is under attack too. It's no secret that that's something I'm passionate about. Some of that is personal experience - I take on physical and cognitive barriers every day of my life. Accommodations I need are not won easily. Mostly, it's empathy. Over and over again, I have found that empathy makes me a better developer. The results of that empathy - accessibility and inclusion - make better systems. And yet, I can only fume as I watch industry leaders choose money over people. I am stuck seething as people I look up to are told to erase their accessibility work or lose their job.

We took the short-term view with the Cavendish banana. Its lack of genetic diversity means the global banana industry collapse grows more likely every day. In the same way, a lack of diversity of thought in tech will rob us of a more sustainable, more human future. We can combat that by listening to those who see the negative impacts of technology the most - like Amazon Alexa engineer Michael Running Wolf's work trying to revitalize indigenous languages. Let's start by acknowledging that the kinds of people they're trying to erase have been and always will be integral to advances in programming and web development.

The Black Women Who Made Margaret Hamilton's Work Possible

Photo credit: mathshistory.st-andrews.ac.uk

Evelyn Boyd Granville was the second Black woman to receive a Ph.D. in mathematics from an American university. Academic posts for Black women were highly restrictive, so she explored other options. In 1956, she was working as a computer programmer at IBM. She started out writing programs in the assembly language SOAP and FORTRAN for the IBM 650 computer. In 1957, as part of IBM’s Vanguard Computing Center, she wrote programs that tracked orbits for the Vanguard satellite and Mercury spacecraft programs. In 1962, Evelyn joined the aerospace firm North American Aviation. This time, she was working on celestial mechanics and trajectory calculations for the Apollo project.

Photo credit: nasa.gov

In 1957, Dorothy Johnson Vaughan was manager of the National Advisory Committee for Aeronautics’ (NACA’s) West Area Computing Unit. She had been managing the segregated unit since 1949. While NASA (National Aeronautics and Space Administration) wasn't even called NASA yet, she was the first Black woman promoted to a managerial role. During the 10 years she managed the unit, Dorothy and the Black women who reported to her contributed to virtually every area of research at Langley. When engineers found that they had a challenging computing task, they would ask Dorothy to handle it personally. In that role, she took it upon herself to advocate for her direct reports and other women who were passed over for raises and promotions.

In 1958, the space race was heating up. This is when NACA desegregated, abolished teams separated by gender, and became NASA. Dorothy joined the new Analysis and Computation Division (ACD). The book and movie Hidden Figures covered events in 1961 and 1962.

As part of her work for the ACD, Dorothy learned FORTRAN and contributed to the Scout Launch Vehicle Program. This program aimed to make reliable rocket launches possible. It created the launch system used by many U.S. and international space missions and programs. This includes the first American satellites and the Interplanetary Monitoring Platform (IMP). The IMP collected data on spatial and temporal relationships of geophysical and interplanetary phenomena like radiation. The Apollo program required the technological advances made to get the system working and the data collected by it.

Although Dorothy never received another managerial role, Dorothy's legacy lived on through the success of those she supported while she managed them.

Photo credit: nasa.gov

Mary Jackson became the first Black woman to be promoted to engineer. For a long time, she was probably the only one at NASA. To work in the 4-foot by 4-foot Supersonic Pressure Tunnel, she had to get special permission to attend the required training classes. They were held in a segregated high school. After a couple decades and 12 papers on understanding air flow, including thrust and drag forces, she was awarded the Apollo Achievement Award. When she realized she wasn't going to get promoted anymore, she took a demotion. Her new position had impact on the hiring and promotion of the next generation of all of NASA’s women mathematicians, engineers and scientists. She even opened her home to aspiring NASA employees who needed a place to stay.

Photo credit: nasa.gov

When NACA became NASA, Katherine Johnson joined the Space Task Group. Katherine calculated trajectories for America's first manned space flight. She was the first woman in the Flight Research Division to receive author credit on a research report. In 1962, astronaut John Glenn said he would only do the Friendship 7 mission if Katherine hand-checked the IBM computer's trajectory calculations. Katherine also did the calculations that synced the Apollo Project’s Lunar Module with the lunar-orbiting Command and Service Module. She worked on the Space Shuttle and the first satellite launched to study and monitor Earth’s landmasses. She authored or coauthored 26 research reports. In 2015, she was awarded the Presidential Medal of Freedom.

Molly Holzschlag

Photo credit: tucsonsentinel.com

In 2023, I watched accessibility advocates mourn Molly Holzschlag, the "Fairy Godmother of the Web". A contemporary of Sir Tim Berners Lee, she wrote one of the first blogs, earning her the handle mollydotcom. She was the leader of the Web Standards Group which pushed Microsoft, Opera and Netscape to adopt web standards. After she strong-armed Bill Gates into including CSS in the next Internet Explorer release he called her "the annoying web standards girl".

In other words, during the browser wars, she was the person making sure the browsers agreed on enough standards to make the same website code work on all of them. Many of the standards were also aimed at making screen readers actually usable. Her motivation? The world wide web should be usable for everyone.

Molly died at the age of 60. In her last few years, her husband died, and she grew very ill. She was forced to raise money for her medical bills including selling off her eponymous domain molly.com.

Alan Emtage

Photo credit: internethalloffame.org

Alan Emtage, a gay Black man from Barbados, wrote the first search engine, Archie. In 1989, working on a mainframe computer meant waiting hours for a dot matrix computer to print out what you needed.

"Rather than spending my time logging on to FTP sites and trying to figure out what was on them, I wrote some computer scripts that would do the same thing, and much faster too." - Alan Emtage

Alan co-founded the world's first Internet startup. As a founding member of the Internet Society, he headed up several groups in the Internet Engineering Task Force alongside Sir Tim Berners Lee. One of those groups standardized Uniform Resource Locators (URLs).

Alan is a partner at Mediapolis, Inc., the award-winning web development company that operates LGBTQ+ sites under ‘The Datalounge Network". These days, Mediapolis also helps new startups.

Mary Ann Horton

Photo credit: maryannhorton.com

If you've ever used macros or function keys in a vi editor, you have Mary Ann Horton, a trans woman, to thank. If you've only used other text editors, you can thank her every time the editor shows you an error in a formatted file. Linux/Unix users and developers owe her a lot. Among other things, she developed uuencode/uudecode which enabled email attachments beyond text files.

She was also integral to Usenet, one of the first social media networks. As part of the Backbone Cabal, she set up spam filtering and started content moderation.

After college, she started working for Bell Labs. She developed email, Usenet, and internet gateways for AT&T.

As if all that wasn't enough, she also advocated for transgender employment rights while exploring her own gender identity.

Roy Clay Sr.

Photo credit: Roy Clay Sr. family via usatoday.com

Roy Clay Sr. was one of the first Black men to attend Saint Louis University. After school, he was turned away from an interview because of his race. He spent five years applying to that company. In 1956, they hired him as a computer programmer. In 1958, he moved to California to write radiation tracking software to map the aftermath of a nuclear explosion. In 1965, David Packard, co-founder of Hewlett-Packard (HP), hired him to head the software devision for their new computers. Roy was director of the team that built the HP 2116A minicomputer, HP's first computer. With his teams, he emphasized results over set work hours. He invented flex time.

In 1971, Roy left HP to found a consulting firm. The venture capital firm Kleiner Perkins relied on his recommendations, like Intel and Compaq.

In 1973, he was the first Black person to serve on the Palo Alto, California City Council. At one point, he served as the city’s vice-mayor.

In 1977, he got wind of new electronic safety requirements. Roy founded ROD-L Electronics, the first company to produce testing equipment that certified products met those requirements. The company was located in East Palo Alto. He hired community residents, who were predominantly Black, earning him the moniker the Godfather of Silicon Valley.

Edith Windsor

Photo credit: nyhistory.org

You may know Edith "Edie" Windsor as the LGBTQ+ rights activist who sued the U.S. government. Her Supreme Court case, United States v. Windsor, established a precedent for marriage equality.

You may not know that Edie, the daughter of Jewish immigrants, was a talented and prolific programmer. While she earned her second degree, Edie worked on nuclear steam supply power systems for the Atomic Energy Commission as a programmer at Combustion Engineering. This was in the 1950s, so she worked on one of the country's only UNIVACs. At the time, it was illegal for her to be homosexual and to wear men's clothes. Terrified, she wore "crinolines and a marvelous dress to meet the FBI” to get clearance to work on the project.

Edie began her career at IBM as a mainframe programmer. She was there for 16 years, designing systems architecture and language processors. She eventually reached the company's highest technical rank, Senior Systems Programmer. Known for her "top debugging skills," she owned the first IBM-PC shipped to New York City.

"I could read code until it wrapped around the room and back again. A guy I was working with said, ‘give this woman a roll of toilet paper, she can do anything.'” - Edie Windsor

After she left IBM in 1975, she founded a consulting firm called PC Classics. Among other things, they worked to set up computer systems for LGBTQ+ advocacy groups. Lesbians Who Tech have a scholarship for queer women and non-binary techies in her honor.

Conclusion

The idea that any one race, gender, class, or sexuality is more suited to a technical role is patently false. DEI and accessibility efforts seek to level the playing field, but are slow and currently under attack. We need people to lean into their empathy now.

Don't know where to start? I wrote 8 Ways to Support Women Developers in such a way that you can swap out the word "woman" for pretty much any other identifier.

10 Tips from 10 Tech Conferences in 2024

Abbey Perini — Fri, 29 Nov 2024 16:21:42 +0000

I attended 10 conferences this year, spoke at 6 of them, and I'm not in DevRel. Here are are my top 10 tips - one for each conference!

1. The Hallway Track

Leave time in your schedule to talk with people, visit booths, and decompress. Your brain can only absorb so much technical information at once, and networking is important too.

2. No Two Conferences Are the Same

Every conference organizer prioritizes different things. Not every conference is going to be your cup of tea, and that's fine.

3. Support Your Local Organizers

Community events are struggling. Go to events. Share you're going. Bring friends. Volunteer. Talk to your company about sponsoring.

4. It's a Small World

Be kind, because you never know who knows who. There are multiple people who I saw at four or more conferences this year. This also means speaking and socializing at conferences can lead to speaking opportunities!

5. Wear What Makes You Feel Comfortable

Be you. If you're more fabulous than everyone else, someone's going to compliment you. Easy networking.

6. Plan an Easy Way to Connect

I make stickers. You can do business cards or even a QR code. The networking continues after the conference is over.

7. Have We Met Before?

Especially as a speaker, you talk to dozens of strangers at a single conference. Don't expect people to remember you, and you don't have to be embarrassed if you don't remember them. If you haven't interacted with someone since the last conference you saw them at, reintroduce yourself and mention the last time you met.

8. Travel is Hard

Even if you're practiced and enjoy it, you're always in danger of dehydration. The best conference provides water and snacks, but plan like they won't.

9. Read the Emails

Speaking of planning, at least read the schedule before you show up. At some conferences, after-hours events fill up before the conference starts.

Conference organizers will love you if you read the emails. This is also how you find out if there are days when you are encouraged to wear costumes, and costumes are a surprisingly good networking tool!

10. Shoot Your Speaking Shot

When I was peer pressured into submitting talk ideas to tech conferences' call for proposals (CFPs), I did not expect so many to get get accepted. Now, I pass that pressure on to you. Check out confs.tech/cfp to find some CFPs and submit! If you have no idea where to start, read So You Need to Give a Talk...!

Dark Mode Toggle in HTML Web Components

Abbey Perini — Tue, 22 Oct 2024 20:50:35 +0000

When designing my digital garden, I knew I wanted a cute dark mode toggle. Once I had drawn my SVG, I started building a web component that had all the same functionality as my dark mode toggle in React. This includes everything I learned while accessibility auditing my site.

In addition to changing the theme, the toggle needs to take the user's prefers-color-scheme selection into account and persist the user's preference across reloads. For accessibility, the toggle's screen reader announcement must make sense (e.g. "dark mode toggle on"). Since I want to display an SVG instead of a checkbox with text, I'll have to add focus and hover styling and a label that shows up on hover.

Toggle Web Component

First, I need a Toggle class that creates an HTML element. Using the Custom Element API, I'll define <toggle-component> using this class.

Using the class's constructor, I set the innerHTML of <toggle-component> to a <label> with an <input type="checkbox"> and SVG as children. The label has a title attribute, giving our toggle a visible "dark mode toggle" label if a user hovers over it or the <input>. Because the checkbox is a child of the <label>, interacting with the <label> is the same thing as interacting with the <input> and vice versa. The title attribute also makes sure screen readers announce "dark mode toggle" when a user interacts with this component.

Once the HTML is in place, I add a connectedCallback function to the class. This part of the custom elements API defines functions for use within the component and executes code when the component is inserted into the DOM.

// /components/toggle.js

class Toggle extends HTMLElement {
  constructor() {
    super();
    this.innerHTML = `
      <label title="dark mode toggle">
        <input type="checkbox" id="theme-toggle" class="theme-switch" />
        <svg id="daisy">{SVG code removed for brevity}</svg>
      </label>
    `
    this.setAttribute("class", "toggle-component");
  }

  connectedCallback() {
    function switchTheme(e) {
      if (e.target.checked) {
        setTheme('dark');
        return;
      }

      setTheme('light');   
    };

    function setTheme(themeName) {
      localStorage.setItem('theme', themeName);
      document.documentElement.setAttribute('data-theme', themeName);
    };

    function setCheckBox(toggleSwitch, theme) {
      toggleSwitch.checked = theme === 'dark' ? true : false;
    }

    function keepTheme() {
      const toggleSwitch = document.querySelector('#theme-toggle');
      toggleSwitch.addEventListener('change', switchTheme, false);
      const theme = localStorage.getItem('theme');
      if (theme) {
        setTheme(theme);
        setCheckBox(toggleSwitch, theme);
        return;
      };

      const prefersLightTheme = window.matchMedia('(prefers-color-scheme: light)');
      if (prefersLightTheme.matches) {
        setTheme('light');
        return;
      };

      setTheme('dark');
      setCheckBox(toggleSwitch, 'dark');
    };

    document.addEventListener("DOMContentLoaded", keepTheme);    
  }
}

customElements.define("toggle-component", Toggle);

Because <toggle-component> is inserted into the DOM before the page loads, the only code that executes immediately adds an event listener. The event listener calls keepTheme as soon as the page has loaded. First, keepTheme adds an event listener to the <input> that calls switchTheme when a user interacts with it. switchTheme passes 'dark' to setTheme if the checkbox is checked and 'light' if it is not. The string passed to setTheme is set as the CSS theme and saved in localStorage which will persist across reloads.

The rest of keepTheme is dedicated to choosing the right theme on load. First, it checks localStorage to see if the user's preference is already set. Next, it checks if prefers-color-scheme is set to 'light'. Finally, it defaults to dark mode. For both dark and light mode, I call setTheme. For dark mode, I also call setCheckbox. The checkbox mounts in an unchecked state. A screen reader will announce "dark mode" and whether the checkbox is checked. To get an announcement like "dark mode toggle checked" or "dark mode toggle on", I have to programmatically check the checkbox when I set the theme to 'dark' on load.

Toggle Styling

I chose to draw a fairly simple design so I could put my SVG code directly in the web component and programmatically change the fill color. This way, the background color of the daisy always matches the theme. Next, I use opacity: 0; to hide the checkbox and position it in the middle of the image. Finally, I add the hover and focus styles.

/* /styles/styles.css */

[data-theme="light"] {
  --toggle-background: #242D54;
}

[data-theme="dark"] {
  --toggle-background: #282e53;
}

#daisy path {
  fill: var(--toggle-background);
}

.theme-switch {
  position: relative;
  bottom: 30px;
  left: 55px;
  width: 1em;
  height: 1em;
  opacity: 0;
}

.theme-switch:focus + #daisy path,
.theme-switch:hover + #daisy path {
  fill: white;
}

.theme-switch:focus + #daisy {
  outline: 3px solid white;
  outline-offset: 5px;
}

Using the Toggle Web Component

All I need to do is import my stylesheet and component script in the <head> of an HTML page. Then I can call <toggle-component> anywhere in the page.

<!-- index.html -->

<html lang="es">
  <head>
    <link rel='stylesheet' href='../styles/styles.css'/>
    <script src="../components/toggle.js" type="text/javascript" defer></script>
  </head>
  <body>
    <header>
      <toggle-component></toggle-component>
    </header>
  </body>
</html>

Conclusion

I had fun getting my dark mode toggle to work just as well in a web component as it does in React. You can see this live in my digital garden and the full code in the GitHub repo.

So You Need to Give a Talk...

Abbey Perini — Mon, 30 Sep 2024 18:45:15 +0000

Take it from someone who barely passed their college public speaking course - you can definitely give a tech talk.

Pick an Idea

Everyone has a unique perspective or experience that is worth sharing. Every time you explain something to a coworker, solve a unique problem at work, dive down a research rabbit hole, or solve a hard problem, that's an opportunity to write a talk.

Marketing

Whether it's a meetup or conference call for proposals (CFP), you'll need a title and an abstract. If you can come up with a witty title, great. Otherwise, a short, descriptive title is perfectly fine.

Think about the abstracts you've read that made you want to attend a talk. Don't list out every point you're going to make. Do convey what attendees should expect to learn during your talk.

Many CFPs ask for supporting materials or more explanation. This is the place to list out all of the points you want to cover and show you understand the topic. All of my talks start as blogs, so I usually use a link to the blog.

Save all of this information after you've typed it out. You can and should submit the same talk to multiple events. If the talk never gets picked up, it can always be turned into written or video content. If it gets picked up multiple times, you'll be able to improve upon it iteratively.

If you're mainly motivated by deadlines, you can wait for your talk proposal to get accepted before working on it more. If you're excited about the idea, you can go ahead and start your outline.

Outline

Just like in the more explanation part of the CFP, write down the main points you want to convey during your talk. Once you're done, read back through your points from the prospective of an attendee. Do any of the points require prerequisite knowledge or more explanation?

The best talks have a flow that is similar to a story - a beginning, middle, and end. If your beginning involves introducing yourself, make it relevant. For example, why you're an expert on this subject or how you got the idea for the talk. If you're talking about a problem and a solution, the beginning is the time to outline the problem you're going to solve. The middle sets up all the necessary context for the end. The end is your conclusion, recommendation, or solution.

Slides

Find a slides program you are comfortable using. These days, your slides double as notes for attendees to use after your talk, so don't forget to include ways to connect with you and a QR code with a link to your slides. If you don't want to use slides, structure what you will be showing on the screen so that you can still give a copy to the audience. For example, a code repository with comments in the code. I've even heard of making a copy of your terminal history and publishing a link to it if your talk is entirely in the command line.

Put your outline in your slides (or code repository or terminal history). Include links to relevant codepens, code repositories, documentation and resources. Include helpful visual aids with captions and/or memes with alt text.

An outline should be just enough words to get your point across. Don't write down the entire script of your talk. You don't need a slide for every sentence you're going to say. Use link formatting to turn text into links rather than bare URLs. Whatever you are showing on the screen should support what you are saying, not distract from it.

Practice

Practice includes rehearsing a specific talk you need to give and giving talks in front of audiences. You'll see that the people with lots of public speaking experience don't have to rehearse specific talks as much. Until you have made a mistake and recovered in front of an audience, it's a good idea to know your talk really well before you get on stage. If you rehearse, when something goes wrong or throws you off, it's much easier to remember what you were going to say and get back on track.

Experienced speakers will tell you speaking in front of an audience is the only way to get comfortable speaking in front of an audience. So utilize opportunities to give demos and presentations at work and in school. Ask your friends and family to listen to your talk even if they don't understand the topic.

If there is dedicated time for questions or you'll allow attendees to ask you questions after your talk, you need to be familiar with the topic beyond what's on your slides. If you want to use a clicker, play a video, use a prop, or live code, rehearse with these things.

Unless you have confirmed beforehand with the event that you will have reliable internet and multiple screens, practice your presentation without internet on a single screen.

You can always use paper notes, but I prefer to make my slides my notes. If you read your notes like a script, it will sound like you're reading a script. As I rehearse, I'll add slides with points I keep forgetting to say and remove slides I find I don't need.

If you're live coding, set up examples that require the least amount of typing. This usually means commenting and uncommenting chunks of code or only running simple commands.

If you're planning on doing a demo (especially if it's your company's product), record yourself demoing before the talk. Something always goes wrong with a demo, so you may need to play the recording instead.

The Big Day

As a speaker, you'll find every other speaker understands that your goal is to minimize your anticipatory anxiety until you've given your talk. Prepare for this. In the weeks leading up to the talk, find a few anxiety reduction techniques that work for you and use them on the big day. I find it extremely helpful to ask a friend to set aside 30 minutes before my talk just to hang out and talk with me. Don't pick the day of your talk to do things that spike your anxiety. Do remember to eat regular meals and drink plenty of water. Charge your devices and bring adaptors for display cords. This puck has saved many butts, including mine.

Attend other talks and hang out in the speaker room. This way, you'll find out if other speakers are running into problems with the setup and have already found solutions. Get to your speaking location early so you have time to do a tech check.

If you don't have friends attending the event, befriend other speakers and attendees. If all else fails and you start panicking, a friendly face makes a big difference.

Most importantly, remember the audience wants to be interested in your talk and thus wants you to succeed.