株式会社プログリットではLaravelをメインで利用し、さまざまな英語学習のアプリを開発しています。

近年、生成AIの登場によりこれまでは開発困難であったさまざまな機能が実現できるようになりました。
英語学習においては、ユーザに最適化されたフィードバックや、インタラクティブに変化するテーマやコンテンツなどを扱えるようになりました。
それによって、より効率的な学習体験を提供することが可能になり、新しい機能のアイデアがどんどんと生まれていきました。

しかしながら商用利用に当たっては、PHPの公式のSDKなかったりその他ライブラリが他の言語と比較して少ないなどいくつかの障壁がありました。
そこで我々は、これまでで開発した既存のリソースを活かしつつ、Pythonで書かれたAI関連の処理組み合わせるハイブリットなシステムを設計しました。

• AWS Lambda を利用したAIチャットボット開発と技術検証
• AWS Step Functions による添削システムとプロダクトへの組み込み
• FastAPI 統合で実現するAIネイティブな英会話アプリ開発

これまで開発した機能やプロジェクトの一部実例を踏まえしつつ、いかに生成AIを活用したアプリ開発を実現してきたのかご紹介させていただきたいと思います。

想定聴講者
・生成AIを活用した機能開発を行いたい
・PHPで構築された既存システムがある
・既存システムを活用しながら開発を行いたい

覚えていますか？プログラムを読めるようになってきたある時、突然出会った彼らのことを。
先輩エンジニアの書いた三項演算子やnull合体演算子、高階関数にクロージャ。
理解不能。何を表し何の為に何をしているのか。
同時に思ったはず、「なんかカッコいい‥」と。

そして、いつかは自分もこんなプログラムを書いてみたいと言う憧れに近い感情を感じたはず。
エンジニアなら誰しもが通った、なんか小難しいけどカッコいいシンタックスへの憧れを
「PHPシンタックスコレクション〜ペチコレ〜」厨二病が好きそうな小難しいシンタックス編
と称して紹介していきます。
独断と偏見で選んだ「なんかカッコいいシンタックス」達が華やかにランウェイを彩ります。

Rectorというリファクタリングツールがあります。
このRectorではカスタムルールを作成することで、任意の条件でリファクタリングを行うことが可能になります。

このカスタムルール上でPHPStanの機能を利用したり、php-parserを用いることでRectorの能力を最大限に活用してリファクタリングすることができます。
そしてPHPStanのbaselineをゴシゴシ削減することにも繋がります。

エディタ上やCLI、CI等でしか普段使わないPHPStanをコード上で利用するという不思議な体験をお届けします。

「PHPStanをCIとエディタでしか使わないなんて勿体ない！」と発言する人間を量産できるように頑張ってトークします。

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則には、「英語の文法」にヒントが隠されているかも...?
英語文法の基本ルールに着目することで、設計原則を詳しく知らなくても、シンプルで明確な設計を行うための手がかりを得られるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• ソフトウェア設計に詳しくはないが興味を持っている方
• 設計の原理や手法が多くてなかなか手を出せずにいる方

組織によっては、フロントエンドの専門エンジニアがいないケースも多く、バックエンドエンジニアがフロントエンドを兼任することがあるかと思います。そのような組織においては、フロントエンド領域における技術的課題が溜まりがちではないでしょうか。

私が所属していたチームでもそのような課題を抱えていました。特にフロントエンドのテストが非常に乏しく、ちょっとした変更のたびにマニュアルでのテストが必要な状態でした。

このトークでは、バックエンドを主担当としてきた私が、フロントエンドテストの拡充するために行った取り組みを紹介したいと思います。主に以下のお話を考えています。

• フロントエンドテストのキャッチアップをどのように行ったか。
• リファクタリングを容易にするために、関数単位のユニットテストよりも、コンポーネント単位のユニットテストを重視。
• フィーチャー開発の手を止めずに実現した、朝の30分活動でのテストコード追加。
• チームメンバーに浸透させるために行ったハンズオンや、AIコードエディタ(Cursor)によるテストコード生成。

このトークを通じて、バックエンドエンジニアでもフロントエンドテストを充実させることが可能であることを示し、参加者の組織におけるテスト拡充の一助となれば嬉しいです。

今年の3月に実施されたPHPerkaigi2024でコードゴルフ大会に参加し、とても楽しかったため、「自分の会社でも実施したい！」と思い立ち、実際に開催しました。結果は大成功で、とても楽しい時間を過ごせたので、その時の話をします。

コードゴルフの内容は、「FizzBuzz」問題や、1時間で解ける程度のの難易度のものを採用しました。言語はPHPを使用しました。

具体的には以下のような内容を話す予定です。

•コードゴルフ大会を実施するにあたって、コードゴルフができるWEBアプリをどのように作成したか
•コードゴルフ大会の雰囲気や参加者からの評判
•参加者たちの感想
•コードゴルフ大会を定期的に開催していることでの社内への影響
•コードゴルフ大会を開催した私自身の感想

何らかの技術の理解を深めるのに最も適した方法は、その技術のサブセットを自分で実装することです。
PHP、ひいてはプログラミング言語というものを理解するために、PHP で PHP のサブセットを実装しましょう。
プログラミング言語処理系における「セルフホスト」とは、その処理系のソースコードをその処理系自身が処理できることを指します。つまり、今回作るPHP処理系の上でそのPHP処理系を動かすことを目指します。

話すこと

PHP で書く PHP 処理系（のサブセット）の作り方

• 字句解析
• 構文解析
• 実行 (今回の実装では AST を直接実行します)

必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

実際の PHP 処理系 (php-src) の実装方法に近づけることは目指していません。説明のしやすさや実装の容易さを考慮し、適宜アプローチは変更します。PHP 処理系へのコントリビュート等を目標としたものではありません。

モジュラーモノリスは近年、マイクロサービスの代替として注目を集めています。このトークでは前半で設計の話を、後半で開発の話をします。

私が所属するBASE社では10年以上モノリシックなサービスでの開発が続いていましたが、デプロイ時間の増加や依存関係の複雑さにより機能提供のスピードに課題が出てきました。その課題を解決するためにモジュラーモノリスの新システムへの移行が始まって丸4年が経過しました。

本トークでは、モジュラーモノリスの基本的な設計概念から、その実現する方法論、また実践例について解説します。モジュールはコアドメインとサブドメインの考え方に基づいて区切られており、各モジュールの中ではアプリケーション層とドメイン層が分かれており、UnitOfWork での永続化管理やドメインイベントを用いた実装が可能になっています。

また、モジュラーモノリスを選択した際の利点とトレードオフについても議論します。具体的には、テストのしやすさ、デプロイの単純化、チーム間のコミュニケーションの向上など、エンジニアリング全体に与える影響を掘り下げます。メリットは多くありますが、それでも生じる課題についても触れていきます。

このトークを通じて、モジュラーモノリスというアーキテクチャの現実的な価値を理解し、チームやプロジェクトの規模に適したアプローチを選ぶための指針を得られれば幸いです。

概要

筆者は2024年9月にECサイト構築用のOSS開発者から、企業向けバックオフィスのSaas開発会社に転職しました。
両者ともにPHPをメインの開発言語として置いていたのですが、「開発へのアプローチの仕方」や「PHPであること」の
意味合いはかなり異なったものでした。

例えば、以下の例

• 可読性を重視するのか、パフォーマンスを重視するのか
• 開発スピードを重視するのか、品質担保を重視するのか
• セキュリティをコードで担保するのか、ミドルウェアに任せるのか
  等々・・・

ソフトウェア開発における「あるある」でもあり、この問題と対峙している人は多いのではないかと思います。
OSS開発とWeb系Saasという2つの視点から、PHP開発における価値のあり方についてお話します。
筆者が実際に直面した課題もできる範囲でお話します。

対象者

• 開発におけるQCDSで優先順位どうするか日々悩んでる人
• 2つの宗教に挟まれた時に「どこに着地点を持っていくか」で悩んでいる人
• OSS開発のノウハウとWeb系Saas開発のノウハウを単純に比べて聞きたい方

得られるもの

• PHPのWeb開発における一つの価値基準
• 立場が変われば同じPHPでも取り組む姿勢が変わるという視点
• ソースコードとインフラの役割分担の考え方

運用中のPHPアプリケーションに後からCDNを導入する際、特に歴史的な経緯により、複数のカスタムドメインを使用している場合、移行作業には慎重な計画が必要です。このセッションでは、AWSのCloudFrontを例に、複数ドメインを持つ既存アプリケーションにCDNを導入する際のベストプラクティスを解説します。

まず、複数ドメインで運用している環境で効果的なCDN導入が難しい理由を整理します。たとえば、静的リソースのURLがハードコーディングされている場合や、既存のキャッシュ制御ヘッダーが正しく設定されていない場合、移行中にアクセス障害やパフォーマンス劣化を引き起こすリスクがあります。これらの課題を特定し、解決するための準備ステップを紹介します。

次に、CloudFrontを活用して既存のアプリケーションにCDNを導入するプロセスを具体的に解説します。CloudFrontのディストリビューション作成方法、複数ドメインを扱うためのカスタムオリジン設定、HTTPS対応のためのACM（AWS Certificate Manager）の証明書設定について実例を交えて説明します

さらに、移行中の段階的なテスト方法についても触れます。たとえば、特定のリクエストのみCloudFrontを経由させる設定や、デバッグ用にキャッシュを一時的に無効化する方法など、移行時に安全性を確保するためのテクニックを共有します。

このセッションは、複数ドメインで運用中のPHPアプリケーションを対象に、後からCDNを導入する際の手順と注意点をわかりやすく解説します。AWSを活用した実践的なアプローチに興味があるエンジニアの方に、移行作業をスムーズに進めるための知識を提供します。

クラウドネイティブやマイクロサービスアーキテクチャの普及に伴い、アプリケーションは複雑化し、
従来のモニタリング手法では原因特定が困難な障害やパフォーマンス劣化が増えています

こうした状況下で注目されるのがObservability（可観測性）です
Observabilityは、システム内部の状態や相互作用を可視化し、迅速な問題解決や改善策の立案を可能にします

本セッションでは、業界標準化が進むオープンソースプロジェクト「OpenTelemetry」を活用し、
PHPアプリケーションにObservabilityを導入する手順を段階的に解説します
Observabilityの基本概念をMonitoringとの違いを交えつつ明確化し、実際のトラブルシューティングシナリオを示します
これにより「なぜObservabilityが今必要なのか」を理解します
さらに、OpenTelemetry自体が何なのか、その本質と狙いをOpenTelemetryの特徴やコンポーネントをわかりやすく整理します
公式SDKのセットアップ、計測ポイントの挿入、外部サービスとの接続方法をサンプルコードを交えながら示し、PHPアプリへの適用ステップを紹介します

このセッションで参加者が次の開発・運用プロセスでOpenTelemetryを用いてObservabilityを導入できる一歩目を提供します

• 想定する聴講者
  • OpenTelemetryを知らない方
  • OpenTelemetryが何故必要とされているか知らない方
  • OpenTelemetryを利用してみたい方

本セッションではTerminal IDEを、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能をVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。

話すこと

• なぜTerminalで完結させているのか
  -Terminal IDEとIDE製品のPros/Cons
• Lua言語について
• Terminal周りのOSS事情と、Rust製の勢い
• 自分が大規模コードをNeoVimのみで編集できるようになるまでの四苦八苦
• PHPでのライブコーディング

システム設計における「美しさ」は単なる見た目や感覚の問題ではありません
それは設計を維持し、守り、そして未来へ導くための重要な基盤です
本トークでは「美しさ」を設計の中心に据える意義と、それがアーキテクチャ全体の秩序や一貫性をどのように支えるのかを深掘りします

美しいコードやシステムに触れ、感動を覚えたことはないでしょうか
技巧を凝らしたコードに感嘆し、理路整然としたシステムの完成度に心を打たれた経験があるかもしれません
美しさには人の本能に訴えかける抗いがたい魅力があります
この魅力はアーキテクトが最も大切にする「システムの未来を形作る力」を秘めています

本トークでは以下の内容をお話します

• 美しさの価値：美しさがなぜ有用で、アーキテクトにとって欠かせない要素であるのか
• 審美眼の鍛え方：美しさを見極め、活用するために必要な視点やアプローチ
• 実践的な活用法：美しさを設計プロセスに組み込み、システムの秩序を守るための具体的な方法

対象者:

• システム設計やアーキテクチャに関心のあるエンジニア・リーダー
• 持続可能な設計を目指す方
• チームでの設計文化を改善し、秩序あるアーキテクチャを構築したい方

美しさが設計にもたらす力を探求し、設計の未来を描くインスピレーションを手にしましょう

皆さんはパスキーと聞いて何を思い浮かべますか？
なんか新しいすごいやつ、パスワードがいらないやつ、顔認証するやつ、デバイス間で同期してくれる、公開鍵暗号、チャレンジ………

このトークでは、近年GoogleやGitHubなど主要なWebサービスでも採用されてきている新しいユーザー認証方法「パスキー」に入門します。

• パスキーとは何か
• パスキーで何ができるのか
• なぜパスキーが推されているのか
• 従来のユーザー認証と何が違うのか

などのような基本的な部分から、

• パスキーでログインをするために必要な実装
• パスキーを実装する上での注意点
• パスキーを運用する上での注意点

など発展的な部分まで、一通りパスキーでの認証ができるようになるレベルを網羅します。

このトークがお勧めな人

• パスキーに興味がある人
• ID / パスワードによる認証とさよならしたい人
• よりセキュアなユーザー認証を実現したい人

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

• パスキーの仕組みの理解
• パスキーの実装方法
• パスキーの運用のあれこれ

古いコードベースを読み解く作業はしばしば「ソフトウェア考古学」と呼ばれ、多くの人にとって大変で辛い作業と思われがちです。
しかし、サービスの歴史を辿ることで当時の設計思想や変化の過程を知ることができ、それ自体が良い設計を体験し、学べる貴重な機会でもあります。
私の実体験としても20年もの歴史のあるWebサービスの考古学からは学べることがたくさんありました。

本トークでは、新卒5年目エンジニアである私が、20年以上稼働し続けるWebサービスの改善に向き合う中で試行錯誤したことをお話しします。

お話すること

• 古いコードベースを読み解き改善を行った事例とその課題
  • Webメディアの広告運用のための管理画面改修
  • 歴史の塊のバッチ処理をPerlからPHPに移行する
• 全体を知るための「鳥の目」と細部を観察するための「虫の目」の考え方
  • 鳥の目で意図や構造を理解する作図ツールなどを使ったコードの読み方
  • 虫の目で詳細を把握するためのデバッグ方法
  • 「どこまで深掘りするか？」の判断基準
• ソフトウェア考古学の経験から学んだこと
  • 理解しやすいコードを書くコツ
    • 自分が書いたコード、その後どうなった？上手く行ったこと、行かなかったこと
  • ソフトウェアの健全な変化を助けるドキュメントとは？

話さないこと

• トークの中で出てくるツール自体の詳細な使い方
• リファクタリングやデータ移行といったソフトウェア改善に伴う手順の詳細

聴いてほしい人

• コードベースが古い環境で悩んでいる人
• 歴史のあるコードを改善したいと思っている人
• プロダクションコードに初めて触れ、規模の大きさや複雑さに圧倒された経験のある新卒の人たち

本セッションはPHPで計算機を自作します。環境構築からコード全体を解説します。

自分たちが使っているPHPのインタープリタとは何をしているのか、普段使っているPHPがいかに高度なことをしているのかを理解することが目的です。

本セッションは初中級者向けです。コードの記法などは解説致しません。計算機やプログラミングに興味があるが作り方が分からない方、PHPの内部実装の想像がつかない方を対象としています。

そのため、初心者でも理解しやすいように以下の工夫をします。

スタック型です
型をintegerとfloatに制限します
型キャストを使った明示的な型の管理を行います
逆ポーランド記法を使います
ユーザー定義関数を使いません

上記の特徴を持った言語を作ります。つまづきやすい、複数の型に対する演算の定義やASTを構築するタイプの言語における二項演算、ユーザー定義関数を意図的に避けています。

実装を解説し、ある程度計算機を理解したうえで、以下の話をします。

PHPがASTを構築し中間言語をVMで実行するタイプの言語であること、本セッションで実装した言語との違い。
通常の言語における二項演算の処理方法。式、文など。
ここまで作成した言語でHello,worldをする方法 (任意の要素を受け取れるprint文を作り、asciiとして解釈させる)

本セッションを通して視聴者は、計算機を構築するのに何が必要か理解し、自ら新しい計算機を作り出せるようになるでしょう！

php-fpm は PHPアプリケーション の実行環境として広く利用されていますが、その内部処理についてご存知でしょうか。

PHP プログラマから見ると、php-fpm はランタイムですが、php-fpm 自身は単に C 言語で実装されたアプリケーションにすぎません。これは我々が日頃から実装している PHP アプリケーションと領域や抽象度は異なりますが、一つのアプリケーションであるという点は同じです。

ただ、php-fpm ではより低いレイヤを扱っています。これは PHP アプリケーションレベルでは隠蔽されている処理が実装されているともいえます。普段、PHP コードを書くだけであればこうした底レイヤを意識する必要はありません。しかし、こうした下のレイヤがどのように動作しているのかを知ることはより深く PHP とそして自らが書いた PHP コードの挙動を理解することができます。そして、何より自分が書いたコードが内部でどのような仕組みで動いしているのかを知ることは楽しいものです！

本セッションでは、一歩レイヤを下りて、php-fpm がリクエスト受信から PHP アプリケーションを実行してレスポンスを返すまでの流れを内部実装やデバッガを元に追いかけてみましょう。

コンパイルの世界では、中間表現というアイディアが存在します。
ソースコードを任意のデータ形式（中間表現）に変えてから、コンピュータが理解できるデータ形式（機械語）へ変換するというアイディアです。
一気に機械語へ変換するよりも、無駄な計算を省いたり複数フォーマットへの変換処理を効率化するなど効率化の恩恵をもたらします。

PHP8.0でJITによる高速化が導入されましたが、8.4では中間表現のアイディアを採用することで、さらなる高速化を図る変更が行われました。
https://wiki.php.net/rfc/jit-ir
中間表現を実現するにあたって、新しいフレームワークIRを使ってJITを実現しています。
https://github.com/dstogov/ir
このフレームワークでは、一体どのようにして中間表現を実現しているのでしょうか？

本セッションでは、まずJITと中間表現の基本概念を説明し、その後、PHP 8.4で導入されたフレームワークIRの詳細を解説します。
JITフレームワークIRを解説していくなかで、PHP8.4に導入されたJITでの中間表現について理解を深めていきます。

PHPはCGIからPHP-FPMへと実行環境を移行し、最近ではFrankenPHPが登場しました。
本セッションでは、PHP実行環境の歴史を振り返り、初期のCGIからPHP-FPMへの進化過程を簡潔に解説します。
また、各環境の移り変わりにより、パフォーマンスやスケーラビリティ、セキュリティがどのように改善されてきたのかを具体例を交えて紹介します。
さらに、最新技術として登場したFrankenPHPの誕生背景やアーキテクチャ、特徴を紹介し、PHP-FPMとの比較を通じてそれぞれの利点と欠点を明らかにします。
本セッションを通じて、プロジェクトに最適な実行環境を選択するための基礎知識と視点を提供できれば幸いです。

ソフトウェア開発を行うエンジニアで「『技術的負債』という言葉を知らない」という方は今日においてほとんどいないと思います。その一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くないように思います。その相手が非エンジニアであればなおさらです。

また、技術的負債についての理解が不十分なことによる誤解や偏見も散見されます。例えば「技術的負債＝悪」というイメージから無用・無謀なリファクタリングを行ったり、逆に放置しすぎた結果、ビジネスにおけるリスクが表面化してしまうこともあります。

このトークを通じて技術的負債についての理解を深め、技術的負債とどのように向き合えばよいのか、その具体的なアプローチを考えるきっかけにしていただければと思います。

お話しすること

• 技術的負債とはなにか
• 技術的負債はいつ・どうして生まれるのか
• 技術的負債を放置することで発生するビジネス面・技術面でのリスクとは
• 技術的負債を最小限に抑えるいくつかのテクニック
• 技術的負債とどう付き合っていくべきか