AD(Active Directory) 是微軟的權限管理體系，大型企業常常使用 AD 來做權限的管理。我們如果可以跟 AD 介接，那麼企業在成為我們客戶的同時，還能夠自行管理企業內部員工的帳號權限。本次分享，將介紹 Rails 如何使用 SAML 協定，整合企業的 AD、ADFS 與 Azure AD。

Collaborative notes on HackMD

工作上專案的需求需要不停從交易所抓即時資料回來，這時候我們選用了公司同事本來就已經寫好的 gem mcoin 來解決我們這方面的需求，為了能夠了解他到底做了什麼事而看了程式碼卻發現........ 頭腦壓根沒有 thread 這個概念。
我希望能夠讓像我一樣沒有這些概念，但是想成為，或是已經成為菜鳥工程師的人能夠減少我在碰到這一塊的時候的滿頭問號，而且知道在 ruby 中要如何應用。
以下是主要內容：
Thread 的存在意義。
為什麼要用到 queue。
為什麼要讓 thread sleep。
並行和並列的差別。
現在電腦速度那麼快，真的會有差別嗎?

Collaborative notes on HackMD

Ruby 是一個已經 25 歲的程式語言，雖然很多人說 Ruby 已死，但事實上它還是目前世界排名前 20 名的程式語言。

從開始學習寫程式到現在，不知不覺已經 20 年了，在這 20 年中曾使用過許多款程式語言。在 2008 年開始接觸 Ruby 這個可愛且有趣的程式語言，並使用它工作到現在。

想要成為資深的 Ruby 工程師，並不是隨著年紀變大就會變資深，而是要有方法並且正確地在同一條路上持續耕耘。我將會分享對於學習 Ruby on Rails 但卻總只是停留在 CRUD 階段的新手一些建議，同時也會分享我使用 Ruby 這個程式語言 10 年來，對我在思考程式設計的改變。

Collaborative notes on HackMD

這年頭開發網站很幸福，遇到需要改善 performance 時有很多方便的第三方服務能幫助你。以 Ruby on Rails 來說可以用的服務像是 NewRelic、Skylight、Scout 等等，很容易幫你調查出是不是有哪些 request 有效能問題。

這些服務雖然很好用，但是大多是專注在調用 database query 上的分析，大部分服務沒辦法詳細分析非 database 造成的瓶頸，當你遇到效能瓶頸是在程式碼純運算層面時，通常沒有辦法給你太多幫助，而這時候就是火焰圖能夠幫助你的時候了！

本議程將會介紹火焰圖能夠在什麼情境之下幫助你，以及介紹如何解讀火焰圖的結果來協助找出程式的效能瓶頸。

註：本議程有部分內容利用 Ruby 解說示範，但大部分的程式語言都可以利用火焰圖分析，概念完全通用，非 Ruby 開發者也適用。

Collaborative notes on HackMD

除了用 ruby -v 來檢查版本之外， 你曾經在 command line 直接執行過 Ruby 嗎?

Ruby 作為 Perl 的接班人，延續了許多好用的 command line 功能。 像是方便的讀取檔案，各種實用的預設變數，不用檔案直接執行程式碼。 讓我們一起來探索各種鮮為人知的 Ruby 功能。

Collaborative notes on HackMD

The Tamashii project provides framework to building IoT application, but we are limited by their tamashii-agent gem. But Tamashii Component, a framework which provides abstract interface let us can craft agent by add gem into our project. For example, Tamashii Component allows users to add IoT component gem directly (eg. tamashii-led) and control led via our Tamashii Component interface. This change the way we use Tamashii, and more flexible compose any devices when we use it.

In this talk, I’ll explain why we use Tamashii and how Tamashii Component are working to solves the above mentioned problems.

Collaborative notes on HackMD

很簡單的原理（30min）

如果你是一個網站開發者，其實已經掌握了必要的條件。日系的卡牌手遊跟過去我們熟悉的線上遊戲不太一樣的地方，主要是在於不需要保持連線，以及玩家的即時互動。

所以，開發一個日系卡牌手遊主要就會落在兩個重點上。

• API 伺服器
• 遊戲端的表演

使用 Ruby on Rails 來開發手遊是一個不錯的選擇，必要的功能都已經具備，只需要透過實作將想要設計的手遊製作出來。

接下來我們會實作手遊的登入、抽卡跟任務關卡。

搭建 OAuth 伺服器（60min）

如果有 App 開發經驗的話，可能會知道使用 OAuth 算是一個不錯的選擇。而常被跟 Unity3D 搭配來開發一些簡易的手遊伺服端功能的 FireBase 服務，也是採用 OAuth 的方式。

所以，我們要先使用 Ruby on Rails 的 OAuth 伺服器套件 Doorkeeper 設定一個提供給手遊玩家的 OAuth 伺服器，讓玩家可以將手機跟帳號連結起來。不過大多數時候，手遊的 OAuth 伺服器其實是有特殊修改過的，因為相較於一般網站使用帳號密碼登入，手遊大多會直接幫玩家生成帳號後，再透過紀錄手機的 UUID 來綁定帳號。

也就是說，登入流程會變成：

• （第一次）生成帳號，回傳帳號跟密碼（引繼碼）
• 透過帳號跟 UUID 產生 Access Token
• 使用 Access Token 在這次的遊戲中進行

以上只是給出一種情況，實際上還有很多細節或者不同的方式可以採用。

完成上述的機制之後，客戶端只需要負責安全的保存帳號、密碼跟 Access Token 就可以正常的運行。

實作：

• OAuth2 伺服器搭建 / 管理
• Unity3D 實作登入遊戲

設計抽卡 API （60min）

身為一個卡牌遊戲，怎麼能少掉抽卡呢！當我們可以順利登入遊戲後，最重要的就是讓玩家可以課金抽卡。不過串接 IAP 之類的事情會花上不少時間，所以我們就先專注在抽卡上吧！

為了確保遊戲的公平性，所以我們要將所有的抽卡過程都在伺服器上實作，玩家只能發出「抽卡」的要求，然後伺服器回應一個「結果」到玩家端身上。

不過跟網頁伺服器不一樣的事，我們不可能每次都將遊戲美術都下載一次。所以我們需要在遊戲開始前先做好素材檔案的打包，在玩家開始遊戲的時候預先的下載好卡片圖檔，而伺服器只需要回應對應的圖片路徑即可。

實作：

• 卡池、抽卡
• Unity3D 選擇卡池跟顯示抽卡結果
• 素材包概念（AssetBundle）

設計任務 API （60min）

跟抽卡差不多，只是實作另一種變化型跟示範簡易的防作弊（拒絕同時進行多個任務）

總結（30min）

到此為止，我們已經對如何設計一個卡牌遊戲有粗略地理解。不過在手遊開發上還是有不少地方需要注意，像是玩家大量增加後該如何透過 Sharding 的技巧改善遊戲可容納的玩家數量。跟一般網站不同的是玩家的操作都會造成寫入，要如何盡可能的有效設計 API 跟機制來減少伺服器的消耗，都會是之後需要考慮的課題。

Collaborative notes on HackMD