はじめに
ここ数年のルーチンワークになっているPHPerKaigiに今年も参加しました。
今年は無理やり仕事を納めDay0から参加出来た。
Day0はもう少し人が少ないかなと思っていたけど、思ったよりも多くの人がいて知ってる方もいらっしゃってうれしかった。
今年も多くの方々にお声がけいただいて話させていただいて感謝。
ランチマッチング
Day1は午後参加だったから行けなかったけどDay2はマッチングしてカレーを食べに。
お昼っていつも悩ましいのでこういうマッチングがあるとはじめましての人ともお話できるし、近場にお店もいっぱいあるので会場付近のことも知れて有り難い企画でした。
Day0のToday's Updateで千年の宴をご紹介されていたので突撃してみたらまさかの団体予約が。休日の昼居酒屋って案外需要あるのね…。
聞いたトーク
家族の都合とかで聞けない時間帯があったりしたけど、ニコ生タイムシフト使えるのありがたい。後で見るけどとりあえず生トークの感想を。
Readable 正規表現
正規表現は一度にいろんなことを詰め込みすぎて複雑なGODにやりすいからバリデーションとかで役割を分断したほうがいいんじゃないかという主張に対してQAで「結局コード量が増えているけれどもそれって可読性があがってるの？」という問があって、個人的には「Readable ≠ コード行数が短い」だと思っていたので面白い問だなと感じた。
可読性は「何をやりたいか」という情報を初めてコードを読んだ人に伝えられるか、という認識だったのでコードが多少長くなっても実装者の意思が伝達できることがより重きを置くべきだと思っていたけれども、コードが長くなることで可読性が下がっていると感じる人もいるというのは可読性という言葉の幅が広すぎるからなのかもしれないと感じた。
ノイズを削って意思表明を明確にする、というのはあすみさんのAssertionメソッドを使い分けるという話にも通じるけれども、可読性みたいな幅の広い言葉を使うよりも「1度にいろんなことやるのは止めよう」「何をしているか名前をつけよう」（文字種チェックなのか、形式チェックなのか等）みたいに砕いた方がメンバーには伝わりやすいのかもしれない。
マイクロサービスがほしいと思ったときに本当に必要だったもの〜なぜ人は共通基盤の夢を見るのか〜
マイクロサービスを採用したいとなったときに別のやり方でも良くない？という問いかけで、新しい道具を使いたくなってしまう衝動との戦い方の紹介と捉えた。銀の弾丸のように思ったとしても運用のことや実際の使われ方を考えると最適ではないことは多々あるし、「なぜそうしたいか」を考えたときに組織のスケールのためだったりアプリケーションのスケールのためだったりするけれど、技術を先に決めてしまうとやりたかったこと実現できてなくない？となることもあるので、適切なゴールを設定するのを忘れずバズワードに振り回されないようにしないとですね。
共通DBというのはアンチパターンではあると思ってるけど、規模とか価値観によっては取りうる手段かも。分離させてCDCで伝播させてもストレージコストって馬鹿にならないし。
「"品質"が高いコード」って何？
品質とは一言でいっても、個々人の思う品質って「バグがない」「サクサク動く」「読みやすいコード」だったり色々で、定義に立ち返る人って中々いないんだよな〜って思っていたのでとても頷きながら聞いていた。
ソフトウェアの場合は物理的に見えるものではないという性質上、ハードウェアの製造に関わる品質と比べるとどうしてもふわっとした認識になりやすいし、要求も何となくで進めている現実があるのかなと思う。
それはそれとして善良なる管理者としての責任はあるので、要求がなかったら要求を引き出す必要はあるし、要求が引き出せなくても最低限の品質保証プロセスは回さないといけないよな〜という面倒臭さがあるのよね。
（ただしそのプロセスの質が悪いとたちが悪いんだけれども…）
ふわふわした品質を語ってくる上の方々に100回くらい読ませたい。
B+木入門：PHPで理解するデータベースインデックスの仕組み
DBを作ろう→インデックスを作ろう→ドハマリするという流れでB+Treeの解説。
普段何気なく使っているしなんとなくわかった気でいたけれど、挿入時の動きとか全然知らずに今まで来ていたので、改めて見るとアルゴリズムとデータ構造面白いな〜ってなった。
array_is_list関数のことを初めて知ったのでPHPのarrayが何でも屋さん過ぎるのと歴史的経緯が垣間見えたのとarray_is_listっていう何とも言えないネーミングに若干ツボった。
arrayが便利すぎて捨てられるのも面白かった。
あとB TreeのBは完全にBalanceのBだと思っていたので、明かされていないのは意外だった。
C言語のデータ構造とか懐かしくなったので久々にデータ構造もう一度勉強しようかな。
キャッシュと向き合う、キャッシュと共に生きる
キャッシュは麻薬。ちゃんと覚えた。
キャッシュっていうとどうしてもオンメモリを思い浮かべてしまうけれど、コメント返しで言われていた「マテリアルビューもキャッシュの一種」というので無意識にキャッシュのような働きになっていて落とし穴にハマりやすいのがある気がした。
例えばシステム間のファイルインターフェースや、CDC等など。
どれもデータ鮮度の話は出るけれども障害や不整合が発生したときの観点はあとの方になって出てきて困るケースはありそう。
はじめてのメンバー育成。マネージャーとメンバー視点で振り返る1年間
人を育てるのって中々難しくてプレイングマネージャーとかになってしまいがちだけれども、メンバーが自ら球拾いをするようになるまで自立していてすごいなと思う反面、組織のミッションの理解のために施策を行えるなど推進剤になるような環境を作るのは大変だなと思う。
人のタイプによっては全然そういった推進剤があっても響かないので、カルチャーマッチとか採用の段階から育成まで地続きでできているのかな。
privateメソッドのテストって書かない方がいいんだっけ？
少し遅れて入ったらいきなりトーク終了してて面白かった。
闇魔法を目的があってあえてやるのと、楽だからやるのはぜんぜん違うよね。
（一度闇魔法を味わうとそのままずるずるいっちゃうことはよくあるけれど…）
モック化して距離を置くことで偽陰性が出てくるし、内部構造に着目して距離が近すぎると偽陽性が出てくるし、適度な距離を保とうというのはストーリーも含めてわかりやすかった。
個人的にはprivateメソッドのテストをしたいとなるケースはあるけれども、流用性のあるビジネスロジックに近いところは切り出して公開メソッドにして、それ以外のprivateメソッドでテストを行いたいときは捨てる前提で作るのが良いのかな〜って思っている。
開発中はテスト範囲を分割して早めにバグを検知できたほうがいいので一時的には内部構造に着目してもいいけど、CIで知りたいのは振る舞いが変わったときなので、テストコードのライフサイクルを分けるといい感じにならないかな。捨てる予定だったテストコードがゾンビみたいに残り続けそうな予感もするから悩ましい。
懇親会
Day0, Day1と非公式懇親会を経て公式の懇親会。
なんか年々お料理おしゃれになっていってない？
今年は瓶ビールもあって美味しいお酒と美味しいご飯で最高でした。
その後も遅くまで付き合っていただいた皆様方ありがとうございました。
これでまた一年頑張れます。
最後に
PHPerKaigiのコミュニティは「現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たち」と広く受け入れてくれているので気軽に行けるし、過去に言われていた「すべてのみなさんの同窓会でありたい」との思い通りに色んな方々とまた会えてお話できて嬉しかった。
仕事では普段PHPを触らず周りがカンファレンス？なにそれおいしいの？みたいな文化圏なので少々異質なタイプだとは自覚しているけれども、PHPerKaigiは品質の話とか言語関係なく話せる話題も多くて経験に裏打ちされたトークは聴き応えがあるし、SIerのお話も面白がってもらえるのでありがたい。
「最近品質分析するときに最近脳内でメーデーの事故調のナレーションが脳内再生されるんですよね」という話をしたら「それで20分枠話せますよ」って言われてからちょっとネタ考えようかな〜って気持ちになっている。
そろそろLTよりも長い枠にチャレンジしてみようかな。
3日間のお祭りもあっという間に終わったけれども、毎日楽しかったです。
また来年。
