このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
これ大昔 (大学受験浪人してたあたりの頃) に途中まで読んでたなぁと思ってｲﾝﾀﾈｯﾂでポチーして読み直している
現実には多くの人間が適宜法律より、法律とは無関係に存在しているその場の「社会性」を重視して柔軟に振る舞っているけどさ、だからってその法律に基づかない「社会性」に従わない人間を、自己中心的で反社会的であるかのように認識して攻撃しようとする、その振る舞い自体が理屈的には社会性が全然ないことだと思わない？
法律になっていない勝手ルールも、あるコミュニティーの中で支持されているという点では尊重されるべきルールではあるんだけど、インターネットみたいに地理的な距離がなくなって「部外」もなにもない環境で、勝手ルールを誰にどこまで適用するのか、そういう問題があるっていう
ｲﾝﾀﾈｯﾂにおけるコミュニティと自治については、まず物理的/地理的社会における強制的なリソース共有という制約条件と、相互の同意に基く明示的な “加入” という概念をみつめるべきなのかなと思う
> では、そういった面倒やトラブルのリスクを軽減する根本的な手段が何かと言えば、それは当然「他人と同じリソースを共有したり奪い合わない」こと[13]である。 すなわち、これが個人規模への分散だ。
過去何度も自己引用してきたとおり、これに集約される気はするけど
で、じゃあそういう「リソースの共有が強制ではない空間でどのように自治コミュニティを形成できるか」を考えてみると、やっぱり相互の承認と明示的な加入に基く “境界線のあるコミュニティ” なのかなと。もちろん、そういったコミュニティはオープンになることが難しいのでトピックを選ぶし下手にそうすると衰退してしまいがちなんだけど
物理社会でさえ「俺は法律なんかに同意した覚えはない」とか言っちゃう人がいるわけで、そういうところの任意性はちゃんと任意のオプションとして分離したうえで改めて有効化するかは個別に検討すべきなのだろうと思う
(どうでもいいけど「任意のオプション」って意味被ってるな)
Ⅰ型引用〜ⅠV型引用という定義をするのは、議論をするという点では有用なんだけど、そういう定義をしたところで法律と結びついていなければ、どこにも通用しない勝手な理屈でしかない
ハイパーリンクによる引用、SNSの公式埋め込み機能による引用、コピーアンドペーストの引用みたいに、技術的な形態の違いによって引用できるかどうかが変わってくるという主張、法律から見たら、あまり主流の解釈ではないと思うが
そもそもハイパーリンクによる参照のみがあって本文の複製・再頒布がないような形態のもの (“Ⅰ型引用”) は、引用にあたらないのでは？ という感じがある
引用と認められない複製を引用と呼んでしまうやつの逆パターンという感じ。それはそれで場合によっては有害な思考パターンを誘発しかねないかなとは思うが、引用という名前で呼んでいることを除けば並べて列挙すること自体には意味があるとは思う
そもそも、著作権法に「公正な慣行に合致するものであり、かつ、報道、批評、研究その他の引用の目的上正当な範囲内で行なわれるもの」って書いてあるから、最終的にお気持ちにフォールバックして話が拗れるのもしょうがない気はするー
環境がめちゃくちゃ変化しているのに公正な慣行についての共通認識なんてあるんかいな、的な
まあ、どうせ最終的にはマジョリティの認識が勝つので、マイノリティは自分の認識がどうでも、マジョリティに従うしかないんだよな…
図書館で文献コピーするときとかの「半分までならコピーできる」みたいなやつなぁ
著作権にかかわる注意事項｜国立国会図書館―National Diet Library
https://www.ndl.go.jp/jp/copy/copyright/index.html
> 図書館の複写サービスでは、原則として「著作物の一部分」しか複写物を提供できません。
> 「著作物の一部分」とは、一般的には著作物の「半分まで」と解されています。そこで当館では、著作物の種類に応じ、次の例のように運用しています。
判例に基づいて法律バトルすりゃいいのに、なんでお気持ちバトルしてるのかよく分からない
リソースに余裕のない庶民はテレビを修理に出さず叩いて直そうとするものなんですよ。貧乏が悪い。
実際、判例を漁るだけで (作業量と前提知識的な意味で) 超高コスト
「お気持ちバトル」なんて成立しようがない社会ってのが、多様な価値観ってことなんじゃないんですか
インフォーマルなバトル自体は基本的にフォーマルで高価なバトルをするに値するか事前に確認するための不正確なテストのようなもので、それ自体には十分に価値はあると思う。体温で体調を万全に把握できるわけではないが、病院に行く前に体温を測るでしょう。そんな感じ。
インフォーマルなバトルが健全な議論や意見交換の形で行われる限りはそれは “議論” なわけであって、もし巷のあれこれに問題を感じているとすればそれは意見以外のヘイトとか迷惑とかが交換されているからなんでしょう。まあお気持ちバトルという言葉をそのように定義するということなのかもしれないけど
法律バトルは高価なの、裁判所で法律バトルをするからであって、裁判所に持っていかなくてもその場で法律バトルして裁判になったら絶対あなた負けるから折れてくださいねって言えばそれで済むことをお気持ちバトルで話拗らせて無意味にヘイト溜めるの、安価なんですかね…
「あなた絶対に負けますよ」に「そうですね」と納得すること自体に法律まわりの知識と理解は多分に要求されるし、それができるなら既に十分な事前コストを支払い済であるといえそう
「それは永久機関だし、そんなものは作れません」に「そうですね」と答えられる時点で相応の物理的素養を修得している、みたいな話に近いかも
まあ結局理性をちゃんと持って感情をフィルタリングしろというありきたりな結論になってしまう、そのありきたりなアイデアを自分で実行できるのかが本当の問題
https://mastodon.cardina1.red/@lo48576/105759982312326059
https://mastodon.cardina1.red/@lo48576/107635463690911217
https://mastodon.cardina1.red/@lo48576/105548093826218608
無限に同じこと考えてるな
手コキ計測について調べすぎて accelerometer を確実に綴れるようになってしまった
インターネットに無料に公開している文章を限定有料配信でレビューされたみたいなこと、気にする人は気にするのかもしれないけど、ただの転載だったら無料で公開されているものに金を払う必要はないわけだし、金を払ってるのは結局レビュー自体の価値なわけじゃん？
まあ素直に「“まとめ記事” スタイルの記事では一般に付加されている意見が “引用” 対象の情報の総量よりも少なく、引用の公正な慣習の範疇にない (そして氏の記事も例外ではない)」みたいなことを言っておけばいいのではという気はする。
尤も、そう主張されたらされたで本当にそうであるかは一旦疑わざるを得ないし、有料記事となるとその確認すら困難になるという問題もある
もっと言えば公正な慣習の範囲での “引用” をされたとしても腹は立つのだろうけど……まあそれは半ば正面から認めているようなものなのでもともと論点ではないというか、その是非自体は問題としていないようには読める
コピペ型の引用は禁止とか、法律上はそんな規定はないわけだし、コピペ型の引用は法律はともかくみんなに嫌われるって法律を差し置いて主張するのも、受け入れられない話だし
そういう点では結局のところ「戦略的に下手を打っている」という主張は非常にうまいと思っている (個人的にもそう的を外した意見ではないと思っているしだいたい同意見)
べつに「嫌われてもいいから “正義” を貫く」というのも勿論ひとつのやりかただと思うけど、少なくとも「人々がこのように行動した方が良い」という形で大衆の行動を誘導するような啓蒙を行いたい場合にその方法は明らかに優れた戦略とは言い難い
じゃあその “嫌われる” とは何じゃい、という基準がマジョリティに支配されていることの問題はもちろんあるんだけど、それは行動を誘導したい対象がそのような性質を持っているは以上向き合うことを避け難い問題であって、それ自体に道徳的な問題があるとしても戦略のうまさの評価には全く影響しないと思う
何でも原理を貫けば良いというものではなくて、自分で完結する行動においては好きにすればいいんだけど、他者の行動を誘導するならあくまで「行動を最大限誘導するためにどう振舞えるか」という観点で自らの行動を設計するのが方法論として適切であると。
戦略で思い出したから LGPL の話をば:
https://mastodon.cardina1.red/@lo48576/108084038893580873
https://www.gnu.org/licenses/gpl-faq.ja.html#WhyUseGPL
https://www.gnu.org/licenses/gpl-faq.ja.html#WhySomeGPLAndNotLGPL
copyleft であること/またそうでないことの “戦略性” については FAQ を読んでくれという感じ
あなたの次回のライブラリには劣等GPLを使うべきでない理由 - GNUプロジェクト - フリーソフトウェアファウンデーション
https://www.gnu.org/licenses/why-not-lgpl.html
> どのライブラリにもふつうのGPLを使うのは、都合の良いこととは限りません。いくつかの場合においては、劣等GPLを使った方が状況を好転できると考えられる理由があります。
この「状況を好転できる」という言い回しは結構本質だと思っていて、 copyleft は静的な思想ではなく、「ユーザの自由を未来にわたって確保する」という状況をより確かにするための運動の一部でもあるわけよね。だからこそライセンス選択に戦略性がある
> プロプライエタリなソフトウェアの開発者たちには資金力という強みがあります。そこで、自由なソフトウェアの開発者たちも、お互いのために、彼らに対する優位を確保する必要があるのです。ふつうのGPLをライブラリに使えば、自由なソフトウェアの開発者たちはプロプライエタリな開発者たちに対して優位に立つことができます。自由な開発者には利用でき、一方プロプライエタリな開発者たちは使えないライブラリという強みが手に入るのです。
GPL (copyleft) というのは「充実したエコシステムをプロプライエタリ圏から使えない」という状況を成長させることで不自由にすることの優位性を削いでいくという “戦略” のもとでも選択されるものなのよね。
「ユーザの自由が」というのは究極の目標ではあるけど、その手前の段階として「人々が不自由なソフトウェアのエコシステムに参加するメリットをなくす」という戦略目標がある。
copyleft なライセンスでソフトウェアを公開するはそのための戦術のひとつ。
@mandel59
> 自己利益優先で持論に整合性がないって考えた上で
どちらかというと「日頃の言動からそう読み取れる」という話に見えるので、そこは反駁の余地が普通に残されている気がしますね。たとえば既存の記事の “引用” の分量を調整するなり「あなたの記事の引用は公正な慣習の範疇で行われます (保証が欲しいならアクセス権を与えます)」などの話をするなり。そうすれば少なくとも著者の (“引用” をペイウォールの向こうでそのまま使われることに対する問題意識の) 主張はそのままでは通らなくなる。
お前は損をするというSEKKYOUが発生しているのは、単なる嫌味というか人間味の表出という感じがするので評価としては別軸で扱いたいところです。(余計なお世話だろうというのはそう思いますが)
declavatar の機能追加はこれ↓の transition のとこの記法がまだ決まりきらなくて停滞してる
S式を信じろ、Sexpression には sex が含まれているぞ
さておき述語をノードにするとあまりに字数オーバーヘッドがデカい問題、実際ある
or
equals foo 1
and
equals foo 2
isTrue flag
みたいなことやりたくなることはあるが、かなり文法との相性が出てくる
まあ素直に DSL を用意するのが一番おさまりが良いのではという気はする (面倒だけど)
ただ外部ツールでの解釈とかがかなり困難になるのでデメリットも相応
and cond1 cond2
or cond3-1 cond3-2
or cond4-1
and cond4-2-1 cond4-2-2
のようにして圧縮する手はある
あーでも KDL だと閉括弧で1行使ってしまうのか。やっぱりまあまあダルいな
飛び道具としてはシェルの test コマンドみたいにオペレータもオペランドも全部トークンとして配列で渡すなどの手もある
スタックマシン扱いして命令列をノード列として書かせるのはさすがに non-ergonomic が過ぎるか
Man page of DC
https://linuxjm.osdn.jp/html/GNU_bc/man1/dc.1.html
dcコマンドで遊んでみた - Blanktar
https://blanktar.jp/blog/2015/04/dc-calculate
逆ポの良いところは分割を割と都合良く行えるところで、たとえば 1 2 + 3 * 4 5 + 6 * + を
1 2 +
3 *
4 5 +
6 *
+
のように分割しても良いし、
1 2 + 3 *
4 5 + 6 *
+
のように分割しても良い。
Unity の AnimatorController の遷移条件という前提に立つと 9 割はこれでいう Mostly か Complex1 ぐらいしか書かないのでまあ全部ノードで組み立てても良い気がしてきた
クソ非本質的なこと言うけど gt でなく gr なところとか is でなく be なところに個性が感じられて良い
あとこれも非本質的だけど、duration が情報の種類を表現しているのに対して and という低レベル表現が同階層に出ているのが気になった
transition "Complex1" {
condAll {
gr "BlendX" 1.0
le "BlendY" 2.0
}
duration 0.5
}
とか？ うーん
condAll / condAny
onAll / onAny
condAnd / condOr
最初期の案として and などを囲う when ブロックがあったんだけど深くなりすぎるきらいがある
これは私も思ったので、私だったら条件であることの指定と and/or を合体させてキーワード2つにするかなという感じ。どうせ条件指定のトップレベルはひとつの演算子かひとつのプリミティブな述語になることは確定しているので
まあ cond というのも大概雑な気はするので、もうちょっと何かないか？ とは思うけど (あくまで例ということで)
トップレベルに not は使えなくなるけど、ドモルガンおじさんに感謝してもらうということで……
startOn とかかなぁ (でも any/all との食い合わせが悪いか？)
startOnAny / startOnAll
まあ……悪くはないか……
start ってわけでもなく選択なのかなぁ。 selectedOnAny / selectedOnAll とか？
述語や定数に名前を付けたいとか考えだすといよいよ DSL 導入の機運が高まってしまうので悩ましい
KDL 、(hetero な)配列もそうだけど割と入りそうでまだ入ってないシンボルリテラルがほしい
まああくまでデータ構造の表現記法なので文字列でやれということでしょうねぇ
https://github.com/kdl-org/kdl/blob/f3e5ff60270792ed7fb27ad3db787ff02a1de52c/SPEC.md#full-grammar
> value := type? (string | number | keyword)
そっか……
> keyword := boolean | 'null'
なのでたぶんそれを気にしている
後続の単一 identifier を文字列化する前置単項演算子があれば、閉じ括弧のない文字列記法ができるんだけどね
まあ結局一部言語の symbol literal っぽくなるんだけど
文字列型とは異質なものであるように見えてしまうから却下されたのかな
Why must strings be quoted? · Issue #246 · kdl-org/kdl
https://github.com/kdl-org/kdl/issues/246#issuecomment-952390434
> Unquoted strings are one of the errors YAML made that we'd like to avoid, the old "you wrote NO in your list of country abbreviations to mean Norway, but what you got was a false bool" problem.
New data type proposal: symbols · Issue #89 · kdl-org/kdl
https://github.com/kdl-org/kdl/issues/89
提案はあったのか
[B! アルゴリズム] 半開区間の魅力 〜プログラミングでのスマートな区間の扱い方〜 - Qiita https://b.hatena.ne.jp/entry/s/qiita.com/_ken_/items/25cede552e3e325b9ef1
これ、現時点のブコメも含めてleft,rightとか区切り線とかって言葉使ってるけど、index,countとかindex,lengthじゃないの？＞＜
そこらのAPIも大昔のBASICの入門書でさえもそう書かれてると思うんだけど・・・＞＜
start/end だったり begin/end だったりするので、そこは慣習次第だし length でなく実際にインデックスの組を取る場合は結構ある。
まあそれはそれとして left/right はちとセンスないかなとは思うけど、それも状況次第かも。添字ではなく空間そのものの分割ならそれで正解だろうし
left/right は半開区間であることがあまり (慣習的にすら) 明確でないという点で良好な命名ではないと感じる。たとえば begin/end とか first/last はそれぞれ半開区間と閉区間であることが慣習的に合意されていたりして、そういう名前を使える場面では積極的に使った方が良いのは間違いない
このアカウントは、notestockで公開設定になっていません。
GitHub使っててもMerge Commitではタイトルを、Squash MergeではPRのタイトルと説明を含めるようにすれば良いじゃん？って感じがある
ソースコードへのコメントはプログラム構造に沿った形の記述しかできないので「過去にぜんぜん違う構造だったコードについての評価と解説のログ」みたいなのは残せない。そういう点でやっぱりソースコードそれ自体はあくまで(日々変化する環境の中に身を置くプロジェクトの) スナップショットでしかなくて、時間という構造に沿ったコメントとしてのコミットログは代替できない価値を持っているように思う
ソースと独立したドキュメント構造を用意しても、それはそれで同期が取れないとかソースの一部へリンクするのが面倒とかの問題があり……
もちろん (メンテナンスの不足により実情にそぐわぬ記述になる心配がないのであれば) コミットログとコメントにそれぞれ同じようなことを書くというのはありだと思う。そこは DRY とか気にしないで「あるべき場所に情報がある」ことを大事にしたい
コミットログ、実際の作業経路とは異なった形で再構築することがけっこうある。インデントを揃えるのは単独のコミットで、そのあとにコードの修正を別コミットでやるとか。diff としての見易さにそって再構築する。
私も基本的に feature ブランチみたいなのはどんどん rebase/fixup/edit していって、意味的に小さくまとまったきれいなコミット群として再構築してから merge するようにしている。こうすることでブランチ全体のレビューを個々のコミットのレビューへと分割できるようになる (もちろんその際分割が適正か、悪意がないかは別途疑う必要はあるが)
「コードを読む」ということと「差分を読む」ということで、ピックアップしたい情報の性質がかなり違っているとおもう。コードを読むときにはコード間の関連とか論理的な仕組みとか読んでるとおもうけど、差分を読むときに読みたいのはビジネス的な経緯なんじゃないかな。
とはいえ、ヒストリがもう少しコードベースと統合された感じになっていてほしいというのもわかるにはわかるんだよなぁ。現状いろいろなものがソースコードに対してメタな存在でありすぎる (典型的には ticket tracking system のチケット)
チケットからソースを参照することは容易いのに、ソースからチケットやコメントを参照するには HTTP/S URI やサービスローカルな ID を使うしかない。前者はサービス移動で容易く壊れるし、後者はサービス実装とデータベースのロックインを誘発する
そうしてみるとヒストリは相当マシな部類ではあるんだよな。ファイルとして移動できるし、パッチとコマンドの列へと展開できるし、なにより分散型 VCS なら複数ホスト間で同期できる
わかるけど、ソースコードから見るとビジネスとかなんとか、いろいろソースコード外部の存在なのは間違いなくて、コード表現が必要ないものもたくさんある。コード上には変化があらわれないが、ビジネスとしては位置付けが変わっており、コードから読みとられるべき意味が変わってしまうこともあるとおもう。
の投稿
Mikoinko@misskey.io
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
モニター情報を学習しスムーズな映像出力を可能にするEDID保持器 - PC Watch
https://pc.watch.impress.co.jp/docs/news/1511754.html
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
健康がなくとも WHO はある、人々は理想へと漸近し続けるのだ (適当)
「3分でわかる1秒」というタイトルで1秒の定義とその歴史について解説する3分の動画、というアイデアに囚われている
このアカウントは、notestockで公開設定になっていません。
スパムが名前拾ってめちゃくちゃになってるのくるおしいほどすき
