Home > Latest topics

Latest topics 近況報告

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

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

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

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

動物園 - Jul 02, 2014

この間、動物園行ったんですよ。天気いいしどこかに出かけたいけど適当な所が思いつかないなあ、どこがええかなあ、そういや動物園もう何年も行ってないなあ、って。

大人になって動物園行っても楽しめるんだろうかどうなんだろうか、と思いつつ行ってみたんですが、当初の想定以上に楽しんでしまいました。年間パスを買ってもいいかもと思うくらいに。

だって(園にもよるけど)可愛い動物いっぱいいるじゃんすか。ミーアキャットが目の前でちょこちょこ走り回ってすっくと立ち上がってキョロキョロしてまた走り去っていったりとか、レッサーパンダが樹上でぐでーっとしてたりとか、ペンギンが腹ばいで寝てたりとか。たまらん。超癒される。まあアニマルセラピーとかいう物があるくらいですしね。

ほんで思ったんですけど、年間パスってそう悪い選択肢でも無いんじゃないかなあって思ったんですよね。例えば東京ズーネットの4園だったら4回行ったら元が取れる(ちなみにすみだ水族館だったら2回で元取れる)んですよ。心が荒んできた時にフラッと行って癒されて帰ってくるって使い方ができるわけですよ。ペット飼うより手軽。住む所がペット可の物件かどうか気にしなくていいし、ごはんやらトイレの世話やらをしなくていいし(動物園任せ)。美味しい所だけ楽しめるわけですよ。なんて都合のいい存在。

まあ気軽に行きやすい所に動物園があるならっていう大前提があるといえばあるんですけどね……

デスマーチテックキャンプをきっかけにしてモヤモヤと考えた事 - Jun 18, 2014

この「デスマーチテックキャンプ」という闇を生み出した背景が

これか……

うさんくささ

記事を紹介している記事やブックマークコメントで、この人の事を「山師」と評している人を見かけた。山師。辞書的には投機的事業をする人の事で、転じて、詐欺師の事を指す言葉だという。そこまで強烈な断定ではないにせよ、「うさんくさい人」というニュアンスを込めてその言葉を選んだのだろうなあ、とは思う。

これを見ていて、なんとなく、ある友人を想起してしまった。そういえばその友人も、「うさんくさい」と冗談まじりに評されるような所はあった。僕はその友人を今非難するつもりではなく、単に、ふと想起させられたというだけなんだけど、何がそう感じさせたのかは、うまく言語化できていない。

  • 「部外者・異質な存在であるところの自分だからこそ、その固定観念をぶち壊して革新できるのだ!」と突っ走っているのを、エンジニアとか技術とかをより多く知っているであろう周りの人達が「それは筋が悪くて駄目だ」って言ってる、っていう構図、なのだろうか?
  • その人自身はきっと悪意からではなく善意でやっているつもりなのだろうけれども、やり方であったり結果であったりが残念な事になってしまっている、という構図の方、なのかもしれない。
  • もっと一般的に言って、問題の当事者でない人が、当事者はきっとこういう事で困っているはずだ、とか、当事者はきっとこうなっていると嬉しいはずだ、とか、(見当違いの)仮定・断定をしてしまっている、という事についてなのかもしれない。
  • それが個人の枠内で収まっていなくて、イベントの主催であるとか、会社を興すであるとか、他の人を巻き込んでいる、という事についてなのかもしれない。

……と、色々挙げてみたけど、一言では上手く言い表せずにいる。

技術的に、筋がいいか悪いか

っていうか僕自身、僕よりも多くのことを知っている人から「それは(技術的に)筋が悪い」と言われるようなことを、素人の浅知恵でよくやっているようなので、そういう意味では全然他人事ではないとも思うんだけど。

「権威と化した先人の言うことに唯々諾々と従っていては、その縮小再生産しかできない。けれども、闇雲に既存のものを否定しても、それは、既に誰かが試して、駄目だったと諦めた道かもしれない。とは言っても、先人が諦めたのにはその時なりの理由があって、今では状況が変わっていて、今こそ挑戦すべき時なのかもしれない。でもでも、まだ時期尚早かもしれない。」……こういう鶏と卵な話って、世の中にはありふれてる。ダイナブック構想だとか、ハンドヘルドPCだとか、ウェアラブルがどうとか、湧いて出てくる度に訳知り顔の古参が「また出てきたよ……あれはもう何年も前にだれそれが通って失敗した道なのに。あんなのオタクのオモチャでしかない。」って辟易して、事実その通り失敗して消えて、また湧いて出てきて、そんな繰り返しの末にiPhoneが大流行するわ僕はいまAndroidなスマホをガンガン使っているわしてるし、世の中の人達はGoogle Mapsや!Ajaxや!HTML5や!って「再発見」して今Office 365で十数年ぶりにOutlook Web Accessを使っているし、何年かに一回は電子書籍元年がやって来ている。

そういう事例を知ると、何か「うさんくさげなもの」に出会った時に自分自身が直感的に「うっ、これはあかんやつや」と思ったとしても、自分の嗅覚の方が、「筋の良し悪し」を見分ける自分の目の方が間違っているのかもしれない、と思えてきてしまう。

それで、このデスマーチテックキャンプの人がほんとに「否定されるべき駄目な事例」なのかどうかまで、僕には分からなくなってきてしまうんだよね。 色々なことに、特に人の感情とか機微とかに鈍感な僕だから分からないだけで、普通の感性を持った人には、本能と言っていいようなレベルで分かる事なのかもしれないんだけど。

フェアネス

「筋がいいか悪いか」とはまた別の言葉として、「フェアネス」がキーワードになるのかもしれない。 フェアネス、辞書的には公正さのことで、多分合法とかそういう事だと思うんだけど、僕は個人的には、もっと一般的に「人の権利を侵害しない」とか「人に迷惑をかけない」のようなニュアンスを持って捉えている気がして、まあともかく、そこら辺の概念。

「YouTubeはグレーゾーンに踏み込んだから他者を出し抜けた。我々もあんな感じで、現行法ではグレーや黒でも他に一歩先んじたサービスを作ろう!」といった見方は、フェアネスを軽視しているように思う。

これをキーワードにすると、パッと思いつく別の事例がいくつかある。

僕の中では、このあたりの人々は同じカテゴリーと認識していて、今回のデスマーチテックキャンプの人もなんとなくそのカテゴリーっぽいという印象は持っている。 (とかなんとか言ってる自分自身も結構不義理をしているので、僕の事を「フェアネスに欠けている」「うさんくさい」「信用するに値しない」と思っている人もいるのだろうけど……)

リスペクト、尊敬、尊重

あるいは、「自分が理解できない物」に対する態度なのかもしれない。

一般的に言って、自分が理解できない物を、自分が理解できる尺度に無理矢理当てはめて評価しようとするというのは、礼を失した行為であると思う。 「ようわからんけど、要するに、こういうことなんやろ! オッケーオッケー!!」と乱暴に切り刻んで、分かったフリをする(本人はそれで分かった気になっているので、フリではないんだと思うけど)と、大事な物が抜け落ちてしまう。 それをよしとするのは、その対象を軽視している事に他ならない。

自分が理解できない物を、自分には理解できないと認めて、自分が持っている尺度では計れないという事実を受け入れて、その上で、それでもなおそれには価値があるのだという事を認め、尊重し、敬意を払って、どうやって共存していくかを考える必要がある。

……っていうのは、僕とは異なる趣味・嗜好・価値観・考え方・バックボーンを持っている妻との共同生活を送る中で、僕自身もここ数年ようやっと意識するようになった事なんだけど。

それまでも、そして今も、自分自身がそういう決めつけやあてはめをやってしまう方ではあるので、やはり他人をことさら断罪できるわけではないんだけど、自分が理解できない物や考え方に対する敬意の払い方というのも、自分がその人にコミットするかどうかを考える際の1つの判断基準になるんじゃないかなあ、と思う。

結論として

色々な判断材料に基づいて、「うさんくさい」に留まらず、明確に批判・否定する人もいる。

このデスマーチテックキャンプの人が、ただのうさんくさい人なのか、それとも革新をもたらす人なのか。残念ながら僕はまだ分からないでいる。 自分の観測範囲で多くの人が「危険な香り」とか「嫌な予感」とか散々アラートを発しているのだけれども、優柔不断でフワフワしている僕は、そこまでの断定ができずにいる。

まあ、でもとりあえず、「自分とこの人の行く道は違うのだな」という事だけは分かる。

(この「行く道が違う」っていう表現、ガンダムUCでミネバがリディをフッた時のセリフ由来なんだけど、色々便利な言葉だなあって思う。「お前は間違ってる!!」と断定できないけど同意もできない時に、今後も使いそう。)

全力でこの人の言う事に乗っかりたいとか、協力したいとか、そういう風にはどこか思い切れない、一線を引いたおつきあいまでに留めておきたい感じというか。 彼が成功者になった暁には羨むかもしれないけど、でも、袂を別った事は後悔しないだろう感じというか。

ともかくそんな感じで、自分はつくづく保守的で優柔不断な人間なのだなあ、という事を意識させられた出来事なのでした。


たらたら書いた後でデスマーチテックキャンプの運営会社の評判を見てみたら、ログインして無くても見える冒頭切り出しの部分だけでもかなり壮観な眺めで、「うっ、これはどう見てもあかんやつや……」と思った。(綺麗なオチ)

4年越しで溜飲を下げた話 - May 02, 2014

Mozilla Corporationの人から、「なんでツリー型タブはFull Reviewを受けてないんだい? about:addonsからの検索にヒットしないから、ユーザがインストールするのに面倒だよ。You申請しちゃいなよ!(意訳)」的なメールを頂いた。ありがたいことだ。

Mozillaのアドオンポータルサイトである所のMozilla Add-onsでは、アドオンを登録するにあたってPreliminary Review(事前審査)とFull Review(完全審査)という2段階の審査がある。登録したアドオンはまずPreliminary Reviewでセキュリティ面などの大雑把な審査を必ず受けて、通過できなければそのアドオンはAMOへの掲載すらかなわない。ここで問題なしとなれば晴れて「実験的アドオン」としてサイトに掲載されるようになるけど、Firefoxのアドオンマネージャからの検索にはヒットせず、おすすめアドオンとしてもノミネートされないので、これではまだ単に「載っただけ」。そこで一定の支持を得たら、次の段階としてFull Reviewを申請して品質面その他を審査してもらえる。Full Reviewを無事通過すれば、Firefoxのアドオンマネージャからの検索にヒットするようになったり、おすすめとして紹介して貰えたりするようになる。定番アドオンと言われるような物は、代替はこのFull Reviewを通過した状態になってる。

前から見てる人は把握してるかもしれないけど、僕が作ってるアドオンのうちいくつかは、Preliminary Reviewのみ通過していて実験的アドオンのままになっている。新しく作って登録した物は当然なんだけど、それだけでなく、過去にはFull Reviewを通っていた物が、ある時を境に審査にパスしなくなってそれっきりになっている物もある。ツリー型タブもその1つだ。

何故かというと、簡単に言えば、最初のFull Reviewの頃には審査が甘かったから通過できていたのが、その後の審査基準見直しで通らなくなったということ。ただ、僕としてはこの時の裁定にはあまり納得がいってなくて、evalが危険でそれ以外の方法が安全だと思ってる人へ英訳)というエントリでタラタラ不満をぶちまけたりもしてた。

そういう経緯があったから、大人げないオッサンとしては「いやーFull Reviewしたいのは山々なんですけどねーeval()使ってるから駄目っておたくんとこの人達が言うもんですからねー」と嫌味全開で返したくもなったんだけど、そこは我慢して、審査基準に合わないと言われたからFull Reviewしてないんですよ、審査基準が変わったなら再申請するのはやぶさかでないけどそうでないなら多分通過しないと思いますよ、でもまあ確かにeval()使ってるとレビューしにくいだろうししょうがないっすね、と、そんな感じで返信するに留め……られるほどにはやっぱり大人になりきれておらず、嫌みったらしく上記のエントリ(英語の方)のURIを貼り付けてメール送信してしまいました。ああ、なんとも底の浅い人間である事よ……

でもまあ、その時のレビュワーの人とは無関係であるにせよ、公式サイドの人から「Full Reviewに値する」という評価を貰えた事には「やってやったぜ」という胸のすく思いで、4年越しで溜飲を下げたのでした。

反対ばかりしてる奴、って言われることに不快感や劣等感を感じたけど - Mar 20, 2014

という発言を見て、僕個人のことを言っているわけではなくても、僕も当てはまるクラスタの人に対して言っているのだと思って、カチンと来て、でも色々混同したまま感情だけで発言するのは良くないと思って、感情を自分なりに整理しようとして、それでもやはりまだ何か言いたい気持ちを消し去ることができなくて、当たり障りのない平々凡々な、実に意味のないリプライを付けてしまった。

反対……というか要望ばかり言う身勝手なモンスターカスタマーと戦い続けて、そういう人々に失望・絶望した結果として、このようなレッテル貼りと(僕には)思えるような発言をされているのだろうか、と(僕が勝手に)思うと、それは斜に構えたガキがかっこつけて言ってるような軽い物ではなく、政権与党として実際に事にあたる者が無責任に放言するだけの万年野党に対して向ける視線と同じなのだろうと思えて、万年野党の僕ごときが「それでも、と言い続けろ!バナージ!(マリーダさん)」とか「貴様ほど急ぎすぎもしなければ、人類に絶望もしちゃいない!(アムロ)」的な綺麗事を言っても、まるで説得力もなければ正当性もない、と思えて、(自分は人に良い影響を与えられないという)無力感や(絶望を強いられる程までの激しい戦いを繰り広げてきたという偉大な実績がある人に対し、自分は綺麗事を平気で言える程度の傷しかまだ負ったことがない、実績が無いと言うよりも「逃げ続けてきたという実績がある」という)劣等感で、とても憂鬱で嫌な気分になる。

それで急に思い出したけど、氏はOSS貢献者賞を個人で受賞されているのに対して、僕はOSS奨励賞どまりで、そうなると、「ある土俵の上で賞を取った人と、そもそもその土俵に上がっていない人」の比較ではなく「同じ土俵で、上位の賞を取った人と、下位の賞しか取れなかった人」の比較になるわけで、そこには厳然たる優劣があるわけで、「みんな違ってみんないい」みたいなはぐらかしは全く通じないわけで、余計に劣等感が高まるのが自分で分かって、また辛い。

そんな気分のままでは手が動かなくて作業が進まないので、こういう時は、90年代ユーロビートという頭の中を右から左に流れていくような勢いだけの音楽を大音量でBGMにして思考停止して作業を進めるのが、自分の場合は良いようだと思った。酒を飲むと思考停止はできても眠くなるわ思ったような絵を描けなくなるわで、まるっきり作業にならないので……

10代や20代の頃には、こういう風には感じてなかったか、あるいか、ここまで切実には感じてなかったかもなあ、と思う。30代になって、上記のような形で社会からの自分のこれまでの実績に対する評価が可視化されて、「俺はまだ本気出してないだけ」とか「まだ土俵に上がってないだけ」「っていうか戦場が違うし」みたいな言い訳が一切通用しない状況が整ってきて、いいかげん自分ときちんと向き合わざるを得なくなったのだなあ、と思う。これもまた、1つの気付きか。自分の周囲の人、同年代の人達が、既にこういう過程を通過していたのだと思うと、偉そうに説教垂れたり無責任な励ましをしてきていた自分が、とても恥ずかしく感じられる。

あと、ここまで書いたところで読み返してみて「ああこれは人を不快にさせるタイプのアレだな……」とか「これは大人としてっていうか人として、するべき事でない事をしているな……」と思ったんだけど、不快にさせる部分を取り除く努力も放棄して、するべき事でないからしないという大人な判断力も発揮しないで、結局そのままpostしてしまってる。その辺も、過去の自分とは変わった所だなあ、と思う。過去の僕は「これは人を不快にさせてでも、大義のためにはやらねばならない事なのだ」とか「これは意味のある行為なのだ」とか確信してやってた気がする。今は「これは人を不快にさせてまでやるようなことでは明らかにない、っていうか全方位に渡って害悪でしかないけど、そんなもん知るか自分がやりたいからやるんだクソッタレ」と思ってるのが自分で分かる。他人の気持ちを多少は慮れるようになった部分、駄目な物を駄目と素直に認められるようになった部分、感情の抑制が効かなくなった部分、色々とにかく「変わった」という事は分かる。そんな感じ。

OSCでふぉくす子のプレゼンをやってきました - Mar 03, 2014

オープンソースカンファレンス2014東京の一コマとして3月1日に行われた「チャンネルはオープンソースでっ!(ちゃんおぷ)」の「応援キャラクター大集合!」という企画に、ふぉくす子のプレゼンターとして出てきました。

当日の話

1年くらい前に日本OSS奨励賞を頂いた場所で、今度はふぉくす子のプレゼンをするだなんて、誰が想像できようか。とか、実はフォクすけを最初に書いたのも僕なんですよねとか、その辺の話を面白おかしく盛り込めれば良かったのですが、当日はめちゃめちゃ緊張してて頭真っ白でそれどころじゃなかった。っていうか自己紹介の一言があるという事自体を僕は本番が始まってから知った(ふつうにクラウディアさんが自己紹介して、さくらインターネットの人が「さくらインターネットのだれそれです」と言って……という流れができていた)ので、もえじら組のPiroですだなんて名乗るわけにもいかず、3分の制限時間があるということもあって、普通に「プレゼンターの結城です」とつまらない自己紹介をしてしまいました。

しかも、焦ってそのままの流れでプレゼン資料に画面を切り替えてもらってしまったので、現場にいたふぉくす子さんは全然画面に映らないということになってしまいました。「この衣装はうんぬん」とうまく話題を持っていくようなこともできず、わざわざ朝も早くから山の中まで来てもらったのに申し訳ない限りです。

あとフィギュアの話に触れる時に実物を「コレです」って出そうと思ってて会場にも持って行ってたんですが、そろそろリハーサルだからということで荷物置いて軽装で現場まで行ったらそのまま本番までそこにいることになってしまったため、写真だけの紹介になってしまった、というのも心残りな点です。

そんな感じでグダグダのうちに3分を使い切ってしまったのですが、当日のニコ生のタイムシフト視聴(41分頃からふぉくす子の紹介)Togetterとか見た感じでは叩かれてるとかそんな事は特になかったようで、ほっとしました。

イベント後の撮影会でもふぉくす子を撮ってる人が結構いてくれて良かったです。ただ、撮影会の場所となっていたのが自然光の入らない薄暗い場所、しかも掲示板の前という酷いロケーションだったので、記念撮影以上のことはできない感じだったのは残念でした。2Fの受付近辺は吹き抜けで自然光もいっぱい入ってたので、ああいう所を選んでやれば屋内でももうちょっとマシだったんじゃないかなあ。あんなところでやるのはモデルさんに失礼だと思いますよ、ほんとに……

ふぉくす子が表舞台に出るということについての思い

ふぉくす子が表舞台にこうして出てくるというのは、僕としては結構画期的なことであったと思っています。

僕がMozilla Japanに半常駐してた時には既にふぉくす子ももえじら組もあって、当時色々やってたちょっと変わった広報活動の方針決めなどにも口出しさせて頂いていたので、ふぉくす子を表舞台に出そうと思えば出せる状況ではありましたが、当時僕はそれは絶対にやらないつもりでした。それどころか、僕という人間がMozilla Japanの広報活動に関与している事自体もなるべく公言しないでおくべきだと思っていました。

秋葉原でCD-ROMを配布した時(そういえば、この時のCD-ROMを作るためにProtable Firefoxのことを調べたのが、後のFx Meta Installerの開発に繋がったのでした)に、事前事後も色々と批判があって、Mozilla Japanの組織として「今後はこういうのは無しの方向で」的な空気がなんとなくあったのは事実です。

でも、そういう分かりやすい「失敗」が無かったとしても、当時まだ知名度自体がそんなに無かったFirefoxに必要以上にオタクなイメージがまとわりついてはいけない、エロ同人なんかやってる人間が関わってるということが悪意ある人間に知れてしまったらそれを叩きの口実にされてしまう、という恐怖感というか危機感が僕にはありました。だから、フォクすけの作者が僕だという事も公言していなかったのでした。

それから月日が経って、今ではフォクすけもFirefox自体もそれなりの知名度があるようになりました。しっかりとしたブランド価値が築き上げられた今であれば、この程度の事でそのブランドが崩れ去るようなことは無いだろう。そう思えるようになってきたので、僕は最近になってようやくこのあたりのことをおおっぴらに言えるようになりました(周囲に咎められていたのではなく、本当に、自分から「これは言っちゃいけない」とタブー視していたのです)。

また、クラウディア窓辺のように他の所も萌えキャラを使ったプロモーションをオフィシャルにやるようになってきた、という社会情勢の変化もあります。要するに、他の所がこうして大々的にやってるんだからふぉくす子も大丈夫やろ、と。そういう話です。

どうでもいいんですが、クラウディアさんは1985年生まれという設定になっているので、もうあと数年でさんじゅっさいになってしまうわけですけれども、大丈夫なんですかねこれ。(そこらへんを気にしてか、だいたいのキャラは誕生月と日は決まってても誕生年は不明ということになっているので……)

こういう企画そのものへの批判について思う事

今回の企画についても、「ヲタが公の場でオナニーしてんじゃねえよ」「おっさんが綺麗な女の子集めて持て囃してんじゃねえよ」的な批判の声はいくつか見かけました。以下はそのひとつ。

まず思うのは、モデルとして参加していた彼女らは基本的にオファーがあって業務としてあの場に居合わせただけ(ふぉくす子はノーギャラですが……)なのであって、媚びるな云々は筋違いということです。ドワンゴの女子マネージャー弁当手渡しもそうですが、こういったことの責はすべて依頼者側にあるというのが僕の認識です。

で、それ以外の話ですが、実際にイベントの裏側を現場で多少見ていて、確かに、内輪ノリとかホモソーシャルなイベントという空気があったのは否めないと思います。おっさんが若い女の子にデレデレして鼻の下伸ばしてるのは、まずそれ自体がみっともないし、そういうみっともなさを許容する空気があるということ自体が女性参加者を余計に遠ざけることになる、という批判は、まあ、あってもしょうがないなと思います。レースクィーンとか、モーターショーやアニメイベント等のコンパニオンとか、そういうのと同じ物を求める下心というかなんというか。(と、話題に出した所でふと思ったのですが、レースクィーンとかモーターショーやアニメイベント等のコンパニオンとかは実際の所どのくらい女性参加者を遠ざけるものなのでしょうか? そういうイベントに行った事がコミケ以外で全然ないので自分にはよく分かりません。)

ただ、OSCが参加者の人達の善意やボランティアに支えられているイベントであるのなら、支えている人達の「俺はこれがやりたい」という思いが結果的にOSCの方向性を定めていくのであって、「これこれこういう壮大な目的のためにお前らは自分のやりたいことを我慢して我々の指示に従え」なんて事を主催者側が言いだしたら、成立しなくなるのでしょう。だから、これはこうあるほかに無いのだと思います。

というか、OSCがホモソーシャルではいかんという指摘自体がもう的外れなのかもしれない、とすら僕は思っている部分があります。

ここ数年は僕自身、今回のように特別な用事が無ければOSCには積極的に顔を出そうという動機がありません。それは開催場所が遠いから(そもそも、イベント会場が都心からだと電車を一時間も二時間も乗り継いでいかなければいけない場所にあるという時点で、外の人を相手にする気が薄い内輪のためのイベントという性格がかなり前面に出ていると思いますが、まあそれはさておきます)というのもありますが、OSSが自分や自分の周囲の人にとってはもはや当たり前のこと・当然の選択肢の1つになっているからというのが最大の理由です。今自分が仕事でお付き合いさせて頂いている企業さんはどこも「どうしても秘密にしないといけないクリティカルな部分以外は成果物をオープンにして全く構わない」というスタンスですし、クックパッドなどの「金を稼ぎ出している部分はきちんと他にあった上で当然のように技術をオープンにしている」会社はいくつもあって、少なくともオープンソースは「非常に、非常に珍しい物」ではなくなっているというのが今の僕の認識です。成果の技術をオープンにする事には一定の合理性があるという認識がある程度広まっていて、様々な企業や個人が自然な行為としてそれをやっているのであれば、その流れは勝手に広まっていくわけで。

そういう社会情勢の中で敢えて「オープンソース」だけをかけ声にして集まろうというのだから、濃い人が集まるのは仕方がない。その上でさらに各自のボランティアなのだから、そりゃもう濃縮されて余計に濃いことになっちゃうわけです。でも、「オープンソース」の中心がOSCやそこに集う人達だけの間ではなく、普通に回っている経済の中の方に既に移っちゃってるんだったら、もうOSCはそういうものってことでいいじゃん、と。オープンソースというものに全く理解がない社会の中で孤軍奮闘して頑張ってきた人達の同窓会になっちゃっててもいいじゃん、と。そんな事すら僕は思っています。

という僕の認識もまたずいぶん偏っていて、実際にはそんな事は全然なくてオープンソースはまだまだエヴァンジェリストが引っ張っていかないといけない感じなんですかね? だとしたら僕は今ものすごく恵まれた環境にいるんだなあ……

技術系コミュニティ一般の話に広げると、技術やっててヲタ文化に関心が無い人が居られる場所がないのは良くないなあ、とは思ってます。流行りの漫画のジャーゴンまみれにしなくても話を面白くすることは多分できるはずで、そこでジャーゴンに走ってしまうのは、人の関心を引く発表内容や資料を考える手間の省略、手抜きでしかない。無自覚な内輪向け感覚は、こういう事に限らず、なくしていった方がいいと思います。自分がどっかのお料理教室に行くことにしたとして、先生が料理業界の常識だとか流行りの話題だとかを知ってることを前提にして僕のようなよそ者完全置いてけぼりで喋ってたら、嫌だし多分行きたくなくなりますしね。「同質な者同士が馴れ合うための場所」と「広く様々な人を迎え入れて交流するための場所」とはキッチリ分けて考える、分別のある人でありたいものです。

結婚指輪を常に付けるかどうかとかの話 - Feb 09, 2014

中国嫁日記の、結婚指輪を紛失した話を見て思い出したり思ったりしたこと。

僕自身は、母がずっと結婚指輪を付けている人だった(小さい頃に聞いたら「肉が付いて外れなくなったから」と言ってたんだけど……)から、結婚指輪とはそういうものかと思い込んでいた。

が、自分が実際に店に行ってカタログを眺めてみる段になって、それらは「当たり前」の認識ではないのだという事を知った。

  • 派手なデザインの結婚指輪も色々あるらしい。
  • あんまり派手だと生活する上で不便じゃないだろうか、と疑問を口にしたら、「常時付けるとも限りませんし」みたいな事を言われた。

率直に言ってカルチャーショックだった。結婚指輪を付け外しするかどうか、なんてそんなに話題に上る話でもなかったから、最初の時点でインストールされた認識以外の考え方があるなんて思いもよらなかった。

とはいえ、なぜそれでカルチャーショックになるのかというのが重要な点だ。目玉焼きには塩でしょ醤油でしょソースでしょみたいな話は、突き詰めれば好みの問題と片付けられるけど、結婚指輪を付けるかどうかというのは僕にとってはもっと重要な意味合いがあった。それは、「結婚指輪を付けていることが、良好な夫婦関係の証明である」という認識だ。

というのも、ドラマやなんかで既婚者が浮気・不倫をする時に、既婚者だとバレないように指輪を外してから行くとか、「自分と一緒にいる今は、結婚の事を忘れて欲しい……」とかなんとか言って相手が既婚者側の指から指輪を抜き取るだとか、そういう描かれ方をしているところを何度か見てきていたから、「結婚指輪って特別なものなんだな」と、知らず知らずのうちに刷り込まれていたのだと思う。どこでそういうのを見たのかを思い出せないくらいには、僕にはすっかりその規範が内面化されてしまっていた。

でも、この事がきっかけとなって、僕は「そうでない価値観があるのだ」と思えるようになった。そう考えるに足るいくつかの気付きがあった。

  • 「そもそも結婚指輪を作ってない」とかの極端な例すらあるという事をその後知った。というか父がそうだった(いや、ずっと付けてるものと思い込んでたんで……思い込みって怖いですね)。
  • 自分が見てない所で結婚指輪を外していたとしても、どうせ気付けない。
  • 結婚指輪をしていたって、浮気する人はする。
  • 自分が相手に強制して、相手に嫌々指輪を常時付けさせていたとして、それが良好な夫婦関係の証明であるとは到底言えない。それはむしろDVの証明であろう。

相手が本気になれば僕のことなんかいくらでも欺けるのであって、結婚指輪1つにこだわっても本質的な解決にはならない。それに、欺かれないように監視・束縛を強めることで相手が幸せになるわけでもない(束縛されたがりの人は除くとして)。結局、自分がどれだけ相手のことを信じられるのかにかかっている。相手は絶対に自分の事を欺かないはずだと確信するとか、自分は相手に欺かれたとしても絶対に後悔しないでいようと心に決めるとか、そういう事なんだと思う。

という事に気づいたことで、僕は結婚指輪に対する妄執から解放された。今では、自分がずっと結婚指輪を付けているという事自体についてすらも、客観的にフラットに認識できているのではないかと思う。習慣と「自分がこうしていたいから」と、あと「自慢したいから」、そんな程度の理由で付けている、というのが今の自分の認識です。

もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - Nov 10, 2013

人格攻撃をしたくて書いてるわけじゃないですよ、という事はまず最初に表明しておきます。

GitHubで公開してるプロジェクトについて、幸いなことに時々プルリクエストをもらえる事があるんだけれども、その時に、何のストレスもなく「Merge」ボタンを押せる時と、そうでない時とがあるなあと思ってた。

その差は何なんだろう?と思ってたんだけど、今回treestyletabのargumentsを使っている箇所を書き換えるプルリクエストをもらって、それに関してやり取りをした事を通じて、「あ、こういう事かな」と思った点が1つあった。

それは、「相手の考えを尊重する態度が見られるかどうか」。

ロケールの翻訳であったり単純なtypoの訂正であったりというパッチではそういうのはまず見えてこないんだけど、今回のように設計のポリシーにまで踏み込んだパッチだと、互いの思惑がずれていることが見えてくる事がある。今回の場合、僕と彼とでは「こうあるべき」と思っているコードの姿がずれているんだなと思った。また、「ああ、僕がこれほど大事に思っていることが、彼にとっては些事に過ぎないと見えているのだなあ」という残念な思いも感じた。

考え方が違うことがすべて悪だとは思わない。JavaScriptの古い仕様であるargumentsから、ES6のRest argumentsへの置き換えを進めるというのは、古い物ばかり見てしまっていて且つ保守的な自分からはそういう発想がまず出てこない(大抵、どうしようもなくなってからようやく重い腰を上げる感じです)ので、自分の目が届いていないところについて「こういうのもあるよ」と教えてもらえるのは、正直、とてもありがたい。

ただ、僕が大事だと思っている事についてバッサリ切り捨てるような態度を取られるのには、いい気がしない。arguments・Rest argumentsで全部の引数を引き渡すように書くべきか、それともすべての引数をきちんと定義しておくべきか、という議論では特にそれを強く感じた。

僕は僕なりの考えを持って、過去に悩まされた色々な事例からの反省であったり、現実的にどこまでメンテナンスに時間をかけられるかという葛藤であったり、どういうコードであれば僕の思う「How」を正しく書き記せるのかであったり、といった事を考えた結果としてああいうコードを書いていたのだけれども、それらの一切合切を無視して「こうあるべき」と別のスタイルを押しつけられることに、僕はどうしても不快感を感じてしまった。コードを自分と同一視していて、自分自身を否定されたかのような感覚すらあったのかもしれない。最初の1回だったら、まあそういう前提が共有されているはずもないので、齟齬があるのはしょうがないと思うんだけど、2度にわたって否定されると、「あ、この人は僕のいろんな思いを尊重しようというつもりが全然ないんだな」と感じて、急速に心が冷たくなっていく、そんな感じがした。

何年もコードを書いてきたんだとか、自分がここまで育ててきたんだとか、そんなクソくっだらない個人的感情に基づいた見栄でもって、真理を歪めてはならない、というのは、その通りだと思う。でも、とても残念なことなんだけど、僕は大義のために自分の命や思い入れをためらいなく差し出せるタイプの人間ではなく、むしろ個人的な感情の方をこそ大事にしてしまうタイプの人間のようなのだ。僕はそういう頭の悪い人間ではないのだ・もっと賢くて理性的な人間なのだと思い込もうとしてたんだけど、実際にはそうではない・そうなれないのだなということを、31歳の今では痛感している。

思い返してみると、僕がかつて「技術系コミュニティ」という物に激しい拒否感を持っていたのは、それが理由だったのかもしれない。唯一絶対の真理として論理的な正さを偏重し、そうでない価値観は無意味と切り捨てる、そういう傲慢さや冷酷さのような物を僕は嫌っていたのだと思う。まあ、そういう自分の想いでもって彼らを・世界を変えたいと思っていたというのも、また同種の傲慢だったのだなという事も今では分かる。我か彼かではなく、どちらの価値観も並行して存在していてよいのだ、そういうカオスを受け入れることが大事なのだ、という事を認識できるようになったのは、それよりずいぶん後になってからのことだ。

ともかく、そういう残念な人間である僕にとって、一緒に作業をしたいと思える相手はやはり、僕の思いをなるべく尊重してくれる人という事になるのだなあ、と思うし、また自分が他の人と一緒に作業する時も、ある一面から見た時だけの正義をいたずらに振り回すことなく、最大限相手の思いを尊重して事にあたっていきたいなあ、と思う、そんなことを改めて考えた出来事だったのでした。

世の中には、ぬるま湯に浸かっていては駄目だ、自分の間違いをビシビシ指摘してくれる厳しい人と一緒にこそいるべきだ、という言説もある。僕はそれは、基本的にはいい事言ってると思うんだけど、でも、そこに相手を尊重する態度があるかどうかってのが、結構重要なんじゃないかと思ってる。

相手を尊重した上で、その思いを遂げるためにはもっとこうした方が良いよ、というアドバイスをしたり、その思いはこれこれこういう前提がおかしいよと新しい視点を示すというのは、僕にはまだ受け入れられるんじゃないかなって思う。でも、そうでなく、お前は間違っているからこうするべきだ、と、僕の思いを歯牙にもかけないでその人の思う正義であったりあるいは誰か第三者が掲げる正解であったりに沿って特定の行動を押しつけられるというのは、ストレスになる。その「厳しい指摘」がどっちであるかというのは、論理的な正しさだけを見ていると分からないと思う。

俗な言い方をすると、それが「愛があるかないか」って事なんじゃないだろうか。「厳しい指摘」をする時に、「指摘する側である自分の自己愛に溢れた指摘(独り善がりな指摘)」ではなく「指摘される相手への愛がある指摘」をする、というのは、なかなか難しいことだと思うけれども、せめてそう心がけたいとは思ってる。

また、逆に言うと、自分に向けられた「厳しい指摘」をすべて受け入れるでもすべて拒否するでもなく、その中で「愛のある指摘」を上手くより分けることができれば、他人の言説にいたずらに振り回されて疲弊することも、世界全部を敵に回しているかのような疎外感を感じることも、ないのかな……とも思う。

結論:愛は地球を救う!

Why I don't provide "disabe animation of tab dragging operations" feature for Tree Style Tab? - Nov 06, 2013

This is the English translation of my another entry.

I decided to reject a pull request for TST, adding new secret preference to disable animation effects around drag and drop of tabs, because it contradicts the principle of the TST project. This entry describes why I rejected the pull request.

Why I introduced such an animation effect?

Because it is introduced by Firefox itself. After the animation effect is activated on Firefox, I updated TST to follow it. However, it was unwelcome update for some people and I got many requests like "it is hard to operate tabs with drag-and-drop", "I want an option to disable animation effects during tabs are dragged." Actually, I can see two issues on the issue tracker:

The patch of the pull request adds a secret preference to do it. It is enough small and clear. If I added the option, I wrote just same patch.

But I disagree to merge the pull request, because I think that the approach of the patch is similar to a story: "Firefox's Gecko engine is too buggy and less compatibility to WebKit, so why don't you delete all codes of Gecko and introduce WebKit with Firefox-like UI?" In other words, it is very easy to add new option which is requested by people, however, I'm extremely reluctant to do it beacuse it is opposed to my polify on Tree Style Tab project.

Basic premises and my policies.

Basically, this project depends on Mozilla Firefox project --which is very large and uncontrollable by me-- and it is unavoidable to be tossed up and down by the storm of changes in Firefox. Actually, on my another project, I had to rewrite the addon for new versions of Firefox again and again. I learned through the bitter experience that I should have some strict policies on my addon projects:

  • Don't re-implement a feature included in Firefox itself. For example, Tab Mix Plus has its own session management mechanism, because TMP project is started before the session management feature is introduced by Firefox itself. If the TMP project was started after that, they project team didn't implement such a custom session manager. There is no merit to implement a custom feature which conflicts to Firefox's.

    To reduce maintenance cost, and to keep better compatibility with other addons which are developed based on Firefox's APIs, I think I should update and re-construct my addons for new APIs introduced by Firefox. It is better than I struggle to keep old custom implementations against Firefox's changes.

    • However, sometimes I decide to keep my custom implementations, when it is hard to rewrite codes for Firefox's new API for me.

      For example, TST uses a library "JSDeferred" to process asynchronous operations easily. On the other side, lately Firefox uses Promise and Task for the same purpose. I know I should rewrite TST based on them instead of JSDeferred, but I still don't do it because: 1) TST is strongly designed based on JSDeferred. 2) Promise/Task are not available on the current ESR (Firefox 17). (In other words, I'll merge pull requests to do such a reconstruction, if there is no disadvantage about compatibility with other addons.)

    • When the API of Firefox's library is too untrustworthy for me, I decide to use my custom library based on very low stable APIs.

      For example, Firefox has a system named "preference" which can save/restore users' configurations. Because it is not developer-friendly (ex. there are three deferent types --boolean, integer, and string--, and hard to observe changed configurations dynamically), Firefox provides some libraries like FUEL. But, such libraries are untrustworthy and risky for me because Firefox team sometimes changes those APIs despite they promised those APIs are developer-friendly --obviously they should be stable and safe--. I don't want to spend time to update my codes for such unstable APIs, so I actually use my custom library modules/lib/prefs.js which is based only on very stable low APIs. It is one of reasons why I don't update my codes for Promise/Task yet.

      Anyway, I think that FUEL APIs are untrustworthy because Firefox team created FUEL just for third party add-on developers, not themselves. Because Promise/Task are used everywhere in Firefox, Firefox team will keep them stable for themselves.

     
  • Don't depend on deprecated features. For example, "E4X" became obsolete on lately Firefox. TST used E4X in some cases, so I had to decide that I keep E4X for TST or I give up. Some projects (not mine) decided to re-implement E4X by themselves, but I decided to give up and rewrite codes without E4X.
  • Don't include features not related to the main concept. The basic concept is: what I want to use, one feature per one addon, and, as minimum as possible.

    In my old blog entry (note: written in Japanese), I told that: features which I never use or unrelated to the main concept may satisfy users in the short term, but it will shorten life of the project in the long term. Basically I develop and publish my addons on GitHub because I need it and I want to keep it available for me. So I don't want to introduce changes which can disrupt the concept.

  • Provide higihly compatible, natural look-and-feel for Firefox's built-in features and other addons. For example, Firefox has a feature "auto hide toolbox" for the fullscreen mode started by F11 key. And, TST also provides "auto hide tab bar" feature. Yes, it is not related to "tree" feature. But if TST doesn't have the feature, you'll see unexpected vertical tab bar in the fullscreen mode. You press F11, you expect that the web page becomes fullscreened, then the vertical tab bar should not appear on the scene.

    This is the main reason why I took much time to update TST to support drag-and-drop animation effects. Before the animation effect is introduced to Firefox, I respected behaviors of drag-and-drop around layers and objects on Adobe Illustrator. This behavior is still available when you drag a link to the tab bar.

Reasons why the pull request is unacceptable for me.

Based on the above policies, I disagree to merge this pull request to TST's master, because:

  • Firefox has no option to disable animation effect of dragging tabs.
    • There are different and large codes for both cases: with and without animation.
    • However, animation-less operations in rare cases seem to be inhospitable (for me), contrastively basic operations with animation are developed actively.
    • So I forecast that codes for animation-less operations can be removed from future versions of Firefox. It is risky that I develop TST strongly based on such a disappearing implementation.
  • Because there is no option to enable/disable animation effects, I think that Firefox team basically designs Firefox to do drag-and-drop operations with animations. Then, I should keep TST along the design of Firefox itself.

    • I believe that animation effects in GUI often provide better user experiences. I'm affirmative about such a policy of Firefox project.
    • Actually disabling animation effects by userChrome.css or other ways sometimes break Firefox itself. For example, the internal operation to finalize closed tabs uses "TransitionEnd" DOM event to trigger itself, but it didn't workcorrectly because the event was never fired if the animation efect was disabled by userChrome.css. (I don't kwnow the bug is already fixed or not.)

      I don't think my addon should be specially hospitable for people who live without animation effects, because Firefox itself disfavors them.

     
  • I disagree to add new option to disable animation effects, for a request like "it is hard to operate tabs with animation effects." Instead, I think I should improve usability of tab operations with animation effects, to reduce frustrations around such operations.
    • If you don't have to operate tabs manually, you won't suffer from animations. If you have to operate tree of tabs manually to put them as you want, then TST should build tree of tabs automatically more intelligently to set you free from stressful manual operations.
    • If it is hard for you to drop the tab to the favorite position with animation effects, then TST should make it easy, instead of disabling animation effects.
  • Currently I have no plan to use Firefox without animation effects. I don't want to maintain codes for a feature I never use.
  • Of course, disabling animation effects is useful for some people who suffer from visual transitions, about accessibility. However, remember, Firefox itself is not providing ability to disable animations, for such people. And, this addon is "Tree Style Tab." I think TST should not include custom accessibility features which is missing on Firefox itself --it should be done by Firefox project--.
    • If you seriously suffer from the problem, you should file a bug for the issue, induce developers to implement ability to disable animation effects. Or, you should create a new addon which is based on a simple concept: disabling animation effects. (Note, I never develop such an addon because I never use it!) The user script zzzz-removeTabMoveAnimation.uc.js for userChrome.js seems to be written for the purpose.

The conclusion: fork this project freely.

This is just my personal, current opinion. Of course I don't think this is the final truth of the topic. If you have information which can solve my worrying, or if you explain compelling reasons that I should do it, then I possibly merge such a change.

Otherwise, I'm sorry but I never merge such pull requests to my master repository. Then please fork this project, extend, maintain, and release it for people who have same distress - it is my stance on this project. To keep my codes forkable -- this is one of reasons why I distribute all codes of TST under OSS licenses.

プロジェクト名や製品名等、固有名詞の英語表記の1文字目を大文字にするべきか否か - Oct 17, 2013

英語ネイティブの人に、それが固有名詞であると分かってもらいたいなら、1文字目は大文字にしたほうがよい。ということは言えるようだ。

プロジェクト名や社名や製品名の英語表記について、「テキストデータの中では大文字始まり」「ロゴタイプでは小文字始まり」という使い分けがなされている事例をよく見る。例えばこんなの。

振り返ってみると、「固有名詞だがテキストデータ上も小文字始まりである」というケースは、日本人が書いている以外の例を僕は見た事がない気がする(Gemのパッケージ名だとかコマンド名だとかは例外ね)。

例えばミクシィは、ロゴタイプが小文字始まりの「mixi」だが、Webサイト上のテキストデータも小文字始まりの「mixi」で統一されているようだ。mixi自身が提供する英語版コンテンツでも小文字始まり。でも外部の人が編集したと思われる英語版Wikipediaのページでは、大文字始まりで表記されている。

英語ネイティブの人達にとってはどういう感覚なのだろうか?という事を知りたくて英語版Wikipediaで固有名詞の英語におけるキャピタライゼーションについての記述を参照したら、「summer」や「winter」などのごく少数の例外を除いて、固有名詞は大文字始まりで表記するのが原則であるという風なことが書かれていた。

そういえば以前に読んだ記事で、TwitterだかGoogleだかが、サービス名や社名を小文字始まりで書いたり、「ググる」みたいな俗語として「googling」を使ったりということについて、文句を言っているとか、辞書にそういう見出しで掲載するんじゃないと非難しているとか、そういう話を見たことがあったと思う。

英語ネイティブな人が身近にいないから、外してるかもなって思うんだけど、彼らにとっては、「固有名詞は大文字始まりで書くのが原則である、小文字始まりの固有名詞は不自然である」という感覚は、「印象を柔らかくしたいので小文字で表記したい」という欲求よりも優先度・重要度が高い……というか、 後者を優先するという発想が出てこないほどに、前者の感覚が常識として浸透している という事なのかなあ、と、僕は思っている。

もっと言うと、(mixiがそうしているように)日本人が固有名詞を頑なに小文字表記で書きたがるというのは、彼らから見たら、日本語の事を分かっていないDQN親が中二病な発想でキラキラネームを子供に付けてキャッキャ言ってるようなものなんじゃないのかなあ、と、僕には思えてしまう。いや、英語ネイティブの人達がほんとにそう思ってるかどうかは知らないけど、僕はmixiのような事例を見る度に、「うあああニワカが厨二病発症して俺ルール貫いてるよおおお!! 英語の本家であらせられるところのネイティブの人達に失笑されてるに違いないよおおお!!」と、無意味に恥ずかしく感じてしまう。

と、ここまで書いたところでこのサイトの名前も小文字始まり表記である事に今頃気が付いて、どう見ても完全にブーメランなのでした。

ツリー型タブにおける、タブのドラッグ時のアニメーション効果についてのポリシー - Sep 13, 2013

English version of this entry is available.

ツリー型タブに頂いたプルリクエストについて、ポリシー上の理由から取り込めないなあと思ったのだけれども、これまで、参照しやすい形でまとまった文章としてポリシーを表明していなかった気がするで、何故この変更を取り込まないか(タブをドラッグ&ドロップするときのアニメーション効果をOFFにできるようにしないのか)の判断理由を頑張って文章にしてみました。アーカイブとして、少し手直し&追記してこちらにも転記しておきます。

Firefox本体の挙動としてタブのドラッグ&ドロップ操作にアニメーション効果が適用されるようになって以後、ツリー型タブにも、その挙動に合わせるための変更を随時行ってきました。

しかしながら、この変更は万人にとって望ましい結果をもたらしたとは言えず、「タブをドラッグ&ドロップで操作しにくい」「タブのドラッグ&ドロップ操作時のアニメーション効果を無効にできるようにして欲しい」といった意見・要望が何度か寄せられています。今すぐにパッと挙げられるだけでも、Issue Tracker上には以下の2つのIssueがありました。

メールを通じて寄せられた意見も合わせると、無視できない数の人がこの件に関心を持っているようだ、という印象を僕は持っています。

冒頭に挙げたプルリクエストは、ドラッグ&ドロップ時のアニメーションを無効化する設定をツリー型タブに加える、という物でした。変更箇所は最小限で、内容もおかしなことをしている部分はなく、コードとしてはそのまま取り込んで全く違和感のないパッチです。

ですが、自分の認識としては、このパッチで示されている方向での対応というのは言わば、「FirefoxのGeckoエンジンはバグだらけだしWebkitと互換性が低いから、Geckoを全部消して、WebkitにFirefox風のUIを付けた物を次のバージョンのFirefoxにしますよ」というような物なのではないか、と考えています。……という例えは極端なのでもう少し普通の言葉で言い直すと、「確かに皆が望む通りに対処することは簡単なのだけれども、プロジェクトの運営ポリシー的に、この点で皆が望む通りの対処の仕方をする事には非常に慎重である」ということになります。

大前提として、このプロジェクト(ツリー型タブというアドオンの開発プロジェクト)は、Mozilla Firefoxという自分には制御のできない別のプロジェクトに依存している・振り回される事を避けられないプロジェクトである、という事をまず押さえておく必要があります。

ツリー型タブ以外も含めた自作のFirefoxアドオン全体で、Firefoxの仕様変更に追従するために大きな変更が必要だったことが過去に何度かあり、その時の苦い経験から、現在のところ、自分はこれらのアドオン開発のプロジェクトにおいて以下のような方針を立てるようにしています。

  • Firefox本体で実装している物と同じ目的の物は、できる限り、アドオン側で独自に実装し直さない。
    例えばTab Mix Plusはタブのセッション管理機能について、Firefox本体にそのような機能が入る前から開発されてきたという経緯から、Firefox本体のセッション管理機能とは全く別のセッション管理機能を持っています。が、今新たにTab Mix Plusを開発するとしたら、独自の仕組みを持つメリットは全くありません。 メンテナンスコストの削減と、「Firefox本体の機能と親和性が高くなるように開発されている」他のアドオンと併用したときの相互運用性を高く保つという、2つの観点から、独自の仕組みをメンテナンスし続けるよりは、Firefox本体で実装された仕組みにうまく載っかるように改修する道を選ぶべきであると、自分は考えています。
    • ただ、アドオン内の各部分が独自の仕組みに強く依存した設計になっており、Firefox本体で採用された新しい仕組みに基づく形に改修するのが非常に難しい(工数が大きい)場合には、独自の仕組みを保ち続ける選択を取る場合があります。
      例えば、TSTでは非同期な処理と非同期な処理の連携をうまく取るために、JSDeferredというライブラリを使用しています。一方で、最近のFirefoxではPromiseTaskといった仕組みが導入されており、本来であれば、JSDeferredではなくこれらに基づく形で全体を作りなおすべきところです。が、ESR版Firefoxではまだこれらが使えないという事情もあって、移行はできていません。
      (逆に言うと、そのような手のかかる変更に現在のところ自分は着手できていないが、問題視はしているということで、この点を解消するプルリクエストであれば、他のアドオンとの互換性などいくつかの懸念が払拭できていれば、是非とも取り込んでいきたいと思っていると言えます。)
    • Firefox本体で提供されているライブラリのAPIの安定性がいまいち信頼できないという場合、そのより低位の、より変更が少ないと予想されるAPIに基づいて、自分でライブラリを作成して使用しているという場合もあります。
      例えば、Firefoxではユーザ設定を保存する機能としてpreferenceという仕組みがありますが、真偽値・整数値・文字列値という型の違いがあったり、設定の変更を監視するのが面倒だったりということで、より簡単に使えるようにするためのライブラリをFirefox自身がいくつか提供しています。FUELもそのひとつです。しかしながら、それらの「シンタックスシュガー」的な用途で作られたライブラリは、ライブラリ自体のAPIが彼らの都合でコロコロ変えられてしまうリスクが結構あり、それで泣かされるのは非常にアホらしいという認識が自分にはあります。なので、僕は自作のアドオン群では、preferenceを扱う最も低いレイヤのAPIであるnsIPrefBranchを直に操作するライブラリ(modules/lib/prefs.js)を自分で作って使っています。
      PromiseやTaskへの移行に踏み切れていない理由の1つとしては、このような懸念もあります。が、FUELのようなライブラリがFirefox内部でほとんど使われていないために捨てられてしまうリスクがある(彼らは、自分が使う物は大事にメンテナンスしますが、「アドオン作者が使うように」といった感じでお仕着せの便利ライブラリとして用意した物については、彼ら自身が使っていないので冷遇しがちという印象が僕にはあります。)のに比べると、PromiseやTaskはFirefoxの中の深い部分で既に多用され始めているので、今更捨てられてしまうリスクはそれほどには高くないかな……という目算もあります。
  • Firefox本体で廃止が決まっている機能、廃止される見込みがある機能には、なるべく依存しない。
    例えば、記憶に新しいところではE4Xの廃止というトピックがありました。文字列のヒアドキュメント代わりにE4Xを使用している箇所が、E4Xの廃止で動かなくなるという事に対して、E4Xを諦めるか、E4Xを使い続けるのか、という2つの道があり得ました。プロジェクトによっては、E4Xを自前で実装し直すことでそれ以外の箇所の変更を最小限に留めるという道を選んだところもあったようですが、自分は、E4Xを捨てる道を選びました。このあたりの判断については過去に会社のブログで詳しく書いていますので、そちらも見てもらえると幸いです。
  • プロジェクトのコンセプトから外れる事は、なるべくしない。
    コンセプトは「自分が使いたいものを、1機能につき1アドオンとして、最小の形で開発する」ということ。
    過去のエントリで詳しく書いていますが、自分が使わない機能や、コンセプトから外れる機能を盛り込むことは、短期的にはユーザの満足度を高める結果に繋がる可能性がありますが、長期的には、プロジェクトの寿命を縮めるリスクを増やす事だと自分は考えています。GitHub上に置いてある僕のアドオンは、基本的にはどれも「自分が使いたいから・使い続けたいから」開発をしているので、自分が使い続けにくくなる可能性が高まる変更は、なるべく取り込みたくないと考えています。
  • 細かい挙動はFirefox本体の本来の挙動に可能な限り合わせる。違和感が無いように作り込む。
    例えばFirefox本体の機能として、F11キーでフルスクリーン表示に切り替えた時に、ツールバーが画面の外に隠れるというものがあります。ツリー型タブには「タブバーを自動的に隠す」機能がありますが、単機能だシンプル化だと言っておきながら一見するとツリーとは関係ないこのような機能を未だに含め続けているのには、このF11でのフルスクリーン表示時の挙動をFirefox本体の挙動に自然にマッチするようにしたいからというのが大きな動機としてあります。
    タブのドラッグ&ドロップ操作のアニメーションに、ツリー型タブでそれなりの労力を割いて対応している最大の理由も、これです。(Firefoxにタブのドラッグ&ドロップのアニメーションが実装されるまでは、UIが似ているAdobe Illustratorのオブジェクトとレイヤーの操作性を参考に作り込んでいました。これは今でも、タブ以外のオブジェクトをタブバー上にドラッグした時に見ることができます。)

以上を踏まえてこのプルリクエストで触れている問題を考えると、自分は以下の理由から、この変更を行わない方が良いという考えを持っています。

  • Firefox本体に、タブのドラッグ&ドロップ時のアニメーションをOFFにする機能が無い。
    • アニメーションするかしないかでFirefox内でのコードパスが大きく異なり、どちらもそれなりに大きな規模である。
    • が、アニメーションのための開発が活発に行われていたのに対して、アニメーション無しのドラッグ&ドロップについては冷遇されている(気が、自分はする)。
    • ということは、今後、アニメーション無しのドラッグ&ドロップは実装が削除される可能性もある(と、自分は見ている)。 削除される可能性がそれなりにある実装に強く依存してしまうのは、リスクが高い。
  • ON/OFFの設定がないという事は、Firefox的には、タブのドラッグ&ドロップは基本的にアニメーションするものであるというスタンスだと考えられる。であれば、Firefoxに依存するプロジェクトは、Firefoxの方針に従っておくのが得策であろう。
    • アニメーション効果を適用することは、見た目のキレイさだけでなく、使い勝手の向上にも関係するので、自分はそのようなスタンスを取ることには肯定的である。
    • アニメーション効果をユーザが無理矢理無効化すると、正しく動かなくなる、という部分がFirefoxの中にすらある。
      具体的には、タブを閉じる処理は内部でのデストラクタを走らせるトリガーとして「アニメーションが完了した」というイベントを使っており、アニメーションが無効化されているとデストラクタが走らないのでタブがきちんと閉じられないという問題があった(今その問題がどうなっているかは把握していない)。
      Firefox本体の側がアニメーションOFFでの利用をここまで冷遇している以上、そのような使い方をこのアドオンで手厚くサポートする必然性を、自分は感じない。
  • 「アニメーションがあるとタブをドラッグ&ドロップで操作しにくい」、という要望に真正面から「アニメーション効果をOFFにできるようにしました」と応えるよりも、そういう要望が出にくくなるような形での解決を図るべきだと考えている。
    • そもそもドラッグ&ドロップで操作する必然性が薄ければ、問題なくなるのではないか。手動でツリーを編集しなければ意図した通りにならない、という状況があるのなら、ユーザに手動でのツリー編集という手間を強いる方向よりは、ツリー編集しなくてもストレスを感じないように、ユーザの意図を汲んで自動的にいい感じにツリーを構築するようにした方が、より望ましいのではないか。
    • アニメーション有りの状態でドラッグ&ドロップすると狙った位置にドロップしにくい、という問題があるのであれば、それは、アニメーションをOFFにすることで対処するのではなく、アニメーション有りでも狙った位置にドロップできるようにするのが、正しい解決ではないのか。
  • 僕自身は、アニメーションをOFFにして使うつもりがない。自分が使わない機能に対するメンテナンスコストを抱え込みたくない。
  • 視覚的に連続した変化を認識しにくい、アニメーションされた方が却って認識しづらくなる、といった性質あるいは障害を持っている人がいる、という事を考慮すると、アニメーションをOFFにできるようにすることは、アクセシビリティ上意義のある事だと思う。
    が、Firefox本体がアニメーションをOFFにできるようになっていない以上、「タブをツリー表示できるようにする」というコンセプトのこのアドオンが、独自にアクセシビリティ上の配慮を盛り込むのはおかしいのではないか。
    • この点を真面目に考えるのであれば、「FirefoxのBugzillaで問題提起して、Firefox本体の側でアニメーション効果のON/OFFをできるようにする」あるいは、「Firefoxのアニメーション効果を無効にするという1つのコンセプトに則ったアドオンを開発する」という道を選ぶべきだと、自分は思う。(アドオンではないが、userChrome.js用のzzzz-removeTabMoveAnimation.uc.jsというスクリプトは、そのための物と言えそう。)

以上の事は、あくまで現時点での自分の考えがそうであるというだけで、絶対普遍の真理であるとは考えていません。ここに挙げた数々の懸念点を払拭できる材料があったり、あるいは、そのような懸念があってもなおこのようにするべきであるという強い動機があって、僕が同意できるのであれば、変更を取り込むことにはやぶさかでないです。

でも、そうでない限りは、この種の変更については「フォーク版を作ってそっちで自由に開発していって下さい。そして、その機能を必要とする人自身の手でメンテナンスしていって下さい。」というのがこのプロジェクトの方針ということになります。僕がこれらのアドオン群にオープンソースライセンスを適用しているのには、そのような自由を保障しておきたかったからという理由もあります。

冷たいようですが、どこで線を引くのか・何を基準に線を引くのかを熟慮した結果、このような線引きに落ち着いたということで、同様の不満を抱いている方々にはどうかご理解を頂ければ幸いです。

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

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき