Posts

編譯是靜態語言不可避免的步驟。對於開發者而言，編譯是個又愛又恨的東西，好處是他可以幫助在編譯時期找出部分的錯誤又可以幫忙最佳化，但是壞處則是編譯要時間，當專案越來越大時，小小改個檔案可能就要花數分鐘去等編譯。

source: https://xkcd.com/303/

Share storage，諸如家用 NAS 或工作站常有的網路硬碟(NFS)，是一個很方便又隨處可見的一種存儲空間，方便的點在於可以從不同機器存取或修改同樣的資料、避免需要維護重複的東西在不同的機器上；常見的使用情境像是會將 /home 家目錄放置於 Share storage 中，然後再掛載至所有工作站的機器上，這樣就可以讓使用者無論是登入哪一台工作站機器，都可以保持同樣的家目錄環境，十分方便。

CouchDB，一個主打安裝好之後就可以直接有原生 Http API 進行 CRUD (新增、讀取、修改、刪除) 的 NoSQL 資料庫，對於較簡單的應用程式甚至就直接免去後端的開發成本，直接對接 CouchDB Http API 介面即可。

除此之外，CouchDB 同時也主打所謂的 muti-master cluster 架構，可以輕易地設定多個 CouchDB instances 來達到 HA 的目的，確保服務不會因為伺服器掛掉而無法存取。

而本篇就是在記錄如何透過 Docker Swarm 來佈署跨機器的三個 CouchDB 並且將之設定為 cluster mode.

這次六月二十一日台灣正好有機會觀測到難得一見的日環食，我當然也是必不缺席，直接跑去嘉義的香湖公園餐與這次盛會。雖然我一直在腦中規劃這次該如何觀測，但實際要採購時還是太晚根本買不到巴德膜，最後只買到十個日食觀測眼鏡….慘…

而這麼小的日食觀測眼鏡也不太容易直接套在單眼相機鏡頭前，所以我最後就索性決定這次只使用我的手機拍攝，順便來實測看看用手機拍攝日食到底可不可行？

日環食時間序列，下排左一算是有拍到貝里珠。器材：Google Pixel 4 + 太陽濾鏡

敝司長久以來都是自建 Cluster 來做為日常運算資源使用的，長時間一直都被擴充性、I/O 效能所卡住，若是卡在運算資源不夠光是採買新機器動輒要幾個月；被 share storage 的 I/O 效能卡住更慘，整個系統會慢到爆 job 都卡住…
所以我就在想有沒有辦法在雲上建立這種高效能運算叢集，想動態擴張幾台就幾台，再加上我相信無論是 AWS, GCP 等等大平台所提供的 NFS 服務應該都差不到哪裡去吧…?

這陣子心血來潮花了點時間整理敝部落格的原始碼，整理的過程發現其實可以把一些小工具獨立成模組，一方面可以讓 codebase 變精簡，另一方面則是抽出來的模組也可以給其他 Hexo 使用者使用。
一開始我以為只是搬移一下程式、剪剪貼貼就可以完成，後來越做越不對勁…原來要做一個 Hexo Plugin 也是滿多地方需要注意的。
最後的成品叫做 hexo-tag-photozoom，有興趣歡迎用用看～

程式語言通常在執行的時候，為了要最佳化執行的速度，常常會利用所謂的 Early Return。^[1]
比如說條件式裡面 if (a && b) 這種判斷式，假設已經知道 A == false，那其實就可以不需要知道 b 的值，如此就可以直接忽略 b 而達到更快的知道這個判斷式是否為真^[2]。
同樣的這種作法其實會發生在很多地方，比方說像是比對兩個字串是否一樣：在很多程式語言中的實作其實就是遍歷兩個字串比對每一個字元，那只要過程中有一個字元不一樣那這兩個字串肯定就是不一樣，即可提早返回結果。

常常聽到某某遊戲外掛猖獗，作弊仔沒品、破壞遊戲樂趣等等行徑。身為一個好奇寶寶，總是很想知道其中奧秘，雖然我沒有厲害到開發出什麼外掛程式，但這幾年也陸續發現多款遊戲設計上的缺陷，成功用非正當的方式遊玩遊戲 (好含蓄…XD)。看著看著也發現其實這些遊戲的開發者理論上有辦法防止這類型的攻擊，所以只好用我不專業的見解寫下這篇文章。

對沒錯我就是奧客玩家！

本文提及的遊戲只代表曾經可以作弊，不代表現在或未來也可以。

一般的公司或者實驗室都會隔離內部資源，只留一個統一的對外出口來達到比較高的安全性以及讓系統管理者較好控管。但是較高的安全性總是會帶來不便，這種隔離內部資源的架構導致我們無法直接存取內部資源，要透過一些拐彎抹角的方式來存取。

身為一個系統管理者，時常要花時間確保系統正常運行，這時一個好的監控系統就很重要，將所有必要的資訊統整在一個畫面上一目瞭然，既能節省時間，當有問題時又能快速找出問題所在，好處多多。