北海道苫小牧市出身の初老PGが書くブログ

永遠のプログラマを夢見る、苫小牧市出身のおじさんのちらしの裏

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

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

オープニング / @codehex さん

  • めんそーれ!
  • A会場は飲食禁止
  • モバイルルータは電源切ってね
  • 赤いリストバンドの人を撮影しないで
  • JPAの行動規範を守ってね
  • #yapcjapan にて案内あるよ
  • 懇親会受付は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 さん
  • "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のための情報をとりに
    • @INCdo の絡みの問題の議論
    • 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とか、遅いネットワークも同等の傾向
    • ChromeFirefoxでも傾向は同じ
    • 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個なので)
  • 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 も同様
    • ->newon_request で処理
  • クライアント側で request を複数呼ぶだけで並列になっている
  • TLSに対応する
    • ただし、強めの暗号化が必要
    • HTTP/2にしか対応していないサイトもスクレイピング可能
  • サーバプッシュも実行できる (省略)
  • shuvgeyPSGIのサーバができる
  • 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∧An)zn 母関数 (#...は言語Lで長さnのものの個数)
    • 無限和だとコンピュータでは使えない
  • s = ε|>s>x は1 + zS(z)z(S(z)) = 1 + z2 S(z)2 は S(z) である、と記述できる
    • これを解いてテイラー展開すると、無限級数になる
    • 無曖昧な文法から、その言語の母関数を作れる!
  • 文法が、全部の文字列を生成できるか
    • 普遍性が決定可能、等価性が決定可能、などのクラスに分けられる
    • 曖昧、無曖昧が決定可能問題に関係してくる
  • 深い数学的対象、の一つに曖昧性があ る
  • Q). 欠点のあるバックトラックの実装を使うのはなぜ?
    • A). 魔改造しやすい。Perlのように。また、DFAよりまともに使える実装は楽
  • Q). 正規表現を無曖昧にするツールは

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とか必要
  • 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で利用可
  • 趣味プロダクトを宣伝して本番投入した
  • 複数台にする理由
    • 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
  • CVE-20107-12883
    • 正規表現のパース時における、バッファオーバーリード
    • 5.22以上だと影響を受ける
  • CVE-20107-12814
  • これからのPerl5 (5.28)
    • 5~6月でしょう
  • 古い文法、特殊変数の削除
    • <<""
    • $/ = -1
    • :unique :locked
    • これらは、警告されてから、削除。こまめにアップデートしていれば気がつける
  • Unicode 10.0 support
    • Bitcoin symbolなどが追加されている
  • ${^SAFE_LOCALES}
    • ロケールがスレッドセーフに扱える環境かを表す
  • XS向けインタフェース
  • 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
  • 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
  • 小さな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で大変な点は
      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でホスト曲を作った
    • プロバイダの契約は敷居が高い
    • 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さん

  • はてなブログのトップページの言葉
  • 思いをみんな持っている : 「ライブラリ最高」「バグ最悪」「資料楽しい」
  • 「自分の書いたものなんて誰にも読まれない」
    • 自分のために書くもの
    • 言葉にして自分で整理する
    • 絶対需要ないとおもったものが反響あったりする
  • 思いが綴られた言葉を読みたい!
    • ブログを今すぐ書いてくれ! (登録サイトが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 Perlperlを静的解析して拡張
  • 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、airpodsgoogle home
    • kazuhoさん
    • 「アメリカの同僚が書いた資料だったが、架け橋、なので」
  • ベストLT
    • colsisさん kindle oasis
    • 芹川さん
    • 「一ヶ月前まではRuby書いてましたから」
  • 35のスポンサー
  • 3人のゲスト、15 + 4のトーク、50の個人スポンサー、150人出席
  • Next...
  • 懇親会に移動しましょう