PHPカンファレンス北海道2024に参加しました #phpcondo

イベント

2024/01/12 - 01/13に開催された、PHPカンファレンス北海道2024(前夜祭＋本編)に参加しました。

phpcon.hokkaido.jp

今回はLT枠で出したプロポーザルを採択していただき、参加＆発表＆懇親交流＆北海道グルメ・・・の4泊5日の旅程を大変に満喫し、「はぁ〜〜カンファレンスまた行く〜〜」「はぁ〜〜札幌また行く〜〜」という気持ちになりました。

登壇した話についてはコッチに
PHPカンファレンス北海道2024に登壇しました #phpcondo - 大好き！にちようび

今回は、カンファレンスに参加して楽しかったな〜というのと暴力的に食事が美味しかったなぁぁあ〜〜〜〜〜〜という話に触れます

以下、食事の写真を脈絡もなく挟み込むスタイルです。

続きを読む

PHPカンファレンス北海道2024に登壇しました #phpcondo

やったこと・書いたもの

2024/01/12 - 01/13に開催された、PHPカンファレンス北海道2024(前夜祭＋本編)に参加しました。

phpcon.hokkaido.jp

今回はLT枠で出したプロポーザルを採択していただき、参加＆発表＆懇親交流＆北海道グルメ・・・の4泊5日の旅程を大変に満喫し、「はぁ〜〜カンファレンスまた行く〜〜」「はぁ〜〜札幌また行く〜〜」という気持ちになりました。

この記事を書きながら色々と思い出して、また楽しい気持ち＆幸せな気持ちになってきたな・・・

発表したもの

fortee.jp

考えていたこと

マネジメント(ロール)とかEMみたいな話をド直球でテーマにして、外で発表したのが初めてになります。*1

自分の状況を鑑みて、マネジメントやEMとかいっトピックで新鮮味をもって喋れるのは、1月か粘ってもギリギリ2月の関西か・・・と思っていた背景がありました。
そのため、このプロポーザルが採択されたのは、とても有り難かったです。良い機会をいただけたな〜と感じます。

個人的に、今までに「この人からマネジメントを教わった！」とか「マネージャーになってから、”やり方”を教えてもらった」とか「こういうマネージャーを目指したいな」とかとか・・・といった体験を持っておらず、どちらかというと自己流だし、試行錯誤をしながら何となく掴んでいったなーという感覚があります。 *2

その裏返しで、自分が経験したもの・目にしたものは「外に出せる事がありそうだな」とも感じる節があり。偉そうに教えを説いたり心理を掴んだぞ・・みたいな事では勿論なく、単純に「経験をdumpできそうだな」「いま、その時の自分が目の前に居たら、経験を少し積んだ自分からは何を伝える？」という部分です。

あと、PHPカンファレンス福岡でZOEさん(@for__3さん)が発表していたのが、自分から見て良すぎた＆カッコよかったんですよね〜。
「俺も！ああいうの欲しい！！」って思っちゃって、やりたくなっちゃった面もありました。出来上がったものはぜんぜん違うけど。

良いプロダクト作りのための組織育成 健全なコードは、 健全な組織・健全なチームから - Speaker Deck
*3

そうした背景があり、提出したプロポーザルになります。

発表内容について

テーマ的に50分でも1日講義でも行けるものではありそうですが、LTを選んだのは、「結局は正解なんてないし、本人や組織・環境の状況によって全く知るべき事が違いすぎるよな」という性質を気にしての結果です。 1人ずつ話を聞かないとわからないよ！！って感じで。

完成度の高い「万人向けでエッセンシャルなおすすめリスト＆プレゼンテーション」ができない、そうであれば、中身や課題設定に中途半端に突っ込むよりはLTでやるか・・・！と。

当初は「幅広くやる仕事である」ことを反映して雑多なトピックを織り交ぜようとも考えていたのですが、やはり25冊は多いようで全然少ない・・・・
発表内容を考えている内にそう実感してきたこともあり、「今まで知らなかったこと」と「自分が知って役に立ったという実感が強いこと」に焦点を絞りました。これは発表中にも述べた通りです。
(実際にEMやってみると、「教えるために読む本」「色々なレベルに合わせるためのレパートリー」みたいな本も知っておかないとなぁと言う感じで、プログラミングとか設計とかテストとかの本がゴソッと削られているのは、自分的には違和感も有るわけですが。。)

積読も含めて「候補になりうるかな」と考えたリストが、最終選の6倍以上あったのですが、そのままお蔵入りさせるのも悔しいし折角なので晒しておきます😏
12月に可処分時間が莫大にあった際に、全書籍にメモ入れて公開したいな・・・と思っていたのですが。全く叶わず。

oo00hh.notion.site

「おまけ」について

また、発表時間的にギュウギュウだなぁ・・・と何度も素振りしながら感じていたんですね。
その中で、前夜祭の@ogi_chotdake_seさんの発表を聴いたら内容が素敵でして、どうしても入れたくなったのが「おまけ」のパートです。人から刺激をもらったり助けられたりって凄い大きいし、尊いことだよなぁ・・・と改めて心を動かされたので。

時に「マネジメント」って孤独な仕事とも思われがちなんですけど、全然そんなこともなくて、社内でも社外でもいいから仲間を集めて「チーム」としてコトに当たっていけたら、安心できるし強くもなると思うのですよね。

仲間の数だけ強くなれる、自分が強くなった分だけチームを幸せにできる！！！っていうのが、マネジメント職、本当にあると感じます。
自分も、元同僚でマネジメントをやっている・経験がある人(=EM業の先輩)に突然DMを送って「おすすめの本教えて！」「どうやっていたか教えて！」なんて聞いたりして、とても救われていました。
そういう経験ができる人は、増えてほしいです。
(折角なので、もしここ読んでくれている人で、自分でも良かったらﾄﾞｼﾀﾝ?ﾊﾅｼｷｺｶするので、お気軽にご連絡ください〜〜😃)

で。
何度も素振りをして「勢いさえつければ5分でどうにかなるか・・・」と整えてあったスライド、コレを入れるために前夜祭〜当日に何枚も削られていった訳ですがw
時間にも収まったし良かったです。

イベント本番中に起きていることに呼応して変化・進化が起きるのは、生で同じ時間を過ごしている醍醐味ですよね！！

反響について

構成？みたいなところ

「5分間ずっと高速にスライドをめくり続ける」みたいな発表をあまりやったことがない(少なくとも外ではやってないはず)ので、いつものカンファレンスに比べて発表準備や発表後の疲労に独特なものが・・・

苦しくも感じつつ、プロポーザル提出時にこうした反響(↓)を頂いていたこともあり、最初に出したタイムライン(の書籍紹介に入るところまで)を意地でやり通したろう！！という気持ちで臨みました。

実際の発表時には、現地の勢いで喋っているため秒刻みのタイムマネジメントは行われていませんが*4、プロポーザル記述内容と当日の発表資料と見比べてみてください!!!
(あと、各スライドの左下に想定経過時間を書き込んであります)

Youtube上のアーカイブから

そういう他人には全く関係ないコンテキストでのチャレンジがあったのですが、SNSや懇親会でも温かい反応をいただけてホッとしました。
ホッとしたっていうのは控えめな表現で、「やりきったなーよかったなー！」と感じます。懇親会で出たご飯の美味いこと！！ *5

中には「LT慣れを感じました」というような言葉ももらったりしたのですが、今回のは全然そんな感じでもなく・・・終わってお声がけいただいてやっと胸をなでおろした、っていう方が近いですw
(ゆっくり聴いてくれている人の雰囲気を感じながら喋りたい・・)

でも、やったことがないスタイルに挑戦できてのは面白かったです。いい機会をいただけました。

メッセージの部分

「マネージャーこそ1番必死で学んでくれ」というのは、時間の関係で削るかな・・・と最後まで悩んだ部分だったのですが、チラホラと反応を頂いており、残してよかったなと思います。*6

在籍していた会社で「新しくEMになる人に」というテーマで話した際には、「同じ職種(Webエンジニア)からの信頼を勝ち取ることが何よりも大事、自分と一緒に働けることがが胸を張れる出来事と感じられるか？を自問する」みたいな事を話したりしました。
また、Tech Leadに就任した時から「この組織の中では自分が1番成長し続ける」と決め、公言していたので、それを引き続きやっていた背景もあります。
・・・それ故に、「当たり前になりすぎている」ことだったので、5分の中でわざわざ言わなくてもいいかなぁ削るか？？とも考えたのでした。

最終的には、「なぜ25冊もの本を(最初から)読まないといけないのか」に対する回答として使い勝手が良さそうだったので、残す判断に。

現地にいた人(オンライ視聴者も含まれてるかな？)にも、記録に残る形で反応をいただきました。

リアクション: 現場から

所属していた学部の関係で20歳前後の時代は「メディアは身体の拡張である」と言われ続けて育っていますが、生身の経験が追いつかない部分を先取りするのが「読書等のインプット」なのかなぁ〜という感覚はあり。経験値の先取りが、地理・時間を超えて出来るのですから、「本を読める」とか「講義を聴講できる」っていうのは恐ろしい武器になるよなぁ〜とは思うところです。
特に、EMになってからその感覚は強くなりました。

そーだいさん、懇親会で「自分が読んだことがない本が少なかった！」とクレームを頂いたのですが、「発表タイトル見てくださいよ何を言っているんですか！！」などと会話をして笑っておりました (”新しくEMやってみる人”なのになぁ・・w)
あと、「失敗の本質よりも、失敗の科学をおすすめしたい」とのコメントも頂いています。

失敗の科学

失敗の科学

Amazon

俺のおすすめ本！！みたいなのを聞いてみたいなぁーって思いながら資料を作ったりもしていたので、ありがたかったです。 (積んであるので読まないとなぁ)

推し本たち

紹介した書籍の中で、いくつかの共感的なリアクションをいただいています。
わかる〜〜〜〜良い本ばっかだもんね〜〜そうなんだよな〜〜〜〜〜という気持ちになりました。

リアクション: SNS等

SNS上での反響については、特に「自分がいままで一方的に活動やアウトプットを見たりお世話になっていた人」「本読みました！！」「Podcast聴いてます！！」な人からのリアクションが付いたのは、恐れ多いし嬉しくて舞い上がっちゃいますねぇ〜〜

(多分、@asumikamさん → @ryuzeeさんをきっかけに跳ねた感じが)

言及していただいただけでも凄い嬉しいのですが、「それなof the year」をもらいました。今年入って10日くらいの時点での出来事。
25冊の中にも、その前の候補リストにも、チーム・アトラクタな人たちの本がめっっちゃ入ってます。

furoshiki.fm、いつも面白く聴いてます！！の人だ・・

自分より遥かに先の位置にいる人に「納得感ある」と言われるのは、ガッツポーズものでした

「スクラムの拡張による組織づくり」も入れるか？？と思ったりしつつ、「はじめてEM」だと25には入らないかもなぁ・・・という感じになりましたが、読んだ方が良い本だよなぁと思っています

ブログ「勘と経験と読経 」、ここの記事をきっかけに何冊の本を買うことになったか分からないくらい大きく影響を受けているのですが、その中の方の目に留まって「感覚的に合っているし、良書ばかり」なんて嬉しすぎます。ありがとうございます。

本を知る切っ掛けになった素晴らしい発表、引用紹介させていただいたらオリジナルの発表者にリーチするとは！

"これから学ぶ" システム思考 / System thinking introduction - Speaker Deck

一方的に知っているだけの人に届くので、いんたーねっとってすごい

Podcastの人だ！！(違う)

いったん お終い

という感じで、いい経験になりました。機会をいただけてありがたかったです。

長くなったので「登壇以外の」については記事を分けます！

*1:会社のブログで触れたり、読んでもらったPodcastで喋ったりはしましたが！

*2:もちろん、すごく助けになったり仕事をしやすくしてくれた直上はチラホラいます！！どちらかというと、マネジメント志向がなかったが故に、あんまり意識的にマネージャーたちの振る舞いを見ていなかったのかな〜って気がする。気付いていないことが多くありそう

*3:えっ！デブサミでもアップデートが聴ける？！ https://event.shoeisha.jp/devsumi/20240215/session/4859

*4:用意していたスクリプトをバサッと削ってアドリブしまくっているのでねぇ

*5:もちろんココで言っているのは心理的な意味合いですが、実際に出てきたオードブルのクオリティも高かったw

*6:それこそ、「ほう〜こういう見方もあるのか〜」というのは自分になかった視点なので、面白かったなと感じます。 https://twitter.com/for__3/status/1746086437752340788

「PHPのファイルに差分があるかを(astを使って)調べる君」を晒した

やったこと・書いたもの PHP OSS

という訳で、どーん

packagist.org

前に記事を書いたやつです。
daisuki.nichiyoubi.land

を書いた後に、先月のPHP勉強会@東京でもお喋りさせてもらったやつでもあります。

(コマンドしか提供しないので、ワークフローファイルを自分で用意する必要がありますが)PRのコメントで起動する使い方が便利じゃない・・・？って思っています。

こんな感じで動くよ

動作例はココにあります。Actionsの設定例もココに。

ブログや勉強会で話をできたことで、「読みやすい簡単なコードにして、面白がってもらおう〜！」という欲は消化されまして、複雑なコードにしました。
クラスが分割されています。(テスト書きにくい部分とかコーディングが面倒くさくなっている部分から逃避していったら、何となく行き着いた〜って感じ)

原型となったプロトタイプ的なスクリプトも同一のレポジトリ上に同梱されております。

どこにそんな時間があるのでしょうか・・・・・・・という感じではあるのだけど、何となくイメージをしていた所までは書いて。
で、ズルズルと時間を費やしていってもなぁ！！と思ったので見切りです。
とりあえず、PHP勉強会のLTで「今後やりたい」と触れていた内容はコレでクリア！ 本当はLTに間に合うようにコード晒しておきたかったけど、時間切れしちゃっていましたね

Hobby empowered by AI

gistで済むようなスニペットレベルではなくて「コード晒してみるか〜」となったのは、流行りのAIさんの力が大きいですね！面倒くさいことはhogehogeにやってもらおう。
Jetbrains AIが来たので、利用しています。

やってもらったことは・・・

  • メソッドやクラスのphpdocを書いてもらう
    • 少しだけ直した部分や、phpstanと仲良くするために書き換えた部分はあります
    • が、とりあえず「めっちゃズレてる内容になっていなければよし！！」って感じで、ドキュメンテーション率が高くなっていると思います
      • 価値のある情報付与になっているか・・？は、自分でやっていても微妙なところは多いかも。コンテキストに応じて「そうそう、その情報が欲しかった！！というクオリティのコメントになっていないと言うか
  • commit messageを書いてもらう
    • こちらは、ほとんど弄らないそのままコミットしたモノが多い(殆ど自分でチェックしていない)
      • コミットする差分をピックアップして、あとはボタンをぽちーって押しいった感じ
    • 意味のある内容になっているか、は・・・・*1
  • READMEもChatGPTに書いてもらったやつ
    • ツールの説明を箇条書きの日本語で投げて、たたきを作ってもらって、少し構成とかをいじったり〜って感じに

逆に言えば、「AI使ったドキュメンテーションってどのくらい使い物になりそうなの？」というのに興味がある人は、このレポジトリを覗いてもらうことで雰囲気がつかめるかもしれません。

個人的な感じとしては、「(英語で書く関係もあって)ドキュメントを書く部分は9割以上はやってもらった！！」という一方で、「他人と開発するもの(OSSへのコミットとか、業務でのチーム開発とか)には、ノーチェックで使うのは厳しいのかな」というところ。
コレは「人間の手で侘び寂びを加えて・・・」とかって話ではないですけど、やっぱり情報の足し引きが出来ていないと、意味のあるドキュメントって書けないよねーという感じです。単純に自分が使いこなせていない！コンテキストを適切・十分に渡せていない！！が正しいのではないか、と思う。
(逆に言えば、そのための操作方法やコツを調べながらやるのが面倒くさいな・・・ってなっている状況ですね、と。)

他方で、やっていない(やってもらえなかった)こととしては、テストの作成とかですかねー。
これも「もっと適切に情報を引き渡せれば」という面が大きそうですが、自分としては「まだ自分で書いた方が全然早いし使えるな」って感覚です。

ブラッシュアップとか細かい所をついたりとか、「叩きをこちらが書いてフィードバックをAIにもらう」って形ならマッチするかも？
今回、設計面とかテスト面を磨くつもりがそんなに無く、「とりあえず気になっている所を動かしてくれる程度のが備わっていればOK〜」ってノリだった(=あんまり拘っていない)のですが、そっち側で活用の余地がありそうかな？って期待です。
「ここはDIコンテナを使って外部から注入できるようにしましょう」とか言われるんじゃないかな、どうなんだろ。

あと、(同様の理由で)Jetbrains AIにある「Find Problems」「Suggest Refactoring」のメニューも使っていません。こいつら面白そうですよね。どっかで使ってみたい

*1:こういうのとか、コミット内容にあるコード差分で示されていればOK(示されるべき)なものが冗長にコミットメッセージに入っちゃっているね！とか、そういう感じが多い。要約は強いけど抽象化は難しいのかなー

”あれの元ネタを探りに行く"、準備はできている。旅は始まっていない。

この記事は積読 Advent Calendar 2023、2日目の記事です。
昨日はげんえいさんの まだ読んでないけどおすすめしたい本 2023年版 | gennei's blogでした。
随分と面白そうな書籍が紹介されていて・・・というかこの中から実際に”積んで<購入して>"しまったのですが、これが25回続くんですか。恐ろしい…

こちらが、「積読は体に良い」というコンセプトを表現したイラストです。温かく居心地の良い雰囲気の中、多くの本に囲まれてリラックスしている人物が描かれています。

ChatGPTさんに挿絵も書いてもらいました。
本に飲み物を置かないでおくれ。

さて、私からは、「この言葉を浴びたい！！！！」と思って買ったbut積んでいる本たちの紹介です。
思想や知識と出会うのは「旅」のようにも感じます。
そんな可能性を予感する本が「もう自分の家に積んである！」というのは、すなわち、「旅に出る準備」は出来ているという事です。
積んでしまえば安心、いつでも出発できますので。

・・・・これを「安心」と呼ぶのか「慢心」と呼ぶのかは、人次第でしょう。

という訳で、5冊ピックアップしてみました。
順不同で紹介します。

積読の紹介

Project Myopia

Project Myopia

Project Myopia

Amazon

翻訳の発売当初から一気に話題になっていた『Team Toplogies』で、こんな言葉が引用されています。
自分以外にも、強く印象に残っている人が多いのではないでしょうか？

ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ

この出典が、こちらの『Project Myopia』になります。

プロジェクト単位での「コツ」「ノウハウ」は、日本語でもアクセスできるリソースが充実していると感じます。
しかしながら、プロジェクトを超えた先の、「機能する安定したチーム」を実現し、育むには・・？という情報がもっと欲しいな、とも思います。自分も組織周りの仕事をしながら、良い文献がないかなぁと探していました。

そんな時に、チームを解散させる事に対して強い言葉で批判している本がある！！！となれば、気になっちゃいますよね。

サーバントリーダーシップ

サーバントリーダーシップ

サーバントリーダーシップ

Amazon

「サーバントリーダー」、十分に普及していてよく耳にする言葉だと思います。
何となくは分かる。が、しかし「理解がふんわりしていないか？」とも感じます。

ロバート・K・グリーンリーフ博士は、サーバントリーダーシップの提唱者です。
その人の著述が書籍化されている、よし当たってみよう！という次第です。

自分の周りでも、「自分はサーバントリーダーである(を目指している)」と発言している人を目にすることがあります。
しかし、その実、「自身の考えを述べない」「しっかりと周りを導いている感じがしない」といった振る舞いが見られて、これは機能不全的な中立と何が違うのか？とも感じました。
ただの「執事のような親切なお世話係」であれば、それで良いのだと思うのですけど。「リーダーシップ」を持っているとは言えないのでは・・・？という違和感です。

多分、本来はそうじゃないんでしょうね。
この言葉を嫌いになる前に自分の目でちゃんと見ておこう、と考えて積んだ1冊。

Quality is Still Free

Quality Is Still Free: Making Quality Certain in Uncertain Times

Quality Is Still Free: Making Quality Certain in Uncertain Times

Amazon

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉は興味深く刺激に溢れる本なのですが、その中で次のような一節があります。

クロスビーの『品質はタダである』という本を読んだ方々は, ソフトウェア品質についてのわたしの見方がクロスビーの見方とおおむね一致していることに気がつくだろう。

G.M.ワインバーグ・大野 徇郎訳 (1994)『ワインバーグのシステム思考法 ソフトウェア文化を創る』共立出版, p.17

「品質はタダ」という言葉自体もキャッチーですが、ワインバーグ氏の品質に対する考え方の軸みたいなものを深く眺められるのであれば、それは触れておきたい・・・と思ったのです。

加えて、この言葉を聞いた時に、このブログ記事を想起しました。

「品質“実質”無料キャンペーン」を開始しました - pixiv inside

当時も「すごいインパクトのある呼び方だ〜」と思っていたのですが、元ネタがあるのか！！！と。 今、改めて読んでみると、本文でも触れてありました。

実際のテーマにする際には、クロスビーの「Quality is Free」にあやかる面もありました

当然、「質とスピード」のt-wadaさんも言及があり。

品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020 － Publickey

ここまで来たら、もう原典にも興味津々で、買うぞ！！！と意気込んでいたのですが・・・
日本語訳のクオリティ・マネジメント―よい品質をタダで手に入れる法も、原典のQuality Is Free: The Art of Making Quality Certainも手に入りにくそうな雰囲気でした。

なんとか、「Quality is Still Free」は中古で入手できたので、読むぞ！！！と思っているところです。

企業文化

企業文化 改訂版: ダイバーシティと文化の仕組み

企業文化 改訂版: ダイバーシティと文化の仕組み

Amazon

業務上、あるいはアジャイルソフトウェア開発やリーダーシップについての学びを進める中で、組織や企業における「文化」は自分の中で最重要なトピックの1つになりました。
「良い文化を作ろう」「文化を強く浸透させよう」と、こんな調子ですね。

しかしながら、「じゃあ企業における文化とはどんな存在なのか・・・説明できるのか？」と思ったタイミングがありまして。
気になってしまったものは仕方ないので「元ネタと呼んで差し支え無さそうな存在に当たってみよう」です。

エドガー・H・シャイン博士の書籍は、一気に家にやってきては増殖を続けているような印象がありますね・・・・

「組織文化とリーダーシップ」も気になっているのですが、こちらはまだ手に入れておらずにいます。

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

Amazon

これは「読む」という感じなのか・・・？という気もしつつ。
それこそ「UnitOfWork」とか「ActiveRecord」とか、色々な名称・パターンの元ネタといって差し支えないはず。

なぜ読みたいのか？も、なぜ読めていないのか？も、同業の皆さんだと思い浮かぶ話はありそうで、多分それはその通りなのではないかとも思います・・・😇
まぁでも、本当にどこかで目を通しておくべきだとは思っています。がんばろう

まとめ

「元ネタ(原典)に当たってみよう」というのは、割と大事にしている気持ちです。

『チームが機能するとはどういうことか？』を呼んだ時には「心理的安全性って言葉(を口にする人)、何か嫌いだな〜」って思っていたのが覆りましたし、「顧客が本当に必要だったもの」も『オレゴン大学の実験』を読んだりアレグザンダーのパターン・ランゲージについて知って行くことで、より面白く感じられるものになりました。
割と最近になってから読んだ『人月の神話』も、非常に刺さると同時に発見もありましたし、XPなんかも『エクストリームプログラミング』を読んでみると「単なるプラクティス集ではなく、とても豊かな物語が込められているかもな」とすら思えたりもします。

これは、決して「古典」に限った話ではなくて、「みんなが知っている言葉」は「ひとまず本を読んでみておく」というのは大事だなぁと感じます。
例えば最近で言えば「4keys」「チームトポロジー」も(ややバズワード的に？)よく出回っている印象もあり、表面的に切り取って「何となく分かったつもりになって真似をする」なんて勿体ないですよね。
労を惜しんだり高を括って損をするのは悔しいので、謙虚に色々な知識・情報に触れていきたいものです。

つまり、これまでもこれからも本が増え続ける・・・・！
お疲れ様でした。

PHPStanを利用しているPJにおけるbaselineの進化を追う

PHP

会社などでPHPStanを導入したり荒らしたりする事があるのですが、「まずは入れてみた」状態においては、baselineの記述量をなくしていくぞ！！！！という取り組みがあります。
最終的にはbaselineがなくなるのが健全な筈ですので、その解消作業の進捗やトレンドを分かり易くしておきたいのです。

そんな時に、ふと見つけたのが staabm/phpstan-baseline-analysis でした。

コレは、「baselineファイルをソースとして、分析することで、見えてくるものがあるのではないか？」という面白ツールです。
とっても素敵なアイディア！

Software Architecture Metricsを読んだ時に、「GItのデータを用いて、各種活動の発生状況や対象について分析する」といった観点が紹介されていて、なるほど〜と思った*1のですが。
「普段の活動の中で何かしらの動機をもって作成されたり修正されたデータや、あるいは”品質だ！！！管理だ！！！"という意図がなくとも生み落とされる記録」みたいなものであれば、自身の成果物や活動についての状況を示唆するはずだな〜確かに〜〜〜！という。

で、実際にphpstan-baseline-analysisは使えそう・・というか「(ignore)エラー総数だけでも追いたい、俺が欲しい！」と思ったので、セットアップしてみました。

作るものの概要

  • 集計した結果、コレまでのトレンドを示すグラフや最新状況について可視化する
    • 一目でわかるようにする
    • 情報を集約して、1箇所でわかるようにする
  • 自動で更新して、新鮮なデータが溜まるようにする

↑をこなすための制約だったり前提条件

  • 運用上、baselineファイルは単一のものではなく複数に分割されている
    • 複数のbaselineについて個別に & 全体を統合した集計結果の出力に対応させる
  • 分析対象ファイルとは別のレポジトリに置きたい
    • 自動更新を考える上で、J-SOXが〜〜みたいなことを気にしたくない
    • 「対象レポからコードを引っ張ってきて集計にかける」をやる

データは加工していますが、出力イメージはこんな感じになります↓

トップページ = 全体の(ignore)エラー数の推移と

詳細ページ = baselineファイル別のエラー数の推移

作った

集計を実行するレポジトリを github-org/phpstan-baseline-watch 、集計対象のレポジトリを github-org/nanika-no-pj という名前だとします。

github-org/phpstan-baseline-watch には、

  • 集計を実行する処理の実装
  • GitHub Actionsで、↑と絡めつつ、 github-org/nanika-no-pj をcloneしてくる && 集計を実行する
  • GItHub Pagesに可視化結果を出力する

という機能をもたせます。

github-org/nanika-no-pj は、 .phpstan-baselines に(複数の)baselineファイルを持てる構成になっています。

全体像

こんな構成になります。

.
├── .github
├── .gitignore
├── composer.json    # phpstan-baseline-analysisを取り入れる
├── composer.lock
├── nanika-no-pj-src    # 分析対象レポジトリ
├── docs    # gh-pagesの出力対象
├── main.sh    # 集計実行のロジック
├── tmp    # 集計時一時ディレクトリ
└── vendor 
$ cat .gitignore
/vendor/
/nanika-no-pj-src/
/tmp/
!/tmp/.gitkeep

集計実行のアクション

実際に集計をキックしたり、その前段階のデータ集めをする実態は、GitHub Actionsのワークフローに委ねることになります。

処理の流れは

  1. 分析対象のレポジトリを、ignore対象のパスにcloneする
  2. (github-org/phpstan-baseline-watchの方に)Composer Installを実行する
  3. 集計実行のロジックをキックする
  4. 集計結果をcommit&pushする

というものになります。

actions/checkoutは他レポのcloneは可能ですし、fetch-depthを指定することで最新のコミット以外も取得可能です。
今回は「サブディレクトリを掘って、そこにcloneする」という方法を取りましたが、submoduleなんかでも自然だと思います。
ローカルで作業する際に、submoduleではない「自由にいじり放題なディレクトリがあると楽だった〜」くらいのフワッとした理由で、このような形にしています。

集計実行のロジック

workflowファイルに直接書くにはやや煩雑になるので、シェルスクリプトを別出しします。
ざっくりした流れを掻い摘むと、

  1. 相対日時として、今日〜60日前の範囲で1日毎にイテレーションして
    1. 初日(=HEAD)の場合だけ、最新スナップショット保持用に集計結果を出力(コミット対象となる)
  2. スナップショットを取りたい日付(に1番近い)コミットをチェックアウトして
  3. 個別に分かれているbaselineファイルから、ignoreErrorsを取得してマージするPHPスクリプトの実行し、他のbaselineファイルと並列に配置する
  4. baselineが設置されているディレクトリの.phpファイル*2ごとに、集計の実行を行い、一時ディレクトリに結果を出力する
  5. グラフの生成を行い、トップページと詳細ページにmdファイルとして埋め込む

となります。

ちなみに、このスクリプトの要素要素については、殆どChatGPTさんが書いてくれました。ありがてぇ
いくつかポイントを説明していきます

  • ポイント①
    • git checkoutとかcleanを掛けまくるので、ワーキングディレクトリを対象PJのrootに変更しちゃっています
    • その代わり、集計スクリプトの場所などで混乱しにくいように、PJ(github-org/phpstan-baseline-watch)のパスを一時変数に格納して、nanika-no-pj-src 下でゴニョゴニョしている間は各種パスを絶対パスで指定するようにする
  • ポイント②
    • unstagedファイルをnanika-no-pj-srcの下で一時的に作成しているので、イテレーションの冒頭でお掃除しています
  • ポイント③
    • 過去の情報に遡る時 = 「1日」以上前の時だけ、commitを遡ってcheckoutする・・・という分岐なのですが、今思ったらコレ要らないかもですね。
      • git rev-list -n 1 --before="${day_before} days ago" HEAD ってHEADにならない？
  • ポイント④
    • 最終的に出力されるグラフにおいて、「データファイルが読み込まれた順に、グラフの原点から配置される(=左に来る)」という挙動が見受けられたので、若い日時のデータが最初に食われるように命名しています
    • glob() の結果に従った順番通りにファイルを読み込み、iteratorにappendしている感じ
  • ポイント⑤
    • phpstan-baseline-analysisのRADMEを見ると、いい感じにスナップショット作成対象の日時が反映されている・・・？と喜んだのですが、実際に動かしてみると、集計日時には集計実行時点の現在日時が入るっぽい挙動がありました
    • そのため、出力されたファイルから日時のフィールドを直接変更しています。jqが最初から入っているの有り難い

GItHub Pagesの更新

・・・については、ほぼデフォルトのまま(強いて言えばディレクトリを /docs になるように変更したり、スケジュール実行を入れたり)なので、特に言うこともないです。 GitHub上で、PJの settings > pages に行って Build and deployment を GitHub Actions にしてあげれば、雛形を出してくれます。

やった！できたねぇ〜

君も鬼になって、baselineをゴリゴリに削っていこう！

*1:変更頻度が高いファイル(コミットが集中しているファイル)は優先的にテストを書くべき・変更容易性を高めるためのリファクタをすべきだ〜そもそも責務を持ち過ぎかもなので分割するべきだ〜〜とか、そういった類のものですね。

*2:baselineファイルをphpで作成しています