今日のバドミントン練習は体育館で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年がたってしまう。時間が早い。いつでも行けるはずなのに予定を作らないと私はなかなか行けない。ここのお風呂は温度はぬるめ。熱いお風呂が苦手な私でもゆっくり入れる。月曜日のせいか空いていた。最近はシャワーで済ます日の方が多く、お風呂はたまにしか入らない。久しぶりに足を伸ばしてお風呂に入ってリフレッシュできた。あと県立美術館前の広場やスペースも人がいなくてバドミントンの練習をするにはよさそうにもみえた。人が来なくて広いスペースを自然に探すようになってきた。

今日は体育館でバドミントン練習を120分した。前回よりは余裕をもって練習できた。1日の消費カロリーも3000を超えた。

体育館でバドミントン

前回の所感 。先週シニアの方の練習に混ぜてもらって今日も初心者と練習すると伺っていたので部外者なのにまた混ぜてもらった。8時に体育館へ並びに行ったら前に2人いて3番目だった。10分ほどしたらシニアも方も来られて一緒に並びましょうと声をかけた。1人1面しか借りられないため、2面借りるためには2人いる。私は近所なので8時から並ぶことも苦にならない。今後も個人利用の日で9時から来られるなら私が並びますよと提案したら先方もそれは助かるみたいな話しになって line 交換して連絡とれるようになった。個人利用は人数を数えてからチケットを購入し、開始前に窓口でまとめて支払う必要がある。料金の支払い方がよくわからなくて後でまとめてもっていったら手続きが違うって怒られた。ちゃんとした指導者と練習場所を確保できる可能性が高くなることから願ったり叶ったり。先週も並んでいたメンバーが何人かいて、これを繰り返すうちにいつものメンバーになって他のチームとも仲良くなるのかもしれない。

今日は一緒に練習させてもらった中級者の方にフットワークの足さばきを教えてもらった。

• 基本的には奇数で移動する (1歩か3歩)
  • ホームポジションから3歩でコートの範囲内を移動できる
  • 実際の試合だとシャトルが飛んでいるから3歩も歩く余裕はなくて1歩になることが多いらしい
• 足さばきで移動する足は必ず後ろを通す
• 移動した後にラケットを打つために腰を入れられるような動き方が大事になる
• 移動してラケットを振った後に右足が前に出る
  • そのための体重移動や体幹のバランスを取る

その他にも一緒に練習してもらった方からもアドバイスをいただいたりしていた。

• フォア持ちとバック持ちで少し握りを変える
  • 持ち方が少し違うらしい
  • 打ち返す前に握り方を変えているらしい
• バック打ちは手の甲を上に向けて固定する
  • 手首を曲げたりひねったりしない

今日は次のような練習をした。忘れないようにメモしておく。

• ホームポジションからフットワークを使って素振りの練習 (ひとり練習可)
  • 左右斜め前と後ろの4つの方向へ移動する
• 左右にシャトルを投げてフォアとバック持ちでドライブを返す練習
• 左右にシャトルを投げてプッシュを打つ練習
• ネット際からシャトルを投げてプッシュ・クロス・ヘアピンの3つを打ち分ける練習
• ドライブで交互に打ち合いする練習 (真っ直ぐ飛ばす)
• 落ちてくるシャトルをヘッドを立ててひじを曲げてうつ練習
  • 地面にシャトルを置いて真っ直ぐうつ練習
  • これは素振りでもよいかも？ (ひとり練習可)

実際に教えてもらったり実践した練習を覚えていってオプチャのコミュニティでも活用しようと思う。

今日のバドミントン練習はエアシャトルでリフティングを20分した。短い時間でも連続最大回数は244回できた。他に連続100回超えも2回ほどできた気がする。ゆっくり慎重にやれば200回を超すのはできるようになってきたのかもしれない。安定的にリフティングできるようになってきた。

社用車の車検3ヶ月前点検

前回の定期点検はここ 。10時からディーラーさんへ点検にもっていく。お店で点検完了を1時間待つ。最近は月に1-2回ほどしか乗っていないのもあってバッテリーの残容量が48%と低いといったところだけ指摘された。この3ヶ月後に車検がある。もう購入してから2年経つんやな。月日が流れるのは早い。同時に車検の見積もりもしてもらってフル整備で 186,538 円になるという。いくつか必須ではない部品交換や作業を省くと1-2万円ぐらいは安くなるとのこと。さらに まかせチャオ SSコース が 81,690 円となる。これは次回の車検までの4回分の6ヶ月点検の費用を先払いするようなパッケージ。もう2年も乗っていて調子のよい車を6ヶ月ごとに点検する必要はあるのか？という点に懸念がある。私の用途だとそんなに距離走っていないし点検を減らしてよいのでは？という気はしている。整備士さんの立場からは安全のためには6ヶ月ごとに点検するのを推奨している。

走行距離の推移は次の通り。

• 購入時: 49,426 km
• 6ヶ月点検: 50,156 km
• 12ヶ月点検: 52,594 km
• 18ヶ月点検: 53,056 km
• 21ヶ月点検: 53,429 km

開発合宿の資料づくり

もう来週に迫った開発合宿の旅のしおりを今日作った。これまでも作る時間はたくさんあったのだけど、体調が悪くて手が動かなくてずっと先送りしてきた。ようやく資料を作り終えられて準備が前に進んで素直によかった。いつも晩ご飯にみんなで鍋を作っている。これまでは海鮮鍋を作ってきたが、今回は趣をかえてすき焼きを作ろうと予定している。すき焼きは関東風と関西風の2種類の作り方がある。うちの家は煮込む方の関東風のすき焼きだった。参加者でどちらがよいかを聞いていたら関西風は知らないという話題になって逆に関西風を作ってみようという雰囲気になっている。

ストレッチ

先週の バドミントン練習 でころんで腰を痛めたのがまだ続いている。日常生活に影響はないものの、たまに腰を曲げた姿勢によっては腰に鈍痛が響く。出張中もホテルで寝起き時に腰が痛いなと感じていた。トレーナーさんにも相談してストレッチでみてもらったら腰の奥側の筋に張りがあるようだ。右がひどいが、左もやや張りがある。右をかばって左にも影響が出ているのかもしれない。今日の開脚幅は開始前148cmで、ストレッチ後153cmだった。出張明けでカラダに疲労が溜まっているし体調もよくなかったのでそんなもんかもしれない。

今日のバドミントン練習はエアシャトルでリフティングを20分した。連続最大回数は235回できた。出張休み明けだからあまりできないかと思ったが、そうでもなかった。他に122, 192回と20分しかやっていないのに200回超えして、さらに100回超えが2回もあった。練習の間が空いたから慎重にシャトルをみて取り組めたのかもしれない。エアシャトルでのリフティングも200回を超えるようになってきたら別の練習メニューへ移っていく。

神戸にいると、いつも通りのロウカット玄米と生卵と納豆に野菜サラダを食べられる。外食しなくて済むとほっとする。一昨日からの結合テストのリファクタリングを区切りとして終わらせた。一日中テストデータ生成処理のリファクタリングと足りないテストコードの追加をしていた。テストコードの妥当性をカバレッジで確認できるようになったので安心してテストの品質を管理できる。

レゾナンスの楽曲

apple music で 澤野弘之 氏をお気に入り登録しているせいか、新しいアルバムの配信が始まった的な通知をみかけた。これはなんだろう？と調べたら レゾナンス：無限号列車 というスマホゲームの音楽を担当しているらしい。プロモーションアニメも本格的なものが作られている。このイントロの数秒を聞いただけでこれは澤野弘之氏の音楽だとわかる。近未来且つ SF 的な雰囲気。

夜に神戸に戻ってきてからオフィスに来て、機内でやっていた作業を区切りのよいところまで進めてコミットしたりしていた。その後スーパーへ買いものへ行ったりしていた。今日もバドミントン練習はおやすみ。

ローカルは standalone mongodb

mongodb の レプリケーション 機能を使っていて、replica set の設定が容易なことから bitnami/mongodb というコンテナを使っている。これまで結合テストもレプリケーション機能を設定して実行するようにしていた。結合テストの量が増えてきたのもあって実行時間が徐々に遅くなってきた。いまテストのリファクタリングをしているため、ローカルで検証のために何度も実行する必要がある。コードの品質を上げるためにテストを書きやすくする必要がある。実行時間は短いほどよい。そこでローカルでの実行はレプリケーションを設定しないようにしてみた。さらに go のデータ競合を検知する -race オプションも外してテストを実行してみたところ、この2つの改善で macbook の環境で改善前より45%ほど速くなった。十分な高速化を図れた。

飛行機ルートのふりかえり

8月に大雨で新幹線が止まってしまい 神戸に帰れない状況 に直面した。私はほとんど飛行機に乗ったことがなかったため、新幹線が動かないときの迂回手段として飛行機のルートに慣れておく。普段リュックサックに小さいカッターとマイナスドライバーを携帯している。これらは飛行機の手荷物検査でとめられてしまう。荷物を預けるか、検査場で処分してもらうしかない。前回は ANA で帰ってきたが、今回は スカイマーク の飛行機に乗った。値段が安いから LCC だと思っていたら スカイマークは安くて快適なMCC らしい。ANA に比べたらずっと小さい飛行機だった。

タイムスケジュールは次のようになった。

18:15 (都営浅草線) 五反田 発
18:56 (京急本線) 羽田空港 着
19:45 搭乗開始
19:55 飛行機の座席に着く
20:08 羽田空港の滑走路を発進
20:20 離陸
(機内は暗かった、ラップトップで作業)
21:16 神戸空港の滑走路に着陸
21:22 降機
21:25 空港内の荷物受け取り場に着く
21:30 荷物を受け取り
21:35 (ポートライナー) 神戸空港 発
21:51 (ポートライナー) 貿易センター 着

新幹線だと次のようなタイムスケジュールになる。トータルの時間でみれば新幹線の方が20-30分早いかなといったところ。一方で新幹線だと2時間半、同じ姿勢で座っている必要がある。飛行機だと座っている時間は1時間強。飛行機は搭乗手続きのチェックポイントがいくつかあってそれぞれに細かい待ち時間ができてしまうのが気になる。そのときの体調によってもどちらがよいかは変わってくるかもしれない。来月は行きは飛行機、帰りは新幹線にしてみる。

17:57 (JR) 五反田 発
18:03 (JR) 品川 着
18:19 (新幹線) 品川 発
20:53 (新幹線) 新神戸 着
21:10 (市営地下鉄) 新神戸
21:12 (市営地下鉄) 三宮

出張で道具がないのでバドミントン練習はおやすみ。

プロジェクトの進捗報告

出張したときの月例報告の21回目。前々回の進捗報告はこちら 。前回の9月は特別な話題がなかったのもあって書いてなかった。今回も淡々と進捗を報告してあまり話題はないものの、プログラミングを教えることの、抽象化能力と論理的思考、モジュール設計について話題にしてみた。経験のあるプログラマーやできる人は勝手にできてしまうものの、普通の人へどうやって指導していけばいいのか。どこでもよく聞く話しではあるし、プロダクト開発で課題管理をする上での延長上にある話題かもしれない。プロジェクトで解かないといけない問題の本質を認識できるかどうか、気付くかどうかという個人の素養に基づくところが大きい。経験を積んでスキルアップする過程で身につけていく特性を言語化したり明文化したりすることには意味がある。いまの私は答えをもっていないのだけど、とりとめのないの話題だけ共有した。

その後、ある案件の社内向けキックオフがあった。うちらが約2年開発してきたプロダクトがお客さん先で導入することが決まった。1月にテストして2月下旬から本番導入となる。最初のお客さんなので本番導入後のトラブルがあることも想定しておく。それが終わったらフルタイムもお仕事もようやく終えられるかもしれない。うちの会社のプロダクト開発に工数を取るようにしていきたい。

出張で道具がないのでバドミントン練習はおやすみ。

始発の新幹線で東京へ。定例会議に出て、昨日の カバレッジ計測 の成果をメンバーに共有して、その後もバグ修正や結合テストのリファクタリングをしていた。夕方には疲労で眠くなってきて17時でお仕事を終えて、お気に入りの 中華料理屋さんの晩酌セット を食べて、ホテルに帰って3時間ほど寝てた。起きてから軽く散歩に外に出たぐらいでまたホテルに戻って寝てた。毎月の出張で生活のリズムが乱れる。食べものと生活の拠点がいつもと違うのがしんどくなってきた。

今日は1日中オフィスにこもって作業と出張準備をしていたのでバドミントン練習はお休み。夕方にお土産として モロゾフのプリンクッキー を購入するために本店へ行ってきた。これも神戸限定らしい。

パッケージ外のディレクトリにあるテストのカバレッジ計測

先日 深夜にバイナリのビルド・起動調査 をしたのに、最終的にはそんなことしなくてもよかった。デフォルトではパッケージ外のディレクトリにあるテストのカバレッジを計測しないことから普通にはできないと考えていた。しかし、調べたら次の SO で解決法をみつけた。結論としては -coverpkg ./... のように go test で実行している結合テストに対してオプションを指定するだけでよかった。

• How to detect code-coverage of separated folders in GO?

この調査を終えて最終的な makefile の coverage ターゲットは次のようになった。

coverage: lint
	rm -f coverage.*
	go test -tags=integration -race -cover ./... -coverpkg ./... -covermode atomic -coverprofile=coverage.out
	go tool cover -html coverage.out -o coverage.html

この make ターゲットを gitlab ci/cd から実行して coverage.out/coverage.html を自動生成する。coverage.out があるので必要に応じて好みのツールで統計情報を解析すればよい。たとえば nikolaydubina/go-cover-treemap でツリーマップを作るなら次のように実行する。

$ go-cover-treemap -coverprofile coverage.out > treemap.svg

近況報告の資料作り

普段は週末に報告資料を作っているのにもうやる気が無さ過ぎてお仕事を終えてから作っている。今回はネガティブな内容も報告に入れる。過去の経緯などを調査しながら3時間もあれば一通りのアウトラインはできた。明日がマイルストーンの最終日になるため、明日を終えてからでないと細かい数字は決定しない。マイルストーンの issue を調べたら qa テストでみつけた不具合の issue がそれなりに溜まっているようにみえる。本当は次のマイルストーンで5次開発は完了予定だが、もう1つ増やしてもよいかもしれない。いずれにしても12月／1月に本番導入のための準備もある。今の開発フェーズを完了しても次の開発フェーズには入らないのではないかという見通しもある。