今年もYAPC::Asia Tokyo 2015に参加してきました (3年目、個人スポンサとして2年目)。
ブログを書くまでがYAPCということで、印象的だったトークの感想などを書き残します。 記録として残そうとすると、ですます調で書きにくいなと感じたため、固い感じになってます。 間違いがあったらツッコミお願いします。 (個人的なメモにもなっているので、カッコ書きが多く、読みにくいかもしれない)
前夜祭
前夜祭では次の発表を見た:
言語開発の現場
Ruby メンテナであり、弊社チーフエンジニアでもある柴田さんの発表。
Ruby という言語がどのように開発されているかという、ソフトウェア開発にまつわる話だった。 意思決定や実装、リリースに至る一連のサイクルについて、見えにくい部分がどうなっているのか知ることが出来た。 かつて柴田さんから聞いた話もあったけど、まとまって聞くのは新鮮だった。
Ruby 1.8 と 1.9 では実装が異なり、それぞれ MRI (CRuby/MRI という表現も見かけた1) と YARV と言う。 この違いを説明するほど理解できてないので、詳しくは『Rubyのしくみ -Ruby Under a Microscope-』を。 今まで、Rubinius や JRuby と区別するために MRI と言っていたが、Ruby 1.9 以降を考慮すると、CRuby と表記したほうが良さそう。
スライド No.13-14 は特に興味深かった。 まず、CRuby (のコミッタ?)から見える “Ruby” がある。 一方、Rubinius や JRuby から見た “Ruby” もある。 (この微妙な違いは文字に書き起こしにくいので、ぜひ動画を見てほしい。) この「見え方」の違いによって、時々揉め事を呼んでしまうらしい。 Ruby コミッタにとっては頭の痛い問題なのだろうけれど、Ruby が楽しく、自由だからこその(副)産物のように思えた(良い意味でも悪い意味でも)。
感想としては、やはり Ruby は OSS で、OSX や Linux, Windows といった多くのプラットフォームで動くことは「当然」ではなく、多くのメンテナのおかげで成り立っているということ。 もちろん、当たり前のように動くことを目指しているだろうけど、私の言いたいこととしては、チャンスがあればコントリビュートだということである。
技術ブログを書くことについて語るときに僕の語ること
ゆううき君 の書いたブログ記事はこちら(資料は公開しないそうです):
自分に影響を与えてくれた恩人は多いが、ゆううき君のブログに対するスタンスにはとりわけ強く影響を受けている。 以下の新卒エンジニア研修に関する記事は特にその影響を受けている、と思っている。 (「どこが?」と思われるかもしれないが)
ブログ記事に書かれた以下の文章もグッと来る。
… OSとかアーキテクチャの話は数年後、がんばれば10年後にも読める内容になるのではないかと思います。 話題に限らず自己表現の場だと思って記事書くと、人間は数年でかわったりしたりないと思うので、勝手に息が長くなるような気がしています。
あくまで私の感想に過ぎないが、このブログ記事を読んだ時に、ペパボが謳う「技術力」を思い出した。
mizzyさんのエントリにある基準に基づき評価を行いました。その際、そこで謳われている「技術力」を以下のように分解しました。
- 作り上げる力
- 時間の経過に耐える力
- 影響を広げる力
ブログ記事についても、上記と同様のことが言えるのではないか、と思った。
1日目
1日目では次の発表を見た:
- メリークリスマス!
- Managing Containers at Scale with CoreOS and Kubernetes
- HTTP/2時代のウェブサイト設計
- 【sponsored contents】若手エンジニア達の生存戦略
- Lightning Talks Day 1
HTTP/2時代のウェブサイト設計
@kazuho さん の発表。 今年の YAPC::Asia Tokyo で一番見たいトークだった。
Rebuild のゲスト出演回を聴いておくと、予備知識も備わるのでオススメ。
断片的にしか知らなかった HTTP/2 の技術要素を把握できると共に、kazuho さんのトークの上手さに知的興奮が止まらなかった。 質疑応答の場面で、「(h2oの)チューニングの勘所は?」という質問に対して、「チューニングのポイントはあまり無い。できるだけデフォルトを最適な形で提供しようとしているから」という回答が最高にカッコよかった。
自分に関係があるのかがよく分かっておらず(こういうところが「技術力」不足なんだと痛感)、食指が動かなかった分野だったが、この発表に奮発させられた。 HTTP/2 やるぞ!という強い気持ちをもらえるトークだった。
あと、h2i のデモ画面の字が小さくて読めなかったんだけど、改めて動画を観直して、以下のようなコマンドを打っているとわかったのでメモ(といっても動画も若干文字が潰れているため、絶対の保証はない)。
$ h2i www.google.com
Connecting to www.google.com:443 ...
Connected to 111.168.255.20:443
Negotiated protocol "h2"
[FrameHeader SETTINGS len=18]
[MAX_CONCURRENT_STREAMS = 100]
[INITIAL_WINDOW_SIZE = 1048576]
[MAX_FRAME_SIZE = 16384]
[FrameHeader WINDOW_UPDATE len=4]
Window-Increment = 983041
h2i> HEADERS ★ h2i で送信できるフレームタイプの1つ
(as HTTP/1.1)> GET / HTTP/1.1
(as HTTP/1.1)> Host: www.google.com
(as HTTP/1.1)> Hello: world
(as HTTP/1.1)>
Opening Stream-ID 1:
:authority = www.google.com
:method = GET
:path = /
:scheme = https
hello = world
[FrameHeader HEADERS flags=END_HEADERS stream=1 len=122]
:status = "302"
cache-control = "private"
content-length = "262"
content-type = "text/html; charset=UTF-8"
date = "Fri, 28 Aug 2015 18:13:55 GMT"
location = "https://www.google.co.jp/?gfe_rd=cr&ei=46TgVY-BDaSg8we6lYuQBQ"
server = "GFE/2.0"
[FrameHeader DATA flags=END_STREAM stream=1 len=262]
"<HTML><HEAD><meta http-equiv=\"content-type\" content=\"text/html;charset=utf-8\">\n<TITLE>302 Moved</TITLE></HEAD><BODY>\n<H1>302 Moved</H1>\nThe document has moved\n<A HREF=\"https://www.google.co.jp/?gfe_rd=cr&ei=46TgVY-BDaSg8we6lYuQBQ\">here</A>.\r\n</BODY></HTML>\r\n"
[FrameHeader PING len=8]
Data = "\x00\x00\x00\x00\x00\x00\x00\x00"
無限珈琲
YAPC::Asia ではトークを見るのがスタンダードだが、実は通路や休憩場所でのコミュニケーションも華の1つである(と思っている)。
というわけで(どういうわけだろう)、無限珈琲の提供されるスペースでのんびりしていたところ、 @shiba_yu36 さんとお話することが出来た。 勝手にキタソンとかいうイベントを開いたりしてなんかすみません、みたいなことを伝えた(開いてるのは @kitak だけど名前つけたのは私なので…)。 もうちょっとお話したかったけど、同じ業界(この表現もいささか謎であるけど)にいるので、なにかの機会で会うことはあるだろう。
懇親会
@ryot_a_rai君とかラーメンさんとか@rrreeeyyy君とかゆううき君とか、いつもの(?)面々で喋っていたら、柴田さんに「若手インフラだ!若手インフラだ!」って言われてしまった。 若手インフラが何かを説明すると、お互いがお互いを異常者と罵り合ったり高め合ったりする謎の異常者集団(お互いに言い合うのだからしょーがない)で、名乗った瞬間から時の流れに追い立てられる時限制の仕様となっている(詳しくは過去に書いた記事を参照)。 誰か替わってくれ。
その場で、ついに(?)あんちぽさんとゆううき君が邂逅した(といっても、数回目らしいけど。)
柴田さんが撮影したこの写真は、何故か、私 vs CTO みたいになってる
インターネット(というかツイッタ)で散々バトルしていた2人だったが(そうなのか?)、最後の YAPC::Asia にて邂逅を果たした(大事なことなので2回目)。 しかし、あんちぽさんが「これがおっさんのやり方だ!」と言いながら、周囲の人々を1人ずつ懐柔して仲間に引き込み、ゆううき君を孤立させるという作戦に出たため、若者代表ゆううき君は大分苦戦してた気がする。
次は2人でトークショーを開催してほしい(無責任)。
2日目
1日目では次の発表を見た:
- 3分でサービスのOSを入れ替える技術 - YAPC::Asia Tokyo 2015
- 【特別企画】YAPCあるある(仮) - YAPC::Asia Tokyo 2015
- Profiling & Optimizing in Go - YAPC::Asia Tokyo 2015
- Lightning Talks Day 2 - YAPC::Asia Tokyo 2015
午前中のセッションが無いのは、1日目の26時過ぎまで @deeeet 君とゆううき君と日本酒専門の立ち飲み屋でずっと呑んでたから。 要は起きれなかった。
3分でサービスのOSを入れ替える技術
ここ半年間の集大成ともいうべき発表だった。 動画やスライドの前に、日記に書かれている「伝えたかったこと」を読むと、要旨を理解できるのでオススメ。
“No SSH” という制約によって自動化が進むという趣意にはハッとさせられた。 SSH は、サーバでの好き勝手なふるまいを許す強力な武器だ(もちろん制限をかけることは可能だが)。 しかし、(ほぼ)なんでも出来てしまう状況こそが、自動化を阻む思考の壁になってしまっているのではないか。
そんな魔法とも呼ぶべき(と思うようになった) SSH をあえて禁止することによって、全く別の観点を持ちださなければならなくなる。 制約によるイノベーションというと大仰に聞こえるかもしれないが、そのような感想を持った。
また、Check point 1 (p.33) で述べられている “DO NOT change main architecture” は非常に大切だ。 自動化をする上では、目の前で動いているものこそがベースであって、アーキテクチャを置き換える別のアーキテクチャを持ちだしたところで、アンパンマンの頭のようにスコンと入れ替えることは出来ない。 小さな改良をコツコツと積み重ね、確実な自動化を目指していくという姿勢は見習っていきたいと思う。
Profiling & Optimizing in Go
デモ用のプログラムはこちら: bradfitz/talk-yapc-asia-2015
タイトルの通り、Goで書かれたコードをプロファイリングし、最適化していく方法の紹介なのだが、それをライブコーディングで実演してくれた。 発表は英語なので、翻訳が無いと聴けない人は talk.md を読むのが良いだろう。
go test
のオプションだったり、 go tool
の使い方だったり、golang の標準ツールは非常に強力であるということを教えてもらった。
まさに “Go has amazing tools!” の通りである。
おわりに
最後の YAPC::Asia だ!と意気込んでいたのに、前夜祭で完全に失敗した。(本当にすみませんでした)
おっくんが、うずらさんと間違えて牧さんに「プレゼンお疲れ様でした」って話しかけたのウケる。
— Gosuke Miyashita (@gosukenator) 2015, 8月 20
やりましたね!!!
ついにやりました!!!
— 鶉 (@uzulla) 2015, 8月 20
「おお、おっくんよ、うずらと間違えてしまうとはなさけない」#yapcasia
— Daisuke Maki (@lestrrat) 2015, 8月 20
うちのおくむらがすみません
— SHIBATA Hiroshi (@hsbt) 2015, 8月 20
とほほ。