コーヒ関連で買ってよかったと思っているもの

irof.hateblo.jp

1年半前書いたやつのアップデートとかです。

タイムモア TIMEMORE 栗子C3s 手挽きコーヒーミル 手動式 コーヒーグラインダー ステンレス臼 粗さ調整可能 清掃しやすい coffee grinder 家庭用 省力性 ダイヤモンド (C3s-グリーン)

ミル。これは変わらず、機嫌よく使っています。商品ページの画像違うのになってるけど、まぁ同じでしょ。

ハンドルが軽く、他の低価格帯のミルにあるような「空で回した時も何か引っ掛かる感」がないです。豆を入れてない状態でハンドルを弾くとクルクルと二周します。素敵。

ほどほどのをいくつか買ってみましたが、比べると同じ細さでも挽くのにかかる時間も短くて、いいものなんだなぁ感があります。 価格が一桁違うのでそんなもんでしょうし、同価格帯なら似たり寄ったりかもしれないけど、そっちは試してないです。

静電気がひどくてRDTめんどいーって思ってたんだけど、なんか最近対策しなくてもつかなくなった。なんでだろ。豆が湿度もってる？汚れ？掃除もちゃんとしてるつもりなんだけどな……。

HARIO (ハリオ) 珈琲キャニスターM ブラック MCNR-200-B

キャニスター。電動の真空キャニスターもいくつか持ってるんだけど、これは真空にする機能はないけどレバーをパチンとするだけで密閉できます。お手軽。 200g弱なら10日くらいで使いきっちゃいますし、長期保存するでもなし。十分だと思ってます。気に入ったので複数買いました。

電動の真空キャニスターはいい感じな気もするんだけど、たまに必要な充電が地味にめんどいんよね。

タニタ(Tanita) クッキングスケール はかり キッチン 料理 2kg 1g単位 防水 洗える 丸洗い 最短1秒ではかれる ホワイト KW-201-WH

クッキングスケール、はかりです。 防水で丸洗いできるのがポイント。あと2kgなとこもいい感じ。1kgだとコーヒーはともかくボウル（ガラス使ってるから重い）込みだと超える時があるのよね。

前回のブログの通り、同じタニタの防水じゃない1kgまでのを使ってたんですが、コーヒーとかCOMPとか粉を扱うことが多いとどうしても細かく汚れます。 丸洗いできるのでざぱーっと水かけるだけで綺麗になります。あと以前のと比べてキビキビ動いてピタッと計れます。ミリ秒単位の違いでしょうけど、この違いも快適。というか前の使ったらイラっとすると思う。

[山善] 電気ケトル 電気ポット 0.8L 一人暮らし 二人暮らし ドリップケトル (温度調節/保温/空焚き防止機能) 沸騰後自動電源OFF ブラック EKG-C801(B)

温度調整できる細口の電気ケトル。

コーヒーは沸騰したままの温度で入れると味の違いがわからない私でも感じられるエグ味が出てきて、ぶっちゃけ不味いです。 コーヒー豆によって「この温度くらい」というのが一応あって、書いてたりもしますのでそれに合わせます。

以前は温度計を併用してしばらく待ってたんですが、沸かしたあと温度が下がるまで待たなくていいですし、うっかり温度下げすぎて沸かし直しーとかもしなくてよくなりました。実に快適。

ということで快適面のアップデートでした。

あ、あとこれ。

minne.com

コーヒー色に白文字。お気に入りです。

Gitでまちがえてrebaseしたときにやったこと

三行で

• まちがえて rebase した
• 戻した
• いちやさGit第3版でるよ

背景

GUIのGitクライアントを使用していると意図せず rebase されてしまう場合があります。 pull した時にリモート追跡ブランチで更新があった場合などで、ダイアログがでるものの聞いてくるのは「 rebase する？」だったりして、一般的には推奨されてるんだろうなとは思うものの趣味には合いません。 油断してるとうっかりOKを押しちゃったり、その選択を維持するチェックをうっかり入れちゃったり。あるあるです。

こういううっかりが「あるある」なのはGitの操作（特にローカルに関する）に対する注意力を捨てているからです。 リモートを更新する push などはある程度気をつけますが、Gitのローカルに関して私の通常の操作で復旧できなくすることはまずありません。取り返しのつくところには注意力というリソースを割かないようにしています。

「 rebase してもいいじゃん」と言えばそれまでなんですが、私は rebase せずにありのまま記録する方が好みです。 先に趣味に合わないとか好みとか書いている通り、コードの共同所有者などのコンテキストにこだわりやルールがあればそれに合わせます。 ちなみにそのまま記録したものを整形することはいくらでもできますが、改変したものを事実に戻すのは不可能になることもしばしばです。不可逆な決定はせずに済むならしないに越したことはありません。あといみゅーたぶる推し。

しない方が好みとか書いていますが、 rebase が好きな時期もありました。たとえば gitのrebaseとremoteとbranchと - 日々常々 とか。近年はしない方が好みですが、来年には好きになっているかもしれません。

私はGitの操作はCUIが好みではあるのですが、IntelliJ IDEAではショートカット一発でCommit&Pushできるので利便性からGUIを使うことが多いです。 AIにコミットメッセージ書いてもらうのも便利ですしね。

あ、Gitといえば「いちやさGit（いちばんやさしいGit&GitHubの教本）」の第3版が1/23に出るそうです。来週ですね。

いちばんやさしいGit&GitHubの教本 第3版 人気講師が教えるバージョン管理＆共有入門 「いちばんやさしい教本」シリーズ

第3版は確認していませんが、初心者向けの顔をしてるのにCUIで説明する本です。GUIだと理解してほしいことが裏に隠れがちなので初心者向けだからこそCUIってのもあるんですけど、レビュアー含めてCUI派だったからってのも往々にしてあるんじゃないかなぁって思います。

やったこと

git rebase -i {どっかいい感じのコミット} でインタラクティブにして、混入したコミットを除去するなども考えられますが、これは本来のコミットを復元するわけではなく再現するものになります。 ほぼ問題なく再現されるのでコードや各コミットのタイムスタンプ、差分は同じだけど、コミットハッシュは変わるし、趣味に合わないです。

なので落ち着いて git reflog です。

rebase (start) とか書いてるのが rebase の基点となるコミット。なのでここでは 4ae20327c が rebase される前の最終コミットです。 つまりここに reset してやれば戻ります。 git reset --hard 4ae20327c でうっかりが無かったことになります。（って書いて「これはこれで歴史改変じゃん」とおもったのでダブスタっぽいけど気にしない。）

※ちなみに reflog つかわずともGUIクライアントのログには最後にコミットした時のコミットハッシュが記録されていたりもしますので、そっち見て rebase してもいいと思います。GUIクライアント使っててログを見る人ってそんないないと思うけど。

ということで

かんたんにうっかりが取り戻せたので、今後もローカルGit操作に注意力リソースを割かずにいられそうです。こうして人はどんどん鈍感になってゆく。

reflog は先の本などには（たぶん）載っていませんが、ローカルで「やっちゃったー」なときには手っ取り早く汎用的に使えて便利です。余計な操作する前でないと埋もれちゃったりするので状況次第ですが、トラブってる人の状況を見る時とかにも使えるとたまに役に立ちます。最近はGit慣れてきている人が増えてきているせいなのか、GUIツールの出来が良くなってるのか、リモートで問題に気づく機会が減っているからか、トラブルを一緒に見る機会は減った気がするけど。

Tidy First?のススメ

薄い本なので軽い気持ちで読みましょう。

先に読むべき？→Yes！ 私は初詣の列に並んでいる1時間で読みました。寒かった。

Tidy First? ―個人で実践する経験主義的ソフトウェア設計

力を失ってしまった「リファクタリング」を復活させる本です。私の中のサブタイトルは「Make Refactoring Great Again」です。

第一部の冒頭から引用します。

整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。 「リファクタリング」という言葉は、機能開発の長い中断を指す言葉として使われ始めたとき、致命傷を負った。

「致命傷を負った」に「だよねー」と思ってしまう昨今。「それリファクタリングじゃねーしなー」とか思いながら「リファクタリング」という言葉が使われているのを眺めつつ、たまに「違いますよ」って言ったりして面倒がられたりして。

リファクタリングが力を保てている人にはあまり要らない本かもしれません。 たとえばリファクタリングやレガシーコード改善ガイドを読んでいて、実践し、日々の業務の中でリファクタリングを呼吸のように行えている。 いつもそのような振る舞いができている方であれば、この本から得られるものは少ないと思います。少なくともあなたのリファクタリングはまだ致命傷を負わずにいられているようです。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

レガシーコード改善ガイド: 保守開発のためのリファクタリング

一方、リファクタリングをしたくとも「タスク化されていないとできない」「時間がない」のようなことが日常的な場合、致命傷を負っています。 死んでしまう前に救いましょう。言葉が汚染されてしまった「リファクタリング」全体を救うのに苦戦しているならば、その中の「可愛くてふわふわした小さな」サブセットである「整頓」だけは救ってあげましょう。その役に立つ本だと思います。

ただし注意してください。この本が救ってくれるわけではありません。書籍のどこかにも書いていたと思いますが、救うための考え方を整理している本です。救うのは自分たちです。

実践イメージ

実際やるならどうするかなーってのを、第二部に書いている内容を大いに参考にして考えてみたものです。まだやってないです。うまくいくかどうかはわかんない。

まず「リファクタリング」からサブセットである「整頓」を抽出して名前をつけます。 手がかりは第一部にカタログ化されている15個で、まずはそのまま採用して良いと思います。 ただ、できるならば自分たちで定義しなおした方が良いです。足し引きできなければ「整頓」も遠くない未来に力を失ってしまうでしょう。

整頓を行う際は、行っている整頓を意識し（このために名前があります）、整頓ごとにコミットします。コミットコメントには整頓の名前を書きましょう。 名前をつけた整頓を行う際は、必ずその範囲でのみ活動します。絶対に他のことをしない。他の整頓を同時にしない。した瞬間に整頓も致命傷を負ってしまうでしょう。

次に、整頓を実施します。1日10分でも良いので、習慣化するまで毎日やります。 整頓するところがない？そんなプロダクトは存在しないでしょう。どこからやったらいいかわからない？目についたところからはじめましょう。昨日読んだコードでもいいし、今日やる予定のタスクに関連するコードでもいいです。探すより適当に開いたところから始めるのがいいです。

行った整頓はただちにメインラインにマージします。 トランクベース開発を行っているのであれば特に障害はないでしょうが、プルリクエストによるレビュアーの承認が必須のプロセスを敷いている場合は障害になるでしょう。以前 脱ブランチファースト - 日々常々 で書いた「ブランチを使うと背負いこむこと」がまさにこれです。 irof.hateblo.jp 本書で推奨されているように、整頓はレビューを必須でなくさなければ力を発揮しません。整頓で行うことはボーイスカウトルールと言われる中で行うものに近しく、このメタファをそのまま使用すると「ゴミを拾うためだけに一往復しなければならない」となってしまい、そうなるとゴミ拾いはしなくなるわけです。 レビューすべき重要な変更のノイズを排除するのが整頓です。（リファクタリングもそうなんですけど、リファクタリングの話は今は置いておきます。）整頓によってレビューにかけられる時間を増やそうとしているのに、整頓にレビュー時間を費やしていたら本末転倒です。

もしレビューをなくすのが難しければ、まずは今まで通りのプロセスを回しましょう。 レビューを通して整頓で行う変更の共通認識を作ります。名前通りの整頓を行っているか。新たな整頓が発見できていないか（見つかったらリストに追加しておきましょう）。 整頓における自分たちの振る舞いを醸成し、整頓を行う全員で「整頓はレビューしなくて大丈夫」という自信をもてるまで続けましょう できるのであれば、毎日時間を決めて整頓→レビュー→マージをします。モブでやってもいいでしょうし、よーいどんで個々でやってもいいと思います。いずれにしても行った整頓はすぐにマージします。 もし即マージをためらうものがあれば、それは整頓リストから除外します。

10分で「対象を見つける」「整頓する」「マージする」まで行います。3分で終わるなら3回やりましょう。 このようにしてすぐに変更できて即マージして良いものだけを整頓と呼び、実際にやって経験値を貯めれば、整頓できるようになると思います。 できるようになれば日々の業務の中で整頓することは難しくはなくなるはずです。やめ時を見失わなければ。

Tidy First?

本書のタイトルでは「？」が大事なんですが、それは読んでもらうとして。 まずは整頓をできるようになりましょう。というのがこのブログの趣旨です。

整頓できるようになった？ならば「いつやるの」や「いつまでやるの」などに答える必要があります。ビジネスの話です。本書では結構しっかり書いてるので、悶々としている方は読むと参考になると思います。 ただどこまで行っても「整頓」は単体で見れば小さくてふわふわした可愛いものです。黒いやつみたくいくらでも出てくるのでキリがないのが厄介なとこで、そこに向き合うのが本書の「？」です。

できるようになる前に「いつやるの？」「そもそもするの？」とか考えても絵に描いた餅です。まずできるようになりましょう。やらないことはできるようになりません。話はそれからです。1日10分だけ。トレーニングに費やしてみましょう。新年ですしね。

別の話のスライド だけど同じようなことをよく言ってるなと思って引用。

2025-01-09 追記： Make Refactoring Great Again

私の中のサブタイトル。他には「Refactoring is Dead」とかがよぎりました。

「リファクタリング」は昔からあるテクニックです。先に挙げたファウラーの本も古典と呼んでいい古さ（オーム社のは2014年ですが、その前のピアソン社のは2000年、原著は1999年です。前世紀ですね。）かと思いますが、当時から界隈で行われているリファクタリングをまとめて再定義したものです。リファクタリングは「動いているものに触るな」に対して「安全に触る方法があるよ！」というものだったと思っています。 リファクタリングが広く認知されることにより、ソフトウェアは変更可能性という意味のソフトさを取り戻しつつありました。

これに対して「リファクタリングといえば変更が許容される」という乱用がはじまっていまいました。 そして重々しいレビューや承認プロセスを迂回するためにリファクタリングという言葉の乱用が始まります。 直接コードを触らない人にとって、リファクタリングと他の変更の区別は困難だったこともあり、技術的負債という言葉も振り翳され、リファクタリングの多少の乱用は許さざるを得ないようになりましたす。 ややもすれば「リファクタリングを認めないなんてXXX（遅れてる、開発者体験を損ねる、技術のことを何もわかっていない）だ」とか言われたりして。健全じゃないフォースが働いてしまったのです。

とはいえそのままでは終わらず、当然のように乱用されたリファクタリングはシステムを破壊してしまいました。 ファウラーが定義したリファクタリングやツールが安全に行うリファクタリングでない乱暴な変更にも「リファクタリング」を掲げられてしまうと、「リファクタリング禁止」と言いたくなるのも当然でしょう。 同時にGitHubの台頭によるプルリクエストレビュー（プルしてねーよなぁ、とかいう脱線は プルリクエストとマージリクエストと。 - 日々常々 を参照ください）が一般的になり、GitFlowをかわきりにさまざまなブランチ戦略が考案され、GitHubのようなリポジトリは「main ブランチの保護」を機能として備えるようになりました。プルリクエストレビューやメインラインの保護に従うとどうなるかはTidy First?の第2部に詳しく書かれています。 言葉の乱用の結果、経験値を貯める場が失われ、リファクタリングが存在しない「動いているものに触るな」が優勢になります。 リファクタリングはこうして致命傷を負いました。

リファクタリングには訓練が必要です。 安全に素早く適切にリファクタリングを行うためには、リファクタリングを繰り返してフィードバックを得なければなりません。 リファクタリングはプロダクトで行わねば、本当にこんがらがったコードに対するリファクタリングを行う力はつかないと思います。 「リファクタリングやったことない」「久しぶりにリファクタリングするか！」のような状態で行われるリファクタリングは、おそらくかなりの手探りになり、おっかなびっくりでやって時間に対して効果がでないか、やったはいいもののコレジャナイという結果に終わります。 私が「リファクタリングタスク」などに否定的なのはこういう理由です。 リファクタリングを呼吸のように行うこと。行えば行うほどリファクタリング力はついていきます。この機会が奪われてしまい、リファクタリングの力がつかないのであれば、リファクタリングは行われなくなるのは当然でしょう。

本書はこれに対して、リファクタリングのうちごく軽量で安全な「整頓」を別に識別し、リファクタリングを復活させる足場を改めて作るもの。というのが私のサブタイトルの意図です。 整頓から広がって、経験値をためレベルを上げ、もう少し広めのリファクタリングも息を吹き返すことを望みます。 そのために整頓は整頓として、今度こそは、整頓に致命傷を負わせないように丁寧に扱う必要があると思っています。