I've always liked dev tools as a place to learn about how HTML, CSS and JS actually work. The latest iteration of that: Firefox to show which properties don't actually do anything on a given element
RT @patrickbrosset@twitter.com
I've been involved in DevTools dev for years, and I've both had and heard many good ideas to improve it.
It's always a special feeling seeing on of them finally take shape.

Latest one to date: detect C…

And yes, Firefox is still fighting a huge uphill battle against Chrome interop, and I have no idea how they're even able to keep their heads above water. They need all the help they can get, because they're battling stupid bugs like this every single day.

WebKit (Safari) is no less amazing for the comeback they've pulled off in the past few years, although they have fewer interop pressures. Web devs make sure their sites work in Safari, because the CEO has an iPhone.

> 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.


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 >.<

Rewrote emoji-mart's tests to run in Jest rather than Karma (github.com/missive/emoji-mart/). Gotta admit, Jest is nice:

- can test React components purely in Node
- has a concept of "snapshots," where it writes your expected component tree to a file and then tests against that file, which is what I want to do with my tests 99% of the time, except now it's automated
- I didn't even need a config file, what year is this

"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

agripongit.vincenttunru.com/# Note, IMHO, Knowing #Git is probably a key skill for #FLOSS dev today ? If you don't check : A Grip On Git : A simple, visual Git tutorial by @vinnl

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.

We'd like to thank you all for the follows, responses and support the last few days... Show more

have you ever noticed that someone post a screenshot of text without providing an image description, preventing you from being able to read it? or maybe they posted a huge amount of text that just can't possibly be described with the image description feature?

simply tag @OCRbot in a direct reply to the image. it will download the image and scan it using tesseract OCR to output the text contained in the image!

because OCRbot runs on fedi.lynnesbian.space, it has a character limit of 65535, so even the longest images should work OK!

check the reply to this image to see it parsing the attached screenshot!

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

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.

Show more

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!