hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

物持ちよくしたい

服を長く着たいと思って、今日着てるスウェットは数ヶ月前に買ったものだけど、きのう着ていたフリースは4年くらい前にもらったものだし、その前に着ていた花柄のシャツは8年前くらいに買ったもので、長持ちしていると思う。
服を長く着ようとすると体型を維持するのが重要で、痩せてだるだるになってたらみっともないし、ぱつぱつになって着れなくなるのは情けない。
あとは、じっくり考えて、気に入った上で買うのが大事で、まあこれくらいで、みたいに決めるとやっぱり着なかったりする。
こんなにかわいい花柄のシャツがこの世にあるのか、と思いながら買うのが大事。
こうやって注力して選んでいると、服をプレゼントでもらうハードルが上がっていく。
妻から誕生日プレゼントでも買ってもらおうとなったら難しい選択を強いられることになるので、一緒にでかけて、これがいいって一緒に選んだりしている。
昨年末は部屋着を買ってもらったけど百貨店を巡ったりして選ぶのに苦労した。

服は好きだけど雑貨や日用品なんかはわけわからなくて、無印良品のみを選択肢として暮らしているので、ウェッジウッドのマグカップを買ってもらったら大満足だった。マグカップ毎日使っていて、そのたびに、これは最高のマグカップだ!!と思っている。

f:id:hitode909:20210218225754j:plain
マグカップ


何が言いたいのかと言うと、お金を払うときの納得度をどれくらいにしたいかという話で、気に入ってる分野なら気に入り度90%くらいのものだけに支払いをしたいけど、分野への関心が少ない部分なら10%くらいでも支払いができる、ということ。そして、気に入り分野が高いところは、気に入ったものを長く使いたい。
スティック型掃除機にはまったく関心がないので、ツインバードの2000円くらいのを買って、それでベランダとかを雑に吸っている。
掃除機が好きな人からすると許されない蛮行だと思うけど、吸えればいいし、壊れたら2000円で買えばいいという期待感なので、地球上どこでも適当に吸っている。

1画面1APIと比べるとGraphQLのAPIはどこから作ったらいいか分かりにくい

Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。

グラフをたどって開発することになる

GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。
このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。
スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係が一見するとわかりにくい。
グラフの探索というと、さまざまなアルゴリズムがあるけど、グラフをどう実装していくか、という作戦も、幅優先でトップレベルから使いたいものを順に作ることもできるし、深さ優先で1パーツずつ着実に作ることもできるし、確実に使いそうなResolverやDataLoaderからボトムアップに作っていくこともできる。

衝突回避

開発を進めていくときも、この情報はこっちのオブジェクトのこれ、みたいに、いきなり別の画面用に開発する予定だったフィールドにたどり着いてしまったりする。
複数人で分担して作業しているときに、二人で同時に触ってしまうと、同じものを2回作ってしまうことになったり、お互いが回避すると気づくと実装されてない、みたいなことが起き得る。
ぜんぜん違うところを触るなら大丈夫そうだけど、1画面のうち2コーナーなどを同時に作っていると、作業場の依存関係が発生することがたびたびありそうな印象だった。

落ち着いて開発できるならボトムアップにするのがよさそう

餅つきやわんこそば的にViewもどんどん作って結合していきたい、みたいな事情がなくて、落ち着いて開発できるなら、ボトムアップに、ドメインモデルまわりから定義していくと、出たとこ勝負でtypeをどんどん追加するような混乱を回避できるとと思う。
Atomic Designとかをイメージすると、Atomsから順に作っていくはずで、Pagesから考えて必要に応じてAtomsをどんどん足していくと統一感を得にくいと思う。

スキーマのレビューを通しておく

あと一つ思い出したので書いておくと、実装までやらずに、スキーマ段階でレビューを通すのがおすすめ。
スキーマを読み書きするだけなら、他メンバーと合意する手段としては手軽で、実装まで済んだあとにスキーマからやり直しになるよりは、早い段階でコストを小さく試行錯誤できるほうがよい。
クライアントサイドが別チームになっているときには、ユースケースを満たせるか確認できるし、スキーマさえあれば、Apollo Serverなどから読むことでモックサーバーを動かすとか、作業を進めることができる。

これまでのあらすじ

先日はクライアント、サーバー間の分担について気にしていた。
blog.sushi.money

卵かけご飯

ご飯の用意する時間がなくてもなんとかなるもの、として、卵かけご飯がある。
炊飯器に米を炊いて保温していることと、卵が備蓄されていることが前提。
昨日は明太子と高菜があったので助かった。けどこれを常備しても、そんなに毎日明太子食べたいわけではなさそう。
キッチンで立って食べられる、とか、ダイニングテーブルに運ぶ間に歩きながら食べ終わることができるのも良い。ダイニングテーブルに辿り着く前にすべての食事が完了すれば、ダイニングテーブルが不要になる。
課題としては、栄養バランスが偏っていると思うので、野菜も取れるようにするとか、乗っけるものを工夫していって完全食にしたい。

英文

びっしり英文の書いた製品をたまに見る。こないだは、テレビスタンドにもびっしり英文が書かれているのを発見してびっくりした。
いったい何のために…と思っていたけど、昨日気づいたのは、眠れないときに英文を読むと入眠しやすくて便利そう、ということ。
読めない本を買わなくても、英文のびっしり書かれたテレビスタンドを買っておくことで安眠が約束される。

最近寝る前に読んでるのはこれ。

21 Lessons for the 21st Century

21 Lessons for the 21st Century

だらだら読んでいたけど日本語訳も普通に出ていた。悲しいことです。

チャリで中古車ディーラーを巡って様子を見てきたところ、相場観が分かってきた。10日くらいで納車できることもわかった。
印鑑登録、車庫証明、とかこまごま面倒そうな手続きがあることがわかって、面倒さゆえに興味が失われてきた。そして、面倒な手続きの代行をお願いすると2万5000円くらい。
36万円のフィットとか27万円のデミオとか見てるときに2.5万円の手続きと聞くとものすごく高く感じる。誤って始めたプロモーションツイート費用4万円があれば…とか考えてしまう。