Moby Dick Workout

發布於 2022-05-22 | 最後更新時間 2022-05-22 | 分類: What I Found Interesting

這是推友推薦,在 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 的原因之一,速度快,真的是很大的優點。

#Bike   #Logseq   #Testing


為何我不在部落格上面放評論系統?

發布於 2022-05-22 | 最後更新時間 2022-05-22 | 分類: Daily Why

過往透過 Wordpress 維持個人網站時,有內建的評論系統,可以選擇要不要打開讓讀者留言。

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

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

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

#Blog   #Comment System


What 是通往 Why 的捷徑嗎?

發布於 2022-05-21 | 最後更新時間 2022-05-21 | 分類: Random Thoughts

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

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

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

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

#What How Why


為何值得投注時間維護個人 wiki ?

發布於 2022-05-21 | 最後更新時間 2022-05-21 | 分類: Daily Why

時間是珍稀的資源,為何要花在建立以及維護個人 wiki 上?

我覺得這件事會有複利的效果,當自己的想法持續累積,並且有良好的機制來引用、重組、展示時,對內能提高自己的思考品質以及提問的能力,對外也有機會累積一個持續學習與分享的好形象。

#Personal Wiki


嘗試開始使用 Bike

發布於 2022-05-20 | 最後更新時間 2022-05-20 | 分類: What I Tried Today

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

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

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

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

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

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

就再用用看吧!

#Bike


為什麼我想嘗試 umami ?

發布於 2022-05-20 | 最後更新時間 2022-05-20 | 分類: Daily Why

umami 是一個主打簡單兼顧隱私的數據分析工具。

我是從 Open Source Alternatives to Proprietary Software 這個網站發現他的,當時因為看到 Brian Lovin 在他的網站上提到他在分析數據方面從 Google Analytics 搬家到 Fathom 這個工具上,因此開始研究他為何要從 GA 搬走? Fathom 是什麼?

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

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

仔細看了官網後也發現,他的介面很簡單,但該有的好像都有,例如:

  • 流量都在哪個頁面
  • 從哪個地方來?
  • 瀏覽器以及作業系統
  • 平均停留的時間
  • 觀看次數

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

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

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


Backlinks:

#Umami   #Google Analytics


為何呼籲別人理性很危險?

發布於 2022-05-19 | 最後更新時間 2022-05-19 | 分類: Daily Why

通常被呼籲的人,只會有「被指責不理性」的感覺,即使事實確實如此,但這種「被指責感」很容易引起不悅。

這可能是因為理性的對面可能是「感性」,也可能是「不理性」,這就容易造成潛在被呼籲對象自行帶入「不理性」這個對立面。

而「理性」這個詞也過於模糊,很難作為明確的行動指引。 相較之下,呼籲別人「要禮貌」,大家就比較好想像「禮貌」是怎樣,也可以去想像「自己是否不禮貌、是否粗魯」。(當然,這樣的呼籲還是會有點危險)

該怎麼做可能更好?

若是公眾人物對大眾,那可以提出更明確的行動指引來呼籲大家。 若是對身邊的人呼籲,那可能也不該呼籲,而是應該直面對方令自己不滿的地方去提出建議與改善方法吧。

#Rational


Bionic Reading

發布於 2022-05-18 | 最後更新時間 2022-05-18 | 分類: What I Found Interesting

今天看到有人分享了 Bionic Reading 這個技術,或者說標準?

我不太確定該怎麼命名它,因為他不是一個特定的軟體,在首頁的 CTA 是「Bionic Reading API」。

他的概念可以看這張圖中的文字,左邊是沒有使用的,右邊是有使用的。

簡單來說,就是創造的人們認為人的大腦讀得比眼睛還快,而只要給大腦一小部分的資訊,就會自動補完,所以這能讓人讀得更快,甚至更好地理解讀的內容。

我幾個月、或一兩年前曾經在某個 RSS 閱讀器看過這個功能,當時覺得很酷,但沒特別有感。

今天再看了一次後,發現好像真的比較可以專注閱讀英文文字。

於是就看到 Bionic Reading 官網上有列出支援的 app,目前有

  • Reeder 5
  • Fiery Feeds
  • Lire

看到以後我跑去打開手機上的 Reeder app ,果然是在這邊體驗的。

接下來嘗試看看把 RSS 的閱讀轉到 Reeder 上面好了!

#Bionic Reading   #RSS


極簡的大綱編輯器 Bike

發布於 2022-05-18 | 最後更新時間 2022-05-18 | 分類: What I Found Interesting

今天發現了 Bike 這個新 app ,是由Jesse Grosjean 開發的軟體,看了以後我才發現他是 TaskPaper 這個 app 的開發者。

晚上下載來試用看看,確實打字的感覺蠻好,但目前功能還太少,真的是太 Raw 。

另外,價格也有點太貴,目前不成熟的 1.0 版本就要 31 美金。決定關注一下子開發進度,之後再說。

另外可參考這篇介紹: Bike - a Bicycle for Your Outlines - Bicycle For Your Mind

#Bike   #Outliner


為何我對 Bike 這個 app 有興趣?

發布於 2022-05-18 | 最後更新時間 2022-05-18 | 分類: Daily Why

我對 Bike 有興趣的原因有幾個:

  1. 他主打非常迅速且不佔用資源的 native mac app。
  2. 主打所有文件都是 local 的。
  3. 文件寫得蠻完整的 Bike Guide

這好像可以歸納出幾個我喜歡的元素

  1. 迅速
  2. 純文字
  3. 文件完整
  4. native app

#Bike   #Outliner


關於 Evergreen notes 的命名原則

發布於 2022-05-17 | 最後更新時間 2022-05-17 | 分類: Random Thoughts

思考一些關於 Evergreen notes 的命名原則:

是一個明確的「論點」,例如:

  • 電子報可以直達收信者的小天地 (X)
  • 電子報的優點是可以直達收信者的信箱 (O) 前者的描述比較像是一個客觀描述,後者則是主觀的論點。 換句話說,Evergreen notes 的命名必須是主觀的論點

內含價值判斷或比較,例如:

  • 持續運動的好處(X)
  • 持續運動比不運動好(O) 前者的描述比較是資料的收集與彙整,但後者是涉及一個明確的價值主張或高低比較。 (發現這一點似乎跟前一點有點像,暫且不額外開一則筆記。

random thought 就是可以斷在這種地方,不用管整段內容的結構或完整度,讚啦!

#Evergreen Notes   #Naming


The Compass of Zettelkasten Thinking

發布於 2022-05-17 | 最後更新時間 2022-05-17 | 分類: What I Found Interesting

今天在推特上看到有人在分享 LYT conference 的東西,提到 "Compass framework" ,原本以為是以前看過的 LYT kit 裡面的東西,但後來作者之一 Vicky Zhao 分享了該篇文章 給我,是另一位作者 Fei-Ling Tseng 提出來的方法論,她稱這個方法叫做 The Compass of Zettelkasten Thinking。

具體的做法是,將一個 idea X 置於中央。

此時想像他的四個方向,都各有一個問題,這些問題有助於釐清這個 idea 。

  • 北方(north)的問題是: Where does X come from?
    • what are its origin? what group/category does X belong to? what exists an order of magnitude higher? zoom out. what gave birth to X? what causes X
  • 西方(west)的問題是: What is similar to X?
    • what other disciplines could X already exist in? what other disciplines could benefit from X? what are other ways to say/do X?
  • 南方(south)的問題是: Where can X lead to?
    • what does X contribute to? what group/category could X be the headline of? what exists an order of magnitude lower? zoom in. what does X nurture?
  • 東方(east)的問題是: What competes with X?
    • what is the opposite of X? what is X missing? its disadvantage? what could supercharge X?

我看到這個方法時,我直覺就想到,好像可以透過 Heptabase 來做這件事,透過視覺的方向關係可以很快給出東西南北的方向。

但這個方法有提到,每個 idea 產生的各個方向,都可以再產生更多 idea ,以及他們各自的東西南北(通常是東西南),所以感覺可能更適合用 Outliner 來進行。

不過接下來的問題是,我的羅盤四個方向會是哪些問題?


Backlinks:

#Zettelkasten   #Compass


為何我都寄出電子報了還是會貼公開連結到 Twitter 上?

發布於 2022-05-17 | 最後更新時間 2022-05-17 | 分類: Daily Why

直覺的優點:

  1. 以貼文的形式貼在 Twitter 上有助於觸及更多未訂閱的潛在讀者。
    • 這可能是因為,現在一般人比較不會轉信,比較會轉推。
  2. 貼在 Twitter 上也有助於推送給既有的讀者。
    • 很多人未必會看完每則電子報,以我的經驗來說,訂閱的大多數電子報都沒時間看。

潛在的缺點:

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

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

#Newsletters   #Twitter


Enrich My List

發布於 2022-05-16 | 最後更新時間 2022-05-16 | 分類: What I Found Interesting

今天看到 Jakob Greenfeld 分享 應該是他創造的一個服務 Enrich my List ,覺得很有趣。

該服務的概念很簡單,你給他一份 email list ,他給你「這些人」的名字、Twitter 及 LinkedIn 帳號,以及對方的追蹤者數量等,讓使用者更了解自己既有的 email list 。

這服務的收費方式是「按 List 大小」計費,目前的計費標準如下圖:

我覺得這服務有趣的點在於,他解決了某種懶惰又真實存在的需求: 「我想知道誰追蹤我、誰訂閱我,但我沒力氣一個一個去肉搜」

那就交給機器人吧,另外,為這需求付點費也很合理吧。

#Email   #Startup Ideas


為何我要寫電子報?

發布於 2022-05-16 | 最後更新時間 2022-05-16 | 分類: Daily Why

之前剛開始寫的時候,曾經有規劃是把「中篇幅的短文、論述、文章摘要分享」放在電子報。

也曾在Pin 起來的 Roadmap 2022 中簡單描述過:

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

但今天若問自己這個問題,我的回答比較會像是:

  1. 電子報的固定形式有助於產出內容
  2. 持續寫電子報有助於經營個人品牌
  3. 電子報的優點是可以直達收信者的信箱

#Newsletters


或許我不需要「Literature notes?」

發布於 2022-05-15 | 最後更新時間 2022-05-15 | 分類: Random Thoughts

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

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

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

#Literature Notes   #Evergreen Notes


為何我開始更喜歡用 Dendron 而非 Logseq 紀錄 daily notes?

發布於 2022-05-15 | 最後更新時間 2022-05-15 | 分類: Daily Why

我覺得可能的原因有:

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

#Logseq   #Dendron


為何老師不喜歡學生引用 wiki 上的資料?

發布於 2022-05-14 | 最後更新時間 2022-05-14 | 分類: Daily Why

今天在看「個人 wiki」相關的資料,看著看著就看到 wiki 的介紹,也聯想了不少事情。

發現「wiki」這東西雖然隨著我求學的過程成長發展,但我以前從來沒有「真正」去了解這是什麼。

所以高中&大學時,即使老師說「wiki上的資料很多錯誤」,我也沒有去探究「為什麼」。

但印象中,也沒有老師嘗試跟我們說明「為什麼 wiki 上的資料很多錯誤」,只有叫我們不准抄 wiki 。

我後來覺得,這樣的指示也不是最好的,最好的做法是,明確讓學生知道 Wiki 上面的資料是怎麼來的,並且教學生該如何判斷上面的資料是否可信。

「不能抄 wiki 」是合理的要求,但更好的做法是說明「該怎麼透過好找的 wiki ,去找到更多更有價值的資料,進而寫出自己的東西」。

#Wikipedia


為何信任難以創造?

發布於 2022-05-13 | 最後更新時間 2022-05-13 | 分類: Daily Why

先姑且不論太抽象層面的概念,單純就日常生活的情境來回答這問題好了。

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

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

#Trust


每天問一個問題的過程,是很好的對於設定問題意識的練習

發布於 2022-05-12 | 最後更新時間 2022-05-12 | 分類: Random Thoughts

以之前寫論文的經驗來說,問題意識是貫穿整個寫論文過程的重要元素。 以之前寫影片腳本的經驗來說,問題意識是引起觀眾觀看動機、維繫觀看動機的重要元素。

我似乎感覺到每日這樣練習問 why ,雖然有時會卡住,但好像真的有機會慢慢進步。

例如,我自己以前只會嘗試理解「什麼是演算法穩定幣」,但不會特別去問「為何會有演算法穩定幣」,而透過這個簡短的研究跟理解過程(大約花20-30分鐘讀幾篇文章&自己嘗試找答案),似乎好像就知道了一些以前不知道的事。或者也多了未來產生思考連結的契機,例如,未來再有主打演算法穩定幣的專案出現時,我可能就會好奇他們的目標、動機、願景是什麼。

希望未來有機會連回此則 note 。

#Ask   #Problematic