yapcjapan.orgはてながスポンサーになっていたのでスポンサーチケットで参加させてもらった。誰か行きませんかと社内で募集があったので手を挙げた感じ。運営を頑張っているとJPA方面の方からも聞いていたので、行かない選択肢がなかった。社内に共有したメモから抜粋して感想等を書いておく。Perlは勉強中で、最低限さくさく読めるようになろうとしているところ。減らすと生産的になれる組織も不確実性を減らしていく多くの不確実性に応えられるチームほど生産的エンパワーメント型コミュニケーションエンジニアは否定ばっかりだから...というツイートがバズっていたが物事をはっきりさせたい様子が、否定形に見えてしまうのではないか情報の非対称性を減らすことがコミュニケーションなのではないかコミュニケーションは、常識の距離が近いほど簡単。コンテクストが受け入れやすいから。常識の距離が遠くなるとコミュニケーションは難しくなる。イディア:情報デザインと情報アーキテクチャ地理的に近いと仲間だと思う似ている種類の集まりを仲間と思う個々人は個性的だと思っているのに集団で捉えてしまう問題は、構造にこそあるのではないか。ペアプロ/モブプロも品質改善をするが、プロダクトオーナーと要求インスペクションをやることで、より上流工程での品質改善ができて効果も高いよってことだった。→チームが組織学習できる心理的安全性があるとわかっている状態になっているかということ。結論と感想エンジニア以外の職種においても情報の非対称性が解決され、エンジニアのDX(開発者体験)と、会社としてのDX(デジタルトランスフォーメーション)が同一になることすごく納得した。5.7からそれ以上は8からエラーコード分類による切り分け1000番台ならサーバ系2000番台ならクライアントという切り分けはできる。これらと、3000番台なのかどうかを見るsyntaxのバリデーションはクライアントサイドではしない。デフォルトの認証プラグインが変更された。errorだけが決め打ちで、それ以降は状況次第で出し分けている。ググりにくいエラー番号が分かれば、grepしやすいプラガブルストレージエンジンのログ別のファイルに吐いたり、標準エラー出力に吐くこともまとめエラーメッセージを身近に感じてほしいとのこと。調べ方のためにもソースコードやドキュメントを読んでおくのは良さそうと思った。KeynotetokuhiromPSGI/PlackHTTP:Engineのリプレースプロジェクト他言語だと仕様と実装が分離されている。Mapper当時kamipoさんが言うところのクソクエリが話題になっていたFurlperldoc.jpの翻訳作業をやる人が一人しかいない。コントリビュートチャンスさいごにいい刺激をもらえた。onkさん、Songmuさんの発表の両方で感じたが、Rubyなど他言語のよいところを輸出入するという考え方はとてもよい。何の言語やツールかはわからんけど、なにかコードやドキュメントを書くことでの貢献をもう少しできそうかもという思いを持った。小さく始めて継続できる感じを探ってみたい。あるってーと宣伝しておいたら本当に北海道から数人来てくれていて最高だった。学生同士でもワイワイしていたし、そこらへんにいたバリバリやっているエンジニアたちとも交流していたようだったのでとてもよかった。