今日のバドミントン練習はリフティングとシャトルキャッチを30分、ながいさんと打ち合いを30分した。1時間近くバドミントン練習をしていたことで歩数で言えば5千歩相当の運動になった。バドミントンは激しい運動ではないものの、わりと動き回るので有酸素運動としても優等生だと思う。よい感じにカロリーを消費する。

社内ハンズオン

社内向けハンズオンの2回目。前回の社内ハンズオン 。いまの開発フェーズの機能開発が落ち着いたのでハンズオンを実施して ui などのレビュー会も実施した。朝10時半から始めて、お昼休みをはさみつつ、16時頃までやっていた。私はハドルでつないで聞きながら自分の作業をやろうと思っていたものの、なにかしらハンズオン会場の会話や質問を聞いていると、その回答や背景などを slack に書いたりして注意力が取られてあまり自分の作業はできなかった。みんなでわいわい検証したり、プロダクトへのフィードバックや意見が出て楽しかった。

いそがみ体育館お休み

ながいさんとバドミントン練習する前に筋トレしようと早めにお仕事を切り上げて向かったらお休みだった。偶数月の第1火曜日が休館日らしい。それはわからんやろと帰ってきてから google カレンダーに登録した。2ヶ月ごとの第1火曜日の繰り返し予定という設定は google カレンダーで用意に登録できる。次は12月3日、その次は2月4日・・・今後はこの失敗を回避できるはず。

いそがみのバドミントン練習

スーパーで買いものして家に戻って晩ご飯を作って食べてから20時半にいそがみ公園へ戻る。21時半まで約1時間、バドミントンの練習をした。リフティングやシャトルキャッチの練習をしていて、ながいさんが来られてから打ち合いをしてみた。街灯の隣でやればシャトルはみえなくはないけど、体育館で行うような集中したラリーにはなりそうもない。それは暗くてシャトルがみえにくいから。軽い運動で流す程度ならぎりぎりできるかもしれない。昼間と夜間で練習してみて、左右のシャトルの変化は暗くても把握しやすいが、前後のシャトルの変化は暗いと遠近感をつかみにくい。夜間の方がリフティングが難しいのも微妙に遠近感が狂うから。ラケットコントロールがうまくなればブレずにシャトルを空中に上げられて遠近感を気にせずにリフティングできるようになるかもしれない。

昨日からアウトドア用の メイビスフィールド と メイビスフィールドII の、2つのシャトルを実際に使っていて、その違いを比べてみた。結論からいうとメイビスフィールドIIの方が性能がよいようにみえる。メイビスフィールドIIの方がシャトルをうったときの反発力は強く、軽い力で速く遠くへ飛ばせるように感じる。初期モデルに改良が施されていることが明らかに伺える。一方で初期モデルが不要かというとそうでもなく、リフティングやシャトルキャッチの練習をするなら反発力は必要ではないから跳ねない方がラケットコントロールが適切にできているかの練習になりそうな気もする。ラケットの中心 (スィートスポット) でシャトルを捉えられているか、シャトルのコルクをどの角度で捉えているかの感覚を養うにはあまり反発しない方が感触を確認しやすいようにも思えた。反発しないから強い打球をうつ練習にもなる。適材適所で使い分けようと思う。

ほかに LED ライトがついた光るシャトルというのも売っていて気になっている。電池交換は不可で数時間から数十時間ほど使えるらしい。屋外で行う エアバドミントン というのもある。風の影響を受けにくいエアシャトルを使う以外はバドミントンと大差なさそう。バレーとビーチバレーのような関係？これらのシャトルも近いうちに買ってみて試してみようと思う。

今日のバドミントン練習はリフティングを10分した。連続最大回数は70回できた。シャトルを上に放り投げてラケットでキャッチする練習も10分やってみた。昨日よりは少しうまくなった気がした。それでも5-10回に1回ぐらいの頻度。なかなか難しい。

最後の厄介なリファクタリングを完了

一昨日から着手しているリファクタリング作業に朝から着手していた。一晩寝かせた効果だと思うが、昨日の夜にノーアイディアだった設計もさくさく進んでシンプルに実装できた。無意識の脳の働きがすごい。13時頃には実装を終えてマージリクエストを作るのに約1時間。なぜリファクタリングするのかの目的と意図をマージリクエストに書いた。最終的にはこの issue の対応は丸2日かけてコードを書き直した。これが早いのか遅いのか、もう私にはわからなくなってしまっている。昔の方が体力と集中力がある分、土日で終えられたかもしれないし、いまの方が経験がある分、昔よりも高い品質のコードを短い時間で書いているのかもしれない。

老いは誰にもやってくる 歳を取れば技は練れる 駆け引きにもたける だが圧倒的なパワーに対して対抗しきれない日は必ず来る

幻海師範

知人が「プログラミングは長い間やっているとわかるようになる」と表現していてその通りだなと私も思う。プログラミングに限らず習熟によってスキルアップする対象はだいたい同じなのかもしれない。いまバドミントンの練習を始めたばかりだが、1年後にはいまより少し上手くなっていると嬉しい。

今日のバドミントン練習はリフティングを昼間に10分、夜に10分、壁当てを10分した。連続最大回数は82回できた (昼間) 。昼間にやってみたら夜に街灯の隣でやるときとの違いに気付いた。ほんのそよ風でもシャトルは風の影響を受けるので空中で少し流れたりする。その微妙な変化が暗いとみえにくい。昼間にリフティングをやってみたことで真っ直ぐ落ちてこず微妙に風で流れていることを観察できた。あとシャトルを高くあげた方が重力による加速がつくので真っ直ぐ落ちてきやすくなるかもしれない。

ポータブルネット

外でバドミントンができる準備をしていく。調べてみたらいくつか製品の候補がみつかる。価格帯は3千円から1万円ぐらいの幅。最終的には YONEX の ポータブルネット(バドミントン用).AC334 に決めた。なにかの記事で初心者は製品の良し悪しの判断が難しいから YONEX を買っておけば間違いないと書いてあった。amazon で購入すると9千円ほどだった。土日の昼間に公園へ持っていって練習できるかもしれないし、バドミントン設備がない体育館を借りて練習するのもよいかもしれない。たまたま組み立てしている動画をみつけた。一緒にクリップを用意しておけば幅の調節もできるみたい。

お昼からずっとコードを書いてた

昨日は家に帰る途中でバドミントンの練習場所を探したり、軽く練習をしたりしていて、1時過ぎに帰ってだらだらして3時頃に寝たせいか、少し寝坊してお昼頃にオフィスへ行った。ちゃんと休日にオフィスへ行ってお仕事できるぐらいには体調 (モチベーション) が回復した。病気だったわけでもないが。本当は今日中にマージリクエストまで作りたかったが、ラストワンマイル的なところがなかなか煩雑で24時過ぎまでやって明日に持ち越すことにした。寝ているときに無意識で設計するから明日にした方がコードの品質も上がるだろうと、既存のコードのロジックの確認や設計のヒントになりそうなことの調査をして終えた。

日曜日にお仕事をしたのは1ヶ月ぶり。しかも12時から24時と途中で晩ご飯休憩をはさみながらほとんどフルタイムに働いていた。他人のコードのリファクタリングだから私が直さないといけない積極的なインセンティブがない。この開発フェーズの最後の issue だったのと、私がコードレビューして知ってしまっているからやる・やらないを選択しないといけない。やらなくても誰からも非難されないかもしれない。逆に言えば、だからこそ、やらないといけないなと昨日、決心した。覚悟したからどれだけ労力をかけようが気にならなくなった。そんな休日のモチベーション管理。

今日のバドミントン練習はリフティングを30分した。連続最大回数は27回だった。

最後の厄介なリファクタリング

10時頃に起きて11時にはオフィスへ来て作業をしていたと思う。昨日ジョギングと筋トレしたから寝起きジョギングはやめて普通にオフィスへ行って作業していた。この issue はどこまでリファクタリングするかの決めの問題もあり、少し寝かせてあった。私のもてるスキルを駆使して思い切りやることを決めて土日で大半を終わらそうと思う。いくつかの葛藤と逡巡を振り払って着手はした。昼間は既存のコードの本質的な問題の分析、再設計のための要項の調査、軽くコードを書きながらの感触の確認などをしていた。その後、ストレッチに出掛けて戻ってきてから続きをやるつもりが、いろいろ雑務をやっていたら22時ぐらいになってしまってまた明日でいいやと諦めた。モチベーションが足りない。一回休み。

ストレッチ

昨日、久しぶりに筋トレをして夜は全然平気だったのに寝て起きたらあちこち全身筋肉痛でストレッチもかなりきつかった。悪い痛みではないから筋肉をほぐしてもらった感じになる。今日の開脚幅は開始前146cmで、ストレッチ後153cmだった。筋肉痛だから硬めのように思えたが、数字だけ比べたら普段とそんなに変わらなかった。

トレーナーさんと自民党の総裁選挙の話題になって、一通りニュースをみて私も思うところはあったものの、政治的な話題のやり取りする場所がないから誰と話すこともないだろうとしまいこんでた矢先、トレーナーさんから話題が出てきたのでいろいろ話してみた。石破さんは自民党内で嫌われているから決戦投票で勝てないだろうという大方の見通しを覆したのは見事だったし、石破さんは良識なリベラル、且つ金融所得課税の強化に前向きだったりもするから市場の反応は悪い。これまでは総理大臣が変わったタイミングはご祝儀相場のように歓迎されることが多かったのに対して、月曜日は株価が急落するようにみられている。これほど市場からネガティブな反応が出るのも珍しいなという所感。余談だが、私はいまどちらのポジションもとっていないので株価が下がってもあまり影響はない。個人的にはシステムへの理解が深いという側面だけで河野さんを応援しているものの (一方で官僚に対するもの言いがパワハラ的なところがマイナス)、今回は後ろから2番目と不人気だった。日本では自民党総裁=総理大臣なわけではあるが、政治家が影響力をもつタイミングというのは本当に難しい。石破さんも5回目の総裁選ということで悲願が叶ってよかったんじゃないかと応援したい。

ひとりでできるバドミントンの練習

ストレッチを終えてから 購入したラケットを受け取り してきた。試し打ちではないけど、買ったばかりで使ってみたいから KALIDIA チャンネルから1人でできる練習を探してみた。次の練習はラケットとシャトルとの距離感を掴むための練習になるという。なるべく日課としてしばらく続けてみたい。

1. シャトルのキャッチ
2. バドミントンの技を3つ行う
   • スピンネット
   • ミニクロスネット
   • ロビング
3. リフティング
4. 屋外で向かい風に向かってロビングを打つ

今日は簡単な issue を2つ fix して作業の区切りがよかったので17時にはお仕事を終えた。この開発フェーズで対応する厄介な issue はあと1つだけ。それをもって私の開発者としての集中時間も一区切りとする。これ以上は自分の時間を開発に費やさず、普段通りのお仕事ペースでいこうかなと決めた。

ラケット選び

先週やまとさんに教えてもらった バドミントンプロショップチャンプ というお店へ行って店員さんにラケット選びの相談をしてきた。amazon やオンラインで買いものするのが当たり前となった昨今、リアル店舗で店員さんに相談してモノを買うというのはコンサル料も込みだと思うようになってきた。初心者向けのラケット選びは、ラケットを簡単に扱えることを前提として次の特徴が大事だという。

• ラケットの重さが軽め (4U: 80-84g が標準)
• 重心が手元に近い方にある (これをヘッドライトと呼ぶ)
• シャフトが柔らかい

一方で中上級者になると、フレームの先端側にあるヘッドヘビーが好まれるようで、その中間のバランスのよいタイプをイーブンと呼ぶ。ラケットの重さも重い方が強く返せるが操作が難しい。練習して上達したらヘッドヘビー側のラケットを選ぶようになっていくことを考慮すると、最初からヘッドライトではなく、イーブンでよいのではないか？という考え方もある。そしてイーブンを使っていてスキルアップして物足りなくなったら、そのときにヘッドヘビーのラケットを買い替えたらよいとのこと。事前調査した段階ではヘッドライトでよいと私は考えていたが、店員さんと話していてイーブンにしようと改めた。イーブンのラケットで製品の候補が3つあって最終的に アークセイバー3. ARC3 に決めた。このお店では12,320円だった。他候補のアークセイバー1だと1万円台だった。主な違いはフレームが台湾製か日本製かになるという。ラケットはフレームの品質が重要らしく、その違いを私がわかるとも思えないが、2千円なら別にいいかと思ってアークセイバー3にした。ガットを張るために受け渡しは翌日になるとのこと。

• 【ヨネックス】アークセイバー3をレビュー！初心者に向けたバド上達ラケット！

お店で買ったものの明細 (税込) 。ついでに練習用シャトルも1ダース買ってみた。

• ラケット: 12,320
• ガット + ガット張り工賃 : 2,150
• グリップテープ: 350
• エアロセンサ200 (1ダース): 2,700

いそがみの筋トレ

前回の所感 。気付いたら約2ヶ月ぶり。早めにお仕事を終えて十分に時間もあったから行ってきた。トレーニング器機の重さと回数を 筋トレの記録 に付けていた。2ヶ月ぶりだから前回の数値を覚えていないが、記録をみながら前回の数値を引き継いで筋トレできた。ちょっと辛めではあったものの、意外と同じ数値でこなすことができて、筋肉を増やすのは大変なものの、逆にそんな簡単に減りもしないということを確認できた場面でもあった。また週に2回ぐらいのペースで通えればよいなと思う。

fitbit 交換とサポート対応

出張へ出掛ける前に 故障したデバイスの返品手続き をしていた。今日ちょうど交換用の新しいデバイスが届いた。サポートにトラブルシューティングの連絡をして、メールで購入証明や送り先の必要情報をやり取りして、1週間ほどで交換用デバイスが届くといった無駄のない効率的なサポート対応だったと思う。私の経験則においても、お客さんのサポートはトラブルそのものが問題ではなく、トラブル発生後に適切な対応をしてくれるが大事になる。今回のケースにおいても fitbit の故障そのものにまったくネガティブな印象はない。うちの会社もトラブルが起きたときはその原因の如何によらず、コストの損得に関わらず、そのとき出来ることの対応に努めることを法人の基本的な理念としたい。そんなことは社員を雇うときに考えることでもあるが。

バックエンドで非同期のバッチ処理を実装してサーバーが shutdown したときに実行中のバッチ処理も安全に止めないといけない。

context でキャンセルするのは簡単だけど、非同期で動いている goroutine が中断してから終了したことを main プログラム側で待つ同期をどう実装しようか悩んでいた。たまたま 【Go】Contextの魅力を感じる の記事をみたら sync#WaitGroup と組み合わせたサンプルコードがあって、これまでも sync#WaitGroup を使ったコードを何度も書いてきて知っていたはずなのに context と組み合わせるという発想はなかったなと気付きを得た。それからライブラリとして汎用のバッチ処理の controller を実装した。

type Controller struct {
	ctx    context.Context
	cancel context.CancelFunc
	wg     *sync.WaitGroup
	mu     sync.Mutex
}

func (c *Controller) Register() (context.Context, *sync.WaitGroup) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.wg.Add(1)
	ctx := context.WithValue(c.ctx, ctxKey{}, 0)
	return ctx, c.wg
}

func (c *Controller) Stop() {
	c.cancel()
}

func (c *Controller) Wait() <-chan struct{} {
	c.mu.Lock()
	defer c.mu.Unlock()
	quit := make(chan struct{}, 1)
	go func() {
		c.wg.Wait()
		slog.Debug("completed to wait group in batch.Controller")
		quit <- struct{}{}
	}()
	return quit
}

func NewController(parent context.Context) *Controller {
	ctx, cancel := context.WithCancel(parent)
	return &Controller{
		ctx:    ctx,
		cancel: cancel,
		wg:     new(sync.WaitGroup),
	}
}

parent の context でキャンセルさせることもできるし、この controller の api からキャンセルさせることもできる。

この controller を使うアプリケーションのコードは次のようになる。

c := batch.NewController(ctx)

func() {
	ctx, wg := c.Register()
	defer wg.Done()

    for {
	    // do something
        select {
        case <-ctx.Done():
            slog.Debug("canceled", "err", ctx.Err())
            return
        default:
        }
    }
}()

timer := time.NewTimer(10 * time.Second)
select {
case <-timer.C:
	slog.Debug("expected to complete waiting, but occur timeout")
case <-c.Wait():
	slog.Debug("completed to wait")
}

context.Done() に習って Wait() が channel を返すことで timer と組み合わせて、バッチ処理の中断を待たずに終了するといった制御もできる。後になってふりかえると、timer の制御も Wait() メソッドに入れてしまってもよい気もするが、それは呼び出し側の要件によって変わってくるからこのままの方がライブラリのコードの見通しがよくてよい気もする。朝から設計して、昼間に実装して夕方にテストを書いて、帰りの新幹線でアプリケーションに組み込みしていた。1日でちゃちゃっと作ったわりにはよく出来たと思う。

昨日の定例会議で csv ファイルのエンコーディングの話しになって excel 2016 以降では utf-8 で csv ファイルを保存できるようになった。もう cp932 対応しなくてよいといった話題が出た。そのときにうろ覚えだったものの、excel は byte order mark (bom) を付けていた気がして、実際にファイルを作ってもらったらそうだった。bom の有無は file コマンドや od コマンドでなどで調べられる。

$ file book1.csv
book1.csv: Unicode text, UTF-8 (with BOM) text, with CRLF line terminators

ファイルの先頭に 0xef 0xbb 0xbf の3バイトがつく。

$ head -1 | od -t x1 book1.csv
0000000    ef  bb  bf  68  65  61  64  65  72  31  2c  68  65  61  64  65
0000020    72  32  2c  68  65  61  64  65  72  33  2c  68  65  61  64  65
...

印字可能な文字ではないため、テキストにするとわからないが、byte 列だと bom が付いているのがわかる。16進数の 0x68 が ‘h’ になる。bom がついていると header1 という文字列比較したときに別の文字列になってしまうので取り除かないといけない。

文字列: 'header1'
byte列: 'efbbbf68656164657231'

いろんな対応方法があると思うが、so の回答 でみつけたこの方法がコードの見通しもよくて気に入った。次のように io.Reader をラップするようなコードになる。

func newBOMAwaredCSVReader(reader io.Reader) *csv.Reader {
	transformer := unicode.BOMOverride(encoding.Nop.NewDecoder())
	return csv.NewReader(transform.NewReader(reader, transformer))
}

Transformer という仕組みがあって、準標準ライブラリの golang.org/x/text/encoding で実装されている。so の回答をみただけでコードを追加するのもよくないかと思って unicode#BOMOverride が返す bomOverride transformer のコードを読んで把握した上でテストを書いてマージリクエストを送った。実際の変換処理は次のようなもの。

• fallback として encoding.Nop を使う
  • ソースの byte 列をそのまま使う (実際には変換しない)
  • https://pkg.go.dev/golang.org/x/text/encoding#Encoding
• 最初に呼ばれたときに d.current (fallback) をセットして、2回目以降は fallback が呼ばれる
• 与えられた byte 列が 2byte 以上のときに bom のチェックを行う
• bom があるときはそのバイト数を読み飛ばして d.current (fallback) で変換する

func (d *bomOverride) Transform(dst, src []byte, atEOF bool) (nDst, nSrc int, err error) {
	if d.current != nil {
		return d.current.Transform(dst, src, atEOF)
	}
	if len(src) < 3 && !atEOF {
		return 0, 0, transform.ErrShortSrc
	}
	d.current = d.fallback
	bomSize := 0
	if len(src) >= 2 {
		if src[0] == 0xFF && src[1] == 0xFE {
			d.current = utf16le.NewDecoder()
			bomSize = 2
		} else if src[0] == 0xFE && src[1] == 0xFF {
			d.current = utf16be.NewDecoder()
			bomSize = 2
		} else if len(src) >= 3 &&
			src[0] == utf8BOM[0] &&
			src[1] == utf8BOM[1] &&
			src[2] == utf8BOM[2] {
			d.current = transform.Nop
			bomSize = 3
		}
	}
	if bomSize < len(src) {
		nDst, nSrc, err = d.current.Transform(dst, src[bomSize:], atEOF)
	}
	return nDst, nSrc + bomSize, err
}

自分で実装してもなにも難しくないけど、すでに実績のあるコードがあるならそれを再利用した方が保守コストを削減できる。

同期飲み会

新卒入社した会社の同期との飲み会。2ヶ月前と同じメンバー で飲んできた。4人で飲む予定が、また1人が障害対応でドタキャンになったから3人で飲んでた。日本酒原価酒蔵 という、おいしい日本酒を原価で提供するお店があるみたい。プレミアム飲み放題プランだったのでよいお酒をいろいろ飲み比べできた。どれもおいしかったし、ちょっとずついろいろ飲み比べできておもしろかった。飲み放題メニューに神戸のお酒がなかったのがよいことなのか残念なのか。前半は辛口の日本酒を飲んで、だんだん酔っ払って味がわからなくなるから、後半にコクや甘みの強い日本酒を飲むとおいしく飲めると教えてもらった。本当にその通りで日本酒の飲み方のよい勉強になった。お店で飲んだお酒のカードがもらえる。酔っ払って忘れてしまっても後で思い出せる。

特徴的なお酒で記憶に残っているもので 三井の寿 がスラムダンクに出てくる三井寿に由来して命名されていて、その背番号である14番と同じアルコード度数14度、日本酒度 (辛口甘口の度合いを表す) +14 と意図的？にあっているとのこと。日本酒の中ではトップクラスの辛口らしい。たしかに過去に私が飲んだことがないキレだった。もう1つは 讃岐くらうでぃ という、カルピスのような風味に近い珍しいお酒。甘いので後半に飲むとよい。うちらは酔っ払って訳がわからなくなってきたときに口直しのように飲んでた。そういう飲み方をするものかどうかはわからないが、飲みやすいのでついつい飲んでしまい、さらに酔ってしまう典型的なお酒。同期飲みは記憶をなくす感じで飲む。この歳になってこんな飲み方する相手いないなと思うとまた楽しい。

昨日はテンションがあがらなくて前泊をやめて久しぶりに始発の新幹線にのって東京へ向かう。ゼロ時頃まで作業をして帰って晩ご飯を作って食べて、お風呂入って、適当に時間を潰したり仮眠したりしているうちに5時頃になって出掛けた。新幹線でもなるべく寝ておこうと思ったものの、あまり寝付けなくて仮眠程度だったと思う。過去の経験だと、始発でいくと夕方には眠気と疲労でしんどかったりするものが、休日明けのせいか、まったくしんどくなかった。なんか体調管理もおかしい。

いつも通りマイルストーン最終日の定例会議に出席して、そのスケジュールにあわせて issue を2つ fix して、可もなく不可もなく特徴のない1日の働き方だった気がする。

お昼ご飯を食べる余裕がなくて夜にまとめて食べた。この前チームランチで行った ハルピン という中華料理屋さんを気に入っていて、その後も出張のときに必ず1回は行くようになった。晩酌セットというのがあって小皿3品 + 餃子3個 + 飲みもの1杯で1330円というコース。たとえば、小皿の1つは次のよだれ鶏のようなもの。

餃子はこんな感じ。

私はこの晩酌セットに単品で料理をもう1つ頼む。今回は定番料理の鶏肉のカシューナッツ炒めを食べた。おいしかった。

2000円ちょっとで一杯飲んでいくつか料理も味わえて満足、且つコスパもよい。今後も2泊するうちのどちらか一方の晩ご飯はこのお店になる可能性が高い。

朝から起きてはいたものの、午前中は漫画読んでだらだらしていて、お昼からオフィスへ行って作業していた。軽くコードを書いてリファクタリング後の機能拡張の issue を2つ fix した。先週いっぱいリファクタリングして内部設計を改善したので、その先にある機能拡張は容易ですぐに対応できた。本当は今晩から移動して前泊する予定だったが、今晩のホテルを予約してなくて新幹線も遅れたりしている状況だったので明日の早朝に変更した。スマートEX 便利。

近況報告の資料作り

昨日やろうと思っていたものの、休んでいたので今日作っていた。issue の数字だけみればまずまずの実績ではある。意図していた機能開発も動くレベルでは実装できていて完璧ではないが悪い状態ではない。先週と今週は3連休が2回続いて、9月は祝日が2日あって稼働時間が少ないことを考慮すると、十分と言える気もする。今月は若いメンバーの開発したモノをレビューしたりリファクタリングする時間を多くとった。その過程で 相手に責任を投げてしまわない働き方 の考察をする機会にもなった。若いメンバーがそうなるためには経験や時間を必要とするのはわかりつつ、自律的な働き方への取り組みとしてマネジメント側からできることはあるのか、もしくはただ待つだけなのか、そういう話題も近況報告のスライドに入れてみた。

故障した fitbit の発送

サポートとやり取りして デバイス異常になってしまった fitbit を返品することになった。メールで添付されてきた返品票を印刷して、壊れたデバイスと一緒に梱包してファミリーマートへ持っていった。発送用の QR コードもメールに添付されていた。ファミリーマートの 宅配便・配送 サービスで読み取ったレシートをレジへ持っていって、店員さんから配送用のラベルを受け取って梱包物に貼り付けて発送できた。先方で返品確認してから交換用デバイスを送ってくれる予定。

昨日はいろいろ活動して疲れてしまったのと、雨降りもあってだらだらしていた。

土曜日はだらだらしがちなのが、今日は朝から起きて活動できた。お昼に少しコードを書いて、夕方にストレッチして、夜はカフーツさんへ行ってきた。よい一日になった。

みなとのもりの運動

前回の所感 。起きてからシャワーを浴びようとしたときにふと軽く走ってこようと思い立って9時過ぎから公園へ出掛けてトラックを3周ほどジョギングしてきた。公園に近いマンションに引っ越したことのメリットを活用できた。運動するとそれだけで報酬系を刺激して気分がよい。これまでは起きてもしんどくて出掛ける余裕がなかった。ジョギングへ出掛けられるぐらいには体力が回復してきたのかもしれない。来週も朝からジョギングへ出掛けてみたい。

ラケット選び

• バドミントンラケットの選び方
• バドミントンラケットのヘッドライトラケットとは？最新のおすすめ16選も紹介！

うちらの業界で言えば未経験者が「どのプログラミング言語を学べばよいですか？」という質問の答えになる。私なら一番無難なのは typescript で、データ分析や汎用用途で学ぶなら python、バックエンドが好みなら go といったようにお奨めする。こういう答えのない問いは経験者にこれと決めてもらうのがよい。ラケット選びのサイトをみてもパラメーターがいくつかあるのは理解できたが、最初にどのラケットを選択してよいかがわからない。経験者のやまとさんに相談してみた。エントリーモデルの、価格帯は1万円前後のものでよいという。振った感じで合う合わないがあったりするから、お店へ行って店員さんに相談したり試し打ちさせてもらったりするのがよいとのこと。相談に乗ってくれる近所のバドミントンショップを教えてもらった。モチベーションを上げていく意図で道具を揃えていくのもよいと思う。

ストレッチ

水曜日にバドミントン をしたことによる筋肉痛が残っていた。腰や背中のあちこちが痛かった。あと右腕や右肩もバドミントンでラケットをたくさん振ったことによる影響で張りや硬さがみられた。運動した張りをストレッチでほぐすようなサイクルになれば健康にもよさそうにみえる。今日の開脚幅も開始前149cmで、ストレッチ後153cmだった。

カフーツさん訪問

ストレッチを終えてからビールとおつまみをもって久しぶりにカフーツさんへ行ってきた。先週末にだらだらしてしまったからその反省も踏まえて出掛けることにした。ちょうどバドミントンのイベントをよく手伝ってくれている方がいて、あちこち友だち探しをしているようにみえるのでその一つとしてカフーツさんを紹介していて 以前にもキャンプ飯部 に参加していた。知っている人がいないとなかなか参加しにくいと伺っていたので一緒に参加してきた。しかし、参加者内で女性1人なってしまって、これはこれで居心地が悪そうにもみえた。他に女性の参加者が何人かいそうなカフーツさんのイベントを紹介した方がよかったなと反省した。

書店というビジネスの在り方について、いとうさんと議論していて、この本を読めと 取り戻す旅 という本を貸してくれた。本当は自分で買ってよいのだけど、なんとなくそのまま借りてみた。読んで内容がよかったら買ってみようと思う。本書では Culti Pay(カルチペイ) という取り組みをしていて みんなの銀行 を介して著者に投げ銭のようなこともできるという。新しい価値観に触れるという意図でも読み終えた後でやってみようと思う。

• カルチペイはただの送金システムではなく新しい経済圏を作っている：今日のアウトテイク#310（2024-09-23）