盛り上げます！

小田原っこ: 小田原に住んでます。ラブ。

PSR-15はPHP-FIGが勧告するHTTPハンドラとミドルウェアの標準仕様です。仕様の基盤となるPSR-7とともに非常に簡潔なインターフェイスの素晴らしい仕様です。

このトークではPSR-15がどのようにミドルウェアの仕組みを提供するのか、シンプルすぎるPSR-15とPSR-7の実用アプリケーションでの利用しにくさを改善できるかの試み、そして拙作のPSR-15ディスパッチライブラリHakoneの設計思想についてコンパクトにお話しいたします。

GitHubが提供するCI/CDサービス 「GitHub Actions」。
ドキュメントが充実していて簡単に使い始められる反面、ジョブが終わらなくてキャパを食い尽くしてしまったり、GitHub Actionsが障害中でCI/CDが出来ない、などのトラブルも耳にします。

本トークでは数多のプロジェクトでGitHub Actionsと戯れときに事故に向き合ってきた体験をもとに、GitHub Actionsを使うときにやっておくと良い設定をご紹介します。

お話しすること

• GitHub Actionsのおさらい
• タイムアウトの設定は必ず
• バージョンは明確に
• CIで出来ることはローカルでも出来る状態が理想
• 3rd-party Actionsは定期的にバージョンアップしましょう
• Environment VariablesとSecretsは正しく使い分けよう

PHP8.3が2023年11月リリース予定です。

PHPカンファレンス小田原2024が実施される頃には、皆さんの理解も進んでいることでしょう。

一方ですべての方がその機能を理解しているとは限りません。

今回はそのPHP8.3の機能を、小田原の地で一緒に振り返りましょう。
あと話者の趣味でパフォーマンス比較も行います。

• お話すること
  • PHP8.3の機能に関して
  • PHP8.3のパフォーマンスと、今までのPHPのパフォーマンス比較に関して

SRE、この言葉からあなたは何を想像しましたか？
会社のAWSアカウントを管理してくれている人！困ったときに助けてくれる人！SLI/SLOを推進する人！
さまざまあると思います。
SREの起源であるGoogleではSRE(サイト信頼性エンジニア)の名の通り、運用するサービスの信頼性を保つことが責務とされていました。
現代では Enabling,Embedded,Platformなどなど多様なSREが存在しています。
サービスの信頼性を保つという観点は同じでもそのアプローチ方法は多様です。
このトークではこれらの違いについて弊社での実体験も交えて説明します。
ぜひ、皆さんの会社におけるSREについて考えるきっかけを作れればと思っています！

小田原っこ: 小田原の会社で働いていました!

（初心者向けトークです）
PHP Data Objects（PDO）は、DBへのデータアクセスを抽象化する、軽量で高性能な拡張モジュールです。PHPでWebアプリケーションを作成するときは、多くの機会でPDOを利用する事があります。

このトークではPDOの基礎的な使い方から、実務レベルでRepository層でのPDOの扱い方についてお話しします。

対象者

• Webアプリケーション開発の経験が浅い方
• ORMなどは使った事があるけどPDOは無い方

話さないこと

• PDOの内部実装について

Architecture Decision Record (ADR)はご存知でしょうか？
設計に関する議論や決定をまとめておく文書として、近年注目を集めています。

本トークでは、実際に会社でADRを導入して一年以上運用した結果、開発現場で継続的に使われているのかどうかなど、 実情を赤裸々にお話します。

本トークで話す内容

• ADRとはなにか？
• なぜ、導入する必要があるのか？
• 実際に導入してみて苦労したこと
• 良かったこと、悪かったこと

概要

JIT コンパイルとは、実行時にネイティブコードへのコンパイルをおこなうことです。
PHP では、バージョン 8.0 から導入されました。
PHP 8.4 (プロポーザル記述時点での予定) では、8.0 で導入された JIT エンジンが作り直され、新しい JIT エンジンが導入される予定です。
このセッションでは、新しく入る JIT エンジンについて、現在の実装と比較しつつ紹介する予定です。

話すこと

• JIT コンパイルとは
• 現在の JIT エンジン
• 新しい JIT エンジン
  • 何が異なるのか
  • どのようなモチベーションで導入されるのか

目標

• JIT コンパイルとは何か理解する
• 新旧の JIT エンジンについて知った気になる

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

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

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

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

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

P.S. 浜松っこです。

近年、PHPプロジェクトの品質を高めるためのツールとしてPHPStanのような静的解析ツールが導入されるケースが増えています。

PHPStanを導入することによって、PHPでもJavaやTypeScriptのように静的解析の恩恵を受けることができます。

• コードを解析しやすくなるのでIDEが賢くなって補完やコードジャンプがしやすくなる
• 網羅的に検査しているのでコード修正によるエンバグを減らすことができる
• etc

既存のコードベースに初期導入するのは、コードベースが大きい程ハードルが高くなりがちです。
本トークでは40万行のLaravel PHPにPHPStanを導入した実例を踏まえて、どのように導入したのかをお話しします。

想定対象読者

• これからLaravelにPHPStanを導入したい人
• PHPStanを継続的に運用する方法に興味がある人

テストの目的は、迅速に進めるための十分な自信を得ることであり、より多くのコードをテストすればするほどチームはより自信を持つことができます。

しかし意味のない努力をしていないでしょうか？

• カバレッジ100%を目指すことにこだわるあまり、肝心な業務要件のテストが漏れている
• カバレッジレポートを見ていないせいで、重要な処理が集まるパッケージへのテストが漏れている
• そもそもテストコードがきちんと書けていないため、カバレッジレポートの数値が正確ではない

これらのアンチパターンに陥った場合、品質を高めるどころかむしろ下げてしまう方向へ努力していくことになります。

このトークでは、上記のようなアンチパターンに触れながら、努力に見合ったテスト品質の向上を目指すためのノウハウをお話しします。

テストを書くとき、テストデータ（テストフィクスチャ）をどのように用意していますか？プロダクションコードを改修するとき、テストフィクスチャにも多数の改修作業が発生してつらくなっていませんか？
私は10年近くテストのある開発をしてきた経験から、テストフィクスチャもオープン（拡張に対して開いている）で、クローズド（修正に対して閉じている）にするのが良いのではないかと思うようになりました。
このトークではまず様々なテストフィクスチャの作り方を概観した後、オープン・クローズドなテストフィクスチャを実現するために現時点でベストだと私が思う方法をお伝えします。

テスト書いてますか？ますよね？
─果たして、本当にそれが正解でしょうか。

テストには「欠陥があることの証明」が重要です。
「証明しなくて良い事」が増えれば、テストの責任も軽減されるでしょう。
つまり、書くべきモノが減ります！！
実際に、設計技法やPHPの機能、ツールによって、そんな願いが叶えられると考えます。
例えば「引数にint型宣言」で、「文字列を受け取ったらどうバグるかの証明」はお役御免です。

良い意味でテストを減らす道・・・探りましょう！

持ち帰って欲しいもの

• 改めて「テストの訳」に立ち返る
• 「横着してテストを書く」以外の方法を模索する

話すこと

• 単体テストに何を期待していますか？
• 安心できて開発体験も良いコードに想いを馳せる
• 「テストを書く」以外に責任を分散する

話さないこと

• E2Eなど、単体テストよりも「広め」のテストについて

締めます