最近心血來潮，決定重新開始學習打從一年前就想玩玩看的 Flutter，試試看能不能做出我廢棄多年的 E-Hentai 閱讀器 for Android。
Flutter 是 Google 開發的跨平台 UI toolkit，可以同時支援 Android、iOS 和 Web，其原理就是用 canvas 來繪製所有的 UI，不需要像 React Native 一樣得在 UI 和 JavaScript engine 兩邊互相溝通而導致效能問題。
另一個優勢就是 Flutter 本身已經提供了非常完整的 UI library，無論是 Android 或 iOS 風格皆有對應的元件可直接取用，雖然有些時候可能會發現和原生的 UI 在外觀或是動畫上有些微妙的差異，但整體來說已經非常實用了。
本篇接續 Yarn 2 和 Monorepo 提到的部屬的部分，因為 monorepo 裡包含了很多套件和網站，如果直接在根目錄執行 docker build 把整個 monorepo 打包成 Docker image 的話，勢必會做出大於 1 GB 而且內含一堆無用垃圾的 Docker image；為了要讓 Docker image 能夠最小化，必須只打包正式環境會需要用到的套件，確保不會浪費任何空間和時間。
我把建構 Docker image 的步驟分為：
上週試著用 Tailwind CSS 重新打造了網誌的主題，一開始使用的時候，覺得一直翻文件很煩，因為大部分的 CSS 規則大概都知道怎麼寫，卻得要翻文件才知道對應的 class；但寫了一段時間後，開始覺得還不錯，大部分的 class 都很容易預測，也很容易根據需求客製變數或外掛。
跟 Bootstrap 或 Semantic UI 這類 UI library 相比，Tailwind CSS 不提供現成的元件（另有提供須付費的 Tailwind UI），而是把每個 CSS 規則都寫成單獨的 class，因此即便完全不寫 CSS，只要在 HTML 中設定 class，也很容易能夠拼湊出想要的樣式，但缺點就是還是需要有基本的 CSS 知識才能上手。
今年初隨著公司的 repo 越來越多，我們決定把 web 前端部分轉為 monorepo 的形式，一開始花了一段時間研究各個 monorepo 方案的利弊，最後決定基於 Yarn 2 打造一套自用的工具。這篇文章會大概分析一些我試過的 monorepo 方案的優缺點，以及最後用 Yarn 2 的成果。
本篇接續上一篇文章，是我在 Dcard 開發的第二個 Kubernetes 工具。
目前敝社的開發流程基於 GitHub flow，大致上如上圖所示。要開發新的功能時，會從主要分支 master 開出新的功能分支 feature，功能開發完成後會提出 pull request，審核通過後就會合併進 master，並部署到 staging 伺服器上。
通常在審核 pull request 時，我們僅會檢視程式碼和附帶的測試，如果一切順利而且 CI 測試通過的話，就會直接合併進 master。然而在某些情況下，特別是以前端極少測試的狀況來說，只看程式碼有時無法看出問題所在，必須實際執行才能確保程式能夠正常運作，有時也可能需要 PM 確認程式符合 spec，或是讓設計師確認程式符合設計稿。
對於工程師來說，要把程式執行起來並不困難，但對於其他人來說，光是設定環境可能就是件讓人頭痛的事了。我們常用的方法是直接讓他們透過區網或 ngrok 連到工程師的電腦上，有時甚至為了上 staging 伺服器就直接合併進 master 了。讓還沒審核通過的程式碼進入 master 不僅可能造成 staging 伺服器的異常，也有可能會影響其他工程師的開發進度。