前言

本次的 Ruby Conf 算是敝人遇過最大的 Ruby 研討會（其實也是參加過的第一個 Ruby Conf）。感謝主辦方的用心，連 PicCollage 的 pre-party 算在內的兩天半會程可以說是收穫滿滿。除了有機會能夠與前輩及大神講者們近距離交流討教外，還有吃有拿又得玩。這麼棒的 conf 還不知道找不找得到第二個啊！ 在這邊希望能夠透過心得記錄，留下在這次 conf 中曾經聽過的大神演講和交流過的朋友們帶給我的啟發與感動。

Pre-party

還記得抵達地點的時候約莫是 pre-party 開始約半小時的時候。在稍微觀察現場一下後，發現場內的大家似乎有些害羞，許多人好像都還待在外圍、或者是自己認識的人旁邊。而初來乍到摸不太清楚套路的我，就選擇了先在旁（填飽肚子）觀察一下大家都如何開話題認識彼此。 在請教了現場的前輩們有關身為一位新手要如何開話題的時候，大家都不約而同地說「向對方表明自己是初學者並沒有關係。反倒要好好利用自己是初學者的優勢，多多了解有經驗的開發者們在看事情時的考量」。的確，在把自己的「 conf jitter 」給甩掉後，連拿個 tortilla chips 都能夠與其他開發者交流。感謝 PicCollage ，當晚得以見到許多在其他場合認識的前輩；而較有印象的新朋友們，則有已用 Rails 開發已十年之有的 Matt ，和身形精實、著 Dreamcast T 恤的 Yuji （本次 Conf 講者之一）。整體而言 pre-party 可以說是交談熱絡，非常熱鬧。

Day 1

The Future of Ruby by “Matz” Yukihiro Matsumoto

當日的首個議程，即由 Ruby 語言之父、江湖上人稱「 Matz 」的 Yukihiro Matsumoto 所帶來。開頭即來個點破江湖謠言，如「 Ruby is dying 」或「 Ruby is slow 」等。 針對第一點， Ruby 在 TIOBE Index 中仍居高位；而對他人說 Ruby 很慢的部分更有趣了： Matz 的回應一針見血：大意是「那是他們不會寫」。Matz 並說到目前許多大型網站（如 GitHub ）背後是用 Ruby 撰寫而成。使用者們用起這些網站的服務也不會覺得它們慢。 會中 Matz 也有提到 Ruby 3 的預定發表時程（暫定於2020年12月左右推出）與更新的內容。有印象的是（也許）會將 Ruby 的型別獨立出來，放至副檔名為 .rbs 的檔案中。

Rethinking the View Layer with Components by Joel Hawksley

本議程中， Hawksley 提到了可以將 Facebook React libery 中元件的概念帶入 Rails ，及其概念是如何從實做出來的。單一功能化、依據給予的狀態而變化 HTML 的元件，除了也可以複用外，據他的說是也可以更容易地拿來做單元測試及維護。此外 Hawksley 也提供在各條件下、元件是如何比只使用傳統的 partials 渲染畫面得更快的 benchmark 數據。議程結束前，也有帶到與主題相關、他的開源計畫 ActionView::Component。

Let’s Scale Ruby Applications with Love by Bernie Chiu

鴨子聽雷； Chiu 提到開發者可以透過工具找到後端服務中常被觸及的 API endpoint 後進行分析，和該如何應用 Flame Graph 來尋找讓效能低落的 methods 。 發人省思的是 Chiu 所引用的「 average (response time) is not representational 」。的確，以一個 task 執行二十次後平均完成時間為24.5毫秒論，背後實際數據可能為5毫秒十八次，與跑了200毫秒之久的兩次。倘若開發者只採用平均執行速度做效能依據，這需要被關注的兩次就會被帳面上的24.5毫秒所掩飾住，不可不慎。

Ruby like it’s 1995 by Matias Korhonen

會想來聽這場的原因就單純覺得題目非常地有趣。 Korhonen 介紹他試著讓在 1995 年的 Ruby 0.95 版在 24 年後的今天繼續運行時，一路披荊斬棘的過程。 Event Sourcing for Everyone by Jenna Blumenthal 鴨子聽雷；對於 Rails 中的 record 因狀態轉換而造成的資料遺失， Blumenthal 所提的 Event Sourcing 可以解決這個問題。 會後的 Q & A 時間有人提問道「在何種狀況下會需要這種複雜的設計」， Blumenthal 的回答答大意如下： 「 When you think the data loss in the state changes is very important (e.g., bank account transactions) 」。

Developing Dreamcast Games with mruby by Yuji Yokoo

整場被拿著 Dreamcast （ DC ）的霸氣演講給迷住。這種「想要做什麼就自己做一個出來」的駭客精神實在是令人佩服。演講所用的軟體和結束前所展示、用 mruby 寫出來的俄羅斯方塊都可以在 Yokoo 的 GitHub 上找到。

The Journey to One Million by Samuel Williams

鴨子聽雷；怕人家以為我聽不懂，達一百萬的時候搶著一起拍手歡呼。

Day 2

Compacting GC for MRI by Aaron Patterson, a.k.a. “tenderlove”

鴨子聽雷；議程中可充分感受到 Patterson 的舞台魅力，及用心準備的投影片。 Patterson 試圖以最少的專有名詞，及最圖像化的方式展現他三年以來的心血：讓零碎的可使用記憶體變為一塊塊更大、可作更多利用的記憶體區域。 從 Enumerator 看 Ruby 的迭代器 / Decipher Ruby’s iterator with Enumerator by 蒼時弦也 鴨子聽雷。感謝蒼時會後的補充，得知了 lazy 方法可以如何地運用在日常工作情境上：

# 若有個不知道有多長的陣列需要處理（此例中為無限大）
array_of_infinity = 1..Float::INFINITY

# 透過 lazy 方法，可以（不用先將整個陣列跑過）
# 直接結束在自己想要停的地方（ .first(5) ）
array_of_infinity.lazy.select { |num| num * 2 }.first(5)
#=> [2, 4, 6, 8, 10]

後來發現五倍紅寶石的專欄文章「與你每天擦身而過的 Enumerator 」中，也有類似內容可以供研究。

開拓者們建立鐵道的辛酸血淚史 Building Rails with Trailblazer, The Good, Bad and Ugly by Wen-Chuan Lin

Lin 分享了他的團隊從將產品的 Online App Form 從 Rails 轉到 Trailblazer (TRB) 上的心路歷程、分析了 TRB 之於 Rails 的優缺點，和 TRB 的 concept 如何地幫助團隊把產品架構變得更有彈性。假設專案有一需求，需要將 form 的 create 與 update 分別做驗證不同的欄位，和 Rails 相較， Lin 指出 TRB 可以更輕鬆地做到將兩者驗證方式分開。 結束前 Lin 也給了一些有關導入技術時，以欲解決的問題為導向（問「導入一特定的技術是要解決什麼樣的問題？」）和團隊支持（透過討論、 code review 、 pair programming 等）的重要。

Suit up for frontend and backend development by Tse-Ching Ho

鴨子聽雷； Ho 提到了好的後端 API 就是要前端要什麼、給什麼，後端都能夠做出相對應的處理。議程的內容除了介紹前後端分離對於網站開發的好處外，多圍繞在如何透過 Ruby 物件中引入的 gem 設計出好用的 API 。

Using AWS Lambda with Ruby on a large-scale system by Luka Huang

Huang 介紹了大型網站系統的架構、所遇到的困難及解決方案（ Redis 、 AWS Lambda 等）。頭一次看到別人的服務架構，覺得新鮮。 What’s new in Rails 6? by Vipul A M 由於議程時間長度因素， Vipul 僅介紹了 Rails 6 中一些重大的改變。

心得

身為一位初入程式圈的開發者，一開始給自己「要努力聽懂全部議程的內容」的目標實在是有點太不切實際了。而事實上每個議程也是有許多聽不懂的東西，只能透過關鍵字來查詢來想辦法跟上講者內容的節奏。 回顧兩天來的參與，發現到自己雖然還有許多自己不理解的部分，但是每一場議程與每一次的交流，總會有些理性或感性的啟發可以帶回去，已可謂寫 code 最佳精神食糧。