shuymn

cloudflare/wrangler-actionsクソ遅いので使わないようにしたらデプロイがクソ速くなって最高

D1 beta backendにしたらクエリがめちゃくちゃ速くなってすごい

正直今のD1はマイグレーションはCDでやらずにローカルからやるorダッシュボードからクエリ投げるほうがトラブルシューティングしやすくて良さそう。ただCDでwrangler使って実行してるログを見た感じwrangler d1のエラー出力貧弱すぎてどういうエラーなのか全く分からない

トランザクション張れるようになったときに解決するならいいんだけどなー。もしくはSQLに `PRAGMA foreign_keys = false;` 書いても反映されないとか？よく分からないことがおおい

ローカルのSQLiteに対して成功するマイグレーションがD1に向けると失敗することがまあまあある。とくにスキーマを変更するために新しいテーブル作ってデータをINSERTしてから入れ替えるみたいな何個かステートメントが連続しているようなやつを実行するとだいたい失敗する。でも何回か実行すると成功するんだけどその途中でマイグレーションが中途半端な状態で失敗したりもするから危険

proxymanマジで良いな。求めていたもの

KVって25MBのデータまで保管できるのか。思ったよりもデカいな developers.cloudflare.com/workers/platform/limits/

ホームタイムラインのキャッシュっていまはDurable Objectsに置かれてるんだけどこれってKV使ったらだめな理由あるのかな。あるていど更新頻度が担保されてるなら結果整合性だったとしても問題ないと思ってるんだけど、DOのほうがレスポンス良いとかあるのかな

D1の500MB制限って意外と厳しいな。これ参照されにくいオブジェクトはD1以外の場所に逃がすような処理を書かないとRelayの対応とかは絶対にやっちゃいけないな。どれくらい厳しいかというと1投稿2KBと過程すると25万投稿ぐらいで足りなくなる

コード書くのに集中してると飯食べる頻度落ちるし、お腹いっぱいになると眠くなったりするので食べるとしてもそんなに食べないので、夕食として普通の量食べると消化不良起こしてお腹痛くなるのどうにかしたい。作業しながらアイスコーヒー飲んでるせいでそもそも胃腸冷えがちだし

Wildebeestってローカルアカウントの秘密鍵をDBに保持してるんだけど、これってつまりDBを見れる人ならローカルアカウントのだれかになりすましてActivityを流すことが可能ってことだよね

UIまわりのテストがすぐ落ちるのでGitHub Actionsには標準でリトライ機能を実装してほしい

microblog.pubみたいに1インスタンス1ユーザー固定？の実装だとacctからactorのidが推測不可能な場合があるから現状のWildebeestの実装だとダメだ〜ってなった

limitが指定できる系のエンドポイントで使われるSQLはテーブルのスキーマ間違えるとJOINによって行が分裂してSQLのLIMITと結果の個数が変わる可能性があるからめんどい

今後はもっといろんな物が結果整合性で処理されるようになると思う

test

st

あとはreblogと投稿のvisibilityをちゃんとハンドリングする修正もとりあえず自分の環境ではちゃんと動くようになった github.com/shuymn/wildebeest/pull/134

とりあえず自分の方もREADME更新しておいた github.com/shuymn/wildebeest

Wildebeest、いい奴だったよ