みなさんは「SadServers」というwebサイトをご存知ですか？
webサイトにアクセスすると「Like LeetCode for Linux」と説明されています。
「LeetCode」であればご存知の方もいらっしゃるかもしれませんね。

このwebサイトでは「悲しい状態のサーバー」となっている設問が準備されており、「LeetCode」の要領で悲しくない状態にしてあげることが設問のゴールとなっています。
最近は「webアプリケーション開発を行っているとサーバーを触る機会がない」、「サーバーのことをどうやって勉強したらよいかわからない」といった話をたびたび耳にします。
なので、「SadServers」を通してこのセッションがサーバーに関する勉強を始めるきっかけになればよいと思っています。

PHP 処理系内でメモリのどこに何があるか、を意識してプログラミングをしたことがありますか？

2020 年頃から、PHP で PHP のプロファイラを作っています。
これは プロセス外から FFI を通じてシステムコールを呼び、対象プロセスのメモリ内容へアクセスし、実行中の処理系内部の C 言語構造体のデータを直接読み取るという仕組みで動作します。
https://github.com/reliforp/reli-prof

さて、このスクリプトを動作させるには、処理系内でどこにどんなデータがどのような形であるか、を詳細に把握する必要があります。そしてその構造知識をコード内へ転写していくことでツールの機能を追加していけるのですが、この過程で私自身の中にもちょっとした変化が現れてきます。ふつうの PHP スクリプトを書きながらでも、プロセス内でメモリがどう使われどのような処理でアクセスされるかを、なんとなく把握できるようになっていくのです。

このトークではツール作成の過程で得られた処理系内のメモリレイアウトについての知識を幾つか紹介し、聴講者の皆さんも PHP スクリプトを書きながら裏側のメモリ構造がうっすら透けて見えるという状態になることを目指します。

対象聴講者はたとえば以下のような項目が気になる人です。

• 変数や値がどうメモリ内に格納されているか
• interned string とは
• 配列がどうメモリ内に格納されているか
• オブジェクトがどうメモリ内に格納されているか
• 「クラス」はメモリ上でどういう構造のものなのか
• 宣言された引数と動的な引数の違い
• 宣言されたプロパティと動的プロパティの違い
• opcache でキャッシュされた内容のメモリ上での表現
• apcu でのキャッシュのメモリ上での表現

「コンピュータは0と1しか処理できない」とよく言われています。
ビット演算があったり、浮動小数点演算があったり、文字コードが16進数だったりと、ソフトウェアエンジニアならなんとなく実感としてはあると思いますが、なぜどうして「0と1しか処理できない」のでしょうか。

コンピュータは現実世界に存在するモノです。コンピュータの実態は電気回路ですが現実世界に存在する以上はアナログの世界に存在しています。
一方、コンピュータは計算機であり、計算する対象はデジタルな離散値です。
過去に、アナログ計算機や、電気を使わない機械式のデジタル計算機も存在しましたが、現在主流なのは電気回路からなるコンピュータです。
コンピュータが「0と1しか処理出来ない」のは、電気回路でデジタルな計算を効率良くするための工夫なのです。

このトークでは「電気回路でCPUがどの様に表現されるか」から、私たちがディスプレイやスピーカーでコンピュータの動作を認識できるところまでがどの様にできているかを以下の様なトピックを中心にお話します。

・電気回路上での0と1
・コンピュータの構成要素 - CPU, I/O, メモリ
・本当に演算だけをしている「中央演算装置」ことCPU
・いろいろなメモリ: 近い or 遠い, 安い or 高い, 速い or 遅い, 小さい or 大きい
・キーボードもディスプレイもBluetoothも…多岐にわたるI/O
・デバイスを結ぶ通信路: バス

初心者の方から上級者の方までお楽しみ頂けるトークになると思いますのでぜひ聞きに来て下さい！
このトークを通して、コンピュータ好きの方が増えること、そんなみなさんで楽しいコンピュータ話をすることを楽しみにしています！

Twitterの変化が激しい今日この頃、ツイッタラーの皆さんはいかがお過ごしでしょうか？
私は普段から技術情報の収集などあらゆる面でTwitterにお世話になっており、ホームと言っても過言ではありません。
しかし、最近はエイプリルフールでもないのに突然アイコンを犬に変えるCEOの采配などに不安を感じています。

万が一の際の移住先を色々と調べた中で、技術者としても興味があるCloudflareのWildebeestに手を出すことにしました。

WildebeestはActivityPub＆Matodon互換サーバーであり、Cloudflare PagesとPages Functionsで稼働するフルスタックアプリです。
CloudflareアカウントとCloudflareを使用したDNS zoneが１つあれば、手持ちのドメインでセルフホストすることができます。

• データベースに D1
• オブジェクトキャッシュに Workers KV
• 認証に Zero Trust Access
• 非同期ジョブに Queues
• メディアに Images

と、Cloudflareが提唱するSupercloudの見本市とも言えましょう。

私も以前からエッジコンピューティングには注目してはいたものの、読込の多いWebサイトのようなシステムにしか向いていないのではないか？という偏見がありました。

MastodonのようなWebアプリがエッジでまともに動く？ 本当に？

本トークでは、Wildebeestの利用を通じて、最近ノリにノッているCloudflareのSupercloudを覗いていきます。

● 話したいこと

• Cloudflareの提唱するSupercloudという概念
• Wildebeestの構成とCloudflareのプロダクトについて
• Wildebeestを運用してみた感想
• パフォーマンス面

● 話さないこと

• PHP

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の楽しさをみなさんにお伝えします。

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

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

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

このトークでは私たちが愛する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について語る仲間が増えることを期待しています！

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

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

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

"品質"

IT業界では長らく「ふわっと」利用されてきた言葉です。

ですが、"品質"には定義があります。
あなたは"品質"について説明できていますか。

このトークでは"品質"の定義とシステム開発において要求される"品質"の満たし方についてお話します。

このトークで得られる知見

• "品質"の定義
• "高品質"の達成の仕方
• ユニットテストにおける"「どこまでやるか？」の割り出し方"

このトークで話さない事

• 品質工学

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
しかし、せっかく作ったウェブアプリケーションも、保守・運用で扱いにくいとレガシーアプリケーションとか、技術負債などと呼ばれます。また、PHP を忌避するエンジニア達も存在していて、レガシー化しやすいから PHP で新しいアプリケーションは作りたくないと評されたりもします。

しかし、保守性の高いウェブアプリケーションとなると、難しい設計論とかアーキテクチャーとかの話が出てきて、どうやっていいかよくわからなくなります。
なんとか、PHP の気軽さを保ちつつ、保守・運用がしやすいウェブアプリケーションを作ることはできないだろうか？
本トークでは、なるべく難しい設計論を避けつつ、どうやったら無難で、レガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークでお話すること

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り

ソフトウェア開発において、データとして数値化できるものを管理可能な状態にまとめたものをメトリクスと呼びます。"Lean と DevOpsの科学" で有名になった Four Keys なども４つのメトリクスをまとめたものです。

ソフトウェアの改善においては、まずメトリクスを計測し、KPI を定め、改善を進めるのが王道です。

うちのアプリケーションは複雑で理解しにくい。そんな話は、ある程度成功したウェブサービスであれば、どのサービス事業会社でも聞けそうな発言です。では、その複雑とは、一体どんな原因によってもたらされているのでしょうか？その複雑さは監視・改善できるのでしょうか？

本トークでは、複雑性の監視に使えるツール類と、計測できるメトリクスを紹介し、どうやってそれを継続監視して改善に活用するかを紹介します。

本トークで話す内容

• 複雑性とはなにか
• メトリクスの測り方、継続監視の仕方
• 複雑性改善の方法

アプリケーションを安定的に運用していくには、安定した実行基盤を構成する必要があります。
プラットフォームの選択肢として Microsoft Azure というクラウドをオススメしたいです。

「PHPとAzure」についての情報はそれほど多くないため、親和性はあまり良くないんじゃない？と思う人もいるかもしれません。
しかし現在の Azure は様々なサービスが提供されており、PHP 製のアプリケーションでも PHP を普段使っているエンジニアでも、様々なシーンで Azure を利用することができます。
PaaS (Platform as a Service) を中心としたアーキテクチャーを構成することで、運用の作業負荷を軽減し、エンジニアが本来の役割や作業に専念するための環境を作ることができます。

アーキテクト（アーキテクチャーを考える人）やアプリケーション開発者を対象に、Azure で実現するクラウドアーキテクチャーについて紹介するセッションを行います。

【取り上げる予定のキーワード】
パブリッククラウド、Microsoft Azure、PaaS、GitHub、コンテナー、CI/CD、サーバーレス、DevOps、NoSQL、開発環境

スキーマ駆動開発を行っていくと実装とスキーマが乖離してしまい辛いという話をよく聞きます。

スキーマ定義自体はOpenAPIを利用するケースが多いと思いますが、OpenAPIはエコシステムが充実しているが故にツールの組合せだったり、APIを作成する際の開発手順は様々だと思います。
本セッションでは如何にキーマ定義と実装に乖離が発生しない・させない様に開発フローにまで踏み込んで実現させた事例を紹介したいと思います。

トークの狙い

• スキーマ定義をどの様に扱い開発フローに組み込むと良いか？を理解できる
• 利用するツールとそのテクニックに触れることができる

テストコードの書き方について説明する資料等は世の中に充実しつつあります。
一方で具体的にテストコードを書いていく様子を説明、実演する資料というのはまだ数が限られています。

そこで今回はソフトウェアテストの領域でよく題材とされる「マイヤーズの三角形問題」の実装を取り上げ、
素朴な PHP コードからはじまり、テストコードを補いながら、ときにつまづきつつ、解くべき問題を捉えたコードへと洗練させていく過程を実演します。

本セッションで扱うテーマ

• テストファーストなアプローチによるコーディング、リファクタリング
• PHPUnit の基本的な使用法と data provider の活用

本セッションで扱わないテーマ

• テスト戦略やテスト設計について

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

主な対象

• Git 内部で commit がどのように表現されているかを知らないかた
• マージとリベースの差を説明できないかた
• よくあるブランチフロー (e.g., Git Flow、GitHub Flow) から外れたときに操作を迷うかた

話すこと

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

話さないこと

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

目標

• Git の内部表現を理解する
• 複雑な操作を迷うことなくできるようになる
• 操作が複雑にならないようなブランチ運用を選べるようになる

私はこれまでビジネスロジックとドメインロジックをほぼ同じものとして捉え、ドメインモデルにビジネスロジックを実装することで業務知識を表現するような実装を意識していましたが、最近の開発の中でドメインロジックとビジネスロジックはレイヤーの異なる概念なのではないかと考えるようになりました。

この2つのロジックを区別し、ドメインモデルからビジネスロジックを追い出すことで仕様変更に強いドメインモデルを構築することが出来るのではないか、という考えを今回のトークでお話ししたいと考えています。

このトークでは、以下のトピックに関する僕の考えを共有することを目標とします

• ドメインとはそもそも何なのか
• ドメインロジックとはどのようなものなのか
• 何をドメインロジックとして扱うべきで、何を扱わないべきなのか

PHPカンファレンスに参加される方の中には、またプログラミング経験がほとんどなく
これからPHPを勉強しようと考えているという方も多くいらっしゃると思います。

そんな方々へ向けて、Webアプリケーション開発に必須の知識である
データベースやSQLというものを、世界一分かりやすく解説します。

このトークのゴールは、
・データベースという概念をなんとなく理解すること
・簡単なSQLを自力で書けるようになること
です。

私自身が初心者の頃にこういう説明をしてほしかった…と思うような
順序と言葉遣い、例示を用いて、初心者向けに本当に世界一丁寧に（当社調べ）解説します。
初心者の方の「データベースってなんだか難しそう」という印象を吹き飛ばせたらと思います。

※データベース/SQLというものを全く知らない方に基本のキを腑に落としていただくことが目的のトークなので、
分かりやすさを優先して厳密さを多少犠牲にする場面があります。上級者の方はご注意ください。

※このトークはPHPに直接関連しない汎用的なトークとなっています。

この発表ではSREの概念や手法をDevOpsに適用するための具体的なアプローチを紹介し、組織に適したSREの実践方法を探求していきます。

2022年9月29日に発表されたState of DevOps 2022は、ソフトウェアデリバリーパフォーマンスに関する調査結果レポートであり、年に1回Google Cloud内のDevOps Research and Assessment(DORA)チームが公表しています。このレポートでは、ソフトウェアデリバリーパフォーマンスを評価するFour Keysの指標や、Four Keysを改善する上で効果が高いとされるケイパビリティについて、さらにソフトウェアサプライチェーンのセキュリティに関する調査の詳細が記載されています。

DevOpsは、開発（Development）と運用（Operations）の連携を強化し、ソフトウェア開発プロセスの効率化を目指すアプローチです。一方で、SREは開発と運用双方に取り組み、システムの信頼性や効率性を高めるエンジニアリング手法です。DevOpsとSREは相互に補完的な関係にあり、DevOps実践を具体的で効果的に進める指針を提供します。

ただし、SREの概念や手法を盲目的に適用すると、DevOpsの本来の目的や価値が見失われる可能性があります。自社の状況やニーズに合わせてSREの考え方や手法を適切に採用し、DevOps実践を効果的に推進することが重要です。

この発表では、State of DevOps 2022を紹介しつつ、組織に適したSREの実践方法を探求します。具体的には、SRE導入時のコミュニケーション戦略、チーム構成や役割の再定義、適切なツールや技術の選択など、効率や生産性を向上させる具体的なアプローチに焦点を当てます。

Domain Modeling Made Functionalは、静的型付けによる関数型プログラミング言語でのドメインモデリングの手法について説明した書籍です。重要なコンセプトは、業務ドメインを型で表現し、異なる概念には異なる型を作成することです。静的型付けによる関数型プログラミングとは対照的に、PHPは動的型付け言語ですが、業務ドメインを型で表現することは可能です。本講演ではそのメリットについて検証し、具体的なコードを使用して説明します。

ドメインモデリングとは何なのかという点についても、冒頭で説明しますので、馴染みのない方もぜひ参加してください。

昨今のWEBサービスにおいてはインフルエンサーによる広報や、ニュースサイトでの掲載により、突然の大量アクセスが発生することがあります。そのような場合に、サイトがダウンしてしまったり、やむなくレートリミットをかけることがあります。

このような状況において、WEB上に仮想待合室を作ることで、ユーザーを待ち行列に並ばせることで、効率的にリソース制御しながらサービスを提供することができます。

本セッションではngx_mrubyとGoで作成した高速な待合室APIを用いて、かんたんに仮想待合室を実現する方法を紹介します。

技術的なトピックとしては、Nginxの詳細な仕様や、機能に触れながら、Go、Redisを用いて高速なAPIを作る方法について紹介します。