Home > Latest topics

Latest topics 近況報告

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

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

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

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

「なぜ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のファイルとして記述します。以下に例を示します。

続きを表示する ...

性役割が逆転された世界、の描き方に現れる視点の違い - May 08, 2020

ほんとに「女が強い時代」って、こういうこと? 「女が支配する社会」を描いたディストピア作品3選 - wezzy|ウェジー という記事が話題になっているのを観測した。自分の観測範囲では批判的な感想が多かったように感じるけれど、それは「この記事を批判的に見た人が、記事を紹介し、同様の批判的意見を紹介している様子」を観測したせいかもしれない。

男女の性役割逆転というのは昔から度々描かれているようで、家畜人ヤプーはその代表的な一作と言えるようだ(僕は江川達也氏による漫画版だけ見た)。僕は先の記事に挙げられている3作品はいずれも未見だけれども、近年の観測範囲でも、立て続けに2作品ほど男女の性役割逆転を描いた作品を見かけた。ただ、先の記事の3作品や「家畜人ヤプー」と、僕の観測した2作品とでは、描き方にどうも差があるように感じられた。

 

僕の観測した1作目は「貞操逆転世界」(原作:天原、漫画:万太郎)で、主人公が「性」に関する事だけ男女の性役割の逆転した世界に迷い込んでしまうという内容。先の記事で紹介されている「軽い男じゃないのよ」とプロットは似ていて、「街中に無意味に男の水着の広告が溢れている」のような描写も共通しているようだけど、設定としては以下の点が大きく異なる。

  • 主人公は男性ではなく女性。
  • 主人公は社会人ではなく学生(高校生)。
  • 体力・体格差などの肉体的な性差は逆転していない(性的な消費・被消費の関係以外は現実世界を踏襲している)。

これらの事から、本作は「今まで優位な立場だった人が、劣位の立場に戸惑う」という内容ではなく、「今まで消費される性の立場だった人が、消費する性の立場に戸惑う」という内容になっている。

敢えて「優位・劣位」と書かなかったのは、本作では「高校生」という、性差が経済的な差や権力差にあまり結び付いていない年代の視点であるために、必ずしも「性役割が逆転したら女性が優位になっている」とは限らないからだ。

続きを表示する ...

「もっと考えろよ」「想像力なさすぎだろ」みたいな言い方を僕はしたくないなっていう話 - May 06, 2020

IQが20違うと会話が成立しない、みたいな話は昔からよく聞くけど、そもそも「自分自身が一般よりIQが高い天才です、一般人と会話が通じなくて困ってます」って当事者になってることがあんまり無いと思うので、実際そうなのか?ってのはよく分からない人の方が多いんじゃないかと思うんですよね。僕もそのクチで。

ツイッターみてたら、そういう場面において、一般よりもIQが高く「ギフテッド」と呼ばれる人の側が当事者として実際どう感じているのか、をご自身の体験から詳しく説明されている記事が流れてきて、読んでみたら、前々から「きっとこういうことなんだろうなあ」と考えてた事とわりと合致する話が書かれてたんですよ。

というのも、これって「自分がアニオタで、アニメにまったく興味がない人に話が通じない」みたいな場面にすごく似てるなって思ったんですよね。

  • 自分はその作品にも、作品が生まれた背景にも、今のオタク業界にも色々詳しくて、業界用語もめっちゃたくさん知ってる。オタク仲間同士なら呼吸をするように自然に会話が成立する。
  • でも、そういう前提を共有してない人と話すとなるとものすごく大変。好きな作品の好きなキャラの事を語ろうとしても、作品の説明に時間がかかるし、キャラの説明に時間がかかるし、「◯◯という作品の××というキャラのように……」みたいに言うとその「◯◯」や「××」自体も詳しく説明しないと分かってもらえないし……

こういうの、すごく身に覚えがあるんですよね。「オタク知識」の話でなくても、社会人だったら自分の業務分野・専門分野の知識とか、自分は滅茶苦茶詳しくてお客さんは全然詳しくないので説明に苦労するってのはすごくありふれた話だと思うんです。自分も今まさに、テクニカルサポートの業務でお客さんに説明する場面でそういう事はよくあるし、Linuxのシェルコマンドの解説漫画を描く上で大変な事もまさにそういう事だし。

で、「自分側が知識がありすぎて、知識が無い側の人に話が通じなかった」体験をそういう風に想起できる一方で、「自分側の知識レベルや頭の回転速度が低過ぎて、有能な相手がする話の内容がまるで理解できなかった」体験もまた、自分には想起できるんですよね。学校で先生の言う話が分からなくて授業についていけないとか、仕事の上で先輩の話しに全然ついていけないとか。むしろこっちの方が多いくらい。

なので、自分としては「IQが20も違うと会話が成立しない」という話の両方の当事者の感覚を想像しながら、先の記事を読んだんです。

それで思ったのが、「この記事を書かれた方(ギフテッドの人)には、もしかして、自分の話を相手に理解してもらえなかった経験はあっても、相手の話が自分には理解できなかった経験が無かったりするんだろうか?」という事で。

そもそも記事自体が「IQが高い側の弁明」という体裁だから敢えてそう書いたのかもしれないんですが、「やばい、相手の言ってることがまるで自分には理解できない。どんなに説明されてもチンプンカンプンだ」という感覚が、あまりその記事からは感じられないような気がして。

続きを表示する ...

Virtual DOMでなく生のDocumentFragmentを与えてDOMを差分更新したいって話 - Mar 09, 2020

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

概要

FirefoxのアドオンやChromeの拡張機能向けに、名前空間をまたいでDOMに変更を差分適用したい場面で使える、Virtual DOMでないReal DOMで差分適用する、webextensions-lib-dom-updaterという名前のライブラリをつくりました。

どう使うの?

クライアント側でタブの情報を取得して、サーバー側でそれをレンダリングする、という場面であれば以下のようになります。

クライアント側(制御担当):

// IDからタブのオブジェクトを得る(WebExtensionsのAPI)
const tab = await browser.tabs.get(tabId);
// プロセスをまたいで、レンダリングして欲しい内容を送る
browser.runtime.sendMessage(
  '受信側の識別子',
  // ↓テンプレート記法でHTMLのコード片をそのまま生成
  `
    <span id="tab"
          class="${tab.active ? 'active' : ''}">
      <span id="throbber"
            class="${tab.status}">
        <span id="throbber-image"
              class="${tab.status}"></span>
      </span>
      <img id="favicon"
           class="${tab.status}"
           src="${tab.favIconUrl}">
      <span id="label">${tab.title}</span>
    </span>
  `.trim()
);

サーバー側(画面描画担当):

import { DOMUpdater } = './dom-updater.js';

// 他のプロセスからのメッセージを待ち受ける(WebExtensionsのAPI)
browser.runtime.onMessageExternal(message => {
  // 反映先の要素
  const before = document.getElementById('container');

  // 反映する内容をDocumentFragmentにする
  const range = document.createRange();
  range.setStart(document.body, 0);
  const after = range.createContextualFragment(message);
  range.detach();

  // DocumentFragmentの内容でbeforeと異なる部分があれば、
  // それをbeforeに差分適用する
  DOMUpdater.update(before, after); // ←これを作った。
});

どの辺に新規性があるの?

Virtual DOMでなく生のReal DOMを更新内容として指定する(※例ではDocumentFragmentを使ってますが、普通のElementでも構いません。)ので、Virtual DOMの独自記法を覚えなくていいです。利点はそれだけです。

既に同じ事をするライブラリが世の中にはあったのかもしれませんが、自分には見つけられませんでした。どなたかご存じでしたら教えてください……

→と書いていたら、morphdomという似た趣旨のライブラリが既にあると教えて頂きました。今回実装したものとの比較を最後に追記しました。

なんで作ったの?

Tree Style TabというFirefox用アドオンで、「他のアドオンから指示して、タブの中に任意のUI要素を追加する」という事をやるために作りました。

(スクリーンショット:Tree Style Tabでの利用例) 見た目を元々のタブに合わせているのでちょっと分かりにくいですが、このスクリーンショットの左側で「Add-ons - Mozilla | MDN」というラベルを伴って表示されている「細いタブっぽい物」が、別のアドオンから指示された通りの内容を、このライブラリによる差分適用で埋め込んだ部分です。

アドオン間での通信ではJSONオブジェクト形式のメッセージしか扱えないため、こういう事をやろうとすると

  • 挿入するUI要素の内容を、どんな書式でどうやって指定させるか
  • 挿入されたUI要素を、どんな書式でどうやって指定して更新させるか

ということを決める必要があります。

Virtual DOM使えばいいやん

DOMの変更の差分適用といえば既存のVirtual DOM専用のライブラリは既にいくつもあって、

このあたりの記法をそのまま使えばいいといえばいい話です。

が、どれもべつに「スタンダード」というわけではないようなので、どれを選んでも後で文句を言われそうな気がします。宗教戦争がもしあるなら、そこに参戦したくはないですし、ただでさえ「Tree Style Tabが他のアドオン向けに提供する独自のAPI」というめちゃめちゃニッチな場面なので、こんな限定された場面のために新たに(もし普段から使っている物があるなら、それとは別のライブラリ由来の)独自の記法を覚えてもらうのは忍びないです。というか、自分がこれ以上覚えたくありません。

その点、HTMLのソースを文字列で指定してDOMの標準的な機能でNodeやDocumentFragmentにするという事にしておけば、多少冗長ではあるものの、「デジュールスタンダードなんで」と言ってしまえます。技術選択で悩まなくてもよくするためだけの選択というわけです。

続きを表示する ...

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

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき