トーク

本セッションでは拡張性に重きを置いたシステムについてお話しします。

マイクロサービス・モジュラモノリスとアーキテクチャスタイルは多様化していますが、重要なのはスタイルではありません。
本セッションではスケーラビリティを重視します。
スケーラビリティはリソース・コード・組織など様々な観点があり、それらのスケーラビリティの向上はいずれもビジネスにポジティブなインパクトを与えます。

本セッションではそれらを担保するために必要な要素が何かを深堀りし、それらを実現する具体的な技術スタックやアーキテクチャを模索します。
その中でPHPを主軸としたとき、活用しやすい箇所・しづらい箇所についても言及します。

得られる知識：

スケーラビリティの多面的な観点の理解
スケーラビリティを担保する重要な要素とその実現方法
スケーラブルなシステムを実現するための実践的な知識と洞察

■ スライド
https://speakerdeck.com/tamayama0111/typescriptdatutarafetobedotutimoshu-kerusi-le-ziyanai-typescripter-vs-phpernozhan-i

■ あらすじ
「TypeScriptだったらFEとBEどっちも書けるし、楽じゃない？」そんな一言からこの戦いは勃発した。
今PHPer vs TypeScripterの戦いが始まる!

本トークではPHPのメリット・デメリットとTSのメリット・デメリットを話します

■ 内容

• PHPでAPIを作る上での優位性
• TSでAPIを作る上での優位性
• 性能面での比較
• バグの産みやすさの比較
• ユニットテストの比較

■ 対象者

• フロントエンドもバックエンドも書いている人
• TSに興味があるPHPer

リリースはサービスの価値をお客様に届けるための重要なステップです。しかし、特に長期間開発されてきたプロダクトでは、そのリリースのプロセスに課題を抱えていることが少なくありません。
サイボウズのグループウェアGaroonも、ビッグバンリリースが常態化している、機能がリリースされるまで時間がかかる、リリース後の障害の改修にも時間がかかる、複数チームが利害関係者になっているリリースプロセスが複雑で制約が多い、といった課題を抱えていました。
しかし、ここ1年でGaroon開発チームが行ったリリース改善は一定の成果を得ることができました。例えばリリース回数だけをとっても、ここ数年のリリース数が月1～2回であったのに対して、最近では月14回のリリースができています。
本セッションでは、私たちがリリース改善への共感をどのように得て、どのような改善を行い、どのような成果を得ることができたのかを紹介します。

Symfonyは、PHPのフレームワークの一つで、多くのPHPerに愛用されています。その魅力とは何でしょうか？そしてその魅力をどのように活用すれば良いのでしょうか？

このセッションでは、Laravelなど他のフレームワークが優位を占める現在でもSymfonyが一定のシェアを保つ理由、Symfonyの特性とその魅力について掘り下げます。

• Symfonyの主な機能とそのユニークな特性
• Symfonyがもたらす開発効率の向上とその理由
• 実際の現場でSymfonyを活用するケーススタディ

このセッションを通じて、他のフレームワークを使用している方に、Symfonyの可能性とその魅力を感じていただき、Symfonyを活用した開発の新たな視点を提供できればと考えています。

このセッションは、PHPフレームワークに興味がある方、Symfonyについて知りたい方に特におすすめです。

PHP には古くから PHP Extension という機構が備わっており、ネイティブで高速な言語拡張を提供することが可能です。
普段からよく利用されているであろう APCu や PhpRedis なども PHP Extension という形で提供されています。
実は、 PHP Extension 取り巻く環境が以前と比べて変わりつつあるのはご存知でしょうか？
今回はそんな PHP Extension の今について発表させていただきます。

オープンロジでは約10年もののPHPアプリケーション(Laravel)が日夜動き続けています。
コードの行数は数十万行あり、データベースのレコード数も数十億程度あります。

弊社ではアプリケーションエンジニアの採用を積極的に進めています。
巨大なコードベースかつ物流のドメイン知識は複雑怪奇なので、少しでも認知コストやレビューコストを下げ、安心して開発を進めていけるようにCI整備が肝要です。

今回は具体的に取り組んでいることについて幾つか紹介します。

開発環境構築整備 / CI整備 / Linter整備 / 静的解析整備 / UnitTest整備

あなたのアプリケーションでは、複数のコンテキストでロジックを共有することはありますか？

例えば、ECサイトの商品ページでは、管理者が商品の内容を変更して事前にプレビューしたいケースがあります。
ここには一般ユーザーが商品ページを閲覧するコンテキストと、管理者がプレビューするコンテキストが存在します。

プレビューのロジックはどこにあるべきでしょうか。
管理者コンテキストでは、一般ユーザーのロジックを再利用すべきでしょう。完全に分離してしまうとプレビュー機能が一般ユーザー向けのロジックに追従し続けるコストが発生します。
一方で、一般ユーザーコンテキストではプレビューのロジックは不要です。プレビュー機能を改修するたびに一般ユーザー側までテストしたくありません。

複数のコンテキストでロジックを共有する場合、コンテキスト間の依存関係を適切に制御するにはどう実装すべきかを考えます。

誰かの書いたコードが世に出る過程で、コードレビューを行う組織は多いのではないでしょうか。
コードの質を担保するため。属人化を防ぐため。知識共有や認識合わせのため。チーム内のスキルアップのため。

コードレビューは様々な意味や目的を持って行われます。

本セッションでは、コードレビュワーがコードレビューイに求められていることとそれに応える方法を下記の例と共に考察していきます。
・PHPコード上でのレビュワーとレビューイのコミュニケーション例
・レビューが活性化するPHPコード例

また、実際に弊社で働く様々なポジションのPHPerエンジニアにインタビューを行い、彼らが求めるレビュー内容をもとに共通項を見つけたり、
レビュワーとしてコメントをするときの工夫点や注意点を紹介します。

レビュー時、依頼時に少しでもお役に立てると幸いです。

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

PHP 8.1から始まった、mbstringの大規模改修。
それをまとめたところ、大規模改修をしているAlex DowadさんからFYA(For Your Action)をもらうようになり、レビューをしていました。
すなわち、mbstringの変化をリアルタイムで見るようになってしまったのです。

2022年12月から始まったこのゆるい関係は、ときに入ってきたプルリクエストをサポートしたりとたくさんの出来事がありました。てきめん自身もプルリクエストを送りマージされたため、GitHub上でContributorフラグをもらえました。

また、php-src上で誰に何を投げれば良いのか段々とわかってくるようにもなりました。

本トークでは、PHP 8.3のmbstringの変更点・貢献内容はもちろんのこと、php-srcへのコントリビュートに挑戦したい方への足がかりになれば幸いです。

モノリス全盛期〜マイクロサービスブームを経て、近年、両者のいいところ取りができるアーキテクチャとしてモジュラモノリスが話題になることも増えてきました。PHPでも流行のLaravelフレームワークでのやり方やハマりポイントの記事がありますが、基本的に密結合を指向しているLaravelをベースにかなり無理をして実現している事例を見かけます。
私が数年にわたってSymfony+Doctrine ORMをベースにモジュラモノリスでアプリケーションを開発してきた経験から、Laravelベースで開発するよりも数段楽にモジュラモノリスを実現できることを証明したいと思います。

話者は好んでOSSのBrefを利用したサーバーレスのシステムを構築しています

その中で不自由なくLaravelを利用しているのですが、
AWS Lambdaに大きなフレームワークを組み込む事は１つのアンチパターンだと認識しています

しかし自分の体験を元に考えると、本当にアンチパターンなのかを疑問に感じており、
その疑問を解消するために、必要な機能のみ切り出したフレームワークを自作することにしました

フレームワーク実装について学びながら
本当にAWS Lambdaに大きなフレームワークを利用するのが
アンチパターンなのかLaravelと比較しながら検証します

アンチパターンを正面から踏み込むことで、新しい議論の場を作れればと思います

• 想定する聴講者
  • サーバーレスに興味がある方
  • フレームワークの自作に興味がある人
  • Brefが好きな人、気になる人

ノンフレームワークのプロダクトに、フレームワークを導入した経験はありますか？
計画で諦めた人、チャレンジして失敗した人もいるかもしれません。

私の開発しているプロダクトは2001年にリリースされました。
当然設計もレガシーで
・PHPファイルにHTMLがベタ書きされている
・ルーティングはページごとにxxx.phpが存在する
など、非常に”牧歌的”設計になっています。

そんなプロダクトを、Laravelに移植するプロジェクトが立ち上がりました。

誰もが無理だと思ったこのプロジェクトは
""載せる""をキーワードに設計され、無事にリリースされました！

このトークでは”載せる”をキーワードに
”載せる”戦略と、そのメリット
”載せる”ときに苦労した点
”載せた”あとの世界
についてお話します！

※このトークは、PHPerKaigi2023で行ったLTのレギュラートーク版です。

「プログラミング、上手くなりたいです！」
しばしば聞かれる質問です。
「まずはエラーを気にしましょう！」
最近はこう答えるようにしています。

プログラミング言語は、(数学や理学の世界と比べて)人工的であり恣意的な創造物です。
エラーが出ると怖い・面倒臭いと思われるかも知れませんが、
温室に氷を放置すれば溶けていくのに比べて、プログラミングのエラーは「誰かがわざとそうしている」に過ぎません。

プログラマにとって、なぜエラーが重要なのでしょう？
あるいは、PHPを作る人は、何をエラーとして何を許容してきたのでしょうか？

このトークでは、

• フィードバックシステムとしてエラーの機構を捉えた時に、何の利益を提供しているのか
• エラーの変化から、昨今のPHPの進化を読み解いてみる

事を試みます。
それによって、エラーと仲良くなって、「まともなコードを書ける」人が増えることを目指します。

「コードレビューが順調に進んだほうが、チームの生産性が上がる可能性が高い」ということについては、違和感なく思う人が多いのではないでしょうか。

「順調に進める」ためには、それを意識することだけでなく、レビューする側・レビューを依頼する側のそれぞれにテクニックが必要になってきます。

このトークでは、かつて、「おまえのプルリクエストは大きすぎてレビューできない（意訳）」と実際に言われたことがある発表者が、現在までにどのような工夫をして「分割プルリクエスト」にたどり着いているのかを共有したいと思います。

なお、このトークのタイトルは「リーダブルコード」にインスパイアされていますが、トーク内容については特に関係するものではありません。

■想定する対象者

• プルリクエストのサイズが大きくなりがちなかた

■話さないこと

• コード自体をどう読みやすく書くか、など

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

このトークでは私たちが愛するPHPをスタート地点にして、「CPUによる"プログラム実行"」「 PHPやJavaとC言語の根本的な違い」など、コンピュータプログラムがどの様に動作するのかを解説します。

コンピュータのレイヤー構造を理解すると、いままでは見えていなかった角度からプログラミングを楽しめるようになります。
このトークを通じて、低レイヤーが好きになったり、いろいろなレイヤーで面白いことをしたりする方が増えることを期待しています！

開発者数が多く、MVPアプリにも高トラフィックなアプリにも採用できるPHP。
インターネットではPHPのゆるい使い方ばかりが槍玉に上がっていますが、最近のPHPは言語仕様としての型サポートも強固になってきています。

もう一歩進んで、より安全に仕様変更やリファクタリングを行うためにどういう工夫が出来るでしょうか？
本セッションでは、プロダクト開発時に堅牢性を高めるための仕組みと文化についてお話致します。

対象観客

• ビクビクしながらコードを変更しているPHPer
• 初学者でも安全にコードを書ける環境を作りたい人

お話しすること

• 年々型安全になりつつあるPHPの言語仕様
• テストを更に堅牢にするテスト戦略
• 静的解析で、テストされていない部分の不安を減らす
• MTTRを縮めるエラートラッキングツールの活用
• エラーの見落としを防ぐ週次エラー確認イベント

多くの現場でコーディング規約が策定され、それに沿った開発が行われています。
私のチームでもコーディング規約があり、実装者とレビュー者がそれぞれチェックを行っていました。
しかし守るべきルールの数は80を超え、人間が限られた時間の中目視でチェックするのは無理がありました。その結果見落としも頻発していました。

大変なことは自動化するのがプログラマの美徳。そこでPHP_CodeSnifferをIDEとCIに導入し、人間の負荷を下げることに成功しました！

しかしその裏では、既存プロジェクトであるが故のいくつもの障壁がありました。
「独自の規約なので、定義済みのルールセットを利用できない……」
「既存コードに違反があるせいで、毎回CIがエラーになる……」

このトークでは、約半年をかけてPHP_CodeSnifferをチームに導入した経験談と、直面した障壁の乗り越え方についてお話しします。

composer.json、composer.lock、composer require、composer install......よく分かんないぞ。
そんな疑問を持ったまま、なんとなくモヤモヤとしている新米PHPerを救いたい。

このトークでは、Composerというやつが何なのかを紹介します。

具体的な内容

• Composerの役割について
• composer.json .lock requireについて
• プラットフォームパッケージについて
• pharについて
• autoloadについて
• 実際にComposerを使って構築してみる

対象者

• Composerが気になる人
• 「pharアーカイブ」ってなんだよ？という人
• 「autoload」ってなんだよ？という人
• PHP初心者の人

常に機能追加が続く運用中の大規模オンラインゲームプロジェクトで、PHPを5.5から8.1にバージョンアップしました。
言語バージョンアップに伴い、PHPUnitも4.5から10に更新しました。

今回のバージョンアップについて、以下のポイントで話したいと思っています。

• バージョンアップの計画と結果（平均レスポンスタイムが42％短縮）
• PHPのバージョンアップでPHP_CodeSnifferをベースにして修正箇所を特定していった話や、そこで起こった問題へ対応
• PHPUnit10にバージョンアップする際、代替手段なしに削除されたメソッドへの対応など
• PHP5.5とPHP8.1を並行稼働させ、運用ツールなどがPHP8.1起因で止まってしまった場合にもゲーム運営を止めない工夫
• バージョン移行後に起こったopcache.jitに関するエラーなど

長年稼働しているサービスのDBを運用途中からマイグレーション管理した話をします。

PHPでマイグレーションを扱うのに、例えばLaravelのマイグレーションの利用を考えると思います。
複数のサービスアプリケーションで接続しているDB、どのアプリケーションでマイグレーション管理が最適なのかと考えました。

いや、、、サービスアプリケーション側でマイグレーションを持たせず、独立したマイグレーションアプリケーションを立ち上げましょう。

その時に最適だったのがCakePHPが公式に採用しているPhinx。

• Phinxを利用した独立したアプリケーション立ち上げ
• 運用途中からDBマイグレーション管理
• GitHub ActionsとECSを利用したRDS環境へのマイグレーション実行
• 実行テスト・ルール設定・テスト環境にマイグレーション利用など運用アレコレ

について話をします。