今日もバドミントン練習はお休み。

mongodb の healthcheck

bitnami/mongodb というサードパーティのコンテナ を使って mongodb サービスを設定している。docker compose でコンテナサービスの依存関係を記述できるが、特別な設定をしないとコンテナサービスの起動をトリガーに依存関係を制御する。実際はコンテナが起動して内部のサーバー／デーモンが正常に起動するまで少し時間がかかる。たとえば mongodb のコンテナであれば mongod デーモンに初期設定をして再起動したりといった処理を内部的に行っている。そんなときに healthcheck を使うことで実際に mongod デーモンに接続できるかどうかでコンテナのサービス間の依存関係を制御できる。

これまで mongodb には healthcheck の設定をしていなかったので調査して次の設定を追加した。

healthcheck:
  test: mongosh "mongodb://localhost:37017/test?directConnection=false&replicaSet=${MONGO_REPLICA_SET}" --eval 'db.runCommand("ping").ok' --quiet
  interval: 60s
  timeout: 5s
  retries: 3
  start_period: 30s
  start_interval: 3s

mongosh で db に接続して ping を実行するだけなら認証は必要ない。mongosh でなにもパラメーターを指定せずに接続すると direct 接続になってしまう。replica set の設定が完了していることを検証するために replica set 接続にしている。また interval は起動中もずっと死活監視に test コマンドを実行している。それとは別に start_interval を指定することでサービス開始時と通常の運用時の test コマンドによる制御をわけて管理できる。

rabbitmq のアップグレード

19時過ぎに業務終了報告をして、帰ろうと思ったときにふと rabbitmq のバージョンを最近あまり確認していないことに気付いた。いま 3.12.14 を使っているが、Release Information をみるとコミュニティサポートは切れていて、現行バージョンは 4.0 になっていることに気付いた。試しに結合テストの rabbitmq のバージョンを 4.0.3 に上げてみたところ、問題なく動作している。テスト環境の移行は他のメンバーが使っていない夜にやった方がいいかと帰ることをやめて普通に移行作業をやり始めてしまった。メッセージキューは永続化したデータを基本的には保持しないため、メジャーバージョンアップで互換性がなかったとしても volume 配下のデータを削除して exchange/queue を移行すればよい。

rabbitmq の http api client として rabbit-hole というツールを使っている。それも v2 から v3 へアップグレードしていて Changes Between 2.16.0 and 3.1.0 (Oct 31, 2024) に書いてあるが、機能的な変更も非互換の変更もいまのところはないが、4.0 にあわせて将来的に非互換な変更をやりやすいよう、メジャーバージョンを上げると書いてある。go.mod の依存関係も更新したりした。

19時過ぎに帰ろうと思ってから、なんやらかんやらしているうちに最終的には21時半まで作業していた。

昨日遅くまで作業していたせいか、体調があまりよくなくて19時でお仕事を終えて帰って休んでいた。21時過ぎにはベッドに入って寝てた。

base path 移行とビルド

リバースプロキシのルーティング検証 を終えて path based routing を採用することに決まった。そのため、nginx の設定にあわせて sveltekit の ui の base path を設定し直し、テスト環境にデプロイして検証していた。デプロイ先の制約によって base path が変わるというのはよくある状況なので sveltekit も Configuration paths で svelte.config.js に base path が設定できるようになっている。当初は環境変数で切り替えできるように設定して修正したものの、実際にビルドしてコンテナでテスト環境へデプロイしてみると有効にならない。adapter-node を使ってビルドしたソースコードを調べてみると svelte.config.js に設定した値がリテラルで埋め込まれていることがわかった。node.js サーバーの起動時に環境変数などを参照して動的に設定することはできない。次の issue が登録されている。

• make adapter-node base path configurable via environment variable #7242

ビルド時にパスを固定にしないと、他のスクリプトソースやアセットの管理で煩雑になるところがあるのだろうと推測する。本当は環境変数で起動時に動的に変更できると、お客さんの環境にあわせて base path の値を変えたりもできるが、現状ではこちらが決めた値を固定で使ってもらうしかないことがわかった。

前日は十分に休みつつも夜遅くまで事務手続きをやって週始め。昨日作った請求書を送付して会計処理もした。

法人税の中間申告 (続き)

税務署からの通知は 自治体のそれから約1ヶ月遅れて 届く。朝からお手伝い先の社内で管理している gitlab サーバーに接続できない。障害が発生していたようで復旧するまで1-2時間ほど隙間時間ができた。その間に e-tax で法人税および地方法人税、それから消費税の中間申告／納付をした。eltax と比べて e-tax の中間申告は手順が少なくて簡単にできる。いまシステム移行しているようで、古いシステムと新しいシステムの全く違う UI を行き来する、めちゃくちゃな UI の違和感さえ我慢すれば簡単に手続きできた。

先週分の残作業や溜まっていた issue の整理

先週の金曜日をお休みしていたマージリクエストをレビューしたり、修正済みの issue をメンバーに検証してもらっていたところで修正漏れがあったりして fix した。その過程で仕様を変えたりもしたのでテストケースも修正したりした。週初めで元気があったせいか、作業の区切りも悪かったせいか、早くお仕事を終えて日記を書こうと思っていたのに21時過ぎまでやって疲れてしまって、すぐ帰ってそのまま寝てた。

朝から起きていたものの、開発合宿疲れのせいか、起き上がる気力がなくて夕方まで家でのんびりしていた。お腹が空いて外へ出掛けたことをきっかけにそれから活動していた。イベントは楽しいし得るものも多いが、その疲労も確実にくる。前回の開発合宿は忙しい時期に休みもなく 精神的に疲弊した 記憶がある。こうやって書いておくと当時の様子を思い出せるので日記を書いておくと役に立つ。今後も開発合宿のようなイベントの後に休日がある日程を設けていく。今日のバドミントン練習もお休み。

経費の精算

夕方からオフィスで経費精算をしていた。11月に入ったのでお客さんへの請求書も発行していないことに気付いて請求書を作ったりしていた。11月1日にお休みをとったから忘れていた。その後に開発合宿の経費の整理をいろいろやってた。今回は約15万円ほど会社の経費を使ったことになる。予算通りではあるが、改めて精査してみるとインフレの影響で食費や宿泊費のすべての値段が上がっていることを実感する。

バドミントンの予定登録

エアバドミントンの予定登録、磯上体育館の抽選確認／確定、中学校体育館の予約、冬期スポーツ教室 の申し込みなど、バドミントンに関する予定の登録などを行った。自分のモチベーションコントロールが難しくなっていて、ゆっくり休みたいという気持ちはありつつも、なにも予定を入れないとただだらだら過ごしてしまうという懸念もある。バドミントンは今後がんばりたいのでどんどん練習の予定を入れてしまう。

昨日で大雨が過ぎ去って朝から快晴だった。近くの公園へ行って3人でバドミントンの打ち合いを30分ほど軽くやってみた。せっかくバドミントンの道具を持っていったので少しでもみんなで出来てよかった。

朝からお風呂へ行ったり雑談したりお土産を買ってきたりしながら11時にチェックアウトする。行きと同じ参加者と2人で帰路につく。時間があるので篠山城跡に寄り道してから神戸へ帰ってきた。周辺でお昼ご飯を食べてから篠山城跡へ行ってみる。11月3日は文化の日なので美術館、博物館、資料館などが無料拝観になったりするらしい。篠山城大書院 も無料公開されていた。初めて入ってみた。大書院 (おおしょいん) と読む。中は広くて資料展示や10分ほどで歴史のダイジェスト動画を流していた。明治の初期には篠山県と豊岡県があったんやというのも初めて知った。

明治4年（1871年）7月14日の廃藩置県により篠山藩は廃され、篠山県となる。さらに同年11月には篠山県も廃され豊岡県に編入、明治9年（1876年）8月には兵庫県に編入された。

wikipedia:篠山藩

常設展示かどうかはわからないが、有志の方が手作りでつくった戦国武将の甲冑が展示されていて見事だった。写真を撮っていいのかわからなかったが、ダメとは書いてなかったし、本物でもないからいいかなとおさめてきた。

帰りの車の中でも政治や課題管理など、いろいろ雑談しながらゆっくり帰ってきた。途中、2箇所で渋滞につかまった。車のナビ通りにいくと渋滞になっているところを google map で回避できるルートを使うとうまく抜けられた。みんな車のナビをみて移動するから同じルートで渋滞になってしまうのかもしれない。google map はリアルタイムで利用者が投稿した渋滞情報を更新しているようでそれを参照して迂回ルートを提案しているらしい。渋滞に捕まりそうなときは車のナビではなく、助手席で google map のルート検索をしてもらうとよいことを学んだ。同乗の参加者を神戸空港まで送り終えて今回の開発合宿を終えられた。

今回は私の準備不足でなにも出来なかったが、無事にイベントを終えられてホッとした。家に帰ったら疲れてなにもする気がなくなってそのままぐったりしていた。イベントをやっているときはスケジュールをこなすことに必死だけど、終わりはいつも達成感と、物足りなさや反省に加えて寂しさも混ざって複雑な心境になる。

居間で1時半から6時頃まで寝てた。今日のバドミントンは雨天中止。朝から大雨、河川洪水、土砂災害警報と出ていた。雨も夜までずっと降り続いていた。

起きてから昨日、移動途中のサービスエリアで買っておいた丹波黒枝豆を茹でてみる。大粒で少し甘みがあっておいしい枝豆だった。普通の枝豆とは少し趣が違うようなのでお土産にもよさそうに思えた。おやつ代わりに茹でた枝豆を食べていた。

その後、午前中に雑談しながら発表資料を作り終えた。今回の開発合宿は余裕がなくてすべてにおいて準備不足だったが、そのうちの大きな反省として発表資料を事前に作らなかったことがあげられる。きのいえにいると、なんやらかんやら周りと雑談して盛り上がるので自分の作業がまったく進まない。ワーケーションは「余白」が大事になる。普段話さない人たちと雑談するためのイベントでもある。

お昼頃に マルサン精肉店 ですき焼き用の但馬牛を買いに行く。店員さんと話しながら1人200gを基準に購入する。但馬牛のリブロースを200g、鹿児島産の赤身肉を100gとした。但馬牛はとてもおいしかったが、リブロースの霜降りの脂身があるため、量は食べられない。実際に食べてみた所感としてはリブロースを150g、赤身肉を100gでよかったと思える。足りないよりは余る方がよいのでこのぐらいは許容範囲と言える。お店では陳列棚にお肉を並べていなかったため、100gの単価がわからなかった。私の先入観でお肉はそう高くないだろうと考えていた。実際に買ってみたらリブロースが3000円/100g、赤身肉が1900円/100gだった。先に値段を聞いてから他の部位とも調整して買うべきだった。インフレしているのもあると思うが、5人分のお肉の料金が8人でカニを購入したのと同じぐらいの金額になってしまった。失敗。

午後からまた別のお風呂へ入りにいったついでに かみや民藝店 さんの前を通りかかって入ってみた。陳列されている麦わら細工を見学してからオーナーさんに話しかけてみた。この麦わら細工を作っているのは日本で城崎温泉と伊勢の2箇所しかないらしい。昨年、お土産に麦わら細工のストラップを購入してから気になっていた。

お土産を買ってきてから、うちの会社のロゴは幾何学模様だからこの麦わら細工で作れないかと考えていた。うまくできればオリジナルな会社のノベルティになるのではないかと。オーナーさんに聞いてみたところ、うまくできるかどうかは実際に作ってみないと分からないものの、特注のようなものも引き受けているという。基本的にすべて手作りで作るため、既成品を作るのも特注品を作るのも手間暇はあまり変わらないらしい。

• カスタムメイドの追加費用はない
• 最低発注数のようなものはない
• 納期は急いでいないからいつでもよい

1つ2500円前後で作ってくれるという。まず試作品としてうちのロゴの色違いで2つを作ってもらうことにした。それをみてから実際にノベルティとして発注するかどうかを決める。麦わら細工でノベルティの試作品交渉がうまくいった。

晩ごはんに関西風のすき焼きを作って食べる。まず肉を焼いて溶き卵でそのまま食べる。焼いて食べるときのインパクトは大きい。よいお肉だったのもあっておいしかったと思う。焼いて食べた後は普通に煮込むすき焼きを作る。最初に焼いて食べるお肉のインパクトが大きかった分、煮込んで食べたときの印象が薄くなってしまう感じがした。2回に分けて鍋を作ったが、最初は野菜が足りなくてすき焼きに煮込む水分が少なかったように思えた。鍋いっぱいの野菜を多めに入れてから煮込むとよさそう。

晩ごはんを食べ終えてから2日目の親睦会に入る。3人で発表していく。私はこの10ヶ月間の運動や体重減やバドミントンを始めた話しをまとめてみた。準備不足もあって単体と経緯をまとめただけでなにを伝えたいか、よくわからない発表になってしまった。はらさんは「ロールモデルを歩く」という主題で自分がなりたい人に、自分がなっていけるような生き方をしていくという話しをされた。それを聞いていて参加者からこれからは「風の時代」になっていくとか、経済的な価値よりも精神的なつながりを大事にする価値観が重要視されるのではないかといったコメントもあった。60歳になってものづくりをしている人は周りからみて迷惑になっているのではないか？若い人たちからみて年配の作る人は迷惑ではないか？50代になると受託開発の単価が下がる問題への対応。40代のうちから単価をあげず最初から高くないから下がらないという戦略もある。

私がいま独立して会社をやっている理由を端的に表すと「組織に馴染めない」ということがあげられる。それについても聞いてみた。

• ai を相手に話せば、若い人に迷惑をかけずにやり取りできるのではないか？
• 老化しないための研究が発展して不老不死のような状況もみえてくるのではないか？
• 50代になると選択肢がなくなっていく
  • サラリーマンとして我慢してやっていく
    • その生き方も強いと言える
  • 組織と折り合いをつけられているならそれは能力の1つと言える
• 50代で潜伏していた人はあまりいない

発表を終えて、0時ぐらいから知人のトラブルプロジェクトの話しを聞いていた。自身の経験則から私ならどう考えてどう行動するかと考えながら雑談していた。抜本的に改善しないといけない状況だが、プロジェクトの状況からどうにもならない、かなり高い確率で失敗の未来がみえている。雑談をしていて課題管理や業務の教え方について思うことが出てきたのを、忘れないように書き殴っておいた。この話しをできただけでもこの開発合宿は価値があった。

• 若いメンバーは「わからない」「できない」が言えた時点で正しいとする

  • そこから先の問題を表現する練習を積み重ねる
  • これは文章でやり取りするよりも、口頭で話しながらできるようになってもらう
  • 専門用語が出てくれば、なにが／どうわからないかを短文で説明してもらう
    • その後に具体的に論理を説明しながらわからない内容を長文で説明してもらう

• 問題の本質を理解するための問答ではなく、私が言ったことを理解するための問答になっていた

  • 文章で指摘した方が後で読み返せて調べられるし、証拠も残ってよいだろうと考えていたが、人によってはそのやり方が最善でもなかった
  • 口頭で問題の本質を確認したり、相手が何を理解出来ているかを質問して考えてもらう時間をもっと取るべきだった
    • 教え方・教わり方に個人差がある
      • 文章だからわかりやすいとか、口頭だから曖昧になるというわけでもないことを学んだ

• プロダクト開発のコアな役割を担ってしまうと品質をとるか、成長を促すかのトレードオフに直面する

  • 私の価値観ではプロダクトの品質をあげる方を選んでしまった
    • プロジェクトに入る前にお客さんにどちらかの2択を決めてもらう
      • メンバーの成長を優先か、プロダクト/プロジェクトの品質を優先するか
        • お客さんが選ばなければ、逡巡と葛藤の結果、最終的に私は品質を優先する

• 業務の進め方が一定水準に満たないメンバーをどう対応するかa

  • コードレビューならマージしない、やり直しをしてもらうスキームを作るべきだった
  • 最初からうまくできるわけはないから、やりながら慣れていってもらうことを優先して導入を甘めにしてしまった
    • 問題の本質を理解できていないようにみえても指摘したことを修正したらマージしていた
      • 問題の本質を理解するよう促したり、モブプロしたりしてもっと時間をかけて基本を指導して最低水準を設けるべきだった
      • もっと話して時間をかけてゆっくりしっかり指導していくべきだった
        • 最初に業務を遂行する上でのスキルの基準を示すべきだった

• リーダークラスのできる人、チームを相手に課題管理を教えるのか、新人や経験の浅い人たちも含めて課題管理を教えるのかでやり方が異なる

  • 前者はみて学んでくれる
    • 実践しながら勝手にできるようになっていくのでプロジェクトが進む
  • 後者は成長を主目的とする
    • 品質や機能開発を停滞させても業務の進め方をしっかり指導することが中長期的に大事になる

• 課題管理のビジネスをする上でマネージャーとして実践的に入るのはよい

  • 終わりのスキームを最初から作っておく必要があった
  • マネージャー (&遊撃) でプロダクト開発のコアな役割を担ってしまうと抜けられなくなる
    • クロージングをどうすればよいかを悩み始めた
    • 課題管理の OJT を実践的に1ヶ月で終えられるようなコンテンツづくりやノウハウのパッケージングをしていく必要がある
      • 現状ではうまくいけば半年、そうじゃなかったら1年ぐらいかかる
  • プロダクト開発の初期で私からメンバーにマネージャーを移行するスキームを作っておく

• マネージャーは厳しいことを指摘しないといけない

  • なぜ厳しいことを指摘するのかの背景や理由を説明できるようになる
  • 厳しいことを言っても人間関係を崩さないだけの人間力も必要になる

1時前まで資料作りをして2時過ぎに寝た。神戸から城崎温泉まで3時間もあれば着くことはこれまでの経験でわかっていた。三ノ宮で8時半に待ち合わせてして出掛ける。出掛けていろいろやってたので今日のバドミントン練習はお休み。

開発合宿へ出掛ける

今回は一緒に車で移動するのは1人だけ。レンタカーを借りずに社用車で出掛ける。8時半に待ち合わせして9時半頃に 西紀サービスエリア で休憩。丹波産の黒豆は使っていないらしいが 黒豆せんべい を買ってみたらおいしかった。また今度買ってみようと思う。その後、出発したもののナビの案内がおかしい。中継地点として西紀 SA を設定していたため、出発した後も西紀 SA へ向かうようなループした案内になってしまった。中継地点を通過したことを登録するか、ナビのルート案内をやり直す必要があった。失敗。あとナビの目的地を城崎温泉駅にするよりも「但馬空港IC」のように高速道路の出口を指定した方が高速道路を使ったルート案内になるように思える。ナビの設定で回避できるかもしれないが、なるべく高速道路よりも下道を使うようなルート案内が行われてしまう。

やや運転トラブルはあったものの結果的には予定通りの11時半に きのいえ に到着した。スタッフさんもおられてそのまますぐにチェックイン手続してくれた。前回はクレジットカードの上限設定を超えて決済できなかった。今回は上限設定を見直していたので問題なく手続きできた。プロジェクターとの接続チェックで手間取った。wifi の接続先が 2.4g と 5g あり、プロジェクターが 2.4g を使っているためにラップトップも 2.4g に接続しないと接続できなかった。周波数をあわせないと接続できないというのを学んだ。

その後、12時半、14時半と電車や自分の車で来られた参加者と合流。今回の参加者は私も含めて5人。参加者が chromecast をもってきていた。プロジェクターに hdmi 接続で chromecast を接続し、chromecast はモバイルバッテリーから電源をとる。これで wifi 接続すれば、OS に関係なく chrome ブラウザなら画面共有できるようになる。ブラウザのタブ単体と画面全体のどちらでも共有できる。プロジェクターが提供する ios キャスト (airplay) やミラキャストは os ごとに設定を変えないといけないのでそれが面倒になる。いま chromecast は生産中止になっていて現行機種は Google TV Streamer になり、値段も16,000円とやや高い。このデバイスとモバイルバッテリーをもっておけば、開発合宿のような、不特定多数のラップトップで画面共有するときに便利なことを学んだ。

雑談しながら作業したり、お風呂へ行ったりしながら19時からイタリアンのビールレストラン GUBIGABU で晩ご飯にした。この時期はまだカニが解禁されていない。インフレのせいか、値段はやや高めになっていた。味はおいしかった。地ビール4種飲み比べ のメニューがあってそれぞれ飲んでみた。どれも特徴があって好みが分かれると思う。私は雪のビール (カニビール) が一番好みだった。最初の1-2品を頼んでみて量が少なかったのでそれからは2皿頼むことにした。5人という人数は料理の量やお皿を置く位置と席の配置が難しい。2皿ないとどちらか一方の端にいる人は料理を取れない。

21時頃に晩ご飯を終えて21時半から恒例の親睦会に移る。今回は初日に2人、2日目に3人と分けて発表してもらう。詳細は省くがおもしろかった。人数が少なくて時間も余裕があるからゆっくり雑談しながら発表内容についてあれこれ話しができてよかったと思う。人数が少ないから濃い話しや雑談になる。これは昨年よりも参加者数を少なくしたことのメリットだと思う。その後も作業したり雑談しながら25時半頃に寝た。私はいびきがうるさかったら申し訳ないから1Fで毛布にくるまって寝てた。暖房を入れておいたら寒くもなくよく眠れた。4時間ほど寝て1時間も深い睡眠があった。運転したり普段とは違うことをして疲れていたようにみえる。

今日のバドミントン練習は体育館で1時間ほど練習できた。試合中にまた足と腰を痛めてしまった。無理しないように意識していてもついついシャトルを追いかけてしまう。しばらく試合はやめとこうと思う。

テストコード追加の一区切り

これまでテストの改善をやってきてもっとも仕様が複雑、且つ数量も多い api 群のテストコードを一通り書き終えた。カバレッジを目標の1つにしているので改善していることを数値で確認できる。その過程でいくつかバグをみつけて直すこともできる。区切りとして一通りやり切ったので安心して明日はお休みをとって開発合宿へと行ける。しんどかったけど、やっていれば形になって結果は出てくる。一方で私が実際の開発をやってしまうと自分の時間をどんどん浪費していることにも気付けるようになってきた。自分の時間をどう使うのかをいろいろ考える開発やリファクタリングの機会となった。今回の開発フェーズが終わったらまた振り返りしたい。

体育館でバドミントン

前回の所感 。抽選予約で獲得した平日夜の時間帯。今日は参加者が多くて8人来られた。1面のスペースだとこれ以上の人数はちょっと無理そうに思えた。なにか練習をしてもよかったのだけど、8人もいたらスペースが足りないかなと思ってどう運用していいのかわからなかった。不完全燃焼。最初は3対3でネットを挟んでの打ち合いをしてみたが、スペースが狭いからなんとなく手持ち無沙汰になってしまう。経験者の方から2人チームを作ってローテーションでまわしましょうという提案をもらって2対2で10点先取の試合形式にした。10点取ったら交代でローテーションしていくようにした。このときにチーム編成を簡単に決める手段を準備しておくと、決め方を「決める」の無駄な時間を省ける。前に練習に参加させてもらったチームではトランプのカードを引いていた。これはなにかしらツールを用意しておくとよさそう。

経験者の方にフットワークについて教えてもらった。一歩でどう動くか、腕とラケットを伸ばしてどこまで届くかの距離感を掴むのが大事なように思えた。カラダの近くでシャトルを捉えようとすると動かないといけないが、実際の試合だとシャトルの方が速いのでなかなか動けない。フットワークの重要性が少しわかってきた。

私の場合、下手だから試合形式にするとすぐミスをして試合を止めてしまい、申し訳なさと自身の練習時間も短くなるという2重でネガティブな所感を受ける。なにかしら量をこなせる練習メニューや打ち合いをしていた方が楽しかったりする。中級者なら試合する方が楽しめるのかな？やはり2面ないと別の思考をもつ人たちが一緒に活動するのは難しいのかもしれない。いまの私はスキルアップにつながる練習の量をこなしないという思いがある。また他のチームの練習にも参加して考察してみようと思う。

開発合宿の準備をしていて今日のバドミントン練習はお休み。

nginx のリバースプロキシ

compose に起動している2つのサービスを同じポート番号で共有したい。nginx を tls 終端にしていてリバースプロキシとして構築している。ルーティングするには2つの方法がある。次のような compose.yml を作ってローカルのファイルシステムをマウントして設定変更しながら検証する。

services:
  proxy:
    container_name: proxy
    image: docker.io/library/nginx:stable
    ports:
      - 8443:8443
    network_mode: "host"
    restart: unless-stopped
    volumes:
      - ./nginx:/etc/nginx

sub-domain based routing

クラウドでは普通のやり方がサブドメインのホスト名でルーティングを行う。設定もシンプルでファイルも管理しやすいように分割できてよいと思える。システム変更時の移行も名前を切り替えればよいので移行しやすい。

• nginx.conf

http {
    sendfile on;

    upstream web-api1 {
        server localhost:8801;
    }

    upstream web-api2 {
        server localhost:8802;
    }

    ssl_certificate /etc/nginx/ssl/sample.crt;
    ssl_certificate_key /etc/nginx/ssl/sample.key;

    include /etc/nginx/sites-enabled/*;
}

• nginx/sites-enabled/www.sub1.example.com

server {
    listen 8443 ssl;
    server_name sub1.example.com;
    location / {
        include     /etc/nginx/common_proxy.conf;
        proxy_pass  http://web-api1;
    }
}

path based routing

サブドメインの方が私は好みではあるが、サブドメインをネームサーバーに登録したり、tls の証明書にも複数ホストの考慮が必要になってくる。パスでルーティングするなら1台のマシンのように仮想的にみせられるというメリットはある。

http {
    sendfile on;

    upstream web-api1 {
        server localhost:8801;
    }

    upstream web-api2 {
        server localhost:8802;
    }

    ssl_certificate /etc/nginx/ssl/sample.crt;
    ssl_certificate_key /etc/nginx/ssl/sample.key;

    server {
        listen 8443 ssl;

        location /app1/ {
            include     /etc/nginx/common_proxy.conf;
            proxy_pass  http://web-api1;
        }

        location /app2/ {
            include     /etc/nginx/common_proxy.conf;
            proxy_pass  http://web-api2;
        }
    }
}

コンテナの capability

docker compose を rootless mode で使っていて 443 ポートを使いたいと言われてどうしたらいいのだろう？といままで考えていないことに気付いた。調べたらすぐにやり方が書いてあった。

• Exposing privileged ports

$ sudo setcap cap_net_bind_service=ep $(which rootlesskit)
$ systemctl --user restart docker

これだけで compose サービスの1つにポート設定できた。めちゃ簡単だった。いままで capability を設定したことがなかったのと、権限周りはややこしいという先入観もあって触る機会がなかった。いろいろ洗練されて抽象化されているのだと推測する。バックエンドの場合は任意のポート番号を使えばよいから capability の設定をして 1024 以下のポート番号を使わないといけない理由はあまりない気はするが、そういう設定もできるようにはみえる。そういう話題すら聞いたことがなかった。

• Set capabilities for a Container

お仕事の区切りが悪くて23時までコードを書いていたので今日のバドミントン練習はお休み。ひたすらテストコードを書いている。テストケースをみて、カバレッジをみて、アプリケーションコードを読んで、テストコードを読んでの繰り返しの日々。時間をかけてきたけれど、ようやく成果が出てきつつある。一番ややこしいところのカバレッジを 50.6% から 80.4% に改善したと報告をあげた。テストデータを細かく管理できるようになったのでカバレッジが上がっているだけでなく、複数設定の違いによる振る舞いの検証も進んでいる。

改善のための改善を繰り返すと苦しくなる

ちょうどいま私がやっていることのしんどさを代弁してくれているような記事をみかけた。

• 業務効率化の苦しみでもとの濁りの田沼恋しき的な気持ち

私もいまマネージャーやって、プロダクトの開発全般を改善して、また開発者に戻ってプロダクトのコードを改善して、ここ半年ほど技術的負債になってしまったところを改善しまくってきた。小さい規模ではうまくいったことが規模が大きくなる中での見直しや依存関係によって複雑化したり、自動化をしても自動化のための仕組みは保守しないといけない。改善にはいろいろ面倒くささがついてくる。その割にその成果がみえにくかったり分かりにくかったりする。やっている本人ですら微妙とか思ってしまうことさえあるものの、しかし、それをやらないとさらにひどい状況になるのでやらざるを得ない。

ひどいプロダクトやどうしようもないスタートアップなどはリアーキテクチャをやらないので直せないといった状況になってしまい、保守している人たちが苦労したり、鈍重な開発で苦しんでいるのをみかけたりする。少なくとも私がイニシアティブをとっているプロダクトでそんなことは起きない。常に改善しまくっているから短期でみた機能開発のスループットは高くないかもしれないが、中長期でみた開発を停滞させる要因はまったくない。

この「より良くしているのに、より苦しくなってくる」機序は、基本的に産業資本主義の特徴なのだろうと思っている。
時間軸上の価値体系の差異から価値を取り出す行為を回し続けないといけなくて、効率化して生産性を上げたなら、さらに上げ続けないと価値を取り出せなくなってしまう。

テストがなければそもそもテストの改善や見直しという作業は発生しない。開発したときにテストコードを書くという作業も発生しない。業務量はずっと下がる。もちろんその減った業務量は将来の不具合や鈍重な開発により後払いになるわけだが、いまテストを書いていてもその保守や改善のための作業が既存の開発に付加された形で将来に積み重なっていく。テストがなかった未来とテストがある未来を比較することはできないが、どちらの未来にも手に余る業務量が待ち受けているという展望はそれほど変わらないようにみえる。そこで自身の自己実現や成長といった目的がないのであれば、テストがある未来に得ているはずの利益を資本家が搾取するだけで労働者はなんら変わらないのではないかという気持ちが「改善すればするほど苦しくなっていく」と感じてしまう。

今日のバドミントン練習は公園で軽く打ち合いを15分ほどした。昨日は疲れて休んでしまってオフィスへもっていくご飯も炊いてなかった。お仕事もバタバタしていてほとんど何も食べずに夜まで過ごした。

光るシャトルの試し打ち

シャトルのコルク部分に LED がついた光るシャトルがある。amazon で検索してみつかるのはほとんど中国製で安かろう悪かろうな印象を受ける。試しに買ってみて4個で561円だった。注文してから届くまで3週間ほどかかった。amazon の配送状況もトレースできていなくて今週中に届かなければ返金しますというステータスになってから郵便受けに届いていた。値段も安いからシャトルの品質は粗悪なモノだった。軽く練習で使うならいいんじゃないかと私は許容範囲。

バドミントンのシャトルを打ち合いするには公園の街灯は光量不足でみえない。光るシャトルなら軌跡を追いかけられる。慣れればそれっぽく打ち合いできそうな雰囲気はした。今日は雨上がりで地面が濡れていたのと風も少しあったので軽く試し打ちにとどめた。また天気のよい日を探してやってみようと思う。なにもしないよりはラケットの制御やシャトルを打ち返す感覚を養うために使うのはよいと思う。一方で打ち合いするにはそんなレベル感で一緒にやってくれる人を探さないといけない。相手を探す方が難しい気はする。

電池交換は不可で10時間ほどで電池がなくなる。おそらくコルクに LED を取り付けたものだと状況によってはすぐ壊れるだろう。安いから使い捨てでも構わないが中国から取り寄せになるから購入に時間がかかる。品質のよい既存のシャトルに自分で電子工作して LED を取り付けたりできないやろか？と考える。そうすれば電池交換や修理対応も自分でできてコストも削減できて、品質がよければ他の人にも関心をもってもらえるかもしれない。

お風呂ウォーキング

光るシャトルの試し打ちを付き合ってもらってから、ながいさんと HATなぎさの湯 へ歩いて行ってきた。往復してきて15,000歩を超えていた。前回は3月26日に行っていた から半年ぶりになる。もう半年以上も経っていることに日記から気付く。毎日なにかしらに追われて生活しているとすぐ半年や1年がたってしまう。時間が早い。いつでも行けるはずなのに予定を作らないと私はなかなか行けない。ここのお風呂は温度はぬるめ。熱いお風呂が苦手な私でもゆっくり入れる。月曜日のせいか空いていた。最近はシャワーで済ます日の方が多く、お風呂はたまにしか入らない。久しぶりに足を伸ばしてお風呂に入ってリフレッシュできた。あと県立美術館前の広場やスペースも人がいなくてバドミントンの練習をするにはよさそうにもみえた。人が来なくて広いスペースを自然に探すようになってきた。