Posts for: #Go

1日を通して歩きまくった日

#founding  #go  #event  #kobe  1日を通して歩きまくった日

今日の運動は散歩をした。統計を 運動の記録 にまとめる。

オフィスの書類整理

午前中はいろいろ不要なものを捨てたり書類のファイリングをしていた。法人決算の申告書類やその年度の保管書類などもクリアブックにまとめた。個人の書類と会社の書類がオフィスの机の上で散乱していて、過去にはそれが 公正証書の正本を紛失する ことにもつながった。少し片付いたものの、まだ個人の書類をどう片付けてよいかの結論が出ていない。自宅に置くのもよいが、書類を扱う事務作業をオフィスでやることが多いため、個人の書類もオフィスにある方が効率だけ考えたら都合がよい。GW のお休み中にオフィスの書架の整理などもしたい。

LT 発表

午後から Kyoto.go #50 オフラインLT会 に参加するため、京都へ行ってきた。会場は 阪急烏丸駅 近くにある、はてな社だった。行きは JR + 市営地下鉄 (1時間9分)、帰りは阪急 (1時間10分) で帰ってきた。阪急でも十三乗り換えで1時間10分と、JR で京都へ行くのと総合的にはほとんど時間が変わらないことに気付いた。京都って行きにくい場所だと常々思っていたが、こんなルートもあるのだと、実際に行ってみてたまたま阪急烏丸駅をみつけて発見があった。

イベントは LT 大会だったのでいろいろな方の発表を聞きつつ、私も遠出したので会社として発表しつつ、たかさごさんやおおなかさんといった、初対面ながら話してみたいと考えていた方々とも少しお話しができてよかった。京都にははてな社やマネーフォワード社、LINE など著名な web 企業がこういった勉強会を開催していて、そこに集まる参加者のレベルも神戸より高いように感じた。神戸には著名な IT 企業がないというのが、こういったテックイベントの参加者層の厚さに相関があるようにも思う。なぜ私が京都のイベントに出張っているのかがその所以か。

神戸ポートタワー

夕方に京都から戻ってきてその足で 神戸ポートタワー へ行ってきた。リニューアルしたばかりで屋上デッキというものが新たに作られた。神戸のシンボルの1つではあるのでお客さんがきたときの観光に使えるかどうかを検証してきた。展望フロアへ上がるためのエレベーターに乗るのが20-30分ほど、展望5Fから屋上デッキへ上がる階段に30分ほど並んだ。リニューアルしたばかりなのでこのぐらいの混雑は仕方ないと言えよう。ポートタワー自体が狭い建物なので展望スペース、エレベーター、階段すべて2人がすれ違う程度の幅しかなく、そんなに多くのお客さんがいるわけでもないにも関わらず、その狭さゆえに窮屈さを感じる。展望フロア + 屋上デッキの2つのセットで入場料は1200円／人になる。値段は高くも安くもないかな。混雑度にもよるが、1-2時間もあれば上って下りてくるぐらいの所要時間になる。

屋上デッキは周囲をぐるっとみて回れるだけで真ん中の方はタワーのアンテナのような設備があってかなり狭い。屋根がない分の開放感はあってよいが、それほど展望5Fから眺める感覚と展望デッキから眺める感覚に違いはなかった。想像していたよりも屋上デッキはしょぼかった。タワーへ行ったおまけ程度のもので屋上デッキを期待していくような場所ではない。展望3Fがカフェ & バーとして外を眺めながら椅子に座ってくつろげるスペースになっている。とは言ってもタワー内なので狭いため、長時間居座るような場所でもない。この場所がタワーの中で一番ゆっくりできる場所にみえる。

全体の所感としては、気分転換に展望3Fのカフェ&バーへ行ってみるというのは非日常の空間を演出するとう意図でおもしろいかもしれない。年間パスポートは4,000円なので1回あたりの入場チケットが1,200円であることを考えると4回行けばもとを取れる。十分に安いので地元の応援として購入してみるのもよいかもしれない。一方でゲスト向けに期待値をあげていくとタワー体験はややしょぼい気はする。ゲストに先入観をあまりもたせず、近くに来たついでに立ち寄ってみようといった程度で行くと楽しめると思う。

リファレンス

テンパった開発状況

#go  #design  #github  #ci/cd 

今日の運動は腹筋ローラー,スクワットをした。統計を 運動の記録 にまとめる。

開発がなかなか進まない

本当は次の開発課題に着手しないといけないところだが、先週からずっと新機能のための、既存コードのリファクタリングに時間を費やしている。データ構造を変えたり、主キーを変えたりしているので影響範囲が大きくて、テストコードもあちこち修正しないといけなくて時間がかかる。結合テストの実行そのものにも時間がかかるし。

なかなか開発がテンパっているものの、今日でようやく一通りのリファクタリングを完了して、意図していた新機能のための web api が動くところまで確認できた。なんというか、新機能を作るために既存コードの改善に8割の時間を費やした感じ。おかげで新機能はなにも開発していないのに勝手に動いた (違) ような気持ちになった。今後、同様に個別データの拡張や新たなデータ追加のときは既存データに影響を与えず、独立して追加しやすい設計となっている。将来的に私がいなくなった後に拡張するときにこの設計は役に立つだろうと思う。

awesome-go へ道

昨日の続き 。contribution guidelines を読んでいて最低限やれと書いてあることの1つに Go Report Card report を作れと書いてあった。これは静的解析したスコアのようなものが表示される。すべて100%が表示されるようにした。

カバレッジも測れとあったので github actions の workflow ファイル を設定して計測してみた。63.9 % といまいちだった。コアなところしかテスト書いてないからかな。ユーティリティや cli のテストもちゃんと書いたら 80-90% ぐらいはいくのかな？また後日、時間のあるときにやってみる。余談だけど、久しぶりに github actions を触ったらもうワークフローファイルの文法とか覚えてなくてずっと触ってないとすぐ忘れるとか思ったりもした。

if the library/program is testable, then coverage should be >= 80% for non-data-related packages and >=90% for data-related packages. (Note: the tests will be reviewed too. We will check your coverage manually if your package’s coverage is just a benchmark result);

Quality standards

来週の資料づくり

#go  #review  #device 

今日の運動は腕立て,スクワットをした。統計を 運動の記録 にまとめる。

外では神戸まつりやっていたけど、1日中雨降りだったからとくに見に行くこともしなかった。

kyoto.go の資料づくり

前日の深夜2時頃までかけて資料を作った。社内 slack でレビュー依頼を出して帰ったら2時半頃にこみやさんがレビューしてくれてた。こみやさん夜型やなぁ。朝起きてから家事を済ませて、お昼前にオフィスへ行ってレビューで指摘してくれた内容の修正をしていた。なんやらかんやらでスライドも2-3枚増やして指摘前よりわかりやすくなったと思う。他者にレビューしてもらえると、自分だけの視点では気付かなかったところの示唆を受けて改善できる。レビューしてくれる存在のありがたさ。いつか本当に レビューサービス を作るかもしれない。

こみやさんと話していて、私はライブラリを探すときに avelino/awesome-go の話題になった。私はこのリストを参照することが多いのだけど、mapslice-json は実用的に使えるライブラリではないのにここにリストされていておかしいなということに気付いた。このリストを更新する PR を送るべきだなと思って contribution guidelines を読んでみることにした。

macbook air (2013-mid) の再インストール

古いマシンを処分しようと思ってオフィスにもってきた。もう1つの macbook は故障していて起動しない。試しに電源につないで起動させてみたらこっちは起動した。

処分するにしてもデータは全部消したいと思って os の再インストールのようなことができないかを調べていた。最近の macos にはその機能がある。この macbook では macOS Catalina までアップデートできるが、その os では再インストールのようなことはできないみたい。facebook にそんなことを書いていたら知人から ChromeOS Flex をインストールすればいいんじゃない？とコメントをもらって、それはいいなと思ってやってみようと思う。ChromeOS ならタブレットの代替のような用途に使えるかもしれない。

go の generics に慣れてきた

#go  #design  #programming 

今日の運動は腹筋ローラー,スクワット,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

go の generics の扱い

今日はほぼまる一日コードを書いていた。あるデータ型のリファクタリングをしていて次のような constraint とメソッドの組み合わせで型チェックできることを理解した。generics 使って1年以上開発しているので感覚的にも慣れてきた。User と Group のどちらかを受け取る constraint とそのデータストアの定義は次のようになる。

type UserOrGroup interface {
	User | Group
	GetPrimaryID() string
}

type UserOrGroupStore[E UserOrGroup] interface {
	generic.Store[E]
	FindByPrimaryID(ctx context.Context, primaryID string) (*E, error)
}

この型定義を使う関数では次のようになる。

func find[
	E entry.UserOrGroup,
](
	ctx context.Context, store entry.UserOrGroupStore[E], primaryID string,
) (*E, error) {
	e, err := store.FindByPrimaryID(ctx, primaryID)
	if err != nil {
        ...
    }
	ee := *e
    // ee.PrimaryID はコンパイルが通らない
	_ = ee.GetPrimaryID() // 現時点ではメソッド呼び出しが必要
}

ここで UserOrGroup に GetPrimaryID() というメソッドを追加している。本来は両方の構造体に保持するメンバー属性ではあるものの、現時点の go のコンパイラはメンバー属性を正しくチェックできない。そのため、メソッドにして generics の型チェックが正しく通るようにしないといけない。go の issue にも上がっているのでいずれはメンバー属性を解決できるようになるのだろうと推測する。

4月1日の月曜日

#go  #ldap  #project management  #issue management  #team building 

23時頃に寝て4時に起きて6時に起きた。変な寝方した。私はわりと月曜日は好き。休み明けで元気だから、世の中的には逆かもしれないが。月曜日に加えて、今日は4月1日で新年度とあってさらに新鮮な気持ちになって晴れ晴れしい。

今日の運動は腹筋ローラー,腕立て,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

go-ldap のコントリビュート

過去に私がコントリビュートした非同期検索の機能のなかで context によるキャンセルと channel の操作のところで効率のよい方法を提案してくれた方がいた。私が開発していて気付かなかったところをリファクタリングした。指摘されればその通りだと思う。開発していて non-blocking な select 文を書くことに気を取られているとその認識が漏れていたといった程度のリファクタリングになる。ちょうどいま go-ldap ライブラリを使うアプリケーションのデバッグをやっていて、特定のケースにおいてブロックしてしまう現象に遭遇していて、この context と channel の select 文の扱いが参考になった。issue をあげてくれた方に感謝。

アウトプットがない開発者への対応

お手伝い先でフルタイムの新規開発者が1ヶ月たっても機能開発の issue を1つも fix できていない。svelte で新規の一覧画面を作ってもらう、相対的に簡単な issue なのだけども1ヶ月かけてマージリクエストを出せるレベルにはなっていない。そして今日は休暇をとっている。普通の開発者の感覚として、どんな理由があろうと1ヶ月で issue を1つも fix できていない状況は異常だと思う。ほかメンバーだとそれぞれ16と8つの issue を fix している。もちろん開発者によってやっていることや取り組んでいることの複雑さが異なるため、単純に数が多ければよいというわけでもない。そして内容については私が課題管理を介して把握しているので他のメンバーの働き方になんの問題もない。どんな issue に取り組んでいても1週間に1つも fix できないという状況にはなっていない。1ヶ月かけて開発の issue を1つも fix できないというのがどれだけ異常な状況かはわかると思う。明日から出張で経営陣と進捗について話すときに大きな問題の1つとして共有して対策を検討する必要がある。

仕事も運動も満足な金曜日

#go  #debug  #exercise 

22時過ぎから休んでいるうちに寝てしまい、24時過ぎに起きてトイレ行って、寝る準備を整えてまた寝て6時前に起きた。

今日の運動は腹筋ローラー,スクワット,縄跳び(両足跳),散歩をした。統計を 運動の記録 にまとめる。

agent のバグ修正

前の開発フェーズの QA テスト中に agent の致命的なバグ に気付いた。非同期／並行にしてはいけないデータストリームの処理を分割してしまったがためにそれぞれのデータストリームの依存関係を保証できないといった不具合をみつけていた。1つのデータストリームで扱えばいいだけではあるのだけど、既存の設計を見直しながら、効率も考慮していくつか最適化もしながら、関連するところをあちこち直した。今日はチームのメンバー2人がお休みだったのでメンバーのサポートも必要なくて、朝から晩まで集中して自分のコードを書いていた。テストツールを実行して QA テストのときにみつけた依存関係に関する不具合は解消したが、まだ一部で発生するエラーもみつけている。おそらくそれらはデータストリームの不具合とは関係ない、テストツールの不具合か、別の処理の不具合な気はする。せっかく再現できる状況にあるのでまた来週デバッグして背景を調べて直す。

スマート縄跳びの運用開始

ここ最近雨降りの日が多くて縄跳びできなかった。コンクリートのところで縄跳びすると足を痛める懸念があるからなるべく土の上で飛びたい。土の地面で雨に濡れない場所が身近になくて雨降りだと縄跳びできない。体育館のような場所を気軽に使えればよいのだけど、まだ調査不足。

今日は天気がよかったので縄跳びしてきた。試行期間 を経て縄跳びのワークアウトをこれからちゃんと作っていく。タイマーも一緒にもっていって15分をセットする。しばらくは15分間で跳べるだけ跳ぶ。とはいえ、私がいま跳び続けるのは最長1分間になる。1分たったら休んで呼吸を整える。休憩を1分、2分と疲れ具合にあわせて時間をあけながら1分間跳ぶといったサイクルをしている。おそらく今日は5-6回跳んだのかな？合計で800回になった。現在の私のペースだと、1分間で110-120回ほど跳んでいるみたい。きっと慣れてきたり体力がついてくれば同じ時間でもっと回数を跳べるようになるはず。急にやると足を痛めるかもしれないから、最初はそのぐらいのノリでカラダを慣らしていこうと思う。

ordered map という適当な粒度の課題

#go  #design  #packaging 

1時に寝て4時に起きて CPAP 治療忘れて寝ていたことに気付いて、装着してまた寝て6時半に起きた。

今日の運動は背筋をした。統計を 運動の記録 にまとめる。

orderedmap ライブラリ

json のオブジェクトの属性を意図した順番に並び替えたいという要件があって 適当なライブラリをみつけられなくて 最終的には自分で実装した。そのときに参考にしたモジュールではネストした配列やオブジェクトの順番を維持できないことに気付いて、どうせ実装するなら json の marshal/unmarshal の処理を完璧に実装しようと思って、再度フルスクラッチで作り直した。要は python の OrderedDict のようなものの go 版になる。

orderedmap というキーワードで検索するといくつもオレオレの実装がみつかる。次の3つを参考にしながら、私も自分の思う「ぼくのかんがえたさいきょうの orderedmap」 を作ってみた。

実際に作ったものが次になる。

インストール

$ go get -u github.com/kazamori/orderedmap

go のモジュールは GOPROXY protocol を介してプロキシサーバーから取得される。デフォルトでは proxy.golang.org が設定されている。

$ go env | grep GOPROXY
GOPROXY='https://proxy.golang.org,direct'

プロキシサーバーではモジュールがキャッシュされているため、利用する側でリビジョンを更新しようとしても短い間隔だとすぐには反映されない。プロキシサーバーに存在しないモジュールのリビジョンを取得したい場合は GOPROXY の環境変数でダイレクトモードに変更する。

$ GOPROXY=direct go get -u github.com/kazamori/orderedmap

generics 対応して汎用の map を扱えるのがちょっとお気に入りなところ。他人が作ったライブラリを使うことはできるけど、プログラミング勉強として自分で実装してみるのもよい気はする。ちょうど kyoto.go のイベントがあってそのトークに orderedmap について話して来ようと思う。

リリースパーティの食べもの

#event  #go  #kobe  #food 

0時に寝て6時に起きて7時に起きた。

今日の運動はお休み。統計を 運動の記録 にまとめる。

go 1.22 リリースパーティのパブリックビューイング

【オフライン限定】Go HackBar in MF Kyoto #2 に参加した。裏番組で同時開催されていた Go 1.22 リリースパーティ のパブリックビューイング的な雑談イベントになっていた。神戸から京都は遠い。三条まで待ち時間などを考慮すると片道1時間半ぐらいかかった。行きはよいよい帰りは怖い的な。

go のイベントでちょくちょくみかける luccafort さんと初めて面識をもって話してみた。理詰めでしっかりした方だったように思う。マネーフォワードさんの技術広報のお仕事をされているみたい。いまは開発者以上にエンジニアリングマネージャー (EM) が求めているといったお話をしていた。うちの会社の課題管理は業務委託で EM のお仕事を手伝うのに近いものではあるけど、ビジネスにコミットしてもらうといった性質があるから業務委託はなかなか難しいみたい。あとマネーフォワードさんの場合、顧客企業の財務データがみえてしまうため、お客さんのプライバシーを守る上でも業務委託にみせにくいデータもあるといった話しもあった。

私は食べもの担当に応募したので南京町にある 劉家荘 で焼鶏 (しょうけい) という食べものを手土産にもっていった。大 (5-6人分) で4,400円。10-15人で食べるのでちょうどよい分量。包丁やまな板も持参でもっていった。慣れない鶏を捌いていて、骨があるから難しくて手を2-3箇所切った。絆創膏も用意して持っていけばよかったと、戻ってきてから失敗をふりかえりした。

今回はリリースパーティということもあって、焼鶏は見た目は豪華だし味もおいしかった。油で揚げているので量をたくさん食べると少しもたれる。1人あたりそれほどたくさん食べれない。あらかじめお店の人に切り分けてもらうかどうかは写真の撮り甲斐と食べるときの利便性のトレードオフになる。私が初めて切り分けてもそれなりに分解できたので素人でも配膳できなくもない。

キャンセルが続くような日

#event  #go  #design  #health 

3時半に寝て7時前に起きた。昨日はコーディングに集中していた。

今日の運動は腹筋ローラー,腕立て,スクワット,散歩をした。統計を 運動の記録 にまとめる。

明石海峡大橋海上ウォークのキャンセル

明石海峡大橋海上ウォーク の当日。こみやさんが関東からわざわざ来るというので私も付き添いで参加することにしてした。朝起きて準備して元町駅から8時半頃の電車に乗って舞子駅へ向かう。途中で slack に一報したらこみやさんから今日は中止だよと連絡が入る。新長田駅で折り返して三ノ宮に返ってきた。当日6時に強風予報のため中止になっていたらしい。普通に晴れているのに。橋の上を歩くイベントは強風で当日中止とかになるんやということを学んだ。

雑談会のキャンセル

毎年行っているある大学の先生との雑談会を13日に予定していた。大阪のバーで飲むイベントだったのだけど、家族全員がコロナにかかってしまったという話しで周りへの感染予防のためには飲みに行くわけにはいかないという連絡がきた。それでお店の予約をキャンセルした。早めに連絡をいただいたのでキャンセル料を支払う必要はなかった。感謝。私も開発合宿と出張の移動疲れで疲労困憊になっているのでこれはこれでよかったのかもしれないと思えた。

ordered map の開発の続き

複雑なデータ構造のときに map (json で言えばオブジェクト) のキーの順序を保持できないことにもテストを書いていて気付いた。そこの部分も作り直さないといけないとデバッグしたり設計をやり直したりしていた。

昨日の続き

json を自前でパースしないといけないという判断を下し、json パーサーを探してみて ujson というパーサーを使ってみることにした。今日は ujson を使った json のデシリアライズの処理を設計したり実装したりして試行錯誤していた。こういうシンプルなライブラリは私のやりたいことを邪魔しないので好み。

ストレッチ

本当は午前中に明石海峡大橋海上ウォークへ行くつもりだったからストレッチは夜の時間帯に変更していた。先週は開発合宿でお休みしたので2週間ぶり。散歩する機会が多くなったせいか、右足の太ももが筋肉痛であることは自覚症状があった。今日の開脚幅は開始前150cmで、ストレッチ後155cmだった。トレーナーさんのストレッチを受けて、足は左右とも前も後ろもあちこち痛かった。トレーナーさんからもあちこち張りがあるという指摘があった。運動の成果というのか、散歩をたくさんするようになって足に負荷がかかっているのは間違いないようだ。こういうときこそプールを使うべきなんだけど、なぜか夜に予定が入りまくっていてなかなかスケジュール調整ができない。土曜日が一番時間の調整しやすいのにプールの制約によって利用できない。カラダが疲労していると脂肪燃焼の効率が悪くない。カラダを休めるのも必要なことかもしれない。

ordered map 開発のきっかけ

#go  #design  #debug 

0時に寝て6時半に起きた。神戸に戻ってきてようやく落ち着けた。

今日の運動はスクワットをした。統計を 運動の記録 にまとめる。

ordered map の開発

金曜日は打ち合わせが何もない曜日の1つ。疲労困憊で神戸に戻ってきたので今日はずっとコーディングに集中していた。本当はお仕事終えてからプールへ行こうと思っていたものの、逆にコードを書くのに集中し過ぎて晩ご飯に一旦帰って食べた後も、もう一度オフィスに来て、さらに1時ぐらいまでコードを書いてた。

go の map をイテレートすると意図的にランダムに key-value を返す仕様になっている。これは開発者がキーの順序に依存した実装をしてしまって潜在的バグを混入させてしまう懸念を取り除くため。その設計思想は理解できるものの、go の map を json で返すときに ux の視点からキーの順序を保証したい場面がある。そんなときに ordered map のようなものが必要になる。go のコード内で ordered map を実装しているライブラリはいくつかあるものの、json のシリアライズ／デシリアライズも考慮してキーの順序を保証するライブラリはあまりみつけられなかった。それを考慮しているライブラリの1つに mapslice-json がある。しかし、このライブラリの実装はイケてなくて致命的なバグを1つみつけて PR を送ったものの、おそらく3年ぐらい保守されていない。あとジェネリクスを使うと使い勝手がよくなるからコードを書き換えたい。

結局このライブラリからアイディアだけもらって自分で再実装することにした。そして、array や map が入れ子になるような、複雑なデータ構造のときに map (json で言えばオブジェクト) のキーの順序を保持できないことにもテストを書いていて気付いた。そこの部分も作り直さないといけないとデバッグしたり設計をやり直したりしていた。これは会社の oss ライブラリとして作ってもよいかもしれない。

ホットクックのレシピを upnote で書く

#founding  #recipe  #health  #upnote  #go  #ldap  #design 

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 のソースコードを読んで設計をしていた。また明日余裕があったらサンプル実装してみる。