5時に寝て9時過ぎに起きた。昨日は久しぶりに夜更ししてコードを書いてた。
以前作った github-api-tools を拡張して github actions の実行履歴の分析するための機能を作っている。
ひとまずワークフローの実行履歴からジョブのステップの実行時間を積み上げた時間を算出してみた。いくつか API を調べているうちに課金時間は直接 API から取得できることに気付いた。この3つの時間は全然別の意味をもっていて、それぞれの時間は一致しない。
github actions は public リポジトリに関しては課金対象ではないんやね。private リポジトリ且つ github-hosted ランナーを使っている場合のみ課金対象となるみたい。
0時に寝てたぶん夜中に起きて7時に起きた。
先日から 見始めて1週間ぐらいかけて12話を見終えた。個人的には4話の そのマチェットを強く握れ！ がよかった。最初の4話をみて、この物語の演出や構成の仕組みが理解できて、その後の話しもみてみようという気になった。4話がおもしろかったから8話と12話も期待したんだけど、4話が私の中で一番はまった分だけ、8話と12話は期待し過ぎになってしまった。別におもしろくなかったわけではない。パブリック・エネミー という言葉が出てきて、こんな言葉を使ったことないし、人生で1度は言ってみたい言葉だなと思った。よくよく考えたらクリエイターって既存の価値観に捕われず新しい価値観を創造するのだから、それは従来の価値観や秩序をよしとする人たちからみたら秩序の破壊者にみえることもあって、クリエイターをパブリック・エネミーと呼ぶのはそれほど的外れでもないかもしれないなとか思ったりもした。
今日の開脚幅は開始前161cmで、ストレッチ後162cmだった。今週もまったくやらなかったので先週より数値が悪くなった。そろそろ暖かくなってきたし、お仕事も一段落ついて落ち着いたので新たに生活のスタイルも変えていきたいと思う。そうやってさぼっていても週に1回はストレッチを受けられて本当にラッキーだと思う。
てらださんが週末は暇だから Horizon Workrooms をしたいと話しているのをみかけて参加してみることにした。workrooms のよいところの1つとして、現時点では仮想空間内でパソコンを扱い難いので内職をしないことがあげられる。私はもはやパソコンを持ち込まないようにしていて、その場での会話に100%集中している。これが普通のオンライン会議ツールだと、自分が関心のない話題なら個人の作業を始めたり、外部とのインタラクションがあったりするとそれに反応したりする。そういったことをしないためのツールとして workrooms がいいなと思うところもある。これはただの運用の話しだけど。
workrooms で2時間ほど4人で雑談した。メタバースや仮想空間の技術への取っ掛かりの1つとして workrooms を始める人が私の周りでは少しずつ増えていて、徐々にメタバースに関するなにかは盛り上がっていくのかもしれないという雰囲気も出てきている。私の場合、月に1-2回は workrooms で雑談会をするようになってきた。私もただのユーザーではなく、なにかしらツールかコンテンツを作ったりする方に行くべきかもしれないけど、まだまだ他の現実のお仕事でできていないことが山ほどあって傍観している程度。
0時に寝て3時に起きて6時に起きた。
せらさんのツィートをみかけて調べたら2日ほど前に失敗したジョブからの再実行の改善が行われたらしい。
GitHub Action で失敗したジョブだけ実行できる様になってる。今まで失敗しやすいものは再実行を小さくするために設定を分けたりとかしていたんだけど、そういうことをしなくてもよくなった。
— Kazuhiro Sera (瀬良) (@seratch_ja) March 18, 2022
たまにだけど、i/o エラーみたいな内容で github actions のワークフロー実行が異常終了することがある。そんなときに途中から再実行できるといいなぁとは思っていた。これはステップ単位ではなく、ジョブ単位の実行みたいだけど、それでも途中から再実行できればワークフローの自由度や効率は上がると思う。github actions がどんどん強力になっていくのが楽しみ。あとやぎさんから教えてもらった GitHub Actions 実践入門 も購入した。ある程度触ったところで雰囲気は掴めてきたので体系的に学んでみる。
0時に寝て3時に起きて5時半に起きた。
過去のスクラムのふりかえりをみていて、12月15日にレビューアが1人のため、Pull Request (以下PR) のレビューにかなり時間がかかっているという指摘をしてから3ヶ月かかって、ようやくレビュー負荷が集中していた社員からレビュープロセスの改善の機会がもたらされた。なぜレビュー負荷が1人に集中するかというと、チームの開発者は5人で、正社員1人で他4人は外部の協力会社であるため、正社員の approve なしでマージすることに躊躇するという状況だった。
大幅にレビュープロセスが緩和された。
私の作業時間の1/3は PR レビューの待ち時間だったのでこれだけで私の生産性は1.5倍になる。どんどんコミットしていけると開発していて楽しい。
余りまくっている交際費の予算消化も兼ねて前にお手伝いしていた会社のたにがきさんと雑談した。近況を話したりもしつつ、たにがきさんは私が過去に働いていた会社の親会社で働いていて、その時期も重なっていて、その親会社の話しを主にしていた。その親会社は主力プロダクトの完全な作り直しを宣言して、1000億円ぐらい開発費を投じたものの、実際にはプロダクトの作り直しに失敗して、資金繰りが悪化して事実上の倒産をした。親会社の社長はカリスマ社長で新興宗教の教祖みたいな感じだったんだけど、会社がファンドに買収されて、取締役を退任させられて、しばらくは鳴りを潜めていたけど、最近はまた会社を作って精力的に活動しているらしい。近く OB 会のようなイベントがカリスマ社長から呼びかけられているらしく、どう考えてもリクルーティングの場なんだろうと話していた。また1年ぐらいしたら近況報告会をしてもいいかもしれない。
0時に寝て6時半に起きた。
お奨めされたので 映像研には手を出すな を見始めた。あまり現実と空想が入り交じる展開が新鮮と言えば新鮮だし、ストーリーがわかりにくい気もしてもやもやする。浅草氏も「アニメは設定が命」と言っているし、この設定はどうなの？とか思いながら、それでもみているんだからいいんだろうって感じ？最初はごちゃごちゃしててわかりにくい感じがしたんだけど、見続けていると徐々に独特の世界観に慣れてきたのか、ところどころおもしろいなと思うようにはなってきた。また全話みてから総括する。
お仕事でたまたま触っているところの sql をみたら次のようなものがあった。サブクエリで group by 句を使っている。仮に mytable_detail が1億件ぐらいあったらこんな sql 動くわけがない。データが溜まるごとに遅くなっていって、しきい値を超えると急激にパフォーマンスが悪化する時限爆弾みたいな sql だと思う。お手伝い先は or mapper を使っていないので開発者が sql を手で書いているにも関わらず、こんな sql が実運用されてしまうような開発体制には大きな課題があるなぁとか考え込んでしまった。
SELECT mytable.*, t.is_some
FROM mytable
LEFT JOIN LATERAL (
SELECT mytable_id, bool_or(mytable_detail.is_some) as is_some
FROM mytable_detail
WHERE mytable_detail.mytable_id = mytable.mytable_id
GROUP BY mytable_detail.mytable_id
) as t on t.mytable_id = mytable.mytable_id
WHERE mytable.foreign_key_id = :foreignKeyId
ORDER BY mytable.mytable_id;
以前、お手伝いしていた会社の CTO が社内の開発者のデータの取り扱いの指針として書いた記事が次になる。社内では 最低 1000万件のデータがあると思ってコードを書けと強く啓蒙していた。いまどきのデータ量として1000万件というのはよい指標だと思う。
0時に寝て3時に起きて6時に起きた。やっぱり起きてからドラクエタクトしてた。
デプロイ改善が完了したので新しいタスクに取り組み始めた。もともとこの開発チームはバックエンドもフロントエンドも全部やるというチームなので、やりかけ中のタスクのフロントエンド側の変更に着手して、既存の画面に新規項目を追加するといった作業をやってみた。フロントエンドは vue.js + nuxt で開発している。ビルドに30秒ぐらいかかる。ちょっと遅い。宣言型 ui のよいところかもしれないけど、vue.js も nuxt もまったく触ったことないけど、ripgrep で検索してちょちょっとコピペしたらそれっぽく動いた。これはまさにあれだ。
全然わからない。俺たちは雰囲気で開発している。
動いたらラッキーみたいな感じで PR を作って、たまたまレビューも通って、テスト環境で動いたんでラッキーだった。
0時に寝て5時半に起きた。一仕事を終えて淡々と前の作業の続きのリファクタリングなどをしていた。
週末にパイプライン処理の検証やロールバック処理の実装を行った。ドキュメントも一通り書いた。チームの開発者にそれらを説明して3スプリント(3週間)に渡った改善が完了したことを報告した。チケットにすると26、そのうち私が担当したのが22なので、私がイニシアティブをとって完遂させた。github actions を始めとする、github のサービスの理解が深まってそれなりに学びがあった。自分でもいくつかカスタム action を作ってみようと思う。
0時に寝て7時に起きた。
Rolling Back to a Previous Revision をみながらすぐできた。ロールバックもこれまでと同様、github actions の workflow dispatch で管理できるようにした。基本的にはこれだけでロールバックできる。
$ kubectl rollout undo deployment/my-app-deploy
ちょっと工夫したこととして、デプロイ時に kubernetes.io/change-cause というアノテーションに git のリビジョンもセットしておくと確認するときにちょっと楽ができる。apply した後の deployment リソースに docker イメージのタグ情報 (= git のリビジョン) を書き込んでおく。
$ kubectl apply -k ${{ env.DEPLOYMENT_ENV }}
$ kubectl annotate deployment my-app-deploy kubernetes.io/change-cause=${{ env.IMAGE_TAG }} --overwrite=true
kubectl から履歴をみたときに k8s のリビジョンがどの git のリビジョンを使っているかがわかりやすい。デフォルトでは何も設定されていないかもしれない。
$ kubectl rollout history deployment/my-app-deploy
deployment.apps/my-app-deploy
REVISION CHANGE-CAUSE
15 <none>
16 <none>
17 <none>
18 <none>
19 <none>
20 <none>
21 <none>
22 <none>
24 1f17a22a6659ea0714a21fca034645cd191e189b
27 a84e113d8b7c124178b58e2f40f57b00aae65485
28 dcf3552db0668d416ed880f6e896455d7bab194c
23時に寝て2時に起きて4時ぐらいまでだらだらして寝て6時に起きた。
これまで11時からストレッチを受けていたが、今週から dr.stretch さんの土日の開店時間が10時になったのにあわせる形で時間変更した。朝に予定が入っているとその時間にあわせて起きて身支度して1日が始まるので家で中途半端にだらだらしなくてよい。いつもは11時にあわせて家を出掛けるのが、10時にあわせて出掛けるようになったのでいつもより1時間早く活動できるようになった。私はなんか予定がないとだらだらしてしまって怠惰に過ごしてしまう。そういう怠ける自分の性格もわかっているので適度に予定を入れて怠けないように注意している。
今日の開脚幅は開始前163cmで、ストレッチ後165cmだった。先週とほぼ同じ。今週もお仕事が忙しくて全くできなかったので現状維持といったところ。
github deployment から workflow dispatch に移行したおかげでせっかく deployments ベースで作ったパイプライン処理のツールを workflow dispatch 向けに移行する必要があった。言うても基本的に同じパラメーターを処理するだけなので大半は再利用できる。ツールのちょっとしたリファクタリングをやってパイプライン処理が動くかどうかの検証をして、ドキュメントを wiki にまとめた。あとはロールバックを自動化するための仕組みを作るだけ。基本的には k8s の kubectl を実行するワークフローを作るだけという想定。
1時に寝て6時に起きた。朝ちょっとデバッグをやって午後からは来週のオンライン飲み会の手配をしたり、打ち合わせのメモをまとめたりしていた。
顧問のはらさんと隔週の打ち合わせ。直近の2-3週間でやっていた ci/cd の改善や github actions のことについて共有したりした。次の契約更改のタイミングで契約条件の変更を相手と協議しようと考えている。具体的には単価をあげたり事例紹介を許可してもらったりといった類の交渉をする予定。一般論として業務委託は最初の契約条件から条件変更するのが難しいらしく、なかなかタフな交渉になるっぽいというのをはらさんから助言してもらったりしている。私の中では交渉するネタはいくつかあるし、ダメならダメで最悪のケースなら契約終了して、別の会社のお仕事に切り替えてもよいし、いまは開発者は売り手市場なので楽観的に考えていたりする。
元同僚と1年ぶりにオンライン飲み会をした。それぞれ近況を話したりしていた。私が見限ったビジネスはその後うまくいったらしくてなにがうまくいくかわからんものだという話しも聞いた。私が在籍していた頃の早期退職制度は50歳以上が対象だったけど、いまは45歳以上に下がっているらしい。また来期から年配の社員を辞めさせるための追い出し部屋ならぬ追い出し会社がグループ企業として設立されるという話しも聞いた。おそらくは戦力外社員をその会社に集めて待遇を下げるみたいな話なんだろうと推測する。日本の労働基準法では、一方的な解雇や減俸はできないが、配置転換は許されていて、別会社に転籍してその会社の待遇が元の会社よりも悪いというのは法律的に問題ないらしい。本体より待遇の悪いグループ企業を作って、そこに転籍することで事実上の減俸や自主退職を促すような慣習となっている。私が起業した理由の1つは早期退職制度ができて自分の未来もそうなると実感したというのがある。少なくとも自分の会社で自分が解雇されることはない。
元同僚の1人も来期は45歳になるので早期退職制度を使って会社を辞めるかもしれないという話されていた。40代からのキャリアってなかなか難しいなとは思えた。私もいまはなんとかなっているけど、このままお仕事がある保証はないし、引き締めていかないといけない。ただあるとき急に追い出し会社に送られるという組織の論理で生きているわけではないという自由だけは謳歌している。
23時に寝てたぶん1回ぐらい起きて6時前に起きた。
やぎさんに GitHub Discussions というのがあると教えてもらった。軽くチュートリアルやドキュメントに目を通してみた。stackoverflow のような q&a ができるようなサービスなのかな？著名な oss のコミュニティでたまに盛り上がるネタとして issue がサポートセンターになってしまうという問題がある。経験が少ない開発者が自分の環境で動かなかったときに issue 登録して開発者にサポートを依頼するみたいなことになってしまうケースがある。もちろん経験が少ない開発者にとっては環境要因のエラーとそうじゃないのを見分けるのは難しいことかもしれない。一方で oss コミュニティのメンテナーのリソースも有限なことから初心者質問を回答するために多くの労力をさけないという現実もある。その issue と q&a のギャップを埋めるようなサービスになるのかな？と推測している。試しにいま作っているデプロイツールで discussions を有効にしたのでいろいろ触ってみる。
約1年ぶりにやすだ先生とオンライン飲み会をした。3月にやっているので今期の経営的なふりかえりも少ししつつ大半は雑談をしていた。昨年、経営コンサルティングで交際費が少な過ぎるという指摘を受けてからオンライン飲み会や雑談会を始めたときの、身近な相談相手の1人と言える。今期は10人以上とオンライン飲み会やオフラインの雑談会をやっているし、こんな感じで知人と定期的に近況を話す仕組みを継続できればいいなとは思う。今期は交際費として30万円/年の予算を確保しているものの、現時点では83,747円しか消化していない。もう決算まで1ヶ月もないのに。なぜなのか。。。