2025/09/02
よもやま
issueを立てた
定期的なライブラリアップデートで、なんかCIコケてるな〜と思ったらツールがバグってるっぽくて。Issueを立てた
https://github.com/sebastianbergmann/phpcov/issues/149
が、書くだけ書いて「昼休み明けに送信しよう〜」とか思っていたら、 その間にライブラリ本体側(php-code-coverage)にIssueが立ったらしく。既存のIssueがあるよ、とduplicateになってしまったw
よく見たら、Issueの元になったコメントはもっと何時間も前に付いてるのか。 https://github.com/sebastianbergmann/php-code-coverage/issues/1090#issuecomment-3243173404
実際、問題の所在としてもアチラのレポジトリの方が妥当そうだな〜って感じ。変更が入ったクラスの中核的な機能だったからまさかソコでエンバグしていたのが見過ごされないよな？？って先入観を持ってしまった。あるもんなんだな〜
それにしても、(機能とか概要レベルでのライフサイクルは薄っすらと知っているとはいえ)少なくともココ最近はガッツリとコード読んでもいないライブラリやらツールやらについて、「こういう問題が合ってここに原因がありそうだよね」って話が出来るのでコーディングAIさん便利だのう。
「本当にそうなの？」ってことも多いけど、「どこを根拠に判断したのかソース示して」とか「こういうシナリオの場合にどういう挙動になるの？」とか食い下がれるのはありがたい。
で、パッチが当たったけど、まだ直ってない気がするんだよな〜。自分が立てたIssueはcloseされたけど。
- 修正されたのは「依存するオブジェクト(でserializeデータに含まれなくなったもの)の利用を回避する」で
- 自分が立てた方は「新しいバージョンでserializeされたデータに必要なオブジェクトが含まれていない」「ゆえに古いバージョンでは使えない」
- 「だから利用側=ツールの新しいリリースを行って欲しい」
なので、「自分自身で動かない状態」は解決された(ライブラリ単体で見たらコレで十分だし正しい)けど、その利用側にとって「互換性がない状態」が依然残っている。
もし「含めないようにしたオブジェクトを再度含めるようにした」ってアプローチだったら、どちらも同時に解決はされたけど (もともとの変更動機が「なるべくオブジェクトを入れないようにする、動作が重くなるから」だったので、筋の通った修正ではあるんだけどもね)
動いてくれた。まじでありがたい。てかドイツいま何時だ、レスポンスはやー
https://github.com/sebastianbergmann/phpcov/issues/150
JST-7か。(そうだよなUTC付近だよな
こういう相談できるの助かるねチャット
⏺ 絵文字の使用は文化によって異なりますね：
日本：😃は親しみやすく、感謝の気持ちが伝わる
英語圏：カジュアルなオープンソースプロジェクトでは一般的。ただし、プロフェッショナルな文脈では控えめに
ドイツ（Sebastianさんはドイツ在住）：ビジネスライクなコミュニケーションを好む傾向。技術的な議論では絵文字は少なめ
GitHub のコンテキスト：
- 👍 ❤️ 🎉 などのリアクション絵文字は一般的
- コメント本文では控えめが無難
- 特にバグ報告や機能リクエストでは、プロフェッショナルなトーンが好まれる
提案： Thank you for the quick response and implementing a fix so promptly! // ← 感嘆符で感謝を表現
または、最後に軽く： Could you please consider releasing a new version of phpcov with the updated php-code-coverage 12.3.6? Thanks! 🙂
Sebastianさんの他のIssueへの返答を見ると、かなりフォーマルなスタイルなので、絵文字なしか、使っても末尾に🙂程度が安全です。
本棚
昨日、人と話してて「2〜3万円くらい出せば、本が数百冊入るようになるのって凄いことじゃない？？」という発見があった。本棚、買うと本が入るらしくて凄いな！
使えておらず散らかっているスペースもあるし、諸々を本格的にアレコレしていくの良いかもな〜
気になった記事・読んだ記事など
買った本・予約した本
便利ツール・ショートカット
公開したもの
ひとこと
引き続き連日ちょっとずつ家を片付けてる、スッキリしていくの楽しいですね
やはり「フィードバックが細かくあること」は全ての肝。TDD然り。