- 投稿日：2019-01-26T14:36:02+09:00
YAPC::JAPAN 2019 Tokyo 会場走り書きメモ
YAPC::JAPAN 2019 Tokyo
開催中のYAPC::Tokyoのメモ
誰かが「この資料あったよー」って編集リクエスト来たりしないかなーと思いつつ公開してます。終わった後清書して更新します。
尚コレを書いてる本人はPerl書いてないです。公式サイト: YAPC::Tokyo 2019
opening
テーマ: 報恩謝徳
「報いる方法は人それぞれ」
得た刺激を返していこう周知事項
- ランチセッションが先着150名分
- 電源は3階オープンスペース
ハッシュタグ
#yapcjapan #yapcjapanRoom0 #yapcjapanRoom1
チームが前に進み続けるために僕たちが考えたこと (20min)
papix 氏
資料
hatena blog media
toc向けとは違うtob向けチームだけど連携はしてる停滞感を感じた
- 規格の全容が追いにくい
- ディレクターが全部決めるため
- タスクの進捗状況がわからん愛
- 定例MTGでしか進捗が共有されない
- 余裕がない
- タスクの見積もりがざっくりしている
- はてなブログのステークホルダーがおおい
- ディレクター陣も交渉に大忙し
辛い
アジャイルって?
- 「適応すること」に価値を置く
「全然わからない俺たちは雰囲気でスクラムをやっている」
「兼任スクラムマスターをやろう!」
インプットフェイズ
- 前職の経験
- アジャイル侍
- カイゼンジャーニー
導入設計
腹をくくる
業務開発フローは「変えることは無条件に正しい」
2つの看板
- 要件定義の様子を可視化する
- タスクの状態を管理する看板
デイリースクラム
- 昼会として実施
スプリント計画
最初は1週間なれてきたら2週間スプリントに
僕たちはこうなった
- 開発者の視点も盛り込んで要件定義できる
- デイリースクラムでアラートも出しやすい
- ベロシティに基づいて計画できる!
「頑張ろう まだまだ若い まだまだこれからだ」
ユーザーストーリー
テンプレートを用意しておけば自然と埋まっていくするとやることが見えていく
変化
- タスクの管理
- 当初は分割したタスクをIssueにしていた
- 1つの企画お情報複数に分散する
- → 物理看板に変化
- 相対見積もりを時間による絶対見積もりに
- 相対見積もりは終わりがあると使いやすいが僕たちには終わりがない
- 相対見積もりは使いづらい
- 物理看板
- ユーザーストーリーや開発タスクなど種類ごとに色分け
- デイリースクラムをスタンディングに
- 座っていると副業ができてしまう
- 立ってたくないから早く終わるように
- デイリーは立ってやろう!
- バックログ整備会
- 議論や説明に集中できるように
- 振り返り会
- スプリントをイベントで振り返る
- "感情"を数値化する
- 投票して点数が高い物事に議論する
スクラムをチームにCustomizeして導入できた
「変化し対応し続けない」
「手を動かしたもののみ世界を変えることができる」
# 私とOSS活動とPerl (20min)
前田隼輔 氏資料: 私とOSS活動とPerl
普段はserver side kotlin
0.学生時代
- 生命科学での研究で大量のデータ処理を行うことに
- バイオPerlで解析していた
- 当時は何もわからず取り敢えずOSSを使っていた
1.新卒社会人
- アプリケーションはJAVA
- オブジェクトを覚える
- 運用ではPerl
- 運用作業の発生頻度が微妙
- SQL覚えられない
- JAVAのメゾットチェーン的になのをPerlでも書きたい!
- ここで初めてmoduleの概念をしる
- これでJavaと同じようにかける!
- PerlのO/Rマッパーを作る
- コレを会社でも使いたい
- 初めてGithubにソースコードを公開
- CPAN:Authorになりたい!
- 3年目で称号がほしかった
- SLACK:RTM:BOTを作った
- 初めて公開
- ソースコードのリポジトリに変化
- Star
- PR
- 異なる言語圏
- 言葉以外の情報が大切
- 最後に
- 今作っているもの
- SLACK:RMT:Bot
- duck8823/duci
- GO製CIサーバー
- 特別な設定が要らないCIサーバー
- 「世界はOSS開発者に優しい」
Perl to Go (40min)
xaicron 氏
GoでWebアプリ各流れを知れるといいよね
なぜGoを使うのか
- 昨今オンプレはダウントレンド
- クラウド上でコンテナ上で運用することが当たり前になってきている
- コンテナでの運用ではスペックが低いため軽く高速であることが求められる
- コンテナサイズは小さい方が高速に立ち上がる
- スクリプトライクに使うことができる
- コンパイル速度も早い
- クロスコンパイルが容易にできるので簡単にできる
上記の理由で現代では使いやすい言語だと思う
流行に乗り遅れないためにもPerl MongerがGoを始めたときにハマったところ
- CPANがない
- git repositoryのURLで指定してインストールする
- CPANやGEMみたいな中央集権型のようなライブラリ情報がない
- ライブラリで探すときはGiothubでググる
- → 将来的にModule Indexerを作るらしい
- こんごCPAN Testersみたいなももでるかも?
- ライブラリのmirroも作成予定
- 現状Githubが落ちると何もできない
- 1.13でコアに入るよてい
- ＄GOPATHから逃れられない
- golangは＄GOPATH以下で開発する必要がある
- あらゆるライブラリは$GOPATHいかにないといけない
- 1.8以降は$HOME/go以下がデフォルト
- 1.12で気にしなくても良くなる…?
- 実際は…?
- ライブラリの管理が難しい
- $GOPATH/src以下にクローンされる
- go1というタグがあればそれを見てくるらしいが対応している物が少ない
- gogetでバージョン設定ができない
- 実際はWEB APP開発ではgo getはあんま使わない
- cartonとかが大体
- オーサリングツールがない
- GOにはオーサリングツールの決定版がない
- まっさらな大地でやっていく
- go xxxコマンドを打つMakefileを書く
- minilla
「ライブラリの扱いでハマることが多かった 今後も変わっていく」
GOの言語仕様で学ぶPerlとの相違点
- camelCase
- 型
- 配列とスライス
- スライスは可変長変数 基本はこっちを使う
- 関数名
- PascalCaseで書くとpublicにcamelCaseで書くとprivateに
- 複数の返り値を指定できる
- 関数を代入したり他の関数を渡したりできる
- Errorハンドリング
- Try/cacheはない
- 例外を出すときはpanic()を使う
- Perlでいうdie()
- recoverでキャッチする
- しかしpanic()を使うことは推奨していない
- カーネルやErrorで終わらないといけないときに出す
- 慣習として返り値がErrorインタフェースかboolを返す
- defer
- deferすると関数を抜けるときにfunc()を実行する
- gorutine
- Goを象徴する機能
- go func()で別スレットでプログラムが走る
- 簡単に並列プログラミングできる!
- context.Context
- 特定のgorutineや一連の処理中にデータを入れて引き回したりキャンセル処理を波及させるのに使う
Perl on Rails
GUEST: 大仲 能史 氏
はてなとしてPerlを脱出仕様にも決め手がない
「(この間にRailsを布教できるのでは)」Perl on Railsとは
RailsのいいところをPerlに輸入して布教させたい
Write Less Code
- コードは少ないほどよい
- Locの話
DRY CoCは実現するための手段
RESTful
The 12-Factor App.
はてなPerlの状況
- 「薄いフレームワーク」
- 安全で最小限な実装をプロジェクト内に持つ
レールに載せたい
4年ぐらい前の世界ならRailsは最強最速フレームワークだった
Rake
makeのRuby版
モブプロしてる中Perlプロダクトでrakeを書いてるのがバレた
API REPL
サーバーはJSONを返すAPIがある
- APIの確認にCURLを使ってた
- tokenを取得したりとか大変
- HTTP Requestを発行できるREPLを作成
ACTIVE RECORDE
- 全テーブルに対するクラスを生成
- 弊害
- 複合主キーがデフォルトにない
- プライマリーKeyがないテーブルがある
- migrateしまくって使いやすくしていった
- ER図の自動生成をして不況させていく
Test::mysqld Test::RedisServer
- pral界特有
- ミドルウェア全部入りのコンテナでテストしている
migrate
- リリースのチェックボックスで管理している
- →migrateでrakeタスクを作った
CLI
- プロダクト用のCLIツールを作った
seed
- rake db:seed を作った
- 本番からデータを取ってきて適用する
- 運用会社が別だったのでなにかあるのか対応するために
エンジニア組織論への招待
GUEST: 広木 大地 氏
資料: ２つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deckビジネス書とも技術書とも言われるエンジニア組織論への招待
- 何かを実現することは不確実性を減らすことである
- 不確実なものから人は闘争防御回避取ろうとする
えんじにありんぐ ＝ 不確実性をへらす
- マイクロマネジメント型組織
- エンパワーメ型組織
後者の方が基本強い
- 環境性不確実性
- 通信制不確実性
僕たちっ物事を明確にしたがる
そのコミュニケーションが否定に取られがちコミュニケーションとは
非対称性を解消していくこと
常識の距離が近い人ほど簡単
人数の2乗のオーダーで交流が発生する
ダンパー脳のサイズと群れの大きさが比較したものだいた｀150以上か群れとして認識でできないととされている
他人と向き合うのは怖い
- 攻撃的行動
- 回避的行動
学習を促す心理状態になれば本能を克服できる
- 心理的安全性を高めれば本能を克服できる
- 心理的安全だけが高いとコンフォートゾーンになってしまう
- 脳には似ているものをまとめてしまう機能がある
- → ゲシュタルト原則
- 15階のれんちゅうがー あの部署のれんちゅうがー
- → もんだいは脳の機能が悪いに作用していること
- →リファクタリングしよう
- バグを憎んで人に組まず
- なぜかコード数式がないとポエム扱いされる
- ソフトウェア工学の問題
- 生産性、品質、コストのトリレンマを超える
- トリレンマ ・・・同時に三つ取れないもの
よいチームの傾向
- 関わる人数が最小限におさまっている
- 多様性がある組織構造はコミュニケーション構造と同じになりやすい
→そのため悪い組織構造は悪いシステムを生み出しやすい
- 逆コンウェイ作戦
- マイクロサービシーズ
選択肢をもつ側が強く持たない方が弱い
コントロールの喪失によるホールドアップ現象はありふれた経済現象である
技術的負債は何十兆円という価値になっているなぜ多くのエンジニアは技術的負債現象と呼ばらなければ行けなかったのか
見ることができないという非対称性が問題の根本
システムの見えかた
- エンジニアにはctスキャンに通したように隅々からわかる人体
- 日エンジニアにはなにもなかみがわからない人体
技術の構造がわかるコミュニケーションを取っていく
何をやりたいのかをはっきりさせる
問題に光を当てればそれは技術的負債と呼べないかもしれない
コンピテンシートラップとdx
資料
見に行けなかったけどTwitterで公開してくださった資料たち
当日
- 20歳の僕が経験した Perlエンジニアへの道 - Speaker Deck
- Wazuhを利用した 大統一サーバ監査基盤 - Speaker Deck
- YAPC::Tokyo 2019 GMOペパボ会社紹介 - Speaker Deck
- perl_2019_winter - Speaker Deck
- Perlでも分散トレーシングしたい！AWS::XRay による解析とその実装 / YAPC::Tokyo 2019 - Speaker Deck
前夜祭
- 投稿日：2019-01-26T14:36:02+09:00
YAPC::JAPAN 2019 Tokyo 会場 まとめ メモ
開催中のYAPC::Tokyoのメモ
誰かが「この資料あったよー」って編集リクエスト来たりしないかなーと思いつつ公開してます。終わった後清書して更新します。
尚コレを書いてる本人はPerl書いてないです。公式サイト: YAPC::Tokyo 2019
opening
テーマ: 報恩謝徳
「報いる方法は人それぞれ」
得た刺激を返していこう周知事項
- ランチセッションが先着150名分
- 電源は3階オープンスペース
ハッシュタグ
#yapcjapan #yapcjapanRoom0 #yapcjapanRoom1
チームが前に進み続けるために僕たちが考えたこと (20min)
papix 氏
資料
hatena blog media
toc向けとは違うtob向けチームだけど連携はしてる停滞感を感じた
- 規格の全容が追いにくい
- ディレクターが全部決めるため
- タスクの進捗状況がわからん愛
- 定例MTGでしか進捗が共有されない
- 余裕がない
- タスクの見積もりがざっくりしている
- はてなブログのステークホルダーがおおい
- ディレクター陣も交渉に大忙し
辛い
アジャイルって?
- 「適応すること」に価値を置く
「全然わからない俺たちは雰囲気でスクラムをやっている」
「兼任スクラムマスターをやろう!」
インプットフェイズ
- 前職の経験
- アジャイル侍
- カイゼンジャーニー
導入設計
腹をくくる
業務開発フローは「変えることは無条件に正しい」
2つの看板
- 要件定義の様子を可視化する
- タスクの状態を管理する看板
デイリースクラム
- 昼会として実施
スプリント計画
最初は1週間なれてきたら2週間スプリントに
僕たちはこうなった
- 開発者の視点も盛り込んで要件定義できる
- デイリースクラムでアラートも出しやすい
- ベロシティに基づいて計画できる!
「頑張ろう まだまだ若い まだまだこれからだ」
ユーザーストーリー
テンプレートを用意しておけば自然と埋まっていくするとやることが見えていく
変化
- タスクの管理
- 当初は分割したタスクをIssueにしていた
- 1つの企画お情報複数に分散する
- → 物理看板に変化
- 相対見積もりを時間による絶対見積もりに
- 相対見積もりは終わりがあると使いやすいが僕たちには終わりがない
- 相対見積もりは使いづらい
- 物理看板
- ユーザーストーリーや開発タスクなど種類ごとに色分け
- デイリースクラムをスタンディングに
- 座っていると副業ができてしまう
- 立ってたくないから早く終わるように
- デイリーは立ってやろう!
- バックログ整備会
- 議論や説明に集中できるように
- 振り返り会
- スプリントをイベントで振り返る
- "感情"を数値化する
- 投票して点数が高い物事に議論する
スクラムをチームにCustomizeして導入できた
「変化し対応し続けない」
「手を動かしたもののみ世界を変えることができる」
## 私とOSS活動とPerl (20min)
前田隼輔 氏資料: 私とOSS活動とPerl
普段はserver side kotlin
0.学生時代
- 生命科学での研究で大量のデータ処理を行うことに
- バイオPerlで解析していた
- 当時は何もわからず取り敢えずOSSを使っていた
1.新卒社会人
- アプリケーションはJAVA
- オブジェクトを覚える
- 運用ではPerl
- 運用作業の発生頻度が微妙
- SQL覚えられない
- JAVAのメゾットチェーン的になのをPerlでも書きたい!
- ここで初めてmoduleの概念をしる
- これでJavaと同じようにかける!
- PerlのO/Rマッパーを作る
- コレを会社でも使いたい
- 初めてGithubにソースコードを公開
- CPAN:Authorになりたい!
- 3年目で称号がほしかった
- SLACK:RTM:BOTを作った
- 初めて公開
- ソースコードのリポジトリに変化
- Star
- PR
- 異なる言語圏
- 言葉以外の情報が大切
- 最後に
- 今作っているもの
- SLACK:RMT:Bot
- duck8823/duci
- GO製CIサーバー
- 特別な設定が要らないCIサーバー
- 「世界はOSS開発者に優しい」
Perl to Go (40min)
xaicron 氏
GoでWebアプリ各流れを知れるといいよね
なぜGoを使うのか
- 昨今オンプレはダウントレンド
- クラウド上でコンテナ上で運用することが当たり前になってきている
- コンテナでの運用ではスペックが低いため軽く高速であることが求められる
- コンテナサイズは小さい方が高速に立ち上がる
- スクリプトライクに使うことができる
- コンパイル速度も早い
- クロスコンパイルが容易にできるので簡単にできる
上記の理由で現代では使いやすい言語だと思う
流行に乗り遅れないためにもPerl MongerがGoを始めたときにハマったところ
- CPANがない
- git repositoryのURLで指定してインストールする
- CPANやGEMみたいな中央集権型のようなライブラリ情報がない
- ライブラリで探すときはGiothubでググる
- → 将来的にModule Indexerを作るらしい
- こんごCPAN Testersみたいなももでるかも?
- ライブラリのmirroも作成予定
- 現状Githubが落ちると何もできない
- 1.13でコアに入るよてい
- ＄GOPATHから逃れられない
- golangは＄GOPATH以下で開発する必要がある
- あらゆるライブラリは$GOPATHいかにないといけない
- 1.8以降は$HOME/go以下がデフォルト
- 1.12で気にしなくても良くなる…?
- 実際は…?
- ライブラリの管理が難しい
- $GOPATH/src以下にクローンされる
- go1というタグがあればそれを見てくるらしいが対応している物が少ない
- gogetでバージョン設定ができない
- 実際はWEB APP開発ではgo getはあんま使わない
- cartonとかが大体
- オーサリングツールがない
- GOにはオーサリングツールの決定版がない
- まっさらな大地でやっていく
- go xxxコマンドを打つMakefileを書く
- minilla
「ライブラリの扱いでハマることが多かった 今後も変わっていく」
GOの言語仕様で学ぶPerlとの相違点
- camelCase
- 型
- 配列とスライス
- スライスは可変長変数 基本はこっちを使う
- 関数名
- PascalCaseで書くとpublicにcamelCaseで書くとprivateに
- 複数の返り値を指定できる
- 関数を代入したり他の関数を渡したりできる
- Errorハンドリング
- Try/cacheはない
- 例外を出すときはpanic()を使う
- Perlでいうdie()
- recoverでキャッチする
- しかしpanic()を使うことは推奨していない
- カーネルやErrorで終わらないといけないときに出す
- 慣習として返り値がErrorインタフェースかboolを返す
- defer
- deferすると関数を抜けるときにfunc()を実行する
- gorutine
- Goを象徴する機能
- go func()で別スレットでプログラムが走る
- 簡単に並列プログラミングできる!
- context.Context
- 特定のgorutineや一連の処理中にデータを入れて引き回したりキャンセル処理を波及させるのに使う
Perl on Rails
GUEST: 大仲 能史 氏
はてなとしてPerlを脱出仕様にも決め手がない
「(この間にRailsを布教できるのでは)」Perl on Railsとは
RailsのいいところをPerlに輸入して布教させたい
Write Less Code
- コードは少ないほどよい
- Locの話
DRY CoCは実現するための手段
RESTful
The 12-Factor App.
はてなPerlの状況
- 「薄いフレームワーク」
- 安全で最小限な実装をプロジェクト内に持つ
レールに載せたい
4年ぐらい前の世界ならRailsは最強最速フレームワークだった
Rake
makeのRuby版
モブプロしてる中Perlプロダクトでrakeを書いてるのがバレた
API REPL
サーバーはJSONを返すAPIがある
- APIの確認にCURLを使ってた
- tokenを取得したりとか大変
- HTTP Requestを発行できるREPLを作成
ACTIVE RECORDE
- 全テーブルに対するクラスを生成
- 弊害
- 複合主キーがデフォルトにない
- プライマリーKeyがないテーブルがある
- migrateしまくって使いやすくしていった
- ER図の自動生成をして不況させていく
Test::mysqld Test::RedisServer
- pral界特有
- ミドルウェア全部入りのコンテナでテストしている
migrate
- リリースのチェックボックスで管理している
- →migrateでrakeタスクを作った
CLI
- プロダクト用のCLIツールを作った
seed
- rake db:seed を作った
- 本番からデータを取ってきて適用する
- 運用会社が別だったのでなにかあるのか対応するために
エンジニア組織論への招待
GUEST: 広木 大地 氏
資料: ２つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deckビジネス書とも技術書とも言われるエンジニア組織論への招待
- 何かを実現することは不確実性を減らすことである
- 不確実なものから人は闘争防御回避取ろうとする
えんじにありんぐ ＝ 不確実性をへらす
- マイクロマネジメント型組織
- エンパワーメ型組織
後者の方が基本強い
- 環境性不確実性
- 通信制不確実性
僕たちっ物事を明確にしたがる
そのコミュニケーションが否定に取られがちコミュニケーションとは
非対称性を解消していくこと
常識の距離が近い人ほど簡単
人数の2乗のオーダーで交流が発生する
ダンパー脳のサイズと群れの大きさが比較したものだいた｀150以上か群れとして認識でできないととされている
他人と向き合うのは怖い
- 攻撃的行動
- 回避的行動
学習を促す心理状態になれば本能を克服できる
- 心理的安全性を高めれば本能を克服できる
- 心理的安全だけが高いとコンフォートゾーンになってしまう
- 脳には似ているものをまとめてしまう機能がある
- → ゲシュタルト原則
- 15階のれんちゅうがー あの部署のれんちゅうがー
- → もんだいは脳の機能が悪いに作用していること
- →リファクタリングしよう
- バグを憎んで人に組まず
- なぜかコード数式がないとポエム扱いされる
- ソフトウェア工学の問題
- 生産性、品質、コストのトリレンマを超える
- トリレンマ ・・・同時に三つ取れないもの
よいチームの傾向
- 関わる人数が最小限におさまっている
- 多様性がある組織構造はコミュニケーション構造と同じになりやすい
→そのため悪い組織構造は悪いシステムを生み出しやすい
- 逆コンウェイ作戦
- マイクロサービシーズ
選択肢をもつ側が強く持たない方が弱い
コントロールの喪失によるホールドアップ現象はありふれた経済現象である
技術的負債は何十兆円という価値になっているなぜ多くのエンジニアは技術的負債現象と呼ばらなければ行けなかったのか
見ることができないという非対称性が問題の根本
システムの見えかた
- エンジニアにはctスキャンに通したように隅々からわかる人体
- 日エンジニアにはなにもなかみがわからない人体
技術の構造がわかるコミュニケーションを取っていく
何をやりたいのかをはっきりさせる
問題に光を当てればそれは技術的負債と呼べないかもしれない
コンピテンシートラップとdx
Dive into MySQL Error (40min)
yoku0825 氏
「こんに千葉!」資料: Dive into MySQL Error (YAPC::Tokyoバージョン) - Speaker Deck
Error種類
- MySQLサーバー以上
- クライアントに対するネガティブな反応
- クライアントライブラリーの異常
サーバーからのクライアントに対するネガティブな反応
- 認証失敗
- Error時はErrorパケットを発行する
- サーバーそもそもの異常
- プラグインやサブシステムで拾えるのはある
- サーバーからクライアントに返すやつ
- 概ね1000番代 昔からよくあるからあるわけだし
- エラーが出たらまず何番台かを確認
2k番台なら到達していな可能性が高い
- ごく前れにサーバー側の問題だったりする
- 2002 sockファイルがない
- 2003 tcp接続に失敗
- 同じエラーでもタイムアウトでもタイムアウトさせる箇所によって変化がある
- 2006, 2013
- どこで落ちるかで変わる
- クエリを投げてからつながらなくなる
- クエリ処理中にTCP接続が切れる→2013
- 2059
- 8.0になってからみんなググるあれ
- 8.0からの新規の認証ライブラリだが昔のものでは持っていないのででる
- 1251
- 8.0へMySQLもっと古い物を使うと出てくる
- プロトコルに互換がないことに気づいて出してくる
- libmysqlclient.so
- MySQL Connetor
- Perl Rubyが使っている
- サーバー
- perrorで調べれない
1213番
- デットロックErrorとして有名だが、コレはデットロック思想になったことに対するError
2000番台Error応用
Last_IO_ErrorはOSエラーコードが出てこない
1xxx, 3xxx
- 1251
- SQLステート
- サーバ
perror
- エラーコードを渡すとエラーメッセージのフォーマットを返してくれる
- たとえば1593 Fatal error以外は場合によって変わる
- エラーコードでググっても効果はない
- ググるならメッセージでググったほうがいいよ
「 C/C++は $ ないだけでだたいperl は同じ」
「MySQL Test RannerはPerl製」エラーに触れるついでにエラーログについて
- MySQLエラーログは実はstderrとstdoutがつながってるだけ
めとめ
- エラーにはクライアントとサーバーがあり
- サーバーエラーは物によっては汎用的すぎるエラーがあったり特化してるやつがある
資料
見に行けなかったけどTwitterで公開してくださった資料たち
当日
- 20歳の僕が経験した Perlエンジニアへの道 - Speaker Deck
- Wazuhを利用した 大統一サーバ監査基盤 - Speaker Deck
- YAPC::Tokyo 2019 GMOペパボ会社紹介 - Speaker Deck
- perl_2019_winter - Speaker Deck
- Perlでも分散トレーシングしたい！AWS::XRay による解析とその実装 / YAPC::Tokyo 2019 - Speaker Deck
- CPAN Module Hacks - Speaker Deck
- 20190126_YAPC_TOKYO.pdf - Speaker Deck
- Perl5の静的解析入門 / The static analysis of Perl5 - Speaker Deck
- 綱渡りバッチ脱出大作戦 - Speaker Deck
- Development and practical use of CLI in perl 6
- Development and practical use of CLI in perl 6
LT
- YAPC::Tokyo 2019 Lightning Talks Perl6 正規表現バトルの裏側 - Speaker Deck
- npmという次世代CPANパッケージマネージャの紹介 - Google スライド
- Perl meets AWS Lambda - Speaker Deck
- YAPC::Tokyo 2019 Lightning Talks Perl6 正規表現バトルの裏側 - Speaker Deck
- 自走するプログラミング入門者の探し方 - Speaker Deck
前夜祭