トーク

ファーストリリースが3ヶ月後という状況の新たなWebアプリケーション開発プロジェクトに参加する中で、目の前のスケジュールに間に合うような高速開発と、ファーストリリースの先も破綻せずに改善しつづけられるよう中長期的な持続可能性を意識した開発を両立させることが求められました。
このトークでは、全力で走りながらレールを敷くようなWebフロントエンド開発を支えるために工夫した点、導入したテクニック、うまくいったことやいかなかったことなどをお話しします。

※本トークの内容は PHP に関連しません。

SPA全盛の時代ですが、まだまだ古き良きMPA（Multi Page Application）のシステムを触る機会は多いですし、
凝ったUIを必要としない社内システムなどでは、新規開発でもMPA構成を採用することは普通にあります。

MPAだとビューのテストは基本的にPHPフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上でJavaScriptを使ってある程度複雑な処理が行われる場合に、その部分をテストすることができません。

MPAであっても、一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJavaScriptの処理を楽にテストする方法を、Laravelにおける実装例をもとに解説します。
（例としてLaravelを取り上げますが、他のフレームワークにも容易に応用可能な内容です）
既存のMPAに後付けで簡単に導入することが可能なので、すぐにでも実務に活かせる内容になると思います。乞うご期待。

突然ですが、皆さんの現場のPHPはバージョンはいくつでしょうか？

既にPHP7系もEOLとなって久しく、先日行われたPHPerKaigiで行われたアンケートでは8系がマジョリティーとなっていました。
CIで静的解析やユニットテストが回り、デプロイは自動化され、RectorやDependabotでライブラリは最新、エディタはPhpStorm一択！
といったモダンな現場がある一方で、無視できないのは少なくない「5系」に入った票です。

現実には様々なしがらみからレガシィ化してしまったコードベースは存在します。
無限に広がるarrayの可能性、なくならないバグやデグレ、属人化したデプロイ作業...
そんなPHPの闇の中でもDeveloper eXperienceを諦めたくない！

このトークではレガシィな環境で戦ってきた中で培った自分なりの工夫、実際の現場で使っているツールや行っている取り組みをお話します。
過去の自分と同じような境遇の方の参考になれば幸いです。

お話すること

• PHP5系でも使える品質向上のための開発支援ツールの紹介
• 既存コードベースに引きずられないように開発している箇所とそのアーキテクチャ
• レガシィと向き合うための自分なりの工夫とマインドセット

お話しないこと

• PHP4系で動いているシステムへの言及
• PHP8系で動いているシステムへの言及
• リプレースの話

アプリケーションを実装する時にEventDispatcherを使ったことのある人は多いと思います。
そんな便利に使っているEventDispatcherの仕組みはご存知でしょうか？
まずSymfonyのEventDispatcherの仕組みを参加者の皆さんと一緒にソースコードリーディングで解明するとともに、SymfonyのEventDispatcherがどのようにPSR-14を実装しているかも見ていきます。

障害、嫌ですよねぇ。
嫌だから、起こしません・・・！素晴らしいのですが、「リリース怖い」「改修怖い」では、前に進めなくなります。

1番良いのは「適切に怖がる」「転んだら盛大に学び尽くす」という態度です。
スクラムを筆頭に、「ふりかえり」の力は「組織を強くする」ためのアジャイルな組織に必須な力と考えられています。もっと広げれば、体験学習の世界でも重要なことです。

そうした、本来の「これから先に活かすふりかえり」の姿を取り返しませんか？

お伝えしたいこと

• ただの「事実確認」で終わらせない、障害のふりかえりをやろう
• 「同じことはもう起きない」ではなく、「組織としての課題」につなげよう

私のキャリアの直近3~4年は、東京のエンジニア採用に加え、地方のエンジニア採用をしてきました。
採用活動を通じて、地方のエンジニアが現地に根を張り、活躍することに非常に大切な意味があると思っています。
特にリモート普及後、「フルリモート」「現地の企業」「地方拠点」など、企業の選択肢も格段に増えてきました。

■話をしたいと思っていること
・関東と地方のキャリアの違い
・リモート普及後の地方のエンジニアの変化
　・どのような活躍の仕方があるか
　・逆にどのような問題がおきているか
　・技術コミュニティの在り方の変化
・リモート時代の地方のエンジニアの存在意義
　・地方でエンジニアが活躍することにどのような存在意義や価値があるのか

日本社会は、労働力減少や少子高齢化など直面している問題が山積みで、関東一極型の働き方は難しくなっています。
福岡であったり、それ以外の地域でのエンジ二アが活躍・活動する場所が増えていったり、居住地を含めた柔軟な働き方は今後ますます必要になっていくため、地方でキャリアの挑戦をしたいと考えている人の後押しになる発表を目指していきたいと思います。

私自身の経験を通じて、地方のエンジニアの活躍・地域ITコミュティの重要性についてお話したいと思います。

PHPのフレームワークやライブラリを作成する人に向けて、「みんながこういうノリで実装してくれたら嬉しいな」を形にした「PSR」と呼ばれる取り決めがあります。

https://www.php-fig.org/psr/psr-14/

「PSR-4(オートローディングに関する規約)」「PSR-7(HTTPメッセージの取り扱い表現方法に関する規約)」「PSR-12/PER Coding Style(コードのスタイルに関する規約)」などは、耳にしたことがある人も多いのではないでしょうか。

そんなPSRの中に、「PSR-14: Event Dispatcher」があります。イベントやその発行・購読についての規約です。
この14番は、どちらかというと知られていない部類のような気もしています！

このセッションで、改めてスポットライトを当ててみましょう。
「PSR-14とはどういうもので、リアルワールドにおいてはどのような実装があるのか」について知ってみませんか？

話すこと

• PSR-14は何を狙ったものなのか
  • この取り決めが議論され形になった背景には、どのようなプログラミング上の課題があったのか。何を解決するものなのか
  • = 「Observerパターンとどう付き合うか」みたいな話
• PSR-14を用いた実装例(ライブラリ)を覗いてみる

みんな大好きWordPress！世界のWebサイトの4割以上と圧倒的シェアを誇る皆様御存知のPHP製超有名CMS！
そんなCMSで作られたWebサイトのインフラをリプレースする機会に恵まれたので、イキって「時代はコンテナ！冪等性こそ至高！」とEC2からFargateに載せ替えようとしたら大失敗？！

今回のトークでは上記のEC2からFargateへのリプレースプロジェクトにおいて得られた知見を共有させて頂きます。

お話すること

• 実際に行った移行手順
• ハマったポイントとその解決策
• リプレースしてみた感想

PHPのビルトインウェブサーバーを使ったことはありますか？
Laravelユーザーの方ならお馴染みの「php artisan serve」というコマンドで使用しているかもしれません。

実際HerokuやAWS ECSのLaravelデプロイ時に「php artisan serve」を使用する例もちらほら見受けられますし、公式サイトでもこのようなサンプルが紹介されています。

しかしながら、php公式がビルトインウェブサーバーを本番環境で使用することを禁止しています。
https://www.php.net/manual/ja/features.commandline.webserver.php

実際にビルトインウェブサーバーを使用した経験に基づいて、その弊害についてお話ししながら、ビルトインウェブサーバーの注意点をまとめてみました。