andante

ログイン盆栽をずっとしている。なんかまあバックエンドは結論出つつあるのだけど、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を見てこれは何に使われているのだろうかと考えることはない（インラインで書くのと同じ）のだから、そのための命名規則も必要ないということか。

見た目が幾分それらしくなってきたし、そろそろバックエンドの実装に戻るべきか。投稿とかできるようにしたい。

寝ます。

花火大会を観た。まあまあの距離で観られたのでけっこうよかった。埼玉の方では雷が鳴っていたようで、花火より稲妻のほうがみんなのリアクションが大きくておかしかった。
花火大会を観るたびに思うが、この野蛮な娯楽はいつまで生き残るだろうか。ドローンでやればいいのでは？という風潮にいつまで抗い続けられるだろうか。（そしてまあ、僕もドローンショーのほうが格好いいし安全だしでいいのでは？と多少は思っている）。

録画していたパリオリンピック開会式を観た。なんか、個性的というか、これはオリンピックとかいうよくわからん平和の祭典である前にパリの文化の祭りなんじゃいという意志が強く感じられた。パリコレパートとか、どういう意味があって開会式でやってるのか僕にはわからなくて、こんなの東京オリンピックでボカロMV延々流すくらいの尖りかたじゃない？という気持ちがあるのだが、それをやるぞという自信と、それでいける文化的ポジションは羨ましいよね。ただ、選手入場までの前半パートはなんか散漫な感じだった。街中でいろいろパフォーマンスをやるのも、どうもしっくりこないというか、フラッシュモブに出くわした時の気恥ずかしさみたいなのがあって、うーむと思った。後半はけっこうビシッとしててよかったけど。

Reactを手探りで書いている。カレンダー関連の機能を適当に書いたらなんかパフォーマンスが悪くなったのでとりあえずメモ化で対応したが、本当にこれでいいのだろうか。Dateがオブジェクトだから同値判定がポインタでされる？のが地味に面倒で、これのせいでuseEffectもuseMemoも一回文字列を挟むとかで対策が必要になる（よね？）。ふーむ。

寝ます。

諸事情ってのは、だいたいの場合は、すごい喧嘩とかで疲弊したということです。

Remixぽちぽち。Webフロントエンドに触れるのが数年おきなので、基本的なところから毎回ググらないとベストプラクティスがわからない。日付時刻操作は今でもdayjsが現役のようだけど、せっかくなのでtempoというやつを試してみる。でもなんかこいつは関数ベースなので書き味がイマイチかもしれんな。
すこしずつそれらしいコードが集まってきたが、まだいろいろ迷いもある。ディレクトリ構成とか。たぶんこれはみんな悩むやつなんだけど。そういう意味ではRailsとか楽だよなと思うが、あれがあるべき姿かというとそうではなかろう。

オリンピックシーズン（？）ということで、なんとはなしにロンドンオリンピックの開会式を（また）観た。これ3回くらい観てる気がする。やはりね、これと比べると、TOKYO2020は（コロナ禍とはいえ）なぜこうなれなかったのか……という気持ちになり、国民的自傷行為という気がする。
パリオリンピックも楽しみだ。録画したのでそのうち観よう。どうせYouTubeに上がるだろうけど。

寝ます。