PipperL
日本跑步路線 – 橫濱港未來21
這一篇是2025/7 去日本旅遊時旅跑的路線分享，
這次跑了三條路線：
- 富士山下 東富士，在靜岡縣的小山町，沿著富士美華resort 附近繞一圈，大概5K 左右。除了我以外，沒有碰到任何其他的人。
- 橫濱港未來21 (Minatomirai) ，沿著港區繞一圈，距離大概 6K。早上很多跑步的人，但以休閒跑步為主。
- 千葉港 (Chiba minato) ：在千葉港站附近沿著港區跑，距離大約6K。會遇見不少認真的跑者和釣客。
本篇分享的是在橫濱港 未來21 區域的跑步體驗。
日本跑步路線 – 富士山下 東富士
趁著去關東地區走走，也抽空用旅跑的方式認識日本。
日本的夏天，天亮的很早，早上4:05左右天邊就魚肚白，4:35左右天就亮了。要早起跑步的話，晚上得要早點睡、或是犧牲些睡眠時間，然後白天再抓時間補個眠…
今年(2025) 七月份跟台灣一樣炎熱，沒事還是早點在日出左右出門，跑完早早回旅館盥洗、把跑衣洗好、用浴巾壓乾，然後掛起晾乾(或者收進行李等移動到下一間旅館再取出晾乾)。考量到早上6:30之後要配合起床、整理行李、吃早餐等等的行程，跑個5~10K 是沒什麼問題的。
這次跑了三條路線：
- 富士山下 東富士 (Higashi-Fuji)，在靜岡縣的小山町，沿著富士美華resort 附近繞一圈，大概5K 左右。除了我以外，沒有碰到任何其他的人。
- 橫濱港未來21 (Minatomirai) ，沿著港區繞一圈，距離大概 6K。早上很多跑步的人，但以休閒跑步為主。
- 千葉港 (Chiba minato) ：在千葉港站附近沿著港區跑，距離大約6K。會遇見不少認真的跑者和釣客。
這一篇先寫富士山下的跑步體驗，其他兩篇寫好後會再陸續分享出來。
2025Q2 財務盤點
Q2 結束的這個時間點，除了意味著我離職滿一年了，也象徵著「壓力測試期」已經走了一半。
這半年來，試著靠著資產的現金流過活，過程中有焦慮、有意外，也有一些讓人安心的觀察與修正。
這一篇，算是對Q2的生活與財務狀況的回顧。
也是再一次撥開迷霧，更了解自己財務狀態的嘗試。
六月做什麼
六月快結束了，接下來是暑假。
今天在想，六月發生什麼值得記錄的事呢？
除了從Pocket 跳船到 Keep，學了 n8n ，重改了 Colab+ WhisperX 腳本之外，生活裡，印象較深的就是跟兩個孩子一起玩遊戲和課業吧。
又要玩又要顧課業，還真的是 study hard, play hard.
對科技工作講LINE社群的觀察
我應該是在 clubhouse 時期開始收聽科技工作講的，後來隨著這個科技從業者社群的成長和演化，也開始固定聽podcast、偶爾聽每週的youtube 直播 (如果題目有興趣，想現場討論的話)。我也追蹤了臉書粉絲頁，閱讀主理人抹布的觀點和言論、加入了LINE 社群、甚至連 telegram 群組都加入過。
這篇文章是針對 科技工作講 LINE 社群的一些觀察和個人觀點。不一定100% 客觀和全面。
簡單說，我要退群了。
Colab + WhisperX 將音檔轉成逐字稿 (20250619版)
這兩天有需求，再上 colab 用 WhisperX 把音檔轉成逐字稿。發現之前寫好的code 又跑出錯誤訊息了。
解決問題的路上，發現新版已經跑得起來，不用像之前還要移除 Pytorch、安裝特定相容的版本。但版本依賴的狀況還是蠻混亂的。
新的版本還是帶來新的問題：
- whisperx.DiarizationPipeline 指令改成 whisperx.diarize.DiarizationPipeline
- alignment.py 裡有個Index Error，Issue 裡也有人回報，但還在等修復，目前需要自己進去改code。
我整理了一下，再把新的code 放上來，但使用上要小心。再幾個版本後可能又不能用了。
目前日期 (2025/6/19)所安裝的版本為：
whisperx 3.3.4
ctranslate2 4.4.0
pyannote-audio 3.3.2
torch 2.6.0+cu124
torchaudio 2.6.0+cu124
libcudnn8 8.9.7.29-1+cuda12.2
libcudnn8-dev 8.9.7.29-1+cuda12.2
以下是目前的code 跟修改的地方。如果要知道更多 code 的作用，可以回去參考一開始發佈的版本，裡頭有說明。
我的備份SOP (2025版)
數位時代下，個人與家庭資料的安全性與完整性日益重要。我在2018年寫過一版當時的備份SOP。7年後，我更新了目前我所使用的，如何在多裝置、大資料量的家庭環境中，建立一套高效且可靠的備份SOP。如果你的環境比較簡單，可以用下面的簡易版本SOP作備份：
- 異質備份：以大容量外接硬碟作為資料備份與歸檔的主要媒介。
- 將所有日常工作文件、重要家庭照片及影像等「熱資料」定期備份至外接硬碟。
- 對於不再頻繁使用但具長期保存價值的「冷資料」（如已完成專案的原始檔、高解析度照片RAW檔），定期將其歸檔/搬移至大容量外接硬碟，以釋放主力設備空間。
- 異地防護：採用 Backblaze 進行雲端遠端備份。
- 僅依賴本地實體儲存仍不足以抵禦區域性災害（如火災、水患或竊盜）。因此，建議利用如 Backblaze 這類提供個人電腦無限儲存空間的雲端備份服務，作為異地備份解決方案。
- 策略性運用： 對於儲存於外接硬碟中的歸檔資料，可規劃每半年將該外接硬碟連接至主力電腦數日。此舉將使 Backblaze 偵測到並自動將這些歸檔資料納入遠端備份範圍，以極低的邊際成本實現冷資料的異地防護。
如果你對完整版的備份SOP有興趣，想了解我的心路歷程，或是想知道我怎麼處理較複雜的架構，可以繼續看下去。
n8n Workflow: 在Karakeep 打星就分享到 Twitter
上週從Pocket跳船到 Karakeep 之後，由於 IFTTT 不支援 Karakeep，之前 IFTTT 上的「打星就分享到 twitter流程」就沒得用了。
正好也想用 n8n 玩點花樣，於是就到 n8n 上試著寫個 workflow 來做這件事。
個人血淚提醒：
使用 docker compose down 時千萬不要加 “- v” (也就是不要下 docker compose down -v)。
一般來說 -v 會讓人想到 –verbose；但在 docker compose 裡是把已經建好的 volume 移除 (remove)，包含之前所有輸入的資料，workflow，以及設定。我寫到一半要加個功能，想要rebuild container時，粗心大意直接 copy & paste chatGPT 給的指令，然後兩天的心血就…消失了。後面問 chatGPT 他還理直氣壯說我又沒有說要保存 volume 資料… Orz
以下的內容是先請 AI 分析我寫的 workflow，然後我再補充。
這樣產生說明文件的方式真的很快。不過某些我覺得重要的節點(node)還是會被略過。得要手動指定或是手動加入。
workflow 拆成兩個部份：
- Karakeep_webhook_queue.json：接收 Karakeep 更新書籤時所送出的 webhook，稍後由 Karakeep_share 批次處理。
- Karakeep_share.json：把已經打星的書籤分享到 Twitter，並把已經分享過的書籤歸到 “shared” 列表中。
我請AI 從功能、架構與流程、重要節點的設定方式等三個面向進行分析。