Welcome to my PinkLetter. A short, weekly, technology-agnostic, and pink newsletter where we cultivate timeless skills about web development.
What’s your definition of professional?
This week, I finally pulled a ticket that would justify merging two repos in the legacy project I’m on.
Since Rails integrates with Webpacker (a wrapper around Webpack), I just needed to figure out the current configuration.
As soon as I noticed webpack.config.js
is 454 lines long and read the initial comment, I was already in despair:
/* Yay! This works! ...but it's probably a bit overwrought for our configuration. Should be pared down. */
It only got worse when I found out the production configuration sits in a different 373 LOC file.
This is not professional.
The comment provides absolutely zero value. Given the line count and the shape of the file, my reaction to “it’s probably a bit overwrought” was: “no shit!”
And yeah, this is the same codebase where I keep finding life-saving comments like:
private updateAlertVisibility() { if (this.isVisible && !this.isAlertPresented) { // Show alert this.showAlert(); } else if (!this.isVisible && this.isAlertPresented) { // Remove alert this.removeAlert(); } }
or just-so-you-know comments like:
FIXME: This service doesn’t handle charge errors from Stripe!
One makes me angry; the other doesn’t make me sleep at night.
But you know what? I’m still grateful to be given this opportunity.
This week, I developed a proof of concept: merged the repos and deployed successfully. Not only I learned a ton on the way, but the removed complexity will help with unlegacying further.
That is if I manage to deploy the change to production. Fingers crossed!
Want to know how the story will end? Hit reply and let me know!
Tail-Call Elimination by Evan Czaplicki
First, a common technique for writing recursive functions is to create a function foo with the API you want and a helper function fooHelp that has a couple additional arguments for accumulating some result. This definitely can come in handy if you are working on some more advanced algorithms!
Second, it turns out that “Is recursion going to crash my program?” is not a practical concern in functional languages like Elm. With linear structures (like List) we can do tricks to take advantage of tail-call elimination. With branching structures (like Dict, Set, and Array) you are likely to run out of disk space before you run out of stack space. Those are the only two kinds of structures we have!
Finding the Root Cause of Slow Postgres Queries Using EXPLAIN by pganalyze
This situation might look familiar: Our application is slow, but we don’t know why. We look at our monitoring dashboards and finally arrive at the center of our problem:
A Postgres query that is taking longer than it should.
Now where do we go from here? How can we understand better what our database does when it executes our slow query to retrieve our data?
How to Find and Remove Dead CSS by Justin Searls
Do you have a pile of old CSS styles that you’re pretty sure are no longer referenced anywhere, but that you’re nevertheless afraid to delete because you have no way to be sure that no musty corners of your site somehow depend on them to render correctly?
I’ve been saying for years that the most valuable uses for code coverage have nothing to do with testing, and today I was happy to add another great use case: gaining confidence over which styles are actually safe to delete. The approach in this screencast shows a way to record and combine the code coverage results for our site’s CSS across each web page.