PHP を書く上で、静的解析ツールは必需品となりました。コードを実行する前に型を解決し、問題を明らかにすることで、開発イテレーションを大きく向上することが可能です。

静的解析ツールはいくつかありますが、その中でも PHPStan は非常に強力なツールとして利用されています。その PHPStan で最も細かく解析してくれる level: max を使うと、 mixed 型や array-shapes を含め 全ての変数に型を明示する必要があります 。

このトークでは、自作 PSR-7 実装を通して、どのようにして level: max な PHPStan で 型安全 に実装するか、そして その費用対効果がどれほどなのか を紹介します。

レベルマックスな PHP ユーザーは一体どうなるのか？解き明かします

PHPerの世界でもwhatやwhyが大事だ、howはなんでもいい、と言われるようになりました。
たしかにwhyやwhatはとても大事で、howは所詮howです。
しかし、howを軽視しすぎるのはおすすめできません。
「思考に気をつけなさい。それはいつか言葉になるから。言葉に気をつけなさい。それはいつか行動になるから。（後略）」というマザーテレサの名言にもある通り、howは知らず知らずのうちにあなたの設計方針に影響を与えてしまうのです。
howがどのように設計方針に影響を与えるかの実例をいくつか紹介した後、その対策についてお話しします。

本セッションではDDDのための設計パターンの一つ CQRS/Event Sourcingの実装をアクターモデルとともに体験します。

アクターモデルを通じて他言語と同等な
本格的CQRS/Event Sourcingの実装を体験することで仕組みの理解に役立てることができます。

PHP アクターモデルツールキットPhluxorによるCQRS/Event Sourcing実装体験と、
CDCを利用したCQRS/Event Sourcingが体験できますので、
他言語でおなじみのAkka/Pekko、Proto Actorなどの理解にも繋げることができます。

実装ではREST APIまたはGraphQLを利用予定です。
実行環境はローカルのDockerとなりますのでPCの持参をお願いします。
コードは簡単な土台を提供しますので事前準備は必要ありません。

クリーンアーキテクチャの同心円で、一番外側にあるデータベース。ドメインのコードはデータベースに依存させないように書きましょうと言われがちです。しかし、果たしてデータベースは本当に常にドメインの外側に置くべきなのでしょうか？
リンケージではLaravelとDoctrineORMを組み合わせてドメインのコードとフレームワークの距離を保ちつつ開発していますが、ドメインとデータベースとの距離については議論がありました。
Doctrineという技術選定、ドメインのコードからORMへの依存を許す決断をした根拠についてお話します。

トークの対象者

①
「このコード何となく良くない気がする、リファクタしよ〜」「書き換えてみたけど、しっくりこないな‥」
そんな経験はないですか？
②
「コピペコードになってるなぁ。もっと良いやり方がありそう…」「でも既存コードに手を入れる踏ん切りが付かない！」
そんな人はいませんか？

トークの趣旨

• リファクタリングには時折「概念の整理」が欠かせません
• 概念の抽出や切り分けには「抽象/具体化」を用います
• そうして「物の見方を変えていく」体験を提供します

トークのアプローチ

コードの代わりに、日本語で記述された要求・手続きの文章に「変更」を加えていきます

• 「開放閉鎖原則を満たす」を目的に変更していきます
• 具体的なコードを用いない事で、一歩引いて考える脳みそを鍛えます
• コーディングテクニックに依存しない、リファクタリング力の向上を目指します

良い設計技法やイケてるコーディング──
新しい事を学ぶ際には「なぜ生まれたのか」を知ると武器になります
そのために、「それが生まれる前の様子」を知ると助けになります

現代的な「良い」コードの探求のため、昔っぽい世界を覗いてみませんか？
「クラスもねぇ制御フローもねぇglobalやgoto頼りの世界」を覗いていきませんか？？？

手続き型？いいえ！もっと遡りましょう
「構造化プログラミング的な要素を排除しつつ、今日のPHP(8.4)で開発」に挑みます

話すこと

• 構造化プログラミングの簡単なおさらい(定義・歴史)
• コードサンプルと解説: 簡易CMS

「非構造化」のルール(一部)

• クラスや例外やwhile(true)以外のループや名前空間は使わない
• ユーザー定義関数: 引数は使わない・値を返さない/グローバル変数でやり取りする
• gotoや標準関数は使う

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

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

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

PHPUnitには多くの便利なアサーションが用意されていますが、わたしたちが普段使っているフレームワークにも独自のアサーションが実装されていることをご存知でしょうか？
普段便利に使わせてもらっているアサーションの中身がどうなっているか、みたことはありますか？
「まだ、みたことない・・・！」という方、このセッションでテストの裏側にある仕組みにDeep Diveし、テストライフをさらに快適にしていきましょう！

話すコト
・PHPUnitがどのようにアサーションの結果をOK/NGと判断しているのかを知る
・各フレームワークにあるいろいろなアサーションを知る
・自分でカスタムアサーションを作成するという選択肢を知る

PHPのバージョンが上がるにつれて型周りの機能が充実してきました。
これに伴い、実行時、型によるエラーを発生させないためにコードを書く時に注意したり、静的解析による検査を導入するという事が必要となってきました。
PHPStanはそのような実行時にエラーとなる可能性のある部分を指摘してくれる静的解析ツールであり、ご存知の方も多いと感じます。
しかし、「導入がしたいけど出来ていない」という話や「導入したけどあまり活用出来ていない」という話を時々聞きます。

そこで、本トークでは以下のような点について自身の経験を踏まえてお話します。

• PHPStanの基礎
• 導入時や導入後の課題とその解決方法
• baselineの活用と落とし穴について
• セキュリティに関する活用

PHPStanを全く知らないという人から導入を検討している方、更に知識を深めたいという方まで楽しめるトークを目指します。

アセンブリ言語といえば，mov とか jmp とかよくわからないワードがズラズラと並んでいるイメージがあると思います。
PHP は高級言語なだけあって，変数も関数もメモリの許す限り定義し放題。一方，アセンブリは限られたレジスタと呼ばれる一時的に値を格納するモノと
いくつかの命令を駆使するものです。
そのためアセンブリ言語の入門はハードルが高いなと感じてしまうことでしょう。
そこで PHP をアセンブリ言語っぽくかけたらハードルも下がりますし，アセンブリの理解が深まるのではないかと考えました。
本トークではなるべくアセンブリ言語と同じ制約のもとに PHP を置き，アセンブリ言語っぽく PHP を書く技術について紹介しつつ FizzBuzz を出力することをゴールとします。
なお，トーク中のアセンブリ言語は NASM （Netwide Assembler） と呼ばれるものを例に用います。

あなたは DockerHub で公開されている PHP のイメージサイズに満足していますか？

コンテナイメージのサイズが小さいことには様々なメリットがあります。 DockerHub ではイメージサイズを最小化するために Alpine Linux ベースのイメージも公開されていますが、 Debian ベースのイメージと比べパフォーマンスや互換性の面でデメリットを抱えています。

パフォーマンスや互換性は妥協したくないけど軽いイメージが欲しい...！

そんな夢を叶える Distroless PHP プロジェクトについて紹介させていただきます

Microsoft によって提唱されているコンテナ技術を開発環境の構築に利用する規格 Development Container
Visual Studio Code で最初にサポートされ、 GitHub Codespace や Visual Studio, さらには JetBrains の IntelliJ IDEA でもサポートが開始されています。

実は PhpStorm でもベータながらサポートされており、すでに実開発で利用可能な水準に達してきています。

今回はそんな Development Container と PhpStorm を用いて、 Laravel アプリケーションの開発環境を爆速で構築する方法を紹介します。

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

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

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

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

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

話すこと

PHP で書く PHP 処理系（のサブセット）の作り方
必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

以下は実用的な言語処理系を支える重要な要素ですが、このトークでは意図的に省き、より容易に理解できる手法で代替します。

• LR 法のような実用的な構文解析手法
• 仮想機械

PHP で JVM (a.k.a. Java Virtual Machine) を実装したり，RubyVM を実装したりと様々な試みがなされてきました。
PHP といえばウェブ開発に特化したプログラミング言語だと思われがちかもしれませんが，今では他のプログラミング言語と遜色ないほど様々なことができます。
もちろんそれは，PHP で CPU を実装することも例外ではありません。CPU にも様々な種類があり，Intel や AMD が代表どころですが，CPU 自体が違えば
実装方法も大きくことなります。
手軽に CPU を自前で実装するのは事前知識がいくつか必要であり，多くの文献を参考にしなければ一つの形にするには時間を要することでしょう。
本トークでは，ChatGPT とともに Intel x86 アーキテクチャをベースに手軽に PHP で CPU エミュレータを実装する方法を解説します。