カンバンの弊害

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

「緊急対応」という種別

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

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

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

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

nodeSelector を試す

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

k8s の nodeSelector

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

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 を再起動するとそのラベルが消えてしまっていて保持されないようだった。ちょっと調べてローカルの環境を作るのが面倒になったので早々に断念した。

放置していたバグを直した

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

参議院選挙

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

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

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

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

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

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

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

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

github actions の push イベントワークフロー改善

23時に寝て6時に起きた。今週はサービスインで凸凹していて疲れた。

ストレッチ

今日の開脚幅は開始前161cmで、ストレッチ後164cmだった。ちょっと数値がよくなった。一昨日の日本酒イベントで4時間ほど立ち呑みをしていた疲労で腰に張りが少しあった。それ以外はとくに問題はなくて調子がよかった。右股関節の詰まりも2-3週間前よりもよくなっている気がする。これはトレーナーさんも注意を払って詰まりを取り除くようにストレッチのメニューを組んでくれているのでその成果が徐々に出始めている気がする。以前よりも可動領域が広がってきている気がして安心感を得た。

github actions の push イベントワークフロー改善

午後からビルド・デプロイの最適化のために github actions のワークフローを改善作業をしていた。

今週はサービスインにより、本番環境への緊急リリースを何回もやっているのを傍からみていて、ビルド・デプロイが速くなればなるほど、その回数を増やせるし、修正後の検証に時間を多く割ける。あるリポジトリが7つのモジュールをまとめてビルド・デプロイしている。これはあるモジュールの微修正の反映には向かないので改善することにした。結果として最大で50%ぐらいのビルド時間の削減、モジュールに依っては、具体的には10分かかっていたものを4分台でビルドできるようにした。

ワークフロー改善のためのデバッグしている間はビルド・デプロイが出来なくなることから開発者が使っていない時間帯が望ましい。必然的にサービス休日出勤して github actions のワークフローを改善していた。デバッグと動作の検証も兼ねて午後から半日以上やっていたので休日にやったのは正解だと言えるだろう。

push イベントの github コンテキストの github.event.commits にコミット情報が入っていて、そこにコミットのリビジョンがある。例えば、次のようなオブジェクトで id がコミットのリビジョンに相当する。

[
  {
    "author": {
      "email": "...",
      "name": "...",
      "username": "t2y"
    },
    "committer": {
      "email": "...",
      "name": "...",
      "username": "t2y"
    },
    "distinct": true,
    "id": "f8df1f77ffec9ef234e7321b2e237b663256b01c",
    "message": "コミットログのメッセージ",
    "timestamp": "2022-07-08T12:32:33+09:00",
    "tree_id": "37b066734e58779c5d2c687d40b4cc43af177cb2",
    "url": "https://github.com/OWNER/REPO/commit/f8df1f77ffec9ef234e7321b2e237b663256b01c"
  },
  ...
]

このリビジョンを使って github rest api からファイル情報を取得できる。

$ gh api -H "Accept: application/vnd.github+json" /repos/OWNER/REPO/commits/f8df1f77ffec9ef234e7321b2e237b663256b01c

いろんなデータが返ってくるけど、ここでは変更したファイルのパスを知りたい。

{
  "sha": "...",
  "node_id": "...",
  "commit": {
    ...
  },
  ...
  "files": [
    {
      "sha": "...",
      "filename": "module1/path/to/src",
      ...
    },
    {
      "sha": "...",
      "filename": "module2/path/to/src",
      ...
    }
  ]
}

この filename のトップディレクトリがモジュール名と同じなのでここだけ取り出して、管理対象のモジュールかどうかを比較する。bash でも =~ をサブ文字列のマッチングができる。

$ targets=(mymodule1 mymodule2)
$ echo " ${targets[@]} "
 mymodule1 mymodule2 
$ [[ " ${targets[@]} " =~ " mymodule1 " ]] && echo "match"
match
$ [[ " ${targets[@]} " =~ " mymodule2 " ]] && echo "match"
match

さらにマッチしたモジュールを github actions の expressions で制御しやすいように json の array に変換する。

$ jq --compact-output --null-input '$ARGS.positional' --args -- ${targets[@]}
["mymodule1","mymodule2"]

これを step の outputs として格納する。

echo "::set-output name=modules::${json_array}"

例えば、後続の job で実行条件としてモジュールの有無を調べたいときは expressions を使って次のように記述できる。if 文は ${{ ... }} のブラケットを省略できるようだけど、ここだけ省略すると返って混乱するかなと思って私は記述するようにしている。その方が統合性があってコードが読みやすいように私は考えている。

  mymodule1-job:
    if: ${{ contains(fromJSON(needs.build.outputs.mymodule_target.modules), 'mymodule1') }}
    needs:
      - build

ちなみに workflow レベルの env は job の if 文には使えない。outputs を使って動的な値を扱うようにしている。どうも workflow レベルの env はいろいろ問題があるみたいでなかなか issue がクローズされないのをみると取り扱い注意なのかもしれない。

最終的なモジュールを判別するための step は次のようなものになった。

  build:
    outputs:
      mymodule_target: ${{ steps.mymodule-target.outputs.modules }}
    steps:
    - name: コミットログからビルド対象のモジュールを設定
      id: mymodule-target
      run: |
        declare -A modules
        target_modules=${{ env.TARGET_MODULES }}
        revisions=$(jq --raw-output '.[].id' <<< '${{ env.COMMITS }}')
        for revision in ${revisions}
        do
          names=$(gh api -H "${{ env.ACCEPT_HEADER }}" ${{ env.COMMITS_PATH }}/${revision} | jq --raw-output '.files[].filename' | cut -d"/" -f1 | sort -u)
          for name in $names
          do
            if [[ " ${target_modules[@]} " =~ " ${name} " ]]; then
              modules[${name}]=true
            fi
          done
        done
        targets=$(jq --compact-output --null-input '$ARGS.positional' --args -- "${!modules[@]}")
        echo "::set-output name=modules::${targets}"        
      env:
        TARGET_MODULES: |
          (
            'mymodule1'
            'mymodule2'
          )          
        ACCEPT_HEADER: "Accept: application/vnd.github+json"
        COMMITS_PATH: /repos/${{ github.repository }}/commits
        COMMITS: ${{ toJSON(github.event.commits) }}

処理も理屈も簡単なんだけど、実際の運用コードはもう少しだけ複雑なものの、デバッグは github actions を実行しないといけない。ちょっとした typo のために実は2時間ほどはまっていたのは内緒。シェルの配列や連想配列を使うと、記号が多くてわかりにくい。配列の閉じブラケットを忘れていたがために EOF のエラーが発生していた。閉じブラケットのミスだけにエラーが発生しているところと実際のコードがズレていて、それに気付くのに少しずつコードを足したり消したりしてデバッグするみたいな原始的なやり方で些細な typo を気付くのに時間がかかった。

xxx.sh: line 47: unexpected EOF while looking for matching `"'

ゾンビスクラムを教えてもらった

2時に寝て7時に起きた。今週はバテた。金曜日は非稼働日だけど、バタバタしているから普通に働いていた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今週はお手伝い先がサービスインでバタバタしていて議題の準備がほとんどできなかった。少し前に参加したアトラシアンさんのウェブセミナーのスライド資料が公開されたのでそれを眺めながら雑談していた。

jira の有料プランのサービスに jsm chat という halp の技術を活かした新機能が追加されたらしい。既存プランの延長上で使えるらしい。質疑応答のときに halp とは別プロダクトだと明確に回答していたので halp が今後どうなっていくのかの将来にはかなり懸念がある。チャットと課題管理システムの双方向連携という、slack や teams といったチャットサービスがよく使われるようになった昨今のビジネス事情にあわせたサービスと言えるだろう。

私も以前からその領域に課題意識をもっていたし、ベンチャーでは workstreams.ai も同様のサービスを提供している。満を持してというのか、(私にとっての) 課題管理システムのベースラインとなる jira にその機能が入ったことで競合製品も同様に機能拡張を提供していく気がする。1-2年後にはチャットと課題管理システムが双方向連携しているのが当たり前の開発スタイルになるのかもしれない。非開発者にとってはチケットを扱うよりも敷居が下がるのでそれは適切な世の中の変化だと私は考えている。

ゾンビスクラム

jsm chat と課題管理の話しをしているうちにスクラムの話題になった。Zombie Scrum Survival Guide という書籍があって形骸化したスクラムの特徴をまとめているらしい。ある記事で2021年から翻訳していると書いてあったので翻訳版が出版されたら読んでみようと思う。

ブログ記事の所感を読んだ感じだと、私がいま関わっているスクラムにも一部通じるところがあるなと思って関心がある。

うちのチームは1週間スプリントをもう1年近く続けているのだけど、これは検査が早い段階でできるというメリットがあるものの、開発のメリハリがないなぁとずっと思ってた。それはただ与えられたタスクを無理なくこなすだけというルーチンになってしまっているのと、昨今の労務管理を徹底する働き方改革?のせいか、残業・休出を一切やらない開発スタイルが開発者の自律性や意欲を削いでしまっているのではないかとも思う。もちろん「余白」があれば、業務時間内に好きなことをやったらよいと思うけれど、うちの場合は半分ぐらいのスプリントゴールが未達で、スプリントに達成できないタスクを盛り込むからスプリントゴール未達の状態で他のことをやるのが憚られる空気がある。もっとも好き勝手やっている私がそれを感じるのだから、若い開発者には相応のプレッシャーになっていると思う。結果として、指示されたタスク (プランニングで決めたこと) 以外のことはやらない雰囲気になってしまっている。試しに直近3ヶ月のスプリントバックログアイテムの種別のみで開発者のチケット登録した数をカウントすると次のようになった。

  • 私: 66件
  • 開発リーダー: 17件
  • 開発者1: 14件
  • 開発者2: 12件
  • 開発者3: 1件
  • 開発者4: 6件

これは課題管理システムに慣れていて、業務をタスク分解しながら作業していくというワークフローに私が最も習熟しているから、適度な粒度のチケットをいくつも作りながら作業をやっているという背景もある。しかし、いまやらなくてもいずれ必要なタスクも、業務をやりながら気付いたときに私は随時登録している。憚られる空気を感じている私が週4日労働で控えめにやっても3ヶ月でもこれだけの数が開く。要はゾンビスクラムだと開発者の自律性は期待できないという話し。

七夕と日本酒

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

障害対応の手伝い

昨日の続きで定期処理を k8s の cronjob へすべて移行した。その後、チケット整理したり、他メンバーの手がまわっていない作業を手伝ったりしてた。バッチ処理の在庫チェックの数字があわなくて「俺たちは雰囲気で在庫チェックをやっている」みたいな状況に陥っていた。とはいえ、サービスイン3日目でも致命的な運用の問題は発生していないということでこのリリースはもう完了したと断言してしまってもよいだろう。今後、数ヶ月かけてさらに他施設へのサービスインが続いていくわけだけど、見通しはみえてきた感じはする。まぁ大丈夫そう。

灘五郷酒所イベント

なにかのきっかけで クラウドファンディングの灘五郷酒所 をみつけた。地元の応援をしとくかと思って5,000円を支援した。いまみたら271人の支援者から1,472,900円の支援金が集まったみたい。その支援金のお礼イベントがあって、せっかくの機会なので行ってきた。5,000円ってちょっとよい居酒屋さんで使うぐらいの金額だけど、その場で飲める2,000円分の金券とお腹いっぱい食べられたビッフェ形式で十分に飲み食いできた。写真にある料理をもう1皿もらってきてお腹いっぱいになった。料理はなくなっても補充されていたので十分に用意されていた。支払った支援金を考慮すると十分に良心的なイベントだった。小耳に聞いた話だと80人ほど参加者がいたらしい。

飲んだお酒はこれら。あと竹酒と呼ばれる竹の筒に入れて主催者がついでまわっていたのを2杯ほど飲んだ。

  • 福寿 純米酒「御影郷」 (神戸酒心館)
  • 琥泉 純米吟醸おりがらみ無濾過生酒原酒 (泉酒造)
  • 黒松剣菱 (剣菱酒造)
  • 浜福鶴 生酛純米辛口 (小山本家酒造 灘浜福鶴蔵)

1人で行ったのでぼっちだったらどうしよう?みたいな不安もあったんだけど、たまたま隣り合わせた人が プライズ日本酒会 というコミュニティのメンバーで4人組で参加していた。その人たちと雑談してた。ご近所さんでとてもよい人たちだった。三ノ宮でお酒イベントをやっているそうで、また機会があればそちらにも参加してみようと思う。私は地元の人たちとのコネがほとんどない。今後会社のマーケティングをやっていく上でも地元の人たちともなにかしら繋がりをもてるとよいなとは考えている。お仕事がバタバタしてたから朝の時点では行くのをやめようかと考えていたけど、午後から落ち着いていたのもあって行ってよかった。

lambda から cronjob へ

0時に6時に起きた。今日は晴れたので自転車通勤。

優雅にドキュメントを書きながら障害対応

昨日は凸凹しながら乗り切ってサービスイン2日目。今日から外部システムとの連携なども絡んでくる。昨日の今日なんで何か起こるだろうと思いつつ、暇だったらドキュメント書くタスクがいくつも溜まっているのでそれを片付けるかと業務を始めた。私ぐらいの人間になると、いつ凸凹が発生してもよいように、この日のために取っておいたようなドキュメントタスクがいくつも溜まっている。午前中に私の出番はなく、優雅にドキュメントの1つを完成させた。

以前から定期実行やバッチ処理は lambda 関数をトリガーに作られていた。それらを serverless framework から cdk へ移行した んだけど、その後にバッチ処理を k8s の cronjob で実装した 。この cronjob が思いの外、うまくいって、私がフルスクラッチで cli を作っているのだから、私からみてさいきょうのばっちしょりの土台を実装している。定期実行もすべて cronjob でやればいいやんと気付いて、過去に lambda 関数 (cdk/python) で実装したものをすべて移行することに決めた。昨日の流れからわかるように過去に作成済みの一連の lambda 関数はまだ本番環境にデプロイされていない。m1 chip macbook 問題 で同僚のマシンからデプロイできないという不運もあったんだけど、もうデプロイしなくていいよ、すべて cronjob で置き換えるからと伝えて2つ移行した。あと半日もあれば完了できそうな見通し。

lambda 関数から cronjob への移行作業をしていると、本番環境でのバッチ処理の一部のロジックが誤っているとわかってそれを修正したり、当然のようにテスト環境のデータも誤っているので正しいかどうかは本番環境にデプロイするしかないみたいな凸凹した状況を横切りながら本日の作業を終えた。いくつか残課題は残っているものの、明日中には平常業務に戻れるぐらいの状況にはなりつつあるのかもしれない。サービスイン2日目を終えて致命的な問題は起こっていないようにみえる。ひとまずはよかったという感じ。

サービスインは突然に

1時に寝て6時に起きた。暑くてあまり眠れない。今朝も雨降りで徒歩通勤。

cdk の ECS サービスに紐づくセキュリティグループの設定

明日がサービスイン初日だと思っていたら、私の勘違いで今日だった。私が直近でやっている作業はアプリケーションの直接的な機能ではなく、インフラやバッチ処理などの間接的な機能を作っているわけだけど、それでも1日調整を間違えていて、あれーって感じでサービスインが始まった。とはいえ、私は本番環境にアクセスできなければ、ログすらもみれないので同僚ががんばっているのを傍から応援しつつ、平常通りタスクをこなしていくだけのはずであった。

のほほんと通常通りのタスクをやっていたら、本番環境の ecs サービスと通信できないという連絡がくる。私が前任者から引き継いで構築したインフラなので何だろう?と調査していて、本番環境でセキュリティグループの設定が漏れていることがわかった。これはわかりにくい問題で cdk の FargateService で ecs サービスを構築している。このプロパティは securityGroups のパラメーターをもっている。このパラメーターを指定しない場合、新規にセキュリティグループそのものは作成してくれるけれど、その ecs サービスへ通信するポートへのインバウンドルールは作ってくれない。

securityGroups?

Type: ISecurityGroup[] (optional, default: A new security group is created.)

The security groups to associate with the service. If you do not specify a security group, a new security group is created.

https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.FargateService.html#securitygroups

テスト環境はセキュリティグループに対して、インバウンドルールを管理画面から手動で追加していたために疎通できていた。セキュリティグループは ecs サービスに紐付いているものだから、ecs サービスを再作成しない限りはインバウンドルールが消えることもなくてこの作業漏れに気付けなかったという落ちだった。さらに、そのセキュリティグループのインバウンドルールを設定したのは私ではない。その説明欄に次のコメントが書かれていた。

atode-kesu

今すぐ消してやろうかという気持ちを抑えつつ、cdk でインバウンドルールを設定したセキュリティグループを紐付けるようにして解決した。疎通ができないと、ロードバランサーのヘルスチェックが通らず、ecs のタスクが延々と再起動を繰り返すというわかりにくい障害となっていた。1時間ぐらい唸っていた。

未検証の本番環境

前節で障害の原因自体はわかりにくいものだが、なぜサービスインの初日にこんなことが起こるのだろうか?という当然の疑問。そう。これまでこのインフラの本番環境は一切検証されていなかった。4月から5月にかけて構築されたインフラだった。この後にデータを格納するための s3 bucket がない、一部の設定はテスト環境の設定しかない、アプリケーションのコード中にテスト環境の設定がハードコードされているとか。追加であちこち直してデプロイしていた。私は本番環境に一切アクセスできないので過去にこれらの検証をすることはできなかったわけではあるけど、いろいろ思うところはあるなぁと感慨に浸っていた。

m1 chip macbook と cdk の追加調査

0時に寝て7時に起きた。昨日はずっと寝てて、今朝は雨降りで徒歩通勤。週始めからしんどい。

デバッグ調査を断念

以前 m1 chip macbook で aws-lambda-python-alpha のデプロイができない ことについて書いた。同僚がそのためにデプロイできないと運用上の不都合があるので調査してみることにした。ワークアラウンドの1つとして、ビルドに使う Docker イメージを任意のものに置き換える仕組みを使えば、arm64 アーキテクチャでビルド処理のプロセス自体は通ることを確認していた。しかし、その後の python distribution が生成されていなかった。同僚にデバッグを手伝ってもらってログをみていると、python distribution をバンドルする処理のログが出ていない。

おそらく docker イメージのビルド処理ではなく、aws-cdk の core 側の bundling のところに原因がありそうに思える。core のライブラリをみると、たしかにいくつか条件次第で bundling をスキップする実装はあったし、ログが出力されていないことからも意図したステップが実行されていないことだけはわかった。その周辺から当たりをつけて aws-cdk の issues なども検索してみたけど、それっぽい issue をみつけることはできなかった。何よりも私がもっていないマシン環境の、様々な環境設定を調べることもできず、aws-cdk の core をデバッグするのも大変かなと午前中いっぱい調べて断念することに決めた。もしかしたら同僚のホスト環境に特化した問題が発生している可能性もある。

アプリケーションレベルで再現できた問題を解決できないというのは情けないけど、自分でデバッグできないものは仕方ないかと諦めることにした。本当に悔しいけれど。

夏休み

目次

0時に寝て7時に起きたけど、昨日から体調よくなくてしんどくて寝てた。

開発やら決算の事務手続きやらのタスクが一段落して余裕時間ができたことでぼーっとしてた。まぁたまにはそういう日もあるか。何も作業せず休んだ日は day off というタグを付ける。あとで何日ぐらい休んだか、どのぐらいの期間で休んだかの確認にもなるかもしれない。

夏バテ

0時に寝て7時に起きた。途中で吐き気がして何度も起きた。夜うまく眠れない。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。先週とほぼ同じでよい状態を維持できている。外が暑くなってその比較から dr.stretch さんの事務所はエアコンがよくきいていて涼しい。うちのオフィスはエアコンの設定温度を上げる人がいて気付くと26.5℃とかに設定されていて私にとっては暑い。とくにどこか張りの強い部位や痛いところはなかった。夜にあまり眠れないわりには身体的には負荷がかかっているところはなさそう。

ストレッチを終えてからオフィスに戻って軽く調べものして、眠くなって仮眠して、そのまま家に帰って寝てた。とくに急ぎでやるタスクがなかったせいか、なんか一気にバテた。