<strong>: 強い重要性要素 - HTML: HyperText Markup Language | MDN
https://developer.mozilla.org/ja/docs/Web/HTML/Element/strong#em_vs._strong
<em> は文章の解釈が変わるような強調で、 <strong> は特定部分の重要性を示すに留まっている、なるほど
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
<strong>: 強い重要性要素 - HTML: HyperText Markup Language | MDN
https://developer.mozilla.org/ja/docs/Web/HTML/Element/strong#em_vs._strong
<em> は文章の解釈が変わるような強調で、 <strong> は特定部分の重要性を示すに留まっている、なるほど
HTML Standard
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-em-element
もうちっと厳密には、 em は stress emphasis だから「発音するときそこを強調する」というもので、結果として、そこが強調されたときとされないときで解釈が変わるような文に使われる。
一方の strong は内容 (contents) の重要性を示すものなので、たぶん強調があろうがなかろうが重要なものは重要なんだよな。こっちはたぶん人間や機械が重要であるとされる場所を発見しやすくする程度のマーカー。
> The em element represents stress emphasis of its contents.
> The strong element represents strong importance, seriousness, or urgency for its contents.
……ということをちゃんと言語化できるレベルまで噛み砕いて理解したうえで英語で説明できるようにならないと、今書いてるライブラリのドキュメントがちゃんと整備できないんだわ
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.
駄目押しの「アンストします」で駄目だった
そういえば moonlander をﾎﾟﾁｰしてそろそろ1か月ですが、論理今日になって UHK 60 v2 発送の通知が来ました。
やっと moonlander の変態配列に慣れてきた頃なのにどうしよう……
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.
ソフトウェアの持続可能な開発を考えるとき資金がないとどうしようもないじゃんという話は一理あるんだけど、その主張をするなら同時に「その資金でやりくりする権利者が解体されたり死んだ後の時代にどうなるのか」という観点でも論じないとフェアじゃないよねとは思う
「大規模ソフトウェアの開発・改修を持続させるためにはフリーライドを禁じる必要がある」は中期的には成り立つだろうけど、もっと長期的に見たとき同様のことが言えるのかは疑問に思うところです
なんかこう、メンテナが現役のソフトウェアをクソデカテックがプラットフォームに使っているという現状に特化しすぎた考え方に見えるというか。メンテナが不在になったソフトウェアをクソデカテックが拾うとかの可能性はないんですかと。
まあ実際そういう事態に直面してみないとどうなるかわかったものではないし、ここで論じていてもしょうがないかもしれないけど……
少なくとも近年の商用フリーライドへの対抗ライセンスは (由来が由来だけに必然的ではあるけど) 文脈が限定的すぎて、自由ソフトウェア思想ほど普遍的あるいは一般的なものではないように感じるので、最近流行りの対クソデカテックフリーライドライセンスが破綻する日はそう遠くないかもしれないと思わずにいられない
端的に言えば、 workaround 的に見えると。
まあそれを言うたら GPL-2 も workaround 突っ込んで GPL-3 になったり、 GPL へ workaround を突っ込んで LGPL や AGPL になったりしているわけで、どこまで本質的な差なのかというのは微妙かもしれない。
まあ結局リスペクトの足りない企業に金を出す人々が邪悪を助長しているのだというところはあって、言ってみれば「ブラック企業でブラックに働く時点でブラック企業を手助けしているのと同じ」と似たような構図が見える
もっと根本的なところまで遡るなら、自分が使っているソフトウェアのライセンスや思想に対する認識が弱すぎるということになるんだろうけど。
ｾﾃﾞｯｸ今回は言語系の話少なそうだったのでまあいいかの気持ちになっている
Pixiv をﾋﾟｰｶｲﾌﾞと読む人じゃん (?)
ﾋﾟｰｶｲﾌﾞ本当に好きなんだよなぁ
むしろﾊﾟｲｶｲﾌﾞか？ (英語的に妥当かは知らん)
"hard break" と "soft break" ってたぶん英語圏特有の言葉だと思うけど、 AST のノード名として使うにはあまり良い命名ではないなと思った。じゃあどうするかというのがちょっと悩みどころではあるけど。
hard break は変換先の文書や表示においても改行として見えるべきもので、 soft break はソースでは改行になっているけど変換先や表示において改行として見える必要がないもの (たぶん)
hard break の方は、もっとこう…… forced break とかなんとか別の言いようがあったでしょ
explicit はちょっと違う気がしている
書きたいロジックはどんどん湧いてくるのに、いつも命名で手が止まるんだよなぁ
soft break、 line break as a whitespace くらいのニュアンスなのでめちゃくちゃ弱い
enforcing linebreak と possible linebreak とが思いついたな
This account is not set to public on notestock.
結局ライセンスが「感染」とか言っちゃう人、ライセンスは守らないといけない鬱陶しいルールとしか思っていなくて、我々やその成果物を守ってくれるから能動的に選択していくものだという考えでないということなんでしょうね
たぶん法律のことを聞いても「守らないといけない鬱陶しいルール」くらいにしか考えてないと思う (超偏見)
GPL が感染とか言ってるけど、プロプライエタリの方がよほど “感染” してるからな。
GPL は “感染” したまま広がることができるから様子が可視化されているだけで、プロプライエタリは “感染” したら即死して広まりづらいというだけで。
This account is not set to public on notestock.
This account is not set to public on notestock.
まあ人々が思想に興味ないというのは、それこそ2017年の Mastodon ブームからわかっていたことではあるが……
ソフトウェア開発の本職でさえそういうレベルの人が多いというのは特別に残念ね
copyleft にせよ permissive にせよ、結局思想というか理想を知らずになんとなくで使っても「バナナは健康に良いと聞いたので食べてる」程度のことでしかなくて何もわかってないし応用も効かないし、バナナ食えなくなったときどうするかも考えられないままなんだよな……
This account is not set to public on notestock.
Botフラグを利用する話は繰り返し出るんだけど、ユーザーが自由に指定できるものなので、Botブロックとか特有の挙動が一般的になると、今度はBotにBotフラグをつけないとか、逆手にとってBotフラグつけるようにする人がでてきたりとか、いろいろ難しいのよね。
UserAgent の再来じゃん
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.
hard break を EffectiveBreak とするか ForcedBreak とするかで悩んでいる
line breakとoptional breakとかならわかる
単に "line break" とすると、ソース文書での改行と、出力文書のソースにおける改行と、出力文書のビジュアル表現における改行の区別が付かないんですよね……
典型的ユースケースでは後者の2つを区別したくて、たとえば HTML のソースにおける soft break は単なる ASCII における LF とか CRLF で、 hard break は <br/> によって表現されるものなので、これらを区別するには mandatory か optional かではうまく表現できない
だもんで、 hard break には effective とか forced くらいのニュアンスが必要かなと思うんだけど、 "effective break" で調べると「詩を書くとき改行を効果的に使う」みたいな文脈の文章が出てきて、 effective…… うーんそうだね…… という
semantic はちょっと違うんだよな、純粋に visual 全振りで改行を使いたい場合には semantic とは限らなそうなので
こういうとき英語ﾈｰﾁﾌﾞの言語感覚欲しいなぁと思うんだけど、考え直してみるとそもそも連中が hard とか soft とか雑な表現してるのが元凶なんですわ
"guaranteed to be applied to / appear at the visual output" くらいのニュアンスを形容詞1〜2語で表現したいんだけど、まあ険しいのでどこかで妥協するしかない (最有力候補は effective だけど気持ちは forced に傾いている)
なんかしらんけどあっちのひとびとhardとsoft好きよね。master/slaveやmale/femaleみたいなアレソレにも引っかかる表現じゃないから雑に使えるし。
tab も hard tab と soft tab があってｵｴｰという……
hard tab は \t で表現するタブで、 soft tab はエディタとかが適切な数の whitespace を吐き出すことで表現するタブ
collapsible break... うーん
もう strong と weak でいい気もしてきた (最悪)
pull tab と push tab (???)
1文字で特定の倍数桁まで引っ張られる \t が pull tab で、インデントの深さ分空白文字を入れないといけないのが push tab #適当
explicit break と implicit break とか
soft break 、解釈段階においては単なる空白と等価に扱われたりするので、実質的に break の仲間扱いすべきかさえ怪しいところがある
まあこうなると、こんなめんどっちい単語使うならhardとsoftでよくね？と戻ってしまうので、なんかhardとsoft使いたがるお気持ちがとてもよくわかった
命名が上手なﾎﾟﾖｸﾞﾔﾏになりてえよ
ソースのpresentationと出力のpresentationが密にくっついてる＆ソース側の視点で名前を付けたいという前提ならcascading breakとline breakとかにするかなぁ
文脈としては、複数の文書形式 (e.g. markdown, HTML, etc.) に共通の AST を定義したいみたいな状況で、 (ソース側でなく) 出力側に反映されることを確約するようなノードをどう命名するかという話なので、 cascading はちょっとだけ違う (<br> とかはソースにおける改行ではないため)
や、普通に line break にしてもいいのかもしれないけど……それだとソースの話をしているようにも読めてしまうため
visual line break / visible break とかも考えたけど、うーん？？？ という感じ
出力でline breakになって欲しいトークンであって、ソースでline breakに見えるならcascadingで、ソースではline breakでない（<br>とか）ならline breakerとか名付けそう
breaker おもしろいな、命令的セマンティクスではあるけど意味はわかりやすい
This account is not set to public on notestock.
「全席優先席」でも効果なし？ 横浜市営地下鉄、新たに「最優先席」: J-CAST ニュース【全文表示】
https://www.j-cast.com/2012/02/28123685.html?p=all
それはそうだし少数の過激な人かもだけど、BSDL系のライセンスを強く好みGPL陣営とのライセンス議論バトルが趣味みたいな感じになってる人々からすれば、それらの議論を全部スルーされたような話に見えるし、なんだかなって感じかも＞＜
GPLの感染性って、GPLで言う所の第零の自由つまり"用途を制限しない"をどこまでそれを認めるかの違いであって、GPL系のライセンスは「GPLと互換性が無いソースコードと混ぜる用途を制限する」事が特徴なわけで、BSDL系のライセンスは「あらゆるライセンスのソースコードと混ぜる用途にも制限しない」という部分が大きな考え方の違いなのだから、
その部分を触れないのはフェアでは無いと思うし、無意識にやってるなら第零の自由の事をほんとに真面目に考えてるのか疑問って思うかも＞＜
持続性の観点で言うなら長期的には copyleft の方が生存しやすいし、短期的な利用・普及しやすさで言うなら permissive な方が使いやすいし、それは自由というよりスパンと想定用途の問題でしかないと感じる。使いやすい方を取るか長持ちする方を取るか。
プロプライエタリはどちらも指向していないか、あるいは試みているものの長期的な生存に向いているか疑問だというのが元の話題なので
むろん企業が潰れる間際に全成果物を自由ソフトウェア化するようなことも原理的には可能なわけなので、短期的に収益化による持続を試みて長期的には自由ソフトウェアの戦略を採ることもできるにはできる。
とはいえ、たとえそのようにしたいと考えていたとしても皆が本当にそれを実行できるとは到底信じられないので、ほとんどナンセンスな仮定ね
copyleft の性質が自由を求める観点からどうなのみたいなのは、 GNU による「いつ LGPL を採用すべきか」みたいな FAQ 項目でかなり素朴に答えが提示されているものと認識している
つまりライセンスに “感染” 性を持たせるのは自由ソフトウェアのエコシステムへの参入のインセンティブを高めると同時にエコシステムを充実させるものなのであって、多分に政治戦略的な動機があると。
極めて雑に言ってしまえば、自由ソフトウェアに自発的に貢献する人々が十分に多い優しい世界では GPL のような強力な copyleft の意義は薄くなる。
が、残念なことに (ライセンスに疎い人々や槍玉に上げられがちなクソデカテック企業を見ていればわかるように) ここはそのような優しい世界ではなくライセンス違反とフリーライドの溢れた世界なので、それらに潰されないための戦略として copyleft が意義を持っている
copyleft は個々の成果物の生存戦略というよりはエコシステム全体の生存戦略といえる。
一方プロプライエタリで対価を確保しようとするライセンスは結局個々の成果物の持続的開発を試みているに過ぎないので、本質的な違いはそこにある
(というのが個人の見解)
で、 permissive なライセンスはというと開発の持続性とかそういうものを指向するものではないので、自由ではあるけど今回の文脈で Poly なんとかと並べて考えるには少し毛色が違いますね (べつに比較できないとは言わないけど……)
PolyForm だった。まあそれに限らず近年ポコポコ生えてきた諸々の類似ライセンス含めての文脈。
そういえば、この前なんかウェブブラウザで実行できるなにか(なんだったっけ？＞＜；)すごいやつでオープンソースのができたってニュースになってて「おもしろそう＞＜」と思ってgithubに置いてあるソースを見に行ったら、一番読みたかった部分がwasmのなんかバイナリなエンコードをテキスト化した人間が読めない状態になってて「オープンソースとは＞＜；」ってなった＞＜；
wat 、手書きすると従来のアセンブリ言語より真に強力くらいの表現力はあるんだけど (たとえば再帰的に部分式を記述できたりなど)、 wasm からの逆変換だとそこまで綺麗に出力されるとも考えづらい
逆汗がライセンスの文脈で「ソース」かというと相当疑わしいし、どこかに生成元言語のソース転がってそう (知らんけど)
GPLコンドームとかいう面白ワード思い出しちゃった
そういえばMITやらBSDやらはFree Softwareのイデオロギー感を嫌う人たちがOpen Sourceって言いだしてからできたライセンスではないよね。
MITは1980年代後半 https://en.wikipedia.org/wiki/MIT_License
GPL2は1991年 https://en.wikipedia.org/wiki/GNU_General_Public_License
4項BSDは1990年 https://en.wikipedia.org/wiki/BSD_licenses
OSI設立は1998年 https://en.wikipedia.org/wiki/Open_Source_Initiative
PolyFormの記事を読むと勘違いしちゃいそうだけど。
wat 手書きは一応現実的なので、よく読んでみると本当にそれがソースな可能性も十分ある
wat形式じゃなくなんか人間が読めないいかにもバイナリをテキスト化しましたみたいな、uuencodeとかishみたいなやつがjsの中にBASICのDATA文でマシン語が書いてあるやつみたいな風に " " で囲われてずらっと書いてあった＞＜；
HTML なら画像の base64 エンコード埋め込みかもねの気持ちになるけど、 js でやる話はあまり聞かない気がするし
Wrap it before you tap it? No, say Linux developers: 'GPL condom' for Nvidia driver is laughed out of the kernel • The Register
https://www.theregister.com/2020/08/04/gpl_condom_nvidia_linux_kernel/
NeruPointerException
身代わりのメールアドレスでプライバシーを保護 「Bunsin」アプリ - ITmedia Mobile
https://www.itmedia.co.jp/mobile/articles/2108/16/news113.html
こういうサービスで:don:に登録して最終的にアカウントお亡くなりになった@karubabumiを思い出す。
This account is not set to public on notestock.
This account is not set to public on notestock.
転送型の仮メールアドレスであってもサービス提供者がテキストを平文で読めるには違いないので、果たしてそこまでプライバシーを明け渡すべきか微妙
こればかりはユーザが自発的に MITM を受け入れている構造になってしまうので……
PGP とかで E2EE しようとしてもメールヘッダ部分の情報 (たとえば宛先の表示名やスレッド ID) は可読になってしまいそうだし
Kyash 、サービス品質はまあまあ信頼できるのにビジネスとしてのビジョンは信頼できないという
コンパイル時に定数を処理してしまうアレ | κeenのHappy Hacκing Blog
https://keens.github.io/blog/2021/08/22/konpairutokiniteisuuwoshorishiteshimauare/
フォント作りって結構人の手が多いあたたかみあるお仕事だし、ツール内製するほど人材潤沢な業界なのだろうかという疑問
ところで GUI がびみょーってなる人、直すと良いですよ。GIMP 2.8 で UI いろいろ多少マシにしたの GSoC の成果だったりしますし、学生さんは来年応募するとかもあり
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.
xeyes をフォークして xpies を作ろう。
乳首がカーソルの方向を向きます。
アリーナで1vs2から1vs1まで持ち込んだら動悸と身体の震えが止まらなくなってしまった (負けた)
This account is not set to public on notestock.
背が高くてオーバーサイズなTシャツ着て、丈の短いパンツで生脚出まくりはそれはズルなんよ (今日見たもの)
というか性癖 (誤用) 全般それでは
事業会社「パナソニック」東京に本部機能 世界展開加速: 日本経済新聞 https://www.nikkei.com/article/DGXZQOUF18BF90Y1A810C2000000/
門真から完全移転じゃないけど、社内カンパニー制になってる本体から事業会社を子会社として切り出して本社機能を持株会社であるパナソニック・ホールディングスにして存続、かつ子会社のうちパナソニックの本丸、家電事業などを担う子会社は名前をパナソニックにして東京に送る、みたいな話
登記簿上の本店登録は門真のままなんだけど、パナソニックそのものと言える事業部門は実質東京移転といったかんじですね
ﾆｰｿとかもそうだけど、あのあたりのデカいグループでどこが何やっててどういう名前なのか、地味にわかりづらい
