@aqz@p1.a9z.dev いまどきのカリフォルニアの若者なんてみんなこうでしょ（ど偏見）
まあ個性の範囲であって、咎めるほどではないかな〜という感想
そもそもWeb系のプロジェクトのGithub Issueの投稿内容が全般的にワイルドだと思う

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

日本語組版処理の要件（https://www.w3.org/TR/2012/NOTE-jlreq-20120403/ja/）はみんな読んだことがあるよなぁ～！

プロポーショナルフォントやカーニングを駆使してすっきりとした見た目を良しとする欧文の組版と、仮想ボディによる整然とした見た目を良しとする和文の組版は発想に根本的にずれがある。「要件」文書では和文中に欧文の単語欧文においては4分アキをいれるとしているが、こういった固定幅スペースを独立した文字として扱うのは、欧文組版の発想ではナンセンスだと考えられると思う。ともかく、欧文と和文を区切る特別な抽象的スペース記号がUnicodeにない以上、半角スペース（と日本人が勝手に呼んでいるただのスペース記号0x20）で代用するのが妥当だと思っているので、技術的な文章（とくに、固有名詞を和文に登場させるのではなく、欧文も読む読者を想定し一般名詞を原語の意味合いで盛り込む場合）では私はそうしている。見た目上空きすぎてしまうのはやや不格好だが、単語の境界を認識しやすくなり、原文を読んでいる時と同様にどの単語であるか一瞬で読み取れるというメリットがある。このような目的がある場合、日本語フォントに入っているアルファベット（従属欧文）を用いず、前後のスペースも含めて欧文用のフォントを使うと見た目が良くなる。

件の「要件」については、資料的価値は大いにあるけれども、W3Cにわざわざ出すくらいならプロセスをどう抽象化するかという提案もしなければあまり意味がないし、「要件」と呼ぶには言っていることがちょっと保守的すぎるとも思っている。

RE: https://p1.a9z.dev/notes/9gzxz513a2

なんというか、英語を日本語の枠組みに合わせる時代でもないと思っている。

ひろゆきっずの実例が身近にいるのだが、どうやら大人が思っている以上に自他境界を secure する手段だと感じているみたいなのですよね。（ふっかけてくる議論の話題設定がめちゃくちゃで屁理屈にしか聞こえなかったとしても。）
信頼するに値する共同体と接続することでこういった傾向性は克服されると思っているのだけども、具体的にどうしたらいいかと考えると「もしかしたらうまくいくかもしれない」程度の手段しか思いつかない。まぁコントロールしようという発想は有害な結果にしかならないので、「そうなんだなぁ」くらいに思っています。

まだつらいのでカフェインと砂糖を摂取した（ちょっと砂糖を入れすぎて甘い）
効くといいなぁ

RE: https://misskey.io/notes/9h0s9ho3lx

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

ちょっと体調が良くなった

もはや芸術的な間違い方してる

RE: https://mystech.ink/users/riq0h/statuses/110693366398888164

おはようございます
Misskey がアニメ化されるというニュースを夢で見た（私も登場するらしい）

学部の時に複素解析にあんまり興味を持てなかったのでChatGPTに聞いたらネヴァンリンナ理論を学ぶのが面白いかもよと言われてWikipedia読んでいたら寝てた
第一の標数定義と第二の標数定義がほとんど同じといえる理由は分からなかったが、まあたしかに面白そうだとは思った

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

テストに使っているライブラリのAPIが変わるせいでテストが落ちるのは悲しいはなし

RE: https://p1.a9z.dev/notes/9h3r09h0ei

Fediverse の Discoverability が低い問題、
1. ニッチな話をしてもどうせ通じないというユーザーの信念を変容させる
2. 検索エンジンフレンドリーにする（サーバーサイドレンダリングとか）
3. 特徴的なキーワードを（tf-idf的な手法で）取得し、（word similarity的な手法で）整理してユーザーに提示する
が必要なのかな
協調フィルタリングによるリコメンデーションはエコーチャンバー化などの弊害を招きやすく、またユーザーが少ないとそもそも成立しないと思っている

Relayから流入する投稿だけをオリジナルサーバーでフィルタリングしたいのだけど、inbox リクエストでリレー経由かどうかって判別できるのかな…（これができていないせいでFedibird relay への参加申請をまだしていない）

サービス利用規約に運営者が果たすべき義務を運営者自らが盛り込むことは、恣意的な運営を行いサービスの価値を自ら毀損する行動に対する抑止力となること、相手が運営者に対して抱く期待を明文化し紛争を予防すること、正当業務行為の主張に具体性を持たせられること、英米法の文脈における約因を構成でき国際的統一性のある規約を構成できることなど様々なメリットがあると考えられる。

@Ravil_Dgma まあ、よそで話すのはなんか違うんだよなぁって時に話せる場所であれたらなぁと思ってます

鉄道の写真を撮るのは好きだけどいわゆる撮り鉄ではない

大学、難しい講義を選択すればするほどGPAが下がるのは深刻な仕様バグだからすぐに直した方が良い

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

to不定詞 = to 原型不定詞
on不定詞 = on 原型不定詞
というのは極論ですが、動詞をそのまま　名詞にしたり、名詞をそのまま動詞にしたりする用法の生産性が高いのが英語の特徴の一つだと思っています。

RE: https://gnusocial.jp/object/note/3479507

@gnusocialjp@gnusocial.jp もちろん、on + 原型不定詞というのは非標準的な用法だと思います。ただ、to不定詞が to + 原型不定詞から発展してきた歴史を踏まえると、前置詞に動詞の原形をつなげる表現は、比較的許容度が高い部類に入るのかな、という趣旨の発言です。（言語は自然に存在するものであり、文法規則（という言語に関する仮説）は用例に適合するように作られるべきだという立場です。単なる誤りは相手にすべきではないですが、少なくない話者が「間違ってもいない」と思う表現については、その理由を考えていきたいと思います）

@gnusocialjp@gnusocial.jp
1. 私の感想です。私は「事実未満の直観・内省」「作品未満のモチーフ」を共有する場所としてSNSを良く使っています。その直観、根本的に間違っているのでは？という指摘も歓迎です。
2. 例えば of + 原型不定詞というのは想像し難いですが、「イベントとイベントがどう繋がっているのか」を積極的に表現できる前置詞の場合は通用する可能性がある（慣用表現が生じてくる可能性がある）のではないかと思います。
3. 動名詞だと俯瞰的・抽象的になってしまって、表現したいニュアンスを言い表せないかと思います。動名詞は動作の概念を名詞的に指し示すのに対し、原型不定詞はある具体的な動作の遂行という事件そのものを指す働きがあるので。（参考：https://journals.openedition.org/anglophonia/775）
『「接続した！」に対して〇〇する。』と『「接続すること」に対して〇〇する。』の違いといえばよいでしょうか。

別の用例として、on demand publishing の demand も、漠然とした「需要」を指しているのではなく、theも使わずに「具体的な注文を受けました！」を指しているので、名詞というより原型不定詞としての性質が強いのかなと思います。

あるニンゲンを使う人、自分で用意したニンゲンを使う人…

RE: https://mk.xiupos.net/notes/9h4t2r1tgc

@gnusocialjp@gnusocial.jp
2. 言葉を整った考えを伝える道具として使う人にとっては、有名な文法書やスタイルマニュアルが推薦する表現や、想定読者が慣れ親しんでいる慣用表現を使う、というスタンスが好ましいですね。
3. 文法を付け加える必要があるか？については、文法は誰かがコントロールするものではありません。（ある文章が文法に即しているかどうかはインフォーマントと呼ばれる被験者が判断し、文法学者は判断しないのが正式なやり方です。）いかに不合理な文法であろうとも、もし実際に使われているのなら、文法に付け加えなければそれは不完全な文法理論になってしまいます。
言語学者は、話者たちが感じているはずの微妙な違いを自分たちが聞きこぼすことを危惧しています。V-ing と原型不定詞の意味の違いについては、私の感想ではなく、先程のリンク先の論文にも書かれているように文法理論では一般的な見解と思います。(大学の講義でそのような議論をどこかで聞いた覚えがあったので、とりあえず言及をしている論文の例を調べて示したところです）一見重要ではない違いに着目することで、人間の認識の枠組みが明らかにされていく…というのは言語学者の夢の一つですが、文法を考えている人は「良い意志疎通手段を作るには？」とは全然違うことを考えていることを知っていただけると幸いです。

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

再代入禁止は末尾再帰最適化のある関数型プログラミング言語の流儀だから、末尾再帰最適化が保証されていないJavaScriptでやるのは制約が多すぎる
と思う

RE: https://mstdn.kemono-friends.info/users/nanase/statuses/110709989819586782

Scratch、yuriが含まれているユーザー名の登録をブロックしているらしい。fuckとかshitとか同じ扱い。ひどすぎませんか。