aboutsummaryrefslogtreecommitdiffhomepage
path: root/public/posts/2021-03-30/phperkaigi-2021/index.html
diff options
context:
space:
mode:
authornsfisis <nsfisis@gmail.com>2023-03-19 00:47:11 +0900
committernsfisis <nsfisis@gmail.com>2023-03-19 00:47:11 +0900
commit88b66f82aae2d7784002b07bfc7877932da3ec94 (patch)
tree4950a8f9f740715f2c56383309edab97df37a2f5 /public/posts/2021-03-30/phperkaigi-2021/index.html
parent0e5fff11e9a455273dad77fc26796af03ddf08d3 (diff)
downloadblog.nsfisis.dev-88b66f82aae2d7784002b07bfc7877932da3ec94.tar.gz
blog.nsfisis.dev-88b66f82aae2d7784002b07bfc7877932da3ec94.tar.zst
blog.nsfisis.dev-88b66f82aae2d7784002b07bfc7877932da3ec94.zip
fix(content): fix XML notations
Diffstat (limited to 'public/posts/2021-03-30/phperkaigi-2021/index.html')
-rw-r--r--public/posts/2021-03-30/phperkaigi-2021/index.html298
1 files changed, 149 insertions, 149 deletions
diff --git a/public/posts/2021-03-30/phperkaigi-2021/index.html b/public/posts/2021-03-30/phperkaigi-2021/index.html
index f42b9b1..2e7df8c 100644
--- a/public/posts/2021-03-30/phperkaigi-2021/index.html
+++ b/public/posts/2021-03-30/phperkaigi-2021/index.html
@@ -9,7 +9,7 @@
<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="/style.css?h=48694677b43b77e5c45f25e6bfdebb41">
+ <link rel="stylesheet" href="/style.css?h=36f8a090080ebb76d78b17f1d93b3ba4">
<link rel="stylesheet" href="/hl.css?h=340e65ffd5c17713efc9107c06304f7b">
</head>
<body class="single">
@@ -62,27 +62,27 @@
<section id="section--_phperkaigi_2021_参加レポ">
<h2><a href="#section--_phperkaigi_2021_参加レポ">PHPerKaigi 2021 参加レポ</a></h2>
<p>
- 2021-03-26 から 2021-03-28 にかけて開催された、 <a href="https://phperkaigi.jp/2021/">PHPerKaigi 2021</a> に一般参加者として参加した。 弊社 <a href="https://www.dgcircus.com/">デジタルサーカス株式会社</a> (今年1月から勤務) はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。
+ 2021-03-26 から 2021-03-28 にかけて開催された、 <a href="https://phperkaigi.jp/2021/">PHPerKaigi 2021</a> に一般参加者として参加した。 弊社 <a href="https://www.dgcircus.com/">デジタルサーカス株式会社</a> (今年1月から勤務) はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。
</p>
<p>
- このようなカンファレンスには初めて参加するのでかねてより心待ちにしていたのだが、生憎2日目から体調を崩してしまい、この記事も途中までとなっている。まだ見ていないセッションも多いが、ひとまず現時点での参加レポを書いておく。
+ このようなカンファレンスには初めて参加するのでかねてより心待ちにしていたのだが、生憎2日目から体調を崩してしまい、この記事も途中までとなっている。まだ見ていないセッションも多いが、ひとまず現時点での参加レポを書いておく。
</p>
<p>
- 発表はトラック A、B に分かれていたのだが、今回はすべて A トラックを視聴している (切り替えるのが面倒だっただけ)。
+ 発表はトラック A、B に分かれていたのだが、今回はすべて A トラックを視聴している (切り替えるのが面倒だっただけ)。
</p>
<section id="section--_凡例">
<h3><a href="#section--_凡例">凡例</a></h3>
<blockquote>
<p>
- 発表・スライドのメモ (引用ではない)
+ 発表・スライドのメモ (引用ではない)
</p>
</blockquote>
<p>
- 感想など
+ 感想など
</p>
</section>
@@ -91,12 +91,12 @@
<section id="section--_1730_a">
<h4><a href="#section--_1730_a">17:30 [A]</a></h4>
<p>
- PHP で AWS Lambda
+ PHP で AWS Lambda
</p>
<blockquote>
<p>
- Rails のプロジェクトを PHPer のメンバのみでメンテ →他のメンバもわかる PHP にリプレースを検討
+ Rails のプロジェクトを PHPer のメンバのみでメンテ →他のメンバもわかる PHP にリプレースを検討
</p>
<ul>
@@ -114,68 +114,68 @@
</ul>
<p>
- ゼロベースで作れる案件が (Railsの件とは別に) あるため、そちらで試験的に導入?
+ ゼロベースで作れる案件が (Railsの件とは別に) あるため、そちらで試験的に導入?
</p>
<p>
- AWSの学習 AWS のドキュメント DevelopersIO
+ AWSの学習 AWS のドキュメント DevelopersIO
</p>
<p>
- AWS Lambda のカスタムランタイムで PHP を動かす
+ AWS Lambda のカスタムランタイムで PHP を動かす
</p>
<p>
- サーバのセットアップや維持管理を気にしなくて良い サーバーレスで PHP を動かすツールがすでにある サーバーレス構築はすんなり
+ サーバのセットアップや維持管理を気にしなくて良い サーバーレスで PHP を動かすツールがすでにある サーバーレス構築はすんなり
</p>
<p>
- 今は Laravel がルーティングしている Laravel Livewire を Lambda に載せられないか？ デプロイ方法は？ バッチ処理は？ (Lambda は 15分の制限)
+ 今は Laravel がルーティングしている Laravel Livewire を Lambda に載せられないか？ デプロイ方法は？ バッチ処理は？ (Lambda は 15分の制限)
</p>
<p>
- Lambda でコンテナイメージがサポートされるように
+ Lambda でコンテナイメージがサポートされるように
</p>
<p>
- 抽象化されたもの「だけ」しか知らないよりも具象の理解は助けになる
+ 抽象化されたもの「だけ」しか知らないよりも具象の理解は助けになる
</p>
</blockquote>
<p>
- AWS Lambda のような Function as a Service はマイクロサービス化における一つの到達点に思えるのだが、これを使って実際に web サービスを作る具体的なイメージがまだ見えない (注: すべて for me として書いている)。
+ AWS Lambda のような Function as a Service はマイクロサービス化における一つの到達点に思えるのだが、これを使って実際に web サービスを作る具体的なイメージがまだ見えない (注: すべて for me として書いている)。
</p>
<p>
- PHP on AWS Lambda があれだけ簡単に動かせるのには驚いた。
+ PHP on AWS Lambda があれだけ簡単に動かせるのには驚いた。
</p>
<p>
- 勝手に AWS Lambda だとフットプリントの軽さが求められそう (= PHP + Laravel などでは動かなさそう) だという先入観を持っていたのだが、この発表のデモによればそうでもないらしい。
+ 勝手に AWS Lambda だとフットプリントの軽さが求められそう (= PHP + Laravel などでは動かなさそう) だという先入観を持っていたのだが、この発表のデモによればそうでもないらしい。
</p>
</section>
<section id="section--_1810_a">
<h4><a href="#section--_1810_a">18:10 [A]</a></h4>
<p>
- 大規模サイトの SEO
+ 大規模サイトの SEO
</p>
<blockquote>
<p>
- 大規模サイト (100万ページ以上) Google の基準
+ 大規模サイト (100万ページ以上) Google の基準
</p>
<p>
- クロールバジェットを意識したSEO
+ クロールバジェットを意識したSEO
</p>
<p>
- 大規模サイトでコンテンツが中頻度 (1回/週) で更新 OR 中規模サイト (10,000以上) でコンテンツが目まぐるしく変更される これを満たさないなら、クロールバジェットを考えなくてもいい
+ 大規模サイトでコンテンツが中頻度 (1回/週) で更新 OR 中規模サイト (10,000以上) でコンテンツが目まぐるしく変更される これを満たさないなら、クロールバジェットを考えなくてもいい
</p>
<p>
- サーチコンソール 「カバレッジ」の「除外」 多すぎるのは問題→クロールバジェットを浪費している
+ サーチコンソール 「カバレッジ」の「除外」 多すぎるのは問題→クロールバジェットを浪費している
</p>
<ul>
@@ -197,28 +197,28 @@
</ul>
<p>
- リニューアル前のURL
+ リニューアル前のURL
</p>
<p>
- インデックスは移行される リンクのURLが存在する限り、別のURLとしてクロールされる リダイレクトされるとはいえ、リニューアル前のURLは移行した方が良い リニューアルで無視されるようになったパラメータも注意
+ インデックスは移行される リンクのURLが存在する限り、別のURLとしてクロールされる リダイレクトされるとはいえ、リニューアル前のURLは移行した方が良い リニューアルで無視されるようになったパラメータも注意
</p>
<p>
- robotes.txt で拒否しているのにクロールされる 一時的に拒否を外して 404 や 301 を読ませる 内部リンクを確認する JS でのリンクに書き換え
+ robotes.txt で拒否しているのにクロールされる 一時的に拒否を外して 404 や 301 を読ませる 内部リンクを確認する JS でのリンクに書き換え
</p>
<p>
- クエリパラメータからURLのパスに <code>/tokyo?area=HOGE</code> → <code>/tokyo/HOGE</code>
+ クエリパラメータからURLのパスに <code>/tokyo?area=HOGE</code> → <code>/tokyo/HOGE</code>
</p>
<p>
- URL 設計だいじ
+ URL 設計だいじ
</p>
</blockquote>
<p>
- SEO (Search Engine Optimization) は大して知らないので新鮮な話が多かった。その分語れることも少ない……。
+ SEO (Search Engine Optimization) は大して知らないので新鮮な話が多かった。その分語れることも少ない……。
</p>
</section>
@@ -226,7 +226,7 @@
<h4><a href="#section--_1850_a">18:50 [A]</a></h4>
<blockquote>
<p>
- 知覚可能 操作可能 理解可能 堅牢 ちゃんとしたHTMLを書く (閉じタグ・入れ子構造など)
+ 知覚可能 操作可能 理解可能 堅牢 ちゃんとしたHTMLを書く (閉じタグ・入れ子構造など)
</p>
<ul>
@@ -252,11 +252,11 @@
</ul>
<p>
- button タグ →キーボード h1 タグ →スクリーンリーダー・クローラ a タグ
+ button タグ →キーボード h1 タグ →スクリーンリーダー・クローラ a タグ
</p>
<p>
- WAI-ARIA HTML では表現できないセマンティクスを追加する
+ WAI-ARIA HTML では表現できないセマンティクスを追加する
</p>
<ul>
@@ -293,56 +293,56 @@
</ul>
<p>
- まずは標準の HTML 要素で解決する 何でもかんでも WAI-ARIA を使えばいいというものではない
+ まずは標準の HTML 要素で解決する 何でもかんでも WAI-ARIA を使えばいいというものではない
</p>
<p>
- マウスホバーでツールチップが出てくるが、キーボード操作では出てこない
+ マウスホバーでツールチップが出てくるが、キーボード操作では出てこない
</p>
<p>
- VoiceOver
+ VoiceOver
</p>
<p>
- 全ての属性を使う必要はない あくまでアクセシビリティを上げるための方法の一つにすぎない
+ 全ての属性を使う必要はない あくまでアクセシビリティを上げるための方法の一つにすぎない
</p>
</blockquote>
<p>
- つい最近 WAI-ARIA についての記事を読んだばかりだったので個人的にタイムリーな話題だった。(あまりこの言葉を使いたくないのだが) いわゆる「健常者」にとって、こうした問題を普段の生活の中で意識するのは難しい。だからこそ情報へのアンテナは張っておくようにしたい。
+ つい最近 WAI-ARIA についての記事を読んだばかりだったので個人的にタイムリーな話題だった。(あまりこの言葉を使いたくないのだが) いわゆる「健常者」にとって、こうした問題を普段の生活の中で意識するのは難しい。だからこそ情報へのアンテナは張っておくようにしたい。
</p>
</section>
<section id="section--_1930_a">
<h4><a href="#section--_1930_a">19:30 [A]</a></h4>
<p>
- PHP で FUSE
+ PHP で FUSE
</p>
<p>
- 個人的に楽しみだった発表。
+ 個人的に楽しみだった発表。
</p>
<blockquote>
<p>
- VFS (virtual filesystem) vs 具体的なファイルシステム
+ VFS (virtual filesystem) vs 具体的なファイルシステム
</p>
<p>
- 最適な実装方法は状況により異なる
+ 最適な実装方法は状況により異なる
</p>
<p>
- アプリケーションに見せるAPIは変えずに実装を隠蔽する→VFS
+ アプリケーションに見せるAPIは変えずに実装を隠蔽する→VFS
</p>
<p>
- カーネルのプログラムを作るのは難しい * 権限がデカすぎる * システム全体がクラッシュ * セキュリティリスク * 開発サイクルを回しづらい * ネイティブコードにコンパイルされる言語である必要がある
+ カーネルのプログラムを作るのは難しい * 権限がデカすぎる * システム全体がクラッシュ * セキュリティリスク * 開発サイクルを回しづらい * ネイティブコードにコンパイルされる言語である必要がある
</p>
<p>
- Filesystem in USEr space (FUSE)
+ Filesystem in USEr space (FUSE)
</p>
<ul>
@@ -356,11 +356,11 @@
</ul>
<p>
- SSHFS / s3fs / Docker Desktop
+ SSHFS / s3fs / Docker Desktop
</p>
<p>
- Linux 以外でも使える
+ Linux 以外でも使える
</p>
<ul>
@@ -374,15 +374,15 @@
</ul>
<p>
- VFS: システムコールが呼ばれると、ファイルシステムによってコール FUSE: カーネル空間からユーザ空間へ通信
+ VFS: システムコールが呼ばれると、ファイルシステムによってコール FUSE: カーネル空間からユーザ空間へ通信
</p>
<p>
- 高レベルなラッパで型をつける
+ 高レベルなラッパで型をつける
</p>
<p>
- PHP 以外では Wordpress を FUSE にマウントする実装がある (C, Python など)
+ PHP 以外では Wordpress を FUSE にマウントする実装がある (C, Python など)
</p>
<ul>
@@ -401,7 +401,7 @@
</blockquote>
<p>
- 期待通りの興味深い発表だった。FUSE 自体も今回の発表で知ったのだが、これ本体の実装を見るのも面白そうだ。 この発表を聞きながらファイルシステムにマウントできそうなものを考えていたのだが、およそ木構造をしているものすべてと言えそうだ (ハンマーしか持っていないと云々)。何かできそうだがなかなか思いつかない。
+ 期待通りの興味深い発表だった。FUSE 自体も今回の発表で知ったのだが、これ本体の実装を見るのも面白そうだ。 この発表を聞きながらファイルシステムにマウントできそうなものを考えていたのだが、およそ木構造をしているものすべてと言えそうだ (ハンマーしか持っていないと云々)。何かできそうだがなかなか思いつかない。
</p>
</section>
</section>
@@ -411,7 +411,7 @@
<section id="section--_1050_a">
<h4><a href="#section--_1050_a">10:50 [A]</a></h4>
<p>
- ATDD
+ ATDD
</p>
<blockquote>
@@ -430,15 +430,15 @@
</ul>
<p>
- ユーザストーリーの受け入れ条件が曖昧になりがち デグレチェックがユニットレベルでは収まらない場合、手動で同じシナリオをテストしている
+ ユーザストーリーの受け入れ条件が曖昧になりがち デグレチェックがユニットレベルでは収まらない場合、手動で同じシナリオをテストしている
</p>
<p>
- Q2の強化 アジャイルテストの4象限
+ Q2の強化 アジャイルテストの4象限
</p>
<p>
- 技術面/ビジネス面 開発チーム支援(コーディング前・コーディング中)/製品批評(コーディング後)
+ 技術面/ビジネス面 開発チーム支援(コーディング前・コーディング中)/製品批評(コーディング後)
</p>
<ul>
@@ -470,11 +470,11 @@
</ul>
<p>
- Agile Alliance ユーザストーリーのスキルレベルを高める
+ Agile Alliance ユーザストーリーのスキルレベルを高める
</p>
<p>
- テストピラミッド
+ テストピラミッド
</p>
<ul>
@@ -505,27 +505,27 @@
</ul>
<p>
- 高レベルテストが多すぎる→アイスクリームコーン　アンチパターン
+ 高レベルテストが多すぎる→アイスクリームコーン　アンチパターン
</p>
<p>
- ATDD (Acceptance TDD) API経由・UI経由での高レベルテスト E2E test
+ ATDD (Acceptance TDD) API経由・UI経由での高レベルテスト E2E test
</p>
<p>
- ストーリ受け入れテスト
+ ストーリ受け入れテスト
</p>
<p>
- 入れ子のフィードバックループ ATDD(外側) と TDD(内側)
+ 入れ子のフィードバックループ ATDD(外側) と TDD(内側)
</p>
<p>
- 外部品質・内部品質
+ 外部品質・内部品質
</p>
<p>
- バーティカルスライスのデリバリー
+ バーティカルスライスのデリバリー
</p>
<ul>
@@ -543,27 +543,27 @@
</ul>
<p>
- ユビキタス言語 手動テストもspecに書く 自動化は可能だがコスパが悪い 失敗することがわかっているテスト(レッドテスト)はCIから外す 失敗時の原因究明が難しい 饒舌なエラーメッセージ 状況のスナップショット
+ ユビキタス言語 手動テストもspecに書く 自動化は可能だがコスパが悪い 失敗することがわかっているテスト(レッドテスト)はCIから外す 失敗時の原因究明が難しい 饒舌なエラーメッセージ 状況のスナップショット
</p>
<p>
- Continuous Testing
+ Continuous Testing
</p>
</blockquote>
<p>
- User Acceptance Test (UAT) くらいの規模になると個人開発・趣味開発では触れない領域なので、大いに勉強になった。スライドに添付されている資料が相当に充実していたので、これを読むのが本番といった様相すら感じる。 高レベルテストの自動化は現在のプロジェクトでも感じており、自動化のチャンスは伺っている。とはいえセッションでも指摘されているように自動化することにコストがかかりすぎる領域があるのも事実で、そのバランスが難しい。
+ 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>
@@ -582,151 +582,151 @@
</ul>
<p>
- autoload も認識できる bootstrapFiles
+ autoload も認識できる bootstrapFiles
</p>
<p>
- 編集箇所と利用箇所を CI でチェック ルールレベルを徐々に引き上げていく 警告が多すぎると見落としてしまう・無視されやすくなる
+ 編集箇所と利用箇所を CI でチェック ルールレベルを徐々に引き上げていく 警告が多すぎると見落としてしまう・無視されやすくなる
</p>
<p>
- 型がついていないことによるエラーが多い
+ 型がついていないことによるエラーが多い
</p>
<p>
- 型よりも詳細な検査 <code>Util_Assert::min</code>
+ 型よりも詳細な検査 <code>Util_Assert::min</code>
</p>
<p>
- SQL を静的解析 placeholder の型付け
+ SQL を静的解析 placeholder の型付け
</p>
<p>
- 警告レベルを低いレベルから導入 タイプヒントを積極的に書いていく PHPStan の拡張を追加する
+ 警告レベルを低いレベルから導入 タイプヒントを積極的に書いていく PHPStan の拡張を追加する
</p>
</blockquote>
<p>
- 昨今、動的型付き言語での型宣言・型アノテーション・型ヒントの導入が相次いでいる。長らく静的型付き言語を書いてきた私からすると、ようやく気づいたかといったところだが、ともかく型を導入する言語が増えてきた。 今のプロジェクトでも新しく追加するコードには型をつけるよう努めているが、どうしても古いコードには型がついていない。個人的には型のないコードに対してどう型を自動的に付けるかという点に興味があり、その点で Ruby の typeprof には注目している。
+ 昨今、動的型付き言語での型宣言・型アノテーション・型ヒントの導入が相次いでいる。長らく静的型付き言語を書いてきた私からすると、ようやく気づいたかといったところだが、ともかく型を導入する言語が増えてきた。 今のプロジェクトでも新しく追加するコードには型をつけるよう努めているが、どうしても古いコードには型がついていない。個人的には型のないコードに対してどう型を自動的に付けるかという点に興味があり、その点で 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
+ Documentation as Code
</p>
<p>
- この発表も以前から非常に楽しみにしていた。
+ この発表も以前から非常に楽しみにしていた。
</p>
<blockquote>
<p>
- 開発開始までのオーバーヘッド 新規にチームにジョイン 担当範囲外の機能を理解 オンボーディングのコスト
+ 開発開始までのオーバーヘッド 新規にチームにジョイン 担当範囲外の機能を理解 オンボーディングのコスト
</p>
<p>
- PHPerKaigi 2020 で発表あり
+ PHPerKaigi 2020 で発表あり
</p>
<p>
- 継続的にシステムの理解を助けるドキュメント
+ 継続的にシステムの理解を助けるドキュメント
</p>
<p>
- 継続的ドキュメンテーション システムとドキュメントの乖離
+ 継続的ドキュメンテーション システムとドキュメントの乖離
</p>
<p>
- 書いてあることが間違っている・足りない * 徐々にずれていく * システムの更新タイミングとドキュメントの更新タイミングに差がある
+ 書いてあることが間違っている・足りない * 徐々にずれていく * システムの更新タイミングとドキュメントの更新タイミングに差がある
</p>
<p>
- システムとドキュメントは対応関係がある * 間違ったドキュメント * 存在しないドキュメント
+ システムとドキュメントは対応関係がある * 間違ったドキュメント * 存在しないドキュメント
</p>
<p>
- システムとドキュメントの乖離を定量化する 継続的に システムの更新に近いタイミングで ドキュメントを更新し続ける
+ システムとドキュメントの乖離を定量化する 継続的に システムの更新に近いタイミングで ドキュメントを更新し続ける
</p>
<p>
- Documentation as Code
+ Documentation as Code
</p>
<p>
- コードと同じツールでドキュメントを書く * issue tracker * vcs * plain text markup * automation
+ コードと同じツールでドキュメントを書く * issue tracker * vcs * plain text markup * automation
</p>
<p>
- 開発者 システム ドキュメント 構造化データ ソフトウェア
+ 開発者 システム ドキュメント 構造化データ ソフトウェア
</p>
<p>
- システムから構造化データを抽出する PHPDoc OpenAPI
+ システムから構造化データを抽出する 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 管理
+ cookie による session 管理
</p>
<p>
- 全体的に基本的な話だったので特に触れない。Cookie やセッションの話としては非常に分かりやすくまとめられていたので、知らない人が学ぶにはいい教材だろう。
+ 全体的に基本的な話だったので特に触れない。Cookie やセッションの話としては非常に分かりやすくまとめられていたので、知らない人が学ぶにはいい教材だろう。
</p>
</section>
<section id="section--_1450_a">
<h4><a href="#section--_1450_a">14:50 [A]</a></h4>
<p>
- PHP のエラーと例外
+ PHP のエラーと例外
</p>
<blockquote>
<p>
- エラー PHPエンジンがエラーを通知する 例外 プログラムが投げる
+ エラー PHPエンジンがエラーを通知する 例外 プログラムが投げる
</p>
<p>
- PHP7-8とエラー
+ PHP7-8とエラー
</p>
<p>
- PHPエンジンのエラーの一部が に変換されるようになった → try-catch で捕捉できる
+ PHPエンジンのエラーの一部が に変換されるようになった → try-catch で捕捉できる
</p>
<p>
- は例外とは異なる
+ は例外とは異なる
</p>
<p>
- PHP8 でエラーレベルの引き上げ
+ PHP8 でエラーレベルの引き上げ
</p>
<ul>
@@ -754,19 +754,19 @@
</ul>
<p>
- 例外 * 捕捉して事後処理 * 捕捉せず(or 捕捉した上で)さらに上に是非を問う
+ 例外 * 捕捉して事後処理 * 捕捉せず(or 捕捉した上で)さらに上に是非を問う
</p>
<p>
- 開発段階で例外を把握し、ハンドリングを考えておく
+ 開発段階で例外を把握し、ハンドリングを考えておく
</p>
<p>
- と
+ と
</p>
<p>
- はキャッチすべきでない
+ はキャッチすべきでない
</p>
<ul>
@@ -805,152 +805,152 @@
</ul>
<p>
- 捕捉して対応するのではなく、未然に防ぐ
+ 捕捉して対応するのではなく、未然に防ぐ
</p>
<p>
- 独自例外を使う を投げてしまうと、 catch ()せざるを得ない →catch 範囲が広すぎる
+ 独自例外を使う を投げてしまうと、 catch ()せざるを得ない →catch 範囲が広すぎる
</p>
<p>
- SPL の例外を使う
+ SPL の例外を使う
</p>
<p>
- 例外翻訳 上位のレイヤが下位のレイヤの例外を捕捉し、上位レイヤのAPIに「翻訳」する 下位レイヤの知識に依存させない
+ 例外翻訳 上位のレイヤが下位のレイヤの例外を捕捉し、上位レイヤのAPIに「翻訳」する 下位レイヤの知識に依存させない
</p>
<p>
- @throws 捕捉してほしい例外を書き連ねておく
+ @throws 捕捉してほしい例外を書き連ねておく
</p>
<p>
- 呼び出しもとに負わせたい責任
+ 呼び出しもとに負わせたい責任
</p>
</blockquote>
<p>
- PHP を学んでいる途中の私としては、今まさに聞きたい発表だった (現時点で PHP を書き始めてから 4ヶ月ほどになる)。
+ PHP を学んでいる途中の私としては、今まさに聞きたい発表だった (現時点で PHP を書き始めてから 4ヶ月ほどになる)。
</p>
<p>
- 個人的に例外やエラーを最もうまく扱っているのは Go、Swift、Rust、Haskell などのエラーを「値として」扱う言語だと思っている。try-catch は通常の処理フローを完全に壊してしまう上、構文としても重すぎる。値としてのエラー通知は C言語時代への回帰ともいえるが、その頃と異なるのはエラーを暗黙のうちに握り潰すことがないということだ。これらの言語は型を持っており、静的に検証ができる (C のそれはまともな型付けではない。念のため)。
+ 個人的に例外やエラーを最もうまく扱っているのは Go、Swift、Rust、Haskell などのエラーを「値として」扱う言語だと思っている。try-catch は通常の処理フローを完全に壊してしまう上、構文としても重すぎる。値としてのエラー通知は C言語時代への回帰ともいえるが、その頃と異なるのはエラーを暗黙のうちに握り潰すことがないということだ。これらの言語は型を持っており、静的に検証ができる (C のそれはまともな型付けではない。念のため)。
</p>
<p>
- PHP のように、すでに例外が言語システムに根ざしている言語ではどうすればよいか。この場合も同じく静的検証の力を借りることになるだろう。
+ PHP のように、すでに例外が言語システムに根ざしている言語ではどうすればよいか。この場合も同じく静的検証の力を借りることになるだろう。
</p>
</section>
<section id="section--_1530_a">
<h4><a href="#section--_1530_a">15:30 [A]</a></h4>
<p>
- Laravel のメール認証
+ Laravel のメール認証
</p>
<p>
- Laravel の知識がない私にはまったくついていけなかった。また、個人的にタイトルがややミスリーディングに感じた。
+ Laravel の知識がない私にはまったくついていけなかった。また、個人的にタイトルがややミスリーディングに感じた。
</p>
</section>
<section id="section--_1610_a">
<h4><a href="#section--_1610_a">16:10 [A]</a></h4>
<p>
- gRPC
+ gRPC
</p>
<blockquote>
<p>
- Unary RPCs Server streaming RPCs Client streaming RPCs Bidirectional streaming RPCs
+ Unary RPCs Server streaming RPCs Client streaming RPCs Bidirectional streaming RPCs
</p>
<p>
- Protobuf
+ Protobuf
</p>
<p>
- 実装とAPIが乖離しにくい 自動生成 複数言語でも相互に使える
+ 実装とAPIが乖離しにくい 自動生成 複数言語でも相互に使える
</p>
<p>
- マイクロサービスのサービス通信 スマホアプリ ゲームサーバ
+ マイクロサービスのサービス通信 スマホアプリ ゲームサーバ
</p>
<p>
- PHP では？
+ PHP では？
</p>
<p>
- PHP ではストリーミングが難しい リクエストごとにプロセスが使い捨て
+ PHP ではストリーミングが難しい リクエストごとにプロセスが使い捨て
</p>
<p>
- PHP ではgRPCのクライアントしか対応していない
+ PHP ではgRPCのクライアントしか対応していない
</p>
<p>
- gRPC-Web ブラウザで扱うためのJSライブラリ+プロトコル
+ gRPC-Web ブラウザで扱うためのJSライブラリ+プロトコル
</p>
<p>
- HTTP/1.1 でも使える Unary RPC と Server streaming RPC のみ
+ HTTP/1.1 でも使える Unary RPC と Server streaming RPC のみ
</p>
<p>
- Envoy Nginx などで相互に gRPC と gRPC-Web で変換
+ Envoy Nginx などで相互に gRPC と gRPC-Web で変換
</p>
<p>
- Amp イベント駆動な並行処理のフレームワーク
+ Amp イベント駆動な並行処理のフレームワーク
</p>
<p>
- HTTP/2 対応
+ HTTP/2 対応
</p>
<p>
- C#のgRPC-Webが楽
+ C#のgRPC-Webが楽
</p>
</blockquote>
<p>
- (発表の中でもまさに同じことをおっしゃっていたが) PHP 以外の方が向いているだろう、というのが第一の感想である。gRPC はそれ自体というよりも Protobuf というエコシステムに乗れることのメリットが大きいと感じる。そのエコシステムにうまく乗れない時点で、うーんという感じ。
+ (発表の中でもまさに同じことをおっしゃっていたが) 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
+ Independent Core Layer Pattern
</p>
<p>
- 開発初期のアーキテクチャが崩れる アーキテクチャ観点のコードレビューができない
+ 開発初期のアーキテクチャが崩れる アーキテクチャ観点のコードレビューができない
</p>
<p>
- どこにクラスを置けばよいか？ ドキュメントがない
+ どこにクラスを置けばよいか？ ドキュメントがない
</p>
<p>
- アーキテクチャ設計に関する知識が属人化・暗黙知化
+ アーキテクチャ設計に関する知識が属人化・暗黙知化
</p>
<p>
- ガイドライン * 最初にルールを決めるのは簡単 * ルール通り作り始めるのも簡単 * →維持するのが難しい、人が決めたものゆえ壊れやすい
+ ガイドライン * 最初にルールを決めるのは簡単 * ルール通り作り始めるのも簡単 * →維持するのが難しい、人が決めたものゆえ壊れやすい
</p>
<p>
- PHP の特性 * クラスは public * 可視性の制御が public / protected / private のみ * 依存関係の制御が困難
+ PHP の特性 * クラスは public * 可視性の制御が public / protected / private のみ * 依存関係の制御が困難
</p>
<p>
- アーキテクチャテスト クラスの依存関係や実装ルールをコードとして表現し、自動テスト化する
+ アーキテクチャテスト クラスの依存関係や実装ルールをコードとして表現し、自動テスト化する
</p>
<ul>
@@ -964,15 +964,15 @@
</ul>
<p>
- Independent Core Layer Pattern
+ Independent Core Layer Pattern
</p>
<p>
- アーキテクチャテストの失敗 * 実装誤り * or アーキテクチャが適切でない * 開発の過程でフィードバックしていく
+ アーキテクチャテストの失敗 * 実装誤り * or アーキテクチャが適切でない * 開発の過程でフィードバックしていく
</p>
<p>
- モジュラーモノリス→マイクロサービスへ
+ モジュラーモノリス→マイクロサービスへ
</p>
</blockquote>
</section>
@@ -981,30 +981,30 @@
<section id="section--_day_2_20210328">
<h3><a href="#section--_day_2_20210328">Day 2 (2021/03/28)</a></h3>
<p>
- 冒頭に書いた通り、2日目から体調が悪くまともに聴けていない。途中までは頭痛を我慢しつつ見ていたのだが、まともに入ってこなかった。
+ 冒頭に書いた通り、2日目から体調が悪くまともに聴けていない。途中までは頭痛を我慢しつつ見ていたのだが、まともに入ってこなかった。
</p>
<p>
- 残念ではあるが、いずれにせよ見られていない発表は他にもあるので、今週末にでもまとめて見ようと思う。
+ 残念ではあるが、いずれにせよ見られていない発表は他にもあるので、今週末にでもまとめて見ようと思う。
</p>
</section>
<section id="section--_全体の感想">
<h3><a href="#section--_全体の感想">全体の感想</a></h3>
<p>
- Day 2 にほとんど参加できなかったのは残念だが、イベント自体は大変楽しく、また興味深いものであった。自分がまったく知らない領域の話を聞けるのはこうしたイベントならではだと感じる。オンライン開催ゆえ現地に行く必要がなく、気軽に参加できたのも (特に初参加者として) 嬉しいポイントだった。
+ Day 2 にほとんど参加できなかったのは残念だが、イベント自体は大変楽しく、また興味深いものであった。自分がまったく知らない領域の話を聞けるのはこうしたイベントならではだと感じる。オンライン開催ゆえ現地に行く必要がなく、気軽に参加できたのも (特に初参加者として) 嬉しいポイントだった。
</p>
<p>
- 今回、雑談/登壇者への質問等向けに Discord サーバもあったのだが、こちらは参加こそしたものの ROM のままになってしまった。発表に1ウィンドウ、メモを書くのに1ウィンドウ、Discord 表示に 1ウィンドウで私にはもう脳のリソースとディスプレイのスペースが追いつかなかった (さらにいうと Zoom でアンカンファレンスもやっていたようだ。こちらはまったく参加していない)。
+ 今回、雑談/登壇者への質問等向けに Discord サーバもあったのだが、こちらは参加こそしたものの ROM のままになってしまった。発表に1ウィンドウ、メモを書くのに1ウィンドウ、Discord 表示に 1ウィンドウで私にはもう脳のリソースとディスプレイのスペースが追いつかなかった (さらにいうと Zoom でアンカンファレンスもやっていたようだ。こちらはまったく参加していない)。
</p>
<p>
- 1つ個人的な反省点としては、一つ一つのセッションを真剣に聞き過ぎたというものがある。もっと適当に聞いておけばよかった。これだけだと大変語弊があるのだが、言い方を変えると、Discord しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、後から見返せる発表やスライドに注力してしまった、ということだ。発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。 まあ初カンファレンスだし、とお茶を濁しておこう。
+ 1つ個人的な反省点としては、一つ一つのセッションを真剣に聞き過ぎたというものがある。もっと適当に聞いておけばよかった。これだけだと大変語弊があるのだが、言い方を変えると、Discord しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、後から見返せる発表やスライドに注力してしまった、ということだ。発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。 まあ初カンファレンスだし、とお茶を濁しておこう。
</p>
<p>
- さて、カンファレンスで一つ気になったことがある。それは、Discord という書き込み場所が増えたことでニコ生のコメントの流量が吸い取られてしまったのではないか、という点だ。ニコニコだけ見ていると過疎っているかのように見えた発表も、Discord の方では盛り上がっている、というのを何度か見かけた。ニコニコのコメント方式は盛り上がりを如実に反映するが、逆もまたしかり。Discord があったこと自体はプラスだったと思うが、この点はマイナスだったのではないかと感じる。
+ さて、カンファレンスで一つ気になったことがある。それは、Discord という書き込み場所が増えたことでニコ生のコメントの流量が吸い取られてしまったのではないか、という点だ。ニコニコだけ見ていると過疎っているかのように見えた発表も、Discord の方では盛り上がっている、というのを何度か見かけた。ニコニコのコメント方式は盛り上がりを如実に反映するが、逆もまたしかり。Discord があったこと自体はプラスだったと思うが、この点はマイナスだったのではないかと感じる。
</p>
<p>
@@ -1013,11 +1013,11 @@
</p>
<p>
- 最後になりましたが、毎年の PHPerKaigi 開催にご尽力されている皆様、スピーカーの皆様、楽しい3日間でした。ありがとうございました！ (ずっと常体で書いてしまったのでいきなり仏頂面から笑顔になったようで気持ち悪い)
+ 最後になりましたが、毎年の PHPerKaigi 開催にご尽力されている皆様、スピーカーの皆様、楽しい3日間でした。ありがとうございました！ (ずっと常体で書いてしまったのでいきなり仏頂面から笑顔になったようで気持ち悪い)
</p>
<p>
- ではまた来年。
+ ではまた来年。
</p>
</section>
</section>
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-12-01 00:00:39 +0000