Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/245: 1 2 3 4 5 6 7 8 9 »

WindowsのストアアプリがWindowsの更新後に「指定されたユーザーには有効なプロファイルがありません」で起動できなくなる問題の回避方法 - Nov 09, 2020

結論:Windowsをもう1回再起動してください。

Windows 10 1909からWindows 10 20H2に更新した後でWindows Terminalを起動しようとしたら、「指定されたユーザーには有効なプロファイルがありません」と言われて起動できなくなってしまった。Preview版の頃に入れてそのまま使っていたのがまずかったのか?と思って1回消してストアから入れ直してみたけど、症状は変わらなかった。

エラーメッセージで検索すると、どうもこれはストアアプリで共通して起こる問題らしく、他にはiTunesやSkypeやWordやExcelでも発生した事例があるようだった。ただ、検索上位に出てくる情報は役に立たない情報ばかり(何々というアプリが原因かもという的外れなリプライしか付いてなかったり、Wordのバージョンを書いて下さいというリプライに質問者が無反応で放置してたり)だった。

そんな中に1つ、Stack Overflowとかの情報を機械翻訳してる系のスパムサイトか?と思える文面のページがあって、そこには「更新後にもう一度再起動するで問題を解決できます」と書かれていた。更新の後に再起動かかった直後なのに、そんなので本当に効くのか? と、機械翻訳くささに半信半疑になりつつも実際試してみたら、これが当たりだった。本当に2回目の再起動で状況が改善して、Windows Terminalが起動できる状態に戻った。1回アンインストールしたので、設定が吹っ飛んでしまったけど……

(教えてもらって気が付きましたが、ページ内に小さくリンクがありました。元記事はHow to fix broken Windows user profile after latest Win10 pro upgrade? - Super Userだそうです。)

次にググる人が少しでも優位な情報に辿り着きやすいように、ここに記録を残しておく事にする。

ラブタイツキャンペーンの炎上について、タイツフェチの視点からの記録と問題点の考察 - Nov 08, 2020

アツギ社が「タイツの日」に合わせて行った「ラブタイツ」キャンペーンが、各方面から批判されて中止になった件について、批判側に立っていた人の一人として書いてみます。

なお、アツギ社による公式の謝罪が既に出ていますので、このエントリはこれ以上の批判・非難を意図しません。自分がこの企画の何をどのように問題だと考えたかの自己分析・記録・説明と、表現に関わるあらゆる人が似たような事を繰り返さないための判断材料の提供を意図しています。

続きを表示する ...

鋼鉄人形論法を意識してトーンポリシングになる(気がする) - Oct 13, 2020

鋼鉄人形論法とは

最近、「鋼鉄人形論法」という言葉を知った。

自分と反対の立場の意見について、その中でも最も愚かな主張をしている人を取り上げたり、時には実際には存在しない支離滅裂な言説をでっち上げたりして、容易に批判できる対象に対してマウンティングを取ることで、「だからあの連中は阿呆なのだ」と身内や周囲にアピールする論法を、藁人形論法と言うのだけれど、鋼鉄人形論法はその逆だそうだ。つまり、自分と反対の立場の意見の人の中でも、最も理性的で賢い人の主張を取り上げたり、相手の主張を理論的に補強したりして、容易には批判できない強固な敵と敢えて相対することで、自分の主張を鍛えていく、ということらしい。

反論をある程度想定した上で持論を述べる時には、なるべくそのようにした方がいいだろう、と自分もなんとなく思っていたので、それに鋼鉄人形論法という名前が付いてセオリーとして認知されていると知って腑に落ちた感覚がある。

トーンポリシングとは

別の話で、「トーンポリシング」という言葉がある。

これはMeTooやBlack Lives Matterといった反差別の運動の文脈でよく聞かれる言葉なのだけれど、例えば抗議者が「差別をするな! この差別者め! 貴様のような奴は生かしておけん!」みたいな強い口調で迫ったときに、抗議を受けた側(差別をしている側)や周囲の人が、「そんな攻撃的な言い方じゃ聞く気になれないよ」と言い方(トーン)を穏やかに改める(ポリシング)ようになだめることを、そう呼ぶようだ。抗議者(被害者)と被抗議者(加害者)の間に圧倒的な権力差がある状況では、穏やかな言い方に改めたら単に抗議が無視されるようになるだけだ、ということで、反差別の言説を無効化し差別を維持・強化する悪行であるとされている。

鋼鉄人形論法を意識すると、感情と向き合わざるを得なくなることがある

鋼鉄人形論法に則って相手の主張の論理を深く掘り下げていくと、多くの場合、相手の視点での合理的な判断の結果として自分とは異なる結論に至っていることが分かってくる。衝突を解消するための交渉においては、相手の合理的な判断と自分の合理的な判断とが衝突しなくなる落とし所を探る必要がある。

ただ、合理性では落とし所を見つけられない場合というのも多くある。僕はそれを、感情的に折り合いが付かない場合だと考えている。

例えば「あなた1人が死ねば100人が助かります。死んで下さい」と言われて、なるほど合理的だと納得して粛々と殺されようという人は、あまりいないのではないだろうか。少なくとも僕は納得して殺されようとは思えない。死ぬのが「怖い」し「嫌だ」、という感情があるからだ。感情に根ざす衝突は、どんなに鋼鉄人形論法を突き詰めても合理的な根拠には辿り着けない。

……という書き方をすると、「つまりそういう奴らは合理的な判断ができずに感情に流される愚かな連中なのだ」という話だと思われるかも知れないけれど、僕が言いたいのはそういうことではない。僕は今のところ、「感情で判断するな、合理性で判断しろ。感情なんてくだらない」とは思っていない。感情は合理性に劣るものではなく、合理性と直交する概念だと思っている。人は、合理性の面では利が小さくても感情面で利が大きい判断をすることが多々ある。僕自身は、合理性が高くても感情面で納得できない判断よりも、感情面で納得度の高い判断の方が、満足感・納得感が大きいという実感がある。

(これをもっと突き詰めると、「合理的な方が良い」と常に判断している人すらも、「合理的な方が好きだ」という主観的な感情に引きずられているのではないか? という話になってくると思っている。ただ、これは本題ではないので、これ以上掘り下げないことにする。)

感情と向き合うと(本当の)問題が解決することがある

ともかく、両者の意見が衝突して落とし所が見つからないケースの中には、感情の折り合いが付かないことが根本的な問題であるにも関わらず、「双方あるいは片方が」「自覚的か無自覚かはともかく」感情の問題に向き合おうとしていないケースがある、と僕は思っている。

特に、「感情的になるのは愚かなことだ、感情で判断するのは愚かなことだ」というスティグマに囚われている人は、無自覚のうちに、自分の中の根本原因の存在にも、ましてやその解決からも目を背けてしまいがちではないかと思う。(というか、過去の僕はそうだった。)

そういうケースでは、感情面の問題が解決されるだけで、意外なほどスルッと話がまとまることがあるようだ。例えば、サポートセンターに電話をかけてきて、上司を出せ謝罪しろとがなり立てていたクレーマーが、電話口で一通りの感情を吐き出すとおとなしく引き下がっていった、みたいな話は度々見かける。そのクレーマー自身は、自分の感情を満足させたかっただけだとはきっと認めないだろうけれど、事実としてそれはやはり感情の問題だったのだろう。

先の「あなた1人が死ねば100人が助かります。死んで下さい」の例で言えば、多くの人は、それで救われる100人から「早く死ねよ」と石を投げられている状態よりも、感謝の言葉をかけてもらったり、「死後永遠に語り継いでいきます」みたいな事を(嘘でも)言われた方が、感情的に納得して決断をしやすくなるのではないだろうか。「お国のために」「郷里に残した家族のために」と涙を呑んで散っていった特攻隊の若者達のように。まあ、人によっては、「俺を犠牲にして自分が生き残りたいだけのくせに白々しい。そんな欺瞞に満ちたおべんちゃらを言われるくらいなら、石でも投げられた方がマシだ」ということもあるかもしれないけど(そういうタイプの人にとっては、そのように感情を徹底的に傷付けられることこそが、感情面で折り合いを付けるために必要な事なのかもしれない)。

感情面で受け入れられやすい表現にした方がいいのでは、と言うとトーンポリシングになる

差別の話についても、ここまでで述べたような感情の話が当てはまるのではないか、と僕は思っている。

といっても、ここで僕が注目したいのは、差別を受ける側の感情ではなく、「差別をした」と抗議を受ける側の感情だ。差別をしてしまう・やめられない・抗議を素直に受け入れられない側にある「自分がこれまで慣れ親しんできた文化が侵される嫌悪感」とか「自分と異質な物に対する忌避感」とか……もっと平たく言えば「怖い」「嫌だ」といったプリミティブな感情のことだ。

ここまでで述べたとおり、僕は、そういった感情も判断に大きな影響を与える要因で、且つ、決して軽視はできないと思っている。抗議される直接の加害者や、直接の加害者以外にも、その加害者を包摂する社会を構成する一員・間接的な関係者として抗議を受ける側となる、周囲の傍観者も含めて、「抗議する人とその支持者」以外のすべての人の感情を傷付けたり逆撫でしたりする言動は、問題の解決を遠のけることすらあると思っている。

「だから、抗議をするときは相手の感情を傷付けない言葉を選んだ方がいい」……というまとめ方をしたら、そう、トーンポリシングと非難されるアレになってしまうのですよね。これが、長々と書いてきてここで僕が言いたかった事。

 

僕自身は、何かを抗議した時に、まともに取り合う気のない相手からあれやこれやの言い逃れで抗議を無効化されれば腹が立つ。でも「言い逃れ」できる余地を残してしまっているのは自分の側の落ち度だと思うので、正攻法でいくなら、言い逃れができないように丁寧に外堀を埋めて臨むしかないのではないか、と思っている。表現を見直すこともあるだろうし、あるいは、根回しをすることもあるのかもしれない(自分はその手の政治がとても下手なので、できる気がしないけど)。傍観者から「自分の非も認められないガキが駄々をこねている」と思われてしまっては勝てない、という思いがある。

でも、「そんな悠長な事をやっていられない事態なのだ、これは今その場にある命の危機の問題なのだ」というのが差別の文脈ではよく聞かれる話で、確かにそれはそうだと思う部分もある。卑近な例えをしてしまうけれど、自分がかつて虐めを受けていた頃に、「まずは周りを味方に付けて」とか言われても「は? ふざけんなし。味方なんかおらんし。戦って自力救済するしかないし」としか思えなかっただろうと思う。その頃の自分にとっては、自分の非を少しでも責める者はすべて「敵」で、自分の事を全部許して認めてくれる者だけが「味方」だったような気がする。

差別に抗議している最中の人達が、その頃の自分と同様の心境なのだとしたら、抗議を受けている世界を構成する一員であるところの、つまり、差別者の一員である僕から、どんな言われ方であろうとも、抗議の仕方を咎めるような言い方をされて、受け入れる気分にはならないのではないかと思う。

かといって、ここまでで述べたようなことを考えている僕には、傍観者の敵意を増すような抗議の仕方を積極的に擁護する事もできない。

なので僕は、抗議している人達に直接は賛同も批判もしないで、黙って自分の良心に従って行動するだけに留めるのがいいんだろう、と思っている。差別的言動を見かけた時には自分の言葉で咎め批判し、自分が差別的な言動をしてしまったときには粛々と反省し、自分の信じるメッセージを込めて、不用意に差別を再生産しないことを心がけて表現していくしかないな、と。

オチはないです。

「なぜMozillaはXULアドオンを廃止したのか?」に寄せられていた反応を見て、「甘い……甘すぎる……」と思って、W3C信者時代からの価値観に行き着いた話 - Aug 27, 2020

1つ前の翻訳記事の末尾には当初、自分の個人的な考えを長々と書いていたのですが、翻訳記事でそういうことをやるのはマナー違反という指摘を頂きました。自分でも確かに、思い入れのあまり熱くなって書きすぎと感じていたので、別記事に分けるついでに増補改訂することにしました。)

原文に寄せられていたHacker Newsでの反応や、僕の翻訳に寄せられていた反応を見ていると、XULを捨てる判断を間違いと断じる物や、そのような判断をしたMozillaに対する恨み節、あるいは「バカな判断をしやがって、そんなだから俺らパワーユーザーから見捨てられたんだ」みたいな捨て台詞じみた物が結構見られました。

それらを見て僕は正直、「これだけ丁寧に書いてあってまだそんな風に思えるってどういうことなの……」と驚くやら呆れるやらしたのですが、自分自身もかつてはそっち側にいた自覚があったので、「なんでそう思うのか」も分からなくはありません。

甘い見通し

今でも「見境のない拡張機能の仕組み」を支持し続けている人というのは、アドオン開発者にしてもユーザーにしても、ある意味で楽天的というか、性善説を信じているというか、そういう感じなのかなあと思っています。

「従来路線でいっても生きていけただろう、少なくとも玄人向けとしてなら生き残れただろう」という意見については、以前の記事で「それでは結局現実に生き残れない」とバッサリ切りましたし、1つ前の記事のコメント欄にも書いてみました。しかし、それとは別に「諸々の進歩を継続しつつ、アドオン開発者やユーザーに自己責任での自由を残すのでは駄目なのか?」という主張もあります。自分もFirefox Quantum以前はそのような立場でした。

この場合の世界観は以下のように要約できるかと思います。

  • アドオン開発者:「自分はFirefoxの変更に振るい落とされることはない、いつまでだって追従し続けられる」と考えている。
  • ユーザー:「アドオン開発者はそのような努力をいつまでも続けてくれる」と考えている。

しかし、自分の体験と先の記事の内容を踏まえて、今僕が思うのは、「甘い……まったく甘すぎる……」ということです。

僕自身、日々壊れていくXULアドオン時代のTSTを維持するのには、ものすごい苦労を要していました。当時はそれが当たり前だと思って麻痺していただけで、実際には狂気の沙汰だったと感じています。TSTをWebExtensions化して以後の感覚では、XULアドオンを書くのなら、実作業時間で1時間あたりN万円くらいのお金を貰って仕事としてやらないと、とてもじゃないけどやってられないです。それくらいに、XULアドオンは維持にコストがかかると言わざるを得ません。「少額ながら寄附を……」とかいうレベルでは収まらない、もはやビジネスの話です。

僕自身はライフステージはそれほど変わらないままですが、結婚や子育てなどライフステージの変化の影響で、毎日アドオンのメンテナンスに時間を割くことはできなくなってしまう人も、当然いたでしょう。メンテナンスに膨大なコストを要するアドオンを継続し続けなくてはならないのでは、作者の人生をそれだけに縛り付けることにもなりかねません。

あるいは、作者個人が自分の使う範囲だけで細々メンテナンスし続ける程度なら可能かもしれませんが、それを「第三者が使いやすい」状態でリリースまでするモチベーションはどんどん下がっていく一方でしょう。

「見境のない拡張機能」は、もはや「ユーザー」はお断りの世界

なぜなら、ものすごく嫌な言い方をしてしまうと、今XULアドオンを一般向けにリリースしても、パッチも提供してくれない・問題の再現条件の特定もしてくれないクレクレ君達からの、「お願いですぅ~直してくださいぃ~ボクにはとてもメンテできましぇ~ん」みたいな声が増えるばっかりで、いいことがないからです。

それは言いすぎだろう、パワーユーザー向けならそんなことないのでは、と思う人もいるかもしれませんが、こういう修羅の世界では「敬意を払ってくれるユーザー」や「お金を出してくれるスポンサー」だけいても、結局は搾取構造にしかならない、と僕は考えています。。

一般的には「OSSにできるコントリビュートはプルリクエストだけではないです。障害報告も立派なコントリビュートです。必要な環境、再現手順、期待される結果、実際の結果を明記した良い障害報告をしましょう」ということを僕も言っていますが、「見境のない拡張機能」の世界では、それですら作者側の負担が大きすぎると言わざるを得ません。プルリクエストやコードを実際に提供し合うような、「同じ技術レベルで共に並び戦ってくれる戦友」同士で助け合う以外には成り立たない、そのレベルで戦列に加われない人に関わられて期待されても困る、というのが正直な所です。

技術的な事実をいうと、今でもFirefoxでは「見境のない拡張機能の仕組み」と同等のことをやる余地は残っています。AutoConfigの仕組みを使って、(Firefoxのインストール先)/defaults/pref/autoconfig.js

pref("general.config.obscure_value", 0);
pref("general.config.filename", "autoconfig.cfg");
pref("general.config.vendor", "autoconfig");
pref("general.config.sandbox_enabled", false);

という内容のファイルを置き、(Firefoxのインストール先)/autoconfig.cfgにゴリゴリ書いていけば、Firefoxのchrome領域上で任意の特権スクリプトを動かすことができます。実際、僕も仕事の上でどーーーーーーしても必要に迫られた場合はそうしていますし、Firefox内部で任意のスクリプトを特権付きで動作させるアドオンだった「userChrome.js」のエコシステムを継続している人達も、この方法を使っているようです。

こういう使い方をすると、前の記事で散々書かれているような「バージョンアップですぐ動かなくなる」「代替策がない」というドン詰まり状況が頻繁に発生します。ググって見つけたブログ記事やQiitaの記事のコピペで使うだけではとても維持できず、「自分で原因を調べて、自分でコードを直す」ということがどうしたって必要になってきます。誰かが直してくれるのをボケッと待ってるだけでは、今のFirefoxのリリースサイクルにはまず追従できないでしょう。

なお、この方法を使っている人達は百も承知だとは思いますが、この方法もいつまで使い続けられるかは分かりません。それでも、「Firefoxのソース自体に手を入れて、Firefoxそのものを独自ビルドする」のは依然として可能です。あるいは、そこまでやるならChromiumに乗り換える(Chromiumを改造して独自ビルドする)方がいいかもしれません。もはや完全に根性試しの世界ですが、腕力さえあれば乗り切れるのがOSSのいい所です。腹を括って「この方向でも生きていけるんだ」ということを示し続けていく人は、いてもいいとは思います。僕にはとても真似できませんが……

Thunderbirdの場合

FirefoxはFirefox 57で「見境のない拡張機能」をバッサリ切りましたが、Firefox ESRのスピード(1年ごとのメジャーアップデート)でゆっくり物事が推移しているThunderbirdは、もう少しソフトランディングな方向で進んでいます。会社のブログに書いたThunderbirdアドオンのTb78対応の話では「使うな」とサラッと流していますが、アドオン作者向けのThunderbird 78向け移行ガイドによると、Thunderbird 78では「公式のWebExtensions APIには含まれていないけれども、こういうAPIが欲しい」という機能があるときに、アドオン作者がそれを自力で実装する、Experimental APIという仕組みが利用できるようです(これはFirefoxでも提案はされていたのですが、なんやかやで結局実際には使える状態にならなかったと記憶しています)。

ただ、そのような本来の意図とは裏腹に、Experimental APIは結局「見境のない拡張機能」と同じことをするための互換レイヤー作りのために使われてしまっているようです。少なくとも、CardBookという巨大アドオンのThunderbird 78対応ブランチでは、ほとんどのソースはXULオーバーレイ前提になっていて、Experimental APIでXULオーバーレイ相当のことをしている様子が伺えました。

まあ、そうしたくなる気持ちは、分からなくもないんですよ。移行ガイドは(ちょろっとしか見てないですが)「こうやってちょっとずつ移行していきましょう」みたいなソフトな書き方をしてるし。一般的に、ハードランディングよりソフトランディングの方がいいとされてますし。前の記事にあった通り、Firefox自体もちょっとずつ段階的に改良されていったわけですし。

でもねえ、XULアドオンのWebExtensionsへの移行だけは、TSTのWebExtensions化で僕がやったように、「腹を括ってゼロから作り直す」以外の選択はないと思うんですよ。XULアドオンとWebExtensionsアドオンではパラダイムが違いすぎて、「ちょっとずつ置き換え」なんてできないんですよ。

「ちょっとずつ置き換えるためにとりあえずExperimental APIで全部持ち越した」の先にあるのは、「ちょっとずつ移行しようと思ってたけど、どうやって移行したらいいか見当もつかない」という混乱、そして何もできずに手をこまねいての停滞、最終的には時間切れ(Experimental APIの廃止)での完全死だけ。そうなる前に、いかに早く頭を切り替えて腹を括ってゼロから作り直そうと思い切れるか、それが生死を分けると僕は思ってます。

優先順位が違ったから僕は腹を括れたのかもしれない

XULアドオンのWebExtensions化では、「WebExtensionsらしいやり方でゼロから作り直して」「APIが足りない部分は、WebExtensionsらしい作法に則ったAPIを提案する」「要望が通らなかったら諦める、無理はしない」というのが最も「正しい」やり方です。自分は一応今のところはそういう方針でやっているつもりですが、改めて考えてみると、僕がこの方針を取れているのは、僕の本心が、多くの「見境のない拡張機能の仕組みに今でもこだわり続けている人達」とは別の所にあったからなのかもしれません。

元記事に寄せられたPale Moonのメンテナーの人のコメントでは、徹底的なカスタマイズを必要としている人のために頑張っているのだ、ということが語られています。それ以外の怨念の籠もったコメントや捨て台詞じみたコメントも、通底しているのは「自分のやりたいようにカスタマイズできることが一番大事、それ以外は二の次」という価値観のように僕には思えました。

対する僕は、「Mozillaの掲げるOpen Webの実現が一番大事、そのために必要な物としてGeckoというレンダリングエンジン実装が継続することが必要、自分のやりたいようにカスタマイズできることは二の次」と考えているようです。いま自分がインターネットを使いたいように使えるのはOpen Webがあってこそで、その邪魔になるなら自分の細かい要望は(なるべく実現できるに越したことはないけど、どうしても衝突するなら)脇に置いても構わない、というか、自分の要望を無理に押し通した結果Open Webが失われては元も子もない、という考え方なのだと思います。

これはべつに、Mozilla信者だからMozillaの言うことに何でも従ってる、というわけではありません。Mozillaに入れ込むようになるより以前、W3C信者として調子こいてた頃に僕が入れ込んでいた、アクセシビリティとかユニバーサルとかの話が先にあって、Mozillaの掲げるOpen Webはそれに連なる物だと捉えている、ということです。(そもそもで言えば、僕はWeb標準を素晴らしいと思っていて、そのWeb標準の技術に基づいたXULとCSSて実用的なデスクトップアプリケーションを作れる実例が示されていたから、ということでMozillaに入れ込むようになったのでした。)だから、もしMozillaが「Open Webなんかどうでもいい、Web技術の標準化とかどうでもいい」なんて言いだしたら、僕はその時の方が深く失望すると思います。

 

この日記の話題が、ここ数年ジェンダーとか差別とか多様性とかそういう話ばっかに偏ってた感じはありましたし、「シス管系女子」でみんとちゃんやその周辺の人物達の様子を描くときにもそれがずっと裏テーマとしてはあったんですが、それらも大きな括りでは近いところにあるんですよね。

そう考えると、僕がやってることはあれもこれもどっかで繋がってるんだなと。しがないラジオのとき自分のやってきたことを線で繋いだ図にしたけど、単にバラバラにそれらがあったわけじゃなく、1つの価値観の多様な表現形だったということなのかなと。

W3C信者活動をやめてすっかり軸足がよそに移ってしまったと思ってたけど、判断の根底にはまだまだW3C信者だった頃の何かが残ってたんだなあ、と改めて思い知らされて、感慨深い思いをしたここ数日だったのでした。

なぜMozillaはXULアドオンを廃止したのか?(翻訳) - Aug 22, 2020

原著:David Teller, 2020年8月20日CC BY-NC 4.0で公開されている内容の全訳。Qiitaにもクロスポストしています。

要約:Firefoxはかつて、XULとXPCOMに基づく偉大な拡張機能の仕組みを持っていました。この仕組みは長い間私達によく尽くしてくれました。しかし、Firefox開発者と拡張機能開発者の両方にとって、メンテナンスコストは増大し続けるばかりでした。ある面では、増大していくコストは、Firefoxをセキュアにしたり、高速化したり、新しい事を試したりするための努力を、少しずつ破壊していきました。また別の面では、増大していくコストはアドオン開発者のコミュニティを少しずつ破壊していきました。最終的に、古いアドオンの仕組みを守ろうとして数年を過ごした後、Mozillaは、この拡張機能の仕組みを廃止し、それより拡張性は劣るもののメンテナンスしやすいWebExtensions APIに置き換えるという、難しい決断をしました。この選択のおかげで、Firefox開発者は再び、セキュリティや安全性やスピードを改善するために必要な変更を行えるようになったのです。

ここ数日、私はFirefoxのユーザーと会話して、2020年8月のMozillaによるレイオフの結果に関する噂と事実を区別しようとしていました。その過程で何度か持ち出されたのが、Firefox Quantumへの移行におけるXULベースのアドオンの廃止のことでした。私は非常に驚きました。もう何年も前に起こったことについて、この選択に感情を害されたと感じている人が、コミュニティにまだいるということにです。

そして、誰かがredditで指摘していたとおり、私は、何故XULベースのアドオンの廃止以外に選択の余地が無かったかについて、私達が深いところを説明する機会をまだ持っていなかったということに気付きました。

そこで、アドオンとGeckoの内部事情の話に飛び込む準備ができている人向けに、これを機にもう少し詳しい話をしてみようと思います。

続きを表示する ...

「同調圧力は忌むべきものだ」と思考停止していたことに気付いた話 - Jun 19, 2020

このところ狂ったような長文を立て続けに書いていて、いいかげん出涸らし感が出てきた気がするけど、このツイートからたらたら書き連ねたことの増補改訂版として残しておく。

欧米社会にもあるらしい同調圧力

Gitのデフォルトブランチ名「master」が奴隷制を想起させるさせないの議論を発端に、差別される側にとって「言葉狩り」に一体どういう意義があると考えられるのかを改めて考えたんだけど、釈然としないモヤモヤ、露悪的な言い方をしてしまうと「差別主義者って言われるのが怖くてビビって過剰反応してるだけなんじゃないの?」「現実にある差別構造の撤廃に切り込む方が大事だろうに、言葉遊びをしてるだけの人がなんで『これぞ先進的な人権感覚、皆も追従せよ』みたいなツラしてるわけ?」みたいな違和感はずっと残ったままだった。

なぜそんなにモヤモヤしてしまうのかというと、これって普段から日本でも見慣れてる、同調圧力に基づく自主規制の光景と変わらないと思うからだ。ナイフでの殺傷事件が起これば文脈を問わずナイフ描写がマスメディアから一斉に「自粛」で姿を消す。問題がありそうかなさそうかを個別に熟考する暇も無く。それとよく似てると思った。

続きを表示する ...

Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか - Jun 16, 2020

1つ前のエントリにちょいちょい追記してるんだけど、見通しが悪くなってしまったので別エントリにした。

blacklistをblocklistにするとか、master/slaveを別の語に言い換えるとかの変更は、一体誰のためのもので、どういう意義があるのか? という問いに対して、1つ前のエントリを書き始めた時点でまだ自分は完全に腑に落ちる理解ができていなかったように思う。

その後、観測した反応や他の人による同じ件への言及を見ていて少しずつ、表題の話が腑に落ちるようになった。と同時に、改めて、先の言い換えを推進する流れの妥当性の怪しさを感じた。

自分がどう理解しどう腑に落ちたのか、今どのような疑問を持っているのか、を記録のためにまとめる。

続きを表示する ...

GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた - Jun 12, 2020

Gitのデフォルトブランチ名は慣習的にmasterとされてるんだけど、これがmaster/slave(主人と奴隷)つまり奴隷制に由来する表現であるとして、2020年5月25日にミネアポリスで起きた白人警官による黒人被疑者の殺人事件を契機に盛り上がりを見せているBlack Lives Matter運動の流れを承けて、別のブランチ名に変更しようという動きがある、という事を知った。実際に、GitHubの公式のコマンドラインツールで既定のブランチ名がtrunkに変更された(……と例に挙げたけど、たまたまタイミングが一致しただけで、このプロジェクトでの変更は事件の前だったみたい)ほか、いくつかのプロジェクトも追従しているという。

結論から先に言えば、僕もこの判断に追従した。GitHubの僕のアカウント配下のリポジトリは現時点で186あって(hub api users/piroor | jq .public_reposで調べたらそう言われた。プルリクエスト用の一時的なforkが結構あるのでそれで多くなってる部分はあると思う)、ひとつひとつ手でやっていると埒が開かないので、それぞれローカルでは1つの作業ディレクトリにcloneされているのをいいことに、WSL1のUbuntuのbashで、GitHubのリポジトリを操作するAPIを叩けるhubを併用して以下のようなワンライナーで一気にやることにした。

export NAMESPACE=piroor;
ls | while read path;
do
  [ -d "$path" -a -d "$path/.git" ] &&
    echo "checking $path";
    (cd "$path";
     export ORIGIN_INFO="$(git remote show origin)";
     (echo "$ORIGIN_INFO" | egrep "Fetch URL: git@github.com:/?$NAMESPACE/[^\\.]+\.git") &&
     (export REPOSITORY="$(echo "$ORIGIN_INFO" | grep 'Fetch URL' | egrep -o "([^/\.']+)\.git" | cut -d . -f 1)";
      echo "updating $NAMESPACE/$REPOSITORY";
      ((git branch | grep '* master' &&
        (git branch --move master trunk;
         git push --set-upstream origin trunk));
       (hub api "repos/$NAMESPACE/$REPOSITORY" | jq .default_branch | grep master &&
        hub api "repos/$NAMESPACE/$REPOSITORY" -X PATCH -F default_branch=trunk);
       (URL_BASE="https://travis-ci.org/$NAMESPACE/$REPOSITORY.svg\\?branch=";
        git grep -E "${URL_BASE}master" |
          cut -d : -f 1 |
          uniq |
          xargs sed -i -r -e "s;${URL_BASE}master;${URL_BASE}trunk;g" &&
        git commit -m 'Migrate master to trunk' $(git grep -E "${URL_BASE}trunk" | cut -d : -f 1 | uniq) &&
        git push))));
done

まずgit remote show originでリモートリポジトリとの対応付けを調べる。移行対象のリポジトリであれば、git branch --move master trunkでブランチ名を変更して、GitHub上のデフォルトブランチもtrunkに切り替えて、Travis CIのビルドステータス画像のURLに含まれているブランチ名もついでに更新する、という感じ。他にもまだ変えないといけない所は残ってると思うけど、それは気付いた時に追々直していこうと思ってる。

同様に各リポジトリをclone済みの他の環境では、ローカルリポジトリの情報を変更するだけなので、以下のようになるか。

export NAMESPACE=piroor;
ls | while read path;
do
  [ -d "$path" -a -d "$path/.git" ] &&
    echo "checking $path";
    (cd "$path";
     export ORIGIN_INFO="$(git remote show origin)";
     (echo "$ORIGIN_INFO" | egrep "Fetch URL: (https://github.com/|git@github.com:/?)$NAMESPACE/[^\\.]+\.git") &&
     (export REPOSITORY="$(echo "$ORIGIN_INFO" | grep 'Fetch URL' | egrep -o "([^/\.']+)\.git" | cut -d . -f 1)";
      echo "updating $NAMESPACE/$REPOSITORY";
      (git branch | grep '* master' &&
       (git branch --move master trunk;
        git branch --set-upstream-to=origin/trunk))));
done

ローカルにcloneされてないリポジトリは、今の所まだ手つかず。hubでどうにかできるだろうとは思ってるので、やったらまた追記する。

(6月15日追記)ローカルにcloneされてないリポジトリも全部やるワンライナーは以下のような感じになった(whileループが二重になってまでワンライナーて……)。

export NAMESPACE=piroor;
export TOTAL_REPOS=$(hub api users/piroor | jq -r .public_repos);
export PER_PAGE=100;
seq 1 $((($TOTAL_REPOS / $PER_PAGE) + 1)) | while read page;
do
  hub api "users/$NAMESPACE/repos?page=$page&per_page=$PER_PAGE" |
    jq -r .[].name |
    while read name;
    do
      [ "$(hub api "repos/$NAMESPACE/$name" | jq -r .default_branch)" = "master" ] &&
        echo "updating $NAMESPACE/$name" &&
        (export workdir="$(mktemp -d)" &&
         echo "  workdir: $workdir" &&
         (cd "$workdir" &&
          git clone "git@github.com:$NAMESPACE/$name" --branch master --single-branch &&
          cd "$name" &&
          git branch --move master trunk &&
          git push --set-upstream origin trunk &&
          hub api "repos/$NAMESPACE/$name" -X PATCH -F default_branch=trunk);
         rm -rf "$workdir");
    done;
done

API叩いて直接リポジトリをリネームするやり方が分からなかった(そういうのはない?)ので、一時的にcloneして作業するという形で解決してみた。プルリク用にforkした物までゴソッとやっちゃうので、気になる人は除外処理を入れて使おう。

自分はこのように移行したけど、既存ツールチェインが壊れる危険とかいろいろあるし、これが本来意図された通りの効果がある変更だという確証もないので、みんながみんなやるべきとまでは思ってない、という事も書き添えておく。

以下、技術的な話から離れて、このような言い換えの必要性と妥当性について今回色々調べた事・考えた事を、記録のために書き残しておく。

続きを表示する ...

ポジショントークに騙されないようにしたいし、狭い視野でポジショントークじみた極論を言うよりも、メリットとデメリット両方を把握した上でソフトランディングを図っていきたい - Jun 06, 2020

ツイッターでつぶやいてた話

匿名と実名、どちらか一方を称揚する発言に対する評価の話

ネットは実名であるべきなのか匿名であるべきか、という話は何年かに一回くらい目にする議論な気がする。

自分は、「Piro」というハンドル(ペンネーム)で、匿名でWebを使い始めて、「OSSのライセンス文には本名を書かないといけないらしい」という誤解があって途中から実名も公表するようになったので、実名のメリットもデメリットも、匿名のメリットもデメリットも、全部一通り我が事として体験してきたと思う。

その上で思うのは、「匿名の連中は無責任だから全員実名を強制するべきだ」「いや匿名の方がいい、実名を使いたがるやつは売名目的だから出ていけ」みたいな、「自分がどうするか」ではなくて「みんなどうするべきか」でどっちかに寄せたがる発言をする人や、そういう言説は、あんまり信用しちゃいけないな、ということ。

  • 確かに実名の公表には、「子供もいないし子育てもしたこともない人が教育論を語っている」「社会に出たこともない人が仕事論を語っている」ようなまやかしを防ぐ効果がある。それに「馬鹿な事をしないように慎もう」と思わせる一定の力もある。
    • けれど、馬鹿な事をやらかす人は実名でもやる。Webが一般的になる前のパソコン通信時代やネットニュース時代に一番ヤバい事をしていたキチは、実名だったという。実名公表は、最後の一線として究極的には機能しない。
  • 確かに匿名の言論には、「既に知名度のある人が、社会的地位を濫用して道理の通らぬ事を押し通す」事を阻む効果がある。「その人の社会的地位から切り離された、純粋な言論だけでやり取りされるフェアな世界」がもたらされるように見える。
    • けれど、それは同時に「過去何度も同じやらかしをしてきた人が、素知らぬ顔でまた同じやらかしをする」「過去何度も他人を騙してきた人が、次の獲物を狙う」「その時その時でコロコロと言う事が変わり、理屈に一貫性がなく、確たる裏打ちがあってそう言っている訳ではない、という事実を包み隠す」ことをも容易にする。「フェアな世界」に見えていた物は、詰まるところ、相手を口八丁で言いくるめる技に長けた人が有利なだけの世界に過ぎない。

まずかつての自分のように、こういうそれぞれのデメリットを分かっていなかった(言葉で知っていても実感はしていなかった)時点で、わかりやすいメリットだけ並べて「だからみんなそうするべきだ」って言ってる人は、視野が狭く考えの浅いアホなので、信用するに値しない。

また、匿名のデメリットも実名のデメリットも分かった上で、デメリットを伏せてメリットだけ並べて「だからみんなそうするべきだ」と言ってる人は、自分の持つ武器(社会的地位なり、相手を言いくるめる術なり)が最大の効力を発揮し、自分の持つ不利(社会的地位の無さなり、理屈のガバガバさなり)を最大限ごまかすのに、たまたまそっちの方が都合がいいからそう言ってるだけの事が多い(そういう発言を「ポジショントーク」と呼ぶ)。自分の都合のいいように世論を動かして自分が利益を得たいだけで、煽られた他人が実際に被る不利益の事なんか知ったこっちゃないのに、それを隠してる不誠実な人なので、これも信用してはいけない。

善意のアホが悪意のポジショントーカーに乗せられてる事もあるし、アホが無自覚にポジショントーカーになってしまってる事もある。結局ポジショントークをする人にロクな人はいない。「ポジショントークをしない事」イコール「信用に足る」という事では必ずしもない(信用する十分条件ではない)けれども、ポジショントークをしてる人の事は真っ先に「あ、この人は信用しちゃ駄目だ、信用しない人リストに突っ込んじゃっていいや」とバッサリ切ってしまっても、大抵は不都合がない(信用する必要条件ではある)。今の自分の感覚をなるべく正確に言い表すと、こんな感じになると思う。

続きを表示する ...

ES moduleとして簡単に静的に検証できるテストを書けるようになって(個人的に)幸せが増した話 - Jun 03, 2020

この記事はQiitaとのクロスポストです

テスト実行後に気付くのってあほくさいじゃないですか?

ES moduleのコードでは「関数名や変数名の誤記」をESLintなどで容易に静的に検出できます。なので、JSで書ける物は片っ端からなんでもES moduleにしたくなるのですが、いわゆる自動テストのコードでは、この性質がかえって邪魔になることがあります。

たとえばMochaのテストケースには、何の前触れもなくdescribe()it()などの関数が登場します。これらが「未定義の関数呼び出し」としてエラーにならないようにするには、テストと実装でESLintのルールを切り替えて警告条件を緩和したり、テスティングフレームワークの関数やオブジェクトを警告の例外に明示したりといった対策が必要になります。

しかし、警告を甘くすればテストだけ静的な検証が甘くなりますし、警告の例外を指定するのもテストの作成やメンテナンスが煩雑になります。テストの書きやすさ・維持しやすさと静的な検証の完全性とを両立しにくいのは、JSで物を作る時に個人的にずっと気になっていた点でした。

Pure ES modulesなテスティングフレームワークつくった

というわけで、このような難点がないPure ES modulesなテスティングフレームワークを作ってみました。

Node.js v13以上の環境で、npm install tiny-esm-test-runnerでインストールできます。

元々は、特定プロジェクトでのCI用に簡易的なテストランナーを書いて使い捨てにしていたのですが、それを複数プロジェクトで使い回すうちに、さすがメンテナンスが面倒だと感じるようになってきたため、この度一念発起してきちんと整備したという次第です。

基本的な使い方

テストはES moduleのファイルとして記述します。以下に例を示します。

続きを表示する ...

Page 1/245: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき