嘗試安裝 umami 成功

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

因為稍早嘗試安裝 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 的追蹤碼移除了!

#Umami   #Google Analytics


嘗試安裝 Cusdis 但失敗

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

之前曾經有提過想試試看輕量的評論系統 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 評論方式吧!


Backlinks:

#Cusdis   #Failed Experiences


嘗試了 iA Writer 6 的 backlinks

發布於 2022-06-17 | 最後更新時間 2022-06-17 | 分類: What I Tried Today
  • 前幾天 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 主打的用戶吧!

#iA Writer   #Backlinks


GPT-3 擅長回答什麼問題?

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

接續昨天的 嘗試使用 Logseq 上面的 GPT-3 plugin

這兩天玩下來,我覺得 GPT-3 擅長:

  • 回答某個名詞的解釋,包含它是什麼、與它相似的有什麼、它含有什麼元素等等
  • 回答如何進行某件事,包含初步的作法以及進階的指南

這兩類問題讓 GPT-3 非常適合拿來作為某個新領域的入門工具,可以快速給出一個初步的認識、給出一些學習的方向以及子領域,接著可以再去問子領域的相關事情。

我自己有這樣的理解後,也問了 GPT-3 他擅長回答怎樣的問題,他回答:

  • General knowledge questions
  • Questions about the world around us
  • Questions about history
  • Questions about science
  • Math questions

看起來主要就是某些有「確定答案」的問題。

不過, 我也問了 GPT-3 不擅長回答什麼問題,他的回答包含:

  • Questions about specific people or personal experiences
  • Questions that require in-depth research
  • Questions that require creativity or original thought
  • Questions about the future
  • Questions about complex topics or concepts

看起來,主要是那些資料不夠的、沒有答案的、複雜深入的、與未來有關的問題。

而這些 GPT-3 自認不擅長的問題,好像也是人類相對比較有能力去回答的問題?

#GPT-3   #AI


嘗試使用 Logseq 上面的 GPT-3 plugin

發布於 2022-06-15 | 最後更新時間 2022-06-16 | 分類: What I Tried Today

References: 

這是什麼?

  • 這是 Brian Sunter 這個工程師透過 OpenAI 的 GPT-3 api ,製作而成的 Logseq 插件。

  • 它非常地簡單使用,只要在 Logseq 寫下任何問題,並且在後面輸入 /gpt3 ,就會呼叫 GPT-3 的 AI 來回答這個問題。

如何安裝?

  • 在 Logseq 的 plugin 市集搜尋 GPT-3 Open AI 並安裝

  • 到 OpenAI 官網註冊帳號,複製自己的 API-Key

  • 回到 Logseq 的 plugin 介面,打開設定,貼上自己的 API-Key ,就可以開始用了。

我嘗試問了一些基礎的知識型問題,例如 What’s bitcoin? What is personal knowledge management? 它回答的答案都很合理。而我繼續問一些觀點類型的問題,例如 Should we have clear goals? 或是 Why should I keep making notes? 它給的回答也還是很合理,那種答案有點像是 Google 找到 Quora 或是 Reddit 上面最多人 upvoted 的問題一樣。

我問了一些問題後,有點欲罷不能,覺得非常開心,好像有了一個自己的私人問答機器人一樣。整體初步的感覺是, GPT-3 很適合在面向一個新議題時有一個最初步的理解,他的回應通常都蠻簡潔扼要,可以順著回應再繼續往下問。但我還沒有問他太複雜的問題,以後再來測試看看。期待之後能夠把這個機器人加入我的 workflow 裡面!


以下是我問的幾個問題與回答節錄:

Q: What's Bitcoin?

A: Bitcoin is a cryptocurrency, a form of electronic cash. It is a decentralized digital currency without a central bank or single administrator that can be sent from user to user on the peer-to-peer bitcoin network without the need for intermediaries. Transactions are verified by network nodes through cryptography and recorded in a public distributed ledger called a blockchain.

Q: What is personal knowledge management?

A: Personal knowledge management is the process of organizing, storing, and retrieving the information and knowledge resources that are important to an individual. This includes both digital and non-digital resources, such as books, articles, notes, contacts, and files. Proper personal knowledge management can help individuals be more efficient and productive in their work.

Q: Should governments regulate cryptocurrencies?

A: There is no definitive answer to this question as opinions will vary from person to person. Some people may feel that cryptocurrencies should be regulated in order to protect investors, while others may believe that too much regulation could stifle innovation. Ultimately, it is up to each individual to decide what they believe is best.

Q: Why do people use Zettelkasten method to taking notes?

A: There are a variety of reasons why people might use the Zettelkasten method. Some people find that it helps them to better organize their thoughts and ideas, while others find that it helps them to better remember information. Additionally, some people find that the Zettelkasten method can help them to make connections between ideas that they might not have otherwise made.

Q: How to increase productivity?

A: There is no one answer to this question since productivity varies from person to person and depends on many factors. However, some tips to help increase productivity include:

  1. Create a daily schedule and try to stick to it as much as possible.
  2. Set realistic goals and break them down into smaller, more manageable tasks.
  3. Take breaks when needed and make sure to get enough rest each night.
  4. Find a work environment that suits your needs and helps you focus.
  5. Stay organized and keep track of your progress.
  6. Seek help when needed and don’t be afraid to ask for assistance.
  7. Be willing to adjust your approach if something isn’t working.
  8. Reward yourself for meeting milestones and goals.
  9. Keep a positive outlook and avoid getting overwhelmed.
  10. Stay motivated by setting yourself new challenges and goals.

Backlinks:

#GPT-3   #AI   #Logseq


為何我不再用「純」文字編輯器了?

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

我已經有好長一段時間沒有使用以前很喜歡的那些文字編輯器來寫作,像是 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,我真的很喜歡這個編輯器,雖然暫時找不到使用情境,但我仍會保留著他。

#Text Editors   #iA Writer   #VS Code


嘗試了 Beam 這個工具

發布於 2022-06-10 | 最後更新時間 2022-06-10 | 分類: What I Tried Today
  • 今天嘗試了 Beam 這個「瀏覽器+雙鏈筆記」的工具

    • 他目前還在很早期的版本 (0.9.0),核心的功能只有幾個: 

      • 瀏覽

      • 擷取(capture)

      • daily journal (outline)

      • backlinks

  • 我會想要嘗試是因為,覺得這是一個很不錯的構想,讓 Capture 到 make notes 這段過程的阻力降到最小,好像挺適合進行速記,再拿去 Heptabase 裡面整理。

  • 初步體驗的感覺

    • 編輯起來蠻流暢的

    • Capture 的速度也蠻快,好像很適合拿來擷取 Twitter 上面有感覺的推文,並且快速寫下自己的想法。

    • 但每寫下一段文字以後,右邊的 action 竟然是「搜尋」,這點也蠻奇妙的。

    • 對於雙向連結的中文支持度也不錯,但好像不支援 Markdown 語法 (看起來只支援一點,支援粗體但不支援連結。)

    • 喜歡它的地方:讓瀏覽 -> 擷取的步驟更無阻礙。

  • 但當我想認真一點使用時,卻發現它有一些缺點

    • 不太支援 markdown

    • 複製出來的不是純文字,很難貼到其他 app 裡面

    • 沒有 export 的功能

    • 對我來講,這代表在這裡面記錄的東西很難導出到其他地方,是個蠻大的缺點

    • 這些缺點就讓我不想要在上面累積東西了,寧願多花一點點力氣把內容收集在其他 app 上面。

  • 在試用的過程中也讓我思考,我真的有需要這個「瀏覽 → 擷取」的 workflow 嗎?目前「瀏覽 → 畫線 → 寫筆記 → 擷取」的流程用起來有什麼不好嗎?

  • 簡單列點一下:

    • 原先的 Curius 著重在畫線,畫線時可以快速寫下自己的想法

    • 畫線完畢後,我會再找時間把畫線的段落與想法丟到 Hepta 裡面

    • 透過這個流程,我可以重新思考

      1. 我真正喜歡這篇文章哪些地方

      2. 我要怎麼重新組織這篇文章的重點

      3. 我產生了哪些想法

      4. 我產生的想法是否跟既有的筆記或想法有連結

    • 所以看起來,假設 Beam 沒辦法很好轉貼到其他 app ,也沒辦法 export ,那就有點失去了使用的價值,我很難再將它加入我既有的工作流裡面。

#Beam   #Curius   #Journal   #Browsers


為何我更偏好週休三日(而非工作五天但全遠端)

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

今天志祺在 Twitter 上面問了一個問題:

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

我的直覺反應是:當然是週休三日+全遠端。

但如果真的要選的話,我會傾向週休三日。因為對我來說,遠端已經是現在進行式。

而即使完全不能遠端,我還是更想要週休三日,因為那真的會有「多出一天」的感覺,那一天是完全自由的,是可以盡情揮霍、浪費的。

相較之下週休二日的第一天通常仍在回復體力,而第二天又要準備上班,心情沒辦法那麼自由。

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

#Works


測試 Heptabase Journal 的「拖曳到白板」功能

發布於 2022-06-08 | 最後更新時間 2022-06-08 | 分類: What I Tried Today
  • 今天 v0.152.0, Journal 功能的內測更新,提高了 dragging to whiteboard 體驗。

  • 具體來說,目前的實踐方式有兩種:

    • 假設在 Journal 編輯器上,透過 @ 或 [[ 建立卡片,或連結某張卡片。那麼我會得到的結果是,這個編輯器介面上的 block ,本身就是一個卡片的連結,此時將這個 block 拖曳到白板上時,得到的體驗是我期待的結果,就是顯示在白板上的卡片對應到的就是 journal 裡的這個項目,且在白板會自動展開,也會顯示 journal 對應的日期資訊在 Card Info 裡面。

    • 直接將某個文字 block 以及底下的列表文字拖曳到白板上,此時在 journal 中原本的列表文字會收起,而白板上則會呈現展開的內容。我覺得這是很有趣的設計,有點像是 journal 速記完以後,他在 journal 上的意義就是一個帶有時間序的「項目」。但白板上則是重新展開的內容。

  • 整體來說,我很喜歡這次的小更新,設計上很直覺也合理,期待後續有更多隨之產生的 workflow 。

#Heptabase   #Journal


人們不喜歡的網站體驗有哪些?

發布於 2022-06-07 | 最後更新時間 2022-06-07 | 分類: Random Thoughts
  • 今天看到有人轉推一則今年 1 月的推文,裡面列了許多「現代網站」惱人的地方如下:

    1. Figure out how to decline all but essential cookies
    2. Close the support widget asking if I need help
    3. Stop the auto-playing video
    4. Close the “subscribe to our newsletter” pop-up
    5. Try and remember why I came here in the first place
    6. A browser message asking if you’ll accept push notifications
    7. Another asking if you’re willing to share your location
    8. A banner suggesting you download the iPhone app
    9. An NPS survey asking you to rate the site.
    10. More ads than content
    11. Being required to register to read the full article.
  • 後面推主有列出他覺得的可能原因

    • Most digital teams don't experience the website as new users experience it. They're either looking at mock-ups / sandboxed version or have already accepted all the cookies.

    • Different teams are responsible for different elements based on driving different KPIs.

  • 想法:好像可以歸納整理一下共通的元素、以及思考「為何要有這些東西」,「有沒有其他解決方案」

歸納結果:

  • 人們不喜歡的地方在於

    • 在他體驗網站前就打斷他的體驗(蓋板廣告、聊天機器人、cookies 提醒、訂閱電子報的 pop-up、詢問是否要接收通知、是否分享位置)

    • 以他沒有預期的方式強迫他體驗(自動播放的影片、過多廣告)

    • 體驗正好時阻斷自己的體驗(訂閱、註冊以閱讀更多)

為何要有這些東西?

  • (好像太顯而易見,目前沒有其他答案或想法)

有沒有其他解決方案?

  • 如果整個使用網站的過程是不斷地根據體驗給予正負分,那麼還沒累積正分時打斷體驗就會直接負分出局,較好的作法可能是累積了一定的正分後,再給予這些可能會扣分的功能。

  • 要釐清自己如果真的需要這些負分功能,優先序是什麼?如果最多只能選 2 個,要選哪兩個?(為什麼是 2 個?好像是純體感。)

#Websites   #UX


我真正想要的不是個人 wiki

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

經過了一個月持續更新個人 wiki ,我發現我真正想要的不是「wiki」,wiki 感覺更像是面向一個社群或一個知識主題的知識系統,但對我來說,我想要的核心元素比較不是「多人協作」以及「知識」,而是更初步的「想法」。

我想要的地方仍會放置知識,但更偏重的是我對這個知識的想法與觀點。

我想要的地方仍會開放其他人留言,但更偏重的是放置我自己的內容。

所以我決定調整這個子網站的方向與定位,重新思考以後的定位如下:

這個網站會分成兩大類的內容,一類是我的「長青筆記」(evergreen notes),一類是我的「想法快照」(姑且稱為 thought snapshots)。

前者是我會持續維護的筆記,每則筆記只承載一個觀點或主張;後者在紀錄的當下即成形,也許會發展成長青筆記,也許過一陣子就會被拋棄。

而思考一個連假後,在製作的方式上,我決定再捨去 Dendron ,也不會回頭轉向 Logseq ,而是選擇與部落格相同的 Zola 來處理。因為這兩個東西的使用者應該都算極小眾,就不在這邊展開比較了,只分享幾個我最後判斷的原則:

  • SEO 表現
  • 網站讀取速度
  • 互動的可能性

但這一個月對 Dendron 的嘗試對我來講仍非常有意義,我重新思考了層級架構對我的重要性,也認識了這個很小眾,但很有自己個性的工具。

這樣的使用經驗也讓我意識到,我目前在 Logseq 上面運作的每日工作與專案紀錄系統,好像更適合放在 Dendron 上面。

這整串寫下來,我隱約有個想法是,我好像已經找到三件事情上面的 90 分方案了。

  • 面向自己的第二大腦是 Heptabase
  • 工作上的每日紀錄與資訊管理是 Dendron
  • 向外輸出則是 Zola 這個靜態網站產生器 (分成部落格與「筆記&想法」的子網站)

但這整套工作流的演進,也離不開之前嘗試過的每一個軟體與工具。

這邊汲取一點,那邊發想一些,帶著 markdown 文件搬來搬去,

最終形成一個自己用起來越來越順,各方面效率也越來越高的系統。

#Personal Wiki   #Dendron   #Heptabase   #Zola


測試 Hepta 的 Journal

發布於 2022-06-05 | 最後更新時間 2022-06-05 | 分類: What I Tried Today
  • 今天參加 Hepta 的新功能 Journal 測試,覺得很有趣。

  • 測試的方式:

    • Hepta 團隊先在 Discord 邀請有興趣的人填寫表單,再挑選大約 30-50 人加入一個 private channel ,並且邀請大約 8 人在這兩天進行線上會議的測試。我剛好連假有空,就登記了參加

    • 會議開始後,團隊先跟我確認我的註冊帳號,接著他們在他們那邊幫我開通新功能,我的 Hepta 裡面就多了一個 Journal 的頁面。

    • 接著他們就開始讓我自由使用,看看有沒有什麼問題。

  • 而我在測試的過程中發現下列問題:

    • 目前的介面,缺少一個日曆可以快速點到其他日期

    • 不知道怎麼連到其他日子

    • 這個 journal 本身好像不是一張卡片,看不到卡片資訊,但從其他卡片連回來後,發現 journal 的等級跟 whiteboards 同級。

    • 不過,從其他地方還是連不到這一天,只能連到這一天建出來的卡片

    • 目前日期的顯示方式 Jun 5, 2022 我不是特別喜歡,想要可以改成 2022-06-05 這樣。

  • 後來發現,在白板中也可以打開 journals 的視窗,變成是可以把 Journal 裡面記下來的東西傾倒到白板,我還蠻喜歡這樣的設計,也很直覺,但缺點是傾倒時會直接消失在 Journal 的欄位裡面,我比較希望可以留著。

  • 後記: 在 2022-06-08 時的測試 Heptabase Journal 的「拖曳到白板」功能 這篇裡面就可以保留拖曳的內容了。

#Heptabase   #Journal


為何 Heptabase 要建立 Journal app?

發布於 2022-06-05 | 最後更新時間 2022-06-05 | 分類: Daily Why
  • 在 Hepta 裡面,側邊欄的這些「功能」被它們稱做 app ,我的理解是「應用卡片的方式」。而在 Timeline, Tags, Map (Whiteboards), Library 後,Journal 是第五個可以應用卡片的 app。
  • 沒有很認真去查證,但我在 discord 裡面觀察的感覺是, Journal 的用意是讓 Hepta 的使用者們能「更快速無壓的紀錄」。
  • 那原本的 Timeline 有遇到怎樣的問題嗎?坦白說,我覺得也是很快速無壓了,但少了「時間」這個重要的屬性,因此我必須自己去建立對應時間的卡片,來滿足這樣的時間屬性。
  • 但從 Hepta 團隊的角度,這個新功能的意義會是什麼呢?
  • 讓用戶養成儀式感?更黏著?好像可以。
  • 透過各種 Daily Journal 的 templates 來讓新手用戶更好上手?好像也是。
  • 這樣想來,Journal 的概念比 “Timeline” 更適合在「累積」為主的系統裡面,畢竟社群的 timeline 是鼓勵大家想到就發,發了就不去管。

#Heptabase   #Journal


Dendron 跟 Zola 哪個好?

發布於 2022-06-04 | 最後更新時間 2022-06-04 | 分類: Random Thoughts
  • 透過 Dendron 建立個人 wiki 剛好滿一個月了,這個月我養成了每天至少提一個問題的習慣,而連帶的好處是我的各種思考更多了,也開始把他們都連在一起。

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

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

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

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

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

#Dendron   #Zola


嘗試在部落格加上 navbar

發布於 2022-06-04 | 最後更新時間 2022-06-04 | 分類: What I Tried Today
  • 今天比較有空,就來處理 blog to-do list 上面的其中一項:加上 navbar。

  • 先研究了 zola 官網的各種 themes ,發現好像都是用 sass 的架構,跟我從 Owen 那邊承襲而來的單純 css 有些落差。所以最後還是看回 Owen 的作法。一開始糾結在他的版本,但後來轉念一想,他放置的地方是在 Section Root ,那我只要放到 Section Top 不就好了?

  • 於是經歷了一番亂搞,最後終於製作完成了,整體感覺我還蠻喜歡的,雖然肯定還可以更好,但目前也夠用了。

  • 附上截圖

  • 這個研究的過程也讓我開始思考,是不是個人 wiki 還是用 Zola 來建更好?

#Zola


結構化與去結構化的筆記工具優劣

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

這是從雙向鏈接的一點思考這篇文章延伸的一些想法。

一開始會棄 Obsidian 朝向 Workflowy 跟 Logseq 是因為,我在 Obsidian 裡面實踐 MOC 的形式是 top-down 的方式,但那讓內容太難增生,每次產生想法都在想這個該放哪,久而久之就壓力很大,覺得無法順利進行。

後來到 Workflowy 及 Logseq 後的確感到了無壓力的輸入體驗,但累積久了卻發現 Logseq 讓我無法全心投入(見我為何無法全心投入 Logseq ),現在想起來可能是因為 Logseq 提倡的「去結構化」,也就是沒有資料夾,單純倚賴連結的架構。

在讀了發現問題思考法後,察覺到「分」跟「連」的意義,覺得 Logseq 這類工具擅長連,但不擅長分。

開始接觸 Dendron 後,被他們對於層級化架構的理念吸引,開始覺得有結構還是很好的一件事。

隱約感覺,還是必須先有結構,再來產生去結構化的好處,有點像是我在打這串 thoughts 時,串連的這幾個東西,都因為有明確的層級,所以我反而更好聯想,能讓他們串在一起。

#PKM Thoughts   #Hierarchy


更新卡片內容的最佳實踐方式是?

發布於 2022-06-03 | 最後更新時間 2022-06-25 | 分類: Random Thoughts
  • 在 Heptabase 裡面,如果某張卡片的內容需要更新,但也想留著之前的版本,該怎麼做最好?

    1. 透過卡片的命名去處理新版本,例如原本是 卡片A 2022-03-04 ,更新後變卡片A 2022-06-03 ,然後在 03-04 的卡片連結到 06-03 但白板裡的卡片就換成 06-03
    2. 卡片命名都是卡片 A ,但直接更改 03-04 的卡片內容為 06-03 的版本,不特別標注日期跟版本差異
    3. 卡片命名都是卡片 A,在 03-04 的卡片內容下方,補充 06-03 的內容。
  • 我覺得更好的作法,可以把卡片 snapshot 起來,當前還是顯示最新版本的卡片,但 UI 上面可以看到有點類似文件夾那樣的「卡片組」樣式,然後點開就可以看到過去版本的卡片內容。

  • 而這樣的卡片是「整組綁定的」,也就是說在任何白板加入卡片時,都會直接加入這個卡片組。

  • 我覺得卡片組的方式優點在,本質上,這張卡片的主題一樣,方法一會過於冗余累贅,方法二會看不到變化的過程,方法三也可能會感到混亂。


但在還沒有這種「卡片組」的概念前,我想到的實踐方式是:

  • 類似方法一的內容,只是把舊卡片後面標註為「archived on 日期」,並且在 Hepta 裡面的新卡片內部連結到這張卡片。部落格上面則不需要特別處理。

#Heptabase


我為何無法全心投入 Logseq?

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

我覺得使用 Logseq 幾個月下來,似乎讓我沒辦法有「累積」的感覺,我只知道我建立了很多東西,但他的搜尋體驗沒有太好,很難直覺找到我想找的東西,而即使要透過連結,我也必須要先知道「我有這個東西可以連結」,才能連結的到。

這兩件事都會造成我使用上的心智負擔。

還有一個是 Logseq 的 block embed 功能我也沒有特別信任,之前就發生過錯誤,不知為何過一陣子回去看某則筆記後,發現讀不到 embed 的東西,但又因為整串 embed 資訊是一串亂碼,導致我根本不知道我 embed 了什麼東西,結果那則筆記也失去它的意義。

綜合以上幾點,自從 Heptabase 出現後,我就感覺 Logseq 蠻難作為第二大腦的儲放地點,最多最多只能當作想法隨意萌芽迸發的地方,而一但有了某種固定的結構,就適合放到 Heptabase 裡面當作我的原子筆記。


Backlinks:

#Logseq   #Heptabase


為何我想把工作記錄由 Logseq 移到 Dendron?

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

今天動起了這個念頭。也不知從何而來的,感覺好像是發現,我雖然工作上很倚賴 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 的主頁面。長久來說,這樣好像更能有組織地累積內容。

那就先來試試看吧!

#Logseq   #Dendron


什麼是「鑄幣稅(seigniorage)代幣」?

發布於 2022-06-01 | 最後更新時間 2022-06-01 | 分類: Daily What
  • DeFi 穩定幣的過去與未來:寫在 Terra UST 崩盤後 這篇好文裡看到這個有趣的概念。
  • 鑄幣稅代幣引用鑄幣稅的概念,指的是直接與該貨幣對應,並且會直接基於該貨幣的流通使用量影響價值的代幣。
  • 以 USDC 為例,該穩定幣的鑄幣稅代幣可以理解為發行商 Circle 的股票。
  • 而之前崩盤的 UST ,其鑄幣稅代幣就是 LUNA ,而 DAI 的鑄幣稅代幣是 MKR。
  • 這篇文章認為,如果鑄幣稅代幣本身就是對應穩定幣的價值支撐,那麼就有可能會讓穩定幣的「穩定效果」受到負面影響,因為鑄幣稅代幣的流通性跟需求若容易觀測,那就會讓市場處於悲觀情緒時,更難逃離悲觀的賣壓漩渦。
  • 因此這篇文章提出的主張是:對等無知(symmetric)的不透明貨幣市場有利於流動性。

#Stablecoins