トーク

Laravel開発でphp artisan serveを叩きビルトインサーバを起動するお馴染みの光景。
しかし、公式ドキュメントには「本番環境で使うな」の一文が。
なぜビルトインサーバーは手軽さと引き換えに、本番環境で採用できないのでしょうか。
また、本番環境でデファクトスタンダードとなっている「Webサーバー + PHP-FPM」という構成は、どのようにそれを解決するのでしょうか。

以下についてお話しします。

• ビルトインサーバーが本番環境で推奨されない理由
• WebサーバーとPHP-FPMの基本的な仕組み

皆さんはPHPに機能追加してみたくなりませんか？
私はPHP 8.4から機能追加をPHP本体にやってきていて、様々な関数を世に送り込んできました。

• mb_trim、mb_rtrim、mb_ltrim関数
• mb_ucfirst、mb_lcfirst関数
• grapheme_str_split関数

PHP 8.5では以下の関数が追加予定です

• grapheme_levenshtein
• grapheme*関数にロケールを追加する(8月8日現在では投票中です)
  https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive

みなさんも、RFCで提案してみるのはどうでしょうか？そのコツなどやり取りをお伝えできればと思います。

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

テレビ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-srcを知りたいときの教材として、てきめんさんの「var_dumpを写経する - php-srcを学ぶぞ -」は分かりやすいです。

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

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

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

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

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

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

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

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

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

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

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

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

技術コミュニティへの参加は、エンジニアにとって学びや刺激を得る貴重な機会です。
しかし、様々な制約がある中で「どこまで集中して参加できるか分からない」という不安から、足が遠のいてしまうこともあるのではないでしょうか。

先日子連れでPHPカンファレンスJapanに参加した体験では、参加者・スタッフの皆さんの温かい配慮に支えられ「全力で参加できなくても、コミュニティとの小さな繋がりがエンジニアのモチベーションを支えてくれる」ことを実感しました。
あまりセッションを聴けなくてもブースでの何気ない会話から仕事のヒントが得られたり、同世代・若い世代のエンジニアのアウトプットに刺激を受けたりと、予想以上の収穫がありました。

実際の参加体験から得た気づきや感謝、そして参加後の変化までをお話する予定です。
同じように「全力のコミュニティ参加」を迷っている方の背中を押すきっかけになれば幸いです。

カンファレンスに行き始めた頃、「カンファレンスの歩き方」に迷っている自分がいました。
セッションを通じて学ぶことが多く、満足はしていたものの、どこか聞いて終わりで完結してしまっている感覚がありました。

そんな中で、あるカンファレンスの懇親会に参加したことをきっかけに、一気に世界が広がりました。
登壇者からセッションでは語られなかった裏話を聞いたり、遠い存在に感じていた人たちと気軽に話ができたり、自分の悩みを相談できたり、参加することで得られるリターンの質が大きく変わったのを感じました。

このセッションでは、自分の中でカンファレンスの価値が「学ぶ場」から「つながる場」へと広がっていった体験をもとに、ちょっとした行動で変わる景色についてお話しします。
初参加の方や、踏み込みきれていない感覚を持っている方に届いてほしいなと思っています。

オブザーバビリティという言葉もよく聞くようになり、常にサービスの状態をモニタリングすることが運用において重要になってきていると思います。
モニタリングするためにダッシュボードを作って見るようにすると思いますが、あなたのチームのダッシュボード、いつの間にか"見る人しか見ない"飾り物になっていませんか？

本トークでは、その形骸化したダッシュボードから脱却するため、ダッシュボードをTerraformでテンプレート化し、コードとして管理する取り組みを実施しています。
コード管理することで、新規開発した機能や画面のダッシュボードも即座に出力することができ、一定水準のダッシュボードを開発・運用チームに配布することができます。
複数の開発チーム間で同じ構成のダッシュボードを利用することでダッシュボードを「開発組織の共通言語」へと進化させ、みんなが頼るダッシュボードにするための取り組みを紹介します。

世界で最も利用されているCMSであるWordPressをご存知でしょうか。
WordPressは、PHPを使用して構築されたコンテンツ管理システム（CMS）です。そして、おそらく殆どの企業が独自にカスタマイズし、プラグインを導入して利用していると思います。
近年、コーディングエージェントという技術が進歩しており、プロンプトに指示をしてコードを開発してもらうことが多くなっています。
果たしてカスタマイズされたWordPressの環境で実用可能なのでしょうか？

本トークの内容
このトークでは、実際にカスタマイズされたWordPressに対して以下の点を具体的に説明いたします：

• どのような指示を行ったか
• 何を改善できたか
• 何を改善できなかったか

実践的な事例を通じて、WordPressとコーディングエージェントの現実的な活用方法をお伝えします。

PHP は2015年以来、毎年11〜12月頃にバージョンアップが行われており、11月20日には待望の PHP 8.5 がリリース予定です。

かつてはゆるふわ言語の代表格として知られた PHP ですが、7.0 以降は型周りの表現力が大幅に強化された他、Readonly Property/Class の導入など、堅牢で読みやすく、壊れにくいコードを書くための強化が行われてきました。

そして PHP 8.5 では Haskell や Elixir など「関数型言語」にあるような「パイプ演算子」が導入されます。PHP にパイプ演算子……隔世の感がありますね。

本トークでは PHP 8.5 で導入される新機能の内、個人的に注目しているパイプ演算子と NoDiscard アトリビュートを中心に、どのようなメリットをもたらすのかを具体的なコードと用例を用いて解説します。

弊社で運用しているサービスの一機能である検索機能は、数百万件以上のデータを対象に、ユーザから毎分3,000件以上もの検索リクエストが送られています。
検索機能のミドルウェアにはAWS OpenSearch Serviceを利用していますが、現行バージョンがEOLになる見込みがあり移行が避けられない状況でした。
移行にはアプリケーション側の修正も必要で、移行中にダウンタイムが発生するとサービス提供に影響が生じ、インシデントに繋がる可能性もあります。

本発表では、運用中のサービスを止めず・壊さず、段階的リリースやコードの移植を通じて実現したゼロダウンタイム移行の手法、移行を通じて浮上した移行しにくい設計、今後の設計改善についてお話します。

ターゲット

ミドルウェアのバージョンアップを実施・検討している方
ゼロダウンタイムでのリリース手法に興味がある方
既存設計の改善に興味がある方

「このレガシーコードから、いつか抜け出したい」──そう願いながらも、触れれば壊れる恐怖と日々のタスクに追われ、巨大な技術的負債を前に動けずにいませんか？
本トークは、そんな絶望的な状況から抜け出すための、現実的かつ具体的な「脱出計画」を提案します。
鍵は、一度きりの大規模リファクタではなく、チームで実践する持続可能な「1日1改善」です。
新機能には必ずテストを書き未来のバグを防ぐ。バグ修正の際は「来た時よりも綺麗に」を合言葉に少しだけ改善する。静的解析をCIに組み込み品質の門番とする。未来の調査を楽にするログを戦略的に仕込む。
この小さな一歩の積み重ねが、やがてチームを、あなたを負債のスパイラルから解放します。
明日から始める「脱出計画」で、もうコードに怯えず、楽しく開発していきましょう！

国内外であまり知られていないAstroのContainer API。主にコンポーネントテストのために使われますが、実はバックエンドフレームワークとの組み合わせも可能にするAPIです。
本トークでは、Astro Container APIの紹介、バックエンドフレームワーク組み込みのための使い方、APIを使うときの落とし穴について語りたいと思います。HonoやLaravelなどを利用し、実例を紹介しながら発表します。
「Astroを使ってるけどバックエンドを追加したい！」　「既存のバックエンド知識を活かしながらモダンなUI開発をしたい！」　という方に向けたトークです。

どのようなビジネス、プロダクトであろうと運用していくのに必要なのが管理画面
ただ、管理画面を作っているとこういう課題に出会ったことはないですか？

• 調査依頼が来てもどこを見ればいいかわからない
• おかしなデータが入ったことに気づけない、ログを追うのが大変
• 調査依頼からバグを再現するのが難しい

これらを1つ1つ向き合って解決し、プロダクトとビジネスの成長をさせるための管理画面の作り方を話します

話すこと

• 管理画面におけるログやデータの残し方
• 管理画面におけるアプリケーションの設計

話さないこと

• アプリケーション設計における具体的なコードの説明
• 画面のUI

Laravelでの開発経験を活かしつつ、TypeScriptの型安全性やAIとの親和性、そしてバックエンドとフロントエンドを一つの言語で統一できるメリットに注目し、「AdonisJS」を紹介します。
AdonisJSはリリースから10年を迎える歴史あるフレームワークでありながら、まだまだ日本では知名度が高くありません。
Laravelユーザーにも馴染みやすいMVC構造や公式エコシステムを備え、デモを交えつつTypeScriptによる型安全な一貫開発体験やAI活用の可能性、実案件で採用した際の利点や課題もお伝えします。
TypeScript時代の新たな選択肢としてAdonisJSの魅力を15分でご紹介します。