YAPC::Kyoto 2023 的參與，以及京都短行

這次 YAPC::Kyoto 2023 的實體聚會應該是 Perl 社群最想參加的一次聚會了。原本預計是在 2020 年三月舉辦的，但因為當時 COVID-19 傳染狀況的關係不得不取 消。就算沒有取消，大概實際上也不會有人要去。而就過了這麼三年，所有研討 會不得不降級為只有線上舉辦，讓大家透過群組視訊會議與線上文字聊天室來模 擬實體聚會。

主催者 papix 一直把此事定調為延期，而不是取消。除了個人堅持之外，原來也與其公司（はてな）是在京都リサーチパーク（京都研究園區）創業這一點有直接的關聯。這點倒是在聽完了最後的主講之後才明瞭的。

京都研究園區是此次研討會場地的所在。這園區內共有十五棟大樓，有辦公用也有活動用。其地點離京都水族館不遠，但是是一個觀光客不太會停留的地區。園區內有辦活動專用的場地，雖然並不像中研院那麼大規模，但教室大小適中，動線容易理解，也有很大間的，適合全員聚集的地方。

我稍微早到了一些而目睹了工作人員仍在準備的狀況，因此先在場地附近隨意散步了一下。再回報到處時不小心從舞台後面走出來了。正好碰到 papix 在佈置 Perl 神社而搭了幾句話。

<

這神社就是一個鳥居、一個小賽錢箱、跟御神體：一本日文版《Perl 學習手冊》。賽錢箱所募得的款，會被捐給 Perl 基金會。

哦，去年是讓 perlbrew 成為酒標，今年是要讓 Perl 成為宗教了嗎。我當下這突然這麼想。元是技術、先是商品化、再是宗教化。很會哦。不過，這三件事其實也不一定是那麼壁壘分明的。

Perl 本體的宗教感一直都是存在著的。像是 Perl5 內製造物件的關鍵字是為 bless 而不是 new 的這一點，就使其獨一無二。bless 語意是「祝福」，若要讓宗教感強一些的話或許可用「加護」來表意。（雖然這邊把佛教用語用在天主教情境下了，但請讓我在此模糊一點。）

my $it = { "name" => "Learning Perl" };
my $obj = bless $it, 'Book';

普通變數在接受加護過後，就會成爲物件。

這大概就是 Perl 本體內宗教感的來源了。

不過大部分 OO framework 模組為了迎合流行，又各自將建立物件的方法名稱定為 new，日常寫程式時倒是沒有一直在施法加護的心情。

這次倒沒有甚麼人再度發表新的 OO Framework，不過值得一提的是 perl 5.37 已經開始內建 class 關鍵字，可用來定義類別與物件。並且絕贊更新中。可能會有一些人覺得 perl5 的物件導向支援太原始、而這 class 關鍵字來得太遲了。但是在很多時候，遲到總比沒到好（Better late than never.），或許這就是那種時候。在物件導向系統完善了之後，或許接下來可以期待型別系統、多重分派等等更有利與效能的子系統出現在 Perl 中了。這麼一來或許 Perl 又會與 Raku 稍微接近了一些。

在報到處領到研討會手提袋跟一整袋贈品後稍微看了一下，發現這次的幾年 T 恤設計很簡單明瞭。正面「you bless it」一句話。圈外的人大概會覺得這顯然是件意義不明的怪 T 恤。但社群內的人就能知道 bless 這個的特殊意義而在臉上露出會心一笑。

如果在程式碼內到處都是 bless 會不會讓人有在施法的感覺這我是不太知道了，不過另外一點會讓 Perl 程式變得好像在施法的就是內建在語言中的正規表示式引擎了。

例如 dankogai 這次發表的演講標題爲：

my$talk=qr{\b((?:ir)?reg(?:ular )?exp(?:ressions?)?)\b}ig; 

據本人說，他也不知道要怎麼把這個標題用嘴巴說出來。

確實，在程式內有很多正規表示式的時候，程式碼會變得很難唸，而對於像我這種依賴聲音來記憶的人來說，唸不出來的文字就比較不好記。或許哪天開始我該擅自把正規表示式內內各記號對應到口腔內各發聲部位，賦予其音素，然後試着唱出來。說不定會很有趣。

與 Perl 神社稍微有點距離的贊助廠商攤位區內可以抽運勢籤，由面白法人這個長期贊助商提供。我當日的運勢是小吉。其中關於「移管」的部分的內容是 undef。這真是有趣。

字面上 undef 是表示無值，但在搜尋系的 API 中有時侯會被拿來當作是「沒有、隨便、都可以」這幾種意義。在更新 (PUT / PATCH）系的 API 內又可代表要將部分內容刪除的意義。與 0、1 一樣，是十分有用的一個關鍵字。但這籤怎麼解？

Perl 神社內沒有神職人員可以問，但如果是我自己擅自解釋的話，我會說：Whatever | Mu。

當天在 Twitter 上看到有人抽到了運勢全是 undef 的籤。完全是超越大吉的籤種，真是令人羨慕。

於主會場找個好位置坐下後，立刻就碰到了 charsbar 與 skaji，也將 dankogai 的演講完整聽完了。中午過後又碰到了 miyagawa。常見的狠角色通通都到了。稍微問候幾句之後，也立刻讓人覺得：現在能這樣面對面的 跟這些人簡單講幾句話，還真是難得啊。

看時刻表發現午餐時段內有堂奇妙的課可以聽，領了便當進去教室坐下後發現講臺上是幾位今出川.FM 在做 Podcast 節目的人在錄音。在座位上吃便當的同時可以用聽廣播節目的心情來邊聽邊吃，同時還可以透過 slido 發問題給他們回答。這真是有趣的一段經驗。可以給還有在辦研討會跟還有在做 Podcast 節目的人參考參考。

除了去參加研討會，這次也趁著有春分之日請了連假在京都觀光了幾天。但也沒有安排行程細節，只有幾件想做的事。如果天氣好就外出，如果天氣不好就再找看看有沒有好備案。很幸運的，天氣基本上還不錯。先花了一個早上去稻荷山上走了一整圈，就是千本鳥居的那座山。當然，那裡是個人氣旺盛的觀光地區，觀光客人數真是多。鳥居底下人多的狀況就像站滿人的電扶梯。大家都只能慢慢地往前方移動，沒有辦法在半途離開。當然，越往山上走，人就越少。

走上稻荷山山頂並不是太困難的。雖然有十分多樓梯階段，但基本上走走停停也一下子就到了。山頂附近有三群神社叢集，或者應該說整座稻荷山上其實大大小小有十來群神社叢集。要全部仔細看完的話還真的是要不少時間。在山頂區發現了這樣的一個看板：

顯然是在有太多人會跑去問神社旁邊的小賣店「這裡就是山頂了吧？」這種基本問題而讓店家不勝其煩。只好明確設下阻擋規則：問其他問題可以，問這個問題不行。

由 kazeburo 所分享的〈DNS権威サービスへのDDoSとハイパフォーマンスなベンチマーカ〉是關於 DNS random subdomain attack -- 基本上就是如果有很多人來查詢 xx1.example.com, xx2.example.com, xx3.example.com... 等以一大堆隨機生成的名稱，那麼 DNS 伺服器要不就是會因爲頻寬被這些噪音佔去而讓服務品質降低，要不就是會因爲軟體內的熱騰騰的快取內容被一堆路人甲乙丙丁擠走了而變是快取失準。真的要遇到這種類型攻擊時，如果祭出類似「來問 *.example.com 的一律當作沒看到」這種太廣泛的阻擋規則的話，又相當於是自己把自己的服務給廢了。因此不是很容易處理。似乎就是得讓改寫 DNS 伺服器軟體本身的演算法，讓「查無此處」變成是最快的途徑。

上稻荷山山頂前的四達路口顯然是聚集了最多人的地方。所有還想往上走的人都必定會經過那裡、或許休息一下。所有已經不想再往上走的人也必定會在那裡休息到體力回復了為止。當天早上在耳邊通過最多的語言是西班牙語。厲害啊，西班牙語。

這幾年的 yapcjapan 研討會的議程幾乎全是日語的，幾乎沒有任何以非日語發表的議程。不過這次有位遠道而來的講者 nugged 他主要是來替八月份辦在赫爾辛基的 YAPC::Eurpoe -- Perl + Koha Conference 宣傳的。據他所言，Koha 是一套廣爲使用的圖書館管理系統，而這次研討會將會辦在圖書館內。看來這顯然會是一次非常獨特的、能讓人旅行兼充電的研討會。

河原町與四条一帶也是一個很容易讓人充電的地方。那一帶能讓客人充電的連鎖咖啡店很多，各種大小商店也很多、很好逛。最近 幾次到京都都會在 Holly's Cafe 充電。這次也是利用了這間連鎖店提供的電源服務。其實這連鎖店的飲食方面沒有甚麼太特殊的地方，不好不壞，只是通常其分店內都設有爲數不少的電源插座，店面本身不小。對於有此需要的客人來說 資源充足，比較不會讓人去了纔發現因客滿而沒有插座可用。也就是說這連鎖店的電源服務的可用性程度很高（High Availabality）。

而說起來像神社這種場所的可用性程度也算是很高了。對於幾類到場「客戶」 （參拜者），只要將神社境內幾項伺服器維護妥當便可讓參拜者自行服務，例如： 鳥居與參道、淨手、抽運勢籤、托願於繪馬、參拜（許願）、賽錢。基本上只要各項硬體設施沒有損壞，就可以 同時滿足大量客戶來訪，是可用性程度很高的。

只是也有例如：求御守、求御朱印、問事、求加護。這類服務內容需要神職人員來真人服務，無法輕易地規模化，可用性的程度也就受到服務者人數限制。而就算是無需人類提供服務的伺服器，在來客數很多時，也是無法同時滿足所有客人的要求。參拜者必須當場自行協調、等候。也就是在來客數多時，必會有排隊情況發生。

在神社系統內要解決排隊問題，就是要把空地騰出來，提供座位區讓人坐着等。或許這就是爲何各設施之間不會離得太近的原因。又或者，若像淺草神社那般人氣旺盛者，偶爾得把筆直的參道全部分配給排隊人潮來用。

而軟體系統內排隊除了要有空地（臨時的儲存空間）之外，還必須要有某些機制來確保隊伍整體有在向前行進，隊伍最前端的客戶能立刻被處理、處理次序先後必須依照特定規則等等。無論隊伍內容是連線、網址、背景工作。都是類似的問題。

這次正好聽到 GMO 公司的 SRE 在分享他們把工作佇列（Job Queue） 改爲 fireworq 的事情。他們一直在使用 TheSchwartz，卻感到諸多不便處而改用 fireworq。兩者分派工作的模式不同，各有優缺點。但看來 fireworq 有個獨特的優點是它本身是個 HTTP JSON API 形式的伺服器，只是負責處理排隊事宜（或者說：讓人抽號碼牌、叫號），不處理實際工作內容。因此它能夠配合任何既有系統內來使用，所有程式語言皆可。實際上負責工作的函式則必須要能以 HTTP JSON API 的形式來接受工作之外，最好亦必須爲冪等實做（Idempotent by implementation），也就是說：同樣的工作重複多次進行也不應對系統造成任何衝擊。

初步聽起來，如果有將系統一部分從 A 語言改寫成 B 語言的需求的話，或許也可以透過 fireworq 的使用，讓轉移稍微容易一些。又或者是在資源調配方面，由於實際上進行工作的伺服器也是 HTTP 伺服器，對於已經有維護 HTTP 伺服器的人員而言，所有調配資源的慣例或操作步驟皆可通用。

這麼說來 Holly's Cafe 等咖啡連鎖店需要人員的服務就是最開始的點餐與結帳。事實上幾乎所有連鎖咖啡店都是讓客人一開始就把點餐、結帳兩個步驟完成。一間店多半設置了兩個點餐臺可以做負載平衡，在服務人員配置比較少的店面則是連取餐都同步完成了。所有服務作業都是在前景（客人面前）完成。雖然要讓客人等一下，但既然在人力工作資源有限時無法分配任何人去做背景作業，也就是讓客人先拿個號碼牌走而幾分鐘後再由店員將商品送上，那讓所有要求同步完成，亦不失爲一個好辦法。

稻荷山上的千本鳥居其實一座一座上都刻寫了神社贊助者的大名。看來是一般公司行號（或個人）在捐了款之後便能立座掛名的鳥居。從山頂上下來時，可看到玲琅滿目的贊助商大名以及起立年份。有點令人意外的是，其實大部分的鳥居都頂新的，最近十年內年左右立起來的似乎佔了大多數。超過十年以上的就不太常見了。不過我所注意到最老的一座是大正五年（1916）的，而且看來是混凝土之類的材質，不是木造的。不知還有沒有更早的。

一般在稍有規模的神社建地內，除了各種服務參拜者的硬體設備之外，也有類似的工商服務設備，基本上都是各種形式的捐款者名錄。雖然不一定會像千本鳥居這麼遠近馳名，例如文字看板、燈籠陣列等等。雖然大小醒目程度不同，但都是要將捐款者大名清清楚楚地顯示出來給參拜者看而設置的硬體。這類掛名讓人看的做法似乎由來已久，替神社這種宗教感滿點的場所混入了一些些商業氣息。亦如教堂與市集、廟口與夜市，在宗教設施附近，商業與宗教兩者總是處於一種互相廣告、互相依賴的關係。既然一直有人會到神社來參拜，那神社就是一個能夠提升知名度的地方。是不是有點像「入口網站」呢？

正如同神社參拜者在登堂參拜之前就會看到各種形式的贊助者列表，YAPC 與會者們在進入場地的同時也會開始接觸到贊助商的大名。日本這裡辦的 YAPC 研討會，是自一開始就十分重視贊助商的曝光度的。贊助商除了能在走廊擺攤，其大名會出現在網站上、在於報告出領到的手提袋內、在講臺後方的背景看板上、在大講堂螢幕兩邊掛着的布條上、在議程表上、以及各教室的名稱、還會被主辦者在謝幕之前口頭逐一點名致謝。有這麼多時機能讓讓贊助商大名曝光。而所有與會者，既是「消費者」（使用 Perl / CPAN 的人），也是「經營者」（製造 CPAN 模組、開源專案、貢獻給 Perl 生態系的人）；藉由參與研討會，還是「Perl 宗教感」的起立者、贊助者。在這層表現上，年年在世界各地舉辦 YAPC 似乎就像是種「Pop-up 神社」之類的，讓人來大拜拜的地方。而這次研討會 T 恤上的「you bless it」這句話似乎正好替這種種宗教活動感給總結了。或許這種像是魚幫水、水幫魚的方式，就是一種能使其規模向上提升、讓系統容量更大的方式。

GMO 公司 SRE @rsym1290 所發表的〈 4PB(ペタバイト)を超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ 〉，是關於他們製作的 Bayt，這是在 API 層相容於 S3、底層爲 MogileFS、目前容量約爲 4PB 網路儲存伺服器。這項服務是提供給 GMO 公司內部各專案使用的，也因此有此規模，實際上在費用使用彈性方面也比 AWS S3 更好一些。也提到最近版半導體短缺的狀況，實際上也影響到了他們日常硬碟淘汰換新作業。普通約兩個月可以到貨的新硬碟，變成要等六到十二個月這種極爲不安定的日期。

在 YAPC::Asia 2007 時，Brad Fitzpatrick 曾經分享過讓 LiveJournal 系統能規模化的建構方式（主要是談 mysql）。當時他也提到，爲了將系統規模化，他做了 Gearman (分散式工作排程)、MogileFS （網路儲存系統）、memcached （網路快取服務）、以及當時才剛開始做的 TheSchwartz （工作佇列）。Gearman 這名字是取自於 "Manager" 這個單字的易位構詞（anagram），而 MogileFS 這名字則是取自於 "OMG Files" 的易位構詞。不過，他當初沒有提到 "TheSchwartz" 和 "memcached" 是甚麼其他詞彙的易位構詞（笑）。

隨着系統的規模化，部件與模組越添越多，能故障的地方也就會越來越多。如果平時都系統架構沒有一定的熟悉度，也未必對應得來。雖然有不少問題可以藉由退到舊版來解決，但也有很多狀況是與新版的釋出並無直接相關，而是在架構中有什麼地方壞了。什麼地方容量不夠了。若是不知道架構中有哪些模組、彼此之間是如何相連、那顯然就沒辦法仔細找出問題的根源。只能夠暫時迂迴、避開會讓問題發生的路徑。好比這間點餐機壞掉的麵店：

店內的店員、廚師、店長都沒有人知道該如何修理那台故障的機器，但店員仍然能用老方法以口頭接待、把訂單記在紙上、以訂單出餐、按計算機計算總額之類的。來順利完成經營麵店所該做的工作流程。

有幾位講者分享了與錯誤處理、故障對應相關的主題。分別是ryuichi_1208 的〈入門障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワトソン君」〉、以及sadnessOjisan 的〈my new error...〉。都是能讓我有所借鏡的主題。特別是關於故障對應的部分。講者提到平時的「演習」很重要，這部分特被有有同感。各個專案都應該在故障對應是順便做一份實戰手冊，讓未來的組員們能夠依照手冊內容來快速判斷那些時候該做什麼操作。同時也可以依照手冊來做練習。平常開發是得程式碼中四處加入妥善的錯誤處理與記錄，隨時翻翻記錄也能有助於在有大規模故障是能快速動作。 一件一件都是需要練習的事情。總不能只因爲點餐機秀逗，就讓客人喫不到麵吧？

Helpfeel 公司的 niboshi 所分享的〈"普通"のWebアプリでWASMを活用する〉似乎值得參考。主要大意爲他們有許多文字資料需要同時在伺服器段與網頁段解析，爲了避免維護兩套不同語言版本解析器而試著選用 WASM 看看。目前階段是使用 Rust 實做解析器，並編爲 .wasm 讓 python 與瀏覽器 javascript 來使用。

雖然是一段還在摸索的過程，但這種實例正好符合 WASM 的強處。似乎值得探索看看。

在研討會開幕時，螢幕上播放了一段影片。內容是兩位主辦者在法輪寺內求加護，神職人員(*)以特有聲調唸著像是經文的一段話，但仔細一聽是「願 YAPC 舉辦順利」之類的內容，而加護對象是一本書。也就是放在 Perl 神社內的那本《Perl 學習手冊》。這本書在閉幕時，以「學生應援」的名義，贈送給了某位學生。賽錢箱最後募得了一萬四千餘元，而御神體竟然是做爲贈品送出去了，這真是一段不錯的始末。

(*): 我無法從服裝判斷唸經者的職階，只好用這種通用名詞來代稱了。

在旅行最後一日，我也到了法輪寺去簡單參拜一下，我參拜的對象是寺內的電電宮。並且求得了「電電宮御守」與「情報守護」（貼紙）兩項物品。願：半導體能自短缺狀態逐漸恢復，人人有硬碟跟 GPU 可買，bcrypt 回數節節高昇，密文密得不得了。

依照這次場地地點，我選擇了一間位於下京區靠中京區的飯店。下京區與中京區這一帶有很多小巷可以探索，三条商店街也是個好逛的地方。雖然附近就有世界遺產二条城，但寧靜的巷內街景在我眼裡也是一樣出色。這一區的房子尚比較矮小，也還沒有被改建爲大規模的高樓。但從偶爾出現的工地來看，或許接下來也會面臨都市更新吧，屆時風景必然會有顯著改變，趁現在多多拍些照片吧。

在春分之日早上，我還是到二条城內去看看庭園、看看御殿。這市區內的世界遺產果然是值得一看。中午時偶然碰到「さくらパレード」這個由關西各校吹奏樂部聯合參加的遊行活動。事前並不知道，是碰巧路過京都市役所時聽到樂聲、調查了一下纔知道是個年年有辦的活動，但過去幾年因 COVID-19 流行而中止。

也正好因爲我完全沒有任何行程與計劃，看到這個遊行活動，就當下決定依照其時間來看遊行。橘高校是遊行的壓軸，但其他如島根県立出雲商業高等学校、兵庫県滝川第二高等学校、都是實力不相上下的。整段遊行看下來很過癮，也感受到了人情與活力。雖然是碰巧，但沒有預約任何行程而可以隨意即使調整，真是太好了。

無巧不書。這次的 YAPC::Kyoto 主講者 yasuhiro_onishi 與最佳演講得獎者 ar_tama 兩人都在臺上講到，十幾年前某年參加 YAPC::Asia 時忘了帶票去而在報告處讓主辦者通融一下而得以繼續參與研討會活動。這顯然是參與一般研討會是碰不到的人情表現。YAPC 研討會的主辦者也全都是 Perl 社群生態系內的人，才知道在當下通融放人入場並不是甚麼壞事。畢竟大部分的神社參拜者也都是只帶著誠意空手而去的。偶爾通融放沒有持票的人入場，也其實有助於社群的活絡與成長。而且說不定他們就會在幾年之後的研討會講臺上感謝當年的主辦者了。

某種意義上 YAPC 似乎也就像是さくらパレード那種聯合多間學校舉辦的遊行活動一樣。YAPC 就是由多個 Perl 社群撐起來的一種草根研討會。當然通常還是由幾個主辦人張羅所有事情，但來自各處的小社群、Perl Mongers、也各自出力。像是在午餐時間錄 Podcast 的、或是把現場講臺直播出去的、或是像這個其他房間直播「裏 Talk」的這個 大井町.PM 也是替 yapcjapan 出了很多力的社群。而且他們還做了一支很有某節目閒扯淡風格的贊助商影片。看來似乎毫無重點。不過有時候社群就是這樣，在很輕鬆的時間裡面讓一些甚麼和事情能夠推進一些。

如果真要爲本文做個像樣的結論的話，那麼：各位研討會主辦者啊，如果有人說他忘了帶票，千萬不要對他太嚴格喔。或許十年後會變成一段佳話呢。