I designed a fully revertible modification for a Vornado 633DC fan so I could control it remotely over WiFi. The final result is concealed entirely within the fan’s housing, leaving no visible modification.
Docker volume mounts are commonly used to allow specific files and directories to be persisted outside of the container lifecycle. In other words, volume mounts provide a way of letting data persist even after a container has been deleted. The other convenient effect of this behaviour is that it can allow data to be shared between multiple containers.
This is often leveraged in web application configurations where one container may be running software responsible for the generation of static assets, while another container may be be responsible for the serving of those assets (e.g. Nginx or Caddy).
If you’re running Arch Linux on a laptop with a supported finerprint reader, you might like to be able to use your fingerprint to unlock after suspend. At first glance of the Arch Wiki fprint page, it would appear you can simply add some config into /etc/pam.d/i3lock and you’d be good to go. However, the common approach of using a Systemd unit file with Before=sleep.target to start a lock application (i3lock, in my case) won’t work, and you’ll find the lock application rejecting your fingerprint every time.
When async/await was introduced to ECMAScript it was generally pretty celebrated. Nearly every engineer I spoke to raved about the feature, how it “finally” made asynchronous operations in JS not confusing.
I’ve been using async/await professionally for a couple of years now. Through trial and error, I feel I have a good understanding of when to use it, and when it isn’t the best hammer with which to whack your asynchronous nails.
My colleagues and I once faced a recurring problem: we’re terrible at keeping plants alive. But as software developers in an open-plan, plant-plentiful office, something needed to be done, and it needed to be cheap. My love of DIY IoT and Serverless led me to a vision of a swarm of ESP8266 modules monitoring plants, publishing data with MQTT to AWS IoT, which in turn triggers a Lambda Function, writing and comparing data in DynamoDB, and finally, notifying us on Slack when a given plant needs watering.