晴れますように！！！

おはようございます、このへんは朝は寒いですね…

うちのアビーくんですよろしくお願いします

ありがとうございます。たいぶ目覚めました！

山形ではよく使われます

As you can see on Wikipedia, temperature in Tokyo is mild in October and getting chilly in November. I think it will be the most comfortable season with a proper outfit there. Kyoto is bit cooler but I don't think it's an issue.

October is bit cloudy in Honshu region because of an autumn rain front, however, not a rainy at all, no issue in my opinion.

If you prefer sight seeing in Kyoto with beautiful autumn leaves, the beginning of November will be a good timing. However, I have to warn your that Kyoto will be fill of tourists both from inside and outside of Japan. I would suggest booking transportations and a accommodations earlier.

Hope it helps!

😞

内側にもダートトラックあるんですかね？面白いですね。

Hope none of them got hurt...

ぼくが若かった頃は結城浩せんせいが啓蒙してて、建築の方もデザインパターンの方もわりと有名でした。

No meaning for sticking around being a human

最近はもっぱらストリートファイター６です！

この仕組みが課金なく使えるのすごいですよね…

どちらも静的ファイルだと思います。いまgithub pages の仕様をもう一度確認したのですが、github actions を使って、githubの仮想マシン上でhugoや他のサイトジェネレータを走らせることができそうです。なので、私がやってる程度であれば、どちらでも差はなさそうです。

SSGのhugoを使う場合、github pagesには、ビルドしたあとのhtmlをアップロードする必要がありました。結果的に、ソースと出力結果を両方管理する必要がありました。

gitlab.com ではpushしたソースを、gitlab.com 側でビルドしてくれる機能が最初から備わってて、特に準備なしにソースの管理のみで済む環境を作れます。

違いはそれくらいですが、ソースの管理だけで済むのはスッキリしてていいな…と思ってそちらを使い続けています。気にならない人には気にならない違いかもです。

もうちょっとフレームワークのお作法把握するといいかもですね。

ぼくもちょっと前にwindows core audio で使うデバイス列挙オブジェクトの取得で似た問題ではまって、結論は結局列挙オブジェクトのclass id はゼロでオーケーでした。リファレンスにも書いてなくて、作法は知ってる人に聞いたり、マイクロソフトに問い合わせたりしないとわからないように思いました…。

テキストサービスを登録するプロセスが別にあってそこでclassidが既知になるような動作です？

たしかにわかりにくいですね…。

はい。Nostrのpubkey は後ろの32バイト分です。

圧縮形式のpubkeyは33バイトだと思います。先頭の1バイト目はpubkeyの偶奇に応じて取る符号でpubkeyのy座標と紐づく情報、後ろの32バイトがpubkeyのx座標を表す整数値のはず。たぶん。