Short list of useful Mac utilities

I don't add a lot of customization to my Mac, but these I have found to be very useful:

Shottr for screenshots.

https://shottr.cc/ 

Espanso for text expansion.

https://espanso.org/ 

Pure Paste for clipboard format removal.

https://sindresorhus.com/pure-paste

Doll to show messaging apps' icon and badge in the menu bar. (I turn off all notification sounds and banners.)

https://github.com/xiaogdgenuine/Doll

cd to app Finder toolbar extension that opens the current directory in the Terminal.

https://github.com/jbtule/cdto

The recent discussion Taking command of the Context Menu in macOS on Hacker News has good advice on configuring the Finder's context menu with the ContextMenu, Automator, and other tools.

The Paris Olympics' pictograms

I have to say that this Paris Olympics pictogram for the Giant Mollusks Eating Women event is very well done... Joking aside, the design of the pictograms broke with tradition and the result is objectively useless. The illegibility of the pictograms on the printed material is a spectacular design fail. Linus Boman's critique at Paris 2024 Olympic pictograms - what happened? is great.

Remain in control of your runtime

Several years ago I wrote Remain in control of your search. When you directly provide to your users a mechanism that your application depends on for its runtime then you immediately lose control of your ability to evolve the application. The recent speaker on the Stack Overflow podcast spoke about how ScriptRunner was implemented in Groovy, and it directly provided Groovy as the user's scripting language. When the application's evolution required updating Groovy the developers incurred the burden of ensuring that all the user's Groovy scripts would continue to operate correctly as is. Scripting languages designed for embedding usually provide a sandbox mechanism for limiting access to runtime resources, but few (none?) limit the language itself. It would have been better if ScriptRunner's design used a Groovy-like language that they translated to the runtime language. Having done that they would have been free to update Groovy, incurring only the burden of ensuring the translation continued to work.

Maintenance, evolution, and technical debt are different

I was listening to a recent Stack Overflow podcast on technical debit and was getting progressively annoyed. The cause of the annoyance was that the speaker was lumping all changes that were not feature changes as technical debit. The changes he was speaking about are better characterized as either maintenance, evolution, or technical debt.

Maintenance is bug fixes. The original implementation is deficient and needs to be repaired. This work is only related to the original design and current feature set.

Evolution is change needed due to alterations in the runtime environment. This work is only related to the original design and intended runtime environment. For example, you need to update a library and that results in a need to update the original implementation.

Technical debt comes about when the original design is unable to accommodate a new need. For whatever reason, it is no longer suitable.

Too often "technical debt" is used to mask an organization's lack of timely maintenance and planned evolution. Don't do that.