トーク

Composer で見かける「PSR-0」「PSR-4」、コーディングスタイルでみかける「PSR-2」「PSR-12」など、PHP に関わっていると自然と目にする「PSR」という言葉。
「PHP Standard Recommendation（標準勧告）」の頭文字なのですが、果たしてこれは何なのか？使い方は？どんなメリットがあるのか？
そんな疑問に対して、具体的なコードとともに解説していきます。

皆さん、PHPのDockerイメージは使ってますか？

開発手法は人や組織によって様々ですが、ローカルでの環境構築や本番環境へのデプロイにDockerイメージを使うことは一般化しつつあります。ですが、普段使っているイメージの中身をきちんと把握していると言い切れる人は意外といないかもしれません。そこで今回は「PHPのDockerイメージの深堀り」をテーマにお話をしたいと考えました。

・「何のために使ってるか分かってないけど、依存関係の都合でとりあえず入れてる。」
・「イメージのサイズが大きくなってきたから軽量化をしたいけど、パッケージの役割がよく分からなくて触りにくい。」

このセッションでは、自信と確信をもってDockerイメージの運用をしたい方へ向けた掘り下げを話していきたいと思います。細かい構成は決まっていませんが、軽量化の話を交えた構成にするつもりです。

※特定のフレームワークを深堀りする話はしませんが、リアルなDockerイメージを作るためにLaravelやCakePHPを使用する可能性はあります。

Discord Channel: #track4-2-a-php-docker

フレームワークのバージョンアップだとか、新しいコーディング規約の導入だとか・・・
コードをメンテナンスしているとどうしても避けられない「面倒くさい作業」ってありますよね。

その作業の一部で、よしなに機会がやってくれたらどんなに素敵でしょう？
PHPには、そんな「些細なリファクタリング」を手助けしてくれるツールが複数あります。
使いこなせれば、あなたのチームを「面倒」から解放してくれることでしょう。

このセッションでは、いくつかのツールを取り上げながら「仕組み・原理」と「活用・カスタマイズ」について紹介します。
具体的には、Rector, PHP CS Fixer, EasyCodingStandardを想定しています。

「一括してコードを綺麗にしたい」という人たちのために、「ツールの基本利用やオレオレルールの作成」までお届けして、退屈な仕事を減らす！！ことができれば幸いです。

みなさんはカンファレンスで登壇したことがありますか？
カンファレンスで登壇をしているスピーカーは、様々な過程を経てみなさんの前でトークをしています。例えば採択前ならネタ決めやプロポーザル、採択後ならスライド作成・トーク練習などの準備・・・
このトークするまでの過程は、人によって違うところもあり暗黙知であることが多いように思えます。

そこで今回は、過去に私がPHP系カンファレンスにて登壇した内容を例にしつつ、自分がカンファレンスで登壇するまでに準備していることを話します。
あくまで私個人の例ではございますが、少しでも登壇に対する暗黙知をなくすことを目的としてトークします！
まだ登壇したことがない方はもちろん、登壇したことがある人も良いところを取り入れられるきっかけになれば幸いです！

具体的には以下のことについて触れる予定です！
・プロポーザルを出す時にどんなことを考えているのか？
・無事採択されたけどトークするまでの準備はどういうことをしてるのか？
・過去に採択されたことのあるトークを例に具体例を紹介

普段開発しているコードベースでは PHPStan で静的解析をしているものの Lev.1 に留まっており、レベル上げをしようとすると大量のファイルがあって膨大な数のエラーが出てしまい手付かずの状態でした。静的解析が弱い分、ユニットテストや手動テストを主にして検証を行っていますが、手動テストの終盤で型エラーが起きてやり直しになるなど、非効率なことが起きていました。

その状況を改善すべく、モジュール毎に静的解析レベルを設定することで独立したメンテナンスを可能にし、比較的新しいモジュールからレベル上げをしていきました。
本セッションではその取り組みやつまずいたポイント等について紹介し、これから静的解析を強化していく方の参考になれば幸いです。

・解析対象と実行方法の整理
・レベル別静的解析の恩恵
・Laravel IDE Helper の問題点とその対応
・レベルを上げてからのコードの書き味

Discord Channel: #track2-5-b-php-static-analysis-max

多くの場所でジェンダーに関する話題が議論されるようになり、ITコミュニティでも無意識バイアス、ハラスメント対策などエンジニアの女性比率を高める為の取り組みに注目があつまっています。

これらの議論の中ではしてはいけない行動がなにかといったことが多く話題に上がる一方で、ではどのような行動をすればいいのか、また男性エンジニアの文化そのものについてはあまり話題に上がりません。

このセッションでは「男性エンジニア」とそれを取り巻く環境と文化とはどういったものなのかを考察し、より多くの人に対してインクルーシブなコミュニティや職場を作るために男性エンジニアがどのような行動を取れるのかについて紹介します。

トーク内で取り上げる予定の話題

• ロールモデル
• 無意識バイアス
• 心理的安全性
• Cultural Water
• アライシップ
• ジェンダーギャップ
• Michael Welp : White Men: Time to Discover Your Cultural Blind Spots
• Tony Porter: トニー・ポーター：男達への提言
• ジェラルド・ワインバーグ: プログラミングの心理学
• イリス・ボネット: Work Design

At the recent years, I used a lot PHP to develop my web crawlers and save my life to make some duplicated works automated.
I also research them and write a book (it's written in Mandarin). And the book link is available here: https://www.books.com.tw/products/0010882656
This book tile translates to English is: PHP Web Crawler Development:From beginner to advanced web crawler technique guides.

In this session, I will present following topics:

• The motivation about writing this book.
• The guide about web crawler developments and sections introduction
  • Basic HTTP fundamentals and the tips for inspect HTTP packets and requests via web browser.
  • The PHP web crawler environment building demonstration.
  • Using the advanced web crawling techniques. Such as headless Chrome web browser.
  • Some Labs and live demonstration about developing crawler.
• The feedback and experiences about publishing this book.
• Extended references and other advanced crawling tips that not included in books.
  • Inspecting HTTP packets and requests via non-web browser.
  • Advanced extract/decode CAPTCHA codes.

Discord Channel: #track4-4-b-php-web-crawlers
Joind.in: https://joind.in/event/php-conference-japan-2021/best-practices-for-using-php-to-develop-web-crawlers

トーク概要
PHPそのものにバグがあるということがあります。仕様が変更されたために起こったバグだったり、PHPほどの歴史があるオープンソースソフトウェアだと皆に知られないまま十何年も潜ってしまったバグもあったりしたりします。

バグ報告を行おうとすると、PHPの側がおかしいのか、自分のPHPコードがおかしいのかで切り分けないといけませんし、仮にPHPそのもののバグだとすると、PHPのソースコードの莫大さと、PHPや使用しているライブラリの歴史の厚み、マニュアルにない仕様の変更、頻繁かつ大規模なリファクタリングなどが壁になりがちで意外と大変です。

私が間違っているのか、PHPが間違っているのか。大体は前者です（そして、そうあってほしいのです）が、後者だったときの切り分けの仕方を考えてみませんか。

トーク対象
PHPのバグを見つけてみたい人や、PHPのみならず規模が大きいソフトウェアのバグとどう見つければいいかの参考になれれば嬉しいです。

Discord Channel: #track3-2-b-php-src-bug

小学校でプログラミング教育が必修化される中、「Scrach」のような
ビジュアルプログラミングは注目されています

そんな中、LOVOT（https://groove-x.com/）と呼ばれる
『役に立たない、でも愛着がある” 新しい家庭用ロボット』がコンセプトの
ロボットに、「LOVOT STUDY ビジュアルプログラミング」という
ブラウザを用いてビジュアルプログラミングし、LOVOTを操る仕組みが提供されています

"ビジュアルプログラミング"でできることは、PHPでもできる！ことを
実証するために、
本来、ビジュアルプログラミングで操作するLOVOTを
直接PHPのプログラムから操作してみました(非公式)

まずは、ビジュアルプログラミングを解析する過程、そして
解析内容を元にPHP（Ampを用いて）で再実装する過程をお話しします

Let's PHP programming！

Discord Channel: #track3-5-a-php-robot

Webサービスを運営していると、サービスからユーザーにせっかく送ったメールが届かないことがあります。
そのような、何らかの理由で目的のユーザーの元に届かなかったメール＝バウンスメールをどう処理するかは、サービスにとって避けては通れない課題なのではないでしょうか。
また、AWS SESを使っている場合、バウンスメールの数が多すぎるとペナルティがあったりするなど、サービスにとってバウンスメール処理は意外に大事なものだったりします。
このセッションでは、そもそもバウンスメールとは何なのか、バウンスメールを適切に処理しないとユーザーそしてサービスにどんな不利益があるのか、またBASEのバウンスメールの処理に関する知見と実際の実装について、お伝えしたいと思っています。

みなさんのチームでは日頃からコードレビューはされてますか？
弊社でもリリースするコードに対して2人以上のコードレビューを必須にしたりと活発に取り組んでいます。

コードレビューには以下のような効果が期待できます
　・ソフトウェア品質の向上とアーキテクチャの統一
　・スキルの向上とナレッジの共有
いかに効果的にコードレビューを実施するかによって、チームの成熟度やプロダクトの品質に影響すると言っても過言では無いかもしれませんね。

しかし、正直なところ自分はコードレビューに苦手意識がありました。
一度のレビューに時間がかかったり、他のメンバーと比較してコードの改善提案をする回数が少ないのです。。。
そんな私が苦手意識のあるコードレビューをどの様に克服していくのか、体験談を踏まえてお話しできればと思います！（現在進行形）

▼お話しする内容
・コードレビューの概要
・弊社で取り組んでいるコードレビューの仕組み
・良いコードレビューするためのTips
・苦手意識のあるコードレビューをどのように克服していったのか（体験談）
・チームの過去1年分のコードレビューを分析してみる
・ペアプロならぬペアレビューをしてみる
・とにかくレビューしてみる
などなど

Discord Channel: #track3-3-a-code-review

LaravelのフォームリクエストのprepareForValidationでは
バリデーションを実行する前にリクエストデータを加工することができます。
リクエストデータを小文字に統一することや
[name=month value=10]、[name=day value=2]の2つリクエストデータを
[name=date value=102]という1つのリクエストデータにmergeすることができます。

ですが、prepareForValidationでmergeして新たなリクエストデータを作るとテストがしにくなってしまうのです。
基本は、Laravelのフォームリクエストをテストするとき、
Validatorファサードでバリデーションインスタンス生成して
passesメソッドに想定していデータを受け渡して確認するのですが、これが使えなくなるのです。

こういった場合のテスト方法として、以下の3つが考えられます。

1. Validatorファサードを使わず、自己流でバリデーションインスタンス生成してテストする
2. フォームリクエスト単位ではなくFeatureTestとして大まかにテストする
3. Laravel Duskを利用したE2Eテストで大まかにテストする

それぞれについて試した結果について話します。

本セッションでは主にLaravelのフォームリクエストとテストについて話します。

私たちのサービスはローンチから20年を超え、現在も積極的に開発中です。幸いにも今まで多くの方に使われるサービスとなっています。しかし、これだけの年数を経て多くの機能を追加しているため、典型的な「レガシーシステム」となっているのが現状です。
もちろん、開発時にはさまざまな課題があり、完全に解消することは難しいです。それでも、大規模なサービスを維持していくためには開発を継続することが重要です。

本セッションでは、大規模なレガシーシステムを継続して開発していくために取っている戦略の中で、ミドルウェアのバージョンアップに関する戦略を中心にお話します。

ミドルウェアのバージョンアップは、通常の機能開発とは大きく異なります。たとえば、サービス提供を続ける限り避けて通れないものですが、新たな価値を発生する者ではありません。そのため小さな機能追加などで積極的にバージョンアップをすることは難しく、EOLに合わせると、PHPの場合は2年に1度のバージョンアップになります。
そして、広い範囲の既存コードに手を加える可能性があります。バージョンの間が開くと修正箇所も当然増えます。いわゆるレガシーシステムであれば、影響範囲はアプリケーションすべてといっても過言ではないですし。修正が重複する個所すらあるかもしれません。
この影響範囲の広さが、レガシーシステムのミドルウェアバージョンアップを難しいものにしています。

それを考えずに、通常の開発と同じようにミドルウェアのバージョンアップをすることは困難で、正面から挑むだけでは無限の時間とコストがかかります。
現実世界には時間、コストなど、さまざまな制約があります。これはビジネスでサービス提供をしている以上当然避けられず、その中で戦わなければいけません。
となると作り直すのも現実的ではないすし、だからといって場当たり的な対応だけでは、技術的負債を抱え込んで開発の継続が困難になるかもしれません。
広範囲で複雑な問題には、取捨選択が必要です。いまある複雑な問題は、今この場面で対応すべきことではないかもしれません。
このように、普通の機能開発とは異なる困難さ、複雑さをもっています。これに立ち向かうためには、戦略をもって挑まなければなりません。

本セッションは、ミドルウェアのバージョンアップ事例の紹介とそのプロジェクトで採用した戦略についてお話します。
事例紹介では、直近実施した2件のバージョンアップ(PHP,PostgreSQL)の事例を紹介します。その中では現実の制約に沿った形でプロジェクトを推進するためのゴールの設定、事前準備、実際の作業プロセスについてお話します。
そして紹介した事例をより一般化し、レガシーシステムの開発を継続していくための戦略を紹介します。

Discord Channel: #track3-1-b-middleware-up

PHPのメジャーバージョンアップは変更点が多く、歴史が長くコードベースの大きなサービスでは対応に手間が掛かることが度々発生します。
弊社ではPHPのEOLを避けつつサービスの品質を担保するために、PHPのメジャーバージョンアップを2年に1回は必ず行っています。
そのため、今年EOLを迎えるPHP7.3からPHP8.0へのバージョンアップを行いました。
今回、対象となったサービスは2008年から続いてるレガシーシステムであることと、PHP8.0の変更点が多いことが重なり過去にないレベルの修正が必要となりました。
PHP8に対応するあたり発生する、次のような課題と、それに対する解決事例をご紹介します。
・影響範囲の調査と対応範囲の検討
・後方互換性の無い変更に対する対応
・静的チェックが難しい変更点に対する対応
・品質担保
息の長いサービスがPHP8対応する際に注意すべき点、大きな課題を発見した際にどのように解決したのかを具体的に紹介します。
これからPHP8対応を行う方々の一助となれば幸いです。

Discord Channel: #track3-a-php8-up

PhpStorm 使っていますか？
ご存知の通り、PhpStorm は、開発を効率的に進めるための機能がたくさん搭載されており、PhpStorm を使いこなして開発を進めている人の作業を見ると、素早いコーディングに驚かされると共に、自分も同じように PhpStorm を使い倒したいと憧れます。
しかし、一方でいざテクニックを覚えようとしても、何から覚えていけばいいかとっかかりがわからず、結局自身の知っている範囲でのショートカットやテクニックのみを利用してしまうといったことはないでしょうか？
このセッションでは日常の業務で役に立ち、かつ手をつけやすい PhpStorm のテクニックを段階ごとに解説し、徐々に PhpStorm エキスパートに近づく手助けをすることを目的とします。

$_GET["page"]、$_POST["name"]、$_SERVER ... PHP を初めて触った日、これらの変数を扱いませんでしたか？
これらの "スーパーグローバル" と呼ばれる変数は、初学時にこそ利用しますが、フレームワークを使い始めるとすぐに利用しなくなり、すでに忘れてしまった人も多いのではないでしょうか。
基本的にフレームワークの仕組みを使えば、これらの変数を利用する機会はない上に、中には設計上、セキュリティ上利用すべきでないとされている変数も含まれているため、PHP を扱っていてもあまり正面からスーパーグローバル変数を理解する機会は少ないと思います。
本セッションでは、PHP 初学者を対象に、スーパーグローバル変数をおさらいし、何気なく使わなくなったこれらの変数がなんだったのか、意外と理解していない使わなくなった理由について考えることで、PHP 初学者以降のスーパーグローバル変数との付き合い方を紹介します。

社内勉強会を開催したい！でも運営を続けられるか不安... という方は多いのではないでしょうか？

コロナ以前の2019年から毎月開催しているコミュニティイベント "PHP TechCafe" は、Web や PHP に関わる IT エンジニアがスキルアップを目指して意見交換を行うことを目的としています。
私が運営に参加することを決めたときには、自身の学習モチベーション向上にもつながるだろうと、軽い気持ちで活動を始めました。
しかし、実際に運営を続けると、コンテンツのネタ切れや集客不足、自身の知識の限界による不安など、想像以上に問題点が多く、今も試行錯誤している状態です。

本セッションでは、これから社内で技術系勉強会を開いて盛り上げようとしている方を応援すべく、月一でPHPのイベントを開催するにあたって心がけている、勉強会を継続させるためのポイントやノウハウ、今後考えていくべき課題を紹介します。

Discord Channel: #track3-3-b-community-operation

Composerには、Pluginという仕組みがあります。
Comopserに2.0が来るまでは、hirak/prestissimoにお世話になっていた方も多いと思います。(私もその1人です！！)

では、「どういうことが出来るのか」はご存知でしょうか。
「あの便利なComopserが、更に便利になっちゃうんですか？！」とワックワクな妄想をしてみたい・・・そのためには、まず「どういう事ができるのかな？」を知る必要があります。

知ることが全ての始まりです。
もしかしたら、あなたの仕事に革命を起こすような素晴らしい可能性が眠っているかもしれません。
(もちろん、「not for me!!!」と叫ぶだけの結果に終わる可能性もあります)

このセッションでは、「Composer Pluginとはなんだろう？」とイメージを掴むために、「どういう仕組みになっているのか」「どういう機能があるのか」を紹介したいと思います。

PHP8利用していますか？
フォトウエディングサービスのアプリケーションをPHP7.2から8系に上げた時の奮闘記を話します。

アプリケーションの言語バージョンアップって勇気入りますよね。
サービス運用・開発エンジニアとして担当サービスのアプリケーションは常に最新言語バージョンにしていきたい！と思いますが、
案件開発の優先度でどうしてもバージョンアップには手が付かない事もあると思います。

PHPバージョンアップを遂行し、開発者だけじゃない事業に関わるチーム全員が得られた素敵な話をしたいと思います。

• バージョンアップする意味を考える（メリット・タイミング・モチベーション）
• 優先度の持ち方。事業担当者理解への手配。
• 準備、実対応、リリースの話
• 効果とその後の開発記

【トーク対象】
・webサービス運用エンジニアの方
・アプリケーションのPHPバージョンを上げたいと思っている方

【その他】
大きなカンファレンスなどに登壇するのは初めてです。

Discord Channel: #track3-4-b-php8-up-by-ops

みなさんの運用しているアプリケーションはモニタリング（監視）されていますか？
サイボウズのGaroonではサーバーレベルのモニタリングはされていましたが、アプリケーションレベルのモニタリングは今まで十分には行われていませんでした。
そのため、お客様からのお問い合わせがあって初めて障害に気がつくことが多くなっていました。
また、発生している問題の重大さもうまく把握できていないため、どれくらい優先して障害対応をすべきなのか、本当に障害として対応するべきなのかといったコミュニケーションを、SRE・ビジネスメンバー・サポートメンバーなどの社内の他のメンバーとうまく取れていない、という問題もありました。

そういった状況から脱却すべく、昨年からアクセスログの集計やメトリクスの収集を行い、必要に応じてアラートを飛ばすモニタリングの仕組みを導入しました。
このセッションでは、モニタリングをどのように導入したのか、モニタリングで得られた数値とお客様に与えている不便さをどう結びつけたか、モニタリングによって開発チームと社内の他のメンバーとのコミュニケーションにどのような変化があったか、いまモニタリングで苦労していることをお話しします。

Discord Channel: #track3-2-a-php-monitor