完全食漬けで1年過ごした結果

特に問題なく生きてます。健康診断とか献血とかの数値的にはよくなってたりする。

内訳

• 合計 1,857kcal * 365日=677,805kcal
• COMP 440,000kcal
• Huel 13,600kcal
• BASE BREAD 4,208kcal

2020-04-01から2021-03-31の1年分。約67.5％です。後述のようにわからないものの扱いが雑なんで5%くらいは上下するかもだけど。

お値段は 353,480円。同じ割合で100%換算すると、年の食費50万弱……多いのか少ないのかわからんな。

iPhoneの記録

ものすごく雑な摂取エネルギーの記録。 COMPとかお菓子とか、カロリーが明記されてあるものは数値通り記録してるけど、外食でメニューに書いてないのとかは「値段＝kcal」と言うルール。1日5,000kcal超える日とかあったけど気にしない。あと自炊分の野菜はゼロカロリーで、肉だけカウントしてる。

摂取エネルギー少ないけど、自宅仕事＆ほぼ出歩かないわけで、多分この辺で落ち着くんだろうなぁと。運動しなきゃなーと思いながら、思うだけ……。

あ、身長は175cmちょいです。鴨居にギリ頭をぶつけないくらい。（低いところは当たる）

この辺の記録を続けるのにiPhoneのショートカット作って、ワンタップで入力（体重は前日の値が出る）ようにしてる。直接記録できる体重計使えばもっと楽なんだろけど。

道具とか

はかりと浄水器くらい。

タニタ クッキングスケール キッチン はかり 料理 デジタル 1kg 1g単位 ホワイト KD-187 WH

COMPとかHuelとかはでかい袋に入ってくるので、量を測る必要があります。スコップで雑に入れてもいいんだろけど。

ブリタ 浄水器 ポット 浄水部容量:2.0L(全容量:3.5L) アルーナ XL マクストラプラス カートリッジ 1個付き 【日本正規品】 ホワイト 塩素 水垢 不純物 除去

初めはミネラルウォーターとか煮沸した水とか使ってたんだけど、沸かしたてで飲むのは辛い（と言うか湯でシェイクすると噴き出る）。 日本の水道だしいっかーとか思って、ブリタ通すだけで飲んでる。

いろいろ

• 現場に行っていると昼食はまず外食だし、夜もなんだかんだで食べたり飲んだりするから、こんな機会でもなきゃやらんね。
• 粉系（COMPやHuel）は水分がないので賞味期限も長い。3ヶ月以上はある感じ。BASE BREADはこれらに比べると短い。
• そんなわけで保存食も兼ねてたりする。
• COMPは20日ごとに1箱（32,000kcal）届く。
• 全部COMPだったら若干足りない計算だけど、ちょっと多いくらい。2箱溜まったらスキップな感じ。
• Huelは最初「なんじゃこりゃ」って思ったけど、1袋終える頃には慣れてた。
• 1回買ったら定期販売以外の輸出がストップしたのでそれっきりだけど。さっき見たら再開してたな。
• BASE BREADはあまり好きじゃない系。好みってあるよね。
• 食材の買い物がなくなった。
• ゴミがほとんど出なくなった。台所の排水溝が綺麗。洗い物がない。
• これ都市に住んでる意味なくね？
• 記録すんの面倒だけど記録しなかったら食べたの忘れる。飯はまだかのう？
• 「朝昼晩食べてる？」みたいなのに答えられなくなった。小腹が空いた時に適当に。
• 歯や顎が弱るのを懸念してひたすらガム噛んでる。
• ガムの噛みすぎで顎の付け根（耳のちょっと下）が筋肉痛な今日この頃。ほどほどにしましょう。
• 牛乳と混ぜるのが好き。たまにコーヒーも混ぜてる。

別に感染症の影響で意識的にやったわけじゃなく、偶然と言うか、便乗？元々出無精だからね……。

ってことで白い粉にまみれて生きてます。

irof.hateblo.jp

今は小麦粉もないや。全部ホットケーキになっちゃった。

追記: 飽きないの？

もともと食に飽きとかを感じないタイプなんですよね。三食カレーでも問題ないし、三日つづいてもいいとか思ってる。 人と食べに行く時に「昨日この店行ったから今日は別にしましょう」みたいなことはしますが、正直なところ相手に気を使ってるだけで、自分は同じ店が連発してもばっちこいとか思ってるくらい。「何食べたい？」に「なんでも」と答えるダメなやつですが、心の底から本気でなんでもいいと思ってて、例えばマクドナルドと言われても「いいっすね！」となるのが私です。マクドナルド理論の理屈はわかるし場合によっては私も使うけど、元ネタになる食事文脈では通じない。

「昨日何食べた？」「そば」「じゃあそばやめておきましょうか」←これで自分が聞かれてる側だとそばで構わないし、むしろ選択肢を狭めることを心苦しく感じてたりする。

まったくこだわりがないわけではなく、食べるなら美味いもの食べたいとは思ってる。とはいえ機会があれば選ぶくらいで、機会を作ってまでとは思わない。そんな程度。食を優先する人を否定する気は一切ないと言うか、そう言う人が居たら喜んで着いていくくらいではある。

たまにジャンクなの欲しくなって週1回くらいつけ麺やまぜそばを食べに行ったりはしてる。 これが飽き対策なのかもしれないけど、1ヶ月いかなくても別にストレスとかは感じなかったなぁ。。。

こう言うジャキーなの。家の近くの「潰れたらやだなー」って店で客単価高めのメニューを頼んでる感じ。

開発時間の内訳を眺めてみよう

開発効率を上げたいとか、開発速度を上げたいと言うのはプログラマの自然な欲求だと思います。 「そう思いはするもののどうすればいいかわからない」のであれば、開発時間の内訳を眺めてみましょう。

この図はグルーピングが微妙だったり、重要なものが抜けていたりすると感じるかもしれませんが、雰囲気は伝わるかと思います。使用している技術要素や取り組んでいる内容によって項目レベルでなかったりもします。参考程度に。

さて、単に「開発効率」と言うと、「コードを書いている時間」に目が向きがちです。これはさらにタイピングの時間だとかに分けられるかと思いますが、実際のところ、ここに割かれる時間は全体で見れば誤差のようなものです。もちろん早いに越したことはありませんし、無意識に書けるようになれば思考を他にやりながら書けるようになります。実際ある程度慣れた方であれば、コードを書きながらコードを読み、抜け漏れに気づいたり、リファクタリングを考えたりしてると思います。ここで重要なのは、短絡的にコーディング効率を求めても思うように改善はしないと言うことです。

もし「調べている時間」の比重が大きく、プロダクト自身のコードを読むのに時間がかかっている場合（図では「同様の機能を探している時間」や「呼び出し元や呼び出し先を調べている時間」が該当します）は、リファクタリングやコメントの追加が役に立つかも知れません。コードリーディングを重ねるでもいいかも知れませんし、時間が解決する問題かも知れません。調べている時間の比重が大きい時に、コードを書く時間を短くする施策の効果があまりないのはわかると思います。

時間のとられているものが識別できれば、そこに対して具体的なアプローチが取れます。ものによってはプロセスの組み替えによってそもそもその時間をなくすこともできます。たとえばテストファーストは作ったものを確認する時間を削減できますし、型パズル（コンパイルエラーの解消）はリファクタリング機能を使ったりコンパイルエラーの即時解決によってゼロに近づけられるでしょう。もちろんそれにより他の時間が増えたりはします。良いことしかないアプローチであれば既にやってるはずなので、何かしらのトレードオフは常に発生します。合ってるかどうかを見極めるのに、対象の識別が役立ちます。

言うまでもありませんが、図の中にない「質問の返答待ちになっている時間」とか「説明してもらっている時間」とかもあります。この整理の中では、他人が絡むような自身で制御できないものを混ぜない方がいいかなと思っていますが、「ドキュメントなどの情報を確認している時間」に入れたりもできるかも知れません。別のグループを作ってもいいと思います。グルーピング（左側）は直接アプローチできるものにできるていると良いかなーと思っています。ここで「考えたり調べたりしている時間」には思考法や情報整理の技術が役立ったりします。

思考法図鑑 ひらめきを生む問題解決・アイデア発想のアプローチ60

問題解決のための高速思考ツール

自分の開発の時間の内訳に向き合って、どこを改善すると効果がありそうかを考えてみるのもいいんじゃ無いかなーと思うわけです。重要なのは「時間」という単位を揃えること。違う単位は比較不能です。効率とか生産性とか、どうとでもハックできる数値を使用しない。この辺りの整理ができていると、見積もり精度が上がったり、差分がある時の説明が明快になったりします。そう言うのを外に出す目的にやると辛くなるのでお勧めしませんが。。。

一つ注意。この手の時間は体感値と実測値に大きな乖離があるので、なるべく計測しましょう。とはいえ厳密に記録しようとすると手間がかかって続きませんので、無理せず記録できるのがいいなと思います。もともとグルーピングも大雑把ですし、ポモドーロと併用して25分内の内訳は体感（25分内ならそんなズレないでしょ）とかで十分かなと。ペアプロなどをしてるならナビゲーターに記録してもらったりしてもいいと思います。

このやり方は個に閉じているので、一人でも始められます。と言うか、下手に複数人の絡むような不確定要素を混ぜない方がいいと思ってます。全体最適が要らないとか言うわけではなく、これはこれ、それはそれって感じ。

関連

irof.hateblo.jp

「機械的な対応をしている時間」が多いと感じた場合、量を量のまま扱っている可能性があるかも知れない。

コミット対象をよりわけるのをやめてみよう

git add {ファイル名} でステージングするファイル単位で選べます。10ファイル変更しててそのうち3ファイルだけコミットしたい時とかに便利です。

git add -p でステージングする変更を行の塊単位で選べます。関係ないコメントを足しちゃったのとか、うっかりついでに変えてしまった変更をコミットから避けたり、別のコミットにしたい時とかに便利です。

間違いなく便利な機能ではあるんだけど、常用するものじゃないと思ってます。

なので

git add -A を基本にする。

……とか言いつつ git add . を常用している私。単にタイプ数と手の慣れ。ちなみにgitのaliasは使わない派です。これは違う環境でコマンド叩く機会が多かったりする都合です。

理由

を並べてみます。

コミット対象を選択するのがいちいちブロッキングなので時間がかかる

10ファイルの変更から3ファイル選択する時間は git add . より絶対に長い。tabで1文字で補完できるとしても git add x<tab> y<tab> z<tab> が必要になる。どれを選ぶかの判断もしなきゃいけなくなる。選び間違いもある。

これはデバッガで止めながら動作確認しているようなものだと思う。デバッガは強力で間違いなく有用なんだけど、それ一辺倒になると時間が無限に溶ける。デバッガは道具箱には入れておかないといけないものではあるけど、きっと最初に使う選択肢ではないはずなんだ（脱線）

コミットした状態は自分の手元で過去のどの瞬間にも存在しなかった状態になる

そのコミットでコンパイルやテストが通るかは確認できていないし、きっとその確認もしないままになる。必要になった時、たとえば git bisect とかでその辺が混じるとよくわからないことになってしまう。

コミット漏れが発生する原因になる

• A 「pushしました！」
• B 「ありがとう！……コンパイル通らないんだけど？」
• A 「あ、コミット忘れてました！！」

……なやりとりをする必要があるの、だいたいこれのせい。二往復したりもする。言ってることは一つ前と同じ。

コミットしちゃいけないファイルの存在を許すことになる

ローカルで動作させるためにコードを変更する必要があるライブラリやフレームワークは存在した。今もする。 コードではなくローカル用に設定ファイルを編集するのは当たり前だったりした。 ある程度は制約や効率もあるんで仕方がない。

けれど、クラウドやコンテナが後押しになって、秘匿情報は環境変数など他のもの経由で渡せるようになってきている。本当に仕方がないかは見直してもいいと思う。

継続的デリバリー　信頼できるソフトウエアリリースのためのビルド・テスト・デプロイメントの自動化 (アスキードワンゴ)

もう日本語訳が出版されて9年経っている継続的デリバリーだけど、ビルドしたバイナリがすべての環境で同一のものを使うことを示していた。当時はwarやearの中に環境依存の設定をねじ込んでいたんで難しいだろうって思っていたけど、今はほとんどそう言うのも見なくなっている。

なんでこんなこと書いてるかってと

コミットしちゃいけないファイルや変更がある場合「コミットしないように気をつける」ことになる。 人の注意力に頼ったプロセスは、その事象を起こしてしまって良いように設計しなければならない。

でなければ誤った際に「注意不足でした」「もっと注意します」しかなくなる。 こうなると問題の責めが個人に持っていかれて、改善の発見がしづらくなる。

……とか言いつつ、自分が注意不足でやらかす側だから、自分を甘やかすために仕組みの方に持っていきたいだけなんだけどね。

一部のコミットだけ丁寧に取り繕っても意味がない（04-01T11:21 追記）

「コミット粒度を揃えよう！」と掲げるプロジェクトは結構あります。それがうまく機能している現場はあまり見ません。できてるところもありますが、私の観測範囲では多数派ではないです。

Gitの使い方すらままならないこともしばしばです。 チームメンバーが漏れなく壊さずコミットできるかを確認する必要がある程度には、Gitを前提に置くのは難しいです。 もちろんcommitやpushはできますが、複雑なコンフリクトが発生した時にスムーズに解消したり、ローカルリポジトリがおかしくなった時に原因を切り分けたりとかは一定水準以上のスキルだと思っています。

そんな状況で「自分の意図した変更だけ選んでコミットする」ようなことを「やるべきこと」に加えるのは、余計な問題の発生を増やすことになります。ぶっちゃけどうでもいいから手元のファイルを全部確実にコミットしてくれれば、あとはどうとでもなるんです。コミットされていない、pushされていない状況だとどうしようもないんで、先に挙げたような「コミット漏れてました！」なんてのが起こらないのがまずありきです。……脱線が過ぎた。

閑話休題。コミットログを読んだりする時は「コミット粒度はバラバラなものだし、コミットには複数の変更が混ざっている」を前提に読んでます。たまに読みとりやすいコミットもありますが、それは儲けってくらいの温度感。もちろん混ざってない方がいいんで、それを目指すのは諦めずに。

うまく行っているOSSはありますが、そこにはかなりのパワーが割かれて文化が醸成された結果です。それを現場で再現するのは結構難しいんじゃないかな。仕事なんだから強いルールで縛れば？そう言うアプローチもありますね。雁字搦めの結果は推して知るべきかと思いますが、うまく行ったら教えてください。

どうすれば

.gitignore でちゃんと避ける。 環境依存な情報は外に置いて取り込めるようにする。

と言うのができる環境ならって話だけど、数年前よりは確実にやりやすくなっている。と思う。 できない環境もある。それは仕方ない。心の片隅に置いておいてください。

でも1つのコミットに複数の変更混じるじゃん

混ざる状態で進めてたんですよね、としか……（ブーメラン）

偽造するより素直に歴史おいとく方がいいよ。今よりわけられるなら未来でもよりわけられるよ。必要になった時でよくないかな、全部にやらなくてもいいと思うんだ。

コミット単位で分析してたりして、きっちりわけるルールが敷かれているリポジトリなら、わけた状態で進められるようにした方がいいと思います。 私がそう言う時にやるのは先にコミットメッセージを書いた空コミット作って、その後に変更をamendしていく形。 テストファーストやアサートファースト、チケットファーストと同じ感じでコミットファーストです。小さいゴールなら寄り道も少ないし。

先にも書いたように、混ざってていい。混ざってる事実を記録して後で振り返って、直すべきだと思ったら、混ざらないプロセスを組み立てていこう。

でもGitの一般的な機能じゃん

じゃーなんでステージングエリアなんてあるんだって話だけど、まぁ便利だからだよね……必要な時に便利に使うのはいいけど、常用するのはやることが少なくて安全なプロセスだと思う。おかしなことになった時になんとかする時、ステージングエリアがすごく役に立つ。

機能があるからと言って使わなければならないってことはないんです。

でも git add -A とかがデフォルトになると、add + commit が二段階なのが無駄に感じるよね。Subversionならcommitだけだったのに…… そうだSubversionに戻ろう！！

git add . とかした時のちょっとした反応とか、git status した時の赤と緑の具合みた時とか、そう言うとこから何か感じ取ってたりする。何か感じ取ってるのは間違いないんだけど、なんか言語化できてない。なんだろなこれ……（そのうち考えてみようかな）

私の距離感

間違いなく便利な機能ではあるんだけど、常用するものじゃないと思ってます。 使えるようになった上で、平時は使わないでおこう。それくらいの距離感。

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

本稿はこの本のレビュー中に思ったことだったりする。

04-01T09:52 追記: push前に整理するか否か

以前書いたブログが関連にあるので。

irof.hateblo.jp

push前にrebaseなどでコミット整理を行うかは、状況によります。とはいえ基本的にしていません。 先に書いたように

偽造するより素直に歴史おいとく方がいいよ。今よりわけられるなら未来でもよりわけられるよ。必要になった時でよくないかな、全部にやらなくてもいいと思うんだ。

って感じです。要らないコストを払う必要はない感。

イミュータブルデータモデルとかも若干近いんだけど、起こった事実はそのまま記録しておいて、見る必要があった時に編集するでいいと思っている。それが参照頻度が非常に高いものなら事前に整理しておく価値はあるのだけど、Gitのコミットを私（や関わっているプロジェクトで）見たいと思った時、綺麗に整理されていることを前提にはしていない。むしろ混沌としたコミットログを読み解くくらいの気持ちでやってて、それでも必要な情報にたどり着くまでそんな手間はかかっていない。

細かい未整理のコミットが膨大にあって読み解くのに労力がかかったところで、読み解きが必要になる（「必」ね。参考に見るくらいのは除いてる。）頻度が低いなら、コミットの整理にかかるコストを払うのはあまり効果がないんじゃないかなと思っている。参考に見るくらいなら傾向を把握したりとかなのでそもそもそんな時間かからないし。

整理されてないとcherry-pickしづらい、とかは確かにあるけど、改変された未テストのcommitをcherry-pickしてもうまくいかないことの方が多い印象がある。cherry-pickじゃなく手で移すなら整理されてるほうがいいんだろけど。

「それはあなたがコミットログを読まないだけで、他のコミットログを読む人に苦労を強いているだけでは？」とかも考えたりしますが、どちらかと言うと私はコミットログを読んだりコミットグラフとかコミット時間とか諸々見てるし、PRレビューをするときは全コミット追ったりするし（未整理で構わない。むしろ未整理の方が好ましいと考えてるくらい。）、有効に活用している方だと思ってます。もちろん恒常的に分析したりしてる人ほどではないけど……。

コミットを改変すると歴史が歪み、情報が失われる。その方がリスクが高いと思っています。と言うことで、余程でない限り、コミットの整理は不要と考えています。