00:01
先週、風邪をひいてしまって、休んでしまって、連続1週間に1回の配信記録が途絶えました。
まあ、それはいいんですけど、今回のトピックは、開発者としての自分のキャリアです。
2024年になって、別のチームに移動して、その後スクランマイズを始めました。
なんとなく、その仕事は楽しいんですけど、開発者の仕事から離れているんですね。
最近、趣味でというか、この1週間、本当に趣味で、GitHub Actions を書いてまして、新しいものを。
ちょうど1週間前に、GitHub Actions を書いたんですけど、
この1週間、本当に趣味で、GitHub Actions を書いてまして、新しいものを。
ちょっと思いついたので。どんなものかというと、GitHubのワークフローの時間ですね。
だいたいこのワークフローのランはどれくらいかかった、次のランはこれくらいかかった、みたいにしてなっていて、
GitHub Actions をCIで使っている場合に、テストの時間が気になると思うんですよね。
さらに言うと、その推移が気になると思うんですよね。
例えば、テストの時間を改善するために、いろいろなリファクタリングをしたりとか、
無駄なテストを削ったりしてCIの時間をやろう、みたいな試みがよくされると思うんですけど、
GitHub Actions だと、どれだけ改善されたかっていうのがいまいちわかんないんですよね。
UIで1ページ1ページ見るのでも構わないんですけど、
結構、かったるいというか、それにチャートになっているわけじゃないので、
数字の羅列が5分何秒とか10分何秒とか、そういうのを見ていって、
前回に比べて改善されたけど、もう一回実行してみたら、
前回よりあまり改善されていなかったみたいなのがあって、
もうちょっと俯瞰してみたいなと、そういうニーズが自分の中には結構あったので、
グラフ化するといいんじゃないかなっていうのが思って、最近そのコードを書いています。
その中身は正直いいんですけど、この開発を本格的に始めたのがこの1週間なんですけど、
ものすごい集中をしてやっているんですよね。結構楽しいと。
やっぱり自分って開発者なんだなっていうのを感じる瞬間なんですよね。
本当に今までってコンピューターに向かい合うのって結構はばかられてたんですよね。
家族がいまして、子育てとかもしなきゃいけなくて、
そうなってくるとどうしてもやっぱりコンピューターに触る時間って減らさざらを得なくてってやってたんですけど、
03:07
その開発を始めたらちょっとでも隙があればちょっとごめんって言って、
コンピューターに向かってタスクをこなしていくと。
本当に30分。30分って長いかもしれないですね。
ちょっとっていうのが30分くらいだったりして、やってしまうと。
ちょっとその時間は本当に非常に家族には申し訳ないんですけど、
この30分とかの隙間時間、ものすごい集中してるんですよね。
あらかじめバックログをそれなりに、個人レベルなんでそこまで本格的にやってないですけど、
ある程度リファインメントして、トゥードゥにして、本当に雑念。
全部Miroで管理してるみたいな感じなんですけど、それをやっていって隙間時間にどんどんやっていくと。
非常に楽しい。本当に非常に楽しい。
これが私のやりたいことなんだなっていうのがよくわかる。
ということで、開発者、今後もやっていきたいなっていうのが正直なところです。
スクラムマスターが嫌いかっていうと、全然嫌いではなくて、今後もやっていきたいというか、
実践していきたいなとは思ってるんですよね。
最近ゾンビスクラムサバイバルガイドを本格的に読み始めてて、
ゾンビスクラム.orgとかを訪問してみて、
最近ブログどんなものが書かれてるのとか見てたんですけど、
そこから辿っていくと、著者の一人のクリスティーンさんが、
最近書いているブログ記事は、
Why I'm Sometimes a Grumpy Developerっていう記事が書いてあるんですよね。
グランピーっていう単語がわかんなかったんですけど、
意味はBad Temptedみたいな感じだから、
ちょっと嫌な感じのっていうか、ちょっとイラついてるみたいなそういう意味かなと思ってます。
内容は、クリスティーンさんはそもそもスクラム.orgでトレーナーしてるぐらいだから、
相当スクラムわかってる人なんですよね。
トレーナーできるぐらいだからファシリテーションとか、
ヒューマンスキルみたいなものもあるはずで、
実際ソーシャルな会話とかそういうのはめちゃくちゃ好きな方だと。
ただ開発者になると、なんかちょっといろいろあるんだよねみたいなことが書いてありました。
それを振り返ってみて、こういうことがあったんだねと。
どうも集中している時間が欲しいんじゃないかとか、開発者として。
みたいなことが書いてあって、
どうやってその折り合いつけていこうかねみたいなことが最後書いてあるんですよね。
06:00
なんでこのクリスティーンさんの話を持ち出したかっていうと、
としてみたいなことを書いてあって でまぁじゃあどうやってその折り合いつけていこうかねみたいなことは最後書いたんですよね
折り合いっていうのは例えばそのミーティングの時間をなるべくその 集中ミーティングが集中する日っていうのに集めて
コーディングの時間を確保するみたいな なんでこのクリスティーンさんの話を持ち出したかというと
クリスティーンさんがスクラムトレーナーやりつつ 開発者やってるっていうのが結構私としては衝撃なんですよね
その日本でもフリーランスでスクラムマスターやりながら
支援先って言っちゃうなんですけどによっては 開発者としてのロールが必要であれば開発やるみたいな
そういう方も結構いるとは思ってるんですけど あんまり大多数じゃないかなと思ってて
大多数じゃないと思うんですけどこのクリスティーンさんはさっき言った通り スクラムトレーナーやりながら開発やってるっていうのが自分の中ですごくて
なんか尊敬するなとこれができるなら 両方目指すっていうのもありなんかなと思ったり思わなかったりしましたと
ただですね最後の方にもしかしたら開発者としての手を止める時期が来てるのかもしれない みたいなことが書いてあったりはするんですけど
でもそれでも 頑張ってほしいなとなんとなく思うわけですよね
何が言いたいことですね その開発者としてのスキルというか開発者としてのキャリアか
キャリアに対して結構思うところがあって この辺りの記事に触れて非常に感銘を受けたと
そして私の最近の開発体験がやっぱりこう なんかものすごく楽しいと
いうところで自分は開発者なんだなと思ったところであります
そうですね 先ほどの開発 GitHubワークフローの時間の可視化なんですけど
結構面白いというか 罠がありまして
まず一つ目の罠は 時間の正確に測るためには GitHubワークフローランズっていう
APIとは別にワークフローランユーセージっていう別のAPIが必要なんですね
これがGitHubワークフローランのIDを要求しまして つまりID1個でエンドポイント
RESTのAPIを叩く必要があって なのでランの数が
ランっていうのは要するにはワークフローが トリガーされたやつのことをランと言うんですけど
09:00
例えばtest.yamlみたいなのがあったとして test.yamlが仮に1日1000個作られると
5日で5000ですよね 結構な数だなと思うんですけど
つまり5日分の情報を何らかの形で集計して ビジュアライズするためには
ユーセージ さっきのワークフローランユーセージを 5000回実行する必要がありますと
で やればいいじゃんって話なんですけど GitHubにはレートリミットの問題があったと
前職はGitHubインテグレーターの会社だったこともありまして 非常に馴染みがあるなという感じなんですけど
レートリミットの問題があるのは分かってるんだけど
ランユーセージ 正確なランの実行時間をとるためには これしかないんだよな
どうすればいいんだろうなみたいなのが 罠にはまりましたね
最近だとGitHub 最近というかもうだいぶ時間経ってますけど GitHubはGraphQLのAPIも提供していますよね
GraphQLのAPIで取ればいいじゃんと GraphQLのAPIだと結構その
IDを要求するようなエンドポイントの 要はリストじゃなくてゲットを要求するエンドポイントも
そのGraphQLで一度のリクエストで取れたりするんですよね 多分裏側で計算時間がかかる
なんかリストAPIとは別の仕組みで計算されるので レートリミットが純粋にその使わなくて済むかっていうとそんなこともないんですけど
過去実験したところ 何だったかな 何かのAPIでその1個のゲット相当のものが GraphQLでリストで何か取得できるので
それをやってみたらレートリミットの減りがほとんどなくて かなり驚いたことがあります
GraphQL最高じゃないかと なんですけどGraphQL全部のリストAPIを
サポートしているわけじゃないですよね そのサポートしているわけじゃないに含まれるのがこのワークフローランユーセージ
ワークフローランユーセージはGraphQLのAPIでは取ることができないと なのでなくなくリストAPIを使う必要がありレートリミットの問題に悩まされると
レートリミットの問題 1日に50の欄が作られるとしましょうと 5日間やると250ですよね
とはいえもっとたくさんの情報を集計して もっと長いグラフを取りたいといった時に
例えば そうですね今日は3月31日なので 3月31日に
各500件取ったとしましょうと 1日50個作られるんで450個はすでに取得した
欄なんですよね ユーセージか欄ユーセージなんですよね 次の日も実行するとまた新しい50に加えて
12:09
残り450が既存 つまり既存のやつ450でレートリミット使うのってもったいないよねって
発想に普通になると思うんですよね そこでキャッシュを使おうって話になって
愚直に自前でキャッシュを実装してもいいんですけど 結構大変なのであんまり
やめた方がいいかなと どういうふうにキャッシュを使うといいかというと
GitHubはコンディショナルリクエストっていう仕組みを提供していて 要はHTTPヘッダーですね
キャッシュ系のいろいろあると思うんですけど それをセットするとGitHubはキャッシュしたやつを使っていいよっていう時に
304のステータスコードを返すと そうなった時にはレートリミット減りませんよってちゃんと書いてあるんですよ
これは最高じゃないかなと なのでその手元にキャッシュしたデータを保持して
eタグが必要なんですよね eタグのバリューが eタグのバリューをif-not-matchっていう
HTTPヘッダーにセットして送ると 304が返ってきたら手元で保持しているキャッシュのデータを使って
残りの計算をするみたいなふうにすれば これはハッピーなんじゃないかと思ったんですけど
罠があって これドキュメントに載ってないんですけどね レートリミットは
パーソナルアクセストークンみたいな 人に紐づいたアクセストークンだったら減らないんですけど
GitHubアクションで実行される アサインされるトークン GitHub.Tokenみたいなあれですよね
あれだとレートリミット減るんですよね これ私実験しました 実験したのでもう減ると思います
なんでかわかりませんが多分減っちゃうんですよ どうも他のその似たような記事がスタックオーバーフローにあって
あっちの方にはトークンを使わずにやった場合には レートリミットが減っちゃうんだよね みたいな つまり
認証してない状態でやるとレートリミット減るんだよね みたいなことが書いてあって なんかそれと似てるなと
きっとそれもドキュメントに書いてないことだろうなと思います これがまあ本当に2つ目の罠で
結局だからその 乱優勢時を使おうと思うとレートリミットの問題に悩まされるということが判明して
じゃあ別の策を問うかなというのを今考えているところです こんな感じでこういうのを考えるのがめちゃくちゃ楽しいんですよね
やっぱり開発者いいですね おっと今日は結構しゃべりすぎてしまったのでこれで終わりにしようと思います
それではまた
