ブログ記事とは何であってどのような構造を持つべきなのかずっと考えている

本質的には日時に紐付いたものなのかなと思ったけど、では具体的に何の日時に紐付いているのかと問われるとちょっと難しい

一般のシステムでは公開日に紐付けることが多いが、内容の文脈はどちらかというと公開日よりも執筆開始日に基いており、あるいは記事が特定の現実の出来事を参照したものならその出来事の日時や区間 (の始点) に紐付くべきである可能性もある。

日時に紐付かないがしかしテーマを追って随時更新するとも限らない情報も、ブログで公開することは可能だが、それは本質的にはブログではない別の何かと考えるべきなのか、とかも

そもそも状況の変化への追従の姿勢が記事の形態の分類に影響すべきなのか否かも曖昧な気がしており、実装の手が完全に止まっている

ブログだとどうしても日時が (URL の一部などとして) 紐付いてしまうから「追記」とかの形で誤魔化しそうになるけど、それを許容するならべつにブログ記事が考えや出来事の snapshot 的なものであったりすると捉えるべきでもないということになる

私個人の運用で言えば、ブログ記事への追記は内容が outdated になったことへの警告や訂正っぽい意図でのみ使うようにしているけれど

ちゃんといい感じの型を作らないと自分でメンテする気が失せてしまうので

いちど区別しない形でやってみるかなぁ。ブログなんて概念はなかった。

実際のところ、動的な CMS を使っているのでもなければブログかそうでないかみたいな分類には大して意味がない気がする一方で、世の static site generator を見ていると「明らかに日時に紐付いた記事群の公開に特化してるだろ」というものが多数派なのもまた事実であり

しかし日記記事の ID としてソートで滅茶苦茶になる UUID を使うというのもかなり違和感のある選択ではあるんだよなぁ (やっぱり ULID か？)

しかし少なくとも一部の記事が本質的に unsortable であるという仮定のもとで日時との紐付けの非強制を正当化するのだから、そこに「ID をそれっぽくするだけだから！ 内容と日時の結合を示唆するものではないから！！」と建前を用意して ULID を使ったところで謎の日時が湧いてきていることに変わりはないし……

……とか考えてると、やっぱり sortable なものとそうでないものはカテゴリを分けた方が (少なくとも ID の生成規則や名前空間は分けた方が) いいのではないか、みたいな気持ちになってくるんだよなぁ

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

そして最初の疑問に戻る。記事が日時に紐付いているとは一体どういうことなのか。

ｴｰｺﾞぢからがあればスパッとそれらしい命名して分離して解決となったのかもしれんが

いつだって命名に苦しんでいる

は？？？？ chelsea 死んでるじゃん

いや違うわ、 PANA session のアップデートに死んでる。電子レンジか何かを使うタイミングが悪くてセッション切れてしまったやつか

Retry PANA auth later if failed (#1) · イシュー · NOP Thread / house-exporter · GitLab
https://gitlab.com/nop_thread/house-exporter/-/issues/1

立てるだけ立てた。直すかは知らん

まったく怖いなぁ。外形監視で室温メトリクスと電力メトリクスは別々に監視させるか

ルール追加した

SNS のアカウント名が今季アニメタイトルの構文になっているオタクを見ると、俺たちの平成という感じがして安心する (悪口ではない)

あーあーあー思い出してきた、もともと「随時更新の記事でない場合は (あるいは随時更新であっても) 別の記事によって obsolete にすることはあるし、その場合明示的に時刻に紐付いておらずとも明確に因果関係による順序が発生する」みたいなことを考えていたのだった

あらゆる記事が “後発” の記事によって obsolete にされうることを考えるのであれば、すべての記事の間に暗黙に順序があってもそこまでおかしくはない (よって ULID を全体で使おう) みたいなことを考えていた時期があったはず。

じゃあ “後発” の snapshot 的記事が随時更新の記事によって obsolete にされる可能性はないのかというと、まああるんだけど……

本質的に lexicographical order が全順序であることが大いに問題なんだよな。どうしようもない。どこかで妥協するしか……

何かあったときのことを考えるとなぁ。名前空間分けたいなぁ……

The Open Graph protocol
https://ogp.me/

OGP で og:image が required property なのマジで勘弁してくれの気持ちが強い

もちろん現実にはあらゆるコンテンツが扉絵やサムネイル画像を用意するのは明らかに無理があるため、 og:image はしばしば用意されないことがあり、多くの展開器もそのようなページに対応しているが……本来であれば規格が og:image を optional とするべきであることは明らかだ

og:image のないページの代表例 (?) として Wikipedia などが挙げられる (e.g. <https://en.wikipedia.org/wiki/Garden-path_sentence>)

なんなら Wikipedia、 og:url さえ出力してないからな。 rel="canonical" は吐いてるのに。

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

今気付いたけど og:article ですらなくて og:website なのか……

枕元の湿度の振れ幅が20%から80%まで幅広い。耐久試験じゃあるまいし……

Release Next-L Enju Leaf 1.4.0 · next-l/enju_leaf
https://github.com/next-l/enju_leaf/releases/tag/v1.4.0

> バージョン1.4.0-rc.1から、RubyGemsやVirtualBoxの仮想マシンによるアプリケーションの配布を中止し、Dockerでの配布に変更しています。

うお、まじか

Install · next-l/enju_leaf Wiki
https://github.com/next-l/enju_leaf/wiki/Install

Mastodon とかを見ていても思うのが、 docker や docker-compose 経由でサービスを提供するのに git によるリポジトリの clone や pull が必要になったりするの、なんか……なんか嫌じゃない？ という

開発で使いますよという話ならわかるんだけど、そうでないならコンテナに全部入れといてくれという感想がある

実は本当に開発やコンテナビルドに使うだけで、実際は不要だったりするのかね……

まじか
無駄に git pull してたわ (まあ諸々込みで 256 MB らしいので誤差っちゃ誤差か)

bookwyrm は 53 MB だった (てかお前もかよ……)

「燃やすごみ」から「燃やすしかないごみ」に変更　4月から分別方法も、京都・亀岡市（京都新聞）
https://news.line.me/detail/oa-kyoto/5z0axk6kwie3

しょーもなくてワロた

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

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

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

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

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

conflict の後には merge が待っているでな……

https://github.com/daniel5151/inlinable-dyn-extension-traits/blob/master/writeup.md

ほー、おもしろ #rustlang