Weekly Issue 第 9 期：Ghost 發布 6.0 版本
Ghost Release 新版了！距離上次大版號更新，已經過了 3 年多，這幾年來，創作者經濟變化得很快，Ghost 也嘗試讓創作者更容易經營自己的內容。
我會等 6.0 發布一陣子，穩定下來後才會更新。很期待他們下一步會是什麼。
🗞️ 熱門新聞
Ghost 6.0
Ghost Release 6.0。
兩個重量級更新：支援 ActivityPub，讓 Ghost 可以 Leverage 社群媒體分發渠道；以及內建 Analytics，支援流量分析。這剛好就是兩個我最想要的功能，Great Work。
常說經營內容的痛點在，不知道如何發佈內容，不知道訪客從哪來。當然這都可以用工具協助，例如設定 GA、或者使用 Postiz 等來經營社群，可是我覺得一個好的平台應該要替創作者處理掉這些事，Ghost 的方向會讓人感覺到他們是真的跟創作者站在一起。
Do Variable Names Matter for AI Code Completion?
一直很好奇變數名稱對 LLM 有沒有影響，看到有人做了實驗，證明：的確有差。
實驗是用自動補全，觀察補全後的成效（用了三個指標）判斷命名影響程度，描述性的命名效果最好，不同的 Naming Style 差異有限，最差的是不知所謂的魔術命名。
簡單講，跟人類體驗一致。
有意義的點是，LLM 某程度上可以成為人類實驗的替代品？這種實驗如果用真人，應該會很貴。再來就是，LLM-as-judge 看起來正逐漸變成標準實踐。
I used NotebookLM to "watch" a show, and honestly, I might do it again
看到有人用 NotebookLM 「看」了后翼棄兵，原本想說又是個用摘要來取代細節的應用吧，但看到這句登時引起興趣：「就像你是那個剛追完劇、正滔滔不絕向我劇透的宅友。 」
我前幾天滔滔不絕跟朋友講《你的顏色》有多讚時，深深覺得自己沒辦法傳達電影的優點，以後不用這麼麻煩了，直接丟個 NotebookLM 的連結給朋友就好。
「那個什麼什麼劇好看嗎？」
「來，這是連結，自己去問。」
GPT-5: Key characteristics, pricing and model card
Simon Willison 對 GPT-5 的評估，推薦閱讀。
我自己注意的段落是這句：「寫作、程式碼和健康是 ChatGPT 最常見的三個使用情境 」實際上這跟我的經驗不太相同，我大多的應用是查詢，但這三個領域有個共同點，就是對有害內容特別敏感。
OpenAI 看起來引入了新的訓練方式（safe-completions）來克服輸出，也許能理解成模型比較不會無腦拒絕使用者請求？如果是 AI 應用開發，也許是加個 LLM as judge 來達到類似效果（不確定）？
Understanding Kiro's Pricing: Specs, Vibes, and Usage Tracking
AWS Kiro 團隊發文說明他們的定價方式。
依照用途不同，對 LLM 的請求分為兩種，vibe request 跟 spec request，前者類似普通的對話，有意思的是後者，依照規格驅動開發的概念來設計，可以生成需求和設計規格。
原則上還是 usage based 的計價，只是更細分？我理解 spec request 可能類似 thinking 的處理，當然實作面一定不同。
這比 token based 更讓我放心一點，用 Claude 要時時盯著用多少 token，認知負擔還是有點明顯。
✨ 科技觀點
Linear sent me down a local-first rabbit hole
這篇談到 Linear 的 Local-First 技術架構。
簡單來說是直接用 IndexedDB 當資料庫，所以資料都能在前端直接處理，不用每次都從後端拿，想當然能帶給使用者流暢的體驗。乍聽下有點異想天開，可是 git 好像也符合 Local-First 的精神，也許有點道理。
看到的第一時間在想，要如何解決資料衝突問題？看文章答案有點意思，是用了 event sourcing 的架構，所以不會修改，只會 append，配上 ts 真的可以解掉沒錯。我猜還有拍定期快照，降低資料處理的壓力。
不得不說 Linear 技術上挺有膽量的，這種東西想想可以，用在 production 我應該不敢。
Live coding sucks
現在應徵工作，很常需要進行 Live Coding 來測試應徵者的能力，有人提出這種面試流程或許有問題。
原因是，人在壓力環境跟在工作環境的表現不同，當有人盯著你看時，可能只有一半的心思會想著如何解決眼前那道演算題。
對我來說，Live Coding 還是能幫助我識別應徵者的思考模式，我通常不希望給對方帶來壓力，但有時真的很難，有次我看到一名應徵者，邊跟我講話邊摸著喉嚨，當時我一直在想該如何降低他的壓力。
我自己也是很容易有壓力的人，我懂那種被盯著看的奇怪感覺。
How To Review Code
這篇討論如何進行程式碼審查，即使工作已經一段時間了，我還是掌握不好這件事。
主要問題是時間，審查程式碼意味著我得理解不是自己實作的邏輯，常常包含應用場景，然後還得跳出來想想是否影響到擴展性，以及是否會影響到專案進度，如果剛好那週還負責其他重要功能開發，留給審查的時間真的不夠。
本質上還是專案管理跟工程管理的問題，特別在新創，真的很有挑戰。
我们都只是在假装着做 Agile
前面對 Agile 誕生史的講解很有參考價值，後面就……隨便啦。
2001 年的雪鳥會議，某個程度上跟網路時代到來密不可分，更多的需求等待開發，更多的機會等待實踐。敏捷宣言具體化了這些期待，就像美國獨立宣言人皆生而平等，直到 1964 年才通過民權法案。
宣言的意思是「我們希望擁有這樣的世界」，它原本就是很長很長的過程。
How I hacked my washing machine
你有試過 Hack 你家的洗衣機嗎？
英國有人 Hack 了宿舍的洗衣機，將它接到 Discord 的通知中，有意思的是過程各種細節，例如洗衣機只有兩個 API，/http-read.json 跟 /http-write.json，我猜底下真的是兩個檔案，而 MCU（應該吧）會輪詢這兩個檔案來操作。
有時候研究半成品比成品有趣，以及，這讓人覺得數位是漸進式地進入生活。
📌 工程實務
Debugging Distroless Containers: When Your Container Has No Shell
你有遇過 k8s 的容器出問題，卻沒有 shell 能用的情況嗎？
剛看到 k8s 有 kubectl debug 工具，能在有問題的容器旁掛上臨時的 side car，藉由共享 namespace，除錯用的容器可以讀取目標容器上的檔案系統。原理講起來很簡單，但我之前沒想過 😆 。
這對 distroless 的應用幫助很大，退一步講，只要你是用 alpine，也能用這方式來補你需要的除錯環境。
From Database to Data Lakehouse — Part 8
以前工作有用過 Columnar Database，但沒仔細研究，看完這篇有打通幾個點。
從場景上，還是最直接的 OLTP vs OLAP 劃分，假設你需要寫入快讀取也快呢？這就是門學問了，還好我沒遇過這種狀況。
Sentry 是個有突發性寫入（線上出 Bug 時）跟常態分析需求的應用，他們底層是用 ClickHouse + Kafka 搭的，跟這篇談到的一些處理方式能互相驗證。