USBハブの周辺機器が動作不安定になる問題に終わりはくるのか | TINY WORK
https://tinywork.site/2020/12/04/usbhub_trouble/

げェー、これめちゃくちゃ心当たりがある (USB 3 のハブに USB 2 のマイクを繋いでいるが Bluetooth ヘッドセットが異様に切れる)

しかし USB 3 に USB 2.0 の信号を通す場合は物理的に別の線を通しているはずだし、わからんな (3.0 ハブが稼働するだけでもマズいのか？)

This account is not set to public on notestock.

これなぁ、ちゃんとスキーマの議論してデータ蓄積できそうな人が集まれるなら是非とも注力してみたいところではあるんだよな

だいたいの場合、ちゃんとやってても個人規模であるか、大規模ではあるものの wiki や table のようにスキーマを諦めたり平坦だったりするデータかのどちらかなんだよな

いつも思うのが、分類の階層化なしで「一連の『ひぐらしのなく頃に』シリーズを人間に都合よく分類することは可能なのか？」という話で、これへの答えとなる実装を見たことがない

さて mastodon の引越を試みるゆえ、もうそろそろ一時的に鯖を落とします (まだだけど)

む……二重リバースプロキシを許容するとかなり楽になるけど、どうすべきか

とりあえずそっちの方が設定がシンプルになるからやってみるか。オーバーヘッドが許容できなそうなら諦めて1段にして設定ファイルをゴチャゴチャさせよう

や、でもなぁ……ちょっと頑張ればいけるのか？

現状だと一番表の reverse proxy の設定が「所定のフォーマットのデータを食わすとテンプレートを埋めて nginx の設定が吐かれる」みたいな感じの実装になっていて、ところが mastodon は reverse proxy 側にあれこれ設定を要求するのでそこの境界を分離するか乱すかという

個人用の Nextcloud で nginx → Apache → Nextcloud というチェーンは使っているのでそれらしく動くであろうことはわかっているんだけど、 Mastodon はトラフィック量が桁違いのはずなので、どうなるか

よっしゃ復活ッ！！！

というわけで、 mastodon.cardina1.red が物理的に鯖を移動しました (論理的にはそのまま)

設定ミスって redirect loop 発生させたりしたので、リモートからうちへの配送が多少遅延する可能性がある

あと sidekiq のプロセスを分割するのをやめてデフォルトに戻したので、その辺りでもこっちが原因の配送遅延とかが発生するリスクはある (昔よりマシになっていてそうそう詰まったりしないと信じて戻した)

昔はリモート鯖が死んで push が溜まりまくって pull まで詰まるみたいな酷い状況だったからなぁ

や、これは今でもそうである可能性があるんだよな (ダッシュボード確認したら5スレッド全部 push のジョブが詰まってた)

おーっと、 Ctrl-F5 でリロードしたら画像系が全滅してるぞ

no live upstreams while connecting to upstream... ほう？

あーーーーはいはいはい、 intermediate reverse proxy が外に繋がらないようにしてあったのでそれで object storage に繋がらなくなってるのね

Mastodon 標準の docker-compose のコンテナ、 web とか streaming みたいな超汎用のやつだから最前線 nginx-proxy のネットワークに接続したくないんだよな……

はい直った

一応画像ｱｯﾋﾟﾛｰﾄﾞ試しとくか…… (大丈夫そうではあるが)

はいｱｯﾋﾟﾛｰﾄﾞ失敗！！！

Storage server error: execution expired

なんじゃろな

AWS_ACCESS_KEY_ID も AWS_SECRET_ACCESS_KEY も合ってる

execution expired ってのは sidekiq 側のメッセージか？

はいはいわかりました、 web コンテナを外部接続可能なネットワークに入れてなかったから画像アップロードが失敗してるのね

画像ｱｯﾋﾟﾛｰﾄﾞテスト

アップロードはできているようだけど object storage へのリダイレクトがうまくできていない？

むむ、さっき一瞬だけ画像出せるようになっていたのは何だったんだ

あーはい今度こそ完全に理解した

過去弄った docker-compose.yml にコメントが足りてなかったせいでだいぶミスしてしまった

よし、今度こそおｋ

画像ｱｯﾋﾟﾛｰﾄﾞテスト final

はい完璧
引越完了

あとは配送遅延の解消を待つのみ

旧サーバのインスタンスを削除した

@eniehack 要らなそうな雰囲気がしますね。これは最初の admin user を作った直後の設定画面で、メールを受け取らずともここに流されました。
(でもメール鯖は設定したので設定しなかった場合どうなるかは知らず)

nop_thread - NopWyrm
https://bookwyrm.nops.red/user/nop_thread

さて #BookWyrm の鯖を立てたは良いが、 #OpenLibrary とか #Inventaire は日本語の書籍がかなり貧弱なはずなので (実際そばにあった1冊を探してみたが未登録だった)、まず本の登録をどうするか考えねばならない。
BookWyrm に直接登録することもできるしそちらの方が自由度が高そうだが、一度 OpenLibrary や Inventaire (inventaire.io) のような広く共有されたデータベースに登録する方が日本語文化圏での互換サービスの普及には貢献するだろう。

物理今日の調べ物はこれだな

Open Library (openlibrary.org) と Inventaire (inventaire.io)、日本語情報がほぼ皆無でビビる

私が知りたいのは機械可読な書誌情報の管理と共有の話なのに、日本語情報 Open Library は無料で本が借りられるみたいな話しかないし Inventaire に至ってはそもそも言及すらほとんど見付けられない。
日本語の本の登録も少しはあるので、多少はユーザがいるはずなんだけど……

Inventaire 、実は母語が日本語でない人が勉強で読んだ本を登録しているだけでネイティブ日本語話者のユーザは本当にいないのではと疑うレベル

ノベルゲームと電子書籍の本質的な違いについて考えていたんだけど、よほどインタラクティブでもなければ (たとえばミニゲームや QTE とか？) 表面的な違いしか思いつかないし、だったら書籍と同時に (混在させて) 管理できて然るべきでは？ の気持ちが出てきています

ゲームブックなぁ (概念は知っているが実物は見たことない)

そう、選択肢による分岐は古くから小説にも実装済みだし、 e-book ともなればハイパーリンクなどを使って実装もより簡単になるはず。
イラストは挿絵で言わずもがな、音声や動画も電子書籍なら埋め込めてしまうはずで (クライアントが対応しているかはさておき)

であれば、本を管理することを想定している BookWyrm のようなサービスでｴﾖｹﾞを登録して感想を投げたって何もおかしくないし、むしろできて当然では！？ という

ISBN やその他書籍用 ID が必須扱いだったりすると厳しいけど、 ASIN くらいなら用意できるのでどうにか

やっていこうな

そうらしい。
特定の bookwyrm インスタンスに登録された本の情報を他インスタンスから参照できるかは確認してない (できてほしいが)

溺れたニジマス ドラウンドサーモン
#適当

本を読んだとかレビューしたとかのフィードが AP で飛ぶらしいという理解 (ちゃんと使ってないのでまだわからんが)

あとはインスタンスを跨いでユーザのグループを作ったりとか？ (これも試してないのでまだわかっていない)

OpenBD 書誌APIデータ仕様 (v1)
https://openbd.jp/spec/

「hasshohyo…… ﾊｽﾎﾋｮｰって何だ……」となった。愉快 (has 書評 のつもりらしい)

datezeppan (ﾀﾞﾃｾﾞｯﾊﾟﾝ) もとい date 絶版 などなど、見てると頭おかしなってくる

日本語話者としては意図するところはどうにか読み取れるので及第点ではあるだろうけど、もうちょっと、こう……どうにかならんかったのだろうか

受賞情報は jushoujouhou なのに重版は jyuhan なのか、一貫性ないなぁ

This account is not set to public on notestock.

openBD は「データの改変をするな」とか「アップストリームでの削除を速やかに反映しろ」みたいな規約があるっぽくて、オープンあるいは distributed な書誌情報データベースへの結合はしづらいんだよなぁ

たとえば「表記揺れがあるので (こちら側で) 統一した」みたいなのは認められないように読めるし、情報源としてはかなり使いづらい。書誌情報そのものの蓄積を目的としない web サービスに埋め込むためにしか使えなそう

まあ openBD 運営側からしてみれば競合サービスにデータをくれてやるつもりはないということだろうし理解はできるんだけど、だからこそ (ビジネスの都合が明確に出てきているからこそ) あまり頼りにならないというか……

This account is not set to public on notestock.

https://twitter.com/inventaire_io/status/1566739692720193543

ジャパンサーチ
https://jpsearch.go.jp/

Inventaire の中の人から JAPAN SEARCH なるものを教えてもらった

やっぱり国立国会図書館なんだよなぁ

つらいなぁ

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

これ、おかしくなっている箇所や代替の文字の組み合わせで送信先を一意に特定できるようになっていて、画像で晒したことでメールアドレスと SNS アカウントが紐付きます (適当)

This account is not set to public on notestock.

あーあ…

書けば書くほど C 言語に戻りたくなるプログラミング言語、Cプレスプレス

John Regehr's Integers in C https://www.acepace.net/integerQuiz/

難しかった (わかっててなおミスる)

Release 9.0.0 · UltimateHackingKeyboard/firmware
https://github.com/UltimateHackingKeyboard/firmware/releases/tag/v9.0.0

レイヤーが増える！！！

キーボードのァームウェアバージョン上げたら電力不足っぽい挙動でちゃんと初期化されなくなったっぽい、ケーブルが長すぎるのかハブが貧弱なのか……
(それはそれとしてなんで消費電力上がったんだろう、まあいろいろ機能追加されたっぽいのでわからんでもないが)

こうなるってワケ

FTY は factory らしい？

表示された画数で止まっているフェーズを推測できそうなの、 LILO を感じません？ (老並感)

ﾈｯﾂ小説で「僕は呆気にとられた顔をしていた。」(←鏡などを見たわけではない) という一文を読んで、かねてからずっと感じていた違和感について考えたんだけど、一人称の小説で自分の表情について叙述するのって、意図して表情を作ったのでない限り変だよね

「彼は悲しい」はおかしい、みたいな話題があったなというのを思い出したが、あちらは語の意味論の問題であるように思われるのに対してこちらは幾分物理的なニュアンスもあるような

「顔 (表情) というのは一般に視認や触覚等による認識なしに自動的に判定できるものではない」みたいな暗黙の前提がある気がしていて、これは特定の語の意味論というよりはもっと根底にある共通の部分で要請されているのかなと思っただけ

いやそうでもないか、「悲しい」もそれ固有の意味論というよりは内心の感情の表現全般における制約に従っているだけか。となると根底は同じかもしれん

や、これ表情についての制約というよりは「していた」が外界を認識するニュアンスを暗に持っている (ゆえに五感による知覚なしで使われるのはおかしい) と解釈すべきなのか？

日本語なんもわからん、プロ解説してくれ

白昼夢の青写真 - NopWyrm
https://bookwyrm.nops.red/book/1/s/

読書管理で初手ｴﾖｹﾞ新規登録マンと化した