弊社M&Aクラウドでは会社や事業を売却したいユーザーと、その会社や事業を買いたいというユーザーがマッチングするプラットフォームを提供しています。
そのシステムでは、マッチングした場合のみに特定の情報が閲覧開示されます。
しかし既存の実装ではほとんどUIに近い層で情報をコントロールしていたためヒヤリとする実装となっていました。
このトークではその実装を堅牢な仕組みに作り直す事例を紹介したいと思います。
PHPStanも活用し、コーディングの時点で開発者が迷うことなくオブジェクトを利用できる設計を紹介します。
※本トークでは実際のコードではなく参考コードで紹介します。

スクリプトがサーバ全体のメモリを食いつぶさないようにするための安全装置として、PHP にはプロセスごとのメモリ消費を memory_limit という設定値で制限できる仕組みがあり、制限を超えた時には "Allowed memory size of N bytes exhausted" というメッセージが出ます。

世には PHP 製の OSS が星の数ほどあり、GitHub を "Allowed memory size of" で検索すれば、そういった PHP 製の OSS プロジェクトでメモリ問題に悩まされているものを見つけられます。

それらを適当に拾い食いして辻斬りのように解決していく活動を通じ、PHPのメモリ問題の基本的な解決方法を紹介していきます。PHP の基本的なメモリ管理機構やメモリ消費量の計測方法、参照関係のたどり方、メモリを食いがちな部分といった話もあわせて解説します。

過去、PHPerKaigi 2022のパンフレット記事に「日本語で開発してラクしよう」を掲載していただきました。
記事では、「英語について考える時間がもったいないよね」という主旨でした。
日本語でコーディングすることで、設計・実装をよりよくしていくスピードを上げようというアプローチです。
想定以上に好評なフィードバックをいただきましたが、皆さん現場で日本語コーディング使ってますか？
かくいうぼくは使う機会が無いんですが。

今回のトークでは、実務的に日本語で開発作業がどこまでできるのか試した結果を共有します。
ファイル名は？RDBは？ORマッパーは？Gitは？など、詰まりそうなところはどうなるのか。

日本語のほうが、英語よりはいくらか得意な人は多いと思います。
なら、日本語コーディングが認知される世界のがラクですよね…？

マネーフォワードでは、各サービスが1つの大きなDBに依存している状態を抜け出し、各サービスごとに別々のDBを持つように再構築していくプロジェクト（桃園脱却プロジェクト）が進行しています。
桃園脱却プロジェクトにおいて、私が担当した業務の1つに、Money Forward クラウド経費の会計データ参照の分離がありました。この対応では、サービスの停止やビッグバンリリースをすることなく、共通DBへの依存を切り離せました。
本登壇では、この分離の進め方や採用した技術・手法についてお話します。

話す内容
・桃園脱却とは？
・featureフラグを活用したリリース
・Rubyを使っているMoney Forward クラウド経費上でgRPCを使用した会計データの参照手法
・リモート環境下での、複数人の開発者で分離を進めるためのissueの切り方やコミュニケーション
・コードを書かない選択肢

アジャイルのプラクティスにプランニングポーカーというものがあります。
タスクのストーリーポイントをみんなで見積り、今までのスプリント履歴からベロシティを計算し、今回のスプリントで行う作業を決める。スプリントが終わるときれいにタスクが完了し、デリバリー出来ている。。。本当にそんなにうまく運用できていますか？？
でも、不確実性コーンというものがあって、初期のソフトウェア見積りは、4倍から1/4倍まで工数がブレてしまって信用度が低い。。。本当でしょうか？？
実はよく知られていない不確実性コーンの歴史を紐解き、現代の統計データからどれほどソフトウェア見積りが可能になっているのか？
古典的ソフトウェア見積りを再考した調査結果を発表いたします。

このトークについて

皆さんはPHPのDockerfileを書かれておりますでしょうか。プロジェクトに一人、Dockerfile職人がいらっしゃいませんか？PHPのDockerfileはいろいろな書き方があり、秘伝のタレになっていませんか？秘伝のタレを脱して、自信を持ってかけるようになりたくないですか？

話すこと

• Dockerfileの基本的なコマンドのおさらい
• PHP公式Dockerfile(8.3, Apache系)は何をしていて、何をしていないのか
• プロジェクトにおいて考慮すべき項目について
• 拡張モジュールのインストール方法

対象者

• PHPのDockerfileのコピペを脱出したい人
• 意図してDockerfileをかけるようになりたい人

PHPはWebアプリケーション開発に特化したプログラミング言語です。Webアプリケーション開発においては非常に柔軟で強力ですが、リレーショナルデータベース(RDBMS)を作ることには全く向いていません。

全く向いてないにも関わらず、なぜPHPでRDBMSを作るのか？大きく分けて２つの理由があります。一つは車輪の再開発によりRDBMSの仕組みを深く理解できること、そしてもう一つはロマンです。例えば、WordpressがピュアにPHPだけで動作したら、なんだかワクワクしますよね！

本トークで話す内容

• PHPで動くデータベースのデモ
• RDBMSを作るために必要な構造・設計の基礎知識
• PHPだから理解できるデータベースのコア実装
• ステップ実行でクエリが処理される様子を観察

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試しています。
まだまだ実験途上の試みではありますが、私がどういう不便を解消したいと考えているのか、その不便を解消するために使っているツールのアップデートの履歴、PHPカンファレンス福岡当日までの成果を発表したいと思います。

検索機能は現代の情報検索の基礎で, 多くのWebサービスに搭載されています.
検索機能の実装者としてElasticsearchなどの全文検索エンジンを使ったことのある方も多いと思われます.

一方で, その内部実装を知っている方は多くないのではないでしょうか？
本セッションは検索エンジンをフルスクラッチ実装しながら解説するパワフルなコンテンツです！

基本的な検索エンジンの実装のトピックとして、以下を想定しています

• 転置INDEXの実装
• AND / OR検索の実装
• 簡単な結果ソート手法(スコアリング)の概要と実装
• ElasticSearchなど実用的な全文検索システムにおけるスコアリングの概要実装

このセッションの対象者:

• 検索の仕組みに興味がある方
• 全文検索エンジンを使ったことがあるが内部の仕組みはよくわからないという方

私は学生時代から個人開発をはじめ、社会人エンジニアとなった今でも個人でWebサービスを開発・運用し続けています。

その中で一際思い入れが深いサービスが「National Economy Online」です。当時はコロナ禍がちょうど始まった頃で、物理的な交流や遊びができなくなってしまい退屈な生活を送っていました。ボードゲームが趣味の友人とリモートでも楽しく過ごすため、「ナショナルエコノミー」というボードゲームがオンラインで遊べるものを開発しました。今では友人だけでなく多くのユーザーに何千回と遊んでもらっています。

個人開発を通して習得できる技術や審美眼、また実際にPHPでボードゲームが遊べるWebサービスを作る際のテクニックについてご紹介します。

cf.) https://speakerdeck.com/arthur1/hatena-engineer-seminar-number-28

技術選定で「何を選べばいいかわからない」「何が適切なのかわからない」など悩む方も多いのではないでしょうか。私自身もたくさん悩んできました。
一介のエンジニアとして開発に携わった経験，エンジニアリングマネージャーやテックリード，CTO 経験など多くの屍を超えて辿り着いた結論は「答えがない」です。それは，事業のフェーズ，ビジネスモデル，既存プロダクトの状態や既存のエンジニア組織の性格など技術選定において必要なパラメータが多岐に渡るためです。
それでも，技術選定を進めなければプロダクト開発はもちろんのこと，圧倒的な事業への成長に貢献できません。
では，ハードシングスを必要とするようなシーンの技術選定は，どのように行っていけばよいのでしょうか。
本トークでは，どういう視点で技術選定を行えばよいのかを皮切りに，様々な事業の状況を仮定しながら最適な技術選定に近づけるためのノウハウについてお話します。

システム運用/開発において、取り扱いが難しいもののうちのひとつとして、「過去」や「未来」があると思います。

たとえば、「履歴データ」と呼ばれるようなものの取り扱い、あるいは「予約された時間になんらかの処理をしたい」という要件に対しては、「システムを作ったはいいけど運用していく中で取り扱いに困ってしまった」という経験はないでしょうか？

「現在の状態」だけを相手にすればいい場合は非常にシンプルで済むシステムも、過去や未来を取り扱おうと思った途端に複雑性が上がるというのは、私の実感とも一致します。

本セッションでは、「過去」「未来」を取り扱うにあたって、「そもそも何が難しいのか」と、その難しさに対する処方箋、およびそこから見えてくる勘所と考え方を考えてみたいと思います。

アプリケーション開発で、単に要求に答えるための開発をするだけでなく、
データ分析に関する知識や幅広いドメイン知識が必要となる機会も多いのではないでしょうか？
このセッションではドメインイベントの理解がアプリケーション開発において中心的な役割を果たすかを探求します。

この概念を踏まえることで、分析の段階から境界づけられたコンテキストを明確にし、
如何にデータ分析設計やシステムアーキテクチャの進化に寄与するかを解説します。

このセッションでドメインイベントを中心とした考え方を得ることで、
柔軟なシステム設計・ドメイン理解のための洞察力を養い、
ビジネス要件の迅速な変更に対応し、継続的な成長と進化を実現するアプリケーションの開発が可能になるかもしれません。
発表では具体的な事例とともに、ドメインイベント中心の技術がもたらす可能性についても深く掘り下げていきます。

配列は、柔軟なデータ構造で便利である一方、使い方を間違えるとしばしば不具合の原因となります。

配列は==や===を使って比較することができますが、例えば ['a' => 'aaa', 'b' => 'bbb'] と ['b' => 'bbb', 'a' => 'aaa'] の比較では、 == ではtrueに、===ではfalseになります。

このトークでは、PHPが配列の等しさをどう扱っているのかをphp-srcを読み解きながら深掘りしていきます。

わたしは、かつてPHPカンファレンスやRubyKaigiなどで技術発表を行ってきましたが、近年ではこのカンファレンスのスポンサーも務めているピクシブという事業会社全体の制度作りの一翼を担ってきました。
ジョブチェンジをしたわけではなく、ソフトウェアエンジニア及びその分野のマネジメントの経験から設計スキルを武器として活用しています。

このセッションでは、わたしが実際に行った取り組みをもとに、それらの背景、思考プロセスを紹介し、今後のキャリア選択のフロンティアとしての発展像を示します。

なお取り上げる事例は以下を想定しています。
https://inside.pixiv.blog/2022/10/31/140000
https://inside.pixiv.blog/2023/02/22/115500
https://inside.pixiv.blog/2023/11/28/130000

Webサービスの開発運用においてセキュリティは一つの重要なテーマです。CSP(Content Security Policy)はwebの標準仕様であり、クロスサイトスクリプティングやデータインジェクション攻撃などのような特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。しかし実際にこれをサービスに導入し運用をしているという事例をまだ多くは聞きません。

発表者が所属する組織においてもセキュリティ対策の一環でCSPを導入しプロダクト運用に組み込んでいます。どういった意図で導入し何が発生してそこからどういったことを学んだか、一つの事例として発表を通じて共有したいと思います。

[想定オーディエンス]

• これからCSPについて知りたいと思った方
• CSPの導入を検討しているおり、導入事例に興味関心がある方
• Webサービスの他社運用事例一般に興味関心がある方

どんなに綺麗な仕様書を書いても、コードから離れては生きられない（メンテナンスされず陳腐化して活用されない）。
そんな思いからスキーマ駆動開発でのコードとスキーマの乖離をさせないという理想を追い求めて辿り着いた開発プロセスを紹介したいと思います。
スキーマ駆動開発での悩みポイントにフォーカスし、なぜ今回のプロセスを採用しようと判断したのか？
また段階的にプロセス見直し最終的には他プロジェクトにも適用可能なcomposer化を目指したのか？についてお話します。

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

みなさんは GraphQL を利用したことはありますか?
GraphQL の利点として、クライアントが必要とするデータを API に 過不足なく伝達して取得できる という、 従来の REST API では実現が難しい機能 を実現できます。

GraphQL は さまざまな言語やフレームワークでサポート されており、 PHP でも利用できます。
さらに、 Laravel では、簡易的な API サーバーであれば容易に実装が可能です。

本トークでは、 GraphQL の基礎と、 Laravel で GraphQL サーバーを実装する方法を紹介します。
また、実際に Laravel で GraphQL を利用した事例についてもお話しします。

一緒に GraphQL の基礎を学んで、 GraphQL の便利さを体感してみませんか?

サービスが成長すると愚直にコードを書いているだけではパフォーマンスの問題にぶつかります。
参照はcacheやリードレプリカを増やすことで対応することができますが、書き込みが多い場合はそういうわけには行きません。

PHPの鬼門ともいえる、書き込み処理を如何に改善していくか。
そのために必要な基本的な考え方や実際のアプローチについて説明します。

話をすること

• イベントアーキテクチャとイベントストリーミング
• 書き込みをスケールさせるために必要な勘所
• 運用するときに陥る落とし罠
• 現場で必要な考え方