My Old Snapshots

為何我不打算同步 Twitter 跟 Mastodon 的內容
在對 Mastodon 產生興趣並註冊 Mastodon 後，我有思考過一個問題：我該在 Mastodon 上面 Po 什麼東西？
方案一：把 Twitter 的內容也同步過去。
方案二：某些東西發在 Twitter ，某些則改到 Mastodon 上面發。
方案三：在 Mastodon 上面發布 Twitter 的英文版內容。
方案四：在 Mastodon 上面用英文寫跟 Twitter 完全不同的內容。
難度依序遞增，最後我選擇最難的四。（所以現在在還很少發東西，哈哈）

但為什麼呢？我好像是從自己的觀看經驗回推的：

假設我在複數地方追蹤同一個人，例如臉書、IG、Twitter都追蹤，此時若對方在每個地方都 po 一樣的內容，我一定會先在一個平台上看到，但在第二第三個平台看到時，我可能就會迅速滑過去。而若大家都這樣，次要平台的貼文表現就不會太好。

我感覺長久下來，若次要平台表現不好，就不會花太多力氣經營，自然該平台也會繼續表現不好，惡性循環，最終還是待在原本的地方。

我想要多探索不同平台的社群，因此我想先嘗試不要同步內容。

為何我想為網站加上搜索功能？
在去年七月時，看到 Owen 這篇「给Zola博客增加搜索功能」文章後非常心動，就很想要找機會幫自己的網站也加上類似的功能，不過後來一直遲遲未展開研究。

前幾個禮拜，看到 Pagefind 這個工具，好像可以為靜態網站建立搜尋 index ，又激起了我的興趣。

今天終於認真想來研究一下，結果發現 Pagefind 對目前的我好像還是有點太進階了。我能夠照著它的教學，在我電腦裡的網站 directory 成功生成 index，但我不知道該怎樣把這個流程也套用到 Netlify 上面，不知道該怎麼讓網站在自動 build 的同時也可以透過 Pagefind 產生 index ，所以就暫且先放棄。

這時又回頭看 Owen 那篇文章，發現我還是很想要有站內搜尋的功能，而且看起來或許可以試試看 Owen 在用的 Meilisearch ，不過這部分就過幾天再來研究了。

那麼，為什麼我會想要網站裡有搜尋功能呢？我覺得好像是想讓瀏覽的人有更多機會接觸他想看到的內容，無論是什麼，只要搜尋當下有某個念頭，而我又正好寫過相關的東西，相信那樣的體驗一定會很不錯。

所以為了促成這樣的體驗有機會能真正發生，這幾個月一定要嘗試把搜索功能做出來！（立 flag ）

為何我想嘗試看看 Linear 作為個人專案管理的工具？
今天在 Twitter 上面看到有人推薦 Linear ，我以前也看過有人分享與推薦，但一直沒有去看看他「到底是什麼」。

今天好奇心充足，就點開來瞧瞧，看了第一眼的理解是為了軟體開發團隊打造的協作工具，可以提 issues，進行 sprints，規劃產品的 roadmaps 。

在官網上還有許多功能與特色，但我突然間被打動的是，好像可以拿來作為我的「個人專案管理工具」？

在團隊上，我們使用的是 Clickup 作為團隊的專案協作工具，目前運作起來沒什麼問題。

在個人工作向的任務管理上，我這禮拜開始使用 Todoist ，覺得蠻順暢的，很不錯。

不過一直以來好像沒有花很多力氣在「個人專案管理」上面，無論是學習東西、長期性的累積，常常都是比較隨機性地進行，某個時段對某件事比較有熱情，就會投注大量時間與專注力，但熱情一旦消逝或移轉，也會離開得很快。

不過從 2023 年開始，有點想要更有紀律地執行一些事情，例如寫電子報，例如學習更多東西，例如更投入某些專業的領域。

當我想到這些比較大的「專案」時，就覺得好像需要一些工具來協助我。這時， Linear 出現了，我來用用看吧！

用了一下子，發現還不錯，好像真的有機會成為自己的專案管理工具。

優點：

免費版就有甘特圖、串接 Raycast 後能夠快速加入 issues、有自定義的 workflow 流程
我暫時設定為
- Issues
- Tasks
- Doing
- Blocked
- Done
- Archive
- Abandoned
感覺有機會來同步多線進行幾個不同的事情。

我覺得拿這個工具來進行個人任務管理的好處是，可以「重器輕用」，例如團隊協作需要的 comment 功能，一樣可以拿來自己使用，這就可以讓一個任務被賦予多次的註解紀錄。另外也可以設置任務的好幾個階段，把專案好好拆解成不同任務，並且按部就班地去執行。

而因為他不是任務管理工具，因此沒有諸如比較進階的 defer 推遲、重複任務等功能，但這反而好像蠻適合我的使用場景，因為我本來就不太需要為這些個人研究興趣的東西設定截止日。

換句話說，我在做的事情好像本來就該以「專案」為規模，而非單純的「任務」才對？

為何我想開始使用 Todoist 作為我工作上的任務管理工具？
今天突然有個想法是，想用用看不一樣的任務管理工具來管理工作上的各項任務，例如回信給客戶、準備會議文件、整理某項專案紀錄等等。

從進入目前的工作與職位以來，我的任務管理工具一直有些變化，有一陣子是單純用子彈筆記的形式，每天在文字編輯器列出待辦事項與優先序，然後當天沒做完的事就手動移到下一天，依此類推。

後來還是希望有些比較「任務管理」的功能，於是又移回了老朋友 OmniFocus 上面。

OmniFocus 一直是我信任的夥伴，多平台同步、能夠定義詳細的任務資訊，也能設定 defer 的狀態，讓某些任務在特定時間才會浮現在自己面前，避免過載。

因此我在 OmniFocus 上倒也使用得還算順利。

不過，跨年的這幾天我一直在想，我對筆記軟體那麼有「嘗試慾」，為何從以前到現在幾乎沒用過幾個不同的任務管理工具，而一直獨鍾 OmniFocus 呢？曾在 2 個月前簡單寫了一下相關的想法「為什麼我總是離不開會讓我過載的 OmniFocus？」但現在想想，也沒那麼絕對，於是我剛才就憑著一股衝勁，註冊了 Todoist 並開始使用。

會選擇 Todoist 是因為感覺它蠻有存在感，常常在我使用的不同工具，例如 Spark, Slack, Raycast 等等都有看到可以串接的樣子。因此在稍微研究後，覺得我的使用情境好像免費版也夠用，就註冊了。

結果試用了 20 分鐘發現相當喜歡，只是淺嚐而已就有許多不錯的 UI 體驗，例如 quick capture 功能可以直接用自然語言設定 due day 與指定 project ，另外內建的一些小提示也蠻溫馨的，而成功串起 Slack 與 Raycast 的感覺也非常好，快速用下來的感覺是，我應該有機會把工作上的任務都丟來這邊。

至於 OmniFocus ，假設工作上不再需要了，可能只剩下個人成長上的待辦事項，但隱約覺得它未來應該會被 Heptabase 給取代，因為 Heptabase 只要加上基本的 todo view ，就能夠在給我任務的同時，也給我更多「關於這個任務的產生情境與相關內容」，這是 OmniFocus 線性的介面設計很難達到的效果。

嘗試透過 ChatGPT 改部落格的 CSS 樣式
今天早上本來想設定部落格的 backlinks 功能，這是從 Zola 0.16.0 版本就有的功能，但我這幾個月一直沒空研究。

結果研究了一個早上一直失敗，最後直接放棄，不管是 Rust 還是 Zola 還是我的部落格，我懂的還是太少了啊。

不過研究的過程看側邊欄有點不滿意，就想調整看看，這時想到了 ChatGPT，問了一兩輪後，就真的順利解決了我的小問題，非常開心。

此時又看首頁每篇文章連在一起的呈現方式不太滿意，決定一樣請 ChatGPT 幫我調整看看，這次花比較多時間，但最終也順利完成了，成果是目前看到的這樣，每篇文章會區隔開來，並且也有響應式的自動變換尺寸。

整個過程 run 下來，我覺得真的很神奇，如果在沒有 ChatGPT 前，我大概要花上兩三倍的時間才有機會完成，但現在快上好多，甚至讓我開始想像設定其他進階樣式的可能性，例如分欄顯示、Menu 按鈕等等。（對，我就是這麼麻瓜！）

而這好像是用過幾次 ChatGPT 後最直接的感受：它帶給我更多的可能性與想像。甚至會為了想好好利用它，先再去多學一些基礎知識。

期待接下來的發展。

為何我對 Mastodon 產生興趣了？
我一個月前曾在為何我對 Mastodon 等「推特替代品」暫時沒興趣？這篇裡面提到：

> 這次好像對 Mastodon 提不太起興趣
不過今天的我變了。

因為早上 Twitter 公布一項新的規定是，未來不能在 twitter 上面 po 其他社群平台的連結，例如 Facebook, IG, mastodon 等都名列其中，雖然目前最認真使用的社群平台就是 Twitter，也不太會 po 別的帳號，但 Twitter 現在這樣做，未來有可能會擴及到其他類型的連結。

例如，假設未來 Twitter 主打長文章或電子報的閱讀，可能就會禁掉網站或 substack 的連結。假設未來 Twitter 主打某某新的內容類型，可能就會禁掉該領域的其他競爭對手。雖然 Twitter 這篇公告很快就下架，但信任的摧毀通常只在一瞬間，我不太喜歡 Twitter 這樣的決定，因此看到這個規定後就覺得，是時候該新找地方待了，而最有機會的替代方案就是 Mastodon。

晚上下班後搜尋了一下，之前在 PKM 社群裡面看到不少人都加入 pkm.social 這個伺服器，我覺得在這上面可能最有機會找到同一批我在 Twitter 喜歡追蹤的人，因此也選擇在這邊註冊。現在我在： https://pkm.social/@pj ，歡迎追蹤和交流！

至於在 Mastodon 上面暫時要 po 什麼呢？我在想，或許可以 po 英文版的內容，一直都想要認真練習英文，不如就從這次開始吧！

嘗試使用 Heptabase 新更新的 PDF 卡片功能
在今天更新的 0.233.0 版本裡，可以上傳 PDF 檔案到 Heptabase 裡面成為 PDF 卡片，在 Heptabase 裡面閱讀、從其他卡片連結到這些 PDF 卡片，同時也可以將這些 PDF 卡片放到白板上或者是側邊欄。

稍微測試了一下，覺得導入 PDF 以後閱讀的體驗還不錯，並且可以放在側邊欄，同時開啟別的卡片寫筆記，覺得透過這種方式蠻好整理閱讀筆記以及自己的想法，也很容易把拆解後的卡片放到白板上去組織成自己的想法。

跟其他稍微比較先行的 PKM 工具比較起來，Hepta 的 PDF 功能是剛推出而已，所以還缺乏標註、直接連結與跳轉段落等功能。

但以「拆成卡片」以及「重組卡片」的體驗來說，我覺得 Hepta 具有很大的優勢，因為 PDF 文件通常較長，所以每段標註或筆記的內容可能都會比較零散，此時在傳統線性或樹狀架構的工具裡，需要花較多力氣去建立這些零散註解與想法之間的關聯性，但「卡片」天生就是零散的，而在 Hepta 裡面可以很容易地組織這些零散的卡片。

假如我寫論文時有 Heptabase 就好了 XD

為何我想使用 Proton 的各項產品？
我從好幾年前就聽說過 Proton，一直以來都很有好感，一開始只知道 Proton 是個很厲害的加密電子郵件，後來知道他們有 VPN 服務，不過也一直沒去用。

可能是一方面覺得麻煩（畢竟要改 email 感覺是個超大工程），另一方面也不便宜。

但對 Proton 的好感則是一直持續存在，可能是欣賞他們注重隱私的理念、也覺得這是一間很酷的公司，甚至 UI 視覺方面也很合我的胃口。

所以今年看到 Proton 的黑色星期五優惠後，整個就被燒到，包含了 Proton Mail, Calendar, Drive, VPN 等四個產品的 Proton Unlimited，平均一個月只要 250 台幣左右，完全可以負擔。

其中， Proton Mail 跟 Proton VPN 應該是我會想要認真嘗試看看的產品，而 Drive 目前沒有特別想存的東西，但或許也可以放一些個人的備份資料。 Calendar 則是暫時不知道可以怎麼用，因為目前日曆應該還是離不開 Google 跟其他人（公司同事）的協作。

但至少前兩個都很值得一試，我也決定要認真地跟 Google 說掰掰。

測試以 DEVONthink 作為暫存資訊的 hub
過去在使用 DEVONthink 時的心態，都是把 DEVONthink 當作資訊儲存的終點站，我可以把東西收錄進來，也許未來會用得到，屆時也很好搜尋。

不過後來一直覺得 DEVONthink 偏「重」，無論是介面、啟動速度、同步複雜性等等，都好像少了一些靈敏的速記的感覺。

但今天想到，或許這只是我的盲點，如果我要「輕用」的話，好像也是做得到。尤其是他很方便的 clipping 工具，可以截圖並馬上備註、可以截取文章並備註，好像也蠻適合拿來作為暫存箱的（也有完整的 inbox / reminder / smart group / date view 等 workflows），但感覺就是要確保定期把它清空，避免越累積越多。

測試 15 分鐘後的結果：

不行，處理「圖」這類素材的能力跟現代的「 block 編輯器」差太多了。我擷取圖片以後註解的內容蠻難閱讀，也沒辦法像 capacities 這樣把內容展開，或許可以考慮用用看 capacities 唷！

至於 DEVONthink ，可能還是要放比較正經的內容？或者，真的用不到它的話，就別再執著了？

Metaphor - 類 GPT-3 的新搜尋引擎
這幾天忘了在哪則推文看到有人分享 Metaphor 這個新玩意，看了一下，好像是以類似 GPT-3 以及 Stable Diffusion 的技術運作的「搜尋引擎」，有點像是可以用自然語言搜尋，更精確一點，他希望你輸入的是日常社群或對話中，你推薦或分享給別人的時候會怎麼講話，Metaphor 就會「產生」那樣的連結。
例如：接觸一個新工具時，一般搜尋時可能會搜尋「Heptabase / Heptabase introduction 」，但 Metaphor 可能會希望你輸入「These are the best blog posts about Heptabase: 」。

我實際測試後，發現… 還找不到 Heptabase 的資料 XD ，而以其他生產力工具帶入，得到的答案也似乎不到特別厲害。不過若要找的是比較大眾一點的東西或工具，好像內容就還蠻豐富的。

我在使用的過程中，好像有產生之前在 Logseq 上面測試使用 GPT-3]類似的感受，就是，我好像不知道該拿來測什麼、我不知道怎樣與這些全新的 AI 工具互動。但隱約覺得這好像是接下來幾年很重要的一種能力呢！

最後放一下 Metaphor discord 裡面介紹 Metaphor 是什麼的文字：

> Metaphor is a search engine that predicts the next link, similar to the way that GPT-3 predicts the next word. You search with it by writing a prompt: a phrase that looks like it could end with a link.

> For example, if you prompt it with everyone knows the best scooby doo movie is, it'll predict what link is most likely to come after. In this case, Scooby-Do on Zombie Island, which is objectively the best.

為何我對 Mastodon 等「推特替代品」暫時沒興趣？
這一兩個禮拜由於 Elon Musk 收購 Twitter 後各種大刀闊斧的動作，引發許多人對目前 Twitter 的不滿，或者是擔心 Twitter 會驟然崩塌，因此開始有不少人主動遷離 Twitter 。其中最多人的去處應該是 Mastodon 。

雖然我一向對這類新玩意都蠻好奇也願意嘗試，但這次好像對 Mastodon 提不太起興趣。為什麼呢？我想到可能有幾個原因：

1. Mastodon 去中心化的架構，讓我感覺有點…不安定？或者說，不適應；又或者說，會有選擇障礙？我不知道我該在哪個地方經營、PO 文、與其他人交流。
2. 我喜歡用 Twitter 首先是因為 Twitter 上面有許多我有興趣的人、以及我有興趣的內容和社群，而在上面分享比較屬於次要的使用目的，因此假設替代品尚未形成這樣的量級，能讓我每次打開隨意一滑都能看到許多自己有興趣的討論話題，那麼我好像也不太有興趣到這個替代品上面。
3. 我還是很喜歡 Twitter 的各項功能與設計，以及使用起來的正面體驗，因此我似乎沒有感覺到什麼把我推離 Twitter 的推力。

或許這個狀態未來終究會改變，但我想那應該還要一段時間吧！

為什麼我總是離不開會讓我過載的 OmniFocus？
我從 2018 年開始用 OmniFocus，中間大概經歷過兩三次的大循環，每次循環都從認真設定一波開始、穩定運行一陣子，後來因為任務量過載而系統崩潰，荒廢一陣子只用其他軟體替代，但又忍不住回來重新大掃除，再開始認真設定一波。

這次我又進入一個新循環，正處在大掃除舊任務、重新設定一波的狀態。

為什麼系統崩潰這麼多次，我卻總是仍想好好整理乾淨，再重新開始？

可能是習慣、可能是喜歡他方便的時間設定、或者是 defer 的功能、或者是有序任務的功能，或者是 Perspective 的功能，這些功能好似沒有在其它的工具裡面看到過，所以我始終喜歡 OmniFocus 。

另一方面是，每次我把閃念想法存到 OmniFocus 後，它似乎就真的被我快照下來了，有時間點、有時會有一些 references ，所以即使過了幾個月再看，好像還是很快可以進入這個情境，我喜歡這樣的感覺。

不過為何每次系統都會崩潰呢？

這次重建，我想要好好釐清這個問題，看能否再順利的運作下去，就試試看吧！

一忙起來，什麼生產力工具都沒用
上一篇發文已經是將近 4 個月前的事了。

這段期間，工作極忙，加班甚多，導致下班後、或者週末時，也只想放鬆放空，好像騰不出多餘的腦力再學習新東西、關注新工具，甚至是發表自己的想法。

另一方面， 7 月購入了 Football Manager 2022 這款遊戲，也讓我重溫求學時代的回憶，回到了 FM 系列這個精神時光屋中。

這兩個狀況互相結合起來，讓這幾個月幾乎只有足球遊戲來填補我工作以外的生活。

不過近期總算慢慢把工作時數壓下來了，足球遊戲也有點玩膩了，或許可以再回到七月以前的狀態了。

但這幾個月這樣接近 burn out 的經驗也讓我深刻感覺到，當心神完全被工作佔據、耗盡，真的是很難再用任何方法、流程或工具，讓自己在工作以外的時間持續吸收、持續產出。

期待 11 月開始，能把工時再降下來一些，好好分享這幾個月裡面那些很值得分享的事、待看的文章、待玩的新工具。

嘗試把 The Archive 當成 Heptabase 的草稿夾
我買 The Archive 好久了，但一直沒有認真用它。曾經有一度拿來當成 Obsidian 的 quick capture 剪貼板，但當時並沒有一個很穩固的工作流，變成大量塞入內容，卻沒有去處理。
不過，最近開始用 Heptabase 學習與實踐 Zettelkasten 後，好像慢慢掌握卡片筆記法的流程了。在這個流程中，只要當我有一定的卡片後，在 Heptabase 裡面產生跟組織新的卡片都蠻容易的。

但我發現，如果是「還沒建立卡片集群」的概念或主題，這個過程就會有點卡。因為我好像不想要直接用珍貴的個位數編號來放置我零散、未組織的隨機想法。

可是這就會讓我的想法「塞車」，因為我一天消費的資訊頗多，可能每天累積下來會對至少 5-10 個不同的領域的資訊產生想法，但我的卡片集群還沒建立這麼快，這些想法都會被我在第一關就卡住排除掉。

於是我想到了 The Archive ，他有很快速的輸入工具，也可以區分標題跟內文，並可以依照標題來排序。

對我來說，這好像變成一個「卡片草稿」的暫存區，當我想到零散的想法，我可以快速幫它編上任何編號，但我可以先從這個編號開始往下展開。等我覺得我累積到一定的量，我再一次把這些卡片放到 Heptabase 裡面去正式編號與歸檔整理。

對我來說， The Archive 目前更適合做這件事的原因是，他有「快速輸入」的小視窗，並且可以「透過標題排序」，這兩點都是目前 Heptabase 還沒有的功能，但好像是我實踐卡片筆記法的需求，因此目前就先來嘗試用 The Archive 處理看看吧！

平鋪畫面的卡片軟體
這禮拜都在用 Hepta 製作卡片筆記，在建立樹狀架構上面花了一些時間研究怎麼做比較好。 想起之前不知道在哪邊看到一個專門用樹狀架構處理筆記的軟體，找了一下應該是 Gingko 。
它的特色是提供一個橫向的介面，最左邊是所有卡片的根，往右則是該卡片的子卡片，以此類推。
透過這個介面可以很清楚的知道卡片彼此之間的階層關係，我還沒有去測試使用它，所以不確定在建立連結、或者是不同卡片樹之間該如何互動操作。
但總體來說我蠻喜歡這個 app 的理念，也希望未來 Heptabase 能夠加入這樣的卡片用法，可能是可以建立這種卡片樹，然後就可以手動添加對應的卡片進來。
總之只要 Hepta 保持「以卡片為最小單位的元件」，就有機會疊加出不同的互動方式吧！
最後也分享看到的一個 2001 A Space Odyssaey 範例： https://gingkoapp.com/2001-a-space-odyssey

連結想法的關鍵也許是 Zettelkasten 的編碼系統？
之前我一直沒有完整研讀 Zettelkasten 的介紹，只有東看西看，大概懂一些，大概做一些。這兩天決定來認真學習及實踐，因此晚上開始看 Zettelkasten 的相關介紹。

一看就發現，之前一直還沒做，因為不太知道從何開始的「將我的 Evergreen Notes 互相建立連結」流程，很適合透過 Zettelkasten 的編碼方式來進行。

因為編碼這件事情就是在強迫自己釐清每則筆記之間的關係，甚至應該說，釐清「新筆記」與「卡片盒裡的既有筆記」之間的關係，這樣的關係是基於上下文脈絡的、也是排他獨立的。

雖然會預料到一些未來可能的問題，例如「可否變動卡片的主編號？」「卡片主編號太多以後該怎麼辦？」但好像又覺得這些潛在的「困擾」都沒那麼難克服，只要優點多於缺點，這件事對我來說就很值得去做。

那就開始建立卡片盒吧！編號 1 就是 “1 Zettelkasten” 。

為何我想要看到卡片的變化歷程？
今天在更新某個 workflow 時，又遇到了更新卡片內容的最佳實踐方式是？這篇裡面提過的問題，我不太知道該怎麼更新卡片最好。這時我嘗試詢問自己，為何我那麼在意「卡片的變化歷程」。

答案可能是恐懼「失去」？覺得過去的想法應該要被留住。

再進一步挖掘，這樣的恐懼，可能是某種損失趨避的心理，會希望自己盡量握有許多足以進行思考和決策的籌碼。

那麼，如果重點是「不想要失去」（而非「看到版本差異」），那好像更適合的作法是，把「過去版本」 archive 起來。然後新卡片有個連結能指向過去的版本就好。

漂亮好用的註記工具 Glasp
今天在 Twitter 上看到有人分享 Glasp 這個 highlighter 工具，稍微嘗試一下以後發現蠻喜歡的，喜歡的點包含：
- highlight 的體驗不錯，有四種顏色可以選擇，也可以註記想法。
- 可以快速複製 highlight 的文字內容。
- 個人頁面可以累積自己的 highlight 紀錄，有那種熱力圖，感覺會有額外的動力去累積 highlights。
- 可以看到很多人精選的文章跟 highlight 內容。

跟目前我最常用的 Curius 相比，Curius 有兩個地方更好：
- 到一個網頁就可以看到「追蹤的人的儲存與 highlight 紀錄」，等於我可以隔空發現「原來這個頁面某某人已經讀過了」。
- 在點到任一篇文章後， Curius 在右上角可以顯示「這個頁面我有幾個 highlights 」，這對我來講是判斷一篇文章價值或重要程度的視覺依據。Glasp 則必須到自己的首頁才看得到這個資訊。

但 Glasp 可以用不同顏色是個蠻重要的優勢，我可以用不同顏色去區分不同用途的 highlights ，比方說黃色是標註有感的句子，綠色拿來標註能讓我產生下一步行動的句子，紫色是我有疑問的句子，紅色則是我不認同的句子，透過顏色這樣簡單的分類方式，可以更快記下重要的靈感與想法，未來再回頭查找時也更直覺。
除此之外， Glasp 的複製體驗，還有 Quote 段落到 Twitter 分享的體驗都不錯，感覺蠻值得嘗試的。

嘗試安裝 umami 成功
因為稍早嘗試安裝 Cusdis 但失敗，想說一鼓作氣再來試試另一個之前曾提過的 umami。
這次參考的是 搭建 umami 收集个人网站统计数据 | Reorx’s Forge 這篇文章，架設過程蠻順利的，基本上是完全照著 Reorx 提供的步驟做就成功了，只有幾個地方與原文稍有不同（或需要補充）：
1. 原文寫的 brew install libpg 應該是 brew install libpq 才對（不是 g, 是 q）
2. 原文所說的「完成后，将 libpg 的 bin 路径添加到 PATH 中，在 .zshrc 或 .bashrc 中添加一行:」這段我本來看不太懂，搜尋一下才知道 .zshrc 跟 .bashrc 大概是什麼，後來我直接在 /home 底下建立了這兩個文件，並且添加那串 libpq 的路徑代碼，才順利完成。
3. 我沒有像 Reorx 一樣修改腳本的名稱，避免被 ublock 擋住。（我覺得如果真的被擋住那也沒差。）
4. 最後，我是透過 Netlify 的 Snippet Injection 功能來放置 umami 的代碼，我非常喜歡這個功能，快速好用，相當推薦。
整個過程對不熟悉任何資料庫或部署的我來說，大概花了一個小時完成，完成後所有數據都可以很直觀地透過 umami 看到，現在我對它非常滿意！如果過一個禮拜沒什麼大問題，應該就會把 Google Analytics 的追蹤碼移除了！

嘗試安裝 Cusdis 但失敗
之前曾經有提過想試試看輕量的評論系統 Cusdis，今天突然有股動力實作，就照著 轻量级开源免费博客评论系统解决方案 （Cusdis \+ Railway） · Pseudoyu 這篇的說明開始架設。
第一步註冊 Railway 帳號並部署 Cusdis ，沒問題。
第二步，把 Cusdis 的 embed code 貼到部落格的對應段落，花了一點點時間，還是完成了。
但完成以後，卻只看到那個區塊有個「空白」，卻跑不出 Cusdis 的留言框框。
原先以為是 CSS 的問題，花了好多時間在亂調整一通，都失敗。後來打開瀏覽器的 inspect ，看到有一段錯誤碼是：
Access to script at 'https://cusdis-production-54de.up.railway.app/js/iframe.umd.js' from origin 'https://notes.pinchlime.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
嘗試研究了一下，發現這好像是我看不太懂，也不知道該怎麼解決的 CORS 問題。所以只好先放棄了！
還是先維持目前的 email 評論方式吧！

輕量的評論系統 Cusdis
這兩天從 Twitter 網友 Reorx 那邊看到一個很有興趣的服務是 Cusdis。
- 他看起來是一個非常簡單輕便的網站評論系統，且主打 privacy first。
- 我曾在「為何我不在部落格上面放評論系統？」這篇裡面寫過，我暫時不想在部落格放評論系統的原因之一是，覺得既有的評論系統介面都不好看，而且好像會拖累網站效能。
- 但 Cusdis 看起來有機會成為那個例外，他的介面很單純，可以看他們官網的 blog 頁面如： Hello Cusdis | Cusdis Blog 。
- 整個評論的介面跟 Disqus 比起來也相當乾淨，如下圖：
-
- 我覺得好像是個值得試試看的方案，決定排入 queue 裡面，放在 umami 之後預計會想裝在部落格上面的東西。

嘗試了 iA Writer 6 的 backlinks
前幾天 iA Writer 大改版，加入了 Backlinks 的功能。

我看了 MacStories 的 iA Writer 6 Adds Cross-Document Linking, Metadata, and More - MacStories 這篇介紹後，被勾起了一點點的興趣，嘗試使用了看看。

但發現，目前的 iA Writer backlinks 功能還相當簡陋，還沒有什麼實用性，因為連最基礎的「Linked References」區塊都沒有，這樣充其量只能說是建立了一個快速的單向連結功能而已。

不過這篇文章也有介紹 iA Writer 讓 YAML 區塊的內容可以作為本文的 variables 來使用，覺得這蠻有趣的，例如設定了 “Creation Date” 這個變數後，在本文中就可以用 \[%Creation Date\] 來呼叫這個變數。

整體感覺起來，雖然這個 wiki-links 功能是一次重大的改版，但好像沒有很確定 iA Writer 的開發者們是怎麼看待這個功能，或怎麼期待用戶使用這個功能。這讓我有些小失望，也可能我根本不算是這個 app 主打的用戶吧！

為何我不再用「純」文字編輯器了？
我已經有好長一段時間沒有使用以前很喜歡的那些文字編輯器來寫作，像是 Ulysses、iA Writer、Scrivener 等等。

工作上，在我轉換職位後，比較沒有須要頻繁地寫有架構的長文字（大約 3000 字）。因此我不再使用 Scrivener 或 Ulysses 來分拆段落寫作並組合在一起

在個人知識管理上，我也從文件型的筆記軟體 Obsidian ，轉向了大綱型的 Workflowy 及 Logseq ，現在則是開始在 Heptabase 上進行卡片寫作，因此我也不再需要像以前使用 DEVONthink 時那樣，還要外連 iA Writer 來撰寫 .md 文件的內容。

在向外輸出上，我目前習慣的作法是，先透過 Drafts 寫大致的草稿，寫得差不多後，就直接丟到 VSCode 裡面編輯，好了以後就可以直接透過 github 讓 Netlify 自動部署，這個過程，也不再需要透過 iA Writer 來進行，甚至這些原始檔案，也都直接放在同一個 repo 裡，可以透過 VSCode 統一管理。

對我來說， Scrivener 更像是「傳說中」的小說與學術文件寫作利器，目前我用不到。而 Ulysses 則是很早就被我刷下來，這兩個工具如果不再使用了，好像不會特別惋惜。

只剩下 iA Writer，我真的很喜歡這個編輯器，雖然暫時找不到使用情境，但我仍會保留著他。

為何我更偏好週休三日（而非工作五天但全遠端）
今天志祺在 Twitter 上面問了一個問題：

「假設只能二選一，大家喜歡週休三日，還是工作五天但全遠端？」

我的直覺反應是：當然是週休三日＋全遠端。
但如果真的要選的話，我會傾向週休三日。因為對我來說，遠端已經是現在進行式。
而即使完全不能遠端，我還是更想要週休三日，因為那真的會有「多出一天」的感覺，那一天是完全自由的，是可以盡情揮霍、浪費的。
相較之下週休二日的第一天通常仍在回復體力，而第二天又要準備上班，心情沒辦法那麼自由。

所以結論是，週休三日可以令我感到更自由，因此我更偏好週休三日。

為何 Heptabase 要建立 Journal app？
在 Hepta 裡面，側邊欄的這些「功能」被它們稱做 app ，我的理解是「應用卡片的方式」。而在 Timeline, Tags, Map (Whiteboards), Library 後，Journal 是第五個可以應用卡片的 app。

沒有很認真去查證，但我在 discord 裡面觀察的感覺是， Journal 的用意是讓 Hepta 的使用者們能「更快速無壓的紀錄」。

那原本的 Timeline 有遇到怎樣的問題嗎？坦白說，我覺得也是很快速無壓了，但少了「時間」這個重要的屬性，因此我必須自己去建立對應時間的卡片，來滿足這樣的時間屬性。

但從 Hepta 團隊的角度，這個新功能的意義會是什麼呢？
- 讓用戶養成儀式感？更黏著？好像可以。
- 透過各種 Daily Journal 的 templates 來讓新手用戶更好上手？好像也是。

這樣想來，Journal 的概念比 “Timeline” 更適合在「累積」為主的系統裡面，畢竟社群的 timeline 是鼓勵大家想到就發，發了就不去管。

Dendron 跟 Zola 哪個好？
透過 Dendron 建立個人 wiki 剛好滿一個月了，這個月我養成了每天至少提一個問題的習慣，而連帶的好處是我的各種思考更多了，也開始把他們都連在一起。

這週開始用更成熟的 Heptabase 來實踐這個習慣，發現也非常順手，甚至因為圖像化的連結，比 Dendron 更勝一籌。這也讓我想起，既然 Dendron 在實踐習慣這一環已經不需要了，那在 Publish 這環是否也有必要維持呢？

曾被淘汰的 Logseq Publish 就先暫且不論，我想比較的是拿來寫部落格的 Zola 。

Zola 的優點是，部署極快，網站跑起來也極快，而且隨著我四月那波認真玩的經驗，我對於自己的整個 zola site 裡面的各項程式碼有一定的了解程度，這樣的了解一方面是了解「Zola 可以辦到什麼」，另一方面則是了解「我還無法透過 Zola 辦到什麼」。

我無法辦到的是像 Dendron 那樣內建的階層架構以及資料夾的呈現方式（但可以學習命名方式），我也無法辦到 Dendron 方便地建立雙向連結。（但若只是把 Hepta 裡整理好的資訊更新上去，則有機會手動辦到。

所以看起來，Hepta 補足了 Zola 這種單純的 SSG 在管理知識系統上的功能缺陷，那這樣看起來就更有使用 Zola 的理由了。

為何我想把工作記錄由 Logseq 移到 Dendron？
今天動起了這個念頭。也不知從何而來的，感覺好像是發現，我雖然工作上很倚賴 Logseq ，但拆解實際的使用情境後，真正會用到的只有快速的雙向連結（關聯性連結）以及迅速的大綱紀錄體驗。

但缺點也是有的， Logseq 缺乏文件夾的架構，讓我在資料多了以後，必須更仰賴雙向連結，而無法 top-down 式的查找資料。

另外，Logseq 的編輯體驗說不上太好，每次都抓不準有序列表跟無序列表的切換跟 indent / outdent 。

再者，我在工作上的路徑是「Logseq → Slack & Email」，但 Logseq 複製出來的效果也都不是特別好，常常需要重新排版一下。

這時就想到了目前在 Wiki 上用的蠻喜歡的 Dendron ，覺得好像可以擔負這個責任。

首先， Dendron 也有 daily notes ，可以讓我每天記錄事情。
再者， Dendron 也可以透過雙向連結跟 note references 去建立基本的反向視角。比方說，我在 2022.06.02 下面紀錄 \[[ 專案 1 ]] 時，記完就可以把整段 reference 到專案 1 的主頁面。長久來說，這樣好像更能有組織地累積內容。
那就先來試試看吧！

為何「為什麼」比其他類型的問題都還難產生？
每天在想問題時都會感覺到，Why 類型的問題比 What 跟 How 還要難產生。What 跟 How 可以透過很純然的好奇心來支撐，例如，我現在桌子上擺著一個杯子，我可以問這個杯子由什麼組成（what）、這個杯子是怎麼做的（how）、我該怎麼使用這個杯子（how），這個杯子跟其他杯子有什麼不一樣？（what），但我好像問不太出一個關於杯子的「why」。

或者說，我知道即使我問了，我好像也回答不出來，或者對我來講好像沒什麼特別驚喜感，所以也不想問。例如，為何這個杯子上面要印 Beatles 的圖案？因為他是在利物浦賣的，觀光客喜歡呀。

如果要回答今天這個問題，我的答案好像會是，因為 why 是複合的元素組成的，有著他的情境，例如「我為何喜歡某軟體」，是由「我」跟「某軟體」組合而成。「為何某某狀況在台灣時常發生」，是在討論「某狀況」與「台灣」的關係。

這樣複合的狀況需要花更多力氣去觀察，也更難回答一些，而這個「更難回答」因為可能要花很多力氣，就會讓我潛意識傾向尋找「比較好回答」的 why 問題，但並沒有那麼多又好回答，我又感到有興趣的 why 問題，所以就容易卡住了。

為何我喜歡逛 Heptabase 的 discord？
* 這裡的頻道分類架構很好，不會很混亂（除了 feedback 跟 feature-request 有點像），基本上大家可以很容易找到可以討論的地方
* 團隊成員對於問題的回覆很即時，參與感很高
* 團隊成員（尤其是 Alan）會提到很多決策的理由，這點可以讓人快速同理他的想法，進而認同。
* 社群的討論品質很高，常有人分享有趣的問題。
* 這些上述元素綜合起來是：

* 這裡有我欣賞的人，會發表我認同與有收穫的觀點，並能接觸到我有興趣的主題與討論。

短想法的終點都是 Evergreen notes
剛剛在整理自己該怎麼使用 Heptabase 時發現，我的目標好像是要盡量累積 evergreen notes，因此無論是 why, how, what, 或者是 random thoughts ，好像都應該盡量提取可以成為 evergreen notes 的片段。

也因此，整個工作流的目標可以設定為，如何讓自己更有效率的提取可以成為 evergreen notes 的想法？

另外，從另一個角度來想， daily WHW 則是我的內容引擎，能持續讓我產出 evergreen notes。

怎樣程度的抱怨最剛好？
大部分的人可能都不喜歡聽到別人抱怨。
大部分的人可能都喜歡向別人抱怨。

除了發洩情緒之外，抱怨的好處可能是拉近與接收抱怨者的距離（對同樣的事不滿）。
但倘若對方對於這件事沒有不滿，或者無法同理自己的感受，抱怨可能就會讓對方產生負面的印象。

所以，抱怨的對象必須限定在「理解自己不滿」、「有類似不滿」或「可能被自己說服產生類似不滿」的人身上。

好的抱怨可能可以迅速拉近雙方距離。
但壞的抱怨就會讓大家迅速遠離自己。（不止對方，因為對方可能會把這件事傳出去）

為何我要把 Dendron 的 notes 搬回 Heptabase？
前天晚上 Heptabase 更新到 0.143.0 版本，上線了 nested whiteboards （層級化白板、巢狀白板）的功能，這是我期待已久的重要功能，試用了一下發現體驗很好，決定把累積了快一個月的 Dendron notes 全部搬回 Heptabase。

但這樣搬移的意思並不是未來就不再用 Dendron 了，而是讓流程調整一下，把原本「直接在 Dendron 撰寫 daily notes，並發布到網路上」的程序，調整成為「在 Heptabase 撰寫 daily notes ，貼到 Dendron 上，再發布到網路上」。

為何要這麼做？因為 Heptabase 的功能更全面，他能滿足 Dendron 沒有的兩個功能：
1. 把 notes 一次攤開，一起檢視
2. 實踐在 5/17 提過的 The Compass of Zettelkasten thinking 的功能（還需要調整成我自己的版本）

這兩個功能都是基於 Heptabase 的空間屬性，覺得更有助於建立連結以及進行聯想，因此在有層級化白板後，就決定這樣做了。

但 Dendron 仍然在建立公開 wiki site 這件事情上扮演重要的角色，而且從 Dendron 上面學到的 hierarchy 命名概念非常實用，讓我現在在 Heptabase 裡面也透過同樣的方式來命名以及識別。

一個多月沒用 Hepta ，中間有 Dendron 這樣的練習與累積真是太好了，感覺離自己的 workflow 完整體又更近了一步。

我的純文字沒那麼純
我的純文字沒那麼純，還有用到 Logseq 這樣的大綱渲染架構，也有 Drafts 這種文字內容還是存在軟體裡的狀況。

但我覺得「沒那麼純」或許才是最好的方案，因為太純文字的話，就少了連接的便利性、少了排版架構的可視性、或者是拖曳的可互動性。

或許不該一味地推崇純文字，只要剛剛好，就好。

最好的選擇應該是那些以純文字為基底，卻能夠產生出不同變化，而且也能讓用戶保有資料、方便 export 的軟體。從這角度來看待純文字可能會更有意義一些。

為何有時候問不出為什麼？
最近發現，有時候會想不到當天該問什麼。可能的原因是：
- 更新速度太頻繁，目前每天都要問一個，可能太密集。
- 我的 input 太少，在既有 routine 工作裡面沒有發現太多「為什麼」（有的則是涉及到個人或特定的事，無法公開）

可能的作法：
- 更有意識地收集各種 why （目前已有在做，效果還不錯。
- 把更新頻率降低，目標改成「每天至少 PO 一則 Why, What 或 How」

我覺得好像可以兩個做法並進看看！畢竟重點是無壓的輸出，如果發現某種壓力太過，可以嘗試適度降壓！

為什麼我要在部落格上放電子報的備份？
從 4 月底開始，我在部落格上面開設了電子報的頁面，把每一期電子報的全文都放上。

為什麼我會想這樣做？最直接的原因是，SEO。

在這樣做之前，我曾嘗試在 Google 搜尋了我的 Substack 電子報內容，但發現幾乎搜不到，即使直接搜尋標題，還是看不到。

即使 Substack 上面每篇電子報都有獨立的網址，但看起來 SEO 沒做很好，所以我想要有更好的表現。

尤其我在電子報裡會分享一些特定 app 的 workflow ，或者是針對某些議題分享想法，如果這些內容都不容易被搜尋到，感覺有些可惜，所以我想要把文字放到網站上。

但也因為目的就這麼單純（希望多一個搜尋引擎的曝光機會），所以我在分享電子報到 Twitter 等平台時，還是會放上 Substack 的連結，因為這樣可以讓大家更容易訂閱。

下一個可以問的問題是，為何我要在意網站（或自己內容）的 SEO？

Moby Dick Workout
這是推友推薦，在 Bike 的作者 Jesse Grosjean 的網站上看到的文章
，或者說一種測試方法，覺得非常有趣。

Moby Dick 是白鯨記，而 Grossjean 這個測試方法，就是拿白鯨記的完整文字檔，來測試筆記軟體或文字編輯器的效能。

具體的測試方法是，透過想測試的軟體打開或 import Moby Dick 檔案（有分 opml 格式以及 .md 格式），然後測試看看下列動作：
1. 打開它，快嗎？
2. 滾動到底部，調整視窗大小，快嗎？
3. 再滾動到中段，調整視窗大小，快嗎？
4. 全選文字，剪下、貼上、undo、redo，你的 app 還行嗎？
5. 在文章中段編輯一些內容，是否會 lag？是否會卡頓？
6. 重複測試步驟 2-5 直到你滿意為止，然後打開 macOS 的 Activity Monitor，看看記憶體的用量你是否滿意。

我嘗試用這個方法測試了 Logseq ，發現，效能不太好。

而 Bike 的效能則是非常好，運行這一些動作都很滑順流暢。這也是最後決定實際用用看 Bike 的原因之一，速度快，真的是很大的優點。

為何我不在部落格上面放評論系統？
過往透過 Wordpress 維持個人網站時，有內建的評論系統，可以選擇要不要打開讓讀者留言。

但自從轉換到 Zola 後，我不再放置評論系統了，為什麼？

第一個原因是，我覺得評論系統的介面都不好看，會破壞整體的閱讀感受。
第二個原因是，評論系統好像會讓網站的 Pagespeed 評分變差，既然目前網站有很好的評分，我不想要變差。
第三個原因是，對於部落格這樣比較成熟、完整的文字，我好像也同樣期待完整一點的討論與回饋，而這些完全可以透過 email 來進行。

這些原因讓我暫時不想去找評論系統的解決方案，但也許未來會改變心意也說不定吧。

What 是通往 Why 的捷徑嗎？
因為每天給自己設定的最小目標是「一定要想一個 Why」，但有時還是會卡關。卡住的點是想不到今天想問什麼。

但我發現好像有種很容易問 why 的方式是，基於 "what" 的問題去問 why 。

例如，這幾天可能在研究 Bike, umami, Dendron 等產品，除了可以問這些東西是什麼以外，也可以問，為何要發明這個東西？他想解決的是什麼問題？

不過這類的 Why 不是在問我自己，而是在問這些產品的創造人以及團隊。所以如果可以，或許我該先自己猜測看看，這樣也可以訓練自己的觀察力吧？

為何值得投注時間維護個人 wiki ？
時間是珍稀的資源，為何要花在建立以及維護個人 wiki 上？
我覺得這件事會有複利的效果，當自己的想法持續累積，並且有良好的機制來引用、重組、展示時，對內能提高自己的思考品質以及提問的能力，對外也有機會累積一個持續學習與分享的好形象。

為什麼我想嘗試 umami ？
umami 是一個主打簡單兼顧隱私的數據分析工具。
我是從 Open Source Alternatives to Proprietary Software 這個網站發現他的，當時因為看到 Brian Lovin 在他的網站上提到他在分析數據方面從 Google Analytics 搬家到 Fathom 這個工具上，因此開始研究他為何要從 GA 搬走？ Fathom 是什麼？

但當時看到 Fathom 並沒有免費版的方案，最便宜的方案要 14 美金一個月，我覺得太貴，所以放棄。

因此看到 umami 標榜不用付費，就產生了一些興趣。

仔細看了官網後也發現，他的介面很簡單，但該有的好像都有，例如：
- 流量都在哪個頁面
- 從哪個地方來？
- 瀏覽器以及作業系統
- 平均停留的時間
- 觀看次數

我好像也只需要知道這些就夠了。

因此如果要回答這個 why ，答案應該是： Google Analytics 的功能太多太複雜，使用起來很臃腫，我用不到這麼多功能，因此想嘗試別的方案，而 umami 不僅看起來簡單夠用，也夠便宜，所以我想嘗試看看。

至於隱私也是一個考量，如果可以，我只想知道大家在我的內容上的瀏覽時間以及次數，這對我來講是判斷哪些內容對大家有價值的方式之一。

嘗試開始使用 Bike
今天開始嘗試使用前天提到的大綱軟體 Bike。

我的用法是，把它當成我的簡單 MOC ，或者說 wiki 的快速目錄，把曾在 wiki 這邊寫過 daily journal 都記下來，但不再透過日期排序，而是手動將他們分類。

最直接的體驗是： Bike 真的是快，用起來很絲滑順暢，有很好的體驗。

另一個優點是，把一串文字直接暴力貼上時， Bike 的分段效果很好，能夠直接依照斷行區分，接著只要稍微縮排一下就好。這剛好很符合我「剪貼過去再微調」的需求。

相較之下，若同樣把文字貼在 Workflowy ，就會全部擠在一起。（Logseq 的表現也是好的）

不過 Bike 目前的功能太少，而且不支援 markdown 真的是有點可惜。

就再用用看吧！

為何呼籲別人理性很危險？
通常被呼籲的人，只會有「被指責不理性」的感覺，即使事實確實如此，但這種「被指責感」很容易引起不悅。
這可能是因為理性的對面可能是「感性」，也可能是「不理性」，這就容易造成潛在被呼籲對象自行帶入「不理性」這個對立面。
而「理性」這個詞也過於模糊，很難作為明確的行動指引。 相較之下，呼籲別人「要禮貌」，大家就比較好想像「禮貌」是怎樣，也可以去想像「自己是否不禮貌、是否粗魯」。（當然，這樣的呼籲還是會有點危險）
該怎麼做可能更好？
若是公眾人物對大眾，那可以提出更明確的行動指引來呼籲大家。 若是對身邊的人呼籲，那可能也不該呼籲，而是應該直面對方令自己不滿的地方去提出建議與改善方法吧。

為何我對 Bike 這個 app 有興趣？
我對 Bike 有興趣的原因有幾個：
他主打非常迅速且不佔用資源的 native mac app。
主打所有文件都是 local 的。
文件寫得蠻完整的 Bike Guide

這好像可以歸納出幾個我喜歡的元素
迅速
純文字
文件完整
native app

Bionic Reading
今天看到有人分享了 Bionic Reading 這個技術，或者說標準？
我不太確定該怎麼命名它，因為他不是一個特定的軟體，在首頁的 CTA 是「Bionic Reading API」。
他的概念可以看這張圖中的文字，左邊是沒有使用的，右邊是有使用的。
簡單來說，就是創造的人們認為人的大腦讀得比眼睛還快，而只要給大腦一小部分的資訊，就會自動補完，所以這能讓人讀得更快，甚至更好地理解讀的內容。
我幾個月、或一兩年前曾經在某個 RSS 閱讀器看過這個功能，當時覺得很酷，但沒特別有感。
今天再看了一次後，發現好像真的比較可以專注閱讀英文文字。
於是就看到 Bionic Reading 官網上有列出支援的 app，目前有
- Reeder 5
- Fiery Feeds
- Lire
看到以後我跑去打開手機上的 Reeder app ，果然是在這邊體驗的。
接下來嘗試看看把 RSS 的閱讀轉到 Reeder 上面好了！

為何我都寄出電子報了還是會貼公開連結到 Twitter 上？
直覺的優點：
1. 以貼文的形式貼在 Twitter 上有助於觸及更多未訂閱的潛在讀者。
- 這可能是因為，現在一般人比較不會轉信，比較會轉推。
2. 貼在 Twitter 上也有助於推送給既有的讀者。
- 很多人未必會看完每則電子報，以我的經驗來說，訂閱的大多數電子報都沒時間看。

潛在的缺點：
1. Twitter 看過的人，可能就不會再從信箱看了，這可能會對整體開信率有負面影響。
- 但這個缺點，我覺得無關緊要，因為有人願意點擊連結閱讀，也會在 Twitter 或 Substack 的某個範圍有正面影響。

小結論：優點大於缺點，且每次貼出連結後的一天內都能收到新的讀者，代表此方法應該算有效，可以繼續實施。

為何我要寫電子報？
之前剛開始寫的時候，曾經有規劃是把「中篇幅的短文、論述、文章摘要分享」放在電子報。
也曾在 Pin 起來的 Roadmap 2022 中簡單描述過：

「電子報是一直以來都想嘗試的發送形式，對我來說，非即時的、一對一的電子信件這種東西，一直都很吸引人。」

但今天若問自己這個問題，我的回答比較會像是：
1. 電子報的固定形式有助於產出內容
2. 持續寫電子報有助於經營個人品牌
3. 電子報的優點是可以直達收信者的信箱

Enrich My List
今天看到 Jakob Greenfeld 分享 應該是他創造的一個服務 Enrich my List ，覺得很有趣。
該服務的概念很簡單，你給他一份 email list ，他給你「這些人」的名字、Twitter 及 LinkedIn 帳號，以及對方的追蹤者數量等，讓使用者更了解自己既有的 email list 。
這服務的收費方式是「按 List 大小」計費，目前的計費標準如下圖：

我覺得這服務有趣的點在於，他解決了某種懶惰又真實存在的需求： 「我想知道誰追蹤我、誰訂閱我，但我沒力氣一個一個去肉搜」
那就交給機器人吧，另外，為這需求付點費也很合理吧。

或許我不需要「Literature notes？」
我再一次覺得，我自己可能不需要「Literature notes」這種類型的筆記。

一部分是因為，我過去就曾對 Literature notes 的產製流程感到困擾，即使用最快的速度整理，每篇文章可能也要 20-30 分鐘來整理 notes ，但這樣做的意義卻似乎沒很大，不如直接寫成我的想法，然後適度引用就好。

另一部分是，今天花了不少時間在看 Andy Matuschak 的 notes，覺得更理解他提出的 Evergreen notes 概念，覺得這整套好像是更適合我的作法，而在這裡面似乎不太需要「Literature notes」這個分類。

為何我開始更喜歡用 Dendron 而非 Logseq 紀錄 daily notes？
我覺得可能的原因有：
1. 既然打定主意要讓自己的知識庫公開，那直接透過 Dendron 紀錄更直接一些。
2. 目前為止 Dendron 的層級化體系好像讓我對自己紀錄的內容更有掌握一些。
3. 我已經足夠熟悉各種不同工具以及方法論，所以慢慢地可以透過不同工具都能達到類似的效果，此時關鍵的差別就在於我更喜歡 Dendron 的 publish 方式，所以這個優點決定了一切。

為何老師不喜歡學生引用 wiki 上的資料？
今天在看「個人 wiki」相關的資料，看著看著就看到 wiki 的介紹，也聯想了不少事情。
發現「wiki」這東西雖然隨著我求學的過程成長發展，但我以前從來沒有「真正」去了解這是什麼。
所以高中＆大學時，即使老師說「wiki上的資料很多錯誤」，我也沒有去探究「為什麼」。
但印象中，也沒有老師嘗試跟我們說明「為什麼 wiki 上的資料很多錯誤」，只有叫我們不准抄 wiki 。
我後來覺得，這樣的指示也不是最好的，最好的做法是，明確讓學生知道 Wiki 上面的資料是怎麼來的，並且教學生該如何判斷上面的資料是否可信。
「不能抄 wiki 」是合理的要求，但更好的做法是說明「該怎麼透過好找的 wiki ，去找到更多更有價值的資料，進而寫出自己的東西」。

為何信任難以創造？
先姑且不論太抽象層面的概念，單純就日常生活的情境來回答這問題好了。

對我來說，信任好像就像是展開自己的柔軟面（但也脆弱）給對方，這樣做的優點是有機會也獲得對方的柔軟，但缺點是可能被對方傷害，所以信任只能逐步建構與累積，也會視對方的具體表現（例如是拿刀相向還是展現友好）來決定是否展現自己的柔軟。

因此，信任「通常」無法一蹴可幾。但換個角度想，能夠快速建構信任的人或事物（或 "protocol" ）就很有價值了吧。

使用生產力工具有讓我更有效率嗎？
這好像是個很常見到的質疑：

「使用那麼多生產力工具，真的比較有生產力嗎？」

我的回答是：有的。

甚至即使是「亂嘗試各種生產力工具」，對我來講都是很有生產力的事，因為透過這過程也可以釐清自己喜歡什麼、對什麼感到興奮、對什麼感到好奇，以及對哪些工具無感。這些想法累積起來就有機會提煉出一些更有價值的想法。

我會對怎樣的人提問？為什麼？
對知道我不知道的事情的人，例如在嘗試新工具或學習新技術時，詢問有分享過經驗或想法的人，因為我覺得向他們學習更有效率。（但這些比較屬於 How 的問題）

針對我在意的事情向人提問，通常會在這件事的發展與我預期不符時發生（超出預期時會問怎麼辦到的，低於預期時會問「為什麼會這樣」）

但問「為什麼會這樣」容易有責罵感，可能需要換個方式問，例如：「是發生了什麼意料之外的狀況嗎？」

為何技術文件很容易過時？
今天在透過 Dendron 的官方文件學習 publish 功能時，走了不少彎路，一直卡在一個 bug 裡面，後來我幾乎是逐步驟測試，才發現出現問題的步驟是什麼。
想起之前在學習透過 Zola 部署網站時，也發現文件上的內容看起來已經有點過時了。
我還沒有維護過面向客戶的技術文件，所以不確定這件事的**本質原因**可能會是什麼。表層的原因可能是資源不足，或者覺得這件事沒那麼重要，但流程上是否有改善的空間？現行的工具有沒有適合拿來處理這個問題的？
希望以後的自己有能力回答這些問題。

建構我的 wiki site
上週透過 Logseq 內建的 export 功能，很順利地把頁面整個輸出成靜態頁面，並且上傳到自己的網域裡面，開始建立自己的小小 wiki page。

不過這個方式以目前少少的測試頁面內容量來說，打開就需要一點載入時間，而且也無法自訂各種內容（包含 logo 、metadata 等），有點不滿意。

所以就開始思考＆研究其他的解決方案，此時看到一篇文章提到可以把 Tiddlywiki 輸出成靜態頁面，就嘗試研究了一下，但研究一晚下來覺得， Tiddlywiki 學習曲線感覺頗高，而且整體編輯或維護的流程有點...繁瑣（可能是我還不太會用），好像也沒有很符合需求。

還有一個選項是透過 Logseq 的 Schrödinger 插件，把 Logseq 頁面直接轉成 Hugo 的靜態頁面。

但這個方案感覺起來，反而是以「文章」為主了，不像 Logseq 內建的 Export 功能，在輸出後，還是可以在頁面上面操作它的大綱型介面以及雙向連結。

感覺一時之間好像找不太到好的解決方案，需求：
1. 每月低於 $5 的費用（ Obsidian Publish 好貴）
2. 能在本機迅速編輯，並且迅速匯出成靜態網頁
3. 要有雙向連結功能（被連的頁面能看到誰連到它）
4. 輸出的網頁有辦法自訂一些 metadata

結論：我再研究（慢慢等）看看好惹

為何想建立一個自己的 wiki site？
1. 實踐 Learn in public 的概念
2. 讓自己有更多動力去吸收知識（input）
3. 給自己每天固定寫 notes 的理由

Why ask why?
今天看了發現問題思考法後，決定開始嘗試每天問自己一個 Why，並且嘗試回答看看。藉此找出更多上位的概念。第一天的 Why 就來問 「Why ask why?」

書中提到：
- Why 所表示的並非「單發性事象」，而是事象間的關係性。總之，Why 是用來畫關係性這一條線的疑問詞。只有透過這樣的疑問，才能夠探究關係性的疑惑，進而察覺更進一步的未知。
- 透過重複問為什麼，就能逼近本質，重新定義更好的問題，進而發現真正應該解決的新問題。
- 透過問 Why 可以思考「目的」而非「手段」，藉此改變擂台、改變遊戲規則，這樣就能去思考「不必執行原本的手段也可以達到目的」的做法。

所以持續問「Why」的原因是，探究某件表象事物背後真正的本質是什麼，藉此定義出更好的問題、更應該被解決的問題。以 哈佛這樣教談判力 的概念來說，就是要關注利益而非立場，才有機會找到雙贏的解決方案。

如何透過自己不同意的論點發展想法？
今天看了 David Perell 的 Tweet，他寫說，練習把那些你不同意的論點寫下來，然後嘗試著站在他們的角度去讓論點變得更好，這樣的練習是很好的事。
這個想法看起來是來自 Tyler Cowen 的文，裡面有一句提到 "Much of my writing time is devoted to laying out points of view which are not my own."
我想到以前我很喜歡的一個老師曾說過，他在思考一個論點時，都會思考反對者可能會怎麼想，接著他再想，可以怎麼破解對方的論點，接著又再想，對方可能會怎麼反擊，這樣想個幾輪下來，自己的論點就會越來越強壯了。

關於 Eugene Wei 寫的一小段話
看了 Eugene Wei 網站的 My archives ，這已經是 2012 年的文了，寫著他搬遷網站後，有些舊文沒有空整理，就都放在這個頁面。裡面有一段話很喜歡：

"Going back through my old posts is often embarrassing, like hearing a recording of my own voice or seeing a photo of how I used to dress or comb my hair. But mostly it's like reading letters from past versions of myself. It amuses me."

我也常常因為看到過去寫的東西而覺得有點尷尬，但又會覺得，那就是曾經的我，也是為了變成現在的我而必經的我。

Mess with DNS
今天發現 mess with dns 這個網站，覺得很有趣，隨機分配給使用者一個 domain ，然後使用者就可以照著旁邊的指示去增加 A record 與 CNAME record ，進而了解這些設定是怎麼運作的。
也喜歡它簡單的介面設計，整個體驗很流暢。因此看了一下 about ，發現還有 wizard zines 這個網站，好像是透過漫畫介紹這些複雜的網路＆程式相關概念。不過我還是更喜歡單純的文字內容。