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

EKS クラスターのノードグループと k8s の nodeSelector

先日 k8s の nodeSelector の調査について書いた。いまテスト環境でその調査結果の運用検証中。当初は k8s の機能だけを使いたいと考えていたが、いま eksctl コマンドで EKS クラスターを管理していて、k8s ノードの実体である ec2 のプロビジョニングはノードグループがもつ起動テンプレートとオートスケールポリシーにより制御される。そのため、ノードグループを分割してそれぞれにノードラベルが必ず付与されるように管理する方が簡単だとわかってきた。要はアプリケーションサーバー向けのノードグループとバッチ処理向けのノードグループの2つを作った。あと覚えておくとよいのが、Adding a custom instance role で任意のポリシーもノードグループの iam ロールに追加できる。設定例としてはこんな感じ。

  iam:
    attachPolicyARNs:
    - arn:aws:iam::${accountId}:policy/my-custom-policy
    - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
    - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
    - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
    - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

ノードグループの準備が整ったら nodeSelector を指定した pod をデプロイするだけ。k8s ノードがどんなノードラベルをもっているかは次のようにして確認できる。

$ kubectl get node --show-labels

意図したノードラベルが付与された k8s ノードに pod がデプロイされたかどうかは次のようにして確認できる。

$ kubectl get pod --output wide --field-selector spec.nodeName=${ノードラベルをもつノード名}

これらの環境構築、検証、wiki にドキュメントを書いて本番作業手順もまとめた。一通りきれいにまとまったインフラ作業を完遂できて気分がよい。

1時に寝て7時に起きた。

2つ目のサービスイン

スプリントの最終日が今日になる。しかし、今日はサービスインの作業でバタバタしているので主要な開発者は運用サポートしたり、PO もシステムの切り替え対応で fix したタスクの検証ができないといった理由でこれ以上タスクを進捗できそうにないことを容易に想像できた。スプリントゴールに掲げたタスクのうち、9項目中2つしか完了してないという状況だった。ちょうど夕方にスクラムのふりかえりもあったので、今回のスプリントは一体何なの？みたいな懸念から始まって、やる必要があるのかないのか曖昧な優先度設定はよくないという意見が出ていた。サービスインする週にスプリントをやるのもおかしいというのは前回も私はコメントしていたんだけど、今回も全く同じことが話題に出ていて、過去の失敗から学ばないチームになってた。

個人的に、開発のマネジメントにおいて、できもしない (やる気もない) 納期を設定するのが嫌い。私が古い人間なのかもしれないけど、納期が設定されてそれが大事なんだと認識したらどんな手段を使っても納期に間に合わせようとする。例えば、泊まりがけで開発したり、深夜早朝・休日に開発したり、大事なんだったら間に合わせる。しかし、労力を払って間に合わせたものの、他のメンバーやタスクはそうじゃなかったりして、遅れても何も起きないとがんばってやった人がしんどかっただけで終わる。過去にそういう状況を何度も経験してきてやる気をなくすことが多かった。

もてなしだけではもう食えない

第6章 営業予算の使い方

米国帰りのマーケッターという新たな登場人物。学部から米国の大学に留学すると米国史を英語で学ぶのが大変みたいな余談が出てくる。日本史は2000年を長く薄く勉強するが、米国史は200年しかないから内容が濃いのと最近の話だから史料も多く細かい史実を学ぶ必要があるという。全然、本題じゃないけど、歴史好きの私としてはおやと思えて楽しめた。いくら敏腕なマーケッターでも業務知識がないと空回りしてしまう。マーケティングの精度をあげるために必要ならば、その教育コストもマーケティング予算から捻出すべきだといった話しも出てくる。普段、会計システムに勘定科目を調べながら経費を入力している私にとってはなるほどなぁと、またまた本題ではないところで感心してしまった。

統計学のp値が5%以下ということは95%の確率でそのデータ上の差が実際に起き得る確率を表す。統計学は大事だとか、エクセルを駆使してデータ処理しろとか、そういう話題も出てくる。あとは古典的なマーケティングの手法として AIDMA モデルが紹介されている。基本的な考え方として知っておいたら役に立つときもあるかもしれない。

1. Attention (注目)
2. Interest (興味)
3. Desire (欲求)
4. Memory (記憶)
5. Action (行動)

例えば、Attention は情報誌に広告を出してみてもらうようなフェーズを指す。みてもらったら Interest に移る。口コミの内容で興味をもってもらうとか。興味をもってもらったら Desire として実際のサービスを体験してもらったりしてより強い欲求をもってもらう。一般論として Desire から Action へは間があくこともある。記憶させておいてそれを呼び戻すためのフェーズが Memory になる。最後の Action で成約を得て収益になるといった一連の流れを指す。

23時に寝て9時に起きた。昨日の疲労でよく眠れなくてバテてた。午後から会社の雑務をしていた。

もてなしだけではもう食えない

少しずつ読んでいく と書いてから3ヶ月読んでなかった。ホテルに限らず、ビジネス一般論としても通じるところが多かったように思う。経営の一般論とでも言うべきか。

第3章 お客さまは神様とは限らない

• ビジネスの世界は大学のケーススタディみたいに物事がきれいに整理されているわけじゃない
• 顧客満足度とは本来、企業収益と正の相関関係があるはず
  • 正の相関関係とはAが1増えたらBが1増える
  • 相関係数は-1から1まで
  • 1だと正の相関係数が最大で、0だと無関係、-1だとBが1減る
• 顧客のロイヤリティとは、再訪するか、他者に推薦するか、商品やサービスに対する信頼や共感を指す
  • ロイヤリティには2つの意味があって、これはマーケティングの分野で使われる意味
• 従業員満足度の向上が対外サービスレベルを上げ、それが顧客満足度を上げ、結果としてオーナー満足度を上げる
• 放置できる不満は放置される、経営学的にみて正しい行い

主人公は学生時代の成績が悪かったことから分からないと言えることが強みという説明文が出てきて、教授の説明が理解できないときにどんどん質問して丁寧に説明してもらうというやり取りになっている。この言葉を引き出すために主人公は仕事ができない人設定にしているのかとも考えられる。異世界モノにしてしまえば、こんな説明はいらないなとか読んでて思った。

第4章 「立ち入り禁止」の向こう側

会計は用途によって会計基準が異なる。

• 財務会計: 損益計算書や賃借対照表といった財務諸表に集約される
• 管理会計: 経営者が経営状況を把握するための会計書類作成の基準となる
  • 部門別損益やセグメント別の分析などをする
  • 会社ごとにばらばらでもよい
  • 経営者が知りたい情報が指標になっていればよい

ユニフォームシステムという部門別損益を計算するホテル業界の標準的な会計基準について紹介されていた。米国発祥なので日本での普及率は低いらしい。この話題の中でマネージャーの業績考課やボーナス査定の話しが出てくる。そして、マネージャーのコントロール外の非配賦費用を部門別会計に含めないのはマネージャーの実績を測れないからだと説明されている。つまり、ユニフォームシステムという管理会計の仕組みと人事システムはセットでないと業績改善効果が薄いという話しにつながる。人事というのは本当に難しいことが伺える説明だと思えた。

管理会計によって部門別の損益の悪いところが明らかとなり、そこに対する改善案が進みそうなストーリー展開になってきた。小説風なのでストーリーが進むと、その先の展開も楽しみになってくる。

第5章 数字を分解せよ

投資計画に対して懐疑的になる背景としてフィージビリティスタディの話題が出てくる。私は言葉を知らなかったので勉強になった。ここではセグメント別に分割して大雑把な小さい数字を推定していくことから始め、その数字の裏付けをより精度の高い手法で行うことで現実的な企画ができるみたいな組み立てになっていた。

• 投資がどのぐらいの経済効果をもたらすのかを予測することをフィージビリティスタディ (feasibility study) と呼ぶ
  • 日本語では事業化可能性調査、または採算性調査と呼ばれたりもする
  • 収益と投資額の2つの情報から利回りが何%かがわかる
  • できるだけ数字を分割して考えるのが基本
    • フェルミ推定を使って大雑把な数字から算出するやり方もある
  • 投資によって「追加的な売上」ではなく「追加的な粗利益」を測るべき
• RFP (Request For Proposal): 提案提出依頼書を作る
  • 専門家へ依頼するときにコンセプトデザインを明確にする
  • コンセプトを専門家に正しく伝えないと適切な提案を受けられない
• 自分の会社のリソースを確認し、その比較優位に従って企画を立てるのがマーケティングの王道の考え方

主人公からなぜ横文字を多く使うのか？という質問に対して、コンサルタントの教授が答える。まだ定着していない概念を的確に表すには英語のまま使っておいた方がよいという説明が出てくる。私もこのことは全く同意で、もっと言うとカタカナにせずにアルファベットのまま英語で使うとよいと考えている。本題ではないけど、大型連休はプロジェクトの進捗に影響を及ぼすので考慮にしとけよというやり取りが急に出てきてリアリティがある。私がいま手伝っているプロジェクトは GW の休暇を考慮せずにロードマップを策定していて、私が2回ぐらい指摘してあるとき修正されたことがあった。

1時に寝て5時に半に起きた。朝から夕方まで田んぼの草刈りをしていた。

草刈り

タイトルに1年と書いたけど、厳密には1年も経っていない。2021年10月以来の草刈り になる。本当は小まめに田んぼの手入れをしていれば、草場になんかならない。

6時から草刈り機を使って草刈りを開始。もう1時間早く起きて5時から始めたらよかったと思った。夏は10時まわると暑さが厳しくなるので作業は10時までに終わらせるのがよさそう。今回は6時から11時前まで草刈りをやって6割程度を刈り込んだ。草刈り機は2サイクルエンジンなので混合ガソリンを燃料に使う。ちょうど燃料切れになったのと同じタイミングだったので午前中の作業を終えた。11時の時点での田んぼの状況。

昼間は暑いので長くお昼休憩をとって14時から再開。本当はもう少し遅くてもよいけど、私が神戸に戻らないといけないから少し早めに始めた。まだ7月だったせいか、14時でも想像よりは暑くなくそれでよかったとも言える。午後から母がパートから戻ってきたのもあり、交代して休みを取りながら草刈りをして16時にはほぼ完了できた。この後、少し残っているところを母にやってもらって私は17時の高速バスで神戸に戻ってきた。

この時期の草刈りは、草刈り機を使うことそのものの疲労に加えて暑さでバテる。2人いて交代で草刈りすると、休んでいる時間を有効活用できて効率がよいことに気付いた。草刈り機のエンジンの回転数も全開にするよりも、少し弱めた方が振動量が減って、腕の負担も燃料消費も少なくなってよいことに気付いた。いままで全開で刈った方が早く刈れるのではないかと考えていたが、それは誤りだった。疲労度を下げて草刈り機を扱った方が休まずに長時間作業できる分、全体として作業を速くできることに気付いた。

この後、草を干して乾燥したら焼いて、トラクターで田んぼを耕す。それは9月の連休にする予定。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。あちこち筋肉痛やら腰が痛いやらでストレッチできるような状態でもなかった。ストレッチへ行ったときは暑さにやられて頭痛がひどかったんだけど、ストレッチしているうちに徐々によくなってましになった。暑さで頭痛がするのは血行が悪くなるからだそうだけど、ストレッチして血行がよくなるんだと推測する。腰の張りがひどくてストレッチしてもらって少し楽になった。田んぼ仕事の後にストレッチを受けられるのは疲労回復のためによかったと思う。

1時に寝て7時に起きた。実家に帰ってお見舞い行ったり親戚訪問したりしてた。

お見舞い

午後から父のお見舞い。少し前まで直接面会できるようになっていた時期があったそうだけど、またコロナの感染状況が悪化したため、リモート面会に戻ったらしい。面会時間は20分。たまたま父はお風呂上がりの時間だったらしくてそれで疲れたのか、10分ほどしてそのまま眠ってしまった。もともと父は気管切開していて話せないので起きていても寝ていても面会でやることは変わらない。顔色がよいことは確認できたという感じ。

博士ちゃん

たまたま実家に帰っていたからテレビをみていたらおもしろかった。生物の標本や骨に関心のある小学6年生が、国立科学博物館の収蔵庫を見学するといった番組だった。著名な研究者の方々が案内しながら子どもに研究のおもしろさを知ってもらうような作りになっていたように思う。出演していた12歳の子どもが本当によく勉強していて詳しくて、この分野の研究が本当に好きなんだなという想いがみてとれてよかった。好きなことを突き詰めてやっているのをみると楽しくなる。

• 約480万点の資料が収められた 国立科学博物館の巨大収蔵庫潜入 完全版！

1時に寝て7時に起きた。

煩雑な検証

昨日の続き。午前中に pr を作成してレビューしてもらってマージしてデプロイして検証した。いくつか既存の設計には課題があると思いつつ、工数かけて直してくれという依頼は来ないのもわかっていて、煩雑なコードに煩雑な検証をやるだけにとどめた。テスト環境での検証自体は成功したので問題はなさそう。一部、本番環境でないと検証できないらしい。

会社のテックブログ談義

最高のテックブログを書くために気をつけている3つのこと というブログ記事をみかけた。内容はとても素晴らしいと思う。一方で会社のテックブログでこんな品質を求められたら、品質を満たせない執筆者のモチベーションを阻害しないかということがやや気になった。そんなもやもやを、こみやさんとまさひとさんに共有したらテックブログ談義が始まっておもしろかったのでまとめておく。会社のテックブログと言えばクラスメソッドさんが有名なので引用する。

もちろん弊社では、ブログを書くことを業務上の成果としても評価していますので、このブログを書くこと自体が評価につながるモチベーションになっています。

…

どのように評価をしているかと言うと、1つは本数という指標です。弊社では月4本エンジニアがブログを書くことを推奨しています。これは罰則はないので、書けていないからといって減点をすることはありません。逆に書いてるからといって加点をすることもありませんが、月4本を推奨していますし、10本書く人は高評価ということで「ブログのプロ」と呼ばれることがあります（笑）。その月は「10本書いたからプロになったね」というようなことを社内で言われたりします。

…

業務上の評価ということで、先ほど「減点・加点しないよ」というお話をしたんですが、3ヶ月に1回、ブログの本数とSNSのシェア数とビュー数が多い人に対して表彰をしています。やはり継続的にアウトプットをしているとこういった場面で表彰される機会も増えるので、社内でも「この人はたくさんブログを書いてるんだ」「この人はすごく高いスキルを持ってるんだ」と認められ、評価にもつながります。もちろん上司からも、技術ブログを書いてアウトプットが多いことが高い信頼につながります。

なぜ技術ブログを書きまくるのか？　『Developers.IO』のクラスメソッドが伝える、エンジニアの成長サイクル

みよ！この評価しているのか、していないのか、はっきりしない曖昧な制度設計を！

「テックブログは開発者がやるべき業務とみなしていますか？」と尋ねると、多くの会社では業務時間に書いてもよいけど必須でもノルマでもないみたいな答えが返ってくるのではないだろうか。業務に含めたくないのは、本質的に優先度の低い業務だという事実と、一定以上のコストをかけてまでテックブログに価値があると会社も考えていないのではないかと思う。業務とは言い難いので区別のためにここではテックブログを書くという 活動 と呼ぼう。

そして、個人のモチベーションに期待した活動を安易に評価の対象にするのは想像以上に厄介な制度設計になる。メタ認知で〈学ぶ力〉を高める：認知心理学が解き明かす効果的学習法 を読んで私は理解できたことなんだけど、おそらくクラスメソッドさんの (曖昧にみえる) 制度設計の裏には認知心理学の知見がある。

• 外発的動機づけ: 金銭や物品などの物的報酬、よい評価を得るといった社会的報酬など
• 内発的動機づけ: 自分がそれをしたいからする、知的好奇心など

外発的動機づけは内発的動機づけと比べてずっと弱い動機づけであることがわかっている。ここで外発的動機づけの業務から始めて内発的動機づけの活動に変わっていくこと自体は問題ない。スクラムで言及している自己組織化や自律的な行動というのは内発動機づけによる活動に変わっていくことを期待している。会社の制度設計として難しいのはこの逆はよくないという話しがある。内発動機づけで行動していた活動を外発的動機づけに置き換えてしまうことだ。テックブログのような、本人が自己学習やアウトプットを目的に自律的にやっていた活動に、安易に金銭的な報酬を与えてしまうと、お金のためにやっている業務に置き換わってしまってやる気をなくしてしまうという懸念がある。余談だが、褒めることそのものは副作用のない安全な報酬と認知心理学の研究からわかっているらしい。クラスメソッドさんが表彰という制度設計にしているのは、本人のやる気をなくしてしまわない報酬を考慮しているからかもしれない。

またコンテンツの所有権という側面からテックブログは会社のものだから、自身のブランディング戦略とは相性がよくない。これは 限定合理性 の話しとも関係してくる。開発者に限らないが、転職を当たり前にする時代で個人ブログに記事を書く方が開発者にとってのメリットがある。「会社ブログに書く動機はなにか？」は、人それぞれの理由があるだろうけれど、その理由が明確でないと消極的に会社ブログは書かないという帰結になるのではないか。私の経験則においても、会社のテックブログを書く開発者は圧倒的に少数である。私は過去に会社のテックブログを書いてきたモチベーションは単純にアウトプットすることで自身の勉強になるなら書く場所はどこでもよいという考えがあった。補足としては、会社の利益 (採用) に貢献しようとか、会社のテックブログを書く開発者が少ないという希少性に着目して自身をアピールするとか、そういった考えもあったと思う。

若い開発者にアウトプットする習慣を付けてもらう取っ掛かりとしてテックブログはよいのではないかという話題も出た。開発者のスキルアップのために会社がどこまでコストをかけてサポートするかという話題でもある。その延長上に評価制度もあるなぁと voyage さんの技術力評価会の資料もみてたりした。会社のイベントや業務を通じて、自然とアウトプットに関するスキルが身に付いて行動できるようになるなら本人のキャリアにとってもよいことではある。私は 書く という行為は開発文化から影響を受ける側面が強いと考えていたけど、voyage さんの制度はその下地を組織として支えていく仕組みになっているのかもしれない。

• 5分でわかる技術力評価会

1時に寝て7時に起きた。久しぶりに HELLSING をみてた。アレクサンド・アンデルセンの狂信者ノリが好き。

煩雑な保守

昨日から着手した s3 とやり取りするアプリケーションの保守をしている。一通り機能は実装できたが、このアプリケーションの保守を今後どうやっていけばいいのかが私からはみえない。要件が変わる度に継ぎ接ぎで拡張してきて、意図をもった設計があるわけではないようにみえる。このまま保守することはできるかもしれないが、このロジックの説明もテストも検証もすべてが難しい。私がみても難しいのだから、経験の浅い開発者がみるともっと難しいのではないかと思う。

これを直すにはまず単体テストを直さないといけない。単体テストの大半がモックベースなので実際の振る舞いと異なる可能性がある。とくに s3 とやり取りするところの検証ができない。testcontainers の localstack があるので単体テストはモックからこのモジュールを使うように代替できそう。まずはそこからやるべきだが、2-3日はかかると見込まれるのでチームで承認を得られるかどうか、ちょっと聞いてみてから考える。

Job Summary を使ってみた

ちょっと前に github actions のワークフローの実行画面にサマリを出力できるようになったという記事をみた。

• Supercharging GitHub Actions with Job Summaries

自動でよさげなサマリを出力してくれるわけではなく、自分でサマリを作らないといけないので面倒だなと思ってそのまま放置していた。先週末に モジュール別のビルド・デプロイのワークフロー改善 を行った。ふとワークフローの実行結果をみていて、選択したモジュール名が表示されているとわかりやすくていいなと思えた。それを出力する手段としてサマリがちょうどいいやということに気付いた。inputs などで動的に変更するパラメーターをワークフローの実行画面で確認できるといちいちログ確認する手間が省けてよいという場面が他の用途でもある気がしてきた。もっと積極的にサマリを使っていこうと思えた瞬間だった。

1時に寝て5時半に起きて7時に起きた。夏バテなのか朝起きれなくなってきた。

localstack 入門

s3 とやり取りするアプリケーションの保守を手伝うことになった。いま開発環境向けに minio を使っていて、そのためだけにトリッキーな DI を実装している。そのコードがトリッキーなだけに知らない人がコードをコピペしてトラブルを起こす火種になってた。minio 使う必要性はまったくなく localstack を使えば解決できるのを、誰もその保守してなくて、仕方ないからこの機に私がやることにした。すぐにできるやろと思ったら意外にはまって2-3時間デバッグに時間を取られたので書いておく。

簡潔に言うと、(おそらく歴史的経緯で) minio は基本的に path style で s3 api を扱う。virtual hosted style でリクエストするとアクセスできなくてどうやって解決するのかが分からなかった。ググって出てきたどこかの開発者の言っている通りで path style は deprecated していて、aws も削除するとまで宣言していて、いつなくなるかもわからないのに未だにそれがデフォルトというのはどうなの？っていうお気持ちを表明している。

Beware accessing @_localstack using an AWS S3 client configured with virtual hosted style access: GET my-bucket.localhost:4566/prefix/my-object.txt wrongly 404 errors, but a path-style GET localhost:4566 /my-bucket/prefix/my-object.txt succeeds!

— James Shaw (@hertzsprrrung) October 27, 2020

私も同意見で issue をよくよく調べてみると次のエンドポイントに対しては virtual hosted style でアクセスできた。localhost に対しては path style で動いていて、virutual hosted style は localhost.localstack.cloud という、よくわからんドメインを使わないといけない。ドキュメントには書いてなくてググって辿り着く issue のコメントをみてたら気付いた。

• Support for s3 bucket subdomains #2631

mybuket.localhost.localstack.cloud 

aws-sdk-java v1 のコード例だと次のようになる。バケット名は実際にリクエストするときのパラメーターから s3 client がセットしてくれるのでこんな感じ。

var endpoint = new AwsClientBuilder.EndpointConfiguration("localhost.localstack.cloud:4566", "ap-northeast-1");
var client = AmazonS3ClientBuilder.standard()
        .withEndpointConfiguration(endpoint)
        .build();
return client;

こんな初期設定でつまづくと、このライブラリを使うのをやめようかという気持ちになる。ちゃんとドキュメントに書いておいてほしい。

窓付きオフィスの空きをみつけた

エリンサーブさんの内覧 に行ってきてから縁があればという感じでオフィス引っ越しは待ち状態になっていた。いま契約しているところの別オフィスで 神戸旧居留地 のサイトを、たまたま今日みたら窓付きの部屋が空き予定だと書いてあった。

7F-07 7月末空き予定 ￥69,300 ￥6,600 2名 6.22㎡ 完全個室/窓付き/棚付き

家賃はいまより 31,900 円増える。年間にすると 382,800 円のコスト増になる。高くはないけど、いまの環境でもう少し続けたら？と言われたらそれでもいっかと思えるぐらいのコスト感。優先度は高くないが、縁があるなら見逃す手もないといったスタンスで臨む。ひとまず明日、電話してまだ空いているなら内覧できるかを聞いてみるところから始める。内覧してよさそうな場所だったら引っ越しを検討する。7月末って急な話だけど、小さいオフィスなので本気出せば レントラ便 で2時間もあれば引っ越しできるはず。荷造りの準備に1時間、搬送に1時間といったところかな。

0時に寝て8時に起きた。起きたら豪雨だった。梅雨明けが早かったから水不足の土地には恵みの雨だなとか思った。

「緊急対応」という種別

先週のリリースに際して発生した問題に「リリース時緊急対応」という種別が設けられた。当時、私はその種別を設けることそのものに否定的なコメントを発したのだけど、誰かがすでにその種別を作ってしまっていて、いくつかのチケットに設定されていたので成り行きで使うことになった。そして、もうリリースしてから1週間も経つのに未だに「緊急対応」というチケットがいくつも作られている。1週間も運用しているのに緊急もへったくれもないだろうと指摘して、明日から新しいスプリントが始めるので「緊急対応」という種別を付けるのはやめようと提案した。一般的な課題管理システムは緊急度と重要度の2つをもっているけど、backlog は優先度しかない。それでも優先度があるのだからそれを設定すればいいだけなのに優先度を使った運用をしていないのと、課題一覧をフィルターするのではなく、大半のメンバーがカンバンしか使えないといったスキル不足もあって、なくてもよい無駄な種別をまた増やしてしまった。

カンバンはシンプルな要件に使うならよいけど、一定以上の複雑さをもつ普通の会社の開発プロジェクトに使えるようなキャパシティをもっていない。それなら最初から使わない方がよいのではないかと考えるようになってきた。というのは、非開発者にとってカンバンは簡単に使い始められる分、そこからさらに高度な検索フィルターを使いこなすスキルアップを阻んでしまう。複雑な要件をカンバンで実現しようと考えてしまってバッドノウハウ的なアプローチをしていく。その典型例が「緊急対応」という種別作ればいいやんみたいな考え方。

クレジットカードの有効期限の更新

前に yj カードが paypay カードに置き換わったときに有効期限が更新されてクレジットカードの設定更新が必要になると書いてあった気がする。4月8日に paypay カードが届いたみたい。クレジットカードの引き落としタイミングのせいか、しばらくは有効期限が異なっていても paypay カード側で決済を許可していたのか、いずれにしても最近あちこちでクレジットカードの引き落としに失敗するという通知がくるようになった。気付いたら、クレジットカードによる セカンドハーベスト・ジャパン さんの寄付の引き落としも止まっていた。通常、有効期限前にクレジットカードが更新されることはないからサービス側で有効期限が近づいてきたときに更新依頼通知を送っているのだと推測する。寄付みたいなところは引き落とし失敗になると督促しないのかもしれない。もう1つ 国境なき医師団 さんにも寄付しているが、こっちは銀行口座からの引き落としだった。クレジットカードと銀行口座の違いとして有効期限の有無が違う。どちらもメリット・デメリットがあるからずっと払い続けるつもりなら銀行口座、自分が死んだ後にいずれ停止してほしいならクレジットカードを使った方がよいといった考え方もできると気付いた。

4時に寝て8時に起きた。久しぶりに寝坊した。

k8s の nodeSelector

先日 定期/バッチ処理を k8s の cronjob にすべて移行 した。すでに本番運用もしていて調子もよさそうにみえる。あと残課題としてバッチ処理とアプリケーションサーバーの pod がデプロイされる k8s ノードを分割したい。現時点では、バッチ処理の負荷は小さいから同じスペックのインスタンスの k8s ノード上で混在させて運用している。しかし、いずれ運用上の問題になる懸念がある。そのため、バッチ処理のみを実行する k8s ノードを管理したい。次のドキュメントに書いてある。

• Assigning Pods to Nodes

k8s のドキュメントによると、大きく分けて nodeSelector と Affinity という2つのやり方がある。前者はラベルでフィルターするシンプルな仕組み、後者はさらに複雑な要件に対応するもの。いまのところ、ただ分割できればよいのでシンプルな nodeSelector で実装してみることにした。

• nodeSelector
• Affinity and anti-affinity

余談だが、nodeSelector はいずれ Affinity に置き換わるので deprecated だと一時期ドキュメントに書かれていたらしい。具体的に決まっていることでもないため、nodeSelector: when will it be deprecated? #82184 によると deprecated という文言を含む文章がその後に削除された。Affinity は高機能且つ高コストであることから、(現時点では) nodeSelector はシンプルで推奨すべき方法とまで書いてあるのですぐになくなるわけではなさそう。

minikube で nodeSelector の検証を始めたんだけど、いくつかうまくいかないことがあって断念した。multi-node 機能を使って controll plane と worker ノードの2つを起動できたけど、worker ノードから docker host にアクセスできなかった。何かしら設定が必要なのか、別途レジストリが必要になるのかよくわからなかった。あと node にラベル設定したときに worker ノードにラベル設定しても minikube を再起動するとそのラベルが消えてしまっていて保持されないようだった。ちょっと調べてローカルの環境を作るのが面倒になったので早々に断念した。

• Using Multi-Node Clusters

1時に寝て7時に起きた。寝ていて夜中に吐き気して眠れなくて上体を起こすしかなかった。たまにある 胃食道逆流症 のひどいやつ。

参議院選挙

普段は期日前投票で済ませるのだけど、今週は他のことに注意を取られていたせいか、当日行ってきた。場所が期日前と違ったので勝手がわからなかったけど、とくに混雑もしてなかったのですぐに完了できた。タイムラインを眺めると、私のタイムライン上では投票したと発言する人が増えてきたように思う。投票率が50%程度で半分ぐらいの人が投票していない状況に懸念をもつ人たちの可視化がされている。

ふと父の選挙はどうなるんだろう？と思って検索してみた。意思表示できない状態だと選挙はできないみたい。

選挙人本人が投票所に行き自らの意思で投票することが原則であることから、意思表示が困難である場合には投票することはできません。これは投票所の係員が選挙人の投票を補助する代理投票においても同様です。したがって、家族の方が本人に代わって投票することはできません。

神戸市 FAQ > 市政情報 > 選挙

70歳以上は傷病で選挙権を行使できない人たちもいるだろうから減るのかな？と、総務省の 年代別投票率 のグラフを確認してみた。直近だと、70歳以上が61.96, 60歳代が71.43、50歳代が62.96だった。60歳代と比べて減ってはいるけど、50歳代とそう変わらないのをみると、元気な人たちに選挙へ行こうと呼びかけるのは正しい気がした。

backlog-github-integration-action のバグ修正

運用してすぐにコミットメッセージ中にシングルクォートやダブルクォートが含まれると引数を正しくパースできなくてエラーになることがわかっていた。いま運用している環境の用途だと、それほど重要ではないので後回しにしているうちに面倒になって放置していた。晩ご飯を食べてからデバッグしていたら7時間ぐらいやってた。

• push subcommand is failed when a commit message includes single quote or double quote #6

bash 上の文字列の扱いと action.yml の inputs の args に引数渡しするときの振る舞いの勘違いもあって、issue の見た目以上に複雑な振る舞いをしていることがわかった。github actions 上のコンテキストに依存したくなかったため、github.event.commits の json をそのまま cli パラメーターとして渡している。bash 上の json 文字列と cli パラメーターとしての扱いが煩雑になるのでこのやり方は失敗だったかもしれない。ローカルでのテストもやりにくい。私はそのことをよく理解していたはずなのに github actoins 上のアンチパターンにはまってしまった。カスタムアクションのユーザーが簡単に使えるように cli パラメーターの設定を簡単にする意図で json 渡しにしたんだけど、エスケープの振る舞いが想像以上にややこしくなって、エスケープしたいユーザーには簡単ではなくなってしまった。それでもデバッグをがんばったおかげでシングルクォートは完全に使えるように実装できた。ダブルクォートは制限付きでエラーにならなくできるが、事実上は使わないでくださいといった仕様制限にしてしまおうと思う。引用するときはダブルクォートじゃなくてシングルクォートを使ってくださいと啓蒙することに決めた。