Vincent Tunru @vinnl@mastodon.social

> In this paper, we aim to answer a long-standing open problem in the programming languages community: is it possible to smear paint on the wall without creating valid Perl?

> We answer this question in the affirmative: (...) merely 93% of paint splatters parse as valid Perl.

The idea is very funny, the presentation is hilarious.

http://colinm.org/sigbovik/

Aargh. I just pressed Ctrl+Q instead of Ctrl+W, and after a restart of Firefox, the Google Inbox tab I had open started redirecting to Gmail >.<

"I don't really want to argue against optional chaining because it's so popular and I don't want to make enemies, but here's how *other* people might argue against it."

- @rauschma

A major advantage of virtual DOM-based approaches I'd started to take for granted: being able to run unit tests without firing up a browser.

Tests become so much less brittle and much quicker, and I've almost forgotten the annoyance of debugging tests rather than code.

All this is powered by freely available open source tools. More info at my blog: https://vincenttunru.com/fearless-deployments/

To make that even easier, the pipeline also runs a visual regression test, which compares the various states of the app to reference screenshots created earlier. This prevents the inclusion of unintended changes, and allows me to view the effects of my changes at a glance.

Next to the app itself, it also deploys a Storybook, showcasing the app in the various states it can be in. This is perfect for quickly verifying the effect of styling changes, without having to run through countless scenarios in order to reproduce specific app states.

After every deployment, instances of headless Chrome and Firefox are fired up. They visit the deployed app and run some basic checks, ensuring that the infrastructure was set up correctly, the deployment was successful, and the server runs as expected.

This "Review App" has its own URL, its own environment-specific build artefacts and reports, and a separate database. I can thus play around freely without interfering with production. It also allows me to verify reproducibly whether database migrations work.

The cool thing is: new production-like environments are deployed for every Git branch I create. When I'm working on an issue, I create a new branch associated with that issue, which will set up a new environment in which that issue's fix can be tested in isolation.

By itself, the deployment pipeline already provides several reassurances for every change: the code still builds, the tests still succeed, etc. It also makes code coverage reports available for those specific changes.

I'd like to showcase the deployment pipeline I use daily. It results in fearless deployments to production, and an excellent developer experience. I'll start with the most boring parts, and save the best for last.