andante

本業ではずっとKotlinを書いているんだけど、SpringBootがだいぶ憎くなってきた。なんでもかんでも俺の知らんものをDIしないでくれ。そして俺の知らん例外を投げないでくれ。
あとGradleも何が悲しゅうてこんなややこしいものを扱わねばならんのか？と思う。いや、これは僕が1秒たりとも勉強してないからだけど。でも、Version Catalog？とかって誰も使ってなくない？ってくらい情報が出てこないのよな。うーん？

本業じゃないやつは、これまでOpenAPIに生成させていたバックエンドのルーティングを全部消して自前で書き直し、さらにそこからスキーマを生成させるところまで。utoipaはまあ普通に使えるけど、欲をいえばもう少しコードからよしなに読み取ってほしい。今回はAPIの本数が10本もないくらいだから別にいいけど、増えてくるとやはり煩わしいのではないかと思う。結局自分でマクロ書けって話になるのか？
ついでにエラーハンドリングもすこし改善した。まだボイラープレートコードが残っているから、これはderiveマクロを書こうかな。各エラーにステータスコードを割り振るためのFromは自動生成させたいところだ。
フロントエンドもOpenAPI generator以外の選択肢を探してみようかなと考えている。なかなか先に進めなくてもどかしいね。

寝ます。そういえば就職して3ヶ月、試用期間が終わりだ。

盆栽に明け暮れている。バックエンドがutoipaでスキーマを生成し、フロントエンドはorvalでクライアントを生成する。結局二段構えの自動生成になるのは前と同じ。
utoipaが思ったほど気が利かないで、なかなかうまくいかない。これはOpenAPIの問題でもある気がするけど、命名をうまくやらないと名前が衝突する気がする。まあ今回はそれほど気にしなくていいと思うけど。うーん。
そんなことよりせっかくルーティングを自分で書いたのだから本来やりたかった認証部分に着手したいのだけど。まあ、こうして試行錯誤しておくといつか本業で役に立つと思うから、筋トレをしておくか……。

本業のほうは負荷試験を始めた。k6は便利。

寝ます。

ずっと盆栽。utoipaもなかなか癖があるなと思いつつ、とりあえずはいったんこれでいいか、というスタイルに落ち着いた。ただ、これくらい自動でやってくれないのか？と思う部分はあり、まあそれはもう自分でマクロを書いた方がいい領域の話なのかもしれないと思った。
一方で、OpenAPI generatorのテンプレートは少しならカスタマイズが利くという話もあり、そっちを模索するほうが結局は正気なのかもしれないと迷う。ついでに言えばOrvalもイマイチ使い勝手が良くない。悩みが多い。
もっとも、こんなのは完全に盆栽要素なので、今はほどほどにして実装を進めたい。今度こそログインをやる。

寝るよ。

ログインをやろうと思っていろいろ試行錯誤している。Google Sign Inに対応するボタンを置くのは問題なくできたが、結局どのようにログインセッションを持つのか悩ましい。今のところはバックエンドがセッションクッキーを発行するのをそのまま使えばいいかなと思うけど、それだとCookieの内容にはフロントエンドはアクセスできないから、ログイン状態確認エンドポイントを作る必要がある？いや、それもよくわかってないな。結局RemixはCookieをどう扱うんだ？調べなくては。

「誰が勇者を殺したか」読んだ。素直。結末でもう一回くらいひっくり返ると良かったと思う。続編がちょうど出たところだったので買った。

寝ます。

ログイン盆栽をずっとしている。なんかまあバックエンドは結論出つつあるのだけど、Remix側が難しい。結局Cookieを食わせて回らなきゃいけないし、バックエンドから送られてきたらセッションに入れなきゃいけないが、そのあたりの共通化がうまくできそうもない。なんかラッパー書けばいけるのか？

寝ます。明日は夏期休暇でおやすみ。

平日に休みをとっても結局仕事のことが気になってあまり気が休まらないんだよな。そうでもないか。

休みだけど特にたいしたことはしていない。「地面師たち」見始めた。面白い。

ログイン盆栽は今日は手をつけていない。結局Remixでやる限りは何らかのバケツリレーを許容するしかなさそうだ。一旦はそれで進めることにして、あとで何かうまい抽象化ができないか考えよう。うーむ。
そうと決まればつぎはフロントエンドに注力か。

寝ます。仕事か〜。

眠い。

Orvalのfetch API対応はやはり壊れているように思う。ヘッダーを外から渡せるようになっていない（渡せるように見えるがContent-Typeヘッダを内部で渡しているのがちゃんとマージされていないので消えてしまう）。修正のPRを出した方がいいのか？簡単にできるのかはわからないけども。
OpenAPI GeneratorもOrvalも微妙で、困るなと思う。いや、OpenAPIのほうが少しマシなのか？でもこっちはこっちでsingle-fetchと相性がよくないので悩ましい。どいつもこいつもな！ハーッ！
それはさておきCookie認証はなんとかできつつある。妥協の産物だが、妥協点を決められたのは良かった。結局こういうのを一度やっておく筋トレが、限られた時間の中で設計と実装をやっていかなければならない時のために必要なんだなと思う。

寝ます。

なんか夜中に頭痛で目が覚めて、今日も一日頭が痛かった。閃輝暗点も出るので偏頭痛ということなんだろうと思う。偏頭痛の薬は飲んだ。この薬を飲むと何に作用しているのか元気がなくなる。しかもそれほど効くわけでもない。

openapi-typescriptとopenapi-fetchを試した。これはけっこういい。ただ、開発版はいいんだけどビルドするとエラーが出るようになってしまうので、開発完了までに直らなければ使えないだろう。フロントエンドのエコシステムは全部何かしら壊れているのではないかと疑っている。たぶん色んなものがどんどん変化するから誰にも全部は追いつけないし変な不具合を踏む確率も下げられないのだろう。それってどうなの。やっぱフロントエンドには関わらない方がいいのか？？

寝る。明日は頭痛が治っていてくれよ。頭が痛いと全然仕事にならん。

昨夜はなかなか寝つけなくてしんどかった。最近はめったにこういうことはなくなってきたけど、たまになるとしんどい。

頭痛はだいぶ良くなった。仕事は激遅クエリがあったのでマテリアライズドビューを書いて対応した。これ便利やね。活用していきたい。
徐々にアクセス増えてきたから、パフォーマンスを注視しなくてはならない。頑張る。

blogのほうは細かなリファクタだけ。SeaORMが1.0になっていた。とりあえずはAPIを埋めて、それからフロントエンドのデザインにかかろう。でもエラーハンドリングとかまだ決めきれてないんだよな。うーん。

ツイッター学級会のルールには、ざっくりの傾向として厳罰化の一途を辿っている以外には一貫した基準など何もないように思われるのだが、参加している人たちはそれぞれにその基準があると信じている。しかし、毎度毎度アドホックに変形していくその基準は、天動説に付け加えられた周転円のように見えて少しおかしい。

エラーハンドリングに悩んでいる。正確には、レイヤーを跨いだエラーの受け渡し。コントローラからアプリケイションロジックを呼ぶ時に、テスタビリティ的にはtraitになっているほうが嬉しいが、そうしてしまうと今度はコントローラからアプリケイションロジックのエラーの具体的な型を得るのが難しくなり、レスポンスエラーへのキャストもしづらいし、どうしたものか。アプリケイションロジックはtraitにするが、エラーの型は固定にするか。それもなんだか気味が悪いが。
結局、インフラ層のエラーをコントローラまでそのままリレーしてくる必要は全然なく、スタックトレースだけ取れればよいはずなのだから、そこをうまく妥協できる枠組みを考える必要があるだろう。もうすこし考えなくては。

寝ます。