YAPC::Tokyo 2019に参加してきた

はじめに

これです yapcjapan.org

はてながスポンサーになっていたのでスポンサーチケットで参加させてもらった。誰か行きませんかと社内で募集があったので手を挙げた感じ。同僚の id:papix が運営を頑張っているとJPA方面の方からも聞いていたので、行かない選択肢がなかった。社内に共有したメモから抜粋して感想等を書いておく。

Perlは勉強中で、最低限さくさく読めるようになろうとしているところ。

冬のPerl

Perl 5.28

Perl 5.30

  • 多少のパフォーマンス改善
  • Unicode11
  • なんかいっぱいエラーになるものがあるらしい

Perlを取り巻く状況

  • cpanのactive authorはだいぶ減っている
  • CPAN Pull Request Challengeが4年以上続いていた
  • Perl::LanguageServer
  • Perl 6.d がリリースされました

2019年の開発予定

  • MoarVMの最適化、部分的エスケープ解析
  • 高速化
  • 並行・並列処理

Rakudoとか、MoarVMとかわからん

広木大地さん講演

資料: ２つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deck

2つのDX - 開発者体験 - 企業のデジタル化

組織構造

  • 不確実性を減らすといい。減らすと生産的になれる
  • 組織も不確実性を減らしていく
  • 多くの不確実性に応えられるチームほど生産的
    • エンパワーメント型

コミュニケーション

  • エンジニアは否定ばっかりだから…というツイートがバズっていたが物事をはっきりさせたい様子が、否定形に見えてしまうのではないか
  • 情報の非対称性を減らすことがコミュニケーションなのではないか
  • コミュニケーションは、常識の距離が近いほど簡単。コンテクストが受け入れやすいから。常識の距離が遠くなるとコミュニケーションは難しくなる。このズレをすり合わせていけるのがコミュニケーション能力なのではないか

ダンバー数 https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%B3%E3%83%90%E3%83%BC%E6%95%B0

  • 明晰な言語化という意味だと、立法行為と同じことをしているのでは
  • 我々エンジニアはコミュニケーションそのものをしている
  • 学習を促す心理状態になれば、本能を克服できる
  • 心理的安全性と責任の両方が高ければラーニングゾーンに行ける
  • 本能的機能は組織にも適応される: ゲシュタルト原則
  • 問題は、構造にこそあるのではないか。構造をリファクタリングする
  • ソフトウェアづくりはコミュニケーションそのもの

  • こういったことを考えていると、ポエムでしょ？と言われる

    • ソフトウェア開発を誤解した反応だと思うとのこと

  • ★ 要求インスペクション、よくわからんかった

    • 懇親会で聞いた: ペアプロ/モブプロも品質改善をするが、プロダクトオーナーと要求インスペクションをやることで、より上流工程での品質改善ができて効果も高いよってことだった。
  • コード解析より組織構造解析によるバグ予測のほうが成績がいいこともある
  • QCDのトリレンマを超える

よいチームの傾向

  • 関わる人数が最小限度
  • チームが本能的な恐怖を克服する方法を知っている ★これもよくわからなかったな
    • 懇親会で聞いた: →チームが組織学習できる心理的安全性があるとわかっている状態になっているかということ。なるほどね。
  • 多様性のある状態から認識を揃える力がある

組織構造とリファクタリング

  • 社内にも取引コストはある
  • 変えようとするとコストが非常にかかるものと簡単にできるものは、取引コストによって変わる
  • 組織設計とアーキテクチャの関係
    • 相互に影響を与え合う
  • システムは時間を経ると交換可能性を失ってコントロールを喪失する
  • ホールドアップ問題 - Wikipedia
  • なぜ多くのエンジニアは「技術的負債現象」と表現せざるを得なかったのかという論点
  • 見えてしまったら技術的負債ではないのかもしれない
  • 両利きの経営

結論と感想

  • エンジニア以外の職種においても情報の非対称性が解決され、エンジニアのDX(開発者体験)と、会社としてのDX(デジタルトランスフォーメーション)が同一になること
  • すごく納得した。どういうこと？と思われる方がいれば、エンジニアリング組織論への招待を読んでみることをおすすめする
  • 併せて読みたい: 「チームが機能するとはどういうことか」を読んだ感想 - 実はhokkai7go](https://blog.hokkai7go.jp/entry/2017/02/07/090655)

Dive into MySQL Error

資料

t.co

MySQLのエラー

  • エラーの分類
    • MySQLサーバのエラー
    • クライアントネガティブ応答
    • クライアントライブラリの異常
  • ネガティブな応答
  • 余談
  • MySQLエラーパケット
  • 先頭FF固定

エラーコード分類

  • 1000系がサーバ
  • 2000系がクライアントサイドエラー
  • 3000番台 5.7から
  • それ以上は8から

エラーコード分類による切り分け

  • 1000番台ならサーバ系
  • 2000番台ならクライアント
  • という切り分けはできる。まずはこれらと、3000番台なのかどうかを見る
  • syntaxのバリデーションはクライアントサイドではしない。

perror

  • perror というツールで調べられる
  • 2003番のエラーでも、どこでタイムアウトするかによってちょっと違う
  • MySQL has goneとか、サーバサイドの問題も一部2000番台に含まれている
  • 2059番 デフォルトの認証プラグインが変更された。古いクライアントから接続しようとすると、このエラーが出る
    • 5.7からは接続できるが、5.6以下はこれが出る
  • slaveはクライアント
    • エラーを起こすと、1000, 2000番台のエラーに従う
  • エラーメッセージ実は日本語にできる
    • 3000番台以降は日本語対応されていないからプルリクチャンスかもしれない
  • perror
    • 引数にエラーコードを受けて、内容を返す
  • 1593は、Fatal errorだけが決め打ちで、それ以降は状況次第で出し分けている。ググりにくい
  • エラー番号が分かれば、grepしやすい
  • プラガブルストレージエンジンのログ

まとめ

エラーメッセージを身近に感じてほしいとのこと。調べ方のためにもソースコードやドキュメントを読んでおくのは良さそうと思った。

Keynote

tokuhirom

  • PSGI/Plack
    • HTTP:Engineのリプレースプロジェクト
    • 他言語だと仕様と実装が分離されている。たとえばRack
    • 徹夜して書いたライブラリの話をフルセッションでやるのが許された牧歌的な時代
  • Amon2
  • Teng
    • O/R Mapper
    • 当時kamipoさんが言うところのクソクエリが話題になっていた
  • Furl

perldoc.jpの翻訳作業をやる人が一人しかいない。コントリビュートチャンス

さいごに

いい刺激をもらえた。onkさん、Songmuさんの発表の両方で感じたが、Rubyなど他言語のよいところを輸出入するという考え方はとてもよい。何の言語やツールかはわからんけど、なにかコードやドキュメントを書くことでの貢献をもう少しできそうかもという思いを持った。小さく始めて継続できる感じを探ってみたい。LOCAL学生部の人達に学生交通費支援制度あるってーと宣伝しておいたら本当に北海道から数人来てくれていて最高だった。学生同士でもワイワイしていたし、そこらへんにいたバリバリやっているエンジニアたちとも交流していたようだったのでとてもよかった。尊い。

はい。それは私です。S.O.Sって曲最高だし、MAHO EMPiRE最高だよねと話した。尊い。