關於 #Ruby 的內容

中秋連假的時候想到老爸的客戶大多是稍微有年紀的長輩，過去都是慢慢教會怎麼使用 Email 來註冊系統的，但在台灣 LINE 的普及率其實非常的高，如果能用 LIFF 並且免去註冊流程的話似乎是個不錯的選擇。

目前 LINE 的 Mini App 還沒開放，因此不知道是否能獲得比 LIFF 更好的開發體驗。

最近剛好被人問到使用 Ruby on Rails 應該如何開發遊戲，因為是個很有趣的題目所以就利用週末的時間來簡單討論一下這個問題。雖然是以 Ruby on Rails 作為案例，不過這些經驗大致上是適用於所有程式語言的。

大概在 2019 年底就有考慮要來報名，結果一直拖到 2020 才下定決心。寫測試這件事情雖然很早就知道，不過一直到出社會開始工作後才逐漸的接觸，而且最開始的時候其實寫了很多糟糕的測試，直到這幾年逐漸摸索才有一個比較有系統的測試撰寫方式。

但是透過自學比較大的問題就是知識很多時候是沒有系統的，大多是碎片的形式同時我自己也不太擅長將這些東西歸納整理，也就會出現一些盲點。也因此這次參加課程主要有兩個目的，一個是看看是否適合作為公司內部訓練的選項建議老闆，另一方面就是我自己學東西的習慣，反覆的練習基礎來達到熟練一個技能。

這次第四屆的 Astro Camp 有學員嘗試做了 GitHub 的架構，也就是能夠在遠端建立 Git 專案並且能夠在本機上傳檔案。

不過在和當助教的同事跟學員聊到 git 使用者可以登入伺服器進行任意操作的安全性問題時，在前陣子的一些測試發現實際上我自己的假設（特製的 SSH Server）是有問題的，而這個解決方法實際上也比我們想像的還容易。

當我們的 Rails 專案邊複雜的時候，Form Object 算是一個常見的方法。不過網路上的教學似乎大多都沒有能夠相容 Rails 的 Form Helper 的版本。

所以我就開始思考，有沒有辦法法在比較少的修改下去支援 Form Helper 呢？

在幾年前我有一篇文章討論 Autoloading 的問題，這幾天剛好有同事在 Autoloading 和 Reloading 上也有類似的問題。

所以我決定寫一篇文章來複習 Rails 5 和 6 的 Autoloading 的機制。

因為時間的關係錯過了實體課程，不過利用 228 連假把工作上用得到的函數式程式設計這門課補完。

在 Functional Programming（函數式程式設計）裡面有許多概念是可以提取出來應用的，如果你使用的語言有支援一定程度的特性的話，就能更做出更多的變化。

包括我自己在內，寫測試有時候是一個非常不想面對的工作。也有很多剛入門的工程師覺得很難去分辨該怎麼去寫測試，在今天跟同事說明完一些技巧後就決定來寫一下這篇分享一下我自己的經驗。

去年雙十一活動的時候有一個算是比較急的專案是要做活動網站，當時評估了一下之後決定來嘗試透過 CI 自動生成 GCE 的自訂映像檔然後搭配 Auto Scale 來做部署。

會選擇這樣的方式主要是因為 Rails 或者大多數開發框架的部署工具預設大多是不適合 Auto Scale 的，像是 Capistrano 大多數是手動填入伺服器位置（之前也有實作過透過 GCP API 自動填入）比較適合雲端服務的作法其實就是是製作成一個映像檔來處理，也因此像是 Docker Image 這類型容器化技術在這方面是相對容易做的。

不過考量到容器化本身也還有一些調整問題才適合使用，再加上雲端服務的選擇是使用 GCP 來提供服務，並不像 AWS ECS 有專門針對容器的服務（可能是我不知道）而是提供 K8S 的方案，對一個短期活動來說在整個專案成員都沒有經驗的前提下學習成本還是偏高的。

因此相對適合的做法是用之前我準備好的 Ansible 腳本，搭配 Packer 這套工具直接在 GCP 上面生成一個自訂的映像檔然後直接更新 Instance Group 的設定讓他以新版本 Scale 起來，就能做到基本上網站不斷掉的更新（Health Check 和 Scale 規則需要調整好）

我們大概花了約一天多的時間快速搭起來，這次的開發時間約兩週中間是透過放額外的人力去支援搭建這個部署流程。

前陣子在嘗試一些比較少見的 Google API 時發現，在 Google 提供的 Ruby Gem 裡面並不支援這個 API 的實作，這表示需要自己去想辦法解決如何去呼叫這個 API 的問題。

不過呼叫 API 需要 Access Token 才能夠使用，以往我們都是依靠第三方套件或者 Google 官方提供的 Gem 直接呼叫，似乎很少去直接實作客戶端。另一方面我們對 OAuth2 的認識大多是做 SSO（Single Sign On）而非這種伺服器對伺服器的呼叫。

以 Google 這種規模的公司，如果是直接使用一般 OAuth2 的伺服器對伺服器的作法似乎也不太適合，而 Google 提供的解決方案就是 Service Account 了！