たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
高級生食パンの乃が美と、量産型高級食パン専門店のひとつの真打ち登場を4日ほどかけて食べ比べて、自分にははっきりした優劣は感じられなかったので、今後は(も)単純に店に行きやすい方で買って食べることになるだろう、という思いを新たにした。というのが結論で、以下は余談です。
「高級食パンがブームだ」という話はテレビで時々目にしてはいたものの、別世界の出来事だな、と思っていたら、近くにそういう店ができちゃったんですよね。それで興味本位で買ってみたら、確かにおいしいっすねと感じまして。
そもそも、脂肪と糖が多く含まれてればそれを美味と感じるバグが人間にはあって、「高級」食パンゆうても結局はバターたっぷり牛乳たっぷりブチ込んでそのバグを衝いてるだけに過ぎない、というのはブームになり始めた頃に度々聞き及んでましたし。
そういうシンプルな仕組みだから模倣も容易なのか、それで高級食パンのプロデューサーなる怪しげな人があちこちでヘンテコな名前の量産型高級食パン屋をプロデュースしている、という話も聞いてましたし。
その量産型高級食パン専門店のうちの一店が近くにできて、なんだかなあと思いはしつつも、これはこれで流行り物のエンタメかなと思って、たまに無性にパンを食べたい気分になったら買ってくる感じで、それなりに楽しんでおりました。
そんな折、
みたいな言説を立て続けに目にしたんですよね(いやはっきりそう言ってはいない物を勝手に僕が曲解しただけかもしれないんですけど。そういう文脈であるように僕は感じたのです)。
確かにドギツイ色と珍妙な店名はどうかと思うけど、出店された地域の側を貶されたり、食って満足してる人間の舌を馬鹿にされたりというのは、いい気分がしません。
もちろん、美味い不味いは主観なので、量産型を不味いと思う人がいても、自分にとって美味いと感じられるなら何も問題は無いはずです。
けれども、僕はすっかり呪いをかけられた気分になってしまいました。
「本物」を食べた事もないのに、量産型だけ食べて美味いと言っている、「本物」は格段に美味いかもしれないのに、それより格段に劣るかもしれない物を、安くない金額で買っているなんて、ああなんと哀れな事だろう、と。
そんな呪いの言葉が頭をチラつくせいで、僕はそれまで平気で食べられていた量産型を買いにくい気分に、すっかりなってしまったのです。
直接自分個人に向けられたわけでもない揶揄のせいで、ジレンマを感じてしまうなんて、馬鹿馬鹿しい話です。
買いたいと思って買うにせよ、買いたくないと思って買わないにせよ、自分のしたい行動をしたいように取れればそれでいいのに、それができないなんて。
この呪いを解くには、「本物」と持ち上げられてる物と量産型とを実際に食べ比べるしかない。
どうせ、そんな何万円とするような買い物でもあるまいし。
食べきれなくても、冷凍すれば保たせられるし。
無理せず買える程度のお金が手元にあって、買いに行ける距離に店舗があるのだから、とっとと白黒付けてしまった方がスッキリできます。
気をつけたいのは、食べ比べるにあたって「どちらが真に美味かを客観的に評価する」「すべての量産型の味を評価する」ことは目的にしないということです。前述の通りの個人的な屈託を解消するために、「本物」とされる物と、「量産型」とされる物の中でも自分が買う可能性がある物の味の差を体感して知り、自分の意志で判断を下せる状態になることだけを目的にします。
仮に量産型が本物より著しく不味いと感じられたとしても、「それでも近いから買おう」なり「値段に見合わないから買わないでおこう」なりの判断を下せるようになるなら、それは目的が果たされたうちに入ります。
逆に、自分が買いに行く可能性が無い量産型の物をいくら食べた所で、当初の目的の達成にはつながりません。
網羅的に調達するとか、厳密に条件を揃えるとか、二重盲検法だとかいった、データの客観性を高めるための努力をするつもりは最初からありませんでした。
1ヵ月ほど前の話になりますが、11月6日に行われたCROSS Party 2020という(オンライン)イベントにおいて、「90分、ITマンガ家に学ぶ技術の伝え方〜これであなたもマンガ家になれるかも?〜」というタイトルの枠で、わかばちゃんと学ぶシリーズの湊川あいさん、インフラ女子の日常のなつよさん、モデレータのゆうこりんさんとご一緒させて頂きました。丸一日のイベントを取り仕切られた運営の皆様、たいへんお疲れ様でした!
当日の様子はセッションの配信内容のYouTube Liveアーカイブ(の4:42:15頃から90分)でフルでご覧頂けます。
ちなみに、この時間の直前の枠はotsune氏を含むお三方による、SNSでの炎上をテーマとしたパネルトークでした(アーカイブを90分ほど巻き戻すとその様子を見れます)。自分のセッションの準備のために途中までしか見られなかったので、後で見ようと思っていたものの、まだ見られていません。
リアルタイムでご覧になられた方の感想も拝読しております。皆さま、長時間お付き合い頂きありがとうございます!
元々はゆうこりんさん→湊川さん→僕 と話が回ってきて、さらに以前から交流があってお声がけしやすかったなつよさんが加わって、この面子になりました。「ITでマンガ」というと他にも有名な方がたくさんおられるので、次回以降また人が入れ替わって開催されると面白そうだなあ、と思っています。
話が回ってきた時点ではセッションの趣旨はまだ決まっておらず、異なる立場を代表する話者でのパネルディスカッション(議論)にするのか、議論形式でなく座談会のようにするのか、などのことを打ち合わせで喧々諤々した結果、イベントの視聴者層がITエンジニアであること、3人とも現役ITエンジニア業をしながらマンガを描いていること、イベント自体のテーマが「明日の自分を今日変える」であることを踏まえて、「セッションを見た人に、マンガを描くノウハウや、技術を絵で解説するノウハウを紹介して、自分もITでマンガをやってみようとか、普段の仕事に取り入れてみようとかの気持ちを持ち帰ってもらおう」という方向のパネルトークセッションになりました。各人がそれぞれの「マンガの描き方」「技術の話をマンガに持って行くまでの流れ」を語っているので、まだ誰もマンガで描いていない分野に皆さんが切り込んでいく上での参考になるのではないかと思います。なるといいなあ。
僕以外の登壇者お三方は皆アバター登壇で、僕だけ顔出しだったのですが、これは僕がLive2Dとかの技術についてけてないロートルおじさんだからです。白壁の前に移動して3000円くらいのLEDリングライトで顔を照らすという、アナログ極まりない方法で登壇しています。美容院の予約が間に合わず、半年くらい伸ばしっぱなしの髪のまま出ましたが、その2日後にバッサリ切ったので、今はだいぶ短くなっています。
タイムテーブルに「懇親会」とあったのですが、オンラインでどうやるんだ?と思っていたら、Zoomのビデオチャットに全員一斉参加した後、ランダムに複数人ずつブレイクアウトルームに割り振られて、ルーム間の移動は各自に任せる、という形になっていました。この形態は、同じルームの人と話す分にはいいのですが、
という難があり、やはりオフラインで行われる懇親会とは質が異なっていて完全な代替にはならないな、と感じました。僕と同じルームになってしまわれた人は、僕のヨッパライ独演会に付き合わされた形になってしまったのではないかと思います。
オンラインでのイベント参加は、自分はこれの他にはOSS GateワークショップでDiscordのボイスチャット・ビデオチャットを使ったことがありますが、上記の問題は共通しているように思いました。オンラインイベントには「廊下」が無いという声を何度か観測していますが、「廊下」の方で話されている話題に混ざりたくても(共通の「廊下」が無いためにその存在を把握できず)混ざれない、というのも似た問題のように感じています。「他のルーム」や「廊下」で話されている内容がリアルタイムに文字起こしされて流れるテキストチャンネルでもあれば少しはマシになるのではないか、という気がするのですが、誰かやってくれませんかね……
結論: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だそうです。)
次にググる人が少しでも優位な情報に辿り着きやすいように、ここに記録を残しておく事にする。
アツギ社が「タイツの日」に合わせて行った「ラブタイツ」キャンペーンが、各方面から批判されて中止になった件について、批判側に立っていた人の一人として書いてみます。
なお、アツギ社による公式の謝罪が既に出ていますので、このエントリはこれ以上の批判・非難を意図しません。自分がこの企画の何をどのように問題だと考えたかの自己分析・記録・説明と、表現に関わるあらゆる人が似たような事を繰り返さないための判断材料の提供を意図しています。
最近、「鋼鉄人形論法」という言葉を知った。
自分と反対の立場の意見について、その中でも最も愚かな主張をしている人を取り上げたり、時には実際には存在しない支離滅裂な言説をでっち上げたりして、容易に批判できる対象に対してマウンティングを取ることで、「だからあの連中は阿呆なのだ」と身内や周囲にアピールする論法を、藁人形論法と言うのだけれど、鋼鉄人形論法はその逆だそうだ。つまり、自分と反対の立場の意見の人の中でも、最も理性的で賢い人の主張を取り上げたり、相手の主張を理論的に補強したりして、容易には批判できない強固な敵と敢えて相対することで、自分の主張を鍛えていく、ということらしい。
反論をある程度想定した上で持論を述べる時には、なるべくそのようにした方がいいだろう、と自分もなんとなく思っていたので、それに鋼鉄人形論法という名前が付いてセオリーとして認知されていると知って腑に落ちた感覚がある。
別の話で、「トーンポリシング」という言葉がある。
これはMeTooやBlack Lives Matterといった反差別の運動の文脈でよく聞かれる言葉なのだけれど、例えば抗議者が「差別をするな! この差別者め! 貴様のような奴は生かしておけん!」みたいな強い口調で迫ったときに、抗議を受けた側(差別をしている側)や周囲の人が、「そんな攻撃的な言い方じゃ聞く気になれないよ」と言い方(トーン)を穏やかに改める(ポリシング)ようになだめることを、そう呼ぶようだ。抗議者(被害者)と被抗議者(加害者)の間に圧倒的な権力差がある状況では、穏やかな言い方に改めたら単に抗議が無視されるようになるだけだ、ということで、反差別の言説を無効化し差別を維持・強化する悪行であるとされている。
鋼鉄人形論法に則って相手の主張の論理を深く掘り下げていくと、多くの場合、相手の視点での合理的な判断の結果として自分とは異なる結論に至っていることが分かってくる。衝突を解消するための交渉においては、相手の合理的な判断と自分の合理的な判断とが衝突しなくなる落とし所を探る必要がある。
ただ、合理性では落とし所を見つけられない場合というのも多くある。僕はそれを、感情的に折り合いが付かない場合だと考えている。
例えば「あなた1人が死ねば100人が助かります。死んで下さい」と言われて、なるほど合理的だと納得して粛々と殺されようという人は、あまりいないのではないだろうか。少なくとも僕は納得して殺されようとは思えない。死ぬのが「怖い」し「嫌だ」、という感情があるからだ。感情に根ざす衝突は、どんなに鋼鉄人形論法を突き詰めても合理的な根拠には辿り着けない。
……という書き方をすると、「つまりそういう奴らは合理的な判断ができずに感情に流される愚かな連中なのだ」という話だと思われるかも知れないけれど、僕が言いたいのはそういうことではない。僕は今のところ、「感情で判断するな、合理性で判断しろ。感情なんてくだらない」とは思っていない。感情は合理性に劣るものではなく、合理性と直交する概念だと思っている。人は、合理性の面では利が小さくても感情面で利が大きい判断をすることが多々ある。僕自身は、合理性が高くても感情面で納得できない判断よりも、感情面で納得度の高い判断の方が、満足感・納得感が大きいという実感がある。
(これをもっと突き詰めると、「合理的な方が良い」と常に判断している人すらも、「合理的な方が好きだ」という主観的な感情に引きずられているのではないか? という話になってくると思っている。ただ、これは本題ではないので、これ以上掘り下げないことにする。)
ともかく、両者の意見が衝突して落とし所が見つからないケースの中には、感情の折り合いが付かないことが根本的な問題であるにも関わらず、「双方あるいは片方が」「自覚的か無自覚かはともかく」感情の問題に向き合おうとしていないケースがある、と僕は思っている。
特に、「感情的になるのは愚かなことだ、感情で判断するのは愚かなことだ」というスティグマに囚われている人は、無自覚のうちに、自分の中の根本原因の存在にも、ましてやその解決からも目を背けてしまいがちではないかと思う。(というか、過去の僕はそうだった。)
そういうケースでは、感情面の問題が解決されるだけで、意外なほどスルッと話がまとまることがあるようだ。例えば、サポートセンターに電話をかけてきて、上司を出せ謝罪しろとがなり立てていたクレーマーが、電話口で一通りの感情を吐き出すとおとなしく引き下がっていった、みたいな話は度々見かける。そのクレーマー自身は、自分の感情を満足させたかっただけだとはきっと認めないだろうけれど、事実としてそれはやはり感情の問題だったのだろう。
先の「あなた1人が死ねば100人が助かります。死んで下さい」の例で言えば、多くの人は、それで救われる100人から「早く死ねよ」と石を投げられている状態よりも、感謝の言葉をかけてもらったり、「死後永遠に語り継いでいきます」みたいな事を(嘘でも)言われた方が、感情的に納得して決断をしやすくなるのではないだろうか。「お国のために」「郷里に残した家族のために」と涙を呑んで散っていった特攻隊の若者達のように。まあ、人によっては、「俺を犠牲にして自分が生き残りたいだけのくせに白々しい。そんな欺瞞に満ちたおべんちゃらを言われるくらいなら、石でも投げられた方がマシだ」ということもあるかもしれないけど(そういうタイプの人にとっては、そのように感情を徹底的に傷付けられることこそが、感情面で折り合いを付けるために必要な事なのかもしれない)。
差別の話についても、ここまでで述べたような感情の話が当てはまるのではないか、と僕は思っている。
といっても、ここで僕が注目したいのは、差別を受ける側の感情ではなく、「差別をした」と抗議を受ける側の感情だ。差別をしてしまう・やめられない・抗議を素直に受け入れられない側にある「自分がこれまで慣れ親しんできた文化が侵される嫌悪感」とか「自分と異質な物に対する忌避感」とか……もっと平たく言えば「怖い」「嫌だ」といったプリミティブな感情のことだ。
ここまでで述べたとおり、僕は、そういった感情も判断に大きな影響を与える要因で、且つ、決して軽視はできないと思っている。抗議される直接の加害者や、直接の加害者以外にも、その加害者を包摂する社会を構成する一員・間接的な関係者として抗議を受ける側となる、周囲の傍観者も含めて、「抗議する人とその支持者」以外のすべての人の感情を傷付けたり逆撫でしたりする言動は、問題の解決を遠のけることすらあると思っている。
「だから、抗議をするときは相手の感情を傷付けない言葉を選んだ方がいい」……というまとめ方をしたら、そう、トーンポリシングと非難されるアレになってしまうのですよね。これが、長々と書いてきてここで僕が言いたかった事。
僕自身は、何かを抗議した時に、まともに取り合う気のない相手からあれやこれやの言い逃れで抗議を無効化されれば腹が立つ。でも「言い逃れ」できる余地を残してしまっているのは自分の側の落ち度だと思うので、正攻法でいくなら、言い逃れができないように丁寧に外堀を埋めて臨むしかないのではないか、と思っている。表現を見直すこともあるだろうし、あるいは、根回しをすることもあるのかもしれない(自分はその手の政治がとても下手なので、できる気がしないけど)。傍観者から「自分の非も認められないガキが駄々をこねている」と思われてしまっては勝てない、という思いがある。
でも、「そんな悠長な事をやっていられない事態なのだ、これは今その場にある命の危機の問題なのだ」というのが差別の文脈ではよく聞かれる話で、確かにそれはそうだと思う部分もある。卑近な例えをしてしまうけれど、自分がかつて虐めを受けていた頃に、「まずは周りを味方に付けて」とか言われても「は? ふざけんなし。味方なんかおらんし。戦って自力救済するしかないし」としか思えなかっただろうと思う。その頃の自分にとっては、自分の非を少しでも責める者はすべて「敵」で、自分の事を全部許して認めてくれる者だけが「味方」だったような気がする。
差別に抗議している最中の人達が、その頃の自分と同様の心境なのだとしたら、抗議を受けている世界を構成する一員であるところの、つまり、差別者の一員である僕から、どんな言われ方であろうとも、抗議の仕方を咎めるような言い方をされて、受け入れる気分にはならないのではないかと思う。
かといって、ここまでで述べたようなことを考えている僕には、傍観者の敵意を増すような抗議の仕方を積極的に擁護する事もできない。
なので僕は、抗議している人達に直接は賛同も批判もしないで、黙って自分の良心に従って行動するだけに留めるのがいいんだろう、と思っている。差別的言動を見かけた時には自分の言葉で咎め批判し、自分が差別的な言動をしてしまったときには粛々と反省し、自分の信じるメッセージを込めて、不用意に差別を再生産しないことを心がけて表現していくしかないな、と。
オチはないです。
(1つ前の翻訳記事の末尾には当初、自分の個人的な考えを長々と書いていたのですが、翻訳記事でそういうことをやるのはマナー違反という指摘を頂きました。自分でも確かに、思い入れのあまり熱くなって書きすぎと感じていたので、別記事に分けるついでに増補改訂することにしました。)
原文に寄せられていたHacker Newsでの反応や、僕の翻訳に寄せられていた反応を見ていると、XULを捨てる判断を間違いと断じる物や、そのような判断をしたMozillaに対する恨み節、あるいは「バカな判断をしやがって、そんなだから俺らパワーユーザーから見捨てられたんだ」みたいな捨て台詞じみた物が結構見られました。
それらを見て僕は正直、「これだけ丁寧に書いてあってまだそんな風に思えるってどういうことなの……」と驚くやら呆れるやらしたのですが、自分自身もかつてはそっち側にいた自覚があったので、「なんでそう思うのか」も分からなくはありません。
今でも「見境のない拡張機能の仕組み」を支持し続けている人というのは、アドオン開発者にしてもユーザーにしても、ある意味で楽天的というか、性善説を信じているというか、そういう感じなのかなあと思っています。
「従来路線でいっても生きていけただろう、少なくとも玄人向けとしてなら生き残れただろう」という意見については、以前の記事で「それでは結局現実に生き残れない」とバッサリ切りましたし、1つ前の記事のコメント欄にも書いてみました。しかし、それとは別に「諸々の進歩を継続しつつ、アドオン開発者やユーザーに自己責任での自由を残すのでは駄目なのか?」という主張もあります。自分もFirefox Quantum以前はそのような立場でした。
この場合の世界観は以下のように要約できるかと思います。
しかし、自分の体験と先の記事の内容を踏まえて、今僕が思うのは、「甘い……まったく甘すぎる……」ということです。
僕自身、日々壊れていく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のいい所です。腹を括って「この方向でも生きていけるんだ」ということを示し続けていく人は、いてもいいとは思います。僕にはとても真似できませんが……
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信者だった頃の何かが残ってたんだなあ、と改めて思い知らされて、感慨深い思いをしたここ数日だったのでした。
(原著: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の内部事情の話に飛び込む準備ができている人向けに、これを機にもう少し詳しい話をしてみようと思います。
このところ狂ったような長文を立て続けに書いていて、いいかげん出涸らし感が出てきた気がするけど、このツイートからたらたら書き連ねたことの増補改訂版として残しておく。
Gitのデフォルトブランチ名「master」が奴隷制を想起させるさせないの議論を発端に、差別される側にとって「言葉狩り」に一体どういう意義があると考えられるのかを改めて考えたんだけど、釈然としないモヤモヤ、露悪的な言い方をしてしまうと「差別主義者って言われるのが怖くてビビって過剰反応してるだけなんじゃないの?」「現実にある差別構造の撤廃に切り込む方が大事だろうに、言葉遊びをしてるだけの人がなんで『これぞ先進的な人権感覚、皆も追従せよ』みたいなツラしてるわけ?」みたいな違和感はずっと残ったままだった。
なぜそんなにモヤモヤしてしまうのかというと、これって普段から日本でも見慣れてる、同調圧力に基づく自主規制の光景と変わらないと思うからだ。ナイフでの殺傷事件が起これば文脈を問わずナイフ描写がマスメディアから一斉に「自粛」で姿を消す。問題がありそうかなさそうかを個別に熟考する暇も無く。それとよく似てると思った。
1つ前のエントリにちょいちょい追記してるんだけど、見通しが悪くなってしまったので別エントリにした。
blacklistをblocklistにするとか、master/slaveを別の語に言い換えるとかの変更は、一体誰のためのもので、どういう意義があるのか? という問いに対して、1つ前のエントリを書き始めた時点でまだ自分は完全に腑に落ちる理解ができていなかったように思う。
その後、観測した反応や他の人による同じ件への言及を見ていて少しずつ、表題の話が腑に落ちるようになった。と同時に、改めて、先の言い換えを推進する流れの妥当性の怪しさを感じた。
自分がどう理解しどう腑に落ちたのか、今どのような疑問を持っているのか、を記録のためにまとめる。
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した物までゴソッとやっちゃうので、気になる人は除外処理を入れて使おう。
自分はこのように移行したけど、既存ツールチェインが壊れる危険とかいろいろあるし、これが本来意図された通りの効果がある変更だという確証もないので、みんながみんなやるべきとまでは思ってない、という事も書き添えておく。
以下、技術的な話から離れて、このような言い換えの必要性と妥当性について今回色々調べた事・考えた事を、記録のために書き残しておく。