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

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

minillaは便利

songmu さんの WEB+DB の記事を読むのが良い。

gihyo.jp

リリーステストで、

Hoge.pm requires 5.010 due to explicit requirement 

で死んだときは Perl version 指定が正しいか確認する。 // とか使ってると 5.8 系はサポートできないというか、流石に 5.8 系は平成半ばにしてすでに終わっているのではないか。

xt/minilla/spelling.t ......... skipped: no ~/.spellunker.en   

が出てたときは touch ~/.spellunker.en するとPODのスペルチェックもやってもらえる。

CircleCIのsave_caheするPATHとdocker imageの相違

.circleci/config.yml に以下のように書いておいたら、ある時からキャッシュが効かなくなってハマった。

version: 2
jobs:
  build:
    docker:
      - image: perl:5.28
    steps:
      - checkout
      - restore_cache:
          key: cacheminil-v1
      - run:
          name: Install Minilla
          command: |
            cpanm Minilla
      - save_cache:
          key: cacheminil-v1
          paths:
            - "/usr/local/bin"
            - "/usr/local/lib/perl5/site_perl/5.28.0"
..以下略..

正しくは以下。いつまでも 5.28.0 のままではないのだ。

          paths:
            - "/usr/local/bin"
            - "/usr/local/lib/perl5/site_perl"

本当は - image: perl:5.28.0 を指定したいところだが、残念ながら https://hub.docker.com/_/perl を見てもない。

mariadbのdokcer imageの10.2と10.3でmysql.dbが違う

https://hub.docker.com/_/mariadb

10.2 の方では、 MYSQL_USERtest_ データベースを作れない。

mariadb:10.2mysql.db

MariaDB [mysql]> SELECT Host, Db, User, Create_priv FROM db;
+------+--------------+----------+-------------+
| Host | Db           | User     | Create_priv |
+------+--------------+----------+-------------+
| %    | hogehoge_dev | hogehoge | Y           |
+------+--------------+----------+-------------+
1 row in set (0.00 sec)

mariadb:10.3mysql.db

MariaDB [mysql]> SELECT Host, Db, User, Create_priv FROM db;
+------+--------------+----------+-------------+
| Host | Db           | User     | Create_priv |
+------+--------------+----------+-------------+
| %    | test         |          | Y           |
| %    | test\_%      |          | Y           |
| %    | hogehoge_dev | hogehoge | Y           |
+------+--------------+----------+-------------+
3 rows in set (0.000 sec)

なんで違うのか調べてもわからなかった。 mariadb:10.3 の挙動が意図的なのかデグレってるのかも。

【朗報】健康になるために酒を辞める必要はなかった

前回の健康診断で、高脂血症のため要治療というショッキングな結果が出た。どうせ医者に行けば禁酒しろと言われると思い、2018年は完全に酒を絶った。本当に一滴たりとも酒は飲んでいない。

そして一年後の健康診断の結果がこちら。

f:id:hiratara:20190212211225j:plain
健康診断の結果

変わってないよ! 禁酒しても健康にはならないという貴重な実験結果である。

辞めるべきだったのは酒や食物 1 ではなく人生だったようだ。病院へ行きます。


  1. 同様の理由で肉類を経って7年、毎朝納豆を摂るようにしている。平日の昼食を COMP に変えて1年。カフェインも秋頃から摂るのを止めた。

django.urlsのコードリーディング

django ではURLのルーティングを django.urls パッケージで処理している。このパッケージのソースはなかなか読みにくいので、読むための手がかりを記しておく。

バージョンは2.1を仮定していることに注意1

クラス階層

django.urls パッケージでは継承もインタフェースも使っていないダックタイピングの見本のようなコードになっており 2 、この点が読みにくくしている一番の要因である。しかも、歴史的な都合なのか、クラスの命名規則にも致命的なわかりにくさが存在している。まずは主要なクラスの構造を説明することで見通しを良くする。

ゾル

いちばん重要な概念はリゾルバである。リゾルバは自分が解決すべきURL ( PATH_INFO )と、その解決方法を知っているデータである。 resolve() メソッドを提供し、入力されたURLに合致するビュー 3 を返す。リゾルバは木構造をなしており、以下の2種類がある。

URLResolver は他のリゾルバを含むリゾルバである。最上位のリゾルバは URLResolver となる。また、 path 関数で include を指定したときにも生成される。

一方、 URLPattern は末端に位置するリゾルバで、ビューを保持している。 path 関数でビューを指定したときに生成される。

「自分が解決すべきURL」は、パターンクラスによって表されている。

パターン

パターンはリゾルバに付属する。URLが自分が扱うべきものであるかを判定し、さらにビューに必要なパラメータを抜き取ることができるクラスである。 match メソッドを提供し、マッチ後に残ったURL、抽出したパラメータ ( args または kwargs )を返す。以下の3種類があるが、 URLPatternはパターンではない ことに注意する。

RegexPattern はおそらく django 1.x 系の頃使われていたもの。今でも re_path によって生成することはできるが、利用する必要はないだろう。

RoutePattern が通常使われるもので、 path 関数を使ってパターンを記述すると生成される。結局入力されたパターン文字列は正規表現に変換されるが、 re_path のように正規表現で直接記述するよりはわかりやすい記述が可能と言えよう。

LocalePrefixPattern は特殊なもので、 i18n 対応でURLの先頭に言語 /ja/... /en/... などをつけるときに使われる。マッチする文字列は現在の言語設定によって異なる。例えば、現在の設定が日本語の場合、 ja/ という静的な文字列にマッチするパターンとして振る舞う 4 。このパターンを含め、URLの i18n 対応は無理やり突っ込んだ感がかなりある。例えば、このパターンは最上位のリゾルバにしか指定できないが、その判定も include を使った構築時に 配下となる予定のリゾルバがこのパターンを使っていないかをチェックする と言っただいぶ強引な方法で判定している。後、URLの先頭に含まれる静的な文字列 ja/URLの先頭に含まれる文字列から決まったりする のだが、卵が先か鶏が先かよくわからない。国際化対応の実装は他にやりようがなかったんだろうか・・・。

resolve : 順方向の解決

与えられたURLを処理するビューと呼び出しに使うパラメータを得るための resolve 関数のコードを見ると、 最上位のリゾルバに依頼するだけ 。とてもシンプル。他の箇所もこれくらい読みやすければ文句がない。

念のためリゾルバ内の resolve も読んでみると思ったより長くてウッとなるが、実際は 再帰的にresolveを呼び出している だけ。リゾルバのクラスが成す階層構造さえ知っていれば怖いことはない。ただし、ここにでてくる変数 patternパターンではなくリゾル なので注意が必要(自分でも何を言っているかわからない)。

reverse : 逆方向の解決

reverseresolve の逆で、ビューの名前と呼び出し時に使うパラメータからURLを生成する。こいつもリゾルバに依頼すれば終了なのではないかと 淡い期待で読み始める と、全くそうではない難解なコードであることがわかる。なんでリゾルバに reverse させないの・・・マジなの・・・?

reverse 関数内では、リゾルバの階層を潜ってビューを持つ URLResolver を得る 5 。このとき、途中で現れたパターン(を表す正規表現)を拾う 6 。得られた URLResolver新しいURLResolverでラップされる 。この URLResolver は集めておいたパターン(正規表現)に紐付けられるので、新しい URLResolver は完全なURLを再構築できる。

reverse 関数がリゾルバの階層を潜るには URLResolver が持つ reverse_dict という辞書が必要になるが、この辞書は _populate というメソッドが生成する。実質、 _populate が逆引きロジックの本丸になっていると言え、非常に重要な役割を果たすメソッドである。

URLの再構築は、新たな URLResolver_reverse_with_prefix メソッドが行う。なんとプライベートメソッドである・・・。このメソッドは一見長いが、 reverse_dict に入っている再構築に必要な情報を元にURLを再構築し、 パターンに適合するURLができたかをチェック した上で返すだけである。

ということで、URLの再構築に必要な情報は _populate の中で構築される。 _populate の実装を見てこのエントリは終わることにしよう。 _populate は配下のリゾルバをすべて読み込み(再帰的に _populate が呼ばれる)、ビュー名 ( pathname 引数)をキーとする辞書を作る。これが reverse_dict で、 reverse 関数が URLResolver を見つけるために用いる。

そして、この辞書の値がURLの再構築に必要な情報である。値にはパターンの正規表現(検証用)、引数のデフォルト(穴埋め用)、コンバータの一覧が含まれるが、一番重要なのは正規表現normalize関数 で変換したフォーマット文字列と引数リストである。例えば <int:year>/<int:month> のような RoutePattern からは (?P<year>[0-9]+)/(?P<month>[0-9]+) のような 正規表現が作られる が、この正規表現から '/%(year)s/%(month)s/' のようなフォーマット文字列と ['year', 'month'] という引数リストが抽出される。 normalize の実装は真面目に正規表現をパースしており、利便性のためとは言えここまで頑張るか・・・と思わせる実装になっている。この情報を使うことで、 _reverse_with_prefix は URL を再構築できるというわけである。長かった。

ところで、 normalize の戻り値は1つではない。これは、 ?* など、 0 個を許すパターンにおいて、フォーマット文字列の該当する引数があるパターンとないパターンを場合分けする必要があるからだ。URL再構築時にはキーワード引数などからどの引数があるか、ないかをチェックし、利用するフォーマット文字列を決めることになる。また、 .[0-9] などがパターンに使われている場合はいずれの文字を選んでもマッチするので、前者は . 、後者は 0 を含むURLが代表として構築される。


  1. 今のプロジェクトで使っているため。世間では2.2が出ているようだ。

  2. しかも、ダックタイピングを使う必要はまったくない。

  3. djangoのビューは一般的なWAFで言うコントローラであり、 callable な関数またはクラスである。

  4. 静的な文字列なので、 reverse 関数適用時に利用者が言語名を指定する必要はない。

  5. 末端である URLPattern ではないことに注意。

  6. 正確には値の変換に使うコンバータも。

今日は 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

今日は YAPC::Tokyo 2019 前夜祭 の日です

YAPC::Tokyo 2019 前夜祭 LTソン presented by 吉祥寺.pm に参加予定ですので、自分用のメモを残します。

技術イベントスポンサーやっていこう / micchie さん

  • なぜ? → 応援したい
  • Perlは20年前に書いていて、今はgo好き
  • イベントのことを知る
    • ターゲット層、来場者数は調べたかった
  • 年間予算の確保
    • イベントの費用は毎回違う
  • Twitter公式アカウント、代表アカウントでキャッチ
  • 会社のロゴを用意
  • 配布物を用意
    • おやつ、キーキャップ
    • 会社のロゴは嬉しいかしら
    • 自分が欲しいもの
    • メガネが多いのでメガネ拭き
    • チラシお断りステッカー
  • 別の会社のステッカーで上書きされると悲しい
  • Tシャツ、紙コップを用意した
  • デザイナーさんの力が必要
    • 紙コップ用のデザインなど
  • 当日
    • ブースがなければ、楽しんできてもらう
    • ブースがあれば頑張る
  • 目的など明確化
    • 複数の担当者が受け取れる連絡
    • 配布物のニーズを確認
    • イベントも登壇もやっていき

NQPとMoarVMと私 / AnaTofuZ さん

  • Rakudo はどうプログラムされてる?
  • Perl6はPerl6で書かれている
    • NQP という
    • Not Quit Perl
    • Perl6だが、制約がある
  • 束縛 := しかない。 i++ できないけど ++i は書ける
  • フィボナッチ、整数の和、くらいは書ける
  • NQPオペコード。MoarVMのバイトコードと1-1
  • 型が書ける
  • Perl6は漸進的型付言語
  • 型を書いたときと書かないときでオペコードが違う
  • MoarVMは頑張って実行している
  • Rubyish : NQPで作成されたRUbyエミュレータ
  • 文献が日本語も英語もない
  • Perl6が読めないと読めない
  • 関数と () の間に空白入れられない
  • NQP で Perl6 Hack

AWS CDKについて / cohalz さん

  • Perlは一文字も書いたことない
  • AWS CDK 知ってる人、使ってる人は結構いる
  • Cloud Development Kit
  • YAML、CFnで複雑な処理を書くのは辛い
  • CDK Construct Library が便利
  • cdk deploy デプロイツール。そのままデプロイ
  • cdk diff 人間が読める変更
  • IAM、Security Group の変更を警告してくる
    • TCP 80 あいちゃうよ、とか
  • リソースをテンプレ化しやすい
  • エンジニアからは、TS触りやすい
  • Construct Library の中を読むのは難しい
  • 利用者が少ないので情報が少ない
  • CDKのツール群が便利なので使おう
    • ただし、開発者プレビューです

SPVM共同開発の話 / yuki_kimoto さん

  • Static Perl VM
  • Perl 5 の話だから安心して
  • 沖縄で「目があって」
    • Perl入学式東京の講師
  • SPVM
  • Perlは配列が連続してない
    • C風の配列を実相
  • 2人で開発している
    • motxx さんと一緒
    • Perl入学式の受講生だった
  • 共同開発の方法
    • Github issue、Slack、自宅、喫茶店
    • ミーティング後の飲み食い
  • 共同開発したい方は声かけて
    • 目線を飛ばしてもらっても

DBI::TracerでN+1クエリを検知できるようにした / return520 さん

  • 今日も1,000行書いてきた
  • N+1 → SQLがたくさん発行されてサーバが辛くなること
  • 初心者でもそうじゃなくても生み出してしまうもの
    • リリースした途端RDSが停止
    • 動いているけどめちゃめちゃ重いAPI
  • スロークエリログ、計測
    • Perlのコード読みたくない
    • 楽に知りたい
  • ORMを使っている → クエリのばらつきはない
  • Amon2 の BEFORE_DISPATCH でSQLの実行をフック
    • 正規化
    • カウント、ログ
  • DBIx::Tracer でフック
  • 正規化は改行消すだけ
  • さくっとできた
  • このあとめちゃくちゃリファクタした
    • 1日の処理時間が 56.53日減った
  • DBIx::Trace 使うと簡単
  • callerでlog出しやすい
  • リファクタリング楽しい

こんな@INCにまじになっちゃってどうすんの / わいとん さん

  • とりあえず shipit
  • 同僚が古来のロジックに悩んでいた
  • @INCsub {}
    • @INC coderef hooks
    • 動的なモジュールのロード
  • perldoc -v @INC で出てくる
  • Model 層をプラガブルにロード・・・?
    • web app でモデル層をプラガブルにするのはイケてない
    • 普通に use がいいでしょう
  • Ooimachi.pm で相談した
  • おじさん「そういうのを防ぐモジュールを作るべきですよ」
  • Acme::AtIncPolice
  • MoobX で実現できる?
    • observer のトリガは読み込みのみ
  • @INC の codref hooks を予め仕込んでおく作戦
    • @INC に2つcoderefは入れられない
  • おじさん「Tie::Traceがいいんじゃない」
    • 変数の中身を追える
  • Acme大全に入るの楽しみ

YAPC Tokyo 2019前夜祭LTソン / hokkai7go さん

  • Perlのコミュニティがどうなっているのか数年ぶりに見に来た
  • 普段はサービス横断するSRE、基盤構築、
  • 「割れ窓タイム」の対応
    • 放置された不安全な状態のインフラ、ソフトウェア
    • 割れ窓 hokkai7go で検索
  • 横断するSRE
    • 把握すべきことが多い
    • 構成、キーマン、用語、ソフトウェア、最近のリリース
    • 天体観測「はてなスターのコードを読むこと」
  • 社内のことはほとんど文書化されている
  • わからないというと助けてもらえる

行動してから主張せよ / Masahiro Honma

自分のLTでした。

Cプログラム単体テストPerlで楽にする / SHIRAKATA Kentaro さん

  • JNetHack
  • readobjnam() 関数
    • 文字列をアイテムに変換
    • 「2個のりんご」「呪われた-3短剣」「祝福された油の塗られた食べかけのクロマティック・ドラゴンの死体」
    • 1111行ある
  • テストを追加ごとにコンパイル
  • Perl のテストツールで楽にできないか
  • libtap
    • TAPを吐く
    • コンパイル必要、文字列処理必要、楽じゃない
  • Inline::C
  • 標準入力でつなぐ
    • Perl側はテストファイルを読む
    • 標準入出力で
  • テスト重要
  • やり方は一つじゃない
  • NetHackの闇

Calendar::Japanese::Holiday は無事にupdateされました / melonsode さん

  • Calendar::Japanese::Holiday
    • 夜間、休日にコールセンターへ転送するプログラムで利用
  • 祝日業界に激震
    • 5/1 に爆誕、祝日と祝日に挟まれた平日は祝日
    • 2019 年は 4日休日が増え1日減る
    • 2020 年は ゲルマン民族の大移動並に変わる
  • メンテなの kztomita さんにメールを送れなかった
  • 会社のサポートページからメールを送るが、反応がない
  • 万策尽きた
  • nipotanさんがパッチ送っていたが・・・
  • yahoo.co.jp から送れなかっただけ
  • kztomita さんより直したと連絡あり
  • 祝日判定は今年も来年も大丈夫

昨日から取り組んでること / codehex さん

  • VSCode
    • ターミナルとエディタの行き来は辛い
    • emacsにする
  • vscode + emacs key bindings
  • emacs のために Lisp を覚えたい
  • Lisp interpreter を作る
  • p5-Lisp-Tiny 作った
  • カッコだらけ
  • VSCodeじゃん」「みなさんもカラフルな方が見やすいでしょう」
  • VMも作った
  • グローバル変数、ローカル変数、逐次処理、print、四則演算
  • REPLはTerm::ReadLine
  • perl もビルトイン関数

大コンテナ時代を生き残るためのJSONスキーマ / aereal さん

チームが前に進み続けるために僕たちが考えたこと / papix さん

  • トークの宣伝
  • 朝一なので
  • 考えたことシリーズの第四段
  • 対象者
    • スクラムをやってみたい人
    • これからチームにはいる人
    • 開発はコードを書くだけでは終わらない
  • はてな社のカンバンの様子とかも公開します
  • 「時間は」「後2分」「長々話すのもあれなので」

makamakaさん

  • 光る棒を入れている
  • Acme大全の作者
  • 2018年版、電子書籍版もある
  • 選り抜きAcmeさん
    • 30個くらい紹介