今日はYAPC::Okinawa 2018 ONNASONの日です

YAPC::Okinawa 2018 ONNASON に参加していますので、自分用のメモを残しておきます。

オープニング / @codehex さん

• めんそーれ！
• A会場は飲食禁止
• モバイルルータは電源切ってね
• 赤いリストバンドの人を撮影しないで
• JPAの行動規範を守ってね
• #yapcjapan にて案内あるよ
  • #yapcjapanA, #yapcjapanB
• 懇親会受付は12:00からです
• ベストトーク章に投票してね
• リゾートYAPCをお楽しみください

万国之津梁 / @chasbar さん

• London Perl Workshop 2017 へ参加した
  • YAPCより少し小さいイベント。国単位
  • 基本言語は英語で集まりやすい
• PAUSE Operating Model について聞きに行った
  • 削除やコメンテナの登録など
  • DBIx::Classでトラブったので、新しい権限が考えられている
• それだけで15万はもったいないので、LTしたり、クラフトジン(お酒の仕事)とか、古代遺跡(大学の専攻)とか、橋(YAPC::Okinawa)とか
• 海外カンファレンスの参加で観光の予定を入れておくと良い
  • ジェットラグの緩和
  • 必要な品の入手
  • 入国審査の簡易化
• LT Perl::PrereqScanner::NotQuiteLite
  • Y8でのネタ
  • require とかをうまく扱う
• PAUSEのオーナーと議論ができた
  • 新しいモデルがどの程度役に立つの？
  • Mojoliciousの作業を優先することになった
• YAML::PP : bookの扱いがJSONと違う問題
• DBD::SQLite
  • 巻き添え食って新しいモジュールをリリースできなかった
  • ブロックしていたDBIx::Class の変更をリリースしてもらえた
  • SQLiteの
• YAPC::EUにも参加した
  • JSON::PP が壊れた問題
  • 数値に見えたらクォーテーション外すようにした
  • Cpanel::JSON::XS の問題が残っている
  • LT PAUSEをMojoliciousにポートする話
  • DBICのメンテナと話したり、Booking.com を訪問したり
• "Three Little Words" Damian Conway さん
  • 正規表現でPerlの構文解析？
• "glob() の問題について" Lukas Mai さん
• "perldoc の改善"　Herbert Breunung さん
  • perlの同梱ツールを良くする、という話が聞けるのは海外のyapcの醍醐味
• "cperl" Reini Urban
  • perlに機能が入らなくて不満の方は聞いてみると
• DBIC のメンテナと話をして、リリースはしてもらった
• gugodさん「台湾語を学ぶ」
• Vickenty Fesunov さん
  • YAPC Hokkaid Tシャツ来てた
• YAPC::NAには参加できなかった
  • 6月はフリーランスには大変な時期
  • が、ビデオは見れる
  • CPAN Testers has an API / Doug Bellさん
  • perl5のヘルステストの仕方について / James E. Keenan
    • CPANモジュールもテストしている
    • 社内のものも、公開するとテストしてもらえるのでオススメ
• Perl Toolchain Summit 2017
  • PAUSEのMojolicious化のため行った
  • 終わらなかったので、持ち帰り
  • skaji++ さんはPerl5でもPerl6でもいい仕事をしていた
• FOSDEM 2017
  • YAPC::Kansaiのための情報をとりに
  • @INC と do の絡みの問題の議論
  • Perl 6.d
  • MooseじゃないOOP、Perl6高速化、など
  • UVのためにtypesterさんの連絡先アナウンスしたり
• ？？？
  • YAPC::Hokkaido用の情報
  • ビートルズの情報
  • 5.14以降であれば Try::Tiny よりも別のモジュールを使ったほうがいい / Paul Evansさん
• YAPC::EUは参加できなかったり
• QAハッカソン2016
  • PlackにしたときにPAUSEが遅くなったかも
  • 遅くなっていたら、また行ったときに修正します
• FOSDEM 2015
  • Perl6のクリスマスリリース
  • sasadaさんのトーク聞いたり
• 海外への行く橋はいくらでもかかっている
  • ビデオが見られる
  • スケジュールを見るだけで情報がわかる
  • 自分たちがやっていることとの違い
  • 自分自身が、橋をかける、かけない、を決められる
• 海外のコミュニティへ行き続けることが大事
  • 最初はお客さん
  • その後知り合いになったほうが、いい情報が得られる
• 海外
  • Perl Toolchain Summit 2918
  • The Perl Conference YPAC::NA
  • The Perl COnference YAPC::EC
• Q). 日本と海外の違いは？
  • A). 海外のカンファレンスではコアメンバーにあえてperl自身の議論ができて楽しい
• Q). 過去と比べて何か違いはあるか？
  • A). 2012年ころからの傾向しか比べられないが、数字だけで見ると、日本のほうが海外より非活発になる速度が速そう

HTTP/2で速くなるときならないとき / Kazuho Okuさん

• HTTP1.1とHTTP2のどちらが速いのか → 「場合による」と思っている人が一番多い
• 速くする理由 → 利益につながる
• HTTP2が必要な理由
  • ロード時間がバンド幅に比例しない
  • レイテンシに比例している
• 理由 → HTTP/1 に多重性がないため
  • データが流れない時間が発生する。
  • 4割しかデータを流せてなかった → バンド幅が増えるほど利用率はどんどん下がる
• HTTP2ではリクエストをまとめて投げて、まとめて受ける
  • バンド幅を有効利用
• HTTP2は制定されて3年
  • バイナリ、多重化、ヘッダ圧縮、push
• ブラウザとサーバによって変わる
• 遅くなるケースもあるのはなぜ？
  • クライアントがJS, CSSを優先することをサーバに伝えねばならない
  • サーバも、それに対応できなければならない
  • ワークアラウンドの対応が必要。それをやってるかの差
• push ができるようになると、HTMLとJS, CSSも同時に戻せてさらに速い!!
• 大量の画像を取る、WebPageTestを使ったベンチマーク
  • 2% 程度のパケットロスを入れると、HTTP2がHTTP1より遅くなる
  • 3Gとか、遅いネットワークも同等の傾向
  • ChromeとFirefoxでも傾向は同じ
  • DCL(DOM content loaded)や Speed Index (Googleさんの指標) も似たような傾向
• 理由
  • HTTP1のほうが同時接続数が多いので、パケットロスがあっても数で速度を稼げる
• 実データでのテスト
  • 例: Fastly customer page (3MB)
  • 同様の傾向。パケットロスがあるとh2が不利に見える
  • 3G回線では、パケットロスがあってもHTTP2とHTTP1は半々
  • ロード完了時間はパケットロスの影響を受ける。DCLは影響を受けにくい
• 実世界のパケットロスはどのくらい？
  • 7割の人はパケットロスを経験していない
  • 1.5msの人もいるので、ないといえない
• QoS : ユーザごとの使用帯域を均等に
  • 帯域を使いすぎるとパケットロスは上昇
• 色んな要素が関連しすぎるので、HTTP2とHTTP1の速度差は「場合による」
  • こういうときはどっちが速い、とか言ってる人は信用ならない
  • ベンチマークを取るしかない
  • セグメントを分けて95パーセンタイル値を比べるとよい
• webpagetest を使う
  • 世界中に端末があり、指示を出すとベンチマークしてもらえる
  • 自分の顧客と同じ環境とは限らない (ex. androidが顧客の場合など)
• Resource-Timing
  • リソースのロード時間をJSで取得するしくみ
  • 独自に継続的に集計ができる
  • H2へ以降すべきかの判断材料にしたりできる
  • iOS safariにも入った
• Resource-Timing では問題の切り分けには使えない(ネットワークのせい？サーバのせい？)
  • Server-Timingヘッダ : HTTPヘッダにサーバ側での値を埋め込める
  • Server-Timing: connect; dur=132, req; dur=0, process; dur=230
  • HTTPヘッダのトレーラーの仕様を使っている Server-Timing: response; dur=11, total; dur=373
• HTTP/2はブードバンド時代に必須
  • 断定的な結論は信じない
  • 測定と最適化のループ / webpagetest, Resource-Timing, Server-Timing
• Q). パケットロスが半々の場合に、どうするのがいい？
  • A). それを取得する仕組みがない。いい質問なのでゆっくり考えたい
• Perlのパの字も入ってなかったが、次でxaicronさんが話します

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

• HTTP2とHTTP1はどちらが速いと思いますか？ → 「場合による」
• はじめにSPDYがあった
  • 2010年のChrome6から実装
  • HTTP/2.0から正式名称がHTTP/2に
  • 2015年にHPACKとRFC化
  • 16年ぶり
  • バージョン3.1で終了
• HTTP2が必要な理由
  • コンテンツ容量が増加、WEBの表示が遅い
  • ネットワーク帯域が遅い → 5G、10Gbps固定回線, 120Tbps海底ケーブル
  • TCPの無駄が多い → 輻輳ウィンドウを大きく、googleのBBR、UDPベースのQUIC
  • HTTP/1.1 の問題の解消
• HTTP/1.1の問題
  • リクエストを多重で送れない、HTTPヘッダを何度も送っている
• リクエストが直列
  • HTTP/1.1ではリクエストを待つ仕様になっている
  • Chromeなどでは6つまでTCPコネクションを張る / HTTP/1.1の仕様では2つまでだけど無視
• HTTPパイプラインによる解決
  • 罠: リクエスト順に返す必要がある(最初のリクエストの処理が遅いと巻き添え)
  • べき等なリクエストでのみ利用可能 (GET, HEAD はO.K. PUT, DELETE もよいと言われているが・・・)
    • ブラウザがデフォルトでONにするのは難しい実情
• その他 : リソースの結合(CSSスプライト)、インライン化(が、パケット30%増)、ドメインシャーディング(1つにつき6個なので)
  • ドメインシャーディングはCDNで使われる
• HTTP/1.1 では HTTP Header は、職人が削るしかない
• HTTP/2 の特徴
  • セマンティクスは互換性 (URLやポート、ヘッダなど)
  • ストリーム : 優先度付き全二重多重化通信、独立してブロックしない、ストリーム数は設定可能
  • ストリームはサーバからも初められる : ストリームIDはクライアントが奇数、サーバーは偶数
  • 送受信はバイナリ、フレーム単位で送受信
  • バイナリプロトコルになって、パースが厳格化
  • ライブラリがラップするので、フレームを意識することはほぼない
  • HPACK 形式で圧縮 ( gzip ではないのはCRIME攻撃手法を避けるため)
• HPACKの特徴
  • 辞書更新、ハフマン符号
• サーバプッシュ
  • サーバがHTMLと紐づくCSS、JSを知っていれば、一緒に送れる
  • 問題もあり、いろいろと改善中
• はじめに、クライアントがHTTP/2を喋れるサーバなのか調べる
  • Connection: Upgrade, HTTP2-Settings Upgrade: h2c
  • 101 Switching Protocols が返ってくる(web socketと同じ)
  • そのままHTTP/2のレスポンスも返ってくる
• HTTP/2でのhttps
  • TLS1.2以上が必須
  • ALPN
  • PRI メソッドを送る。HTTP/1.1サーバが壊れないようなリクエスト
• HTTP/2 まとめ
  • プロトコルを改善
  • 実際にうまくいくかは研究中
  • プロトコルは若干複雑になった
• Perlでは？
  • http2-perlとProtocol::HTTP2 (後者のみメンテ)
  • Perlはほぼすべての機能が実装されている
• Protocol::HTTP2
  • TCPコネクションの管理はやってくれない
  • LWPやFurlほど簡単ではない
• Protocol::HTTP2::Client, Protocol::HTTP2::Server, PSGI
• nghttpd -notls でサーバを立てておく
  • Protocol::HTTP2::Client ->new
  • ->request : で始まるようなHTTP/2のヘッダ、HTTP/1.1のヘッダ、on_done
  • AnyEvent でコネクションを張る。
  • ->next_frame リクエストのフレームを得られるので、コネクションへ push_write する
  • ->feed へ読み込んだ値を渡すと、 on_done が呼ばれる
• ブロックできないので AnyEvent で書かなければならない
• Protocol::HTTP2::Server も同様
  • ->new の on_request で処理
• クライアント側で request を複数呼ぶだけで並列になっている
• TLSに対応する
  • ただし、強めの暗号化が必要
  • HTTP/2にしか対応していないサイトもスクレイピング可能
• サーバプッシュも実行できる (省略)
• shuvgey でPSGIのサーバができる
• gRPCの話は略
• まとめ
  • 最適化の議論は続いているので、これから使えるようになってくると期待できる
  • Perlでも使える（イベント駆動）
  • gRPCライブラリ出して欲しい

【正規表現と曖昧性】マッチングの困難さについて / sinya8282さん

• 正規言語の研究をずっとしている
  • 河野真治先生 (入門Perl著者)の弟子
  • Shibuya.pmで話した
• (\D|<\d+>)*[!?] はバックトラック(VM)型の正規表現エンジンと相性が悪い
  • pcregrepだと 'a' x 30 に対して結果が戻ってこない ( egrep は大丈夫)
  • * の中に + があること : バックトラックの可能性が増える
• (a?){22}a{22} もバックトラック型の正規表現エンジンと相性が悪い
  • 22 の壁、と呼んでない（けど、これがしきい値）
  • マッチする文字列に重なりがある
• どちらの正規表現も、曖昧であるのが問題
  • 曖昧がゆえに、どこでバックトラックするかが決まらない
  • 7章に書いてます
• 曖昧な文脈自由文法
  • content-free grammar
  • A = {a, b}。 G = ({S}, {(S, ε), (S, aSa), (s, bSb)}, S) : 開始集合、書き換え規則
  • L(G) は {a, b} 上の偶数長の回文全体
• 文法Gとw ∈ L(G)について、wの構文木を考える
• 構文木を作ること == 構文解析
• 統語的曖昧性 (ジャーゴン)
• 構文木が複数ある場合もある
  • G = (v, R, S) について、すべての w について構文木が一個しかなければ、無曖昧という
  • 無曖昧でない文脈自由文法は、本質的に曖昧
• Time flies like an arrow
• if a then if b then s else s2 : elseはどちらにつくのか？
  • プログラミング言語であれば、曖昧ではないはず
  • 曖昧のない文法になっているか、文法ではないレベルで決まりを決めている
  • PEGs など、曖昧にならないクラスをつかうとか
• {(s, ε), (s, ss), (s, >s>) } と {(s, ε), (s, >s>x) } は等価。後者は無曖昧
• 正規表現をバックトラックしないように変換することはできる
  • 自由言語はそうでもない
• Fz = ∑#(L∧Aⁿ)zⁿ 母関数 (#...は言語Lで長さnのものの個数)
  • 無限和だとコンピュータでは使えない
• s = ε|>s>x は1 + zS(z)z(S(z)) = 1 + z² S(z)² は S(z) である、と記述できる
  • これを解いてテイラー展開すると、無限級数になる
  • 無曖昧な文法から、その言語の母関数を作れる！
• 文法が、全部の文字列を生成できるか
  • 普遍性が決定可能、等価性が決定可能、などのクラスに分けられる
  • 曖昧、無曖昧が決定可能問題に関係してくる
• 深い数学的対象、の一つに曖昧性があ る
• Q). 欠点のあるバックトラックの実装を使うのはなぜ？
  • A). 魔改造しやすい。Perlのように。また、DFAよりまともに使える実装は楽
• Q). 正規表現を無曖昧にするツールは
  • A). https://github.com/sinya8282/recon

High (Availability|Performance) WebSocket for Perl Real-Time Application / macopyさん

• 高可用性 : どこまで担保するか、を決めておくと、作りやすい
• High performece : 10k ～ 100k
• リアルタイム : サーバプッシュ技術
• Aさんはどうやってサーバから相手のターンの終了を知るか？
• ポーリング : 定期的に書くにする 10秒とか
• サーバプッシュ : タイムラグなし
• 現状、生のTCP/UDPで、各々が独自実装している
  • WEBの世界で生きるなら、WEB標準をつかいたい
  • しかし、HTTPはクライアントから通信が始まる
• ロングポーリング、Server-Sent Events、WebSocket、HTTP/2 Server Push, WebRTC ・・・など
• 同期型preforkモデルを使っている
  • 寿命が長いHTTPリクエストを処理するとプロセス枯渇で死ぬ
  • C10K : 並行プログラミングが必要
• リアルタイム通信のために、アプリ全体のパラダイムを変えるべきなのだろうか
• kuiperbelt
  • WebSocketとHTTP/1.1の相互変換プロキシ
  • Goで書かれている
• 機能 : 接続認証、スケールアウト
• 思想 : WebSocketのサーバはロードバランサーの下に入れる
  • 他の事例では直接インタネットに晒すことが多い
• LBに入れる理由 : 管理コストを下げる
• 思想 : 独自のデータ構造を作らない。HTTPをしゃべる
  • kuiperbelt ではクライアントからサーバへの通信はサポートしない(HTTPを使う)
• X-Kuiperbelt-Endpoint X-Kuiperbelt-Session
  • Web appはkuiperbelt経由でpushする。HTTPでよい。
• PerlでWebSocketを使うには、AnyEventとか必要
  • DBのトランザクションとかも不安
• websocketの接続をもっているやつにHTTPで依頼するのがいい、という思いつき
  • 先人の知恵 APNS::Agent : HTTPでiOSのpush通知を送れる
  • 偉大: アーキテクチャごとに分けてデーモンで切り出す
  • 偉大: 土管に徹する
  • Gunfhsiというデーモンで、androidでもできるようにしている
• 彗星(commet)の起源 エッジワース・カイパーベルト
• 認証の方法
  • kuperbelt の実装が太る。クライアントに矯正したくない
  • WebAppに任せる。成功時は200レスポンスUpgrade。kuperbeltの実装をコンパクトにしてバグが入らないように
• 宛先 : kuiperbeltはUUIDのジェネレータがない
  • WebAppにおまかせ
  • HTTPヘッダでやりとり
  • Bodyはappのものなのでさわらない
• 土管に徹することで、言語は自由
  • Perlにこだわるとユーザ数が少なくなってしまう
• 切断検知
  • 行儀が良ければ知れる
  • kuiperbeltがコールバックURLを呼ぶ
• モバイルの世界では行儀が良くない
  • トンネルとか
  • 能動的な切断検知 : メッセージ送信失敗、無通信時間(pingフレーム)
• WebSocketに必要な要素をステートレスHTTPに分解
  • WebAppでも扱える
  • 土管に徹すると任意のWebAppで利用可
• 趣味プロダクトを宣伝して本番投入した
  • 実績がない (ユースケースはただしい？)
  • いい加減なコンセプト実装
  • スケールアウト、ベンチマーク、監視API、ログ
• 複数台にする理由
  • 1台落ちると障害になる
  • 1台の上限は決まっている
• KVSのシャーディングを参考
  • 自分は分散されていることを知らない
• 設計のときにボトルネックを知っておくことが大事
• ユースケースを想定したベンチマーク
• メモリ使用量はクライアントに依存、CPUは秒間メッセージ数
• fujiwaraさんによるチューニング
• mackerel-plugin-kuiperbelt
• プロダクションレディとなった
• 産みの苦しみはあるが、概念を作れる
  • 小説の世界観設計に似ている

2018年春のPerl / karupanerura さん

• charsbar さんの取り組みを支えるため、みんなで情報を集めた
  • charsbar さんにも手伝っていただいた
• 5.26
  • インデント付きheredoc <<- 、 @INC
  • @INC に . がなくなったので、対応が必要
• 5.26.1 、 5.24.3
  • 脆弱性の修正 (5.24 未満には公式パッチはないので注意)
• CVE-20107-12837
  • 正規表現コンパイル時のヒープバッファオーバーフロー、DoSに悪用
• CVE-20107-12883
  • 正規表現のパース時における、バッファオーバーリード
  • 5.22以上だと影響を受ける
• CVE-20107-12814
  • ENVにおけるスタックバッファオーバーフロー、任意コード実行の可能性
• これからのPerl5 (5.28)
  • 5～6月でしょう
• 古い文法、特殊変数の削除
  • <<""
  • $/ = -1
  • :unique :locked
  • これらは、警告されてから、削除。こまめにアップデートしていれば気がつける
• Unicode 10.0 support
  • Bitcoin symbolなどが追加されている
• ${^SAFE_LOCALES}
  • ロケールがスレッドセーフに扱える環境かを表す
• XS向けインタフェース
  • dTHX_DEBUGGING デバッグモードか
  • Perl_setlocale
• delete %hash{@keys}
• 文字列結合の高速化
  • 5.26.1 より 4.85 倍に
• 正規表現マッチの高速化
  • 5.26.1 と比べて 1.1倍
• 正規表現文法の拡張
  • *positive_lookbehind と説明的に書けたり
• スマートマッチの変更は？
  • 5.27.7で変わったが、5.27.8で差し戻された
  • 今回は無理そう
• Rakudo-Star 2018.02
  • まだまだ活動が活発
• Perl6をプロダクションで使い始めている人もいる
• :atom: 系の演算子
  • 演算をatomicに行う
• Perl6高速化計画の完了報告
• Elizabeth氏からの暑いニュースレター
• Perl6のモジュールが1,000件を超えた
  • Inline::Perl5 を使えばperl5の資源は使えるけど
• Cro というWAF
  • Perl6の機能を活かすためのWAF
  • リアクティブな分散システム
  • HTTP2対応、ZeroMQ, Web Socket対応
  • 試したら 223.84 rps 程度だった
• まとめ
  • Perl5もPerl6も進化している
  • アップデート差分が大きい。人気の低い機能の積極的な廃止？
• Q). Perl5の文字列結合がなぜはやくなった？
  • A). とにかくはやくなった。非常におめでたい話
• Q). Perl6高速化計画は？
  • A). 訳しきれていない部分もあるので、サイトを参照してください
• Q). 5.28までは語呂合わせで 5/28 だったぽいけど？
  • A). 把握してません
• Q). charsbarさんと同じように外国行ったりされますか？
  • A). 今のところはないですが、やっていきたい

Perl's work inside the company (Perl のお仕事)

Perlで実装されたLINE NEWSの裏側 / @nipotan さん

• LINE NEWSに最初から携わっている
  • livedoor News と LINE NEWS でパイの奪い合い
  • livedoor News も LINE NEWS もちょっと前まで両方担当していた
  • 前者は中高年、後者はナウなヤングな女性スマートフォン
• どちらもPerl
  • livedoor News, livedoor Blog (Sledge), BLOGOS (Pickles), LINE NEWS (Amon2)
• 2013年からサービス開始
  • ネイティブアプリ中心 MAU 300万
  • アプリをインストールしてもらうハードルの高さ
• LINEニュース 公式アカウント
  • LINEが作っているbot
  • アクティブユーザを増やす施策
• LINE NEWS DIGEST を開始
  • 文字情報だけから、画像も送るように進化
• CMSでのデータから自動生成
  • 指示がわかりにくい
• Perl、Imagerモジュール、フォント、画像
  • ご家庭のIPAフォントでも
  • 文字幅から位置を計算
  • グラデーション、影、文字を指示通り置いていく
  • 文字なども位置を決めて配置
• 4年間、毎日3回配信
  • Imagerすごい
• 2015 LINE上で読める Web App 1200万MAU
• 2015 LINEアカウントメディア
• 2016 タイムラインに掲載
• 2017 5番目のタブ 5900万MAU
• LINEニュースが重い
  • DIGEST配信による同時アクセスにより、重くなる
  • ささやかな未読バッヂも
  • 地震情報によるスパイク
  • 描画まで3秒
• 世の中AMP, Instant Articles, Smart View
• 0.5秒化計画
  • SPAをやめ、HTML表示
  • 読まない後続する記事を生成しない(調べたら後続の記事は読まれてなかった)
  • ローカルキャッシュ
• 通信を速くする
  • CDNでのキャッシュを利用
  • HTTP2が自動的に利用されたり
• PSGIの高速化
  • PSGIによるキャッシュ
  • クエリ結果のキャッシュ
  • 行単位のキャッシュ
• 2016年にミッションを完了した
  • 日経電子版とは違い、全く話題にならずに実現した
• LINE NEWS の未来予測
  • エンジニア採用は難しい
  • JavaエンジニアにJavaで実装してもらうことが多い
  • Perlを死守する理由はないでしょう
  • Java : Perl は 6 : 4
• LINE NEWSではPerlエンジニアは積極的にはしてないが、他のサービスでは使っているので
• 沖縄からまたPerlの火をともしましょう

Perl in Mercari 2018 / @kazeburo さん

• 重要なお知らせ memcached UDP リフレクション
  • DDoS攻撃ができる
  • さくらで 11211/UDP をフィルタリング
  • memcached をグローバルに後悔しない
  • UDP無効化したほういいのでは (デフォルト無効に変わってる)
• メルカリとは？
  • 国内最大級のフリマ。
  • 簡単に出品 : 機械学習で自動で商品名が埋まったり
  • 安心安全な決済
  • 1億DL、100万出品、月間100億取引
• プログラミング言語はPHP7
  • Golang マイクロサービス、ミドルウェア
  • Python 機械学習
• 小さなPerlスクリプトが根幹にいる
• slacklog (OSSでもなんでもない)
  • cronlog + slack notification
  • cronlog : 終了コード0じゃないときだけSTDOUTへ
  • 「監視とは継続的なテスト」
  • slack通知できるようにしたもの
  • 起動と終了のログ (slack通知、syslogへ)
  • hostnameとpidの付加
  • メルカリのほぼすべてのcronで利用
• slackboard
  • メッセージを集めて、一元管理
  • リージョンごとに分けて送信
  • 大量のメッセージが来た場合など
• ログを /dev/null に投げない
• トイルの撲滅 「あのバッチ動いてますか？」
• 商品閲覧履歴サービス
  • 数千req/sec
  • consul, nginx, q4m, ワーカがDB更新とmemcached
  • Gazelle 、 XS moduleによる速度向上
• workerはスケールアウトが可能
• ボトルネックはMySQLのレプリケーション遅延
  • Multi Thread Slave 18,000
  • 念のためSharding は設計に組み込み済
  • golangが3ms、Perlが4ms
• なぜPerl？
  • System Call friendly
  • coreモジュールで作ればDeployが容易
  • Perlで培われた技術の継承
• コンテナからPerlが消えていく
  • SRE研修でPerlを触ってもらう
  • UNIX哲学に触れて、技術を底上げ

Perl's work inside factory / @n0442 さん

• 15人中Perlを書く人は9人
• 事例からPerlについて見ていく
• NTT docomoさん Inter bee 新しいライブの形
  • Shibuyaのスタジオから配信
  • 観客はスマホを持って見る
  • アートワークをクライアントから受けている部分がAWS
  • Pocket.IOでリアルタイム
• WEBキャンペーン企画
  • 期間限定のコンテンツ
  • 人をあつめるのが目的
  • スパイクが起きるのでLambdaとS3で分散させて対処
  • AWSを使って、おいしいところだけPerlで書く
• PUMAさん ファッションシミュレーション
  • Image::Imlib2、Imager、Image::Magick
• ユニフォームシミュレーションの方法
  • 写真か、CGベースか
  • 写真で。素材感が伝えやすい。工数が低い
  • 同じ角度で写真を取って
  • ベタ塗りのレイヤと質感のレイヤをレタッチでわける
  • パーツをPerlで合成する(Image::magick)
• オムニチャンネルのECサイト
  • 2着目以降はスマホだけでオーダー可能にする
  • 2週間という短納期
  • たくさんのPerlモジュール : AnyEvent, Data::Validator, FormValidator::Lite, HTTP::Session, Net::APNs::Extended などなど
• なぜPerlか？
  • よく知っているから
  • 不得意な部分ではHUBとしてつかう
• 今後もPerlは活躍していけるか？
  • まだまだPerlを使って魅力的なものづくりができる
  • Perlを使って何ができるか？
  • Perlを書きたい人を募集
• 1. Perlで大変な点は
  2. 1. 大人数だと開発がきつい

フリークアウト社の事業を支えるPerl / 本間雅洋

http://hiratara.hatenadiary.jp/entry/2018/03/03/174252

Keynote / yappoさん

• AKBの握手会の日だった・・・
• 受託、メール広告、モバイルポータル、EC、フォトサービス、LINE
• LINEと言えば ikebe さんのキーノート
• Perlのコミュニティにどう関わってきたかの話をする
• 学研のBASICの本
  • ファミコン買ってくれなかった。パソコンも
  • こどものしろの1Fでコード書いてた
  • 作文用紙にコードを書いてた。消しゴムでeditができる
  • 実行環境は頭の中で
• 高校で SHARP PC-G815
  • マシン語のほうが高速なことに気がついてアセンブラ書いてた
  • バンドとかチャラいことをやり始めた → シンセ
  • 全自動でmidiの操作をしたくなった
  • Macintosh Collor Classic II を作曲に使う
    • コンパイラが数万円の時代
    • 資料もなく、厳しかった
  • パソコン通信 / Internet
    • 雑誌とかにはサンプルプログラムついてた
    • 定額ではない。自分でパソkん通信は厳しい時代
    • パソコン通信のマクロとApple scriptでホスト曲を作った
  • プロバイダの契約は敷居が高い
    • インターネットカフェでインタネットを利用していた
    • AKBの劇場になったので、今も通っている
  • 1997年にYappoというサービスを作った。iYappo
    • ユーザ層が若くなり、インタネットを知らない人も使い始めた
    • サポートをしていたときに、Yappoという名前で回答していた
• 規格、開発、OSS開発元へのfeedback、プレスリリース(広報/マーケティング)
  • 一人だと意思決定が速い
  • サービスがスケールすると一人では無理・・・だが
  • 声は受けたが、当時は断った
  • リリース、企画持ち込み、代理店契約周り
• 転職感
  • 鹿児島の人から声を受けて会社をはじめた。リモートワーク
  • インタネットのメールを送受信できるケータイ
    • 生年月日を送るとバイオリズムを返すメールサービスを作ってたら、声をかけられた
  • 声をかけられた事が多い。livedoorさんだけ、転職活動をした
• miyagawaさんから喋らないかオファーを受けたのがきっかけ
  • miyagawaさんからの架け橋
  • チャンスと思って、話すことを初めた
• オライリーじゃないラクダ本
  • 1998年くらい
  • 近藤さんのサインの10年後にLarry Wallのサインをもらった
• 参加したPerlイベント
  • Shibuya, Fukuoka, Kyoto, Hokkaido, Kansai, Yokohama, Kamakura, Kokusaitenjijomae, Okinawa
  • OSDC Taiwan (Shibuya.pm枠)
• IRC文化
  • 色んな会社の人々がいるので
  • いいチームワークが生まれた
  • miyagawaさんが転職したという理由で一晩でfreenodeへ
  • miyagawaさんが声をかけて一晩でUTF-8へ
• coderepos
  • gitがなかった時代。パッチのためにリポジトリをクローンするしかなかった
  • 個人のリポジトリを一つのレポジトリにまとめた
• HTTP::Engine
  • Catalyst Engineがよくできていたので再利用
  • このあとWSGIを元にtokuhiromさんとmiyagawaさんがPSGIを策定
• perl-users.jp
  • JPerl Advent Calendar 2日くらいで開始
  • 指名制度。最後まで書いたら飲みに行く
  • 日本のJPerl Advent Calendarの走り
• Perl Hackers HUB 49記事、作者が50人
• LINEにもYAPC関係者が多い
• 開発チームマネージャー
  • 少人数では仕事がスケールしない
  • もっと上のレイヤで仕事をしていたらそうなった
• NEED, SPEED, DETAIL, ENJOY, TEAMWORK
• 一人では何も成し遂げられない
  • いいなと思う人に橋をつなげて、より面白い仕事をしましょう
• Shibuya.pmの次のリーダーをやりたい人は言ってね
  • バソキヤやるらしい

キーノートスポンサーセッション

思いは言葉に / papixさん

• はてなブログのトップページの言葉
• 思いをみんな持っている : 「ライブラリ最高」「バグ最悪」「資料楽しい」
  • 携われることは誇りと責任感
  • はてなブログを使って欲しいが、Twitter, FBなどある
• 「自分の書いたものなんて誰にも読まれない」
  • 自分のために書くもの
  • 言葉にして自分で整理する
  • 絶対需要ないとおもったものが反響あったりする
• 思いが綴られた言葉を読みたい！
  • ブログを今すぐ書いてくれ！ (登録サイトがhttps対応！)
  • 仲間を募集中！ (こっちはHTTP・・・？)
• yappoさんありがとうございました

Lightning Talks

PPRとKeyword::Simplと言えば後Variable::Declaration / @kfly8 さん

• PPR 静的解析モジュール
  • 正規表現による解析が可能
  • キャプチャとかも直感的
• Keyword::Simple
  • PurePerlでPerlにキーワード追加
  • PL_keyword_plugin (Devel::Declareが前進)
  • defined 関数で
• PPR と Keyword::Simple *Pure Perl でperlを静的解析して拡張
• Variable::Declaration
  • ほか、 Type::Tie, Data::Lock
  • let Int $foo = 2018 などと指定すると、型制約チェックを入れられる
  • buggy、静的型付け言語を入れればと言われる→「いいじゃないですか」
• ゴーン！ (時間切れ)

・・・ / 芹川葵さん

Windows 10がブルースクリーンになったのでメモなしです・・・。

ActivityPub について / @argrath さん

• 分散ソーシャルネットワークネットワーキングのためのプロトコル
• サーバ間、サーバクライアント間は HTTP + JSON
• 広くて浅い作りになっている
  • 実装レポートを参考
  • mastodon 完全な実装ではない
  • Kroeg .NET 大変
  • pylodon クラウドサービスが必要
• actub : Perl/Mojoliciousとactub
  • 色々未実装
• デモ
• これから作っていきたいのでよろしく

Perl入学式に参加した結果、その後 / 城後さん

• 大学編入後に新しい言語を
• AnaTofuZさんから彼女ができると言われて
• 入学式を感想した
  • AnaTofuZさん彼女いなかった
• すぐわかるオブジェクト指向perlの読み会
• 今年からサポーターやります

Acme大全が電子書籍化されて1年が過ぎました / makamakaさん

• Acme::Sundial
  • 日の出、日の入
  • 日の出後は何も出ない
• use oist
  • -Moist しっとり
• 664個のAcmeモジュール
  • 重くて買ってもらえない → 電子書籍化
  • donzoko.booth.pm
    • 5名
• Acme大全が10年目
  • 全巻収納ボックスにチャレンジします
• ゴーン！(時間切れ)

クロージング

• でーじ上等!!! (すごくよかった)
• スタッフ撮影 「はやくはやくはやく」「まんなかまんなか」「まえまえまえ」
• ベストトーク章
  • Supershipさん(エンジニア募集中です!)からappleTV、airpods、google home
  • kazuhoさん
  • 「アメリカの同僚が書いた資料だったが、架け橋、なので」
• ベストLT
  • colsisさん kindle oasis
  • 芹川さん
  • 「一ヶ月前まではRuby書いてましたから」
• 35のスポンサー
• 3人のゲスト、15 + 4のトーク、50の個人スポンサー、150人出席
• Next...
  • http://yapcjapan.org/2018tokyo/
• 懇親会に移動しましょう