Welcome to the sixth edition of my year in review. (See 2023, 2022, 2021, 2020 and 2019 for previous editions.)

2024 was a year of two beautiful babies born to two of my best friends: congratulations to their proud, wonderful parents, Robin and Mark and Véro and Geoff ♥️

It was also the year I became an American citizen, my two younger siblings graduated from law school, I rounded out the first decade of my career as a software engineer and O turned 3. We also discovered apartment swapping this year: we did two, one with M in Montreal and the other with a family of Js from Berlin, two big highlights.

Let's start at the beginning.

See you never, USCIS

I came to the U.S. from Canada on a three year dual intent work visa, an L-1B, in early 2017. I was working at a Canadian startup with a New York office and quite literally hit the ground running: I remember dashing out to pick up my new social security card emblazoned with the words VALID FOR WORK ONLY WITH DHS AUTHORIZATION followed by a new SIM card in Chinatown on one of my first mornings.

In my first few weeks I attended a University of Toronto alumni event at a hotel by Central Park. I don't know what I was expecting: it was a ballroom full of Canadians drinking cocktails discussing which visas they were on.

I lived in Williamsburg in a fourth floor walk-up with a roommate I found on Craigslist (shout out to Milo 💖) and worked in SoHo. It feels silly in retrospect, but I was actually surprised at how much I loved living in New York, pretty much immediately.

When I raised my hand for this opportunity, I wasn't thinking long-term: it seemed like a new and interesting challenge, one that would be fun. But once I arrived, I realized the three year clock on my visa was already ticking. I had to start lobbying my employer to sponsor my green card application if I had any interest in buying myself more time. I also met Carla soon after arriving and didn't want this new and clearly very special relationship cut short.

Thus began one of the most challenging periods of my life as I embarked on the journey from nonresident alien to lawful permanent resident, and finally citizen in February of this year.

There's a lot more to say here and maybe I'll write about it in greater detail one day. But seeing the life and career I was building dangling by a thread as I navigated a mind-bogglingly slow and artificial process, without job portability, while working at a faltering startup, all during a virulently anti-immigrant administration—not to mention the early pandemic—was so stressful it's hard to describe.

For four years, I obsessively read immigration forums and shared application timelines with fellow travelers through the broken system that is the U.S. Citizenship and Immigration Services. I felt totally powerless and dealt with depression and anxiety for the first time.

The people I found it easiest to talk to during this period were my grandparents, three of whom I'm very fortune to still be able to call. Speaking with them gave me comfort: they had immigrated to Canada from Italy in the 1950s with other close relatives ending up in the U.S., and they knew about the travel restrictions and missed life events that were part and parcel of this experience.

I'm happy I—a Canadian with a degree, though crucially not one relevant to the field I wound up in—can finally put down my bags, but so many people are stuck with far longer waits or without any path to legal status. The scale of human suffering caused by this system is mind numbing. It urgently needs to change.

The last thing I'll add, in case it helps someone in the future, is how critical it is to consult a lawyer. But this is important: NOT the one your employer hires to work on your application. That is the company's lawyer. The best advice I received was from attorney Jonathan Langer; if you're ever in need of a U.S. immigration consult, I can't recommend him highly enough.

Anyways, I'm American now. 🇺🇸 This is the place I call home, where I've started a family and plan to stay for the rest of my life—it still feels surreal to write those words.

From Montreal to Berlin

In June, we went to Montreal to celebrate Carla's birthday. It was our first apartment swap with a stranger (!): we stayed at M's apartment in Little Italy and had a ball. We went to Jean Talon market, the wading pool and playgrounds in Jarry Park, Iconoglace (run don't walk, ice cream fans), did a 40km bike ride around the south-west part of the island with a rented trailer for O and ended Carla's birthday at JazzFest for the second year in a row. We remain enamored with Montreal and want to do a winter family visit next.

In August, we celebrated O's 3rd birthday on the plane to Berlin, concluding about a week of parties with friends and family in New York. He's such a thoughtful, loving kid, and getting sillier by the day.

~Eight months earlier, we joined a home exchange group on Facebook and began searching for a match for a week in August when we had no childcare. We happened upon a family from Berlin that was planning a big American vacation and our dates lined up!

As hosts, we loved seeing this family enjoy our immediate neighborhood and explore the city over the course of ten days, and left out plenty of games and sports stuff for their kids.

Not paying for lodging can also unlock new experiences: my parents decided to drop in for part of the trip because we had space for them to stay. Some highlights included a visit to Neuremberg to see the DB Train Museum and the Playmobil FunPark at Zirndorf, and the German Museum of Technology (below) in Berlin.

We also got to spend time with Carla's friend and former roommate, F, and her lovely family 💕 Many thanks to the J name family and my colleague Lenz for all the recommendations.

Thanks for the good times, Apollo

This past Friday was my last day at Apollo. I want to thank my colleagues who made the last 2.5 years as special as they were: Jeff, Hugh, Jerel, Lenz and Ben especially, and my wider Clients Team family including Martin, Benoit, Calvin, Anthony and Zach.

It was nothing short of a dream job: I got to do open source work full-time with some of the brightest, most thoughtful engineers and managers in the business and travel around speaking about what we were building. I gave eight talks in two years (ok, with some recycled material 😅) at some of the biggest React and GraphQL conferences around the globe. My face was in the (in)famous React Conf 2024 grid:

It has been such a pleasure working with everyone at Apollo and the wider open source communities I've spent time with, and I've learned so many things from this experience I'll carry forward in my career. The future is incredibly bright for Apollo and the GraphQL community writ large.

Tudum

One last bit of news: today is my first day as a Senior Software Engineer at Netflix! I'll be working on the XD Design Engineering team building the Design Platform API with some incredible colleagues, and I couldn't be more excited about it.

Quarter century complete

I'll end on a note of gratitude and anticipation: there are some very exciting things on the horizon in 2025... We're so grateful for the past 12 months we've shared, and for everyone who made them special.

From our family to yours, we hope you have a wonderful holiday season and a happy new year. ♥️

Welcome to the fifth edition of my year in review! (See 2022, 2021, 2020 and 2019 for previous editions.)

This year was both intense and utterly wonderful. A bigger walking and talking Baby O turned 2! I had the opportunity to speak at six conferences on two continents. Our family traveled to new places including Newfoundland, Idaho and (new to the little one) London and Paris. We also spent a wonderful weekend with several of O's siblings in Buffalo, NY, and are winding down the year with our families in New York and Toronto.

Let's get started ▶️

January

The most notable thing that happened in January: Baby O said "I love you" for the first time. I've never managed to journal consistently, but whenever a "first" happens, I try to add it as a calendar event in my phone.

A few taps calls up a precious set of memories: the first time he used a spoon by himself; the first time he slept in a big kid bed (he transitioned from a crib at 18 months for height and safety reasons - do not recommend if you can help it 🥲); the first time he demanded toys in a toy store (I remember it well...)

March: Brooklyn rendezvous

My friend Adelaide was engaged to be married in the spring and made the excellent choice of Brooklyn for her bachelorette party.

I put together a list of dinner spots and activities. We ate, we drank, some of us played the tambourine until our legs were bruised. (Shout out to the tambourines at Insa, the hardest working karaoke accessories in the five boroughs.) Above all, we celebrated the bride to be - congratulations Adelaide and Matt, we love you!

June: another Canuck in the house

In June, O had his Canadian citizenship legally recognized, coincidentally on my grandfather's 95th birthday whose name O bears as a middle name. I was able to file online using a new paperless process - the artifact at the end is a simple PDF.

Our appetite for bureaucratic paperwork not fully sated, we then applied for his NEXUS card. NEXUS is actually a superset of the Global Entry program, and costs $50 instead of $100. The only downside is you have to do an in person interview at an enrollment center, but if you ever fly through Toronto's Pearson airport it's pretty quick and so worth it.

July: heading East

I have a bucket list like every good Millennial and Newfoundland has always been on it. I can't really explain why. In my early twenties, I dated someone who had lived in and subsequently moved back to Halifax, so I got to know a few Maritimers through my visits.

...if you're thinking "but Alessia, Newfoundland isn't part of the Maritimes!" there's like a 90% chance you're from out east. (Does anyone know this outside the region? I learned it while browsing /r/StJohnsNL for toddler activities and watching unsuspecting redditors get roasted.)

Now you know this bit of Canadian arcana, too: Atlantic Canada is the Maritimes (Nova Scotia, New Brunswick, PEI) plus Newfoundland. That and Newfoundland is both the only active time zone with a half-hour offset from UTC in the Americas and the home of the easternmost point in North America (excluding Greenland), Cape Spear.

The plan was to fly into St. John's (via Montreal where we spent a few days first at JazzFest), check out the Newfoundland and Labrador folk festival and travel around a bit.

It was the perfect destination to bop around with a toddler: we hiked through beautiful parks and coves, saw all kinds of wildlife including whales (a.k.a. Baby Beluga), met lovely people like Marnie, the owner of children's book publisher and store Running the Goat in Tors Cove which was an amazing find by Carla, had top notch dinners at places like Chinched and the biggest, most perfectly cooked piece of haddock at Portage. I'd love to visit more remote parts of the province and see Gros Morne one day.

Here's my google map of mostly places we visited and some we'd like to next time.

The folk festival was also a good call: O ran up and down the aisles during the sets pretending he didn't know us out of fear we'd cramp his style.

August to November: conference szn

In August the year kicked into overdrive. A string of conferences began with React Rally in Salt Lake City followed by a trip up to Boise to visit the Arnolds' growing family (we missed the newest member by just a couple of months!).

Then in quick succession: GraphQL Conf in San Francisco, GraphQL Summit in San Diego, React Advanced in London (with trips to Cambridge to visit Laura 🐮 and Paris to visit Martin and Clémentine 🌰), React Summit US back in NYC and RVA.js in Richmond, Virginia. (All of the recordings are up on my speaking page for posterity.)

Our trip to London in October marked O's first time in Europe and he was enamored with the various modes of transportation we encountered, including:

• Subways of all colours and varieties (in Paris you can open the doors before the train stops moving!)
• Double decker buses: this was a BIG one. O sang “wheels on the bus” on one memorable 45 minute bus journey back to Battersea causing a nearby passenger to not only put on her noise cancelling headphones but also press the cups against her ears until we disembarked.
• The high speed Eurostar train from London to Paris which reached speeds of 295kmh (~185mph).
• A charming-given-how-touristy-it-was open air bus pretending to be a train that took us on a sightseeing jaunt from Moulin Rouge to Sacré Coeur and back. This was also where O heard the Can Can from Orpheus in the Underworld for the first time, still a favourite of his.
• The national rail line in London, which we took almost daily to connect to the subway as the nearest stop to us was Clapham Junction.

In addition, we got to meet one of O's siblings who lives in London! We were sick at the end of our trip so we didn't get to spend as much time together as we were anticipating, but it was still such a delight to meet R and mums. ❤️

It was also so nice to spend time with Lenz and Jerel, two colleagues I work closest with and whom I rarely see in person.

Working at a remote-first distributed company means collaborating with some truly excellent coworkers across a nine hour timezone spread (GMT-8 to GMT+1) at the expense of IRL face time 98%+ of the year. The prep and travel were tiring, but being able to have a pint over some food after our presentations was all the sweeter for it.

September: a sibling visit in Buffalo and starting preschool

Amidst the conferences, we made a trip back to Carla's ancestral homeland of Buffalo, NY and the next day O started preschool.

Buffalo

Having met a number of O's siblings and their families on our travels, a few families decided to get together for a weekend, some for the n+1 time and some for the first!

We rented an Airbnb with three big apartments under one roof. There were 9 kids and 12 adults in total (one family with young kids stayed nearby for napping purposes, a very smart move).

It was such a blast. With ages ranging from 3 months to almost 3 years, and three families bravely flying from California (dealing not just with toddlers or jet lag but the force multiplication of the two) we were all on different schedules, but we still managed to spend a lot of time together and make so many memories.

This was the first time that O had, if not conversations, independent interactions with his siblings and even an inside joke or two! Then there was the time I came down the stairs as we were getting ready to leave and O looked like he was hugging one of his brothers. My chest swelled with pride and emotion for a second, that is until I realized he was trying to steal A's Timbit... We can't wait for next year on the west coast!

Preschool

As a newly minted 2 year old as of August, O's personality is on full display: he loves (perhaps not strong enough of a word... adores to the point of dreaming nightly about) his toy vehicles, being cozy with Mama and Mommy and, since starting "school", seeing his friends and teachers every day, all of whom he talks about with great excitement.

And I'd be remiss if I didn't give a special shout out to the cat we pass on our daily walk, Mish Mish:

An ode to Carla

September marked my first time being away for four consecutive nights since O's birth. While I'm so grateful to have had these opportunities, work travel comes with a cost for the parent holding things down at home.

Carla has always had a busy work life as a lawyer running her own practice. This year was no exception: Carla won a federal appeal before the Second Circuit, was named a Rising Star and Super Lawyer featured in a magazine spread and still manages to pull off a bedtime routine after a long day (no easy feat for those who haven't faced down a strong-willed or even just average-willed toddler recently).

Carla: O and I love and appreciate you so much, not for what you do for our family—which is incalculable—but for your goofy, exuberant self and huge heart. We are so lucky to have you.

Year's end

We're rounding out the year with Thanksgiving and holiday celebrations in NYC and a coming visit to Toronto. None of this would have been possible without help from our families, particularly my mother-in-law Mary who helped us on numerous occasions when child care fell through, and the support of our friends. Thank you all for being a part of our lives, and sending our love and best wishes for 2024. 🥂

If React and GraphQL are your thing, check it out and let me know what you think!

Changesets

After comparing several options, Changesets stood out as the library that would allow our team to adapt our existing manual workflow seamlessly.

Some of its features include:

1. changelog entries written in Markdown at the time code is committed so both changelog and release notes can contain formatted code blocks, links, and other rich contextual information related to the change
2. an API for handling prereleases in long-running integration branches
3. a simple mechanism for batching changes into releases (changesets .md files themselves)
4. many other nice to haves, including snapshot releases

IMO, the prerelease workflow is more interesting to discuss since its API may undergo significant changes in v3 and it took a bit of experimentation before landing on the current approach, so let's take a look at the more straightforward release workflow first.

Releases

The basic premise of Changesets is that each change to your library (or libraries—it was designed with monorepos in mind) is represented by a markdown file generated via npx changeset.

The CLI prompts you with two questions: whether your change represents a new patch/minor/major version, and for a description of the change. Once this info is entered, the CLI uses it to generate a new file inside of .changeset.

Here's an example of a recent Apollo Client changeset, .changeset/gorgeous-buses-laugh.md:

---
'@apollo/client': patch
---
 
Adds `TVariables` generic to `GraphQLRequest` and `MockedResponse` interfaces.

In a monorepo, more than one package can be specified in the frontmatter block at the top. Once the PR containing the relevant change + changeset is merged to main the release workflow kicks off.

Here's an abridged + commented version of Apollo Client's release workflow:

name: Release
 
on:
  push:
    branches:
      - main
 
jobs:
  release:
    # Prevents action from creating a PR on forks
    if: github.repository == 'apollographql/apollo-client'
 
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
        with:
          # Fetch entire git history so  Changesets can generate
          # changelogs with the correct commits
          fetch-depth: 0
 
      # You can pass NPM_TOKEN directly to the
      # changesets action, but if you have an existing .npmrc
      # checked in, you'll need to append the token since .npmrc wins
      - name: Append NPM token to .npmrc
      # ...
 
      - name: Create release PR or publish to npm + GitHub
        id: changesets
        uses: changesets/action@v1
        with:
          # changesets increments the version in package.json according
          # to changesets files it detects and `npm i` updates lockfile
          version: npx changeset-version && npm i
          # publish command should build library and call changeset publish
          # it also accepts several flags including `--tag` to specify npm tag
          publish: npm run build && npx changeset publish -- --tag next
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
 
      # optional: announce the release somewhere
      - name: Send a Slack notification on publish
        if: steps.changesets.outcome == 'success' && steps.changesets.outputs.published == 'true'
        # send Slack/Discord/etc. message with
        # ${{ fromJson(steps.changesets.outputs.publishedPackages)[0].version }}

The first time this is run after merging a PR, changesets detects the new changeset file and opens a "Versions Packages" PR.

Every time the release workflow runs on push events to the main branch, any unreleased changeset files are incorportated into the "Version Packages" PR and Changesets is smart enough to increment the package(s) version number(s) to the correct version.

By that I mean: if you have two unreleased changesets, one a minor change and one a patch, that results in a new minor version 🎉 The automated "Version Packages" PR will update CHANGELOG.md listing minor/patch changes in separate sections, increment the version in package.json and lockfile, as well as removing the changeset markdown files for changes in the new release.

Merging this "Version Packages" PR is what will trigger the changesets/action to generate a new release 🥳

Prereleases

Prereleases work fairly similarly, but took some experimentation since entering "prerelease mode" generates a pre.json file that Changesets uses to track alpha releases.

Here's an example pre.json from Apollo Client's current release-3.8 branch:

{
  "mode": "pre",
  "tag": "alpha",
  "initialVersions": {
    "@apollo/client": "3.7.2"
  },
  "changesets": [
    "early-pens-retire",
    "polite-birds-rescue",
    "rude-mayflies-scream",
    "short-bikes-mate",
    "sixty-trains-sniff",
    "small-timers-shake",
    "wild-mice-nail"
  ]
}

In other simpler prerelease workflows I've seen in the wild, pre.json is repeatedly added and removed from the default branch, but that seemed like a nonstarter for Apollo Client with its many forks. I wanted to avoid ever committing pre.json to main.

Instead, Apollo Client:

1. enters pre mode on all release-x branches by default
2. each new commit with a changeset opens a "Version Packages (alpha)" PR that functions the same as regular releases,
3. but the version is monotonically increased, ie 3.8.0-alpha.0, 3.8.0-alpha.1, and so on
4. and only npm releases are generated (not GitHub releases)

Apollo Client's prerelease.yml looks like this:

# Are we already in pre mode?
- name: Check for pre.json file existence
  id: check_files
  uses: andstor/file-existence-action@v2.0.0
  with:
    files: '.changeset/pre.json'
 
# If .changeset/pre.json does not exist and we did not recently exit
# prerelease mode, enter prerelease mode with tag alpha
- name: Enter alpha prerelease mode
  if: steps.check_files.outputs.files_exists == 'false' && !contains(github.event.head_commit.message, 'Exit prerelease')
  run: npx changeset pre enter alpha
 
- name: Create alpha release PR
  uses: changesets/action@v1
  with:
    version: npm run changeset-version
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
# Read package version from package.json
# in case we just published a new version
# and want to pass it to a Discord, etc. bot to announce
# since `steps.changesets.outputs.publishedPackages` is undefined
# for prereleases (though we can read the version there
# for non-pre releases)
- name: get-npm-version
  id: package-version
  uses: martinbeentjes/npm-get-version-action@main
 
- name: Run publish
  id: changesets
  # Only run publish if we're still in pre mode and the last commit was
  # via an automatically created Version Packages PR
  if: steps.check_files.outputs.files_exists == 'true' && startsWith(github.event.head_commit.message, 'Version Packages')
  run: npm run changeset-publish

Exiting pre mode has its own workflow that does two things: removes pre.json and reverts the package number in package.json to the last released version in main, and a separate workflow check-prerelease.yml makes sure pre.json will never be accidentally merged to main.

Conclusion

Working with Changesets has been a breath of fresh air! It's taken a lot of tedious and repetitive tasks out of the release process, and allowed us to focus on the fixes and features on our roadmap. Many thanks to the team that builds and maintains it 🙌

Slow comes the hour, its passing speed how great!

Hello again! I can hardly believe I'm back at my laptop typing up another Year in Review post! Let's go 🏃‍♀️

2022 was a year of:

• two sweet babies born to friends and family (Adriano and Vivian 💛💜)
• one lemon-and-soccer-themed 1st birthday for Baby O ⚽️
• one 60th birthday celebration ft. pizza, sushi and my amazing mom, Erica
• one 60th birthday bash that involved a surprising (or unsurprising, if you know my dad) number of cartwheels: HBD "G Money" aka my uncle Gino
• one 70th birthday beach weekend for the books celebrating my father-in-law, John
• four beautiful weddings in Boston, Muskoka, Salt Lake City and the Bahamas (Véro & Geoff, Karyn & Cam, James & Germaine and Andrew & Naz 🎉)

At the close of 2021, Baby O was just four and a half months old and Carla and I were still getting our sea legs as parents. Through the warm glow of the first few months, we couldn't have been happier to be new moms to someone we already sensed was a very happy, goofy and energetic kid.

Hello, Manhattan

We started off the year in Brooklyn, but not for long. After 15 and 5 years respectively, Carla and I decided it was time to try out a new borough; midway through January we moved to Manhattan Valley on the Upper West Side. We've loved our first year here: everything we need is within a couple block radius of our apartment, we're closer to Carla's family and, crucially, our pediatrician's office is right downstairs.

By the power vested in me by the Commonwealth of Massachusetts

In February, I officiated the wedding of two of my best friends in Boston, Véronique and Geoff. I was very happily surprised by how simple it was to tick the bureaucratic boxes required to legally perform a wedding in Massachussetts—if you must wed a couple in the U.S., see if they'll tie the knot in the Baked Bean state.

Baby O took his first road trip with Carla, my mother-in-law, Mary, and me as we made the four hour drive. I was more nervous than I thought I'd be (will my retelling of their love story do it justice? is the tone just right?), but the couple made it easy. Their vows were 1 of 1 (x2), as expected, and the wedding speeches delivered by beaming parents landed differently than in the past, each recounting tender stories of awkward adolescences or less than convincing threats of running away from home. It was our first real outing in ages and the whole thing ******* rocked.

Meeting the family

The spring brought some highs (new job for A and Carla's law firm back in full swing post-maternity leave) and lows (COVID for A), but the summer made up for it. For ten days in June and July, Carla, Baby O and I descended on the Bay Area to visit close friends of mine: Robin is a brilliant historian who makes a mean martini and gorgeous pottery and ceramics; Mark, Robin's husband, is a skilled gardener who tends cells in his day job genetically engineering sustainable and delicious lab-grown meat.

But there was another important reason we took our 10 month old on his first cross-country plane ride: to meet some of his siblings for the first time 💖 Carla and I have come to understand the importance of bio kin on Baby O's dad's side from listening to the perspectives of adult donor conceived people (DCP).

While some use the term "diblings" (portmanteau of "donor siblings") to describe these sibling relationships, we've realized the term can downplay the connection our son has with the people who share 50% of his DNA. After all, lots of non-DCP kids grow up knowing their biological half siblings, and no one corrects them when they refer to them without qualification.

Meeting some of his siblings and their families and spending time with them throughout our visit was an incredible experience: the kids are all happy and outgoing, and while they're being raised in different households, it was stirring to observe the traits they share even at a young age. When the youngest sibling present began to cry, every parent in the room perked up. It sounded remarkably like each of our kids.

A huge added bonus for Carla and me was getting to know the parents. I've heard the term "cross-mom" used by DCP to refer to your sibling's mom, for example. Well, Baby O has lots of cross-moms and non-binary cross-parents! We're biased, but it's a super cool group of kids and parents, to a person. We're grateful for Baby O's, and by extension, our family, of all three branches of his family tree.

Leo szn

August was another highlight: we celebrated Baby O's first birthday back in NYC and again in Toronto followed by a weeklong Montreal trip. As a former coworker told me during the coldest February in recorded history soon after I'd moved there: don't worry, the summers are magical. Can confirm.

Heading into the end of the year, we're feeling so fortunate to be able to spend time with loved ones and marvel at how far our little family has come in the last 12 months. Sending you love and warmth this holiday season, reader, wherever you may be. 💌

-Alessia

@apollo/client is the most widely used GraphQL client library on the web: thousands of engineers building high performance web apps rely on it to cache and manage data fetched from GraphQL APIs.

The team is incredibly talented and kind. This will be my first full-time role working in OSS, and the chance to collaborate with veteran open source leaders like hwillson and benjamn is an opportunity I couldn't pass up. I'm so excited to get started.

My team is hiring! If this work sounds interesting to you, here's a more detailed job description. Feel free to get in touch.

The year began with much less fanfare than 2020, but with an undercurrent of anticipation for the newest family member already well on their way.

Ghost, our formerly-outdoor-but-now-solidly-indoor cat kept us entertained through the darkest hours of the winter as Carla slept more than usual and I kept myself occupied making Detroit-style pizzas from scratch. I turned 30 and my sister-in-law helped me realize my dream of one day owning a pasta maker.

Countless loaves of quarantine bread were baked and consumed, and in March we had the joy of becoming aunts for the first time to Dana & Jon's delightful Baby A.

15 minutes of Canadian infamy

In April, after gratefully receiving both vaccine doses, Carla and I decided to pay my family in Toronto a visit. The quarantine hotel requirement for international air travelers was in effect so we thought we'd walk across the Rainbow Bridge at Niagara Falls instead...

Our travel day went almost exactly according to plan save for the CTV reporter who rushed us on the Canadian side. I dodged him, but Carla proudly told him and his camera exactly why we'd crossed the border on foot. Her clip made the 6 o'clock news and we even received a few calls for our arrest via Twitter, this being 2021.

The rest of the spring/summer sped by: a couple of short visits to Rhode Island, Buffalo and Shelter Island, one baby shower in Prospect Park and a NYC Dyke March to remember (Carla was one of the most popular marchers with her crop top and, by then, massively pregnant belly.)

Here he comes

We were sitting (emphasis on sitting) on the N train when Carla's water broke as we pulled into the 39th Ave. station in Queens, what the labour and delivery nurse later called Baby O's "New York baptism." We hopped off and frantically called Carla's doctor who advised us to calmly head home (yeah right), grab our bag and proceed to the hospital.

It was an otherwise quiet Saturday afternoon when we finally arrived at the delivery ward. Veronika, the nurse on shift when we were first admitted, assured us Carla would probably still be waiting for active labour to begin when she came back on shift ~24H later. Baby O had other plans: the next morning at 7:24am he was in our arms.

In the middle of the delivery (!) one of the nurses noticed my OCAD sweatpants and exclaimed "Canadians?!" to my utter bewilderment. And in the seconds after Baby O's birth, another nurse grabbed my phone and snapped what are now the most precious photos I possess. I've heard other parents describe the bond that is formed with the people who help bring your child into the world, but I couldn't stop marveling at the level of care we received. We are forever indebted to the team at NYU Langone.

Learning to parent in a pandemic

The late summer/fall was a glorious jumble of diapers, long walks and discovering exactly what hour of the early morning my favorite podcasts drop while savouring my half of the night shift.

Despite the fully vaxxed summer in effect in NYC, having a newborn in many ways felt like being transported to day 0 of lockdown: fewer MTA trips, more walking and park hangs.

To end the year, we traveled to Toronto for Christmas and introduced the kid to one of the three branches of his family tree to everyone's delight. We cut our trip short due to Omicron, but we're so thankful for the time we had.

Thanks for reading! Wishing you a very happy holidays and a wonderful 2022 :^)

- Alessia

January

After a trip to Warehouse Wines & Spirits at 8th and Broadway (for drinkable champagne in vast quantities), Carla and I hosted a NYE party with friends in Brooklyn. The next morning, we exchanged the rings we'd both been not-so-secretly harboring and got engaged.

We were excited to tell our families, but first we had a trip lined up: after reaching a five year work anniversary, I was eligible for a four week sabbatical. On January 16, we headed to JFK en route to Tokyo via Beijing.

Beijing

We were flying via Beijing both ways and had ambitious plans for our two 24hr layovers.

We landed the evening of the 17th, obtained our temporary tourist visas and headed to our hotel. Initially, we thought we'd hop on a bus to the Great Wall, but this was the shorter of our two layovers and the jet lag was already hitting us. We figured we'd save that day trip for the way home...

Tokyo

We arrived in Tokyo on my 29th birthday the following day, tired and vibrating with excitement. Carla's cousin Joseph has lived in the city for the last seven years and graciously serves as tour guide/karaoke buddy for family traveling through Japan.

He is now also one of just a handful of people who have witnessed my rendition of Pour que tu m'aimes encore -- I was pleased to find the largest catalog of Celine Dion's French music I've seen outside of Québec.

I won't attempt to recap our whole trip: we bought Japan Rail passes and got to experience the unmatched convenience + punctuality of the Shinkansen while visiting Kyoto, Hiroshima, Hakone, Niseko, Sapporo and more over the course of two weeks. We met so many friendly people along the way, narrowly making it back via Hawai'i as the US borders closed to non-citizens who had visited China in the previous two weeks: on our date of re-entry, our initial Beijing layover was 16 days prior.

We didn't get to see the Great Wall, but we had two days in Honolulu we weren't planning for -- two rather than one due to a time zone mix-up. Best mistake ever!

In February, I squeezed in a trip to SF, a conference (the first ever WebAssembly Summit!) and managed to visit both family and friends back home in Toronto, celebrating a close friend's impending nuptials at her bachelorette in Prince Edward County. 2020 was off to a strong start.

New job, a fire and a wedding

The first few terrifying weeks of lockdown in NYC began mid-March, followed by an apartment fire at the end of May which started in our next door neighbour's yard and woke us to an apartment filled with thick smoke.

Everyone made it out unscathed, thankfully. The fire came just two weeks after I started a new job which added to the stress of being uprooted -- all told we were out of our apartment for four months. I'm extremely grateful for the support my team gave me in the weeks that followed.

Project Cupid

By July, with no end to the pandemic in sight, Carla and I decided to use the reservation we'd made as a hedge with New York State's Project Cupid to obtain a marriage license via Zoom.

Once we'd gotten the license -- issued by a bureaucrat via DocuSign -- we only needed 1. a minister registered with the city and state to perform Zoom weddings and 2. at least one witness physically located in New York state. We were lucky to find Reverend Annie online and called on our friends Nicole and Josh.

We were spread across Queens and Brooklyn, all except Rev. Annie who performed the virtual ceremony from the West Village. The paperwork is filed in the officiant's borough, so we were officially married in Manhattan on July 31, 2020. 🎉

Fresh air

We headed north to the Adirondacks in August where we mostly hiked, swam in lakes, worked and roasted marshmallows.

Year's end

The end of the year has been a blur, not unlike the rest. We're grateful for family and friends with whom we've tried to remain connected, despite great distance and difficulty. Sending warm wishes to you, reader, wherever you are this holiday season.

- Alessia

The best advice I've heard on the topic of coming up with ideas for technical blog posts was from Write/Speak/Code MC Angie Jones at the 2018 conference.

Quick plug for Write/Speak/Code: it's one of the best conferences I've been to! It's a conference for technologists with marginalized genders; if that describes you, I recommend you check it out.

The genius of the conference is that it mixes professional development talks and panels with hands-on workshops. You hear from experts like Angie, someone who has maintained a popular technical blog for years, get some tips on how to get started and then you do the thing: in this case, you start writing a blog post and workshopping it with peers in the room. I can't overstate what a great experience it was.

The Blog Post Ideas Hidden in Your Browser History

To come up with ideas for material, Angie said we only needed to look as far as our browser histories. We're all experts in our experiences: that means we don't need to wait for an earth-shattering revelation to get writing. We just need to pick the last thing that stumped us and drove us down a Stack Overflow rabbit hole or sent us trawling through piles of closed GitHub issues to find a topic we can shed some light on. (That is, assuming we've already come out on the other side. If not: we've got this, the answer is probably one extremely specific search query away.)

If nothing else, she noted, her blog posts often helped Future Angie who would sometimes find herself facing the same issue years later only to come across a blog post she'd written!

It is in that spirit--of helping Future Alessia--that I'm writing this post.

Back to Web Workers

I found myself reaching for a Web Worker recently. I was building some data vizualizations from raw CSVs, and in building the prototype I had to do a bunch of data wrangling, committing various JavaScript crimes in the process. Long story short, I introduced some significant lag on page load.

The computations I was doing were perfectly suited to happen off of the browser's main thread, so as not to interfere with the other graphs I needed to start rendering. Web Workers to the rescue!

I was working on a Gatsby site and a quick search revealed, indeed, there's a loader plugin for that: gatsby-plugin-workerize-loader. It doesn't do anything too fancy, just adds workerize-loader to your Webpack config and injects the worker scripts in gatsby-ssr.js.

The plugin docs demonstrate how to write a worker file with the expected suffix .worker.js in which you export your async function(s):

export async function generateSeries(data) {
  const series = []
  for (const [key, value] of Object.entries(data)) {
    // do expensive calculations
  }
  return series
}

Then, in another file—something the docs refer to as a "source file"—you can import and instantiate the Web Worker. (They only work in the browser, so in a Gatsby project you have to check that the window object is defined.)

import DataWorker from './computeData.worker.js'
const dataWorker = typeof window === 'object' && new DataWorker()
export default dataWorker

Web Workers + TS

In the docs, the example source file that imports the worker and instantiates it is a JavaScript file, but I happened to be working in a TypeScript project, so I gave it the .ts extension.

At this point, I knew I'd have to add some types for the functions my worker is exporting. After flipping through some docs, I added a sibling declaration file, computeData.worker.d.ts, and declared a class that extends TypeScript's built-in Worker interface. It just needs a constructor and the type definitions for the functions I'm exporting, which return Promises.

Put it all together and you've got:

declare class ComputeDataWebWorker extends Worker {
  constructor()
 
  generateSeries(data: {
    [key: string]: number
  }): Promise<{ name: AnalysisYears; data: number[] }[]>
 
  sumDailyTotals(
    data: Point[],
    column: 'Demand__MW_' | 'Net_Generation__MW_',
  ): Promise<{ [key: string]: number }>
}
 
export default ComputeDataWebWorker

Ta da 🌼 Type-safe Web Workers in your Gatsby app.

Law of the Instrument: "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." - Abraham Maslow, 1966

The Problem

Back in August, I was looking to generate some Open Graph images for blog posts I was publishing to this very Gatsby site (as in the photos that appear when one of my posts is shared in most social apps). The idea is simple: take each post's metadata and create images containing some text (title, author, site name) at build time.

I had some requirements in mind: I wanted to supply a custom font, and if that wasn't possible, at least use a monospace font (for the personal #brand). A custom background image would be a bonus.

I couldn't find an existing solution that met these requirements, so I set out to build my own. Some interesting constraints led me to Rust and WebAssembly, though I also admittedly found myself holding a Rust-and-Wasm-shaped hammer after working with both technologies to build an interactive web app at RC.

Why WebAssembly?

The prior art for Open Graph image generator plugins in the Gatsby space consists mainly of gatsby-remark-social-cards. I came across some other approaches that involve writing bespoke code to achieve more complex layouts by rendering some HTML on the server and using Puppeteer to take screenshots, but these felt too heavy-handed for my use case.

After taking a look through the README, gatsby-remark-social-cards fit all my criteria except for the font (it only supports DejaVuSansCondensed). This is for a purely practical reason: the main library for image processing in Node.js with zero native dependencies is jimp. And jimp only supports bitmap fonts.

Bitmap Fonts

Bitmap fonts are comprised of a matrix of pixels, so they can't be scaled or styled like vector/"scalable" fonts (think TTF/OTF). In practice, this means a standalone font file is needed for every combination of font size, color and weight. Indeed, the plugin I was examining had a /fonts folder containing twenty different .fnt files for a single typeface styled twenty different ways 😲

Aside: Netlify Build Image

I generate this site with Netlify and its build image includes native dependencies graphicsmagick and imagemagick, so I could have used a Node library like gm to render text in the vector font of my choice. I didn't want one of my Gatsby plugin's dependencies to require native dependencies, however, even if it would work out of the box for me and other Netlify users.

Alas, I was back at square one: jimp + bitmap fonts. The thought of having to download a program to generate a bitmap font file for every text style I wanted to try was deeply unappealing, not to mention the lack of configurability for users of my plugin, the very problem that set me down this path in the first place... There had to be a better way™️ Which brings us back to Rust+WebAssembly.

Step 1: Write Rust

I've been learning Rust on and off over the past year, and while I'm familiar with many aspects of the language, though still a relative beginner, I knew exactly nothing about low level text layout when starting this project. I picked a crate (synonymous with "library" or "package" in other languages) that seemed to handle my use case called fonterator, grabbed the example code from the docs and used this template to spin up a Rust + Wasm project with wasm-pack.

The fonterator demo uses the crate to render some text in English and Korean and finally calls:

std::fs::write("out.png", out_data).expect("Failed to save image");

std::fs::write is a function in the Rust standard library that writes to a file, as you'd expect. It saved out.png to my machine when I compiled and ran the Rust program locally 🎉

Rust → Wasm

The next step was to annotate my Rust function with #[wasm_bindgen], compile my Rust to WebAssembly and call the function via generated JavaScript interface from my Node script. Nothing else about my code was changing, and if all went well, I'd still get my out.png!

Not so fast:

Error: operation not supported on wasm yet

Oops. When compiling Rust for the wasm32-unknown-unknown target, the Rust standard library can only assume the WebAssembly instruction set, and since Wasm provides no means of doing I/O, these stubs are left to return errors in the standard library.

The Rust and WebAssembly book has a helpful section on how to add Wasm support to a general-purpose Rust crate. The first tip: avoid performing I/O directly 😀

Why is the target called wasm32-unknown-unknown? wasm32 means the address space is 32-bits large, the first unknown refers to the system the code is compiling on, and the second refers to the system being targeted: unknown-unknown implies "compile on almost any machine, run on almost any machine."

Uint8Array All Day

Since I can't perform I/O from my Rust-generated Wasm, I'd have to pass in the font as a Uint8Array and return a Uint8Array buffer of rendered text. The Rust API I settled on looks like this:

#[wasm_bindgen]
pub fn generate_text(
    title: &str,
    author: &str,
    title_font_size: i32,
    subtitle_font_size: i32,
    rgb: JsValue,
    font_style: &str,
    font_file: Uint8Array,
) -> Vec<u8> {
  // ...
}

generate_text takes the strings to be rendered and some config: font sizes, RGB value for text color passed in as a JsValue converted to a Rust tuple and either a string to set the font style using preselected open source fonts or a TTF font as Uint8Array. It then lays out the text, draws the glyphs to a dynamic image backed by a buffer of RGBA pixels and returns a Vec<u8> buffer of pixel data.

Publishing Wasm

Once you're done writing your Rust, publishing your Wasm couldn't be easier: the CLI wasm-pack generates the Wasm module, all the JS glue, TypeScript types and publishes to the npm registry 🤘 I blinked and had published wasm-twitter-card.

Putting It All Together

I could then require my Wasm module and call generate_text like any regular JS function. This is the meat of my Gatsby plugin gatsby-remark-twitter-cards: it uses fs.readFileSync to read a TTF font to a buffer passed to our Wasm code.

const Jimp = require('jimp')
const twitterCard = require('wasm-twitter-card')
 
// utility functions for reading/initializing jimp images
 
module.exports = ({ markdownNode }, config) => {
  const fontToUint8Array = fs.readFileSync(require.resolve(config.fontFile))
  const buffer = twitterCard.generate_text(
    post.title,
    // ...
    fontToUint8Array,
  )
  return Promise.all([generateBackground(), writeTextToCard(buffer)])
    .then(([base, text]) => base.composite(text, 0, 0))
    .then((image) =>
      image
        .writeAsync(output)
        .then(() => console.log('Generated Twitter Card: ', output))
        .catch((err) => err),
    )
    .catch(console.error)
}

I no longer needed to use bitmap fonts, but jimp was the perfect library to stitch everything together. I was amazed at how easy it was: I initialized a Jimp image for the card background from the user-provided image (or created one consisting of a solid color), then called my Wasm function and read the text as a buffer of pixel data into a second Jimp image. Finally, I'd composite the latter over the former, a one-liner with jimp, save the final image and voilà.

Once I saw the result, I was glad I had ventured down this particular rabbit hole!

Missing Glyphs

There were a few bumps along the road, mainly falling into the category of missing or incorrectly rendered glyphs:

After some head scratching, I chalked it up to a bug in fonterator and moved to rusttype as my underlying text rendering crate which fixed things (I would also realize I needed something like glyph_brush_layout to handle layout/text wrapping). I still don't know exactly what the issue with fonterator was, but I received the following thoughtful comment from the folks at the font editor FontForge via Twitter:

I would check the directionality of the glyphs in your image. I noticed that "b" and "p" are OK, yet "d" and "q" are not. I think the problem is that splines which should be clockwise are counter, and those which should be counter are clockwise. Try e.g. "Correct Direction".

I still lack some context here, but I'd love to dig in and try to find the fix. If anyone has any ideas, let me know!

Conclusion

This was a fun and unexpected introduction to solving a real world problem with emerging tech I remain fascinated by.

A few takeaways:

• The partially self-imposed constraints made this more fun! A native dependency-free solution was in the cards after all thanks to WebAssembly.
• The complexity that underlies rendering 2D text to screens is humbling once you scratch the surface. It's too often and too easily taken for granted.
• Rust is a vast language that has introduced me to many new concepts, chief among them the ownership model of memory management. There is a dauntingly long list of language features I have yet to master (lifetimes! turbofish! 😉), but I don't need to master them all to start writing Rust. I can start with the parts I need, and go from there.

2019 was a year of 4 weddings (the fourth and final thanks to an elopement we unwittingly crashed, congrats John & Sara!), 2 gifted wedding eggs (congrats Robin & Mark!), 2 new baby cousins (congrats Jess & Anth and Christina & Zach!), 1 adopted cat and 9 states visited (excluding home state NY that's RI, MA, HI, VA, MD, PA, CA, CT and NJ).

A friend inspired me to write up a few things that happened this year. If you've found your way here, take a minute and join us for a whip around the last 12 months.

Carla, Peter Carlos & Ghost

Since being admitted to the Eastern District's CJA (Criminal Justice Act) panel for federal indigent defense in January, Carla's practice has been growing apace. While running her own law firm and keeping one of the busiest schedules of anyone I know, she nevertheless manages to Citi Bike to midtown most days and care for not one but two small creatures, in addition to me.

Carla continues to earn the title of "Neighbourhood Pied Piper of Adorable Animals": most everyone knows Peter Carlos, the good-natured chicken who walked into Carla's life three years ago and never left. 2019 in turn brought us Ghost, a young cat with white fur and a little grey cap.

Our friend Andrew, a person with far too much idle time on his hands, lovingly built Ghost a cat ladder up to our second story apartment so Ghost could begin to get acquainted with his new home. The ladder was a hit and, so far, it seems he likes what he's found at the top.

Finally, an affable web developer offered to make Carla a new website; in June the new and improved carlasandersonlaw.com came online.

The Bellisarios

Erica and Santino were thrilled to have their three kids along for the ride in Rome this July, in addition to the sixty-odd other kids they were legally responsible for.

Younger brother Luca, ever the peacemaker and overall agreeable Bellisario, had no trouble making new friends in Italy despite the language barrier.

An older gentleman living near our hotel would see Luca on his way to the subway and wave him over for some help navigating Rome's precarious streets. They'd walk together for several blocks until the man would wave Luca off, having arrived at his destination. In Italy as in life, few words, a smile and many wild gestures can go a long way.

In the spring, Luca graduated with a bachelors degree with high distinction from U of T--no small feat says the woman who did a victory lap and still barely got out alive--and began graduate school in the fall, also at U of T.

On January 21, Jessica and Anthony welcomed beautiful baby Giacomo. He is implausibly chill for an infant, setting the bar nice and high for Bellisario babies to come. His arrival, complete with mini Lowry jersey, almost certainly spurred the Raptors to their uncharacteristic championship. We thank Giacomo for all he has done in his first eleven months with us.

For my part, I had the amazing opportunity to join the Recurse Center in April for a mini batch, which is to say I spent a week in downtown Brooklyn among likeminded programmers exploring a language called Rust. I compiled my Rust to Wasm in order to do some neat interactive stuff with the DOM. In other words, I drew a bunch of moving circles on a web page.

I learned a few other useful things this year, too, like how to build a "split" keyboard, how to use a robotic arm called EggBot to programmatically draw on small spherical and egg-shaped objects (namely eggs, see: Peter Carlos) and how to make holiday cards using a solution to the travelling salesman problem.

As the year and decade wind down, I'm eagerly anticipating all the time with loved ones this season affords... especially when those loved ones include three wise, wonderful grandparents who relentlessly pressure me to move home to Toronto ❤️

Sending love to all my friends and family near and far. See you in 2020!

- Alessia

This time, the problem was something that had annoyed me for as long as I'd been employed: resumes. Not the fact of them, or even writing them, necessarily. Just managing different versions.

I was swimming in Dropbox folders with dozens of files saved in various formats; I needed to maintain multiple documents to preserve different iterations, and export PDFs for distribution. Version control was a nightmare.

LaTeX and git to the Rescue

One day I happened upon Daniel Cousineau's resume. Daniel was using a tool I'd heard of but never worked with called LaTeX (a system for generating documents, and not a particularly new one), along with GitHub releases to track his resume's evolution. It seemed promising.

I set up alessbell/resume, rewrote my resume as resume.tex and, back in June, released v1.0 🎉

Wherefore Art GitHub Actions

Having a resume managed in GitHub was a very welcome change, but there were still a few manual steps every time I wanted to cut a release:

1. Draft a new release via GitHub UI. Tag my commit and begin manually creating the release.
2. Manually compile resume.tex and upload the PDF as a release asset. GitHub automatically includes the source code in both zip and tarball formats, but I wanted to include a compiled resume.pdf, too. I'd run pdflatex locally and drag and drop the file, again via GitHub UI.
3. Update the copy of resume.pdf in Gatsby's /static folder. I'd take my new PDF and drag and drop it into my local copy of the codebase for this website, since I want aless.co/resume.pdf to always display the latest version. Then I'd manually commit it and open a PR.

Once I'd isolated the steps that were candidates for automation, I sketched out the ideal workflow: first, automating releases in alessbell/resume, then somehow pinging another repository when a new release was published (?), and finally, the other repository (this blog) would download resume.pdf from the latest release, commit it and open a PR... maybe?

I had no idea how feasible this all was, still knowing little to nothing about the GitHub Actions API. But automating even one step would be a win!

Spoiler Alert

tl;dr my ideal workflow was possible, so I built it 🐙💜

If you'd like to browse the code, steps 1 and 2 are achieved by the main workflow in alessbell/resume. Step 3 is handled by actions in this blog's repository, namely /commit-resume. For a walk-through of the code, keep reading 😎

1. Compile the PDF and Automate Releases

I figured automating the release part would be easy—surely there's already an action for that—but I wasn't so sure about compiling the LaTeX to PDF for inclusion in the release.

Delightfully, both steps turned out to be trivial to implement. I found off-the-shelf actions for both: xu-cheng/latex-action for compiling my LaTeX to PDF and softprops/action-gh-release for creating the GitHub release with the compiled PDF from the previous step attached as an asset.

My first workflow looked like this:

name: Publish new release of resume
on:
  push:
    tags:
      - 'v*.*'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@master
      - name: Compile LaTeX document
        uses: xu-cheng/latex-action@master
        with:
          root_file: resume.tex
      - name: Release
        uses: softprops/action-gh-release@v1
        with:
          files: resume.pdf
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

This workflow runs on any push event targeting tags matching the glob pattern v*.* (docs). The first step, actions/checkout, checks out the repository to the current GitHub workspace so that the workflow can access the contents of your repository.

After that, I can pass the next step the name of my file, resume.tex, and the subsequent step can directly access the compiled resume.pdf from the previous one. In order to author a release, I need to pass in a GITHUB_TOKEN; luckily GitHub already makes certain environment variables available.

2. Ping Another Repository

In order to keep the version of my resume displayed on this website up-to-date, I'd need a way to kick off a new workflow each time I published alessbell/resume.

Luckily, such an event exists: repository_dispatch triggers a webhook event "when you want to trigger a GitHub Actions workflow for activity that happens outside of GitHub," or, in this case, in a different repository's action. A simple curl request with the correct auth token, headers and body does the trick.

This is the whole bash script from alessbell/resume/ping-repo:

#!/bin/bash
main() {
  curl -XPOST -H "Accept: application/vnd.github.everest-preview+json" \
  -H "Content-Type: application/json" \
  -H "Authorization: token ${GITHUB_TOKEN}" \
  "https://api.github.com/repos/${REPO}/dispatches" \
  --data '{"event_type": "update_resume"}'
}
 
main

There were two small caveats here. First, because this POST request is being dispatched for a repository other than the one from the action's execution context, I needed a personal access token with repository scope set as a secret on the repository. I stored my secret as PA_TOKEN and passed it in the way I had the others:

- name: Pings repo
  uses: ./ping-repo
  env:
    GITHUB_TOKEN: ${{ secrets.PA_TOKEN }}
    REPO: alessbell/aless.co

Second, certain events, e.g. push will run on any branch unless the scope is narrowed by specifying a certain branch or tag. When I was testing this repository_dispatch event, however, nothing was happening despite having pushed a workflow to a branch in my blog's repository listening for this exact dispatch event. It wasn't until I pushed the blog's workflow config to master that I saw it spring to life, activated by my Postman request to the /dispatches endpoint.

3. Download New PDF, Open PR

This final step felt like a stretch goal, but it proved to be just enough work for a train ride from Rhode Island to NYC. The first part involves fetching the latest version of alessbell/resume, and GitHub's API has a dedicated endpoint for retrieving information about a repository's latest release:

RELEASES_URL=https://api.github.com/repos/alessbell/resume/releases/latest
 
RES=$(curl -sSL -H "${AUTH_HEADER}" -H "${HEADER}" --user "${GITHUB_ACTOR}" -X GET ${RELEASES_URL})
VERSION=$(echo "${RES}" | jq --raw-output '.tag_name')
PDF_URL="https://github.com/alessbell/resume/releases/download/${VERSION}/resume.pdf"
 
# download resume.pdf and save in /static/resume.pdf
curl -L0 "${PDF_URL}" --output ./static/resume.pdf

Once I had the file downloaded, I'd just need to commit it and open a PR. This time, I'd try to use a pre-existing action with a bit less luck: I wasn't able to integrate vsoch/pull-request-action directly (I'll be the first to say it could have been user error -- when I'm out of my comfort zone, I need to be able to tinker with the code), but reading its source taught me a lot about how to write a similar action that would work for my case.

I wound up with ~90 lines of bash and successfully used jq to process JSON for the first time. There was plenty of trial and error along the way, but once I plugged it all together, it Just Worked.

Writing bash and yaml isn't part of my day job, but it was a lot of fun once I got started; tinkering with GitHub Actions was the perfect excuse to learn something new while scratching an itch.

Is there a workflow you're thinking about automating? I'd be curious to hear about it -- you can ping me on twitter at @alessbell or email me at web[at]bellisar.io.

I was happily a standard issue MacBook keyboard user at the time (pre-2015 redesign, RIP). I'd never typed on anything else. Glancing over at his desk as he set it down, I was the first to pose the question I'd later hear him field a few times a week: ...but where are the letters?

He had chosen a flashy pattern of multicoloured, and crucially, blank keycaps. Something about them was both endearing and an affront. They said: "I'm a confident touch typer making a playful aesthetic choice," and also "if you're not in the club, I am the functional equivalent of a gilded tray of marbles." I was mystified.

WASD

My first mechanical keybord was one I would purchase preassembled: a WASD 87-key "v2" build. It (not coincidentally) also had blank keycaps, though I went with the slightly quieter but still satisfyingly tacticle Cherry MX Brown switches. I was a fast typist, but I found myself hedging: I got my initials in highlighter yellow as a visual anchor 💛

I loved it and used it every day for almost two years. And then I saw the Planck.

Planck OLKB

The Planck looked more like a practical joke than a productivity tool the first time I saw it. Its petite size (40% the size of a typical keyboard) and unusual grid layout ("ortholinear") give the Planck both a strange and satisfyingly symmetrical look.

It was so fundamentally different from every keyboard I'd ever seen that at first I was genuinely confused as to whether it was some kind of art project or if people actually used it to get things done. Frustratingly, this question seemed to have an answer so obvious that no one had wasted their time posting it online, until an internet commenter somewhere assured, no, seriously, they use their Planck at work! That was all I needed.

If you're still wondering about that maybe-fake-sounding term "ortholinear," here's a bit of history from OLKB:

Ortholinear is a semi-made-up word that was originally coined (to my knowledge) by TypeMatrix as "ortho-linear" - this term got concatenated, became popular among the keyboard community, and eventually became the banner for a keyboard company!

The company OLKB (OrthoLinearKeyBoards) sells Plancks in ready-to-build kits; for the most part, you can't get a Planck preassembled. I got mine on Drop and it arrived in a handful of pieces: a PCB (Printed Circuit Board), a single steel plate with holes where the switches would be mounted, an alumninum case to house the finished product, a humble USB cable and a bag of keycaps.

Learn to Solder

I knew I'd have to solder the switches to the board, something I'd never done before. (In the past I'd played around with little hardware projects but was always careful that no soldering was required.) After a bit of research, I picked up:

• the "Blink" Learn to Solder Kit
• a pair of micro wire cutters
• this fan to remove solder fumes
• a now-discontinued $17 soldering iron kit that came with an iron, some solder, and a carrying case

I found the learn to solder kit to be very approachable: it comes with a single small PCB, 3x LEDs, 3x resistors, 3x push button switches and a 3V coin battery and battery holder. I watched a few YouTube videos of people soldering and came across the great Adafruit Guide to Excellent Soldering before I gave it a shot. In about ten minutes, I had turned a pile of loose parts into a tidy row of buttons hooked up to a battery that could summon light from LEDs. 🤯

My first attempt at soldering was passable! I did have one joint I needed to fiddle with, but more importantly, I was becoming comfortable wielding an iron without having to think about a "real" project.

I was ready to try my luck with the Planck PCB. Something I didn't fully appreciate at the time is that it comes with all the components that aren't switches already soldered: resistors, diodes and a microcontroller. And like most boards compatible with Cherry MX-style switches, the Planck's switches are plate mounted, meaning the switch first snaps onto a metal or plastic plate to position it securely before its pins are soldered to the PCB below.

Grid or MIT?

There are two main layouts for the Planck: grid, consisting of 48 keys (4x12), and MIT, consisting of 47 keys (a similar grid, except a single switch is used for the spacebar in the bottom row with an optional stabilizer bar). As I'd read online, the best strategy for soldering plate mounted switches is to pop in the four corner switches, solder those, and then proceed to solder the rest of the board.

I went with the MIT layout, so I had 47 x 2 pins per switch = 94 pins to solder (!). This sounded like a lot, but once I got into a flow state (pun regrettably intended), I blinked and was suddenly done.

All that was left was the task of re-learning how to type! I underestimated how steep the learning curve would be: the default layout is intuitive once you're used to it, but to compensate for the fact of so few physical keys, the Planck has three layers of "keys" in software embedded on the board, also known as firmware. There are "raise" and "lower" keys on either side of the spacebar that allow you to access these layers, mostly consisting of special characters and numbers, via key combinations.

I also came across several mentions of flashing the board, or loading new firmware instructions ("flashing" for "flash memory"), but I was able to bypass what is usually the final step of a keyboard build in this case as the Planck comes pre-flashed with a well-designed standard layout.

After around a year and a half of daily use, I can confirm Plancks are great everyday keyboards. I'm able to switch between staggered and ortholinear layouts with brief periods of slower than normal typing speeds, and since only switch soldering is required, Plancks are also a great introductory soldering project.

After I finished the Planck, my iron began collecting dust... until I discovered split boards. In my next post, I'll describe a slightly more involved build: a Levinson split ortholinear board with, as you might expect, two separate PCBs. To be continued!

RC is often referred to as a "writer's workshop for programmers." In practice, it's a place where programmers go to explore, create and, above all else, learn. There are very few rules (aside from RC's social rules), but one one of my favourite unofficial rules comes from Mary Rose Cook's testimonial:

There is one constraint: work at the edge of your programming capabilities. Which is to say: work on something that makes you a better programmer.

Sounds simple enough! And, actually, RC asks you point blank about what you plan to work on during the application process, so you'd think I'd have it all figured out by now...

As someone who feels most at home wielding browser technologies, I initially pitched an "explorable explanations" project through which I'd examine low level DOM APIs. Truthfully, I needed to meet a self-imposed deadline, and the "what you'll work on" question was the hardest by a factor of 10. Done is better than perfect, etc.

After I got my acceptance email, I started thinking about what I could really use my RC time for. While all of this was rattling around in my head, I came across an impromptu meetup on Twitter: it was around the corner from my office, and the short lineup included Henry Zhu, Paul Irish and Ashley Williams (!!).

Ashley gave a talk on wasm-bindgen (slides) that really resonated with me: she described Rust as the systems programming language for people without a background in systems programming, and mentioned this deep dive post on oxidizing the source-map JavaScript library ("oxidizing" being the term of art for rewriting some code in Rust... Rustaceans love their wordplay).

While I'd heard of Wasm (not web or Assembly!) and Rust, I was missing the larger picture of how they might be leveraged together: rewriting hotpaths from unidiomatic, performance-tuned JS to idiomatic Rust, with wasm-bindgen providing the bindgings for the bridge. Suddenly it was all making much more sense, and just in time for RC :)

I started reading The Rust Book on a recent vacation, and it's one of the best and most accessible technical books I've come across. I'm half way through, and while I'm new to the language, having a JS background makes the possibilities of Rust + Wasm all the more exciting.

In case I was doubting my inclination toward Rust, one of the other soft rules of RC is to embrace serendipity: avoid tunnel vision, and pursue what might otherwise be a passing curiosity. So Rust it is.

Over the next few weeks I'll be posting some of the programs I'm writing, as well as my evolving plans for my project. If any of this is of particular interest, you can drop me a line via email or twitter.

True to startup form, we arrived at a decision quickly. I pinged Christine to let her know I’d love to help: I had mentored at a few Canada Learning Code workshops and was excited at the prospect of coaching a team of young women. Ever the daughter of a high school teacher and a programmer by day, I thought it would be challenging but fun in the way a really good Sudoku puzzle is.

Kickoff: Day 0

On October 24 and 25, 2015, a few dozen young women gathered at Montreal’s La Gare for Technovation’s kickoff hackathon. The students were given a primer on the program’s curriculum, then students and mentors were matched up in the afternoon when the work began in earnest. Christine and I were paired up with five 16-year-olds from an all-girls school in Montreal’s Outremont neighbourhood.

The students had to choose a problem domain right away--they could change it later on--but our team quickly decided on building a tool to aid in the process of finding internships or jobs for teenagers, a time when they’re beginning to make important decisions about pursuing a career they may or may not have already identified. As part of secondaire 4 and 5 (grades 11 and 12), students at their high school were beginning to search for part-time positions. The whole process left something to be desired: most students found placements through their parents’ professional networks which limited the kinds of careers they were exposed to.

One of the first exercises our team completed came from Google’s design sprint methodology: the students were tasked with quickly and independently sketching the six primary screens of their app-to-be. When the timer buzzed, everyone glanced around at each other’s pages. To their amazement, they had all drawn more or less the same screens: a search view with a list of results, a map with pins for local establishments that are hiring, a user profile page, and so on. This came as a pleasant surprise, if not a relief; for a brief moment, their problem seemed to have a straightforward solution. Think Instagram for jobs.

Our students could identify the problem because they observed its effects every day—a stunning 74% of 100 classmates answered “Yes” to the question “Is it stressful to think about your future career?”—but Christine and I could see the challenges in a software solution based on our own experiences navigating career paths.

Finding the job you’re best suited for is a kind of chicken and egg problem: a young person is more likely to express interest in careers that fit the set of skills/strengths she’s developed, but she’s likely cultivated those skills with a short list of potential careers in mind. Sixteen year old me would be shocked that I wound up a developer mostly because I didn’t have a clue what being a developer entailed.

What Does Being a Developer Entail?

For a long time, I thought of programming as a job that is in many ways the exact inverse of teaching. The marginal cost of a piece of software, the cost of every additional copy, approaches zero, so software products can grow to an almost inconceivable scale relatively quickly. With over 1 billion users, Facebook’s continued growth is largely constrained by the number of humans on earth with access to the internet (hence Facebook’s internet-beaming drones). Software’s reach is broad, but thin and ephemeral, I thought.

I knew that teaching in its current state didn't "scale" in the same way, but I hadn't considered that the impact of a talented educator can be as far-reaching as any piece of software.

Take Ms. Mabel Hefty. A fifth grade teacher at Punahou School in Honolulu in the 1970s, Ms. Hefty probably taught several hundred students in her career. One of them happened to be a young person named Barack Obama, who says she was the first person who taught him that he had something to say. Of course, President Obama had other great teachers and mentors throughout his life, though he often cites Ms. Hefty as his favorite. But the more I considered the potential impact of a great educator, the more I thought: if Internet scale is a proxy for impact, Ms. Hefty’s might rival Facebook’s.

Tech companies often talk about nurturing relationships with “users”, but the word itself is revealing. If I deploy a bug to production, I never have to watch a user’s face twist in frustration as they struggle to accomplish a simple task. But when I occasionally mangled the explanation of some technical concept and reflexively asked our students “Does that make sense?”, I had to look on in mild horror as five young people turned my poorly-chosen words over in their heads, vaguely pained and confused.

Teaching is not Sudoku. It’s more like stand-up comedy with higher stakes, where your performance is evaluated every 30 seconds and your score conveyed via the facial expressions of smart young people you want nothing more than to help succeed as much as you possibly can.

Teaching a Programmer to Teach

I knew one thing I'd learned from my dad, a high school English teacher of over thirty years. To him, it's one of the golden rules of teaching and the theme of an excellent TED talk by educator Rita Pierson: "students don't learn from people they don't like." Beyond that, well, I didn’t study computer science or education. I studied philosophy, but early on in the mentoring process I knew with a weirdly visceral certainty that I was the perfect person to be giving five 16-year-olds a crash course in JavaScript’s primitive data types.

The night before our first lesson on git, I spent hours crafting slides that answered all of the questions I was too self-conscious to ask in my earliest programming days. Is there a difference between git and GitHub? How do you combine branches once you’re done building a feature? And what exactly is a branch?

Armed with my deck, a carefully prepared exercise set up in its own repository and an irrational confidence in my ability to convey the particulars of a complex decade-old version control system in under two hours, I was as prepared as I’d ever be.

Once the lesson was underway, and much to my relief, they dug into the material without hesitation. I knew the most important thing was to remove any fear of asking the wrong question, trying the wrong approach, committing the wrong code. Learning in an environment where you feel completely comfortable making mistakes is important for reasons beyond the happiness and well-being of students. It also creates the shortest possible feedback loop, allowing you to adjust and improve with every successive attempt.

In retrospect, the how of Technovation, the way we learned and worked as a team, was probably as critical as the content of the curriculum. Learning and building through iterative processes allows for faster progress.

Survey, Test, Interview, Repeat

And it wasn’t just in the programming portion that we embraced this approach. In order to test certain assumptions the team was making about how best to solve their problem, Christine had the idea of having them implement a “concierge” version of their idea before writing a line of code. Our team went through the motions of manually helping a few classmates land internships and realized it was actually way less straightforward than they’d imagined. Even when they were able to make warm introductions to professionals in fields their classmates were interested in, students were daunted at the prospect of reaching out to a professional they didn’t know.

A large portion of the six months of Techovation were spent this way: survey, test, interview, repeat. After testing our ideas, we realized the importance of two things: 1) that students have the opportunity to interact with professionals of diverse backgrounds, and 2) that students feel comfortable communicating on the platform.

The solution our team arrived at was a digital network in which a high school student has access to school alumni who are organized by industry and students are prompted with helpful conversation starters when they’d like to ask a question of one. Under the hood, it’s a responsive web app built with Meteor (here’s the source code).

This was maybe the most exciting takeaway of Technovation: as programming becomes a tool more and more people use to create, the kinds of software being made will naturally diversify. As our team learned, some of the hardest problems in software are in understanding the needs and aspirations of those you hope to serve.

Postscript

Most people I spoke with about Technovation over the past nine months assumed its goal is to encourage more young women to pursue careers in technology and entrepreneurship. Our team was interviewed by reporters several times—once by Radio-Canada, for example—and the question of career path was a common one. Did they now suddenly have dreams of going into tech? Each time our students politely answered, “Well… maybe!” They’re interested in all kinds of things, from medicine to law to the arts. It’s hard to say when you’re 16.

The more often adults asked the career question, though, the more I realized it’s beside the point. As much as I know that increasing the proportion of marginalized and underrepresented folks in tech is intrinsically valuable and important, I don’t actually have any vested interest in these five smart young women becoming programmers or entrepreneurs. What I do have a vested interest in is that they feel empowered to solve problems they deem interesting and worthy of their time, because that is in all of our interests.

In that way, Technovation isn’t really about technology or innovation at all: it’s about teaching young people (and reminding adults) of the importance of setting your sights on a wildly ambitious objective, even, or maybe especially, when the path to achieving it is unclear. You might not know how you’re going to get there, but you are sure you’re going to figure it out.

This is my attempt to remedy the situation, having recently joined the wonderful team at Breather as a developer. This post is a brief reflection on my time at Bitmaker and what made it the right choice for me, a previously self-taught freelance designer/developer.

Bootcamp or Self-Study?

My answer is secret option C: both.

Throughout my undergraduate degree in philosophy and political science I found myself taking on freelance web design/dev jobs out of sheer enjoyment. The Jessica Hische-ism “procrastiwork” always felt apt: making things on the internet was the work I did when I should have been doing other work. First for my dad's small business and later for freelance clients or politicians I was working for, I would mostly build WordPress sites with themes I could hack in a fairly limited way, or use a no-code site builder like Apple's old iWeb (RIP).

In my final year of university, I got bored of making static pages and copying inscrutable JavaScript plugin code into WordPress, so I signed up for One Month Rails and started learning Ruby at night. This turned out to be a lot more fun but also more difficult than expected: I’d start making meaningful progress only to have my busy school schedule take over.

Weeks later, I’d come back to programming, resigned to repeating lessons I’d already completed and managed to forget. Bitmaker was, for me, the answer to a persistent question: how can I build more interactive and complex things on the web? Many successful developers are self-taught, and this is surely a legitimate path to follow, but for me a bootcamp gave me the time and space to focus on one objective after years of ad hoc self-learning and build a portfolio.

A passion for programming is something I saw in all my classmates, and I think it’s the closest thing to a prerequisite for courses like Bitmaker’s. In the past few years, bootcamps have come to constitute a new category in education, and self-initiated learning is at their core. Your instructors are there to help you, not to convince you to work or reprimand you for skipping your homework three nights in a row. When prospective students ask me for advice, my main suggestion is to make sure they've tried building some simple web pages before sending in an application; it's a low bar, but if you don’t enjoy this much, you surely won’t enjoy doing it for ten hours a day, nine weeks in a row.

As for more granular tips on learning to program, I defer to the definitive post on the topic by Christina Cacioppo. It was written after I finished Bitmaker, but there isn’t a single observation out of place.

Bootcamp Prep

I can share more specific advice on what is and isn’t important while gearing up for the course, however. When I first started making my way through the prep material in May 2014, I found myself gravitating toward blog posts about spaced repetition memorization and other memory hacks. “Flash cards!” I’d think to myself wistfully, “at last, the answer to my problems...” Flash cards can be useful in retaining new material, and there are lots of great free tools like Anki if you’re interested. In retrospect, though, my search for a single unifying approach to learning Ruby was flawed.

When I think about the time I spent exploring different study strategies, one of Ben Horowitz’s famous lessons from his Netscape years comes to mind: there is no silver bullet, only a lot of lead bullets. Learning to build things you’ve never built before is mostly a function of persistence. It’s easy to feel discouraged--I certainly did!--but if you don’t fully grasp a concept today, trust that you’ll get it tomorrow, or the day after that. One day, as it tends to go, you’ll be right. As Christina Cacioppo puts it rather bluntly, “Learning to program requires tenacity, not brilliance. Most professional programming isn’t rocket science, metaphorically or actually.”

It’s not rocket science, but that doesn’t mean it’s not difficult (and it definitely doesn’t mean you won’t struggle). As a student who was used to feeling self-assured in classroom settings studying the humanities and often felt out of my depth at Bitmaker, this is far and away the most valuable lesson I learned: working hard and persisting is its own reward, not simply because trying and failing "builds character" in some abstract sense, but because it’s fundamentally how human cognition works.

As The Khan Academy founder Salman Khan writes in his excellent blog post “The Learning Myth: Why I’ll Never Tell My Son He’s Smart”:

Researchers have known for some time that the brain is like a muscle; that the more you use it, the more it grows. They’ve found that neural connections form and deepen most when we make mistakes doing difficult tasks rather than repeatedly having success with easy ones. What this means is that our intelligence is not fixed, and the best way that we can grow our intelligence is to embrace tasks where we might struggle and fail.

It's OK Good to Fail

At Bitmaker Labs, perhaps more than anything else, you will struggle and fail. That’s what makes it such a fantastic place to learn. While attempting to build Rails apps on my own, I’d make moderate progress, hit a stumbling block I couldn’t overcome, get discouraged and walk away from the computer. Instead, at Bitmaker, after ten or fifteen minutes of struggling on my own--generally the point after which spinning your wheels becomes significantly less productive--I was able to find an instructor to give me the boost I needed to keep going.

As I came to discover, the core feature of a bootcamp is that it accelerates this feedback loop to enable you to fail faster, more often and in the most constructive environment possible. This is terrible for your ego but exceptionally effective where it counts: learning new and difficult things.

Growing up in Copenhagen, DHH loved tinkering with computers and tried to learn programming on three separate occasions. In retrospect, he says, his early, uninspiring attempts at writing software had one important thing in common: each time he had tried and failed, Hansson had encountered programming in the context of computer science. As a teenage gamer and aspiring video game developer, some of his first attempts at programming were in the esoteric language AMOS Basic. There was plenty of math involved and Hansson has the report cards to prove his lack of mathematical aptitude: he was an F student in math and physics, but an A student in English.

Years passed. Closer to the age of 20, Hansson finally learned to program. Just three years later, he invented Ruby on Rails, the open source web application framework I’m learning here at Bitmaker Labs nearly a decade down the line. If your understanding of programming is based largely on the way it’s depicted in popular culture, you may be wondering: how could that possibly be?

Stories like Hansson’s are inconvenient exceptions to many of the storied myths of programming. From the outside looking in, many believe that what all software engineers do is some strain of computer science. Worse still, many programmers wish it were so (Hansson calls this hitting them in their “impostor plexus”). In reality, Hansson says, writing software is less like engineering and more like studying 17th century French poetry: when reading other people’s programs, most of his time is spent wondering “what the f—k did this person mean?”

Point taken, and now that I’ve waded through other people’s code, I can attest to this. The analogy elicits a few chuckles from the audience, but it also succeeds in getting the message across. In DHH’s view, writing software boils down to precisely that: writing. He uses this notion of computer science as a liberal art--a kind of cognitive re-framing of the discipline popularized by Steve Jobs--to further argue that, while there will always be a place for unit testing and optimization, prioritizing metrics ahead of system architecture is fundamentally wrongheaded because it sacrifices sound system design "on the altar of objective science."

As a web developer-in-training, I prefer to view the issue of testing and TDD with a bit more nuance (this is a great piece if you’re interested in the other side of the story), but hearing DHH challenge the computer science paradigm was a much-needed reminder that, despite a lack of formal computer science education, programming is still very much “for me.” This may seem like a trite realization, but as someone who loved studying the humanities in university while maintaining a strong interest in software, it was a relief to hear that the two aren’t mutually exclusive. In fact, they might be more closely related than you think.