眠い。
Orvalのfetch API対応はやはり壊れているように思う。ヘッダーを外から渡せるようになっていない（渡せるように見えるがContent-Typeヘッダを内部で渡しているのがちゃんとマージされていないので消えてしまう）。修正のPRを出した方がいいのか？簡単にできるのかはわからないけども。
OpenAPI GeneratorもOrvalも微妙で、困るなと思う。いや、OpenAPIのほうが少しマシなのか？でもこっちはこっちでsingle-fetchと相性がよくないので悩ましい。どいつもこいつもな！ハーッ！
それはさておきCookie認証はなんとかできつつある。妥協の産物だが、妥協点を決められたのは良かった。結局こういうのを一度やっておく筋トレが、限られた時間の中で設計と実装をやっていかなければならない時のために必要なんだなと思う。
寝ます。
平日に休みをとっても結局仕事のことが気になってあまり気が休まらないんだよな。そうでもないか。
休みだけど特にたいしたことはしていない。「地面師たち」見始めた。面白い。
ログイン盆栽は今日は手をつけていない。結局Remixでやる限りは何らかのバケツリレーを許容するしかなさそうだ。一旦はそれで進めることにして、あとで何かうまい抽象化ができないか考えよう。うーむ。
そうと決まればつぎはフロントエンドに注力か。
寝ます。仕事か〜。
ログイン盆栽をずっとしている。なんかまあバックエンドは結論出つつあるのだけど、Remix側が難しい。結局Cookieを食わせて回らなきゃいけないし、バックエンドから送られてきたらセッションに入れなきゃいけないが、そのあたりの共通化がうまくできそうもない。なんかラッパー書けばいけるのか？
寝ます。明日は夏期休暇でおやすみ。
ログインをやろうと思っていろいろ試行錯誤している。Google Sign Inに対応するボタンを置くのは問題なくできたが、結局どのようにログインセッションを持つのか悩ましい。今のところはバックエンドがセッションクッキーを発行するのをそのまま使えばいいかなと思うけど、それだとCookieの内容にはフロントエンドはアクセスできないから、ログイン状態確認エンドポイントを作る必要がある？いや、それもよくわかってないな。結局RemixはCookieをどう扱うんだ？調べなくては。
「誰が勇者を殺したか」読んだ。素直。結末でもう一回くらいひっくり返ると良かったと思う。続編がちょうど出たところだったので買った。
寝ます。
ずっと盆栽。utoipaもなかなか癖があるなと思いつつ、とりあえずはいったんこれでいいか、というスタイルに落ち着いた。ただ、これくらい自動でやってくれないのか？と思う部分はあり、まあそれはもう自分でマクロを書いた方がいい領域の話なのかもしれないと思った。
一方で、OpenAPI generatorのテンプレートは少しならカスタマイズが利くという話もあり、そっちを模索するほうが結局は正気なのかもしれないと迷う。ついでに言えばOrvalもイマイチ使い勝手が良くない。悩みが多い。
もっとも、こんなのは完全に盆栽要素なので、今はほどほどにして実装を進めたい。今度こそログインをやる。
寝るよ。
盆栽に明け暮れている。バックエンドがutoipaでスキーマを生成し、フロントエンドはorvalでクライアントを生成する。結局二段構えの自動生成になるのは前と同じ。
utoipaが思ったほど気が利かないで、なかなかうまくいかない。これはOpenAPIの問題でもある気がするけど、命名をうまくやらないと名前が衝突する気がする。まあ今回はそれほど気にしなくていいと思うけど。うーん。
そんなことよりせっかくルーティングを自分で書いたのだから本来やりたかった認証部分に着手したいのだけど。まあ、こうして試行錯誤しておくといつか本業で役に立つと思うから、筋トレをしておくか……。
本業のほうは負荷試験を始めた。k6は便利。
寝ます。
本業ではずっとKotlinを書いているんだけど、SpringBootがだいぶ憎くなってきた。なんでもかんでも俺の知らんものをDIしないでくれ。そして俺の知らん例外を投げないでくれ。
あとGradleも何が悲しゅうてこんなややこしいものを扱わねばならんのか？と思う。いや、これは僕が1秒たりとも勉強してないからだけど。でも、Version Catalog？とかって誰も使ってなくない？ってくらい情報が出てこないのよな。うーん？
本業じゃないやつは、これまでOpenAPIに生成させていたバックエンドのルーティングを全部消して自前で書き直し、さらにそこからスキーマを生成させるところまで。utoipaはまあ普通に使えるけど、欲をいえばもう少しコードからよしなに読み取ってほしい。今回はAPIの本数が10本もないくらいだから別にいいけど、増えてくるとやはり煩わしいのではないかと思う。結局自分でマクロ書けって話になるのか？
ついでにエラーハンドリングもすこし改善した。まだボイラープレートコードが残っているから、これはderiveマクロを書こうかな。各エラーにステータスコードを割り振るためのFromは自動生成させたいところだ。
フロントエンドもOpenAPI generator以外の選択肢を探してみようかなと考えている。なかなか先に進めなくてもどかしいね。
寝ます。そういえば就職して3ヶ月、試用期間が終わりだ。
バックエンドに認証をつけたりセッション管理をつけたりしようとしているのだが、そうするとOpenAPIの生成コードではうまくいかなくなってしまった。Axumはリクエストハンドラの引数にextractorを追加していくシステムだから、コードジェネレイタが用意したextractorしか使えない。今回は署名済みクッキーによるセッション管理をやりたかったので、これではダメだ。
しばらく考えたが、これはschema firstを棄てるタイミングなのかなと思う。もはやスキーマにバックエンドが合っていることを保証するものはないのなら、逆にcode firstに生成してやる方がいい。ただcode firstはそれはそれで使い勝手悪いなという話もあり、そこは慎重に考えたい。
まあ具体的なところは明日以降見ていく。
寝るよ。
記事投稿APIをとりあえず作って、Remixのactionで呼べるようにした。いいね。あとは認証をやらないといけないのだが、これはどうするのがベストプラクティスなのか。ううむ。
スタイルもすこし整えた。Chromeでは約物の余白調整にtext-spacing-trimが使えるけどFirefoxでは秘伝のCSSでやらなくてはいけない。このロジックをフロント側に持ってくることも考えられなくはないけど、悩ましい。基本的にはバックエンドでやる方が速いし確実だろうと思うのだけども。
寝ます。
主にCSSをいじっていた。blogのスタイルを多少変えようとも思っているけれど、とりあえず完コピを目指している。記事周辺のレイアウトはだいぶ再現できてきた。flexとかgridとか、現バージョンを書くときも多少使ったけど、その時よりすこしうまく使えるようになっていると思う。あとtailwindにも慣れてきた。
20年近く前にCSSを学んだから、文書の内容と装飾は綺麗に分離して、CSSのクラス名には意味を表す名前をつけて、……みたいな考えかたが頭にあるのだけれど、ReactでWebアプリケイションを作る上ではすこし違う風に考えるほうがいいのかなと思うようになった。まず、もはやこれは文書ではない（その境界は曖昧だが）というのと、意味的な区切りはコンポーネントとして作れるのだから、CSSのクラス名で表現する必要はないというのと。tailwindのクラス名はそれがどんな装飾であるのかを端的に表していて、それがどんな意図で使われているのかはコンポーネント名に現れている。もはやCSSを見てこれは何に使われているのだろうかと考えることはない（インラインで書くのと同じ）のだから、そのための命名規則も必要ないということか。
見た目が幾分それらしくなってきたし、そろそろバックエンドの実装に戻るべきか。投稿とかできるようにしたい。
寝ます。