ｺﾛ試合してるけど、キル・ジョンウンに殺されて爆笑してる

ずるいだろ

原神やりすぎて、ｱｰﾍﾟｯｸｼのアーマーを水元素とか雷元素とか火元素とか岩元素とか言い始めた

5時間 #知らぬ間に椅子の上で気絶部

XML のことを考えていたら無性に string interner を作りたくなってきた。よくない流れだ

不治の病

27.6℃ 26%RH

#ShikakuOfTheDay
#EASY240210 ⏱️ 00:21.25
#MEDIUM240210 ⏱️ 01:15.04
#HARD240210 ⏱️ 04:21.00
#EXPERT240210 ⏱️ 10:11.50
#MASTER240210 ⏱️ 08:18.41
https://shikakuofthe.day

このパズル初めて知ったけど、ちょっと作問アルゴリズムの癖みたいなのがわかりやすくてメタ読みが激しくなってしまったので残念 (それで難易度が下がるの込みで調整しているのかもしれないけど)

二分を繰り返しているというか、「四畳半」みたいな分割が起きづらそうというか

cf.
四畳半問題 - Humanity
https://tyru.hatenablog.com/entry/20110108/matp
四畳半問題 証明方法 - Humanity
https://tyru.hatenablog.com/entry/20110108/try_to_solve_matp_part2

進捗するか……

<title><!-- --></title>

これだから HTML はカスなんですよ

一貫した文法というやつを完全に捨てた地獄フォーマット

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

気絶部リスト……

しばらく活動がなかったら死亡疑いリストに入れられそうな不健康なリストだ

運用においてソース公開の義務があろうが、それに違反して悪意あるコードを秘密裏に走らせることはできるから、そこは正直あまり実用上関係ない

単に「悪意ある機能やそれを使って収集した情報をユーザに提供できるか否か」で違いが出るだけ。どうせほとんどのユーザは悪意あるコードを検知できないし、形態によっては原理的に検知が不可能な場合もある

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

磁性流体 | 株式会社フェローテックマテリアルテクノロジーズ
https://ft-mt.co.jp/product/electronic_device/ferrofluid/

言わずにおいたものを……

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

ﾏｽﾄﾄﾞﾝで人々がｸｿﾃﾞｶインスタンスに集っていたときに「まずは人が増えるのが大事だから……」とか言って妥協し続けてきたその成果が、現状なんじゃないですかね。なるべくしてなったとしか思えない

思想のオタクなので「啓蒙しなかったら、そりゃこうなるだろ」以外の言葉がない

データ量や DB ﾊﾟﾌｮｰﾏﾝｽの問題だろうけど、なにか述語を指定しておけば特定条件を満たすときだけ永続的に保存するみたいなことをやってくれてもいいはずとは思う

自前実装さえあれば……！ みたいなアイデア無限にあるので、はやく静的サイトジェネレータ実装タスクをやっつけないといけない

揖保乃糸を垂らしてくれる仏？

罰当たりすぎる

日本昔クソ話に本当にありそうな絶妙なストーリー成立感が嫌

> 後にはただ極楽の蜘蛛の糸が、きらきらと細く光りながら、月も星もない空の中途に、短く垂れているばかりでございます。

原文ママなのに意味深に見えてきたじゃねえか！

親譲りの無節操で小供の時から自慰ばかりしていそうな坊ちゃんやめて

エリート

canvas
https://canvas-break.studio.site/

https://redmine.potato.immo/issues/138

ばか

それUNIX野郎どもは「エディタごときがメモリを何GBも食ってんじゃねえよJava頭が」と思ってるよ

ｼﾞｬﾊﾞの統合開発環境ってやつ、近年の language server 系のあれこれでマシになってたりするんですかね。というかｼﾞｬﾊﾞで実装するのやめるだけでメモリ消費軽くなったりしない？ (まああの界隈みんなｼﾞｬﾊﾞで実装したがるだろうけど)

継承が駄目なのはインターフェースと内部実装を区別せず統合するから (適当)

「コードが散って読みにくくなる」は字面通りに捉えるべきではなくて、「典型的な方式で書いたコードが、コードを追わないとまとめて必要な情報を得られないような良くない切り方になりがち」という抽象化能力や共通化機構の error-prone 性を指摘していると解釈すべき

C のプロトタイプ宣言を見て「宣言から定義が追えなくてわかりづらい」とか言う人はそうそういないわけですよ。それが †継承† を使った言語で言われるようになるということは、「“良くない分割” を促進する言語仕様になっている」という背景があると考えるべき。
分割そのものの是非というよりもメタな視点で考えないと。

はっきり言って DRY とかいう原則が雑すぎるので素直に従うべきか疑わしい場面がとても多い

独立したコードであるべきか、同じものとして抽象化すべきか、そういうのはコードやモジュールに負わせる責任を見て決めるべきなのであって、コードが文字列的にどれくらい近しいかで決めるべきではない

放言するなら「ロジックを先に考えるから滅茶苦茶になるんだろ、インターフェースを丁寧に設計しろ」という感じなんだが、これはたぶん流儀の違いみたいなところが大きくて大いに反発を受けそうなので、大声で言えるかというとちょっと……静かに暮らしたいので……

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

リファクタリングで「同じコードじゃん！まとめたろw」という考えかたをやめることができるか、という。精進あるのみですね……

祝ってほしいのか同情してほしいのか (?)

#労働は健康に悪い

もしかして: exslt:node-set 拡張が必要になってきた

回避しようとすればできそうだが (named template ではなく match を使えば良い)、はてさて

標準にある generate-id() でもいいんだけど、あれなーんか気持ち悪いんだよな

ﾎﾟﾖｸﾞﾔﾏってやつ、 (ｼｬの環境が良いというのはもちろんあるが) かなり適性があるというか、この業界でないとここまで生存負荷下げられなかっただろうなと思うので、たぶん相当向いている

10年後に同じこと言えるか見物

全然関係なかった、 ancestor:: を ancestors:: と書いていたせいだった……

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

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

世知辛いな

直和型は人権

もちろん直積も人権だけど、直積型を (間接的にも) 書けない言語は流石に高級言語と呼ばれているものでは見たことがない

<xsl:element> と書くべきところに <element> と書いていて、 element 要素が出力された (ばか)

べつに DRY 原則が雑だからといって重複が正義とは誰も言ってなくないですか……

ゴミな重複があり、ゴミな共通化もある。そういう話

アウトライン生成に失敗して泣いてる。どうして……

XSLT のデバッグしづらさよ

ネイティブコードで変換書きてえ……やはり XML ライブラリを作るしか

つらい

Rust だと衛生的マクロがあるので、ちょっとした syntax sugar とかを (コンパイラによる雑ドキュメントしかないマイナー拡張なしに) いくらか実現しやすくなっており、その辺りはちゃんとライブラリを作れば結構効いてくるのではという気はしている (エアプ)

syntax sugar を気にしないのであれば、メソッドチェーン風の何かなり inline assembly なり好き放題書けるわけで、一番下のレイヤーはまあ大丈夫じゃないでしょうか (超エアプ)

ポリネシアンN'EX 1日目: 運休

ポリネシアン
ポリネマゼンタ
ポリネイエロー

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

うーん、思い出してきた

そういえば [not(self::elem)] とかよく書いてた

一度罹れば一生罹らなくなるという点では「必ず免疫がつく」と言えないこともない >狂犬病

日本獣医学会　人獣共通感染症（第176回）狂犬病を発病した患者の最初の回復例
https://www.jsvetsci.jp/05_byouki/prion/pf176.html

狂犬病を発症後回復した１例、2004年－米国・ウィスコンシン州
http://idsc.nih.go.jp/iasr/26/301/fr3013.html

二度と罹らないとは限らないか

「もう一度噛まれて♥」とは頼めんよなぁ

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

ゴスロリ ゴマスリ 違い

一部の乙女が好むのがゴスロリ
一部の大人が好むのがゴマスリ

☑ 自分がユーザでないものに issue を立てたことがある

コミュニティ全体への貢献だと思えば、フォーラムで見ず知らずの人の質問に回答するのと大差ないですよ (たぶん)

不明な踊り三選:

* インピーダンス
* デカダンス
* コンスタンティン・カラテオドリ

#適当

バグについては「踏まなければセーフ」よりも「誰も踏んでいなくても修正すべき」寄りの思想なので、とりあえず知ってるなら報告してくれという気持ちがある。そのうえで優先度をどれだけ下げるかは踏みそうな人数と想定被害の大きさによるけど

優先度による管理がうまくいかないのは issue tracker の力不足だと思うし、それを踏まえてどう運用するかというのは一緒に考えるべきかもしれないけど

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

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

RT非表示使いまくってる

考えてみると、 RT にも suggestion/recommendation としての RT と、quote (embedding into TL context) としての RT があるはず。
機械可読な形で区別できないものか

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

そもそもインターネットお絵描きマンをイラスト以外を目的にフォローすることが滅多にないというのはある

つまり RT 前後の文脈とか関係ない (それらの投稿に関心がなく読まないので)

ソシャゲのスクショ投げまくるマンなどはRT非表示を貫通して興味ないコンテンツが流れてきたりするので、こういう場合はもう諦めてフォローをやめるしかなさそう

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

こういうのが実体験としてあるので用途別でアカウント分けて運用したいという気持ちがある (できるとは言ってない) (久しくログインしていない進捗垢)

XSLT 1.0 (XPath 1.0) で node-set (というか単一ノード) を = で比較するときってどうなるんだっけ。 string() 的な変換がかかってから比較されるんだっけか

namecheap ←→ rich entity

XML Path Language (XPath)
https://www.w3.org/TR/1999/REC-xpath-19991116/#booleans

> If both objects to be compared are node-sets, then the comparison will be true if and only if there is a node in the first node-set and a node in the second node-set such that the result of performing the comparison on the string-values of the two nodes is true.

合ってた

地獄の XPath 1.0 式錬成をしている (つらい)

どう考えても汎用言語でやるべき編集