最近參加了一場兒童營活動，活動快結束時有一環節是當日活動回顧。攝影大哥在電腦上執行了一支 app，將當日所拍照片用投影機播放出來，同時播放背景音樂。我不清楚那支 app 是怎麼做的，但它激發我一個靈感：通常要將多張照片做成一個個播放的影片是要花一些時間作影片編輯、輸出。但遇到要當日回顧的情形，就要趕著做影片。所以如果能簡單將需要播放的照片、音樂丟到電腦的一個目錄，再用一支 app 讀取目錄、播放，就可以免去趕時間做影片。 我原本搜尋有沒有這種 app，但沒找到理想的，有些只能播照片、再手動播音樂。既然沒有，只好自己寫一個但萬事起頭難，要用什麼程式方法快速達成目的？我沒什麼頭緒。後來我想到最近很紅的 AI，就把需求輸入給 Bing Chat，果然輸出不錯的原型設計 (prototype)。我們可以提示 Bing Chat：功能需求、要用什麼語言寫、要用什麼軟體框架寫、要用什麼套件寫。Bing Chat 幾分鐘就能輸出結果。由於我們輸入的提示有時難以精確，可想而知 AI 也無法因此輸出相應的部分，因此這種輸出只是原型設計。但原型設計就很有價值了，只要我們輸入 AI 的提示將主要部分描述清楚，剩下一些未輸出的小細節再手工實作就行！ 最終我以 Bing AI 生成的原型 app，再經由我的手工雕刻完成了一款”照片投影機” web (PWA) app: https://myhpwa.github.io/photo-slideshow/ 支援 Windows, macOS, Linux, Android, iOS. 原始碼： https://github.com/MrMYHuang/photo-slideshow (實測 Bing Chat 有時會拒絕幫你寫程式，可能是跟微軟自家的 GitHub Copilot AI 寫程式付費服務衝突。目前可以多試幾次重新與 Bing Chat 對話，有時就會吐出程式碼)

我是個業餘研究分散式計算的門外漢😅。踏入這門領域，遇到許多不解的規則，其中一項就是標題寫的：為什麼有些分散式計算要求奇數節點？今天找到一篇文章讓我豁然開朗：https://etcd.io/docs/v3.3/faq/#why-an-odd-number-of-cluster-members 首先要釐清是哪些分散計算？我把分散式計算分兩類：一類是追求高效能、各節點可獨立平行運作的計算（簡稱高效能），比如用多個節點服務多個獨立資料計算的使用者請求。另一類是追求高可靠度、運作結果有相依的計算（簡稱可靠度）。而原問題是指高可靠度。 許多高可靠度分散式計算應用軟體，如 etcd, RabbitMQ (quorum queues), 要求叢集中的節點數設定為奇數，為什麼？首先這類軟體是利用節點數的「多數」, floor(n/2) + 1, 作為某項可靠度的依據，如選出領導節點。以 n = 3 為例，多數為 2，也就是容錯為 3 – 2 = 1 個節點。那麼再多加 1 個節點會怎樣？就是 n = 4，多數變為 3，但容錯仍為 1 = 4 – 3. 所以 3 節點與 4 節點相比，4 節點不但沒增加容錯能力，反而增加達成多數的難度 ( 2 vs 3 )。因為多加的節點也可能出錯，能導致原本只錯 1 個的叢集再多 1 個錯，反而不能達成多數！因此用偶數節點的叢集不比減一的奇數來得好。 另外高可靠度分散式計算有一點與高效能也很不同。高效能是節點數愈多，效能愈好。但高可靠度往往是節點數愈多，要花更多時間作節點間的資料交換才能計算出多數，因此效能反而變差！所以高可靠度叢集要在可靠度與效能間作取捨。

我做了一款 app 可以隨機顯示聖嚴師父的108則自在語。希望對大家有幫助。可在各 app 商店下載，或用瀏覽器安裝。 iOS 14+, macOS 10.11+:https://apps.apple.com/app/id1634911913 Android 6+:https://play.google.com/store/apps/details?id=io.github.myhpwa.sy108q Windows 10+:https://www.microsoft.com/store/apps/9N6PT9RL8P1D Linux:https://snapcraft.io/sy108q PWA 網頁版：https://myhpwa.github.io/sy108qPWA 安裝教學 （這是我之前寫的另一款電子佛典 PWA）：https://github.com/MrMYHuang/cbetar2/blob/master/PwaInstall.md 開放原始碼：https://github.com/MrMYHuang/sy108q

這是一款成語遊戲 + 成語詞典的 app。遊戲部分：可作為聚會遊戲。玩法是出題者，點擊遊戲開始，會隨機由離線成語資料抓題，並依設定答題時間一題題切換。每題成語，出題者不可說出其中任何一字，只能用比手畫腳方式讓答題者猜是什麽成語。如果在限時內，答題者猜中成語，出題者請按綠色勾。若答題者放棄，出題者可按紅色叉跳過或等答題逾時。所有題目完成後，最後會顯示分數，與每題答題狀況。另外有些成語用字較生僻，建議在玩時可以自行判定相似成語為答對。 iOS 14.0+, macOS 10.11+:https://apps.apple.com/app/id1634551497 Android 6.0+:https://play.google.com/store/apps/details?id=io.github.myhpwa.ygig Windows 10+:https://www.microsoft.com/store/apps/9PHK9WGRCL9Z Snap Store (Linux):https://snapcraft.io/ygig PWA 網頁版：https://myhpwa.github.io/ygig 開放原始碼：https://github.com/MrMYHuang/ygig

上個禮拜六、日，我又想到我這款電子佛典 app – cbetar2 可以加什麼新功能。我這款 app 起初是為手機、平板的觸控裝置設計，因此它的 UI 較適合觸控，其中佛經目錄的瀏覽是一頁一層目錄列表呈現，這種好處是每列可以足夠大，方便手指觸控。但操作時想從目前一層往上跳 n 層，就得按 n 次向上鈕，不過這也是不得已的妥協。 然而我這款 app 另一設計訴求就是跨平台，不止觸控裝置可以用，桌機、各種作業系統都可以用。因此此種觸控 UI 在桌機上運作就不是這麼適合，雖然堪用，例如過大的 UI 讓滑鼠的滑動距離變有些長。 後來參照一些桌機用的電子佛典 app，發現它們都使用樹狀目錄，較適合滑鼠操作，這使得我想改造我的 app 支援可切換觸控與鍵鼠 UI。要做樹狀的佛經目錄 UI，首先要有樹狀結構的佛經目錄資料、樹狀 UI 元件，還有將資料轉為 UI 的演算法。CBETA 經文檔有提供樹狀佛經目錄資料，格式是 XML，把它讀入記憶體後，可以作一些處理，產生新的樹狀資料，例如把分開的樹狀目錄資料合併成單一樹狀資料。 “遞迴”是一個操作樹狀結構很好用的演算法，很適合做上述樹狀資料的處理與樹狀 UI 的生成。要了解遞迴如何處理一棵樹，首先可以將樹表示為節點與分枝的組成。一棵樹由根節點開始作分枝，長出子節點。這些子節點又能再分枝長出它們的子節點。而遞迴處理的切入點就是每個節點都做類似的事，以程式來講可以表示為一個 function：每個節點除了作自己負責的事，也可以呼叫它的子節點作事。而這些子節點也是作類似的事，也就是用同一個 function 作事。如此一來只要從樹的根節點啟動 function call，就能讓每個節點都作事。這種 function 呼叫自己的演算法就是遞迴。遞迴還有一重要注意事項，就是在最終端的”葉節點”，要終止遞迴下去，忘了寫這條件可是會造成無窮遞迴。以下為一段遞迴 function 的範例： 有了樹狀資料，接著仍是使用遞迴將它們對應成樹狀 UI 元件即可。但我遇到一個小挑戰，就是我這支 app 是基於 react + Ionic Framework 寫 UI，但…

最近在改良我的電子佛典 app – cbetar2，其中新增一項大功能就是支援匯入 CBETA 經文檔 zip 作離線瀏覽。起初的版本我只在我的 hTC U19e 6 GB RAM Android 手機與 iPad 模擬器測過。但後來發現 iPad 模擬器與實機有一重大差異 – 硬體資源，主要是 CPU, RAM, 儲存空間這些部分基本上模擬器的資源就是開發機(我的 MacBook Air M1 2020)的資源，而不是 iPad 實機的資源。而往往開發機的資源會比實機好上很多，因此這個部分模擬器的表現與實機不同。的確我的 app 在模擬器可以順利運行，但在實機 iPad 6 2 GB RAM 就會當掉。 我的 app 在匯入小檔 zip 時都可以順利運作，但匯入完整 CBETA 經文檔 zip 才會在 iPad 當掉。因此這顯然是匯入時作 zip 解壓縮的部分耗掉太多 RAM 所致。經研究我原本使用的解壓縮程式 adm-zip 只支援一次將…

As discussed on chromium.org in Sep 2018, Chrome iframe has a service worker (SW) inheritance limitation with srcdoc and about:blank. This limitation invalidates the offline and cache capabilities provided by service worker for progressive web app (PWA), if iframe with srcdoc or about:blank is used in PWA. This issue can hurts PWA, e.g., a PWA…

2022/06/02 星期四端午節前夕，搭電車回家的路上，我在想我開發的 CBETA 電子佛典 app 還能支援什麼新功能、作什麼改善？這款 app 之前已支援離線瀏覽，但僅限於整合 Electron app 的版本，若單純用 PWA, 只能用連線版資料庫。因此我就在想有沒有辦法克服此問題。 這問題的影響面涉及 iOS, Android 平台不支援 Electron app (特別是 App Store 禁止此類 app 上架)，因此我的 app 在這兩平台缺乏對離線瀏覽資料庫的支援。這兩個平台的用戶數是主流，因此這是一個值得解決的問題。 起初研究此問題，要先探討可行性，例如現有的系統、程式能不能達成需求，例如經文資料檔要存哪、目標功能能不能用 JavaScript 完成、需要多少時間能做得出來？如果不可能，就不必繼續了😭探討完可行性，就是整理有哪些工要做。 以這次的問題來說，經文資料檔有幾 GB，在 PWA 環境得試著用 IndexedDB 才可能儲存，而實際測試發現不同平台有不同限制。例如在 iOS 把 PWA 新增至桌面後，會限制 IndexedDB 最大空間 1 GB😭、在 Android 讀取 1 GB 多檔案會出現錯誤😭 iOS 的問題，我後來想到經文原檔中排除用不到的檔案，再壓縮後由 3 GB 變為 600+…

我開發的一款”非官方 CBETA 電子佛典 2″ app 近期的重要改進有兩個。一個是支援全螢幕顯示經文、另一個是效能上的明顯改進。 原本 app 在手機上（橫向）顯示的版面如圖： 空間利用不太好，有許多空白處不能拿來顯示經文。這就促使我開發全螢幕閱讀經文的功能。下圖是成品全螢幕模式，完整利用所有空間顯示經文。至於一些 app 功能呼叫，可以利用浮動按鈕（圖中右下一半隱形淡藍色按鈕），雖然目前放的功能不多。 另一個重要改進則是使用楷書字形的效能。之前因為寫 PWA 必須考量各執行環境差異、限制，導致每次載入經文要重新載入楷書字型。這問題源自於 Chrome 瀏覽器的 iframe 無法共享主視窗的 service workers，因此也無法共享 PWA 離線瀏覽的特色。為了避開此問題，我將字型檔存致本地 IndexedDB 作離線使用，在需要時用 JavaScript 載入主視窗與 iframe。但 iframe 的限制只要載入不同卷經文內容，字型就要重新載入，頗消耗電腦效能。特別是後來完整支援全字庫楷書更耗電腦效能，尤其是手機。 這問題存在一年半，一直沒想到怎麼解決。最近突然有想法並作實驗，發現在記憶體快取字型後，字型只須在 app 啟動時載入記憶體 1 次，結果經文載入效能明顯改善。以阿彌陀經為例，原本在我的 hTC U19e Android 手機開啟約 8 秒，使用快取後，降為 2 秒（4倍快！)，幾乎與使用手機內建字型的效能差不多，而且能顯示的字也較多。 以下是各種 app 安裝通路：App 商店安裝：Apple App Store (macOS 10.11+ x86_64 & arm64, iOS…

NodeJS 是一款 JavaScript (JS) 的直譯器 (interpreter) 或執行環境 (runtime)。不過 JS 最早是在瀏覽器 (browser) 上執行的，可用來寫網頁應用程式 (web apps)，後來才有 NodeJS 可以用來開發獨立運作的應用程式 (standalone apps)。 這兩類 JS 直譯器，browser (pure JS) vs NodeJS，雖然都是基於 JS 語言，但卻有一重大差異：除了語法、一部分核心 APIs 相同，但有些核心 APIs 不相同。例如前者獨有網頁相關的 DOM APIs, 而後者獨有檔案系統讀寫 APIs。之所以會有這些差異，源自於它們一開始的定位不同，一種重於 web apps 開發、另一個重於單機程式開發。除了出發點發展的差異，另一種是本質上的限制造成 APIs 差異，例如 web apps 為了確保其安全，瀏覽器不提供它們直接對使用者裝置的檔案作讀寫，而 NodeJS apps 則沒有這限制。因此在寫 JS 時，知道一個 API 是否支援 browser 還是 NodeJS 是很重要的，用錯是基本行不通的。因此常久以來，兩種 JS…