あたまがおかしい
しかしこの室温で電気ヒーターを使うのもかなり癪に障るというか、これから4〜5ヶ月使い続けることになるというのもちょっと困る。計算できないヒーターなんて……
「まあ呆れるザマスよ」
「死ぬでガンス」
「アンガー」
「まともに怒りなさいよ!」
……という電波を受信したが、絶対似たようなことを以前にも考えたことがあるはず
C コンパイラ書いてみたい気持ちはかなりあるが、同時に、 C とかいう未定義動作の雨あられな言語のコンパイラを書くの不毛すぎてかなり嫌という気持ちも強く、今のところ後者が勝っている
でも言語仕様としては C99 くらいが手を付けるには丁度良さそうではあるんだよなぁ……
@yakumo_izuru 私が立てていたのは潰してしまいました。ほとんど新規投稿がなく私も使っておらず、それでいて外国語スパムがたまにあって放置もできなかったので……
未定義動作山盛りが嫌というよりは、未定義動作かどうかを検査することが難しい領域がそこかしこに散らばっているのが嫌、というのが正確かもしれない。わかっているのに検査できないもどかしさというのは、落とし穴を見てフェンスを置けないもどかしさに近い
This account is not set to public on notestock.
布団で横になってるだけで喉が渇いて仕方ないのが険しいな。かといってこの寒さでこれ以上水を飲んでも、眠りを妨げる尿意に襲われるだけだし……
いっそ油を飲んで喉を乾燥から保護するか (バカ)
This account is not set to public on 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/
ドキュメント書くサービス、書いてくに当たってタイトルが変わることは普通にあるからそれならnotionみたいにURLはランダムなIDのほうがいい気がするな
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 がバカなのが悪い))
“ペタライトに含まれるリチウム”
EVシフトで「土鍋」の生産がピンチ 背景にリチウム争奪戦 | 毎日新聞
https://mainichi.jp/articles/20230915/k00/00m/020/392000c
ほぼ同意だけどURLだけだとなんもわからんのも不便なので、ID+タイトルの要約英文になっててタイトルの(略)に部分は鯖側で無視するみたいな形式のが流行ってほしい><
例えばパラメータの方にタイトル入れるとか><
そうすればどういうタイトルの時に広まったURLであるかも判別出来るかも><(例えばSNSでシェアした人が認識してた時のタイトルといまは趣旨が違うとか><)
それは URL ではなくその外側の仕事だし (つまりタイトル+URL で投げられるべき)、なんなら記事のバージョン管理あたりのトピックかもしれない (それこそ wiki の履歴ビューアとか WebArchive とか)
ID に ID 以上の意味をもたせるとだいたい弊害の出る形で abuse されるので、そこは徹底する必要がある
時系列ソート可能な性質が欲しければ LUID みたいなのを使う手はあるけど、あれもあくまでID 文字列であって、日時を取り出せるのは副作用でしかない (し、実際人間が目視で取り出せる想定にはなっていない)
/yyyy/mm/dd/slug みたいに切るのは、どちらかというと名前空間を分割しておくことで命名スキームの変更に耐えられるかもしれないというのと、あとは /yyyy とかで一覧を取り出せる (index.html の index 要素を原義通り提供する) などのメリットも見込んでのことで、本来こういう形で日時が ID に構造化されて出てくるのは健全ではないところがあると思っている
理想で言えばそれはそうだけど、SNSとか、あとブログ記事の参考文献の欄とかでリンクだけはる人がわりといるので、そういうのの時にURLにタイトルあると便利かもって><
タイトルを含むことで得られる価値、ID 破壊リスクや一意性喪失リスクや ID と名前のミスマッチリスクを呑み込むには値しない (そりゃ検索エンジンだけを考えるなら canonical をメタデータで指定すれば統合はできるが……ブラウザのブックマークとかはどうする?)
Amazon がタイトルを 実効性のない形で URL に含むしぐさやってるけど……あれを望ましいとは思わないです
?foo=bar みたいなやつは ID 機能の一部と見做されるので # frag みたいなフラグメント指定しかその用途では使えないけど、フラグメントは文書の特定部分を指す用途で使われているので……
?foo=bar (query 部) をトラッキングとか流入元指定に使ってるの、特定サービスがそういうのを無視するという仕様を持っているという前提で個別に許されていると考えるべきで、一般化するとまあまあ邪悪だし真似するべきではないです (文字通りトラッキングに使えるし)
あれはあれで ID というよりは階層指定で住所と被る部分があるからちょっと違うような……
AmazonのURLに対してオレンジがしてるのと同じで、配慮する人はゴミ部分カットしてタイトルを併記して、配慮しない人はタイトル併記せずURLのゴミ部分カットもしないのでURLのパラメータにタイトル判別文字列が残って便利かもって><;
や、これはもう単なる ID 破壊なので方法には関係ないけど、 URL に含めてしまうことであたかもタイトルが対象指定において本質的であるかのような印象を与えてしまうのがよろしくない。本当は全く関係ないのに。
URI を住所に喩えるのも本当はちょっと違うんだけど、まあそれは今は考えないことにしよう……
URLの使われ方の問題は、住所はどこかの時に郵便番号だけ書かれても郵便局員じゃなきゃそんなの暗記してないし一目で見てどこだかわかんねーよって問題なわけで、「住所を書かないとどこの話だかわかんないだろ?><;」って言っても頑なに郵便番号だけ書く馬鹿が現れたら、馬鹿がコピペするときだけ住所がわかりやすい文字列が含まれる郵便番号文字列が必要になる・・・みたいなことをいってる><
そもそも URL が「どこであるか」を識別するのは人間の仕事ではない (アプリケーションの仕事である) のだから、人間にどこであるかをわからせる必要があるなら ID と別に書けという話ですね (つまり タイトル+改行+URL とかにすればよろしい)
問題の半分以上は、タイトル+改行+URL のような形でコピーさせてくれないブラウザやアプリの共有機能に責任がある。
ブラウザならアドオンがいくつもあるので改行挟むなり markdown 形式にするなり好き放題できるが。
アプリケーションがリソースを識別するためのコードを目的外利用して「人間が一目みてそれが何なのかを察せられるようにする」、これを abuse といいます
1歳ぐらいの女の子抱いた女性はねられ 女児死亡 千葉 四街道 | NHK | 千葉県 https://www3.nhk.or.jp/news/html/20231114/k10014257041000.html
これがたとえば
「1歳ぐらいの女の子抱いた女性はねられ 女児死亡 〒284-0044」
ってタイトルで
「13日午後5時半ごろ、〒284-0044で1歳ぐらいの女の子を抱いていた母親とみられる女性が道路を横断していたところ...」
って記事だったらどこだかわかるか?><;
郵便番号いちいちググらないとわかんないでしょ?><;
これも全く同じことを逆から言ってるだけで、「郵便物の配達先を郵便局アプリケーションが識別するためのコード」を人間が地域を察するのに使おうとするのが目的外利用であって、そういう使い方をするやつが全面的に悪い
URLだけじゃ内容がわからない場面でURLしか貼らない馬鹿がやってるのはこういう記事書いてるのと同じでしょ?><
って言ってる><
まさしくその通りで、「馬鹿のために構造を歪めて全ユーザが弊害を呑むべきほどのことなのか」という話で、私はそうは思わないのでシステムを歪めるより馬鹿を非難して調教するなり文献列挙の何たるかを学校で教育しろ、という立場です
先の話に乗るなら、郵便物に「〒284千葉県-0044」と書く慣習を (必須でないとしても) 推奨するのはおかしいということ
それはそうだけど、実際にそういう馬鹿が大量にいるんだから、機械的に対処出来る(道具側の仕様で対処出来る)のならそうすべきでは?>< って言ってる><
それをしないで「人間がちゃんとすればいい」ってするのは、らりおさんがよく嫌ってる人間への過剰な期待であろうし、安全装置を省いて運用でカバーしてコケまくる人間依存の安全対策と同じかも><
そもそも URL にオプショナルでタイトルを含めたところでいかなる検査もされないとすれば、最初から信用できないし、むしろ悪意の入り込む余地を残すだけ。
「〒284大阪府-0044」と書かれていたら無頓着な人々が騙されるばかりか、「この記事が書かれたときは 284 は大阪府だったのかなぁ」などと余計な気を回す人まで騙されかねないわけで、どう考えても害のほうが大きい
タイトルと ID を完全に別々に扱えば、少なくとも「ID は当時有効で機能するものだったはず、タイトルは付随する情報なのでミスマッチがあればタイトル側が却下される」というのが明確になる。権威とそうでないものをちゃんと分離できる
タイトルはリソースへのナビゲーションに使われないし、人間もナビゲーションに使われると想定しないので。言ってみれば「変なことになっていてもおかしくない領域」としてちゃんと (いくらか) 安全に分離されている
ID が identifier としての機能以上の何も提供しないというのは、そういう「汚染からの防護」に有用だし、汚染源を敢えて取り込むような慣習を促進すべきでないということです
うーん><;
でも、パラメータにタイトルがあれば、「タイトルが変更されています」とか「不正に加工されたURLよりアクセスされています」とか鯖側で対策する事も可能になる面でも安全性が高まってると思うんだけど><;
それって一般的な web サーバの機能として持つべきか……?
そもそも「タイトル」と言ってもタイトルバーに出る文字列と記事そのもののタイトルは違ったりするし、さらに content negotiation によってクライアントごとに言語や表示フォーマットが異なる可能性があるし、そういう諸々の複雑な “人間向け” 要件を ID 内に取り込むのはだいぶ余計な複雑さの導入に見えるけど
オレンジ的にはタイトルの要約が望ましいと思うし、なおかつ英語が望ましいと思ってる><
あと、IDそのものじゃなくスクリプト言語でいうコメントに近い存在だと思ってる><
うーん……
コメントならそれこそ ID と別に並べて書いてしまえばいいわけで、やっぱり「ブラウザなり何なりが標準でタイトルも付加する」形式の方がストレートに見えるなぁ。
Android の共有機能とかは実際にタイトルと URL の組を受け渡しすることを標準的な手法として実現しているわけで
「PC でも Android 等の共有機能みたいにタイトルをペアにする方式を標準で提供しろ」という方向に行くのが一番健全な気がしますね。 ID の構造や意味を弄るよりは。
実際、ロケーションバーから URL を全コピーして他所で貼り付けるというのはあまり良い体験ではない。たまに失敗して日本語部分が URL encode されてない人とかいるし。ボタンポチーとかで実現されるべきよね
タイトルの要約をパラメータに含めるのを標準化したら、ちゃんとそういう対策をとってる場面では自動的にカットするようにも出来るかも><
それはむしろ「別の用途で使われているかもしれない構造を外部で第三者が勝手に『問題ないだろ』として改変する」ことを推奨しているわけで、 ID どころの騒ぎではないのでは……?
URL (というよりか URI) が **HTTP/S においては** ID ばかりでなくルーティング情報としても機能しているから「ルート中に無意味な部分があってもナビゲーションに使われなければ問題ない」という発想になってしまうのかもしれないが、 URI 一般にそれを期待すべきでないし、 HTTP でのみ URI 標準から異様に乖離した非ID文字列としてのエセ URI を使ってほしいとも思わない
突如とある文字列がコメントを示す予約語になるわけだからそれはそう><;
もし新規設計するなら「人間フレンドリーな文字列 + 純粋な識別子」というデータ構造を用意するだろうし、「識別子中に人間用非規範データを混ぜ込む」という手はやっぱり取らないと思う
つまり既存の URL 意味論との互換性云々を無視したとしても、混ぜ込むのは健全な設計であるとは思わないし可能な限り避けるべきバッドプラクティスだと思う
これは私はちょっとだけ違う捉え方をしていて、「セクションと記事の区切りはどこにある」というのと「情報のまとまりの『親』が単一であることを URL や木構造ナビゲーションは要求するが、本来は情報の関係性ってグラフだよね」というのがある
「おいしい食事」記事の中に「おこめ」があるかもしれないが、それが埋め込まれて見えているのは本質的な性質ではなく、「おいしい食事としてのおこめ」という情報が「おいしい食事」情報 “でもある” という関係を埋め込みで表現した、ということだと思うのよね。
で、「おいしい食事としてのおこめ」は同時に「おこめ」情報 “でもある” し、また「生活の買い物」情報 “でもある” かもしれないし、さらには「俺のお気に入り」情報 “でもある” かもしれない。
ほらもう木構造では厳しくなってきた
つまり「セクションが一方的に “記事” に従属しているように見えてしまうが、そもそもセクション自体が単体で記事レベルのアイテムとして成立しうるし、それが単にリンクされ埋め込み表示されていると捉えるべきではないか? (そして大抵のアプリはそういうモデリングをできていない)」というのと、「アイテムがひとつの親アイテムの下にあるという木構造はそもそも情報の関係性のモデリングとしてあまりに貧弱すぎるし、それがサブアイテムの切り出しや整理を阻害しているのではないか?」という感じで世界を見ています
よくわかんないけど、場所を示す文字列がどういうフォーマットであろうが、その文字列の中に意図の情報が含まれていないと、場所(URLならばリンク先)が変化してしまうと意図の解釈がおかしくなるって話だと思うんだけど><
さっきの記事の言葉で言うなら、「脱線」はそもそも特定の記事という最小単位パッケージに対する追加ではなく、独立した記事を “埋め込む” ことによって実現される (たとえば『ラーメンばかり食っていると危ない』という小さな “記事” を『ラーメン』記事に “埋め込む” ことでインラインに表示する) べき、ということ
後から「分割」する必要が生じるのがそもそも自然ではなくて、最初から「別物だが表示上は一体化できる」くらいの距離感であるべきなんですよ。まあ実装やリンク設計がダルそうというのはもちろんそうなんですが……
物事をノードとリンクというプリミティブで捉えると、一瞬でリストや木で足りなくなって有向非巡回グラフを使うことになるんですよね。
そんで次はリンク自体をノードとしてリンク対象にしたくなっていくと……
ようこそ RDF の世界へ。
結局どういう構造でも文字列に意図が入ってないと同じなので、意図が含まれる文字列になってるか否か以外はあんまり関係無さそうな気が・・・><
意図にせよなんにせよ、 canonical form が存在しない情報への一意なラベルとして ID というものが存在しているわけなので、 ID は一意なラベル以上の何かであることを期待すべきではないし、もし何でもいいから別の情報が入っていてほしいならそのためのフォーマットを発明すべき
たとえば「ISBN や URL だけでは不十分だから BibTeX の .bib フォーマットを使う」みたいなのはそういうことだと思うんだけど
BibTeX 記法を SNS なり HTML なりに書いてそれっぽいリンクにならないのはシンプルに処理系がそういうのに対応していないからであって、 BibTeX の記法がリンクとして使えないことを意味しているわけではない。既存フォーマットを abuse せずにちゃんと処理系で適切な表現を出すことを考えるべき
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.
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.
OAuth “認証” についてはいろいろ言われてたりしましたね……今となっては何もかもがなつかしい
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.
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.
ネット小説七不思議: 異世界感を出そうとしてひねり出した策が、「林檎を『アプル』と呼ぶこと」
その程度のよわよわ強度の取って付けた説得力 ZERO な変換を入れるくらいなら、最初から「林檎」と呼んだ方がだいぶマシだと思う
これが薩摩芋とか言われると薩摩ってどこだよとなるけど、長芋とか山芋みたいなジェネリックな要素のみから構成されている名詞をわざわざ弄る必要あるか?
「林が存在しない異世界だから林檎という果物もない」とかならわかるけど…… (ほんまか)
べつにそれだって林檎という漢字表記が異世界において強いられていることを必ずしも意味していないし、やっぱり雑念とノイズを注入してまで避けるには値しないどうでもいい細部でしょ
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.