I’ve been writing some particularly detailed comments in my code lately and stumbled upon an Reddit post asking about some of the best comments people have come across.
This particular method is absolutely genius.
Book Review: Deep Work by Cal Newport
The pandemic forced a change in the way many knowledge workers work. Many of us have shifted to working from home — some roles are permanent.
I’m fortunate to be in such a position, but it’s been both a blessing and difficult to adjust to.
Distractions are frequent. From regular Zoom meetings, Slack messages and various alert notifications, to email. I think a number of people (myself included) are over compensating in our communication styles.
For software engineers, this causes a lot of context switching. And that’s generally a bad thing.
Context switching can lower productivity, increase fatigue, and, ultimately, lead to developer burnout. Switching tasks requires energy and each switch depletes mental focus needed for high cognitive performance. Over an entire workday, too many context switches can leave developers feeling exhausted and drained.
The impact of context switching lingers even after switching tasks. Cognitive function declines when the mind remains fixated on previous tasks, a phenomenon known as attention residue.
I’ve recently felt myself feeling drained and less productive that usual. While browsing a thread on Hacker News, a comment on Hacker News suggested that someone should read Deep Work by Cal Newport for ideas on how to regain focus and minimize distractions. It was the first I’d heard of that book.
It was pretty enlightening and I was pretty hooked!
It has a number of self-help style steps (that are somewhat obvious, in hindsight) that you can take to improve your situation and increase productivity (e.g., carve out set times when no one can bother you, like early in the morning or late at night, keep consistent times, set reasonable expectations and have a plan, don’t wing it).
But it also had shared some interesting research on how our brains have been rewired to have shorter attention spans, thanks to all our fancy pants technology.
“Once your brain has become accustomed to on-demand distraction, Nass discovered, it’s hard to shake the addiction even when you want to concentrate. To put this more concretely: If every moment of potential boredom in your life—say, having to wait five minutes in line or sit alone in a restaurant until a friend arrives—is relieved with a quick glance at your smartphone, then your brain has likely been rewired to a point where, like the “mental wrecks” in Nass’s research, it’s not ready for deep work—even if you regularly schedule time to practice this concentration.”
Yeah… guilty.
Anyway, definitely want to put some of these ideas into practice. It was a quick read and had some concrete steps on how to improve attention and focus that I can start using immediately. Excited to try it!
The best form of debugging…
Experimenting with parallel computing using node worker_threads
I’ve wanted to play around with worker threads in Node JS, so I put together this little repository that demonstrates how it all works. Check it out here.
In order to simulate multiple threads that are each processing data, each worker thread uses a randomly generated timeout between 100 to 700 milliseconds. In addition, it has a random number of loops (between 10 and 1000) that must be completed before the worker is terminated.
It’s kind of fun to watch the tasks run and automatically complete inside the terminal (check out the screenshot of the output up top).
Advent of Code: The most wonderful time of year…
December is upon us! That means the latest edition of the Advent of Code is here.
The Advent of Code is essentially a daily programming challenge featuring a new problem each day through Christmas. The problems all relate to a certain theme. This year, it sounds like we’re going on an undersea adventure.
— Day 1: Sonar Sweep —
You’re minding your own business on a ship at sea when the overboard alarm goes off! You rush to see if you can help. Apparently, one of the Elves tripped and accidentally sent the sleigh keys flying into the ocean!
Before you know it, you’re inside a submarine the Elves keep ready for situations like this. It’s covered in Christmas lights (because of course it is), and it even has an experimental antenna that should be able to track the keys if you can boost its signal strength high enough; there’s a little meter that indicates the antenna’s signal strength by displaying 0-50 stars.
Your instincts tell you that in order to save Christmas, you’ll need to get all fifty stars by December 25th.
Collect stars by solving puzzles. Two puzzles will be made available on each day in the Advent calendar; the second puzzle is unlocked when you complete the first. Each puzzle grants one star. Good luck!
I’ll be partaking using my preferred language of choice: x86 assembly.
I kid, I kid. JavaScript.
Generating terrain maps
Recently, I went down a rabbit hole attempting to learn how to generate interesting looking maps for games (insert mind-blown-gif here). While I’m not going to be using Voronoi diagrams anytime soon, I am still interested in attempting to generate Civilization-like maps.
Most map generation algorithms rely on perlin noise. I wanted to go a different route.
So far, these are the rules that I’ve come up with for my algorithm:
1. Create a grid of some given size (e.g., 100 x 50). Set all tiles to “ocean”.
2. Randomly pick 8 tiles (variable) across the map to seed as “land”.
3. Now iterate across all tiles on the map and build an array of tiles that are “ocean” tiles but have a land tile N/W/S/E of them.
4. Once you have this array, randomly pick a single value. Flip it from “ocean” to “land”
5. Repeat step 3 until a given number of tiles have been filled across the grid (e.g., for an “Earth-like planet”, 30% of tiles will be land).
6. Now, to add some additional randomness — iterate across all tiles and build an array containing all “land” tiles next to water (N/W/S/E).
7. Randomly pick 1, flip from land to ocean.
8. Repeat step 6 a given number of tries (e.g., 100).
9. Done! (Maybe)
Height maps, biomes and all that can come later. To quote Amit, whom I linked to earlier:
The most realistic approach would have been to define elevation first, and then define the coastline to be where the elevation reaches sea level. Instead, I’m starting with the goal, which is a good coastline, and working backwards from there.
Anyway, it’s been kind of neat to figure out.
Another example map, created using the above rules:
Revert my last commit
Story of my life lately.
For those who appreciate clean air…
It seems like every year, late in the summer or early in the fall, the air in the Bay Area fills with thick smoke from raging infernos happening around northern California. The air is hazardous to breath, preventing you from taking kids to the park, walking your dog or even opening your windows.
Last year, we made the wise decision to purchase an air purifier, which admittedly, looks like a giant iPod shuffle.
As fires continue to burn around these parts, we’ve started to rely on air quality data from PurpleAir, which monitors air quality data from a series of IoT sensors that people can purchase for their homes or businesses.
You can view a map featuring realtime data collected from their sensors. Here in the Bay Area, the sensors are quite ubiquitous and can give a more realistic pictures of air quality near your home.
For example, here is the current air quality around the Bay Area from PurpleAir while I write this post.
For comparison, here is the current air quality map for Bay Area Air Quality Management District (BAAQMD), which we used to reference when trying to determine local air quality.
The fidelity you get from PurpleAir is pretty amazing.
Knowing this, I decided to write a Node app that periodically queries PurpleAir for air quality data from a sensor located a few blocks from our house. It continuously runs on a Raspberry Pi setup in our entertainment center and sends me a text message to close our windows when the AQI crosses above 100.
I’ve made the source code available on Github. Check it out!
A simple dark-mode hook for React
I recently wrote a simple hook for React to automatically detect a device’s dark mode preference (as well as any changes to it) and style your web app accordingly, using something like ThemeProvider from styled-components.
It was developed as part of a side project I was hacking around on using my personal React Starter Kit, which is my own React project for quickly getting prototypes and side projects up and running.
I’ve released this as a standard GitHub repo instead of an NPM module due to the simplicity of this hook, especially in light of one-line packages breaking the Internet. To use it, just copy it into your project where needed.
I’ve released this under an MIT license. Feel free to use as-is, fork, copy, tear apart, profit, and share as you wish.
You can check out the code on Github.
Fixing rendering issues with React and IE11
Happy April Fools’ Day. This post is no laughing matter because it deals with IE11. 🙀
Awhile back, we had an issue where visitors to our site would hit our landing page and not see anything if they were using Internet Explorer 11. The skeleton layout would appear on the screen and that was it.
Debugging the issue using IE11 on a Windows box proved to be difficult. Normally, we open up the inspector window, look for an error stack and start working backwards to see what is causing the issue.
However, the moment I opened the inspector, the site would start working normally again. This lead me down a rabbit hole and I eventually found a relevant post on StackOverflow: “Why does my site behave differently when developer tools are open in IE11?”
The suggested solution was to implement a polyfill for console.log, like so:
if (!window.console || Object.keys(window.console).length === 0) {
window.console = {
log: function() {},
info: function() {},
error: function() {},
warn: function() {}
};
}Interestingly, we didn’t have console.log statements anywhere in our production build, so I figured it must be from some third party library that we were importing. We added this line of code at the top of our web app’s entry point to try and catch any instances of this. For us, that was located at the following path: src/app/client/index.js
After rebuilding the app, things were still broken, so the investigation continued.
We eventually concluded that the issue had to do with how our app was built. Our web app is server side rendered and we use Babel and Webpack to transpile and bundle things up. It turns out, Babel wasn’t transpiling code that was included in third party libraries, so any library that was using console.log for one reason or another would cause our site to break.
(The fact that IE11 treats console.log statements differently when the inspector is open vs. not is an entirely separate issue and is frankly ridiculous.)
Knowing this, we were eventually able to come up with a fix. We added the polyfill I posted above directly into the HTML template we use to generate our app as one of the first things posted in the head block. The patches console.log so that it’s available in any subsequent scripts (both external or not) that use it.
<!doctype html>
<html>
<head lang="en">
<meta content="user-scalable=no, width=device-width, initial-scale=1.0, maximum-scale=1.0" name="viewport"/>
<meta charSet="UTF-8"/>
<script>
if (!window.console || Object.keys(window.console).length === 0) {
window.console = {
error: function() {},
log: function() {},
warn: function() {},
info: function() {},
debug: function() {},
};
}
</script>After that, everything started working again in IE11.
#TheMoreYouKnow