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

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

今日は YAPC::Tokyo 2019 の日です

YAPC::Tokyo 2019 に来ましたので、自分用のメモを残します。

オープニング / @magnolia_k_ さん

  • 拍手の練習
  • 普段は 吉祥寺.pm してます
  • Hokkaido, Kansai, Fkuoka, Okinawa と回ってきた
  • Tokyo に戻ってきた
  • 「報恩謝徳」
    • 恩送り:誰かから受けた恩を他の人に送ること
    • 報い方は人それぞれ
  • 自由なイベント
    • トーク、交流、出会い、もくもく
    • ランチセッション、懇親会
    • 会場の空気を感じるのが大事
    • 空気感を持ち帰って下さい
  • ランチセッションは 150 名まで
    • 聞くだけもO.K.
  • 電源は3Fオープンスペースを
  • wi-fi はフライヤーを見て
  • ハッシュタグ
  • リストバンド付けてね
  • 飲食禁止ではない。匂い、音、アルコールは注意
  • 喫煙は3階で
  • 赤ストラップは撮影禁止
  • 行動規範を守って
  • 懇親会はホールで。まだ申込可能
  • 移動は外の階段、寒いので注意。
  • ベストトーク賞投票してね
  • ツイート、ブログで情報発信を(次回のYAPCが開催されるかが決まる)

肩のこらない型の話 / Dan Kogai さん

  • What is this
    • 64個の0と1の列
    • YAPCASIA という文字は、Number、Address のいずれとも解釈できる
    • そのうちのどれを決めるのが型
    • Perlの場合は、いずれでもあると解釈する
  • Perl$scalar
  • "0 but true" は文字列として表示できる
    • boolean で評価すると true
    • 数字として表示すると 42
    • (クイズ形式で、聴衆に答えてもらっていた)
    • では、型は? → 複数の意味がある
  • join ",", localtime
    • カンマ区切りで時刻を表示
    • "".localtime だと英語表記
    • 0+localtime0
  • 通常の言語は、宣言するときに型が決まる
    • Perlではあるデータがどのような型で使われるかは、使うときに決まる
  • Perlの場合は、コマンドライン引数(文字列)をいきなり数値として使える
    • Ruby では型エラーになる ( to_i すればよい)
  • say localtime の出力はドキッとする (現在時刻の数字のリストが連結されて表示される)
  • Perl5の特徴「遅延型決定」
  • Perl6 では、 subset Fizz of Int where * %% 3 というように3で割れる型を作れる
    • FizzBuzzに条件分岐が要らない
    • 型が実行時に決まる。型で分岐する
  • 型推論
    • 数値だったら数値、文字列だったら文字列に決まっとるやんか
    • swiftのFizzBuzzの例。一度コンパイルするとPerlよりコンパクトで速い
    • 型推論があるといいところどりができる?
    • コンパイルに時間がかかるという問題がある
  • まとめ
    • データに意味を与えるのが型
    • Perl5は特殊。使うときまで型が決まらない
    • 型の未来。割り切れる型 (Perl6)、みたいなものができるといい
    • 型を書かなくていいようにしたい (型推論)
    • SPVM を使うとPerlを静的にコンパイルできる

Perl 6 でのアプリケーション開発と実用 / risou さん

  • 若干強めのタイトルにしてしまった
  • Perl6で仕事をしたことはない。趣味でやっている
  • 文法、Web、モジュール開発の話はしない
  • 環境構築 : 公式サイトにある通り
  • Perl6には MAIN() 関数がある
    • 使う必要はない
    • 両方使うと、デフォルトスコープが先に実行、その後 MAIN()
    • MAIN() を使うと、コマンドライン引数の型チェックができる
    • usage が出力される
    • multi sub によって、 MAIN 関数を引数によって分けることも
  • Usageは自動で作られるのか
    • USAGE() 関数を実装できる
    • 内容を置き換えられる
    • ヒアドキュメント
    • デフォルトは $*USAGE に入っている
  • デフォルトのUsageの変更は?
    • #| #= 宣言子ブロックで補足ができる
    • #| は関数の前、 #= は関数の後
    • Perl6のpodの機能
  • CLIでもファイル操作は使う(よね?)
    • 「Perl5 とそんなに変わらないでしょう」「はい」
    • open で書ける
    • .slurp ファイルの中身を全部取る
  • $fh.slurpIO::Handdle のメソッド、 slurp ""IO role が提供する関数
    • close は必要ない
  • spurt で文字列を一括で書ける
  • 行単位での読み込み
    • .lines で行ごとに取得。 for を使う
  • 文字列 .IOIO::Path インスタンス
    • ファイルハンドラにも使える。同じ効果
    • IO::Path はファイルの情報を提供する .e .d .s
  • zef コマンドでモジュールを管理できる
  • 環境変数%*ENV
  • モジュールの作り方: mi6 を使え
  • 参考文献
    • perl6intro.com/ja 、 docs.perl6.org
  • まとめ

Perl to Go / xaicronさん

  • 半年くらい go を書いている (Perl は 10 年くらい)
  • スライド 150 ページくらい (本当は250ページくらいになる予定だった)
  • Go で Web アプリケーションを作る話
  • なぜ Go ?
    • オンプレは最近流行らない
    • コンテナでアプリを動かす
    • コンテナは低スペック。たくさん並べる
    • 高速、メモリ効率が良い言語が必要
    • Go は Java, C に匹敵する言語
    • コンテナのサイズを小さくすると、コンテナの起動速度が上がる
    • go だとビルドして入れればいい
    • バイナリがあればランタイムが要らない
    • goroutine によって効率的にCPUとメモリ空間を利用できる
    • オンプレでも有利ですね
  • CLIとしてみたGo
    • コンパイル速度が早く、手元でスクリプト感覚でコードを書ける
    • ロスコンパイルが簡単。コツはいる。バイナリが簡単にできるので公開が楽
    • 利用者から見ると、数十MBのファイルを落とすのは苦ではなくなった
    • まとまってダウンロードするほうが楽
  • (本当は流行ってるから)
  • Goの辛さ
    • CPANがない
    • $GOPATH から逃れられない
    • ライブラリの管理方法が難しい
    • オーサリングツールがない
  • goのエコシステムはgit (CPANじゃない)
    • indexerがない。googleにインデックスされている(ググれ)
    • github のレーティングを見る
    • ソムリエが会社に必要
    • github.com でググるのがいい
    • 2019 年中に Module Indexer を作るらしい
    • CPAN Testers 的なものもできる
    • ライブラリのミラーも (githubが落ちても大丈夫)
    • Go 1.13 で対応 (2019年8月?)
    • minicpan 懐かしい
  • $GOPATH の下で開発を行う必要がある
    • Perlとかは好きな場所で開発できる
    • Go は守らないと難しい
    • Go 1.8 以降は $HOME/go がデフォルト
    • Go 1.12 の go mod$GOPATH を木にしなくてよくなる?
      • バージョニングされてないけど、大丈夫?(githubのマスタとってくる)
  • go get bin/ の下に実行ファイル、 src/ の下にソース
  • ライブラリの管理方法が難しい
    • master の HEAD を取ってくる
    • go1 というブランチがあるとそれをみるが、ほとんど浸透していない
    • そもそも stable なの?
    • version 管理できない。そもそも version 管理されてない
    • go mod で semver (セマンティックバージョニング) を使うようになるよう
  • WEB アプリケーションを書くときは go get 使わない
  • ベンダリングツールはたくさんある
    • 最終的には go mod
    • glide dep go mod
    • vgogo mod なので要らない
  • オーサリングツールがない
    • なにもないところから始める必要がある
    • Perl には Minilla ExtUtils::makeMaker とかあって便利だった
    • go mod で解決する?
  • ライブラリの扱いで1~2日ハマった
    • しかも、今後も変わっていく
  • 変数は camelCase で指定する
  • 変数に型がある。別の型にはできない
  • 配列とスライスがあるが、スライスのみを使うのでスライス
  • var で型を指定するか := で型を推論させるか
  • 文字列は UTF-8
  • slice []string() 、 map map[string]int
    • map はネストしたりすると記述量がめんどくさい
    • ハッシュより struct を多く使うようになった
  • perl は dualvar で複数の型をぶちこめて楽しいのに
  • 関数は PascalCase だと Public 、 camelCase だと private
  • ... が可変長引数
  • 関数が複数の値を返せる
  • 関数を変数に代入したり、関数を返したり、引数として渡したり
  • go は perl とおなじで exception クラスがない
    • 例外は panic() で発生、 recover で受ける
    • go は null のことを nil と書く
    • panic は推奨されない。コーディングミスとかだけ
    • リクエストの一番外側で recover するくらいが良い
  • エラーを戻り値で返すことが推奨
    • 複数の戻り値を書けるので
    • error インタフェースか、 bool で返す
    • file, err = os.Createerr != nil でエラー処理
    • log.Fatalf は終わるので return は不要
    • defer file.Close() などとして終了処理
    • エラーを伝搬させていく書き方をする
    • 関数はほぼエラーを返す
  • deferPerlScope::Guard のようなもの
    • ただし、より貧弱 ( dismiss はできない)
    • スコープを抜けたときではない。関数を抜けたとき
    • スコープの代わりに無名関数が必要
    • if のスコープで defer しないように注意
    • file.Close のエラー処理は本当はしないといけない
      • defer へ無名関数を指定してエラー処理。面倒
  • gorutine は説明すると長いので1ページまとめ
    • go func() するだけで別スレッドが走るので簡単
    • チャネル channel でメッセージのやり取り (PerlAnyEvent Coro )
    • 詳しくなるのは時間がかかりそう。オライリーからgoの並列の本が出ている
  • context.Context
    • データを一連の処理で引き回す
    • タイムアウトの検出。ライブラリは早期リターンする(はず)。ロールバック処理できたり
    • Amon2 Catalyst と似たような概念
  • package の仕様
    • コアモジュール net/http のようにすっと書ける
    • そうでない場合は github.com/jmoiron/sqlx のように書く
    • Perlでは常にフルパッケージ名
    • 使う場合は、末尾のみ利用。汎用的な名前にすると被りまくる
    • 例: xaicron/http とか作ると net/http とかぶる
    • Pythonas のように別名をつける。でも、かぶるとイラッとする
  • packageのスコープ
    • Perlはファイルスコープ
  • あと5分
  • if はカッコが要らない
  • range 使ったり
  • 軟弱な while はない
  • 悪名高き switch
    • break がいあらないので、多少は安心
  • go は goto がある。 goto がない言語は辛い
  • Struct 構造体 一番重要
  • Interface
    • java と違って、クラスと紐付かない
    • インタフェースを満たしていれば、自動的にコンパイルが通る
    • インタフェースにメソッドを実装しすぎると辛い
    • 1~数個にして細かく作るといい
  • formatter がたくさんあるのは便利
  • 2分でAPIを作ることは不可能
  • net/http はクライアントにもサーバにもなる
    • 立ち上げるだけで gracefull shutdown , http2 にも対応した高性能サーバが
    • middleware にも対応している。玉ねぎの画像
    • gracefull shutdown はちょっと長い
  • go の DB アクセスは libmysql 使わず全部自前
    • コネクションプール・・・貼りすぎてしまう問題
    • SQL叩くの辛いのでラッパー
    • トランザクションマネージャーもあるよ(作ったよ)

Perl5の静的解析入門 機械と人間双方の歩み寄りによる平和編 / macopyさん

  • PPR.pm : 正規表現Perlコードをパース
    • 業務での利用
    • 人間にも機械にもわかりにくいプログラム
    • Perlに静的型を注釈、PPRから読み込む
  • 骨折経験が豊富です
  • 業務時間に書いたスライドです(カヤックさん)
  • 静的解析とは
    • コードをただの文字列として扱う : 実行しない
    • プログラム内のパッケージ名を一致しているか、 /\Apackage / 正規表現で引っ掛ける
    • 改行があるだけで詰む (CPANのインデクサを避けるために use に改行を入れるとこ )
  • perlがやることを途中までやって抽象構文木を利用する
    • 字句解析、構文解析 の結果を利用
    • Opcode生成、VM上で実行
    • Perlでは構文解析の結果をもらうのが難しい
    • go/parser go/token go/types go/ast RubyVM::AST などはこの方法
  • コメントなども含め、コードの見たままを扱える
  • 言語機能を超えた表現力が持てる
    • コメント内の型をIDEが使えたり
  • 実行できる状態になるに連れ、情報が抜け落ちていく
    • 静的解析をしたほうが扱える情報が多い
    • トークンの位置、前後のトーク
    • 変数がどこで宣言されているか(関数はstack traceのためについている)
  • 実行せずにコードを扱える
    • 危険な BEGIN を飛ばせる
    • 逆に、 BEGIN で生成しているものは静的解析でアクセスしにくい
  • すべての実行パスを調べ上げられる(場合がある)
    • 型バリデーションは実行するまで動かない
  • Perlの気持ちにならないと静的解析はできない(難しい)
  • 機械の力を借りて安全なコードを書きたい
  • PPI
    • Pure PerlPerl コードを解析する
    • PPI::DocumentPPI::Dumper
    • PPI が生成するのはコードではなくドキュメント
    • PPI が解析した後は、 ' ' ( Whitespace ) ; ( Structure ) が残っている
      • PDOM (パース後のツリー) からコードを書き換えるため
    • 解析するための構造で実行するための構造ではない
    • 遅い。 1,175 行のコードで 6.80/s
    • 一番最初のモジュールなので、広く使われている
  • Compiler::Lexer
    • XSなので速い
    • 最新のPerlの仕様にあってない
    • トークン列が出てくる
  • Perl::Lexer
    • 内部APIを使っている
    • ドキュメントには使うなと書いてある
    • Perl 本体と交渉して、使えるようにするのが本来の流れでは
  • Pattern-based Perl Recognizer
    • Perl コードのトークンにマッチする正規表現のパターン集
    • (?&PerlOWS) のように正規表現が作れる。ゼロ文字以上の空白文字
    • grep defined しないと undef がたくさん返ってくる (PODにも書いてある)
    • (?&PerlBuiltinFunction) はビルトイン my など
  • 例: Data::Validator を使っている
    • 実行時にバリデーションがかかる
    • プライベートメソッド以外できちんとバリデーションしているかのチェック
    • PerlSubroutinDeclaration で関数定義を引っこ抜ける
    • PerlQualifiedIdentifier クォートされてない識別子
    • PerlBlock ブロック
    • 関数名がアンダースコアのものを弾く
    • バリデータの正規表現を作り、バリデータのある部分を引っこ抜く
    • バリデータがないとエラーにする
  • 誤検知 : 引数のないサブルーチン
    • attribute、関数シグネチャに非対応
    • 引数以外にヴァリデータを使っている場合に検知できない
  • PPRは正規表現でコードの一部を引き抜ける
  • Perl::Critic (PPI) , Perl::Lint (Compiler::Lexer)
    • github にコードレビューとして書き戻したりできる
    • 治安がよくできる
  • 人間の歩み寄りが必要
  • (dothis $foo, $bar) の評価
    • (dothis($foo), $bar) dothis($foo, $bar) のどれ
    • Deparse では ($foo->dothis, $bar)
    • 関数定義があれば dothis($foo, $bar)
    • 人間が明示したほうがいいのでは
  • sub f { { hoge() => "fuga" } }
    • 内側の {} はブロック? ハッシュ
    • return を書く、ファットカンマの左辺値を文字列にする、 + をつける、のいずれかで曖昧じゃなくなる
    • return 書いたらいいのではないか
  • 除算、正規表現、デファインドor、は /
  • 「これだからPerlは」「JavaScriptもだよ」
  • コードの記法が揺れているときは、よく考える
  • greppability
    • grep ができるのかどうか
    • ->$method などと書いていると、機械的な置換ができない
    • このメソッドをどこで使っているかを静的解析で抽出できない
    • メソッド名を動的に構築 $meth = "hoge_$bar" は避ける
  • コードを書いて、型が静的に決定するかを考える
    • イミュータブル変数など、モダン言語の機能、制限を入れる
  • use BEGIN など動かさないとわからないものは避ける
    • Moosehas などはそれを解釈する解析機を書けばいい
  • 書くのは一回、読むのは n回×m人
  • 機械にも人間にも優しいPerlコードはPerlのサブセット
  • 人間がルールを遵守するのは難しい
    • 機械に指摘してもらう
    • RubyQuerly
    • PerlPPR でも検知可能
  • Plack->request->param を使わない(複数値を指定したときに問題)
  • ResultSet->search を array コンテキストで受けない
    1. 「クォート内にコードが合った場合は?」
      1. 「マッチすることもある。便利なこともある」
    1. PPR 改行の対応は?カッコの対応など
      1. Perl正規表現はできる。再帰した正規表現が書ける
    1. Perl C++ だとできないのはなぜ?
      1. 実行時に型が決まる。Javaもリフレクションだと厳しい。実行時にしか型がわからない。すべてが Any になって難しい
  • Perlのコードに型を書くためのモジュールが(時間切れなので懇親会で)

エンジニアリング組織論への招待 - 2つのDXと技術的負債論 - / 広木 大地さん

  • 2008 年 mixi、開発部長、執行役員 2015年退社
    • ビジネス書部門大賞受賞
    • ITエンジニアに呼んでもらいたい技術書10選
  • EMFM podcast 、 Qiita
  • YAPC Asia 2010, 2011 年に登壇
  • ビジネス書なのか技術書なのか
    • 離れているものではない
    • それぞれ給料をもらっている
  • 2つのDX
    • DX(開発者体験 Developer eXperience)
    • DX (企業のデジタル化 Digital transformation)
  • どちらもビジネスの一部である
    • 仕事でプログラムを書いているというのは何をしている
  • 骨子
      1. 実現 == 不確実性を減らす。曖昧じゃなく動作するもの
      1. 不確実なものに対する本能がある。良くない行動を取る
      1. それらを防ぐための行動規範
  • 誤差を減らすのがエンジニアリングプロセス
    • プロジェクトの修了見込み プロジェクトコーン
    • 組織 : 社長、部長、課長、社員へと、指示が具体的になっていく
  • 不確実性を減らすのが企業活動、ソフトウェア開発
    • マイクロマネジメント
    • エンパワーメントチーム : より生産的。不確実性に耐えられる
  • 不確実性の2つ
    • 未来 : 実験による仮説検証をする
    • 他人 : コミュニケーションですり合わせる
  • 「エンジニアは否定形から入る」のツイートがバズった
    • 物事を明確にする。境目をはっきりする。そのコミュニケーションが否定と感じられる
  • コミュニケーションとは
    • コミュニケーション能力で採用する、とは?
    • お酒を飲んでワイワイ過ごす能力?
    • お互いの理解していること、していないことの差を埋める。情報の非対称性の解消
  • コミュニケーション能力とは?
    • 常識の距離が近い人ほど非対称性の解消は簡単
    • 常識の距離が離れる : RubyPerl 、趣味の違い
    • より離れた相手とも非対称性を解消できる
  • 同一の目的をもつチーム 10人、同一の事業は 150 人
    • n人いると n 次乗のオーダーになるため
    • 人類の群れのサイズは、 150 - 250 人。ダンバー数(これを超えると群れと認識できなくなる)
  • ソフトウェアとは数理的なもの?
    • 機械が理解できるほど明晰な言語化
    • 立法行為と近い。法律の過程と似ている
    • コミュニケーションそのものをやっている
  • 他人と未来と向き合う必要がある
    • Fight(戦う) or Flight(逃げる)
    • 明日から違う言語で開発しよう、というとき
  • 監視者と作業者で起こる無駄
    • 納期圧力のあるプロジェクトで、不具合やミスが隠される
  • 心理的安全性と責任
    • 心理的安全性 : 危ないときに危ないと言える
    • 責任 : 目的に向かって進んでいく
    • 両方が高いとランニングゾーン
  • ゲシュタルト原則
    • 近い集団、似た集まりを脳が勝手にグルーピングする
    • 席の近い人と仲良くする。趣味の合う人、価値観の合う人と仲良くする
    • 「10階の連中」「エンジニアの連中」個々ではなくグルーピングしてしまう
  • 組織に問題がある。組織をリファクタリングする
    • 人を憎まずバグを憎む
    • 人を憎まず組織の構造を憎む
  • それはポエムでしょう?
    • 「ポエム書いたことないでしょう」
    • 一行でもコードや数式を入れるといいらしいが
    • ソフトウェア工学への無知がある
  • ペアプロ、モブプロは 10-15%の品質改善
    • インスペクションが入るだけで 30%以上の改善
  • コード解析によるバグ予測より、組織構造解析によるバグ予測に効果的だった
  • 生産性、品質、コスト (Q, C, D) : トリレンマ (3つは取れない。ジレンマ)
  • 良いチームの傾向
    • 人数が最小限度、恐怖を克服する方法を知っている、多様性(業種、価値観、ビジネス全体を見通せる)
  • ソフトウェア、組織構造 : リファクタリング対象
    • システム設計は組織の情報伝達に似たものになる
    • 組織構造 == コミュニケーション構造
      • ソフトウェアも同じ構造に変化しやすい
    • 悪い組織構造からは悪いソフトウェアが生まれる
    • 見える、見えない、プラスの価値、マイナスの価値(技術的負債の四象限)
  • 探索、交渉、取引にコストがかかる
    • 市場から手に入れるのか、内部で作るのか
    • ないと死ぬなら M&A するはず
    • 取引コストより内部コストが安ければ買うでしょう
  • 隣の部署にやってもらったほうが安いはずなのに、外注が安いような言い方をすることがある
  • ソフトウェア、組織、どちらの構造を変えるコストが高いかで、どちらになるか決まる
  • ソフトウェアではアーキテクチャと呼ぶ
  • コンウェイ作戦、マイクロサービス : 組織とソフトウェアを合わせる
    • 取引コストの低い組織を作り、ソフトウェアに寄せていく
  • マーケテクチャ、ターキテクチャ : 流行らなかった
  • 良くすることができるとは、交換可能であること
    • 選択肢を持つ側、持たない側 : 権力、依存
    • モテる異性との恋愛、エンジニア求人、属人化した業務
    • システムは時間が経つと交換できなくなる。コントロールの喪失
  • システムのコントローラビリティのレベルがある
    • 仕様、ソースコード、握っているか。個人じゃなく組織で握っているか
    • ホールドアップ状態 : 技術的負債により交換不能に陥る
    • ありふれた経済現象
  • 8割×7割ののシステムが老朽システムがDXの足かせになっている
    • 何百兆円の損失があると政府がレポート
    • ユーザ企業がコントローラビリティを失った結果
  • システムが人質となり、ホールドアップされる
    • 「技術的負債現象」という名前を使ったのはなぜか
    • 非エンジニアからは工数が見えない。非対称性。
    • エンジニアから見るとCTスキャンされた状態の人体を見ている。悪いところがわかる
    • 医者「健康そうに見えたのにあの人死んじゃった」は信じてもらえる
    • エンジニアが同じことを言っても聞いてもらえなかった。コミュニケーションの問題
    • 非エンジニアは技術の構造がわかるコミュニケーションが必要
    • エンジニアから技術的分析を伝える必要がある
    • 見えてしまえば技術的負債という問題ではない
  • 多様性チームから職能型組織
    • コンピテンシートラップ
    • 繰り返す
    • これらの違いを埋めていくことがDXの解消につながる

Perlでも分散トレーシングしたい! - AWS::XRayによる解析とその実装 / fujiwara さん

  • カヤックのSRE、ISUCONの宿題、WEB+DB Press、ゲーム運用系
  • 分散トレーシング
    • 知ってる人は30%、導入している人は数人
    • Dapper論文 Google 2010年
    • 複数言語の分散サービスのパフォーマンスの計測
    • 複数のコンポーネントにまたがる。障害。パフォーマンスの問題がわかりにくい
    • 運用ができない
    • 時間軸でどのコンポーネントが実行されているか、可視化
  • Traceは一個の解析をするためのひとかたまり
    • 複数のSpan (資格) を含む有効非巡回グラフ (閉じた経路がない)
    • Span : 名前、開始時刻、終了時刻、コンテクスト(ID, Trace-ID 親)、Tag、Log
  • 実装
    • Zipkin(Twitter), Jeager(Uber), OpenTracing (仕様)
    • AWS X-Ray
    • 2016 年くらいから世に出てきた。マイクロサービスの出始め
  • トレースの仕方
    • アプリがトレースデータを取得(言語の中で実施)。Agentに投げる
    • サービスメッシュでする
      • DataPlane (例: Envoy) を経由させる。DataPlaneにTraceを任せる
      • 言語などに依存しなくて楽
      • 内部の情報が取れない
  • AWS X-Ray
    • X-Ray daemon デーモン
    • SDK ライブラリ
    • console 可視化
    • マネージドサービス。トレースを送りさえすればO.K.
  • X-Ray デーモンが UDP 2,000 を listen している
    • アプリからデータを投げるだけで良い
    • X-Ray API に届いたあとはマネージド。何もしなくて良い
  • 利点
    • トレースデータは大量に発生
    • SQL大量発行していると、1,000スパンとか
    • アプリから同期通信TCPするとレイテンシが悪化。特に障害児
    • アプリはUDPで投げっぱなしなので、送ったあとは知ったことはない
    • X-Ray が落ちてもアプリは影響を受けない
  • X-Ray では スパン == セグメント
  • X-Ray SDK があります
    • Java, Go, Node, Python, Ruby
    • CPAN 検索してもない
    • 古いプロジェクトはPerl。書くしかない
  • JSONUDPで投げればいいだけ。300行程度
    • 去年の夏書いた
  • capture ブロックで囲むと、それがセグメントになる
  • Plack::Middleware::XRay 勝手にトレースが始まる
  • トレースを仕込むのは面倒
    • SQL 叩いている場所に全部手で突っ込む?
  • Devel::KYTProf
    • DB, LWPなどのネットワーク通信をログに出す
    • Devel::KYTprof::Logger::XRay ロガーを差し替えてX-Rayを送ってもらう
  • ISUCON
    • サーバで動くアプリの高速化、優勝賞金100万円
    • 2018年はカヤックDeNAさんで出題
  • ISUCON 8 本戦問題
  • Perl実装に AWS::XRay を組み込む
    • 初期実装はdocker-compose
    • Dockerfileを書いて、 docker-compose.yml に組み込む
    • AWS_XRAY_DAEMON_ADDRESS 別ホストを指定する
    • app.psgi に 5 行追加して、 XRayを有効に (cpanfileも)
    • 以上でベンチを実行するとトレースが出る
  • トレースの見方
    • レスポンスが遅い部分を見る
    • 平均レイテンシが遅い部分がわかる
    • 遅いSQLが見つかる。メタデータを見ると23万行呼んでいることがわかる
    • LIMIT 1 で完了
    • slowlog でわかるのでは
  • 外部APIも調べることができる
    • 一番遅い外部APIのどこを叩いているかまで特定できる
    • (出題の意図で、遅いAPIを混ぜていた)
    • Devel::KYTProf でログを出せばわかるのでは
  • 外部APIX-Ray を組み込んでみると? (実際はブラックボックスなのでできない)
    • golang なので go SDK を組み込む
    • 外部API呼び出しのヘッダに X-Amzn-Trace-ID ヘッダを付ける必要がある
    • isubank 呼び出しが必要な isucoin リクエストが見える
    • 外部API呼び出しのSQL呼び出しまで、合わせてトレースできる
    • 分散トレーシング
  • プロセスをまたがった追跡の仕組み
    • X-Amzn-Trace-ID1-[timestamp]-[unique_id] という形式のID
    • 受け取ったほうがそのヘッダを引き継ぐ
    • trace ID と 親のセグメントIDを送る
  • 現在の Root Parent が必要
    • 引数を追加するのはきつい
    • capture を書くと、自動的に親が入っている
    • local を使っている
  • local
    • 「あなたが本当に望んでいるのは my のほうでしょうか」
    • ダイナミックスコープ ( my はレキシカルスコープ)
    • ブロックをネストしても、 local は復元してくる
    • 親子関係と相性がいい。グローバル変数なので引数渡しが不要
    • 言語のサポートなので、確実に戻る(例外とか考えなくて良い)
    • Perl便利
  • goの場合
    • context.Context を引数に引き渡す
    • ORM などで ctx を渡せないと厳しい
    • 実際、40箇所くらい関数呼び出しを書き換えた
  • コスト
    • 直接コスト : 利用料
    • 間接コスト : パフォーマンス劣化でリソース増、ユーザ体験悪化で売上減
  • パフォーマンス劣化はない
    • 2ms 程度のオーバヘッド。ほぼオーバヘッドがない
    • X-Ray デーモンに渡さなければ 0.1ms
    • 実際はサンプリングする
  • 毎月の無料枠
    • 10万回は無料
    • すべてのリクエスト取ると 1,000req/sec で 14 万くらい。高い
  • サンプリングしよう
    • 1秒の最初はサンプリング、その後5%をサンプリング
    • response_filter : 遅いリクエストのみサンプリング
  • まとめ
    • 対 ISUCON 最終兵器に有用
    • サンプリングミスると費用が安い
    • AWS::XRay 作った

ISUCON8予選問題作成の裏側 / karupanerura さん

  • ISUCON 8 の予選問題を作った
  • ISUCON の問題を作れるようになるのがゴール
  • ISUCON / ISUCON 8 参加者は半分
    • ISUCON 本戦参加者もぼちぼち
    • 出題者も少し
  • Web アプリケーションを自由にチューニングする
  • 「今夜テレビに出るから落とさないで。仕様書もない」みたいなシチュエーション
  • イベントの席予約。キャンセルも可能
  • 管理画面もある。購買レポートのダウンロード
  • ISUCON2 のテーマのリバイバル
  • 本戦には一回だけ、ほかは予選落ち
    • 出題したことももちろんない
    • どうやって作る?
  • 競技を成立、楽しく、解ける、低コストでの他言語移植
  • 競技とは
    • 一定の規則、優劣を互いに競う
    • ◎ チューニング技術の優劣 ✕ ISUCONで勝てる
    • WEBアプリケーションを高速化する一般的な技術
    • プロダクションコードですべてをオンメモリに載せますか?
    • 普通のチューニングをしっかりやると勝てる問題
  • 競技として成立
    • 目的を阻害する行為を封じる
    • 目的に沿った工夫は許容
    • 優劣を可視化。不正をできないように
    • 技術的アプローチを成約しない
    • カーネル入れ替え、フルスクラッチで書くのもO.K>
    • 金で解決させない
    • プロダクションで使えないアプローチは使わせない (再起動試験の導入)
  • スコア化
    • 優れたもの、優れてないものがしっかりさがつく
    • スコア計算式、負荷
    • 性能の悪いアプリに性能の良いアプリと同じ負荷はかけられない
  • レベルの調整
    • マニュアル指定で負荷をかけると、運営側が決めることになる
    • 自動的に負荷をかける
    • タイムアウトを許容しないと、どんどんレベルが上ってしまう
    • 本戦で導入された シェア機能 による自然なマニュアル設定
  • 完成させる
    • 業務時間の確保
    • マイルストーンを設置。合宿。テストプレイ
    • 集まれる場を用意(毎週なんとなくこの時間に)
  • 楽しい問題とは
    • 単なる作業ではない
    • 工夫の余地がない => 作業スピードの競技になる
  • 解法が簡単に明らかにならないように
    • コード規模大きく、仕様を複雑に
    • 過度な共通化ボトルネックをわかりにくく
    • やり方が一つじゃない状態 (ロックが原因。では?)
    • 静的型付け言語が勝てる、だと面白くない
      • リソースの希少性を調整
  • 解ける問題
    • 解いてみないとわからない
    • テストプレイをしてもらう
  • 低コストでの言語移植
    • Perl Ruby Python Go Node.js PHP
    • 後でガッと移植。純粋に移植する必要がある
    • フロントエンドに処理を寄せる
  • 目的ドリブンで価値観を決める、価値観で善し悪しを決める、大変でも工夫で乗り切る
  • 問題提供は大変だが、面白い。
    • 実際の問題の本質を抽象化して別の形に具現化

多くのCPAN Authorに育てられ、息をするようにCPANモジュールを書けるようになり、そして分かったこと / Songmuさん

  • Mackerel について世界で一番詳しい (ディレクター)
  • 入門 監視はいい本なので買ってね
  • コミュニティに関わって成長した
    • 楽しいことをやっていった
    • 実力よりプレゼンスより。レバレッジ
    • ナッパくらいにはなった。見る人からすると圧倒的だが圧倒的上もいる
    • 無限に成長できるといい
    • Perlとの出会い、関わり方
  • 昔話から、エンジニアのキャリアについて考える
  • マネージャー業をやっている
  • 多くのCPNAモジュールをあげる
    • App::tmclean
    • 牧さんとYAPPOさん、songmuさんが人探し
  • 早く書けるのがPerl
  • 日本人7位のCPAN Author
  • 1987年にPerlが生まれた
  • SIer でITにうつった。転職活動難航。25社で2社。
  • 2010年の転職活動。ここでも難航。カヤック
    • スーパーエンジニアとの仕事
    • コミュニケーションとの関わり
    • 2012年、初登壇
    • 2014年、はてな社入社
    • 2015年、年間20回以上登壇
  • 発信することが大事だった
    • 2005年からBlog
    • Movable Type -> Riji
    • 7~8年でブックマークがつくようになった
    • ずっと続けて、メディアを育てる
    • デザインを見てもらってわかる。コンテキストを前提にした発信
  • 恥ずかしいアウトプット
    • dir 使えないから ls を作った話 ( readdir がある・・・)
    • 2009 年に TortizeSVN が使えずに Mac 買って捨てた事件
  • CPAN Author
    • Math::CheckDigit
    • Git::Repository : git 操作のperlモジュール
    • Archer : PRを初めて送った
    • Redmine::Chan : YAPCトーク後にメンテ券をもらった
    • Redis::hiredis : 海外の方への初PR。初めてXS
    • Minilla
  • 学び
    • OSSはバグが有る
    • 英語喋れても技術レベルは上ではない
    • CPANモジュールは使っていこう
  • L ドキュメントを書いていたら、好意的に受け止められた
  • cronlog のkazuhoさんはすごい
  • App::RunCron
    • Perl限定、重厚
    • Go移植。 horenso というcronのラッパー
  • メンテナ権を譲ったり
  • Rijiが使われていたり
  • Daiku
    • Rake ライク
    • skajiさんとの出会い ( cpm 作者)
  • CPANにモジュールをあげるのはなぜ?
    • あげたかった → 仕事をしていると普通にやるよね
    • プロジェクトコードを簡単にするため
    • 黒魔術をモジュール側に閉じ込める
    • 世界が広がったり
  • CPANモジュールの強調、後方互換を大切にするのも良い
  • 主体的に関わることが大事
  • OSSにするのが前提だと、設計がきれいになる
  • Authorは人間なので、信頼関係で開発のやりやすさが変わる
  • CPAN Authorになる
    • 移植、メンテナンスの引き継ぎ
    • 車輪の再発明を恐れない。時代は変化する
    • CPAN Author は神様?
      • 完璧ではない。人間臭い。間違う
  • OSSは使うことだけでも貢献。質問、疑問も貢献。
  • 関わっているソフトウェアを良くする == 世界が良くなる
  • 社外のエンジニアと交流した経験
    • Mackerel のマネージャー
    • fujiwara さん、kazeburo さんがお客様なのはやばい
    • Mackerel の OSSプロダクト。User Group Slack では日本語可

Lightning Talks

Perl6正規表現バトルの裏側 / Shuya Motouchi さん

  • Perl6とは
    • 使える人がいない
    • alpineイメージがない。インストールが大変
  • 正規表現を知らなかった
  • スピードバトル
    • あまり差が出なかったのが失敗
    • 基盤にしていた OpenFaaS
  • ベンダーがやってくれる
    • k8s 上で動く。いろんなフレームワークに対応
    • docker で動き、標準入出力に対応していれば動かせる
    • Web のエンドポイントが楽
    • Docker が楽
    • Kubernetes のしんどいところの隠蔽
    • チュートリアルがある。 kenfdev さんが日本語訳
  • ごーん

Perl入学式2018年度の報告 / OGATA Tetsuji さん

  • Perl入学式の教頭先生。6年目
  • Perlの初心者向け勉強会
    • 大阪、東京、福岡、沖縄、札幌。7年目5拠点
    • 出張版やったり
  • pappix さんが大阪ではじめたもの
  • papix 校長が勇退
    • 旅に行きたい ANA修行
  • 大阪の梅田駅近郊の会場探したい
  • メイン講師 sironekotoroさんへ
  • 東京 : MSYS2が環境
    • ノンアルでピザを食べるようにしている
    • ピザの注文だけしている
    • ピザーラのロゴはPerlのP
  • サポーターへお題を出す
  • sironekotoroさん 採用の内定をもらったらしい
  • キッカソン
    • 合宿
    • 大阪、札幌では災害に負けずにやった
  • Perl書ける人を育てます

npmという次世代CPANパッケージマネージャの紹介 / aereal さん

  • cpan / cpnaplus / cpanminus / carton / cpm たくさんある
  • cpanfile で依存関係を書きますね
    • cpanfile.snapshot をバージョン管理
    • git リポジトリを指定したいことがある。できないっぽい
  • distごとに fetch 先を指定できない
    • cpnam はできたが、 cpanfile には書けない
    • carton はリポジトリ指定はできない
    • 提案するなら歓迎
  • npm i -S git のリポジトリ指定ができる
    • 汎用的な仕組みに見えてくる
    • package.json さえあればうごくでしょう
  • npm install でモジュールを落としてこれるデモ
  • 依存関係は・・・akiym さんのトークに更に詳しい情報

??? / 八雲アナグラ さん

  • Perl1.0に対する偏見
    • 95% は古い
    • perl1.0 は emacs より新しい
  • golang で書き換えると新しい
  • go / goyacc / go
  • c2go はエラーで死んでしまった
  • golang でポインタ、アドレス演算が厳しい
  • yaccのデバグトレースは辛い
  • 無駄な処理が多い、名前がわからない、charの下位ビットのフラグ、資料がない、goto多用
  • マクロ使ってない、ラリー・ウォールのコードなのでテンション↑
  • 一週間ではできなかった
  • これからのgoPerl1.0に期待

自走するプログラミング入門者の探し方 / 門松宏明 (note103) さん

  • 誰にも言われずにコードを書いている人のこと
    • モチベーションの源を見つけたい
  • 未経験者に教えるときにうまくいく人
    • 興味をもつかどうか
    • 馬を水飲み場に連れていけるけど飲ませられない
    • 向き不向き
  • 自走する人 == 向いている人
  • フリーランス編集者からPerl入学式へ参加
  • ITの会社に転職した
  • 自走するプログラミング入門者 == 私
  • 一人二役。自分に問題を出す
  • 自分で課題を出して、機能をどんどん増やす
  • どこにいるのか
    • アウトプットしている。ブログ、LT
  • なんでアウトプット?
    • メモ
    • 見知らぬ人への手紙
    • 自慢
    • 恥ずかしさが薄れていく。やりたいことがでてくる
  • 「才能は消して埋もれない」もりひろしさん
  • アウトプットしている人のモチベーションに着目しよう

Perl meets AWS Lambda / moznion さん

  • AWS Lambda
    • 15分迄走らせれる
    • サーバレス
  • AWS Lambda にあれがきた
  • 任意のランタイムをLambdaで動く
    • bootstrap を入れたzip
    • AWSプラットフォームとやり取り
  • Perlを動かしたい
    • aws-perl-lambe-layer
    • 年に4回Perlを動かしたい
  • bootstrapを書き、LambdaのDockerコンテナに入れるだけ。シンプル
  • carton friendly 、 ビルド済 Layer 、リージョンすべてサポート
  • dependency を local 以下に vendoring
  • zip でまとめる
  • App::Perlambda
    • 簡単に使う CLI
    • dist, create, update に対応
  • func.zip を自動生成、そのまま起動できる
  • ごーん

Perl Community への報恩感謝 / tokuhiromさん

  • Perl好きな人、仕事で使っている人、メインな人 : ぼちぼち
  • 学生時代はニューラルネットワーク
    • Pythonが主流(海外では)
    • LLで行列計算ができるのは numpy だけ
    • 就職でPerlを書き始めた
  • CTOがエッジだったので、会社もPerl
    • Shibuya.pm : 勉強会が少なかった。超人気勉強会
    • livedoor、Blog、wikiが流行っていた
    • Blogなどはperlで書かれていた
  • 着メロ、ポイントサイト、など、今は滅びたものをやっていた
  • 営業第一。早く物を立てて売りを立てるスタイル
  • 早く作るコツ
    • ライブラリを書く
    • もっと良い実装、いいインタフェースになるのでは
    • datetimeの引数が冗長とか
  • リリースしてすぐ終わるサービスは多かった
    • 最近は、数ヶ月作って、じっくり育てるのが増えた
    • マーケティング・リサーチなどなかった
    • リリースすらできないことも
  • モチベーションの維持
    • サービスが閉じるのは寂しい
    • 新しいチャレンジを必ず入れる (ミドルウェア、ライブラリの導入)
    • サービスがなくなっても、得たものはあるように
  • ライブラリ、ソリューションの不満をコードで表明したかった
  • PSGI/Plack
    • HTTP::Engine のリプレース
    • YAPCの一週間前
    • なぜリプレース? : ライブラリだった。仕様と実装を分離したい
    • miyagawa さんのフライト中に終わらせた(徹夜コーディング)
    • トークの一本を勝手に差し替えた
  • Amon2
    • WAF 。高速、シンプル
    • Catalyst は起動が遅い。開発サイクルを早くしたかった
    • Sledge (livedoorフレームワーク) が気に入らなかった
      • 品質は良い
      • 社内リポジトリでは直ってることが多かった
      • オープンな開発体制が欲しかった
  • Teng
    • DBIx::Skinny がいまいちだから作り直すぞという話になった
    • CDBI/DBIC への不満
      • CDBI はキャッシュで互換性が壊れた
      • DBIC は複雑なクエリの組み立てが可能
        • SQLが想像しにくい
        • メンテナンスが難しいコード
        • SQLを手で書きたい。grepでクエリを見つけたい
  • Furl
    • LWP::UserAgent がデファクト
    • 高速なものが欲しかった
    • 東工大YAPC : 真っ昼間からビールを飲んで餃子を飲みながら、技術的な話をしていた
    • マイクロサービス的な試みが始まっていた
      • LWP::UserAgent が遅すぎた。低レベルのAPIが必要
      • LTで、作りたい、って思いだけ語った。泥酔。
    • 翌日から皆でコードを書き始めた。1ヶ月で完成
  • Text::Xslate
    • XSのテンプレートエンジン
    • 開発初期から口を出した
    • Template Toolkitデファクト
    • 速いときは clear silber を使っていたが、使いにくかった
    • gfx さんがとにかく XS を書きたかった → 書いてもらった
  • 問題があるよというと、寄ってたかって解決する文化
    • 野生のPerl Hacker がどこからか集まって、解決していく
  • Effective Perl
    • Software IC
      • 複雑な電子回路が埋まっている
      • 複雑な機能を持ったパッケージが組み合わされる
      • コードの再利用をしたい人がたくさんいる文化
      • 転職した先で同じコード角のだるいからオープンソースにしていた
  • CPAN はちょっとしたものでもアップロードしていい
    • 100 ~ 200 行。手近なところから始められる
    • CPANは幼稚園児の砂場じゃない」とはCatalystプラグインの話です
    • ingy.net さんとかはやばいバイナリ上げまくってるし
  • OSS活動したいというモチベーションではない
    • OSSに不満があるからコントリビュートする
    • githubの草を生やしたくなる。が、それだけではないほうが気が楽
  • コミュニティは利用するもの
    • フリーライド人間は死すべき? お客さん気分で来られると困る?
    • 気負う必要はない。コミュニティの一員であることを思っていれば貢献でしょう
    • ライブラリを利用、Perlを利用、ライブラリはないのかTwitterなどで聞く、挙動が仕様なのか聞く
    • 自分で書き上げるのが大変なライブラリの開発に仲間を巻き込む(競合他社とかに)
  • コミュニティへの貢献
    • ブログを書く。qiitaでもよい。
    • Twitter だと引っかかりにくい。
    • 特にPerlは古い情報が引っかかりやすい
    • 教わったことをブログに書いてまとめる
    • イベント参加レポート。盛り上がりをアピールする
  • 初心者のサポート
    • チャットでの質問に答える
    • 正規表現どう書けばいいんですか」「perldoc perlre」みたいなやり取りは多い
    • 凄腕のハッカーじゃなくても答えられる
  • 懇親会でいろいろな人に話しかけて交流すると良い
  • カンファレンスに参加する
    • 日本人は真面目に話聞きすぎ
    • ディスカッションしたほうがいい
    • 1日中ロビーでコード書いてるだけのおじさんでもいい
  • Issue をあげる
    • バグレポートがないとバグは治らない
    • Vote も立派な貢献。スターを付ける
    • metacpan にもレーティング機能ある
    • Twitter で down vote を先導したりはやめましょう
  • コードを書く
  • perldoc.jp のリニューアル
    • 15年前にmiyagawaさんが始めた。飽きた。メンテナンス止まった
    • perldoc.jp のドメインをもらって作り直した
    • めちゃくちゃ時間がかかる貢献。おすすめはしない
    • 去年、一昨年は1名だけだった。翻訳できる人は貢献を
  • FrePAN
    • 最新バージョンがRSSで配信されるサービス
    • CPAN Module Upudates が自宅サーバの故障などで止まったのがきっかけ
    • metacpanに同じ機能が入った。だいたいmetacpanでできるようになった
  • 海外への渡航支援
    • YAPC::NA に参加してきた
    • みんな自由にしてたり、Hiって挨拶してたり
    • LTで踊ったり壇上でバンド活動したりしてる
    • 牧さんにコミュニケーションをとるために送り出された
  • Perl書いてないのでは?」
    • ここ2,3年はPerl書いてない
    • やり尽くした。ORM, WAF, Template Engin だいたい作った
    • Javaやるか聞かれて Java を始めた
  • How to become a hacker の世代
    • ハッカーは複数を常時使える状態をキープしておくこと(1つだとプログラマですらないかも)
    • いっぱいいろいろな言語を書けたほうがかっこいい(ですよね?)
    • PHP Conference, Python Conference にも登壇している
    • django が流行る前に django の勉強会を開いたり
    • 他の言語を取り入れてPerlでの開発をよくしたい
    • すごいPerlが好き、というわけでもない。仕事で初めてここまで来てしまった
  • Perlは領域を広げすぎた?
    • レポートをフォーマットするための言語。テキスト処理言語
    • 0 "" が falsy 、 wantarrayAWSGoogleSDKを出してくれない(深刻)
    • 正規表現リテラルs///e$___DATA__ 、便利
    • CSVファイルの先頭に __DATA__ をつけて、適当な処理書くのは便利
  • sed awk より高機能。 ruby では足りないかな
  • みんなと一緒にHACKを楽しんできた
    • いろんなPerl Hackerにお世話になった
  • Future Perl Community is You
    • ここにいるみなさんが、コミュニティを盛り上げて欲しい

クロージング / kfly8 さん

  • 五反田.pm の人。YAPCは 2011 年から
  • Twitter やブログに楽しかったことを書こう
  • ベストLT賞 (COLSISさんの独断で)
    • moznionさん (勇気が出て、Perlでやってみようと思った)
  • Best Talk Award (投票で)
    • songmuさん (ほっこりした気持ちになりました)
    • 本気で狙ってた。話したいことが多くて困ってた。嬉しい(号泣)
  • スポンサー様の紹介 (今回はすべて読み上げ)
  • 個人スポンサーの紹介 (アイコンのみ)
  • ゲストスピーカー、座談会、トークの紹介
    • 47 トーク応募、 29 トークが採択
    • 意外と Perl モンガーが元気だった(おじいちゃん扱い)
  • 384名が参加(90%)
  • 37人のスタッフ (写真撮影)
  • 次の YAPC::Japan は?
    • 募集中です
    • 「島根でやろう」「総本山で」「キーノートMatzさんで」
  • YAPCにもいろいろある
    • yusukebeさんがYAPCをやったあと 2014年
    • moznionさん、かるぱさんとどうしようか話していた。やりたいと言った
    • 1,000人規模は厳しいからと、断ってしまった
    • 自分なりに今できる最高のYAPCができた
    • この経験が、今後何かを作る人の後押しになればいい
    • 次のYAPCをやりたい人は話しかけてね
    • 島根も含めて
  • 懇親会は「まだ」受付可能です
  • Thank You