最近ほぼ毎日カレーを食ってるんだけど、今日はなんとなくの思い付きで火鍋をカレーにしたらめちゃくちゃ美味かったので忘れないようにレシピを書き記しておく。

# 材料(2人分)
## A) 火鍋
- 豆板醤: 大さじ1
- 花椒: 小さじ1
- 八角: ちょっと
- 鷹の爪: 1カケラ
- 桃屋のしびれと辛さががっつり効いた麻辣香油(もしない場合は普通の食べるラー油+ニンニクをガッツリ): 1/3瓶
- ウェイパー: 小さじ1
- 水: 300cc前後

## B) 具(何入れてもOK)
- とり肉: 適当
- にんじん: 適当
- 玉ねぎ: 適当
- じゃがいも: 適当

## C) カレー
- S&Bのカレーフレーク(固形でも多分OKだが安物はやめろ、最低限ジャワ): 大さじ2.5

## 作り方
### 鍋にA)火鍋を全部投入して中火にかけて煮立たせる(15分くらい)
ぐつぐつの方が火鍋感が出て良い。

### B)具を火が通るまで炒める
具は何を入れてもOK。にんじんが美味かったのでおすすめ。

### B)を火鍋に投入する
具が馴染むまで少しかき混ぜる

### C)カレー を鍋に投入する
カレーが全体に溶け切るまで混ぜる。もしとろみが足りなければルーを足す。とろみが多すぎたら水を足せ。

## 写真
![IMG_3277 2](https://user-images.githubusercontent.com/1421093/183254406-995b65fb-c721-40ba-9c85-1875b49997fb.JPG)
![IMG_3278](https://user-images.githubusercontent.com/1421093/183254480-e3a1a331-8210-4d2d-97d1-9f3459398007.JPG)
![IMG_3281](https://user-images.githubusercontent.com/1421093/183254425-1b6ba9f0-e277-4092-8a9e-a806b5e0d38e.JPG)

## 感想
基本はカレーだが遠くで中華の声が聞こえるような感じの味。花椒とニンニクとシビ辛が効いていて最高。火鍋自体で出汁みたいなものが効いているので全体として味の密度が異常。

[桃屋のしびれと辛さががっつり効いた麻辣香油](https://www.momoya.co.jp/shop/products/detail/115)がかなり重要なのでお近くのスーパーで買ってくれ。カレールーは固定のやつでも全然OKだがPBの安物はやめた方が良い。火鍋に味が負けるので。最低でもジャワあたりで。

全体的に結構辛めなのでお腹が弱い人は注意。

おすすめ。

火鍋カレー

※以下、エンジニア=ウェブアプリケーションエンジニアとして書いています

[エンジニアとして今の自分を形成した本を5冊紹介する](https://panda-program.com/posts/introduce-five-books)という記事を読み、自分だったらどの本を選ぶかなと考えてみた。

この記事を読んでみた感じ、名著が多いな〜という印象を受けた。対象読者に関しては、

> 独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人

と著者も書いている通りちょっと実務経験のある人になっているので確かにそういう人達には丁度良さそうだなと思う。

自分もこのブログの著者が書いているようないわゆる名著の部類に入る本をそういう時期にいくつか読んではいるが、それらはタメになった本ではあるものの"今の自分を形成した"とまではいえないよなーと思う。

本というのは読むタイミングが大切だ。プログラミングを始めたての頃にClean Architectureを読んだ時の感想(ふーんとしかならなかった)と負債に塗れたプロジェクトをくぐり抜けた後に読んだClean Architectureへの感想では全く異なるはずである。

またいくら名著といっても時間と共に古くなってしまう考えや方法が出てきてしまう。技術書であればなおさらだ。よくこういう記事で挙げられる「UNIXという考え方」もその一つで、[名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた](https://qiita.com/ko1nksm/items/f1800c6ff6dd649d7429)という記事ではこの本の今では古臭くなってしまっている箇所などを丁寧に検証してくれている。

古くなってしまったからもうその本は読む必要がない、というわけではないからこそ名著であるというのもまた事実である。現代に至るまでの歴史の中で今を振り返るために、また未来を見据えるために重要なヒントをくれたりする。

では"自分を形成した"本とはどういう本なのか、それはこの道へのめり込むきっかけや感動を得た本ではないかなと思う。

それが結果的に名著と呼ばれる本であることも多いが自分にとってはどちらかというとスキルが圧倒的に未熟な頃に読んだ本、いわゆる入門書のようなものがそれにあたるのではないかと考えた。今風にいうと"駆け出しエンジニア"のようなスキルレベルの頃に読んだ本である。

未熟な頃に感動した思い出があるからこそ今もエンジニアとして仕事を続けられていると思う。なのでそういう思い出が詰まった本、思い出補正全開本を"自分を形成した本"として5冊選んでみた。思い出補正全開ゆえ今回選んだ本は決して全てがおすすめできるわけではないので悪しからず。

# [初めてのRuby](https://www.oreilly.co.jp/books/9784873113678/) 
Ruby1.8と1.9に対応している。現在3.1とかを使っていることを考えると感慨深い...。この本を読んだのは大学卒業~新卒入社した位のタイミングだ。当時の会社ではPHPでウェブアプリケーションを(なんとなく)書いていた。しかし世間はどこもかしこもRuby on Railsを使っておりミーハー心からRubyについて学ばねばな〜などと思い手に取った本だ。

完全な初学者が手を出すとわからないかもと思えるような一見無味乾燥な本ではあるけど解説がとても丁寧なので当時の自分くらいのレベルでも理解できた。この本を読み切れたことで技術書を読むことのハードルが下がった。またRubyという言語の面白さとかスピリットみたいなものが垣間見えた気がしている。と同時に各種一般的なプログラミングに関する用語についての理解も深まったのでPHPを書く時やドキュメントを読む時の理解力も上がったという副次効果もあった気がする。

対応Rubyバージョンを見て貰えば分かるとおり今読むべき本ではないとは思うけどあのぐいぐいと引き込まれる体験は確実に今の自分を形成するスタート地点になっていると思う。

# [Rails3レシピブック](https://www.sbcr.jp/product/4797363821/)
Railsといえば[Ruby on Railsチュートリアル](https://railstutorial.jp/)である。ウェブアプリケーション開発者においては言わずと知れた当時の神サイトだ。当時はまだ全て無料で閲覧できたのでその点もありがたかった。

このサイトでTwitterもどきを作ったり、このRails3レシピブックと睨めっこしながら粛々と自分の考える最強のwebサービスを開発するみたいなことを毎日やっていた。その開発体験から派生してすぐあとに起業することになるわけであるが、その時も開発時にいつも横にはRails3レシピブックがあった。

これまた対応Railsバージョンを見て貰えば分かるとおり今読むべき本ではないものの、当時の自分にwebサービス開発の楽しさを教えてくれた気がするので個人的に思い出深い本であることは確かである。

# [リファクタリング: Rubyエディション](https://www.amazon.co.jp/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0-Ruby%E3%82%A8%E3%83%87%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3-Jay-Fields/dp/4048678841)
起業してから一人で我流でwebサービス開発を続けていく中でコードが肥大化していきどうしたもんかね...となってしまう時期がきた。恥ずかしながらこの頃は**Done is better than perfect**よろしく、動けば良い、さっさとリリースじゃ!とガンガン積み木を重ねていくようにコーディングをしていた。実際自分以外に誰もコードを触らないわけなのでなんとかなっていたわけであるが、それなりにコードが大きくなると自分一人でもこれは不味いなと感じるようなコードが増えてきた。その時に手に取ったのがリファクタリング: Rubyエディションである。

この本は[リファクタリング 既存のコードを安全に改善する](https://amzn.to/3b3ACYK)というオリジナルのRuby版である。元の本の方はJavaで書かれているのだが、PHPとかJavascriptとか当時のweb開発の言語しか触っていなかった自分に敷居が高く感じられた。一方Ruby版の方はすでに慣れ親しんだ言語で書かれているということで臆せず読み始められた。

デザインパターンやOOPなどの実装テクニックについて見聞きしたことはあっても実際にどう使えばいいのかというのがいまいち理解できずにいたが、これを読んで腑に落ちた。実際のコードベースに取り入れやすいという環境やタイミングがぴったり合ったというのも大きいがそれにしても学んだ概念がすぐに実践で活用できたというのは気持ちよかった。

# [コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方](https://amzn.to/3J5EuFa)
ある程度webサービスなどが作れるようになるともっとコンピュータの仕組みとか低レイヤーについても知りたくなった。こういうことは本来大学でCSを学んできている人には素地としてあるのかもしれないが自分には全くその手の知識がなかった。

巷でおすすめされている本やいわゆる名著というものを手に取って読んだりはしてみたが難しいしピンとこないものが多かった。元来頭が良くなくて抽象化能力とか理解力が低いという自覚はあったので理論が延々と続くようなちゃんとした教科書が得意ではないのである。

そんな時に手に取ったのが[コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方](https://amzn.to/3J5EuFa)だ。これはNANDという電子素子から始まり、CPU、OS、コンパイル、VMと実装していき最終的にはNAND Tetrisと呼ばれるゲームまで作ろうという本。作ると言っても物理的に回路を構築したりするわけではなくHDLや好きな言語(自分はPython)でコードを書いて組み上げていくという流れになる。とはいえ本格的に論理回路から順に組み上げて一応は一通りのコンピュータがどうやって動いているのかを手を動かしながら知れるのでコンピュータへの解像度が爆上がりして感動した。

OSとか言語を作る部分は流石に全然物足りないのだけど低レイヤーを理解するための足がかりにはなるはず。この本はすでに名著の部類に入ってるし今でも十分おすすめできる。[From Nand To Tetris](https://www.nand2tetris.org/)や巷にすでに実装を行なっている人たちのコードがGitHubやQiitaやZennにたくさんあるのでそれらを参照しながら挑戦すると良いと思う。

# [Writing An Interpreter In Go](https://amzn.to/3PCmynY)
上記の本を読み始めたのと同じ理由でこの本を読んだ。タイトルの通りGolangでインタプリタを書く本である。プログラミング言語を作ってみるというのは誰もがやってみたいことの一つではあると思うが、いきなりドラゴンブックを読めるわけはないのでどうしたもんかと思っているような人に丁度良い本。

これまた解説メインではなくLexer・Parser・Evaluatorを実際に手を動かしながら順を追って解説してくれるのが嬉しい。プログラミング言語を作るっていうのはこういうことなのかと膝を叩く経験ができる。

今だと日本語版で[Go言語でつくるインタプリタ](https://amzn.to/3PZvOmd)という本になっているので手に取りやすそう。同じ著者がこの本の[コンパイラ版](https://amzn.to/3POSB3K)も出しているのでそちらも読むとさらに理解が深まると思われる。

よく考えると最初から最後までしっかりと読み込んだ洋書はこれが初めてだったかもしれない。そういう意味でも自分の身になった良い本だったなと思う。

# 最後に
[エンジニアとして今の自分を形成した本を5冊紹介する](https://panda-program.com/posts/introduce-five-books)という記事を読み、自分にとっての5冊を選んで書いてみた。

今の自分を形成した本というのは必ずしも万人にとって有益な本ではないかもしれないが、その人の人生を垣間見ることができるという意味で酒のつまみにはなるようなネタだなと思った。他の人(もっと自分より年季の入った人)の経験も読みたい。

わからない概念だったものが腑に落ちて一段解像度が上がる体験をすると感動してしまうタイプの人間なので分からないことだらけのエンジニア初期の頃に読んだ本の方が贔屓目で見てしまう。新卒の彼らに技術書をお薦めする時は慎重を期して選出するのだけどある意味おじさんの自分語りのようなレベルならばこういう少し偏った選び方もありだと思う。

そういえばこれを書くために今までどんな本を読んできたかなと振り返ってみたが、圧倒的にインターネット上の記事やドキュメントなどのコンテンツを読んでいる方が多いと思った。

今は当時にも増してweb上のコンテンツがテキスト・動画問わず溢れているので「おすすめの本」というのを挙げることにそんなに意味はなくなっていくのかもしれない。とはいえ媒体が変わっても初心者が成長していく過程でブレークスルーのきっかけとなった思い出の"何か"はあるわけでそれを共有して感慨に浸っているのをみるのはまぁまぁ面白いと思う。

最後に自分がプログラミングで万能感を得た最古の原体験として、このゆーすけベーさんのブログ記事が出発点だったなと思い出したので貼っておく。一人部屋にこもってこの記事を読みながらクローラを書いていた、フォルダに溜まっていく大量の画像を見つめながら万能感に浸っていたのがめちゃくちゃ懐かしい...

- [Rubyやってみる！（新おっぱいスクリプトもあるぉ）](https://yusukebe.com/posts/2012/0520074309/)

エンジニアとして今の自分を形成した本

4月頃に痔が酷くなり座るのが嫌になってしまった。座りたくないのであれば立って仕事をするしかないが、スタンディングデスクをいきなり買っても使わなくなるんじゃないのか？という不安もありまずは手近でスタンディングデスクっぽいものをこしらえて試してみることにした。

# 最初の1~2週間
めちゃくちゃ足が痛くなる。そりゃ毎日8時間くらいほぼ立ち続けているから当然だ。足の裏、股関節、ふくらはぎなどへの疲れがすごい。風呂に浸かってマッサージをしてた。

作業はというと割と普通にできる。腰が痛くなったり首が痛くなったりということはない。長時間座っていると腰が痛くなることがあったがそれがなくなったのは少し良かったかなと感じた程度。

会議が無駄に長くなったりするとキレそうになる。さっさと要点まとめて終われボケ...と強く思うようになる。

# 1ヶ月ほど経過
立ち続けることがそれほど気にならなくなる。2時間くらいは平気で立ったままでいられる感じ。とはいえ一日の仕事が終わると座って仕事をしている時よりも全身の疲労感は多め。

スタンディング力が高まったおかげでダラダラ続く会議への苛立ちが少し減った。さっさと終われとは思うけど...。

夏が近づくとPCからの熱と部屋全体の熱気が顔の辺りを覆う。座っている時よりも汗をかきやすくなる。30℃を超えると流石に冷房がないとキツくなった。

# 2ヶ月経過
特に普段と変わりなくスタンディングワークをしていることに特別感すら感じなくなる。

そういえばこの頃から電車で立っていることが苦ではなくなっていた。コロナ関係なく外出時はあまり人と接触したくなくて立ってることもまぁまぁ多めだったので疲れにくくなったのはありがたい。

# 2ヶ月半頃
この頃からか、足の裏の特に踵や母指球辺りが硬くなってきて時折結構な痛みが出るようになった。当時はスリッパを履いてフローリングの上に立っていたわけだが、おそらく足の裏の出っぱっている部分に力がかかりやすくなっていてタコのようなものができる寸前になっていたのだと思う。

1時間立って作業をして5分座って休み、また1時間立つみたいなインターバルをちゃんと入れるようになった。今までは疲れたら座って休憩みたいな感じだったけど疲れてなくても休憩を入れるようにした。

まぁそれでも痛みはちょくちょくやってきたりするもので途方に暮れていた。

<img width="591" alt="スクリーンショット 2022-07-25 21 04 21" src="https://user-images.githubusercontent.com/1421093/180773703-76e6eda7-e959-4104-8194-76c00a9de302.png">

# 現在
ついに足の裏の痛み問題を解決する術を発見した。地面をふにゃふにゃにするのである。

今まではスリッパを履いていたとはいえ、足場は平面で硬かった。故に足の裏への負担が偏ってしまっていた。その足場に別の部屋で浸かっていたロングな座椅子を置きその上に立って作業をするようにしてみた。すると1日中立っていても全然痛くなくなったのだ....。

さらにしゃがめばすぐ足元は座椅子なのですぐにリラックスタイムに入れる。立って良し、座って良しのロング座椅子便利すぎる。

それに合わせて足元に小さめのちゃぶ台を置いたり座椅子にクッションを追加したりしてようやく文句ないスタンディングワーク環境ができた。

# 作業環境全体像
現在の作業環境の全体像はこんな感じ(後ろの椅子はほぼ使っていない)
![IMG_3244](https://user-images.githubusercontent.com/1421093/180774838-28eb541b-9d6b-4b9b-8998-92d54f935d7a.JPG)

スタンディングデスクを購入すると結構高い(まともなやつだと5万くらいする)し合わなかったらマジで邪魔な机なので、家に最初からあったちゃぶ台とかテーブルを重ねたり魔改造してそれっぽい机にしている。

普通こういう作業環境を公開するエンジニアのブログなどでは配線周りやキーボード、ディスプレイ、椅子などもこだわりぬいて綺麗な写真を載せているのだけども、自分はそういう細部へのデザインセンスがなく美的感覚が終わっているためこんな有様になっている。

ニトリとか激安通販とかで買った家に元々あったものばかりなので、新たに費やした費用は0円。もしスタンディングワークをやめるとしても臆することなく辞められるのが利点。

そもそも論として痔を治せばこんながんばらんでも良いのでは？みたいな話もあるが、まだ手術するほどではない(と病院で言われた)のと手術後は出産後よりキツかったと知り合いの妊婦さんが言っていたのを聞いて恐れ慄いており、対処療法でギリギリまで頑張って悪化させないぞ!!!と決意したという経緯があります。。。

(ジオン注射なら日帰りで痛みもそんなにないとか色々言われてはおりますが中々踏み出せないものです...)

スタンディングワークを3ヶ月ほど続けた感想

- Web3とは何であったか
  - トークンとコントラクトと誰からでも見える台帳を使ってなんか出来そうなことないっすかねくらいの思想または活動
    - 自動販売機で金入れたら人を解さずにジュースが買えるような感じで、トークンを支払ったら人を解さずにトークンが買えたり付与したりできる仕組みを作れるスマートコントラクトというのがあり、これなんかに応用できないっすかみたいなことだけだったはず
    - NFTとかDAOとかもその応用例の一つなだけにすぎない
  - トラストレスとか分散性みたいな話はEthereumのDocsには一部記述があるがあくまで理想論として語ってるだけ。会社がvisionをHPに書いてるようなもん。
  - Internetの技術が置き換わるとかBigTechを打倒するみたいな対立構造を煽るような話では全く無い
    - そもそも既存のインターネットの上に成り立っているし、分散されたそのノードはどこのサーバーで動いているんだという話がある。お前は自宅サーバの独自のノードを稼働させてるのか？(私はブレーカーが落ちてPCが終わったりした経験がある)
      - まぁPoSになると必要なマシンパワーがかなり少なくなり最低32ETHあれば参加しやすくなるはずなのでやってみてほしい
  - Web3という何かに技術的な新しさは無い
    - あるのはWeb3論者が語る理想の世界が"今とは違う"ということだけ(良し悪しや実現可能性は問わず)
  - ブロックチェーンにしてもソフトウェア的には既存の技術を組み合わせた仕組みだしそれ自体でブレークスルーとなるかは自分にはわからない。これだけ世界中の人々を巻き込んだムーブメントを起こす基盤になっているというのは面白いけど。
  - ZKPとかは真新しいかもしれないけどクリプト固有の範疇では
- Web3という言葉は死んだ
  - 現状はバカを丸め込むためのバズワードと化した
  - 機械学習やDL界隈が盛り上がってきた時にAIという言葉が流行ったのと同じ感じ
  - 概念をまとめて名前をつけるとマーケティングが捗る
    - バカでも難しい概念を使えるようになる
      - バカでも自分の会話に取り入れられるようになる
        - この時自らは何も概念を理解できてなくても問題ない。複雑な理解の部分は相手側に委ねられるので。
          - 「Web3でやっていきましょう!」「(Web3でやっていくとは...)」
  - とはいえある現象への名づけ行為自体は概念の普及やコミュニティの拡大には役に立つので一概に悪いことではない
    - ブラック企業/毒親/非モテ/LGBTなどは複雑な現象や概念に対して言葉が定義されてバズワード化して広く普及した。良し悪しは知らんけど。
- 危険な一発逆転思想
  - 政府のWeb3政策みたいなやつ。Web2.0までは世界に遅れを取ったという敗者根性に起因してると思う。
  - Web3という概念は「ゼロからのスタートだし世界に勝てるかも」という一発逆転願望を良い具合に刺激してくれる
    - 巷のエセサロンがうまくいかない人間に対してささやく甘い言葉と同じ
      - 「未経験でも高収入」みたいなやつ
  - これは完全に自分の考えで余談だけどそもそもIT戦略に関する政府の失敗はなんだったか考えてみると、天才育成の失敗だと思う。ITの世界(というか高度に発展してきた科学が主流の時代)は1万人の凡人より1人の天才(及びそれに次ぐ数人の優秀)な頭脳によって大きく発展する傾向がある。それにもかかわらず自由と多様性の確保や研究開発への資金援助を怠り、規制及び選択と集中に舵を切ったのが間違ってたのではと思う。
- 市場と信仰
  - DEXの台頭で一定の流動性が確保されてトラストレスにトークンを売買したりできる経済っぽいものが立ち上がったのは確か
  - しかし大体において暗号通貨市場は信仰によって成り立っている印象
    - S&P500のインデックス投資ですらある意味米国経済への信仰の元に成り立っているわけではあるが、 暗号通貨市場のそれは全くその比ではない(歴史も根拠もなすぎるし既存の金融市場のおこぼれを貰ってるだけでは...)
  - 投資(投機)は自己責任の範囲でやるべきというのは当然だけど、他人へ暗号通貨の保有を勧めたりする行為はカルト宗教の勧誘と同じ(根拠なく理想を語り、甘い言葉で自己の利益を目論む行為という点で)
- 自分のポジション
  - 一言で言うとdapps作るのが楽しい、以上。くらいな感じ。現状ほぼ金になってないから盆栽いじりと同等。
    - 情報を追い始めたのは去年の夏くらいからなので割と最近。仕事上必要で情報をキャッチアップし始めた感じ。最初はEthereumから見ていった。
    - コントラクトを書いてブロックチェーンにデプロイ(有料)しておくと、適当なAPIが生えて、なんか激烈にreadのAPIリクエストしてもちょっとやそっとでは落ちない(writeに関しては同時処理できるtransactionが少ないのでそもそも激烈にリクエストできないが)使い方によっては便利じゃんとか、ウォレットをネットワーク全体通じたID代わりにできればユーザー認証周りはサービスごとに特別に作らずとも良くなり、フロントエンドだけ書けばよくてラクできそうみたいな感じで色々遊んでた感じ
      - まぁ現実はそううまくいきませんが(オフチェーンとオンチェーン間のシャトルランで死にそうになりながら...)
  - それぞれ好き勝手に好きなネットワークにコミットして俺だけの最強のWeb3をやれば良いとは思ってるけど、既存の技術や先人の肩に乗って生きているくせに彼らに敬意無く、己の利益のためだけに都合のいい嘘をついたり、対立構造を煽ったりして、大衆を分断させる卑劣な行為や言説は糾弾したい
  - 粛々と研究開発している人はたくさんいるのでそういう人達だけ相手にしていきたい


最近のWeb3への雑感

最近は複数のフォーム入力項目があるページをお仕事で作ったりしてる。その中でUIを作ってる時に動作確認をするんだけど数十項目の入力フォームをいちいちゼロから埋めてsubmitして...みたいなことをするのが結構だるい。この作業を良い感じに手助けしてくれるChrome Extensionを作った(というか作っているところ)。

- [YuheiNakasaka/FormFill](https://github.com/YuheiNakasaka/form-fill)

↓下記がデモとしてGoogle Formを埋めている例。Google Formは結構特殊でinput要素を全然使わずdivをボタンやチェックボックスにしているので一発入力できずに厳しいのだが90%くらいの要素は一気に埋められる。

https://user-images.githubusercontent.com/1421093/179355981-2729be7c-7552-4217-a9a2-1dc809997dc2.mp4

今回欲しかった機能としては、

- 任意のフォームのセレクタとvalueを指定して一発でフォームを埋めてくれる
- 入力パターンのセット(住所が東京の場合とか電話番号が070から始まる場合のパターンなど)をいくつも作成できる
- 入力パターンセットを好きに組み合わせて選択してフォームを埋めてくれる

逆に不要なものは、

- リッチなGUI

という感じ。

なので今回は入力パターンセットをまとめたJSONを指定して、それに則ってフォームを埋めてくれるようにした。開発者とか向けのデバッグでしか使わんだろうと思うしGUIは設けていない。

JSON一つあれば良いことのメリットとしては、チーム内で入力項目をまとめたJSONを作りgit管理とかしておけること。テキストファイル一つにまとめられるので共有が楽なのは良い。まぁJSONを作るのがだるいのだけども...

Chrome Extensionを作り始める際のボイラープレートとしては[chibat/chrome-extension-typescript-starter](https://github.com/chibat/chrome-extension-typescript-starter)を使った。

過去にいくつか作ったことはあったので基本的な開発の流れは覚えていたが細かい部分を忘れていたので[API Docs](https://developer.chrome.com/docs/extensions/reference/)と睨めっこしたりした。

ChromeでしかもPCでしか動かさなくて良いから考えるべき動作環境が限定的でその辺りは楽。

あとストアへのリリースはまだしてない。一旦は雑な作りだし、リポジトリとして公開しておけばそれをビルドして自前の環境で使うこともできるので後回しにしている。開発者向けなのでなおさら。

ちなみにこのExtensionはよくある住所などの自動入力のためのExtension([AutoFill](https://chrome.google.com/webstore/detail/autofill/nlmmgnhgdeffjkdckmikfpnddkbbfkkk?gl=JP&hl=ja)みたいなやつ)ではない。

あくまで複数の入力パターンを何度も実行するようなケースでしか嬉しくない。その辺りは理解しておいてほしい。

開発時のフォーム入力を少し楽にするためのChrome Extensionを作った

[目の見えない人は世界をどう見ているのか](https://amzn.to/3P9Tl3g)という本を読んだ。その中に目の見える人と目の見えない人が美術館で一緒に作品を鑑賞するソーシャルビューという試みが書いてあった。

ソーシャルビューではまず見える人が作品について語る。その際に重視するのは作品の形や客観的な情報ではなく本人の主観的な感想だ。それを聞いた目の見えない人たちはどう言った作品なのか想像しながら質問したり感想を述べたりする。このインタラクティブなやり取りの中で互いに作品の意図や意味を感じ楽しむ。このような美術鑑賞の試みがソーシャルビューである。

> 情報化の時代にわざわざ集まってみんなで鑑賞する面白さは、見えないもの、つまり「意味」の部分を共有すること

作品そのものを見るだけで得られるものはただのデータである。そのデータを受けた鑑賞者がそこにどのような意味を見出すのか。その共有を通じて目の見えない人は作品を脳内で立体的に補完し、さらにその補完した作品を受けてそこに自らの意味を見出していく。こういう営みだ。

> 作品を鑑賞するとは自分で作品を作り直すこと

「鑑賞する = 自分で作り直す」という文章に感銘を受けた。

というのも自分は鑑賞が苦手だからだ。映画やアニメや漫画などあらゆる物語に対してそのストーリーを追うことしかできない。キャラクターに感情移入することもないしストーリーの不自然さに苛立つこともない。だから深読みとか考察みたいなものもできない。登場人物のパラメータの暗記と筋書きを追うことで満足してしまう。

いわば"物語"という食べ物を食べても消化されずに排泄されてしまう感覚に近い。胃で消化されず腸で吸収されず体の一部になるような、そういう摂取の仕方が"鑑賞"なのだと思うのだけど、自分の場合は舌で感じた味くらいしか摂取できないわけだ。

大味なバトル漫画を読んだりするときは心臓がバクバクすることもある。スナック菓子を食べているような感覚。刺激の強い味はどんどん食べたくなるしよく噛まずに早食いになる。物語を異常な速度で雑に食ってると変なアドレナリンが出ちゃうのだと思う。

これは老化とか体調が悪いからとかそういうのは関係なくて昔からこんな感じである。むしろそういう自分に自覚的になってきた分まだマシだ。

鑑賞することは自分で作り直すということであるならば、自分は全く鑑賞が出来ていない。勿体無いなと思う。クリティカルシンキングだとか共感性の問題だとか、色々と理由はあるのかもしれないが浅い人間だな〜と感じてしまう。

そういえばオードリーのオールナイトニッポンで春日が何十年もジャンプを読み続けているがどの作品も誰々が強いとか弱いみたいな話だけで自分と作品との関係から出てくる感想とか考察みたいなものが一切なくて若林にdisられてたのを聞いてめちゃくちゃ共感と安心感を覚えた。俺だ〜〜〜となった。

鑑賞が出来ない

6/29、モーニング娘。とJuice=Juiceの新メンバーが[ハロプロ公式Youtubeチャンネル](https://www.youtube.com/watch?v=OIjk6pzQl30)にて発表された。

娘。には一般オーデから1人、Juiceには一般オーデから1人+研修生から1人という結果である。
[http://www.helloproject.com/news/14778/](http://www.helloproject.com/news/14778/)

雑感としては、

- 研修生から石山咲良が昇格してくれて最高
- 研修生からの昇格人数少なすぎ！？

という感じ。

石山咲良に関しては年齢的にも辞めるか否かの瀬戸際だったと思うのでここで選ばれなければもうあとはないかもしれないと誰もが思っていたと思う。なので彼女の昇格に関しては誰もがおめでとうという気持ちなはず。しかも本人がずっと好きだったグループへ加入できることになったわけなのでオタクだけでなく本人の希望も叶った形で全方位丸く収まっている感じがした。

問題はもう一つの方で、研修生からの昇格人数少なくない？というやつ。
特に今年は研修生の実力診断テストで念願のBPを獲った古株の松原&小野田ペアの昇格を心待ちにしていたオタクも少なくなかったはず。というか自分もこの2人+一般1人の計3人が娘。入りかな〜などと考えてたところもあるので今回の新メンバー発表には驚かされた。松原オタとまーオタを兼ねていた人はまーちゃんのエメグリを受け継いでくれることを確信していたんじゃないかなと思うし、ショックだっただろうと思う。

さらに追い討ちをかけたのはその後に発表されハロプロ研修生ユニットである。研修生の歴の順に上から5名が選ばれてハロプロ研修生ユニットとして活動すると発表されたのだが、これがあからさまな塩漬け感を感じさせる人選であるし活動も何をどのくらいやるのか未定なため当該メンバーのオタクは激しく落胆した。発表直後は界隈のTwitter/Space/Youtubeが研修生オタクの悲しみと怒りの声で溢れていた。

色々な話はあると思うがどうしてこういう人選になったのか少し考えてみたが、個人的にはやはり事務所の経営的にメンバーを増やす余力があまり無いのではないか？という説が濃厚なのではと思った。

OCHA NORMAのデビューもあるしハロプロだけですでに70人近いメンバーを抱えているから人件費だけでも数千万/月と固定費が膨らんでいるはず。しかしここ数年はコロナで興行は思うようにできないので経営的にまだ厳しい。が、研修生はたくさんいるし、せっかくここまで育ててきたのに辞めさせたくはない。となると取れる選択肢としては経営を圧迫しないギリギリの枠を用意して、そこに1番やめる確率の高いメンバーだけを昇格させようとなるはず。

それが石山咲良だけだったのではないか。今年BPを獲った2人は歴は長いがなんだかんだでまだ若い。石山と比べた時にギリまだ研修活動の継続ができる余力がある。

そう考えると割と今回の人選は理解できる。何より昨今の事務所は頑張ってきた研修生を辞めさせたくないのだ、ここが大事だ。だから石山昇格を急いだし、残りの研修生のための引き留め措置としてのグループを作ったのだと思う。

という感じで厳しい経営状況と研修生への親心みたいなものが生んだのが今回の人選と新体制の発表だったのではないか。

まぁ塩漬けされた側のオタク各位は放心状態だと思うし同情するが、研修生グループもまた新グルとしてデビューさせるようなOCHA NORMAパターンと決まったわけではないし、今年末~来年にかけてまた卒業するメンバーも出てきそうな雰囲気もなんとなく感じるのでそこで空いた穴を埋めるためにあっさりデビューみたいなこともあるかもしれない。

その辺りは全くわからんのだけど、今回の件で事務所も昔のように鬼ではないのかもなと思ったので、何かしらの形で彼女たちが報われるようにしてくれるんじゃないかなと淡い期待をしておく。

ハロプロ新メンバー発表に対する雑感

[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感あってよいなとも思った。