Nip-11を実装しようとしたらwebsocketパッケージは使えないな。HTTPで接続してからWebSocketsにUpgradeするまでのあいだにHTTPでサーバの情報を送らなくちゃならないってことだと思うので。多分そういうことだと思う。
あと、よく考えたらWebSocketsじゃないHTTPクライアントから接続されたときに、何かしらの「まあまあちゃんとしたもの」を返すようにしておいたほうがいいのかもしれない。
となるとWebSocketを実装する他のパッケージを探すか、あるいは自分で書かなくちゃならない。
YoshikuniJujo
YoshikuniJujo@yoshikunijujo.github.io
npub1a7y7...fdm2
Haskell好き
テスト
リレーサーバーの名前などをクライアントに提供するのがNIP-11なのだけど、思ったよりめんどくさくて、WebSocketはHTTPからUpgradeされるらしいのだけど、まだHTTPのうちにJSONファイルを送らなくちゃならなくて、今使ってる関数だと「HTTPのうちにデータを送信する」という機能がない。
Renderにuploadしたりとかそういうことって、「ちゃんとコードを書く」こととごっちゃになると腰が重くなるので、まずはws://localhost:10000を使ってるクライアントのリレーのリストに追加して、ローカルでちゃんと動くようにしてから、次にローカルのDockerイメージで動くようにして、それからRenderにアップしよう。
localhostリレーに対する書き込みのテストです。
wss://nostr-kyomu-haskell.onrender.com
ちょっとしたものにも名前を決めておくと、いろいろな段階で意志決定のコストを減らすことができる。
HaskellでNostrのRelayを作っていこうと思うのだけど、NostrのHaskellのRelayということでNoskellayにしようかと思う。で、実験的に作るので本番では大きく設計等が変わると思うので、stopgap(まにあわせ)をつけて、プロジェクト名はNoskellay Stopgapにしよう。で、ディレクトリ名やパッケージ名、Docker imageのタグなどにはnoskellay-stopgapを使おうと思う。
やっぶみーん
うにゅう、おはよう
ブラウザエンジンとかHTMLエンジンとかいうものが、一強になってしまうのは、HTMLというものが、はちゃめちゃだからなのだと思う。
HTTPはいいので、HTTPプロトコル上できちんと定義されたスクリプト言語で書かれたコードを送るようにしたらどうだろうか。
レンダリングエンジンにはblink gecko webkitがあるけど、まだ研究的な段階だけどservoというRust製のレンダリングエンジンもあるようだ。
https://news.mynavi.jp/techplus/article/20171016-a187/
Qutebrowserってのがあるらしい
明日はDockerのコンテナ内でemerge -v sqliteをしないで、simplest-sqliteのインストールを試し、エラーになるのを確認したうえで、emerge -v sqliteをしてからsimplest-sqliteのインストールを試してみよう。
タスクリストは「タスクを実行するため」に作るのではなくて、「タスクを忘れるため」に作るというの話、わかる
クロワッサンの断面。中央部の層はきれいに広がってるけど、上部と下部はややつぶれ気味。
僕のオーブンレンジは下火がないので、上から強い熱を加えなくちゃならない。
そうすると、上部はメイラード反応が進み硬くなり膨らみにくくなる。
下部は温度の上昇が遅れるためバターの水分の蒸発による力が不十分になる。
なので今のオーブンを使っている以上はこれが限界かもしれない。
次買うのは石窯ドームあたりがコスパ的にもいいように思う。
Qiita
SQLiteが泣きたくなるほど遅い場合の対処法 - Qiita
はじめに 恒例のお断りですが、この文章の内容は、筆者が所属している会社・団体とは一切関わりがありま...
SQLiteがだいたい使えるようになったら、次はPostgresあたりを使ってみたい。
docker build ...でdeprecatedだよって言われるのは、sudo emerge -av docker-buildxすれば直る。
「よつばと」好き
