ドキドキするとき無敵でしょ

映画とプログラミングの話

鹿肉を、食べた

これは #力強くアウトプットする日 の記事です。

みなさん、鹿肉を食べたことはありますか。私はあります。

年末、散歩をしていたらハラルフード店で鹿肉が売っているのを見つけたので「年末だし、せっかくだから食べたことないものでも食べよう」と思い、今年の締めに鹿肉を買いました。 海外産かな?と思いきや、なんと国産です。嬉しい。

調理する

ジビエを調理したことがないので、いろいろ調べてみたところ「獣臭い」「硬い」と書かれていました。脂分が少ないから焼いたりするとしまって硬くなりやすいそうです。ちょっと下処理が必要だなぁ、と思いつつ、早速事前準備をします。

まず、冷凍されている肉なので冷蔵庫でゆっくりと自然解凍します。 前日の夜に冷蔵庫に入れたら全然溶けなかったので、昼間外に出したらドリップがえぐいことになったので、みなさんは冷蔵庫でゆっくり自然解凍するのをお勧めします。

自然解凍後、肉を柔らかくするためにどうしようか…と悩んで調べたところ、ブライン液が有効なようでした。ブライン液を用意してとりあえず漬け込んでみました。 ちなみに肉自体は結構柔らかかったので、どちらかというと肉の臭みをとる方に舵を切った方が楽かもしれません。

鍋はその辺に売っている鍋のもとで味噌を使いました。味噌なら全て味噌になる、ラーメン発見伝でも味噌味は70点になる(うろ覚え)って言ってた。 というわけで煮込み始めます。

30分ぐらい煮込んで蓋を開けたところ、味噌の匂いがしない。獣臭さい。あまりにも臭い。 味噌の匂いを消すことあるんだ…という衝撃があったので、にんにくと生姜、野菜を投入して更に煮込みました。

更に20~30分煮込んだところ、獣臭さが収まって、白菜のような匂いになりました。

というわけで完成。

めっちゃ味噌の味。出汁の出てる味は全くしなくて、鹿肉の出汁ってもしかしてない…?になりました。

肉はタンパクで引き締まっていて、ぎゅむぎゅむでこれは美味しかったです。獣臭さはほぼなくなっていて、ちゃんと美味しくなっていました。

来年は山羊肉、猪肉あたりも食べようと思います。では。

おまけ

と、いうわけでリベンジの鹿肉年越しそばです。

下準備

前回、柔らかくすることに集中し過ぎてうまくいかなかったので、今回は冷蔵庫に余っていたビールとネギの青い部分をジッパーに肉と一緒に突っ込んでしばらく寝かしました。
全然臭くない。というわけで塩胡椒で下味を付けて焼きます。

調理

表面を焼いて焼き色がついたので、その辺で売ってた醤油味のスープで煮る。

完成

あとは煮ておいたそばの上に完成した鹿肉鍋をかけて年越しそばの完成です。

感想

なんだろう、鹿肉から出汁が出ないので、スープは野菜で頑張る感じになりました。肉自体はうまいのですが、そんなに強い味がするわけではないのでもっと味付けしてよかったかもしれません。 臭みはかなり取れたので、食べる時にちょっとラムやマトンのような感じがする程度でした。

タンパクで美味しい、みなさんも年越しに鹿肉を食べてはいかがでしょうか。

ドメイン駆動設計入門を読んだ

これは #力強くアウトプットする日 の記事です。

今年はお仕事がバタバタしすぎて何もできなかった Gunzi です。 いろいろ振り返るとドメイン駆動設計周りを全く勉強していない状態から仕事がスタートしてかなり地獄を見たので、年末落ちついたから今のうちに本を読んで来年は変な苦しみ方をしないぞ…!と心に誓いました。

いきなり小難しい本を買うか悩んだのですが、なんの知識もない状態でいきなり読めるか正直不安でした。なので、まずは入門書を、ということで「ドメイン駆動設計入門」を読むことにしました。

https://www.amazon.co.jp/dp/479815072X

感想

ユニットオブワーク、仕様、ファーストクラスコレクションあたりはあまり意識してなかったけど多分使ってるな…?になりました。仕様はあんまり理解できなかったかも。

Go ならどう表現するか?を考えながら読めて楽しかったです。

読み進めながら今年のレビューや PR での議論の背景を振り返って、いろいろ理解が進みました。なぜ俺はこれを年初に読まなかったのか…と後悔しています。

来年は設計業務も増えそうなので、これを機に難しい方も読みたいと思います。

メインキーボードを2年振りに変えた

この記事は、キーケットスタッフ Advent Calendar 2025 19日目の記事です。

adventar.org

昨日はぴろりどんさんの記事でした。自分はそんなにこだわりないなぁと思ったのですが、XDA か DSA しか使っていないことに気づきました。

note.com

なぜ変えるのか

現在のメインキーボードは Cornelius でキースイッチが Azure Dragon です。

去年までは問題なかったんですが、今年に入ってから平日は9~11時間ぐらいキーボードを叩きはじめて、流石にちょっと跳ねっ返りが強くてキツい。 そろそろ買い換えようかなぁ、でも Cornelius も好きだしなぁと悩んでいました。ただ肩幅も広くなってきて、ナローな姿勢がしんどくなってきたところで前メインにしていた Corne Cherry に戻すか考えていました。

そんなこんなで遊舎工房を覗いていると、新型のアイツがいるではないですか。

Corne V4 Chocolate が!!!!!!

(写真はないので遊舎工房のサイトをご覧ください)

Corne V4 Chocolateshop.yushakobo.jp

キースイッチも Choc なら指も疲れなさそうだしありだな〜と思い、キーケットスタッフの皆さんにおすすめを聞いてみたところ、いろいろ教えてもらったので Chocolate に決めました。

いろいろ触ってみて、最終的には silent pink にしました。

Choc Switch V2 Silent Pink, Linear 35gf

なんかリニアの割にはタクタイルっぽくて個人的にはめっちゃ良いです。 打ち心地がとても良い。なんで今まで気づかなかったんだろう。Choc の良さに。

とても静かなのでこれからは職場で Azure Dragon をズダズダ打たずにすみます。(ヅダじゃないよ) 流石に周りに人が多いので申し訳ない気持ちは多少あったので変えて良かったです。

Choc スイッチはいいぞ。

おまけ

スタッフのみなさんからのおすすめを貼っておきます。

Ambients Silent Choc Switches

Choc Switch V2 Silent, Tactile 45gf

Void Low-profile POM Switches – Lofree Japan

Kailh White Rain Switch

Lofree Ghost switch / linear (90pcs)

2024年のふりかえり

年末コインランドリーで乾燥機を使っていたところ、終了した直後にカップルが間違えてしまい、追加で40分乾燥がはじまりました。  

というわけで今年のふりかえりです。あんま文章にすることもないので雑に箇条書きする

仕事

  • 別チームのリーダーからヘッドハントされて 5 月に突然部署異動になった
  • それまでアプリケーションの API ばっか書いてた
  • と思ったら異動後はずっと CI / CD を整えてた
  • でもいろいろあって CI / CD 整えながらアプリケーションコードを読んで直したりしてた
  • Kubernetes 周りは業務で触れるに越したことはないな~と思っていたら本当に触ることになってしまいちょっとびっくりした
  • ベテランに囲まれる 3 年目のひよっこをやっている
  • 来年はアプリケーションもさらにゴリゴリ書くことになりそうだ
  • 場合によっては RFC やら論文やら漁ることになる仕事もありそうではある
  • 難易度がたけぇ。面白いからいいけど
  • ネットワーク周りに関わるようなもの作れたら作りたいな~

プライベート

  • いろいろあった
  • 筋肉がめっちゃ増えた。というかガタイがめちゃくちゃ良くなった
  • 体力の上限値が伸びた
  • 懸垂をワイドで3,4回程度ならできるようになった。これはだいぶうれしい
  • ただ体格が変わりすぎて服をめっちゃ捨てた

全体的な感想

仕事の難易度がいきなり上がって草だった。ヘッドハンティングって本当にあるんだ...
いきなりフル出社になって知ってる人たちがいなくなってしまったり、別れもそれなりにあった。
ただ、部署異動したのは結果的に良かった。学習の必要な量は大幅に増えたが、がっつりやればそれだけ返ってくるともいえるだけの技量は手に入る。
いろいろあったし、来年は目標立ててがっつり潜るぞ、の選択をする覚悟ができたので良かったかも。

最後に

カップルが「どうしよう...」としばらく呆然としていたので観察していたら去っていった。というわけでささっと洗濯物を取り出して事なきをゲットした。
40 分だと乾き具合が微妙だったので、ちょうどいい感じに洗濯物が乾いてよかった。

『Design It!』を読んだ

年末は積読を消化するのにとても良い....
というわけで2本目です。『Design It! ―プログラマーのためのアーキテクティング入門』を読みました。

www.oreilly.co.jp

感想

小さなチームに異動したので、やることが増えたのもあり、自分自身設計を少しでもかじっておかないと来年困っちゃうな~とか考えてたら会社にあったので持ち帰って読んだ。
アーキテクチャをどう考えるか?ということの入門としてかなり良かった。
ステークホルダーやチームメンバーを巻き込んでガンガンディスカッションしていこうぜ!みたいな感じだった。
あとやっぱり図に起こすって超大事なんだ...ってなった。複数種類作ったっていい。俺もそうしていきたい。

個人的には「選ばなかった道」の話が好きだった。なんでそうしたのか?俺ならこうするが?みたいな気持ちになることはあるので、ちゃんとだめだった理由を後から知られるのはいいことだなぁ、と思った。

これもまた読み返すと面白い本だ。

『プログラミング作法』を読んだ

Tidy First? 読みたいなぁ、と思っていたら t-wada さんのツイートが流れてきて気になったので読んだ。

感想

めちゃくちゃ面白かった......
書籍自体は純粋に全部面白かったが、第4章のインターフェースの話が本当に面白くて興奮した。
1つの機能を例に挙げて、ステップバイステップで改善していくという内容だった。
考え方が言語化されていて、これは自分も意識してやった方がいいなと思わされた。結構フレームワークに近いエッセンスを感じた。うまみがすごすぎた。

全体的に根底の考え方を固めるような内容で、また読みたいと思った。インターフェースの章はあらゆる人に読ませたい。
Tidy First? も近いうちに読むぞ、になった。

感動した Go のテクいコード

この前上司の PR を読んでいたら「理解できるけどどうすればこんなこと思いつくんだ」と思ったコードがあり、聞いたら出典を教えてくれたので紹介する。

というわけでこちら。 strechr/testify のコードにそれはある。

github.com

私が感動したコードはこの getLen() 関数。

// getLen tries to get the length of an object.
// It returns (0, false) if impossible.
func getLen(x interface{}) (length int, ok bool) {
    v := reflect.ValueOf(x)
    defer func() {
        ok = recover() == nil
    }()
    return v.Len(), true
}

Named return values

まずこの関数を一目見て、最初に気づくのは Named return values かと思う。 このコードを読んだ時に、まずこの書き方をほぼ見かけたことがなかったので、挙動を追うのに手間取った。 使いどころとしては、引数がめっちゃ長いときに補完を効かせるとかそういったところらしい。

go-tour-jp.appspot.com

A Tour of Go のこのページの説明で Goでの戻り値となる変数に名前をつける( named return value )ことができます。戻り値に名前をつけると、関数の最初で定義した変数名として扱われます。 とあるように 戻り値に名前をつけるとゼロ値で初期化された変数として扱われる。

Effective Go の Named result parameters の項目にも named results are initialized and tied to an unadorned return という記載がある。

初期値が入っていることを確認するために A Tour of Go の関数をちょっと書き換えて実行してみる。 https://go.dev/play/p/xzmXKpjH5jk

package main

import "fmt"

func split(sum int) (x, y int) {
    if sum == 0 {
        return
    }

    x = sum * 4 / 9
    y = sum - x
    return
}

func main() {
    fmt.Println(split(17))

    // ゼロ値で初期化されているので 0 0 が返ってくる
    fmt.Println(split(0))
}

この関数の実行結果は

7 10
0 0

となり、戻り値に名前をつけるとゼロ値で初期化されるということを確認できる。

defer func() 内の recover()

getLen() で引数に渡されたreflect でオブジェクトが取得できなかった場合このコードは panic が起きる。 しかし、この関数では defer func() することにより panic が起きた場合 recover() して戻り値のゼロ値を返すようになっている。そのため getLen() は 0, false を返すことにより、関数が失敗したことを通知できる。 stretchr/testify はテストフレームワークだから無邪気に recover() して返すことができる、という背景があるからこそ書けるコードでもあるので、めちゃくちゃ合理的やん…!!!! とテンションがぶち上がった。

この関数自体は panic() を起こさなかった場合 recover() は nil を返すので問題がない。だいぶ気持ち良い。

感想

今までに Named return values を使ったコードをほとんど見たことがなかったのでかなり驚いた。 なんなら自分でも書いたことはないと思う。 Naked return できることを考えると正直あまり気が進まない。このコードの製作者はその点にも気を配って書いていて、洗練された美しいコードに出会えて感動した。 他にもテクいコードの話をしてくれたので、自分でも見つけたら紹介する。

上司が「 Go の標準パッケージや OSSソースコードにはこういうテクいコードが色々あるから読んでみると良い」とアドバイスされたので、自分も定期的に読みたいと思う。

参考