研究100歩後退したから申し訳程度に2歩進めた
For those who wants information about Yuito, subscribe my English posts only (available on account profile, Mastodon v4 or above).
くだらないこと言ってる人格は わんせた 、コード書いてる人格は kyori
呼ぶときは わせたん でもよし。たんってついてればかわいいので
Manages: https://odakyu.app https://nitiasa.com
Maintains: https://accelf.net/yuito (fork of Tusky)
when these instances down see here: @ars42525 @ars42525
Server Status: https://graph.accelf.net
Prometheusのデータ用ディレクトリに書き込みできなくなっていたせいでDBが崩壊しまくっていたらしく、ようやくWALの復旧が終わってTSDBが帰ってきた
特定のフレームワークが書ける人を求人してもボイラープレート職人しか集まらないし、そういうタスクは存在しないのでやめたほうがいい気がしてきた
フレームワークを使ったことがない人はデバッグとかができなくなるから困るが、ボイラープレート職人は実装ができないので困る
コードを書いていて「いつも通りに作っておいて〜」ってなるタスクって、時間的にもモチベ的にもすごく良くないと思うわけさ
そんな部分はそれこそ機械に解決してもらうべきなんだが、解決手段がコード生成・共通化・AIに丸投げの3択くらい見えているのが近頃の風潮であって、実装工数的には正直どれでもいい
しかし、コードレビューのコストを見たときにコードを増やされると強いエンジニアの工数がもったいない
つまり何が言いたいかというとDSLを作って共通化をしろ(過激派)
KotlinにResult::recoverっていう関数が生えてるんだけど、返り値がResult<R>になっていておかしい気がする
これSuccessしかありえないからRでいいよね?