關於 #Ruby 的內容

去年雙十一活動的時候有一個算是比較急的專案是要做活動網站，當時評估了一下之後決定來嘗試透過 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 了！

今年把在六月到八月做的一個小專案拿去投稿 Ruby World Conference 意外的獲得了 15 分鐘的時間，於是又展開了一次日本出差之旅，剛好彌補一下今年因為客戶專案需要趕上線而無法參加 RubyKaigi 的遺憾。

跟 RubyKaigi 不太一樣的地方是 Ruby World Conference 雖然叫做「World Conference」但是除了台上的講者之外，幾乎都是日本人（而且是稍微有年紀的大叔）去參加的。

寫完上篇後就開始員工旅遊、鐵人賽（從讀遊戲原始碼學做連線遊戲）反而一直都沒有時間把下篇寫完，離 COSCUP 都已經過了一個多月自己都忘記還剩什麼沒有寫在文章裡面。

中間在鐵人賽的部分花了一些時間把目前理解到關於 Unlight 的一些基本設計整理出來，後面則是實作。至於近期也已經開始在搭建 HTML5 版本的底層設計，還有 mruby 的整合（因為想提供 Mod 功能到遊戲中）等等東西都在進行中，十一月還要飛日本一趟參加 Ruby World Conference，可以說是完全都閒不下來。

總之，讓我們在來看看 COSCUP 這場演講的後續吧 XD

在 COSCUP 分享了這兩週左右（8/3 ~ 8/17）把一款決定開放原始碼的網頁遊戲，從無法啟動到恢復伺服器開始運作的一些經驗跟大家分享。 不過看起來還是有很多人沒有機會來聽，雖然之後因為會把一部分重心放在這款遊戲上，所以應該還是有不少機會，但還是簡單的來彙整一下今天講的東西。

上一篇快速閱讀 Unlight 原始碼大致上有提到了我在當時看到原始碼的看法跟概觀。有興趣的話可以搭配演講簡報一起讀這篇文章。

另外，這次整個遊戲運作起來除了我自己本身對 Ruby / ActionScript 有一定的了解外，也要感謝一下我們這個團隊（Open Unlight）的初期成員 Poka 和舞鶴，給我硬體上的支援跟對其他玩家的客服支援，不然有時候真的很難同時處理這些事情。

最近一款有點年紀的頁遊 Unlight 在停止營運後幾年，突然公佈說要開放原始碼跟圖片素材。

這款遊戲嚴格說起來並沒有像我們熟悉的端遊、手遊之類的那樣華麗，但是非常有特色的人物設計跟對戰系統倒是讓很多玩家即使在好幾年後仍然在期待他能復活。

作為一個曾經的玩家，其實也是非常期待的，不過這次的開放原始碼路線大概是復活無望。不過從這幾天公開的資料來看，圖片、音效到客戶端和伺服端都公開的狀況下，還是很有希望被熱血的玩家復活的。

另一方面，既然伺服器是透過 Ruby 撰寫的，身為使用 Ruby 的開發者在遊戲類應用不常見的狀況下，能可以作為學習素材肯定是要看過一遍的。

今年 RubyConf Taiwan 嘗試辦了 After Hack 這個活動，也因此有機會可以跟 Ruby 語言的 Commiter 聊一些有趣的問題。

當天我的預定是把活動這幾天寫的 Gem 認真的補完測試，不過沒想到還剩下一個多小時就做完了，那就順便來思考一下 Tamashii 專案能怎樣去改進，在今年的演講中大家應該都對 Fiber 有一個認識，而這個也許是一個不錯的選項。

所以就馬上去看了一下講者（Samuel）的 Async 這個 Gem 做了些什麼事情，因為剛講完關於 Enumerator 的演講，所以自然地看到了一段引起我興趣的說明。

Due to limitations within Ruby and the nature of this library, it is not possible to use to_enum on methods which invoke asynchronous behavior. We hope to fix this issue in the future.

既然作者本人就在現場，而且 Issue 的內容也看不太出來發生什麼問題，那麼就直接問吧！

跟前幾年一樣基本上就是工作人員，這幾年參加研討會也都比較沒有在仔細聽了，所以大多是邊顧邊寫點程式。

比較不一樣的大概是今年更累了，從週四下午場佈到 Pre Party 然後兩天的活動、Official Party 最後到今年嘗試的 After Hack 幾乎是四天左右的連續接力，每天早上醒來都要先懷疑自己是否能撐過這一天。

六月底的時候發現巴哈姆特似乎想為他們推出的 Messaging APP （哈哈姆特）舉辦一個聊天機器人的比賽，看到之後想說還算蠻有趣的，所以我就跟朋友很隨意的組成一個團隊來開發。

跟大多數我們熟悉串接 Chatbot 的機制是類似的，我們可以用 Webhook 的方式接收一個來自使用者發送的訊息，然後再透過程式處理後回傳訊息給使用者。

最近跟朋友弄了一個透過 Chatbot 做出手遊效果的專案，沒出什麼意外的話大概能在九月看到一個雛形。不過既然是手遊類型的遊戲，更新資料跟維護其實就會遇到一些困難點。

如果是線上遊戲或者手遊，大多數只要在公告後把玩家切斷連線然後升級過程中避免玩家連上就好。不過因為是 Chatbot 所以除非能做到不停機升級，不然是很困難的。 如此一來，讓玩家知道遊戲（機器人）正在更新，處於無法使用的狀態，就是一個重要的關鍵。