Nostrのイベントを取得する練習用コードを書いてるのだけど、pタグでフィルターする機能をつけた。
今フィルターを表すデータ型とJSONの相互変換の関数を書いてて、変換したJSONがちゃんと「使えるもの」であることを確認するため。
なので、他の項目でのフィルターも実装していく必要がある。
YoshikuniJujo
YoshikuniJujo@yoshikunijujo.github.io
npub1a7y7...fdm2
Haskell好き
コードのチェックでnos.lolに投稿してみるんだけど、うまくいかないことが多い。
リレーがbusyってことなのかな。
ギャグマンガ日和で「夏休みの宿題の工作を手伝ってくれるロボット」が「夏休みの宿題」として「自分より高性能のロボット」を作って、そのロボットがまた「自分より高性能のロボット」を作りと繰り返した結果、人類がロボットに支配される話あったけど、現実化しそうな勢いなのかな。
カフェワッサンやっぶみーん
うにゅう、おはよう
やればやるほど勉強することが増えていく
|
V
「楽しい!」
「基本的に自動運転のほうが人間による運転よりも安全であることが期待できるが、テスラに関してはその限りではない」って感じかな。
あまり進まないな。
とりあえず、フィルターを表すデータ型からJSONの表現に変換する部分を書いた。
次は逆の変換をする部分を書く。
それができたら、フィルターを表現するデータ型からSQLのwhere節(句?)を作る部分を書く。
たとえば、モジュールFooのなかで、Barとの相互変換の関数を書くとしたら名前は
fromBar :: Bar -> Foo
toBar :: Foo -> Bar
みたいになる。
で、モジュールFoo.Barのなかでそれらの相互変換の関数を書くとしたら、もし明らかにBarのほうがより平坦であれば、
encode :: Foo -> Bar
decode :: Bar -> Maybe Foo
みたいにするかな。どっちも平坦さの度合いが変わらなかったら、
fToB :: Foo -> Bar
bToF :: Bar -> Foo
みたいな感じかな。
--(encode)->
構造を持つ値 平坦な値
<-(decode)--
--(pretty print)->
構造を持つ値 平坦な値
<-(parse)--
みたいな感じ。pretty printとかencodeは基本的な失敗がないのに対して、decodeとかparseにはerrorがあり得る。
ppr :: Value -> String
encode :: Value -> Binary
parse :: String -> Maybe Value
decode :: Binary -> Maybe Value
僕は静電気のバチッていうの好きだったな
やっぶみーん
うにゅう、おはよう
Nostrのフィルターを表現するデータ構造を定義した。
data Filter = Filter {
ids :: Maybe [BS.ByteString],
authors :: Maybe [Pub],
kinds :: Maybe [Int],
...
みたいなやつ。
「お呼ばれする」は言うかも
高性能なGPUを欲しがるのがゲーマーだけだった牧歌的な時代があって……
めったにないことだけど、プログラム組んでて、「ここはややこしいな」ってところは紙に書いて考えることがある。
紙とペンでしかできない思考ってあると思う。
「情報が漏洩したので火消しのために、お金をください」
「大変だ。このお金を使いなさい」
「だまされたな、あれがやつの手口なんだ」
「よかった。情報漏洩はなかったんだ」