很高興看到台灣時間 12/5 號 Flutter 正式推出 1.0 版本，相信很多人都不知道什麼是 Flutter，簡單來說開發者只要學會 Flutter 就可以維護一套程式碼，並且同時編譯出 iOS 及 Android 手機 App，其實就跟 Facebook 推出的 React Native 一樣，但是 Flutter 的老爸是 Google。相信大家很常看到這一兩年內，蠻多新創公司相繼找 RN 工程師，而不是分別找兩位 iOS 及 Android 工程師，原因就在後續的維護性及成本。而 Flutter 也有相同好處。我個人覺得 RN 跟 Flutter 比起來，單純對入門來說，RN 是非常好上手的，但是如果您考慮到後續的維護成本，我建議選用 Flutter，雖然 Flutter 要學一套全新的語言 Dart，在初期時要學習如何使用 Widgets，把很多元件都寫成 Widgets 方便後續維護。但是在 RN 後期的維護使用了大量的第三方 Library，您想要升級一個套件可能影響到太多地方，造成不好維護。語言選擇 RN 可以使用純 JavaScript 撰寫，或者是導入 JS Flow + TypeScript 來達到 Statically Type，而 Flutter 則是使用 Dart 直接支援強型別編譯。如果現在要我選擇學 RN 或 Flutter 我肯定選擇後者。那底下來看看這次 Flutter 釋出了哪些新功能？對於 Flutter 還不了解的，可以看底下介紹影片。

在上週寫了『Drone 推出 1.0.0 RC1 版本』介紹，裡面提到一個很重要的改變，就是 Drone 現在支援『單機版』安裝了，你會問什麼是單機版安裝？以前不就是可以支援在單台機器把 Drone 給架設起來，那在 1.0.0 RC1 版本指的是什麼意思？在之前的版本，要完整的安裝完成 Drone，需要架設 drone server 及 drone agent，但是在 1.0 版本之後，只需要一個 drone 服務，裡面就內建了 server 及 agent，這很適合用在團隊非常小的狀況底下來快速安裝 drone，假設團隊專案很多，或者是成長很快，建議還是將 server 及 agent 分開架設，未來只需要擴充 agent 即可，底下來看看該如何架設單機版 drone。

終於看到 Drone 作者 bradrydzewski 在 11/7 號釋出 1.0.0-RC1 版本，此版本尚未開源在 GitHub 上面，所以目前只能透過 docker 方式來安裝。另外如果您正在用 0.8.x 版本的，不建議現在轉換到 1.0 版本，原因有幾點，第一作者尚未公開原始碼，第二現在公開也才一週而已，還有很多 bug 以及用法都沒有在線上 document 寫很清楚，第三就是作者尚未提供工具從 0.8.x 升級到 1.0.0 RC 版本。根據上述的原因，建議大家先不要轉換，當然如果團隊尚未導入 CI/CD 的話，我強烈建議使用 1.0.0 RC-1 版本。底下來看看 1.0.0 RC-1 做了哪些變動？

今年又以講者身份參加 Mopcon 南區最大研討會，此次回高雄最主要推廣 Drone 這套 CI/CD 平台。大家可以從過去的 Blog 或影片可以知道我在北部推廣了很多次 Drone 開源軟體，唯獨南台灣還沒講過，所以透過 Mopcon 研討會終於有機會可以來推廣了。本次把 Drone 的架構圖畫出來，如何架設在 Kubernetes 上以及該如何擴展 drone agent，有興趣的可以參考底下投影片:

看到這標題也許非常聳動，也可能覺得不可思議，今天來探討如何將專案直接部署到 AWS Lambda 並且自動化將 API Gateway 設定完成。當然要做到完全自動化，必須要使用一些工具才能完成，本篇將介紹由 TJ 所開發的 apex/up 工具，如果您不熟悉 EC2 也不太懂 Command line 操作，本文非常適合您，不需要管理任何 EC2 機器，也不需要在熟悉任何 Linux Command 就可以完成簡單的專案部署。首先為什麼我選擇 apex/up 而不是選擇 apex/apex，原因是使用 up 工具，您的專案是不用更動任何程式碼，就可以將專案直接執行在 AWS Lambda，那 API Gateway 部分也會一並設定完成，將所有 Request 直接 Proxy 到該 Lambda function。如果您希望對於 AWS Lambda 有更多進階操作，我會建議您用 apex/apex 或 Serverless。您可以想像使用 up 就可以將 AWS Lambda 當作小型的 EC2 服務，但是不用自己管理 EC2，現在 up 支援 Golang, Node.js, Python 或 Java 程式語言，用一行 command 就可以將專案部署到雲端了。

本篇來聊聊 Go 語言在 1.11 版本推出的 新功能，相信大家也許還不知道此功能是做什麼用的，我們來回顧看看在初學 Go 語言的時候，最令人困擾的就是 GOPATH，所有的專案都必須要在 GOPATH 底下開發，然而在更久前還沒有 Vendor 時候，兩個專案用不同版本的同一個 Package 就必須要使用多個 GOPATH 來解決，但是隨著 Vendor 在 1.5 版的推出，解決了這問題，所以現在只要把專案放在 GOPATH 底下，剩下的 Package 管理都透過 Vendor 目錄來控管，在很多大型開源專案都可以看到把 Vendor 目錄放入版本控制已經是基本的 Best Practice，而 go module 推出最大功能用來解決 GOPATH 問題，也就是未來開發專案，隨意讓開發者 clone 專案到任何地方都可以，另外也統一個 Package 套件管理，不再需要 Vendor 目錄，底下舉個實際例子來說明。

gofight 是一套用 Go 語言撰寫的 HTTP API 測試套件，之前已經寫過一篇介紹用法，當時候尚未支援檔案上傳測試，也就是假設寫了一個檔案上傳的 http handler 在專案內如何寫測試，底下來看看該如何使用。

本篇想介紹我在寫開源專案會用到的工具及服務，其實在編譯 Go 語言同時，就已經確保了一次程式碼品質，或者是在編譯之前會跑 go fmt 或 go vet 的驗證，網路上也蠻多工具可以提供更多驗證，像是：

• errcheck (檢查是否略過錯誤驗證)
• unused (檢查沒用到的 func, variable or const)
• structcheck (檢查 struct 內沒有用到的 field)
• varcheck (拿掉沒有用到的 const 變數)
• deadcode (沒有用到的程式碼)

但是這麼多驗證工具，要一一導入專案，實在有點麻煩，我自己在公司內部只有驗證 go fmt 或 go vet 或 misspell-check (驗證英文單字是否錯誤) 及 vendor-check (驗證開發者是否有去修改過 vendor 而沒有恢復修正)。如果你有在玩開源專案，其實可以不用這麼麻煩，導入兩套工具就可以讓你安心驗證別人發的 PR。底下來介紹一套工具及另外一套雲端服務。

通常在使用資料表時，都會在每一筆紀錄上面寫入當下時間，而這個時間會根據目前系統所在的時區而有所不同，當然我們都會使用 UTC+0 作為標準時區，而欄位我們則會是使用 timestamp 或者是 unix time 格式，兩者最大的差異就是在前者 (timestamp) 會根據目前系統的時區來記錄，而後者 (unix time) 則是紀錄秒數差異 (Jan 01 1970) 而不會隨著系統時區改變而變化。如果是發展開源專案，則會使用後者居多，這樣不會因為使用者時區變化，而產生不同的差異，在 Gitea 開源專案保留了兩者，但是只要計算時間則是用 (unix time) 作轉換。