トーク

PHPの、新しいExtension Installer・・・PIE!
php/pie: The PHP Installer for Extensions

そして、このツールで導入できる拡張たちは、Packagist上で検索やメタ情報の取得ができます。
・・・となれば、興味が湧くのは「ここで、どんな情報が扱われているのか」ですよね✨️
また、従来からPackagistで扱われていたComposerパッケージのそれとは、なにか違うのでしょうか？
更に言えば、ここで取得された情報は、どんな役割を果たして、PIEによるインストールのプロセスに役立っているのでしょうか？？

この記事では、「PIEをどう使うか」「どう活用・運用していくか」といったトピックには重きを置かずに、
「レポジトリ(Packagist)の提供するAPIとして、どうなっているの？」といった内部事情・詳細部分にフォーカスを当てた、
ちょっとニッチな話題を扱います。

API Platformという、APIを作るためのフレームワークがあります。

便利なフレームワークである反面、引き換えに犠牲を伴うことが多くありますが、
その話題がのぼるほど利用者がいないのではないか…と思っています。
なので、API Platformを広めるために便利機能を見開きでわかりやすく！お伝えします。

現代のソフトウェア開発において、脆弱性への対応は非常に重要な課題です。PHPを使用したウェブアプリケーションにおいても例外ではなく、フレームワークやプログラミング言語、ミドルウェア、OSなど、様々な要素において脆弱性が発見される可能性があります。

このパンフレット記事では、そんな脆弱性情報をどうやって日頃から収集するのか、そしてどのようにして自分のウェブアプリケーションが脆弱性にさらされていないのか確認・検知するのか。
また、実際の対応方法について紹介します。

本記事で記述する内容

• 脆弱性情報の収集方法
• 脆弱性検知の方法
• 検知された脆弱性の対応優先度の決め方
• 実際の対応方法

例えば、何かのテストケースを1つ実装します。 vendor/bin/phpunit で、テストを実行します。
その後に起こることは何でしょうか？
「CLIの入力を解釈して」「設定ファイルを読み込んで」「実行可能なテストケースを列挙して」「実行対象のテストケースを選別して」「実行順序等のオプションがあればそれも考慮し」・・・

「普段は何気なく使っているPHPUnitも、良く考えたら色々なことをしていそうだ」なんて気持ちになりませんか？

PHPUnitを支える仕組みに、イベントシステム(Observerパターン)があります。
例えば https://github.com/sebastianbergmann/phpunit/tree/11.4.0/src/Event/Events を見てください、こんなに色々なイベントが定義されています！
これにより、複雑に要素が絡み合った「テスト実行」の全体の中で、要所要所の拡張性が高く保たれている訳です。

見方を変えると、PHPUnitの管理するイベントに着目することで、テスト実行のライフサイクルの骨子を掴めます。
つまり「イベントを知る」=「FWの思想に触れる」ための手掛かりになるのです。
また、エクステンションと呼ばれる機構を用いて、任意のイベントを利用した機能拡張も可能です。

知っているとPHPUnitとちょっとだけ仲良く慣れるかもしれない、どこかで役に立つかもしれない、
そんな仕組みに触れてみませんか？

記事の内容

1. PHPUnitの持つイベントシステムの仕組み(実装観点での概要)
2. 用意されているイベントの紹介
3. 「Extension」入門・実例の紹介

本文

Language Server Protocol (LSP)は、2016年にMicrosoftが発表したJSON-RPCベースのプロトコルです。
LSPはモダンなテキストエディタなら必ずある機能(例: 定義ジャンプ)を提供していますが、一番の魅力は特定のテキストエディタに依存しない形での実装になっていることです。
これにより各テキストエディタでの実装の必要がなくなり、エディタ選択の自由度が飛躍的に高まりました。

PHPの言語サーバ実装はintelephenceとPhpactorがメジャーです。
本登壇ではPhpactorの実装に触れつつ活用テクニックを紹介していきます。

パンフレット記事に記載すること

• LSPの台頭とLSP前後のテキストエディタの変化
• プロトコル解説とLSPがサポートしている機能の紹介
• PhpactorとPHPStan拡張などの便利な機能の紹介

2024年、PHP界隈では日本各地で個性あふれるカンファレンスが開催されました。
それぞれの地域が持つ特色や、カンファレンスごとに感じられる独特の雰囲気、そしてコミュニティの良さがぎゅっと詰まった一年でした。
そこでこの記事では、各地域のカンファレンスが見せてくれた魅力をasumikam視点で語ります。

みて楽しい、いって楽しい、そしてやっぱり学び深い。
「次あれば行ってみたい！」「足をのばしてみようかな？」と思えるようなワクワク感をお届けします！

そして迎える2025年（もう迎えてる）、PHPカンファレンスはさらに進化を遂げ、新たな伝説が始まるかもしれません…。
伝説を一緒につくるのは、あなただ！

PHPStanは明示的な型宣言と型推論、そして動的型拡張の3種類を組み合わせることで動的言語に実用的な型付けを提供する静的型検査ツールです。

本記事では「PHPStanクイックガイド2023」「キミにも作れるPHPStan拡張」の内容を踏まえ、前述の3種類の型付け方法の考え方をもとにあなたのコードに効率よく安全に型付けできるようにするための指針を提供します。

皆さんはコードゴルフというe-スポーツ（※）についてご存知でしょうか。本来のスポーツであるゴルフはスコアを低くしていくことを求められるワケですが，コードゴルフも同様に短くコードを書くことが求められます。アルゴリズムやパフォーマンス，コードの視認性などは関係ありません。いかに短く書くかが重要です。
さて，そんなコードゴルフを楽しむために，本セッションではコードゴルフの基礎から，どのようにコードを短くしていくかテクニックを含めて，そしてあなたが将来のコードゴルファーとして一人前になれるように LT で解説していきます。

※ 筆者の見解であり，非公認です。

「フレームワークに依存するなと言っても、フレームワーク移行なんてほぼ起こらないのでは？」
そう思っていた頃が私にもありました。では、いま使っているフレームワークが開発停止になったらどうしますか？
かつて、symfonyはv1.4で開発を停止し、Symfony v2.0という名前で全く新しいフレームワーク（Symfony v2〜最新のv7は連続性があり、v1のみ別）に生まれ変わりました。
維持されたのは名称とMVCアーキテクチャベースであることだけ。使い方も、考え方も大きく変わってしまいました。当然、symfony v1を使ってアプリケーションを開発していた世界中の開発者は大混乱。
「ほぼ起こらないのでは？」と言われつつも、私がフレームワークに依存しない開発を求めてしまう原動力となっている当時の大混乱をふりかえり、フレームワークに依存しないことのメリット・デメリットと現代でのやり方についてお話します。

皆さんはDaemon（デーモン）をご存じですか？Daemonとは、バックグラウンドで実行され続けるプログラムのことです。ジョブキュー、バッチ処理、アプリケーションサーバー、クローラーといった役割を担うプログラムがその例です。

このトークでは、PHPを用いてDaemonプログラムを「飼いならし」、実用的に運用する方法についてお話します。具体的には、Daemonとはどのようなものなのか、その基本構造や必要な技術を解説します。PHPでのメインループの実装、シグナル処理、終了時のリソース解放といった基礎から、安定稼働を支えるスーパーバイザー（systemdやコンテナ）との連携、監視の仕組み、さらには並列処理やワーカーの協調についても取り上げる予定です。

もし、まだデーモンを「飼いならした」ことがない方は、Daemonという言葉だけで少し身構えるかもしれません。でも安心してください。初心者でもわかるシンプルなDaemonプログラムの構築方法から丁寧にお話しますので、召喚する楽しさ、支配するスリルと万能感を得られる要になると思います。

単純なウェブアプリや、Cronによるバッチで物足りないPHPerのあなたも（あるいはそうでないあなたも）、この機会にDaemonを造り、飼いならしてみませんか？

OpenAPIはAPIの仕様を記述するための仕様で、リクエストやレスポンスの詳細をYAMLまたはJSON形式で記述することができます。これを採用すると、記載内容を統一できる、バージョン管理しやすいなど様々なメリットがあります。
しかし、単なる仕様書と考えていると、徐々に実装との乖離が生まれてしまうリスクがあります。

これを防ぐための仕組みとして、OpenAPIドキュメントを使ってコードを生成したり、実行時に検査をする手法があります。
本セッションでは、Slimフレームワークを採用したシステムにOpenAPIドキュメントを用いたバリデーションとテストを導入した実例をご紹介します。
具体的には以下のような内容を含みます。

• OpenAPIを導入する際のポイントと注意点
• 具体的な実装方法 (league/openapi-psr7-validator)
• 導入の効果と進め方の反省点

Slim以外のフレームワークをお使いの方にも役立つセッションになるはずです。

リッチなUIを実装するために多くのアプリケーションでjQueryが利用されています。JavaScriptのAPIやCSSの機能拡充によりjQueryの出番は減ってきているものの、導入の簡単さ、APIの使いやすさ、プラグインの豊富さから「MPAで画面の一部をリッチなUIにすること」においてはjQueryはまだまだ最適な技術の１つです。しかしながら、DOM操作の命令的なコードはロジックやUIが複雑になると保守性が悪くなる傾向があります。

一方で、ReactやVue.jsなどのフレームワークは、宣言的UIにより保守性が上がるものの、学習コスト・運用コストの点でtoo muchになるケースも少なくありません。実際、LaravelをAPIサーバーとして利用するようなフルSPAよりも、MPA + 小〜中規模のJavaScriptで十分に要件を満たすアプリケーションがほとんどではないかと思います。

そこで、jQueryに代わる選択肢として注目されているのがAlpine.jsです。Alpine.jsはMPAでリッチなUIを構築するのに適したJavaScriptフレームワークです。Livewireの作者が開発したOSSですのでLaravelやLivewireとの連携も簡単で、ビューファイル内に宣言的UIとして実装できるため保守性が高いことが特徴です。

本トークではLaravel MPAにおけるフロントエンドの実装手法についてお話します。Alpine.jsを使ったフロントエンド実装を中心に、宣言的UIと比べたときのjQueryの優位性、ViteによるビルドやNodeモジュールを使ったバージョン管理、JavaScriptの管理パターン、Blade連携、コンポーネント化について紹介します。このトークが、Laravel MPAにおけるフロントエンド技術選定の参考になれば幸いです。

依存性注入(DI)は、単体テストを書きやすくして、変更容易性を上げるために有効なアプローチです。また、Laravel等のフレームワークでも使われており、その動作を把握するためには、DIの理解が必要になります。

しかし、学び始めたタイミングでは直感的ではないため、難しく感じることもあるかもしれません。

このトークでは、依存という概念を「使う・使われる」という、簡単な言葉で整理して、理解しやすくすることを目標とします。

話すこと

• 「依存している」とは「使っている」ということ
• 依存すると何が困るのか
• 依存を外から与える(注入する)メリット
• DIの実装例

私が現在開発に携わっている販売管理サービス「楽楽販売」は誕生して15年以上経つプロダクトです。
フロントエンドにフレームワークは利用しておらず、長年にわたり静的に生成されるHTMLの画面部品コードがコピペされ続けており、共通化が行われていない状況に陥っています。
その結果コピペコードは新画面を作成するたびに増殖していき、PhpStormが親の仇の如く「Duplicated Code」を指摘してきます。

この課題を解消するため、私たちは以下の2つの目標を重視し「画面部品のUIコンポーネント化」に取り組みました。
　・新しい画面を作成する際に、コピペする必要がない環境を構築する
　・画面の構成パーツに何があるのかを容易に把握できる仕組みを作る

ゴールは以下２点です。
・複数画面から共通利用可能なUIコンポーネントを作成する
・将来的なコピペを駆逐すること

本セッションでは、取り組みの背景の課題から具体的な解決策、さらに実践例までを詳しくご紹介します。

■お話しすること
　・なぜUIコンポーネント化が必要か
　・どのようにコンポーネント化を進めたか
　・コンポーネント部品を活用してもらうための施策

■想定する視聴者
　・技術負債を解消したい人
　・フロントエンドのフレームワークを利用していない人
　・画面部品のUIコンポーネント化に興味がある人
　・レガシープロダクトから脱却したい人

みなさん、ドメインイベントって使っていますか？

このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。
ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルです。注文の完了やユーザー登録のようなビジネスプロセスの特定の状態変化を表現できます。
これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。

ドメインイベントを導入してみると、「あ、こんな風に設計すれば良いんだ！」と新しい発見があるはずです。リファクタリングを通じて、どうやってドメインイベントを設計し、活用するのか、その具体的な手法をお伝えします！

話すこと

• ドメインイベントって何？
• リファクタリングでドメインイベントをどう導入するか
• システム間の連携を簡単にするイベントの使い方

オブジェクト指向大好きPHPerのみんなで、構造化プログラミング以前のスタイルで考えてみよう というトークです
クラスも無ぇ、制御フローもマトモに無ぇ、globalやgoto頼り！！！
非構造化の世界で、ぼくらの「認知負荷」は、どうなっちゃうの・・！？

開発生産性や変更容易性が特に重んじられる昨今、「認知負荷」との闘いに多くの時間が費やされます。
プログラミング言語もまた、こうした課題を解決する「あるべき姿」へと進化してきました。

一方で、「解決済み」の問題は見えにくいものです。
関数を定義できる、if-elseが使えることに、感謝の気持ちを抱いていますか？

それを理解するためには、温故知新のアプローチが役立ちます。
時代を遡ってみましょう。
オブジェクト指向以前の・・・手続き型？いいえ、もっと根源へ──
脱・構造化です！

この探求の先に、「今とは全く違うように見えるパラダイム」と「現在の姿」が地続きであると実感することでしょう
そして今の世界にも通じる「良さ」の再確認へと繋がるトークを提供します

みんなでスパゲティを食べに行きましょう

対象者と得られること

• 「どうしたら読むのに疲れるコードを生み出せるのか」に興味がある人
• 逆説的に「普段の開発で避けるべきこと」を知る

話すこと

• 構造化プログラミングの簡単なおさらい(定義・歴史)
• 「非構造化」のルールに則って書いたコードの紹介: お題 => 簡易CMS
• これらを踏まえ「我々が普段やっている&戦っていることはどんな意味があるの？」の確認

「非構造化」のルール(一部)

• 使わない: クラスや例外、while(true)以外のループ、名前空間
• 制限する: ユーザー定義関数 => 引数は使わない、値を返さない
• 使う: gotoや標準関数は使う

レガシーと向き合い続けるって大変ですよね。
大小様々な問題を抱えながらも、小さなパッチを当て続けることで生き抜いてきた、まさにプロダクトの中枢。
これはそんな「レガシーシステムのフルリプレイス」という大きな課題と向き合った、とある小さなチームの挑戦記です。

弊チームでは先日、大きな障害を出すことなく、レガシーシステムのリプレイスを終えることができました。
その際に以下の検証手法・リリース手法を組み合わせて、リスクを最小限に抑える「安全に倒し切ったリリース」を実現しました。

• チームオリジナルの検証手法「ペンギンテスト」
• シャドーテスト
• カナリアリリース
• ダークローンチ
• フォールトマスキング など

特筆すべきは「ペンギンテスト」で、これは以下のような特徴を持ったオリジナルの検証手法です。

• 本番環境で実際のデータを使いながらも
• ユーザー影響は出さない
• 未然に徹底的に見落としを削ぐための検証

この「ペンギンテスト」についてを主軸に、どのようにして予期せぬトラブルを未然に防ぎ、
計画通りのリプレイスを成し遂げたのか、その実践的なプロセスについて詳しくお話しします。

他の組織、チーム、プロダクトでも応用可能な知見を共有するので、
今同じような壁に直面している方には、有用な解決策の一つとして聞いていただけます。
安全に倒し切ったリリースを必要としている方、そして日々レガシーシステムと向き合う方は必見の内容です。

PHP 8.4では、BCMathにオブジェクトAPIの追加と処理の高速化という大きなアップデートが行われました。このトークでは、BCMathの処理速度向上について詳しく解説します。まず、従来のBCMathが「なぜ遅かったのか」を明らかにし、その問題点を具体的に説明します。その後、新しいコードの改善点や実装方法について詳しく説明します。普段PHPを使用する際には見えない部分であるメモリ管理やCPUの処理が主なテーマとなります。これにより、BCMathの内部動作への理解を深めていただける内容となっています。

PHPフレームワークとして広く採用されているLaravel。その最初のコミットは 2011年6月8日 のことでした。
それから約14年。Laravelは進化の過程で何を大切にし、どのような機能追加を重ねてきたのでしょうか。
本トークでは、ChatGPT、Claude、Geminiを活用し、14年分のGitHubのコミットメッセージを分析。Laravelの設計思想の進化を取り上げます。

特に以下の観点から解説します：

• 黎明期のシンプルさから、モジュール化への進化（Laravel 3-4）：Composerの採用とFacadeパターン導入
• 現代的アーキテクチャへの転換（Laravel 5-8）：サービスコンテナ導入がもたらした開発体験の変革
• パフォーマンスとスケーラビリティの追求（Laravel 9-）：Octaneの採用に見る実行モデルの転換点

生成AI時代だからこそ、コードを書くだけでなく「なぜそのような設計を選んだのか」を理解することが求められる今日。
先人たちの試行錯誤から、私たちの開発に活かせるアイデアの種を見つけましょう！

本セッションでは、CSVファイルのダウンロード速度が遅すぎて切り戻しになった知見をもとに、Laravelアプリケーションのパフォーマンス改善のデモンストレーションを行います。
「頑張って作ったのに遅すぎて使ってもらえない」では悲しすぎるので、ご参考にしていただけますと幸いです。

以下のテーマに沿ってデモをしていく予定です。
・ しくじり談
・ DBからのデータ取得時に気をつけること
・ 取得したデータを加工するときに気をつけること
・ 加工したデータを出力するときに気をつけること

キーワード
・ Eloquentとクエリビルダ
・ N+1問題
・ メモリ
・ ジェネレータ

想定視聴者
パフォーマンスを意識したコードを書ける・レビューができるようになりたい方