トーク

皆さんは Joe Watkins さんをご存知でしょうか。
PHP コア開発者の一人で、インターネット上ではしばしば krakjoe というニックネームで活動しています。

ご存知ない方は、以下いずれかの PHP 拡張や SAPI のお世話になったことはありますでしょうか。彼はこれらの拡張や SAPI の作者です。
・apcu
・pcov
・phpdbg
・parallel
・pthreads

また彼は PHP Foundation 設立のきっかけとなった一人でもあります。
ここ最近のバージョンの PHP を使っている人は PHP Foundation の雇ったコア開発者の仕事の恩恵を得ており、つまり最近のバージョンの PHP を使うだけでも、間接的にですが krakjoe さんの取り組みから少しばかりの嬉しさを得ている、と言えます。

彼は現在、健康上の理由・経済的理由から危機に瀕しており、gofundme にて寄付を募っています。
https://www.gofundme.com/f/a-big-ask-from-a-big-community

この記事では krakjoe 大先生がまた元気になってよく分からないものを沢山作って、世の中や PHP 界隈を賑やかにできるよう、その偉業をたたえつつ寄付を煽っていきたいと思います。

昨今、開発の中にコードレビューのフローが存在するチームは多いのではないでしょうか。
そして、そういったチームへのジョインや会社への入社したエンジニアは、いつかコードレビュー1日目を迎えることでしょう。

特に、自分自身のスキルに自信がない方は、
・ 他の先輩方のコードレビューをするのは気が引けるな・・・
・ 自分はスキル的にまだまだだから、コードレビューなんてまだできないよ・・・
・ いざレビューしてみてるものの、なんてコメントしたらいいかわからないな。。
・ 自分はLGTM( = Look Good To Meの略。自分的にはOKという意) と思ってLGTMにしたけど、他の人がめっちゃコメントしてる・・・

のようなネガティブな考えに囚われてしまい、気付けばLGTMしかコメントしなくなっていたり、誰かがLGTMとコメントした後に自分もコメント残しておこうみたいなマインドにもなってしまいます。（新卒時代の僕がまさにその状況でした。）

本セッションでは、自分自身が思考錯誤して見つけた「自信を持って最初の1歩を踏み出す方法」を紹介します。

・ これならできそう
・ そんなに難しく考えなくていいんだ
と思っていただけると嬉しいです。

新たにチームにジョインする方が新しい環境にも臆さずコードレビューできるようになったり、
チームに招き入れる側の方が、新人に対して安心させてあげられる状況作りの1つになると幸いです。
新卒1年目の僕のような状況に陥ってしまう方が1人でも少なくなりますように。

対象者：コードレビューの体制のあるチームの全エンジニア（役職問わず）、これから新卒として入社を控えるエンジニア志望の学生の皆様

昨年のカンファレンスで「CodeReviewerが求められること」について発表させていただきました。
その中で、Revieweeが
・気づきや学びが欲しい
・自信を持ちたい
と感じていることが明らかになりました。
またその時の発表では触れませんでしたが、Revieweeは「楽しく働きたい」とも考えていることがわかりました。

しかし、コードレビューにおいて、Reviewerが気づきや学びにつながるようなコメントをしたとしても、伝え方次第でRevieweeから楽しさや自信を奪うことがあります。
逆に言えば、伝え方次第ではRevieweeが自信を持たせたりコードレビュー依頼を活性化させることもできるようになります。
本セッションでは、Revieweeのやる気を促進させつつ、レビューも行っていく方法を紹介し、PHPerエンジニアへのヒアリングも交えながら、心地よいコメントの条件を考察します。
コードレビューの場が楽しくなり、組織が活発になる一助となれば幸いです。

対象者：コードレビューを行う全エンジニア（役職問わず）

設計に詳しくなりたいし、設計力が欲しいし、色々な場面で良い感じな設計を描けるようになりたいですよね。
ソフトウェアづくりに設計は必要です。
何をもって「良い設計ができた」と言いますか？何を目指していますか？
本トークは、その自信と根拠を持つための、「なぜ設計を行うのだっけ」を考えるきっかけとなることを目指します。

考えるべきこと

このトークにおける「設計」に対する態度

• 設計は、何かしらの品質を支えるためにある。その意思決定が具体化されたものと捉える
• 品質には「いま必要なものを、必要なレベルで実現できている」「必要な期間中、継続的に、要求に応え続けられている」の両軸が必要
  • 「将来的にも拡張・変更しやすい」だけでは満足されず、「今の環境や要員でついて行ける」ことも重要
• 自信が持てるような設計にするには、「身の丈にあう」のガイドラインとしての機能を果たす必要がある
  • 「ぼくのかんがえたさいきょうのデザイン」にしない

「良い設計」のために必要なこと

• 設計の「ねらい」をトレードオフとして表現して伝える
  • カーゴカルトよりテイラーメイドを重んじる
  • 何が本質かは自ら選び取り、思考をdumpする
• その設計を「支える」のはメンバーたち
  • 本来のねらいが、実現され続けてこそ意味がある
  • 技量面への教育やツールによる支援が必要

このトークで得られるもの

• ねらい: 「良い設計」を議論するための観点を提供する
• 得られるもの: チームで「自分たちに必要な設計」を見つめ直すきっかけ

話さないこと

• 具体的な設計技法やパターン
• 各論的な品質特性やその計測方法

想定オーディエンス

• 「設計ってなんだろう？」に興味を持ち始めたジュニア
• 駆け出しテックリード

PHPではtry-catchを使った例外処理が一般的ですが、「この例外はどのレイヤーで処理すればいいのか？」や「どの場面で例外を使うべきなのかが曖昧だ…」と感じたことはありませんか？
例外の種類や扱い方が曖昧だと、設計の混乱やコードの保守性低下を招きます。この課題に対するヒントとして、Rustなどの言語で採用されているResult型の考え方があります。

Result型は、失敗が起こり得るということを型として扱い、例外に頼らずエラーを管理する手法です。これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高めることができます。このセッションでは、Result型をPHPに応用する方法を実装例を交えて解説します。

取り上げる内容：

• 例外の種類や扱い方が曖昧になる原因とその解消方法
• Result型の基本的な考え方とPHPでの実装方法
• try-catch採用プロジェクトでも活かせる学び

例外の扱いをもっと明確にし、エラー処理を改善するヒントをお持ち帰りください！

ScalaやErlangなどでアクターモデルは、1973年に発表された並行計算の数学的モデルの一種ですが、
長い間PHPでは実現が難しいとされてきました。
アクターモデルは、並行プログラミングにおける効率的な計算モデルであり、プロセス間の非同期通信も特徴の一つとしています
効率よくそれぞれが並行で動作し、簡単に状態を復元することができたりPHPのOSSなどではあまり見ない特徴を持っています。
PHPでももしそれが実現できたら・・・

しかし時間が経つにつれ、Swooleなどをうまく活用することで実現できそうなことがわかり、
PHPでフルスクラッチで開発したアクターモデルのツールキットがPhluxorです。

Phluxorは、PHPではあまり見られないメッセージングを活用した仕組みを持ち、
各インスタンスが独立して動作し外部から隔離されたアクターを実現しています。
さらに、物理的に異なるサーバ間でのアクター操作が可能な機能を実装しています。
Webフレームワークとは異なり、情報伝達設計に特化した仕組みを持ち、
PHPでは他に類を見ないヒエラルキー構造や自動復旧機能でアクターシステムをサポートしています。

これらは一体どのように実装して、どんな仕組みで動いているのか？
アクターモデルのツールキットの作り方について、詳しくお話します！乾杯！

本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、その仕様を様相論理の一種である時相論理を用いて厳密に記述し解析する技術について解説します。

みなさんは「ボタンをクリックすると機能 X が正しく動く」といったテストケースを目にしたことはありませんか？ お気づきの通り、このテストケースはあまり良くない例です。では、何が良くないのでしょう？ 一番の問題は、ここで言う「正しく」がどのような状態を指すのか、言い換えればこのテストケースが何を保証しているのか、が全く具体的ではない点です。

我々が何らかの方法でシステムの仕様を保証しようと考えた場合、テスト設計であるとか、あるいは自動化ツールのような、仕様を「テストする」ための方法論に目が行きがちです。しかしその前段階として、仕様を「記述する」というステップがあることは忘れてはいけません。入力に対して出力がある、いわゆる単体テストであればそれほど困らないかもしれません。しかし、例えば複数のサーバが協調して動く「分散システムの正しさ」だったら？ さらに、複数のサーバのうち一部が高負荷となってレスポンスを返したり返さなかったりする状況だったとしたら、全体の動作の「正しさ」にはどのような影響があるでしょうか？

自然言語による仕様の表現は、我々が普段なんとなくイメージしている以上の曖昧性を含みます。そしてその曖昧性を排してシステムに対するより良い理解と洞察を得るために、厳密な「共通言語」を定義したいという動機は、かなり旧い時代から現在に至るまで、一貫して計算機科学の興味の対象であり続けています。

本セッションでは、このような動機に応える様相論理とモデル検査について、可能な限り誤魔化さずに解説したいと思います。普段、分散システムを触っていて、何となく計算機科学の基礎が気になってきたぐらいの方にお薦めです。

私たちのチームはPHPとRDBMSを用いた受託開発を中心に開発をしてきました
チーム文化として、クライアントニーズに迅速に応えながら、時代の変化への柔軟性を持って開発を進めることを大切にし、
常に新しい技術や手法を積極的に受け入れることを得意としていました

そんな中、話者である私自身は「サーバーレス」を得意としていましたが、そのスキルを自分ひとりの武器として振るうのではなく、
チーム全体の文化や価値観に溶け込ませ、組織的な生産性・開発価値の向上につなげるにはどうすればよいのか、日々考え続けてきました

そこで目を向けたのが「Platform Engineering」の考え方です
Platform Engineeringは、開発者がインフラやツール選定に悩まず、本質的なビジネスロジックの創造に集中できるようなプラットフォームやサービスを用意し、組織内のエンジニアリングプロセスを最適化するアプローチです
サーバーレスが得意な「私自身」から離れ、あくまで「チームとしての開発価値向上」をゴールに据え、共通のプラットフォーム基盤としてサーバーレス技術を位置づけることで、メンバー全体がその恩恵を享受できる形が見え始めました
その結果サーバーレスDBとして価値のあるTiDBもスムーズに導入出来てコストメリットを享受しています

従来のLAMP系スタックを踏襲しながらもサーバーレス環境をチームにシームレスに組み込み、Platform Engineeringという視点で共通基盤として活用し続ける価値について話します
個々人がスキルやツールに依存するのではなく、チームとして得られる付加価値、そしてエンジニアリング体験の向上についてお話できれば幸いです

• 想定聴講者
  • サーバーレスをチームに浸透させたい人
  • Platform Engineeringが何か知りたい人

話者は普段PHPをBrefというOSSを利用してAWSにデプロイしています
この方法は非常に有用で、サーバーレス環境にPHPアプリケーションを載せるための標準手法として紹介してきましたが
一方で第三者が構築しているOSSに対する不安を感じる方もいるはずです

既存コードをどのようにサーバーレス化すれば良いのか、またカスタムな環境構築がどこまで信頼できるのかといった懸念があるかもしれません
特に既にLaravelやSymphonyなどのフレームワークを用いて開発されたアプリケーションを、
既存のワークフローを大きく変えずにクラウドネイティブな環境へと移行したい場合、そうした課題はより顕在化します

そこで今回はAWSが構築を行っているAWS Lambda Web Adapterを利用します
PHPerはサーバーレスの利点を享受しつつ、従来のWebアプリケーションをシームレスに移行する手法を身につける事が出来ます
さらにLaravelに適用する際には、既存のルーティングやミドルウェア、コントローラ群をそのまま活用し、AWS Lambda上でリクエスト-レスポンスサイクルを再現することが可能です
最終的に話者がいつも利用しているBrefとの比較を行うとで、選択肢を提示します

AWS Lambdaの可能性を広げるWeb Adapterを利用したサーバーレスPHPの普及に助力出来れば幸いです

• お話すること

  • AWS Lambda Web Adapterについて
  • Brefについて（簡易版）

• 想定聴講者

  • サーバーレスPHPに興味がある方
  • AWSを利用してPHPを利用している方

• お話しないこと

  • Laravelのデプロイ手順（GitHubにコードを公開します）

PHPユーザーであれば、日々APIのパフォーマンスと向き合うことがあるかと思います。
中でもGolden Signalと呼ばれる4つの指標（レイテンシー、トラフィック、エラー、サチュレーション）は、システムが「健全」であると判断する基準となるものです。
本セッションではGolden Signalを中心に、Performance Insightや周辺のメトリクス、モニタリングツールの操作、問題の特定や推論を可能にする為のTipsについて話します。

• Golden Signalについて
• 価値のあるログとは何か、どこにあるのか
• Performance Issueをどう特定するか
• ケーススタディ、 ex: このアプリケーションは20時台にCPU Usageが跳ね上がるのってなぜ？
• ログとメトリクスからユーザー特性を推論する、問題発生箇所のコードを探す技術

EC2のセキュリティがガバガバに穴が空いている状態の皆さん息してますかー？
すみません。いきなり煽りから入ってしまいました。
最近、サーバー構築作業をしている中でセキュリティ担保の方法を学ぶことがあったので、この場を借りて皆さんに共有させて頂ければ幸いです。
EC2へSSH接続を行い、サーバーでの作業を行っているバックエンド側の人の幸せにつながってくれたら嬉しいです〜
EC2のSSH鍵の扱いどうしていますか？
複数人でプロジェクトを組んでいる場合、サーバーで作業をする人が複数出てくると思います。
そうなってくると以下の作業を 作業者の人数分 × サーバーの台数分 実施しなければいけなくなります。
この時点で億劫ですね。
また、上記の作業に加えて 鍵の定期的なローテーション、チームの入退場が発生した時のユーザー管理が発生してしまいます。
死ぬほど面倒くさい！
更にセキュリティに興味が無いメンバーが存在すると、鍵のローテーションはやらなくていいじゃんとか抜かすんですよ。。あー、面倒くさい。
その問題、ECS Instance Connect で解決しましょう
EC2 Insatnce Conncetを使うと僕達ユーザーが鍵の管理をする必要がなくなるので、運用の手間をかなり減らすことができます。
（サーバー運用やったことにしか伝わらないと思いますが、管理するものを減らすという事は運用において絶大に効果があるのです！！
EC2 Instance Connect を使う際には、セキュリティグループで SSHのポート 22 を開放して置く必要があります。
22番ポートを開けるのは多少なりとも気が引けますよね〜
最低限のセキュリティ担保として、 EC2 が所属する Region のみからアクセスできるようにIP指定をすることができます。
運用負荷が下がると幸せになれます。
幸せになろう。

近年、大規模言語モデル（LLM）が急速に進化し、ナレッジグラフとの連携が重要性を増しています。LLMは膨大なデータを処理しながらも、特定分野の知識を正確かつ構造化して扱うには限界があります。ここで注目されるのがナレッジグラフ。データを構造化し、関連性を明確にすることで、LLMと補完し合いながら、より高度なアプリケーションが実現可能になります。では、PHPでナレッジグラフを扱うにはどうすれば良いのでしょうか？

本セッションでは、PHPを使ってナレッジグラフを活用する方法を解説します。ナレッジグラフとは何か、その基礎概念から始め、具体的にPHPでどのように操作・活用するかを探ります。まず、ナレッジグラフに関連するRDF、OWL、SPARQLなどを簡単に説明し、PHPでそれらを扱うためのライブラリ（例: EasyRdfやRdfPhp) を紹介します。その後、SPARQLクエリを用いてナレッジグラフからデータを取得・操作する方法を具体例とともに解説します。

さらに、PHPで構築した既存のWebアプリケーションにナレッジグラフを組み込むためのアーキテクチャ設計や、LLMとの統合方法についても議論します。たとえば、LaravelやSymfonyのようなフレームワークを利用して、ナレッジグラフを効率的にクエリ・操作し、APIを通じて他のシステムやLLMと連携するパターンを具体例で説明します。

最後に、ナレッジグラフとLLMの組み合わせによる具体的なユースケース（FAQシステムやレコメンデーションエンジンなど）を示し、ナレッジグラフの可能性を最大限に活用するための道筋を提案します。このセッションは、ナレッジグラフという新たな分野に挑戦するための第一歩となる内容です。LLM時代の今だからこそ必要とされる技術に触れ、一緒に未来のWebアプリケーションの可能性を広げてみませんか？

何かを作ることって楽しいですよね。プログラミングを始めたキッカケは、それぞれ違うでしょうけれど、「動くもの」ができたときに得る快感は、およそ共感できるでしょう。
ところで、日々のお仕事に忙殺されて、その得られる快感が薄くなっていませんか？業務ではさまざまな制約があることでしょう。

そんなあなたに、自由な開発をする後押しをしたい。そして自由を糧にしてあなたのWayを作って欲しいのです。

想定ターゲット

• お仕事でしか開発をしない人
• 日々のお仕事に忙殺されてる人
• 個人開発ってなんだろう、どうすればいいんだろう、という人

話さないこと

技術的な詳細には触れませんが、トーク後に質問をいただければ大歓迎です！嬉！

みなさん、PHPのテストを書くときに「他のクラスや依存関係のせいでテストが難しいな…」と思ったことはありませんか？
そんなときに役立つのが、PHPのモックフレームワーク Mockery です！

Mockeryを使えば、依存するクラスやインターフェースの動作をモックして、テストをもっとシンプルに、効率的に進められます。このトークでは、Mockeryの基本的な使い方から実際の業務で役立つテストケースまで、具体例を交えて解説します。

取り上げる予定の内容はこちら！

• モックを使ったメソッド呼び出しの検証方法
• 高度な引数の比較を使った柔軟なテスト
• 実務でのテストケースの実例紹介

Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

「アジャイルなんてオシャレな自社開発企業だけの特権でしょ？」

そう思っていた時期が自分にもありました。

その後、自組織へのアジャイル導入を主導し、実践を重ねた今となっては、アジャイルはチーム単位や、ひとりからでも始められる！と確信しています。

このセッションでは、アジャイルの魅力、そして「はじめの一歩の踏み出し方」についてお話しします。

こんな人に聞いて欲しい

• アジャイルのことは知っているけど、まだ実践できていない人
• 受託開発だからアジャイルは無理、とあきらめてしまっている人

お話しないこと

スクラムや XP などについての細かいお話はしません。

「言語設定」という言葉は普段の開発でよく耳にするものの、これまで深く考えたことがありませんでした。日本語や英語などの言語設定がどのように決められ、どのように利用されているのかを理解することで、国際化対応やユーザー体験の向上にどのように活かせるのか。本セッションでは、自身が初めて真剣に言語設定の仕組みと設計に向き合った経験をもとに、言語設定の基本から設計に至るまでの学びを共有します。

まず、OS（Linux、Windows、macOS）やブラウザがどのように言語設定を決定し、利用しているのかを解説します。その後、これらの情報がPHPアプリケーションに渡されたときにどのように利用されるのか解説します。

さらに、実際のアプリケーション設計において、どのように言語の対応を処理すべきかを検討します。具体的には、Accept-Languageヘッダーを基に動的に言語を切り替えるミドルウェアの設計や、クッキーやセッションを利用したユーザー固有の言語設定の永続化方法についても触れます。また、多言語対応におけるドメインの利用（例: example.jpとexample.com）やURLパス（例: /enや/ja）を使った切り替えの実装パターンについても議論します。

このセッションは、言語設定について初めて真剣に考えるエンジニアに向けた内容です。言語設定の仕組みを理解し、設計に落とし込むまでのプロセスを一緒に探ることで、これからの国際化対応に必要な知識と視点を得られるはずです。一緒に、言語の設計に一歩踏み込み、真剣に考えて見ませんか？

Svelteって名前、聞いたことありますか？
SvelteはReactやVue、Angularなどと同じ、リアクティビティをもったWebアプリケーションライブラリです。
Reactに対してNext.jsがあるように、SvelteにもフレームワークとしてSvelteKitがあります。

このLTではPHPerの皆さんにだからこそ伝えたい、
SvelteKitの魅力やおすすめポイントを5分でギュギュっとお伝えします！

このLTがおすすめの人

• SvelteやSvelteKitに興味がある人
• よりよいUIフレームワークを探し求めている人
• 状態管理でつらい思いをしたことがある人

このLTで得られること

• SvelteやSvelteKitの概要
• SvelteKitの基本
• 「早速触ってみたいぞ！」という気持ち

現在担当しているプロダクト（建設DX領域のバーティカルSaaS）で多言語対応プロジェクトに参画した際の学びを共有したいと思います。

背景

プロダクトは10年以上運用しているものでリポジトリのファイル数は3千を超えます。
図面を見たり写真を撮ったりという標準的な機能のほか、外部機器と連携して検査をするというオプショナルな機能をあわせると30以上機能があります。
標準的な機能は多言語対応が完了していましたが、オプショナルな機能をこれから多言語対応していくというタイミングでした。

本トークで話すこと

• サービスを多言語対応をするうえでそもそも起こりうる、日本語と英語で文字数や記号による違いなど、表現について。
• 長く運用しているプロダクトの複雑な仕様を理解しながら進める多言語対応。
• 考慮不足によって発生したバグからの学び。

発表者について

プログラミング歴約2年半で転職して入社した会社での話し。
入社から数カ月後に参画したプロジェクトが多言語対応でした。

対象者

これから多言語対応をする予定の方、今多言語対応している方。
多言語対応で起きる問題に興味がある方。

メンドウ？タイクツ？書き方がわからない？？

決めたことを文書にまとめない理由はたくさんあるかと思います。
一時的には文書を書かない方が、仕事のスピードは早いかもしれませんが、長期的に見たときにはどうでしょうか？

この発表では一時の時間短縮のためにドキュメント化を怠った結果、どのような末路が待っているかを具体例を交えて紹介します。

WebAPIを介して他のサービスと連携して、新しいサービスを作ることってありますよね。Googleアカウントでログインする機能の実装はまさにその一例です。
しかし、OpenAPI Specification等のフォーマットで各APIの仕様が公開されていたとしても、それらをどう組み合わせれば目的のユースケースを実現できるかは自明ではありません。ドキュメントを読み込み試行錯誤する中で、API間の依存関係やシーケンスを解き明かした経験がある方も多いのではないでしょうか。
この問題を解決するために、OpenAPI Initiativeでは「Arazzo Specification」という新しいAPIワークフロー定義が検討されています。2024年5月には、この仕様のv1.0.0が公開されました。本ポスターでは、そんな「Arazzo Specification」の詳細について解説します。

【予定している内容】

• Arazzo Specificationの概要
• 想定されるユースケース
• Arazzo Specificationの詳細内容
• Arazzoを用いたAPIワークフローの記述例