Laravelの魅力の一つであるORM「Eloquent Model」。
雰囲気でも動くものが書けてしまう反面、実は正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのメソッド、返り値nullableにつき
• 全件取得による富豪的プログラミングにご注意
• データベース泣かせのN+1問題
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

古いコードベースを読み解く作業はしばしば「ソフトウェア考古学」と呼ばれ、多くの人にとって大変で辛い作業と思われがちです。
しかし、サービスの歴史を辿ることで当時の設計思想や変化の過程を知ることができ、それ自体が良い設計を体験し、学べる貴重な機会でもあります。
私の実体験としても20年もの歴史のあるWebサービスの考古学からは学べることがたくさんありました。

本トークでは、新卒5年目エンジニアである私が、20年以上稼働し続けるWebサービスの改善に向き合う中で試行錯誤したことをお話しします。

お話すること

• 古いコードベースを読み解き改善を行った事例とその課題
  • Webメディアの広告運用のための管理画面改修
  • 歴史の塊のバッチ処理をPerlからPHPに移行する
• 全体を知るための「鳥の目」と細部を観察するための「虫の目」の考え方
  • 鳥の目で意図や構造を理解する作図ツールなどを使ったコードの読み方
  • 虫の目で詳細を把握するためのデバッグ方法
  • 「どこまで深掘りするか？」の判断基準
• ソフトウェア考古学の経験から学んだこと
  • 理解しやすいコードを書くコツ
    • 自分が書いたコード、その後どうなった？上手く行ったこと、行かなかったこと
  • ソフトウェアの健全な変化を助けるドキュメントとは？

話さないこと

• トークの中で出てくるツール自体の詳細な使い方
• リファクタリングやデータ移行といったソフトウェア改善に伴う手順の詳細

聴いてほしい人

• コードベースが古い環境で悩んでいる人
• 歴史のあるコードを改善したいと思っている人
• プロダクションコードに初めて触れ、規模の大きさや複雑さに圧倒された経験のある新卒の人たち

東京都が主催するオープンデータハッカソンは、プログラミングスキルがなくても誰でも参加できるイベントです。このLTでは、私がこのハッカソンに参加し、運良くファイナリストに選ばれた経験を共有します。

このハッカソンの特徴は、技術的なスキルよりもアイデアや実現性を競う点です。そのため、技術的な話題が中心となることが多いカンファレンスの中で、少しリラックスできるセッションになるかもしれません。

作品についての詳細は、以下のリンクでご覧いただけます:
東京都オープンデータハッカソン作品
https://odhackathon.metro.tokyo.lg.jp/collection/106/

今年の3月に実施されたPHPerkaigi2024でコードゴルフ大会に参加し、とても楽しかったため、「自分の会社でも実施したい！」と思い立ち、実際に開催しました。結果は大成功で、とても楽しい時間を過ごせたので、その時の話をします。

コードゴルフの内容は、「FizzBuzz」問題や、1時間で解ける程度のの難易度のものを採用しました。言語はPHPを使用しました。

具体的には以下のような内容を話す予定です。

•コードゴルフ大会を実施するにあたって、コードゴルフができるWEBアプリをどのように作成したか
•コードゴルフ大会の雰囲気や参加者からの評判
•参加者たちの感想
•コードゴルフ大会を定期的に開催していることでの社内への影響
•コードゴルフ大会を開催した私自身の感想

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

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

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

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

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

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

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

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

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

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

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
こちらは【ツールなど使わず手動で】【データプロバイダに】【少しずつ値を変えて大量のパターンを対照実験する】ための方法です。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方

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

スクラム開発において「振り返り」と「スプリントゴール」は、単なるイベント以上の意味を持ちます。これらを形骸化させず、しっかり活用することでチームのパフォーマンスは大きく向上します。

本セッションでは、振り返りを通じて課題を具体的な改善アクションに変える方法や、スプリントゴールを設定する効果を説明します。

これらを実現した現場での成功例や失敗例を交えながら、スクラムの本質的な価値を掘り下げ、明日から実践できる具体的な方法論をお伝えします。スクラム開発を採用してもしていなくても、このセッションを通じてチームの開発プロセスを改善することができるでしょう。

「オブジェクト設計スタイルガイド」は、オブジェクト指向プログラミング（OOP）の設計と実装におけるベストプラクティスを網羅した優れた書籍です。スタイルガイドという名前の通り、明日からすぐに実践できる内容であるため、オブジェクト指向の基礎を理解している開発者にとって有益な参考書です。

本セッションでは、まずオブジェクト指向設計の基本概念を確認し、その後に書籍の具体的なコーディングスタイルを紹介していきます。以下はテーマとコーディングスタイルのサンプルです（番号は書籍によるものです）。

・2.1 2種類のオブジェクト
→ サービス層とドメイン層の役割とその違い（オブジェクトを呼び出す側と呼び出される側）
・2.3 サービスロケータを注入するのではなく、必要なもの自体を注入する
→ 依存性注入（DI）

・4.1　エンティティ：変更を追跡し、イベントを記録する識別可能なオブジェクト
・4.2　バリューオブジェクト：置き換え可能、匿名、イミュータブルな値
→ エンティティとバリューオブジェクトの設計（ミュータブル／イミュータブルの設計指針を含む）

・6.7　クエリメソッドからはコマンドメソッドは呼び出さず、ほかのクエリメソッドのみを呼び出す
・7.5　情報を収集するためにクエリを使用し、その次のステップに進むためにコマンドを使用する
→ CQS（コマンドクエリ分離原則）の基本と実践

本セッションを通じて、開発者がOOPの原則を理解し、それを適切に活用する知識を提供することで設計力の向上を目指します。

なお、本発表は「軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう」という発表を、より PHPer 向けに深掘りしたものです。
https://speakerdeck.com/panda_program/no-more-lightweight-ddd

モジュラーモノリスは近年、マイクロサービスの代替として注目を集めています。このトークでは前半で設計の話を、後半で開発の話をします。

私が所属するBASE社では10年以上モノリシックなサービスでの開発が続いていましたが、デプロイ時間の増加や依存関係の複雑さにより機能提供のスピードに課題が出てきました。その課題を解決するためにモジュラーモノリスの新システムへの移行が始まって丸4年が経過しました。

本トークでは、モジュラーモノリスの基本的な設計概念から、その実現する方法論、また実践例について解説します。モジュールはコアドメインとサブドメインの考え方に基づいて区切られており、各モジュールの中ではアプリケーション層とドメイン層が分かれており、UnitOfWork での永続化管理やドメインイベントを用いた実装が可能になっています。

また、モジュラーモノリスを選択した際の利点とトレードオフについても議論します。具体的には、テストのしやすさ、デプロイの単純化、チーム間のコミュニケーションの向上など、エンジニアリング全体に与える影響を掘り下げます。メリットは多くありますが、それでも生じる課題についても触れていきます。

このトークを通じて、モジュラーモノリスというアーキテクチャの現実的な価値を理解し、チームやプロジェクトの規模に適したアプローチを選ぶための指針を得られれば幸いです。

サービスを作る上で、維持費と収益を獲得できるかどうかは、非常に重要な要素です。
StripeのDeveloper Relationsとしてユーザーや社内のプロジェクトに関わった経験と、
前職や個人開発におけるマネタイズに関する経験と想いを元に、ウェブサービスを開発する際のマネタイズ手法や料金モデル、そしてリリース後に発生しがちな請求管理に関するアレコレを紹介します。

トピックの例
・初期フェーズで決済・サブスクリプション機能の開発をやるべきか否か？
・開発工数と売上は比例しない話
・本当にあった、サブスクリプション請求管理で頭が痛くなる話

「List とは、キーが連続した数値 (0 から count($array)-1) である配列」これだけ覚えて帰ってください。

その上で、このライトニングトークでは

• PHP 内での扱われ方
• 静的解析
• 内部実装

の 3 つの視点から List についてお話します。

本セッションはPHPで計算機を自作します。環境構築からコード全体を解説します。

自分たちが使っているPHPのインタープリタとは何をしているのか、普段使っているPHPがいかに高度なことをしているのかを理解することが目的です。

本セッションは初中級者向けです。コードの記法などは解説致しません。計算機やプログラミングに興味があるが作り方が分からない方、PHPの内部実装の想像がつかない方を対象としています。

そのため、初心者でも理解しやすいように以下の工夫をします。

スタック型です
型をintegerとfloatに制限します
型キャストを使った明示的な型の管理を行います
逆ポーランド記法を使います
ユーザー定義関数を使いません

上記の特徴を持った言語を作ります。つまづきやすい、複数の型に対する演算の定義やASTを構築するタイプの言語における二項演算、ユーザー定義関数を意図的に避けています。

実装を解説し、ある程度計算機を理解したうえで、以下の話をします。

PHPがASTを構築し中間言語をVMで実行するタイプの言語であること、本セッションで実装した言語との違い。
通常の言語における二項演算の処理方法。式、文など。
ここまで作成した言語でHello,worldをする方法 (任意の要素を受け取れるprint文を作り、asciiとして解釈させる)

本セッションを通して視聴者は、計算機を構築するのに何が必要か理解し、自ら新しい計算機を作り出せるようになるでしょう！

近年、急速に"(コードの)質と(質の高さからくる開発)スピード"が注目されるようになってきました。

一方で「何故、"質とスピード"を求めるのか」に対するお話はあまり見かけません。

このトークでは「兵法」から見た「"ソースコードの質"や"開発スピード"は何のために必要なのか？」、「"ソースコードの質"や"開発スピード"は本当に必要なのか？」についてお話します。

日本でも著名な「孫子の兵法」から現代戦で重視される戦術論「リズムとテンポ」などの観点から「市場を支配するために必要な"質とスピード"」に迫ります。

このトークで得られる知見

1 あらためて考える「なぜ"質やスピード"が必要なのか」
2 "質やスピード"を求める場合の基準
3 組織人として組織を持続可能にするために考える事

このトークで話さない事

1 孫子の兵法をはじめとした戦略論・戦術論の詳解

コンパイルの世界では、中間表現というアイディアが存在します。
ソースコードを任意のデータ形式（中間表現）に変えてから、コンピュータが理解できるデータ形式（機械語）へ変換するというアイディアです。
一気に機械語へ変換するよりも、無駄な計算を省いたり複数フォーマットへの変換処理を効率化するなど効率化の恩恵をもたらします。

PHP8.0でJITによる高速化が導入されましたが、8.4では中間表現のアイディアを採用することで、さらなる高速化を図る変更が行われました。
https://wiki.php.net/rfc/jit-ir
中間表現を実現するにあたって、新しいフレームワークIRを使ってJITを実現しています。
https://github.com/dstogov/ir
このフレームワークでは、一体どのようにして中間表現を実現しているのでしょうか？

本セッションでは、まずJITと中間表現の基本概念を説明し、その後、PHP 8.4で導入されたフレームワークIRの詳細を解説します。
JITフレームワークIRを解説していくなかで、PHP8.4に導入されたJITでの中間表現について理解を深めていきます。

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

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

何らかの技術の理解を深めるのに最も適した方法は、その技術のサブセットを自分で実装することです。
PHP、ひいてはプログラミング言語というものを理解するために、PHP で PHP のサブセットを実装しましょう。
プログラミング言語処理系における「セルフホスト」とは、その処理系のソースコードをその処理系自身が処理できることを指します。つまり、今回作るPHP処理系の上でそのPHP処理系を動かすことを目指します。

話すこと

PHP で書く PHP 処理系（のサブセット）の作り方

• 字句解析
• 構文解析
• 実行 (今回の実装では AST を直接実行します)

必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

実際の PHP 処理系 (php-src) の実装方法に近づけることは目指していません。説明のしやすさや実装の容易さを考慮し、適宜アプローチは変更します。PHP 処理系へのコントリビュート等を目標としたものではありません。

オブジェクト指向を学ぶ私たちは、必ず一度は「SOLID原則」に触れる機会があると思います。
私も何度も学習を重ねる中で、その原則がもたらす恩恵や、守ることの重要性を徐々に理解してきました。

…ただ、「リスコフの置換原則（LSP）」だけは「これを守るとどう良いのか？」がいまいちしっくりきていませんでした。
「同じ気持ち！」なあなたに向けて、このセッションでは、以下のようなお話をします。

・LSPとは何か？よくある例と「なぜピンとこないのか」
・実際に私が遭遇したLSP違反の具体例
・LSPと"継承"の関係性をしっかりと理解する

「なるほどLSP完全に理解した！」といってもらえるようなトークにします！

2年前、私は「Laravelへの異常な愛情」と題し、Laravelの基礎的な考え方と、そのレールがもたらす開発上の効果を紹介しました。Laravelをモデルに対するCRUDに特化したリソース志向フレームワークと捉え、コード量を削減しスタイルを統一する、これがLaravel Wayです。

しかし、現実のアプリケーションが、この枠組みの範囲に収まることはありません。

枠組みを超えた要件はプロジェクト固有の設計やルールで解決する必要があります。この試みは、成功することもありますが、それが「ほころび」となりコードベース全体の保守性を脅かすこともあります。これもまた、Laravelというフレームワークの特徴です。

逆に考えましょう。枠組みの外に出るのではなく、枠組み自体を拡張すれば良いのです。その手法を紹介します。

個別のテクニック

• 認証の拡張
  認証プロバイダを理解し、Eloquentに依存しない認証や外部の認証基盤との連携を実現する
• リクエスト処理の拡張
  Laravelの処理ライフサイクルを理解し、変則的な要件に対応する
• Eloquentの拡張
  データベースドライバを理解し、データベース固有機能を自在に利用する
• レスポンス処理の拡張
  Responsableを理解し、モダンフロントエンドへ対応する

拡張の考え方

• あらゆるものを拡張
  Laravelの内部設計を知り、拡張の考え方を理解する
• 再利用性と安定性
  パッケージ化による責務分離と、バージョンアップへの備え

題材として扱うOSS

• Laravel Doctrine ORM
• Laravel PostgreSQL Enhanced
• Laravel Debugbar
• Inertia.js
• Testbench