(メモ)今日はYAPC::Hokkaido 2016 SAPPOROの日です

YAPC::Hokkaido 参加のために大雪の札幌市におります。適当に自分用のメモを残しておきます。

オープニング / onagatani さん

• YAPC::Asia が YAPC::Japan になった
• 会場150名(けっこういっぱいいっぱい)
• タイムテーブル変わってるよ（入れ替わった？）

HTTP/2の課題と将来 / 奥 一穂さん

• HTTP/2の理由
  • HTTPのボトルネックはレイテンシ
• RFC 7540
• 2016年7月で30%くらい
• ヘッダ圧縮で90%圧縮
• 並走度の向上でパフォーマンス
• 課題が4つ
• 課題1: 優先度制御ツリー
  • 重み付け＋順序指定
  • バンド幅をウェイトで指定
  • 画像の重み付けはHTMLより低い (Firefox)
  • SafariやBlinkは優先度指定が正しくない (全てが同じウェイト。画像に奪われる)
  • 良くないクライアントを検出して、サーバ側で正している
  • 優先度制御は重要だが、必ずしも正しく実装されていない
• 課題2: TCPバッファ
  • CSSの要求を検出したら、CSSを先に送ったほうがよい
  • ヘッドオブラインブロッキング (先行データが後のデータを阻害)
  • カーネルに渡した送信待ちのデータは取り戻せない
  • TCP_NOTSENT_LOWAT を使ったハック(即送信できるもののみカーネルに渡す)
  • レイテンシが大きい環境だと、良く効く
  • これだけじゃ駄目。TCPバッファは他にも存在
    • TLSターミネータ (直接HTTP/2サーバで受けないとパフォーマンスが出ない)
    • モバイルネットワーク (モバイルキャリアが頑張ってる。QUIC(UDPベース)でたぶん治る* 課題3: プッシュ
  • 改善するが、プッシュされた47%が捨てられたり
  • キャッシュがあるから。HTTP/2サーバ側が判定できない
  • pullであればクライアントが教えてくれる
  • cache-digests : (効率よく圧縮された)キャッシュ済リソースのハッシュ値をクライアントが送ってくる仕組み
  • 小さいのでオーバヘッドにならない
  • HTTP/2 フレームを使った提案になっている
  • HTTPヘッダ、クッキーでも
  • プッシュでもパフォーマンスはあまり変わらない(正しい使い方ではない)
  • 正しい使い方:
    • 送信順の変更 (あまり効果ないやつ)
    • DBアクセスなどHTML生成が遅い
    • CDN
  • 103 Early Hints
    • 1リクエストへ複数回のレスポンスを返す。100番台
    • 103 を受け取ったクライアントは、先にロードする。提案中
  • CDN側で対応必要。設定できるか、CDN側がログから自動で判断するか
• 課題4: ファイルの結合
  • 小さいファイルの圧縮率は低い
  • SDCH : 事前ダウンロードした辞書による圧縮
  • Compression Dictionaries for HTTP/2 : 直前のレスポンスを辞書に
  • 問題 : 圧縮率を観測して情報を抜く( CRIME、 BREACH攻撃)
  • 小さいファイルを結合するのが、今のところはおすすめ
• 注意
  • サーバ、CDNでパフォーマンスが変わる。条件でも変わる
  • 避ける: TLSターミネータ、隠れたCSS、JS(サーバサイドでわからないもの)
  • プッシュ、小さいファイルの注意事項
• Q. WEB屋さんが、使い始めるのがいつがいいかとか、調べる方法はある？
  • A. HTTP/2まではもう入れたほうがいいでしょう。その先はWEBサイト依存であることが多いので試すしかない。
• Q. TCPでウインドウサイズを意識して転送する仕組みは難しい？
  • A. TLSターミネータ内に受信、送信バッファサイズがある。サーバサイド側がバッファサイズが大きくなりがち

2016年のPerl (Long Version) / charsbar さん

• 5.24がリリース
• perl コマンドはシェバン行を見ている
  • シェバン行の perl6 を見る
• auto dereferencing が実験的機能になった
• postderef $maybe_undef->%* とか
• Unicode 8.0 のサポート
• \N{EMOJI MODIFIER FITZPATRICK TYPE-5} みたいの
• lexical $_ がなくなる
• /\C/ がなくなった(危険なので)
• ネストの my out がなくなった
• chdir(undef) が die するようになった
• sysread と syswrite を :utf8 ハンドルに使うと警告
• パフォーマンスの改善
  • スコープの出入りが速い
  • 固定文字列の正規表現
  • 四則演算 (境界値チェック周りを速く)
• セキュリティ関連のバグ修正
• Perl 5.26 の開発
• 正規表現の { } が廃止。先頭にあれば大丈夫
• my sub ... {}
• use encoding 'cp932' が Filter => 1 が必要に
• <<~HERE ヒアドキュメントのインデント対応
• @INC から . がなくなる。 Find::Bin 使う
• コミュニティの変更
  • パンプキン、TPF Presidentの変更
  • YAPC は The Perl Conferences という名前に
• イベント系
  • WA Hackathon
  • meta::hack
  • Perl Dancer Conference
• CPANの状態
  • 12915人、日本人600人くらい
  • モジュール登録数は減少傾向。日本も減ってる
  • App::、Test::、Dist::Zilla:: とかが人気
• Perl 6
• 6.c ROAST 公式テスト
• Rakudo : use v6.c しても死なないRakudo、という意味
• 6.c の全てが実装できているわけではない？
• Linuxで動かないのはバグではなく仕様になっている (!?)
• テストされている機能については STABLE
• 6.c 内の experimental などは仕様から外される
• バグか迷ったら ROAST を見ること
• 6.c-errata を見る
• パフォーマンス改善を色々直している
• Rakudo on JVM は一度壊れた。速度もMoarVMより遅い
• Rakdo.js もうすぐでコンパイルできるレベル
• Parrot は消えた
• Rakudoのリリースボットなど整えた
• テストのハーネスはperl5を使ってたが、 TAP.pm6 を作ってる
  • パフォーマンスの問題で切り替えてない
• ユニコードサポート
  • 半角の 「」 、 × 、 とか
• BUILD の改善 (TWEAK)
• use してないモジュールを使えなくする（ロード済でも）
• 750モジュール。perl5の資源も使える
• PAUSEにも /PERL6/ 以下に上げれる
• 資料
  • Perl6 Advent Calendar、RosettaCode、roast、perl6.orgとかとか
  • Learning Perl 6、Perl 6 By Example
  • p6weekly.wordpress.com
  • bit.ly/perl6_english_video
  • WEB+DB Press
  • 次は 6.d

Perl6 と Web 開発と / tokuhirom さん

• Perl6 、数年前まではできる雰囲気ではなかったが、最近はいけそう
• Perl5 との互換性はなく、別の言語
  • Parrotが消えてMoarVMになったのでPerl5と共存できる理想郷はなくなった
• Rakudo star ・・・ 実用的とは？
• 実用的なWEBアプリケーションを書けること
• modules.perl6.org → git clone して master をガンガン入れるやつ
• panda install HTTP::Server::Tiny 会場では22番ポートが通らないので注意
• (現実的な速度で動く)HTTPサーバがない
  • p6-HTTP-Server-Tiny (Starletの移植)
  • Perl6だなーって感じの良いコードなので読んでみて
• JSON::Tiny コアじゃなくなった
• DBIish
• Template::Mojo サーバサイドレンダリングしたい
  • Mojo::Template 互換 (なんで逆？)
  • Perl6のコードを埋め込める (Perl5は無理)
  • 読みやすいコードなのでオススメ
• p6-WebSocket
  • Perl6は並列性を扱うとアピールしやすいので
• p6-HTTP-MultiPartParser
• p6-HTTP-Parser 単体のものがなかったので
• p6-Cookie-Baker 単体のものがなかったので
• 小さいモジュールの寄せ集めで作りたいので
• Crust - Plackクローン。人気。
  • 15人で作れた。コミュニティー的にも重要
  • プラグイン単位でポートできるので、Perl6のとっかかりにおすすめ
  • P6SGI (別の人) を参考に
• パフォーマンスは
  • MoarVMになって、Perl6専用になったので速い
  • 99 req/sec まで出た。（スタックしないのがすごい）
  • Perl5 だと 1744 req/sec
• LINE BOT
  • Perl6だとちょっと楽になる
  • Perl6で1000万円ゲットできるチャンスはあまりない
• O/R マッパとか、書かれてないものがまだある
• クリスマス前よりは安定してる

Number Unlimited / Dan Kogai さん

• 本来コンピュータは計算するもの。数を扱うもの
• 1 << 64 と 2 ** 64
  • perl : 結果が違う (1 と 浮動小数)
  • ruby, python : きちんと計算される
  • Haskellは (**) が浮動小数 (筆者注: (^) が整数のべき乗で意図通り動く)
  • Perl6 1+<64 と記号が変わってる
• 昔は、数字をコンピュータ寄りで考えていた
• Perl6 には is-prime がある
  • Ruby の (2**127-1).prime? は時間がかかる。Perl6は速い (danさんがパッチ送付済)
• 複素数 on Perl6 i
  • sqrt(i*i).im.WHAT 虚部が倍精度整数
• swift-pons
  • (BigInt(1) << 127-1).isPrime 速い
  • Complex.sqrt(-1) も計算できる
  • 浮動小数の精度もいくらでも細かくできる
  • 定数 : pi(1024) など。精度指定ができる
• 筆者注: 時間切れになってしまいました

スペシャルセッション「今さら聞けない、でも聞きたい。クラウドの過去・現在・未来」

パネルディスカッションです。

• 自己紹介 : 馮さん、福田さん、荒木さん、田中さん、久森さん
• 荒: AWSは歴史が長い。使って当たり前になった。種類が多いが、美味しいところだけ使えばいい
• 荒: AWSの求人は増えている(Perlのほうが多いけど)
• 田: さくらはハウジングが減少傾向。専用サーバが伸びると見込んで石狩データセンターを作ったが、クラウドに飲まれた
• 田: サーバ屋でもトレンドが変わってる。クラウドとホスティングを使い分ける時代。裏をかくならホスティングの求人も
• 久: MSはOSを作っているので、他のクラウド会社もお客様。開発ツールとクラウドの連携を考えるとMSは面白い
• 福: G社はインフラ力。gmailとか検索が動いているのと同じインフラの上にシステム構築できる。データセンター効率がいい
• 福: ネットワークを自分で持っている。ソフトウェア資源もある。no ops、サーバレス。開発者はコードに専念
• 馮: クラウドを使っている面白い事例はある？
• 久: ブロックチェーンへの取込。ベンチャー支援してazureでやってもらう。
• 田: ディープラーニングの電気代が半分になる。 Bonanza も利用している。囲碁やGPS使う系
• 田: コンプライアンス的に日本に置きたい要求はある
• 荒: リージョンによって値段の高い、安いときの差がある。糖尿病の解析会社ではそういうことをやっている
• 福: ポケモンgo、snap chat(米ではFBより滞在時間長い)、abemaTV。リクエストを読むのが難しいところ
• 馮: 全部クラウドじゃなくてもいいの？
• 田: 全部クラウドでいいと思っているが、部分最適だとVPSでも。物を見たい（情緒的な）
• 田: 中身のわかるクラウド（石狩データセンターの見学とか）
• 久: azureもデータセンターを見せている
• 荒: AWSは逆で、中身は絶対見せない。第三者に見てもらってはいる
• 福: GもAWSに近い。お客さんが選択すればいい。G社は隠す方向へ
• 馮: 適材適所がポイント？
• 荒: インフラエンジニアが知らないものを使うのが嫌なのはわかる。一方で、自分ではなし得ないすごいこともある
• 田: 安全性と安心感は違う。中身を見たい人は安心感も求めている。大きいとこだと安心できる、コミュニティで人を見る、実物を見る、など
• 久: 使う側も冷静にならなければ。安全と安心、どちらが原因で使いたくないのか
• 馮: 説得材料とかある？
• 荒: AWSは説得材料が多くある。コミュニティに参加して聞くのが早い
• 田: どのように上司を説得したのか、を共有しているのはよかった。「使いたくない」にデータを示しても逆効果。情緒的な対応が必要
• 久: 情報を出す人に情報が集まる。コミュニティでアウトプットするといい
• 馮: 会場から質問ありますか？
• Q. 当局からの圧力にどう対応する？そういう線引とかあれば
• 荒: AWSはあらゆるお客様に中を見せない。第三者認証機関には中を見せる。国の法律は守る。法律にあれば公開するしかないが、見せないようにしている
• Q. リージョンによって違うと思うが、ユーザがマイグレートした場合は？
• 荒: ユーザに不利益ないようにしている
• Q. お客様が規約を守っているのをどう担保？
• 荒: AWSは、著作権以外については関係ない。お金を払わないユーザには出ていって頂く
• 田: さくらは日本の法律に基づく。日本は当局の力は弱い（規制は強い）。礼状がなければ見せない。
• 田: 操作次項紹介書、で、利用者の名前までは見れる。見た人の記録はすべて残る
• 田: 警察からは犯人を捕まえやすいように圧力がかかる。NHKとか使って。事業者としてはユーザを守る
• 福: データとアプリはお客様のものというのをはっきりさせる。正当な理由がなければ見せない。見せた場合は、要件と何を見せたのか、すべて公開している
• 久: ローカルのルールに従う。エンタープライズ契約をする場合は与信を取る
• Q. 今、一番日本人に使って欲しいサービスはなに？
• 福: BigQueryとAppエンジン
• 荒: S3
• 田: GPUクラスタ、国内向けCDN(安い)
• 久: 開発ツール、PAAS
• 福: BQはデータサービス。大量のデータを超高速に処理。簡単で効果がわかりやすい。
• 福: App Engineはサーバレス。2008年からやってる。pokemon goとsnapchatも動いている
• 荒: 70のサービスがほとんどS3と関係する。S3は次のサービスの入口になる
• 田: コンピュータの資源をもっと無駄遣いすべき。プログラマの時間は限られてる、ビジネスチャンスはたくさんある。CPUが解決する
• 田: 日本のクラウドベンダーなので、日本向けCDNを出すのは自然。自治体のホームページとか
• 久: 開発者の時間は有限。G、AWS、MSが全てリージョンがある国は珍しい。代表者が日本語で喋りに来るとかすごい
• 久: 生産性の高いツールとクラウドで、バットを振る回数を増やす
• Q. WEBコンソールが遅くてイライラする。早くならない？
• 福: よく頂くフィードバック。CLIを使う。APIを使う。直していく必要はある
• 久: azureのコンソールはメモリすごい、リダイレクト多い。歴史的な自由。APIがある。操作も宣言型になってる。クラウドの変化が激しくてUIがどんどん変わる。本質はAPI
• 田: APIがないので分が悪い。作り込めば速いのでしょうが、汎用的にするしかない。回線を増やすとかいうチューンアップも。頑張ります
• Q. ISUCONをやってて、過去に色々な事業者さんからクラウドを提供頂いた。田中さん、次回ご提供いただけませんか
• 田: ぜひ提供させていただきます
• 馮: 最後に一言
• 荒: REPL APIをPerlから叩けます
• 田: 手のかかるものから手のかからないものまである。プログラミングもサーバの面倒を見るのも楽しい。個人のサーバを一台持ってかわいがって見て下さい
• 久: エンジニアとして働く人は生産性を考えて、その観点から事業者を選んで欲しい。MSは色々揃えている
• 福: なんでクラウドを使うのかは説得しやすいが、なぜGを使うのかはまだまだ。今までないとっつきにくいものが多い。使うとファンになるので、ぜひ
• 馮: クラウドを使っていただいて、またお話できることを祈ってます

モジュールメンテナンスを通して感じる最近の Perl / 吉田昌平 さん

• Mouse ,Xslate, MesagePack, Minilla, plenv, Perl::Build
• MELPA, markdown-mode, php-mode, coffee-mode, git-gutter, auto-complete,...
• peco
• zsh-completions
• 最近のPerl
  • 積極的に開発されてない
  • 新しいことも行われない
  • 古いモジュールも放置(パッチ、PRが放置)
• 反応が乏しい (MessagePackとか)
• Perlへのモチベーションの低下
  • 技術的チャレンジがない。壊れることがある
• Perl盛り上げてた人
  • Java, Scala, Go, Ruby, Pythonへ
  • 年を取って時間が減った (結婚、子供)
• 開発が盛んな時期であれば対応しやすいが、その後重荷になる
  • やがて放置される
  • 早めにメンテナンス方針を立てる（問題がたまった後では遅い。引き継いだ時点で isuue 100個とか）
  • コントリビュートする方も、それを加味した上で楽になるよう
• 継続したメンテナンス
  • 負荷を減らし、共同でメンテナンスする
  • やめると宣言する
• 負荷を減らす
  • issue を閉じ、PRのみに。issueは stackoverflow へ誘導する
  • 反応がない issue や PR は閉じる
  • issueテンプレートやPRテンプレートは効果ない（消される）
  • 自動化
  • サポート対象を減らす (5.8はサポートすべきなの？)
  • 依存パッケージが5.8で動かなくなって巻き添えとかあるし
• 対応をしないときは、はっきりNOという
• 共同メンテナンス : commit権限、comaint
• メンテナンスをやめる
  • 燃え尽きるぐらいならやめよう
  • 他のリポジトリにまで影響が出るとよくない
  • 曖昧にしない。明示的にやめる
  • 余力があれば、代替手段を提示する
• コントリビュータ
  • メンテナの負荷をなるべく減らす
  • PRは自分のコードを他人に管理してもらう行為
  • バグ修正は最低限で
  • reactionで十分なものはreactionで。コメントは新情報を
  • 過去のPRを見て、メンテナの傾向をつかむ。同じことを何度も言わせない
  • PRの過去のコメント数を見る。多ければ気にすべきことが多いリポジトリ
  • 機能追加や拡張は積極的な方がいい。ただしユースケースを示す
• メンテナンスは大変で燃え尽きることもある。負荷の低減が必要

LINE Bot on the Perl / Yappo さん

• LINE bot : 無料で開発できる。有料プランもある。
• Messaging API
  • Webhook Event を用意しておくと、LINEからリクエストが飛んでくる
• Reply Message API、Push Message API : ユーザに送る
• sending image, receiving image
• JSON API、official SDK。SSL上でしか動かない
• Let's Encrypt で試すときはfullchain.pemが必要
• Ikachan : 簡単なAPIコールをIRCボットへ
• LINE Notify : curlだけで使えるもの。Ikachanぽい
  • 画像もPOSTできるように
  • OAuth2 との連携
  • notify-bot と notify-api のURLが似ているので注意
• LINE::Bot::API
  • X-Line-Sigunature : 改ざんを検証
  • 全イベントをループで処理 Text, Image, Audio, Video, Sticker, Location
  • 友達登録、ブロック、入室
  • 30秒以内ならReplyできる。過ぎたらPush(ただし有料かも)
• リッチメニュー、beacon
• 「LINEビーコン欲しい #yapcjapan」

Delivering a CDN / miyagawa さん

• Fastly : Realtime CDN
  • Realtime Stats
  • Instant Purge (世界中のホップサーバから1秒以下で削除)
  • Instant Configuration (数秒で反映)
    & API first
• CPAN, MetaCPAN, cpanmetadb, PyPI, Rubygems, npm, GitHub, NewRelic, Foursquare
• 「CDNって面白いんだろうか、そう考えていた時期が僕にもありました」
  • nginxでもsquidでも入れれば終わりでは
  • モダンCDNには色々なものが必要
• Varnish : SSDを効率良く使えるように書き換えたり
  • HTTP/2 のサポート
• Realtime Logging
• APIで提供
• 5M requests/s をさばく
• お客様のトラフィックをシールドする
• cpanmetadb
  • 1ヶ月キャッシュする
  • 手元で更新を見るバッチが動いていて、変更があればパージする
• Firstly の技術要素
  • JS(Ember), Ruby*Sinatra, Rails), Perl (Plack), Python, Go, C
• Perl
  • 2008-2010年にモダンだったものを使っている
  • Plack, Starman (Dancerはやめた)
• Control Plane : Cache Fleet を制御する。設定を管理し、配布する
  • クリティカルなソフトウェア
  • お客様のWEBサイトが壊れる
  • 技術的、心理的な問題で変更しにくいものだった
  • 安定にしたかった。新しいものにする必要があった(Stable means dead)
• Cotinuous Delivery => すぐにリリースする仕組みを作ること。哲学
• 誰でもリリースできるように
  • 変更前: リリースマネージャがPRのリスクを判断して選んでリリースしてた
  • 変更後: PRはすぐマージ、CIやタグは自動化。リリース履歴を記録。誰でもリリース可
• Canary Testing : カナリヤを単行に連れていけば、カナリヤが死ぬことで危険がわかる
  • カナリヤサーバを使ってテスト
• 例: PerlからRubyを読んでいたコードをpure perlへ
  • 2倍早くなった
  • 実データで全データ試した → 2ドメイン失敗
  • カナリヤサーバで24hテスト
• プロダクションでテストするのは重要
  • ユーザの入力データは読めない
  • 実データでのテスト＋カナリヤサーバ
• apex を検証するコードが遅かった
  • 全データをselectしてた
  • 当時はユーザが少なかった
  • そんなにボトルネックではないが遅いのは良くない
  • 変換済データをDBに入れて、一発で引く最適化
  • 小さな修正を、何度もデプロイ。
• 古いコードと新しいコードを並列実行。比較して問題ないか確認。安全になるまでは古いコードの結果のみ使う
  • ログを全回収、Fluentd, Kibana, Sumologic, Splunk → Alert on Slack
  • 3回バグが見つかった (古いコードのバグとか)
• リリース回数とリスク
  • リリース回数が少ないと差分が大きくなる。リスクが増す
• APIの更新 → 古いAPI、新しいAPI、並走する時期が必要
• Dark Launch : 一部のユーザにのみ最初は公開する
• Contain Errors
  • エラーの許容の度合い
  • 間違えたデータを返すよりエラーで落ちたほうがいい
  • 常にエラーは起きる、という前提のデザイン
  • 復旧しようとしない
  • エラーが伝搬しないよう
• 手法もツールも溢れてきている。自身を持って怖がらずに変更できるようになる
• Architectはチームをleadする。management以外のキャリアパスとしてよい

LT

株式会社ファームノート / 谷内さん

• 農家の生産性を高めるためならなんでもやる
• うれにうれてうれまくった
• issue が 2,600
• 人増えてissue 386 に減った
• 50名くらいにしたい

ダイアモンドヘッド / じょにー石田さん

• 恐らく誰も知らない会社
• アパレルブランドのECに特価
• 札幌にも支社がある
• じゃんけん大会

Perl で書く、さまざまな Hello, world! / risou さん

• hello world を出す。改行は問わない
• print ,pringf ,q//, qq//, qc//
• syswrite
• 5.010 say
• AAのやつ、ppencode、ppencode2
• use re eval
• Perl6のやつ

エンジニアが挑むサービス設計（仮）/ ar_tama さん

• エンジニアはサービス設計に向いてる
• 無限に膨れ上がる機能がユーザを疲弊させる
• 多機能よりシンプルがよい
• UI設計 → みんなをしっくりさせる

Perl6 で Module をつくる / astj さん

• panda install
• ローカル、git、githubから入れられる
• ecosystem-api にメタデータがあって、そこから取れる
• ecosystemリポジトリのMETA.listに書く
• App::Mi6
• Test::META
• githubにおく、ecosystemにPR、めでたい

シェルスクリプトと人生 / sakura818uuu さん

• YAPC HOKKAIDO
• HACK API KODO Y
• APIとシェルスクリプトを使ってツイートを送信してみるか？
• ツイートできたらLTを終わります
• あれ？
• できました！

若手エンジニアのUターン転職について / 岩山 浩将 さん

• 上京して2年半で帰ってきた
• U, I, J
• YAPC Hokkaido 最高です

5分でわかる Perl & web security / mala さん

• CSRF, XSS 言語依存ではない
• WEBアプリ フォーム値を受けてJSONを返す
• ハッシュで param で受けると、多値でハッシュがずれる
• JSON
• File upload のコマンドインジェクション IMageMagick, Plack アップロードしましょ
• HTTP::Body::Multipart 拡張子を保持してしまう（拡張子部分実行する）
  • 2引数openは使わない
• ... とか systemは使わない
• OSコマンドインジェクションとか、ないとか言われてても起こるので注意
• Cookie周り
• metacpan、Event::RPC → Storableで任意コード実行
• String::Random パターンが少ないのでブルートフォース可能
• 資料見て下さい--

クロージング / nekokak さん

• 牧さんから代表理事を nekokak さんが引き継いだ
• JPAの問題 : YAPC、東京だけ
  • Perl入学式をサポートします
  • Perl入学式NEXTを検討
  • 東京以外でのYAPC
• ロゴの変更 (オライリーさんと話済)
• サイト、ブログのリニューアル
• 試される大地での開催
• 参加人数: 265名 (実質 185名)
• 次は YAPC::Kansai 2017.3.4
• さらに次は YAPC::Fukuoka 2017.7.1
• さらにさらに次は？？？ YAPC::Tokyo 2018 をやりたい
• 明日も飛行機飛ばないかもしれないのでがんばりましょう