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+localtimeは0
- 通常の言語は、宣言するときに型が決まる
- Perlではあるデータがどのような型で使われるかは、使うときに決まる
- Perlの場合は、コマンドライン引数（文字列）をいきなり数値として使える
- Ruby では型エラーになる (
to_iすればよい)
- Ruby では型エラーになる (
say localtimeの出力はドキッとする (現在時刻の数字のリストが連結されて表示される)- Perl5の特徴「遅延型決定」
- Perl6 では、
subset Fizz of Int where * %% 3というように3で割れる型を作れる- FizzBuzzに条件分岐が要らない
- 型が実行時に決まる。型で分岐する
- 型推論
- まとめ
Perl 6 でのアプリケーション開発と実用 / risou さん
- 若干強めのタイトルにしてしまった
- Perl6で仕事をしたことはない。趣味でやっている
- 文法、Web、モジュール開発の話はしない
- 環境構築 : 公式サイトにある通り
- Perl6には
MAIN()関数がある- 使う必要はない
- 両方使うと、デフォルトスコープが先に実行、その後
MAIN() MAIN()を使うと、コマンドライン引数の型チェックができる- usage が出力される
- multi sub によって、
MAIN関数を引数によって分けることも
- Usageは自動で作られるのか
USAGE()関数を実装できる- 内容を置き換えられる
- ヒアドキュメント
- デフォルトは
$*USAGEに入っている
- デフォルトのUsageの変更は？
#|#=宣言子ブロックで補足ができる#|は関数の前、#=は関数の後- Perl6のpodの機能
- CLIでもファイル操作は使う（よね？）
- 「Perl5 とそんなに変わらないでしょう」「はい」
openで書ける.slurpファイルの中身を全部取る
$fh.slurpはIO::Handdleのメソッド、slurp ""はIOrole が提供する関数closeは必要ない
spurtで文字列を一括で書ける- 行単位での読み込み
.linesで行ごとに取得。forを使う
- 文字列
.IOでIO::Pathインスタンス- ファイルハンドラにも使える。同じ効果
IO::Pathはファイルの情報を提供する.e.d.s
zefコマンドでモジュールを管理できる- modules.perl6.org
useで使える。requireも一応ある
- 環境変数は
%*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
- (本当は流行ってるから)
- Goの辛さ
- goのエコシステムはgit (CPANじゃない)
$GOPATHの下で開発を行う必要があるgo getbin/の下に実行ファイル、src/の下にソース- ライブラリの管理方法が難しい
masterの HEAD を取ってくるgo1というブランチがあるとそれをみるが、ほとんど浸透していない- そもそも stable なの？
- version 管理できない。そもそも version 管理されてない
- go mod で semver (セマンティックバージョニング) を使うようになるよう
- WEB アプリケーションを書くときは
go get使わない - ベンダリングツールはたくさんある
- 最終的には
go mod glidedepgomodvgoはgo modなので要らない
- 最終的には
- オーサリングツールがない
- なにもないところから始める必要がある
- Perl には
MinillaExtUtils::makeMakerとかあって便利だった go modで解決する？
- ライブラリの扱いで１～２日ハマった
- しかも、今後も変わっていく
- 変数は camelCase で指定する
- 変数に型がある。別の型にはできない
- 配列とスライスがあるが、スライスのみを使うのでスライス
varで型を指定するか:=で型を推論させるか- 文字列は UTF-8
- slice
[]string()、 mapmap[string]int- map はネストしたりすると記述量がめんどくさい
- ハッシュより struct を多く使うようになった
- perl は dualvar で複数の型をぶちこめて楽しいのに
- 関数は PascalCase だと Public 、 camelCase だと private
...が可変長引数- 関数が複数の値を返せる
- 関数を変数に代入したり、関数を返したり、引数として渡したり
- JavaScript 的
- 引数にシグネチャを全部書くのはめんどくさい
- go は perl とおなじで exception クラスがない
- 例外は
panic()で発生、recoverで受ける - go は null のことを
nilと書く panicは推奨されない。コーディングミスとかだけ- リクエストの一番外側で
recoverするくらいが良い
- 例外は
- エラーを戻り値で返すことが推奨
- 複数の戻り値を書けるので
errorインタフェースか、boolで返すfile, err = os.Create、err != nilでエラー処理log.Fatalfは終わるのでreturnは不要defer file.Close()などとして終了処理- エラーを伝搬させていく書き方をする
- 関数はほぼエラーを返す
deferは Perl のScope::Guardのようなもの- ただし、より貧弱 (
dismissはできない) - スコープを抜けたときではない。関数を抜けたとき
- スコープの代わりに無名関数が必要
ifのスコープでdeferしないように注意file.Closeのエラー処理は本当はしないといけないdeferへ無名関数を指定してエラー処理。面倒
- ただし、より貧弱 (
gorutineは説明すると長いので1ページまとめcontext.Context- package の仕様
- packageのスコープ
- Perlはファイルスコープ
- あと5分
ifはカッコが要らないrange使ったり- 軟弱な
whileはない - 悪名高き
switchbreakがいあらないので、多少は安心
- go は
gotoがある。gotoがない言語は辛い - Struct 構造体 一番重要
- Interface
- formatter がたくさんあるのは便利
- 2分でAPIを作ることは不可能
- net/http はクライアントにもサーバにもなる
- 立ち上げるだけで gracefull shutdown , http2 にも対応した高性能サーバが
- middleware にも対応している。玉ねぎの画像
- gracefull shutdown はちょっと長い
- go の DB アクセスは libmysql 使わず全部自前
Perl5の静的解析入門 機械と人間双方の歩み寄りによる平和編 / macopyさん
- PPR.pm : 正規表現でPerlコードをパース
- 業務での利用
- 人間にも機械にもわかりにくいプログラム
- Perlに静的型を注釈、PPRから読み込む
- 骨折経験が豊富です
- 業務時間に書いたスライドです（カヤックさん）
- 静的解析とは
- perlがやることを途中までやって抽象構文木を利用する
- コメントなども含め、コードの見たままを扱える
- 言語機能を超えた表現力が持てる
- コメント内の型をIDEが使えたり
- 実行できる状態になるに連れ、情報が抜け落ちていく
- 実行せずにコードを扱える
- 危険な BEGIN を飛ばせる
- 逆に、 BEGIN で生成しているものは静的解析でアクセスしにくい
- すべての実行パスを調べ上げられる（場合がある）
- 型バリデーションは実行するまで動かない
- Perlの気持ちにならないと静的解析はできない（難しい）
- 機械の力を借りて安全なコードを書きたい
- PPI
Compiler::Lexer- Perl::Lexer
- Pattern-based Perl Recognizer
- 例:
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
- コードを書いて、型が静的に決定するかを考える
- イミュータブル変数など、モダン言語の機能、制限を入れる
useBEGINなど動かさないとわからないものは避けるMooseのhasなどはそれを解釈する解析機を書けばいい
- 書くのは一回、読むのは n回×m人
- 機械にも人間にも優しいPerlコードはPerlのサブセット
- 人間がルールを遵守するのは難しい
Plack->request->paramを使わない(複数値を指定したときに問題)ResultSet->searchを array コンテキストで受けない- 「クォート内にコードが合った場合は？」
- 「マッチすることもある。便利なこともある」
- Perlのコードに型を書くためのモジュールが(時間切れなので懇親会で)
エンジニアリング組織論への招待 - 2つのDXと技術的負債論 - / 広木 大地さん
- 2008 年 mixi、開発部長、執行役員 2015年退社
- ビジネス書部門大賞受賞
- ITエンジニアに呼んでもらいたい技術書10選
- EMFM podcast 、 Qiita
- YAPC Asia 2010, 2011 年に登壇
- ビジネス書なのか技術書なのか
- 離れているものではない
- それぞれ給料をもらっている
- 2つのDX
- DX(開発者体験 Developer eXperience)
- DX (企業のデジタル化 Digital transformation)
- どちらもビジネスの一部である
- 仕事でプログラムを書いているというのは何をしている
- 骨子
- 実現 == 不確実性を減らす。曖昧じゃなく動作するもの
- 不確実なものに対する本能がある。良くない行動を取る
- それらを防ぐための行動規範
- 誤差を減らすのがエンジニアリングプロセス
- プロジェクトの修了見込み プロジェクトコーン
- 組織 : 社長、部長、課長、社員へと、指示が具体的になっていく
- 不確実性を減らすのが企業活動、ソフトウェア開発
- マイクロマネジメント
- エンパワーメントチーム : より生産的。不確実性に耐えられる
- 不確実性の2つ
- 未来 : 実験による仮説検証をする
- 他人 : コミュニケーションですり合わせる
- 「エンジニアは否定形から入る」のツイートがバズった
- 物事を明確にする。境目をはっきりする。そのコミュニケーションが否定と感じられる
- コミュニケーションとは
- コミュニケーション能力で採用する、とは？
- お酒を飲んでワイワイ過ごす能力？
- お互いの理解していること、していないことの差を埋める。情報の非対称性の解消
- コミュニケーション能力とは？
- 同一の目的をもつチーム 10人、同一の事業は 150 人
- n人いると n 次乗のオーダーになるため
- 人類の群れのサイズは、 150 - 250 人。ダンバー数(これを超えると群れと認識できなくなる)
- ソフトウェアとは数理的なもの？
- 機械が理解できるほど明晰な言語化
- 立法行為と近い。法律の過程と似ている
- コミュニケーションそのものをやっている
- 他人と未来と向き合う必要がある
- Fight(戦う) or Flight(逃げる)
- 明日から違う言語で開発しよう、というとき
- 監視者と作業者で起こる無駄
- 納期圧力のあるプロジェクトで、不具合やミスが隠される
- 心理的安全性と責任
- 心理的安全性 : 危ないときに危ないと言える
- 責任 : 目的に向かって進んでいく
- 両方が高いとランニングゾーン
- ゲシュタルト原則
- 近い集団、似た集まりを脳が勝手にグルーピングする
- 席の近い人と仲良くする。趣味の合う人、価値観の合う人と仲良くする
- 「10階の連中」「エンジニアの連中」個々ではなくグルーピングしてしまう
- 組織に問題がある。組織をリファクタリングする
- 人を憎まずバグを憎む
- 人を憎まず組織の構造を憎む
- それはポエムでしょう？
- 「ポエム書いたことないでしょう」
- 一行でもコードや数式を入れるといいらしいが
- ソフトウェア工学への無知がある
- ペアプロ、モブプロは 10-15%の品質改善
- インスペクションが入るだけで 30%以上の改善
- コード解析によるバグ予測より、組織構造解析によるバグ予測に効果的だった
- 生産性、品質、コスト (Q, C, D) : トリレンマ (３つは取れない。ジレンマ)
- 良いチームの傾向
- 人数が最小限度、恐怖を克服する方法を知っている、多様性（業種、価値観、ビジネス全体を見通せる）
- ソフトウェア、組織構造 : リファクタリング対象
- システム設計は組織の情報伝達に似たものになる
- 組織構造 == コミュニケーション構造
- ソフトウェアも同じ構造に変化しやすい
- 悪い組織構造からは悪いソフトウェアが生まれる
- 見える、見えない、プラスの価値、マイナスの価値（技術的負債の四象限）
- 探索、交渉、取引にコストがかかる
- 市場から手に入れるのか、内部で作るのか
- ないと死ぬなら M&A するはず
- 取引コストより内部コストが安ければ買うでしょう
- 隣の部署にやってもらったほうが安いはずなのに、外注が安いような言い方をすることがある
- ソフトウェア、組織、どちらの構造を変えるコストが高いかで、どちらになるか決まる
- ソフトウェアではアーキテクチャと呼ぶ
- 逆コンウェイ作戦、マイクロサービス : 組織とソフトウェアを合わせる
- 取引コストの低い組織を作り、ソフトウェアに寄せていく
- マーケテクチャ、ターキテクチャ : 流行らなかった
- 良くすることができるとは、交換可能であること
- 選択肢を持つ側、持たない側 : 権力、依存
- モテる異性との恋愛、エンジニア求人、属人化した業務
- システムは時間が経つと交換できなくなる。コントロールの喪失
- システムのコントローラビリティのレベルがある
- 8割×7割ののシステムが老朽システムがDXの足かせになっている
- 何百兆円の損失があると政府がレポート
- ユーザ企業がコントローラビリティを失った結果
- システムが人質となり、ホールドアップされる
- 多様性チームから職能型組織
- コンピテンシートラップ
- 繰り返す
- これらの違いを埋めていくことがDXの解消につながる
Perlでも分散トレーシングしたい！ - AWS::XRayによる解析とその実装 / fujiwara さん
- カヤックのSRE、ISUCONの宿題、WEB+DB Press、ゲーム運用系
- 分散トレーシング
- Traceは一個の解析をするためのひとかたまり
- 複数のSpan (資格) を含む有効非巡回グラフ (閉じた経路がない)
- Span : 名前、開始時刻、終了時刻、コンテクスト(ID, Trace-ID 親)、Tag、Log
- 実装
- トレースの仕方
- アプリがトレースデータを取得(言語の中で実施)。Agentに投げる
- サービスメッシュでする
- DataPlane (例: Envoy) を経由させる。DataPlaneにTraceを任せる
- 言語などに依存しなくて楽
- 内部の情報が取れない
- AWS X-Ray
- X-Ray デーモンが UDP 2,000 を listen している
- 利点
- X-Ray では スパン == セグメント
- X-Ray SDK があります
- JSONをUDPで投げればいいだけ。300行程度
- 去年の夏書いた
captureブロックで囲むと、それがセグメントになるPlack::Middleware::XRay勝手にトレースが始まる- トレースを仕込むのは面倒
- SQL 叩いている場所に全部手で突っ込む？
Devel::KYTProf- DB, LWPなどのネットワーク通信をログに出す
Devel::KYTprof::Logger::XRayロガーを差し替えてX-Rayを送ってもらう
- ISUCON
- ISUCON 8 本戦問題
- Perl実装に AWS::XRay を組み込む
- 初期実装はdocker-compose
- Dockerfileを書いて、 docker-compose.yml に組み込む
AWS_XRAY_DAEMON_ADDRESS別ホストを指定する- app.psgi に 5 行追加して、 XRayを有効に (cpanfileも)
- 以上でベンチを実行するとトレースが出る
- トレースの見方
- 外部APIも調べることができる
- 外部APIに X-Ray を組み込んでみると？ (実際はブラックボックスなのでできない)
- プロセスをまたがった追跡の仕組み
X-Amzn-Trace-IDに1-[timestamp]-[unique_id]という形式のID- 受け取ったほうがそのヘッダを引き継ぐ
- trace ID と 親のセグメントIDを送る
- 現在の Root Parent が必要
- 引数を追加するのはきつい
captureを書くと、自動的に親が入っているlocalを使っている
local- 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アプリケーションを高速化する一般的な技術
- プロダクションコードですべてをオンメモリに載せますか？
- 普通のチューニングをしっかりやると勝てる問題
- 競技として成立
- スコア化
- 優れたもの、優れてないものがしっかりさがつく
- スコア計算式、負荷
- 性能の悪いアプリに性能の良いアプリと同じ負荷はかけられない
- レベルの調整
- マニュアル指定で負荷をかけると、運営側が決めることになる
- 自動的に負荷をかける
- タイムアウトを許容しないと、どんどんレベルが上ってしまう
- 本戦で導入された シェア機能 による自然なマニュアル設定
- 完成させる
- 業務時間の確保
- マイルストーンを設置。合宿。テストプレイ
- 集まれる場を用意（毎週なんとなくこの時間に）
- 楽しい問題とは
- 単なる作業ではない
- 工夫の余地がない => 作業スピードの競技になる
- 解法が簡単に明らかにならないように
- 解ける問題
- 解いてみないとわからない
- テストプレイをしてもらう
- 低コストでの言語移植
- 目的ドリブンで価値観を決める、価値観で善し悪しを決める、大変でも工夫で乗り切る
- 問題提供は大変だが、面白い。
- 実際の問題の本質を抽象化して別の形に具現化
多くのCPAN Authorに育てられ、息をするようにCPANモジュールを書けるようになり、そして分かったこと / Songmuさん
- Mackerel について世界で一番詳しい (ディレクター)
- 入門 監視はいい本なので買ってね
- コミュニティに関わって成長した
- 昔話から、エンジニアのキャリアについて考える
- マネージャー業をやっている
- 多くの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
- 学び
Lドキュメントを書いていたら、好意的に受け止められたcronlogのkazuhoさんはすごい- App::RunCron
- Perl限定、重厚
- Go移植。 horenso というcronのラッパー
- メンテナ権を譲ったり
- Rijiが使われていたり
- Daiku
- Rake ライク
- skajiさんとの出会い (
cpm作者)
- CPANにモジュールをあげるのはなぜ？
- あげたかった → 仕事をしていると普通にやるよね
- プロジェクトコードを簡単にするため
- 黒魔術をモジュール側に閉じ込める
- 世界が広がったり
- CPANモジュールの強調、後方互換を大切にするのも良い
- 主体的に関わることが大事
- OSSにするのが前提だと、設計がきれいになる
- Authorは人間なので、信頼関係で開発のやりやすさが変わる
- CPAN Authorになる
- OSSは使うことだけでも貢献。質問、疑問も貢献。
- 関わっているソフトウェアを良くする == 世界が良くなる
- 社外のエンジニアと交流した経験
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が環境
- サポーターへお題を出す
- sironekotoroさん 採用の内定をもらったらしい
- キッカソン
- 合宿
- 大阪、札幌では災害に負けずにやった
- Perl書ける人を育てます
npmという次世代CPANパッケージマネージャの紹介 / aereal さん
- cpan / cpnaplus / cpanminus / carton / cpm たくさんある
- cpanfile で依存関係を書きますね
- cpanfile.snapshot をバージョン管理
- git リポジトリを指定したいことがある。できないっぽい
- distごとに fetch 先を指定できない
- cpnam はできたが、 cpanfile には書けない
- carton はリポジトリ指定はできない
- 提案するなら歓迎
npm i -Sgit のリポジトリ指定ができる- 汎用的な仕組みに見えてくる
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を動かしたい
- bootstrapを書き、LambdaのDockerコンテナに入れるだけ。シンプル
- carton friendly 、 ビルド済 Layer 、リージョンすべてサポート
- dependency を local 以下に vendoring
- zip でまとめる
- App::Perlambda
- 簡単に使う CLI
- dist, create, update に対応
- func.zip を自動生成、そのまま起動できる
- ごーん
Perl Community への報恩感謝 / tokuhiromさん
- Perl好きな人、仕事で使っている人、メインな人 : ぼちぼち
- 学生時代はニューラルネットワーク
- CTOがエッジだったので、会社もPerl
- Shibuya.pm : 勉強会が少なかった。超人気勉強会
- livedoor、Blog、wikiが流行っていた
- Blogなどはperlで書かれていた
- 着メロ、ポイントサイト、など、今は滅びたものをやっていた
- 営業第一。早く物を立てて売りを立てるスタイル
- 早く作るコツ
- ライブラリを書く
- もっと良い実装、いいインタフェースになるのでは
- datetimeの引数が冗長とか
- リリースしてすぐ終わるサービスは多かった
- 最近は、数ヶ月作って、じっくり育てるのが増えた
- マーケティング・リサーチなどなかった
- リリースすらできないことも
- モチベーションの維持
- サービスが閉じるのは寂しい
- 新しいチャレンジを必ず入れる (ミドルウェア、ライブラリの導入)
- サービスがなくなっても、得たものはあるように
- ライブラリ、ソリューションの不満をコードで表明したかった
- PSGI/Plack
- HTTP::Engine のリプレース
- YAPCの一週間前
- なぜリプレース？ : ライブラリだった。仕様と実装を分離したい
- miyagawa さんのフライト中に終わらせた（徹夜コーディング）
- トークの一本を勝手に差し替えた
- Amon2
- Teng
- Furl
- Text::Xslate
- XSのテンプレートエンジン
- 開発初期から口を出した
- Template Toolkit がデファクト
- 速いときは clear silber を使っていたが、使いにくかった
- gfx さんがとにかく XS を書きたかった → 書いてもらった
- 問題があるよというと、寄ってたかって解決する文化
- 野生のPerl Hacker がどこからか集まって、解決していく
- Effective Perl
- Software IC
- 複雑な電子回路が埋まっている
- 複雑な機能を持ったパッケージが組み合わされる
- コードの再利用をしたい人がたくさんいる文化
- 転職した先で同じコード角のだるいからオープンソースにしていた
- Software IC
- CPAN はちょっとしたものでもアップロードしていい
- OSS活動したいというモチベーションではない
- コミュニティは利用するもの
- コミュニティへの貢献
- 初心者のサポート
- 懇親会でいろいろな人に話しかけて交流すると良い
- カンファレンスに参加する
- 日本人は真面目に話聞きすぎ
- ディスカッションしたほうがいい
- 1日中ロビーでコード書いてるだけのおじさんでもいい
- Issue をあげる
- バグレポートがないとバグは治らない
- Vote も立派な貢献。スターを付ける
- metacpan にもレーティング機能ある
- Twitter で down vote を先導したりはやめましょう
- コードを書く
- プログラマが一番やりやすい行為
- perldoc.jp のリニューアル
- 15年前にmiyagawaさんが始めた。飽きた。メンテナンス止まった
- perldoc.jp のドメインをもらって作り直した
- めちゃくちゃ時間がかかる貢献。おすすめはしない
- 去年、一昨年は1名だけだった。翻訳できる人は貢献を
- FrePAN
- 海外への渡航支援
- YAPC::NA に参加してきた
- みんな自由にしてたり、Hiって挨拶してたり
- LTで踊ったり壇上でバンド活動したりしてる
- 牧さんにコミュニケーションをとるために送り出された
- 「Perl書いてないのでは？」
- How to become a hacker の世代
- Perlは領域を広げすぎた？
sedawkより高機能。 ruby では足りないかな- みんなと一緒にHACKを楽しんできた
- いろんなPerl Hackerにお世話になった
- Future Perl Community is You
- ここにいるみなさんが、コミュニティを盛り上げて欲しい
クロージング / kfly8 さん
- 五反田.pm の人。YAPCは 2011 年から
- Twitter やブログに楽しかったことを書こう
- ベストLT賞 (COLSISさんの独断で)
- moznionさん (勇気が出て、Perlでやってみようと思った)
- Best Talk Award (投票で)
- songmuさん (ほっこりした気持ちになりました)
- 本気で狙ってた。話したいことが多くて困ってた。嬉しい（号泣）
- スポンサー様の紹介 (今回はすべて読み上げ)
- 個人スポンサーの紹介 (アイコンのみ)
- ゲストスピーカー、座談会、トークの紹介
- 384名が参加(90%)
- 37人のスタッフ (写真撮影)
- 次の YAPC::Japan は？
- 募集中です
- 「島根でやろう」「総本山で」「キーノートMatzさんで」
- YAPCにもいろいろある
- 懇親会は「まだ」受付可能です
- Thank You
