恒例の気絶してた

22℃なのに体の芯から冷えてる、こりゃ体調崩すかもしれんなぁ

窓際が14℃になってて絶望

しかしこの室温で電気ヒーターを使うのもかなり癪に障るというか、これから4〜5ヶ月使い続けることになるというのもちょっと困る。計算できないヒーターなんて……

やはりサーバで LibreOffice か何かを焚くのが一番なのか？

とりあえずあたたかい間食にするか……

間食とは言うが3食目なので実質晩飯

筋トレか何かで基礎代謝を上げるべし、まあそういうことか……

運動の前にストレッチをしないとお話にならないが……

「まあ呆れるザマスよ」
「死ぬでガンス」
「アンガー」
「まともに怒りなさいよ！」

……という電波を受信したが、絶対似たようなことを以前にも考えたことがあるはず

https://mastodon.cardina1.red/@lo48576/106879641939859683

2年前かぁ

C コンパイラ書いてみたい気持ちはかなりあるが、同時に、 C とかいう未定義動作の雨あられな言語のコンパイラを書くの不毛すぎてかなり嫌という気持ちも強く、今のところ後者が勝っている

でも言語仕様としては C99 くらいが手を付けるには丁度良さそうではあるんだよなぁ……

C11 は色々ダルいこと増えてそう (_Generic とか？)

@yakumo_izuru 私が立てていたのは潰してしまいました。ほとんど新規投稿がなく私も使っておらず、それでいて外国語スパムがたまにあって放置もできなかったので……

https://mastodon.cardina1.red/@lo48576/107389842196567243

未定義動作山盛りが嫌というよりは、未定義動作かどうかを検査することが難しい領域がそこかしこに散らばっているのが嫌、というのが正確かもしれない。わかっているのに検査できないもどかしさというのは、落とし穴を見てフェンスを置けないもどかしさに近い

このアカウントは、notestockで公開設定になっていません。

性癖 (誤用) が生えてくる瞬間だ

/dev/neru

#今すぐ寝ることで救える命があります

布団で横になってるだけで喉が渇いて仕方ないのが険しいな。かといってこの寒さでこれ以上水を飲んでも、眠りを妨げる尿意に襲われるだけだし……
いっそ油を飲んで喉を乾燥から保護するか (バカ)

このアカウントは、notestockで公開設定になっていません。

言うて我々も習近平をシーチンピンと呼ばずシューキンペイと呼んでたりしたわけで、差別と呼ぶのは簡単かもしれないが肉体に染み付いた動作特性を無かったことにするのも極端だとは思うんだよな。もちろん何事も程度の問題ではあるだろうが……

外国人の名前、正しく発音できる自信ないし、それどころか正しく聞き取れる自信がそもそもない

ゴド！？

天気予報を温湿度計代わりに使うの、不思議な遠回りを感じる (古くなった完璧でない未来予測データを敢えてリアルタイム観測値より優先して参照している)

世界初の25.3型“湾曲”E Inkモニター - PC Watch
https://pc.watch.impress.co.jp/docs/news/1546763.html

> E Ink特有の遅延を極限まで抑えることができ、動画や漫画の視聴/閲覧、オンライン受講などがスムーズに行なえるという。

誇張でないならすごいが……

> 価格はオープンプライスで、実売予想価格はそれぞれ31万8,000円前後、29万8,000円前後の見込み。

価格もすごい

【AA】アスキーアートクイズ選手権 ｵﾓｺﾛ場所【おぼえていますか】 | オモコロ
https://omocoro.jp/kiji/421056/

wiki システムとか markdown プロセッサにありがちな、セクション名をナイーブに id や slug にする実装、現実見えてないし全部廃れろと結構強めに思ってる

有用なドキュメントを作るために心掛けたいこと - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2018/12/24/creating-useful-document/#stable-permalinks-per-sections

ワイのﾌﾞﾖｸﾞの id は自前で指定しているのでタイトルの変更を生き延びられる (完全に outdated になる可能性もあるが、そこまで大きく変化したらそもそも別コンテントとも言えるし別の id を振り直すのもあり)

bookstack という実装などは WYSIWYG モードだとセクション id が勝手に振られて以後はそれを維持みたいになっているみたいで、ひとつの正解だなと思っている
(ところで markdown モードにすると id が欠落して毎回振り直しされるのはだいぶクソなんですがそれは…… (CommonMark がバカなのが悪い))

それは URL ではなくその外側の仕事だし (つまりタイトル+URL で投げられるべき)、なんなら記事のバージョン管理あたりのトピックかもしれない (それこそ wiki の履歴ビューアとか WebArchive とか)

ID に ID 以上の意味をもたせるとだいたい弊害の出る形で abuse されるので、そこは徹底する必要がある

時系列ソート可能な性質が欲しければ LUID みたいなのを使う手はあるけど、あれもあくまでID 文字列であって、日時を取り出せるのは副作用でしかない (し、実際人間が目視で取り出せる想定にはなっていない)

/yyyy/mm/dd/slug みたいに切るのは、どちらかというと名前空間を分割しておくことで命名スキームの変更に耐えられるかもしれないというのと、あとは /yyyy とかで一覧を取り出せる (index.html の index 要素を原義通り提供する) などのメリットも見込んでのことで、本来こういう形で日時が ID に構造化されて出てくるのは健全ではないところがあると思っている

それは徹底してそういう人に全責任を押し付けるべき

タイトルを含むことで得られる価値、ID 破壊リスクや一意性喪失リスクや ID と名前のミスマッチリスクを呑み込むには値しない (そりゃ検索エンジンだけを考えるなら canonical をメタデータで指定すれば統合はできるが……ブラウザのブックマークとかはどうする？)

Amazon がタイトルを 実効性のない形で URL に含むしぐさやってるけど……あれを望ましいとは思わないです

?foo=bar みたいなやつは ID 機能の一部と見做されるので # frag みたいなフラグメント指定しかその用途では使えないけど、フラグメントは文書の特定部分を指す用途で使われているので……

?foo=bar (query 部) をトラッキングとか流入元指定に使ってるの、特定サービスがそういうのを無視するという仕様を持っているという前提で個別に許されていると考えるべきで、一般化するとまあまあ邪悪だし真似するべきではないです (文字通りトラッキングに使えるし)

あれはあれで ID というよりは階層指定で住所と被る部分があるからちょっと違うような……

utf8=✓ などもある

でも Amazon が ASIN を別物に使いまわしたら？

や、これはもう単なる ID 破壊なので方法には関係ないけど、 URL に含めてしまうことであたかもタイトルが対象指定において本質的であるかのような印象を与えてしまうのがよろしくない。本当は全く関係ないのに。

住所に「消防署の方から来ました」と入ってるようなもんですよ (?)

URI を住所に喩えるのも本当はちょっと違うんだけど、まあそれは今は考えないことにしよう……

そもそも URL が「どこであるか」を識別するのは人間の仕事ではない (アプリケーションの仕事である) のだから、人間にどこであるかをわからせる必要があるなら ID と別に書けという話ですね (つまり タイトル+改行+URL とかにすればよろしい)

問題の半分以上は、タイトル+改行+URL のような形でコピーさせてくれないブラウザやアプリの共有機能に責任がある。
ブラウザならアドオンがいくつもあるので改行挟むなり markdown 形式にするなり好き放題できるが。

アプリケーションがリソースを識別するためのコードを目的外利用して「人間が一目みてそれが何なのかを察せられるようにする」、これを abuse といいます

これも全く同じことを逆から言ってるだけで、「郵便物の配達先を郵便局アプリケーションが識別するためのコード」を人間が地域を察するのに使おうとするのが目的外利用であって、そういう使い方をするやつが全面的に悪い

まさしくその通りで、「馬鹿のために構造を歪めて全ユーザが弊害を呑むべきほどのことなのか」という話で、私はそうは思わないのでシステムを歪めるより馬鹿を非難して調教するなり文献列挙の何たるかを学校で教育しろ、という立場です

先の話に乗るなら、郵便物に「〒284千葉県-0044」と書く慣習を (必須でないとしても) 推奨するのはおかしいということ

そもそも URL にオプショナルでタイトルを含めたところでいかなる検査もされないとすれば、最初から信用できないし、むしろ悪意の入り込む余地を残すだけ。
「〒284大阪府-0044」と書かれていたら無頓着な人々が騙されるばかりか、「この記事が書かれたときは 284 は大阪府だったのかなぁ」などと余計な気を回す人まで騙されかねないわけで、どう考えても害のほうが大きい

タイトルと ID を完全に別々に扱えば、少なくとも「ID は当時有効で機能するものだったはず、タイトルは付随する情報なのでミスマッチがあればタイトル側が却下される」というのが明確になる。権威とそうでないものをちゃんと分離できる

タイトルはリソースへのナビゲーションに使われないし、人間もナビゲーションに使われると想定しないので。言ってみれば「変なことになっていてもおかしくない領域」としてちゃんと (いくらか) 安全に分離されている

ID が identifier としての機能以上の何も提供しないというのは、そういう「汚染からの防護」に有用だし、汚染源を敢えて取り込むような慣習を促進すべきでないということです

「汚染」は事故で発生することもあれば悪意で発生することもある

それって一般的な web サーバの機能として持つべきか……？
そもそも「タイトル」と言ってもタイトルバーに出る文字列と記事そのもののタイトルは違ったりするし、さらに content negotiation によってクライアントごとに言語や表示フォーマットが異なる可能性があるし、そういう諸々の複雑な “人間向け” 要件を ID 内に取り込むのはだいぶ余計な複雑さの導入に見えるけど

うーん……
コメントならそれこそ ID と別に並べて書いてしまえばいいわけで、やっぱり「ブラウザなり何なりが標準でタイトルも付加する」形式の方がストレートに見えるなぁ。
Android の共有機能とかは実際にタイトルと URL の組を受け渡しすることを標準的な手法として実現しているわけで

「PC でも Android 等の共有機能みたいにタイトルをペアにする方式を標準で提供しろ」という方向に行くのが一番健全な気がしますね。 ID の構造や意味を弄るよりは。

実際、ロケーションバーから URL を全コピーして他所で貼り付けるというのはあまり良い体験ではない。たまに失敗して日本語部分が URL encode されてない人とかいるし。ボタンﾎﾟﾁｰとかで実現されるべきよね

それはむしろ「別の用途で使われているかもしれない構造を外部で第三者が勝手に『問題ないだろ』として改変する」ことを推奨しているわけで、 ID どころの騒ぎではないのでは……？

勝手に改変される identifier、これほど信用できないものもない

URL (というよりか URI) が **HTTP/S においては** ID ばかりでなくルーティング情報としても機能しているから「ルート中に無意味な部分があってもナビゲーションに使われなければ問題ない」という発想になってしまうのかもしれないが、 URI 一般にそれを期待すべきでないし、 HTTP でのみ URI 標準から異様に乖離した非ID文字列としてのエセ URI を使ってほしいとも思わない

もし新規設計するなら「人間フレンドリーな文字列 + 純粋な識別子」というデータ構造を用意するだろうし、「識別子中に人間用非規範データを混ぜ込む」という手はやっぱり取らないと思う

つまり既存の URL 意味論との互換性云々を無視したとしても、混ぜ込むのは健全な設計であるとは思わないし可能な限り避けるべきバッドプラクティスだと思う

これは私はちょっとだけ違う捉え方をしていて、「セクションと記事の区切りはどこにある」というのと「情報のまとまりの『親』が単一であることを URL や木構造ナビゲーションは要求するが、本来は情報の関係性ってグラフだよね」というのがある

「おいしい食事」記事の中に「おこめ」があるかもしれないが、それが埋め込まれて見えているのは本質的な性質ではなく、「おいしい食事としてのおこめ」という情報が「おいしい食事」情報 “でもある” という関係を埋め込みで表現した、ということだと思うのよね。
で、「おいしい食事としてのおこめ」は同時に「おこめ」情報 “でもある” し、また「生活の買い物」情報 “でもある” かもしれないし、さらには「俺のお気に入り」情報 “でもある” かもしれない。
ほらもう木構造では厳しくなってきた

つまり「セクションが一方的に “記事” に従属しているように見えてしまうが、そもそもセクション自体が単体で記事レベルのアイテムとして成立しうるし、それが単にリンクされ埋め込み表示されていると捉えるべきではないか？ (そして大抵のアプリはそういうモデリングをできていない)」というのと、「アイテムがひとつの親アイテムの下にあるという木構造はそもそも情報の関係性のモデリングとしてあまりに貧弱すぎるし、それがサブアイテムの切り出しや整理を阻害しているのではないか？」という感じで世界を見ています

「ページの『意図』」がそもそも変異しうる、という話では？

> DB上のページIDと、ページ内容が脱線していく事がある

さっきの記事の言葉で言うなら、「脱線」はそもそも特定の記事という最小単位パッケージに対する追加ではなく、独立した記事を “埋め込む” ことによって実現される (たとえば『ラーメンばかり食っていると危ない』という小さな “記事” を『ラーメン』記事に “埋め込む” ことでインラインに表示する) べき、ということ

後から「分割」する必要が生じるのがそもそも自然ではなくて、最初から「別物だが表示上は一体化できる」くらいの距離感であるべきなんですよ。まあ実装やリンク設計がダルそうというのはもちろんそうなんですが……

意図にせよなんにせよ、 canonical form が存在しない情報への一意なラベルとして ID というものが存在しているわけなので、 ID は一意なラベル以上の何かであることを期待すべきではないし、もし何でもいいから別の情報が入っていてほしいならそのためのフォーマットを発明すべき

たとえば「ISBN や URL だけでは不十分だから BibTeX の .bib フォーマットを使う」みたいなのはそういうことだと思うんだけど

BibTeX 記法を SNS なり HTML なりに書いてそれっぽいリンクにならないのはシンプルに処理系がそういうのに対応していないからであって、 BibTeX の記法がリンクとして使えないことを意味しているわけではない。既存フォーマットを abuse せずにちゃんと処理系で適切な表現を出すことを考えるべき

XLink を思い出して涙を流しています、いま

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

それはどちらかというと認証と認可の問題な気が……

このアカウントは、notestockで公開設定になっていません。

まあ「パスワード忘れたんスけど」とか「メアド消えたんスけど」に対して「認証通ってから問い合わせしてね〜」などとは答えられないなどの事情はあるだろうけど……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

OAuth “認証” についてはいろいろ言われてたりしましたね……今となっては何もかもがなつかしい

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

マラーナのナララナのアランラナがビージャでアランラカラリ……

バックライトが壊れて……真っ暗イト！w

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ネット小説七不思議: 異世界感を出そうとしてひねり出した策が、「林檎を『アプル』と呼ぶこと」

その程度のよわよわ強度の取って付けた説得力 ZERO な変換を入れるくらいなら、最初から「林檎」と呼んだ方がだいぶマシだと思う

これが薩摩芋とか言われると薩摩ってどこだよとなるけど、長芋とか山芋みたいなジェネリックな要素のみから構成されている名詞をわざわざ弄る必要あるか？

「林が存在しない異世界だから林檎という果物もない」とかならわかるけど…… (ほんまか)

べつにそれだって林檎という漢字表記が異世界において強いられていることを必ずしも意味していないし、やっぱり雑念とノイズを注入してまで避けるには値しないどうでもいい細部でしょ

このアカウントは、notestockで公開設定になっていません。

『レターパックで大麻送れ』はすべて罪です。

このアカウントは、notestockで公開設定になっていません。

スレイヤー……

++num_炎の壁の魔法が「ファイヤーウォール」などと呼ばれている作品

このアカウントは、notestockで公開設定になっていません。