PHP Conference Japan 2021 2日間の感想。
記載順は順不同というか書き始めた順という程度なので特に意味はない。
見逃し分はアーカイブで視聴予定なのでもしかすると追記するかもしれない。
PHPにおけるコーディング規約と自動整形
コーディング規約の重要性や自動整形ツール導入のメリットがphp-cs-fixer や php_codesniffer でのライブコーディングを交え解説された。
ライブコーディングではコマンド数個でツールの導入が完了してしまう便利さも垣間見させてもらった。具体的な規約の例も幾つか紹介され、すぐにでも業務に活かせる内容のセッションとなっていた。
本セッションに限らず規約や自動整形はチーム開発の秩序やレビュー負担の軽減などの文脈で語られることが多いが、個人的には一人開発であっても十分な力を発揮すると思う。雑に書きなぐっても勝手に綺麗になってくれる、これだけで時短になる。せっかくなのでエディタとの統合なども紹介されていると嬉しかった。例えばVSCodeならワークスペースの推奨プラグインや推奨設定を コードと一緒に配布 できる。コンテナ前提であれば 強制的にインストールさせる ことも可能だ。
セッションの直後、紹介とは別のツールの作者からスライド中の課題に対する回答が即レスで寄せられたりしていた。
非常に有意義なやり取り。この辺りはカンファレンスや登壇の醍醐味だ。
ElasticsearchとKibelaを活用したSlackでのCSお問い合わせ対応業務の改善
形態素解析や tfi-df などの技術を用いてCS部門のお問い合わせ業務を改善した話。あるお問い合わせに回答する際、過去の類似問い合わせを自動的に検索するシステム。
Elasticsearch入門中なので、まさにユースケースど真ん中のシステムの制作過程を知ることが出来て嬉しかった。
途中tfi-dfスコアの使い方に若干の疑問を感じたのだが、その後の段で 「社内評価が極めて高かった」「問題解決が優先なのだから80%の状態でもリリースすることが重要」 という話が出てきてはっとさせられた。社内ハッカソン的な取り組みを認めつつ Done is better than perfect. の考えも 正しく 浸透している。BASEの社風に憧れる。
独自フレームワークPHPアプリケーションの改善戦略
psr-4非準拠の独自FW。宣言と副作用の同居。includeのネストとincludeを跨いだ変数の依存。言うなれば「テストを書けない理由、全部入り」と言ったところだが、これを改善していった話。
並大抵ではない仕事だと思う。次のような方法で解決していったとのこと。
- Docker環境を立ち上げて実際にAPIをコールすることによるテスト
- HTTPヘッダにテストを制御するための値（日時など）を埋め込む。
- 同じやり方でxdebugの制御。テストとテスト対象とで環境が異なっていてもカバレッジを取得。
基盤部分に仕掛けを施すことで既存のコードはそこまで変えずテストだけは可能な状態をまず確保、そしてログを共通化したり、ヘルパ関数をpsr-4管理下のクラスに押し込んだり、と言ったことを実施したそう。
普通に参考になったが、その後で出てきた Webアプリでよく取り組まれている改善をやっただけ という発言に重みを感じた。
確かにその通りなのだが、巷のノウハウを参考にしながら何も考えず 改善 を試みただけでは紹介された技法には行き着かなかったのではと思う。普段の業務で 改善 を行うときも、自分が何をしているのか理解した上で取り組むことが肝要だと感じた。それができれば今回のような 特徴的な アプリへの改善にも向き合える力がつくだろう。
登壇者は レガシー という言葉を避けたいと明言されていた。どこか他人事のような言葉、自分達のプロダクトなのだから自分ごととして捉えたい、そういったことを仰っていた。
こういった姿勢が、今回のような困難な仕事を可能にしたのだろう。
ドメインをモデリングして PHP コードに落とし込む
phpによるDDD実践チュートリアル に相当する内容、と解釈。
@nrslib 氏の DDD本 を思い出した。分かりやすい説明とふんだんな実装例でDDDを解説した名著だが、序盤のエッセンスを凝縮しPHPで書き直したような内容。PHPerとして有り難かった。
このセッション、枯れた技術を好みがちな大規模案件の現場に浸透させたいと感じた。コード例の多くの箇所でphp-8.0からの新機能や一部だが未リリースのphp-8.1の新機能が多用されている。闇雲に新機能を使っているわけではなく、何れもDDDの実践にあたって極めて重要な機能だ。そしてphpに限って言うと、DDDが必要な現場に限って今回のコード例のような新しい書き方が浸透していない確率が高い。
機会があれば広めていきたい。
余談だが、
想定FAQ2 - 図やドキュメントのメンテナンスは？
PlantUML使うとレイアウト調整を諦められる :)
こだわりすぎてしまう性格の持ち主として、爆笑しながら膝を打った。
MySQLとインデックスとPHPer -PHPが本職でもMySQLを手懐けるために-
このセッションに出会えてよかった。自分の知識としてはほぼ理解している内容なのだが、人に説明する時の説明の仕方、という観点で今後活用させて頂きたいと思っている。
where, order by, join などの際にインデックスがどう使われるか、これらをphpのコードになぞらえて紹介、例えば次のようなもの。
- primary keyは連想配列のキー（のようなもの）
- 複合キーは連想配列のネスト（のようなもの）
- inner joinはforeachループのネスト
- outer joinもループのネストだが、ループ順序の交換が行えない
何れも実際のDBの挙動に相当するphpコードが示されたのだが @yoku0825 氏はPHPerでは無かった筈。このセッションのためにわざわざ用意して下さったのか。本当に頭が下がる。
なおこのセッションを聴く以前の、インデックスに対する私のの理解と人への説明はこんな感じ。
- テーブルは辞書、インデックスは索引、selectは「辞書を引く」に相当。
- 索引から探せる条件（先頭1文字、等）で単語を全て弾く。問題ない。
- 探せない条件（単語の総画数、等）で探す場合どうなる？
- 複合インデックスは百科事典の「巻→索引」に相当。結局は索引。
- あとは DBの気持ちになって考えればだいたい分かる。
どうやら一長一短あるようで、この説明で全て理解する人は少なからずいる、が、狐につままれたようにキョトンとされてしまうこともある。説明の引き出しが増えたのは収穫だ。
SymfonyとDoctrineで簡単クリーンアーキテクチャ 〜プロトタイピングにこそクリーンなTDDが活きた話〜
Symfony歴は1年弱だが今となってはPHPの中で一番好きなFWがSymfonyだ。
使える人が周囲には多くないため積極的な採用に踏み切れず歯がゆさを感じているのだが、FWのベストプラクティスに基づいて書けば必然的にDDDになる、みたいな感覚が心地よく感じられる。
という心地よさを疑似体験させてくれるセッションだった。
- Doctrine/ORMのエンティティはアノテーションを剥がせば所詮はPlain Objectなのだから、インフラ書かずともユースケースやテストはいくらでも実装可能。
- テストが書かれているのであれば、プロトならではの試行錯誤に強い。途中何度も、えげつない変更行数のcommitが。
- フロントエンジニア見つからない。Next.js予定だったがtwigでやってしまおう。ユースケースは既にテスト済なのでそう変わらない。
と言ったプロト開発の過程がダイジェストで語られたのだが、聞いていて胸のすく思いだった。
…と思ったのだが、セッションの最終でこうも語られた。
- 本開発でもプロトは活きた、が、コントローラーがFATになってしまいせっかくの設計は活かせなかった。
- アーキテクチャの意図をメンバーに伝えられるかがやはり重要。
Symfonyを採用できれば全て解決、というわけでもないらしい。いつか訪れるかもしれない機会のために覚えておこう。
PHP 8 と V8 (JavaScript) で速さを見比べてみよう！
本当に参考になったセッションだったのだが、非常にレベルの高い内容だったため、感想をまとめるに値する知識を自分は持ち合わせていない。印象深かった点を列挙しておく。
- 表題は 見比べてみよう！ だが 見比べることはできない が結論、と私は感じた。
- JIT以降のPHPであれば競プロでも全く問題なく戦えるのではないか。
- V8 のチューニングは尋常でないが特定の処理でPHPに圧倒的な軍配が上がる感覚は昔からあった。だが何が条件なのかはよく解らなかった。今回理解できた内容はざっくり自分の感覚とも一致する。
本題からは外れるが、最後は結局 C vs C++ と言った勝負になっていた点について、phpは「普及度」というファクターも間接的に速度に貢献しているのではと感じた。gd, gmp, xmlなど外部ライブラリを必要とする、つまり通常であれば パッケージリポジトリ＋実行環境でのビルド というインストール手順が必要となる拡張でもphpの場合ディストリが標準で配布している確率が高いためだ。
Composer2.0 新機能概論
composer 2.0の主要な新機能を（おそらく）全て紹介するセッション。
「高速化された」「autoloadが厳密になった」程度の知識しか無かったが、それ以外の新機能も網羅的に紹介されていた。
確かに必要な機能ばかりで、開発の基盤部分を提供することの多い自分にとって非常に有意義な内容だった。php / php-ext-* の依存チェックやパッケージの選択的アップデートなどは積極的に使っていきたい。
有意義な内容だけに、2.0がデファクトになってくれるのはいつになるのかが気になった。EL7や派生ディストリビューションのおかげで未だにphp-5.4から抜け出せない例などを多く見ている。autoloadの厳密化（破壊的変更）が入ったことなどを考えると…
ComposerとInterfaceとDIを使って業務内のコードを外部公開する
業務内のコードを外部公開 という文脈抜きで役立つ内容だった。
現場では「リポジトリを跨いだ共通処理をどう管理するか」がよく課題になる。composer（に限らずパッケージマネージャ全般）の使い方を把握した人が少ないまま議論のみ進行している例も多く、なのでこの辺の知識は幅黒く普及して欲しい。
またパッケージマネージャの使い方を踏まえた上でDIPやDIを駆使しそのパッケージの拡張性をどう担保するか、などにも触れられており、思いのほか濃い内容だった。
本題の 業務内のコードを外部公開 の部分は使い所が難しいかもしれない。
- 「メール」「データベース」等の処理は既にライブラリやFWが存在する。
- そうでない箇所でドメインロジックの完全な切り離しが可能な箇所は、意外と少ないのではないか。
とはいえ設計の良いトレーニングにはなるので、暫く頭には入れておきたい。
Repositoryパターンを維持しながらN+1問題を起こさないようにする方法論について
登壇者が命名された Hash Map Attachment法 による表題の問題の解決パターン。
セッション中でも述べられていたが Laravel/Eloquentで言うところのeager loadと同じ方法論ながら実装のレイヤーは異なる。
- キャッシュ
- ページング
- CQS / CQRS
- Hash Map Attachment
Hash Map Attachment法 自体よりもむしろ、それ以外含めそれぞれの方法のメリットデメリットが網羅的に紹介されていた点が良かった。実装の方法論よりも背景コンテキストや要件が重要、それを考えるきっかけになるセッションだった。
抽象のはしごの上手な登り方〜使いやすい汎用ライブラリを作るために〜
様々なカンファレンスで 抽象 をテーマにお話されている @77web 氏のセッション。抽象の第一人者と言っても良いのではないのだろうか。扱いの難しい話題ながらとても分かりやすく聞くことが出来た。
巷に溢れるDIPやリポジトリパターンの記事を鵜呑みにしてしまい全体としてよくわからないコードになっている例が多いと感じている。パターン自体が目的になってしまい意味なくクラスが増えているだけの例、極端な抽象化によりコードの分量が無用に多くなっている例などだ。
これらは、セッション中の 抽象度は必要な高さまで という言葉を実践することで対応が可能だ。浸透させていきたいと感じた。
具体的には、「ログ」という身近な実装を例に、どの程度抽象度を上げれば良いのかを実例を交え解説。
- 特定の課題のみを解決したい、これであれば実装の量は減る。
- 多くの問題を汎用的に解決したい、実装量は増えてしまう。
想定範囲の例「次のシステムがPHPじゃない」に対する「視野に入れなくていい」「あなたがAWSのエンジニアなら別」は秀逸な例え。CloudWatch Logsの設計やAWS SDKの実装になぞらえているのだと想像。蛇足ではあるが秀逸だっただけに、AWS全くわからない人にも軽く解説するような一言二言が欲しかった気はする。
