PHPerKaigi 2024の感想です。同じ内容をforteeのフォードバックコーナーへも投稿しています。
同じトークに対して他人がどう感じたか、これもまた学びの糧になると感じているため、自分の感想を投稿しています。順序はトークの実施順です。
雰囲気実装を少し抜け出そう！RFCからPHPの実装までを考えるタイムゾーンとサマータイム！！！ / @suguru_ohki / 資料
メッセージに対するテーマの選定が良かったと思います。
雰囲気で実装しない、あらゆる実装において大切なことですが、何故かタイムゾーンでは皆がそれをやってしまいがちです。「とりあえずJST」までは良くても、その設定により各所の振る舞いがどう変わるのか、これを正確に説明できる人は意外と少ない気がします。
このトークでは「どこで設定されているか？」「何が設定されているか？」に対する注意喚起に加え、実装上の具体的なベストプラクティスまで示されてました。幾つかのポイントを抑えるだけで雰囲気実装から抜け出せる、複雑な問題提起に対しシンプルな解決策を端的に提示している点が見事だと思いました。
一点、惜しいと感じたことがあります。ベストプラクティスに従わないと具体的にどういう不都合があるのか、これに関する実例が本編で紹介されていれば、聴く側としてはベストプラクティスの理由をより腹落ちして理解できたかもしれません。
ちょうど質問コーナーで非常に解かりやすい失敗談の話が出ていました。これがまさに「書式にタイムゾーン情報を含めなければならない理由」になるわけですが、実装例と共にこういった実例も織り交ぜていくことで、資料の説得力をより高められると思います。
マイクロサービスがほしいと思ったときに本当に必要だったもの〜なぜ人は共通基盤の夢を見るのか〜 / @77web / 資料
いかにも現場で起こりそうな判断や失敗が具体的に明示された、とても解かりやすいトークだったと思います。
協調して動作する小規模で自律的なサービス
冒頭でマイクロサービスをこのように定義していました。端的にはこれが全てだと感じており、実際、AさんからDさんまでの4例とも、課題を見た限り前述の3つの定義を満たしているとは思えません。
一方、例にあるような判断ミスが業務中に起こりやすいことも事実だと思います。私自身、初期の設計フェーズならいざ知らず、実装の忙しい真っ只中では、余裕の無さやそれ故の視野の狭さから、こういった判断ミスをしてしまうこともあります。
判断ミスや間違った選択を減らすには、まずは選択肢の幅を広げることも重要だと思います。「マイクロサービス（における失敗例）」という切り口に特化した形で、典型的なアンチパターンと代替案が具体的に示されている点、例示の通りのパターンの時もそうですがそれ以外のケースに遭遇した時も、切り口の異なる複数の案を検討すべきお手本として、主題のメッセージの考え方が広まると良いと思います。
古くなってしまったPHPフレームワークとPHPのバージョンアップ戦略 / @bmf_san / 資料
言語とフレームワークの同時バージョンアップをごく少人数で行う、非常に難しいタスクを完遂された際の、とても貴重な知見を共有頂きました。ありがとうございました。
「難しくする要因」を、様々な要素に分割されていた点が、発表の上でも分かりやすく、また実際にバージョンアップを行う際にも有効に作用したのだろうと感じます。
私の経験の中では「モチベーションの管理」に難しさを感じることが多いです。機能追加とは異なり見た目上のアウトプットが無く、それでいて退屈な単純作業なども含まれてくるため、やはり途中の息切れは避けられない、まさに私も「アップデートのメリット」「学び」と言った点にフォーカスしながらタスクを設計していました。
不確実性の高い課題を優先して対応していく、この点も非常に頷けました。作業の中には、実際にやってみないと結果がわからないようなものも多く、私も同じように「ヤバそうなのをとにかく探す」と言い続けていた記憶があります。
かつて私自身も通った道を思い返させて頂きつつ、それを体系的にまとめて下さったような内容で、とても有意義でした。ありがとうございました。
ウキウキ手作りミニマリストPHP / @uzulla / 資料
昔の苦労や失敗を苦々しく思い出しながら楽しく観ることができました。
プロポーザルには「超ニッチなオタク話」とありました。トークの冒頭でも「既にあるPHPをわざわざ置き換える必要はない」と明言されていました。
確かにそういった側面もあるのですが、同時に私は、この知識を持つ人が、チームまたは組織に最低1人はいるべきとも思っています。
本番コンテナのディストリビューションをバージョンアップしようとしたらビルドが壊れた、使うかはともかくFFIの導入を何らかの機能開発の選択肢に入れたい、こういった状況に対する対応の選択肢の幅を広げることができます。
また最近はphp-srcへのコントリビュートの機運が高まっています。この場合ビルドは当たり前のように要求されるため、PHP自体の発展という観点では是非広めたい知見です。uzullaさんが楽しい語り口でそれを広めて下さったことに、とても感謝しています。
履歴データテーブルとの向き合い方 / @gennei / 資料
「履歴」というとかく間違いやすいテーブル設計を、検討の過程やそれぞれの案に対する具体的なメリット・デメリットを含め分かりやすく解説されていました。
私自身は理解している分野ではあるものの、設計レビューなどで説明に苦労する箇所でもあります。豊富な具体例を含み「間違ったデータの混入が防げる」というメリットまで明示されているこちらの資料は、データベース設計に興味を持ってもらう入口の資料として非常に有用と感じました。
より体系的にまとめられた資料への参照が明記されている点も非常に有り難いです。必要に応じて活用させて頂きたいと思います。ありがとうございます。
帰ってきた「完成度低いの歓迎LT大会」（PHPerKaigi出張版） / @oogFranz
LTを行われた皆様が全員、とてもリラックスされていたのが特に印象的でした。どのLTも社外初登壇と思えない完成度に感じたのですが、肩の力を抜いた落ち着いた語り口によるものが大きいと思います。
冒頭のLT大会自体の説明で、「完成度高い、けしからん」といったチャットメッセージに笑いが起きていましたが、その時にふと「ハードルを下げるのを頑張ってる」と聞こえたのが印象に残っています。
「完成度低いの歓迎LT大会」という名称のキャッチーさが最初に目に入ってきてしまうものの、そうは言っても運営としては、様々な工夫や雰囲気づくりに注力されているのだろうと想像し、頭が下がりました。皆様の落ち着いた語り口もそれに支えられたものだと思います。
LT自体も興味深いものばかりでしたが、それ以上に、最初の発想や運営の想いが伝わる内容でした。良いものを見せて頂きました。
初PHPでサーバーモデルについて考えた話 / @sadnessOjisan / 資料
PHPのカンファレンスに登壇して下さったことをとても感謝しています。
トークでも語られていた通り、PHP（とWebサーバとの統合）は私も「異質」だと思います。この異質さは、他の言語からPHPへ入門する際の大きな障壁となっている一方、PHPerにとってはほとんど疑問を抱かない当たり前の部分でもあるため、ここに壁が出来ていることを勿体なくを感じていました。
現在は、シェアードナッシングが便利すぎるためにレースコンディションや接続リソース枯渇にまで意識が向かないPHPerも少なくなく、PHPのサーバ設計も相まってISUCONでは辛酸を嘗め続ける状況です。そして、FrankenPHPがこの状況に対するゲームチェンジャーになるかもしれない、これが私の認識しているPHP（Webサーバ）の最新事情です。
…という、今まさにのタイミングで、PHP以外の言語での実装やその優位性を、PHPerに理解できる言葉で伝えて下さった点が非常に有意義でした。PHPとそれ以外の言語との架け橋になるようなトークだったと思います。ありがとうございました。
CSRF対策のやり方、そろそろアップデートしませんか / @hiro_y / 資料
体系だった解かりやすい説明がとにかく有り難い、そう感じるトークでした。
特に最近、HTTPリクエスト、Cookie、これらの話題に関する情報共有がとにかく重要に感じています。フロントエンド（特にUI）のエンジニアも普段直接は意識せず、バックエンドもフレームワークの機能で事足りるため深く学ぶ必要はない。一方、（CSRFに限らない話題として）ブラウザのCookieの扱いは年々代わり続け、今年は3PCブロックも開始、しかしこれらに関する知識は空白地帯のごとく熟知したエンジニアが少ない。この現状に危機感を抱いています。
テーマ自体はCSRFですがブラウザの仕様変更やブラウザ毎の挙動の差異にも触れられており、単に実装だけでなく知識のアップデートを促すべきというメッセージが含まれている点が有意義だったと思います。そして「おまけ」という形で最も重要な心がけが語られていました。有意義なトークをありがとうございました。
どうやってWebサービスのページ表示速度を1/3にしたか / @pinkumohikan / 資料
以前からとても楽しみにしていました。そして、期待を裏切らない爽快なトークに、胸がすく思いを覚えました。
「Webページ」「1/3」というトークタイトルにまず驚きました。プロポーザルの本文を読み、扱おうとしている話題の幅広さに驚くとともに、1/3という数字に合点がいきつつ、開催を心待ちにしていました。
トークの前半で「パフォーマンス問題の9割は解法がある」「特定できたらもう勝ち」という言葉がありました。「なるほど、予想通り、これはやり方を既に知ってる人の共有だ」と答え合わせができました。
私も「やり方を既に知ってる」側の人間と自覚しているのですが、周囲からは何か自分しか知らない魔法のようなことをしているように見られることが多く、時に困惑します。
トーク中で語られていた通り、計測し、特定し、解決する。それが無理な場合、直感的な方法で解決可能な方法がおそらく用意されている。アタリを付けてそれを探し、修正する。慣れてしまえば難なく当たり前に実施できると思っています。
この「当たり前」の過程がトーク中盤の軽快な語り口で難しくなく語られている点が秀逸でした。実際には慣れも必要なので未経験者にはもう少し難しいとも思いますが、基本に忠実に従えば何も難しくない、この点を多くの人に伝えられるトークだったと思います。
day 1 Today’s Update / @tomzoh
トークではありませんがとても嬉しい出来事がありました。
当日の私のレギュラートークで、オープニングのナレーションが流れないというトラブルが発生していました。
その時は戸惑いつつもトークが終わったらすっかり忘れてしまっていたのですが、なんとそのトラブルや技術的な原因を「Today’s Update」として共有しトーク自体よりも多い聴衆の前でナレーションを読み上げて下さいました。とても嬉しかったです。
そう言えば長谷川さんは、毎年、最終日のクロージングで「スピーカー、参加者、スポンサー、スタッフ、PHPerKaigiは皆で作り上げている」といったことを仰っているのを思い出しました。PHPerKaigiはとても居心地が良く、普段ほとんど登壇しない私も毎年PHPerKaigiにはプロポーザルをお出ししているのですが、この居心地の良さはひとえに主催者の信念によるものなのだろうと痛感しました。毎年ありがとうございます。
B+木入門：PHPで理解するデータベースインデックスの仕組み / @hanhan1978
プログラマとしての自分の「ルーツ」のようなものを思い出させてくれるトークでした。
PHPを使っている限り、この分野の知識が直接要求されることはほとんどありません。実際私も、本の内容は今となってはほとんど忘れています。
一方、データ構造の良し悪しがアルゴリズムの効率や実装の難度に大きな影響を与えることだけは鮮烈に覚えており、それは、例えばデータベース設計はとにかく熟考を重ねるなど現在の自分の設計スタイルにおそらく活かされています。それを思い出しました。
直接は使わずとも確実に活きる知識だと考えているため、このトークで語られたような知識を、なんとかしてPHPerにも広めたいと私も考えています。
PHPでのB-Treeの実装は、かなりチャレンジングかもしれません。考えたことすら無かったのですが、高級な道具で低級な課題を解決するのは逆に難しいという当たり前の事実に今更気づいてしまい、少し目から鱗でした。
Webアプリケーションの効率を再定義するBEAR.Sundayの分散キャッシングフレームワーク / @koriym / 資料
とにかくモチベーションが上がるトークでした。
私は、エンジニアになるずっと前に、音楽を志していました。とかく「センス」「クリエイティブ」と言った文脈で語られがちな世界ですが、実際にはそれが全てではありません。
楽曲制作のほとんどのプロセスは技術的な問題解決として体系的な理論や技術だけで進めることができます。例えば楽曲の荘厳さや軽快さも、楽器の演奏技術や音響効果という個別の要素に分解し組み合わせるだけで表現できます。
この考えを私は、そのままプログラミングやデザインに適用しながら、Webアプリケーションの開発をしています。
ところが「名曲」はこれでは作れません。ほとんどすべての要素は理詰めで作れるが、最後に心に響かせるための「何か」は、閃きや直感、あるいは時代や流行が左右する。これが私の「ものづくり」の世界観です。
トークの冒頭と最後では、芭蕉の句をメタフレームワークとして導入し、不易をフレームワーク、流行をアプリケーションドメインと位置づけた上で、フレームワークの責務やBEAR.Sundayの設計思想を説明していました。
哲学や思想の世界と技術の世界とを自由に行き来しながらアプリケーションの設計を検討する過程が自分にとって心地よく、また昔から自分がやっている「ものづくり」のやり方を再確認させてもらえるトークになりました。
phpunit/php-code-coverageって何をしてるんだ / @o0h_ / 資料
とにかく徹底的に調べ尽くしていることに驚愕しました。言及の対象はXdebug、PHPUnitに加えOPcacheにまで及び、説明も、関係を図示する程度には留まらず実際のツリーやOpCodeの実例を逐一示されていました。
どれだけの時間をかけられたのか気になったのでトークの後にお聞きしたところ、他のトーク資料と並行とは言え3ヶ月程度とのこと、知識の吸収の量や速さに驚きました。
自分は全く知らない情報を一方的に聞かせて頂くような内容だったため、感想としては「すごい」という言葉しか思い浮かばないのですが、その後の廊下での会話が有意義でした。トーク後の質問コーナーでの私の質問を受け、「仮にphp-code-coverageだけを使い何か新しいツールを作るとしたら？」について簡単にアイディアを考えて下さってました。とても楽しい意見交換を行えました。
トーク本編だけでなく、その後のコミュニケーションでも学びが得られるのも、カンファレンスの醍醐味です。トークの最後でも「普段の業務には役に立たない知識も、いつかどこかでなにかの引き出しになるかもしれない」と語られていました。
技術を真摯に学び続ける楽しさを改めて感じることができました。
超巨大！超重要！な処理のリファクタリングにどのように向き合っているか
リファクタリング自体よりも、対象となるシステムの複雑さや規模に震えるトークでした。なかなか聞けないレベルの話だったと思います。貴重な共有をありがとうございました。
紹介されていた手法や手順自体は、規模の大小こそ違えど私が普段必要に応じて行っているものと似た内容です。しかし、その規模なりに、最初の手順設計の時点で各作業での方針が慎重に検討されていました。
私としてはこれらは、小中規模の範囲内で感覚的にしか進めたことしかない分野だったため、同等の内容を専門チームを設けるほどの規模で体系的に進める場合どうやるのだろう、と思っていました。その答えを教えて頂けたと感じています。
体系的な手順の整理のみならず、作業の副産物となる「識者を増やす」という効果を明確に意識し、理解をとにかく共有することでチーム全員のモチベーションを高め、そういった定性的な効果まで見極めていた点も印象的でした。
「完走した感想」というセクションがありました。「感想」として語られていましたが、これは有意義な「振り返り」だ、と感じました。プロジェクト（仕様整理のみならず、リファクタリング前のコードベースが作られてきたこれまでの歴史全て）を振り返るような内容です。組織ぐるみで内部品質の改善に取り組んでいることが見て取れる「振り返り」だったと思います。
privateメソッドのテストって書かない方がいいんだっけ？ / @asumikam / 資料
とにかく楽しそうにトークする姿、その上で、様々なことを「自分の言葉」として語る姿勢が印象的でした。伝えるべきメッセージがしっかりと伝わってくる素晴らしいトークだったと思います。
実はトークの前半、例えば「私は〜だと思う」と言った表現にある種の勿体なさを感じていました。一意見として述べられていた内容がことごとく「それはその通りだ」と思えたためです。プレゼンテーションなのだから、意見として述べるのではなく、断言して良いのではないか、と。
ところが、話を聞き進めていくとその印象は逆になりました。
実体験としてどう失敗したのか、それに対しどう感じたのか、それを受け何をどう変えたか、これらのストーリーを語るような流れでした。自分自身が体験したストーリーを等身大で語ることで、聞き手により深くメッセージが響く、そんなトークだったと思います。
テストの書き方に答えはありませんが、私が普段気をつけていることとオーバーラップしている部分も多く、それに対する共感や自分自身への安心も得られました。
私はテストを書く時は「そのテストは、単なる実装の二重化になっていないか？」を考えるようにしています。これは「テストとの距離」と表現されていました。テストに限らず様々なタスクで私は「目的を見据えられているか？」を大切にしています。全体として、privateメソッドのテストに「目的」が存在したかが分水嶺であったと振り返っていました。
※ちなみに私も、テスト困難なファットコントローラーの存在するプロダクトで「PHPバージョンアップ」だけのためにテストを書くとしたら、手段を選ばずスコープをこじ開けてでもカバレッジを通すことだけを優先すると思います。
チャレンジし、失敗し、改善していく勇気の大切さを再確認できるトークでした。ありがとうございました。
