ランサーズ（Lancers）エンジニアブログ > PHP > PHPerKaigi 2023に初参戦してきました！

PHPerKaigi 2023に初参戦してきました！

takahashi.hirokazu｜2023年03月31日
PHP

こんにちは！ランサーズのオラインマッチングエンジニアチームの高橋(@t_sumsum)です。

新卒エンジニアの私と、同期の種井さんの二人でPHPerKaigi 2023に３日間参加してきました。人生初のテックカンファレンス現地参加です！ワクワク！

LancersはゴールドスポンサーとしてPHPerKaigi 2023の協賛をさせていただいています。

「1.現地レポート編」「2.トークの感想編」の二つを興奮が冷めないうちに一気に書いていきます！！

1. 現地レポート編

三日間前日雨という花粉症の僕には最高の天候の中開催されました🍭

駅からここねりまでの道 PHPerKaigi入り口ののぼり

終始お祭りのような雰囲気でめちゃくちゃ楽しかった！

前夜祭開始前の様子

PHPerKaigi会場

さりげなくピースをする種井くん

アンカンファレンス

アンカンファレンスは誰でも参加・発表できるLTスペースです。自由な内容でさまざまな発表がされていました！

ノベルティ

会場に来れなかったいさなさん(@isanasan_)のためにノベルティも確保！

ノベルティ

お菓子や飲み物もたくさん用意してくださいました。

おもしろポイント

アイドルのライブのようなLT会（なぜかペンライトも貰えた）

PHPer大喜利も面白かったですね。

2. トークの感想編

全体を通して

他の会社と自社の開発を比較して、できていることできていないこと、使われているツールの比較、今後自社でも抱えそうな問題を解決している内容、、、など実践的な学びがたくさんあったことがよかったです。また、phpunit.xmlやdockerfileなどほとんど触ったことのないファイルを知ることができてPHPの理解の幅がだいぶ広がった気がします。カンファレンス良いですね。

以下の内容は高橋の完全個人の感想です。誤っている点ありましたら教えていただけると🙏

Day0

名著「パーフェクトPHP」のPart3に出てきたフレームワークを令和5年に書き直したらどんな感じですかね？

登壇紹介

生のPHPによる古のWebアプリの歴史の話から始まり面白かった。最新のフレームワークに求められていることはcomposer、DI、静的解析と自動化テストなど。セキュリティはミドルウェアに頼る。追加、刷新されゆくPSRに合わせた開発→「抽象に頼る」程度で捉えるのがよき。

 

名付けできない画面を作ってはならない – 名前を付けるとは何か

サービスへの愛着が大事。

目的のある、みんなで合意が取れた名前をつけよう。

技術負債とプロジェクトと私たち 

lancersでも同様の問題を抱えているためうんうん頷きながら聞かせていただいた。ユニットテストに関してはFixtureFactoryなどフレームワークにあるものを使うのが良いのかなと感じた。

テストコードを書く文化を浸透させるための葛藤とその軌跡が学びになった。

 

PHPUnit 10 概論

主に9 →10での変更内容の話

そもそもでphpunit.xmlの設定ファイルを触ったこともなかったのでPHPUnit初歩の初歩から学びだった。

subscribe, extentionを使ったテストはイベントの開始・終了時にメッセージを送れる例を見ただけでも良さそうだった。

attribute→propertyに名前が変更したがattributeに関するメソッドが全て削除され、property用のものは用意されてないものが多い（辛いポイント）

ログの色を変えられるようになった。色覚の方向け。アクセシビリティ観点。

phpunit.xmlにこんな感じに書く

<logging> 
　　<log type="coverrage-html" target="report"
    colorSuccessLow="#{any color code}"
    colorSucessMedium="#{any color code}"
    colorWarning="#{any color code}"
    // ...
/>
</logging>

差別的な用語のクラス、プロパティ、オプションの変更はいいね。

アンドキュメンテッド「ちょうぜつソフトウェア設計入門」

オブジェクト指向は宗教、宗教は民衆が受け入れやすいように歪んで伝わる。ゆえに燃える。

オブジェクト指向は元々オブジェクト単位での概念の話だったのにもっと具体なクラスのカプセル化などの具体化したものをオブジェクト指向と呼ぶようになり認識に差が生まれた。そのような認識の誤解や歪んだ理解があるため燃えやすいしそれが現実。

本来のオブジェクト指向の抽象部分の理解が大切だなと感じている。（個人の見解です）

Day1

防衛的 PHP: 多様性を生き抜くための PHP 入門

途中から参加

諸々のライブラリの話（rector, ecs(コンテナじゃないよ), PHPStanなど）

本筋ではないがPHPStormはPSRの設定があるのかすごい。

// これでrectorやらPHPStanやら全部入れられるよという便利なやつ
composer require —dev \ quartetcom/static-analysis-kit:~8.1

Composerを「なんとなく使う」から「理解して使う」になる

composer requireの話：　composer require –devで開発環境のみ, no-devで本番環境のみ

開発環境、本番環境で同様のdockerfileを使える。

Dockerのマルチステージビルド→必要パッケージだけを入れられる、冗長な記述を回避

Composerの基礎からDockerでの利用の話までめちゃくちゃわかりやすかった。

データの民主化はじめました 〜俺たちの民主化はこれからだ〜 

1.BIツール導入しても誰も使ってくれない

  • 必要だったことは、
    • 自分がやる：非エンジニアの具体的な使い方を説明する→まずは自分がやる
    • 文化を作る：成功例を示してデータ活用の文化を作る

2. やったこと（具体）

  • 他の人のやっていることに関するデータを勝手に分析して勝手に提案する
  • データの見方教えてください→周りの人が私にも教えてくださいとなっていく→文化の醸成

    Rector ではじめる “運用を止めない” PHP アップグレード

    Rectorを使うことで自動的にリファクタしてくれる。

    Rectorできること：PHPStan（静的解析） + PHP-Parser ⇒ RectorによるPHPDocを考慮した型推論・リファクタリング

    PHP7.4 / PHP8.1で動作するコードベースの維持→移行期間中開発側で意識する必要がない（運用を止めない）

    Rectorではたくさんのルールを決められるのでLaravelマイグレーション用ルールなどそれぞれ必要なものを使うとめちゃ良き

    こう考えるとやっぱりTypeScriptってすごいな、、、

    クローズドなサービスをIdentity-Aware Proxyを使って安全に公開する

    VPN、固定IP使わずアクセス制御が可能なGCPのサービス

    https://cloud.google.com/iap?hl=ja

    AWSにも同じようなサービスがあったらな、、、

    アプリに対しては認証されたリクエスト以外飛ばない

    →比較的楽にセキュアな認証が行える

    ローカルでの開発環境構築は課題だそう。

    パフォーマンスを改善せよ！大規模システム改修の仕事の進め方

    レイテンシーの遅い状態の改善をするにあたって最初からSQLチューニングだと決めつけるのではなく、計測をして実際にSQLが原因だという裏打ちをとった上で改善をしていて「推測するな、計測しろ」の通りのことを行なっていて参考になった。

    具体策

    • INDEXの調整、ORDER句の削除
    • 不要なキャッシュをとっているところを削除

    パフォーマンス改善のツールや手法の勉強は超大事（QcacheGrindとか知らないことたくさんあった。

    結論：計測せよ

    • 課題を見つけるための包括的な計測
    • 遅い場所を知っていても計測
    • 効果測定の計測

    Day2

    PHPの最高機能、配列を捨てよう！！ 

    配列ってめちゃくちゃいろんな使い方あるんやな、、

    配列に旅をさせない

    • すぐ展開してしまおう

    データ取得にはDTOを解するとよい（データベースと1:1にする必要がないのがいいね）

    APIの設計にはreadonlyを使おう

    本質的には静的解析を使える状態にすることが一番大事（機械が理解できるように書く）

    いろいろなフレームワークの仕組みを index.php から読み解こう

    ApacheやnginxでPHPを利用すると全てのリクエストをindex.phpでハンドリングするようになっている。ちゃんと根元の実装を辿ると面白い。

    Composerのautoload.phpなど、普段自分が使っているものを確認しながらみるのが楽しい。

    FWを利用した時のリクエスト→レスポンス→画面表示の流れが大まかに理解できてよかった。

    CakePHPもLaravelもSlimもSymfonyも大体やってることは一緒(Symfonyはちょっと特殊)

    Attributeを極める

    スライドリンク

    関数やクラスなどの直前のDoc コメント、Reflection （getDoc()）を使って読み取ることができる

    アトリビュートはコンピュータが解析できる構造化されたメタデータを定義するもの。Reflection APIを使う。

    Docとの違い静的解析ツールが自然にサポートしてくれる。Docでは変な記述をしても気づきにくい。

    活用事例は模索中だが、DIとの相性が良いかも

    パッケージやFWを作成する人が使うものなのかなという印象

    Laravelへの異常な愛情 または私は如何にして心配するのを止めてEloquentを愛するようになったか

    Eloquentを利用したときにwithでなくjoinを使うのはよくない -> ORMで完結させる。

    リソースルートやRoute Model Bindingによりコード量を削減する。

    S3などのデータをLaravelのStrageなどの抽象のみによって管理するべし。依存性注入もLaravelの基本機能に装備されている。

    素のLaravelを使うことが最大限Laravelを活用するために必要で、それを周知することが大切。

     

    最後に

    実際に現地で参加してみないと分からないことがたくさんあり、本当に素晴らしい経験をさせていただきました。また、優秀な方々や第一線で活躍されている方々と対面で話せる貴重な機会でもありますね。今回は勇気がなくてあまり話しかけられなかったので、次回は頑張ります。

    今回得た知識を業務にも活かし、来年こそはPHPerKaigiで登壇できるように頑張りたいと思います。また、今後も知見のシェアや、イベントへの協賛など、コミュニティ活動に貢献していきたいと考えています。

    最後に、改めてPHPerKaigi 2023実行委員会の皆様に、心より感謝申し上げます。

     

     

    関連記事

    1. PHP、CakePHPバージョンアップの決断
    2. PHPカンファレンス福岡 2017に登壇しました
    3. PHPカンファレンス福岡2018に登壇しました
    4. PHP Conference Japan 2021にランサーズのエンジニアが登壇します！