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…

這個假日在練習 React app 支援多語言，使用的是 react-i18next 套件。其實我之前就用它寫了一個範例程式 pwa-react18-redux-i18n-ts-example 放在 GitHub。在使用一項新的程式架構時，我個人很建議先用它寫範例程式、放上 GitHub，接著再用在大程式上。因為大程式往往很吃硬體資源，要較長的編譯時間，系統也複雜不易修改，所以可以避免的話，不建議拿它來實驗一項新程式架構。而把範例程式放到 GitHub 或其它地方也是很重要的一步，將來要用到時，找出來複製、修改比較快，這些看似平凡的程式碼，背後卻有不知花了多少時間才想出的作法！因此它的價值可不要被它的表面低估了，即便是幾10行的程式碼，也可能是思考了1天才想出。 初步熟悉新工具 react-i18next，接著就要把它用在實際的應用上。我想到我可以拿我過去寫的 apps 作應用。我的 apps 可概略分為2類：1類是特定區域的應用，如電子佛典、台灣水庫、台灣藥品…等。另1類則非特定區域，全球都可用的，如幸運輪盤、雙重認證，這一類 app 就很適合支援多語，因此我決定拿幸運輪盤 app 作練習。 練習的過程包括 app 的修改，要把每個靜態字串用動態程式改寫，才可依不同語言傳回不同字串。而每個字串都要有每個語言的版本。甚至 app 要上架至 Apple App Store, Google Play Store, …等，螢幕擷圖裡的文字也要有各語的版本。雖然作這種重複性的事，會有一些煩人😅，所以我只做了中文、英文兩個語言。但考量到 app 的親切度，還是覺得這麼作是有意義的。試想一支只有你看不懂語言的 app，你應該也不太想用。 我這支 app 前端是用 PWA，因此可以直接推送給使用者。而後端則須上架至各 app 商店。截至目前為止，iOS apps, Android apps, Snap apps 都上架成功了。其它還在審查。不過後端變更不大，只是修改 logo，所以即便是從商店裝舊版，前端 PWA 還是最新的。以下是 app 的各個下載連結： 商店下載：Apple…

最近又在 GitHub 練功改程式，我平常滿喜歡作這事的。GitHub 是一個程式碼存放、合作的網路服務。它上面有許多開放的程式專案，可以自由下載、追蹤、討論、修改、貢獻、編譯程式。每個人可以建立自己的帳號，儲存自己喜愛的程式專案。也可以貢獻自己的程式，GitHub 都會有記錄，小到幾行 codes 都算。 GitHub 這種服務很適合服務開放原始碼。我開發的 apps 多多少少會使用開放原始碼，由於它容易取得的特性。而且有許多高品質的開原程式，讓我能快速的開發多功能的 apps。但程式難免會有 bugs 或不合自己使用，開原的好處就是遇到 bugs 時我們較有機會查清程式哪個部分造成的，進一步小 bugs 可以自行修正，但大 bugs 往往還是要向原作者尋求協助。自行修正後，可以把它貢獻至 GitHub 幫助別人，展現自己的實力😄，這可是頗有成就感。 我尤其喜歡在 GitHub 修別人程式的 bugs，因為沒有壓力，不像工作上有時程限制、高品質要求，客戶要的功能要如期做完、不能一堆 bugs。而在 GitHub 上，就沒有那麼重的壓力，只要發覺某程式有 bug，也不必整個程式都看完（程式可能很大），用自己修改的程式能解決問題，我認為就可以貢獻給原作者。因為原作者通常會審合修改的程式，沒問題，才會合併至原程式。有時放膽去改別人程式，就可能有收獲。 我最近就成功在兩個開原程式專案 – electron-builder, AppImageLauncher 作出貢獻、被採納🙂： https://github.com/electron-userland/electron-builder/pull/6841 https://github.com/TheAssassin/AppImageLauncher/pull/510 其中在 electron-builder 的貢獻，就是放膽去改出新功能。另一個 AppImageLauncher 的貢獻是參考基於別人相關的問題研究、解決方案，提出相似的解決方案。其中在 electron-builder 的貢獻我比較得意一點，因為是提出新作法。提新作法能被接納比修正 bugs 有時難多了，一來”新作法”可能跟原系統不太合、或風格不合，可能就不被接納。但 bugs 往往就是比較客觀的東西，它的修正比較容易被接納。 總結我的參與開放原始碼開發的樂趣在於找到自己有興趣的主題、增強與展現自己的實力，又沒什麼壓力。

最近工作上接手別人寫的程式。我發現這份程式用了一個我之前不太懂的設計模式 (design pattern)，叫作相依注入 (dependency injection, DI)。由於這份程式多處使用 DI，讓我不得不先了解它，才知道這份程式要怎麼改會比較順利。 我之前就曾接觸、學習過 DI design pattern，但沒抓到其精髓（也就是不知道它的好處），所以後來也不知道怎麼用，也就忘了它。今天在 YouTube 找到一部 DI 的入門教學，那位講者舉了一個好懂的例子讓我了解 DI 的優點。 他舉的例子是汽車製造。一輛汽車由車輪、引擎、…等組成。若一家汽車組裝廠什麼都自己來、包山包海，不止組裝汽車，還製造車輪、引擎、…，這樣是有些缺點的。以組裝的彈性度來看，他們只有自家製造的東西可以選。 但如果這家汽車組裝廠改走另一種策略 – 自己不製造零件，只負責買進零件、組裝。那麼這家汽車廠就能生產更多樣的汽車。汽車的組成依賴於 (depends on) 零件，而這家工廠改變自行製造零件的策略就是解耦相依 (decouple dependencies)，而買進零件來組裝就是注入相依 (dependency injection)。 用一些程式設計的術語來說，DI 這種設計模式讓零件更抽象，零件不再是自家生產的特定型號，可以是任何一家生產的。又由於工廠不再負責零件生產，所以要新型號零件不須更動工廠，只要從外面買進來即可。 回到程式設計， DI 設計模式帶來的優點是：一支經過解耦相依的程式碼不再綁定特定相依，可以透過注入相依的方式輕易替換不同相依的實作。這對單元測試 (unit test) 很有利，我們可以把一些實際運作上很複雜的相依，在測試階段用簡單的模擬相依替代。例如要測試一支圖片讀取程式，實際運作要完整的資料庫與後端程式環境，但有了 DI，可在不更動主程式的情況下，可以寫一支簡單的模擬資料庫與後端程式作相依注入。 解耦相依帶來的另一好處就是不須更動主程式下，支援新的相依，減少主程式因為要作修改出現 bugs 的機會。這實際上的確容易遇到，比如不用 DI 寫的程式，要加入一組新功能，一種作法就是多一個 conditional block，但如果沒注意整支程式怎麼寫，舊有的 conditional blocks 可能就會對其造成不良的影響產生 bugs，也就是 – 你想加新功能的程式碼，還要看舊有功能會不會對其造成不良影響！程式碼少可能還好，程式碼一多就麻煩了！

我最近在研究網路上有哪些免費雲端資源可以學習、使用。意外發現 Oracle Cloud 有提供永久免費的虛擬主機！😄之前一直不太願意開虛擬主機，就是擔心會造成每月一筆不小的金額負擔。現在有免費的，真是讓我手癢想來架什麼 servers。 所謂永久免費是指每個月會有一定的免費雲端資源使用額度，如果超過額度還是要被收費。所以思考後，我認為能架的 server 首先不能”太吸引人”😆，再來還要對自己頗具意義。很反直覺，為什麼不能”太吸引人”？因為要吸引人其實很容易達成，例如我只要架一台 VPN server 免費給大家作跳板，就能吸引一堆人來使用，但接著而來的問題是我的虛擬主機可能資源過載或被別人拿來作非法用途，這我就麻煩了。後來我想到可以架設部落格，這對我很有意義，也滿多人這麼作的。一方面也是展現自己架站的技術能力，另一方面可以用來記錄自己的學習歷程、以後還能回來查詢。 要架站除了虛擬主機，再來就是最好有一個好記的網址/網域。我查到 eu.org 可以免費申請網域！像我申請了 mrmyh.eu.org。但後來覺得不夠滿意，想要一更短又有代表性的網域，所以我在 http://tw 找到申請網域的方法，透過域名註冊商 (domain name registrar) – 中華電信取得 myh.tw 的付費網域。我目前只租了一年台幣800元，因為抱持著試著營運這個站的心態。如果一年下來覺得還不錯，就再續約。 取得網域後，再來就要設定 DNS servers 來管理它。幸好也有免費的 DNS servers – cloudflare.com 或 dnspod.com. 設定方法先是在 DNS server provider 的管理網頁登錄網域 (domain, 如 myh.tw)，會顯示應設定的 DNS servers，把它們記下，並且新增一組 A record 將 hostname (如 www.myh.tw 或 myh.tw) 指向虛擬主機的 public IP。再到…