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

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

PHPerKaigi 2023【参加レポート】

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

2023/03/23(木) ~ 03/25(土)の3日間に渡ってPHPerKaigi2023が開催されました。 今回も前回に引き続きハイブリッド開催となり、現地・配信ともに大盛況でした。

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

https://phperkaigi.jp/2023/

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

3/23(木)前夜祭

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

report by id:rakuinoue
きんじょうひできさん (@o0h_)による発表です speakerdeck.com

レポート

2010年頃、同様にMVCフレームワークを作成し社内に広めていた身からすると、非常に刺さる内容でした。
当時と比べると、

  • Composerの登場・PSR-xxなどのデファクト化が進む
  • PHPのバージョンアップに伴う型に関するサポート・静的解析の普及
  • フルスタックより、様々なライブラリを組み合わせていく
  • これに伴う抽象化やDIの概念の必要性

等が変わってきた内容として挙げられていました。
改めて設計技法等含めて、おさらいできる良い内容だったと思います。

ある日オレオレフレームワークを作りたくなったぞ!!

report by id:akikuchi_rks
果物リンさん(@FruitRiin)による発表です

レポート

独自で作成したフレームワーク、いわゆるオレオレフレームワークを作成した過程をお話しいただきました。
composer initフレームワークの雛形を作成するところからPakegistに公開するところまでプロジェクト作成の全体の流れを知ることができ、とても勉強になりました。
また、発表の冒頭ではオレオレフレームワークの歴史的背景が語られていたのですが、2000年代初頭の今普及しているようなフレームワークが登場していない頃には 当たり前のようにオレオレフレームワークが作られていたというお話には衝撃を受けました。
登壇者もお話ししていたようにオレオレフレームワークはセキュリティの問題や引継ぎが大変という理由から現代のプロダクションに活用するのは難しいと思いますが、 今回のようにフレームワークを1から作ってみることは普段意識していないフレームワークの内部的な仕組みを知ることができ、かなり役立つのではないかと感じました。

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

report by id:mrstsgk_rks
ちゃちいさん(@chatii)による発表です speakerdeck.com

レポート

トーク名は「名付けできない画面を作ってはならない」ですが、画面についての話ではなく命名についての話になります。 名前をつける大切さが伝わる発表でした。特に名前を付けて認識を共有するについて、ユビキタス言語の例は納得できました。 また、技術的な発表で心理学の概念(愛着理論)が出てきたのは面白かったです。

最後に、リーダブルコードはやっぱり良書でした。

3/24(金) 1日目

作って理解するバックドア

report by id:hirobex
Rokuさん(@ad5jp)による発表です speakerdeck.com

レポート

バックドアを設置されるとどうなるのか
なぜバックドアが設置されてしまうのか
バックドアの攻撃手法
バックドアを設置されないようにするには

といった、バックドアに関する知識が詰まったトークでした 中でも、実際に採集されたバックドアのサンプルは一見の価値ありだと思います!

時間を気にせず普通にカンニングもしつつ ISUCON12 本選問題を PHP でやってみる

report by id:hirobex
sjiさん(@sji_ch)による発表です speakerdeck.com

レポート

ISUCON12優勝チームのレポジトリを参考にしつつ、PHPでハイスコアを目指すという内容でした
データベースのボトルネック解消後、徐々にGoと引き離されて行く中で、
いかにPHPとしてアプリケーション側のスコアを上げていくのかという挑戦が非常に面白かったです

Webアプリケーションパフォーマンスに興味のある人は、ぜひ見るべきトークだと思いました!

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

report by id:hirobex
しけちあさん(@s6n_jp)による発表です

レポート

多様性を生き抜くためにどのような防衛手法が取れるのか、という話から始まり
PSR-12などの規約や、様々な静的解析ツールの使い方を紹介していただきました
コード品質を担保するために、静的解析を使ってみたい人におすすめのトークです!

個人的に、このトークで紹介されていた「Rector」というツールが気になりました✍

詳説「参照」:PHP 処理系の実装から参照を理解する

report by id:mrstsgk_rks
nsfisisさん(@nsfisis)による発表です
github.com

レポート

PHPにおける参照の不思議クイズから始まり、 PHPの内部でどのような処理が行われているかの解説を挟んで クイズでの参照の挙動を説明していただき、PHPにおける参照を少し理解できました。 特に、PHP 処理系は C言語で書かれていますが、C言語の知識はあまり必要ではなかったので C言語を触ったことのない私からすれば、発表が聞きやすかったです。

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

report by id:hiro_ji
あすみさん(@asumikam)による発表です speakerdeck.com

レポート

Composerではどのように依存関係を管理しているかや、
DockerにおけるComposerの取り扱いについてお話しいただきました。

  • Composerを理解して使うためにはまずcomposer.json/composer.lockがいつ更新されるかを理解する
  • 本番環境に余計なものを入れないためには
    • Copmoser install に[--no-dev]オプションをつける
    • マルチステージビルドでDockerイメージを作成

タイトルにもあるようにComposerを「なんとなく」使っていた身としては必見の内容でした!

PHP Parserで学ぶPHP

report by id:takaram
inouehiさんによる発表です speakerdeck.com

レポート

PHPコードを構文解析して抽象構文木 (AST) に変換できるライブラリ PHP-Parser (nikic/php-parser) を通して、PHP自体について学ぼうという発表です。 PHP-ParserはPHP本体のコントリビューターでもあるNikita Popovさんが開発しており、PHPStanやPsalmといった広く使われている静的解析ツールもPHP-Parserの上に成り立っています。

普段何気なく書いたり読んだりしているPHPですが、文と式の違い、関数と言語構造の違い、スカラー値の種類など、把握している方はどれくらいいるでしょうか? 私はそれなりに知っているつもりでいましたが、「そんな書き方できたんだ!」ということもあり目から鱗でした。

PHP自体はC言語で実装されていて、なかなか中身を読むのはハードルが高いですが、PHPで実装されたPHP-Parserは、PHPを詳しく学びたい人にはちょうどいいと感じました!

安全にプロセスを停止するためにシグナル制御を学ぼう!

report by id:hirobex
やまもとひろやさん(@HiroyaYamamoto1)による発表です speakerdeck.com

レポート

プロセスとシグナルの関係を、なんとなくで理解している人におすすめのトークです!

私自身、とりあえず Ctrl+C でプロセスが止まるんでしょ?といった程度の理解だったのですが
このトークを聞いてプロセスの止め方に適したシグナルがあることや、プロセスの止まり方によって
PHPプログラムが制御できることを知りました!

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

report by id:taclose
弊社 前田啓佑(@taclose)による発表です

speakerdeck.com

発表者本人によるレポート

パフォーマンス改善の失敗談と成功談を話した内容です。 改めて「計測するのが大事なんだな」と理解してもらえたかと思います。 スライドのほとんどは非エンジニアでも読めるような構成をとっており、若手やマネージャーの方でも読める構成になっています。 今一度パフォーマンス改善のやり方をチーム内で話し合って、共通認識を持ってもらえればと思います。

不幸を呼び寄せる命名の数々  ~君はそもそも何をされてる方なの?~

report by id:yamamuuu
弊社 山村光平(@yamamu096454848)による発表です

speakerdeck.com

発表者本人によるレポート

開発をしていると「この変数は何を表しているのだろう?」とか、「この関数は何をしているのだろう?」とか、一目見ただけでは何を伝えたいのかが分からない命名を目にすることがあります。 意図が伝わらないだけであれば調べれば済むかも知れませんが、時には命名が誤解を招き大問題に発展することもあります。 そんな不幸を呼び寄せる命名をあなたも知らず知らずのうちにしているかも知れません。 スライドでは「君はそもそも何をされてる方なの?」と言いたくなる命名の数々を紹介し、改めて命名の重要性を感じていただきます。

stdClassって一体何者なんだ?!

report by id:daina_rks
弊社 寺西帝乃(@dainabook)による発表です

speakerdeck.com

発表者本人によるレポート

stdClassを使う場面はよくあるかと思いますが、「そもそもこのクラスは一体何者なのか」と質問されると答えに困るPHPerは多くいるのではないでしょうか。 この発表ではstdClassの生成方法 ⇒ stdClassにできること・できないこと ⇒ stdClassに関する議論の順番で、「stdClassとは一体何者なのか」の答えに近づく内容です。 PHP8.2で導入される「動的プロパティの廃止」にも関連する内容となっております。 stdClassがよくわからない初心者PHPerや、今までなんとなく使ってきた中堅PHPer、stdClassのあり方について考えるベテランPHPer達の理解の手助けになると思います。

特徴、魅力を知って、各PHPフレームワークを使いこなそう!

report by id:radiocat
弊社 浅野 仁志(@hitoshi_a0)による発表です

speakerdeck.com

レポート

フレームワーク選定は「冒険を共にするパートナー選びのようなもの」とのことで冒険のパートナーになぞらえてPHPフレームワークが紹介されました。

  • Laravel:多くの人に頼られる人気者、能力も高く王道の主人公
  • CakePHP:真面目、曲がったことが大嫌い、正義感が強い委員長
  • Yii:玄人好みの影の立役者、切れ者軍師
  • Slim:最低限の荷物だけで旅をする自由人

永遠の宗教戦争的テーマなので「あのフレームワークは?」という意見も多々あり、反響のあまり発表者が「Symfonyはすみません」とコメントするなど、会場一体の議論を巻き起こすキラーLTとなっていました。また、会場だけでなくオンラインからもコメントが多く寄せられて、会場で流されていたニコ生のコメントともコラボした盛り上がりを見せていました。
SNSでの盛り上がり も合わせてお楽しみ頂ければと思います。

3/25(土) 2日目

実例から学ぶ変化に強いテーブル設計 - 責務の分解とRDBMSの上手い使い方

report by id:hirobex
曽根 壮大さん(@soudai1025)による発表です

レポート

実際にやりがちな設計はこうだけど、こう変更が加わったときに辛いよね、だからこう設計すると楽だよね
といった、実例から正しいテーブル設計を紹介する流れが非常に勉強になりました

今楽だからとりあえず既存テーブルにカラム追加しちゃう
といったことは、私自身やりがちなので気をつけようと思いました

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

report by id:hirobex
おかしょい/岡田 正平さん(@okashoi)による発表です

speakerdeck.com

レポート

フレームワークがなぜWebページを表示できるのか」という話を PHPでWebページを表示する方法から始まり、CakePHP、Laravel、Slim、Symfonyと様々なフレームワークのindex.phpを読み解いてWebページの表示の仕組みを解説するトークです

意外と、フレームワークしか触ったことのない人におすすめのトークだと思いました!

約10年もののPHPアプリケーションとの付き合い方と、今後10年改善し続けるための取り組みについて

report by id:Jazuma
たけてぃさん(@takeokunn)による発表です

レポート

物流システムという商材の特性上、システム障害を起こしてはいけないという要件が存在します。 その制約をクリアするためにSREチーム主導で以下のような取り組みが行われました。

  • Datadogによるシステムモニタリング。 アラートが発生した場合、Slackに通知する仕組みも構築
  • JobサーバをDockerizeしてECS化。 これによりMWバージョンアップ等のメンテナンスコストが低下した
  • gitとAWSの権限管理
  • PHPUnitの高速化

<感想>

メトリックスの監視やMWバージョンアップ等システム運用に必須の作業を効率化するための 施策に先手を打って取り組まれているという印象を受けました。

計測できるレガシーさを捉え、コード改善に対処する

report by id:Jazuma
大橋 佑太さん(@blue_goheimochi)による発表です

レポート

コードを「計測」することで効果的なリファクタリングができるという視点で コードのレガシーさを測定する方法が紹介されました。

  • 重複コードはどれくらいあるか
  • phpcpdというツールにより計測可能。重複コード = 悪というわけではないため検知されたコードの目視確認が必要
  • 循環的複雑度はどのくらいか
    • terryyin/lizardにより計測。(if/else, for, switch等の数を計測する。 これらはコードがどれだけ複雑化の指標となる)
  • 未使用コードの検出
    • ツールは様々なものがあるため複数のツールを試して比較してみると良い
  • ファイルの変更回数
    • Gitコマンドでファイルの変更回数を測定可能。変更回数が多い = 責務過多の可能性がある、あるいは価値検証の場合がある

Gitコマンドでファイルの変更回数を測定するのは特別なツールを導入することなく実現できるので測定の第一歩として適切だと思いました。

【実録】「PHP_CodeSniffer」で始める快適コードレビューライフ

report by id:mrstsgk_rks
弊社 森下 繁喜による発表です

speakerdeck.com

発表者本人によるレポート

私の所属する配配メール開発課の事例をもとにPHP_CodeSnifferを導入したときの恩恵と思わぬ落とし穴を説明しました。 オンライン登壇でニコニコ生放送と発表時の音声を片耳ずつ聞いていたので、 音声のラグでスタートに戸惑いましたので、次はオフライン登壇でリベンジしようと思います。 次回「PHP_CodeSnifferをPhpStormに設定したら実装工数が減少できた件」でお会いしましょう!!!

PHPマジックメソッドクイズ!

report by id:Y-Kanoh
弊社 加納悠史(@YKanoh65)による発表です

speakerdeck.com

発表者本人によるレポート

「このメソッド、定義されていないはずだけど... あ、マジックメソッドを呼び出しているのか」Laravel のコードを読んでいるときに、一瞬迷ったのがこの発表の元でした。

知っていれば「ああ、こういうことね」と脳内で変換できますが、知らないと関係性がわからなくなってしまうのがマジックメソッドだと思います。特に一般的な開発時には自分で実装することが一部を除き多くはないため、まずは知ることが重要です。 このクイズで興味を持った方は、ぜひ一度調べてみてください。

フレームワークが存在しない時代からのレガシープロダクトを、Laravelに”載せる”実装戦略

report by id:radiocat

弊社 廣部 知生 (@tomoki2135) による発表です

speakerdeck.com

レポート

20年モノのレガシープロダクトの新UI導入をきっかけにLaravelを導入した事例の紹介です。
Laravelに”載せる”実装戦略として、アーキテクチャADRパターンを採用して既存コードをできる限りそのまま維持してLaravel上で動作させる戦略が紹介されました。
この戦略によって、載せ替える前の構造を維持したままスピーディーな移植を実現できたようです。また、移植によってデータが返り値となる仕組みになったことでテストが書きやすくなりました。あくまで移植しただけなのでまだまだ課題はあるようですが、レガシープロダクトにモダンなフレームワークを導入する参考事例のひとつとして大きな反響があり、LTではなくレギュラー枠でじっくり聞きたいという意見もあがっていました。

まとめ

初心者向けの内容からマニアックな内容まで幅広い人が聴いていて楽しいイベントとなっていました。LTの時間は現地ではペンライト、配信では色付きのコメントが流れるなど大盛りあがりでした。

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

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

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

rakus.connpass.com

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

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