まあ、「仕様の美しくないところ」に対応するのが、めんどくさくもあり、楽しくもあるところでもある。
YoshikuniJujo
YoshikuniJujo@yoshikunijujo.github.io
npub1a7y7...fdm2
Haskell好き
Nostrの仕様だけど、ハッシュ値を求める計算でタグの部分をシリアライズする場面では、「辞書順にソートして」みたいにしたほうが仕様としては「きれい」だったんじゃないかなと思うのだけど、でもなんか別の部分の仕様で古い仕様なんだけど、タグの出現する順序で意味付けをしてたりする。
まあ、その部分も込みで「辞書順にソートする」ほうが仕様としてきれい。
「きれい」な仕様よりも「使われてる」仕様のほうが価値が高いのでしかたないけど。
同じようなコードを2回とか3回とか実装することってある。
コードを書いているうちに「わりと根本的なところ」に問題が見つかった場合など、1から書き直したほうが早かったりする。
で、1回目書くのと、2回目3回目書くのとだと、ずいぶん感じがちがう。1回目はトップダウンで書いていく。できるだけ早く「動くもの」を用意する。で、動かしてはスタブをうめて、みたいな感じだ。
2回目以降はボトムアップになりがち。
1回目のコードを読みながら、それにそって細かいところから実装していく。で、この場合わりと大きく育ったあとで、「実は動きませんでした」ということになる場合がある。
けど、それでも、全体としてはこのやりかたのほうが早い感じだ。
1回目のコードが「ある程度は動く」ので、比較したがらバグを取っていけばいい。
既存のパッケージに対して、根本的なところを変化させた新しいパッケージを用意するとき、名前に-ngをつけるのが好き。
fooに対してfoo-ngみたいな。new generationの略だと思う。
eventとタグについてなんだけど、今の僕の実装だと一度辞書型に変換していて、それは「きれいな実装」ではあるんだけど、ハッシュ値を計算するときには、タグの順序を保たなきゃならないので、問題があるかもしれない。
辞書型で保存しておいたほうがきれいだけど、[(key, value)]みたいなタプルのリストにしておく必要があるか。
Nostrのイベントが複数の同一キーのタグを持てるという話。
uuidと値のテーブルを作っておいて、insertのときには、タグのところには、生成したuuidを入れておいて、そのタグに対する値はタグ用のテーブルに、そのuuidとペアでinsertするという形になるかな。
外部キーはスケールさせようと思うならUUIDを使うのがいいんだろうな。
Nostrではキーが同一であるような複数のタグを指定できる。
そうなってくると、データベースで「どう表現するか」が難しくなるな。
REQのフィルターをWHERE句に変換するのめんどくさい。単に文字列にするだけでもめんどいけど、セキュリティ的にそこは「プレースホルダー使うでしょ」的な話あるのでもっとめんどい。
REQのフィルターをより抽象度の高いデータ型に読み込み、そこからプレースホルダーの'?'を含む文字列と、プレースホルダーにはいる値のリストとを生成する関数を書く感じかな。
Nostrのリレーを作ってるのだけど、データ型をJSON用のデータ型と、もっと高レベルで抽象的なデータ型とといった感じで変換をしたりするのだけど、そのなかでidとsigのあつかいが、あるところではバイナリとして、あるところでは16進法表記として、とばらばらにあつかってしまうというバグを作りこんだ。直した。
TEST
テストテストテスト
@npub18rtj...tdv6
テスト用のアカウント
やっぶみーん
うにゅう、おはよう
そうか。
一応流れとしては、衆議院解散して総選挙があって、そのあと衆議院で首相を選ぶって感じだったか。
パイ生地は「イーストをいれずにクロワッサン生地を作る」みたいに作れないかな。
あと折り込みを3回から8回に増やすのと。
だめかな。
!きょもなん
のすたろう、今どうなってますか？
折り込みパイ生地 | レシピ・作り方 | 【cotta＊コッタ】
nozomiさんの「折り込みパイ生地」レシピ。製菓・製パン材料・調理器具の通販サイト【cotta*コッタ】では、人...