More than 5 years have passed since last update.

YAPC::JAPAN 2019 Tokyo 会場まとめメモ

Last updated at 2019-07-19Posted at 2019-01-26

開催中のYAPC::Tokyoのメモ

誰かが「この資料あったよー」って編集リクエスト来たりしないかなーと思いつつ公開してます。終わった後清書して更新します。
尚コレを書いてる本人はPerl書いてないです。

公式サイト: YAPC::Tokyo 2019

opening

テーマ: 報恩謝徳
「報いる方法は人それぞれ」
得た刺激を返していこう

周知事項

ランチセッションが先着150名分
電源は3階オープンスペース

ハッシュタグ

#yapcjapan
#yapcjapanRoom0
#yapcjapanRoom1

チームが前に進み続けるために僕たちが考えたこと (20min)

papix 氏

資料

チームが前に進み続けるために僕たちが考えたこと / YAPC::Tokyo 2019 - Speaker Deck
- https://twitter.com/__papix__/status/1089022296625299456

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()を実行する
goroutine
- Goを象徴する機能
- go func()で別スレットでプログラムが走る
  - 簡単に並列プログラミングできる!
context.Context
- 特定のgoroutineや一連の処理中にデータを入れて引き回したりキャンセル処理を波及させるのに使う

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で公開してくださった資料たち

当日

LT

前夜祭

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

YAPC::JAPAN 2019 Tokyo 会場 まとめ メモ