3時に寝て7時半に起きた。前日の深夜にオフィスの掃除をしてた。シェアオフィスなので掃除機をかけると音がうるさくて周りに迷惑なので誰もいない時間帯を見計らって行う必要がある。

逆イールド

会社を経営する上で経済の状況は大きな影響を受けるので機をみて経済の勉強もしている。直近40年近くの統計では、米国債金利において、2年債の金利が10年債の金利を追い越してしまう現象が発生した場合、その1年後ぐらいに景気後退期がやってくる。この現象を 逆イールド と呼ぶ。

なぜ逆イールドが発生すると景気後退となるのか。国債とは政府の借金。金融機関、年金、個人、海外などが貸している。金利は複雑で様々な要因で決まるので一概に言えないが、大雑把にまとめると経済の力や金融政策、世のおカネの量で決まる。政策金利によって3ヶ月債や2年債は大きく影響を受ける。利上げを急ぎでやろうとしている理由は高いインフレがある。米国は約40年ぶりの高インフレとなっている。FRB は約2%のインフレを目標としているが、現状は遥かに高い水準になるので金利を上げてインフレを抑制しようとしている。FRB は次の2つの使命を負っている。

• 物価の安定
• 雇用の最大化

いま物価が急上昇しているため、このまま金融緩和を続けるとさらに物価が上昇して悪い影響を及ぼしてしまう。いまは金融緩和を縮小して利上げをしていく必要がある。しかし、利上げは景気に対して悪影響となる可能性がある。どのぐらい利上げすればよいのかは実際には誰もわからない。最悪の状況として次がある。

• スタグフレーション: 高インフレのまま景気が減速する現象

スタグフレーションが発生すると経済対策や金融政策で対応しづらい非常にまずい状況となる。経済学者によっても意見が分かれるので、まだスタグフレーションが起こるとは限らない。しかし、起こる可能性があるという見方も出てきているらしい。

英語のテックブログ開設

先日作った backlog-github-integration-action の記事を書くことにした。会社のプロダクトとして作ったツールで汎用的なものや業務として保守していくものは積極的にアピールしていきたい。基本的に私は日本市場をあてにしていないのと、せっかく会社を作ったのだし、海外の会社と取り引きできるようになりたいという野望もある。プロダクトの情報発信は英語が基本で、余裕があったら日本語も書くといった優先度でやっていく。

少し前にたまたま hashnode がイケてるというのをタイムラインでみかけたのを思い出した。せっかくなので調べてみたら、どうも Custom Domain を無償、且つお手軽に設定できるのが訴求点になっているらしい。カスタムドメインを使うと、url に統合性があってカッコいいという以外にも信頼できるドメインに対して SEO が行われるため、優良な記事を書いていると自社ドメインの信頼があがっていくといったメリットがある。コストがかからないならカスタムドメインを使わない理由は何もない。そして設定したものが次になる。

• https://blog.kazamori.jp/

ネームサーバーにカスタムドメインの設定をしていて間違って少しはまった。

間違った設定

cname blog hashnode.network

正しい設定

cname blog hashnode.network.

最後にドット . が必要になる。これで blog.kazamori.jp の名前解決が hashnode.network として解決される。

$ dig blog.kazamori.jp
...
;; ANSWER SECTION:
blog.kazamori.jp.	198	IN	CNAME	hashnode.network.
hashnode.network.	46	IN	A	76.76.21.21

CNAME レコードを滅多に設定しないのでドットで終わらないといけない規則を忘れてた。設定後、dns の propagation に最大24時間ほどかかる。世界のどこからでもアクセスできるようになるには24時間ぐらいかかるかもしれないけど、ローカルで動作検証するなら数分で反映されてた。

2時に寝て6時半に起きた。

backlog と github のインテグレーション action の試験運用

昨日作った backlog-github-integration-action を早速お手伝い先の github リポジトリと backlog に導入した。いま暇な時期というのもあって、誰からもクレームが出なかった。この閑散とした間隙を「乗るしかない、このビッグウェーブに」というノリで導入して運用して既成事実を作る。ses でお手伝いに行って課題管理のツールを作っているというのは頭おかしいと思うけど、周りからクレームが出る前に電光石火で運用にのせてしまう。実際に運用で使うといくつかバグがあって、いま latest の docker イメージを使ってカスタム action が動いている。バグがあったら修正して、./gradlew jib (docker push) で新しい docker イメージを gihtub packages に push して、不具合があった pr のジョブを再実行すれば再現環境でテストもできる。いくつかバグ修正をした。実際の運用のデータを使うとばらばらとバグがみつかる。運用で実際に使われていないツールはダメ、絶対。

0時に寝て7時に起きた。丸一日開発していた。構想1ヶ月、実装2日といったところか。

backlog と github のインテグレーション action

お手伝い先が backlog を課題管理システムとして使っている。backlog は git 連携 の機能をもっているが、これは nulab 社のクラウド上に git リポジトリを構築したものと連携する機能であって、github と連携する機能ではない。そこで github と backlog と連携するためのカスタム github action を作った。

• https://github.com/kazamori/backlog-github-integration-action

カスタム github action を java で開発するのは普通にはやらないと思うが、いくつか理由があってお手伝い先が java しかできないというのと、nulab 社が提供している公式クライアント nulab/backlog4j が java しかないから。最初は go で実装しようと思って go のクライアントを試したんだけど、サンプルコードをかいたら一部の処理でエラーになって、そのエラーがよくわからなくてやる気がなくなってしまった。最新の rest api の仕様にそってメンテナンスされていないのかな？と思って、やっぱり公式クライアントしかないなと。他にも次のライブラリを使っている。

• 設定ファイル: https://github.com/lightbend/config
• コマンドライン解析: https://github.com/remkop/picocli
• github クライアント: https://github.com/hub4j/github-api

これまでは commons-cli を使ってきたけど、サブコマンドの機能を提供していない。もうメンテされてないかも？サブコマンドの機能をもつ argument parser がほしくて picocli を選択した。初めて使っていて、実装してみたらわりと私の好みでよく出来ていると思う。今後は cli ライブラリとして picocli を使っていこうと思う。

0時に寝て6時に起きた。

歯科検診

3ヶ月ごとの定期検診。本音は行くのが面倒くさいのだけど、こういう機会がないと検診に行かないので健康のためと思って通い続けている。基本的には30分強ぐらいで歯の掃除？みたいなことをやるだけ。下の歯の親知らずをまだ抜いていなくて、歯磨きでは届かないスポットがあって、そこが虫歯になりやすいのかな？3ヶ月に1回は掃除してもらえるのでたぶん役に立っているのだろう。今回は前にレントゲンをとって2年経ったので取り直ししましょうということで歯のレントゲンもとった。この歯医者さんにきてから2年経ったんだなということを実感した。よい歯医者さんだと思っているのでこれからも通うだろう。

カスタム github action 開発

前からやろうやろうと思っていて、他のことに時間を割かれてできていなかったことに着手した。久しぶりに gradle を触ったら使い方や設定方法を忘れてしまってドキュメントを読みながら再入門した。1つのアプリケーションであってもマルチプロジェクト構成がデフォルトになったみたい。これによってディレクトリの階層構造も変わっている。

• Gradle のマルチプロジェクト機能を試す

今日のところは gradle 設定と main 関数と config のコードだけ書いた。java のバージョンも17を使うことにした。週末にある程度動くものを作りきれるかどうか。着手するまでが一番時間がかかので着手すればすぐにできそうな見通しはある。

2時に寝て何度か起きてだらだらしながら10時に起きた。

gihtub-api-tools のリファクタリングとデータ分析

実際に使ってみながらリファクタリングしたり、足りない機能を追加したりした。ツールに拡張した機能が使えるかどうかの検証のため、お仕事のプライベートリポジトリのデータを使って分析をし始めて、気付いたら分析ならびに分析結果の資料まで作ってしまった。軽く半日ぐらいのお仕事をやってしまっていた。過去5ヶ月分の課金時間の合計を算出し、単体テストの実行を github actions に追加することで増える課金時間の見積もりと金額を算出した。月間でいまより3時間30分、全体の課金時間に対して20%弱程度の追加が見込まれる。それによる課金金額を算出すると 210 * $0.008 = $1.68 になる。いままで無料枠を超えないように運用してきたわけだが、こんな200円程度の金額を節約するために github actions 上でテスト実行しないといった判断がくだされていた。開発者は誰も実際の課金金額を知らなかったし、課金金額を算出するとあほらしくなった。あと github actions はめちゃくちゃ安い。

5時に寝て9時過ぎに起きた。昨日は久しぶりに夜更ししてコードを書いてた。

github actions のいろいろな時間の算出

以前作った github-api-tools を拡張して github actions の実行履歴の分析するための機能を作っている。

• Add actions statistics
• Add gh-cli-actions command for Actions API

ひとまずワークフローの実行履歴からジョブのステップの実行時間を積み上げた時間を算出してみた。いくつか API を調べているうちに課金時間は直接 API から取得できることに気付いた。この3つの時間は全然別の意味をもっていて、それぞれの時間は一致しない。

• ステップ実行時間: ジョブのそれぞれのステップの実行時間の合計
• 課金時間: 課金対象として数えられている時間の合計
• ワークフロー実行時間: アクションのワークフローの実行にかかった時間

github actions は public リポジトリに関しては課金対象ではないんやね。private リポジトリ且つ github-hosted ランナーを使っている場合のみ課金対象となるみたい。

• Viewing job execution time
• About billing for GitHub Actions

0時に寝て3時に起きて6時に起きた。

失敗したジョブの再実行

せらさんのツィートをみかけて調べたら2日ほど前に失敗したジョブからの再実行の改善が行われたらしい。

GitHub Action で失敗したジョブだけ実行できる様になってる。今まで失敗しやすいものは再実行を小さくするために設定を分けたりとかしていたんだけど、そういうことをしなくてもよくなった。

— Kazuhiro Sera (瀬良) (@seratch_ja) March 18, 2022

• Save time with partial re-runs in GitHub Actions

たまにだけど、i/o エラーみたいな内容で github actions のワークフロー実行が異常終了することがある。そんなときに途中から再実行できるといいなぁとは思っていた。これはステップ単位ではなく、ジョブ単位の実行みたいだけど、それでも途中から再実行できればワークフローの自由度や効率は上がると思う。github actions がどんどん強力になっていくのが楽しみ。あとやぎさんから教えてもらった GitHub Actions 実践入門 も購入した。ある程度触ったところで雰囲気は掴めてきたので体系的に学んでみる。

0時に寝て3時に起きて5時半に起きた。

開発のコミット/マージのルール改定

過去のスクラムのふりかえりをみていて、12月15日にレビューアが1人のため、Pull Request (以下PR) のレビューにかなり時間がかかっているという指摘をしてから3ヶ月かかって、ようやくレビュー負荷が集中していた社員からレビュープロセスの改善の機会がもたらされた。なぜレビュー負荷が1人に集中するかというと、チームの開発者は5人で、正社員1人で他4人は外部の協力会社であるため、正社員の approve なしでマージすることに躊躇するという状況だった。

大幅にレビュープロセスが緩和された。

• 軽微な変更は PR を作って自分でマージしてよい
• (所属問わず) 1人以上のレビューアによる apprve があればマージしてよい
• PO が最終レビューするものは PR レビューアの approve を得なくてもよい

私の作業時間の1/3は PR レビューの待ち時間だったのでこれだけで私の生産性は1.5倍になる。どんどんコミットしていけると開発していて楽しい。

オンライン飲み会

余りまくっている交際費の予算消化も兼ねて前にお手伝いしていた会社のたにがきさんと雑談した。近況を話したりもしつつ、たにがきさんは私が過去に働いていた会社の親会社で働いていて、その時期も重なっていて、その親会社の話しを主にしていた。その親会社は主力プロダクトの完全な作り直しを宣言して、1000億円ぐらい開発費を投じたものの、実際にはプロダクトの作り直しに失敗して、資金繰りが悪化して事実上の倒産をした。親会社の社長はカリスマ社長で新興宗教の教祖みたいな感じだったんだけど、会社がファンドに買収されて、取締役を退任させられて、しばらくは鳴りを潜めていたけど、最近はまた会社を作って精力的に活動しているらしい。近く OB 会のようなイベントがカリスマ社長から呼びかけられているらしく、どう考えてもリクルーティングの場なんだろうと話していた。また1年ぐらいしたら近況報告会をしてもいいかもしれない。

0時に寝て5時半に起きた。一仕事を終えて淡々と前の作業の続きのリファクタリングなどをしていた。

デプロイ改善のタスク完了報告

週末にパイプライン処理の検証やロールバック処理の実装を行った。ドキュメントも一通り書いた。チームの開発者にそれらを説明して3スプリント(3週間)に渡った改善が完了したことを報告した。チケットにすると26、そのうち私が担当したのが22なので、私がイニシアティブをとって完遂させた。github actions を始めとする、github のサービスの理解が深まってそれなりに学びがあった。自分でもいくつかカスタム action を作ってみようと思う。

23時に寝て2時に起きて4時ぐらいまでだらだらして寝て6時に起きた。

ストレッチ

これまで11時からストレッチを受けていたが、今週から dr.stretch さんの土日の開店時間が10時になったのにあわせる形で時間変更した。朝に予定が入っているとその時間にあわせて起きて身支度して1日が始まるので家で中途半端にだらだらしなくてよい。いつもは11時にあわせて家を出掛けるのが、10時にあわせて出掛けるようになったのでいつもより1時間早く活動できるようになった。私はなんか予定がないとだらだらしてしまって怠惰に過ごしてしまう。そういう怠ける自分の性格もわかっているので適度に予定を入れて怠けないように注意している。

今日の開脚幅は開始前163cmで、ストレッチ後165cmだった。先週とほぼ同じ。今週もお仕事が忙しくて全くできなかったので現状維持といったところ。

デプロイのパイプライン処理

github deployment から workflow dispatch に移行したおかげでせっかく deployments ベースで作ったパイプライン処理のツールを workflow dispatch 向けに移行する必要があった。言うても基本的に同じパラメーターを処理するだけなので大半は再利用できる。ツールのちょっとしたリファクタリングをやってパイプライン処理が動くかどうかの検証をして、ドキュメントを wiki にまとめた。あとはロールバックを自動化するための仕組みを作るだけ。基本的には k8s の kubectl を実行するワークフローを作るだけという想定。

23時に寝てたぶん1回ぐらい起きて6時前に起きた。

GitHub Discussions

やぎさんに GitHub Discussions というのがあると教えてもらった。軽くチュートリアルやドキュメントに目を通してみた。stackoverflow のような q&a ができるようなサービスなのかな？著名な oss のコミュニティでたまに盛り上がるネタとして issue がサポートセンターになってしまうという問題がある。経験が少ない開発者が自分の環境で動かなかったときに issue 登録して開発者にサポートを依頼するみたいなことになってしまうケースがある。もちろん経験が少ない開発者にとっては環境要因のエラーとそうじゃないのを見分けるのは難しいことかもしれない。一方で oss コミュニティのメンテナーのリソースも有限なことから初心者質問を回答するために多くの労力をさけないという現実もある。その issue と q&a のギャップを埋めるようなサービスになるのかな？と推測している。試しにいま作っているデプロイツールで discussions を有効にしたのでいろいろ触ってみる。

近況報告

約1年ぶりにやすだ先生とオンライン飲み会をした。3月にやっているので今期の経営的なふりかえりも少ししつつ大半は雑談をしていた。昨年、経営コンサルティングで交際費が少な過ぎるという指摘を受けてからオンライン飲み会や雑談会を始めたときの、身近な相談相手の1人と言える。今期は10人以上とオンライン飲み会やオフラインの雑談会をやっているし、こんな感じで知人と定期的に近況を話す仕組みを継続できればいいなとは思う。今期は交際費として30万円/年の予算を確保しているものの、現時点では83,747円しか消化していない。もう決算まで1ヶ月もないのに。なぜなのか。。。