トーク

8年運用しているPHPアプリケーションをリプレイスするのにあたって、目的整理とチームに向き合い、奮闘と決断した話をします。

• リプレイスの目的とやりたい事を整理できた話
• 運営を続けなからリプレイスへのリソースを割く話
• 事業決済者へのリプレイス打診の話
• 解消したかった技術負債へ取り組みと決断。やる決断、やらない決断。
• リプレイス実行とその後

長年運用しているサービスの技術負債を解消しきれず、リプレイスを検討している方へサポートになれれば幸いです。

2024/02/02 にPHPUnit 11がリリースされました。
前回のPHPUnit 10ほど変更量はありませんが、それでも無視できない変更がいくつかあります。
例えばデータプロバイダーからの名前付き引数が使用できるようになったり、Deprecatedになったメソッドが20個近くあったり・・・

今回のトークではPHPUnit 11で何が変わったのか、changelogベースで解説していきます。
必要に応じて、実際に動かしたりしながらの解説もしていきます。

https://github.com/sebastianbergmann/phpunit/blob/11.0/ChangeLog-11.0.md
https://github.com/sebastianbergmann/phpunit/blob/main/ChangeLog-11.1.md

現代のウェブ開発では、クラウドベースのアプリケーション開発が主流となっています。
一方で、時代背景や特定のニーズ、コスト等の観点から、オンプレミスを選択する企業も少なくありません。
特にLAMP（Linux, Apache, MySQL, PHP）環境は、その堅牢性と信頼性で、10年以上にわたり多くのウェブアプリケーションの基盤として選ばれてきました。

しかし、オンプレミス環境におけるPHPやOSのバージョンアップは、複雑で手間がかかり、特に運用中のサービスにとっては高いリスクと大きな挑戦を伴います。

本トークでは、実際に運用している大規模サービスのPHP7からPHP8へのバージョンアップをゼロダウンタイムで行った経験を元に、
オンプレミスのLAMP環境において、安全で効率的にバージョンアップを行うための技術的戦略をお話しします。

AWS CDKでサポートされていないPHPでIac的なことをやるとしたら？という興味とその実装が本発表の論点です。
今回はAWS SDK for PHPから提供されるクラスをを使用して全てのインフラリソースをコード化し、その場合の構成管理やメリデメを共有する内容になります。

インフラ構成の題材としては、下記のサービスを使用したシンプルなContainer Applocationを考えています。
VPC, Subnet, ALB, ECS

扱いたいトピック

• SDK for PHPから提供されるクラスの概要
• SDKでインフラリソースを管理するためのコードやロギング、トレーサビリティの話
• PHPプロジェクト内でのディレクトリ管理、実運用に耐えられそうかどうか

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

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

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

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

過去のPHP(特に５系まで)では、型システムが未熟であり、型の変換や関数の引数や返り値の型が厳密に管理されなかったため、関数を利用する際に適切な型の値を渡すことが難しかったり、返り値の型を信頼できない場合がありました。現在名前ベースで一致を調べる型システム(nominal type system) を採用していますが、他の言語と比べて、どうなのかを次の観点をベースにお伝えします。

1. 採用している型システムの考え方のメリットデメリット(nominal type systemなど)
2. 型コンパイルのタイミングが異なることによる影響
3. 1,2では難しいポイントを各言語ではどう問題解決しているのか？
4. 型システムの違いが及ぼす業務コードを書くことへの影響

手前味噌ですが、私の所属する株式会社リンケージには、PHPのカンファレンスで毎度のごとく登壇するような実績のあるエンジニアが集まっています。

私は23年3月からPdMとしてエンジニアの方々と一緒に働いてますが、よく耳にする一般的なエンジニアとは思考と行動がまったく異なると日々感じています。
この1年間、そのノウハウを盗むべく、気づきがある度にメモを取り参考にしてきました。
今回は、そのメモをもとに、PdMという客観的な視点から実績のあるエンジニアはどのような思考をもってどのような行動をとっているのか、以下3つのベクトルに分けて説明していきます。

①対エンジニア職（開発チーム内）
②対ビジネス職
③対自己

【主な対象者】
・エンジニア/プロダクト開発に関わる方：働き方やチームビルドの参考に
・ビジネス職の方：エンジニアとの関係構築の参考に
・エンジニア採用担当者：エンジニア採用の参考に

「開発環境でクラスが読み込めないからとりあえず打つ」
「手順書に打てって書いてあるから実行する」

composer dump-autoloadを実行する時にこのように場面に遭遇したことはないでしょうか？

実は、dump-autoloadを打つべきタイミングには、明確な場面があります。内容をよく知ることで、「とりあえず打ってるけど、よく分からなくて不安…」を解消しませんか？

話すこと

• dump-autoloadを実行したとき何が起こっているか

対象者

• dump-autoloadをいつ打つべきか分からない方
• psr-4以外のautoloadを使ってみたい方

このトークは、オライリー・ジャパン出版の名著「SQLアンチパターン」で紹介されている25のアンチパターンを「超特急」で学ぶものです。
わずか5分のLTで、25個のアンチパターンをおさらいします。スピード感のある超特急LTをお楽しみください。

大事なところだけをギュッとして、明日からすぐ使える知識としてお届けできたら幸いです。

約４年の歳月を経て弊社プロダクトのFuelPHPからLaravelへのリプレースが完了しました（発表までには完了している予定！）。
完了までにリプレース失敗や負債・複雑性を生み出してしまいました。
本トークではそれらを回避するにはこうした方が良かったなーと思うことをサクッと５つご紹介します！

リプレースプロフェクトを直近で開始される予定の方、あるいは初期フェーズの方のお役に立てるかも？
あるいはリプレースあるあるとしても聞いて楽しんでいただけるかもれません！

みなさん、「GraphQL」 使ってますか？
GraphQLはWeb APIを開発するためのクエリ言語であり、
クライアントが本当に必要なデータのみを柔軟に取得できる仕組みとして注目を集めています。

そんなGraphQLですが、PHPでもLighthouseというフレームワークを使うことにより、簡単にGraphQL APIを実装することができます。
さらにはこの実装したGraphQL API、少しの工夫を加えるだけでこれまた簡単に、TypeScriptから型安全に呼び出すこともできちゃうんです。

このセッションでは「これからGraphQLに触ってみたい！」という方を対象に、
Laravel + Lighthouse + TypeScriptを用いた"型安全なGraphQL API開発体制の作り方"についてお話しさせていただきます。

多くの開発者は手元のマシンでPHPで開発をする際Package Manager経由でPHPをインストールしているはずです。
長年プログラミングをしている方なら brew update を叩いたらPHPが壊れるといった経験をしたことがあるはずです。
バージョン競合が発生しやすいため環境依存性や再現性や安定性に課題があります。

本登壇ではNixというPackage Managerの紹介をします。
NixはAtomicなInstallが可能であり、他Packageとの依存がないので何もしてないのに壊れたという状況が起こりえません。
PackageのBuild Scriptを宣言的に記述することができ、Rollbackも簡単に行うことができます。

想定聴講者

• 既存のPackage Managerで事故ったことのある人
• 複数プロジェクトで異なるPHP Versionを使っている人

▼概要

Laravelでは「運営ユーザのみアクセスできる」などの認可をmiddlewareを使って簡単に定義できます。
定義の仕方も「routingファイルに書く」・「Policyを使う」など様々な用途で使い分けができます。 便利ですよね。

しかし、上のような書き方だと、どうしてもroute側かPolicy側が認可の責務を持つことになってしまいます。
もしかしたらValueObject・Entityを使う設計がされているプロダクトではValueObject・Entityごとに対する操作の認可というアプローチもありなのかもしれません！

このLTでは、ValueObject・Entityごとに対する操作の認可の実際の書き方・書くことでどういうメリットがあるかをお話します！

いざ、大冒険の幕が上がる！！
PHPとLaravelのバージョンアップ――それは、EOLという名の暗雲が迫る中、このデジタルの海を航海する我々の船の帆を張り直す必要がある作業だ。わずかに残された時間でPHPerたちは、この世界を救い出せるのか？

だが、心せよ。この旅は、ただの数字遊びではない。我々の前に立ちはだかるのは、 「破壊的変更」 という名の荒波だ。1つ、2つとバージョンが上がるごとに、新たな敵が次々と姿を現す。
この旅の道中では、我々が冒険の書として頼りにしたアップグレードガイドには載っていない、隠された強敵とも多く戦ってきた。

本LTでは、PHP 7.1から8.1へ、Laravel 5.6から8.xへのバージョンアップで直面した問題と、それに立ち向かった数々の対処法（具体例）を一挙ご紹介。

今、あなたもこの冒険に参加し、戦いに挑もう！（バージョンアップしよう！）