ねるにゃー

タンヤオの出現率: 約22〜23%（天鳳鳳凰卓データで22.8%前後） ピンフの出現率: 約20%（天鳳データで20.2%、他の統計で19.9〜21.5%）

groonga が使えr supabase の料金表を見てるんだけど、$25/mont で1プロジェクトあたり 8GB なんだな。nostr-relay 既に 9GB やがな。

X や Google 風の検索クエリライブラリ書いた。 PostgreSQL の tsquery や SQLite3 の FTS5 クエリ、MySQL の boolean マッチのクエリを作る関数も含む。 これでもし NIP-50 がこの形式をサポートするなら、これを使おうと思う。

vscode のぺろん？

問題は「おれにはそれ実装できねぇ」というリレー開発者を救う必要があるという点で、その場合 hello AND world を "hello" AND "AND" AND "world" として処理する選択肢を用意してあげんといかん。

そうなんですよね。僕もここ数日思っていて、検索だけ別に切り出した方がいいんじゃないかと。

ひとまず構想中の物としては、filter.search は単語リストを取る。クオート可能、カッコでのグルーピング可能。 hello world は "hello" AND "world" "hello world" は "hello world" "hello" "world" は "hello" AND "world" hello OR world は "hello" OR "world" AND は OR よりも結合が強いので hello AND world OR greeting は (hello AND world) OR greeting この仕様を NIP-11 で自分で定義させる。 "nip50_search": { "boolean_operators": true, "parentheses": true, "phrase_search": true } こんな感じ。

挙動不審者絵文字やん :eyes:

NIP-50 の検索はクエリの仕様が決められてないのがキツいな。 「おっぱい いっぱい」で検索した際に「"おっぱい" OR "いっぱい"」なのか、「"おっぱい" AND "いっぱい"」なのか「"おっぱい いっぱい"」なのか決められてない。 EOSE まではデータベースの検索に依存するし、EOSE より後はメモリ操作になるだろうから、せめて統一して欲しい。(お前が提案しろ)

漏らしたら漏らした時

GitHub に blossom-server という名前のリポジトリが2つあり、どちらにも pull-req してるので fork リポジトリに 2 とか付けた。

ゲームしないので GPU とか、光沢液晶にはまったく興味が無い。

開発関連の執筆業をしてるけど、ある程度マシな PC 使ってないと読者と差が出るので、これは必要経費。

メモリ32GB、AMD Ryzen 7 7735HS、1TB　ストレージなら数年は戦えるでしょ。

しんくぱっよです

新しいノート PC買っていい？

大掃除せなあかんので、お昼の準備した。カネテツの野菜天いりの木の葉丼。

我が家を見てるようだわ。

X (formerly Twitter)

Chitra (@just_chitraa) on X

It's called a healthy family 🥹💗

那月さんに手加減しない Nostr 雀士たち