今日のバドミントン練習はメイビス2で壁当てを15分した。勉強会帰りで疲れていたせいか、夜遅くのせいか、あまりカラダが動かなかった。日付が変わってから 中学校体育館の12月予約 で4つ抽選申し込みをしていたが、すべて落選していた。2ヶ月続けてすべて落選したことからそうそう予約は取れないことがわかってきた。

昼間は昨日の続きで mongodb のトランザクション導入のマージリクエストをレビューしてもらって、テスト環境へデプロイして検証していた。id 連携のシステム間連携において意図した振る舞いにならなくてその調査をしていた。チーム勉強会で mongodb のトランザクション周りのいろいろをメンバーに共有した。17時前にお仕事を終えて定期歯科検診へ行ってきた。前回対応してくれたスタッフさんで「また少し痩せました？」と聞かれた。8月からだとほとんど変わっていないと思うが、今週は普段より多く運動できているのでその影響もあるのかもしれない。30分ほどですんなり終わった。

コードリーティング

歯医者を終えてから KOBE.go #7 - コードリーディング会 へ行ってきた。移転したハックバーへ行くのも初めて。三ノ宮駅から10分ほど歩いた場所の、こじんまりしたバーだった。10人程度入ったらいっぱいかな。おそらく集客や家賃などを考えたら妥当なサイズと立地なのだと推測する。いまは水-日の18-23時、月・火がお休みという営業時間らしい。私が着いたときはカウンターが埋まっていたのでテーブル席で発表を聞きながらコメントしたりしていた。私以外の参加者の大半は学生さん、みんな20代の方ばかりだったと思う。kyoto.go で発表したりしていたせいか、kobe.go のスタッフさんにも名前を覚えてもらえていた。若い人がコミュニティを運営しているのはよいことだと私は考えている。年寄りの役割としてなにかしらコンテンツを提供することで協力できればと思う。

コードリーティングはおくたにさんという方が実装している gomoqt という Media over QUIC (MOQ) のサーバー／クライアントを題材とした。京都大学の学生さんで学生起業しているのかな？音声配信サービスをやりたいから moq ライブラリを開発していると話されていて、プロトコルを勉強して自前でサーバー／クライアントのライブラリを実装しようとするの、すごいなと思って聞いていた。quic のライブラリを使ってサーバー／クライアントを実装しているようにみえた。ソケット (トランスポート層) より上のレイヤーを実装すればよいならそんなに難しくはない。

• 発表資料: gomoqt Media over QUIC in Golang
• github: gomoqt

私が想定するコードリーティングのイベントではなかったものの、参加者は誰も moq プロトコルを知らないので moq の背景や現状、プロトコル仕様を共有するようなイベントになっていた。それはそれで私は知らないことばかりなのでへーと思いながら聞いていた。21時半頃にはイベントも終わり、イベント告知や雑談モードになっていって、若い人たちの中におっさんがいても迷惑かなと22時前には退出した。帰る前にワンドリンク (Go という名前の柑橘系カクテル) の料金として700円を支払う。個人的にお酒を飲みながらの勉強会はあまり好きではない。気分や雰囲気でぐだぐだになる印象があって学ぶときは学び、終わってから飲みに行って雑談するといった切り替えが私は好み。バーで勉強会をするという雰囲気もあまり馴染めない。単純に狭いし暗いし椅子よくないし作業に集中しにくいという所感かな。

今日のバドミントン練習はエアシャトルでリフティングを10分した。連続最大回数は275回。リフティングをしてからシャトルを真上に強く打つのを10分、シャトルを反発力の高いメイビス2にして壁打ちを15分していた。シャトルを強く打つときにチカラの入れ方や角度などを考えながら打ってみた。壁打ちも練習していて2パターン思いついた。1つは壁の近くでひたすらシャトルを打ち返すやり方、もう1つは少し壁から距離をとって真上にシャトルをあげて落ちてきたシャトルを思いっきり振り抜いて壁に向かって打つ。壁から返ってきたシャトルをまた真上にあげて、思いっきり振り抜くのを繰り返す。このやり方だと素振りの延長上でラケットを振る練習になるような気がする。

昨日まではジョギングしてからバドミントンの練習をしてきた。今日は逆にバドミントンの練習をしてからジョギングと縄跳びをした。お仕事を終えたのが20時頃で21時にバドミントン練習場 (ビルの軒下) の照明がおちる。だから先に照明が消える前に先にバドミントンの練習をすることにした。おかげで壁打ちのやり方をひらめいたりして約1時間集中して練習していた。その後、みなとのもり公園へ移動してジョギング2周 (0.9km) と縄跳び15分で1770回跳べた。昨日からの筋肉痛も続いているので軽めに運動しようと思ったものの、縄跳びは少し回数が増えた。休憩時間を少し減らしたり、ミスが減ったり、バドミントン後のせいか腕がだるくて縄をまわすリズムにのれなくてペース落ちたりと、昨日とはコンディションがいろいろ違うなと思いながら数字をみるとおもしろい。

お仕事は昨日の続きで mongodb のトランザクションのデバッグをずっとやってた。デバッグしての結論として middleware で unit of work を実装するのは断念した。

メガネ探し

視力が 0.3 ぐらいで有事のときに困る状況を想定してメガネを1つもっておこうと考えている。やぎさんにも相談していくつかアドバイスをいただいた。動体視力も落ちていてバドミントンをしていて動くシャトルを空振りすることも多い。もしかしたらメガネをした方がシャトルとの距離感もつかめるのかも？と思いスポーツ用のメガネがどうなのかも調べてみた。結論から言うと、スポーツ用途ならメガネよりもコンタクトレンズの方がよいらしい。コンタクトレンズをするほど視力低下に困っているわけでもないからまずはメガネを買って必要なときだけ使うといった運用を考えている。

• バドミントンどきに適したメガネ＆保護眼鏡

壁打ち

次のバドミントンの練習方法として壁打ちがよいんじゃないかと調べてみた。上級者の動画をみると、近くで力強く打ち返して壁打ちしている。これはめちゃくちゃ難しい。シャトルが速過ぎて全然おいつかない。実際にやっている人をみるとこのぐらいはできるんやとわかってやり方のイメージづくりにはよい。

もう1つ。室内でスポンジボールを打ち返す壁打ちを取り上げているサイトもあった。これならオフィスでもできるんじゃないかとベルボールを amazon で発注してみた。出張にももっていってホテルでやってもよいかもしれない。

• スポンジボールで壁打ちをやってみた≪ベルバド≫

今日のバドミントン練習はエアシャトルでリフティングを10分、連続最大回数は120回ほど、ショートサーブ30回した。フットワーク練習はお休み。筋肉痛もあったから、みなとのもり公園をジョギングで3周 1.4km、縄跳び15分で1712回だった。縄跳びも2ヶ月ぶり。8月に過去最高が1838回に対して、2ヶ月ぶりにやって2分弱の休憩、十数回のミスがあっても1700回を超えるんやと思って少し驚いた。8月に比べたらいまは涼しいから記録が伸びるのもある。ジョギングで足が筋肉痛になると走るよりも縄跳びの方が負担が小さい。昨日と同じように運動してストレッチして十分にカラダを動かした。

トランザクションとコールバック

お仕事は昨日の続きでリクエスト途中のサービス終了したときに web api ハンドラーの処理が途中でキャンセルされ、そのために内部のデータが不整合になることがわかった。データを不整合にしないため mongodb のトランザクション の仕組みを調べてデバッグしたりしていた。echo のミドルウェアで Unit of work を実装できないかをプロトタイプ実装していた。

基本は次のように callback 関数を渡せばトランザクションに失敗したときにリトライもしてくれて便利なのだけど、いろいろ api サーバーの既存アーキテクチャの都合もあってこれは使えないことがわかった。

session, err := client.StartSession()
if err != nil {
	return err
}
defer session.EndSession(ctx)
result, err := session.WithTransaction(ctx, callback)

今日のバドミントン練習はエアシャトルでリフティングを10分、連続最大回数は322回だった。その後にショートサーブ30回、フットワーク10分の練習をした。リフティングは連続回数よりもラケットコントロールの質を求める練習に変えていく。昨日と同様、みなとのもり公園をジョギングで4週走った。fitbit によると 1.8km 走ったそうな。

プロジェクトマネージャーが手を動かすことの功罪

朝からお手伝い先の社内インフラサーバーが落ちていて待ち時間があったのでふと思い返してつらつら考えごとをしていた。

お客さんが選ばなければ、逡巡と葛藤の結果、最終的に私は品質を優先する

開発合宿の課題管理の雑談から引用

私はもっと仕組みを作るところに注力すべきだった。私自身がコンサル嫌いの、実務をやっている姿勢をみせてメンバーが参考にしてほしいという意識が強過ぎた。また開発は楽しいことから必要以上に手を動かし過ぎてコアな開発に入り過ぎたことで、自分がやらないと他のメンバーが担当しにくい体制になってしまった。「任せる」はずが「任される」ことになってしまった。バックエンドの品質は大事だから責任感もあった。もしかしたらお客さんが求める以上の過剰品質なモノづくりをしてしまったのかもしれない。そして、仕組みづくりの後はメンバーへ委譲すべきだった。いまメンバーへマネージャーを委譲しているが、マネージャーという業務はもともと得意でもなくこだわりもなかったがためにすんなりと委譲できた。

しかし、開発の方は得意分野、且つ好きであるために品質にこだわってしまう傾向があることを認識できた。そのことが裏目に出てしまった。これが自社プロダクトの開発ならばすべて自社の資産になるためにそれでもよかったかもしれないが、他社プロダクトでやってしまうと、自分の時間を必要以上に注ぎ込むことになってしまった。その結果、お客さんの信頼を得られてはいるものの、自社プロダクトの開発に着手できず、クロージングの時期が遅れて微妙な状況になってしまった。もしかしたら、お客さんもうちの会社との契約を終了できなくなってしまって困っているという考え方もできる。

rabbitmq の autoAck (noAck) の振る舞い

先週の続き 。id 連携のリクエストをし続けながら compose サービスを down させたときの振る舞いを検証する。理想的にはそれぞれのモジュールのサービスが graceful に振る舞って、それぞれの永続化する場所でデータが溜まってくれることを期待している。その1つがメッセージキューでもある。Persistence Configuration によると、rabbitmq のメッセージを永続化するには queue に対して durable の設定を行い、producer が送信するメッセージに対しても persistent の属性を付与すればよい。しかし、実際に検証してみると、サービスの再起動時にメッセージキューからメッセージが消失していることがわかった。consume メソッドに渡す仮引数に autoAck というパラメーターがある。コメントにもそれっぽいことが書いてある。

When autoAck (also known as noAck) is true, the server will acknowledge deliveries to this consumer prior to writing the delivery to the network. When autoAck is true, the consumer should not call Delivery.Ack. Automatically acknowledging deliveries means that some deliveries may get lost if the consumer is unable to process them after the server delivers them. See http://www.rabbitmq.com/confirms.html for more details.

ConsumeWithContext

autoAck という名前からメッセージを取得したら自動的にそのメッセージに対して ack を返すようなイメージで私は考えていた。しかし、どうやら consumer が subscribe して接続した時点で consume 扱いとなり、consumer がメッセージを実際に取得したかどうかに関係なく consumer の終了時にそのときに溜まっているすべてのメッセージが消失しているようにみえる。余談だが、rabbitmq のドキュメントにも noAck と autoAck という2つの用語が存在する。どうやらもともと noAck という名前だったのを autoAck という用語に変更したようにみえる。メッセージを永続化するには autoAck=false にしてメッセージに対する処理を完了した後に consumer が必ず ack を返すという実装にしないといけないことがわかった。このパラメーターは2年前から同じ設定だったので私がいま検証するまで誰もこの振る舞いに気付かなかったんやと驚いた。

部屋の掃除

19時に閉まる業務スーパーへ買いものへ行くために18時過ぎにお仕事を終えて、移動して買いものをして、炊飯開始して、ジョギングして、戻って晩ごはんを食べて、バドミントン練習をして、お風呂に入って、ストレッチして、なんとなくベッドに入って休もうとした。ここで22時半ぐらい。まったく眠れなくて寝室の掃除を始めたら、これが捗ってやる気が出てきて、部屋のレイアウト変更したりして少し片付けもできた。引っ越してからまったく進めていなかった部屋づくりが突発的に急に少しできた。これまでも時間がなかったわけではないが、まったくやる気がなくて手をつけられていなかった。それがなぜできたのかはわからないが、手をつけられていなかったことに手を入れられたことで心理的に楽になった気がした。明日も帰ったら少しだけ部屋づくりの作業をしようと思う。

今日のバドミントン練習はリフティングを5分、フットワークを10分した。久しぶりにリフティングしたら距離感が鈍っているかと思いきや、100回は簡単に超えられた。リフティングをするのも少し飽きてきたので他の練習もやっていこうと思う。練習前に無性にカラダ動かしたくなったので 1.8km ほどジョギングで走ってみた。

期日前投票

兵庫県知事選挙 の期日前投票へ行ってきた。元知事のさいとうさんも追い上げしているみたい。来週末が投票日になるので結果がどうなるのか楽しみでもある。

• 兵庫県知事選情勢、稲村氏わずかにリード　斎藤氏が猛追

2人の自殺者のうち、1人は告発された方でもう1人は次の優勝パレードの寄付金を募る企画の責任者だったと思う。表向き補助金のキックバックとは認められてはいないが、不可解なお金の流れがあるのでかなり黒に近い灰色にみえる。百条委員会が進むうちにこの疑惑の検証も進むのではないか？と当初は考えていたが、そうでもなくなっていないみたい。もしくはこれは副知事がやったことで知事の過失とはみられていないのかもしれない。

• 【独自】兵庫・斎藤知事の補助金キックバック疑惑 13金融機関の寄付額一覧を入手！

タスクをこなす日々

以前みた動画で 日々の変化を感じる のが大事だとあった。少し意識して普段やらないことをしてみたり、買いものするモノを変えたりしてみていた。またマンネリになってきたのでそのことを思い出していた。梅原さんの言う 義務感によって受け身の状態になってしまう 状態そのものである。

以前はやりたいことがいくつかあったし、そのための調べものも少しずつ進められていた。夏場は開発者としてお仕事のよくない部分を直すというところに集中したものの (その成果も十分に出た) 、一時期のその繁忙期をすでに過ぎていていまはそれほど忙しくないにも関わらず、心が空き時間を何に使うかということについてこない。いまのプロジェクトの課題に気付き過ぎてすべてに対応できない状況にストレスを感じているところも多少はある。そうであっても、新しいことを学んでいて楽しいとか、日々の生活に活気があるとか、そういう状態ではなくなってしまっている。5月頃は運動をして体脂肪を減らす日々が本当に楽しかった。それが当たり前になってしまったというべきなのか。2024年1月まで運動はほとんどやっていなかったのだから、運動をやるようになって単純に他のことをしていた時間を取られているという考え方もある。一方で運動によって健康にはなっているし、バドミントンという趣味や新たなコミュニティの土台づくりにもなっているから、これはこれでよい方向に変化したとも考えられる。

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

LT 会

午後から LT大会 with カメラマン に参加してきた。副業でカメラマンをやろうとしている方が LT 中にプロフィール写真になるようなものを撮ってくれるという。会社紹介などのスライドで使えるかもしれないと思って参加してきた。趣味で4-5年カメラを勉強しているというだけあって、機材や知識も備えていてよかったと思う。LT のネタとして先月お仕事でやっていた go のテスト改善の一環でカバレッジについての紹介をしてきた。サンプルコードは次になる。

• github.com/t2y/go-integration-tests-sample

終わってから軽く立ち飲み屋で飲んで若い人たちの話しを聞いていた。若い人たちは活気があってやりたいことも多くて、いまの私からみたときのモチベーションの在り方に違いがあるようにも思えた。たまに若い人たちの中に紛れて話しを聞くだけでも自分が失くしたものを気付くきっかけになるようにも思えた。若い人たちはどんどん挑戦してがんばってほしい。

ストレッチ

今日は身体的に疲れているというよりも、開発合宿から続くお仕事のせいか、精神的に疲れていて、2週間ぶりにトレーナーさんと雑談するだけでも気分転換になってよかったと思う。今週はお仕事に集中していてまったく運動していないため、足の張りなどはほとんどなくなっていた。一方でバドミントンの試合をしてこけたときに痛めた腰だけはまだ張りが残っていてなかなか治りきらないことも実感した。今日の開脚幅は開始前149cmで、ストレッチ後155cmだった。

ストレッチを終えてから買いものしてオフィスへ戻って軽く作業していた。

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

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日は先週末の開発合宿のふりかえりをした。

• 1週間前ぐらいに参加者を集めて事前打ち合わせをして過ごし方の共有をした方がよかった
• 周りと雑談してしまうので資料を合宿中に作るのはほとんど時間を取れない
• もう3回目なのでお風呂へ入るのにも慣れが出てきてお気に入りの外湯へ行くようになった
• 人数はどのぐらいが適正か？
  • 5人という人数は中途半端だったように思える
  • 8人は多過ぎた気はするから6人がちょうどよいのではないかと思える
• 周辺の体験イベントにみんなで参加してみるのもよいかもしれない
  • あらかじめ希望をとっておく
• 発表の時間を初日と2日目に分割したのはよかった
  • 夜に発表を固めなくてもよい
  • お昼でも夕方でもみんなが集まっている時間帯にさらに分散させるのがよさそう

細かいところはいろいろあるけれど、覚えているうちに意見をもらった。いつもはらさんが来てくれるから私の負担が低くなり本当に助かっている。

compose サービスの停止の振る舞い

昨日の続き 。それぞれのサービスに depends_on を指定することで依存関係を定義できる。サービス起動時と停止時に依存するサービスが先に起動または停止するように順番を制御してくれる。但し、起動時のデフォルトはコンテナ起動をトリガーにするため healthcheck などを指定しないと厳密にサービスが起動しているかどうかはわからない。

• Control startup and shutdown order in Compose

compose サービスの起動は次の2つのコマンドがある。

• up: すべての依存関係を調べてコンテナサービスを起動する、停止しているコンテナがなければ作成する
• start: 停止しているコンテナのみを起動する

基本的には up を使っておけば運用上の問題は起きない。start を使う理由がなければ up を使うといった感覚でよい。一時的なメンテナンスなどで stop を使ってコンテナを停止し、そのコンテナだけ起動すればよいことがわかっていれば start を使った方がオーバーヘッドが少ないといったメリットはあるだろう。up と start の違いはそれほど気にしなくてもよい。

次に compose サービスの停止は次の2つのコマンドがある。

• down: コンテナを削除する、関連するリソース (volume や network) もすべて削除する
• stop: コンテナを削除せずに停止する

運用上どちらか一報を覚えておくなら down を使えばクリーンに再起動できると言える。コンテナが使うイメージのバージョンアップをするときなどはコンテナを削除する必要があるから down する方が手間がいらない。stop で停止したコンテナがあると、up でも start でもバージョンを自動的にあげてくれたりはせず、ただ停止したコンテナを起動するといった振る舞いになる。そのため、バージョンアップをするときは stop で停止した後に rm でコンテナを削除する必要がある。それなら最初から down で削除してしまってもよいと言える。compose の logs コマンドを使うと複数サービスのログを1つのストリームで監視できる。この状態で stop や down を実行してどういった振る舞いになるのかを検証できた。

• Docker compose stop VS down

$ docker compose logs -n 3 -f

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

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万円ほど会社の経費を使ったことになる。予算通りではあるが、改めて精査してみるとインフレの影響で食費や宿泊費のすべての値段が上がっていることを実感する。

バドミントンの予定登録

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