記得很久以前，我寫註解的方式大概類似這樣：
i++; // i 加 1現在想起來，覺得很好笑。
當時覺得「有寫註解」這件事本身就是好習慣，
至於寫了什麼⋯⋯好像不太重要？
後來進公司，第一次被 senior 在 code review 上留言：
「這個註解跟沒寫一樣。」
很直接，但他說得對。
剛開始寫 C 的時候，我覺得命名這件事不重要。
反正編譯器不在乎變數叫 a 還是 temperature，程式跑起來結果一樣。
直到有一天，我打開三個月前自己寫的程式碼，盯著一個叫 tmp2 的變數看了五分鐘，
完全不知道它是幹嘛的。
那個人是我自己。
從那之後，我開始認真對待命名這件事。這篇是我的一些整理，
不是什麼業界標準，就是我覺得「這樣寫，之後比較不會想罵自己」的習慣。
我以前也是那種看到有人買高股息就想說幾句的人。
配息要課稅、二代健保補充保費、再投入有費用磨損、長期績效輸市值型⋯⋯這些都是客觀數據支持的事情，不是我在亂講。
網路上也有很多人在做這類比較，圖表、回測、試算一大堆，結論幾乎都一樣：市值型長期績效完勝高股息。
但最近我的想法開始有點不一樣了。
不是說高股息突然變得「比較好」，我自己的投資還是以市值型 ETF 為主。只是我開始覺得，用數據去說服所有人都該買市值型，這件事本身可能就是個問題。
說真的，一開始是被逼的。
在寫 GitHub README 的時候，看到別人的專案頁面排版超漂亮，有標題、有表格、有程式碼區塊，我的卻是一坨純文字。
然後去查了一下，才知道那個叫 Markdown。
心想：「這東西看起來很簡單嘛，應該半小時就學完了吧？」
嗯⋯⋯大致上是對的，但要用得順手還是花了一點時間。
在這個科技進步突飛猛進的時代，雖然我們每天用的晶片幾乎都跟台積電有關。但說實話，幾年前我完全沒想到護國神山台積電的股價竟然會從幾百塊漲到破 2000 元。
[聲明]這篇文章不是要給你明牌，純粹是我自己整理的觀察筆記。本文僅為個人學習心得，不構成任何投資建議。投資有風險，請自行判斷。
這不是一般的牛市行情，背後一定有結構性的原因。
第一次看到 1NCE 的廣告時，我的第一反應是：「這不可能是真的吧？」
做 IoT 模組開發這幾年，我對「便宜又大碗」的方案向來保持懷疑。
但研究越深，越發現這個方案有其獨特的定位——它不是騙局，但也不是萬靈丹。
這篇文章不是業配，是我自己試算後的真實分析。
我會把不同使用情境的十年成本全部攤開來算，也會跟台灣本地方案做比較，讓你自己判斷值不值得買。
做嵌入式 Linux 開發那幾年，Memory Leak 大概是我遇過最多次、最難抓、最容易被忽略的問題。
桌面應用程式記憶體洩漏，頂多讓程式跑慢、被 OS 回收。但在嵌入式系統上，RAM 本來就不多，一旦洩漏，輕則效能下降，重則系統直接 OOM crash，而且往往要跑好幾個小時才會發作。
這篇文章整理我這幾年踩過的幾個經典 Memory Leak 案例，每個都有點不一樣，希望能幫你少走一些彎路。
⚠️ 程式碼為簡化示意版本，重點在於呈現問題模式
最近想到幾年前目睹的一場「技術辯論」，至今仍覺得有趣。
A 同事（軟體工程師）：「UART 跟 RS-232 差不多啊，不都是串列通訊嗎？」
B 同事（硬體工程師）：「什麼差不多？這兩個明明就差很多，是完全不一樣的東西！」
當時我聽到的反應是：「這不是差不多的東西嗎？」畢竟在我的認知裡：
看起來根本就是同一件事啊？為什麼 B 同事會這麼激動？