世の中に入門書や入門者向けの記事は溢れています。
上級者向けの書籍や記事も増えています。
入門書を終えた後、次のステップに進むために何を学ぼうか悩んでいるビギナーの方は多いのでは無いでしょうか？
PHPを使って業務で開発を行っていくうえで、次のステップとして学ぶと良いことをお話ししていきます。

◆対象者
・入門書をやり終えた程度のPHP初心者
・簡単なWEBアプリケーションが作れるようになったPHP初中級者

◆話すこと
・バグを生み出しづらい書き方
・コーディング規約
・チーム開発において読みやすい書き方
・コメントの入れ方
・セキュリティを意識した書き方
・エラーの見方

内製開発チームを立ち上げて半年程度のスタートアップに昨年ジョインし、7月からCTOをやっております。
14名の開発チームに成長、サービスの展開を加速させていく中で、組織作りや開発基盤の整備を含め、取り組んできたことをPHPer目線でお話しします。
CTOに限らず似たような立ち位置の企業にジョインしたエンジニアの参考になればと考えています。

◆対象者
・スタートアップエンジニア
・新規の開発チーム立ち上げをしている人

◆話すこと
・エンジニア組織作り
・採用、技術広報
・経営層、他部署の知識向上
・開発環境、ルール作り

ソフトウェア開発において、私が重要だと考えるアプローチは「可能性を狭める」というものです。例えば、型宣言を指定して値が取り得る範囲を絞り込みます。これにより、コードを読む際に考慮しないといけない範囲を限定できます。これは認知負荷を下げることに繋がり、引いては読みやすいコード、変更しやすいコードにできます。さらに、宣言する型を独自に定義した型にすることでその範囲をより狭くできます。こうした型による制約は、静的解析ツールや PHP ランタイムによって機械的にチェックされると言うのも大きな利点です。

一方、こうした制約を設けずに多機能なクラスを作成することで、可読性やメンテナンス性が低下し、問題が生じると言う経験をした人もいるのではないでしょうか。

このアプローチは、型システムだけでなく、クラスやモジュール設計、ソフトウェアアーキテクチャ、デバッグやパフォーマンスチューニング、自動テストなど、開発の多くの側面に適用可能です。

本セッションでは、特にまだ開発経験が浅い方や開発タスク自体はこなせるようになってきた方に向けて、今後さらに現場で活躍していけるように基礎となる考え方として知っていただきたい内容をお話しできればと思います。

「あーあれでしょ、なんか、なんか、ファイル呼び出し良い感じにしてくれるやつ！！」
かつての私のautoloadとの向き合い方はこのレベルでした。
（いや、なんならもっと解像度が低かったかもしれません・・・）
「Composerを「なんとなく使う」から「理解して使う」になる」という発表を別イベントですることになってから、Composerと向き合い、Composerときちんと向き合い彼らとの絆を得ました。
本セッションでは「autoloadってなんだっけ？」から入り、どのように動いているか、また、そもそもComposerを使っていない、namespace採用ができていない、...とかいう拡張が難しいアプリケーションサービスにautoload機能を導入する話も折り入れ話して行きます！

■ autoloading機能とは
■ どのように動くか、コードを見ていく
■ PSR記法について
■ 拡張が難しいアプリケーションでautoloadを導入した話

■ 想定する聴衆
Composerをなんとなく使ってる人
autoload機能あんまり意識して使ってない人

タイトルを見て驚かれた方もいるかもしれません。
そう、サポートの切れた Laravel 6 を利用しているプロジェクトがまだこの世にはあるんです。

最近は意識が変わってきていますが、継続的なシステム開発において、
目に見える機能改善とは異なり、バージョンアップやリファクタリングに時間を割かれる事例は稀です。

それでも、長い、長い、交渉の末に、バージョンアップの機会を手に入れることが出来ました。

このセッションでは、Laravel 6 で4年運用されてきたシステムを Laravel 10 に移行すると共に、
構造が古く、メンテナンス作業の足枷になっていたアーキテクチャの再考をしたプロジェクトについて、
実際に遭遇した問題と解決策を交えながら、知見の共有を行ないたいと考えています。

フルスクラッチで開発を行うプロジェクトとは異なる性質のプロジェクトにおける準備や勘所、そして覚悟をみなさまに共有できたらと思っています。

CPUが好きです。
私は中学生の頃にMSXというパソコンを入手し、MSXのCPUであるZ80のマシン語をプログラミング言語として体験していました。

時を経ること25年、2016年にPHPで書かれたゲームボーイエミュレータのコードを読んで衝撃を受けました。ゲームボーイのCPUはZ80をベースに開発されたものであり、ゲームボーイエミュレータのコードで実装されていたのはまさにそのZ80の命令だったのです。

その瞬間、それまで「よくわからないけどすごいプログラム」だと思っていたエミュレータのコードが、ハードウェア仕様をそのままソフトウェア的に表現したものであることが理解できました。

そしてその3年後、2019年に名著「CPUの創りかた」で紹介されている4ビットCPU TD4を実装し、そこでまた衝撃を受けました。そこに見たCPUは、プログラミング言語として見たCPU、エミュレータの対象として見たCPUのどちらとも違い、電気回路として命令の実行が表現されたものでした。

これで完全にCPUに心を奪われた私は、2022年から趣味プロジェクトとしてZ80のハードウェアエミュレータを開発しています。
これはZ80で動作しているコンピュータからZ80を取り外して、代わりに自作のZ80ハードウェアエミュレータを取り付けて動作させるというもので、Raspberry Pi に自作のハードウェアを接続した形になっています。

このトークでは私がこの数年で触れてきた4つのCPUのうち、特に電気回路として作ったCPUとRaspberry Piで作ったCPUの2つにフォーカスしてCPUの楽しさをみなさんにお伝えします。

・物理CPU Z80
・PHPで書かれたZ80ソフトウェアエミュレータ
・電気回路として作った4ビットCPU TD4
・Raspberry Piで作ったZ80ハードウェアエミュレータ

どれも"CPU"ですが、それぞれ開発時に見える世界が全く異なっています。
初心者の方でも楽しめる様にお話しするつもりですのでお気軽に聞きに来て頂ければと思います。
このトークを通してみなさんがCPUの設計や動作に興味を持ち、いっしょにCPUについて語れることを楽しみにしています！

現代のコンピュータはハードウェアから私たちプログラマが書くプログラムの動作までの間が多くのレイヤーに分けられて動作しています。
レイヤーは自分より下を抽象化し、下のレイヤーを詳しく理解しなくても多くの場合プログラマはプログラムを書けます。
一方、プログラムが期待した様に動作しない時には下のレイヤーの動作の理解が問題の解決の助けになることもあります。

このトークでは私たちが愛するPHPをスタート地点にして、コンピュータプログラムがどの様に動作するのかを解説します。

・PHPプログラムが実行される時にコンピュータ内部で起きていること
・2種類の"プログラム実行" - CPUかそれ以外か
・CPUによる"プログラム実行"
・インタープリタ - PHPやJavaとC言語の根本的な違い

コンピュータのレイヤー構造を理解するとプログラミングに役立つだけでなく、いままでは見えていなかったレイヤーのプログラミングを楽しめるようになります。
このトークを通じて、低レイヤーが好きになったり、いろいろなレイヤーで面白いことをしたりする方が増えることを期待しています！

私はこの数ヶ月、趣味プロジェクトとして1980年代に栄華を誇った名作CPUである"Z80"のハードウェアエミュレータを開発しています。
これはZ80で動作しているコンピュータからZ80を取り外して、代わりに自作のZ80ハードウェアエミュレータを取り付けて動作させるというもので、Raspberry Pi に自作のハードウェアを接続した形になっています。

このトークではZ80ハードウェアエミュレータの解説を軸に、CPUの作り方や、その楽しさをお伝えします。

主なトピック:
・Z80ハードウェアエミュレータの構成
・CPUを作るために必要なもの
・Raspberry PiでCPUを作る方法
・Z80ハードウェアエミュレータの課題とその解決方法

CPUを作ってみたい方はもちろん、コンピュータの仕組みを理解したい方や、プログラムが実行された時にコンピュータの中で何が起きているのかを知りたい方などにもお楽しみ頂けると思います。
このトークを通じて、CPUに興味を持ち、CPUについて語る仲間が増えることを期待しています！

エンジニアの生産性には、優秀な人とそうでない人との間に大きな差があると言われています。
その差はどこからくるのでしょうか？
今回は「学習」という側面にフォーカスしながら、生産性の高いエンジニアであり続けるための戦略について考えてみます。

エンジニアの生産性の差は、ひとつには教わるだけの人と自ら学ぶ人との学習姿勢の差が反映されたものです。
自ら学ぶ人は常に教わるだけの人の先を行きます。それどころか「学び方を学ぶ人」はさらにさらに先を行くことになるのです。

技術・環境・ツールの変化が激しく既存のスキルがすぐに陳腐化してしまう現代において、「学び方の学び方」こそが重要なスキルになります。

このトークでは、エンジニアに欠かせない学び方の学び方と、自ら学ぶ集団の作り方について共有し、みなさんと共に考えていければと思います。

人生は後悔の連続です。
それはシステム開発の現場においても同様と言えます。

Minimum Viable Product だ！必要最低限の機能に絞って実装しよう！
データベースは正規化して、nullable は排除、データベースで整合性を担保しよう！
CI/CD 環境を整えて不安の無いデプロイを実現しよう！

全て3年前のプロジェクトメンバーが聞いたら納得する内容です。
実際に私も納得して開発していました。

しかし、システム開発において想定外の事態というものは必ず存在します。
1つのシステムを横展開するという企画から始まったシステムも、
今や50を超える類似システムが存在します。

「類似」システム……。
そう、何一つとして同一のものはないのです。

度重なる仕様変更。
崩れる正規化。
壊れるブランチ戦略。

そんな、横展開の闇に揉まれながら、血を流しながら、システムを改善していく、

「システム開発現場のリアル」

についてお話したいと思います。

皆さん、技術的負債、返済してますか？
プロダクト開発も進めたいし、負債も返済したい、けどリソースは限られている！と思ったことはありませんか？ならば静的解析を使ってもっと効率的に進めよう！そう思ったことがある人、実行している人も多いのではないでしょうか。

私たちは元々PHPStan等のツールを利用していたのですが、コードの修正まで手掛けてくれるRectorも利用することで更なる効率化を目指そうとしました。標準ルールを使うことは容易に思えました。しかし、カスタムルールを作ろうとなった時にハードルがありました。

インターネットを探すといくつか情報が見つかります。ただ、説明がシンプルだったり、理解するのにある程度の知識が必要だったり、シンプルなルールを書くのにもちょっとした難しさがありました。よりスムーズに入門できるよう、もう少しハードルを下げたいと感じました。

このトークでは、Rectorに入門しようとする過程で整理したナレッジを共有します。
カスタムルールの書き方を理解する上での勘所があると私は考えています。理解を促すいくつかの視点、ルールを書く際に利用できるクラスやその探し方を提案したいと思います。
RectorはPHP Parserの上に成り立っています。これからカスタムルールを書いてみようという方にもとっつきやすいよう、基礎となるPHP Parserの仕組みにも触れつつ説明したいと思います。

誰向けのトーク？

• Rectorでカスタムルールを書くことにハードルを感じたことがある方
• 技術的負債の返済方法を模索している方
• 静的解析の仕組みに興味がある方

本トークの目指すところ

• Rectorのカスタムルールを書き始めるまでのハードルを下げる。
• それによりRectorを活用しやすくし、負債解消手段の選択肢を増やす。
• 静的解析の仕組みについて少し理解を深める。

データベースのレコードがどのような経緯で現在の状態になったのか分からず、困ったことはありませんか？
Event Sourcingは、アプリケーションの状態変更をイベントとして記録し、それを用いてアプリケーションの状態を再構築するアーキテクチャパターンです。このトークでは、LaravelでEvent Sourcingを実装する方法について、具体的な手順と実践的なパターンを紹介します。

• Event Sourcingとは
• Event Sourdingのユースケース
• Event SourcingをLaravelアプリケーションで実装
  • Projector
  • Reactor
  • Aggregate
  • Serializer
• ドメインごとのイベントストア
• テストの書き方

みなさん、 Web 、してますか？ Web アプリケーションの一つに 「 3D リアルタイムレンダリング」 があります。 WebGL と呼ばれる技術を用いて、ネイティブアプリのように滑らかに動作するゲームやショーケースなどを作ることが出来ます。
その中でも今話題沸騰なのが WebGPU という新しい規格です！これは Vulkan や Metal のように GPU を直接呼び出す新しい技術で、今まで WebGL1, 2 で作られてきたものよりも効率的に 3D レンダリングを行うことが出来るようになります。
これは現在 Google Chrome の最新版に 4 月中にリリースされる予定となっていて、もうエンドユーザーに届けられる段階にあります。

その WebGPU を一足先に、一年前から対応していた 3D リアルタイムレンダリングライブラリが Babylon.js です。これは皆さんおなじみ（？） TypeScript で作られているフレームワークで、非常に簡単な API で豪華なアニメーションや VR/AR 表現を行うことが出来る素晴らしいプロダクトです。

しかし、悲しいことに Babylon.js の採用事例はまだ国内外ともに少なく、もったいない状態になっています。そこで、普段 PHPer である皆さんにも是非触って欲しい。ゲーム作ってみて欲しいということで、今回紹介させて頂きたいと思います！

ターゲットユーザー

• 新しいものが好きな全てのエンジニアの皆さん
• TypeScript が好きな皆さん
• ゲーム作ってみたい皆さん

1秒間に PHP が受信する HTTP リクエストが最大 10,000 回以上———

そんな世界が存在します。その一つが 「ソーシャルゲーム」 です。メンテナンスが明けた瞬間、イベントが始まった・終わる瞬間、様々なタイミングでゲームサーバーは瞬間的に高負荷になります。もちろん、サービスをリリースし PR をたくさん出し始めたその瞬間が、プロジェクトで最も高負荷となるでしょう。それらに耐えうるサーバー構成が求められていますが、「リリース直後にサーバーがダウンした」「限定イベントが始まったらすぐ緊急メンテナンスが始まった」という話はちょくちょく聞こえてきます。その 瞬間的な高負荷(いわゆる "スパイク") を耐えるには、事前準備を怠らないことが重要です。
ソーシャルゲームにおいては、他の Web アプリケーションに比べ 書き込みヘビーなワークロード であることが多いです。読み込みは比較的簡単に分散出来ますが、書き込みを分散することは容易ではありません。
そういった要件を達成するため、私のチームで行っている、 Laravel による高負荷を耐えるサーバー設計をご紹介したいと思います。

ターゲットユーザー

• 高負荷案件でも Laravel は使えるの？と疑問に思う方
• どのようにスパイクをさばいているのかを知りたい方

考古学（こうこがく、英語: archeology）は、「人類」が残した「遺跡」から出土した「遺構」などの「物質文化」の研究を通し、「人類の活動」とその変化を研究する学問である。（Wikipedia）
つまりアーキテクチャ考古学とは、「先人」が残した「コード」から出土した「遺産・負債」などの「アーキテクチャ」の研究を通し、「プロダクト」とその変化を研究する学問である。（Akito.Tsukahara）
みなさん、こんにちはアーキテクチャ考古学者のAkito.Tsukaharaです。
この登壇では、新しく入社してくれたメンバー達へのオンボーディングをするために、考古学した（弊社のプロダクトのアーキテクチャを研究、文言化して、社内で勉強会）取り組みについて発表させていただきます！
考古学することには、「システムの理解とドメイン知識の向上」や「技術的負債の認知」をオンボーディングで伝えることで
新メンバーが少しでも楽に現場の開発に慣れてもらう意図があります。
この発表をご覧いただくことで以下の情報をお届けできます。
・考古学のやり方
・アーキテクチャに関する知識・ノウハウ
　・レイヤードアーキテクチャ
　・テスト設計　etc...
・オンボーディング資料の作り方
・社内勉強会でチームの巻き込み
など

我々アプリケーションエンジニアにとってデータは非常に重要なものです。
皆さんもRDBのデータ、ログデータ、分析データといった色々な種類ものを扱うことが多いのではないでしょうか？

しかし、これらのデータはエンジニアだけのものではなく、マーケター、事業責任者といったプロダクトに関わる全員が関わるべきものではないでしょうか？
そのためには、SQLの習得といったスキルの問題や、業務サービスへのアクセス権限といったガバナンスの問題もあり、なかなか難しい課題なのではないでしょうか？

そこで、我々の開発チームでは、開発だけでなくプロダクト全てのサイクルに関わる"Fullcycle Developers"という標語を抱えています。
その一環で、我々が作ったプロダクトの成果をデータ含めてフィードバックループを作るようにしています。

その結果、BIツールを用いて、SQLを出来る限り書かずともチームの皆がデータを可視化・確認できるようになり、開発に関する議論も職種問わず活発化しました。

そこで今回のトークでは、我々のチームが、どのようにデータの民主化を進めていったのか、データの民主化によってどのような変化があったかをお伝えします。

具体的なBIツールなどの使い方などに関しては話さない予定です。

アプリケーションを開発するなかで設計手法が必要と感じたら、DDD（ドメイン駆動設計）が選択肢の一つです。

最初からアーキテクチャを導入するわけではなく、約10年成長してきたLaravel的なEloquentを活用したMVCで作られたアプリケーションにアーキテクチャを導入する際、悩みや数々の試行錯誤がありました。

私たちの経験を元に、オニオンアーキテクチャをベースに、既存コードの対処法やネームスペース、クラス分割のコード例と背景を紹介します。

想定対象

• 既存プロダクトにDDDを導入したい方
• Laravelにオニオン（レイヤード、クリーン）アーキテクチャを取り入れて見たい方

話すこと

• 既存コード（主にEloquentとUtilクラス）との付き合い方
• ネームスペースの切り方と背景
• クラスの分割と背景
• DIの方針と背景

話さない内容

• DDDを使う理由
• モデリングに関すること
• ドメインロジックの定義

ウェブサイトのコンテンツ管理とテンプレーティングはWWW初期から長らく課題とされてきました。

コンテンツ管理システム(CMS)というアイデアの原型が生まれたのは25年ほど前ですが、現在でも世界のウェブサイトの多くはWordPressに代表されるCMSで運営されています。
一方で、コンテンツ管理とテンプレーティングという課題に対する別のアプローチとして、静的サイトジェネレータ(SSG)という概念も発生し、今日でも発展を続けています。

CMSとSSGは二者択一のものとして解釈されがちですが、近年ではHeadless CMSのような折衷案も登場しており、周辺のスタックまで含めると選択肢は無数に存在すると言えるでしょう。
これらの選択肢を個別に検討するときりがありませんが、検討のための手がかりはないのでしょうか。

スピーカーはその手がかりが「歴史」にあると考えています。
ある技術やソフトウェアが開発されるには、それまでの出来事からニーズが発生するためであり、そのニーズを読み解くことで強みを見抜くことができるでしょう。

LAMPからJAMStack含め最新の動向まで、WWWの歴史やエンジニアリングの歴史とともに俯瞰していきましょう。

先日、4月19日に福岡発のオープンソース、baserCMSの最新バージョンがリリースされました。
世の中において、PHPにおけるフレームワークのニーズは、Laravelがうなぎ登りですが、baserCMSは、オープンソースとして外部のコードが受け入れやすいよう、規約重視であるCakePHPを採用し、最新バージョンもCakePHPで開発されています。

最新バージョンであるbaserCMS５の開発では、レガシーコードからの脱却を目指し、これまでの12年間の開発で熟成した「秘伝のタレ」的なコードを全て見直し、モダンな開発プラットフォームとして成長しています。

実は2017年より、ゆっくりとその開発が始まりましたが、その過程の中で、目指すCakePHPのバージョン対象が３から４へと変化し、そして、先日のbaserCMS５のリリース前に、ついにCakePHP５のベータ版が勧告されてしまいました。

このセッションでは、開発中のエピソードや移行のポイント、また、DIやサービスなどの概念を踏まえ、土台となるフレームワークがどのように変化しようと心が折れないアーキテクチャーとは何かについてお話できればと思います。

B+木をご存知でしょうか？RDBMSのインデックス作成に採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてもイマイチ特徴がピンと来ないのです。

本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか？などなど、データベースの仕組みの根幹を覗いてみましょう。

本トークで話す内容

• B+木の特徴
• なぜ、データベースはB+木を採用しているのか
• インデックスとは何か