Monday, January 18, 2021

Controversy corner: Wired earbuds vs Airpods

This is a "just for fun" post on the pros and cons of traditional wired earbuds vs Apple AirPods for everyday use. 

Hat tip to my brother Jeremy for inspiring me to finally put this post together. He was recently seen on Instagram rocking some sweet wired earbuds, even though he's retired, and has sufficient discretionary funds to buy himself AirPods, if he so chose!


Wired Earbuds

Apple AirPods

Price tag 💸

✅ From around US $10-15 💰

US $159+ 💰💰💰💰💰💰💰💰💰💰

Ease of switching between multiple devices (e.g. iPhone 📱 and MacBook 💻) 

✅ Plug them in

Fiddle with the Bluetooth settings menu

Troubleshooting pairing issues

✅ 100% reliable

Seldom, hopefully...?

Charging ⚡

✅ Never needs charging

Up to 5 hours listening per charge; requires charging case + Apple lightning cable or wireless charging mat ($)

Anxiety when they get lost 😰

✅ Shrug and buy a new pair

High

Works with Nintendo Switch, the treadmill TV at the gym, the entertainment systems on airplanes

✅ Plug them in

No; can work around with Bluetooth adapter ($)

Audio quality 🎶

✅ Great

✅ Great

Can simultaneously charge device 🔌 and listen

✅ Yes (on devices with a 3.5mm jack, like my iPhone 6S)

✅ Yes

Risk of inadvertently getting yanked or knocked out of ears 👂

Wires can get caught when doing chores

✅ Minimal 

Works with newer iPhones

Dongle needed 🙄

✅ Yes 🍎💰


Looks like AirPods win in a landslide! Let's all throw away our inexpensive, never-needs-charging, high-fidelity earbuds, and buy AirPods! 😜

For clarity, I am indeed perfectly aware that the ship has (for the most part) sailed on this debate. Apple, at least, doesn't seem likely to release a new phone ever again with 3.5mm headphone jack technology, when they could sell the folks buying that phone $160 AirPods instead. I stand by my entitlement to my (unpopular) opinion on this topic regardless. 😁

Friday, January 08, 2021

Configuring git to prevent commits of temporary/debug code

Developers, have you ever embarrassingly pushed a commit that inadvertently included temporary debug log/print statements, or other code that you intended to remove before committing? I have!

I wondered if it was possible to add some keyword to a code file -- for example, DONOTCOMMIT -- which, if present, would cause git to automatically reject the commit. This could be added as a comment alongside any temporary debug code, to make it impossible to forget to remove that code before committing.

It turns out that it is possible to do this -- and have it apply automatically to all of your local git repositories -- using a git pre-commit hook.

Quick instructions

(The specifics in these instructions apply to Unix-like filesystems, including Mac OS.)

1. If it doesn't already exist, create the directory: ~/.git_templates/hooks/

2. If it doesn't already exist, in that hooks directory, create a text file named: pre-commit (no extension).

3. Add the following content to the pre-commit file:

#!/bin/bash

FOUND=$(git diff-index --cached -U0 HEAD -- | grep DONOTCOMMIT | wc -l)

if [[ $FOUND -gt 0 ]]; then
    echo "pre-commit hook: DONOTCOMMIT detected, commit not allowed"
    echo "(enforced from: ~/.git_templates/hooks/pre-commit)"
    exit 1
fi

4. To apply that pre-commit hook to all git commit operations on your local machine, from the terminal, run:

git config --global core.hooksPath ~/.git_templates/hooks

References

Credit to https://github.com/mudrd8mz for the pre-commit hook code.

Credit to https://stackoverflow.com/users/6309/vonc for the core.hooksPath global git config command.