diff options
Diffstat (limited to 'public/posts/2021-03-30/phperkaigi-2021/index.html')
| -rw-r--r-- | public/posts/2021-03-30/phperkaigi-2021/index.html | 2167 |
1 files changed, 1101 insertions, 1066 deletions
diff --git a/public/posts/2021-03-30/phperkaigi-2021/index.html b/public/posts/2021-03-30/phperkaigi-2021/index.html index a16b49e..43267d5 100644 --- a/public/posts/2021-03-30/phperkaigi-2021/index.html +++ b/public/posts/2021-03-30/phperkaigi-2021/index.html @@ -4,18 +4,14 @@ <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="author" content="nsfisis"> - <meta name="copyright" content="© nsfisis"> + <meta name="copyright" content="© 2021 nsfisis"> <meta name="description" content="2021-03-26 から 2021-03-28 にかけて開催された、PHPerKaigi 2021 に参加した。"> <meta name="keywords" content="カンファレンス,PHP,PHPerKaigi"> <link rel="icon" type="image/svg+xml" href="/favicon.svg"> <title>PHPerKaigi 2021 | REPL: Rest-Eat-Program Loop</title> - - <link rel="stylesheet" href="/hl.css?208c52e3b7c9db1cad782c5d30b4698f"> - - <link rel="stylesheet" href="/style.css?779b1a3debcaeba619f6fe500e93d525"> - - <link rel="stylesheet" href="/custom.css?a649ea3528d4b626fb636505d94c1144"> - + <link rel="stylesheet" href="/hl.css?h=208c52e3b7c9db1cad782c5d30b4698f"> + <link rel="stylesheet" href="/style.css?h=779b1a3debcaeba619f6fe500e93d525"> + <link rel="stylesheet" href="/custom.css?h=a649ea3528d4b626fb636505d94c1144"> </head> <body class="single"> <header class="header"> @@ -29,1073 +25,1112 @@ <article class="post-single"> <header class="post-header"> <h1 class="post-title">PHPerKaigi 2021</h1> - - <ul class="post-tags"> - - <li class="tag"> - <a href="/tags/conference/">カンファレンス</a> - </li> - - <li class="tag"> - <a href="/tags/php/">PHP</a> - </li> - - <li class="tag"> - <a href="/tags/phperkaigi/">PHPerKaigi</a> - </li> - - </ul> - + <ul class="post-tags"> + <li class="tag"> + <a href="/tags/conference">カンファレンス</a> + </li> + <li class="tag"> + <a href="/tags/php">PHP</a> + </li> + <li class="tag"> + <a href="/tags/phperkaigi">PHPerKaigi</a> + </li> + </ul> </header> <div class="post-content"> <section> <h2 id="changelog">更新履歴</h2> <ol> + <li class="revision"> + <time datetime="2021-03-30">2021-03-30</time>: 公開 + </li> + </ol> + </section> + <section id="section--_phperkaigi_2021_参加レポ"> + <h2><a href="#section--_phperkaigi_2021_参加レポ">PHPerKaigi 2021 参加レポ</a></h2> + <p> + 2021-03-26 から 2021-03-28 にかけて開催された、<a xl:href="https://phperkaigi.jp/2021/">PHPerKaigi 2021</a>に一般参加者として参加した。 弊社<a xl:href="https://www.dgcircus.com/">デジタルサーカス株式会社</a>(今年1月から勤務) はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。 + </p> + + <p> + このようなカンファレンスには初めて参加するのでかねてより心待ちにしていたのだが、生憎2日目から体調を崩してしまい、この記事も途中までとなっている。まだ見ていないセッションも多いが、ひとまず現時点での参加レポを書いておく。 + </p> + + <p> + 発表はトラック A、B に分かれていたのだが、今回はすべて A トラックを視聴している (切り替えるのが面倒だっただけ)。 + </p> + + <section id="section--_凡例"> + <h3><a href="#section--_凡例">凡例</a></h3> + <blockquote> + <p> + 発表・スライドのメモ (引用ではない) + </p> + </blockquote> - <li class="revision"> - <time datetime="2021-03-30">2021-03-30</time>: 公開 - </li> + <p> + 感想など + </p> + </section> + + <section id="section--_day_0_前夜祭_20210327"> + <h3><a href="#section--_day_0_前夜祭_20210327">Day 0 前夜祭 (2021/03/27)</a></h3> + <section id="section--_1730_a"> + <h4><a href="#section--_1730_a">17:30 [A]</a></h4> + <p> + PHP で AWS Lambda + </p> + + <blockquote> + <p> + Rails のプロジェクトを PHPer のメンバのみでメンテ →他のメンバもわかる PHP にリプレースを検討 + </p> + + <ul> + <li> + <p> + サーバレス + </p> + </li> + + <li> + <p> + サーバ・インフラの管理が不要 + </p> + </li> + + <li> + <p> + アプリケーションコードの知識だけで保守可能 + </p> + </li> + </ul> + + <p> + ゼロベースで作れる案件が (Railsの件とは別に) あるため、そちらで試験的に導入? + </p> + + <p> + AWSの学習 AWS のドキュメント DevelopersIO + </p> + + <p> + AWS Lambda のカスタムランタイムで PHP を動かす + </p> + + <p> + サーバのセットアップや維持管理を気にしなくて良い サーバーレスで PHP を動かすツールがすでにある サーバーレス構築はすんなり + </p> + + <p> + 今は Laravel がルーティングしている Laravel Livewire を Lambda に載せられないか？ デプロイ方法は？ バッチ処理は？ (Lambda は 15分の制限) + </p> + + <p> + Lambda でコンテナイメージがサポートされるように + </p> + + <p> + 抽象化されたもの「だけ」しか知らないよりも具象の理解は助けになる + </p> + </blockquote> + + <p> + AWS Lambda のような Function as a Service はマイクロサービス化における一つの到達点に思えるのだが、これを使って実際に web サービスを作る具体的なイメージがまだ見えない (注: すべて for me として書いている)。 + </p> + + <p> + PHP on AWS Lambda があれだけ簡単に動かせるのには驚いた。 + </p> + + <p> + 勝手に AWS Lambda だとフットプリントの軽さが求められそう (= PHP + Laravel などでは動かなさそう) だという先入観を持っていたのだが、この発表のデモによればそうでもないらしい。 + </p> + </section> - </ol> + <section id="section--_1810_a"> + <h4><a href="#section--_1810_a">18:10 [A]</a></h4> + <p> + 大規模サイトの SEO + </p> + + <blockquote> + <p> + 大規模サイト (100万ページ以上) Google の基準 + </p> + + <p> + クロールバジェットを意識したSEO + </p> + + <p> + 大規模サイトでコンテンツが中頻度 (1回/週) で更新 OR 中規模サイト (10,000以上) でコンテンツが目まぐるしく変更される これを満たさないなら、クロールバジェットを考えなくてもいい + </p> + + <p> + サーチコンソール 「カバレッジ」の「除外」 多すぎるのは問題→クロールバジェットを浪費している + </p> + + <ul> + <li> + <p> + クエリの順番を決める + </p> + </li> + + <li> + <p> + 空の値のルールを決めておく + </p> + </li> + + <li> + <p> + リダイレクトすればインデックスはうまくいく + </p> + </li> + + <li> + <p> + リンクが存在する限りクロールはされる + </p> + </li> + </ul> + + <p> + リニューアル前のURL + </p> + + <p> + インデックスは移行される リンクのURLが存在する限り、別のURLとしてクロールされる リダイレクトされるとはいえ、リニューアル前のURLは移行した方が良い リニューアルで無視されるようになったパラメータも注意 + </p> + + <p> + robotes.txt で拒否しているのにクロールされる 一時的に拒否を外して 404 や 301 を読ませる 内部リンクを確認する JS でのリンクに書き換え + </p> + + <p> + クエリパラメータからURLのパスに<code>/tokyo?area=HOGE</code>→<code>/tokyo/HOGE</code> + </p> + + <p> + URL 設計だいじ + </p> + </blockquote> + + <p> + SEO (Search Engine Optimization) は大して知らないので新鮮な話が多かった。その分語れることも少ない……。 + </p> + </section> + + <section id="section--_1850_a"> + <h4><a href="#section--_1850_a">18:50 [A]</a></h4> + <blockquote> + <p> + 知覚可能 操作可能 理解可能 堅牢 ちゃんとしたHTMLを書く (閉じタグ・入れ子構造など) + </p> + + <ul> + <li> + <p> + 標準の HTML を適切に使う + </p> + </li> + + <li> + <p> + WAI-ARIA + </p> + </li> + + <li> + <p> + キーボードフレンドリー + </p> + </li> + + <li> + <p> + マシンフレンドリー + </p> + </li> + + <li> + <p> + SEOフレンドリー + </p> + </li> + </ul> + + <p> + button タグ →キーボード h1 タグ →スクリーンリーダー・クローラ a タグ + </p> + + <p> + WAI-ARIA HTML では表現できないセマンティクスを追加する + </p> + + <ul> + <li> + <p> + ロール + </p> + + <ul> + <li> + <p> + 何をするのか？ + </p> + </li> + + <li> + <p> + ユーザーアクションによって変化しない + </p> + </li> + </ul> + </li> + + <li> + <p> + プロパティ + </p> + + <ul> + <li> + <p> + 関連づけられたデータ + </p> + </li> + </ul> + </li> + + <li> + <p> + ステート + </p> + + <ul> + <li> + <p> + 現在の状態 + </p> + </li> + </ul> + </li> + </ul> + + <p> + まずは標準の HTML 要素で解決する 何でもかんでも WAI-ARIA を使えばいいというものではない + </p> + + <p> + マウスホバーでツールチップが出てくるが、キーボード操作では出てこない + </p> + + <p> + VoiceOver + </p> + + <p> + 全ての属性を使う必要はない あくまでアクセシビリティを上げるための方法の一つにすぎない + </p> + </blockquote> + + <p> + つい最近 WAI-ARIA についての記事を読んだばかりだったので個人的にタイムリーな話題だった。(あまりこの言葉を使いたくないのだが) いわゆる「健常者」にとって、こうした問題を普段の生活の中で意識するのは難しい。だからこそ情報へのアンテナは張っておくようにしたい。 + </p> + </section> + + <section id="section--_1930_a"> + <h4><a href="#section--_1930_a">19:30 [A]</a></h4> + <p> + PHP で FUSE + </p> + + <p> + 個人的に楽しみだった発表。 + </p> + + <blockquote> + <p> + VFS (virtual filesystem) vs 具体的なファイルシステム + </p> + + <p> + 最適な実装方法は状況により異なる + </p> + + <p> + アプリケーションに見せるAPIは変えずに実装を隠蔽する→VFS + </p> + + <p> + カーネルのプログラムを作るのは難しい * 権限がデカすぎる * システム全体がクラッシュ * セキュリティリスク * 開発サイクルを回しづらい * ネイティブコードにコンパイルされる言語である必要がある + </p> + + <p> + Filesystem in USEr space (FUSE) + </p> + + <ul> + <li> + <p> + 特定の C の関数を呼ぶことで filesystem が作れる + </p> + </li> + + <li> + <p> + FFI を持つ言語なら FUSE が使える + </p> + </li> + </ul> + + <p> + SSHFS / s3fs / Docker Desktop + </p> + + <p> + Linux 以外でも使える + </p> + + <ul> + <li> + <p> + dokany (on Windows) + </p> + </li> + + <li> + <p> + osxfuse + </p> + </li> + </ul> + + <p> + VFS: システムコールが呼ばれると、ファイルシステムによってコール FUSE: カーネル空間からユーザ空間へ通信 + </p> + + <p> + 高レベルなラッパで型をつける + </p> + + <p> + PHP 以外では Wordpress を FUSE にマウントする実装がある (C, Python など) + </p> + + <ul> + <li> + <p> + grep できる + </p> + </li> + + <li> + <p> + sed できる + </p> + </li> + + <li> + <p> + 編集できる + </p> + </li> + </ul> + </blockquote> + + <p> + 期待通りの興味深い発表だった。FUSE 自体も今回の発表で知ったのだが、これ本体の実装を見るのも面白そうだ。 この発表を聞きながらファイルシステムにマウントできそうなものを考えていたのだが、およそ木構造をしているものすべてと言えそうだ (ハンマーしか持っていないと云々)。何かできそうだがなかなか思いつかない。 + </p> + </section> + </section> + + <section id="section--_day_1_20210327"> + <h3><a href="#section--_day_1_20210327">Day 1 (2021/03/27)</a></h3> + <section id="section--_1050_a"> + <h4><a href="#section--_1050_a">10:50 [A]</a></h4> + <p> + ATDD + </p> + + <blockquote> + <ul> + <li> + <p> + ユーザーストーリー + </p> + </li> + + <li> + <p> + ユニットテスト + </p> + </li> + + <li> + <p> + CI/CD + </p> + </li> + </ul> + + <p> + ユーザストーリーの受け入れ条件が曖昧になりがち デグレチェックがユニットレベルでは収まらない場合、手動で同じシナリオをテストしている + </p> + + <p> + Q2の強化 アジャイルテストの4象限 + </p> + + <p> + 技術面/ビジネス面 開発チーム支援(コーディング前・コーディング中)/製品批評(コーディング後) + </p> + + <ul> + <li> + <p> + Q1: 技術面 & チーム支援 + </p> + + <ul> + <li> + <p> + TDD + </p> + </li> + + <li> + <p> + ユニットテストなど + </p> + </li> + </ul> + </li> + + <li> + <p> + Q2: ビジネス面 & チーム支援 + </p> + + <ul> + <li> + <p> + ATDD + </p> + </li> + + <li> + <p> + ビジネス面の受け入れテストで駆動する + </p> + </li> + </ul> + </li> + </ul> + + <p> + Agile Alliance ユーザストーリーのスキルレベルを高める + </p> + + <p> + テストピラミッド + </p> + + <ul> + <li> + <p> + UI Tests + </p> + </li> + + <li> + <p> + Service Tests + </p> + </li> + + <li> + <p> + Unit Tests + </p> + </li> + + <li> + <p> + 異なる粒度のテストを書く + </p> + </li> + + <li> + <p> + 高レベルになるほど、持つべきテストは少なくなる + </p> + + <ul> + <li> + <p> + ピラミッド型になる + </p> + </li> + </ul> + </li> + </ul> + + <p> + 高レベルテストが多すぎる→アイスクリームコーン アンチパターン + </p> + + <p> + ATDD (Acceptance TDD) API経由・UI経由での高レベルテスト E2E test + </p> + + <p> + ストーリ受け入れテスト + </p> + + <p> + 入れ子のフィードバックループ ATDD(外側) と TDD(内側) + </p> + + <p> + 外部品質・内部品質 + </p> + + <p> + バーティカルスライスのデリバリー + </p> + + <ul> + <li> + <p> + cucumber + </p> + </li> + + <li> + <p> + gauge + </p> + </li> + + <li> + <p> + behat + </p> + </li> + </ul> + + <p> + ユビキタス言語 手動テストもspecに書く 自動化は可能だがコスパが悪い 失敗することがわかっているテスト(レッドテスト)はCIから外す 失敗時の原因究明が難しい 饒舌なエラーメッセージ 状況のスナップショット + </p> + + <p> + Continuous Testing + </p> + </blockquote> + + <p> + User Acceptance Test (UAT) くらいの規模になると個人開発・趣味開発では触れない領域なので、大いに勉強になった。スライドに添付されている資料が相当に充実していたので、これを読むのが本番といった様相すら感じる。 高レベルテストの自動化は現在のプロジェクトでも感じており、自動化のチャンスは伺っている。とはいえセッションでも指摘されているように自動化することにコストがかかりすぎる領域があるのも事実で、そのバランスが難しい。 + </p> + </section> + + <section id="section--_1150_a"> + <h4><a href="#section--_1150_a">11:50 [A]</a></h4> + <p> + 型解析を用いたリファクタリング + </p> + + <p> + 型のある世界で生きてきた身として大いに楽しみにしていた発表。 + </p> + + <blockquote> + <ul> + <li> + <p> + PHPStan + </p> + </li> + + <li> + <p> + Phan + </p> + </li> + + <li> + <p> + Psalm + </p> + </li> + </ul> + + <p> + autoload も認識できる bootstrapFiles + </p> + + <p> + 編集箇所と利用箇所を CI でチェック ルールレベルを徐々に引き上げていく 警告が多すぎると見落としてしまう・無視されやすくなる + </p> + + <p> + 型がついていないことによるエラーが多い + </p> + + <p> + 型よりも詳細な検査<code>Util_Assert::min</code> + </p> + + <p> + SQL を静的解析 placeholder の型付け + </p> + + <p> + 警告レベルを低いレベルから導入 タイプヒントを積極的に書いていく PHPStan の拡張を追加する + </p> + </blockquote> + + <p> + 昨今、動的型付き言語での型宣言・型アノテーション・型ヒントの導入が相次いでいる。長らく静的型付き言語を書いてきた私からすると、ようやく気づいたかといったところだが、ともかく型を導入する言語が増えてきた。 今のプロジェクトでも新しく追加するコードには型をつけるよう努めているが、どうしても古いコードには型がついていない。個人的には型のないコードに対してどう型を自動的に付けるかという点に興味があり、その点で Ruby の typeprof には注目している。 + </p> + </section> + + <section id="section--_1230_a"> + <h4><a href="#section--_1230_a">12:30 [A]</a></h4> + <p> + 昼食をとっていた。事前に何か食料を買っておくべきだった。 + </p> + </section> + + <section id="section--_1310_a"> + <h4><a href="#section--_1310_a">13:10 [A]</a></h4> + <p> + Documentation as Code + </p> + + <p> + この発表も以前から非常に楽しみにしていた。 + </p> + + <blockquote> + <p> + 開発開始までのオーバーヘッド 新規にチームにジョイン 担当範囲外の機能を理解 オンボーディングのコスト + </p> + + <p> + PHPerKaigi 2020 で発表あり + </p> + + <p> + 継続的にシステムの理解を助けるドキュメント + </p> + + <p> + 継続的ドキュメンテーション システムとドキュメントの乖離 + </p> + + <p> + 書いてあることが間違っている・足りない * 徐々にずれていく * システムの更新タイミングとドキュメントの更新タイミングに差がある + </p> + + <p> + システムとドキュメントは対応関係がある * 間違ったドキュメント * 存在しないドキュメント + </p> + + <p> + システムとドキュメントの乖離を定量化する 継続的に システムの更新に近いタイミングで ドキュメントを更新し続ける + </p> + + <p> + Documentation as Code + </p> + + <p> + コードと同じツールでドキュメントを書く * issue tracker * vcs * plain text markup * automation + </p> + + <p> + 開発者 システム ドキュメント 構造化データ ソフトウェア + </p> + + <p> + システムから構造化データを抽出する PHPDoc OpenAPI + </p> + + <p> + ビュー 関心ごとに合わせてアーキテクチャを一つ以上の側面(断面)で説明する + </p> + + <p> + ビューの単位でドキュメントに + </p> + + <p> + スタックトレースからのドキュメント生成 + </p> + </blockquote> + + <p> + ドキュメントの管理は現プロジェクトでも課題と感じている。作られた当初は正しくても、実態と乖離していくのを止めるのは困難を極める。全体的に興味深い発表だったが、特にスタックトレースからのドキュメント生成というアイデアに惹かれるものを感じた。スタックトレースという実態と不可分な (乖離しない) 情報を起点にするのは理にかなっている。問題はトレースをいつ、どう取るかだろうか。それを自動化しなければ、実態との乖離が避けられないだろう。 + </p> + </section> + + <section id="section--_1410_a"> + <h4><a href="#section--_1410_a">14:10 [A]</a></h4> + <p> + cookie による session 管理 + </p> + + <p> + 全体的に基本的な話だったので特に触れない。Cookie やセッションの話としては非常に分かりやすくまとめられていたので、知らない人が学ぶにはいい教材だろう。 + </p> + </section> + + <section id="section--_1450_a"> + <h4><a href="#section--_1450_a">14:50 [A]</a></h4> + <p> + PHP のエラーと例外 + </p> + + <blockquote> + <p> + エラー PHPエンジンがエラーを通知する 例外 プログラムが投げる + </p> + + <p> + PHP7-8とエラー + </p> + + <p> + PHPエンジンのエラーの一部が に変換されるようになった → try-catch で捕捉できる + </p> + + <p> + は例外とは異なる + </p> + + <p> + PHP8 でエラーレベルの引き上げ + </p> + + <ul> + <li> + <p> + 捕捉すべきもの + </p> + + <ul> + <li> + <p> + recoverable + </p> + </li> + </ul> + </li> + + <li> + <p> + 捕捉すべきでないもの + </p> + + <ul> + <li> + <p> + unrecoverable + </p> + </li> + + <li> + <p> + 開発時に対処できるもの + </p> + </li> + </ul> + </li> + </ul> + + <p> + 例外 * 捕捉して事後処理 * 捕捉せず(or 捕捉した上で)さらに上に是非を問う + </p> + + <p> + 開発段階で例外を把握し、ハンドリングを考えておく + </p> + + <p> + と + </p> + + <p> + はキャッチすべきでない + </p> + + <ul> + <li> + <p> + </p> + + <ul> + <li> + <p> + 本番で起きてはいけない + </p> + </li> + </ul> + </li> + + <li> + <p> + </p> + + <ul> + <li> + <p> + 本番で起きてはいけない →生じないのだから捕捉もしない + </p> + </li> + </ul> + </li> + + <li> + <p> + </p> + + <ul> + <li> + <p> + 起こるかもしれないので本番環境でも考慮する + </p> + </li> + </ul> + </li> + </ul> + + <p> + 捕捉して対応するのではなく、未然に防ぐ + </p> + + <p> + 独自例外を使う を投げてしまうと、 catch ()せざるを得ない →catch 範囲が広すぎる + </p> + + <p> + SPL の例外を使う + </p> + + <p> + 例外翻訳 上位のレイヤが下位のレイヤの例外を捕捉し、上位レイヤのAPIに「翻訳」する 下位レイヤの知識に依存させない + </p> + + <p> + @throws 捕捉してほしい例外を書き連ねておく + </p> + + <p> + 呼び出しもとに負わせたい責任 + </p> + </blockquote> + + <p> + PHP を学んでいる途中の私としては、今まさに聞きたい発表だった (現時点で PHP を書き始めてから 4ヶ月ほどになる)。 + </p> + + <p> + 個人的に例外やエラーを最もうまく扱っているのは Go、Swift、Rust、Haskell などのエラーを「値として」扱う言語だと思っている。try-catch は通常の処理フローを完全に壊してしまう上、構文としても重すぎる。値としてのエラー通知は C言語時代への回帰ともいえるが、その頃と異なるのはエラーを暗黙のうちに握り潰すことがないということだ。これらの言語は型を持っており、静的に検証ができる (C のそれはまともな型付けではない。念のため)。 + </p> + + <p> + PHP のように、すでに例外が言語システムに根ざしている言語ではどうすればよいか。この場合も同じく静的検証の力を借りることになるだろう。 + </p> + </section> + + <section id="section--_1530_a"> + <h4><a href="#section--_1530_a">15:30 [A]</a></h4> + <p> + Laravel のメール認証 + </p> + + <p> + Laravel の知識がない私にはまったくついていけなかった。また、個人的にタイトルがややミスリーディングに感じた。 + </p> + </section> + + <section id="section--_1610_a"> + <h4><a href="#section--_1610_a">16:10 [A]</a></h4> + <p> + gRPC + </p> + + <blockquote> + <p> + Unary RPCs Server streaming RPCs Client streaming RPCs Bidirectional streaming RPCs + </p> + + <p> + Protobuf + </p> + + <p> + 実装とAPIが乖離しにくい 自動生成 複数言語でも相互に使える + </p> + + <p> + マイクロサービスのサービス通信 スマホアプリ ゲームサーバ + </p> + + <p> + PHP では？ + </p> + + <p> + PHP ではストリーミングが難しい リクエストごとにプロセスが使い捨て + </p> + + <p> + PHP ではgRPCのクライアントしか対応していない + </p> + + <p> + gRPC-Web ブラウザで扱うためのJSライブラリ+プロトコル + </p> + + <p> + HTTP/1.1 でも使える Unary RPC と Server streaming RPC のみ + </p> + + <p> + Envoy Nginx などで相互に gRPC と gRPC-Web で変換 + </p> + + <p> + Amp イベント駆動な並行処理のフレームワーク + </p> + + <p> + HTTP/2 対応 + </p> + + <p> + C#のgRPC-Webが楽 + </p> + </blockquote> + + <p> + (発表の中でもまさに同じことをおっしゃっていたが) PHP 以外の方が向いているだろう、というのが第一の感想である。gRPC はそれ自体というよりも Protobuf というエコシステムに乗れることのメリットが大きいと感じる。そのエコシステムにうまく乗れない時点で、うーんという感じ。 + </p> + </section> + + <section id="section--_1650_a"> + <h4><a href="#section--_1650_a">16:50 [A]</a></h4> + <p> + アーキテクチャテスト + </p> + + <blockquote> + <p> + Independent Core Layer Pattern + </p> + + <p> + 開発初期のアーキテクチャが崩れる アーキテクチャ観点のコードレビューができない + </p> + + <p> + どこにクラスを置けばよいか？ ドキュメントがない + </p> + + <p> + アーキテクチャ設計に関する知識が属人化・暗黙知化 + </p> + + <p> + ガイドライン * 最初にルールを決めるのは簡単 * ルール通り作り始めるのも簡単 * →維持するのが難しい、人が決めたものゆえ壊れやすい + </p> + + <p> + PHP の特性 * クラスは public * 可視性の制御が public / protected / private のみ * 依存関係の制御が困難 + </p> + + <p> + アーキテクチャテスト クラスの依存関係や実装ルールをコードとして表現し、自動テスト化する + </p> + + <ul> + <li> + <p> + deptrac + </p> + </li> + + <li> + <p> + phpat + </p> + </li> + </ul> + + <p> + Independent Core Layer Pattern + </p> + + <p> + アーキテクチャテストの失敗 * 実装誤り * or アーキテクチャが適切でない * 開発の過程でフィードバックしていく + </p> + + <p> + モジュラーモノリス→マイクロサービスへ + </p> + </blockquote> + </section> + </section> + + <section id="section--_day_2_20210328"> + <h3><a href="#section--_day_2_20210328">Day 2 (2021/03/28)</a></h3> + <p> + 冒頭に書いた通り、2日目から体調が悪くまともに聴けていない。途中までは頭痛を我慢しつつ見ていたのだが、まともに入ってこなかった。 + </p> + + <p> + 残念ではあるが、いずれにせよ見られていない発表は他にもあるので、今週末にでもまとめて見ようと思う。 + </p> + </section> + + <section id="section--_全体の感想"> + <h3><a href="#section--_全体の感想">全体の感想</a></h3> + <p> + Day 2 にほとんど参加できなかったのは残念だが、イベント自体は大変楽しく、また興味深いものであった。自分がまったく知らない領域の話を聞けるのはこうしたイベントならではだと感じる。オンライン開催ゆえ現地に行く必要がなく、気軽に参加できたのも (特に初参加者として) 嬉しいポイントだった。 + </p> + + <p> + 今回、雑談/登壇者への質問等向けに Discord サーバもあったのだが、こちらは参加こそしたものの ROM のままになってしまった。発表に1ウィンドウ、メモを書くのに1ウィンドウ、Discord 表示に 1ウィンドウで私にはもう脳のリソースとディスプレイのスペースが追いつかなかった (さらにいうと Zoom でアンカンファレンスもやっていたようだ。こちらはまったく参加していない)。 + </p> + + <p> + 1つ個人的な反省点としては、一つ一つのセッションを真剣に聞き過ぎたというものがある。もっと適当に聞いておけばよかった。これだけだと大変語弊があるのだが、言い方を変えると、Discord しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、後から見返せる発表やスライドに注力してしまった、ということだ。発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。 まあ初カンファレンスだし、とお茶を濁しておこう。 + </p> + + <p> + さて、カンファレンスで一つ気になったことがある。それは、Discord という書き込み場所が増えたことでニコ生のコメントの流量が吸い取られてしまったのではないか、という点だ。ニコニコだけ見ていると過疎っているかのように見えた発表も、Discord の方では盛り上がっている、というのを何度か見かけた。ニコニコのコメント方式は盛り上がりを如実に反映するが、逆もまたしかり。Discord があったこと自体はプラスだったと思うが、この点はマイナスだったのではないかと感じる。 + </p> + + <p> + <hr> + </hr> + </p> + + <p> + 最後になりましたが、毎年の PHPerKaigi 開催にご尽力されている皆様、スピーカーの皆様、楽しい3日間でした。ありがとうございました！ (ずっと常体で書いてしまったのでいきなり仏頂面から笑顔になったようで気持ち悪い) + </p> + + <p> + ではまた来年。 + </p> + </section> </section> - <section class="section-1"> - <h2 id="" class="section-header"> - - PHPerKaigi 2021 参加レポ - - </h2> - <div class="section-body"> - <div class="paragraph"> -<p>2021-03-26 から 2021-03-28 -にかけて開催された、 <a href="https://phperkaigi.jp/2021/">PHPerKaigi 2021</a> -に一般参加者として参加した。 -弊社 <a href="https://www.dgcircus.com/">デジタルサーカス株式会社</a> -(今年1月から勤務) -はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。</p> -</div> -<div class="paragraph"> -<p>このようなカンファレンスには初めて参加するのでかねてより心待ちにしていたのだが、生憎2日目から体調を崩してしまい、この記事も途中までとなっている。まだ見ていないセッションも多いが、ひとまず現時点での参加レポを書いておく。</p> -</div> -<div class="paragraph"> -<p>発表はトラック A、B に分かれていたのだが、今回はすべて A -トラックを視聴している (切り替えるのが面倒だっただけ)。</p> -</div> -<section class="section-2"> - <h3 id="" class="section-header"> - - 凡例 - - </h3> - <div class="section-body"> - <div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>発表・スライドのメモ (引用ではない)</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>感想など</p> -</div> - </div> -</section> -<section class="section-2"> - <h3 id="" class="section-header"> - - Day 0 前夜祭 (2021/03/27) - - </h3> - <div class="section-body"> - <section class="section-3"> - <h4 id="" class="section-header"> - - 17:30 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>PHP で AWS Lambda</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>Rails のプロジェクトを PHPer のメンバのみでメンテ →他のメンバもわかる -PHP にリプレースを検討</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>サーバレス</p> -</li> -<li> -<p>サーバ・インフラの管理が不要</p> -</li> -<li> -<p>アプリケーションコードの知識だけで保守可能</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>ゼロベースで作れる案件が (Railsの件とは別に) -あるため、そちらで試験的に導入?</p> -</div> -<div class="paragraph"> -<p>AWSの学習 AWS のドキュメント DevelopersIO</p> -</div> -<div class="paragraph"> -<p>AWS Lambda のカスタムランタイムで PHP を動かす</p> -</div> -<div class="paragraph"> -<p>サーバのセットアップや維持管理を気にしなくて良い サーバーレスで PHP -を動かすツールがすでにある サーバーレス構築はすんなり</p> -</div> -<div class="paragraph"> -<p>今は Laravel がルーティングしている Laravel Livewire を Lambda -に載せられないか？ デプロイ方法は？ バッチ処理は？ (Lambda は -15分の制限)</p> -</div> -<div class="paragraph"> -<p>Lambda でコンテナイメージがサポートされるように</p> -</div> -<div class="paragraph"> -<p>抽象化されたもの「だけ」しか知らないよりも具象の理解は助けになる</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>AWS Lambda のような Function as a Service -はマイクロサービス化における一つの到達点に思えるのだが、これを使って実際に -web サービスを作る具体的なイメージがまだ見えない (注: すべて for me -として書いている)。</p> -</div> -<div class="paragraph"> -<p>PHP on AWS Lambda があれだけ簡単に動かせるのには驚いた。</p> -</div> -<div class="paragraph"> -<p>勝手に AWS Lambda だとフットプリントの軽さが求められそう (= PHP<br> -Laravel などでは動かなさそう) -だという先入観を持っていたのだが、この発表のデモによればそうでもないらしい。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 18:10 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>大規模サイトの SEO</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>大規模サイト (100万ページ以上) Google の基準</p> -</div> -<div class="paragraph"> -<p>クロールバジェットを意識したSEO</p> -</div> -<div class="paragraph"> -<p>大規模サイトでコンテンツが中頻度 (1回/週) で更新 OR 中規模サイト -(10,000以上) でコンテンツが目まぐるしく変更される -これを満たさないなら、クロールバジェットを考えなくてもいい</p> -</div> -<div class="paragraph"> -<p>サーチコンソール 「カバレッジ」の「除外」 -多すぎるのは問題→クロールバジェットを浪費している</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>クエリの順番を決める</p> -</li> -<li> -<p>空の値のルールを決めておく</p> -</li> -<li> -<p>リダイレクトすればインデックスはうまくいく</p> -</li> -<li> -<p>リンクが存在する限りクロールはされる</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>リニューアル前のURL</p> -</div> -<div class="paragraph"> -<p>インデックスは移行される -リンクのURLが存在する限り、別のURLとしてクロールされる -リダイレクトされるとはいえ、リニューアル前のURLは移行した方が良い -リニューアルで無視されるようになったパラメータも注意</p> -</div> -<div class="paragraph"> -<p>robotes.txt で拒否しているのにクロールされる 一時的に拒否を外して 404 や -301 を読ませる 内部リンクを確認する JS でのリンクに書き換え</p> -</div> -<div class="paragraph"> -<p>クエリパラメータからURLのパスに <code>/tokyo?area=HOGE</code> → <code>/tokyo/HOGE</code></p> -</div> -<div class="paragraph"> -<p>URL 設計だいじ</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>SEO (Search Engine Optimization) -は大して知らないので新鮮な話が多かった。その分語れることも少ない……。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 18:50 [A] - - </h4> - <div class="section-body"> - <div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>知覚可能 操作可能 理解可能 堅牢 ちゃんとしたHTMLを書く -(閉じタグ・入れ子構造など)</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>標準の HTML を適切に使う</p> -</li> -<li> -<p>WAI-ARIA</p> -</li> -<li> -<p>キーボードフレンドリー</p> -</li> -<li> -<p>マシンフレンドリー</p> -</li> -<li> -<p>SEOフレンドリー</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>button タグ →キーボード h1 タグ →スクリーンリーダー・クローラ a タグ</p> -</div> -<div class="paragraph"> -<p>WAI-ARIA HTML では表現できないセマンティクスを追加する</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>ロール</p> -<div class="ulist"> -<ul> -<li> -<p>何をするのか？</p> -</li> -<li> -<p>ユーザーアクションによって変化しない</p> -</li> -</ul> -</div> -</li> -<li> -<p>プロパティ</p> -<div class="ulist"> -<ul> -<li> -<p>関連づけられたデータ</p> -</li> -</ul> -</div> -</li> -<li> -<p>ステート</p> -<div class="ulist"> -<ul> -<li> -<p>現在の状態</p> -</li> -</ul> -</div> -</li> -</ul> -</div> -<div class="paragraph"> -<p>まずは標準の HTML 要素で解決する 何でもかんでも WAI-ARIA -を使えばいいというものではない</p> -</div> -<div class="paragraph"> -<p>マウスホバーでツールチップが出てくるが、キーボード操作では出てこない</p> -</div> -<div class="paragraph"> -<p>VoiceOver</p> -</div> -<div class="paragraph"> -<p>全ての属性を使う必要はない -あくまでアクセシビリティを上げるための方法の一つにすぎない</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>つい最近 WAI-ARIA -についての記事を読んだばかりだったので個人的にタイムリーな話題だった。(あまりこの言葉を使いたくないのだが) -いわゆる「健常者」にとって、こうした問題を普段の生活の中で意識するのは難しい。だからこそ情報へのアンテナは張っておくようにしたい。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 19:30 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>PHP で FUSE</p> -</div> -<div class="paragraph"> -<p>個人的に楽しみだった発表。</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>VFS (virtual filesystem) vs 具体的なファイルシステム</p> -</div> -<div class="paragraph"> -<p>最適な実装方法は状況により異なる</p> -</div> -<div class="paragraph"> -<p>アプリケーションに見せるAPIは変えずに実装を隠蔽する→VFS</p> -</div> -<div class="paragraph"> -<p>カーネルのプログラムを作るのは難しい -* 権限がデカすぎる -* システム全体がクラッシュ -* セキュリティリスク -* 開発サイクルを回しづらい -* ネイティブコードにコンパイルされる言語である必要がある</p> -</div> -<div class="paragraph"> -<p>Filesystem in USEr space (FUSE)</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>特定の C の関数を呼ぶことで filesystem が作れる</p> -</li> -<li> -<p>FFI を持つ言語なら FUSE が使える</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>SSHFS / s3fs / Docker Desktop</p> -</div> -<div class="paragraph"> -<p>Linux 以外でも使える</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>dokany (on Windows)</p> -</li> -<li> -<p>osxfuse</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>VFS: システムコールが呼ばれると、ファイルシステムによってコール FUSE: -カーネル空間からユーザ空間へ通信</p> -</div> -<div class="paragraph"> -<p>高レベルなラッパで型をつける</p> -</div> -<div class="paragraph"> -<p>PHP 以外では Wordpress を FUSE にマウントする実装がある (C, Python など)</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>grep できる</p> -</li> -<li> -<p>sed できる</p> -</li> -<li> -<p>編集できる</p> -</li> -</ul> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>期待通りの興味深い発表だった。FUSE -自体も今回の発表で知ったのだが、これ本体の実装を見るのも面白そうだ。 -この発表を聞きながらファイルシステムにマウントできそうなものを考えていたのだが、およそ木構造をしているものすべてと言えそうだ -(ハンマーしか持っていないと云々)。何かできそうだがなかなか思いつかない。</p> -</div> - </div> -</section> - </div> -</section> -<section class="section-2"> - <h3 id="" class="section-header"> - - Day 1 (2021/03/27) - - </h3> - <div class="section-body"> - <section class="section-3"> - <h4 id="" class="section-header"> - - 10:50 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>ATDD</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="ulist"> -<ul> -<li> -<p>ユーザーストーリー</p> -</li> -<li> -<p>ユニットテスト</p> -</li> -<li> -<p>CI/CD</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>ユーザストーリーの受け入れ条件が曖昧になりがち -デグレチェックがユニットレベルでは収まらない場合、手動で同じシナリオをテストしている</p> -</div> -<div class="paragraph"> -<p>Q2の強化 アジャイルテストの4象限</p> -</div> -<div class="paragraph"> -<p>技術面/ビジネス面 -開発チーム支援(コーディング前・コーディング中)/製品批評(コーディング後)</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>Q1: 技術面 & チーム支援</p> -<div class="ulist"> -<ul> -<li> -<p>TDD</p> -</li> -<li> -<p>ユニットテストなど</p> -</li> -</ul> -</div> -</li> -<li> -<p>Q2: ビジネス面 & チーム支援</p> -<div class="ulist"> -<ul> -<li> -<p>ATDD</p> -</li> -<li> -<p>ビジネス面の受け入れテストで駆動する</p> -</li> -</ul> -</div> -</li> -</ul> -</div> -<div class="paragraph"> -<p>Agile Alliance ユーザストーリーのスキルレベルを高める</p> -</div> -<div class="paragraph"> -<p>テストピラミッド</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>UI Tests</p> -</li> -<li> -<p>Service Tests</p> -</li> -<li> -<p>Unit Tests</p> -</li> -<li> -<p>異なる粒度のテストを書く</p> -</li> -<li> -<p>高レベルになるほど、持つべきテストは少なくなる</p> -<div class="ulist"> -<ul> -<li> -<p>ピラミッド型になる</p> -</li> -</ul> -</div> -</li> -</ul> -</div> -<div class="paragraph"> -<p>高レベルテストが多すぎる→アイスクリームコーン アンチパターン</p> -</div> -<div class="paragraph"> -<p>ATDD (Acceptance TDD) API経由・UI経由での高レベルテスト E2E test</p> -</div> -<div class="paragraph"> -<p>ストーリ受け入れテスト</p> -</div> -<div class="paragraph"> -<p>入れ子のフィードバックループ ATDD(外側) と TDD(内側)</p> -</div> -<div class="paragraph"> -<p>外部品質・内部品質</p> -</div> -<div class="paragraph"> -<p>バーティカルスライスのデリバリー</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>cucumber</p> -</li> -<li> -<p>gauge</p> -</li> -<li> -<p>behat</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>ユビキタス言語 手動テストもspecに書く 自動化は可能だがコスパが悪い -失敗することがわかっているテスト(レッドテスト)はCIから外す -失敗時の原因究明が難しい 饒舌なエラーメッセージ 状況のスナップショット</p> -</div> -<div class="paragraph"> -<p>Continuous Testing</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>User Acceptance Test (UAT) -くらいの規模になると個人開発・趣味開発では触れない領域なので、大いに勉強になった。スライドに添付されている資料が相当に充実していたので、これを読むのが本番といった様相すら感じる。 -高レベルテストの自動化は現在のプロジェクトでも感じており、自動化のチャンスは伺っている。とはいえセッションでも指摘されているように自動化することにコストがかかりすぎる領域があるのも事実で、そのバランスが難しい。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 11:50 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>型解析を用いたリファクタリング</p> -</div> -<div class="paragraph"> -<p>型のある世界で生きてきた身として大いに楽しみにしていた発表。</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="ulist"> -<ul> -<li> -<p>PHPStan</p> -</li> -<li> -<p>Phan</p> -</li> -<li> -<p>Psalm</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>autoload も認識できる bootstrapFiles</p> -</div> -<div class="paragraph"> -<p>編集箇所と利用箇所を CI でチェック ルールレベルを徐々に引き上げていく -警告が多すぎると見落としてしまう・無視されやすくなる</p> -</div> -<div class="paragraph"> -<p>型がついていないことによるエラーが多い</p> -</div> -<div class="paragraph"> -<p>型よりも詳細な検査 <code>Util_Assert::min</code></p> -</div> -<div class="paragraph"> -<p>SQL を静的解析 placeholder の型付け</p> -</div> -<div class="paragraph"> -<p>警告レベルを低いレベルから導入 タイプヒントを積極的に書いていく PHPStan -の拡張を追加する</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>昨今、動的型付き言語での型宣言・型アノテーション・型ヒントの導入が相次いでいる。長らく静的型付き言語を書いてきた私からすると、ようやく気づいたかといったところだが、ともかく型を導入する言語が増えてきた。 -今のプロジェクトでも新しく追加するコードには型をつけるよう努めているが、どうしても古いコードには型がついていない。個人的には型のないコードに対してどう型を自動的に付けるかという点に興味があり、その点で -Ruby の typeprof には注目している。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 12:30 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>昼食をとっていた。事前に何か食料を買っておくべきだった。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 13:10 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>Documentation as Code</p> -</div> -<div class="paragraph"> -<p>この発表も以前から非常に楽しみにしていた。</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>開発開始までのオーバーヘッド 新規にチームにジョイン -担当範囲外の機能を理解 オンボーディングのコスト</p> -</div> -<div class="paragraph"> -<p>PHPerKaigi 2020 で発表あり</p> -</div> -<div class="paragraph"> -<p>継続的にシステムの理解を助けるドキュメント</p> -</div> -<div class="paragraph"> -<p>継続的ドキュメンテーション システムとドキュメントの乖離</p> -</div> -<div class="paragraph"> -<p>書いてあることが間違っている・足りない * 徐々にずれていく * -システムの更新タイミングとドキュメントの更新タイミングに差がある</p> -</div> -<div class="paragraph"> -<p>システムとドキュメントは対応関係がある * 間違ったドキュメント * -存在しないドキュメント</p> -</div> -<div class="paragraph"> -<p>システムとドキュメントの乖離を定量化する 継続的に -システムの更新に近いタイミングで ドキュメントを更新し続ける</p> -</div> -<div class="paragraph"> -<p>Documentation as Code</p> -</div> -<div class="paragraph"> -<p>コードと同じツールでドキュメントを書く * issue tracker * vcs * plain -text markup * automation</p> -</div> -<div class="paragraph"> -<p>開発者 システム ドキュメント 構造化データ ソフトウェア</p> -</div> -<div class="paragraph"> -<p>システムから構造化データを抽出する PHPDoc OpenAPI</p> -</div> -<div class="paragraph"> -<p>ビュー 関心ごとに合わせてアーキテクチャを一つ以上の側面(断面)で説明する</p> -</div> -<div class="paragraph"> -<p>ビューの単位でドキュメントに</p> -</div> -<div class="paragraph"> -<p>スタックトレースからのドキュメント生成</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>ドキュメントの管理は現プロジェクトでも課題と感じている。作られた当初は正しくても、実態と乖離していくのを止めるのは困難を極める。全体的に興味深い発表だったが、特にスタックトレースからのドキュメント生成というアイデアに惹かれるものを感じた。スタックトレースという実態と不可分な -(乖離しない) -情報を起点にするのは理にかなっている。問題はトレースをいつ、どう取るかだろうか。それを自動化しなければ、実態との乖離が避けられないだろう。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 14:10 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>cookie による session 管理</p> -</div> -<div class="paragraph"> -<p>全体的に基本的な話だったので特に触れない。Cookie -やセッションの話としては非常に分かりやすくまとめられていたので、知らない人が学ぶにはいい教材だろう。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 14:50 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>PHP のエラーと例外</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>エラー PHPエンジンがエラーを通知する 例外 プログラムが投げる</p> -</div> -<div class="paragraph"> -<p>PHP7-8とエラー</p> -</div> -<div class="paragraph"> -<p>PHPエンジンのエラーの一部が に変換されるようになった → try-catch -で捕捉できる</p> -</div> -<div class="paragraph"> -<p>は例外とは異なる</p> -</div> -<div class="paragraph"> -<p>PHP8 でエラーレベルの引き上げ</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>捕捉すべきもの</p> -<div class="ulist"> -<ul> -<li> -<p>recoverable</p> -</li> -</ul> -</div> -</li> -<li> -<p>捕捉すべきでないもの</p> -<div class="ulist"> -<ul> -<li> -<p>unrecoverable</p> -</li> -<li> -<p>開発時に対処できるもの</p> -</li> -</ul> -</div> -</li> -</ul> -</div> -<div class="paragraph"> -<p>例外 * 捕捉して事後処理 * 捕捉せず(or 捕捉した上で)さらに上に是非を問う</p> -</div> -<div class="paragraph"> -<p>開発段階で例外を把握し、ハンドリングを考えておく</p> -</div> -<div class="paragraph"> -<p>と</p> -</div> -<div class="paragraph"> -<p>はキャッチすべきでない</p> -</div> -<div class="ulist"> -<ul> -<li> -<p></p> -<div class="ulist"> -<ul> -<li> -<p>本番で起きてはいけない</p> -</li> -</ul> -</div> -</li> -<li> -<p></p> -<div class="ulist"> -<ul> -<li> -<p>本番で起きてはいけない →生じないのだから捕捉もしない</p> -</li> -</ul> -</div> -</li> -<li> -<p></p> -<div class="ulist"> -<ul> -<li> -<p>起こるかもしれないので本番環境でも考慮する</p> -</li> -</ul> -</div> -</li> -</ul> -</div> -<div class="paragraph"> -<p>捕捉して対応するのではなく、未然に防ぐ</p> -</div> -<div class="paragraph"> -<p>独自例外を使う を投げてしまうと、 catch ()せざるを得ない →catch -範囲が広すぎる</p> -</div> -<div class="paragraph"> -<p>SPL の例外を使う</p> -</div> -<div class="paragraph"> -<p>例外翻訳 -上位のレイヤが下位のレイヤの例外を捕捉し、上位レイヤのAPIに「翻訳」する -下位レイヤの知識に依存させない</p> -</div> -<div class="paragraph"> -<p>@throws 捕捉してほしい例外を書き連ねておく</p> -</div> -<div class="paragraph"> -<p>呼び出しもとに負わせたい責任</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>PHP を学んでいる途中の私としては、今まさに聞きたい発表だった (現時点で -PHP を書き始めてから 4ヶ月ほどになる)。</p> -</div> -<div class="paragraph"> -<p>個人的に例外やエラーを最もうまく扱っているのは Go、Swift、Rust、Haskell -などのエラーを「値として」扱う言語だと思っている。try-catch -は通常の処理フローを完全に壊してしまう上、構文としても重すぎる。値としてのエラー通知は -C言語時代への回帰ともいえるが、その頃と異なるのはエラーを暗黙のうちに握り潰すことがないということだ。これらの言語は型を持っており、静的に検証ができる -(C のそれはまともな型付けではない。念のため)。</p> -</div> -<div class="paragraph"> -<p>PHP -のように、すでに例外が言語システムに根ざしている言語ではどうすればよいか。この場合も同じく静的検証の力を借りることになるだろう。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 15:30 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>Laravel のメール認証</p> -</div> -<div class="paragraph"> -<p>Laravel -の知識がない私にはまったくついていけなかった。また、個人的にタイトルがややミスリーディングに感じた。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 16:10 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>gRPC</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>Unary RPCs Server streaming RPCs Client streaming RPCs Bidirectional -streaming RPCs</p> -</div> -<div class="paragraph"> -<p>Protobuf</p> -</div> -<div class="paragraph"> -<p>実装とAPIが乖離しにくい 自動生成 複数言語でも相互に使える</p> -</div> -<div class="paragraph"> -<p>マイクロサービスのサービス通信 スマホアプリ ゲームサーバ</p> -</div> -<div class="paragraph"> -<p>PHP では？</p> -</div> -<div class="paragraph"> -<p>PHP ではストリーミングが難しい リクエストごとにプロセスが使い捨て</p> -</div> -<div class="paragraph"> -<p>PHP ではgRPCのクライアントしか対応していない</p> -</div> -<div class="paragraph"> -<p>gRPC-Web ブラウザで扱うためのJSライブラリ+プロトコル</p> -</div> -<div class="paragraph"> -<p>HTTP/1.1 でも使える Unary RPC と Server streaming RPC のみ</p> -</div> -<div class="paragraph"> -<p>Envoy Nginx などで相互に gRPC と gRPC-Web で変換</p> -</div> -<div class="paragraph"> -<p>Amp イベント駆動な並行処理のフレームワーク</p> -</div> -<div class="paragraph"> -<p>HTTP/2 対応</p> -</div> -<div class="paragraph"> -<p>C#のgRPC-Webが楽</p> -</div> -</blockquote> -</div> -<div class="paragraph"> -<p>(発表の中でもまさに同じことをおっしゃっていたが) PHP -以外の方が向いているだろう、というのが第一の感想である。gRPC -はそれ自体というよりも Protobuf -というエコシステムに乗れることのメリットが大きいと感じる。そのエコシステムにうまく乗れない時点で、うーんという感じ。</p> -</div> - </div> -</section> -<section class="section-3"> - <h4 id="" class="section-header"> - - 16:50 [A] - - </h4> - <div class="section-body"> - <div class="paragraph"> -<p>アーキテクチャテスト</p> -</div> -<div class="quoteblock"> -<blockquote> -<div class="paragraph"> -<p>Independent Core Layer Pattern</p> -</div> -<div class="paragraph"> -<p>開発初期のアーキテクチャが崩れる -アーキテクチャ観点のコードレビューができない</p> -</div> -<div class="paragraph"> -<p>どこにクラスを置けばよいか？ ドキュメントがない</p> -</div> -<div class="paragraph"> -<p>アーキテクチャ設計に関する知識が属人化・暗黙知化</p> -</div> -<div class="paragraph"> -<p>ガイドライン * 最初にルールを決めるのは簡単 * -ルール通り作り始めるのも簡単 * -→維持するのが難しい、人が決めたものゆえ壊れやすい</p> -</div> -<div class="paragraph"> -<p>PHP の特性 * クラスは public * 可視性の制御が public / protected / -private のみ * 依存関係の制御が困難</p> -</div> -<div class="paragraph"> -<p>アーキテクチャテスト -クラスの依存関係や実装ルールをコードとして表現し、自動テスト化する</p> -</div> -<div class="ulist"> -<ul> -<li> -<p>deptrac</p> -</li> -<li> -<p>phpat</p> -</li> -</ul> -</div> -<div class="paragraph"> -<p>Independent Core Layer Pattern</p> -</div> -<div class="paragraph"> -<p>アーキテクチャテストの失敗 * 実装誤り * or アーキテクチャが適切でない * -開発の過程でフィードバックしていく</p> -</div> -<div class="paragraph"> -<p>モジュラーモノリス→マイクロサービスへ</p> -</div> -</blockquote> -</div> - </div> -</section> - </div> -</section> -<section class="section-2"> - <h3 id="" class="section-header"> - - Day 2 (2021/03/28) - - </h3> - <div class="section-body"> - <div class="paragraph"> -<p>冒頭に書いた通り、2日目から体調が悪くまともに聴けていない。途中までは頭痛を我慢しつつ見ていたのだが、まともに入ってこなかった。</p> -</div> -<div class="paragraph"> -<p>残念ではあるが、いずれにせよ見られていない発表は他にもあるので、今週末にでもまとめて見ようと思う。</p> -</div> - </div> -</section> -<section class="section-2"> - <h3 id="" class="section-header"> - - 全体の感想 - - </h3> - <div class="section-body"> - <div class="paragraph"> -<p>Day 2 -にほとんど参加できなかったのは残念だが、イベント自体は大変楽しく、また興味深いものであった。自分がまったく知らない領域の話を聞けるのはこうしたイベントならではだと感じる。オンライン開催ゆえ現地に行く必要がなく、気軽に参加できたのも -(特に初参加者として) 嬉しいポイントだった。</p> -</div> -<div class="paragraph"> -<p>今回、雑談/登壇者への質問等向けに Discord -サーバもあったのだが、こちらは参加こそしたものの ROM -のままになってしまった。発表に1ウィンドウ、メモを書くのに1ウィンドウ、Discord -表示に -1ウィンドウで私にはもう脳のリソースとディスプレイのスペースが追いつかなかった -(さらにいうと Zoom -でアンカンファレンスもやっていたようだ。こちらはまったく参加していない)。</p> -</div> -<div class="paragraph"> -<p>1つ個人的な反省点としては、一つ一つのセッションを真剣に聞き過ぎたというものがある。もっと適当に聞いておけばよかった。これだけだと大変語弊があるのだが、言い方を変えると、Discord -しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、後から見返せる発表やスライドに注力してしまった、ということだ。発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。 -まあ初カンファレンスだし、とお茶を濁しておこう。</p> -</div> -<div class="paragraph"> -<p>さて、カンファレンスで一つ気になったことがある。それは、Discord -という書き込み場所が増えたことでニコ生のコメントの流量が吸い取られてしまったのではないか、という点だ。ニコニコだけ見ていると過疎っているかのように見えた発表も、Discord -の方では盛り上がっている、というのを何度か見かけた。ニコニコのコメント方式は盛り上がりを如実に反映するが、逆もまたしかり。Discord -があったこと自体はプラスだったと思うが、この点はマイナスだったのではないかと感じる。</p> -</div> -<hr> -<div class="paragraph"> -<p>最後になりましたが、毎年の PHPerKaigi -開催にご尽力されている皆様、スピーカーの皆様、楽しい3日間でした。ありがとうございました！ -(ずっと常体で書いてしまったのでいきなり仏頂面から笑顔になったようで気持ち悪い)</p> -</div> -<div class="paragraph"> -<p>ではまた来年。</p> -</div> - </div> -</section> - </div> -</section> </div> - </article> </main> <footer class="footer"> |