唯一の不満点は、Next.jsで使う場合、RouteHandler前提のインターフェイスになっているため、ServerComponentから各種機能を呼び出す際にCookieが必要になる点。またはClientComponentからもAPI呼び出しになるのでuseなどのawait対応が必要になる点かな。
唯一の不満点は、Next.jsで使う場合、RouteHandler前提のインターフェイスになっているため、ServerComponentから各種機能を呼び出す際にCookieが必要になる点。またはClientComponentからもAPI呼び出しになるのでuseなどのawait対応が必要になる点かな。
プログラミング初学者によく言う「エラーコードをよく見てね」という言葉は、今だと「エラーコードをChatGPTにペーストしてね」になってしまったな
JS系で認証作るのAuth.jsでやってたけど、BetterAuthを試したらかなり良い感じだったので、これからはBetterAuthを使っていくことにする。Auth0などのIDaaSを使わない場合。
マイルドカルディが1100円以上すると聞いて目玉飛び出そうになった
FFTのリマスターが出るとは…。追加ストーリー気になるなぁ。
あと調整は…あれかな盗めるようになるのかなあれが。
あとウィーグラフさんの調整が入るのか…?
www.famitsu.com/article/2025...
もし企業向けSaaSやる場合は初手からSAML/OpenID対応可能な認証を実装したほうが良い
Prismaでselect使ってる処理をVitestでモックにしようとすると型エラーになる。これを避ける方法はいくつかあるっぽいけど、手軽なやり方がなくて ts-expect-error でチェックを無視しちゃっている…うーん微妙だな
40歳を超えてから意識的に新しいことをやるようにしてる。逆にスパッと辞めることも意識している。
新しく始めたこと
・スポーツ観戦:野球やバスケ(実際にスタジアムに行く)
・登山:来年にはテント泊に挑戦したい
・英語学習:成果はいまだ見えず
辞めたこと
・お酒
・X
そしてコーヒを飲みながらカフェインをやめるかどうか迷っている今
ニュータイプ専用モビルスーツの開発者はどうやってテストしてるんだろうか
GoogleDriveの変更通知API( changes\.watch )、ちょっと不便過ぎる仕様だな
・特定フォルダ配下を指定することができず全ファイルになる
・フォルダを閲覧しただけで通知が来る(閲覧日時が更新されるため)
・watch\.listで取得できるファイルの変更差分では、直属の親フォルダIDしかわからない。上位まで遡るには再帰処理で1個ずつ遡る必要がある
特定フォルダ配下の変更だけ拾いたいのに、かなりの数のAPI呼び出しが必要になっちゃうな…
そして、file\.watchのAPIだと、ネストされたフォルダの変更通知は受け取れない
VS CodeのGitHub Copilot Agent mode、自動許可コマンドリスト機能がほしい
Prismaの売上があがらなければPrisma ORMの発展リソースも限られる。でも今のところPrismaのクラウドサービスを使うユースケースがないんだよな…。かなりお世話になっているので、何等か貢献はしたい。
スプラ、ようやくXP2000超えた
IntelliJのMarmaid記法、erDiagramはサポートしてないのか
最近のAIによる恩恵って脳内にあるぼんやりしたイメージを明確な言葉や図として出力することで、他者との共通認識をえやすいことだと考えている。その出力仮定が間違っていることも当然あるが、出力コストの異常な安さや、品質の差が出にくいことからメリットのほうが上回っている。デメリットとして思考能力が養われないという危惧もあるが、それは使い方次第で、従来の外部メディアと同質な気がしているので問題の本質じゃない気がする。
DBのパスワードにスラッシュを使わないでほしい高校
TIME_WAITが多い分には困らないが(ポートを食いつぶさない量なら)、Threadsが全部占有され続けPoolCapacityが0の状態が続くのは大問題だ、という整理であってそうだ。その場合、強制終了させたいがPumaをクラスターモードで動かしてworker_timeoutを設定しないと実現で来なさそう。Nginx側でタイムアウト設定して切断してもPumaのスレッドが開放されるわけじゃないし…。となるとWorkerをスケールアウトさせていくしかないのか?
なんとなく理解した。Nginx->PumaでKeepAliveされているが、処理が長いリクエストがThreadsの数だけ占有されていると、新しいリクエストは新規でTCP接続する。その溢れた数だけTIME_WAITが積み重なっていくという感じか。リクエスト数と処理数が見合わない状況だとそうなりやすい感じね。
どうやらPumaのThreadsを使い果たしPoolCapacityが0担った状態で新規接続が来るとFINパケットが送信されるっぽい雰囲気がある。Puma的にはリクエストが来ても処理できないからもう一度やってね的な挙動なのか…?
Nginx経由Railsで、KeepAlive設定しているのにもかかわらず、KeepAliveが数秒ですぐにRails側から切断されTIME_WAITが大量発生するのなんでだろう。Pumaのpersistent_timeoutも伸ばしてみたけど結果変わらず。Railsではなく、Puma単体やNode.jsで試すと意図通りTIME_WAITは一定の数に収まる。うーん。
一般的にカルーセルはナビゲーションUIではなく「広告」。広告というのは外部コンテンツに限らず、内部コンテンツへのアテンションとしての役割を期待していると思う。その効果測定をしっかりしたうえで判断をしていきたい。
カルーセルに価値がないと断定するだけのデータと揃えて論理的主張をする人を見たことがない。僕個人はカルーセル実装には反対スタンスだけど、ユーザにとって絶対的に無意味で無価値とも思わない。
Puma、KeepAlive有効にしているとパフォーマンスが悪化するのか
Switch2、ほんとうに当たらないな…
IssueをAIがたて、AIがコード書いて、AIがレビューして…「もう全部あいつ一人でいいんじゃないかな」という世界になってきた
あと、現状だとデータは永続化されないので再起動すると全部消える。ここらへんを手当して使う前提だな。
Prisma、ローカルでPostgreSQLを起動できるようになってる。内部ではPGLite(WASM)を使っている様子。完全な互換ではないのでケースによっては使えないけど、普通に使う分には良さそう。Dockerも必要ないし。
www.prisma.io/docs/postgre...
違うか。正確に言うとConnection closeをレスポンスするときに、Webサーバ側からFINで切断する動きになるという感じか。となると、TCPのコネクションがTIME_WAITになるのはどちらも変わらないけど、TIME_WAITになっている場所がサーバとクライアントで変わるってことだ。
tcpdumpで確認すると、レスポンスヘッダでConnection KeepAliveを返すと、クライアント側からFINパケット送信。レスポンスヘッダを返さない場合はWebサーバ側からFINパケット送信というように方向が変わる。
Node.jsのHTTPモジュール、レスポンスヘッダにKeepAliveを返すか返さないかで、TCPソケットの扱い変わるのか…?