YAPC::Okinawa 2018 ONNASONに(行っ|喋っ)てきました #yapcjapan

こんばんわ、みなさんのYAPCは終わりましたか？　俺はこれを書ききったら終わるからみんなも書いてくれ！！！

というわけでYAPC::Okinawa 2018 ONNASONに行ったりトークをしてきたりしました。

yapcjapan.org

前夜祭

前夜祭は国際通りのバーのようなところで開催されました。モニタが壁の至る所にあり、結構奇妙な場所でした。

同僚の@jigyakkuma_さんがspacemacsの話をされました。おそらくneovimでめんどくさい人はワタクシだと思われます。

YAPC::Okinawa 2018 ONNASON に参加できて最高だった話 - 俺イケ！！！

あとAliCloudの話をされていた方は確かに知らない世界！！！という感じでした。中国リージョンだと強そう。というか最近中国の方がOSS界でも目立ってきたねという話を近くにいたしんぺいさんと話していました。Vue.js界隈とか。

LTでやられたきれいなコードの書き方という発表もかなり面白かったです。アプローチや雰囲気がいつかのYAPCの「草とPerl」に似ていました。

Executable Image from Tomoya Ishida

www.slideshare.net

このあとの二次会でも核戦争後の世界を想定して人里離れた今回の会場であるOISTからどのように帰るかなどの話で盛り上がりました。いや、その話をしていたのは僕だけかもしれません。

本編

朝8時に県民広場に集合して、そこからバスで向かうという感じでした。ところで周りを観察すると一般的にWebエンジニアは朝に弱いと思われますが、土砂降りの雨にも関わらず集合率が異様に高く、もしかすると遊園地に行くときだけ早起きする小学生かな？という感想を抱きました。とはいえ朝のトークも皆さん見てくれるので朝にトークする側にとってはとてもうれしいですね。

これは集合場所の県民広場です。

OISTについたあとの写真はどうせあとから公開されるだろうから撮っていませんでした。

見たトークに感想を言っていきます。スピーカーの方々の名前は敬称略です。

Webサービスを監視するときに僕達が考えたこと id:papix

Webサービスを監視するときに僕達が考えたこと / YAPC::Okinawa 2018 // Speaker Deck

個人的にベストトークです。スピーカーチケットしかなかったので投票できませんでしたが。実際世間的にも2位だったようです。

普段は外に出されにくい監視とサービス運用に関するあれこれが濃く詰まったとても秀逸なトークだと思いました。とくに「何故監視を行うのか」「何故アラートの棚卸しを行うのか」など理由とやることがセットになった話というのは僕は大好物です。なので僕がトークをしてもそのようなふうになります。

監視というのはまさに職業Webエンジニアでないと直面しない問題であり、業務で体験しないとなかなか知ることの出来ない知識なので、サービス運用をしたての新人の方などにおすすめなスライドだと思います。

障害に気づく予知能力、得たときの大小がつらくて、「夢の中で障害対応していた」とかそういう話を効くと得たくないなと思ったこともあります #yapcjapan #yapcjapanB
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

ただアラート投げるだけだと「上がってるね」「うんそうだね」となるので意味を考えられるように監視を設定する #yapcjapan #yapcjapanB
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

狼少年アラート最近困ってる！！！　けれど一部のケースで有効なアラートだからうーむともなってる！！！！ #yapcjapan #yapcjapanB
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

HTTP/2にまつわる事実と誤解 Kazuho Oku

視点と検証という感じでした。内容としてはHTTP/2とHTTP/1があるけれど、ぶっちゃけどっちが速い？というちょっと考えるだけだと「色んな要素があるよなあ」と思ってなかなか答えられないことを、様々な視点からベンチマークを行って「実際色んな要素が関わってこういうときはこっちが速くてこういうときはこっちが速いよ、あなたのお客さんはどれに当てはまるだろう？」というグレーをグレーと言い切るための手法を教えられたトークでした。僕、こういうトークも好きです。僕はモバイルがお客さんで、レイテンシも多ければパケロスも多い環境なわけですが、QUICとかだとどうなんだろうと思ったりしました。まだ真面目には調べていない。

パケロスがあるとh2が遅くなるの面白い #yapcjapan #yapcjapanA
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

Resource Timingってボトルネックがどこにあるかを知るためのものなのかーというのを初めて知った #yapcjapan #yapcjapanA
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

そろそろPerlでのHTTP/2について触れたい xaicron

そろそろPerlでのHTTP/2について触れたい // Speaker Deck

僕のトークでも言っていることなんですが、最近のプロトコルって非同期通信を多用して1本の通信路をフル活用するので、それはそれでLLにとっては厳しい環境といえるんですよね。なので出てきたAnyEventを使ったHTTP/2のコードはやはりキビシ〜ってなりました。とはいえプロトコルパーサーがあって、それが使えること自体はすごく意味があって、簡単に使えるラッパーを書いたりするのもこれで出来るんじゃないかなーと思いました。CoroとかPromisesとか使ったらもっと簡単にかけないかなとか。出来るってことで勇気がもらえたトークでした。

こういうマジックワードみたいなの、「既存のサーバがこれならぶっ壊れないだろう」という調査から生まれたという話なので、温かみを感じる #yapcjapan #yapcjapanA
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

みんな大好きAnyEvent、僕も大好き！！！（もう書きたくない #yapcjapan #yapcjapanA
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

曖昧な文脈文法となんか論理的な話 @sinya8282

ああ、はじめはパーサーとか書いたことあるでっていうノリだったんですが、だんだんわからなくなり、最後のテイラー展開でパツンとつながったという感じでした。とはいえ、パワーワードが連発してわからないけれど面白いタイプのトークで面白かったです。22の壁とか。研究者の方で話が面白いのは違反でしょうという話を後でしていました。

無曖昧に文脈自由文法は「本質的に無曖昧」随所に力を感じる文 #yapcjapan #yapcjapanA
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

High (Availability|Performance) WebSocket for Perl Real-Time Application id:mackee

ワイのトークや。後述。

Inlineモジュールの世界 id:moznion

The World of Inline Module // Speaker Deck

「Inlineモジュールは人を脅かすときなどに使える」確かに驚きました。こういう悪魔合体系のモジュールはギリギリAcmeでギリギリ実用的みたいな世界観があり、僕も曖昧になりたいと思いました。というかnumpyが早すぎるんだよな、それが違反です。libnumpyみたいなのが出てきてみんな幸せになって欲しい。moznionさんのトークはいつもどおり大変楽しめてよかったです。

初めから飛ばしているｗ #yapcjapan #yapcjapanB
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

Perl5版Inline::Goのもととなるやつです https://t.co/zs6H7rNH3r #yapcjapan #yapcjapanB
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

Perlコーディングテクニック2018 id:akiym

Perlコーディングテクニック2018 // Speaker Deck

このトークではPerlってやっぱり多様性があるなあと思いました。他の言語だとクラスの作り方が何種類もあるみたいなことはあんまりないと思うし、バリデータも選択肢がたくさんあることはあまりないかと思うんです。けれどPerlだとセンスのいい人が「これはどうだ？」と提案してそれが使われるみたいな世界観があり、人によってはどれを使えばいいんだよ！ってなるけれど、言語が提供するものではなくそれ以外の人が提案して幸せになっていくのもよいのではないかなと僕は思いました。

クラスビルダーに多様性があるのがPerl特有の面白いところだよなー #yapcjapan #yapcjapanB
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

ソースフィルタ使うともっと地獄感を味わえそう #yapcjapan #yapcjapanB
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

A bridge to my carrier by the Perl @yappo

A bridge to my carrier by the Perl

YAPCのキーノートはこういう有名な方のルーツを追えるトークで、僕は大好きです。はじめのほうは写真が気になって仕方がなかったけれど、写真がどんどん話の本筋に絡んでいくのは面白かったです。あと僕は2000年前後のインターネットをギリギリ体験した人間だと自分では思っているんですが、そのときに思った掲示板とかWebサービスを作るかっこいい人が地続きで回りにいるんだなあと思うと感慨深くなりました。

ポケコンだ #yapcjapan
— トーカナイザの守護霊 (@mackee_w) 2018年3月3日

LT

ベストトークの芹川くんは僕が連れてきて来ました。なんや！それぐらい言うてええやろ！！！　とはいえうちの会社の人は新卒氏含め口がうまいのですごいな～と思います。つまり技術ができてトークが出来るだけでは目立てないので危機感を感じました。あとKindle Oasisうらやましい。内容は。。。ごめんな、、、、なんでも聞いてくれな。。。

PPRとKeyword::Simpleの話はちょっと興味がある話題で楽しかったです。ただ、動的解析になっているので静的解析したい！！！　そのためにPPR使えんかなと思っている今日このごろです。どなたか知見を持っていませんか？

自分のトーク

speakerdeck.com

本番投入もしたし、満を持してkuiperbeltの紹介をしてやろうと意気込んでいたんですが、書いているうちに「ミドルウェアの作り方みたいな話のほうが刺さりそう」と思って方針転換してやったトークでした。皆さんいかがでしたか？

あと、WebSocketをLBに入れる入れないという議論があり、今までの前例ではLBに入れない方が多く、Twitterでも「LBに入れるのはつらそう」という意見がありました。で、僕はこのトークではWebApp側がWebSocketのサーバの管理をしたくないからという説明をしたのですが、それだと弱いのかなあと思い、会社Slackでこのトークにも出てこられたid:sfujiwaraさんに「LBなんで入れてるんでしたっけ」と質問したところ、

TLS Terminationをサーバでしたくない
- 証明書の管理とかしんどい。AWSならALB挟めばACMが使える
落ちたやつの切り離しを勝手にやってくれる
そもそもコンテナ化してポコポコ生まれはボコボコ生まれる環境ではそれぞれがインターネットにさらされるのはキツイ
- 弊社ではkuiperbeltはECS上で運用しています

などなど、現在の弊社のアーキテクチャだと必然的にLBに入れざるを得ないと言われました。

これとは別に思ったのが、僕はアプリケーションを書く人間で、fujiwaraさんはインフラをやる人間なのですが、出自が違うと同じミドルウェアであっても視点が少し違うんだなーおもしろいなあ、と思いました。

そんな感じでこのトークを聞いたりスライドを見たりして「俺はこうやっているよ」というのを是非僕に教えてほしいです。そうやって皆さんの知見を吸うために僕はトークをしているので。

あと、できればkuiperbelt、使ってみてほしいなと思います。