Writing from the desk of Henry (From Online)

Dark Forestry

Henry Desroches — Mon, 05 Oct 2026 18:16:54 GMT

Dark Forestry | Henry From Online

Dark Forestry

notes on a new season for technologists

We walk together in an autumnal spruce-fir forest on a crisp mountain morning.

The peaks are yet enwreathed in fog, and the sunlight comes at an uncanny angle through the conifers and aspens. The air is cool and the understory is damp, all but silencing our footfall at the trailhead. The trail is wide and well-trod, but as we make our way up through the woods, the path forward becomes harder to find and follow. The underbrush overgrows, the canopy above weeps heavy yellow leaves and rusty needles, and the pines lift snide roots to catch unwary heels and ankles.

You and I laugh off this encroachment, turning sideways to step between skeletal branches, reassuring each other it’ll clear up soon. Soon the trail will open to a wide open sky, we tell each other, a marshy meadow, a gossipy little snowmelt creek making its way with first-day-of-school nerves down to meet the Colorado River.

But it doesn’t clear up. In fact it grows darker as Douglas Firs grow taller, blocking out the October sunlight. The trees are unkempt, sick with dwarf mistletoe and pine beetle. They lean claustrophobically into each other, and they choke the young trees below out of sun and nutrients and water.

Then all at once we are plunged into darkness. That promised meadow lies unseen, and the trail is lost in every direction, scattered by a lack of care and by relentless, blighted growth.

Well, old friends, I reckon this a new season for us.

We don’t write code anymore, freelance budgets have turned to token spend, our email inboxes are stuffed with letters no one wrote, and our bosses make threats that we use the tech that usurps us or be fired. And the tech is effective — all of our last-season nervous laughter about spicy autocorrect echoes off austere walls as agents write more and better code each day. And what recourse have we? What defense against this onslaught of talking machines? Craft, and “the nobility of a day’s work”, once-proud heraldry against inconsiderate design and careless release cycles, are threadbare banners in winter winds.

Beyond the day-to-day, bright-eyed technologists, come for the promise of creative problem-solving and good salaries, now squint into the unforgiving white glare of this new strange season. We’re not saving the world, rather we’re building the tools to surveil it. We’re training the machines that will come tomorrow to threaten our livelihoods. We sheepishly forgive ourselves daily for transgressions committed obliquely against our neighbors out of what we consider necessity — laboring daily under the maniacal feet of transphobic, racist billionaires, who use the profits we grow for them to subsidize the withering and delitigation of our human and civil rights. Gotta pay the bills.

All the infinite promise of technology is swallowed by the maw of capital’s seething hate of the labor on which it was, for so long, so reluctantly dependent.

And frankly, my optimism for a better fate falters: The organized labor revolution never came. Workers walk a razorwire between rising costs of living and companies with bottomless coffers for legal violence, and for most of us, the risk is too high to try. Protests against the ecological impacts, or the extractive nature of the tooling and the work, or the ultimate impact to labor, are made to individuals — turning our ire against each other instead of the forces that demand we ~~adapt~~ adopt or die. It’s hard to fault people willing to compromise with these tools and their makers: as we’re finding out more than ever before, it doesn’t pay to stand on ethics. Gotta pay the bills.

Higher up the chain, corporations have long abandoned an interest in delivering good products, narcotized in dogged pursuit of short-term profit and quarterly bottom lines. Venture capital props up parasitic mutants that extract subscription fees and dignity from workers in increasingly far-reaching industries. Those misshapen corporations then lurch forward, limping on predatory attention practices, sinister user experiences, and voracious data mining — animated by some twisted hope they might some day be profitable, no matter the cost.

The groundcover of the forest stays woefully damp & fetid in the eternal shade of rotten overgrowth, and healing wildfire never comes.

So what is there to be made of work? For most of us, it’s resignation without resignation — a get-the-bag-and-go-home mindset. It’s just a job. We gotta pay the bills.

It’s self-indulgent of me to not propose another path, to not think critically and tirelessly and synthesize some miraculous Brave Way Forward, but I’m weary too. I’ve got no solutions to offer those who have lost their enthusiasm and creative inertia to white-collar erosion. It’s somehow all connected and totally disconnected, and quite by design there’s no time in the day to make any sense of the whole dizzying machine.

For technology, I don’t think there’s gonna be any going back. The jury is out for other industries, but at least for us computer freaks, especially those at companies well-funded enough to easily weather the changing cost of tokens, I don’t think most will be seeing a future without prompted code. I think there will always be real creatives & sickos in this industry who write amazing things by hand and properly innovate, and there will be prompt-maximalists who gastown their way through the 9-5, and there will always be folks who came here because it’s a paycheck, and find some balance between the two.

As is often the case with these things, the path forward probably lies somewhere in the middle.

Here is what I think I know:

In this new season, the threats to our livelihood loom larger than ever, and so too do the threats we pose to society with our livelihood, as technologists in an increasingly technocratic environment.
As a result of our own work, as a result of the technologies we ourselves developed, it is harder than ever to connect with our fellow worker, with our fellow man, so:
There has never been a better time for us to develop a system of principles and ethics, by which we weigh our decisions. Ultimately, we can be held accountable by no one but ourselves, so it must be us, as individuals, as technologists, who do the holding.
In turn, there has never been a better time to develop a strong sense of empathy for our neighbors. Especially as we come to this system of principled clarity, and — at the risk of appearing too sentimental — we should make room in our hearts for those of us who have not come to the same principles.
In most things, take a stance of harm reduction. Our generation will not be a pure and perfect one. We are all culpable, we are all great works-in-progress, and a bit better is preferable to a perfection that never comes.
As technologists, we must organize our labor. Not only do we deserve it, and not only do we owe it to ourselves, but most of all we owe it to the society that our output — our laggy websites, our UX anti-patterns, our data centers — will be inflicted upon. It is the only chance we have, and the only material impact we can have on our fate and the fate of our neighbors.

And outside of work? How do we shake off the doom of the day? Beats me. Try taking the bus even if it takes a bit longer. Get a library card. Compliment your neighbors and drink iced tea on a park bench. Slow down and make your own days, rather than let them be made for you. We must be intentional, active members of our communities if we are to understand how we can serve them better. I have found I really enjoy reading books by careful thinkers and working on old motorcycles, and you might see if that works for you also.

Today, however, we are having a hard time living because we are so bent on outwitting death.

— Simone de Beauvoir

Thanks for reading. If you liked this, you can find me on my personal websites on Bluesky and Mastodon or reach me via email. If you didn’t like this, I must tell you that you dreamed the whole thing: Henry (from Online) was never real.

As ever, unionize, free Palestine, trans rights are human rights, fix your heart or die.

fin.

go home

I made a Plex server

Henry Desroches — Tue, 14 Jul 2026 18:26:16 GMT

There’s a lot to like about Plex from a philosophical standpoint — it’s local-first software centered around sharing your favorite art with your friends. Plex hosts movies, TV, and music — media you purchase because you love it, and share with your friends because we share media we love with our friends since time immemorial.

I’ve been shaking loose streaming services for the past three or four years, kicking the strident bells of subscription renewal emails back into the grass — I think ownership is important. If I love a book I can keep it on my shelf, but if I love a movie I have to pay $19.99/mo forever and hope that the higher-ups at Poob Streaming Inc. don’t decide to take it down. Plex is a natural answer to the tension between on-shelf ownership and on-line convenience: I purchase movies and I upload them to a server I own, and then I can conveniently share them with folks I love, and those folks can share with me in the same stroke.

Here’s how I started hosting my own Plex server.

Hardware

To run Plex the software, you need some hardware to run it on. Many folks will use a cloud service, but paying a new subscription to have someone else’s computer in another data center hold my media is opposed to the goal of paying once to hold a thing I own. I did a bit of research and decided to pick up a network-attached storage (NAS) device from Synology. This would offer a middle-of-the-road affordable home for the server to run on. This solution isn’t super cheap, but it’s also not super expensive.

A NAS is basically just a toaster for hard drives that you staple to your internet router: the DS225+ I chose lets you mount two hard drives of basically any size and connect that storage to the internet. It has a 2.5Gb ethernet port, which is far more bandwidth than my small group of friends would ever use, has a decent operating system, and doesn’t use too much power. The downsides are chiefly that it only lets you mount two drives (there are variants that are expandable), and it has pretty limited actual CPU and memory capacity (you can expand it), but I was happy with those downsides for my first foray into local server hosting.

I bought the Synology DS225+ and a Seagate 4TB HDD from Micro Center for $500 total — again, you could go more premium or less, depending on your needs and allergies to tinkering.

Server setup

The first step of building the server was to install the drive, which was as simple as mounting the hard drive in the NAS hard drive tray and slotting it back in. This process had an extremely satisfying mechanical reload effect to it and I’d recommend this NAS purely off the kachunk of it all.

Second step was to connect the 2.5GbE port (there are two ethernet ports) to my router.

Thirdly, I followed the setup wizard on find.synology.com, which automatically detects Synology devices and lets you configure them for your RAID preferences, setup the operating system behaviors and user accounts.

After this configuration process was completed, I’m able to visit the operating system (Synology calls it DiskStation Manager/DSM) at the IP address I got back from the wizard.

Folder structure

Next I created a shared folder to keep my Plex libraries (Movies, TV, etc) in. The way the app works is that there is a place where the files that run the server live, and a separate place where the files that are on the server live.

In the Synology OS, Control Panel → Shared Folder → Create gets me a new shared folder, which I called media. In there, I created additional folders for each library Plex should be concerned with:

. 
└── media/ 
	├── Movies/ 
	├── TV/ 
	└── Music/

Once I’ve got the Plex server installed on the NAS, I can point it at these directories, and keep my media files separate.

As a quick important reiteration: Plex Media Server/ in the filesystem is not where media lives. One needs to upload media to the dedicated library folders created.

Installing Plex

In the Synology OS, I went to the Package Center and installed Plex Media Server, which is conveniently a first-class package for Synology.

Once launched, I viewed the server setup screen at port :32400 on my NAS IP — the previous screenshot shows that the Plex URL would be 10.0.0.200:32400. The Plex setup is fairly straightforward, creating libraries like Movies or Music and pointing them at the correct folders.

Also important to note, when configuring the Plex transcoding preferences, the DS225+ off the shelf does not have a ton of power for this kind of thing. I would recommend erring on the side of being kind to the CPU and scheduled transcoding tasks.

Once the server is up-and-running, you’ll be able to access it as a user (instead of a server admin) by visiting app.plex.tv/desktop.

Adding media

On my Mac laptop and my Windows workhorse PC, I added the NAS as a filesystem target so I could move files onto it.

On Windows

It’s called “mapping a network drive” on Windows — File Explorer → More ⋯ → Map network drive, and then set the network address to the network of the NAS.

On MacOS

On a Mac it’s called “Connect to Server” in Finder: Finder → Go → Connect to Server, and then smb:${WHATEVER_THE_NAS_IP_IS}.

Then it was as simple as moving the media files I own off my personal computers and into the NAS filesystem. I’ve learned through trial and error and a lot of jank that names are very important and useful to the Plex ecosystem. They’ve got some strong guidance on their blog for naming and organizing:

Granting access to the Plex library

Now for the sharing with friends aspect. In your server under the extra items menu, there’s a Grant Access… option. You can add your friends by their Plex emails.

One thing to note here is that folks can setup their personal Plex dashboard however they want. Plex the app has some rentals and Live TV, and we found a bit of friction with some users who didn’t realize you could pin our hosted server libraries.

Granting access to the NAS

To let my friends upload their own files, I used Synology’s QuickConnect service, which lets me configure a URL that folks can log in with. This is a tiny bit of a hassle but in a trusted network of friends it works great.

I created a user account for visitors on the NAS itself (not on the Plex dashboard) via Control Panel → User & Group, and gave the user access to the shared media/ folder.

Then after configuring QuickConnect through Control Panel → QuickConnect, I had a URL (something like https://quickconnect.to/true-terrors-nas) which would allow my friends to visit, log in as the NAS user account, and upload files in the Synology File Station.

Going further

Since setting up the server, I’ve made some changes.

Expanding the RAM

The DS225+ has like 2GB of RAM off the rip, which is tremendously bad, and I found that the NAS was crashing the second I uploaded a full season of TV (from Plex trying to identify the intro and credits sections). The NAS has a single expansion slot, and I added an 8GB card, which improved the responsiveness of everything immediately.

Important to note that Synology has very strict rules about which RAM you can use, and using a non-approved RAM module will void your warranty. The linked module is not approved but has more memory capacity than the approved modules.

Adding transcoding drivers

The DS225+ actually does have an integrated graphics processing unit, but Synology removed hardware transcoding drivers for some reason. Someone added the necessary modules for adding those drivers back, and I would recommend installing those. You can read more about improving that transcoding functionality on GitHub.

Plex Pass

Plex actually does charge users to use features like skipping intros/credits, downloading media offline, and manage additional server settings. They do unfortunately offer this as a subscription, but they also offer it as a lifetime buy-once pass. When I bought the lifetime Plex Pass it was literally $500 cheaper than it apparently is now, which to me sounds absurd, and I’d be interested to hear if anyone’s found a better route.

Additional pieces

You can host tools like Seerr and additionally the Servarr stack on your NAS via Docker, to allow users to discover, request, and source additional media. This is tentative territory and if you go, go with caution and with care.

I also built a Discord bot that leverages Plex webhooks to notify folks in Discord when media they’ve requested via Seerr is available.

Anyway that’s all for me for this one. As ever, if anything’s unclear, or if I can answer any questions, feel free to reach out to me via email or on Bluesky.

It doesn’t matter if it works

Henry Desroches — Mon, 08 Jun 2026 12:04:00 GMT

There are about a thousand and one debates about the ecology of AI, the ethics of AI, the governance of AI. As the technology advances, the debate with the slipperiest footing is on the actual efficacy of AI: does this work for this application? Or for this one? Ultimately, whether LLMs “work” as a technology or not doesn’t matter. The function of a system is its output, and no matter what utility individuals find in the tech, the widespread adoption and deployment should be considered and regarded firstly as a threat to the labor force.

To illustrate, we’ll consider a few scenarios.

This is a short preface to a larger piece I’m working on called The Threat, which covers AI mandates at work, harm reduction in the use of LLMs, and long-term strategies as industries expand their adoption of this technology.

AI works

O, great miracle — the tech advances! It will soon be as good or better per dollar than its human equivalent. Under the current economic system, there exists no incentive for corporations to keep those human equivalents employed. Humans necessitate sticky conversations about benefits, work hours, protections, and accountability that AI frankly does not. What happens to those jobs?

AI proponents often compare the advent of the tech to the Industrial Revolution — many jobs were lost as industries were completely refactored and destroyed by these technologies, like we expect AI to, they say, but as you can clearly see, humans are still here, working now in different or differently-shaped industries. Those jobs are considered unfortunate collateral in a necessary technological reshuffling of the labor market.

But the buried lede of the Industrial Revolution comparison is that the revolution didn’t simply exchange some jobs for others. It developed a new capitalist system of labor de-skilling. De-skilling extracts the knowledge of design, craft, and mastery from high-skill workers and replaces those craftsperson type roles with new types of less-skilled and more-specialized roles. Those increasingly specific roles, in increasingly complex systems, meant that the average level of wide conceptual understanding of each worker was reduced, resulting in concentrated power of the managerial class.

As the average skill level of a worker goes down, the easier it becomes for capitalists to control a labor force. If a worker can be easily replaced, there is no justification to pay that worker high wages, or ultimately to keep that worker employed.

In this future where LLMs really are the be-all end-all many techno-optimists purport them to be, they will expand to wider and wider industries. Benefitting from narrowed and more specific job requirements, they will capture more roles, automate and de-skill more industries, and result in a widespread lowering of wages, job security, and employment.

And while those tech leaders on the optimistic far end of the axis pretend to believe this will open doors for some utopia where mankind does not work, it is plain to see the dishonesty of this when looking at how those tech leaders treat humans of any class lower than theirs, be it in their brutal mass layoffs of white collar workers, or the criminalization of homeless folks.

AI doesn’t work

The second scenario is that AI is not nearly as effective or useful in replacing labor as it is lauded to be. In this scenario, the explanation for these mass layoffs by Amazon, Atlassian, Autodesk, Block, Cisco, Coinbase, Dell, Dropbox, Fiverr, Goldman Sachs, Google, Grammarly, HP, IBM, Intel, Intuit, Klarna, Meta, Microsoft, Nike, Oracle, PayPal, Pinterest, Salesforce, TikTok, UPS, Unity, YouTube, et al, is that AI is merely the foil by which companies can cover up all manner of business failings or strategies.

The problem now is that, because there are scant worker protections (especially in the US), the onus to prove any claims about AI efficiencies does not exist. Businesses are enabled to use the magic spectre of AI to justify an any% RIF and spin great successes out of their operational failures.

However, while this is likely at least a contributor to the layoffs sweeping the technology and finance industries, it does not account for the massive scale of the cuts we’re seeing in this industry. Instead, these cuts must be lensed by class. Whether they mean to or not, owners of capital have exceptional class solidarity, because they have the shared goal of reducing the cost of labor. This, then, explains mass layoffs attributed to a technology like LLMs, regardless of actual LLM “productivity gains”: If the technology causing all the layoffs does not actually replace workers, then the workers will need to be rehired. Herein likes the rub — if large portions of the workforce have just spent 6 months or a year searching for jobs in an extremely employer-favored labor market, workers will take what work is available, and as a result wages, role quality, and benefits will nosedive.

The material outcomes

Both of these scenarios result in the same outcome: reduced worker solidarity, reduced worker skill, and reduced worker wages. AI/LLMs are the perfect tool for the capitalist because it doesn’t matter if it works; it threatens the workforce either way.

There exists precedent for this type of threat in the practice of “offshoring”, where companies move work to markets with cheaper labor and make layoffs in more expensive markets. Whether or not this move is useful can obviously vary widely as there are many variables to offshoring, but that companies consider it a tool, that it can happen at any time to large groups of workers is its functional impact.

Furthermore, because it weakens the local labor market and the bargaining power of labor, offshoring, like AI, creates an incentive for companies to position workers to be more easily replaced, through de-skilling and other strategies.

Eat the frame

The widespread deployment of AI/LLMs constitutes an existential threat to labor whether or not it is an adept move by the adoptive industries. Thus it is essential for workers to stop asking whether or not AI works and start asking who ultimately benefits from its deployment.

The answer to that question is capitalists, who have a persistent vested interest in weakening the labor market. Consequently it is imperative for workers to join forces in defense of their work, whether or not they are optimistic about LLMs as a technology. If a functional future of AI is realized, labor must be strong enough to withstand its seismic effects. If the brilliant AI future never dawns, labor must be strong enough to survive the ramifications of all of these companies making existential threats.

This means of course both bargaining for protections against successful widespread automation of the workforce, but protection against widespread automation as pretext.

Throughout history, workers have proven that when they stand together, they take control of their fate and the fate of their industries. You deserve a tech union.

The first thing I did last year was run

Henry Desroches — Wed, 07 Jan 2026 09:00:00 GMT

The first thing I did last year was run | Henry From Online

The first thing I did last year was run.

00:00:00:00

I found myself on the eve of the new year lying restlessly on the floor of my apartment (on this great Mashhad rug from like 1937 which is ornate and beautiful, and for which I negotiated a blood-curdlingly screaming deal on a few years back, but which of course has nothing to do with this story). Most of my friends were taking the year off hosting; I didn’t want to go out for the evening and sit in cold traffic around Denver to cheers with strangers, and I would be damned if I’d start my grand adventurous year with a story of staying home.

So I grabbed the keys.

A quick maps search showed if I left my house at 10pm, I could arrive at the foot of the Rocky Mountain Grand Tetons range, at an old beautiful building called Moulton Barn, exactly at sunrise. I’d spend the dawn of the year on an adventure, watching the furious red of the first sun of 2025 summit the peaks, while I drank hot coffee and The Rest Of My Life began.

I put on a hoodie and a light leather jacket (Vegan, thanks for asking, and yes I am thanks for asking), somehow completely certain that the weather — at the beginning of January in rural Wyoming — would be warm enough for such an outfit, and I hopped in the car at 10pm. The moment I was free of the tangled interstate interchanges of Denver, the roads were completely clear, just me and the ever-present solemn semi-trucks. I could not believe my luck, and did not for a single moment consider that perhaps there was some great and obvious reason why no one else had decided to drive to the Western wilderness at 10pm on New Year’s Eve. I crossed the border out of Colorado at about 11:30 with a face so smug it would’ve gotten me convicted of crimes I was completely innocent of.

Google Maps had offered a scenic route, which when plotting my adventure at 3pm I included without a second thought — Well, let’s see about it, I mused. What wonders will I be privy to on the road less traveled? Surely this will make all the difference.

I had my second thought now, 30 miles into a wily and curving B-road, that perhaps sunlight would’ve improved the actual scenic qualities of the route some. I drove through countless towns in the pitch dark, towns with charming names like Virginia Dale and Tie Siding. I did not see a single one of them.

My first gas stop was at a truck station shortly after the Wyoming border, somewhere near Laramie. I picked up a little snack and an energy drink — I had never had a Red Bull before but I’ve seen what it does to some of you freaks, and that suited me fine for an overnight drive in freezing dark. I fueled the car while regarding the row of 30 semi cabs, which shivered from their idling engines and squinted suspiciously at me with glaring headlights from across the parking lot. I doffed my hat politely at the assembly and resumed.

At around 2:30 in the morning, after many hours of wide-eyed abyssal staring along Highway 287 and then I-80, and then 287 again, and after many hours of an audiobook recording of Wuthering Heights narrated by someone who had only had a Northern accent ever loosely described to them, I hit a wall. I felt like my neck would fall off my shoulders at the sheer weight of my gigantic head, which I had somehow only now become aware of. I parked the car to nap — I did plan for this eventuality, and did quite sensibly have a paper-thin blanket folded at-the-ready in the passenger seat.

It is here I should mention my car is a 30-year-old rear-wheel-drive German car, and the part that is important is that it is 30 years old. I woke with a phone alarm to a very, very cold car, which I had parked with the engine off on the side of a highway in 0ºF weather (or -18ºC, had this story taken place outside of the United States), to let cool for half an hour. I restarted the engine to get back on the road, and a while after pulling back off the shoulder, I realized, with my honed shrewdness and near superhuman situational awareness, that it wasn’t getting any warmer. Bleary-eyed and with hands gone completely white from the cold, I turned to the fourth wall with an infuriating “it’s a living” sort of expression. I donned gloves and wrapped the blanket tightly around my waist and legs, and ~~quite idiotically~~ quite bravely persisted.

It is here I should mention again that my car is a 30-year-old rear-wheel-drive German car, and the part that is important here is that it is rear-wheel-drive. And before you start looking at me like my mom looks at me when she’s reminded of that: People overreact to road conditions and overestimate the utility of all-wheel drive. Tires are more important for traction in inclement weather than drive ever will be, and besides, all-wheel drive does nothing for you when you’re trying to stop. With proper tires, my rear-wheel-drive and a single ounce of common sense has gotten me through frankly surprisingly dramatic weather conditions many a time.

Or at least, that was my ~~heavy cope~~ solemn mantra as the elevation increased towards the continental divide. The mantra, I must admit, grew quite insistent, as the clear but cold roads became lightly-snowpacked roads, and then became heavily-snowpacked roads, and then become a 3" snow track. At exactly the peak of the ascent, the snow on the roads grew to closer to 5 or 6 inches (or 15cm, had the snow fallen on roads outside of the United States), me and the car decided to completely renegotiate our relationship. Until now, I had been confidently commanding it a few degrees left, a few degrees right — whatever the road-going voyage asked of us. But now, a few hours before dawn, we decided together to explore the idea that perhaps the steering wheel was, perhaps, more for suggestions than outright demands. For instance, in this new arrangement, I would not be turning left so much as suggesting we go left, and then when my suggestions were rebutted, I would be slowing the car to 15mph (24km/h, had the slowing etc etc), and then 10mph, and often even 5mph, until my suggestion was taken a bit more seriously.

The two of us went on like this for the next many miles, from Dubois down into the approach to the Grand Teton gates. As the elevation decreased, the snow subsided, and the car let me take over most of the steering again. Rather inequitably, the car did not use its newfound free time and focus to go about fixing the heater issue.

It was still very dark, but the growing blue saturation of the sky told me dawn was approaching (the LCD clock on the dashboard also told me, but mostly the blue told me. I am by nature very in tune with the different levels of blue in the sky at different times of night and that should be noted). I entered the park, turned down the road to get to Moulton, and the smug expression came back with a vengeance. I had done it! Oh, what fools all my peers back in their comfy homes must feel — I was a great champion, of the road, and of the elements. I was starting the New Year on a proper adventure, facing down countless odds to watch the sun rise against one of the American West’s greatest views. I became so engrossed with regaling myself, preening over my own glorious victory, that I almost did not react in time for the road abruptly ending.

As it turns out, most of Grand Teton National Park shuts down between November and April. As it further turns out, that includes the discontinuation of maintenance for many of the roads. So here, 2.5 miles from my destination, instead of a red carpet and crowd of wild animals assembled to cheer my arrival, I faced an 8ft snowbank, which completely blocked the path to the barn.

I blinked dumbly at the wall before me for at least 11 minutes, before furrowing my brow and stepping out of the car. I entertained very briefly the idea of scrambling over the snowbank and hiking the remaining miles to the barn, but that idea was extinguished when my first step onto the snowbank became my first step in to the snowbank, and I realized I’d have to try something else.

I elected to drive over to Jenny Lake, a popular destination that I expected would still be plowed. It would be much closer to the mountains, but in my current circumstances I was happy to see what there was to see.

Back in the car and heading back down Gros Ventre Road the way I came, it started to become clear that “what there was to see” was also a rapidly-narrowing margin. It was now 7:30 in the morning, and the sun was just starting to illuminate the landscape, though it remained beyond the horizon. As if in a silly tablecloth magic trick, the dawn of January 1st, after a perfectly clear night, exchanged the impenetrable cover of darkness for an even more impenetrable cover of blizzard.

I had driven 9 and a half hours into the wilderness of Wyoming to look at a snow fog so thick I couldn’t see the shoulder on the other side of the road.

I went back to blinking dumbly, this time for a longer increment, to really savor the dumbness of the blinks, the sheer idiotic heft of the eyelids, the stupid clapping noise they made. Once I had blinked to my satisfaction, I started up the car, again, and pointed it dejectedly in the direction of the nearest town, Jackson, where I parked at one of the many visitor centers, and fell instantly to sleep.

Ninety minutes’ rest hardly refreshed my weary and frozen bones. I got up to go snag a parks sticker from inside the center, to find by rattling helplessly on its front doors, that it was one of the many visitors centers that closes in that six month window from November into Spring. I went and sat fully on my ass in the snowy parking lot, and blinked some more.

There’s a delightful little bakery & restaurant in Jackson called The Bunnery, where they’ll serve you oatmeal with berries, and a cup of coffee so bad you’ll worry you offended someone on the way in. I know this because I went there and I had both of these things, and I tipped very well as a profuse apology for however I had scorned the waiter.

Back in the car, I reviewed my options. Park: closed, trails: unmaintained, snowshoes: not owned, sunrise: unwitnessed. As the LCD screen ticked up to 10 am, I turned the ignition for the last time, and started driving home.

The daylight drive of return was beautiful. A couple of stressful moments where the blizzard raged its hardest, but mostly it was peace. Snaking patterns of drift over the asphalt, volumetric beams intermittently reaching the road like the sideways glances of god, an ice-covered river caught halfway between polar blue and seafoam green in the rare bright light that filtered down through the storm. Once I was out of the Rockies again and onto the plains, the storm cleared, and in that great, yawning, too-big Wyoming sky I saw the first morning of the year. I kept the stereo silent, and I drove with a steady foot. I felt my manic energy of the night before (and if I may be candid with you, now that I consider us old friends, from the months before) — melt away from me as the snow slipped off the roof and hood of the car.

By the time I got back to Colorado, the sun had crested its wintertime noon and was starting to set once more. I called an old friend on the phone and we talked about love and our awful taste in men and the way friendships change with distance and our grand plans for 2025.

I pulled into my garage. I sat there in the salt-blasted, filthy and weary car, and as I lazily shook loose half-daze from 16 hours of tense driving since the night before, the dashboard vents started blasting hot air.

❦

Thanks for reading. Drive safe. Click here to go back to the blog.

Things I did in 2025 that have nothing to do with the internet

Henry Desroches — Sat, 03 Jan 2026 15:03:00 GMT

What I did

Did not buy any new clothing, save for DIY band merch. (I love fashion, and I did shop! I just only shopped vintage. It made it a really fun adventure, it turned every desire from a whim into a quest.)
Switched off Spotify to Tidal.
Started an earnest movement towards a diet of physical media only.
Stayed vegan for my 8th year, for the animals and for the Earth.

January

Drove to the wilderness of Wyoming on a whim on New Year’s Eve.
Put my car onto Öhlins Road & Track coils and a sport exhaust, holy smokes what a perfect car.
Rode my motorcycle in below-freezing weather for the first time.
Went to London on a whim (~24 hours from decision made to flight touch down) with my best friend, just to eat good, see some wonderful theater, and meet another strange website person, who would rapidly also become one of my best friends in the world. Saw some great designer motorcycles, saw some art galleries, saw Starlight Express and The Tempest.

February

Rewired my 1975 BMW R90/6, a 50-year-old motorcycle, completely from scratch, with the help of the incredible vintage BMW motorcycle community in Denver.
Watched Pride & Prejudice twice on Valentine’s Day.
Went to a few fantastic runway shows for Denver Fashion Week, and some really painfully middling ones.
Went to Chicago ~~(for work)~~, to New York City (for a deep love of the city), to San Francisco ~~(for work)~~, to New York City (see previous New York City trip rationale).

March

Fucked up a simple oil change on my BMW motorcycle so bad that my mechanic for an unrelated issue threatened me with a gun.

The mechanic didn’t do that btw, he just sent a “who did the last oil change on this” text. That’s a bit of “lying” for you

Apparently this is fr all I did this month. Rode motorcycles a lot, drove cars a lot.

April

Turned 30. It was fine, most folks are just weirdly scared of their own mortality. Not me. I’m normal about it.
Went to Portland to see about the city and try out the Web Dev Challenge with my friend Jacky. Got to meet a bunch of internet friends.
Back to New York baby New York City babey it’s all about the Mets.
Had a little local reunion show with my old emo band. Someone showed us the tattoo they got from our music.

Boy I really only took pictures of motor vehicles this year, huh.

May

Went to Leeds with bestie again, this time for All Day Hey, and to see my friends — some of whom would even be speaking. Went to London after, to hit Ronnie Scott’s with some devious co-conspirators and see what Soho has to offer.
Went over Echo Lake (elev. 11,000 ft above sea level) on my motorcycle for the first time. Got pizza on the way back to town.
Tried to start a bedroom Goth rock band. Was awful, learned a lot, didn’t stick the landing. Maybe this year!
Found out Olive Garden will sell you literally 100 breadsticks if you want. They give them to you in a big box which will not fit in the luggage of your motorcycle, so you will have to prop them between your knees while riding across town to the movie party you got them for. It will be hysterical and very dangerous for you.

June

Read Rimbaud for the first time.
BACK to New York City babey!!! This time I saw Turnstile and Boy Harsher under a bridge in Brooklyn, ate immensely good food everywhere in town, and got rained out so hard in Central Park that my phone broke and my paperback book literally disintegrated.
Went to Utah to get lost, skydive, shoot guns, drift ATVs, make music, read book after book in the sun, and make & tell stories with beloved friends. Wore a cowboy hat and rode on the outside the Jeep more often than I sat inside the Jeep. Fell out of a plane at 13,000 ft in altitude again, but this time I did a flip or ten.
Did the brakes on my car and shot myself in the eye with one of the pad retaining springs so solidly that it welted.
Celebrated queer pride by reading only queer poets and seeing queer movies, doing queer-only motorcycle rides, and parading in the street.

July

Learned how to roller-skate. Will not be doing that again.
Joined the vintage BMW & Norton ride, just tons and tons of beautiful ancient motorcycles rolling over the foothills of the Colorado Rockies.

August

Did not go to Ren Faire. I know this isn’t like. Groundbreaking for anyone else but the last two years I went literally every weekend it was open during the Summer lol.
Started learning some Irish folk songs, jigs and reels and such, on the guitar!
Helped the BMW Bike Night boys build a 1968 R69US from the frame up
Had my first white Monster. Gotta say, fellas. Mid, very mid.

September

Took my Triumph cafe racer way, way into the mountains, even found some dirt roads I definitely shouldn’t have been on, but it turns out every bike is an adventure bike if you’re not a scaredy-cat.

With the help of a local friend who is also a furniture freak, found a vintage Eames lounge chair in awful condition, and restored and reupholstered it. It’s been a dream for a long time and I managed to sort the whole thing for less than a thousand bucks.
Blew the clutch in my car to pieces. The technician that worked on it texted me to let me know he’d never seen one so torched — he even kept it so we could laugh about it when I picked up the car after replacing it.
Went over Guanella Pass on my BMW airhead to look at Autumn leaves. Every time that bike does any decent mileage or questing, it feels like an achievement for both of us. I’ve brought some immense life back to this bike since getting it, just going through the whole thing and sorting it out. It’s a real source of pride. And to think of the life it has had, from a factory in Germany a literal half-century ago, to nearly 12,000ft above sea level in the Colorado Rockies in 2025.
Made the most of the foliage. I’ve got a few friends who also love more spirited sports driving, and we sought out basically every great curvy road on the Eastern slope in order to see the aspen groves turn to gold.

October

Off to the UK again, this time to Bristol to see my beloved friends and speak about personal websites at Web Dev Conf, which was an immense opportunity I am very grateful for.
And back to New! York! City! Literal one night trip to make the most of a layover back from England.
Ate at Eleven Madison Park, holy smokes one of the most incredible culinary experiences of my life.
YOU GUESSED IT NEW YORK CITY AGAIN! Lola texted me a few months prior about going in Autumn (why does it seem so inviting), so we did. Met Cloisters, dumplings, rain and shine, live jazz, bought some art. Celebrated Halloween in arguably one of the greatest cities in the world to people-watch in. Highly recommend.
While I was in New York I walked for a few hours on the phone with the gal I had been seeing, and the phone call made me smile so hard I realized I wanted nothing more than to make her as happy as she made me. I basically sprinted home to ask her to be my girlfriend.
Ate at Brutø with now-gf. What an unreal restaurant, and what a miraculous tribute to Coloradan agriculture.
Carved pumpkins. Do you like him. Do you think he’s nice.

November

Hit 50,000 miles on the BMW in its 50th year of life at 12,000ft. Hit ice and snow patches on the way back that were so serious I had my feet down just sliding down the road. What is life if not near-death!
Got into archery. Turns out those elves were on to something in that one movie.
Entered my cafe racer into its first motorcycle show, won best bike in show and even won the rev competition (the Triumph shoots flames when you rev it so it was hardly a competition 😉)
Started building a bike from 1974 with the Bike Night boys for the Bike Relief Project, which donates motorcycles to vets to help with PTSD.
Got a tape deck solely off the dream of putting this song on a mixtape I’d make for the girl I was seeing. I got her a restored vintage '80s Walkman to listen to it on. Typed up a love note for the liner on a Hermes Baby typewriter from like 1941.
Celebrated Thanksgiving down South with my parents and grandparents.
Flew straight from there to Dublin to celebrate a dear friend’s Big 30th Birthday.

December

More time in Ireland. Beautiful country. Ate spice bag for nearly every meal.
Managed to see Deafheaven in Dublin after a tip-off from a beloved friend who had seen them in England days prior. The show was sold out but the band graciously left a handful of tickets at the door. Portrayal of Guilt opened. It was unreal.
Hibernated most of the month. Spent New Years Eve in the arms of a beautiful woman. What more could any of us hope of December?

What I’ll do now

Stop shopping online.
Rebuild the '74 BMW airhead I’ve been neglecting for a few years.
Continue splitting my time between Colorado and New York.
Deadlift 300lbs.
Road trip on a motorcycle to more National Parks, certainly Glacier and Yellowstone.
Climb three 14ers.
Turn my elementary proficiency in Italian into working proficiency.
Stay vegan for my 9th year, for the animals, and for the earth.

Thanks for reading.

A Website To Destroy All Websites

Henry Desroches — Thu, 01 Jan 2026 12:15:01 GMT

A Website To End All Websites | Henry From Online

A website to destroy all websites.

How to win the war for the soul of the internet and build the Web We Want.

Captive Pegasus, Odilon Redon (1889)

A tiny website by Henry (from Online) ~3100 words; about a 15 minute read

table of contents, of course

part one.

The internet is bad.

Christ’s Descent Into Hell, Follower of Hieronymus Bosch (~1625)

Well, the Internet mostly feels bad these days.

We were given this vast, holy realm of self-discovery and joy and philosophy and community; a thousand thousand acres of digital landscape, on which to grow our forests and grasslands of imagination, plant our gardens of learning, explore the caves of our making. We were given the chance to know anything about anything, to be our own Prometheus, to make wishes and to grant them.

But that’s not what we use the Internet for anymore. These days, instead of using it to make ourselves, most of us are using it to waste ourselves: we’re doom-scrolling brain-rot on the attention-farm, we’re getting slop from the feed.

Instead of turning freely in the HTTP meadows we grow for each other, we go to work: we break our backs at the foundry of algorithmic content as this earnest, naïve, human endeavoring to connect our lives with others is corrupted. Our powerful drive to learn about ourselves, each other, and our world, is broken into scant remnants — hollow, clutching phantasms of Content Creation, speed-cut vertical video, listicle thought-leadership, ragebait and the thread emoji.

it wasn’t always like this.

Pastoral Scene, George Innes (1857)

It used to feel way better to Go Online, and some of us will remember.

We used to be able to learn about our hobbies and interests from hundreds of experts on a wealth of websites whose only shared motivation was their passion. Some of those venerable old educational blogs, forums, and wikis still stand, though most have been bulldozed.

Now, Learning On The Internet often means fighting ads and endless assaults on one’s attention — it means watching part-1-part-2-part-3 short-form video clips, taped together by action movie psychology hacks, narrated gracelessly by TTS AI voices. We’re down from a thousand and one websites to three, and each of those remaining monolith websites is just a soullessly-regurgitated, compression-down-scaled, AI-up-scaled version of the next.

We used to make lasting friendships with folks all over the world on shared interest and good humor.

But now those social networks, once hand-built and hand-tended, vibrant and organic, are unceremoniously swallowed by social media networks, pens built for trapping us and our little piggy attentions, turning us all into clout-chasers & content-creators, and removing us from what meaningful intimacy & community felt like.

Even coding for the web used to be different: One could Learn To Code™ to express oneself creatively, imbue one’s online presence with passion and meaning, and for some of us, build a real career.

These days, however, we write increasing amounts of complicated, unsecure code to express less and less meaning, in order to infinitely generate shareholder value. We don’t think about the art of our craft and the discipline of its application, we think about throughput and scale.

To be very clear: I’m not trying to Good Old Days the internet. None of this is meant to make you feel nostalgic — the Internet used to be slow and less populated and less diverse, and its access was limited to those of a certain class. The Web For All is a marked improvement, widespread global internet access is a marked improvement, and what I’m asking you to consider is what it used to feel like to use these tools, and what we’ve lost in the Big Tech, Web 2.0 and web3 devouring of the ’Net.

part two.

The invention of the automobile

Autoportrait, Tamara de Lempicka (1929)

The onset of the automobile was a revelation for access and personal liberty. With the advent of cars, members of society could travel farther, get more done in their day, and bend their limited time more to their creative will!

But as time wore on and the industrialization & proliferation of the automobile progressed, its marginal utility diminished — the industry started to offer society fewer & fewer benefits, and take more & more in exchange1.

In American cities, for example: though at first the automobile enabled humans to travel further distances, it now demanded that humans travel those distances, and demanded infrastructure be created & maintained to enable it.2 Many now must use an automobile to get everything done in their town in a day, and must pay & take time for that automobile’s fueling & maintenance.3

Further than that, the automobile asks all of us to chip in tax revenue to protect its infrastructure, but only certain classes can afford an automobile with which to use that infrastructure, and those classes who can’t afford to do so are relegated to underfunded public transit systems.4

No longer a tool to serve our societies, our societies now serve the automobile.

part three.

Tools for Conviviality, & the industrialization of the Web.

In his book Tools For Conviviality, technology philosopher and social critic Ivan Illich identifies these two critical moments, the optimistic arrival & the deadening industrialization, as watersheds of technological advent. Tools are first created to enhance our capacities to spend our energy more freely and in turn spend our days more freely, but as their industrialization increases, their manipulation & usurpation of society increases in tow5.

Illich also describes the concept of radical monopoly, which is that point where a technological tool is so dominant that people are excluded from society unless they become its users. We saw this with the automobile, we saw it with the internet, and we even see it with social media.

~~No longer a tool to serve our societies, our societies now serve the automobile.~~ Instead of designing and using tools to build a society, our society changes to adapt to the demands of our tools.

Illich’s thesis allows us to reframe our adoption and use of the technologies in our life. We can map fairly directly most technological developments in the last 100 (or even 200) years to this framework: a net lift, followed by a push to extract value and subsequent insistence upon the technology’s ubiquity:

the textile revolution

The preferred imagery used to mythologize the Industrial Revolution is the woodetchings of textile manufacturers, transformed in the early 19th century by the arrival of automated fabric machinery. Its proponents laud the shift of an agricultural society to a technological one, creating new sectors for labor, and raising up the middle class (we will say nothing of this period’s new punishing conditions for labor in this essay6). But the ultimate ecological and human costs engendered by the increasing availability of cheap fabric production are well-documented: In 2022, the fashion and textile industries employed around 60 million factory workers worldwide7, and less than 2% of those workers earn a living wage. Those workers also endure the full suite of labor exploitation practices, including gender-based harassment, wage theft, and unsafe conditions. On the material side, the induced consumption resulting from ever-cheaper products means the world consumed 400% more textile products globally as 20 years ago8, and bins most of it (the average American generates 82 pounds of textile waste each year).

antibiotic technology

The arrival of antibiotics in 19289 allowed for revolutionary leaps in fighting bacterial infections like strep throat, pneumonia, and meningitis, but an over-dependence and over-prescription of penicillin and its siblings through the 1950s-70s resulted in the proliferation of antibiotic resistance, which subsequently led to longer hospital stays, higher medical costs, and increased mortality.10

space exploration

Since the beginning of the space exploration era in the late 1950s, humanity has made leaps and bounds in learning about our own world and its physical systems, telecommunications, imaging, etc. The increasing frequency of commercialization missions in space for satellite systems (and lately tourism) has resulted in immense amounts of space debris being generated — both from active satellites and from jettisoned/destroyed components of previous missions, the debris threatens future missions and has even been destructive to the field of astronomy, making it impossible to use earth-based sensors and photography devices to learn about space.11 So desperate to extract Shareholder Value from the starry sky, we’re blinding our own ability to look at it.

The web is no exception to this pattern. A vision of interoperability, accessibility, and usability, the World Wide Web was first conceived in 1989 as a way to universally link documents and other media content in a flexibly-organized system that could make information easily accessed at CERN, and be easily shared with collaborators beyond.12 But the proliferation of access and ultimate social requirement of access has spawned countless troubles for human society, including cyberstalking and bullying, the instantaneous circulation of CSAM, violent images, and misinformation, identity theft, addiction, etcetera.

The rampant industrialization and commercialization of the Web predictably develops flashy, insidious patterns of extracting capital from its users: new surfaces for information means new surfaces for advertisement, and new formats of media beget new mechanisms for divorcing you from their ownership.

convivial life & convivial tooling

Illich poses convivial tools as directly opposed to this industrialized, radically-monopolized set of social systems. Similar to E.F. Schumacher’s concept of “intermediate technology” introduced in his 1973 book Small Is Beautiful: A Study of Economics As If People Mattered, convivial tools are sustainable, energy-efficient (though often labor intensive), local-first, and designed primarily to enhance the autonomy and creativity of their users.13 Illich cites specifically hand tools, bicycles, and telephones as examples, but with its enormous capacity for interoperability and extensibility, the Internet is the perfect workshed in which to design our own Tools For Conviviality.

part four.

the Web we want

The Plains of Heaven, John Martin (1851-3)

let’s reconsider

the markers of a decaying 'Net I mentioned before, with convivial tooling in mind:

Teaching & learning on the Web

Monolithic platforms like YouTube, TikTok, Medium, and Substack draw a ton of creators and educators because of the promise of monetization and large audiences, but they’ve shown time and time again how the lack of ownership creates a problem. When those platforms fail, when they change their rules, when they demand creators move or create a particular way to maintain their access to those audiences, they pit creators or their audiences against the loss of the other. Without adhering to the algorithm’s requirements, writers may not write an impactful document, and without bypassing a paywall, readers can’t read it.

When those promises of exorbitant wealth and a life of decadence through per-click monetization ultimately dry up (or come with a steep moral or creative cost), creators and learners must look for new solutions for how educational content is shared on the Internet. The most self-evident, convivial answer is an old one: blogs. HTML is free to access by default, RSS has worked for about 130 years^{[citation needed]}, and combined with webmentions, it’s never been easier to read new ideas, experiment with ideas, and build upon & grow those ideas with other strong thinkers on the web, owning that content all along.14

Connecting with friends on the Web

Social media apps have imprisoned us all in this weird content prison — in order to connect with friends we’re sort of forced to create or be vanished by capricious black box algorithms, and all that we do create is, as we’ve already alluded to, subsequently owned by whatever platform we’ve created it on. If Instagram goes away overnight, or decides to pivot catastrophically, your stories and your network of friends goes with it.

The advent and development of tools & methodologies like POSSE (Publish On your Own Site, Syndicate Elsewhere), ActivityPub, microformats, and ATProto, it’s becoming quite achievable to generate your own social network, interoperable with other networks like Bluesky or Mastodon. That network, designed for ownership and decentralization, is durable, designed around storytelling instead of engagement, and free of the whims of weird tech billionaires.

With some basic HTML knowledge and getting-stuff-online knowledge, a handful of scrappy protocols, and a free afternoon or two, one can build their own home to post bangers for the tight homies, make friends, and snipe those new friends with those hits of dopamine they so fiendishly rely on.

Coding for the web

Lastly, consider the discipline of web engineering:

We have been asked to build the same B2B SaaS website with the same featureset n^∞ times, and our answers for the optimal way to do that are increasingly limited. We’ve penned all of our markup into JavaScript templates just in case a product manager needs the wrapper component to post JSON somewhere down the line, and we’ve whittled away at style code until it’s just a mechanism for deploying one of two border-radius-drop-shadow combos to divs. It’s an industrial, production-minded way of approaching a discipline that has all the hallmarks of being a great craft, and that’s understandably uninspiring to many of us.

Yet our young React shepherds have no need to fear: there are countless more colors than blurple out there, and countless more fonts than Inter. HTML and CSS are better and more generative technologies than they’ve ever been: Thanks to the tireless work of the CSS working groups and browser implementers, etc, there is an unbelievable amount of creative expression possible with basic web tools in a text editor. Even JavaScript is more progressively-enhanceable than ever, and enables interfacing with a rapidly-growing number of exciting browser APIs (still fuck Brendan Eich though). ${new Date.getCurrentYear()} is a veritable renaissance of web code, and it asks of authors only curiosity and a drive to experiment.

part five.

so where do we go from here?

The Abbey in the Oakwood, Caspar David Friedrich (1810)

Illich’s thesis is that technology and its derived tools should serve people in a way that enhances their freedom, creativity, independence, and will.

The distillation of those principles on the web through manual code, hand-built social networks, and blogs, points luminously to one answer to the question of how the Internet can best serve humans:

it’s personal websites.

Hand-coded, syndicated, and above all personal websites are exemplary: They let users of the internet to be autonomous, experiment, have ownership, learn, share, find god, find love, find purpose. Bespoke, endlessly tweaked, eternally redesigned, built-in-public, surprising UI and delightful UX. The personal website is a staunch undying answer to everything the corporate and industrial web has taken from us.

And how might one claim this ultimate toolchain of conviviality, and build a place on the web that enhances their autonomy and creativity?

How might one build a personal website?

Start small

Let yourself start small, have fun trying shit that doesn’t work, document your growth, publish failed ideas & successful ones. Some of the best websites in the world are just HTML, and they belong to their authors. Make friends, let yourself be inspired by others, send friendly emails asking to learn new things, and do not demand of yourself masterpieces.
Reduce friction to publishing

Get the resistance to ship out of your way. Don’t get caught up in tooling and frameworks, just write HTML and get something online. If you’re an engineer, delight that you’re not beholden to the same standards of quality and rigorous testing that you are at work — draft some ideas, hit the h1 to p tag combo, and publish. Update and update again; let your ideas grow like gardens, the way they do in your mind. The mutability of the web, often its great weakness, is also one of its great strengths.
Don’t worry about design (unless you want to)

Don’t worry about design unless that’s the part that brings you joy. Make friends with designers and trade your work for theirs, or trade tips, trade advice. Get comfortable with being joyfully bad at something — from that soil of humility grows a million questions for those who have learned and are excited to share. Iterate until you’ve something you’re proud of, or iterate so much you’ve ruined it and have to go back to bald.
Use the IndieWeb

Leverage the IndieWeb and its wonderfully thought-out protocols, tools like brid.gy to syndicate your ideas out to the wider web, and then use Webmentions to bring the ensuing conversations back where the content is. That way, you can publish work where you prefer to, folks on Bluesky can enjoy and discuss it, in the same stroke as folks on Mastodon may, or folks directly on the canonical URL.
Join us in sharing what you’ve made

I encourage you to join us in our auspicious website adventure, and if you do, I hope you’ll further join us on personalsit.es, our happy little home for everyone building something humble or thrilling or joyful or deeply accursed, but personal.

part six.

(denouement)

Sunrise on the Matterhorn, Albert Bierstadt (after 1875)

You’re not crazy. The internet does feel genuinely so awful right now, and for about a thousand and one reasons. But the path back to feeling like you have some control is to un-spin yourself from the Five Apps of the Apocalypse and reclaim the Internet as a set of tools you use to build something you can own & be proud of — or in most of our cases, be deeply ashamed of. Godspeed and good luck.

❦

That’s all for me. If you find any issues with this post, please reach out to me by email. Thanks eternally for your time and patience, and thanks for reading. Find me here online at one of my personal websites like henry.codes or strange.website or stillness.digital or strangersbyspring.com, or sometimes on Bluesky and Mastodon.

As ever, unionize, free Palestine, trans rights are human rights, fix your heart or die.

fin.

go home

Economics & labor rights in AI skepticism

Henry Desroches — Tue, 03 Jun 2025 18:30:55 GMT

There’s a growing attitude in the technology industry that LLM technology is, or will be, the next great innovation to our work. Business owners and workers alike seem to be in unlikely agreement: owners are thrilled at the prospect of making their businesses more efficient and productive, and workers are thrilled at the prospect of simplifying their workstreams or making their jobs easier. It’s a surprising alliance in the prevailing economic system.

This is a post about the economic implications of adopting AI in your work, not about whether or not they actually improve your productivity. For the sake of argument, this will assume there is some productivity added. There is plenty of criticism of countless aspects of AI/LLMs/et al technologies online, but this post engages primarily with the concerns of labor.

Some context on capitalism

From Andrew S. Zimbalist’s Comparing economic systems: a political-economic approach:

Capitalism is an economic system based on the private ownership of the means of production and their use for the purpose of obtaining profit.

That obtained profit can come from many places: production facilities expansion, resource availability, or technological advances make production cheaper, macroeconomic forces increase demand for a product, allowing its price to be increased, etc.

However, in the recent past, that profit has been disproportionately extracted from the labor force. The Economic Policy Institute analyzed productivity and wage data from Bureau of Labor Statistics and Bureau of Economic Analysis from the 1940s until early 2010s, and found that while productivity increased hand-in-hand with hourly labor compensation from 1948 to 1973, the next 40 years showed an increasing and immense gap: while productivity went up nearly 75%, hourly compensation only increased 10%.

This can be attributed to the mechanics of the system. In a capitalist framework, businesses must create profit to be considered successful, and extracting more and more of that profit from labor is practically codified in the economic playbook of capital: stagnating wages, off-shoring work to laborers with lower standards of living, even leveraging legal systems to allow for fewer labor affordances. Capital will always choose the interests of capital over the interests of labor — it must do this to survive.

Where LLMs come in

Capitalism as it stands, in America and beyond, only functions if it continually finds new ways to extract value from labor: so while the upsides of adopting LLM technology to you as a worker might seem marginally useful now, that adoption directly contributes to that extraction, ultimately devaluing labor.

If we take the lofty claims of LLM marketers to be true, that by adopting LLM workflows, you may do the work of your team, say 25% faster, what are the implications of this to the managerial/supervisory class? Consider a scenario:

Let’s say your team is expected to create 1 widget per period, and your team has 5 people on it. By the time your entire team is 25% more efficient, you have gone from individually creating .2 widgets to creating .25 widgets with the help of LLMs, which means your team creates 1.25 widgets per period.

Applying the systematic behaviors of capitalism, one may envision two possible outcomes from this:

The first likelihood is that you now are paid the same wages and expected to create more widgets, which means your labor has necessarily gotten less valuable. If you got hired at $100 per period to create .2 widgets, and now get paid $100 to create .25, you functionally get paid less ($20 less per period in this case, but it’s academic).
The second likelihood, and the more insidious one, is that the increase in efficiency justifies downsizing. If your team is expected to create 1 widget, and now creates 1.25, the bottom line to the company is that if it lets you or one of your teammates go, it can create 1 widget for 25% cheaper. That’s free profit to the company, and sacrificed employment to one of you.

While to an individual that loss of employment might be devastating, to the company a reduction in workforce is a line-item; as mentioned before, capitalism will always choose its own interests. It’s not a personal decision, it’s not a specific person that can save you or betray you: capitalism, as a system, was designed to work this way.

There is a farther-reaching consequence to this, which is that: the more roles that companies eliminate under this increase in efficiency, the higher the supply of the labor market, which as market economics 101 will tell you means that the price for labor will go down, worsening the crisis of stagnate wages.

What is there to do?

As technologists, we are workers first. We cannot individually stop the machine of capitalism from exploiting our labor, and, while this tide will shift, many of us are too romanced by the technofuturist dream of LLMs — despite widespread, multidisciplinary criticism of the technology and disastrous consequences in its application so far — to easily reconsider our adoption of it.

The solution to the oncoming waves of LLM-related labor devaluation has at least two solutions, which should be applied in tandem:

As individuals, we must reject the indiscriminate proliferation of LLM technology in our work. As many have written, there may actually be actually valid applications of this technology, but any that weaken your role as a laborer should be viewed with intense scrutiny. The immediate convenience of writing fewer TypeScript interfaces will be followed swiftly by the economic ramifications of cheapened labor — no matter how much you like your boss, it is a systematic certainty in a capitalist market.

Collectively, we must organize as a labor force. Countless examples through the history of capital show that production owners/business people have no qualms about organizing against us — from the Pullman Strikes, to the Ludlow Massacre, to the Mohawk Valley Formula, the class of means has no incentive not to collude, organize, and act against the interests of labor. Labor must consequently organize and act in its defense.

There is great precedent and inertia for labor organization in the technology industry — I recommend Ethan Marcotte’s book You Deserve a Tech Union as further reading.

Thanks for taking the time :) I’d really like this to be a strong if succinct advocation, so feel free to email me if you have any questions or concerns.

How to collect Webmentions for your site

Henry Desroches — Fri, 23 May 2025 17:59:28 GMT

Quick disclaimer before we start. This is well-trod ground. Nothing here is new or revolutionary, nothing about this implementation hasn’t already been done by smarter folks than I :) This is just my blog post about it.

We’ll use webmention.io for this. webmention.io is a hosted service for receiving Webmentions. There are many other implementations of the Webmention spec, but this is the easiest one to get cooking with in my experience! All we have to do to get started is to authenticate ourselves using IndieAuth, and then connect our webmention.io endpoint.

Authenticating with IndieAuth via IndieAuth.com

One thing I’ll say is that while “the hardest part of computer science is naming things” is contentious, "the hardest part of “interfacing with IndieWeb tools is the names of things” is inarguable: IndieAuth.com is a hosted implementation of the IndieAuth specification, and it’s what webmention.io, which is a hosted implementation of the Webmention specification, uses to handle authentication.

It’s devious work, I agree, but thankfully your old friend Mr. Websites has already handled the mess of this naming convention.

Identity Verification

One of the major tenets of the IndieWeb is this concept that your personal domain, which you own, can be used to verify your identity across the web. A common mechanism for this identity verification is the use of rel="me" links.

The way rel="me" works is:

On your website, you can add a link to another online profile or source of identity, such as GitHub, your email inbox, or Mastodon (for this tutorial we’ll use GitHub, as that’s one of the acceptable providers for IndieAuth), and add an attribute rel="me", which “indicates that the current resource is represented by the linked party.” More on the rel=“me” configuration can be found on MDN. Here’s how it might look for me:
```
<a href="https://github.com/xdesro/" rel="me">GitHub</a>


<a href="https://bsky.app/profile/strange.website" rel="me">Bluesky</a>
<a href="https://front-end.social/@henry" rel="me">Mastodon</a>
```
If you prefer not to have visible links, you can use <link> tags in your document <head>:
```
<link rel="me" href="https://github.com/xdesro" />
```
On each linked profile, link back to your website. On GitHub, for example, if you link to your URL, they’ll automatically add the rel="me" attribute when rendering:

That’s all you need to do for IndieAuth. The basic idea here is that only You can update your website to add a statement like “this link is my GitHub account”, and furthermore only You can update your GitHub account to say “this link is my personal website”, so it stands to reason that because they refer to each other, they’re both You.

We can move on to the next step now, but if you’d like to, you can test your IndieAuth configuration here.

Actually collecting Webmentions using Webmention.io

Now that we’ve set up IndieAuth, we can log in to Webmention.io. It’ll prompt us to log in via whatever modes we’ve configured, and then we’ll verify our login. Next, add the <link rel="webmention"> tag that it gives you to the <head> of your HTML document.

That should be all we need to start collecting Webmentions to our site! The Webmention.io dashboard will show recent Webmentions, or I usually use the actual API view, which you can access from the Webmention.io settings page, because it’s a bit cleaner.

If you want to test that everything’s hooked up, I’ve found the beatonma.org Webmention testing tool works great; just paste in a URL on your site and refresh the Webmention.io dashboard to see it show up!

Next steps for Webmentions

If you’d like, you can also request the mentions.jf2 endpoint from the Webmention.io API:

https://webmention.io/api/mentions.jf2?token=${the token on the webmention.io settings page}

This will give you a JSON readout you could use to render mentions on your site, but that’s another blog post — in fact I’d like to do a whole series on it but IMO this is a great start for getting involved with the IndieWeb and using your domain as an identity store. Fantastic work, your ancestors (the chill ones) are smiling upon thee on this day.

Well, what if I'm wrong?

Henry Desroches — Mon, 19 May 2025 16:19:30 GMT

Anyone online has seen over the past years how the frequency of Palestinian accounts on Bluesky and other platforms has increased, two- and four-fold, folks asking for help and linking to GoFundMes. They share their stories and plea for help, to flee Gaza, to buy price-gouged food for their children, to afford healthcare. I have made the choice to move from my values, namely that no one asks for help that doesn’t need it: I make an effort to give aid to everyone who asks me to. But what if it’s a mistake to do so?

I’ve noticed a strange contrary attitude or a strange silence from my peers in response to these requests for aid. There’s a reflex to keep staring straight ahead, or there’s a great, perfect-posture, chin-up reflex to Verify™. Because it’s easy to sock-puppet on the web these days, and at the end of the day, anonymity is baked into the fiber of the Internet, and you can’t possibly know if you’re donating to a real person or some deft scammer.

You can’t possibly know

The folks who genuinely need help are likely indistinguishable from the malicious actors. With the advent of LLM tools, it’s probably more easy than it has ever been to create increasingly sophisticated bots that could collect donations. While there are some folks doing all the footwork to personally verify the personhood of different accounts asking for help, not every account of the hundreds, thousands, might be verified. All that labor to research signals of legitimacy and interview people — it’s certainly not negligible.

As Johnny Hill points out, there are a lot of prominent folks, like Molly Shah, like Alex Winter, like the fairshare bot doing this labor, meeting these people already. As he further points out, if it’s really so important to you, you can trust people already in community with Gazans, instead of withholding in favor of some different version of your life where you’re the world’s greatest online detective.

Besides, we donate to legacy aid institutions

I’ve written about this before, and donating to aid groups like Doctors Without Borders, UNRWA, the World Food Program, etc, is an honorable and necessary act. But in the case of Israel’s genocide of the Palestinian people, that critical aid is arriving in a disturbingly diminished capacity, and often not arriving at all. That’s not to say that these institutions aren’t critical, that they don’t make a difference. But if your $50 donation is spread among the now millions of Gazans that need aid to get by, and arrives months from now if ever, it starts to impel questions of whether or not there are more effective ways to make a difference.

So what if I’m wrong?

What if my GoFundMe donation actually ends up in the hands of a malicious actor? What if I can’t afford the time and energy to vet the legitimacy of everyone who asks for help? Won’t I be embarassed? Won’t I be a fool, won’t I have wasted money on something so foolish as hope, as prayer?

Yes.

But what if I’m right?

Direct aid and grassroots networks move at a rate institutional aid groups functionally cannot. Quite obviously, getting immediate help in the hands of individual people helps those people immediately. Donating directly to these families eliminates the bottleneck of waiting in lines to receive slim humanitarian aid when those lines are even available in an environment of constant human rights violations. Moreover, providing help beyond their immediate needs enables them to distribute that aid to their community, existing person-to-person networks spread aid among families and neighbors and god-willing eventually whole communities.

And consider your own mental health for a moment — we look daily into the torment nexus to watch children blown apart and families starved and hospitals collapsed and journalists targeted and bastard IOF soldiers laughing at the results of their remote-controlled slaughter. It’s not right for it to happen and it’s not right for us to watch and do nothing. Forgive me the appeal to spirituality, but it’s not right for your soul to sit and view and do nothing. We can riot in the streets, and we should riot, with hope and anger and persistence, but in the mean time, this is something we can do that materially changes the daily life of Palestinians.

And for a minute, put all of this aside — fuck, man. Isn’t it worth the risk? If I donate $25, if I donate $100, if I donate my entire net worth, and 90% of it goes to scammers — but some portion of it is responsible for keeping a single Palestinian alive for one more day, isn’t that worth it? Why is this a calculus any of us are running — your pride, your resistance to being scammed by imagined masterminds is not worth anyone’s life.

Please, please let yourself off the hook. The next time someone asks you for help, it will heal some part of you to help them; without vetting and qualifying the act of helping. You can make a difference to someone right now.

A case for unconditional giving

Henry Desroches — Thu, 06 Mar 2025 04:09:30 GMT

I’ll be honest — I am ashamed of how long it took me to get here. Too many half-hearted hypothetical protestations, hands sweatily-wrung. I read someone’s blog post about this a few years back (I’ll link it when I find it) and it hit me square in the middle of the forehead with how obvious this all ought to be:

We should give folks spare change when they ask for it.

The lady on the corner by your office, the scratchy-voiced man on the subway, the folks pitching local newspapers outside your neighborhood bar — when they ask for help we should help them, unconditionally.

I am uncomfortable with all forms of policing, including behavior scolding. If this post isn’t for you, I don’t take it personally, there’s a whole bunch of articles about HTML right around the corner from this URL.

I get the feeling, however, that this post is actually for a lot of us, and we just need an excuse to let ourselves change our minds on this. Stick with me here.

Why you might not

I’ve gone through literally every one of these little cognitive dissonances at one time or another — it’s just how we’ve been socialized, but I’m gonna face each one and by the end of this I hope you’ll shake them off and sit next to me.

I don’t have any money to give

You’re off the hook. If we can’t afford to spare even a dollar a week from our costs-of-living, that’s real and it really is awful out there, and this post just isn’t for someone facing that.

I reckon many of us can spare it, though — even the smallest amount, and we know who we are. I’m building a habit of taking out a fluctuating amount a week, depending on how sore my wallet is, breaking it at a cafe or convenience store, and because Denver has a big population of folks who need help, I’m usually able shed it by the end of the week.

What if they use it for drugs/cigarettes/alcohol/The Wrong Thing?

This is one of the really sticky things about this conversation — we need to actually believe that people are entitled to their own privacy and their own agency. Just as it’s none of our business what our housed neighbor or our best friend spends their money on, it is none of our business what the struggling person on the bus spends theirs on. It’s the hardest pivot to make from the socialization we’ve received that we have any stewardship over anyone else’s life just because they’re having a harder time than us, but it is imperative to make the mental shift.

Anecdotally, most of the people I’ve known to experience homelessness or otherwise need to ask for help just have to meet obligations — overdue bills, medical care, eating a meal — but even if someone should decide to spend it on what you deem The Wrong Thing, they are owed their own agency to do so. It is not up to us to decide who gets to run their own lives.

Furthermore, I’d love it if everyone got clean of their challenging drug or alcohol habit, but if a fix will get my neighbor through one more day and hopefully some steps closer to getting treatment, a day of self-medicated survival is always worth it over a potentially deadly withdrawal.

Shouldn’t I give them this toiletries/PB&J/care package I keep on hand?

It doesn’t hurt to offer! Usually, people will be honest with you about what they need, though. This goes hand-in-hand with the previous point of affording folks their own agency. If someone asks for cash, and we give them one of the pre-made sandwiches we’ve had in your car for weeks or the toiletry kit that they might already have many of the items from instead, we’ll have gone through a lot of effort to not really help very much. In some cases, maybe the care package we designed is exactly what someone needs, but often folks are best served by being able to choose their own priorities and make their own purchases.

What about the guy that my buddy says drives a Mercedes home from panhandling every day?

You don’t believe that guy exists, and neither do I, and we sound silly saying it — it’s a strange urban myth a lot of people hang onto because they’ve never interrogated it. To be extremely generous and afford this some credence, I’ll make the assumption that this is a warped perspective on there being different states of poverty. Plainly: Some people own homes and still need help. Some people own cars and still need help. Some people have disability statuses that mandate they cannot work without losing coverage. All of these countless states of Getting By are easier to understand if you believe that, almost always, when people ask for help, it’s because they need help.

They should seek help from government programs/soup kitchens!

Many people do! And it is possible to hold true two things: the government programs, government workers, and volunteers all do great work, and people still need help beyond that. If the government responded adequately to the needs of its citizens, we’d have a lot fewer problems in many more directions. Additionally, many shelters are unsafe for myriad reasons, and many programs simply can’t meet the demand, and must turn people away. It’s something but it just isn’t enough — our direct action we take when called upon is one more raindrop that raises the sea.

Why you really ought to

For your peace

This is a little hand-wavey, but stick with me. I know some of us feel uncomfortable with the interaction of being asked for money. It is incredibly distressing to practice ignoring someone asking for help on the subway, and it rots our hearts to do so. We become reflexive in how quickly we deploy “sorry, I don’t have cash”, “not today brother”, etc.

A deliberate practice of carrying cash specifically to help our neighbors solves this: we are able to, in one stroke, meet the need of the person asking for help, acknowledge their humanity and show them kindness and respect, easily resolve a previously challenging human interaction by acting human, and feel like we’ve done something material and active to make our neighborhood better.

There’s no shame in helping because it makes us feel good to help. Our reasons for helping are immaterial to the result.

For your soul, for your community

We take care of us, we keep each other safe. There’s an uneasy silence among middle-class people in neoliberal cities like Denver, like San Francisco, like Seattle, etc, about the routine violence of our police against homeless or mentally ill people. We cannot rely on the government to solve problems; we must show each other love and care freely and openly and unconditionally.

None of this is new or revolutionary — quite the opposite, I came way too late to this way of thinking (garfield-you-are-not-immune-to-propaganda.bmp). But the second I switched over to this mindset it instantly became the easiest, most obvious, most soulful contribution I’m able to make to my neighborhood every single day. We’re late but we’re not too late. I hope you’ll join me.

As always, email me to talk more or challenge these ideas. Thanks for reading.

Using Figma to design perfect gallery walls

Henry Desroches — Fri, 21 Feb 2025 18:50:52 GMT

Quick heads up: Since writing this, I’ve found one or two fairly sizeable bugs in the Galleria plugin. I’ve published anyway cause the guide is not entirely dependent on Galleria, and Galleria is mostly functional. You can still give it a shot, or alternately use Photoshop’s Perspective Warp tool, or come back soon and I should have it worked out :) (cir. Feb 21 2025)

I’m a twisted animal with a penchant for moving every two years, and the universal upside of moving every two years, as everyone will agree, is hanging new gallery walls. The rectangle enjoyer in me started using Figma to design them a few years ago; the upside is I can draft a bunch of ideas without taking up room on the living room floor, and can re-use the assets created year after year on new walls at new apartments. It even has the added bonus of becoming a little archive of past walls. It’s nice, and you can too.

The tools you’ll need for this are:

A tape measure
Phone or other camera
Figma

Bro I realized about 4 seconds into writing this that IRL frames and Figma frames are really hard to refer to distinctly in writing — if any of this is confusing shoot me an email or complain on Bluesky and I’ll get you sorted.

Gathering and treating assets

The first thing that needs done is to photograph the pieces that’ll be going into the wall. I try to always shoot new additions in the same context and light. You want to avoid glare but most everything else can be fixed with a Figma plugin we’re gonna grab in the next step. It doesn’t even particularly matter how far or at what angle you take the photo, but in general:

Take a photo of the entire framed image. The frame is part of the visual effect of the gallery wall so it’s important to include it, not just the artwork it contains.
Leave a few inches around each frame, both to avoid lens distortion and so you have some room to crop in.
Try to shoot mostly straight on. Doesn’t need to be perfect by any means but a little effort to square things up a bit before we manually square them wouldn’t be a bad thing.

Correcting perspective using the Galleria plugin

Next we’ll use a Figma plugin I made (crowd slamming hands on tables, chanting “shill! shill! shill!”) to make sure the perspective of our images is perfectly square for planning and mockup purposes. You can install and run the plugin from Figma Community:

Galleria - Perspective Warp Tool

by Henry (From Online)

A Figma plugin for correcting or warping the perspective of image fills in your Figma document.

this link goes some strange place beyond this website go with care

I’ve already written a detailed guide on how to use the plugin elsewhere on my blog, so if the onboard UI isn’t clear, you can head over there to get situated!

Category: resource
Tags: figma | figma plugins

Correcting perspective in Figma images with the Galleria plugin

Reading Time: 3 minute read
Last updated: Last updated February 17, 2025

I based the functionality of this plugin off Photoshop’s Perspective Warp tool, so if you’ve got Photoshop and don’t wanna touch my garbage that’s a super strong alternative.

I try to stick to an assembly-line style of work, taking all of the photos at once, adding them all to Figma at once, correcting all their perspectives in a batch, etc. For each framed image, we’ll import it to Figma and use Galleria correct the perspective. Then we’ll crop the output to only the framed image, and paste it into the Figma canvas.

Mapping IRL measurements into Figma

Now we can collect the measurements of all of our frames and implement them in Figma. The way we’ll do this is by giving a real life unit a Figma canvas pixel equivalent. I typically map 1cm to 10px. Centimeters are more accurate than inches, and putting a 0 on the end of every number makes everything feel quite tidy.

For each framed image, we’ll grab the width and height of the IRL frame in centimeters and set the corresponding Figma frame to that cm measurement times ten. For example, if one of my posters is 54cm x 70cm, I’ll set its proxy in Figma to 540px x 700px. It’s important to work out an easy-to-remember measurement translation system so you can easily add new walls and new frames in the future.

A quick note about Figma components

I recommend you use the Figma Create Component feature on each frame once you’ve got it warped, cropped, and resized. That way you can easily re-use it without worry of mutating the original.

Planning out walls

Now that we have all of our frames imported, we can start trying out ideas. If I’ve got a wall space I’m designing for, I typically like to measure the entire wall and create it as a rectangle in Figma, even measuring out obstacles like doors or furniture so I can get an idea of the complete visual effect. Our translation system comes in handy again here: If my wall is 13ft long and 9ft high, I can convert that easily to 394cm x 274cm, and create a corresponding Figma “wall” rectangle of 3940px x 2740px. Now my framed images will always by perfectly sized to the walls they’ll be mocking up.

Complex wall shapes

If you want your mockup to respond to wall configurations more complicated than a perfectly-rectangular wall, you can make use of the Figma boolean operations. For example, if your wall is interrupted by a door, you can measure the size of the door and its distance from the closest wall, and then create a rectangle of the corresponding size and distance on top of the wall you’ve already created. Select both the door and the wall, and go to Object → Boolean Groups → Subtract selection. Now your wall shape will be match the wall you have to work with in real life.

Conclusion and potential enhancements

And that’s my system. It’s nice to be able to try out 30 versions of one layout before committing to putting nails in the wall. I’ve been using this method for years, refining my approach each time.

This is the most basic implementation, but there’s a ton you can do to enhance the simulation and implementation of the wall:

Mocking up the actual wall

I usually take a picture of the wall I’m actually mocking up and perspective warp it the same way I do everything else, and then I can add it as a fill layer to the wall rectangle I’m laying out on. It adds just that much to the simulation to have actual wall texture or overlapping furniture visible.

Documenting wall mounting points

If you wanted to get really twisted with it, you could create diagrams of where you need to create mounting holes from this. I haven’t actually done this yet, but the way I envision it would work is that you could create multi-layered components out of each frame. One layer would have the photograph of your image, and on a second layer you would create a diagram of where on the back of the frame the mounting hooks/rails/etc are.

As always, if you’ve found any issues with any of this, the blog post or the process itself, feel free to shoot me an email or get at me on Bluesky.

Correcting perspective in Figma images with the Galleria plugin

Henry Desroches — Mon, 17 Feb 2025 18:20:02 GMT

Whether it’s a framed image that was taken at a slight angle, or a product photo that just doesn’t quite match the rest in the grid, I’ve frequently had the need to adjust the perspective of an image in my design work. In the past I’ve just used the Perspective Warp tool in Photoshop, but it felt silly to boot up a whole separate graphics program for a two-second adjustment, so I made Galleria, a Figma plugin which lets you do exactly this.

Installation

Galleria is part of the Figma plugin community, so you can look it up in the app via Plugins → Manage plugins and search “Galleria”, or just download it directly from the community:

Galleria - Perspective Warp Tool

by Henry From Online

A Figma plugin for correcting or warping the perspective of image fills in your Figma document.

this link goes some strange place beyond this website go with care

A new perspective

To get started with Galleria, you can select any frame or rectangle that has an image fill, and then run the plugin by right-clicking → plugins → Galleria. A window will open with the image fill rendered twice, once as it currently is and also how it will be once you sort out the perspective.

Selecting a perspective plane

You can drag the corners of the quadrilateral on the left image to select the corners of a plane in the image that is meant to be perfectly rectangular. As you adjust the plane selection, you’ll see the image get warped on the right side. Once you’ve matched up the points, the image on the right should have its perspective corrected.

Sometimes, it doesn’t work perfectly lol. As far as I can tell it’s mostly when an image has excessive lens distortion in addition to angular distortion, but if you find additional bugs please don’t hesitate to let me know.

Selecting an output frame

Now that the perspective is corrected, you can choose one of the export options, to put the entire result back into your Figma document, but since the result is a bizarre shape this probably isn’t what you want. If you want to crop the result, you can click-and-drag a shape in the second window to choose a preferred area.

And it’s as simple as that

And folks, it’s as simple as that. Like I mentioned before, if you find any images that fail, feel free to shoot me an email and I’ll do my best to get a fix in place. I use this tooling primarily to square up photographs of framed images in order to plan gallery walls in Figma, but if you have a unique use case, I’d love to hear about that too. Further questions comments concerns generational curses are welcome in my email inbox or you can yell at me on Bluesky.

How I set up a new laptop

Henry Desroches — Sat, 23 Mar 2024 20:00:00 GMT

Well it’s that time again, migrating for one reason or another listlessly between computers as priorities and jobs change. Here’s a middle-depth breakdown of how I speed-run getting a new machine off the ground.

This post is for Mac computer users who might be interested in automating their setup workflow.

TL;DR

It’s like 85% Homebrew automation and about 5% dotfiles and about 3% curling tools that aren’t on Homebrew and 1% making sure Mac settings are correct. What you do with that remaining 6% is up to you, I’ve granted it to you as a gift — do not forget this kindness.

Preheat the oven with Homebrew

Right off the bat I’ll kick open a Terminal window and install Homebrew, which is a package manager for OSX. This tool will handle almost all of my installs going forward — I’m personally quite allergic to the dance of downloading, installing, and subsequently deleting ten thousand .pkg files from all corners of the 'Net, and besides, this is ✨ automated ✨.

The install steps that Homebrew asks for change over time, so your best bet is to visit the Homebrew website and follow their directions, but at the time of writing, the standard way of installing is a shell command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

It’s generally poor form to go pasting things from random strangers on the Internet into your Terminal. You can trust me though, I’m like a chill internet stranger.

Dotfiles Mise en Place

You’ve probably encountered dotfiles before, the janky extensionless files at your home directory that you sometimes have to edit to get certain shell commands to work, etc. Because they have so much potential for configuration, it’s super useful to store them online and reuse them, and that’ll power much of our setup. Plenty of folks have written at length about this pattern, so I won’t dive too deep here. Basically, we’re gonna create a GitHub repo at our home directory, .gitignore everything (because we don’t want to just be adding everything all wilson-nilson), and force-add only the relevant files. That repo will then be a quickly-downloaded source of truth for our hard-fought finicky IDE/terminal/prompt config.

I’ve currently got three configuration files in my dotfiles repo: a .hyper.js JSON config for Hyper terminal, a .zshrc for making my zsh + oh-my-zsh + spaceship setup work well, and a Brewfile.

Setting Up Git And Dotfiles

If I’ve got my dotfiles ready on an old laptop, I’ll need to clone them onto a new machine. The first step for that is making I can even access the repo to clone it. I use GitHub to store my git projects, so I can follow their directions for:

(Obviously you could just copy and paste from the browser but I use GitHub daily anyhow, may as well do this step now and never worry about it again!)

Once that’s sorted, I can put dotfiles where they belong. Since the home directory already has stuff in it, it won’t be possible to just git clone, so what we can do instead is:

cd ~
git init
git remote add origin DOTFILES_REPO_URL
git reset origin/main # we have to do this in case any of the files in dotfiles already exist
git checkout origin main

Now our Brewfiles/.zshrc/etc should have made it to where they belong! Next we can install all the apps that will adopt these configurations.

Installing apps with Brewfiles

One of the cooler features of Homebrew is its ability to consume package files called Brewfiles (similar to Gemfiles, if you’re into the Ruby ecosystem at all), which can perform any number of sequenced actions. I’ve got most of my day-to-day apps and CLI tools sorted in the Brewfile I just pulled in the last step, and I can install them all at once. I’ve included a snippet of that Brewfile here, and you can view the whole thing over here.

# Mac Apps with `--cask`
cask "alfred"
cask "firefox"

# CLI tools with `brew install`
brew "node"

# Even font files are fair game
tap "homebrew/cask-fonts" # point Homebrew to where the font file lives
cask "font-inconsolata-nerd-font" # install it

Once I’ve got my shopping list of apps set up, I can install all of them at once with a quick Homebrew command:

brew bundle install

Homebrew automatically looks to install from ~/Brewfile if no other location is specified, so that Dotfiles import works seamlessly. Homebrew also has really straightforward logging — it’ll clearly indicate what it’s doing, and which of its actions were successful or not.

Installing apps without Brewfiles

I use two tools that don’t jive well with Homebrew installation: nvm and oh-my-zsh.

NVM is a version manager for Node, and they explicitly say on the repo install guide that Homebrew install isn’t supported. Theirs is—at the time of writing—just a curl command to run their install script:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Remember what I said about running random commands you find online? Doesn’t it seem like Apple should’ve made a secure, native package manager so installing stuff doesn’t feel so back alley?

Oh My Zsh is a config manager for zsh — it enables plugins like the extremely useful git shortcuts and aliases plugin. It’s also a curl command:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

And that ought to do it for installs for my default setup.

Last Steps

Believe it or not, that should be everything sorted. Homebrew does so much of the heavy lifting, usually all that remains is to do some logins (easily done if one uses a password manager 👀) and configure final Mac settings. I personally set auto-keyboard intervention to off as a default (I can’t with the auto-capitalization and spellcheck), as well as turn on the battery percentage in the top bar.

Thanks for reading! Hope it was useful, and I hope you find some meaningful, fitting way to get revenge on me for the time wasted if not. If you’re following this like it’s a tutorial and run into any issues, please definitely let me know!

How to map a number between two ranges

Henry Desroches — Wed, 18 Oct 2023 21:00:00 GMT

Often in creative web projects, I find myself having to take a number, which exists in a specific range of numbers, and find the number that would be in the same position if the range were changed. Examples of this type of operation can vary anywhere from converting Fahrenheit to Celsius, to my recent use-case of creating an array of 500 “particles” with 3D coordinates and assigning each one a position between { z: -10 } and { z: 12 } relative to its position in the original array (i.e. particles[0].z = -10 and particles[499].z = 12).

Here’s a basic tutorial on how to do that sort of thing, first as a mathematical rundown of the concept, and then a dirty JavaScript implementation.

TL;DR

In a rush? Don’t have time for a mere five minute tutorial blog post complete with handy diagrams even though I made them just for you? No worries, here’s a quick JS one-liner for mapping a value from one range to another:

const mapRange = (value, oldMin, oldMax, newMin, newMax) =>
  ((value - oldMin) / (oldMax - oldMin)) * (newMax - newMin) + newMin;

The Math Part

What we’re doing here is a form of something called linear transformation, or linear mapping. Simply put, it’s just scaling any operation that happens on one side to the other. Take for instance that we have a line that goes between 0 and 2, and a value along that line of 1. Intuitively, we know that our value is halfway along the line, so if the line changes size (maybe from 0 to 4), our new value will still be halfway along the line.

The actual concept of linear transformation gets way more complex than this, often involving matrices and vectors and extra dimensions and other words. Since as web developers, we’re merely lemon-muffin-brained baboons, we’ll keep to this shallower end of the pool for this blog post.

Breaking It Down

To implement this concept more concretely, the first thing we’ll need to do is to find the relationship between our initial value and our initial range. We can do this by subtracting the minimum of the range from both our value and the maximum of the range, and then dividing the updated value from the updated maximum.

In the following diagram, we’ll use v to represent our input value and A and B to represent our input range’s minimum and maximum values.

\begin{matrix} (v - A) / (B - A) \\ (1 - 0) / (2 - 0) \\ \frac{1}{2} \end{matrix}

Just as we understood earlier, our value of 1 is 1/2 of distance between 0 and 2.

Next, we’ll need to take this fraction multiply it by the actual size of the new range. We can find the actual size by subtracting the minimum of the new range from the maximum. We’ll add the minimum back at the very end.

Here we’ll continue to use variables v, A, and B as before, but with the addition of x as our transformed value, C as our output range minimum, and D as our output range maximum.

\begin{matrix} x = ((v - A) / (B - A)) * (D - C) + C \\ x = ((1 - 0) / (2 - 0)) * (4 - 0) + 0 \\ x = \frac{1}{2} * 4 \\ x = 2 \end{matrix}

Applying The Concept

Now that we understand what needs to happen mathematically, we can try it out with a more practical application. Let’s use the example of converting between Celsius and Fahrenheight we mentioned earlier.

For choosing the ranges, we can use any set of numbers we want, but let’s go with the freezing and boiling points of water, since we know those values in both scales. We can use any temperature, but for this blog post let’s try 17ºC. Knowing our ranges and input value, we can set up our problem:

\begin{matrix} ((v - A) / (B - A)) * (D - C) + C \\ v = 17 \\ [A, B] = [0, 100] \\ [C, D] = [32, 212] \end{matrix}

And all that’s left is to break out our variables and solve:

\begin{matrix} x = ((17 - 0) / (100 - 0)) * (212 - 32) + 32 \\ x = \frac{17}{100} * 180 + 32 \\ x = 62.6 \end{matrix}

Swell! So 17ºC in Fahrenheit is a lovely 62.6ºF Autumn day.

For style points and to prove our salt, we can convert right back simply by swapping the positions of the ranges and solving.

\begin{matrix} x = ((v - A) / (B - A)) * (D - C) + C \\ v = 62.6 \\ [A, B] = [32, 212] \\ [C, D] = [0, 100] \\ x = ((62.6 - 32) / (212 - 32)) * (100 - 0) + 0 \\ x = 30.6 / 180 * 100 \\ x = 17 \end{matrix}

Stupendous. Utterly stunning. We’ll make an insufferable mathematician out of you yet, old friend.

The Code Part

With a mathematical function that does what we want, executing this operation in code is pretty straightforward, and we can even use more meaningful variables. We’ll take our input value, initial range minimum and maximum, and output range minimum and maximum as props, and build a useful JavaScript one-liner from there.

const mapRange = (v, A, B, C, D) => {
  return ((v - A) / (B - A)) * (D - C) + C;
};

// or better yet

const mapRange = (value, inputMin, inputMax, outputMin, outputMax) => {
  return (
    ((value - inputMin) / (inputMax - inputMin)) * (outputMax - outputMin) +
    outputMin
  );
};

Conclusion

I hope this crash course on range mapping was useful to you. As a disclaimer, I’m not A Big Math Guy™, I just end up using a lot of these concepts when I’m making websites. If I got something wrong (I’m specifically unsure about expressing this stuff correctly in the mathematical diagrams), or could explain some aspect more clearly, feel free to reach out via email; I’m glad for the opportunity to improve these blog posts.

A one-liner for freeing ports on OS X

Henry Desroches — Tue, 28 Feb 2023 19:07:00 GMT

TL;DR

One of my most-frequently searched dev tasks over the course of my career thus far has been the “how do I find what process is on a port” to “how do I kill a given process” wombo-combo — there’s always some memory-leaky service running that ctrl+c isn’t tough enough for. Figured it’d be good to write a quick shell function for doing just this. Before I get into the explainer, here’s the code:

function killport {
	echo '🚨 Killing all processes at port' $1
	lsof -ti tcp:$1 | xargs kill
}

This bad boy can also be found as a script in Gist form on GitHub.

Sorry, this guide doesn’t currently solve for Windows ~~or Linux systems~~ (apparently it works on Linux), as far as I know. If y’all have an analogous solution, I’d happily include it in this post :)

Finding the offending process

After defining our function and adding some cute helper text, we can use lsof (list open files) to find processes that match our criteria. The manual for the lsof says:

An open file may be…a stream or a network file (Internet socket, NFS file or UNIX domain socket.)

Sounds like exactly what we’re on the hunt for. We’ll pass a couple of options to make this work as a function:

-t: The lower-case version of the -T flag sets some preferences for the output we get from running lsof. Specifically, -t returns only the PID, which is useful for piping this output to the kill command.
-i: This flag tells lsof to specifically look for matching internet addresses. We can pass the port we’re looking for in the format [protocol]:[port].

The protocol will be TCP, and then we can use a bash positional parameter to accept the port number as an argument to our killport function:

lsof -ti tcp:$i

Killing in the port of

Now that we have the PID of the process that is running on the port we want closed, we can send that over to the kill command. We’ll use a bash pipe and the xargs command to pass that information on.

All the pipe is doing here is passing the output of lsof to xargs, and all xargs is doing is taking some input and providing it as an argument to the kill command. All-told, that comes out to:

lsof -ti tcp:$i | xargs kill

That’s digital plumbing babey; we’re doing steampunk in cyberspace — and they said it couldn’t be done.

Conclusion

Gosh, thanks for reading, and gosh I hope it was useful! I am very certain there are one thousand and one enhancements that could be made for this puppy, so if you’d like to hit me with the Um Actually To End All Um Actuallies, shoot me an email. Like I mentioned earlier, I’d also love to make this article serve Windows and Linux users, so def get in touch about that too :D

Using focal points, aspect ratio & object-fit to crop images correctly

Henry Desroches — Sun, 19 Feb 2023 03:27:00 GMT

Before I even get into the impetus for this blog post, if you came from a search engine and you just want the code, here’s a demo. Pleasure doing business with you.

Introduction

In a client’s project recently, I found that their Wordpress setup required content editors to upload four separate versions of a blog post’s featured image at varying dimensions to ensure a correct appearance in the many contexts that the post will be displayed in (i.e. homepage feature, blog list item, blog post page, social media sharing). Most of these images were getting created with the crop tool in GIMP or Photoshop, and not every content editor felt empowered to create all these images, so publishing timelines were getting pushed back waiting for the images to be generated. This is the sort of thing we can solve with modern CSS, so let’s do it! Don’t touch that dial!

Choosing a focal point

There are many solutions for implementing a focal point selector on images in Wordpress (other content management systems are available), but for the purposes of this tutorial, we’ll create an imitation focal point picker that uses client-side JavaScript to imitate what a back-end tool might do.

Because this part isn’t useful beyond this tutorial, I’ll breeze through so we can get to the actual CSS Tricks (other web development blogs are available).

TL;DR, we’ll display our image in HTML, listen for click events on that image, and use the position of each click to set a --focus-x and --focus-y CSS variable on the :root of the page. In a product implementation of this, it’d be better to be more specific and set those CSS variables somewhere that “focus-x” makes more sense, but since we’re using the same image many times on this page, document.documentElement is okay.

<img
  class="source-image"
  src="https://images.unsplash.com/photo-1676486694880-230d58890871?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8"
/>

const sourceImage = document.querySelector(".source-image");
sourceImage.addEventListener("click", (event) => {
  const rect = event.target.getBoundingClientRect();
  const xCoord = event.clientX - rect.left;
  const yCoord = event.clientY - rect.top;

const xAsPercentage = (xCoord / rect.width) _ 100;
const yAsPercentage = (yCoord / rect.height) _ 100;

document.documentElement.style.setProperty("--focus-x", `${xAsPercentage}%`);
document.documentElement.style.setProperty("--focus-y", `${yAsPercentage}%`);
});

Now, clicking the source image should give us some output like:

<html style="--focus-x:64.2862%; --focus-y:35.5263%;"></html>

Using Aspect-Ratio To Size Images

Now let’s create a few example images that can represent those use cases we described at the start. We’ll imagine we have three potential use cases for this image:

A wide landscape homepage hero, 16:9 dimensions in the design file we’ve been given
A square thumbnail for a blog list item
A 3:4 portrait view for each individual blog post page

We’ll write some HTML for these examples:

<article class="homepage-hero">
  <img src="the same URL as the one before lol" />
</article>

<article class="blog-list-item">
  <img src="..." />
</article>

<article class="blog-post">
  <img src="..." />
</article>

Now, some accompanying CSS. We’ll first use a property called aspect-ratio, which takes an aspect-ratio expressed fraction or decimal.

article > img {
  aspect-ratio: var(--aspect-ratio);
}
.homepage-hero {
  --aspect-ratio: 16 / 9;
}
.blog-list-item {
  --aspect-ratio: 1 / 1;
}
.blog-post {
  --aspect-ratio: 3 / 4;
}

This is doing something, but our images are a little squished. That’s where object-fit comes in. We can use object-fit similarly to background-position, setting it to contain or cover to keep it from stretching. The default value is fill, which will always stretch an image in any direction it needs to in order to fit the rendered aspect ratio of the image. We’ll use object-fit: cover; because we always want images to completely cover their rendered aspect ratio, we just don’t want the deformation.

article > img {
  aspect-ratio: var(--aspect-ratio);
  object-fit: cover;
}

The images are looking a lot better now, but hark: in some of the images, the subject of the image is cropped out strangely. Let’s sort that.

Using the focal point in image positioning

Now we can use object-position (similar to background-position) to move the image until the thing we’ve decided is most important is in frame.

article > img {
  aspect-ratio: var(--aspect-ratio);
  object-fit: cover;
  object-position: var(--focus-x) var(--focus-y);
}

That’s more like it. There’s a problem that used to take a couple minutes per post in an image editor, more-or-less solved with fifteen lines of CSS. Golly gosh is it a good day to be working on the web.

Possible improvements

You’ll find in some cases that setting a focal point in the corner or edge of an image doesn’t work perfectly — the selected point will always be in the image but it won’t always be centered in the image. I briefly tried to work out how this could be solved with exactly our markup and existing CSS, but I think there’s more to it. By my estimate, roughly what would need to happen is:

Wrap the image in a <div> with the same aspect-ratio value as the image, and make sure its overflow is hidden.
Figure out how far the focal point is from the center of the rendered image container.
Translate the <img> by that distance so that the focal point is in the center.
Additionally, scale the <img> by whatever factor is necessary fo ensure it still covers its parent. (I think the math would be something like: if you translate the image left 10%, you’ll need to scale the image to 120% in order to account for that movement.)

Conclusion

Anyway thanks for reading. As always, feel free to shoot me an email if you have further questions, need to make a correction, or think my cool hat is stupid. I’m also on Mastodon. CSS is sick, skate fast, have a blast.

On leaving New York City

Henry Desroches — Sun, 12 Feb 2023 17:00:00 GMT

This Is That Dreaded Blog Post That Was Foretold

Every blog poster fears that one day this post will be upon them — that painfully self-important and -unaware “Why I’m Leaving ${city}” post. I’m gonna try to do this right; to make this one on the less-obstinate side to some of the other ones I’ve seen, but unfortunately I may make no promises, and you’re on my blog.

I’ve tried to write this post for a few weeks, and each time it just gets longer and more ambling and less clear, so I’ll keep this short for now and update periodically. The general rundown is: why did I move to New York, what did I find here, why am I moving back to Denver, and how will it all matter in the context of my life?

Real talk, this one is mad self-indulgent, and has almost nothing to do with websites. You’ve been warned.

That’s New York babey

I moved to New York City towards the start of the pandemic, after the Tiger King Era but before the Vaccine Era. Every movie I loved had a Central Park in Autumn scene, every post-punk revival band that got me through high school had some song about New York; there’s so much cinematic and cultural lore to the city, and I had known for a long time that I wanted to be part of it. New York is a town full of brave and confident main characters — when the isolation of the pandemic set in and I started to lose my senses of meaning and self, it felt like it’d be a good place to find them again.

We’re getting to the overly philosophical part. Bear with me, keep your lantern on the path.

But people are more than the place they live, and it turns out you cannot just update your home address as a proxy for a personality. I did not immediately find who I was meant to be the moment I drove into Manhattan, and that was challenging.

I started experimenting with aspects of my life, an exercise I understand now was meant to test what parts of my Self are durable and valuable. Accidentally at first, then maybe too intentionally, I began to ask myself a torrent of questions — what pieces of my personality am I proud of? What pieces may I leave behind? For example, is my sober lifestyle still important to me, or am I still glad to be a vegan? Do I like dancing? Am I a kind person? Will I look back at the way I’ve spent my time with pride, or with disappointment? Does a man decide he is a certain way, or is that decision made anew in his every act and action?

A thousand years and two apartments and millions of everything bagels and one copy of Viktor Frankl’s “Man’s Search For Meaning” later, I still felt as listless and as confused as when I left Denver, and realizing that was clarifying. I’ve come to understand in the last six months two things:

If I am to be made, I must do it myself — ${city} cannot do it for me, and
If I am to continue to make myself, I’d like to do it out West — it’s time to follow the sunsets back home.

Go West, Young Man

Philosophically, I’m moving back to Denver because New York answered for me empirically that I will not find an end to the deep, gnawing sort of yearning for Something I’ve always wrestled with in a new map location. And more terrestrially, I’m moving because I miss the good weather and the mountains, I miss the tight homies, and I miss my folks.

I’ve always been enamored with the staggering drama of the Rockies and Wild Western skies and I do think it was goofy to deny myself access to those things. There’s a great Cy Warman poem¹ where he identifies the unique feeling of being in the Rocky Mountains:

And when I walk where the flowers talk
I just feel good all over.

I miss my friends, the DIY punk kids and queers and cyclists and car nerds and Arcteryx hiking fiends. New York has all types of people; in fact I’m sure there are these sorts of people here too, but they’re not my people like these old Coloradan friends. You can’t replace your community.

Finally, I’m honestly a huge mama’s boy, and it’s taxing to be so far away all the time. I love my parents. I’m proud of the life they’ve built for themselves, and I want them to witness enough of my life to be proud of me too. The monthly phone calls home ain’t cutting it.

The Bittersweet Part

There’s something poignant about saying goodbye to a city like New York. It’s taken me months to shake loose the fear that I’m somehow giving up on a version of myself I fantasized about being for years. I’m still learning to part with all those imagined futures of SoHo loftdom and weekly West Village diner mornings and painfully-well-dressed see-and-be-seen Central Park walks.

It’s the hidden cost of romanticizing and daydreaming about a million possible lives: you can live all of those lives a little bit if you want, but never at the same time. I think the growth I need to do here is getting comfortable with viewing my lifetime as a collage of lifetimes. It’s the end of this NYC chapter for now, but not necessarily forever, and the tapestry becomes more thoroughly woven with each life I weave into it.

I think I can say this in a more resonant way if I think more carefully about it. Line?

The Actually Constructive Part

At the end of the day, it’s not that useful to spend my entire life yearning, and it makes me feel threadbare. I don’t regret moving to New York even the tiniest bit — I’m grateful for all the soul-searching and adventures and friendships I can’t wait to make last a lifetime.

There are things about New York I adore and will miss dearly, and I’m sure there are things about living in Chicago or London or Mexico City that I’d adore too, but I don’t want to spend the rest of my twenties driving Uhauls and checking the greenness of the grass. It is in my control to actualize the life I want. So here’s the plan:

Wrapping Up This Chapter Right

I dread the thought of returning to Denver and realizing all the things I ought to have done while I was still in NYC, so I’m minmaxing NYC in the weeks I have left. I’ve made a New York City Bucket List that I’ll keep updated even after I’ve moved away. This city is an infinite playground of new experiences to have — in a dozen lifetimes I will not know all the wonder NYC has to share, but I’m gonna do my best. I want to meet everyone here I haven’t yet (get at me lol), and otherwise spend as much time as possible on an adventure.

Urbanism and Civil Engagement

The thing a lot of these Why I’m Leaving City posts get wrong is that the way to live in a city is to invest personally in its development. It is each of our responsibilities to engage with your community and help make it safe and wonderful and accessible for everyone. The things about the city of New York that still excite me most are the trains and the diversity of experience:

You can take a $2 train 30 minutes from my Upper East Side (xoxo) apartment and make it most of the way to any neighborhood in the city, and that’s almost more liberating than owning a car and having access to the entire American interstate system. Denver is a great city and they’ve made leaps with their transit system over the last 10 years, but there’s plenty more progress to be made. I’m resolving to spend my first year back getting involved in the Coloradan public transit infrastructure community, and working to get more accessible, comprehensive, and publicly-funded transit built.

Secondly, you can meet so many thousands of types of people in New York — every time I leave my house I discover a new sort of wonderful and spectral person, and I want to find that sort of diversity and community in Denver too. This is a much more complex pool to wade into as an individual than the aforementioned “lol just build more trains forehead”, but I think I can focus my efforts firstly in the scope of my new neighborhood; as Pratt Institute professor Courtney Knapp writes:

As a unit of planning, the neighborhood is the most important in terms of promoting social diversity and increasing social capital. It is conceptually broad enough to get individuals to think beyond themselves and their streets, but of a small enough scale to still support the notion of “neighborliness” and encourage collaboration between community planners and stakeholders.²

Specifically, I think my background in web design and development can be useful for event programming and outreach — there are always better email newsletters to program and event websites to be built.

Conclusion

Anyway, thanks for reading, I think that’s all I’ve got in this particular gasping breath of a blog post. If you’d like to chat about this one, or make a friend in New York or in Denver, feel free to shoot me an email. If you’ve got recommendations for Things I Absolutely Must Do Before Leaving NYC, I’d love to hear about those too, either via email or via the form on nyc.henry.codes. I’ll keep a running changelog as I inevitably decide to do more rolling down this hill and subsequently update the post.

Can you be a designer if you have no training?

Henry Desroches — Thu, 09 Feb 2023 18:00:00 GMT

I recently saw an online acquaintance of mine share a Controversial Opinion™ that I found challenging:

If you do not have formal training in design you are not a designer.

Right off the bat — L take, and I’m trying not to say that just because I am a designer with no training (lol). I think there’s more ways to be critical here than just being like “haha ok then how me doing design rn”, though. I’d like to interact with this fairly and in good faith, so for the purposes of this blog post, I’ll assume best intentions by the author of the opinion.

I didn’t link the post here because I don’t have any interest in either A. oxygenating platforms I don’t believe in, nor B. dunking on folks who I think just missed the mark.

Design isn’t a thing

Modern design—especially on the web—is just problem-solving. It’s the act of thinking carefully about the way systems and products will work, discovering potential or empirical failures in those systems, and proposing functional solutions. A lot of folks (me) get hung up on the fonts part of Being A Designer, but in earnest, the visual aspects of design e.g. color and type and rhythm and layout just serve to solve a problem, which is that communicating information clearly and memorably is hard.

If this is our framework for understanding design, then design happens in a thousand little ways every day by non-designers. When folks choose the order of items on their restaurant menu, or make the newsletter for their community theater, or rearrange their living room to flow more naturally, they’re thinking about a system and enacting improvements to it. These are just people, though — they’re not necessarily academics nor are they necessarily not, but despite the lack of training in or even awareness of design thinking and discipline, they’re doing design.

Designers aren’t a thing

The threshold for design is care and consideration for problem solving, not formal steeping in impermanent design tools, not a slick BFA from RISD. “Being A Designer” is a mechanism we use to allow people who enjoy the exercise of that considerate problem-solving to do it for a living, but that’s the extent of its utility as a title.

The societal value of someone who spends a lot of time doing design is that they’re practiced in applying frameworks of analysis to problem areas. For example: one turns to a financial advisor because the advisor is practiced in translating financial goals and concerns into investment and wealth management strategies; one turns to a web designer because the web designer is practiced in translating business goals and concerns into web-based solutions.

A really good designer is good because of their aptitude and willingness firstly to discover and constrain the shapes of problems, and then creatively apply different approaches until an amicable solution is found. A really good designer is not good because they know the most about Figma or the best type foundries, but because they’re dedicated to being curious and good at listening.

Controversial opinions aren’t a thing

This is the least fair and least relevant and least-principled part of this analysis, so feel free to skip to the end bit.

Earnestly, I’m a bit allergic to Controversial Opinions online. In real life, when you form an opinion, you tack it together from inputs you value — a recent article from an expert or a conversation with a close friend — and then you try it out in limited social circles. You ask your friends or colleagues what they think about the new opinion you’ve made, and you reshape it based on the feedback you get.

Being Online shortens and malforms that process, however. For example, when a friend responds poorly to an idea you have that they disagree with, they are likely do so in a kind way. Or when a subject matter expert responds poorly to the idea, they might do so critically and with discipline, and those two safety measures allow you to safely haul your opinion back to the shed for some reworking, or maybe out to the junkyard if you find it to have no durable substance.

But posting online removes those safeguards, and the shape of discourse on Twitter means you don’t get to carefully or with nuance respond to criticisms. In the land of quote retweet dunks, “controversial” opinions can just be wrong ones. Be careful.

Conclusion

Anyone can be a designer, and anyone can engage with design thinking (academic purists HATE him). Tooling is irrelevant, and training has value only to the extent that it makes you a more flexible and curious problem solver, or more fluent at knowing when to reuse tried solutions. “Designer” the resume title is a mechanism for collecting a paycheck, but you don’t need the title to delight in designing caring and considered solutions for your day-to-day work.

Anyway, thanks for reading. If you hate this counter-take, feel free to dunk on me online (as long as it’s funny), or (preferred) if you have ideas of how I can improve it shoot me an email.

How To Make a Website

Henry Desroches — Tue, 17 Jan 2023 03:31:00 GMT

I got an email recently from a kind online friend who said they thought my work was swell, and that they’d like to ask about my process or what makes a good website. Aside from that being a really nice email to receive, it’s also good impetus for me to be a little more candid and critical about my practice. Here’s my breakdown on how to make a Good Website.

It’s fine if you disagree with me on these things — let me know by email what great sins I have committed against thee and I shall dearly repent :)

TL;DR

Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.

A Brave New index.html File

HTML is meant to communicate document structure and information, and it does a really good job of doing that if you let it. Before starting the styling steps of any project, I write all of my pages out from a content document or design file completely in HTML. I find this reveals a lot about interactions that need to be considered and information architecture that isn’t quite ready for prime time. Even if I’m using some SPA framework, I’ll still start by communicating the entire document with HTML alone, because I’ve found it’s that much clearer when it’s time to break the markup into whatever the component style du jour happens to be.

Get creative with tagging. There’s a world beyond <div‍>s and <span>s (though sometimes these are exactly what you need) — don’t forget about the <main>s and <section>s and <aside>s for laying out content, and the <time>s or <abbr>s or <dl>s for communicating more complex data. Spend some time reading about elements in MDN, or even the HTML spec. Let yourself discover the breadth of the language. Every week you’ll discover something new you could’ve been using this whole time.

Don’t worry about class attributes just yet, but do worry about semantic attributes like those needed to make a <form> work properly. We’ll hydrate our markup with CSS as needed; now’s a good time to be certain our website is bulletproof from a semantics perspective.

If, in this process, you discover your document is confusing or ordered incorrectly, this is the perfect time to address that. CSS has a lot of superpowers when it comes to layout these days, so consider whether it’s possible to write the HTML in the correct flow and solve for unique challenges with style code down the line. If it’s not possible, that might be a good sign to talk with your designers about their intention. Often you’ll find that something that doesn’t make sense from an HTML perspective was an afterthought, or might be better served somewhere else!

A Note On Accessibility

You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.

You’ll further find that once you’ve gotten used to spec-diving, the WCAG can be a really fun way to give yourself and your users wins. The more time you spend looking for and fixing accessibility issues, the more clever you’ll feel when you start to preempt them on your next project.

It’s important to note that making sure users of all stripes (not solely the ones your product manager has deemed important enough) can be successful using the things you create is literally, like, the job. Designers will do their best to discover issues beforehand, testing and interviews can solve issues later in the process, but at the end of the day, your hand is the one that brings The Thing into being. Bringing accessibility expertise into your stables will make you an extremely formidable developer, it’s a consistent value-add to any project, and it further makes you a far better citizen of the internet.

A Note On Communication

This isn’t HTML-specific, but this advice has taken me further than any blog tutorial ever has:

Be kind and curious and humble when you’re working with folks, and be extra forgiving of their mistakes, so when the time inevitably comes that you make your own, there’s perhaps some goodwill in the vault for you. This might not seem like a consideration for “How To Make A Website”, but making things for the internet takes a village, and you’ll be astounded how much you naturally become a better developer if you default to listening and checking your ego. That’s been a hard lesson to learn, especially the more I feel confident in my ability as a web developer, but it’s certainly been one of the more valuable ones.

Personal Tooling

These days (late 2022, early 2023) I primarily use 11ty to build websites, because it has a very low level of opinion and abstraction — it provides lift where I need it without deciding HOW it ought to provide lift. Its primary use in my development process is merging content with templates. I can use flat files like markdown, query content APIs like Wordpress or Contentful at build time, etc, and serve static HTML to users with no client-side JavaScript payload.

I usually use either Nunjucks or Vue for template logic as they’re both extremely similar to HTML (abstraction is the devil). I default to the former for simpler projects with less data massaging or for projects with collaboration with non-Vue developers. 11ty makes Vue feel great — I can write filters and computed data and interpolations without serving any client-side Javascript to users.

Nunjucks is a first-class citizen in 11ty, but I’ve also written a (possibly slightly out-of-date) guide on using Vue templates in 11ty:.

Category: tutorial
Tags: vue | eleventy | static site generation

How to use Vue to template your Eleventy projects

Reading Time: 4 minute read
Last updated: Last updated December 17, 2021

Style Code (or How I Learned To Stop Worrying and Love The Cascade)

There’s no need to fear CSS. It’s not the language it was in 2012, rife with vendor prefixes and secret hacks to trick it into solving your layout problems. Between the CSS grid API and container queries and custom properties/variables and scroll timelines and filters and layers and math functions, there’s hardly a thing one needs Javascript for these days.

A Quick Thing About Preprocessors

I still use Sass for most projects! It’s still really good! Leveraging the file structure, nesting architecture, and $ tokens maintains its place as a super high value member to any CSS tooling.

Be wary of over-nesting and getting clever with Sass features — as with all aspects of code, it’s better to be readable and clear than it is to be smart.

Methodology

When you’re getting into to writing CSS, my advice is to avoid frameworks but embrace method. In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework. If you need to get a simple documentation project out the door yesterday, you may find a framework can be a great tool, but without exception I find frameworks hinder learning and discovery in CSS. IMHO, you’re better off learning what pieces or patterns you’re not confident implementing quickly. You may be surprised how little the frameworks are actually giving you.

As far as methodology goes, I dare not tread too deeply in these contentious waters — really, whether you elect for BEM or CUBE or OOCSS or Tailwind or SMACSS or whatever, the important thing is that you think carefully about that choice before making it. If some aspect of a methodology feels confusing, make sure you’re prepared to explain that aspect with patience and empathy to any collaborators. Try to weigh methodology by its level of abstraction, the learning curve for implementation, and the additional tooling it requires.

I personally use BEM for almost all projects, for a couple of reasons:

The overhead for learning BEM is knowing that __ means a child of a block, -- means a modifier of a block, and if you have more than one of each delimiter in a selector, it’s time to start a new block. That’s usually pretty straightforward to communicate as quickly as I just did.
It’s clear from looking at a well-named BEM block in CSS what its HTML counterpart is meant to communicate. For example, selectors for .card and .card__title and .card__thumbnail and .card__thumbnail—-small probably represent some sort of card, the card’s title, and two possible states for a card image.
At the same time as the structure is visible by the class naming, BEM CSS also doesn’t care what tags are actually in use in the HTML. (See my note about the cascade below.)
It plays extremely well with the & operator in SCSS. Note that we get the visual organization of nesting without the steep specificity increase.

.card {
  &__title {
  } // .card__title
  &__thumbnail {
    // .card__thumbnail
    &--small {
    } // .card__image--small
  }
}

The inherently low specificity means its easy to override, which is good for cases where you don’t have complete control over markup. For instance, I often have to render some markdown as HTML inside a container. To style that new HTML, all I need to do is style the cascade one level of specificity higher:

.blog-article {
  &__title {
  }
  &__content {
    p {
    }
    blockquote {
    }
  }
}

A Note On The Cascade

Candidly, I’m still navigating my relationship with the cascade. I first enjoyed BEM because it fully sidesteps the cascade and that feels simple to me. However, a lot of smart people that I know laud the benefits and misunderstood nature of the cascade; that makes me think I might be wrong about my election to minimize cascades in my CSS. If you’re a few steps ahead of me and ready to love the cascade once more, I highly recommend Andy Bell’s writing on CUBE CSS, a methodology that balances the best of all worlds between cascade inheritance, block-scoped styling, and utility CSS.

Mobile-first style

This is one that I think gets talked about a lot but that I rarely see folks implement devoutly, and I promise it will make your life easier for writing style code: Always style from the absolute smallest screen your content will be rendered on first, and use @media (min-width) queries to break to layouts that allow for more real estate as it becomes available. Bugs are fewer and further between, and debugging them feels much simpler to me since adopting this approach a few years ago.

If your design doesn’t account for mobile, that’s alright — this is a great opportunity to be creative and think about how different aspects can work on mobile. Do you absolutely need a toggleable navigation bar? Can our three column layout fit meaningfully in two columns, or one?

Stateful CSS

Now’s also the time when you can start prebuilding some of the interactivity that will come with Javascript. Think about all the states that a given interactive element will occupy, and how much of that dynamism can be offloaded from Javascript. Can you implement all states by simply changing the class on an element? Can you manually choreograph your animations with @keyframes, or will you need JS to calculate FLIPs, etc? This consideration will make debugging your JS much easier when we get there.

I’m not 100% certain that I’ve said my piece about CSS as comprehensively or as clearly as I’d like to. Stay tuned, this post may evolve, or yet sequels may utter from these delving mines of content management.

Interactivity and Complex Animation with JavaScript

By this point, our website ought to be lookin’ pretty good, pretty durable, pretty handsome in a dangerous sort of way. As the fashion of the web stands, the things that make websites feel really cool beyond clever screen design and good fonts tend to be in the realm of JavaScript interactivity. Tread lightly as we make our way into these woods. A little JS goes a long way and too much will ruin your project, for your users and for your own enjoyment of managing the code!

Before getting involved in earnest with JS, it’s important to know the facts; great power, great responsibility and all that. I highly recommend you read @malchata’s Responsible JavasScript, which gives a very human-friendly and thorough framework for understanding performance and browser rendering, how you can help JavaScript do its job better, and how you can improve your users’ experience with your site.

A Note On Progressive Enhancement

I try to apply an attitude of progressive enhancement to all aspects of my work — make your project work on the most inconsistent connection, on the smallest screen, for the least able user, and build gracefully upon that foundation. That applies to your HTML, it applies to your bleeding-edge CSS, it applies now to your JavaScript.

This might make me some enemies but my enemies are dorks, so: If your site doesn’t work without JavaScript, your site doesn’t work. It’s not hard to be careful and resourceful in your application (lol) of JavaScript, and constraint makes creativity bloom.

How can you ship fewer bytes? How can you defer some interactivity? How can you let a server handle some computation instead of making a browser do it? These are fun problems to solve, and I found the glee I got from It Just Works-style automagic heavy-duty JS libraries and frameworks, i.e. JS-first development, I started to get threefold from instead shipping projects that I knew loaded fast, and loaded on any device or connection imaginable. It’s just an attitude thing IMO.

Animation

There are a lot of animations that are too complex or unable to be triggered with CSS alone. For those complex animations, I recommend getting your hands dirty with GSAP. The version 3 API is super streamlined and feels very accessible to new and seasoned creative developers, and that support community is one of the kindest you’ll discover online.

Be kind in return! Those that manage the GSAP Forums will be sainted before the decade is through!

With GSAP, I typically organize my code in separate files and just bundle using Rollup or similar. I’ll use a file structure something like this:

.
├── index.html
├── css/
└── js/
    ├── main.js
    ├── animations/
    │   ├── cardReveal.animation.js
    │   └── homepageScroll.animation.js
    └── transitions/
        ├── home.transition.js
        ├── blog.transition.js
        └── default.transition.js

Then if I want to do something like use an IntersectionObserver to reveal the cards when they arrive on the page, it’s easy to do something like this:

// main.js
import { CardRevealAnimation } from './animations/cardReveal.animation';

const revealHandler = (entries, observer) => {
  entries.forEach((entry) => {
    const animation = CardRevealAnimation(entry.target);
    animation.play();
    animation.eventCallback('onComplete', animation.kill);
  });
};

const revealObserver = new IntersectionObserver(revealHandler);

[...document.querySelectorAll('[reveal]')].forEach((el) =>
  revealObserver.observe(el)
);

Transitions

The thing about single-page apps that seems like a killer feature for a lot of JS-first devs is page transitions. Almost nothing* makes a site feel cooler than doing a really slick hide timeline, updating the URL, and subsequently doing a really slick reveal animation of the next page.

*Shaders.

But hark — we’re in dangerous territory again. Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing. You know as well as I do how miserable it is to be hung up between pages because the JS-powered router failed. Be very careful.

There are a lot of ways to do the partial AJAX SPA-style of routing we’re talking about, but my preferred way lately is Taxi.js, and I just mount GSAP timelines between pages. GSAP tends to be very powerful for this style of animation, cause oftentimes you’re looking to bring an element from somewhere but you don’t necessarily know where, and GSAP has both .from or .to methods for seamlessly switching back and forth between known positioning and unknown positioning.

Conclusion

I’d like to make this rant into a resource, more robust guidelines, etc. If there’s something I didn’t cover that you’d like to learn about, something I did cover that I didn’t cover well enough, or if you just think I’m wrong and stupid, please don’t hesitate to hit me up via email or on Bluesky.

Candidly, I hope this hasn’t felt too pedantic or peremptory. Websites are fun, the internet is a gift. It’s important to remember the experience of your users is ten thousand times more important than your developer experience. Have fun, be safe, protect each other, and don’t talk to cops.

How to distort text with SVG filters

Henry Desroches — Fri, 23 Dec 2022 00:33:00 GMT

A lot of the SVG filter primitive content out there is some really rad, deep-dive type content (I’ll link some of these at the end!), so I reckoned it might be nice to do a quick write-up on some effects I use pretty commonly. These are more-or-less plug-and-play; simple filters for making your friends go “ooh how did u do that lmao”.

Setup

To kick this off, all we need is a super simple HTML file with a place for our CSS. We’ll create some placeholder text and an empty SVG tag.

<style></style>

<svg></svg>

<main>
  <p>
    Lorem ipsum dolor sit amet consectetur adipisicing elit. Ratione cum
    inventore ea quaerat, maxime at! Debitis consequuntur reiciendis vero
    dolores, rem asperiores ut quo provident saepe ex ipsam sed culpa.
  </p>
  <!-- ... -->
</main>

We’ll write a little CSS for now just to move our SVG out of our layout — we don’t actually need the SVG to render anything to the page, we just need it to do its magic filter math. Watch out, though: display: none; will hide the effects of the filter too.

<style>
  svg {
    position: absolute;
  }
</style>

Creating the filter

Next we can add to the SVG to start our filter composition. We’ll add a <defs> tag and a <filter> tag — the <defs> actually isn’t necessary here since a <filter> won’t render anything on its own, but it’s a good indicator to future developers that “hey, this won’t be directly rendered anywhere,” or “hey, this will be used later”. We’ll give the <filter> an ID so we can call it in our CSS later.

<svg>
  <defs>
    <filter id="distort"></filter>
  </defs>
</svg>

To create the actual distortion effect is twofold — we need to first generate some random noise, then take that noise and move around pixels based on its output. If you’re new to composing SVG filters, I like to use the guitar pedalboard metaphor: you have a bunch of different effects available to you (in the form of “filter primitives”), each unique and configurable, and you pass a signal through them in any order to update that signal along the way. Hopefully the output is sick :)

Generating noise

For this example, we’ll use the <feTurbulence> primitive to generate noise. You can read more about that bad boy here. We’ll give it a tiny baseFrequency for both x and y axes — you can play around with these values to get different effects once we’ve activated the filter. Higher values will make more thoroughly grainy noise! We’ll set numOctaves to 1 for now, though increasing the number of octaves will smooth the noise output. For this example I want it to look kinda janky. The last attribute we’ll add is result, which is an identifier so the next filter primitive can use the output of the turbulence. You can call it whatever!

<svg>
  <defs>
    <filter id="distortion-filter">
      <feTurbulence baseFrequency="0.01 0.01" numOctaves="1" result="noise" />
    </filter>
  </defs>
</svg>

Using a displacement map

Now we’ll use an <feDisplacementMap> primitive to move around the actual pixels of the text. This takes a few input attributes:

in is your primary image input. We can use the keyword SourceGraphic — this means it will displace whatever you apply the filter to, whether that’s some text, an image in your HTML, or some other SVG element.
in2 is the pixel data to displace the image we just added. We’ll take noise as our input 2, as that’s the result of the first primitive we created.
scale is pretty straightforward; you can use any number. I usually tweak this logarithmically to find the effect I want (does 1 work? how about 2? how about 10? 50? 200, etc). We’ll use 10 here.
xChannelSelector and yChannelSelector tell the displacement map to grab the pixel values from one specific RGBA channel to displace. Since our pattern is totally random, we can use the same channel for both, but if you’re using normal maps or more complex displacement, you might need different values!

<svg>
	<defs>
		<filter id="distort">
			<feTurbulence baseFrequency="0.01 0.01" numOctaves="1" result="noise"  />
			<feDisplacementMap in="SourceGraphic" in2="noise" scale="10" xChannelSelector="R" yChannelSelector="R">
		</filter>
	</defs>
</svg>

That’s actually all we need for the filter! The more time you spend with filter primitives, the more easy it gets (usually) to read at-a-glance what a given filter is doing. Some people write some insane filter shit tho — the difference between “I completely understand this” and “I am a baby-brained fool” can be pretty narrow in my experience. The sky is really the limit with this stuff.

Applying the filter

Now we can go into our CSS and apply the filter using that ID we created in the first step!

<style>
  /* ... */
  main {
    filter: url(#distort);
  }
</style>

Hell yea. So sick. The text is even still cursor-selectable. Feel empowered to tweak values and add primitives. There’s a whole world of wonder and image processing to be discovered.

Bonus: Motion blur with filters

Since we’re feeling so capable and technologically-enabled, let’s run another one. This one’s even simpler from an SVG standpoint. We’ll create another HTML snippet, just like the first one, but with some added CSS to do some clever text overlapping:

<style>
  svg {
    position: absolute;
  }
  h1 {
    position: relative;
  }
  h1:before {
    content: attr(data-text);
    position: absolute;
    top: 0;
    left: 0;
    filter: url(#motion-blur);
    opacity: 0.5; /* not necessary, just nice to soften the effect :) */
  }
</style>

<svg>
  <defs>
    <filter id="motion-blur"></filter>
  </defs>
</svg>

<h1 data-text="This is a title">This is a title</h1>

Adding the blur

Next, we can add our primitive to blur the text. For now we’ll blur horizontally cause that’s fairly simple to accomplish.

To blur at an angle, one might need to do a little Involved Mathematics to rotate/skew/counter-rotate the SourceGraphic, and it’s out of scope for this particular post :)

<svg>
  <defs>
    <filter id="motion-blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="10,0" />
    </filter>
  </defs>
</svg>

There’s a great post by Lucas Bebber on how to bind this effect to actual animation, if you’re interested in taking it a step further! I’ve linked that post in the last section.

Conclusion

Anyway thanks for checkin’ out the post. If you have any questions or you found a typo that you absolutely will die if I don’t correct, hit me via email or on Mastodon.

How to use Contentful with Eleventy

Henry Desroches — Thu, 23 Dec 2021 07:00:00 GMT

Contentful is an immensely well-featured headless content management system, but the density of its featureset can be daunting to integrate with static site generators. The great news is, Eleventy is so well-designed and modular — it doesn’t have to be nearly so challenging.

TL;DR

Contentful has a REST content delivery API and a GraphQL API. This post covers using the REST API to query blog posts from Contentful and render the returned data in an Eleventy project, as well as create multiple pages from that data.

What about GraphQL?

Okay, I meant for this to be one paragraph about why I’m just covering REST but it ended up being kind of a lot, feel free to skip this section lol.

I know a lot of folks find GraphQL quite useful! That’s very nice, but for now I’ve only elected to use a RESTful integration of Contentful, for a few reasons.

My understanding is that GraphQL excels when dealing with multiple data sources, or when trying to be thrifty with bandwidth on the client-side. It provides these optimizations at the cost of additional infrastructure and complexity.

As far as reducing bandwidth goes, it’s a non-issue here — since Eleventy makes its data requests server-side, it’s not critical for us to be so frugal with limiting requests because the user will be served flat files and no client-side JavaScript payload nor client-side requests after the fact.

Lastly, in terms of proliferation, nearly 82% of API practitioners and consumers use a REST style, according to SmartBear’s 2020 State of API report, whereas only 19% use GraphQL. That’s still a sizeable chunk to be sure, but it’s at least self-evident that the likelihood you’ll be integrating a GQL API with Eleventy any time is smaller than a RESTful one.

Creating a Contentful content type

This post assumes you’ve already created a Contentful Space — if you haven’t, I recommend you head over to read about how to get started with Contentful.

Let’s begin by creating a content model — in this tutorial, we’ll create a simple blog-style article. When logged in to our Contentful space, click “content model” and then “Add content type”. You can call this a “Blog Post”, and just use post as the API identifier. Feel free to use whatever you want as a description, or skip it entirely.

If you’ll have content editors in the dashboard that aren’t you, it’s good manners to leave a meaningful description of what this content model will represent, not matter how obvious it might be to you.

Now we can add some fields. For this example, let’s add some Text, Date, Media, and Rich Text fields, in the form of a blog title, publish date, featured image, and body.

Some things to note as you add fields

Make sure the Title is designated as the Entry title in Contentful.

When adding the rich text body block, I’m disallowing hyperlinks to other entries, links to other assets, or embedded entries/assets, inline or otherwise. There are some aspects of this sort of extension of Contentful that are extremely powerful but require some additional setup to render.

Once you’ve added each of these fields, you’ll have something like this.

Now let’s create a blog post using this content model and populate it with some placeholder content that we can query and render on the Eleventy side.

Switch to the Content tab and click “Add entry”. When prompted, select the Blog Post content model type. You can fill all of these fields with lorem ipsum, or use an actual blog post if you want! (I’m intentionally using different text formatting options in the body so I can take full advantage of the HTML renderer we’ll be leveraging later.)

That’s all we’ll need from the Contentful side until we get our Eleventy site going, at which point we’ll need to come back to this dashboard to get some API credentials!

Creating an Eleventy project

You can start from scratch or if you’re an old Eleventy pro, you can skip down to where I write about requesting data from Contentful.

Initial setup

First, you’ll create a new directory for the project to live in, initialize it as a Node project, and install some dependencies. In your terminal, run the following:

mkdir eleventy-contentful-tutorial && cd eleventy-contentful-tutorial
# fun fact, if you're on a Mac you can just do `take eleventy-contentful-tutorial` to create and immediately navigate into a directory.

npm init # you can use the -y flag to skip the init setup

npm install --save-dev @11ty/eleventy contentful @contentful/rich-text-html-renderer dotenv

Since all these dependencies are used to build the site, and not served in production (11ty: It’s Just HTML™), we can npm install -D to install these packages as development dependencies.

Let’s quickly create some standard files and directories for an Eleventy instance. Run these commands in your terminal as well:

mkdir _data _includes # create two directories
touch index.njk _includes/layout.html # create two files

In our base _includes/layout.html template, add the bare minimum HTML required to make this example work:

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="UTF-8">
		<title>How to use Contentful with Eleventy</title>
	</head>
	<body>
		
	</body>
</html>

We’ll be using Nunjucks for this tutorial because it’s the most plug-and-play templating syntax and it’s fairly standard throughout the Eleventy docs. You can use all sorts of templating languages with Eleventy, including Vue, if you’re a bit of a whacko.

In our index.njk, we’ll add some basic Nunjucks code to specify that we want to use the layout.html file, and then render some text.

---
layout: layout.html
---
<main>
    <h1>A brave new world, indeed.</h1>
</main>

Now, you can run npx @11ty/eleventy --serve to start hot-reloading this Eleventy project at localhost:8080.

Requesting data from Contentful

With Eleventy, you can use JavaScript files to make requests to data sources at build time. We’ll create our first file to request all of our posts (or, just the one, I guess) from Contentful.

First we need to get some API credentials from Contentful and put those in a new .env file. In your Contentful dashboard, navigate to “Settings” and then “API keys”, then click “Add API key”. For the name, I usually use the URL of the site, but it just needs to be meaningful to you.

Once you’ve saved this, you’ll be given a Space ID and Content Delivery API - access token. Copy those down into a file .env at the root of your Eleventy project:

CTF_SPACE_ID=fnmde2k23...
CTF_CDA_ACCESS_TOKEN=HuKYnGA87XYI0cNM...

⚠️ Don’t ever publish your .env file. ⚠️ It contains secrets. Don’t commit it to git, don’t text its contents to your tight homies.

Creating a Contentful client

We now need a Contentful client with which to ask the content API for posts. Let’s create a file utils.js in the root of our directory and create our client in there, using the dotenv package we installed earlier to reference our local .env variables.

require('dotenv').config();
const contentful = require('contentful');

const contentfulClient = contentful.createClient({
  accessToken: process.env.CTF_CDA_ACCESS_TOKEN,
  space: process.env.CTF_SPACE_ID,
});

exports.contentfulClient = contentfulClient;

When I have multiple content types, I prefer to create the client once and import it in each Eleventy _data file that needs it. If you prefer to re-initialize the client in each file, that’s your prerogative. I’m proud of you for knowing what you believe in.

Creating our request

Now we can create a JavaScript file in the _data directory that will grab all our posts when we run Eleventy. You can call it _data/posts.js so you’ll be able to reference the data it returns as posts in your templates.

// import the client we just created
const client = require('../utils').contentfulClient;

module.exports = async () => {
  // create a request for all entries that match our post type.
  // we can use the `order` property to sort them reverse-chronologically by their published date.
  const posts = await client.getEntries({
    content_type: 'post',
    order: '-fields.publishDate',
  });
  return posts.items;
};

That oughta be working! (You may need to restart your Eleventy script in the terminal.) Now we can render the data in our templates.

Using data

In our index.njk file, let’s add a Nunjucks tag to dump all the data we just requested to the template.

<main>
    <h1>A brave new world, indeed.</h1>
    \{\{ posts | dump }}
</main>

The dump filter saves us from just getting [object Object] rendered to the template, and instead shows us everything in the JSON object. Think JSON.stringify().

Well, that’s a lot, and mostly unuseful. Contentful offers a JSON view of your content models in the dashboard to make this a little simpler to parse, but I’ll simplify the haystack-digging for the purposes of this tutorial.

You can use Nunjucks to iterate over every blog post (which, for now is only one) in the template:

That’s probably looking much cleaner already. One thing you might notice is that I created a link to a page that doesn’t exist yet, using the title of this post and the built-in Eleventy slug filter. We’ll handle that next.

Creating post pages from data

In this section, we’ll cover the creation of a post template that will autogenerate every individual post page.

Start by creating a file _post.njk at the root of your project and populating it with the following frontmatter:

---
layout: layout.html
pagination:
    data: posts
    size: 1
    alias: post
permalink:  "posts/undefined/index.html"
eleventyComputed:
    title: ""
---

Line by line, what we’ve written accomplishes these things:

Use the layout.html file in our _includes directory as our layout.
Create some pagination for every entry in posts. We use a size of 1 because we only want one post per page. We use the alias post to conveniently refer to our post within the template.
Tell Eleventy to put this page at /posts/slugified-title.
Compute the page title from the data and set the title of the page to this.

Next, add some basic HTML to render the data on the page.

---

---
<main>
    <h1></h1>
    <p>Published on: <time></time></p>
    <img src="?w=400" />
    <div>{\{ post.fields.body | dump }}</div>
</main>

There are some quirks to note here as well.

Firstly, it takes some serious drilling to actually access the URL of an image asset from Contentful. There are a few ways around this, such as separate requests, modification of asset objects on request time, or even an Eleventy filter to avoid all this dot notation.
Second, I’ve added a ?w=400 parameter to the image URL to make sure we’re not grabbing a huge image every time. Contentful provides a number of image transformations by URL, you can read more about URL image transformation methods here.
Lastly, looks like that Rich Text body field renders some wild JSON. We’ll fix that next.

Rendering Contentful rich text

The “Rich Text” concept in Contentful is extremely powerful, as it allows you to generate your own renderer and custom overrides for how your content is displayed. For this tutorial we’ll use the stock renderer, and won’t extend it for any special embeds.

We’ll install the Contentful renderer as an Eleventy filter. Create a file .eleventy.js at the root of the project, and add the following:

const { documentToHtmlString } = require('@contentful/rich-text-html-renderer');

module.exports = function (eleventyConfig) {
  eleventyConfig.addFilter('renderRichTextAsHtml', (value) =>
    documentToHtmlString(value)
  );
};

(You can learn more about the Contentful HTML renderer here.)

All we’re doing here is adding a global filter that uses the Contentful renderer!

Now in our _post.njk template, you can use the filter right away:

<div>{\{ post.fields.body | renderRichTextAsHtml | safe }}</div>

Here I’m referencing the body field, passing that to the render filter we just created, and then using the built-in safe filter to tell the template not to escape the rendered HTML.

Looking genuinely exceptional, I’d say. You’re great at the work you do. You’re a champion. I love you. We all do.

Conclusion

Feel free to reach out and touch faith on Bluesky if you’ve got questions about this article. It would be great to expand this article upon finding new challenges folks face with this integration. I reckon this could also cover:

Using the GraphQL API (as mentioned, I’m not particularly an advocate of this approach, but I know some folks like it and want to use it.)
Extending the Contentful Rich Text engine to render references (it really is incredibly powerful for content creation).
Previewing content using the Eleventy Serverless plugin and the Contentful preview API.

How to use Vue to template your Eleventy projects

Henry Desroches — Fri, 17 Dec 2021 05:00:00 GMT

Okay quick disclaimer before I kick this off — this post does not cover how to use interactive Vue components in an Eleventy project. This post covers using Vue entirely server-side! The client will not receive any Vue code.

All of the code for this project can be found in this repo on GitHub.

TL;DR

If you’re using Eleventy because it’s lovely, but like using Vue syntax to handle single-file components, template merging, interpolation, etc, I’ve got your back. This post teaches how to start a new project in Eleventy, integrate eleventy-plugin-vue, and deal with any arising quirks or idiosyncrasies.

Getting started

This tutorial assumes you have Node and NPM installed. If you don’t yet, you can head over here to get that running on your machine. Once that’s in place, we can create a new directory, initialize it as a Node project, and install the two dependencies we need to get cookin’.

mkdir eleventy-vue-tutorial && cd eleventy-vue-tutorial

npm init # you can use the -y flag to skip the init setup

npm install -D @11ty/eleventy@beta @11ty/eleventy-plugin-vue

Let’s also create some standard directories for an Eleventy project. I personally prefer to keep my app code in a src directory, and reserve the base for configuration and meta files (like package.json, .eleventy.js, .prettierrc, etc.) but for this tutorial we’ll do as little opinionated configuration as possible!

mkdir _data _includes

Creating the Eleventy configuration and scripts

To get any of this working, we’ll need to add our configuration file to use the Vue plugin in our app. First, we’ll create our .eleventy.js file in the base directory of the project and populate it!

const eleventyVue = require('@11ty/eleventy-plugin-vue'); // import the plugin

module.exports = function (eleventyConfig) {
  eleventyConfig.addPlugin(eleventyVue); // tell Eleventy about the plugin
};

Eleventy experimental features

Here’s the first quirk of this process. At the time of writing, the default installations for eleventy and eleventy-plugin-vue rely on an experimental feature of Eleventy for Custom File Extensions. I’ve gotten around this requirement by installing the @11ty/eleventy@beta package, which implements custom file extensions as a feature.

To add the necessary scripts, we’ll go to our package.json file, and add the following:

{
  "scripts": {
    "start": "npx @11ty/eleventy --serve",
    "build": "npx @11ty/eleventy"
  }
}

If for some reason you can’t use Eleventy 1.0.0, that’s actually fine, you’ll just edit your scripts to activate the experimental features flag:

{
  "scripts": {
    "start": "ELEVENTY_EXPERIMENTAL=true npx @11ty/eleventy --serve",
    "build": "ELEVENTY_EXPERIMENTAL=true npx @11ty/eleventy"
  }
}

Layouts, data files, and Vue templates

In this section, you’ll create a layout, specify it as the default layout, and create your first Vue page template.

Creating a layout

As reported in the eleventy-plugin-vue README.md, you can’t use .vue files as base layouts, so what we’ll do instead is create a layout.html and specify it as the global layout template. This file will use some Nunjucks templating, so, sorry, you can’t escape it entirely (yet).

First, create a file _includes/layout.html, and populate it with the absolute bare minimum code to make this tutorial work!

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>{{ title }}</title>
  </head>
  <body>
    {{ content }}
  </body>
</html>

Note those {{ title }} and {{ content }} tags. These will use the Eleventy data engine to inject our page’s HTML from our Vue templates. You can read more about how that works in the Eleventy documentation.

Next, we’ll need to tell Eleventy to use that file as the default layout. This is as simple as creating a layout.js in our _data directory and inputting the following JavaScript:

module.exports = 'layout.html';

Adding our first `.vue` template

Now we can get into the actual Vue side of things. Let’s create our first page template, which, for now, will just have some content and set the page title.

I’m using Vue 2 for this tutorial, but Vue 3 is supported! I haven’t gone through all of these steps with Vue 3 syntax to find the challenges the new API presents.

We’ll create a file index.vue at the base of our app.

<template>
  <article>
    <h1>This is a test</h1>
    <ul>
      <li v-for="(listItem, index) in listItems" :key="index">
        {{ listItem }}
      </li>
    </ul>
  </article>
</template>

<script>
  export default {
    data() {
      return {
        title: "Wow I'm So Excited To Use Vue In My Templates!",
        listItems: [
          'This is the first item',
          'This is the second',
          'This is perhaps the third, though who could truly say.',
        ],
      };
    },
  };
</script>

The way the eleventy-plugin-vue works is by simply rendering the <template> tag and making that the content data property in the Eleventy cascade, and in the same stroke using the Vue data object as additional page data. Your page should look something like this:

Here, we used Vue iteration to turn an array of strings into an unordered list. You’ll even notice that the layout.html file automatically used the title data property as the title of the page. Nice work on this one, really just top notch work.

Rendering content and pagination

Rendering content from either an API like Contentful introduces some challenges. Let’s create a fake Markdown blog post API response and a post template.

In our _data directory, we can create a posts.js file that just exports a JSON array of posts, like what we might expect from a headless CMS API response.

module.exports = [
  {
    title: 'This is a test blog post',
    slug: 'this-is-a-test-blog-post',
    content:
      '## Subtitle\nLorem ipsum dolor sit amet consectetur adipisicing elit. Repellendus, vero, odit animi praesentium obcaecati autem velit, labore voluptates itaque consequuntur ea reprehenderit quod eveniet nobis perspiciatis neque quas cum voluptatum.',
  },
  {
    title: 'This is another blog post',
    slug: 'another-blog-post',
    content:
      'Lorem ipsum dolor sit amet consectetur adipisicing elit. Repellendus, vero, odit animi praesentium obcaecati autem velit, labore voluptates itaque consequuntur ea reprehenderit quod eveniet nobis perspiciatis neque quas cum voluptatum.',
  },
];

Next, create a file posts/_slug.vue which will be the template for our rendered blog posts.

<template>
  <div>
    <h1>{{ post.title }}</h1>
    <div v-html="post.content" />
  </div>
</template>

<script>
  export default {
    data() {
      return {
        pagination: {
          size: 1,
          data: 'posts',
          alias: 'post',
        },
        permalink: (data) => `posts/${data.post.slug}/index.html`,
        eleventyComputed: {
          title: (data) => data.post.title,
        },
      };
    },
  };
</script>

There’s a couple of things to note in that <script> tag:

In the data object, we’re returning a pagination entry — this is straight from the Eleventy docs, just converted to fit the Vue format!
Our permalink entry is a function that takes data from the paginator and returns the URL we want to render the page at.
This last one is tricky, and I’ve wrestled with it a couple of ways, but what I found was that to dynamically get information from data frontmatter, that is, to make available elsewhere in the data cascade, we can use eleventyComputed (not to be confused with Vue computed data) to return the title from the paginated data.

At this point, we can visit one of our blog posts at http://localhost:8080/posts/this-is-a-test-blog-post/ and see it rendering out for the most part. The next thing we’ll have to reckon with is that our Markdown isn’t being interpreted as Markdown, but that’s easily resolved using actual Vue computed data!

Let’s change this template around to use markdown-it to render our content.

markdown-it comes as a dependency of Eleventy, but we can manually install it as well so our package.json is a more accurate representation of the project’s dependencies.

npm i -D markdown-it

<template>
  <div>
    <h1>{{ post.title }}</h1>
    <div v-html="body" />
  </div>
</template>

<script>
  // import and initialize our markdown renderer from markdown-it
  const markdownRenderer = require('markdown-it')();

  export default {
    data() {
      // ...
    },
    computed: {
      body() {
        return markdownRenderer.render(this.post.content);
      },
    },
  };
</script>

We’ve added that computed property which has one body() function, which just takes the content from the paginated post and passes it through the markdown renderer. Things ought to be looking much better now.

Takeaways

You can use the Eleventy pagination object to create multiple pages from a single Vue template.
If you need to make data from a paginated page available higher in the data cascade (e.g. the page title in this case), use eleventyComputed.
If you need to transform data within a Vue template, you can use the Vue computed or filter properties, just like in a Vue single-page application.

Using Vue components

Of course, a lot of the reason for using Vue templates is the single-file component architecture pattern. That works just fine in Eleventy as well! Let’s create a <Navigation /> component for use in our home page.

First, we’ll create the file _includes/Navigation.vue,

<template>
  <nav>
    <a href="/">Home</a>
    <ul>
      <li v-for="post in posts">
        <a :href="`/posts/${post.slug}/`">{{ post.title }}</a>
      </li>
    </ul>
  </nav>
</template>

<script>
  export default {
    props: ['posts'],
  };
</script>

Then in our index.vue template, we can import and reference the component.

<template>
  <article>
    <Navigation :posts="posts" />
    <!-- ... -->
  </article>
</template>
<script>
  import Navigation from "./_includes/Navigation.vue";

  export default {
  	data() {
  		//...
  	}
  	components: {
  		Navigation,
  	},
  }
</script>

This is a pretty rudimentary example, but some things to note, again:

There’s no automatic aliasing or resolution as there is in other static Vue implementations, like Nuxt, so you have to reference your components by a full path to the file.
Components will have access to the Eleventy-supplied page object, but not necessarily data from the _data directory. If I need to reference data from the _data directory, I just pass it as a prop from the page template to a child component!

Everything else is more or less the same!

Using single-file component CSS

eleventy-plugin-vue does have support for using single-file <style> tags, there’s just a little additional setup. In our index.vue template, we can add a style tag with some arbitrary styles:

<template>
  <!-- ... -->
</template>

<script>
  export default {
    // ...
  };
</script>

<style>
  body {
    background-color: #efefef;
  }
  article {
    font-family: sans-serif;
  }
</style>

Now we’ll need to collect the CSS from each relevant file component and output it in the page — there’s a convenient filter for that, which we’ll add to our _includes/layout.html like so:

<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- ... -->
    <style>
      \{\{ page.url | getVueComponentCssForPage }}
    </style>
  </head>
  <!-- ... -->
</html>

We can also, should we so desire, add the scoped attribute to our style tag to leverage Vue’s scoped CSS features.

I avoid doing so because it’s a bunch of extra specificity and for what?

Everything ought to be workin’ just fine now. Nice work there, my friend, really just tremendous.

Conclusion

There are more idiosyncrasies to this implementation, and in a lot of cases you may decide it’s easier to use Nunjucks or a more standard Eleventy template language! That’s fine, I certainly don’t take it personally. I like Vue for the single-file architecture, the ability to do in-file data transformations, and the clean interpolation/iteration/templating syntax!

I’ll update this post as I learn how to do more things, such as:

Use Vue 3 lol

Thanks to my king Zach Leatherman for pointing out the spots in this blog where I was being a doofus, and Robb Owen for proof-reading me to safety while I was recovering from vaccine brain.

What to say when you don't know what to say

Henry Desroches — Sun, 07 Mar 2021 00:00:00 GMT

I have this weird relationship with Incredible Amounts Of Grief where, like, I’ve literally been there — I know there’s nothing to say, and nothing will heal but time. When The Bad Thing™ happened, I felt angry so often with people wasting both my time and theirs trying to string together something moralizing and impactful, either to Make It Better, or to make themselves feel like they tried. When The Bad Thing™ happened, the only thing that would’ve made it better in any capacity, in any universe, was The Thing un-happening, or (the more common path) simply many years of hurt, of crying in the middle of the day for seemingly no reason, until the sun started to rise on my world each morning again.

Despite this, I know what it is to watch someone grieve and feel desperately that I would do anything I could, in any capacity, in any universe, to take away some of the tidal waves of pain that person was experiencing. I’ve caught myself in the same stuttering moments of palaver, uttering everything in hopes that my meaning somehow makes it across — “I love you, and I hope someday you don’t feel this hurt anymore, and I hope that day is soon”.

I’ve have tried to be critical of myself, thinking about how to improve my own response, given my particular expertise in this scenario. I thought back to when The Bad Thing happened to me, and how I would have changed their reactions. Most of the things people said fell into a few categories:

What not to say

I know what you’re going through.

Don’t care, and no you don’t, and even if you did! Even if truly you do know what someone is going through, that’s not what they want to hear. Imagine you experienced the worst thing you’ve ever experienced, a kaleidoscope of skyscrapers falling into your mouth from a thundering sky, disintegrating every bone in your body. Imagine that sinking feeling you get sometimes, except it sinks one hundred times faster and harder and it never stops — and then further imagine somebody told you that this exquisite, technicolor masterwork of suffering wasn’t something completely unique, in fact everyone probably has to deal with the kaleidoscope sooner or later. You knew this to be true, but being reminded to think of others’ experiences when you’re being eaten alive by the thoughts of your own experience isn’t helpful.

They’re in a better place now.

I remember well the flash of anger I felt when someone had the audacity to bring me their religion and their stale platitudes when all I wanted was my little brother back. How those words about an imagined afterlife held a magnifying glass to the raging sunlight of my grief and burned deep lines down my skin — he lived a life of exploration and adventure and troublemaking, and now he’s in a box in my room; that’s hardly a “better place”.

Secularity aside (and “aside” is doing some incredibly heavy lifting here), it’s still an irrelevant thing to share: Even if I believed they were in a better place, they’re not with me, now, and like I mentioned before, that is the only thing that would fix this moment.

Keep your head up.

Honestly, what part of “kaleidoscope of pain” makes you think someone’s grieving head is gonna be anywhere but plunged into an ocean of agony for the next decade?

It gets easier with time.

I know that, I’ve seen the movies about people experiencing grief and healing from it, but grief has this special, incisive way of annihilating any sense of temporality one might have — one finds themselves trapped in a singular plane of cyclical thought and emotion. Unless you have those years of healing ready to inject intravenously, don’t bring the promise of those years.

What to say

Just say “I’m sorry for your loss”.

It’s not overdone! Rather, it carries the tradition of sorrow of millions of sorries-for-your-loss past. It’s succinct and respectful of the grieving and their time. Listen, if they have something to share, and know unequivocally in this moment there is nothing else you can say.

How to use the Spotify API and Netlify Functions to build a “Now Playing” widget

Henry Desroches — Sat, 12 Dec 2020 16:00:00 GMT

I recently* built this really cool feature for my personal website that allows me to use Netlify Functions to show my most-recently-listened-to tracks from Spotify.

*It wasn’t recently, it was in July 2020, please don’t look behind the curtain.

It’s an easy way to show some personality, and mostly just an excuse to get friendly with Netlify Functions. While the authorization flow for Spotify’s API initially threw me for a bit of a loop, this became a really fun way to spend an hour or two.

Check out the code for this at the GitHub Repo
Or check out the deployed version of this site

TL;DR

Here’s a basic outline of what we’re going to do to get this working today:

Setting up a basic application to display our track info.
Writing a basic callback function for Spotify authentication
Setting up an app in Spotify For Developers
Authenticating that app using Postman and Netlify Dev
Writing a Netlify Function to request data from the Spotify API
Rendering the response in HTML

This article won’t cover a fully-featured loop for managing authentication, refresh tokens, refresh timeout, etc. That would probably require a database and other infrastructure, and we don’t need that noise to make this work. ⚠️ This is probably not the way to make a very very secure serverless auth loop! ⚠️ It’s just a fun tech demo. Be safe.

Initial Setup & Prerequisites

It’s dangerous to go alone. You’ll need these:

Node.js and NPM
Postman
Netlify CLI

Node/NPM will let us set up the Netlify CLI tool that makes using Netlify functions Really Quite Convenient, and we’ll use Postman as an interstitial step during authentication.

To install Netlify CLI globally on our machine, we’ll run the following in our terminal:

npm install netlify-cli -g

Then we can use the CLI to log in to our Netlify Account:

netlify login

That’s all we need for initial project set up.

File Structure

We’ll create a new directory for this project, and in it we’ll create two directories, src and functions, as well as a netlify.toml file, which will contain our Netlify Functions configuration.

In the src directory, we’ll create an index.html, and in functions we’ll make a file callback.js. This is the function that will capture our initial authentication information from Spotify.

We’ll also initialize an npm project so we can run the development functions.

npm init -y

(The -y flag on npm init just accepts the default options so we can breeze through this.)

Once we’ve gone through these steps, our project directory ought to look something like this:

functions/
└─ callback.js
src/
└─ index.html
netlify.toml

We’ll put some very basic HTML in our index.html file for now, just to make sure everything’s working.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    <h1>Hello world!</h1>
  </body>
</html>

Our last setup step is to configure our netlify.toml so Netlify knows where to look for our site files and Lambda function files:

[build]
    publish = 'src'
    functions = 'functions'

And it’s as simple as that, folks. Moving right along.

Setting Up The Callback

Our callback function doesn’t need to do much; just receive an authentication code from Spotify when we initially connect to the API. I made mine very simple — literally all the function does is return a stringified version of the query string it receives and a 200 response code.

For a Netlify Function, we just need to export a method called handler that takes some information and returns a basic response. Here’s the code I wrote for functions/callback.js:

exports.handler = (event, context, callback) => {
  callback(null, {
    statusCode: 200,
    body: JSON.stringify(event.queryStringParameters),
  });
};

To test that this is working, we can start our Netlify CLI dev server by running the following in our Terminal:

netlify dev

Once it gives us that blessed “Server now ready on…” message, we can go to the URL and see our HTML file. We can also test out our callback function by visiting its url with any test query string, perhaps something like this? If everything’s set up correctly, it ought to display some JSON.

Setting Up A Spotify App

Next, we’ll need to set up a Spotify app with the correct permissions so Spotify can share our listening information.

We’ll head over to the Spotify For Developers dashboard right here, log in with our Spotify account, and click “Create An App”. We can call it whatever we want, and give whatever description.

Let’s first make sure to copy down the Client ID and Client Secret from the dashboard. We’ll need these in just a moment.

Once the app is created, we’ll go to “Edit Settings”. This is where we’ll fill in our Redirect URI, which is the path to our local callback function: http://localhost:8888/.netlify/functions/callback.

That’s all for this step, GG EZ.

Authenticating The App Using Postman and Netlify Dev

Now we’ll need to get some API client credentials, and authenticate for the first time. The goal here is to get a refresh token from the Spotify API, which we can use to repeatedly authenticate our API requests.

For this step, make sure your local Netlify Dev server is still running. Then we can open Postman and create a new request with the following details:

Set the method to GET.
Set the URL to https://accounts.spotify.com/authorize
In the params tab, we’ll add four parameters:
- client_id: We’ll set this to the Client ID we copied down earlier.
- response_type: “code”
- redirect_uri: Set this to exactly the URL we specified in the app setup. http://localhost:8888/.netlify/functions/callback

Next, you’ll need to acquire some API client credentials and authenticate for a first time. Open Postman and create a new request. Set the method to GET and the URL to http://localhost:8888/.netlify/functions/callback. In the params tab, you’ll add four parameters:

client_id: Set this to the client ID you copied down earlier.
response_type: Just set this to code.
redirect_uri: Set this to http://localhost:8888/.netlify/functions/callback.

I found out while doing this the first time that a difference in trailing slashes will actually make this not work, so be very certain you’ve copied the URL exactly.

scope: This determines what Spotify endpoints your authentication code will have access to. In the feature for my site, I only needed to use the user-read-recently-played scope. You can totally mix this up, just take a look at the documentation here to figure out which you’ll need.

Copy the URL Postman assembles for you out of the URL field and paste it into your browser. You’ll be prompted to sign into Spotify and accept the permissions you designated in the scope parameter, and then redirected back to your callback endpoint — which should give you something like this!

{
  "code": "AQBOoEdTAXroVVK1uI5Ym49LQI2T8Nz7WT2PIlqlfo4iHZ7bPY6msLnmOMnxlRNqAWfQmi3FZFkfHQJW8A3x1RK1QOr8UsfeSDnik_dfnrErFnQM"
}

We’ll copy down the code to use very soon.

We’ll start a new Postman request, this time with the POST method. We’ll set the URL of this request to https://accounts.spotify.com/api/token, per the Spotify API Authorization guide. In the Headers tab, we’ll add two entries, the first of which is:

Content-Type: application/x-www-form-urlencoded

The second entry is a little more involved. The key should be Authorization, and then we need to base64 encode our Spotify Client ID and Client Secret, in the following format:

client_id:client_secret

We can do this with the browser btoa() function or Node’s Buffer.from().toString(‘base64') functionality, or you can just paste it into this convenient CodePen I made specifically for you.

The end result that you’ll plug into Postman will be something like this:

Authorization: Basic andThenTheLongbase64StringThatProbablyEndsWithAnEqualsSign=

If you’ve made it this far, I’m so unbelievably proud of you. This part felt really convoluted and confusing to me when I did it. You’re doing great. You’re 10x the developer I’ll ever be.

Next, we can move on to the Body tab of the request, and enter the following parameters:

grant_type: authorization_code
code: We’ll set this one to the code we got back from the first request!
redirect_uri: Same as last time, we’ll set this to the same local URL (http://localhost:8888/.netlify/functions/callback)

Now, we can run the request. We’ll get back a block of JSON something like this:

{
  "access_token": "moreRandomCharacterStringsHuzzah",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "AQC2kGL-HJ6QgonZju7rDTikEU5_g_FG6y39izdPShgpQStzyYXtqQ3CkALS-YbnrnD6SImvISnmqkN2swXYGSAYdc0fmkeBcb3ZClYXVI9gETZ6HoP0NsKq1zUiWVJT4Q4",
  "scope": ""
}

Like I said before, a cleverer developer might work out a solution for storing access_tokens, checking if they’ve expired, and refreshing conditionally. For this tutorial, we can use the same refresh_token repeatedly, and that allows us to circumvent using a database, etc., so that’s the approach I’m taking.

The refresh_token is exactly what we need to move on to setting up the actual Spotify request in a Netlify function.

Writing The Spotify x Netlify Function

This is where the magic happens. By the end of this step, we’ll have accomplished a whole bunch of things:

Managing credentials in a local environment.
Creating a new Netlify Function to do all our Spotify request magic
Asynchronously fetching authorization from the Spotify API, and then
Fetching our most-recently-listened-to song from the API using that authorization.
Cleaning up the data for when we need to access it.

Managing Environment Access Credentials

Since we’re tracking secret credentials in our environment that we’ll store in the Netlify dashboard, let’s install dotenv so we can still do some local development. While we’re at it, we’ll also install node-fetch, which we can use to make browser-style fetch requests from our function

npm install dotenv node-fetch

We’ll create a file called .env in the root directory of our project. Inside that file, we’ll add our requisite environment variables.

SPOTIFY_CLIENT_ID=e8d7bf1a8ada357a77e4ca85aa7d04c0
SPOTIFY_CLIENT_SECRET=8ae32502d01aa2b579045df049aeb669
SPOTIFY_REFRESH_TOKEN=AQC2kGL-HJ6QgonZju7rDTikEU5_g_F...

⚠️ Don’t ever commit this file! It is now full of great and terrible secrets, and should be hidden from mortal eyes. ⚠️

Instead, when you deploy your site to Netlify, you’ll add these variables to the Build & Deploy > Environment section in your Netlify dashboard:

Creating Another Netlify Function

Let’s create a new file in our functions directory — I called mine spotify.js but whatever works for you is gonna be perfect.

At the top of the file, we’ll require() the dependencies we need and initialize our dotenv configuration so our function is aware of that .env file. We’ll also add the basic async wrapper for a Netlify function:

const fetch = require('node-fetch');
const dotenv = require('dotenv');
dotenv.config();

exports.handler = async (event, context) => {
  // logic and ✨ magic ✨ will go here...
};

Fetching Authorization From the Spotify API

Because we don’t have a system for managing authorization timeout and refresh tokens, we’ll need to get an access token from the API every time we request it.

We can do that by setting up basically the same request we did in Postman, but in JavaScript — and this time, instead of an authorization code grant, it’s a refresh token grant. We’ll add this JS to our function:

exports.handler = async (event, context) => {
	// Get the refresh token we stored as an environment variable
  const refreshToken = process.env.SPOTIFY_REFRESH_TOKEN;

  // Do the base64 encoding we did earlier but with Node tools
  const auth = Buffer.from(`${process.env.SPOTIFY_CLIENT_ID}:${process.env.SPOTIFY_CLIENT_SECRET}`).toString("base64");

  // Store the Spotify API endpoint for readability
  const tokenEndpoint = `https://accounts.spotify.com/api/token`;

  const options = {
    method: "POST",
    headers: {
      Authorization: `Basic ${auth}`,
      "Content-Type": "application/x-www-form-urlencoded",
    },
    body: `grant_type=refresh_token&refresh_token=${refreshToken}&redirect_uri=${encodeURI(
      process.env.URL,
      +"/.netlify/functions/callback"
    )}`,
  };

Next, we can asynchronously declare a variable accessToken that, once we’ve received it, we’ll use to actually query the API. After the options object, we’ll add the actual request.

const accessToken = await fetch(tokenEndpoint, options)
  .then((res) => res.json())
  .then((json) => {
    return json.access_token;
  })
  .catch((err) => {
    console.err(err);
  });

For more information on the way fetch works, check out the MDN article on this bad boy.

Fetching The Most Recent Song

Now we can make our actual request to the Spotify API. We’ll start by adding a variable to track the endpoint we have to hit (I grabbed this from the Spotify API reference). I added this right after the const tokenEndpoint we declared earlier:

const playerEndpoint = `https://api.spotify.com/v1/me/player/recently-played`;

Then, we can return the results of a fetch call to the API:

// That `?limit=1` part is because I only want the API to return a single song.
return fetch(`${playerEndpoint}?limit=1`, {
  method: 'GET',
  headers: {
    Authorization: `Bearer ${accessToken}`,
  },
})
  .then((res) => res.json())
  .then((json) => {
    // transform the results here.
    console.log(json);
  });

This is almost ready to test and adjust — but first, to make this a real Netlify function, we need to return an object that contains a statusCode and body.

.then(json => {
	// transform the results here
  return {
    statusCode: 200,
    body: JSON.stringify(json),
  };
});

Hell yes, brother. Excellent work.

As long as we didn’t stop our Netlify Dev server, we ought to be able to go to http://localhost:8888/.netlify/functions/spotify in our browser and see a big dump of Spotify’s response to our request.

Data Cleanup

For my purposes, I needed the song URL, the artists, the song title, and maybe the album art, so I did a little data massaging:

// Start by destructuring the items from the json response
.then(({ items }) => {

	// Let's do a little more destructuring assignment to take only what we need from the response
  const {
    artists: artistsArray,
    name,
    external_urls: urls,
    album,
  } = items[0].track;

  // We want to keep the array of artists in case there's a track feature, etc.
  const simplifiedArtists = artistsArray.map((artist) => ({
    name: artist.name,
    url: artist.href,
  }));

  // Lastly, make the url/artwork references more specific
  const trackUrl = urls.spotify;
  const artworkUrl = album.images[1].url;

  // And then return a stringified object that contains all the data we want to render!
  return {
    statusCode: 200,
    body: JSON.stringify({
      artists: simplifiedArtists,
      name,
      trackUrl,
      artworkUrl,
    }),
  };
});

That’s all we need to do! Refreshing the localhost URL of the function should give us a JSON string that only contains the data we need. Depending on how you want to use this data, you can be done here, or keep reading to learn how to render this data to the browser.

Rendering The Spotify Response to HTML

If we had some sort of server-side build task, we’d make a request to the function in that build, but in this case, we’re going to make the request client-side.

In our src directory, let’s make an index.js file and link that file in our HTML. In this step, we’ll also add a template that we’ll render data to:

<body>
  <h1>Hello world!</h1>
  <p>My most recent listening on Spotify:</p>
  <div class="spotify"></div>
  <script src="index.js"></script>
</body>

Next, we’ll add some code in that index.js file to hit the Netlify Function endpoint we created:

fetch('/.netlify/functions/spotify')
  .then((res) => res.json())
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

Accessing our project via the Netlify Dev localhost URL ought to show us the results of that in the console:

EZ.

All that remains is templating that data and injecting it into our HTML!

This, obviously doesn’t adhere to best practices of progressive enhancement. This page should work even if client-side JavaScript fails, but for the sake of this demo and tutorial, we’ll accept a half-finished solution.

Here’s my final index.js file, which uses some template literals and destructuring assignment to shape the data exactly how we want.

const spotifyWrapper = document.querySelector('.spotify');
const artistTemplate = (artistObject) =>
  `<a href="${artistObject.url}">${artistObject.name}</a>`;

fetch('/.netlify/functions/spotify')
  .then((res) => res.json())
  .then(({ trackUrl, name, artists, artworkUrl }) => {
    spotifyWrapper.innerHTML = `<div class="song">
            <a href="${trackUrl}">
                ${name}
            </a>
        </div>
        <div class="artists">${artists
          .map((artist) => artistTemplate(artist))
          .join(', ')}</div>
        <img class="artwork" src="${artworkUrl}"/>`;
  })
  .catch((err) => console.error(err));

Conclusion

So thanks for reading, I hope this was super cute and fun and helpful. I love Netlify Functions, they make Lambda/serverless tasks really accessible — especially as I’m not personally much of a back-end developer. If you have any issues, questions, comments, concerns, or professions of love and/or eternal hatred, [get at me on Bluesky]({{ ‘bluesky’ | getSocialUrl(social) }}). I’m happy to update this post at any point to go into more detail about specific aspects, so please def reach out!

The code for this tutorial can be found here on my GitHub page.
A live version of the site is deployed with Netlify right here.

Colophon

Photo by Dylan Leagh on Unsplash

Naming variables in style code

Henry Desroches — Thu, 10 Dec 2020 20:00:00 GMT

This morning, the atomic design GOAT Brad Frost Tweeted a question about variable naming for colors:

Here’s a fun one: what variable name would you define for `rgba(0,0,0,0.9);`?

I drafted up a Tweet to answer this, but it ended up being closer to five Tweets, so I figured it might just work better for me to do a tiny blog post instead of a big, noisy thread.

Strategy

This might seem overwrought, but I actually like to name my variables twice: once to tokenize and once to contextualize. I’ll use Mr. Frost’s example of rgba(0,0,0,0.9) to explain what I mean. Honestly, when he Tweeted about this, he was probably only looking for the first “tokenize” step, but I’ve already written most of this post, and it’s too late to turn back now.

Tokenize

First off, I want to prevent unnecessary variation of color implementation in my style code. Different developers might represent this color as an RGBA function, an 8-digit hex (#000000E6), an HSLA function (0, 0%, 0%, .9), etc. They might also eyedrop sample the color out of a design tool and come up with something just different enough to introduce inconsistencies (lookin’ at you, rgba(0,0,0, .89)). Tokenization gives us a clarified and sanitized way to provide colors to developers implementing design.

With monochrome colors, I try to stay away from descriptive color keywords—we’ve all seen some cursed variation on the $lightishGrayButLighter naming scheme. I prefer instead to sort my mono palette by each shade’s lightness. This makes it easy to see at a glance that:

A color is some form of gray, and
It is very much lighter or darker than another form of gray.

I use an HSL-style representation of that lightness, purely because the mental model of “0 = black, 100 = white” is way more straightforward for me to parse at a glance than “0 = black, 255 = white.”

The last consideration for tokenization is an alpha value—since both rgba(0,0,0,0) and rgba(0,0,0,.9) technically have the same lightness value, we need some distinction between them.

// designate a monochrome namespace with $mono, then a lightness value, then an alpha value.

$mono--0-90: rgba(0, 0, 0, 0.9);

The pseudo-almost-kindasorta-BEM-like namespacing technique is something I learned from Stuart Robson, who’s solved this specific design systems problem a thousand times and whose writing on design systems is incredibly valuable. Depending on your preference, you might also namespace color variables with something like $color__mono--0-90.

If we have many of these in our system, it’ll start to look like we’ve got ourselves a stew going.

Aside

The cool part of the mono palette concept is that it can be used even your grays aren’t pure rgba(x, x, x, alpha) shades. Here’s an example where the colors aren’t literally monochrome, but still represent a monochromatic palette:

$color--mono-14: rgb(32, 37, 39);
$color--mono-35: rgb(93, 88, 86);
$color--mono-49: rgb(129, 123, 121);
$color--mono-66: rgb(172, 167, 165);
$color--mono-86: rgb(223, 218, 216);
$color--mono-90: rgb(230, 230, 230);

Contextualize

Now that we’ve tokenized our colors to protect them from accidental variation and allow for easy reuse within the app, we’ll contextualize our variables for global or component use. We don’t use the pure $mono--0-90 variable in a CSS declaration, because if the design calls for a change to border colors, for example, you’d have to change that instance in every location, which in my opinion defeats the purpose.

Instead, we’ll come up with a purpose for the color in the context of the app or website. What function does the color actually serve? A semi-opaque off-black color could be a lot of things, maybe a $theme-color--text or $theme-color--border. This is a really important consideration, because it makes your color system palette-agnostic. That is, no matter what the colors change to over the life of the system, an element that has color: $theme-color--text; will never need to change. I love hydrating themes with palettes in this way; it feels really systematic and logical. Decoupling. Unbundling. Synergizing.

Conclusion

Anyway, thanks for reading. I know this is a short one but I figured better this than 30 Tweets. I would love to hear what you think about this strategy, why your approach is better, why I’ll never amount to half the developer that you are, etc.—get at me on Bluesky @strange.website.

Colophon

Graciously edited by the Chris Shiflett, and written according to the Faculty Style Guide.

Headless CMS solutions that aren’t Statamic (lol)

Henry Desroches — Tue, 03 Nov 2020 22:00:00 GMT

So as it turns out, the guy who made Statamic has decided to publicize his extremely unfortunate views that controlling womens’ bodies is the most important thing to him in this election, over keeping families together, over immigrant lives, over Black lives, over queer lives.

He’s written—and I’m not linking the post here because I believe in deoxygenating these sort of views when possible—that he fears being canceled or losing support for his business Statamic over expressing his bigoted and narrow-minded views. Oh gosh, oh no. I don’t necessarily believe in “canceling” so much as I believe in folks’ ability to hold others accountable for the stupid shit they blog, with their money or any other resources — If that’s canceling, let’s rumble.

TL;DR? Statamic is run by a jerk and I’d love to recommend y’all some alternatives in case you’re using it or considering it and want to course-correct.

Path of least resistance

If you’re looking for another PHP CMS with a configurable UI, your best bets are gonna be either Kirby or Craft:

Kirby CMS

Kirby is super well-featured and well-liked, but let me quickly list off its similarities to Statamic if you’re looking for feature parity.

✅ Powered by PHP
✅ Works as both a full CMS or just a headless solution.
✅ Self-hosting option
✅ Configurable UI
✅ Version controllable
✅ Drafting and previews
✅ Custom fields and content modeling

Kirby also has a vibrant community, flat-file structure, a really sick customizable Vue UI kit, Markdown support, internationalization support, and it lets you integrate additional data sources.

Additionally, Bastian Allgeier, the founder of Kirby, has written on more than one occasion about the climate crisis and his personal efforts to fight it, which I mention because Statamic Guy has decided climate change is not of interest to him when compared to controlling women.

Check out Kirby.

Craft CMS

Craft is a hugely popular tool, and loved by all kinds of agencies, small businesses, and professionals. Same deal here, let’s talk about some similarities to Statamic and some differences.

✅ Powered by PHP
✅ Works as both a full CMS or just a headless solution.
✅ Tons of content types and custom field features
✅ Configurable Dashboard

Craft also has localization support out of the box, some really good user management tools, and even a built-in image editor tool that allows you to set focal points and cropping, for better image rendering in different contexts. They also have an entire eCommerce solution that works side-by-side with their content manager so your online selling team only has to work with one platform.

It’s worth also mentioning that the Craft team sponsors diversity scholarships and conferences — that prioritization of diverse communities is something missing from Statamic, whose founder believes Black lives and the lives of queer folks and non-men are worth less than his right to legislate women’s bodies.

Check out Craft CMS.

Additional alternatives

I’ve had excellent experiences with a lot of these headless CMS tools. The Jamstack conf team has put together this very good list of headless CMS options, and I have my own personal recommendations:

Netlify CMS

It’s a single flat file you add to your site that manages flat files in Git with a configurable UI, it’s free, it’s open source, it’s powered by Netlify. Its power lies in its simplicity. I’ve used this tool for a couple different projects with small businesses and otherwise, and it really serves a surprising amount of needs. The community is great, too, and they’ve written guides for getting you started with most front-end solutions. It’s purely headless but a great solution for rapidly converting static projects to dynamic content.

Check out Netlify CMS.

Contentful

This blog post was written with Contentful — it’s one of my favorite headless CMS solutions. Contentful is language/framework agnostic, though they provide a bunch of tooling for common integrations. You edit content and content-modeling in your configurable dashboard and it is served through a very flexible RESTful API. They also do a bunch of behind-the-scenes asset/CDN/caching optimization. Big recommend for small teams.

Check out Contentful.

Questions or concerns?

If you’re a DJT supporter or you still think this is a matter of regular old red-v-blue politics, I would love to hear your opinion, feel free to email me at lmfao@henry.codes. If you have other corrections or questions for this post, get at me on Twitter, I’m most responsive on there.

Updates

Craft CMS is based on Yii, not Laravel as previously mentioned. H/T Iain Bean for the correction.

How to convert variable TTF font files to WOFF2

Henry Desroches — Thu, 09 Jan 2020 19:30:00 GMT

Impetus

I’ve been working on a project lately that requires the loading of many, many webfonts. For the main UI font alone, we needed to download over 980kB of WOFF and WOFF2 files. As it happened, the client eventually developed a variable font version of the UI face, which was a much smaller 225kB file.

However, when I received the variable font file, I realized it was a TTF, and not the WOFF2 that I would need to implement it in a @font-face declaration for web. In previous experience, converting variable TTF to WOFF via online tools like convert.io or FontSquirrel would often break the axes needed to interpolate between font variation settings.

A cursory search yielded Google’s woff2 library, a tool for compressing TTF to WOFF2 — it worked perfectly. Here’s how to do the thing.

Installing the library

This is covered in woff2’s README file, but we’ll go over each step here in a little more depth, so it’s clear what’s going on.

Clone woff2 locally

Open a terminal and cd into whichever directory. This doesn’t need to be installed in a specific place, just remember where you’re putting it. For this tutorial, I’m going to clone it into my ~/Sites directory.

cd ~/Sites
git clone --recursive https://github.com/google/woff2.git
cd woff2

Here, we entered the correct directory, cloned the repo recursively, and entered the cloned directory. woff2 uses the Brotli compression library as a dependency, so you need the --recursive flag to clone everything inside this repo.

Build woff2

Next, we’ll run a command to build the library and its dependencies, which will create the scripts we’ll need.

In the woff2 directory:

make clean all

If there were no errors, we should be good to go! (If there were errors, get at me via email or on Bluesky) and we’ll debug through so it so I can update this blog post with troubleshooting steps.

Converting the `.TTF`

Now that we’ve created the binary scripts for compressing and decompressing TTF into WOFF, we can run them here. In this example, I’ve downloaded the variable TTF to my ~/Downloads folder.

In the woff2 directory:

./woff2_compress ~/Downloads/variable-font.ttf

You’ll get some output like this:

Processing /Users/henry/Downloads/variable-font.ttf => /Users/henry/Downloads/variable-font.woff2
Compressed 216568 to 94577.

And voilà, we’ve got a variable WOFF2 file, ready for use on the web.

Thanks for taking the time to read this. If you’ve got any questions or concerns, please reach out and touch faith and we’ll work through it together! Have a great day.

2019: Year in review

Henry Desroches — Mon, 30 Dec 2019 17:00:00 GMT

Introduction

This time last year, I Tweeted out some goals for the New Year.

🗣️ Speak about CSS at a conference or school

🎓 Take a class a month

📚 Read a book a month

✈️ Go back to SF, go back to Europe

💵 Save enough to buy a house

Bring it tf on, 2019.

I was determined and inspired by a strong career year, financial independence earned by selling my car, and the sense of indomitability and self-confidence that comes with healing after a breakup.

I set some goals that I felt were extremely achievable (like reading a book a month), and some that were much loftier (going to Europe, save enough to buy a house).

I missed the mark on nearly all of them.

Now, in the last few days of the year, I’d like to reflect on how and why I failed to meet these goals, and how I plan to estimate and execute better in 2020.

Tl;dr

I slipped super hard on meeting my goals for last year, mostly because I wasn’t good at focusing and using my time usefully. I’m setting goals for 2020 that I feel are meaningful to me, achievable, and that I can be proud of by the end of the year.

Reflection

I didn’t actually fumble 100% of my goals, so I’ll kick this off with a positive.

🌉 Return to San Francisco ✅

Smashed it.

I spent a week or so in May in hotels in Japantown and the Financial District. My former employer sent me to attend the AwwwardsConf in—yes, indeed—~~sunny~~ foggy San Francisco.

At the time, I was up to my knees in the development of a design system and design operations processes for the team. Since most of the AwwwardsConference talks were about design systems,it was a fairly straightforward value prop, and let me knock one goal off the list.

The first half of my trip was for AwwwardsConf , where I had the pleasure and privilege of listening to talks by Omayeli Arenyeka, Alex Cornell, Claudio Guglieri and more. I made friends from Finland, DC and San Diego. I managed to get into an amazing workshop on machine learning led by Pedro Marques and Joël van Bodegraven. I could name drop all day (I won’t) but it was a really fantastic trip for making friends and networking. I already can’t wait to go back (or at least make it to another AwwwardsConf).

🗣️ Speaking at a conference/school ❌

If I’m being real, I just didn’t keep the fires stoked for this one.

I sent a talk proposal on making innovative CSS art using SVG filter primitives to CSSConf Budapest, but didn’t make the lineup, and didn’t really try after that. Speaking is a big time and labor investment upfront, and motivating myself to prioritize such an effort with potentially no payoff was a big challenge.

I’m bringing this goal back in 2020. I’ve met some new connections that can help me engineer better talk proposals, and because my urge to teach and share has persisted, I feel confident I can get this one across the line in 2020.

🎓 Take a class a month and 📚 Read a book a month ❌❌

Reading is super hard. I’m fully embarrassed to admit it, but I took the constant reading and analyzing cycle of academia for granted. It’s been a few years since I really invested in any long-form reading and I felt that in a big way. I was constantly distracted, usually by my phone, and often would realize I was just reading the words of the page individually instead of absorbing the information. It’s hard, and it’s hard to get better, and it’s hard to admit that I’m not really good at reading anymore.

I will bring a desire to constantly learn and consume literature or other long-form reading into the new year, but I will leave the quantifiable “1 book a month”, “1 class a month” goal behind until reading feels more natural.

🛩 Go back to Europe ❌

I didn’t make it — I was mostly focused on saving for a house and eating out all the time. It wasn’t a huge priority and I don’t feel bad about slipping. Just didn’t shake out!

I won’t add this one to the list again, mostly because it really just isn’t that meaningful to me that I make the trip, though if I did it’d be a free win: The Faculty crew and I are headed to Nottingham, UK (that’s still technically Europe these days, right?) in January 2020 for New Adventures conference. I’d love to make some friends while I’m out there, so reach out if I’ll see you there!

💵 Save enough to buy a house 🆗

This was either a win or not, depending on how you look at it.

In 2019, I got fully debt-free, cancelled the majority of my credit cards, shook myself loose of any loans I picked up erroneously in my slightly-earlier-twenties. That was a huge success. I still saved enough to buy a house, but probably not a house in Denver, where I’d like to be buying.

I’ve been hemorrhaging money renting here, year after year, and it only gets worse as the months pass and Denver becomes a more popular destination. I could look at buying somewhere more affordable, but when I set this goal, I had Denver in mind, so that’s why I’m not calling this a win just yet.

Post-mortem

Overwhelmingly, I feel like 2019 was largely unfocused and middling. I have always felt compelled to do all kinds of things, but the aimless splashing around in learning Cinema4D, WebGL, Italian, whatever, hasn’t made me feel like more of a Renaissance person. I feel like I know a little about a lot, and unfortunately, that “little” tends to translate to “slightly-less-than-enough to be dangerous”. It’s not all bad. I definitely let myself down, but in doing so I’ve gained a more careful understanding of some tenets I need to be stronger — that’s focus, deliberation, and meaningful action.

Scrolling through Twitter without purpose, shitposting in nigh-silent groupchats, watching mediocre content on Netflix — I’m doing a lot of things for no reason, and with no benefit to my sense of self.

Additionally, with goals like “save enough to buy a house”, it’s a little too wide-open and not specific enough to know whether I actually hit the mark or not, and leaving it up to a subjective do-I-feel-like-I-did-it means it becomes a matter of mood.

I want to forgive myself for a slow and unintentional year and set useful, achievable yet challenging and quantifiable goals for 2020.

Goals For 2020

Without further ado, here’s the plan for doing 2020 focused, deliberately, and mindfully:

🗣️ Speak about creative web at a conference or school

Like I said, still on the list. I’ve got some ideas for talks but I will spend intentional time to craft at least two fully-fleshed-out proposals I can send off to as many CFPs as possible.

💵 Save $60,000 for a down payment on a home

“Save enough to buy a house” part two, electric boogaloo. This is a very strict success metric and I’ll either hit it or I won’t.

🎓 Enroll in formal further education for computer science, mathematics, or creative computing.

When attempting to learn WebGL or invest more in creative technology, I find my lack of understanding of mathematical concepts as basic as geometry are a huge hindrance. I’ve tried to relearn these concepts (oh, if my high school self could see me now), but I feel that a formal re-education will be a lot more effective for my learning style, as well as providing professional development lift. Plus it’ll make my mom happy 😉.

An additional goal

This one isn’t really quantifiable, it’s just an ethical tenet I’d like to take on.

🥀 Minimize use of “gig economy”, hyper-convenience, and subscription services.

Companies like Lyft, Uber, Doordash, Instacart, etc, have all proven themselves uninterested in serving their labor force ethically, and there’s a full clip of additional reasons these companies don’t deserve my (your) patronage. Instead of rideshare, I’ll be riding my bike a lot more. I can get virtually everywhere and everything I could need within an hour ride of my apartment. Taking Lyfts and Doordashing are the result of a lack of intention, motivation, or preparation.

Second, Amazon is like…inarguably evil, so I’ll be doing my best to patronize local booksellers, craft stores, and so on, instead of defaulting to the path of least resistance.

Lastly, streaming video and other subscription services burn a hole in my pocket and encourage me to waste my time. As much as possible, I will choose buy-to-own products and non-subscription alternatives.

Conclusion

Thanks for taking the time to read. This was a slow year for me, but I still made some leaps and bounds and I’m eager to keep that momentum in 2020. I normally blog about creative web development, and share a lot of cool content on Bluesky. Say hi if you get the chance!

Let’s talk about banning political ads on Twitter

Henry Desroches — Thu, 31 Oct 2019 18:00:00 GMT

Before you get started, fair warning that this post has “takes”, some of which could be considered “hot”. This post is not about web development.

So, Twitter recently stopped allowing political advertising.

We’ve made the decision to stop all political advertising on Twitter globally. We believe political message reach should be earned, not bought. Why? A few reasons…🧵

This, at first glance, sounds like a good thing — no more big money candidates paying big money for big money reach, no more “as president I promise to” in your TL. For a moment, I actually felt relieved by this announcement, but upon further inspection, I lost that faith. Stopping “all political advertising” is Bad, Actually™, and here are a few reasons why:

If the ban was explicitly imposed against candidate ads alone (it’s not, and I’ll talk about that in a second), there’s a possibility it could be a good thing, for the above reasons. However, the advertising budget for big money candidates still exists and will still be spent. Whether that’s on huge TV campaigns or billboards or subway signage, the advertising deluge will simply be redistributed, it won’t just go away. The big money messaging might even stay on Twitter, in the form of fake accounts and bots.
Banning candidate ads is also bad for grassroots movements — plenty of small-budget candidates with really fantastic ideas have, in recent years, been enabled to run and build communities by affordable digital advertising on Twitter, et al. Grassroots candidates will no longer have access to the same reach, and by extension won’t be able to circulate their ideas.

In short, candidates with lots of money, powered by corporate PACs, will continue to be very loud, and smaller-budget candidates will be forced to return to more traditional, outdated methods of community building.

But there’s a more sinister side to this policy change, and that’s the really dangerous part of the whole thing: The ban doesn’t just prohibit candidate ads.

We considered stopping only candidate ads, but issue ads present a way to circumvent. Additionally, it isn’t fair for everyone but candidates to buy ads for issues they want to push. So we’re stopping these too.

Here’s where this gets really dark.

This implies that Twitter will now be deciding what defines a political issue. Based on Twitter’s stance on refusing to remove violent fascists from their platform, one could infer that “issues” like climate change, women’s safe access to healthcare, and other civil liberties will no longer be acceptable to advertise about.

Further, marginalized groups that face unequaled oppression (on Twitter and every moment of every day IRL) like people of color and queer folks, are no longer able to advertise for their own safety, advocacy, and community-building. John Hanawalt puts this exceptionally well:

Fair question a few things: blanket policies can only approach fairness when all else is equal. But all else isn’t equal.

These communities will continue to face political attacks offline, and Twitter is limiting their ability to advocate for themselves by limiting paid reach.

This is a classic pattern in “political” conversations — one side wants to take away the rights of a group of people, and litigate them out of validity and existence, and the other side just wants to exist, safely and equally. This is tagged as a partisan or political issue and the conversation gets elevated to mainstream discussion, instead of the correct outcome: The hate group is broken up and the marginalized community is granted the rights and protections they deserve as human beings.

TL;DR

It would be truly wonderful if good ol’ @jack was actually acting in good faith (or even informed faith) by banning political advertising. Unfortunately, this action on its own, without other motion to support and protect marginalized groups (literally just ban the TERFs and the nazis), is a violent action, masked as virtue signalling and progessive policy. Quieting all voices, when the humans behind those voices don’t have equal access to their own rights, isn’t equitable, it’s oppressive.

How to make an animated interactive vue.js slider

Henry Desroches — Wed, 05 Jun 2019 02:36:00 GMT

So, I was looking for a fun example of UI interactivity to prototype on Codepen, and I stumbled upon this really cool shot that Alexsander Barhon shared.

It’s a simple enough animation, with a really nice loading effect and staggered timeline that make it feel super fluid. I’ve been really into Vue.js lately, and this seemed like a perfect opportunity to code out a little app. Live your life, but I’m gonna use SCSS for style here.

Tl;dr

If you wanna skip the tutorial and get the source, scroll to the bottom of the post or just go check out the finished pen. This post is gonna go pretty in-depth on everything it took to get this running, including the foundational CSS, etc. If you’re just looking for the Vue Interactivity or Vue transitions section, that’s cool too.

Getting Started

When I’m building components like this, I always try to get markup and style in place before trying to futz with JavaScript. That way, I can focus on making things semantic and DRY without adding an additional layer of abstraction.

Basic HTML structure

There’s a bunch of different ways you could break this app down, but based on the way it animates in the Dribbble shot, I see it in three major components, and then a few sub-pieces:

The reason I keep the top navigation separate from the slider or sidebar is because it all animates in together and seems to generally serve the same purpose. There’s definitely an argument to be made that the “kalli” logo is part of the slider and the “about” section is part of the sidebar, but for the sake of this demo, I’m gonna keep them separate.

Let’s code it out:

<div class="viewport">
  <nav class="nav">
    <div class="nav__brand">
      <!-- Logo goes here. -->
    </div>
    <ul class="nav__list">
      <!-- Nav items go here. -->
    </ul>
  </nav>
  <main class="main">
    <div class="main__slider">
      <!-- Slides will go here -->
    </div>
    <div class="main__headline">
      <!-- Headline here -->
    </div>
    <div class="main__nav">
      <!-- Play video & social links will go here. -->
    </div>
  </main>
  <aside class="aside">
    <div class="aside__nav">
      <!-- Our buttons to navigate the slides will go in here. -->
    </div>
    <div class="aside__slider">
      <!-- Slider numero dos. No prob. -->
    </div>
    <div class="progress-indicator">
      <!-- This is like that 01———03 thing in the bottom right. -->
    </div>
  </aside>
</div>

So far so good. I’m using BEM-ish classes for everything, because I like how easy it is to organize in your SCSS without increasing specificity. (We typically want to avoid selectors like .nav .list or whatever, and sometimes Sass’ nesting feature can make that an easy trap to fall into. .nav__list is just as clear and much easier to override/much less specific.)

You’ll also notice I’m assigning seemingly-duplicative classes like .nav to the <nav> element or .aside to the <aside>. I don’t usually use tag name selectors for structural elements because it makes the CSS more dependent on the HTML structure.

Don’t worry about style just yet. If we make sure our HTML is meaningful and well-structured without style, it’ll be that much easier to write up the CSS.

Primary nav

The navigation at the top has two distinct sections — the logo and the right-aligned nav items.

<nav class="nav">
  <div class="nav__brand">
    <p>Logo</p>
  </div>
  <ul class="nav__list">
    <li class="nav__list-item">About</li>
    <li class="nav__list-item">More</li>
  </ul>
</nav>

Main section & slider

I want to keep the slider slides and headline separate, because they animate in different ways, but close enough that they’re clearly related.

<main class="main">
  <div class="main__slider">
    <img class="main__slide-image" src="slide1.jpg" />
  </div>
  <div class="main__headline">
    <span class="main__headline-span"
      >Simplicity is the ultimate sophistication.</span
    >
  </div>
  <div class="main__nav">
    <p>Play Video</p>
    <ul class="social-links">
      <li class="social-links__item">
        <a href="https://facebook.com">Fb</a>
      </li>
      <li class="social-links__item">
        <a href="https://twitter.com/">Tw</a>
      </li>
      <li class="social-links__item">
        <a href="https://www.linkedin.com/">In</a>
      </li>
    </ul>
  </div>
</main>

Aside & secondary slider

I know we need two buttons that navigate forward and backward in the slider, a secondary container for the aside slider that we’ll mark up in a similar way to the first slider, and a progress indicator. I think I’m gonna use pseudo-elements for the counter on the progress indicator, so I’ll pass it the total number of slides via a data-slides-count attribute.

<aside class="aside">
  <div class="aside__nav">
    <button class="aside__button">←</button>
    <button class="aside__button">→</button>
  </div>
  <div class="aside__slider">
    <img class="aside__slide-image" src="slide2.jpg" />
  </div>
  <ul class="progress-indicator" data-slides-count="03">
    <li class="progress-indicator__bar"></li>
  </ul>
</aside>

And that’s the markup done. I really love coding these puppies in layers like this because now that I know that my HTML is sound, I don’t have to worry about it again for a while.

Basic style

Let’s get Sassy with it. In my initial iteration of this idea, I used CSS variables and other weird stuff, so if you’re interested in that but have to support older browsers, it might be worth looking into a polyfill, or better yet, a ponyfill. 🦄 This version of the tutorial doesn’t include any of that crazy bonkers stuff.

“Responsive” CSS

I elected to use a pattern I lean on a lot for CodePens to make things “responsive”, where I set a font size for the app using viewport units and then measure everything based on that root font size using rem units. It looks a little something like this (note the #{} syntax for interpolating SCSS variables):

$app-width: 95vmin;
html {
  font-size: calc(#{$app-width} / 100);
}
.viewport {
  width: $app-width;
  height: calc(#{$app-width} * (9 / 16));
}

This block does a few things:

I’ve decided I want my app to be as large as possible without ever touching the edge of the screen, so I’ll use 95vmin to make sure it is always 95% of the width or the height of the screen (whichever is smaller).
In the html selector, I set the font size to be 1/100th of the width of the app — that way I know that 1rem will always be 1% of the width of the app. (This obviously isn’t required, I just like to have a very consistent and scalable unit to rely on when I’m making pens.)
I measured the sides of the app in the video on Dribbble, and found that the app’s aspect ratio was 16/9. Thus, I’ve set the .viewport (which is the class I’ll add to my app wrapper) width to $app-width and then set its height to $app-width * (9/16), to ensure it is always the correct aspect ratio.

Let’s keep trucking.

Layout style

We’re gonna default to using CSS Grid for most of our layout problems, with some absolute positioning.

body {
  display: grid;
  place-items: center;
}
.viewport {
  position: relative;
  display: grid;
  grid-template-columns: 1fr 30rem;
  // width, height...
}

That’ll make the <aside> section 30% of the width of the app and the main slider will take up the rest of the available space. Let’s do the nav next.

.nav {
  padding: 5rem;
  display: grid;
  grid-auto-flow: column;
  justify-content: space-between;
  z-index: 1;
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  &__list {
    display: grid;
    grid-auto-flow: column;
    justify-content: space-between;
    width: 20rem;
    padding: 0; // Unset default ul padding. You could use a CSS reset too.
  }
}

So here we’ve decided the nav itself will be a grid, but by giving it position: absolute; we’re taking it out of the parent grid. (Z-index just makes sure it’s always the top-most element in the z-index stack.) Then we use the ampersand selector to style the right-aligned nav as grid as well. Let’s do the <main> section and its children.

.main {
  display: grid;
  grid-template-rows: 2fr 1fr;
  grid-template-areas: "headline" "nav";
  align-items: end;
  &__slider {
    position: absolute;
    z-index: 0;
    top: 0;
    left: 0;
    width: 70rem; (T
    height: 100%;
  }
  &__headline {
    padding: 5rem;
    grid-area: headline
  }
  &__nav {
    z-index: 1;
    display: grid;
    grid-template-columns: 1fr auto;
    grid-area: nav;
    width: 30rem;
    padding: 3rem 5rem; // I'm using 3rem vertical instead of 5rem all around cause it just looks better 👀
  }
}
.social-links {
  display: grid;
  grid-auto-flow: column;
  grid-gap: 0.4rem;
  align-items: center;
}

Movin’ right along. Let’s layout the <aside> element.

.aside {
  position: relative;
  display: grid;
  padding: 5rem; // That DANG 5rem padding again....
  $button-size: 10rem;
  &__slider {
    position: relative;
    height: 25rem;
    margin-top: 10rem;
  }
  &__button {
    width: $button-size;
    height: $button-size;
  }
  &__nav {
    position: absolute;
    bottom: 0;
    left: -#{$button-size};
  }
}

Same padding as the top nav, etc. here (if I was a clever person perhaps I’d make it a Sass variable like I did with the button sizing but I am not so here we go, baby).

Looking pretty slick so far. This looks about how we initially broke down the Dribbble screenshot.

Next we’ll add some more visual style to the app.

Visual spice

So the first thing I’m gonna mention is that I don’t actually know what font is in use here off-hand, so I’ll be using instead this really nice sans-serif font called Inter. Let’s go ahead and include it in our style sheet.

@import url('https://rsms.me/inter/inter.css');
html {
  font-size: calc(#{$app-width} / 100);
  font-family: 'Inter', sans-serif;
  @supports (font-variation-settings: normal) {
    font-family: 'Inter var', sans-serif;
  }
}

Let’s style the pen a little bit so it’s not just a bunch of white rectangles. We’ll start with some variables and general app stuff.

$color--background: hsl(
  300,
  3%,
  15%
); // Note the $block--modifier syntax. This is just personal preference. Just be consistent!
$color--primary: hsl(0, 0%, 100%); // White color for most of the app.
$color--secondary: hsl(0, 0%, 90%); // Off-white for the progress indicator
$color--neutral: hsl(0, 0%, 1%); // Nearly-black color for text.

body {
  background-color: $color--background;
}
.viewport {
  background-color: $color--primary;
  box-shadow: 0 1rem 2rem hsla(0, 0%, 0%, 0.2);
}

Next we’ll do some placeholder images in this puppy and style up the slider.

In the HTML, we can use source.unsplash.com to get a random image that generally fits the size we want.

<div class="main__slider">
  <img
    class="main__slide-image"
    src="https://source.unsplash.com/random/1350x1080"
  />
</div>
<!-- ... -->
<div class="aside__slider">
  <img
    class="aside__slide-image"
    src="https://source.unsplash.com/random/1350x1080"
  />
</div>

In the SCSS, we’ll use the same code for the images twice, so let’s make it a @mixin. We’ll include that for both slide images and use overflow:hidden for the wrapping slider elements.

@mixin slide-image {
  position: absolute;
  height: 100%;
  object-fit: cover;
}
.main {
  // ...
  &__slider {
    //...
    overflow: hidden;
  }
  &__slide-image {
    @include slide-image;
  }
}
.aside {
  //...
  &__slider {
    //...
    overflow: hidden;
  }
  &__slide-image {
    @include slide-image;
  }
}

I think the last two kinda strange parts of this are the social links and the progress indicator. Let’s kick those off.

Progress indicator

In CSS grid, you can actually use pseudo elements as grid-level elements, and that works out great for this example, where the social links are divided by two dashes. We already set the social links up as a grid, but now lets place the pseudo-elements in that grid:

.social-links {
  // ...
  &:before,
  &:after {
    content: '';
    display: block;
    width: 1rem;
    height: 0.1rem;
    background: $color--primary;
  }
  &:before {
    grid-column: 2;
  }
  &:after {
    grid-column: 4;
  }
}

That looks about right to me!

Next let’s do the progress indicator. We’ll use pseudo elements for the numbers at the start and end, and use <li> elements in between to show which slide is currently active.

.progress-indicator {
  // ...
  &:before,
  &:after {
    color: $color--neutral;
  }
  &:before {
    content: '01';
  }
  &:after {
    content: attr(data-slides-count);
  }
  &__bar {
    width: 1.5rem;
    height: 0.2rem;
    background: $color--secondary;
    &--active {
      background: $color--neutral;
    }
  }
}

Remember when we used a data-attribute to set the slides count? Here’s where it comes in handy. We can make that dynamic in the Vue step but for now we just did it manually.

<ul class="progress-indicator" data-slides-count="03"></ul>

Real nice:

I’ll breeze through the rest of the styles we’ll be adding. It’s mostly simple visual stuff like setting colors or font sizes — no more weird grid hackery. After all that, our slider’s about ready to become interactive!

Interactivity With Vue.js

The first thing we’ll do is get Vue included and turn our “app” into an App™.

In CodePen, under the Javascript settings tab, you can add Vue as an external resource:

Once we’ve got Vue included, let’s add an ID to the markup of the app and initialize a Vue instance.

<div class="viewport" id="app"></div>

const app = new Vue({
  el: '#app',
});

Adding slides

In our Vue instance, let’s add some data for slides and a currently-active slide index, and then populate that data in the template markup.

const app = new Vue({
  el: '#app',
  data() {
    return {
      currentActiveSlide: 0,
      slides: [
        {
          headline: 'Lorem ipsum dolor sit amet',
          img: 'https://source.unsplash.com/random/1350x1080',
        },
        {
          headline: 'Consectetur adipiscing elit, sed do.',
          img: 'https://source.unsplash.com/random/1350x1081',
        },
        {
          headline: 'Eiusmod tempor incididunt ut labore.',
          img: 'https://source.unsplash.com/random/1350x1082',
        },
      ],
    };
  },
});

<div class="main__slider">
  <img
    v-for="(slide, index) of slides"
    :key="index"
    v-if="index === currentActiveSlide"
    class="main__slide-image"
    :src="slide.img"
  />
</div>
<div class="main__headline">
  <span
    v-for="(slide, index) of slides"
    :key="index"
    v-if="index === currentActiveSlide"
    class="main__headline-span"
  >
    {{ slide.headline }}
  </span>
</div>

You’ll notice we didn’t do anything for the slider in the <aside> section. That’s because I want the aside slider to always show the slide directly after the currently active one, or show the first slide if we’re at the end of the slides. I can do this with a Vue computed value we’ll call nextActiveSlide.

const app = new Vue({
  // ...
  computed: {
    nextActiveSlide() {
      return this.currentActiveSlide + 1 >= this.slides.length
        ? 0
        : this.currentActiveSlide + 1;
    },
  },
});

And once we’ve got that we can do this in the template:

<div class="aside__slider">
  <img
    v-for="(slide, index) of slides"
    :key="index"
    v-if="index === nextActiveSlide"
    class="aside__slide-image"
    :src="slide.img"
  />
</div>

Last thing to do is the progress indicator. We can do this all in the template, by creating as many progress bars as there are slides, and then conditionally adding a class if it should be active.

<ul class="progress-indicator" :data-slides-count="'0' + slides.length">
  <li
    v-for="(slide,index) of slides"
    :key="index"
    :class="index === currentActiveSlide ? 'progress-indicator__bar  progress-indicator__bar--active' : 'progress-indicator__bar'"
  ></li>
</ul>

Navigating between slides

The actual slide navigation is pretty simple, thanks to Vue – it’ll listen to the currentActiveSlide value and change everything we need based on that. We’ll add a method to handle slide changes. I’ve elected to be kinda wordy with this method for the sake of readability, but you could be much more concise!

const app = new Vue({
  // ...
  methods: {
    // We'll pass the function either 1 or -1 to indicate which direction we'the slides will go
    handleSlideChange(val) {
      let direction;
      const calculatedNextSlide = this.currentActiveSlide + val;
      if (val > 0) {
        direction = 'next';
      } else {
        direction = 'previous';
      }
      if (direction === 'next' && calculatedNextSlide < this.slides.length) {
        this.currentActiveSlide += val;
      } else if (direction === 'next') {
        this.currentActiveSlide = 0;
      } else if (direction === 'previous' && calculatedNextSlide < 0) {
        this.currentActiveSlide = this.slides.length - 1;
      } else {
        this.currentActiveSlide += val;
      }
    },
  },
});

Then in our markup we’ll update those buttons in the <aside> section so when clicked, they call that handleSlideChange() method.

<div class="aside__nav">
  <button class="aside__button" @click="handleSlideChange(-1)">←</button>
  <button class="aside__button" @click="handleSlideChange(1)">→</button>
</div>

And just like that, we’re all hooked up to data, slidin’ around, and ready to animate.

Animating With Vue.js <transition> and <transition-group>

In Vue, you can use the <transition> component to trigger animations in CSS or fire JavaScript methods on state changes. We’ll be handling all of our transitions with CSS this time around, but you can check the exceptional Vue docs for more potential uses. The general flow is that

Let’s start by transitioning the headline when you change slides with <transition-group>, which is best for list transitions.

Transitioning the headline

The first step is to convert the .main__headline div into a <transition-group>:

<transition-group
  tag="div"
  class="main__headline"
  name="main__headline-span"
  mode="out-in"
>
  <span
    v-for="(slide, index) of slides"
    :key="index"
    v-if="index === currentActiveSlide"
    class="main__headline-span"
  >
    {{ slide.headline }}
  </span>
</transition-group>

There are a few things going on here:

We replaced the <div> element with a <transition-group tag="div"> element. The group will render as a <div>.
We gave that transition group a name of main__headline-span — what this means is that when a transition is occurring, it’ll apply the transition classes to its children with this prefix. For example:
- .main__headline-span-enter-active
- .main__headline-span-leave-to
(This will come in handy when we’re writing our transition code in SCSS.)
We set the mode to “out-in” — this basically means the element that we’re transitioning out will be completely transitioned out before we start transitioning in the new element.

Now we can write the CSS to make some magic happen.

// ...
.main {
  // ...
  &__headline-span {
    position: absolute; // This is just to make sure there's no jumping around as we transition elements out and in.
    width: 60rem; // We have to add this because we're absolutely positioning the headline-span
    &-enter,
    &-leave-to {
      // This is an easy way for us to keep the animation code with the component code. This selector outputs `.main__headline-span-enter, .main__headline-span-leave-to {}`
      transform: translateY(1em);
      opacity: 0;
    }
    &-enter-active,
    &-leave-active {
      transition: all 300ms;
    }
    &-enter-active {
      transition-delay: 700ms; // This makes the new headline take just a moment to come in.
    }
  }
}

Transitioning the slides using `clip-path`

Let’s use <transition-group> again to prepare the main and aside sliders to be animated.

<!-- ... -->
<transition-group
  tag="div"
  class="main__slider"
  name="main__slide-image"
  mode="out-in"
>
  <img
    v-for="(slide, index) of slides"
    :key="index"
    v-if="index === currentActiveSlide"
    class="main__slide-image"
    :src="slide.img"
  />
</transition-group>

Same as the previous example, we replace the slider wrapper <div> with a <transition-group> that gets the class of its children as a name attribute. That’s all it takes. Let’s write some more CSS.

I’d like to use the CSS clip-path property to transition the slides — I think it’ll be the most visually-satisfying way to achieve that wipe that happens in the Dribbble shot. We’re going to transition a clip-path: polygon() value. When a slide is active, the clip-path won’t clip any of the image:

Since we want to wipe from left-to-right, we need two different clip paths:

Clipped to the left side (“enter” state): polygon(0 0, 0 0, 0 100%, 0 100%)
Clipped to the right side (“leave-to” state): polygon(100% 0, 100% 100%, 100% 100%, 100% 0)

Let’s implement that in our SCSS. We’re reusing this animation for both sliders, so we’ll make it a mixin. (I also want a subtle zoom effect on the image.)

@mixin clip-path-wipe {
  clip-path: polygon(
    0 0,
    100% 0,
    100% 100%,
    0 100%
  ); // Specify the "slide visible" state
  &-enter {
    clip-path: polygon(0 0, 0 0, 0 100%, 0 100%);
    transform: scale(1.3);
  }
  &-leave-to {
    clip-path: polygon(100% 0, 100% 0, 100% 100%, 100% 100%);
    transform: scale(1.3);
  }
  &-enter-active {
    transition: all 700ms;
    transition-delay: 500ms;
  }
  &-leave-active {
    transition: all 700ms;
  }
}

Now let’s hook into this in the <main> slider.

.main {
  // ...
  &__slider {
    // ...
    background-color: $color--neutral; // This makes it so the slider background isn't just white.
    width: 70rem;
    overflow: hidden; // Make sure the image doesn't overflow when it scales up
  }
  &__slide-image {
    // ...
    @include clip-path-wipe;
  }
}

And again in the <aside> slider:

.aside {
  // ...
  &__slider {
    background-color: $color--neutral;
  }
  &__slide-image {
    // ...
    @include clip-path-wipe;
    &-leave-active {
      transition-delay: 200ms; // Offset this animation slightly from the main slider
    }
    &-enter-active {
      transition-delay: 600ms; // See above
    }
  }
}

Conclusion

And just like that, we’re all ready to rumble. If you wanted to, there are a couple of enhancements you could include:

Write some CSS to transition the progress indicator a little more smoothly.
Add a boolean loaded state to the Vue data(), and transition in the navigation and slider depending on whether loaded === true or not.
Use Vibrant.js or similar to set the background of the slider to an accent color of the slider image!

If you end up giving this a shot or customizing it in any way, let me know on Bluesky [@strange.website]({{ ‘bluesky’ | getSocialUrl(social) }})! I’d love to see it. Thanks for reading. As promised, here’s the finished pen.

P.S. This is my first tutorial-style blog post — please let me know if you have any feedback or found any problems with the post! Thanks for reading.

Uses

Henry Desroches — Wed, 01 May 2019 06:00:00 GMT

This is a non-exhaustive list of the tools I use in my day-to-day operation for design, development, and life as a human. If I’m missing something, let me know!

Hardware

Main Computer — 2023 MacBook Pro, 14-inch, 16GB M2
Webcam — Onboard Mac laptop camera ~~Logitech C920 Pro HD~~
Microphone — Blue Microphones Yeti Blackout. Got it for streaming, use it for everything.
Keys — GK64 custom build, with an acacia case, Elven keycaps, and Kailh box jade switches.
Phone — iPhone 14 Pro 256GB. Wouldn’t recommend it. I don’t think Apple holds the future of phones anymore. Might try a Nothing phone next.
Headphones — Nothing ear(open) for being out and about, Nothing ear(2) for when I need noise canceling, and Sennheiser HD 650at home. Love the wide sound stage.
Luggage — Chrome Niko Pack laptop & camera bag. It’s like bulletproof, effectively waterproof, and looks really tech-wear-y and rad.

Software

IDE — VS Code.
- Theme: Nord or Horizon Light (I know, *GASP*, a light theme) depending on the day (and the time of day).
- Font: Menlo, Monaco, 'Courier New', monospace; ~~SF Mono with a Fira Code fallback.~~
- Must-Have Extensions: Prettier, ~~GitLens & Vetur.~~
Terminal — I like Hyper.js — recently switched from iTerm almost solely based on the visual customization and JSON-based (instead of GUI) config.
- Theme: Nord, again.
- Prompt: Used to be a die-hard oh-my-zsh user, but it’s more than I need by a lot. Now I just use Spaceship.
Notes/Content — Obsidian.md and flat files for almost everything. ~~Notion. Notion holds my life together. This blog is published using Contentful.~~
Messaging — I use Discord and Telegram to message most folks.
UI/Prototype Design — I use Figma pretty much exclusively now. It just came down to like one frustrating day of fighting with Framer’s layout tools. ~~Framer X! I recently made the switch from Sketch and have not looked back. The code extensibility makes it a must-have for devsigners 🦄. Figma is also good.~~
3D Design — Gotta be Cinema 4D. I initially got hooked on it via Devon Ko’s amazing 3D For Designers course and now I can’t stop making weird stuff with it. I use Octane Renderer for most things.
Memes & One-Off Imagery — Photoshop lol
Vector Art & Iconography — Usually the twin swords of Illustrator, and Figma get me sorted.
Music — Spotify for everything. Spotify *used to actually do a really good job of suggesting music I’ll like.
VPN — It’s ${new Date().getCurrentYear()} — please, please, please use a VPN. I prefer Nord (lmao) but any one that you pay for is probably decent.
Password Management — I use 1Password for login management these days!
Productivity: — Alfred is a replacement for your Spotlight on Mac OS X that supercharges it with all kinds of useful featureset. It’s well worth paying for a license.

Deprecated

Backup Computer — 2015 MacBook Pro, 15" Retina, 2.2GHz Intel Core i7, 16GB RAM, Intel Iris Pro.
Additional Monitors — LG 4K for screen design and browsers/etc. and an LG Ultrawide riding shotgun, vertically-mounted for contextual peripherals (IRC, Telegram, Spotify, usually Hyper too!).
Tracking — Apple Magic Trackpad in Space Grey

Bad ux in everyday life: kitchen nightmares

Henry Desroches — Thu, 09 Jun 2016 06:00:00 GMT

This article was originally posted on the Universal Mind blog in June 2016.

It’s come to my attention lately that my kitchen is absolutely riddled with poor experiences. Most of the appliances and apparatus one uses on a day-to-day basis in the kitchen were invented or last revolutionized in the early part of the 20th century, and many of them have seen very little innovation, if any, since that time. In this UX- and CX-obsessed age, it seems totally unacceptable that we demand constant iteration and improvement of processes in our web applications, in our vehicles, and elsewhere, but settle for lackluster routines in the kitchen.

In the following exposition, I will outline some of the major experience flaws in a couple places in the standard kitchen.

The toaster

The conventional pop-up toaster you typically see in John Doe’s kitchen was invented in 1919 by Charles Strite, and looks about the same as it did when he initially received the patent for the device, save for a few standard additions like the toast-level knob and sometimes the bagel setting. This run-of-the-mill toaster is plagued with several major detriments, chiefly inconsistent functionality. I cycled through four toasters of varying major brands and continued to get bread that was grossly mistreated by the heating element, often leaving half unchanged while rendering the other half a tragically-charred wasteland.

Through extensive research and great personal cost, I managed to find a unit with a consistent heating element, but this effort should have been managed by the toaster manufacturers in question. With little exception, all new, modern vehicles drive smoothly off the dealership lot, without random changes in speed or wheels that only work a fraction of the time — by the same token, all toasters should do their job without pause or error. Basic functionality shouldn’t be a luxury or difficult-to-find affordance.

Toasters typically let users select a level of toast in an iconographically-vague or otherwise unclear manner, such as a numbered scale. At no point does a user decide they want “3” toast — the lack of clarity here forces one to employ guess-and-check methods and dejectedly munch their way through under-crusty or over-crispy slices. Some variants have attempted to combat this with hieroglyphics indicating differing degrees of toastiness, but the user’s perception of a certain amount of crosshatching on a rudimentary picture doesn’t necessarily coincide with their ideal char level on their bread.

Not lastly of the toaster’s UX sins stems from its traditionally opaque walls. A lot of the schism encountered when trying to nail down an ideal toast level could be countered if you could just see how dark the darn bread was getting. Breville’s “Lift & Look”™ solution (which allows the user to check the toast level without canceling the heating cycle) is a step in the right direction, but could be improved. Morphy Richards’ glass-walled design is the closest to completely solving this problem, but while everyone deserves a seamless toast experience, not everyone can afford to spend $200+ on a toaster.

Rice, flour, and sugar packaging (oh my)

This is one that confounded me long before I had even heard the term “UX” — flour, most culinary sugars, and rice are usually found in stores in tightly-packed paper or plastic bags. This packaging makes it difficult if not impossible to reseal or contain them once opened, without third-party storage jars/boxes/bags. There are very few other food items that ship with this necessity. Crackers come in boxes, butter comes in a wrapper or a box — it seems almost a bizarre oversight that the powdery or granular food items would be assigned to the type of packaging that would be most logistically difficult for it to be retrieved from. The tight packaging is designed with shipping convenience in mind, not the consumer; the amount of flour exploding over unsuspecting users’ countertops at any given moment is unforgivable.

Disclaimer

This is a list of poor user experiences I’ve had in my culinary ventures — many of these could arguably be attributed to “user error” or “expecting too much of a toaster”, but I believe that in 2016, I shouldn’t have to hunt excessively or pay premiums for a toaster that works, nor should I have to buy specialized containers for some food products, when most others leave the shelf of the grocery store in a package they’re fine occupying indefinitely. I’d love to hear your input — feel free to dispute my thoughts or (much more likely) to agree vehemently with me via email.

Agile for the rest of us

Henry Desroches — Mon, 05 Jan 2015 06:00:00 GMT

This article was originally written for the Fusionbox blog in January 2015.

The Fusionbox process takes many pages from the Great Big Book of Agile Methodology to streamline and modernize the production of web content, etcetera, but for the folks at home, what is agile development? Where did it come from? Who let it in? Should we feed it?

Waterfall

Software development used to be treated the same as the development of any other product. Guidelines would be set, features would be decided upon, and a timeline would be locked in place. This is because in the worlds of manufacturing and construction, after-the-fact changes to any design or aspect of a project are prohibitively costly, if not impossible, so it only makes sense when planning to “pick it and stick with it”. When software development was in its infancy, no formal alternative methodologies had been invented, so the manufacturing model was just adapted to fit the software industry. The idea is that requirements are established, and production ensues.

This became known as the Waterfall Method, which until recently tended to be the standard for software dev. In its purest form, Waterfall designated this list of steps:

Product requirements specification
Design
Programming
Testing and debugging
Delivery of product
Maintenance

With these steps, it’s fairly easy to budget and set timetables, because it is already known on Day 1 of design what the finished product will be when on Day X when it is delivered. Also, if a developer can’t be involved in the project for one reason or another, the concrete plan makes it easy for another programmer to hop right into his or her spot.

Here’s the problem:

The Waterfall method is typically incredibly rigid and inflexible. Altering the project design at any stage in the project is nearly impossible. What happens when down the road, someone decides they want some extra functionality for their website? Waterfall says no. When an apartment building is planned, no one decides they want an extra floor or balcony at some point during the middle — but when designing a website, it’s not uncommon in any capacity for requested changes to arise. “Let’s add an eCommerce section to our site”, “can we put the navigation bar on the side, rather than the top?”, “how do we add mobile functionality to our page?” Those suggestions and queries are very difficult to respond to in Waterfall.

And what about debugging? The testing stage of Waterfall method is deferred until especially late in the project. To put this in perspective, remember that apartment building we were talking about earlier? Construction contractors won’t test if the building will stand on its own while they’re still pouring the foundations. Which works quite well for the apartment building. So much planning has gone into that high-rise since the start that the contractor pretty much knows without a doubt that his product is structurally sound. However, software programs or websites are not high-rises. It’s so often impossible to predict how the many MANY different pieces of a site will interact with each other, and this leads to problems in the debugging phase. All of the design steps and all of the programming steps will finally end up in the lap of a QA tester who has a week or sometimes as little as a day to solve every little problem and glitch in the product to deliver it on time.

At the end of those months and months of painstaking planning and prediction, the “finished” product is buggy and might not meet all the needs it is supposed to fill because the requirements may have changed at some point during the process.

Agile

So by now it’s easy to see that building a website is a different task entirely from building an apartment tower. Why would the same development process be applied to both? Pioneers like E. A. Edmonds, Tom Gilb, and Dan Gielen all concurrently started publishing or applying different ideas about adaptive software development in the early- to mid-seventies, but it wasn’t till the mid-nineties that those methodologies started seeing widespread use. Initially, there were many different forms — Rational Unified Process, Scrum, Dynamic Systems Development Method, etc. — but these were for the most part collated under the term Agile Development after the “Agile Manifesto” was published in 2001. (For more information on the Manifesto, see here — it’s a quick read.)

Agile focuses on team-based, adaptive development. Rather than setting all the requirements and solutions at the beginning of the process and not obliging any sort of change, requirements are allowed to vary and solutions evolve in real-time based on those changes. The Agile approach, in essence, works like this:

The process is iterative — rather than the Waterfall style of an ordered list, it is based on the cyclical use of repeated steps. The requirements for a software product are gathered and organized by the team or by a team leader into “sprints” — short bursts of development activity resulting in large leaps forward in production. Frequently, the minimum requirements for an operable product are put into the first few sprints, which means rapid delivery of useful software is standard.

The best analogy we’ve found to describe Agile sprints is this: With Waterfall method, first built are the wheels, and then the chassis, and then the engine, and eventually those leather seat covers are tossed on and that new “fresh-off-the-lot” smell is pumped in, and there is FINALLY a car that can be driven away. With Agile, rather than taking all that time to build a whole car (which we’ve established may or may not work as well as it should), the first “sprint” builds a skateboard. It’s not the aerodynamic supercar that is the end goal, but it’ll get someone down the street from their mom’s house to the grocery store, and it’ll be produced and deliverable in a fraction of the time.

Through further sprints, which are usually a few days or a week long, the skateboard is built out more and more. Maybe a bicycle, second, and then halfway through go-cart stage, someone might decide they actually wanted a Mazerati, not a Ferrari. With Agile, that’s not a problem. One of the primary principles of Agile development is to welcome changing requirements, even late in development. With each sprint, or iteration, working software is delivered — visible proof of progress to put a client or customer’s mind at ease.

“Well, that’s awesome, it’s so intuitive and fluid, why would anyone NOT use Agile?!” Agile isn’t a be-all, end-all solution to development. Agile is very flexible, but that means it operates without the structure of Waterfall method, and that CAN have some drawbacks. Agile projects are harder to predict — changing requirements also means changing budgets and timelines, and that’s not how most business works. Waterfall was so widely accepted because it makes sense outside the world of web development, but Agile is not the same. While it is more intuitive to design and development teams, it is truly a leap of faith for different departments in their organization, or for clients in an agency context. The price paid for more efficient and functional software is sometimes an extension on deadlines and budgets.

So What?

Ultimately, neither methodology is “better” across the board. Waterfall is sometimes better for static projects, where the requirements are not expected to change at all, or for situations where a client can’t commit to a lot of communication, or the deadline or budget is adamant and inflexible. Here at Fusionbox, we love how collaborative and personal Agile development is. We think face-to-face conversation is the best form of communication, and we love giving the continuous attention to technical excellence and good design that is essential to the Agile process…

Writing from the desk of Henry (From Online)

Dark Forestry

Dark Forestry

I made a Plex server

Hardware

Server setup

Folder structure

Installing Plex

Adding media

On Windows

On MacOS

Granting access to the Plex library

Granting access to the NAS

Going further

Expanding the RAM

Adding transcoding drivers

Plex Pass

Additional pieces

It doesn’t matter if it works

AI works

AI doesn’t work

The material outcomes

Eat the frame

The first thing I did last year was run

Things I did in 2025 that have nothing to do with the internet

What I did

January

February

March

April

May

June

July

August

September

October

November

December

What I’ll do now

A Website To Destroy All Websites

A website to destroy all websites.

table of contents, of course

it wasn’t always like this.

the textile revolution

antibiotic technology

space exploration

convivial life & convivial tooling

Teaching & learning on the Web

Connecting with friends on the Web

Coding for the web

so where do we go from here?

it’s personal websites.

Start small

Reduce friction to publishing

Don’t worry about design (unless you want to)

Use the IndieWeb

Join us in sharing what you’ve made

Economics & labor rights in AI skepticism

Some context on capitalism

Where LLMs come in

What is there to do?

How to collect Webmentions for your site

Authenticating with IndieAuth via IndieAuth.com

Identity Verification

Actually collecting Webmentions using Webmention.io

Next steps for Webmentions

Further Reading

Well, what if I'm wrong?

You can’t possibly know

Besides, we donate to legacy aid institutions

So what if I’m wrong?

But what if I’m right?

A case for unconditional giving

Why you might not

I don’t have any money to give

What if they use it for drugs/cigarettes/alcohol/The Wrong Thing?

Shouldn’t I give them this toiletries/PB&J/care package I keep on hand?

What about the guy that my buddy says drives a Mercedes home from panhandling every day?

They should seek help from government programs/soup kitchens!

Why you really ought to