[Misreading Chat](https://misreading.chat/2022/05/12/92-software-development-waste/)で紹介されていた[Software Development Waste](https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/papers/icse17sedano.pdf)という論文。

この論文に載っていたTypes of Software Development Wasteというソフトウェア開発のムダについて類型されていたものが面白かったので日本語にしてみた。

# 誤った機能・製品の構築
## ムダ
ユーザーニーズやビジネスニーズに対応していない機能・製品を構築するコスト
## 原因
- ユーザーの要望
  - ユーザー調査、検証、テストを行っていない、ユーザーフィードバックを無視している、ユーザー価値の低い機能に取り組んでいる
- ビジネスの要望
  - ビジネス関係者を関与させていない、関係者からのフィードバックが遅い、製品の優先度が不明確
## 一言メモ
ユーザーの声を汲み損ねていたり、えいやで作ってしまった機能とかまぁムダですよねと言われてばそう。割とよく起こりがちである。

# バックログの管理ミス
## ムダ
作業の重複、価値の低いユーザー機能の迅速化、必要なバグ修正の遅延のコスト
## 原因
- バックログの逆転
- 同時に多くの機能に取り組む
- 作業の重複
- 十分に準備されていないストーリー(以降"ストーリー"は"機能"と同じ意味で使われてるっぽい？)
- 機能開発とバグ修正のアンバランス
- テストまたは重要なバグ修正の遅延
- 気まぐれなスラッシング(訳が微妙)
## 一言メモ
取り組むべきタスクの優先度づけがうまくできてないと、あるべき順番であるべき機能がユーザに届けられなくなるのでそういうのはムダですよねという感じか。

# リワーク(手戻り)
## ムダ
正しく行われたはずの納品物を変更するコスト
## 原因
- 技術的負債
- ストーリーの却下（例：プロダクトマネージャーがストーリーの実装を却下）
- 完了の明確な定義がない（ストーリーが曖昧、設計モックの推測）
- 欠陥（テスト戦略の不備、バグの根本原因分析がない）。
## 一言メモ
仕様の作り込みが甘かったり、そもそもユーザーテストが不十分であやふやな機能が設計されたりして作り直しが発生するのはムダですよねという感じ。技術的負債やバグ起因で作り直しが発生するのもここの無駄にカウントされてる。

# 不必要に複雑なソリューション
## ムダ
必要以上に複雑なソリューションを作成するコスト、機能、ユーザーインターフェース、コードを単純化する機会を逃す
## 原因
- ユーザーの視点から見た不必要な機能の複雑さ
- 不必要な技術的複雑さ
  - コードの重複、インタラクションデザインの再利用不足、前倒しで作った複雑すぎる技術的デザイン
## 一言メモ
オーバーエンジニアリングの結果、なんかかっこいいけど誰も容易に変更できなくなってしまったみたいな実装はたまにある気がする。しかもそれをやった人が退職してしまい結局全部書き直す羽目にみたいな、、やり直しが発生するという意味で確かにそういう実装は結局ムダと言われればムダ。

# 不要な認知負荷
## ムダ
精神的エネルギーを不必要に消費するコスト
## 原因
- 技術的負債に苦しんでいる
- 複雑または大規模なストーリー
- 非効率なツールや問題のあるAPI、ライブラリ、フレームワーク
- 不必要なコンテキストスイッチ
- 非効率な開発フロー
- 整理されていないコード
## 一言メモ
開発フローやツールや負債に起因してMPを過剰に消費させるのはムダですよねというやつ。

そういえば精神的に負荷がかかることそれ自体がどのくらい開発の生産性低下を引き起こすのか知りたいんだけどそういう研究あるかな。例えば技術的負債によって発生する精神的な負荷は自体は実は生産性を低下させてなくて、技術的な負債そのものが生産性を低下させているだけみたいな。

まぁMPが過剰に減らされるのは人間をリソースと考えるとムダだよねというのは当たり前だけど。

# 心理的苦痛
## ムダ
不要なストレスでチームに負担をかけるコスト
## 原因
- チームのモラルの低下
- ラッシュモード(締切がきつすぎるみたいな状況)
- 対人関係やチーム内の対立
## 一言メモ
これも上のやつと似ててMPの過剰消費に繋がるのでムダというやつ。

そういえばフルリモートでissueベースで働いてると対人関係みたいなものを気にすることがほぼ無くなった。issueだけの関係だと後腐れなくて事務的に処理できることが多くて楽。一方でプロダクトを作っていくチームの一員としてビルドアップから参加する必要があると柔らかなコミュニケーションが必要になるので気を遣う。

# 待ち時間/マルチタスク
## ムダ
マルチタスクに隠れがちなアイドルタイムのコスト
## 原因
- 遅いテストや信頼できないテスト
- 信頼できない受け入れ環境
- 不足する情報、人、設備
- フィードバック遅延によるコンテキストスイッチ
## 一言メモ
テストが遅すぎたりPRのレビューがスルーされたりして先に進めない時に発生する待ち時間はムダですよね、というやつ。確かによく起きがちではあるが、PRのレビューで発生する待ちはどうしようもないところがあるな...。

# ナレッジロス
## ムダ
チームがかつて知っていた情報を再取得するコスト
## 原因
- チームの解散や移動
- 知識のサイロ化
## 一言メモ
チームの移動や変更でナレッジの共有をやり直すのに発生する時間とかがムダですよねというやつ。これは暗黙知を減らすために各人が情報をオープンに見える化しておかないと発生しがち。

ベテランの特定の人に質問が集中しちゃったりするとその人の本質的な作業時間が減るのもよくある。そういうベテランはそのプロダクトのあらゆることを知っているから開発のパフォーマンスも他の人より出せるはずなんだけど、オンボーディングを手伝うコストが度々発生しちゃたりすると勿体無いな〜となる。

# 非効率的なコミュニケーション
## ムダ
不完全、不正確、誤解を招く、非効率的、または不在のコミュニケーションのコスト
## 原因
- チームサイズが大きすぎる
- 非同期コミュニケーション
  - 分散チーム、分散ステークホルダー、他のチームへの依存、チーム外の不透明なプロセス
- 不均衡
  - 会話を支配する、聞かない
- 非効率な会議
  - 集中力の欠如、振り返りのスキップ、毎日ブロッカーについて話さない(どういうこと...)、会議が長引く（例：長い立ち話）など
## 一言メモ
コミュニケーションがうまくいかないとムダですよねみたいな感じ。幅広いけどもまぁそれはそう。会議に関しても不要な話で盛り上がっちゃうとか曖昧な目的始まっちゃって終わりどころが見えずダラダラ続くみたいなことはよくある気がする。

# 雑感
ソフトウェア開発におけるあるあるネタまとめみたいな様相である。こういうムダは確かに至る所に散見されるが、これらをどうやって取り除くかというのは中々難しい問題だ。だがその辺の対処法についてはこの論文に書いていない。

この辺りのムダを取り除くためのプロセス改善の話はどういう本(や記事や論文)を読むと良いのだろうか。

ソフトウェア開発におけるムダ

![IMG_2791](https://user-images.githubusercontent.com/1421093/174434078-aca7b457-1701-4cde-a1a1-2ad6ae79acf1.JPG)


下北沢にある[202カリー堂](https://www.instagram.com/202currydou/)というカレー屋の抹茶バスクチーズケーキが旨い。

個人的には過去に食べてきたバスクチーズケーキの中で1番好き。チーズの味が濃厚、程よいとろみ、深みのある抹茶のほろ苦さ、香ばしい焼き加減、抹茶クリームの甘味が全てマッチしてて最高。少し時間が経つと(溶けて?)柔らかくなってしまいやや口当たりが微妙になるので提供されたらすぐ食べた方が良い。

店名にある通りスパイスカレー屋がメインではある(しそれ自体も普通に美味しい)んだけど、ここは抹茶のバスクチーズケーキ屋を名乗った方が良いレベル。

その他にも抹茶のプリンもマッドな口当たりでたまらん旨さだしテリーヌも良かった。スイーツ全般ハズレがない。

下北沢駅からのアクセスも良いしもちろん人気店なので休日の昼間やティータイムは最低でも1時間は並ぶがその価値はある。夜は列が落ち着いて少し早めに入れるので夜に行くのはアリかもしれない。

客層は20~30代くらいの女性が9割くらいなのでその辺はおっさんが単騎で乗り込むには少し躊躇するかもしれないけど気合いで並びましょう。

ちなみにスイーツ単体注文時はドリンクを注文しないといけないのでその点は注意が必要。

202カリー堂の抹茶バスクチーズケーキ

楽天モバイルからの移行を検討している。前々からニュースになっているが今まで1GB以下のデータ利用で無料だったのが7月からなくなってしまうからだ(追記: 2022年10月末までの最大4カ月間は月額データ利用量が1GB以下の場合、月額料金が実質無料だった →[詳細](https://network.mobile.rakuten.co.jp/fee/un-limit/info_20220513/))。
- [楽天モバイル「0円」終了。7月からは最低1078円](https://www.watch.impress.co.jp/docs/news/1408944.html)

# 要件
要件的には下記のような感じ。

- 1台目のスマホとして使える
- 電話番号は要る(電話はしない)
- SMS受け取れないと困る(が、送ることはない)
- ネットは外出時に検索等の静的サイトやアプリで使えればOK。1GB/月あれば十分。
- 家ではWi-Fiと接続する

# 合理的シンプル290プラン
これら要件を勘案した上で移行先の選択肢を検討した。

といっても候補がたくさんあってマジで訳分からんという感じだったが、いくつか調べた感じだと自分には日本通信の[合理的シンプル290プラン](https://www.nihontsushin.com/plan/plansimple.html)が合っていそうだと思った。

上記要件を全て満たした上で、ドコモ回線で1GB 290円/月というプランだ。

楽天モバイルでのデータ通信はもともと1GB/月以内に収まる使い方しかしていなかった。なのでこのプランで十分である。

さらに1GBを超えると+1GBごとに220円なので2GB使っても510円/月だけ。外出先でYoutubeを見たりゲームをするような人には全く向かないけどプライベートも引きこもりのリモートワーカーにはピッタリだと思う。

ちなみにSIM or eSIMを選べるが初期手数料はどちらも3300円かかる(どこも同じ。7月以降の楽天モバイルx3ヶ月分)。

# その他の候補
## [povo](https://povo.jp/)
基本料無料。年に2回トッピング購入が必要だがそれを加味しても440円/年で済む。多分1番安い。

選ばなかった理由は安すぎる回線は楽天モバイルみたいにどこかで終了しそうだな〜という気がするのと、トッピング購入がちょっと手間。

auの回線だし速度は十分だと思うし(ただし0円0GBの時は128kbpsになる)、何より1日だけ使い放題にしたりとかなり細かく料金をカスタマイズできるのは面白いなとは思った。

## [IIJmio](https://www.iijmio.jp/hdc/spec/)
2GB 850円/月。悪くはないけど日本通信の方が安かった。

## [NUROモバイル](https://mobile.nuro.jp/plan/)
3GB 792円/月。結構安い方だけど、これも日本通信の方が自分にあってたので却下。

## [OCNモバイルONE](https://www.ntt.com/personal/services/mobile/one/charge.html)
昔使ってたやつ。0.5GB 550円/月。月額だけ見たら安いけどさすがに1GBは欲しかったし、日本通信の方が安い。

## [HIS Mobile](https://his-mobile.com/domestic/planlp_2022splan)
1GB 550円/月。100MB未満だと290円/月になる。安いけど100MB未満のことは流石にないので却下。あとは申し訳ないがHISという名前にやや不安があった。

## その他
他にも[ahamo](https://ahamo.com/plan/)・[LINEMO](https://www.linemo.jp/)・[mineo](https://mineo.jp/price/)・[UQ Mobile](https://shop.uqmobile.jp/shop/)など色々と移行先の候補はあるが、どれも自分のユースケースには微妙で割に合わなかったので書いてない。

あくまでも今回は自分の要件に合っているのはどこか？という話であり、特定のサービスを勧めたり贔屓したりしているわけではないことはご了承願いたい。データ通信のみとか逆に20GB以上プランとかだと話が変わってくると思うし。



楽天モバイルからの移行先

「作るのにどれくらいかかりますか？」と訊かれるとイラッとしてしまうことがある。そうなってしまう理由についてある程度自分の中で言語化しておきたい。

そういう訊かれ方をする状況は大抵小規模なMTGで何かのプロジェクトの企画段階で起きる。OOなユーザー向けにXXという機能を追加しようかと思っているんですが、これ作るのにどれくらいかかりますか？といった具合だ。

こういった質問が飛んでくる場合は決まって企画側で未確定の要素が多い。こちらとしては未確定の要素があると曖昧の見積りしかできないし、当然不測の事態を想定して多めにバッファを含めた回答になる。そうすると(おそらく)想定よりも長めの期間の見積りを返された企画者は開発にそんなに掛かるのか...と不満げな様子になってしまう。こちらは困らせたくて長めに見積もりを出しているわけではないのに開発にそんなに掛かるのか...という雰囲気を出されると開発者としての力量を疑われているように感じてしまってイラッとしてしまう。

その他のパターンとしては企画の中に未知の開発が含まれている場合だ。例えばOOOというサードパーティのSDKを使ったBotシステムを作りたいんだけどもこれ作るのにどれくらいかかりますか？といった具合である。

OOOというサードパーティのSDKに関して過去に利用した経験がなく触ってみないとわからないパターン。その際はこのSDKはまだ使ったことがないのではっきりとどのくらいとは言いづらいので少し調査してからの回答でもいいですか？と聞くものの、企画者は何やら急ぎで回答がほしいようだ。そこでざっくりとでいいのでどのくらいか分かりませんかね？と言ってくる。仕方ないので未確定の要素を多めに勘案して多めの見積もりをいう。というこの一連のやり取りでイラッとしてしまう。

企画者の中にはエンジニアは技術に関して全てを把握しているかのように考えている人がいる。そんな人間がいるなら教えてほしい。自分の専門に関することならつゆ知れず、大抵ははっきりと決断しきれない技術的概念の方が多いので常に調査しながら開発している人の方が多いはずだ。

こうやって少し言語化してみると、「こんな簡単そうな開発にもこんな時間がかかるのかよ」とか「OOに関する知識ないんだ」とか **お前スキル不足なのでは？と暗に突きつけられてしまうような物言い** にイラッとしてしまうのだなとわかった。

もちろん相手にそんな気はないと思うしそれぞれの都合があると思うから仕方ないとは理解してるのでこういう企画者滅ぶべしとかは全然思ってないです。あくまでも自分の気持ちを噛み砕いて整理したいという意図で書いている。


「作るのにどれくらいかかりますか？」と訊かれるとイラッとしてしまう

最近というかここ1年くらいなんだけどアニメを全くといっていいほど観なくなった。昔は毎クールどんなアニメが放送されるのかチェックしていくつか嗜むみたいなことしていたのにこれはどういうことか。

一つは興味が薄れたこと。アニメに何を求めて観るかは人それぞれ自由だが自分の場合は声優だった。ストーリーはもちろん好き嫌いあるけど作画とか音楽についてはそんなに興味がなかった。子供の頃から"声"が好きで高校では放送部でアナウンスとかをやっていたくらいだ。一時期は声優のラジオを毎週20番組くらい録音していたりなどライフワークになっていた([radiorec](https://github.com/YuheiNakasaka/radiorec)という専用のサーバーも書いたりしてた)。ところがその興味が徐々にアイドル(ハロプロ)へと軸足が移っていき、今ではもうラジオの録音すらやめてしまった(声優情報はちょっとだけ追ってるけど)。

アニメもアイドルもどちらも追えばいいのにという意見は尤もだけど、これが年齢によるものなのか興味を絞ってその空いた分の時間でよりそれを深めたいという欲求が20代の頃よりも強まったように感じる。幅広く好奇心のままに手をつける体力が無くなったのかもしれない。

もう一つはアニメの制作現場を近くで見過ぎていること。現在はアニメーターと同居しているので近くでアニメ制作の声を聞くことができるのだがそれがとても2022年とは思えないような環境で辛くなってしまっている。元々何年も前からアニメーターの待遇が良くないと言われてはいたがこんなに大変なのかと驚いた。アニメSHIROBAKOでも炎上プロジェクトに万策尽きたと監督が騒いでいるシーンが印象的だったが、あれはリアルよりはだいぶマシである。

具体的なエピソードを挙げるのは控えるけど雇用契約は杜撰だし休みは全然無いし長時間労働(多分月300時間くらいは普通にやってる)しそれで給料が大学新卒の初任給に届かないしかつ正社員ではないみたいな感じの人(もしくはそれ以下)の人がザラにいる。食っていけないからUberなど隙間バイトをやってるみたいな人もいるっぽい。制作や演出の人たちでも似たようなもんのところが多めということでまじか...となっている。

それでも待遇改善をしようと活動している人達や団体ももちろんいるが、業界全体のほとんどが下請け構造で予算も大してないから下に落ちていく金はそもそもない。映画もそうだがこういう制作はどのくらい成功するのか読めなくて博打的な要素があるから安定させるのは至難の技だ。構造的に誰が頑張っても如何ともし難い雰囲気がある。それでもアニメが毎クール制作されているのはアニメを作るのが好きという気持ち一つで身を粉にしている人達がいるからだ。

自分は世の中のアニメの多くは彼らの削った命で生み出されているというのを間近で観てしまったのでアニメを観るのが憂鬱になってしまった。家畜の生産現場を知ることでヴィーガンになる人が多いようにアニメ制作の現場という現代のプランテーション農場をリアルに見聞きしてしまったが故にその反発でアニメを観るのがキツくなったのだろうなと思う。観た方がお金は落ちるし彼ら業界のためには良いんだろうけども...

アニメを観なくなった

会社にエンジニアが一人になってからもう10ヶ月ほどが経った。もちろん一人であらゆる開発を行わないといけないので負荷は大きい。しかし手に負えないほどの仕事があるわけではないのでなんとかなっている。実務面ではそうなのだが、それ以外の面での影響が個人的には少なからずあったなと感じている。

チームメンバーがいた頃は毎日15分~30分程度の朝会があった。ここでは前日・当日の仕事に関する話はもちろん気になったニュースや好きなアニメの話など自由に話していた。この時間を設けたのは業務上のコミュニケーションロスを減らしたいというよりはむしろPCの前で毎日作業を続けるエンジニアは人と会話をする機会が減りがちなのでとりあえず雑談しようという、ライフバランスを整えたい的な意味合いが大きかった。

別に人と会話をしなくても問題ないのではというご意見も尤もだけど、アルツハイマーで認知能力を低下させないためには規則正しい生活はもちろん他者とのコミュニケーションをおこない、ある程度脳に負荷をかけた方が衰えにくいと言われている。エンジニアは知的生産を行う脳みそが資本の職業だから認知能力を維持する時間にある程度投資してもペイするはずだ。そういう理由から朝(といっても10時とか11時とかだけど)に朝会というものを開催していた。

これが10ヶ月ほど前から無くなってしまったわけである。

加えてコロナの影響で外出も減ってしまっているし家にいながら飯が食えたり何もかも家でできてしまうから他者との接点がほぼ無くなっていることに気づいた。

自分は趣味といえば開発かハロプロくらいなので、そういう話ができる仲間を会社の外にも持っておけばよかったなと少し後悔している。ゲームが趣味の人とかは配信で盛り上がれたり内輪で連携を取るメリットもあったりするからそういう仲間がいてDiscordとかでワイワイしてたりするの見て良さ...などと思ったりする。

コロナ以前であれば勉強会やカンファレンスの現地会場で知り合いができたりする機会もあったがリモート開催が普通になっている昨今ではなかなかそういう機会も少ない。アイドルの現場も同じく。

複数人エンジニアのいる会社に所属しているとそういう機会を手軽に得られるのでお得だったな〜などと思うのであった。

とはいえプログラミングはポジティブな意味で孤独な営みであり、自分はそれが好きである。だから不特定多数の人達でワイワイと馴れ合いたいわけでは全くないけど好きなことについて様々な意見を言い合ってコミュニケーションできる相手や場(大学の研究室みたいなやつとか)は大切にしないといけなかったなと感じている。

一人が好きとかコミュニケーションが嫌いとかそういう人が多いこの職業ではある(し自分もそのタイプだ)けど、それは会話したくない人と会話したくないだけであって、楽しく会話できる有意義な時間を過ごせる相手ともコミュニケーションしたくないやつなんていないよな〜という話。

共通の話題で盛り上がれる人間 探し方 2022 が求められている。


会話

![IMG_2991](https://user-images.githubusercontent.com/1421093/171147566-a974868a-5acc-4f79-84c3-ecfab6bda74f.JPG)

ここ2週間くらい毎晩カレーを食べ続けている。きっかけは同居人がレンジで米が炊ける鍋というものを持っており、その鍋を使うとカレーも作れると教えてくれたことだ。

自分はフルリモートで仕事をしているから出来てると思うが、毎日の食事がほぼ一定である。朝は納豆・昼はnosh+0.7合の米・夜は野菜丼(冷凍野菜2,3種+卵+0.7合の米で作る親子丼みたいな味のやつ)という生活をもうかれこれ1年以上続けている(朝は納豆じゃなくBASEを食ってた時もあったがやめた)。もちろん外食に行くこともあるが土日の付き合いなどの特別な日だけだ。

こういうある意味異常な食生活が許容できている人間なので2週間毎日カレーを食うことなど大したことないのだがそれでもいくつか気づいたことがあるので書き記しておこうと思う。

# 基本レシピ
![IMG_2993_2](https://user-images.githubusercontent.com/1421093/171151680-2d6be9c8-cd2e-4740-9209-9d42aaaa9c24.JPG)

まずカレーの基本レシピだが下記。手抜きはしたいが栄養は最低限摂りたいという点から冷凍野菜をふんだんに取り入れた構成になっている。

### 材料
- カレールー: 1片
- 野菜2種: 適当
- オクラ: 適当
- 水: 90~100cc

鍋にオクラ以外を全て入れてレンジで3分~4分チンする。終わったら取り出してオクラを入れてよく混ぜれば出来上がり。そこに適当にご飯を入れてその鍋のまま食べる(洗い物を増やしたくない)。

という感じ。大体所要時間は5分。

1番重要なのは水の量。少なすぎるか？と思うくらいがちょうど良い。

鍋はAmazonにあるやつだとこの[メトレフランセ](https://amzn.to/3N57Y7g)のやつが近いかも。

野菜に関しては今まで夜は野菜丼というやつを食っており、そのため自宅の冷凍庫に冷凍野菜が常備されている。冷凍庫にはほうれん草・ブロッコリー・インゲン・ナスなどが1袋はある状態。なのでこの中から適当に2種類取って使う。

オクラだけ必須にしてるのはオクラを入れて混ぜることで粘性が増しよりドロドロになるので好みのカレーっぽくなるから。単純にオクラが好きというのももちろんある。

# カレールー
カレールーに関してはこれはまだ実験中ではあるのだが、[業務用のジャワカレー](https://amzn.to/3M2NsTJ)が抜群に美味かった。これは近所のスーパーのPBのカレールーと比較してるのもあるけど、玉ねぎや肉が入ってない分オリジナルのルーの美味さがカレー全体の味に直結しているので違いが顕著だ。

レトルトカレーも試してみたところそれなりに美味しいしささやかながらにんじんやじゃがいもや肉も入っているのでよりいつものカレーっぽくなる。弱点としては冷凍野菜を入れるとその野菜から出た水分のせいでやや水っぽくなるというのがある。あとは固形のカレールーから作る場合に比べて1食当たりの値段がPBのカレーでも60~70円くらい増える。まぁどちらも人によっては大したことないと思うのでこれはこれであり。

ただPBの固形カレーについては絶対やめた方が良い。あれは本当に味が微妙。スパイスも足りないし圧倒的にコクが足りない。にんじんや肉を入れてやっと食える味になるようなルーである。先のレシピで使うとしてもニンニクやみりん、あとは黒糖なんかを入れて調整すれば食える味にはなるがそういう調整は面倒だ。

ということで個人的には[業務用のジャワカレー](https://amzn.to/3M2NsTJ)を推したい。

# 飲み物
ほうれん草とナスが好きでよく使うが、これらは調べてみるとシュウ酸を多めに含むため丸腰で食べ続けると結石ができやすくなってしまうらしい。というのを見たのでカレーを食べるときに牛乳を一緒に飲んでいる。シュウ酸はカルシウムを同時に摂取すると腸で吸収される前にカルシウムと結合して体内に吸収されなくなるらしい。

子供の頃、尿管結石により救急車で運ばれていく父の姿が鮮明に脳裏に焼き付いており、ああはなりたくないという強い気持ちがある。

# 体重
カレーは比較的油が多く使われているので脂質を摂りすぎることになるのではないかという心配もあるが、具材を炒めたりしてない(油を敷いてない)し肉も入ってないので大した油分にはならなそうという判断をしてる。まぁこれは人によっては良くないと思うのでうまくやってほしい。自分はBMIが17台のかなりの痩せ型で太ることに関してはあんまり問題視してない。むしろ太ってくれ...という感じ。

# 栄養バランス
自分の場合は昼のnoshが日毎に別のメニューなので一応タンパク質やその他の野菜はそこでほどほどには摂っているつもり。[あすけん](https://www.asken.jp/)で1日の栄養バランスを計算すると50点~60点くらいで全体的に少なくはなるんだけど、あのアプリで満点取れるような食事にするには補助栄養食品を使ったり色々と無理しないといけないことはわかってるから気にしないようになった(余談だけどあすけんはマクドナルドのポテトが野菜扱いなので便利です)。

というかあすけんで普段食ってる1日の飯を入れて計算すれば、60点取るのもそれなりに大変なのがわかるはず。無料でできるので試してみてほしい。

# 値段
業務用ジャワカレーで先の基本レシピで作った場合、米の分も含めて1食大体100円くらい。コスパは良い。

# その他
他にはトマト缶を使うとか卵を入れるとかアレンジしてみたけどやはりプレーンの業務用ジャワカレーが1番好きだった。栄養素的にはアレンジは良いと思うけどたまにで良いかな〜と思っている。

一旦は安定したスコアを叩き出せる手抜き電子レンジカレーを作れるようになったのでしばらくは続けてみようと思う。

そもそも毎日カレー食うような人間はいないと思うので誰得情報ではあるが参考にしてくれ...

おわり

毎晩手抜き電子レンジカレーを食い続けている

[Web Development with Ruby on Rails](https://amzn.to/3N2XFRl)を読んでる。

modelにロジックは書かない、1コントローラーメソッドに対して1Serviceにしてそこに必要なビジネスロジックは詰めこむ、serviceは1メソッドしかpublicにしない、serviceのpublicなメソッドの振る舞いのみ入念にテストするという割り切った考えは前評判どおりだけど思想強ぇ〜となった。

RailsでDDDとかやろうとするとドメインの整理から始まりmodelはただのDTOにしてentityやvalue object等の実装を用意して、なんというか少なくとも実装に関してはクラスがめちゃくちゃ増えていくイメージだけど著者はむしろそういうのと逆方向(というかRailsとしては自然な方向)に逆らわず標準提供されてる道具を使って、最低限のレイヤーをサステナブルという目的(ここが重要)を達成するためだけに追加するという考えだ。

設計に絶対的な正解はなく、未来・要件・チーム・言語・フレームワークなどにあらゆる環境によって最適な選択は変わるという当たり前のことを思い知らされる感じ。

[良いコード／悪いコードで学ぶ設計入門](https://amzn.to/3PNmkuN)を読んだあとなのでなおのことその実装方針の差が面白く感じた。

良いコード設計ができるというのはこういった多種多様な設計方針や実装方法の引き出しがあり、その中から妥当なものを選択できる能力なのだろうと思う。(もっと広い意味でだけど)アーキテクチャ選択に絶対はないというのは[ソフトウェアアーキテクチャの基礎](https://amzn.to/3POoAly)でも書いてあった気がする。

自分は金にならんプロジェクト(スタートアップのすぐ解散するアプリ開発や少人数開発みたいなもの)ばかりやってきたから将来性についてあまり深く考えなくてもぶっちゃけよくて、そんなに神経質に設計について固執してこなかった。そのツケみたいなもので設計に関するスキルにややコンプレックスがあるから最近はこういう本をいくつか読んで妄想したりしている。

自分のようなバックグラウンドの人間からするとどんなにクソコードでも金を産むコードに対してまずはリスペクトが生まれてしまうという悲しい性。めくじらたててキレ散らかしてる人を見るとなんともいえない感情にならん訳でもない。もちろんそれとこれとは別なのは理解するが....

Web Development with Ruby on Railsと悲しい性

昨日gialogで作ったブログを少しカスタマイズした。

具体的にはOGPの設定やTwitterボタンの設置。

最初GitHubのAPIにそんなに詳しくないからYAML front-matterでIssueから渡ってくるレスポンスの種類にどんなものがあるのかわからなかった。とりあえずはGitHubの[APIリファレンス](https://docs.github.com/ja/rest/issues/issues)を読むと大体解決した。

OGPの画像は記事内を正規表現で走査して最初に登場する画像を設定するようにしている。`/\((http[s]*.+\.(?:png|jpg|jpeg|gif))?\)/i`みたいなやつを使っているが、後方参照のキャプチャしないやつの書き方を思い出せなくてちょっと迷った。今回はキャプチャされてもいいんだけど、気分的に無駄なキャプチャは嫌である。グローバルな一致とかだとパフォーマンス問題が起きたりするなど[詳説 正規表現](https://amzn.to/3NaYcAs)に書いてた気もするから避けられるなら避けた方が良さげ。

あとちょっと困ってるのはOGP画像が仕様を超える解像度だった場合にTwitter Cardでうまく表示されない問題がある。これはどう対応したものかちょっと考えているところ。

それと雑でもいいので検索を設置したくてGoogle検索へのリンクを配置したがまだインデックスされていないから機能しない。時間が解決するのかなこれ。。


最後にOGPのテスト。先日[和処黒木](https://twitter.com/kurokijiro)に行った時に八木メシでお馴染みの八木栞FSKと撮った牛しぐれうどんでも載せておく。
![IMG_2962](https://user-images.githubusercontent.com/1421093/170851081-73034fa3-91c3-43be-94db-dcc08b642156.JPG)

ブログのカスタマイズ

## 経緯
昨日[GitHubに日記を書く運用](https://github.com/YuheiNakasaka/life/blob/main/_posts/20220527-tutorial.md)というやつを書いたんだけど、実際にやってみると色々と微妙に使い心地がよくなくてう〜〜〜んとなってしまった。

その旨をツイートしたところr7kamuraさんがGitHub issuesをエディタにしてブログを作れるクソ便利ツールを教えてくれた。

![https://user-images.githubusercontent.com/1421093/170819012-f920b5be-ec7b-4cfd-8bb4-ef4730de3754.png](https://user-images.githubusercontent.com/1421093/170819012-f920b5be-ec7b-4cfd-8bb4-ef4730de3754.png)

## gialogを使った日記の作り方
[r7kamura/gialog](https://github.com/r7kamura/gialog)のリポジトリのREADME.mdに書かれているリンクをポチっとやって、自分用のリポジトリを適当に作成する。するとGitHub Actionsが起動し、gh-pagesへNext.js製のSGGのブログサイトがデプロイされる。これだけ。

あとはissuesを更新することでActionsがその更新を検知して変更を反映してくれるという仕組みっぽい。

サイト自体は普通のNext.js製なのでテーマの概念とかはないけども、その辺は勉強がてらコードを拡張していけばいいんじゃないですかね〜という感じ。

最近のぴよぴよフロントエンドピーポーにとってはNext.jsが一昔前のRailsだろうから大体弄れるだろうし、ちょっとした現代のWordPress感あってよいなとも思った。