2時半に寝て５時過ぎに起きた。それから二度寝して7時に起きた。
今日の運動はレッグレイズ(椅子),腹筋ローラー,腕立て,散歩をした。統計を 運動の記録 にまとめる。
トランクルームの契約
家電を購入すると大きな箱が付いてきて物理的にその置き場所がない。箱を捨てるという戦略もあるが、オリジナルの箱があると引っ越しや売買／処分するときに便利なのでできれば残しておきたい。これまでデスクトップマシンの箱やオフィス備え付けの椅子などをマンションの部屋に保管したりしていたけど、家電の箱が増えてくると邪魔になってきて、トランクルームを借りることにした。面倒なのであまり調べていないが、スペラボ というサービスの屋内型トランクルームをレンタルすることにした。0.7畳で6,450円/月(税込)になる。会社の経費だしこのぐらいの金額ならいいかと思って、朝から内見に行って問題なさそうなので即決した。
ホットクックレシピの公開
ホットクックのレシピをどこかに整理したい。スマホ上でも調理しながら簡単に確認したいとなると web よりもアプリの方がよい。そこで evernote から移行した upnote に書くことにした。実際に調理してみて、デスクトップマシンでレシピを編集・整理して、写真はスマホアプリからアップロードするといった使い方ができる。View shared notes によると、ノート単位で web 公開もできる。試しに次のレシピを公開してみた。ノートブック単位で公開設定して一覧ページがあるともっとよいが、その機能はないみたい。公開リンクを作成する一手間はあるけれど、そんなにレシピノートを書くわけでもないから気にはならない。
ホットクック調理は材料入れてボタン押したら終わりではないか？と思うかもしれない。いや、そうでもないようだ。たしかに材料を内鍋に入れてボタン押したら人間ができることは何もない。だからこそ、ボタンを押す前の過程が大事になってくる。どんな切り方をするのか、素材のサイズはどうか、初期配置はどうか。例えば、豚ロース肉の生姜焼き用を買ってきて、適当に切って3枚4枚重なった状態で投入したらそのままの状態で出来上がった。かき混ぜ棒があるからうまいこと豚肉もバラけるだろうと期待したが、ぴったりくっついているようなお肉をバラかすほどのパワーはないようだ。人間が最初からバラかした状態で内鍋に投入すると、出来上がりのときに豚肉のかたまりがなくなってよいと思う。
あと気付いたこととして、野菜もお肉も素材を少し小さめに切った方がおいしいように感じる。というのは、ホットクックは圧力鍋ほどの火力で調理しない。圧力鍋に慣れていると、少し大きめに切っても原形がなくなって溶けてしまったり、出来上がり時点で原形があっても混ぜたりしているうちに角がとれて、どんどん小さくなっていく。小さくならなくても口の中でとろけるので大きいままでも問題ない。相対的にホットクックはそこまでの火力はないから、小さめで味が染み込むような出来上がりになるため、小さめに切っても原形は保ったままで溶けてなくなってしまうことはない。これは良い悪いではなくて、それぞれの製品の特徴と言えるだろう。ホットクック調理は素材を小さめに切るというのが、いまところ、私が作ったレシピではうまくいっている。ホットクックでは、小さく切った複数の素材をほお張って食べるのがおいしい。
go-ldap への context 導入の考察
go-ldap の issue は subscribe しているので、たまたま initial cut of context support #406 の draft pr のコメントに気付いた。過去に context を導入しようとして途中で断念した残骸みたいな pr になっている。いまの go の api は context を受け取るのが当たり前になっているので確かにほしいというのは理解できる。
代わりに私がやってみようかとソースコードを読んでみた。オリジナルの draft pr は client の interface に WithContext なメソッドを追加しようというもの。go の context の扱いとしてもっとも基本的なもの。それでもよいけれど、net/http の実装はどうなっているのかを調べていたら Request 構造体のメンバーとして context を保持していることがわかった。このやり方は原則のルールに反するものだけど、context を状態として扱わず、限定的な用途にのみ使っている。これは既存の interface を変えずに context 導入をしようという意図があると推測する。この考え方でいくと、go-ldap の Request 構造体に context を保持するように変更する方が既存の API の変更を少なくして net/http の Request も同様にやっているからと説明もしやすいように思えた。
type Request struct {
...
// ctx is either the client or server context. It should only
// be modified via copying the whole Request using Clone or WithContext.
// It is unexported to prevent people from using Context wrong
// and mutating the contexts held by callers of the same request.
ctx context.Context
...
}
今日のところは go-ldap と net/http のソースコードを読んで設計をしていた。また明日余裕があったらサンプル実装してみる。