Posts for: #Go

5年ぶりの健康診断

今日の運動は腹筋ローラー,散歩をした。統計を 運動の記録 にまとめる。

健康診断

昨日は早く寝たのもあり、5-6時には起きていたと思う。朝ご飯も食べられないから朝食を作る必要もなく、暇なので7時頃には家を出てゆっくり歩いて 神戸マリナーズ厚生会病院 へ向かった。受付は9時からだったものの、8時頃には病院へ着いてしまい、待ち合いスペースでそのまま本を読んでいた。病院だから (おそらく) 24時間開いているのかな?8時でも受け付けは閉まっているものの、警備員や当直のスタッフはいるので待ち合いスペースを案内してもらってそこで待っていればよいと教えてもらった。

待ち名簿に一番上に名前を書いておいたので一番先に受け付けして健康診断を開始。私の他には数人ぐらいしかいなかった。これなら早く終わるかな?と思ったものの、検査の合間合間の待ち時間がやや長く、それらが積み重なって11時頃に完了した。土曜日だから病院側のスタッフも少なかったのかもしれない。あるいは私が一般検診 + 付加検診を申し込みして項目が多かったせいかもしれない。最後は私と2人ぐらいしか残っていなかった。他の人たちは1時間ほどで完了していたようだ。久しぶりでバリウム飲めるか不安だったけれど一回でクリアできた。だいぶ慣れたのか、歳をとって感覚器官が鈍くなって気持ち悪さがよくわからなくなったのかもしれない。最後に医師の診察をうけて、いくつか聴診をして、諸々の検査の結果はそれぞれの専門医師がみて判断すると聞いただけだった。初めて行った病院だったけど、余裕をもって検査してくれてよいところだったと思う。次回の健康診断もこの病院でよいなと思った。

一般検診 + 付加検診で診察料は 7,971円 (税込) だった。役員1人だけの会社は健康診断のお金が経費にならないのでこれは個人負担となる。

go のイベント

健康診断を終えてから Kansai.go #1 へ行ってきた。ちょっと遅れて行った。大阪梅田ツインタワーズ・ノース にあるサイボウズのオフィスをお借りしての開催だった。聞いたことないビルだと思ったら2022年4月に梅田阪急ビルからビル名が変わったらしい。サイボウズさんの若手の方がスポンサーセッションをされていた。見た目20代半ばから後半ぐらいの方かな?発表を終えて、私がいたテーブルに来られたので後でグループワークすることにもなる。その後、LT が6人続いて リーンコーヒー という取り組みを行った。私はリーンコーヒーという会議形式をやったことがなかったので新鮮ではあった。ブレストのもうちょっと緩い会議みたいな雰囲気。テーブルにいるメンバーで付箋に関心のあるトピックを書き出して、みんなのを集めて、ファシリテーターが関心の高そうなトピックを選択してそれについてみんなで意見を言い合うみたいな流れだった。7-8つほど付箋に書いたトピックがあって、いろいろな話題について1時間ほど4人でわいわい話し合って楽しかった。テーブルが6つあったのかな?他の所も盛り上がっているようにはみえた。オンラインではなく、オフラインイベントでしかできないことの1つは複数のミーティングを一度に実施できる点がある。オフラインの価値を活かす施策の1つにリーンコーヒーはよい企画のように思えた。

余談だけど、うちのテーブルの開発者はみんなスキルが高くて他言語と go の比較の議論が盛り上がった。4人中2人が rust も勉強していて rust と go の比較の話しも聞けた。学習コストは高いものの、go で満足できない言語機能が気になったら rust がよいと2人とも話されていた。しかし、rust を書ける開発者は少ないから会社の業務で取り組むなら開発者を確保できるか、既存の社員も rust を勉強するかといった意思決定はいるという話しもあった。sns のタイムラインをみていると、開発者の大半が rust の勉強をしているようにみえてしまうが、現実の会社で普通に働く開発者は rust なんか難しくてできなかったり、個人の趣味で勉強したりしていない。コミュニティイベントへ行っているとそういうところでみんな rust 勉強しているんだと勘違いしてしまう。サイボウズさんのスポンサーセッションをされていた若い開発者がめっちゃ優秀でこんな若手がいたらマネージャーとして楽しいやろなと思えた。さすがサイボウズさん。その子が ソフトウェアアーキテクチャ・ハードパーツ がよいとお勧めしていたのでいつか読んでみたいと思う。

kyoto.go と kansai.go へお出掛けして少しずつ知り合いが増えてきた。次は kobe.go かな。うちの会社のプロダクト開発は go を採用すると決めているので go のコミュニティとも密接にやっていきたい。

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

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回行けばもとを取れる。十分に安いので地元の応援として購入してみるのもよいかもしれない。一方でゲスト向けに期待値をあげていくとタワー体験はややしょぼい気はする。ゲストに先入観をあまりもたせず、近くに来たついでに立ち寄ってみようといった程度で行くと楽しめると思う。

リファレンス

テンパった開発状況

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

開発がなかなか進まない

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

なかなか開発がテンパっているものの、今日でようやく一通りのリファクタリングを完了して、意図していた新機能のための 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

来週の資料づくり

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

外では神戸まつりやっていたけど、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 の 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日の月曜日

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つとして共有して対策を検討する必要がある。

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

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

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

agent のバグ修正

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

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

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

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

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

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 について話して来ようと思う。

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

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人あたりそれほどたくさん食べれない。あらかじめお店の人に切り分けてもらうかどうかは写真の撮り甲斐と食べるときの利便性のトレードオフになる。私が初めて切り分けてもそれなりに分解できたので素人でも配膳できなくもない。

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

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

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

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

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

雑談会のキャンセル

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

ordered map の開発の続き

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

昨日の続き

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

ストレッチ

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

ordered map 開発のきっかけ

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 ライブラリとして作ってもよいかもしれない。