RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

PHPerKaigi 2022【参加レポート】

配配メール開発課Jazumaです。

2022/04/09(土) ~ 04/11(月)の3日間に渡ってPHPerKaigi2022が開催されました。 今回は初のハイブリッド開催となり、現地・配信ともに大盛況でした。

このイベントは日本PHPユーザ会主催のイベントで、ラクスはスポンサーとして協賛させていただいています。

phperkaigi.jp

ラクスからは3人が登壇した他、多くのメンバーが参加しました。
そこで今回は参加者によるレポートを紹介させていただきます。

PHP関連の取り組みは以下をご確認ください!
 
PHPイベント
PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe
参加申込はこちら
forms.gle
PHP関連記事
毎月開催しているPHPerのための学習コミュニティ、PHPTechCafe【21年度 まとめ】
ラクスによる The PHP Foundation への寄付について

4/9 (土) 前夜祭

PHPのエラーを理解して適切なエラーハンドリングを学ぼう

report by id:Jazuma

株式会社弁護士ドットコム 所属並里さんによるセッションです。 PHPのエラーとエラーハンドリングがテーマでしたが、特にエラーハンドリングの部分が興味深かったです。

speakerdeck.com

  • エラーハンドリングについて

  • エラーハンドリングの目的

    • エラー発生箇所・原因の特定
    • 処理を中断する
    • ユーザにエラーを知らせる
  • エラーハンドリングで大事なこと

    • 例外を握りつぶさずに適切に対応する。
    • エラーハンドリングのスコープを狭くする。
    • 捕捉すべきものとそうでないものを区別する。

エラーハンドリングのスコープを狭くするとエラーの原因特定がやりやすくなると思いました。

エラー監視とテスト体制への改善作戦

report by id:Jazuma

株式会社ウエディングパーク所属ヒエイカザトさんによる発表です。

speakerdeck.com

  • エラー監視体制

(改善前) エラーを監視する仕組み自体はあったものの、監視が不十分だった。(既存エラーは非対応・自分が担当した機能以外は無視等)

(改善後) エラー内容や日付別のエラー数・内容を集計して、発生回数の多いものから対応する監視体制を整備した。

  • テストコード

エラー監視体制はできたので、次のステップとしてテストコードの整備に取り組む。

  • 実施した作業
    • Dockerでテスト実行
    • モックを使って外部アプリケーションに依存しないテストコードを設計
    • GitLab CI上での自動テスト

当初はカバレッジ向上が目的となり、品質が向上しなかったがペアプロや認識合わせにより解消

  • 施策の活性化

  • 多職種へのアピール

  • テックブログでの情報発信

エラー数やカバレッジ定量化しつつ、定量化だけでは解決できない品質や施策の拡大をチームの運用フローでカバーする取り組みが印象的でした。

4/10 (日) 1日目

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント

report by id:Jazuma

和田卓人さんによる発表です。 Takuto Wada (@t_wada) / Twitter

speakerdeck.com

  • よくある防御的プログラミングの誤解
    • ひたすら入力値をチェックする
    • 不正な入力値を自分で何とかしようとする
    • コメントやPHPDocで補足する

防御的プログラミングとは既存の悪いコードへの対処療法ではなく、問題発生を事前に防ぐためのコーディングスタイル

  • 正しい防御的プログラミング
    • 型やenumによる防御 (不正な値をはじくのではなく、不正な値が来ないようにする)
    • クラスのプロパティで仕様を表現する
    • 不変オブジェクトで予期しない変更を防ぐ(値を変更する際はプロパティを変更するのではなく、新しいインスタンスを返す)
    • 常に正しいオブジェクトのみ存在させる(コンストラクタに不正な値が渡された場合、例外を送出してインスタンスを生成させない)
    • 責務の配置(結果の正しさを担保するレイヤーと動作を担保するレイヤーを分ける)

不正な値を存在させるのはついやってしまいがちな設計だと反省しました。

MongoDB に溜まった約1.6億レコード、データ量1TBのあらゆるサイトの記事データを BigQuery で高速検索できるようにした話

reported by id:hirobex

植江田和成 (@developer_kazu)さんによる発表です。

MongoDBに溜まった1.6億レコード、データ量1TBの記事データを BigQuery に移行しようとした際に出た課題と、解決方法を紹介していただきました!

  • 昔のデータと最近のデータでカラム数が違うため、エラーが出る
  • カラムの順番が違い、型エラーが発生した
  • 壊れたデータ存在していて、エラーがでる

などといった課題に対し、

  • カラムの存在チェックを行い、存在しない場合はnullを代入
  • 配列の構造を固定化する
  • データを小分けにすることで、エラー発生箇所を特定

といった方法で解決したとのことでした!

動的スキーマのMongoDBから、静的スキーマのBigQueryへデータ移行するのは一筋縄ではいかないことがわかりました。

PHPとGraphQL

reported by id:hirobex

永野 峻輔 (@glassmonekey)さんによる発表です。

speakerdeck.com

  • GraphQLとREST APIの違い
  • GraphQLを採用することのメリット・デメリット

といった、GraphQLの解説をした上で、PHPでGraphQLを採用するための話をしていただきました!

非常にわかりやすく、PHPでGraphQLに挑戦したい人におすすめの発表でした!

新卒 Laravel 初心者が成長していく中で感じたコレジャナイ感

reported by id:hirobex

ふわせぐ (@fuwasegu)さんによる発表です。

speakerdeck.com

Laravelはすごく便利なライブラリですが、考えずに使ってしまった結果、感じるようになってしまったデメリットと それに対する解決のアプローチを紹介していただきました!

簡単にまとめると

  • 依存関係の混沌化
    • Facade離れをしよう
  • 責務の肥大化
    • Model・Controllerだけではなく、UseCaseを導入しよう
  • 重くなるテスト
    • Featureテストだけでなく、Unitテストを適宜導入しよう

という内容でした。 Laravelを使っていて、同様の課題を感じている方は、ぜひ聞いてみてください!

メルカリ、巨大モノリスにおける複雑性をリリース9年目にしてどう解決するか

reported by id:hirobex

安達 勇太 (@uadachi)さんによる発表です。

speakerdeck.com

巨大モノリスにおける課題と、モジュラーモノリスに移行するための戦術を紹介していただきました!

といった具体例をあげて説明していただきました。

モジュラーモノリスを扱ったセッションは多く、多くの長寿サービスで使われているPHPの課題なのかもしれませんね

PHPで「時間がかかる処理」を並列でブン回す

reported by id:MasaKu

kiridarumaさん(@kiridaruma)によるセッションです。

www.kiridaruma.net

並列処理を実行する上での基礎的な知識やPHPでの並列処理の実現方法などのご紹介でした。 まず、知識の整理として以下のようなことをご説明いただきました。

  • 並列処理
    • 同時に複数の処理を進めること
  • 並行処理
    • 複数の処理を直列で少しずつ進める

PHPでは GeneratorFiber という仕組みを利用することで並行処理が実現できますが、並列処理を実現するためにはOSの力を借りることになります。

また、ここで重要なキーワードとして「スレッド」と「プロセス」という言葉が登場します。

  • スレッド
    • 他のスレッドとメモリを共有する
      • うまく利用しないと意図しない挙動を起こす
  • プロセス
    • 他のプロセスからメモリは隔離される
      • 入出力周りに気を付ければ何とかなる

基本的にはマルチスレッドにしてもパフォーマンスはそこまで大きな差がないレベルとのことですので、マルチプロセスでコードを書いた方がバグを生みにくいため、まずはマルチプロセスを実現できるようになることが重要かと思いました。

PHPでマルチプロセスを実現する以下のコマンドが紹介されていました。

いくつかの違いがありますが、php.net を読んで自分の用途に合ったものを利用するのが良いとのことでした。

実例としてまして、DBで大量のデータ移行等をされる際はマルチプロセスで並列実行したほうが良いとのことでしたが、サーバスペックに依存するため、比較的サーバスペックに余裕があるサーバを利用されたようでした。

また、長時間走行するようなバッチ処理でありがちなこととして、よくわからないタイミングで失敗していることなどが紹介されておりました。

そんな時に便利なのが、ログ出力をしっかりとしておくこと、とのことでした。ログ出力時はプロセスごとに詳細なログを出力することが重要ですが、ログファイルを出力する際はファイルのロックに注意が必要とのことです。

また、バッチ処理を作成する上での基本的なこととして、シグナルハンドラは必ず設定することが挙げられていました。 例えば、親のプロセスを終了した際に子のプロセスも併せて終了する、などもしっかりと定義しておくべきとのことでした。特に、正常終了した際と異常終了した際のexitコードは当たり前のお作法として今後も気を付けていきたいです。

どういうときに並列処理でコードを書くべきか、また、実現時はどのようなことに気を付ければよいのか、ということの気づきになるご発表と感じました!

作って遊ぼう!Composer Plugin

reported by id:takaram

きんじょうひできさん (@o0h_) によるセッションです。

speakerdeck.com

今やPHPでの開発にほぼ必須ともいえるcomposer(今年で10周年!)ですが、実はプラグインを作るといろんなことができるよ、というお話です。

composerプラグインには大きく以下の2種類があります。

  1. 独自コマンド(composer hogehogeみたいなもの)を登録するもの
  2. composer の各種イベントをフックするもの

2つ目については、composer でフックできるイベントはかなりいろいろあるようで、

  • 各種コマンドの実行前
  • パッケージのインストール前後
  • autoload.php の更新前後

や、他にも種々のタイミングで処理を差し込めるようです。 これがすぐに役立つかはわかりませんが、どんなことができるか知っておけばいざというときの選択肢として使えるかもしれませんね!

計測ことはじめ 〜アプリケーションを知るために〜

reported by id:hirobex

清家史郎 (@seike460)さんによる発表です。

speakerdeck.com

  • なぜ計測するのか
  • なにを計測するのか
  • どのように計測するのか

といった、計測についての基本を教えていただきました!

パフォーマンスに課題感を持っている方は解決の一端になるかも……?

何でもキレイにiterationする方法を考える in PHP

reported by id:hiro_ji

ぬさしさん(@nukisashineko)による LT です。

speakerdeck.com

PHPのforeachをシンプルにするポイントをご紹介いただきました。

  • 配列操作を分類整理して、1つのforeachで1つのことだけ行う
    • 変換、グルーピング、集約等の配列操作はひとつのforeachで行わない
    • 記述が冗長化した場合は関数化
    • 遅延処理にはGenaratorを利用する
    • 並列処理にはPromise + Genarator を利用する

思い返してみると、私自身もスパゲティ気味な繰り返し処理を書いた記憶があるので、 foreachにフォーカスした今回の内容はとてもためになりました!

割とアプリケーションが大きくなってから PHPStan を入れた時の体験談

reported by id:takaram

株式会社 DROBE の都筑さんによる LT です。

プロジェクトの途中から PHPStan を導入した経験を語ってくださいました。 Level と Baseline を調整していきながら、以下のように段階的に PHPStan を導入していったそうです。

  • コマンドラインから手動実行する形で導入
  • CI に導入
  • Level を 0→1→3→5 と上げていく

方針として掲げた「頑張りすぎない!」が大事なところだろうと思いました。 こういうツールを導入するときは、つい張り切ってあれもこれもやりたくなってしまいがちな気がするのですが、一足飛びせず無理しない程度に一歩ずつやっていく「急がば廻れ」を心に留めておきたいですね。

Webサービスのバウンスメール処理の事始め

reported by id:hiro_ji

BASE株式会社の炭田さん(@tac_tanden)による LT です。

speakerdeck.com

Webサービスにおけるバウンスメール処理について、その役割と利用方法をご紹介いただきました。

  • バウンスメールとは
    • 何らかの理由で正常に配信されなかったメールのこと
  • バウンスメールが極端に多い(バウンス率が高い)と...
    • 送信者の評価が下がり、スパム扱いになってしまう可能性
    • ユーザに届けたいメールが届かない
  • バウンス率を抑制するには
    • バウンス回数が多い傾向にあるアドレスリスト(サプレッションリスト)への配信を停止する

弊社のメール配信サービスでもバウンスメール処理を扱っていますが、より確実にユーザにメールを届けるうえで重要な役割を担っていると改めて感じました。

本当にあった怖いPHPコード7選

report by id:ryo479

speakerdeck.com

実際に開発現場で見かけた怖いコード(可読性、保守性が明らかに低いコードなど)を7つ紹介されました。

  1. メソッドの引数が7個以上あって、変数名はアルファベットを並べただけ
  2. if文のネストが6個以上ある
  3. 変数名がわかりにくい
  4. 一つのアクションメソッドに裏で3つのエンドポイントが存在している
  5. コメントアウト地獄
  6. マジックナンバー地獄
  7. 一つのファイルに2つのクラスが定義されている

たしかに怖いですね...。 分かりにくい変数名は割と見かける気もします。
自分では分かりやすく書いているつもりでも、他人からは分かりにくいということも往々にしてあるので、コードレビューは重要ですね。

Predefined Interfacesを使って便利な独自クラスを作りましょう!

report by id:ryo479

speakerdeck.com

PHPの言語側に定義済みのインターフェースである「Predefined Interfaces」についての発表です。

  • Predefined Interfacesとは

    • PHP側に定義済みのインターフェース。実装すると、PHPエンジン自体の機能が提供される。

www.php.net

発表では、定義済みインターフェースの「Stringable」「Traversable」「Iterator」を使用したコードを元に説明されました。 定義済みインターフェースをどのように使用すればいいのか、どのようなメリットがあるのかがよく分かる内容でした。

PHPerだってPHPから「OKグーグル」したい!

report by id:ryo479

speakerdeck.com

GoogleアシスタントPHPプログラムからアクセスして、「OKグーグル」するという遊び心あふれる発表です。
Googleアシスタントの裏側はgRPCなので、PythonやGoで実装されることが多いとのこと。 しかしPHPもgRPCの正式サポート言語なので、やればできるはずなのでやってみようという試みです。
発表では実際にGoogleアシスタントPHPでアクセスし、アレクサを操作して部屋の照明を消すというデモンストレーションもあり、興味を惹かれる内容でした。

4/11 (月) 2日目

PHPとゆかいな「型」たち

report by id:tsudachantan

株式会社ユニラボの石揚千洋さん(あげさん)によるセッションです。 改めてPHPの「型」の種類や使い方、メリットデメリットや実践についてわかりやすくお話いただきました。

fortee.jp

  • 型って何?
  • プログラミング言語における型(静的型付け、動的型付け)

    • 静的型付け
      • プログラムの実行前に型が決まっていて、人間がコーディング時に型を指定する
      • 関数の引数や返却の型指定が合っていないとコンパイル時点でエラーになる
      • 型安全性がある
    • 動的型付け
      • プログラムの実行前に型が決まっておらず、実行時に内部で型定義される
      • 設定や書き方によるが型安全性が少し弱い
      • 強い動的と弱い動的がある
    • PHPインタープリタ言語
  • PHPのゆかいな型の紹介

    • 動的型付けだけでなくコーディング時に型宣言できる
  • 型宣言の使い方(メリット、デメリット)

    • 引数の型指定ができる
    • !!実はPHPは型指定しても、キャスト可能なものはキャストしている!!
    • 型変換がうまくいかない場合にエラーになる(PHPのデフォルトはこれ)
    • 強い型付け(型が違うとそもそもエラー)にするにはPHPの場合設定が必要→strict_types=1
  • 型宣言のメリット、デメリット

    • 〇型がわかるので変数を使いやすい
    • IDEなど使えば候補を出してくれて便利
    • 〇大規模開発は大きなメリット
    • 〇型安全でバグが出にくいかも
    • ×設定次第で暗黙的に型変換
    • ×arrayを使うと何でもよくなってしまう
    • ×きちんと設計しないと破綻する
    • ×小規模開発ではメリット薄い

型とは何か?というとこからPHPでの型の挙動までおさらいすることができました。 「型」をあまり意識せずプログラムしてもなんとかなる時代は過ぎ去り、ほんの少しの抜け穴が大損失になるレベルまでインターネットは広まり、PHPでもバージョンアップにつれてかっちり型を縛ったstrictプログラミングがほぼ主流となりつつあります。 PHPの柔軟性を理解したコーディングに役立つ内容ですので、ぜひ聞いてみてください。

PSR-7とPSR-15によるWebアプリケーション実装パターン

reported by id:takaram

うさみけんたさん (@tadsan) によるトークです。

tadsan.fanbox.cc

PHP で HTTP を扱う際によく登場する PSR-7 / PSR-15 とは何で、どんなメリットがあるのか、どうやって使うのか?といったことを解説する内容です。

  • PSR-7
    • HTTP リクエスト、レスポンス、URI など、HTTP メッセージに関わるインターフェースを定義している
  • PSR-15
    • HTTP ハンドラ、ミドルウェアなど、Web サーバの実装に関連するインターフェースを定義している

PHPフレームワークを使わなくても簡単に、$_GET, $_COOKIE 等でリクエスト情報を取得し、header(), setcookie(), echo等で HTTP レスポンスを作れるわけですが、簡単で自由度が高すぎるがゆえに、無秩序になりやすいという面もあります。 そこで PSR-7, 15 やそれを使ったフレームワークを利用することで、以下のようなメリットを得られるということです。

  • コードの見通しがよくなる
  • テストがしやすくなる
  • 従来の mod_php, PHP-FPM のような、リクエストごとに状態がリセットされる環境以外でも動かしやすい
    • RoadRunner, Swoole など

節冒頭の URL には、スライドの他にサンプルプログラムのリポジトリ URL も掲載されているので、一度見てみると PSR での HTTP の扱いへの理解が深まりそうです!

ラクスからの登壇セッションのご紹介

ここからは弊社から登壇させて頂いたセッションの内容をご紹介します。

今だから話せるPHP8バージョンアップの裏側~全5サービスの事例紹介~

report by id:radiocat

speakerdeck.com

PHPで開発されている弊社の全5サービスの事例をもとにPHP8バージョンアップをどのように行ったのか、その裏側をご紹介する内容でした。PHP8では様々な新機能がリリースされていますが、特に影響が大きいのが「下位互換性がなくなる変更」です。「==」の比較結果や関数に指定する引数の型の扱いなど、これまで緩やかに扱われてきたものが厳格化され、挙動が変わったり、エラーになったりします。
そのような影響の大きなバージョンアップに対して全サービスから代表者が選抜されて密に情報共有しながら対応を進めました。特に、これまでの緩やかな仕様を受け入れてきた歴史の長いサービスでは影響が大きく、ツールなどの仕組みでの対応も難しく、調査範囲、テスト範囲とも大きくなったようです。最終的にこれまでのバージョンアップ対応よりも最大で約10倍の工数がかかったとのことでした。それでも防ぎきれなかった不具合も今後PHP8バージョンアップに取り組む際に役立つ情報として共有されています。
影響は大きいものの、近年PHPが取り入れている新機能を使えるメリットもあるため、情報共有を大切にしながらポジティブに取り組むことが大切 とのことでした。

発表者:久山勝生 /(@MasaKu_e
◆ 登壇を終えて

PHPerKaigi は以前より参加させていただいているイベントで、昨年は残念ながら非採択であったこともあり、今年こそは是非ともスピーカーとして参加したいという気持ちで登壇にチャレンジしました。
 
今回発表させていただいた、PHP8バージョンアップは規模の大きな対応であったため、各商材のノウハウや苦労などが詰まった内容になるという印象がありましたが、それゆえに情報の取りまとめやストーリーの組み立てには苦労しました。
発表当日は、弊社の取り組みについて共感してもらえる声や決められたタイミングでバージョンアップが計画されている点に賛同の声が頂けて嬉しかったです。
「次のPHPバージョンアップの対応についても共有を待っている!」とのコメントも見受けられましたので、機会があれば再チャレンジできればと思いました!

新卒PHPer奮闘記 ~配属されたのは3歳違いのプロダクト!?~

report by id:ryo479

speakerdeck.com

2021卒で新卒入社した弊社社員が、2001年リリースのプロダクト開発に携わるにあたって苦労した経験と、その乗り越え方を発表しました。 苦労した点としては以下を上げています。

ノンフレームワークで独自の実装がされていたり、レガシーコードだったりすると苦労しますよね。 新卒であればなおさらです。 改善を進めようにもある程度大きなシステムだと、簡単にはいかないのが難しいところです。
研修内容やドキュメントの整理、そして周りの方のサポートが重要だと再確認できました。

発表者:廣部知生@tomoki2135
◆ 登壇を終えて

PHPerKaigiに初参加、初LT登壇をしました!
新卒入社後初めてPHPに触れたため、勉強兼PHPerコミュニティを知るということで参加を申し込みました。
CfP作成からスライド資料の作成まで、登壇なれした先輩方にレビューしていただいたおかげで無事採択され、LTも盛況に終わりました!
個人的には、小桜エツ子さんに自分の名前を読んでいただけたのが嬉しかったです。
次回も機会があれば挑戦したいなと思います!

どんとこい、PhpStorm 〜Why don't you do IDE's best!〜 / Don't KOI PhpStorm!! Why don't you do IDE's best!!

report by id:radiocat

speakerdeck.com

PhpStormはPHPの代表的なIDEの1つでJetBrains社が開発しています。稀に「PHPStorm」と表記されることがありますが、JetBrains社のブランドガイドラインには「大文字と小文字を区別してください」と書かれており、まず「PhpStorm」と覚えてくださいと呼びかけられました。 そして、脱PhpStorm初心者を目指すための3段階のテクニックが紹介されました。

  • Level1:補完機能を使いこなす
  • Level2:検索を使いこなす
  • Level3:リファクタリング機能を活用する

しかし、何よりも先に 「PHPStrom」じゃなくて「PhpStorm」 という事を覚えておきましょう。

発表者:加納悠史 @YKanoh65
◆ 登壇を終えて

いつも参加させていただいているイベントなので、今回もぜひ登壇者として参加したいと思い、応募しました。
今回、CfPは3案出したのですが、実は一番トーク内容に自信がないものが採用されたので、自分自身が普段使っている PhpStorm の小技だけでなく、チームの PhpStorm に強いメンバーへのヒアリング結果も併せて記載することで、普段から使いこなしている人でもなにか新しい発見がある発表にできるようにしました。
 
当日は、久々のオフラインイベントでの登壇だったため緊張しました。無事ウケてよかった...
普段 PHP TechCafe などでお話させていただいている方々も多く、イベント期間中は、始終楽しく過ごすことができたとともに、いろいろなセッション、LT、アンカンファレンスを聞いて刺激を受けることができました。
 
次回もチャレンジしたいと思います!

まとめ

コードの内部品質向上・既存プロジェクトへの新ツールの導入等、今あるプロダクトをいかに改善していくかという観点の登壇が多かったように思います。 また、弊社のPHPバージョンアップに関して、多くの方に言及していただきました。

PHPという技術が成熟していることの現れなのかもしれませんね。

PHPerのためのコミュニティ PHPTechCafe

ラクスではPHPに特化したイベントを毎月開催しております。その名も「PHPTechCafe」!!
次回は4/22(金)に『「PHPer Kaigi 2022 を振り返る」』 をテーマに開催します!
まだまだ参加者を募集していますので、ぜひお気軽にご参加ください。

👉PHPerのための「PHPer Kaigi 2022 を振り返る」PHPTechCafe」PHPTechCafe

参加申込は以下フォームよりお願いします!
forms.gle

最後までお読みいただきありがとうございました!


◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

Copyright © RAKUS Co., Ltd. All rights reserved.