23時に寝て2時に起きてそこから断続的に寝たり起きたりを繰り返して6時に半に起きた。ウクライナ情勢のニュースや記事ばかり読んでてあてられた。
kustomize で管理している image のタグをデプロイ処理の中で動的に変更したい。パラメーター渡しなり環境変数なり、なにかしらあるだろうとは予測している。Demo: change image names and tags のサンプルによると、次のように実行すればよいみたい。
$ kustomize edit set image busybox=alpine:3.6
次のような kustomization.yaml をセットしてくれるみたい。
images:
- name: busybox
newName: alpine
newTag: 3.6
タグのところをリビジョン指定できればいいだけなのでとくに SECRET を使う必要もない。このやり方で書き換えた newTag が POD のデプロイ対象になってくれればよいはず。
0時に寝て7時に起きた。アニメみたりドラクエタクトしたりして11時ぐらいまでだらだらしてた。
毎年、社会保険の保険料率が変更されるのでその保険料の計算をして反映しないといけない。多くの会社は3月度の保険料は翌月払いとなるので4月からの反映となるが、うちの会社は当月締めの当月払いなので3月から反映させないといけない。
協会けんぽの来期の保険料率は下がるみたい。毎年少しずつ上がっていく一方だと思っていたのでそういうこともあるんだなという印象。
タイムラインを眺めていると、否応でもウクライナ情勢のニュースやコメントが流れてきてなんとなくみてしまって作業の手がつかなくなってしまった。早めに帰って仕切り直そうとしたけど、精神的に疲れてしまって休んでいた。sns の功罪はいろいろあるけど、ネガティブな情報にたくさん触れるのはなかなかしんどいな。何だったかもう忘れたけど、前にもこんなことがあった気がする。そういうときは sns を見ない方がよいのだろうけど、何もしないでいると気になってついつい見てしまう。情報があり過ぎることも問題なんだなとつくづく実感する。
22時に寝て23時半に起きて1時に寝て6時に起きた。
先週に引き続き、右太もも後ろの張り感が強い。もしかしたらここ2-3週間、長時間机に向かっていることが増えて負担がかかっているのかもしれない。2月は寒いから帰って散歩やジョギングすることもなくて余計に筋肉をほぐすこともできていない。今日の開脚幅は開始前164cmで、ストレッチ後160cmで先週と変わらないぐらいだった。調子がよくなかったのか、ストレッチ後にあまり開脚できなかった。たまにこういうときもある。
github actions を実行するにはなんらかのトリガーが必要なことから、デプロイのためのトリガーに使えそうなものはないかを Events that trigger workflows で調べていたら deployment と deployment_status というイベントがあることに気付いた。
わりと最近できた仕組みで github deployments という api 群が提供されている。一度ベーダとして出したものの、アルファレベルだったせいか、gh cli でも専用コマンドとして機能追加されていないし、github の slack インテグレーションでも一度提供した deploy サブコマンドを削除するみたいなことが発生している。まだ設計やインタフェースが使いやすいものではないから作り直すみたいな状況にみえる。とはいえ、rest api は提供されているので現状の機能のまま github actions のトリガーとして使う分には問題なさそう。
ビルドとデプロイを分離するにあたって、デプロイのためのトリガーが github 上のサービスとしてみつかったのはよかったと言える。github deployments は現状では中途半端なサービスという位置づけにみえる。
github はどこまでいってもリポジトリ単位というのがボトルネックになるからリポジトリをグルーピングする概念を他のサービスで一貫して扱えるようにならないとサードパーティに頼る場面はまだまだありそうかな。
— Tetsuya Morimoto (@t2y) February 26, 2022
0時に寝て4時半に起きた。6時から金朝ツメトギを聞きながら途中で寝てしまって7時過ぎに起きた。
以前 コミュニケーションコストに考えたこと をベースに、3ヶ月フィードバック の一節としてお手伝い先の社内 wiki に書いた。コミュニケーション一般の話なので私の考えを伝えられるよう、社外秘の部分を削除してブログにまとめておくことにした。ちょっと書き始めたところ、また週末にでも時間があるときに少しずつ推敲したり、洗練させて自身の考えを整理していく。現状でも悪い内容ではないけれど、まだしっくり来ていないところもあって、そのもやもやも見直していきたい。
課題管理システムにチケットを作成すると fix しない限り、そのチケットは永遠に残り続ける。未着手の状態でずっと放置することもできるが、それは対応を先送りしているだけで完了するわけでもない。チケットの対応方法として wontfix という選択肢が非常に重要になる。問題があることはわかっていたとしても様々な理由で対応しないという判断はありえる。誰がどういう理由でその判断を下したかという背景や意図さえわかれば、仮に将来的にその問題が看過できない状態になったとしても、過去の判断から新たな対応方法を検討したり、その判断の是非をふりかえることができる。これはチケットを作らずに見てみぬふりをして将来同じことが起きるのとは全く異なる知見が積み重なるので非常に重要な意思決定であると私は考えている。
閑話休題。話しがズレた。ここで fix せずにずっと放置するメンバーもいたりする。様々な理由で課題管理に非協力的な姿勢をとるメンバーがいる。少なからずいる。そういう人を放置すると、真面目に課題管理をやっている人たちが腐ってしまうので、課題管理の専門家を自称する私としては看過できない状況と言える。最初のうちは非協力的なメンバーにお願いしてやってもらうわけだけど、やってくれない人はずっとやってくれない。それを言い続けるのも嫌になるので別の対応方法が求められる。私の経験則では若い人に非協力的なメンバーはほぼいない。いまの若い人は優秀なので上司や先輩のやり方をみて勝手にやる人もいるし、ちゃんと教えれば教えた通りにやってくれる。非協力的なメンバーは往々にしてそれなりの経験をもっている中堅以上の社会人に多い。実はお仕事をさぼっていてあまり作業していないとか、課題管理に馴染みがなければ、それまでの自分の仕事のやり方をアンラーニングできないという人もいるかもしれない。理由はともかく、お願いしてもやってくれない人のチケットが課題管理プロセスの中で浮いてみえてくる。他のメンバーが腐る前に対応しないといけない。私の経験則ではこれはすごく難しい問題であるし、非協力的なメンバーそれぞれの理由にあわせて対応する必要があるので工数もかかる。
課題管理をしたくないというメンバーの中には何らかの理由で自律的に働きたくないという人もいる。課題管理というプロセスにおいては、そういった人たちをあぶり出してしまうため、状況によってはとても難しい人間関係の問題へと発展してしまう。
0時に寝て6時に起きた。
継続的デリバリーのために snapshot jar のマニフェストから取得した git のリビジョンを docker イメージの labels に追加するサンプルコードを jib-sample に実装してみた。jib の gradle プラグインを作って簡略化すれば便利かもしれない。
0時に寝て3時に起きて6時ぐらいまでだらだらして寝て7時に起きた。
昨日 jar に git のリビジョン番号を含める ことについて書いた。jar から git のリビジョン番号を取得できれば、docker イメージを生成するときに labels に jar の artifact id と git のリビジョン番号のラベルを追加して、docker イメージからもソースコードの追跡ができるようになる。いまデプロイは docker イメージのみで運用しているため、maven のバージョン管理ができなくても docker イメージの追跡可能性さえあれば現実の運用で問題にならないのではないかと考えた。つまり、snapshot jar で開発したものをそのまま本番環境にデプロイするということを意味する。こうすれば特定のバージョン番号を付けるだけのビルドとデプロイが不要になって、テスト環境にデプロイされた docker イメージのテストを完了すれば、そのイメージをいつでも本番環境にデプロイできるようになる。デプロイするタイミングでビルドする必要がなくなるので継続的デリバリーに近づくのではないかと考えた。
今日、開発の偉い人やインフラ担当者も含めて、みんなでわいわい打ち合わせして、現状の開発では、インターフェースや互換性の変更にあわせてバージョン番号を付けていないし、古いバージョンに戻すことも現実にはなく、保守は常に最新のリビジョンを更新していくから maven でバージョン管理できなくなっても snapshot jar の運用でがんがん開発していけばいいんちゃうという合意を得られた。
実際にこのやり方がうまくいくかどうか、私も初めての試みなのでやってみないとわからないが、この運用によるワークフローの効率化のメリットも大きいので、引き続き、イニシアティブをもって取り組んでいきたい。
0時に寝て3時に起きて5時に起きて6時半に起きた。
java パッケージのフォーマットとして jar ファイルがある。開発中の jar ファイルは snapshot という特別なバージョンで管理したりするが、この snapshot と git のリビジョンが対応していないので snapshot jar だけではどのリビジョンのソースからビルドされたかがわからない。jar には JAR File Specification で定義された META-INF/MANIFEST.MF に任意のメタデータを保持できる。maven なら maven git commit id plugin と Apache Maven JAR Plugin を組み合わせれば、ビルド設定だけで git のリポジトリ情報を任意のメタデータとして jar に含めることができる。試しにプラグインの検証も兼ねてやってみた。例えば、次のようなマニフェストを作れる。
Manifest-Version: 1.0
Created-By: Apache Maven 3.6.3
Built-By: t2y
Build-Jdk: 11.0.13
Specification-Title: My Nice Product
Specification-Version: 1.0
Artifact-Id: my-product
Build-Time: 2022-02-21T11:39:07Z
Git-Branch: main
Git-Commit-Id: 81a4642
Git-Commit-Time: 2022-02-21T19:39:30+0900
Git-Commit-User: Tetsuya Morimoto
java のコードからマニフェストを取得するサンプルコードはこんな感じ。ググるといくつかやり方があるようなので他の実装もある。但し、このコードだと複数の jar のマニフェストを取得してしまうので、あとで自分がみたい jar のマニフェストをフィルターする処理が必要になる。
private static final String MANIFEST_PATH = "META-INF/MANIFEST.MF";
public static Map<String, Manifest> getManifests() throws IOException, URISyntaxException {
var map = new HashMap<String, Manifest>();
var resources = MyUtil.class.getClassLoader().getResources(MANIFEST_PATH);
while (resources.hasMoreElements()) {
var elem = resources.nextElement();
var part = elem.toURI().getSchemeSpecificPart();
if (part != null) {
try (var stream = elem.openStream()) {
map.put(part, new Manifest(stream));
}
}
}
return map;
}
1時に寝て6時半に起きた。昨日は夕方に一旦帰ってきて仮眠したらまた作業しようと思っていたけど、なんかバテてそのままだらだらしてた。
お手伝い先の社員さんと開発メンバーとのお休みがあわない問題が気になるようになってきた。というのは、お手伝い先は基本的に祝日は営業日として扱われている。おそらくは祝日に働いたら手当がつくのか、代休を別の日にとっているようにみえる。祝日に働かずに休む社員もいる。祝日に休むという表現もおかしいが。業務委託の開発メンバーは原則として祝日は休んで普通の日に働く。ここで社員さんが祝日に働いて普通の日に代休をとると、休みが異なるのでコミュニケーションコストが高くなる。お互いが働いている時間が減ることでその時間に対する価値が高くなってしまうという話し。国が違わない限り、あまりそういう状況は発生しないので、休日をあわせることの重要性を再認識した。
さらに働き始めた頃から気になっている カレンダー共有の問題 がある。休みが異なる可能性が高いのにメンバーのカレンダーはばらばらなので、お休みするという報告をもらっていても日が経つと忘れてしまっていて、slack でメンションをしてしまう場合がある。金曜日に月曜日はお休みすると聞いていたけど、月曜日になったら忘れてたみたいな。お休みしている社員さんに普通にメンションして、普通にやり取りしていて、あとでお休みだったと気付いて申し訳なく思った。カレンダーを確認してお休みだとわかっていれば slack でメンションはしなかった。
0時に寝て6時に起きた。
本当は9時から受け付けなんだけど、昨年早めに行ったら受け付けしてくれたので今年も8時半ぐらいから出掛けていった。家から徒歩5分のところに特設の申告会場があって、行ったらすでに100人ぐらいは並んでいた。整理券を配るために行列を誘導している係員に「書類は作成済みで提出だけです」と伝えると「どうぞ、こちらへ」と行列をショートカットして、書類の作成会場の横にある提出会場へ案内される。朝一なので誰も提出してなくてすぐに応対してくれた。書類チェックして提出完了。会場についてから提出するまでに5分。あわせて10分もあれば確定申告できる。電子申告してもよいのだけど、寄付金の領収書の電子化が面倒なのでまだ紙で申告している。寄付金の領収書が電子化されて添付できるような手軽さになったら電子申告してもよいかもしれない。
jib という java アプリケーション向けの docker イメージをビルドするためのツールがある。お仕事で使い始めたので雰囲気を理解するために私もサンプルアプリケーションを jib-sample として作ってみた。簡単に設定して java アプリケーションを docker 化できるので感触はよさそう。基本的に java アプリケーションと docker は相性が悪くて、たぶん go で開発するような用途と比較するとサイズがめちゃくちゃでかい。それでも jib を使うと作成された docker イメージのサイズも自分でビルドして作るよりは小さくしてくれる。さすが google という感じ。
この jib-sample の docker イメージを使って github actions のカスタム container action を作ってみたのが gh-actions-container-sample になる。Creating a Docker container action のドキュメントには Dockerfile を使ったサンプルしか紹介されていないけど、docker イメージを直接参照して利用することもできる。
検証作業をしているときに jib-sample リポジトリの github packages が private 設定になっていることに気付かなくて少しはまった。リポジトリの visibility 設定と github packages の visibility 設定は連動していないのでそれぞれで別に管理しないといけない。
また jib で作った docker イメージはデフォルトでは manifest を作ってくれない。
$ docker manifest inspect --verbose ghcr.io/t2y/jib-sample:latest
no such manifest: ghcr.io/t2y/jib-sample:latest
How do I specify a platform in the manifest list (or OCI index) of a base image? のドキュメントによると、manifest に platform 情報を追加するのは incubating feature らしくて、なんか条件付きで設定すれば使えそうにもみえたんだけど、私がやってみた感じだとうまくいかなかった。また必要ならもう一度調べてみる。
0時に寝て6時に起きた。
ここ1ヶ月ほどお仕事に集中しているのもあるけど、あまりストレッチに意識を割いていない。やるときは集中して注力するのだけど、飽きてくると怠ける性格的なところがある。とはいえ、やめずに続けているといいことがあると経験則からわかっているのでなるべく継続していきたい。今週も特別なことはなにもしていないのだけど、右足の股関節周りに張りがあってあまり調子がよくなかった。今日の開脚幅は開始前163cmで、ストレッチ後167cmで先週よりも数値が悪化している。良くなるときもあれば悪くなるときもある。毎週ストレッチを受けて計測しているとそういう気付きがあること自体、この機会は健康のために役立っているように考えている。
docker が流行りだした頃に勤めていた会社の貸与端末が docker 禁止だったので私は docker に乗り遅れて、これまでも誰かが用意してくれたコンテナを使うだけでよかったため、最低限の docker コマンドや docker-compose の使い方しか知らなかった。ちょうどインフラの運用を見直す過程で docker コンテナの作成方法から見直すお仕事ができたのでこの機にいろいろ勉強する。いまどき当たり前なんだろうけど、docker の マルチステージビルド をやってみる。
最初に go のバイナリを選択したのは間違いだったのかもしれない。go のビルド環境を作るベースイメージの選択が難しくて、ビルドはできるけど、作成したバイナリが動かないという状況にはまった。ECSのタスク起動時に「standard_init_linux.go」関連のエラーが出た場合の対処方法 であるように、いろんな不具合がある。ベースイメージの選択やビルドに必要なライブラリがないとそういうエラーになるんだと気付くまでに時間がかかった。
最終的に次のような Dockerfile でマルチステージビルドができた。builder としてのベースイメージの選択によってやり方はいろいろ変わってくるように思える。
FROM golang:alpine as builder
RUN apk add --no-cache git make gcc musl-dev
WORKDIR /work
COPY . .
RUN go mod download
RUN make build
FROM alpine:latest
WORKDIR /
COPY --from=builder /work/bin/sql-executor .
CMD [ "/sql-executor" ]
Dockerfile ができたら Publishing Docker images を読みながら github actions で自動的に docker イメージを github packages に公開する設定をやってみた。リリースを作成したときに docker イメージをビルドして公開する workflow yml を作成した。ほとんどドキュメントのまま。
github actions の実行結果。
github packages 上で公開された docker イメージ。
リリースのタイミングじゃなくてコミットのタイミングでも docker イメージを生成できると思うけど、docker イメージのタグに相当するものをどう付けるかというところは工夫する必要がありそう。
23時に寝て1時半に起きてそのまま断続的に寝て起きての繰り返しで6時に起きた。本当は非稼働日だけど、昨日作った pr の機能を検証するための環境を用意してもらったのでそれを動かしたら要件漏れに気付いてその改修をやってた。
顧問のはらさんと隔週の打ち合わせの日。今日の議題は2つ。
先日、見積もりについての 私の考え を整理した。それについて第3者の意見も聞いてみたいと考えた。
いろいろ雑談したけど、結論としてはバーンダウンチャートもストーリーポイントも運用が形骸化したら役に立たないという当たり前の話しになった。従来の期限や工数を見積もる方法と比較して得られるメリットはそう多くないという私の印象である。ストーリーポイントが優れている唯一の点は、タスクの見積もりについて話し合う場ができるという、その機会そのものがあげられる。その機会を使ってメンバーとの情報共有や教育の場にもできるという点がある。それ以外のところでストーリーポイントのメリットはさしてないと私は感じた。
ストーリーポイント(以下SP)について雑談していて、あるチームでは事前に見積もったSPをタスク完了後に実績ベースで上書きする運用をしていたという。その理由は見積もったSPに対して進捗や実績が悪いと偉い人からお叱りを受けるため、SPが正しくなかったという解釈で実績から変更しているという。
— Tetsuya Morimoto (@t2y) February 18, 2022
ざっくり試算すると来期は少し赤字になる。経営者として赤字にならないようの対策を講じる。私が予め用意した施策は次の3つ。
はらさんから役員報酬を下げてはどうか？という提案もあったけど、これは却下しようと思う。もともと役員報酬は高くないし、役員報酬を下げると必然的に健康保険や社会保険の再計算やそれらに関連する事務手続きが発生する。いま私は会計士も税理士も雇わず自分ですべてやっているのだけど、専門家に依頼するにしろ、自分でやるにしろ、経費を下げるために別の経費を発生させてしまう。これは本末転倒な気がしてやりたくない。
したがって、お仕事の単価をあげる交渉からまず始めることにする。私はずっと開発者で働いてきたから交渉ごとはほとんど経験がない。交渉の経験を積むという側面でも自分のキャリアにとって新しい取り組みになってよいと考えている。次の契約更新は3月末になるのでそれまでに交渉のための準備を進めていく。