トーク

PHP 8.5で導入されるパイプ演算子（|>）、楽しみですね！

パイプ演算子を使うと、
strtoupper('hello')
と
'hello' |> strtoupper(...)
が同じ意味になります。

実は、例にあげた2つの式は、opcodeとしても同一です。

このトークでは、php-srcのソースコードを読み解きながら、パイプ演算子がどのように実装されているかを見ていきます。

具体的には以下の内容を扱います

• vldでのopcodeの比較
• opcodeのコンパイルに使われるzend_astとznode
• パイプ演算子を処理するzend_compile_pipe

PHPの新機能を通じてphp-srcに入門してみましょう

6年間運用したPHP製テレビCM分析管理画面で、ストレージとデータ構造の限界から大規模刷新を決断。この機会に、アプリケーション全層の型安全性も確立する統合的リアーキテクチャを実行した事例を紹介します。
きっかけはストレージのスケーラビリティ問題でしたが、管理画面特有の複雑なビジネスロジックにおいて、各層での型の曖昧さが顕在化していました。インフラ刷新と同期させることでリスクを最小化しつつ、gRPC-Connect+静的型付け言語への完全リアーキテクチャを実現しました。
本トークでは、インフラ起点で全体を巻き込む意思決定プロセス、リアーキテクチャの設計と実行、各層での型問題の具体的な解決例、DIを活用したテスタビリティ向上について、実コードとともに解説します。管理画面システムの統合的リアーキテクチャの実践知をお届けします。
話すこと: 実践的な移行プロセス、型とDIによる品質向上の具体例

現代のPHPフレームワークでは、Dependency Injection(DI)が標準機能として組み込まれ、その有用性は広く認知されています。
しかし、既存の動いているアプリケーションへ適用するにはどうすれば良いでしょうか？

本トークでは、実運用されているレガシーアプリケーションや、Ray Di for Laravel など、複数のDI適用事例を基に、実践的な戦略を共有します。
フレームワークとユーザーコードの境界線、既存のライフサイクルに配慮した依存性注入の活用、マーカーパターンによるルートオブジェクトの識別など、既存アプリケーション特有の課題と、その解決策を具体的なコード例と共に紹介します。

本トークを通じて、既存アプリケーションにDIを導入する際に考慮すべきポイントを持ち帰っていただき、明日から実践できる知見を提供します。

皆さんは機能を作成する際に、何から始めますか。

私は情報設計に取り組むチームに所属しており、日々情報設計と向き合っています。
情報設計とは、Web に限らず情報の整理が必要なあらゆる場面で活用できる普遍的な設計の考え方で、受け手が望んだ情報を適切に与える方法を作ることです。

先日、私たちは概念オブジェクト（ユーザーがイメージする「写真」や「メール」のような対象物）を発見し、Slack ワークフローを作成するワークショップを主催しました。

ワークショップでは「なに が なに を どうする」という構文から概念オブジェクトを発見しました。発見された概念オブジェクトは開発者以外にも伝わる共通言語となりました。

本トークでは、ワークショップでおこなった誰にでも分かりやすい概念オブジェクトの発見の方法から、PHP のコードがどのように現れるかを考察しどのような恩恵が得られるのかをお話します。

テレビCMを軸にマーケティング分析プラットフォームを開発する株式会社テレシーで、Laravel Novaは6年間、私たちの事業成長を支え続けてくれました。管理画面の爆速開発を実現し、今の事業スピードを可能にしてくれたのはNovaのおかげです。なぜNovaを選んだのか、どのように事業にインパクトを与えたのか、そしてなぜ今、別れを決意したのか。
本トークでは、Laravel Novaの強みと適用領域、運用で見えてきた限界点、そして「卒業」のタイミングの見極め方を、実際のコードと共にお話しします。さらに、次の技術への移行で採用した仕様書駆動開発のアプローチもご紹介。
Laravel Novaは適材適所で本当に輝く技術です。これから導入を検討している方には最適な活用シーンを、すでに運用中の方には「卒業」のタイミングを見極めるヒントをお届けします。6年間の感謝を込めてお話させて頂きます。

「どこで何が起きているのか分からない」──複雑な処理が詰め込まれたコードを前に、そう感じたことはありませんか？

本セッションでは、そんな不透明なロジックを “出来事” を軸に整理し直す、イベント駆動アーキテクチャへの段階的な移行プロセスを紹介します。
「〇〇が起きた」というドメインイベントを導入し、処理を手続き型から宣言的なスタイルへと転換することで、コードの見通しや責務を明確にしていきます。

まずは同期イベントによる責務分離から始め、そこから非同期イベント処理へと進化させる3ステップを、PHPコードの実例とともに解説します。
さらに、非同期化に伴って生じる整合性の落とし穴についても、Transactional Outbox などの実装パターンを交えて紹介。

“出来事”を中心にコードを組み立てることで得られる、読みやすさと保守性を兼ね備えたアーキテクチャ設計のヒントをお届けします。

PHP では try-catch による例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか？
過剰なエラーハンドリングや、catch したけれど何もしていない“握りつぶし”が積み重なると、責任の所在が曖昧になり、コードの見通しや保守性にも悪影響を及ぼします。

こうした課題へのヒントとして、Rust などの言語で採用されている Result 型の考え方を、PHP に応用するアプローチがあります。
Result 型は、失敗を型として明示的に扱い、成功も失敗も返り値で表現する設計手法です。

本セッションでは、さらに一歩進んで、処理の流れを線路のように“合成”する「Railway Oriented Programming」の考え方を取り入れ、複雑な分岐処理をシンプルに記述する実践的な方法を紹介します！

プログラミングにおける "関数" は 数学の写像とは同じではないものの、一部似た性質を持っています。
数学における写像は集合と密接に関係しており、それらは関数と型に対応します。

集合なしには写像は定義できず、プログラミングでも型なくして関数は定義できないと言っても過言ではありません。
しかし、PHPのような型の宣言を省略できる言語では、型の理解というのは往々にして後回しになることがあります。

本発表ではプログラミングにおける型や関数を、集合と写像によるメンタルモデルで捉える方法について解説し、 PHPのための設計に落とし込む方法を説明します。

お話したいこと

• 数学における素朴集合論と写像
• 写像とプログラミングの関数の違い
• 集合を使ったモデリングと型のメンタルモデル
• PHPアプリケーションの設計への落とし込みと他言語との比較

お話ししないこと

• 圏論

ありがとうPHPカンファレンス福岡！

私が体験したPHPカンファレンスで得たことをとりあえず叫ばせてください

こんなことを話します

• PHPerじゃなくてもPHPカンファレンスに登壇していいんだ！ PHPカンファレンス福岡のおかげ！
• Testerでもテストの話以外を話していいんだ！ PHPカンファレンス福岡のおかげ！
  -社外のエンジニアに知り合えた！ PHPカンファレンス福岡のおかげ！
  -社外のエンジニア以外の人にも知り合えた！ PHPカンファレンス福岡のおかげ！
  -プロポーザルはとにかく出しちゃえの気持ちになれた！ PHPカンファレンス福岡のおかげ！
• 働きたい会社に転職できた！ PHPカンファレンス福岡のおかげ！

本講演は2016年から続けている「PHPで堅牢なコードを書く」シリーズの最新版です。

PHPはバージョンを追う毎に機能が強化され、堅牢なコードを書くための機能が充実してきました。本講演ではPHP 8.4（および 8.5）をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。

参考:
PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計
https://speakerdeck.com/twada/php-conference-2016

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント
https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022

私は京都のスタートアップで働くエンジニアです。

スタートアップでは、売上拡大のために新規顧客獲得が重要になりますが、既存の業務フローがある顧客にはそのままでは導入できないことも少なくありません。

個別のカスタマイズ要望は、プロダクト開発のヒントとなりうる反面、その後の開発に影響を与える要因にもなります。

このトークでは、以下のテーマを主に扱います。

標準機能にするのか個別の機能にするのか
個別機能開発をする際にどのように作るのか
リファクタリングをいつ行うか
このトークを通じて、プロダクトの今と将来を両立するための考え方の一例を提案したいと思います。

php-srcを知りたいときの教材として、てきめんさんの「var_dumpを写経する - php-srcを学ぶぞ -」は分かりやすいです。

https://techbookfest.org/product/5746408227340288?productVariantID=6343868242984960

このトークでは、実際に本に倣って進めていくところで詰まったポイントとその解消方法や、php8で写経をしてみるために必要な準備を解説します。

実際にextensionを含めてビルドして動くところまで到達することを目標にします。

私はdeckというMarkdownファイルからGoogle Slidesのプレゼンテーションを生成するツールを開発しています。
https://github.com/k1LoW/deck

Markdownからプレゼンテーションを生成もしくは実施するツールは既に数多くあります。
一見単純な機能ですが、後発のdeckは明確なコンセプトを持って開発をしています。

• 継続的なプレゼンテーション作成
• コンテンツとデザインの分離

なぜこのコンセプトに至ったのか、そしてそれをどのように設計・実装したのか。
本セッションでは、ゼロからv1リリースまでのdeckの設計と実装の変遷を追体験できるように構成します。
単なる一つのOSSの例ですが、小さなプロダクトが多くの人に受け入れられるようになるまでの設計と実装のログです。
皆さんが自身のプロダクト開発に役立つ気づきを得るきっかけになれば幸いです。

PHPに限らず我々はフレームワークを使って開発を行うことが多いです。一方であえてフレームワークを使わず開発することもあるでしょう。

フレームワーク、便利ですが便利すぎるが故に「なんとなくコードを書いてる感」を自分は感じます。また、フレームワークをそのまま使わず自分たちでカスタマイズ(ライブラリを組み込む、フレームワークの1部だけ使う)する場合は 「なぜこれが今動いているのか」を理解できないとうまくカスタマイズできません。

いわゆる「よくわからんけど動いてる」を少しでも無くし、これまで以上に自分たちがフレームワークやライブラリを使いこなすために何ができるのかを自分の視点で紹介します。PHPに限らず他の言語にも応用できるような紹介を目指します。

話すこと(変更の可能性あり)
・ 今回の話をする経緯
・ 原理を理解するために自分がしていること
・ 「車輪の再開発」という言葉に対する持論

ソフトウェア開発の現場では、短いサイクルで継続的に学習する仕組みとしてスクラムが広く採用されています。
しかし、直近で担当した納期必達のPJでは、コミュニケーションコストを削減するためにスクラムイベントをすべて取りやめる決断を下しました。
このPJは無事に納期を守り、大成功で終わりましたが、後続の追加開発プロジェクトでは、スクラムイベントの廃止により課題共有の不足や、チームの一体感の低下などの問題を経験をしました。
そこで、課題を発見するたびにスクラムイベントを一つずつ再導入した結果、チーム連携が向上し、課題解決も円滑に進むようになりました。
本セッションでは、スクラムイベントの廃止によって発生した具体的な問題と、それらをスクラムイベントがどのように解消していったかをご紹介します。
日頃当たり前のように行っているスクラムイベントが持つ価値を改めて実感してもらえるようなトークをします

新卒でエンジニアとして働き始めてから、タスクの取りかかり方や進め方で度々つまづきました。
知識やスキルといった技術面だけでなく、「どこから手をつければ効率的か」「わからないことをどう相談すればいいのか」といった小さな判断に迷い、手が止まってしまう場面も多くありました。

このセッションでは、そんな“タスク詰まり”を感じたときに私が実践してきた、

・タスクの進め方を整理するちょっとした工夫
・周囲とスムーズに相談・連携するための意識の持ち方

など、日々の業務の中で培ったTipsをお話しします。

これからエンジニアとして経験を積んでいく若手・新人の方はもちろん、
後輩を支える立場の方々にも、現場の小さなつまずきに気づくきっかけやヒントを持ち帰っていただけたら嬉しいです。

PHPでRustリスペクトのResult型をなるべく使いやすい形で実装するならこうなりそうを話すセッションです。
PHPで制御が複雑になりがちなtry-catchのエラーハンドリングを解消したい人に向けて、Result型を使ったエラーハンドリングを話します。

話す予定

• Result型の説明
• （PHPStanを前提に実装するので）PHPStanの簡単な説明
• PHPで実装したコードの説明
• Aの実装だと使いずらいのでBの実装に変更変えると良さそう
  • @templateを使ったジェネリクスだと複数のエラーを返せない
  • 型のnarrowing
  • 関数を補完してくれないパターン（IDEでの関数補完を効かせる工夫）

想定読者

• Result型を使ったことがない人

※ Rustの知識が必要ないセッションにします

GitHubには多くの便利な機能があると知りつつも、 「結局どれを使えばいいのか分からない」 「CI/CDやAI活用をどう始めればいいか迷っている」 と感じている方は多いのではないでしょうか。
開発のスピードと品質を高めるActions、Codespaces、Copilotなどの機能は、単体で使うだけでなく、DevOpsの実践やチーム開発の改善にもつながります。

本セッションでは、GitHubを使っている・これから活用したい開発者を対象に、私が実践しているGitHubの活用方法を30分で紹介します。
10月にはGitHubの年次カンファレンスである「GitHub Universe」に参加予定ですので、カンファレンスの様子も交えてお話しする予定です。

きっかけなんて、なんだっていい

私がPHPを始めた理由。それは「象がかわいかったから」でした。そう、PHPのマスコット“ElePHPant”に心を撃ち抜かれたんです。

「なぜゾウなのか？」と調べていくうちに、PHPという言語の特徴にも、その姿勢にも、ゾウのようなおおらかさや包容力を感じました。そして気づけば、私はPHPを書くようになっていました。

このLTでは、ゾウに惚れてPHPを始めたちょっと恥ずかしい話とともに、「始める理由は人それぞれでいいんだよ」というメッセージをお届けします。
誰かが明日、ゾウに惹かれてPHPを始めてくれたら、それだけで嬉しいです。

対象者

• 初学者や、これからPHPを始めようとしている人
• ベテランだけど改めてPHPへの愛を再確認したい人
• 技術的な話にちょっと疲れて、ほっとしたい人
• ゾウが好きな人

設計について話をすると、実に多くの「◯◯概念」「◯◯原則」が付いて回ります
あるいは、「良い設計を考えよう」とか「設計を学ぼう」とかして、多様な知識が必要で大変だ！と感じた事はありませんか？

全く逆のアプローチで
「たった1つの軸を決め、多くのことを説明できないか」と考えてみましょう
その拘りは、あなたの設計の地力の向上に繋がるはずです

今回は、その回答に 「フィードバック」に注目する という提案をします

フィードバックとは、何かを伝え、その反応を受信することであり、
関係性に意味をもたらすものとも言えます

この「フィードバック」という眼鏡を通じ、システムを覗き込むと？
──設計について多くを語る武器になり得ます
ソフトウェアにとどまらない、組織についても使える武器です
分割、配置、バランス、そこから生まれる相互影響について、
よりシンプルに思考し尽くせるようになるでしょう