要在 Termux 安裝 Dart，透過 Apt 或 Pkg 去安裝 Dart 套件即可。 pkg install dart 安裝完可查詢版本做過確認，沒意外的話應該會正常運作。 dart --version

要使用 HomeBrew 安裝 LuaRocks，可輸入下列命令。 brew install luarocks 安裝完可實際調用命令做過確認。 luarocks --version

要透過 Rider 連線 MariaDB 做些操作，可以點選 [ View | Tool Windows | Database ] 主選單選項，開啟 Database 視窗。 然後點選 Database 視窗工具列上的新增按鈕，新增 MariaDB 的 Data Source。 點選 Data Sources and Drivers 視窗中的 MariaDB Driver 按鈕，或是自行切到 MariaDB Driver 頁籤。 在 Driver files 那邊點選下載 Driver。 下載完回到 Data Source。 帶入 Data Source 的資訊後按下 OK 按鈕。 即可在 Database 視窗透過加入的 Data Source 連線到 MariaDB，並進一步對資料庫進行操作。

CAP定理 (CAP theorem)，又稱作布魯爾定理 (Brewer’s theorem)，指出對於一個分散式系統來說，不可能同時滿足 Consistency、Availability、Partition tolerance 三種特性。 Consistency 是一致性，這邊指的是強一致性，描述所有節點都是使用最新的資料副本。也就是說當資料寫入或是更新後，所有節點都是一致且最新的資料。 像是如果系統在設計上在收到更新或是寫入的請求後，節點處理完後先進行同步再回應請求，確保資料同步完成，資料在所有節點資料一致，這就是一種符合一致性的設計。 Availability 是可用性，指的是每次發送請求都能在容許的時間內得到回應。但每個節點間的資料可能不是一致且最新的，因此回應的資料可能不是最新的。 像是系統收到更新或是寫入的請求，節點處理完後立即回應請求。節點間的同步可能透過排程、訂閱、或是滾資料之類的方式在背後運行，節點間的資料難免有些落差。所以從節點讀取到的資料可能就不會是最新的。 Partition tolerance 是分區容錯，指的是無論網路斷線、節點當機、封包丟失造成系統被切分成不同區塊，系統仍應能繼續服務。 CAP 定理揭露了分散式系統最多只能擁有兩種特性。 如果滿足 AP，則系統內的網路或是節點出狀況的情況下，會無法在容許時間內完成通知更新，無法滿足 C。 如果滿足 CP，在網路或是節點出狀況的情況下，為確保一致性，系統會嘗試等待重試，無法在容許時間內回應，無法滿足 A。 如果滿足 CA，需要在容許時間內完成資料同步並回應，因此在網路與節點出狀況也要服務的話會無法做到，無法滿足 P。 因為分散式系統中網路與設備都是不可靠的，因此 CAP 中的 P 通常是一定要的，故 CAP 多半是在 CP 與 AP 間取捨，看系統適合往哪邊走。 Link CAP定理 - 維基百科 [CAP 定理的含义](http://www.ruanyifeng.com/blog/2018/07/cap.html 分佈式系統理論基礎- CAP) Better explaining the CAP Theorem

要使用 HomeBrew 安裝 Fork，可透過 brew cask 的 Install 命令安裝 Fork 套件。 brew cask install fork 安裝完後可透過 Application 開啟安裝的套件。

要更新 Rider 的套件，可以透過 Rider 的更新自動偵測，當偵測到套件有更新時，Rider 的右下方會看到更新通知框，人框告知哪些套件可供更新，點選更新通知框內的 update 連結。 在 IDE and Plugin Updates 對話框中查閱套件的更新資訊。 勾選要套用更新的套件，然後按下 Update 按鈕。 套件即會開始進行更新的動作。 更新完成重啟 Rider，套件更新即會生效。 除了透過更新通知框，也可以將 Preferences 對話框，左側切到 Plugins 頁籤，右側切到 Updates，挑選要更新的套件按下 Update 按鈕進行套件的更新。

要在 Rider 使用自己的 NuGet feed 去抓取 NuGet 套件，可點選 [ Tools | NuGet | Show NuGet Sources ] 主選單選項。 切到 Sources 頁籤，左側選取 Config 檔案，右側切到 Feeds 頁籤，然後點選 New feed 那列後方的 + 按鈕。 填入 NuGet feed 資訊後按下 OK 按鈕即可。

系統中如果有使用到 Redis，有時會碰到要將 Redis 內資料落地的情境。這時可能會用 Redis 的 List 做一個簡單的 Queue，將資料以先進先出的方式處理。 這樣的做法看似運作良好，但隱藏著一個潛在的問題。如果今天從 Redid 取出資料還未處理就發生錯誤，可能是機器當機重啟那種錯誤，就會有丟失資料的現象發生。 為了解決這樣的問題，可以套用 Reliable queue pattern，當資料確實被處理完才從 Redis 內移除。 簡單的說就是把資料的 Id 放在 List 之類的結構，實際的資料放在 Value，當你 Deque 時將 Id 從 Pendding 放到 Working，處理完才從 Working 清掉，順帶將 Value 對應的資料刪掉。 實作上通常 Pending 與 Working 會用 List 結構去實作，Value 會用 Hash 結構。 當資料要從 Redis 取出處理時，會先查看 Working 是否已經有資料，如果 Working 已經有資料，可能代表之前處理到一半之類的，這時資料直接由 Working 反查 Value 後吐回。如果 Working 沒資料，會從 Pending 將需要處理的 Id 透過 rpoplpush 命令轉到 Working，然後反查 Value 吐回。 資料處理完要將資料從 Redis 移除時，會將 Working 與 Value 中對應的資料移除。

要查詢資料庫的 Constraints 可查閱 information_schema schema 的 table_constraints table。 select * from information_schema.table_constraints order by table_schema, table_name; Link List table check constraints in MariaDB database - MariaDB Query Toolbox

Rider 如果沒設定 SQL dialect，開啟 SQL 檔時上方會有提示訊息，按下 Change dialect to… 按鈕即可設定 SQL dialect。 或是透過滑鼠右鍵快顯選單也可以。 SQL dialect 的設定可分為 Global、Project、與 File 幾個層級。 設定好後按下 Save 按鈕儲存。 SQL dialect 設好後 Rider 就會知道怎麼正確解讀 SQL 檔。 因此能做些對應的支援處理，像是排版、…等。