SPA全盛の時代ですが、凝ったUIを必要としない社内システムなどでは、
まだまだ古き良きMPA（Multi Page Application）構成を採用することは普通にあります。

MPAだとビューのテストは基本的にフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上で行われるJavaScriptの処理はテストすることができません。

MPAでも一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJSの処理をe2eテストによって楽にテストする方法を、Laravelにおける実装例をもとに解説します。

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れもので、
Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。

このトークでは、API Platformの導入方法から、State Provider・カスタムコントローラ・State Processorといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、

• コミュニケーションパスの数
• 1対1のコミュニケーションにおける対話（パス交換）
• チーム間のコミュニケーション経路

というような、チームコミュニケーションにおける「パス」に着目して、私が大切にしている考え方を共有させていただきます。

ある日、「手動オペレーションに定評がありますね！」（意訳）と言われたことがあります。（全然ネガティブな文脈ではないので安心してください！！！！！！！！！）

特にプロダクトの初期フェーズにおいては、プロダクト自体の機能や価値提供のために、管理画面の開発などの優先順位が下がることがあると考えています。

運用フロー、提供フローが定まっていないうちに画面を作り込んでしまうなどが、「早すぎる最適化」になってしまうこともあるでしょう。

そのような事態を避けるためにも、作り込めるポイントがくるまで、安定した手動オペレーションを行うことはチームにとってもプロダクトにとっても大切なことなのかもしれません。

本トークでは、手動オペレーションを行う際に私がどのようなことを心がけているのか？という話を中心に、作り込めるポイントをどう判断しているのかをお話ししてみたいと思います。

コードの問題点は見た目には分かりにくいことがあります。

知らず知らずのうちに悪いコードが増え、気付いた時には『レガシーコード』と呼ばれるような状態になっているかもしれません。

そこで、問題点に気付くための1つの方法として、コードを計測する方法があると考えています。コードの計測によって得られる情報は多岐にわたり、コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などが含まれます。これらの情報を分析することで、コードの状態を知ることができます。

ただし、計測した数値は必ずしもそれ単体で問題点を示す訳ではありません。そのため、他の数値と組み合わせたり、実際にコードと対比して判断・行動することが重要です。

本トークでは、特にコードをツールで計測することによって得られる結果に着目し、コードの改善にどのようにアプローチするかをお話しします。

Laravelには便利な機能がたくさんあります。

Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどなど…
さまざまな機能を活用することで、スピード感のある開発ができることは間違いありません。

ただ、それらにどっぷり依存することによる弊害も少なくないでしょう。
あまりにも依存しすぎると、ビジネスの変化への対応による作り直し、各機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。

そんなことを想定し、Laravelのコードからドメインのコードが独立するよう、主にInterfaceを利用してドメインロジック（＝わたしたちのコード）を切り出すことを心がけています。

Laravelでプロダクト開発を行う中で、どのようにしてLaravelのコードとドメインのコードの距離を保っているかを紹介させていただきます！

「マイクロサービスは銀の弾丸なのでは・・！？」以前の私はそう考えていましたが、現実は甘くありませんでした。

今回のトークでは、PHPやRailsでゴリゴリにモノリシックな開発に飽きつつあった私が、ゴリゴリにマイクロサービスな開発をする環境に移ってどのような学びを得たかをお話しします。

・経験の前後でマイクロサービスに対して感じたギャップ
・今更感じる、マイクロサービスの長所と短所
・運用の難しさ（複雑性やトラブルシューティング） ※特にフォーカスしたい箇所

これらのテーマに添いつつ、今の会社に移ってから肌で感じた「マイクロサービスアーキテクチャによるプロダクト開発のリアル」を共有し、お互いの学びの場になればと考えています。

※本トークでは、特定のプログラミング言語やライブラリ、フレームワークを深掘りする話はしませんが、私のさじ加減で組織・チームの話は入るかもしれません。

Google Apps Script（以下、GAS）とはGoogleが提供するローコードプラットフォームです。
単なるJavaScript実行環境にとどまらずGoogleの提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的なWebページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説検証のサイクルを回す必要がありますが、GASの備える特性はその際の強力な助けとなります。

本トークでは、その際に知っておくと役に立つ

• GASでできること
• GASを使うときのコツ、Tips
• GASの限界、使うべきでないところ

についてお話します。

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
テレワークは働きかたに様々な利点をもたらしてくれた一方で、新たな問題をもたらした側面もあります。

私たちのエンジニア組織は従業員どうしの関係性や勉強会等の活発さといった文化を強みのひとつとしていました。
そして、テレワーク導入直後にはその強みがほとんど見えなくなっていたのです。
もともと組織文化醸成の役割を担っていた「開発組織活性チーム」は、この問題に対して活動内容をテレワークに適応させるための試行錯誤に舵を切ります。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

常に機能追加が続く運用中の大規模オンラインゲームプロジェクトで、PHPを5.5から8.1にバージョンアップしました。
言語バージョンアップに伴い、PHPUnitも4.5から10に更新しました。

今回のバージョンアップについて、以下のポイントで話したいと思っています。

• バージョンアップの計画と結果（平均レスポンスタイムが42％短縮）
• PHPのバージョンアップでPHP_CodeSnifferをベースにして修正箇所を特定していった話や、そこで起こった問題へ対応
• PHPUnit10にバージョンアップする際、代替手段なしに削除されたメソッドへの対応など
• PHP5.5とPHP8.1を並行稼働させ、運用ツールなどがPHP8.1起因で止まってしまった場合にもゲーム運営を止めない工夫
• バージョン移行後に起こったopcache.jitに関するエラーなど

みなさんはWebAssembly(WASM) はご存知でしょうか?
ブラウザで利用するケースはもちろんのこと、WASI( The WebAssembly System Interface) の普及で様々な利用シーンが考えられるようになりました。
そのようなWASMですが、我々PHPerにとって縁の遠い話だと感じられるのではないでしょうか?実はそのようなことはありません。
ブラウザでリアルタイムにPHPが動作するhttps://php-play.devサービスを作りました。
つまり、WASM化することによって、サーバー以外でもPHPを動作させることが可能になりました。
今回のトークでは、以下の2点をテーマにお話します。

• WASMという技術が我々PHPerにとってどのような恩恵があるのか
• 具体的にPHPのWASM化によって得られる恩恵とはなにか

誰かの書いたコードが世に出る過程で、コードレビューを行う組織は多いのではないでしょうか。
コードの質を担保するため。属人化を防ぐため。知識共有や認識合わせのため。チーム内のスキルアップのため。

コードレビューは様々な意味や目的を持って行われます。

本セッションでは、コードレビュワーがコードレビューイに求められていることとそれに応える方法を下記の例と共に考察していきます。
・PHPコード上でのレビュワーとレビューイのコミュニケーション例
・レビューが活性化するPHPコード例

また、実際に弊社で働く様々なポジションのPHPerエンジニアにインタビューを行い、彼らが求めるレビュー内容をもとに共通項を見つけたり、
レビュワーとしてコメントをするときの工夫点や注意点を紹介します。

レビュー時、依頼時に少しでもお役に立てると幸いです。

対象者： コードレビューを行う全エンジニア（役職問わず）

PHPは読み書きがしやすくユーザーによるコンパイルが不要な素晴らしい言語です。その魅力的な構文と特性を支える素晴らしい立役者がいることをご存知でしょうか？本トークでは私たちが愛してやまないPHPの裏側を紹介します。

対象者

• PHPの内部について興味のある方
• PHPの初中級者

話すこと

• PHPの言語のパースと実行メカニズム
• Zend Engineなどの仕組み

話さないこと

• PHPの書き方や文法の解説

昨今のChatGPTをはじめとした生成系AIはますます盛り上がりを見せており、いくつもの企業が生成系AIを利用した事業の発展を宣言していたりします。
そんな中で、自分が携わるプロダクトでも生成系AIを導入したので、その背景や過程について共有していきたいと思います。
まず、なぜ生成系AIを導入しようと考えたかの背景や、その検証のさいに困ったこと、そして助かったことなどについて話します。
次に、生成系AIで利用したAzureのOpenAIサービスについて、できることを簡単に述べたのち、実際にどのように実装したのかについて紹介し、AIが生成するものの不確実性との戦いについても簡単に見ていこうと思います。
最後に、生成系AIを導入した結果どうなったかが表れていると思うので、その結果について共有しつつ、今後の生成系AIの発展についても紹介したいです。

「ユニコーン企業のひみつ」「チームトポロジー」の翻訳もあり、エンジニア組織の形態についての発信が増えたと感じます
主にはシニアテックリードやCTO・VPoEの視点からの、組織全体レベルでどうデザインするか？が多いですよね

コミュニケーションやチームに関する課題は、もっと卑近な単位でも発生します
仕事をうまく行かせるための大〜小の組織づくりについて、学んでみませんか？
「組織パターン」は、発売は10年ほど前ですが、組織に関する知見がパターン・ランゲージ形式で纏められた1冊であり、多くのヒントが得られるはずです

本トークは「ちいとぽよりも小さく、明日から使える組織づくり」を主眼に、書籍の内容・使い方を、実際の活用経験を交えて紹介します

対象

• 全体までは見ていないが、組織について考えている人
  • チームリーダーやEMなど

PHPの配列（HashTable）は内部的には２つの実装で表現されています。１つはキーがそのまま添字となる配列、もう１つはハッシュ表を用いる連想配列です。
キーがそのまま添字となる配列（PackedArray）は、PHP8.2からzval構造体の配列となり、Bucket構造体が不要になりました。

このトークでは、PHP8.2におけるHashTableの解説と、HashTableからデータを探索する処理（zend_hash_lookup）、PackedArrayが通常の連想配列へ変換する処理（zend_hash_packed_to_hash）についての説明を行います。

対象者

• php-srcに興味がある人
• データ構造が好きな人

話さないこと

• PHP≦8.1の話
• 探索以外のHashTableの基本操作（追加・更新・削除）
• （パフォーマンスなど）実用的な話

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

Fiber は、PHP 8.1 から導入された stackful な coroutine です。
ここで一度、Fiber の実装を PHP の処理系レベルまで追いかけることで、Fiber が何であるか、そして、裏で何をしているのかを理解することにしましょう。

主な対象

• 非同期処理の内部実装に興味があるかた
• 言語処理系の内部実装に興味があるかた

話すこと

• PHP における「Fiber」とは何か
• PHP の VM (virtual machine) のおおまかな構造
• Fiber を実行・停止・再開・中断したとき、PHP VM に何が起こるか

話さないこと

• Fiber を裏で利用するライブラリやフレームワーク

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

  話すこと

• PHP における GC のアルゴリズム
• 確保したメモリはいつ解放されるのか
• メモリ溢れを起こさないプログラミング

  話さないこと

• GC のパラメータをいじってチューニングする

不正アクセスが怖くて夜しか眠れない、情報流出のニュースを見るたび不安で寿司しか喉を通らなくなる、
Webエンジニアはこういった日々を過ごしていると思います。

このセッションではLinuxの機能 AppArmorを用いて、PHPアプリケーションのセキュリティを外側から強化する方法を紹介します。

自分達が書くPHPコード自体の脆弱性だけではなく、フレームワークやライブラリ、またHTTPサーバー自体の脆弱性もカバーできる便利な機能です。
OSの機能でアプリケーションに対してファイルシステム・ケーパビリティ等の制限ができ、設定ファイルを用意すれば使えるため採用の手間も大きく有りません。

お客様のデータを預かるWebサービスでは信頼が第一、まだ使われていない方も使おうと思えるよう、具体的な設定例も踏まえて説明できればと思います。

【想定対象】
バックエンドエンジニア、インフラエンジニア

「コードレビューが順調に進んだほうが、チームの生産性が上がる可能性が高い」ということについては、違和感なく思う人が多いのではないでしょうか。

「順調に進める」ためには、それを意識することだけでなく、レビューする側・レビューを依頼する側のそれぞれにテクニックが必要になってきます。

このトークでは、かつて、「おまえのプルリクエストは大きすぎてレビューできない（意訳）」と実際に言われたことがある発表者が、現在までにどのような工夫をして「分割プルリクエスト」にたどり着いているのかを共有したいと思います。

なお、このトークのタイトルは「リーダブルコード」にインスパイアされていますが、トーク内容については特に関係するものではありません。

■想定する対象者

• プルリクエストのサイズが大きくなりがちなかた

■話さないこと

• コード自体をどう読みやすく書くか、など