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

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

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

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

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

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

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

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

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

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

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

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

PHPカンファレンス福岡2023へのプロポーザルを提出するにあたり、
社内のメンバーに何か聞きたいことがあるかヒアリングしました。

結果「打ち合わせがすごい」「打ち合わせのコツが知りたい」という声をもらったので
自分の打ち合わせに関する技術を言語化できればと思います。

打ち合わせは非常にコストの高い業務です。
参加メンバーも多く、メンバーの時給を合算すると意外に多額の予算を消費してしまっています。
打ち合わせの品質を向上すれば、業務全体の生産性は間違いなく上がるでしょう。

下記のようなテーマに沿って話せれば良いなと思っています。
例)

• しっかりとした準備が前提。
• 打ち合わせにはいくつかの性質があり、性質を把握して立ち振る舞いを調整する。
• 前提を合わせることにコストを惜しまない。
• いくつかのオプションと撤退ラインを明確にする。
• 情報の粒度やステータス、用語に細心の注意を払う。

皆さんはサービスを運用していますか？
運用は日々継続して行う必要があるため、とても大切な仕事の1つです。

私は新卒でエンジニアになる前は、新しい技術でサービスを立ち上げたり新しい機能を開発しユーザーに価値を提供する新規開発が、エンジニアの主な仕事だと思っていました。
しかし実際に経験した業務は、既存のサービスをメンテナンスやリファクタリング、ライブラリをアップデートするなどの運用の業務も多かったです。

そのような運用の仕事は、新規開発に比べると地道なものです。
日々の運用をこなす中で「運用の中にエンジニアとして成長できる要素や面白さがある」と気づきました。

本LTでは、新卒2年目のエンジニアがサービスを運用・改善を行う中で得られた成長と技術的な面白さについてお話しします。

話す予定の内容

• サービス監視について
• 運用を楽にする方法
• 腕力（技術力）と怒り駆動開発
• 安全にコードを削除するためには
• サービス影響を小さくリリースする工夫

免責

※ 本LTの内容はPHPに関連しません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

誰向けのトーク？

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

本トークの目指すところ

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

数年間で成長してきた自社プロダクトが、増加したトラフィックを処理できない問題に気付き、
AWSインフラをリプレースすることにしました。

2016年に立ち上げられた自社プロダクトは、利用者数と利用コンテンツがどんどん増えていきました。
さらに、利用プラットフォームもウェブとガラケーからモバイルアプリへと拡大し、利用者の利用頻度も急激に増加しました。
具体的には3年で利用組織が6倍、ユーザーが6倍になりました。
それに伴って、サーバーへのトラフィックも急増し、ボトルネックになりそうな状態に陥りました。

しかし、サーバーは今後も増え続けるトラフィックをうまく処理できず、高いレイテンシで応答するか、最悪の場合システムがダウンするほど可用性が低い状態でした。さらに、障害へのトラブルシューティング対策も不十分で、不安が募りました。

そこで、AWSインフラの問題点を洗い出し、対策案を立てました。
固定台数のEC2インスタンスで対応していたサーバーを、
負荷分散と自動スケーリングが可能な仕組みに変更しました。
さらに、サーバーで行われていたさまざまな処理をサーバーレスに移行し、
自動フェイルオーバーの仕組みも導入しました。
特に、数年間継続して運営してきたサーバーを含むインフラを一新するにあたり、
インシデントが起きないようにリリースまでの流れに検証の内容をしっかり盛り込みました。

• インフラ設計 ‐ 草案
• インフラ構築・実現検証 ‐ デモ
• サーバー簡素化
• システム改修
• プロビジョニングツール導入
• 構築・確認・検証 ‐ デモ
• インフラ設計 ‐ 最終版
• 構築・確認・検証 ‐ 本番
• インフラ切り替え
• ヘルスチェック・イベント可視化

その結果、トラフィックが増えてもうまく分散できるインフラが整い、
低レイテンシでサービスを提供することができるようになりました。
また様々な検証のおかげで、プロダクトに障害を起こさずにインフラのリプレースが実現できました。

このセッションでは自社プロダクトでインフラのリプレースを行った背景ときっかけ、そして実際にリプレースを行った流れを紹介させて頂きます。

Pest (https://pestphp.com)はPHPのテストフレームワークです。PHPUnitをベースにしているので、PHPUnitの機能は全て使えますが、Jestのような直感的なシンタックスで書くことができ、PHPUnitにはない便利な機能がたくさんあります。このトークでは、PHPUnitを使っているけどPestを使ってみたいという方を対象に、以下の内容をお話します。

• Pestのインストール
• PHPUnitとのシンタックスの違い
• LaravelアプリケーションをPestでテスト
• Pest v2の新機能

海外カンファレンスに登壇したいと思ったことはありませんか？Laraconは世界中のLaravelユーザーが集まるLaravel公式のカンファレンスです。
Laracon US, EU, AU, India, Onlineなど毎年に世界各地で開催されています。僕は留学経験などありませんが、今までに2回Laraconに登壇する機会をいただきました (Laracon Online 2022の動画)。英語がペラペラでなくても、面白いトピックと熱意さえあれば誰にでも登壇するチャンスはあります。このトークでは、Laraconへのプロポーザルの提出から、採択されてから本番までの準備、登壇本番までの経験談などをお話します。海外カンファレンスでの登壇に興味がある方にとって、一歩を踏み出すきっかけになれば嬉しいです。

• Laraconのトークプロポーザルの書き方
• 採択されたらどうなるのか
• トークの準備、練習
• 交通費、旅費
• カンファレンス前日（ワークショップ、スピーカーディナー）
• カンファレンス当日

データベースのレコードがどのような経緯で現在の状態になったのか分からず、困ったことはありませんか？
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 が好きな皆さん
• ゲーム作ってみたい皆さん

皆さんはCTO、VPoE、部長、本部長などの役職に就いていたり、キャリアの中でそういったロールに就任することを目標としていますか？
一般的には、役職への就任はポジティブなものとして受け取られることが多いのではないでしょうか。

しかし、私を含めた私の周囲にいる前述のような役職に就いたエンジニアに話を聞くと、どうも本人が望んでいないのにそうなってしまったケースが多いです。
そういった事例を見聞きする中で、本人が望む望まないに関わらず役職に就いてしまうエンジニアの共通点を理解してきました。

PHPカンファレンスに出席するような勉強熱心な方は、出世などせずにIndividual Contributorとしてキャリアを続けたいと考える方も多いのではないでしょうか。
実は、そういった指向の方こそが役職に就いてしまう傾向があると私は考えています。

本トークでは、私がキャリアの中で出会ってきた「気づいたら役職に就いていた」ソフトウェアエンジニアのケースを元に、そういったキャリアを望んでる方には今後目指すためのヒントを、役職に就いてしまった方には出口戦略について考える機会を作れたらと思います。

免責

• 本トークの内容はPHPに関連しません

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

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

ターゲットユーザー

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

概要

エンジニアは継続して勉強する必要があると言われています[要出典]。ただじゃあなにをどうやって学ぶのかはあまり教えてくれません。コードを書いて公開すればいいよとか、本を読むといいよとアドバイスはしてくれるものの、具体的な行動に移すのが難しいなあと感じます。

そんなふうに思っていた自分は今では、年間で、本をたくさん読み、ポッドキャストをたくさん聞き、いろいろな勉強会に参加していました。私が実践している楽しく勉強ができる方法を紹介します。

対象

• 勉強の仕方がわからない人
• いろいろな情報のインプット方法を知りたい人

ValueObject という実装パターンをご存知でしょうか。特にドメイン駆動設計（DDD）の流行以降、基本的な実装パターンとして多くの場面で活用されています。PHP における ValueObject の実装方法は、ある程度は共有されているものではありますが、細部において意見の相違や迷うポイントが存在します。さらに、PHP 8 において Constructor property promotionやreadonlyなどの新しい言語機能が追加されたことで、実装方法が変化しました。

本発表では、ValueObjectを改めて考察し、PHP 8 での実装方法やトレードオフについて議論します。

• ValueObject とは
• PHP 8 における ValueObject 実装
• 完全コンストラクタ（不変オブジェクト）の利用
• 不変条件検証エラーの扱い（バリデーションとの違い）
• 独自型を作る
• ValueObject のトレードオフ

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

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