PHP では、\Traversable を起点に数多くのイテレータクラスが存在します。

極論を言えば、どんな反復可能な処理でも配列を使えば実現できますが、イテレータクラスを適切に活用することで、保守性を高めたり、パフォーマンスを向上させることができます。

本セッションでは、 SPL を含めた PHP がビルトインで提供する様々なイテレータクラスについて、その活用法と合わせて紹介します。

レイヤードアーキテクチャをはじめ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、いわゆるクリーンアーキテクチャ、他には独立したコアレイヤーパターンやADOPなど様々なレイヤ化アーキテクチャが存在していることからわかるように、レイヤを元にアプリケーションを構造化することはとても良いアイデアです。

しかし一方でレイヤを増やしたもののあまりメリットを享受できない場面も存在します。

このセッションでは

• なんのためにレイヤ化をするのか
• どういった観点でレイヤが作られるのか
• レイヤ化することによってアプリケーションの複雑性がどのように管理しやすくなるのか

といったことを考えてみたいと思います

このセッションでは、ターミナル上で動作するリバーシを作成しつつ、テスト駆動開発（TDD）の基本を解説します。
一部、ライブコーディングを取り入れ、PHPを使用してリバーシを開発するプロセスを実際に見ていきます。

セッションの内容 :

• TDDの説明
  • TDDサイクルの説明（Red-Green-Refactor）
• PHPでテスト駆動開発を始めるための下準備
  • PHPUnitのインストールと設定
• ライブコーディング
  • Todoリストの作成
  • 入力の受け取りと出力
  • ルールの実装（石を置ける場所の判定や石を裏返す処理など）
  • 終了判定と勝敗判定の実装

主な対象者 :

• テスト駆動開発に興味がある方
• テスト駆動開発本を写経してみたが、次に何を作れば良いかわからない方

ソフトウェア開発において、モデル化や抽象化と言ったときに、多くの方は実装しようとしているシステムで扱う対象（業務など）に現れる情報や機能の構造をイメージするかと思います。一方で、私のエンジニア経験の中で、扱う対象の見え方がシンプルになるような「道具」としてのモデルを導入できた経験が何度かあります。エヴァンスのドメイン駆動設計でいう「ブレイクスルー」ほど大胆な発明ではないにしても、小さなブレイクスルーと呼んでも良いようなモデルの導入というものがあります。

このトークでは、「日時の範囲」という情報の取り扱いに関して、モデルを導入しない状態から、そのデータと演算とをモデル化して導入していくことで、問題の見え方が変わっていく流れを実際のソースコードを交えてお話します。

Git は、現代のソフトウェア開発において欠かせないツールの1つです。
しかし、一度基本操作から外れると、思いもよらないような複雑な操作を強いられることもあります。
Git の内部構造や仕組みを理解することで、こうしたトラブルを事前に避けたり、トラブルシュートしたりすることが可能になります。
このセッションでは、Git の核となる content-addressable filesystem と commit graph に焦点を当て、それらの仕組みや役割を解説します。

話すこと

• Content-addressable filesystem とは
• Commit の内部表現
• Branch の内部表現
• マージとリベースはどのような操作か

話さないこと

• GitHub、GitLab 等のホスティングサービスについて
• PHP に関すること

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。

このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。

• 少ないGPIOで多くの信号線をコントロールする工夫
• CPUを作るというのは具体的に何をするのか
• 手配線で作るCPUと基板発注して作るCPU
• 自作CPUのデバッグ方法
• Linux上でプログラムを動かすことのメリットとデメリット
• 全てを手放して速度を得る - ベアメタル開発

このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう！

ここ数年、Raspberry PiでCPUを作っています。
これは、CPUをコンピュータから取り外して代わりに自作CPUを取り付けて動かすというもので、オリジナルのCPUの名前のZ80にちなんでPiZ80と呼んでいます。

PiZ80はZ80採用のパソコン・MSXをあわよくば高速に動かすことを目標にしています。
現在のPiZ80はMSXと同じZ80採用のシングルボードコンピュータ・SBCZ80でZ80よりも高速に動作する様になっていますが、ここに至るまでにはさまざまな改善がありました。

このトークではCPUを作るというのはどういうことか、CPUを作る時にどこに速度的な課題があるのか、そしてMSXでPiZ80を動かすまでの道のりをお話します。

このトークを聞いた方がCPUやハードウェア自作が好きになり、そしてあわよくばPiZ80のソフトウェアをいっしょに改善していけることを願っています！

プログラミング言語の処理系は複雑な処理を行っているように見えますが、個別に分解してみれば一つ一つの処理はそれほど難しくありません。
PHP 処理系のソースコードを魔改造して PHP 言語に独自の拡張を施すことで、日ごろ使っている PHP やその他の言語処理系が、内部的にどのような処理を行っているのかを追いかけてみましょう。

話すこと

• PHP のソースコードを改造し、関数の合成を行う独自の演算子を追加する
  • 注: 何らかの事情で、具体的な拡張の方向性は変わる可能性があります
• 言語処理系がどのような処理を行っているのか、はじめからおわりまで一通りさらう

目的としないこと

• PHP に実用的な拡張をおこなうこと

Fiber は、PHP 8.1 から導入された stackful な coroutine です。
ここで一度、Fiber の実装を PHP の処理系レベルまで追いかけることで、Fiber が何であるか、そして、裏で何をしているのかを理解することにしましょう。

主な対象

• 非同期処理の内部実装に興味があるかた
• 言語処理系の内部実装に興味があるかた

話すこと

• PHP における「Fiber」とは何か
• PHP の VM (virtual machine) のおおまかな構造
• Fiber を実行・停止・再開・中断したとき、PHP VM に何が起こるか

話さないこと

• Fiber を裏で利用するライブラリやフレームワーク
• Fiber の使い方

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

話すこと

• PHP における GC のアルゴリズム
• 確保したメモリはいつ解放されるのか
• メモリ溢れを起こさないプログラミング

話さないこと

• GC のパラメータをいじってチューニングする

背景
あるプロジェクトでたくさんの障害を発生させてしまった。。。
障害はユーザーに迷惑をかけてしまうし、エンジニアのメンタルが削られるし、進行中のスケジュールを圧迫する。全然いいことがない。障害はこの世から無くなって欲しい。せめて減らしたい。。。
そんな思いから開発プロセスを見直す動きが社内で生まれました。

お話しすること
・そもそも障害と何なのか？障害と向き合う
・適度な障害予防コストのバランス
・プロセス確立までの道のり
・実際のプロセスや工夫を紹介

障害を少しでも減らしたい、自分のチームに見合ったプロセスをカスタマイズしたいと同じ悩みを抱えているPHPerの皆さんにお伝えできれば幸いです！

弊チームではこのたび、15年間誰も手をつけられなかったレガシーシステムを、バグ0でフルリプレイスすることに成功しました。

チーム発案のオリジナル検証手法をはじめ、シャドーテスト、カナリアリリース、ダークローンチ、フォールトマスキングなど、
多彩な手法を駆使することで、リスクを最小限に抑えながら安全に倒し切ったリリースを実現することができました。
どのように予期せぬトラブルを未然に防ぎ、計画通りのリプレイスを成し遂げたのか。その実践的なプロセスについて、詳しく解説します。

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

本セッションの対象者
・日々レガシーシステムと向き合っている方
・テストや検証手法に興味のある方
・フルリプレイス挑戦記と聞いてワクワクした方

「ライブラリが古いせいでやりたいことが出来ない」「利用バージョンのドキュメントが既にこの世に無い・・・」そんな経験はありませんか？

古いライブラリはセキュリティリスクをもたらし、技術的負債にも繋がります。
本トークでは週次でのライブラリバージョンアップを1年以上続けている実体験をもとに、継続的バージョンアップのメリットや安全に実施するために出来る工夫、はじめ方についてお話します。

想定観客

• バージョンが古いせいで苦しんでいるかた
• ビッグバンバージョンアップでつらい思いをしたかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

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

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

想定観客

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

お話しすること

• そのコード、nullが返ってきたとき死にます
• そのコード、クエリ1,000回発行されるけど大丈夫？
• そのコード、メモリ1GB使うけど大丈夫？
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

登壇をする内容の概要
プロダクト開発を成功させるには、重要な機能にリソースを集中させることが不可欠です。重要な機能にフォーカスすることで、最大の価値と競合差別化を生み出せます。
一方で、重要でない機能を含む全体的なリファクタリングや、コードベースの保守性向上だけでは、こうした成果は得られません。
この登壇では、重要な機能についての考え方とLaravelを使った重要な機能とそうでない機能のコストをかけない機能の実装方法も提示します。

話を聞いた人に持ちかえってほしいこと
聞いた人には、プロダクトの機能を再評価し、リソース配分の優先順位を考え直すきっかけにしてほしいです。また、その考え方をチームで共有し、ディスカッションを通じて話し合う機会を持っていただきたいです。

主な内容

• プロダクトの価値を考える必要性
• どのように優先することを決めるか
• Laravelを使った実装例

このセッションのゴールは、オブジェクト指向の再認識です。

SOLID原則を世に広めた、アンクル・ボブことロバート・C・マーチンの新刊、「Functional Design」が登場しました。関数型ブームの影響を受けた現代のプログラミング言語から見ると、この本の登場はむしろ、遅すぎたと言ってもよいかもしれません。しかし一方で、私達は普段の経験で十分に、関数型の本質的な原理を理解したと言えるでしょうか。

改めて関数型とは何なのかを理解し、そこから逆説的に、次のようなテーマを深堀りしていきたいと思います。

• 関数型の支持者がOOPと呼んだ概念の的外れっぷり
• 計算機科学でオブジェクト指向をとらえようとした過ち
• 生成AIやオブジェクト指向と、21世紀の哲学の相性の良さ
• プログラマーと日本人はなぜオブジェクトをうまく説明できないのか

(ぜんぶ喋れるんかこれ!?)

ここ数年、LLM の進化とともに、RAG（Retrieval-Augmented Generation：検索拡張生成）の構築・利用が進んでいます。RAG の内側ではよくベクトル検索が使われていますが、ベクトル検索には RAG 以外にもいくつかの使い道があります。

本トークでは、ベクトル検索を理解するのに必要な事項と、PHP から利用する際のサンプルコードについて説明します。

• ベクトルとは
• 情報をベクトルで表現すると嬉しいこと
• 距離と類似度の種類と計算
  • ユークリッド距離
  • コサイン類似度
  • どれを使ったら良いの？
• ベクトル検索の使い道
  • レコメンド
  • セマンティック検索 etc.
• LLM の埋め込みモデルとベクトルストア
• ベクトルストアで近似近傍探索インデックスを使う
• pgvector-php を使ってベクトル検索を試す

現代はGitHub Copilotなどの生成AI開発支援ツールが普及していますが、簡単に使える一方で、「サンプルを生成して」等の単純な質問しかせず「ChatGPTで十分では？高いし！」という声も聞きます。

もったいないと私は思います！

チャット機能しか使わないのは確かに煩雑で「自分で書いた方が早い」と思うのも理解できます。しかし、ツールは進化を続けています。様々なUIや機能を活用し、AIとより良いコミュニケーションを取ることで、AIという相棒と共に、より効率的な開発をしませんか？

アイザック・アシモフの『鋼鉄都市』では、C（炭素＝人間）とFe（鉄＝ロボット）がバディになります。最初はR(obot)を嫌っていた人間の主人公も、最終的にロボットとバディとなりました。
それは小説ですが、SWEの皆さんも、人でない生成AIと良きバディになれると思います。共にC/Feの文化を築きましょう！

「複雑で辛いコード」という概念は確かに存在するものの、
その正体がどこにあるか…？を上手く説明できないという事態も、しばしば発生するのではないでしょうか。
プログラミングは往々にして「感覚」「センス」も重要なのは百も承知。
でも、可能なら地に足のついた説明を加えたいですよね。

色々な分析・説明の手法を頭の中の引き出しに入れておくと便利です。
そんな物差しの1つの例として、「LCOM」があります。凝集度を数量化するものです。
定義をしっかり記憶していなくても、
そのコンセプトは、目の前のコードで「何が起きているか」を感じるための大きな助けになります！

このトークでは、
「ざっくりLCOMってなに」を話し
「手書きで図にしてみると分かりやすいね、似た考えを普段から使えそう」を感じてもらい
「抽象化やパターンと絡めて、リファクタリングに取り入れてみるとこんな感じに」をお届けします。

最近またオレオレフレームワークをつくりました、私のフレームワークのポリシーは長生きができることです。

今回私が一晩で作り上げたフレームワーク()をベースに、どのような部分を意識することでコードが理解しやすく、長生きができる工夫をしているかをお話ししたいと思います。

機能が満載のライブラリやフレームワークに慣れている皆様は、「こんな素朴な規約やフレームワークは使いたくない！」と思うかもしれませんが、私は誰でもわかり、5年10年生き延びるフレームワークにしたいのです。

本トークはオレオレフレームワークにかぎらず、特定のライブラリと密結合せずデカップリングするようなコードを書く際にも役立つと思います。

皆さんも手のひらに収まるようなコードにして、暗黙を避け、ジョインした人がすぐにコードをかきはじめられるようにしてみませんか？