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

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

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

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

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

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

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

弊チームでは先日、15年来のレガシーシステムを、バグ0でリプレイス&新機能の追加リリースを実施することに成功しました。

その際、オリジナルの検証手法である「ペンギンテスト」をはじめ、シャドーテスト、カナリアリリース、ダークローンチ、フォールトマスキングなど、
多彩な手法を駆使することで、リスクを最小限に抑える「安全に倒し切ったリリース」を実現することができました。

特にチーム発案の「ペンギンテスト」は、本番環境で実際のデータを使いながらもユーザー影響は出さない、
あらゆるパスを網羅した見落としのない検証を実現する有用な手法です。

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

他のプロジェクトでも応用可能な知見を共有しますので、レガシーシステムへの手入れを検討している方は必見の内容です。

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

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

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

⁠対象者

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

「フレームワークに依存するなと言っても、フレームワーク移行なんてほぼ起こらないのでは？」
そう思っていた頃が私にもありました。では、いま使っているフレームワークが開発停止になったらどうしますか？
かつて、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完全に理解した！」といってもらえるようなトークにします！

Laravel Wayを拡張し、あなた自身のLaravel体験を作る。

2年前、私は「Laravelへの異常な愛情」と題し、Laravelの基礎的な考え方と、そのレールがもたらす開発上の効果を紹介しました。

Laravelの「レール」は開発の効率化やコードベースの統一性を提供する一方、設計の柔軟性を制約することもあります。

本セッションでは、そうした制約を越え、Laravelの可能性を拡張する手法を紹介します。

• リクエスト・レスポンスの拡張: 認証などのコア機能を変更し、柔軟な処理を実現
• Eloquentの拡張: クエリビルダへの機能追加により、データベース固有機能を自在に利用
• テンプレートエンジンの拡張: ビュー層の柔軟性を高め、多様な表現力を実現
• あらゆるものを拡張: Laravelの内部設計を知り、拡張の考え方を理解する
• 再利用性と安定性: パッケージ化による転用と、バージョンアップへの備え

Laravelを深く知り、より素晴らしいアプリケーション作りましょう。

エンジニアとして始めると必ず知る概念、それが「デザインパターン」です（諸説あり）。
私は新卒の頃、輪読会としてデザインパターンの本を読みました。そして、その知識を持て余したものです。
”デザインパターンを勉強しよう”で知ったデザインパターンは、その適用に失敗することの方が多いように感じます。
「道具として自然に出てくること」が大事であること、そして「道具としてもう使われないものもあること」を認識するのが大切です。
普段使用するフレームワークやライブラリに出てくるデザインパターンを参考に、今でもよく使われるデザインパターンを紹介していきます。

話すこと
・デザインパターンとの向き合い方（共通言語として”デザインパターン”を知っておく）
・フレームワークやライブラリに出てくるデザインパターン
・好んで使わないデザインパターン

※GoFのデザインパターンのことを指します。