プロポーザル

テレビ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への愛を再確認したい人
• 技術的な話にちょっと疲れて、ほっとしたい人
• ゾウが好きな人

同じ空間に2つ以上の要素が存在すると、そこに「システム」が生じます
要素とは、ソフトウェアのモジュールであっても、人や部署であっても変わりません
これらをどう配置するのが適切か？を考えるのが、「設計」です

設計には、多くの「◯◯概念」「◯◯原則」が付いて回ります
もっとシンプルに、1つの「大事なこと」だけを見つめて生きていければ…なんて思ったことはありませんか？

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

フィードバックとは、何かを伝えたり受け取ったりすることです
知識を交換し、状態や行動の変化を生み出す働きです
システムは、そうした要素同士の伝達による協調の先に、高度な出力という目的を達成します

良いフィードバックを生み出し、悪いフィードバックを防ぐために、何が出来るでしょうか？
「フィードバックのあり方」から、設計をシンプルに考える方法を模索します

コードの自動修正を行うツール、Rector。提供される修正ルールは700超！
大量で多様なルールに対応する裏には、高い拡張性を実現する「良い設計」があります

中核的なコンセプトの1つは、対象コードを抽象構文木として扱うことです。 そして、各ルールはVisitorパターンで適用されます
──ツリーに対してVisitor。美しく王道的なアプローチの魅力を、一緒に覗いてみましょう

• 目的
  • 普及しているOSSという実践的な例から、Visitorの概要と効果について学ぶ
• 対象
  • これからデザパタやVisitorパターンを身に付けたい
  • Rectorやカスタマイズに興味がある
• 話すこと
  • Rectorの概要
  • ルールを自作して基礎を掴む
  • Visitorパターンの概要、使われ方

与えられたテキストを文法に則って解析し、別の構造へと変換するのが、構文解析器(パーサー)です
独自のPHP製パーサーを生成する、PHP-Yaccをご存知ですか？
文法を定義するための記法(BNF)を使い、本格的なパーサーを生み出すものです
有名どころでは、nikic/php-parserにも利用されています

本トークは、「JSONをPHPのデータに変換する」をお題に
自作パーサー開発の入門レベルの解説を行います
どんな風に作るの？どんなコードができるの？を味わいましょう

これを聞いたら、次はあなたが自作パーサーに入門する番です！

話すこと

• パーサージェネレーターを使ってみる
• 文法の定義(.yファイルを書く)

話さないこと

• レキサー、パーサーの詳細なアルゴリズム、実装パターン

PHPのロゴがどんなデザインか、皆さんは即座に思い浮かべられますか？
「たしか楕円…」「青と紫の中間色？」「このロゴって何代目？」「っていうか背景色あったっけ？」など、さまざまな思いが頭をよぎるかもしれません。

「知ってるつもり」だったPHPロゴについて、公式ドキュメントをベースに正しい仕様を紐解いていきたいと思います。
スライド作成中に「あれ、どのロゴが正しいんだっけ」と迷った経験のある方、一緒に答え合わせをしてみませんか？

対象者

• 資料作成などでPHPロゴを使ったことがある方
• PHPロゴの正しいデザインを覚えて帰りたい方

話すこと

• PHPロゴクイズ
• 正しいロゴの仕様確認
• 入手方法と使用ルール

「DDDは難しい」と思っていませんか？実はコア業務の定義と依存関係の整理こそが成功の鍵です。

レセプト業務という複雑ドメインで法改正に挑んだ実体験から、「何をコア業務とするか」「何に依存させて何に依存させないか」という依存関係の設計がシステム全体の安定性をどう変えるかをお話しします。

コア業務を安定させた結果、以下の効果がありました。

• 開発プロセス全体が改善
• スキーマ駆動開発が自然に導入できる
• チーム間の調整コストが激減

依存関係の逆転によってスキーマ自体も安定化。その安定度を高める具体的施策も含めて、理論より実践重視で解説します。
3年に一度の大規模法改正に立ち向かった実話の例とともに、段階的にアーキテクチャを進化させていくための、現実的な道筋をお伝えします。