Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
液晶ペンタブレットを使った（Androidモードで） - Jan 20, 2014
液晶ペンタブレット買ったという話の続きで、運用編その1です。
お正月の間は、少しでも液晶ペンタブに慣れようと思って練習していました。Cintiq Companion Hybridは単独でAndroid端末としても使えるのが特長の製品で、お正月の間はこれだけ持って出かけていたので、自動的に練習はAndroidモード上で行うことになりました。単独では使えないCintiq 13HDだと、こうはいかなかったですね。
なのでこのエントリではAndroidモードの話をお送りします。とは言いつつ、液晶ペンタブ一般に適用できそうな話も入っていますので、Cintiq 13HDの導入を検討されている方の参考にもなるかもしれません。
液晶ペンタブレット買った - Jan 17, 2014
液晶タブレット買いました。僕もついにCintiqユーザ！ 「#!シス管系女子 Season2」第5話、日経Linux 2014年3月号掲載分からは新作画環境にてお送りいたします（予定）。
以下、3エントリに分けてCintiq Companion Hybrid導入の経緯やレビューを書いてみます。
「1日あたりの余計な摂取カロリーを減らせば無理せず痩せられる」っていうやつの自動計算 - Jan 07, 2014
テレビでやってた「1日あたりの余計な摂取カロリーを減らせば無理せず痩せられる」っていうやつの計算式を覚えてられなかったので自動的に計算するようにしてみた。（JavaScriptが有効なら表示されるはず。数値は半角英数字で入力してください。）
僕の今の数値を入れると結果は355.0114285714285と出ました……
「#!シス管系女子 Season2」第3話掲載の2014年1月号、発売中です - Dec 08, 2013
表題の通り、「#!シス管系女子 Season2」の第3話が掲載されている日経Linuxの2014年1月号が発売中です（PDF版はまだのようで、今の所オンラインでは紙版のみ購入できる模様です）。
今回は、前回・前々回で解説した内容を踏まえて、鍵認証とcronjobの組み合わせによる自動処理をやってみましょうという話です。ほんとは「Season2」一発目でこれをやろうと思ってたんですが、結構時間かかってしまいました……
ところで、Season2の3話ってなんやねんという感じでちょっと状況が混乱してきている感があるので、ここで改めて「シス管系女子」シリーズの概要を説明してみたいと思います。
「シス管系女子（以下、無印）」「#!シス管系女子」「#!シス管系女子 Season2」は、日経Linux 2011年9月号から（時々休載を挟みつつ）連載させて頂いている、Linux・コマンドライン・シェルスクリプト系なんでもありのゆるゆる学習漫画です。無印時代はターミナルを使った操作の基本を扱っていて、「#!」以降はシェルスクリプトをメインに置いた内容となっていますが、前回（鍵認証）・前々回（cronjob）のように必要に応じて要素技術を適宜解説していく感じでやっております。以下は、担当記者さんによる紹介記事です。
基本とは言っているものの、lsやcdといったあたりはざっくりとスキップして、「コマンドラインはちょっとは使ったことあるけど、本格的には使っていない」という段階から1ステップ上を目指そう！という趣旨で話題を選んでいます。また、基本的には時事ネタは扱っていなくて、cutコマンドやscpコマンドの使い方のように、比較的枯れた・安定して使える技術やテクニックを主に扱っています。
1年に1回くらいタイトルを微妙に変えながら続いていて、今回で通算27話にあたります。まだ正式な単行本化はされていないのですが、これも1年1回くらいのペースで「まとめ読み」とした冊子を日経Linuxの付録に付けていただいていて、その中でも無印の全話が収録された「シス管系女子 まとめ読み」は、単独で達人出版会さんからPDF版をダウンロード購入していただけるようになっております。
正式な単行本リリースを目標に、僕の気力と体力が続く限りは今後も頑張って参りますので、なにとぞ応援の程宜しくお願い致します！
達人出版会さんで無印「シス管系女子」まとめ読みをダウンロードできるようになりました&「王様達のヴァイキング」が面白い！ - Nov 15, 2013
表題の通り、「シス管系女子」無印のまとめ本のPDFを達人出版会さんでダウンロード購入できるようになりました。サンプルのページでは1話から4話まで、ページ数にして1/3くらいを無料で試し読みできるようになってます。
中身については過去に「日経Linux」本誌付録DVDに収録されたPDFと全く同一で、描き下ろしが増えているということはありませんのでご注意下さい（付録DVD収録時には本編切り出しに差し替わっていた表紙がまとめ本準拠の物に戻っている、という程度の違いです）。また、ぶっちゃけた話、達人出版会版がめっちゃダウンロードされまくったとしても僕のお財布がものすんごく潤うというわけでもなかったりします。いわゆるひとつの電子書籍での単行本化リリースではなく、あくまで過去の本誌付録の単品での再頒布ということになりますので、当該号を購入されていなかった方で単行本化を待ちきれないよという方のための物と言えそうです。
……という事になってくると「単行本化しないフラグか……？」と思われる向きもあるかと思いますが、編集さんに聞いてみたところそういうわけでもないそうです。僕としても、単行本になるなら本編で触れられなかった点のフォローとかのおまけページを用意したいと思っていますし、その時は全力で告知すると思いますので、大変申し訳ないのですが、単行本派の方はまだもうしばらくお待ちを頂けましたら幸いです。（単行本化が全くあり得ないという事になれば、その時はその時でアナウンスします。）
あと、「#!シス管系女子 Season2」と題して連載継続中の日経Linux 2013年12月号も、紙版、PDF版ともに発売中です。今回はまたシェルスクリプトの話からちょっと脱線して、公開鍵認証の解説をしております（これから先の話をするにはやはり避けて通れなかったので）。
その話の中で「どういうパスワード（パスフレーズ）にするといいのか？」という事にちょっとだけ触れているのですが、本編中で書いているようなもじり方は結構典型的な物なので、辞書攻撃に対する耐性がそれほど強いというわけではないと思われます。じゃあどういうパスフレーズなら安全なんだよって話なんですが、「王様達のヴァイキング」という漫画でまさにそういう話が描かれていましたので、ご紹介しておきます。
こちらは「シス管系女子」とは全く違って、物凄いハッキング（クラッキング）技術を持った非コミュの少年がそのたぐいまれな技能を使って社会の中で自分の生きる場所を見つけていくというお話です。ガチのエンジニアが監修に協力されているという事で技術的な観点でのリアリティは折り紙付き、そして話の内容も安易な「ハッキングもの」とは一線を画していて、とても面白かったです。安全（堅牢）なパスワードの話は2巻目で登場しますが、是非とも1巻から読んでみて下さい。
（自分の漫画の宣伝だったはずが、「王様達のヴァイキング」の宣伝になってる……）
Firefox for Androidに仮想的なスクロールバーを導入するScrollbar Like Scrollerを更新した - Nov 13, 2013
Scrollbar Like Scrollerを更新した。
1.0/1.1での大きな変更点として、仮想的な「つまみ」を導入して、それ以外の場所では反応しないようにした。使い勝手が悪くなったと見る向きもあるかもしれないけど、前の挙動に戻すつもりはないです。
というのも、僕が自分で実際に使ってた感想として、何も無いところでスワイプやパンスクロールしようとして急に画面が飛んでしてしまう（スクロールバー風操作の開始と判断して、指があった位置から計算したスクロール位置まで強制的にスクロールしてしまう）という誤爆が何度かあってイラッときてしまったのです。
スクロール位置を示すインジケーター自体はFirefoxも提供してるんだけど、これは注意深く見ないと気がつかないようなさりげなさで表示されているので、UIとしてこれを目印にするのは辛い。と思ったというのもあって、ぶっとい「つまみ」に相当する物を自前で表示するようにした。これをなるべく正確な位置に表示したくてああだこうだと座標をいじくり回した結果、指のある位置からのスクロール位置の算出が前よりグッと正確になったので、そういう意味でも成果はあったと思う。
もう1つの変更として、画面の上端や左端もスクロールバーとして動作するようにした。右手でスマホを持って親指でスクロールしてる時は右にスクロールバーが出てていいんだけど、左手で持って親指でスクロールしてると、右端に出るつまみまで指が届かなかったので。最後にパンスクロールした時のタッチ位置が画面の1/3より左だったら左につまみが出るようになってるけど、つまみが出てない時でも、つまみがあるであろう位置を指で操作すればスクロール操作は開始できます。
もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - Nov 10, 2013
人格攻撃をしたくて書いてるわけじゃないですよ、という事はまず最初に表明しておきます。
GitHubで公開してるプロジェクトについて、幸いなことに時々プルリクエストをもらえる事があるんだけれども、その時に、何のストレスもなく「Merge」ボタンを押せる時と、そうでない時とがあるなあと思ってた。
その差は何なんだろう？と思ってたんだけど、今回treestyletabのargumentsを使っている箇所を書き換えるプルリクエストをもらって、それに関してやり取りをした事を通じて、「あ、こういう事かな」と思った点が1つあった。
それは、「相手の考えを尊重する態度が見られるかどうか」。
ロケールの翻訳であったり単純なtypoの訂正であったりというパッチではそういうのはまず見えてこないんだけど、今回のように設計のポリシーにまで踏み込んだパッチだと、互いの思惑がずれていることが見えてくる事がある。今回の場合、僕と彼とでは「こうあるべき」と思っているコードの姿がずれているんだなと思った。また、「ああ、僕がこれほど大事に思っていることが、彼にとっては些事に過ぎないと見えているのだなあ」という残念な思いも感じた。
考え方が違うことがすべて悪だとは思わない。JavaScriptの古い仕様であるargumentsから、ES6のRest argumentsへの置き換えを進めるというのは、古い物ばかり見てしまっていて且つ保守的な自分からはそういう発想がまず出てこない（大抵、どうしようもなくなってからようやく重い腰を上げる感じです）ので、自分の目が届いていないところについて「こういうのもあるよ」と教えてもらえるのは、正直、とてもありがたい。
ただ、僕が大事だと思っている事についてバッサリ切り捨てるような態度を取られるのには、いい気がしない。arguments・Rest argumentsで全部の引数を引き渡すように書くべきか、それともすべての引数をきちんと定義しておくべきか、という議論では特にそれを強く感じた。
僕は僕なりの考えを持って、過去に悩まされた色々な事例からの反省であったり、現実的にどこまでメンテナンスに時間をかけられるかという葛藤であったり、どういうコードであれば僕の思う「How」を正しく書き記せるのかであったり、といった事を考えた結果としてああいうコードを書いていたのだけれども、それらの一切合切を無視して「こうあるべき」と別のスタイルを押しつけられることに、僕はどうしても不快感を感じてしまった。コードを自分と同一視していて、自分自身を否定されたかのような感覚すらあったのかもしれない。最初の1回だったら、まあそういう前提が共有されているはずもないので、齟齬があるのはしょうがないと思うんだけど、2度にわたって否定されると、「あ、この人は僕のいろんな思いを尊重しようというつもりが全然ないんだな」と感じて、急速に心が冷たくなっていく、そんな感じがした。
何年もコードを書いてきたんだとか、自分がここまで育ててきたんだとか、そんなクソくっだらない個人的感情に基づいた見栄でもって、真理を歪めてはならない、というのは、その通りだと思う。でも、とても残念なことなんだけど、僕は大義のために自分の命や思い入れをためらいなく差し出せるタイプの人間ではなく、むしろ個人的な感情の方をこそ大事にしてしまうタイプの人間のようなのだ。僕はそういう頭の悪い人間ではないのだ・もっと賢くて理性的な人間なのだと思い込もうとしてたんだけど、実際にはそうではない・そうなれないのだなということを、31歳の今では痛感している。
思い返してみると、僕がかつて「技術系コミュニティ」という物に激しい拒否感を持っていたのは、それが理由だったのかもしれない。唯一絶対の真理として論理的な正さを偏重し、そうでない価値観は無意味と切り捨てる、そういう傲慢さや冷酷さのような物を僕は嫌っていたのだと思う。まあ、そういう自分の想いでもって彼らを・世界を変えたいと思っていたというのも、また同種の傲慢だったのだなという事も今では分かる。我か彼かではなく、どちらの価値観も並行して存在していてよいのだ、そういうカオスを受け入れることが大事なのだ、という事を認識できるようになったのは、それよりずいぶん後になってからのことだ。
ともかく、そういう残念な人間である僕にとって、一緒に作業をしたいと思える相手はやはり、僕の思いをなるべく尊重してくれる人という事になるのだなあ、と思うし、また自分が他の人と一緒に作業する時も、ある一面から見た時だけの正義をいたずらに振り回すことなく、最大限相手の思いを尊重して事にあたっていきたいなあ、と思う、そんなことを改めて考えた出来事だったのでした。
世の中には、ぬるま湯に浸かっていては駄目だ、自分の間違いをビシビシ指摘してくれる厳しい人と一緒にこそいるべきだ、という言説もある。僕はそれは、基本的にはいい事言ってると思うんだけど、でも、そこに相手を尊重する態度があるかどうかってのが、結構重要なんじゃないかと思ってる。
相手を尊重した上で、その思いを遂げるためにはもっとこうした方が良いよ、というアドバイスをしたり、その思いはこれこれこういう前提がおかしいよと新しい視点を示すというのは、僕にはまだ受け入れられるんじゃないかなって思う。でも、そうでなく、お前は間違っているからこうするべきだ、と、僕の思いを歯牙にもかけないでその人の思う正義であったりあるいは誰か第三者が掲げる正解であったりに沿って特定の行動を押しつけられるというのは、ストレスになる。その「厳しい指摘」がどっちであるかというのは、論理的な正しさだけを見ていると分からないと思う。
俗な言い方をすると、それが「愛があるかないか」って事なんじゃないだろうか。「厳しい指摘」をする時に、「指摘する側である自分の自己愛に溢れた指摘（独り善がりな指摘）」ではなく「指摘される相手への愛がある指摘」をする、というのは、なかなか難しいことだと思うけれども、せめてそう心がけたいとは思ってる。
また、逆に言うと、自分に向けられた「厳しい指摘」をすべて受け入れるでもすべて拒否するでもなく、その中で「愛のある指摘」を上手くより分けることができれば、他人の言説にいたずらに振り回されて疲弊することも、世界全部を敵に回しているかのような疎外感を感じることも、ないのかな……とも思う。
結論：愛は地球を救う！
Firefox for Android用のアドオンを作った - Nov 08, 2013
Nexus 7を買って以降、Firefox for Androidをエンドユーザとして使うようになってそれなりに経つんだけど、布団の中でWebブラウズする時間がだんだん長くなってきて（病気で……とかじゃなくて、単にPCの前に座って作業するのが億劫になってきたという事です）、触る時間・頻度が増えてくると、色々細かい所で「イラッ」と来るようになってきた。
アドオンを作れば解決できるんだろうなあと思ってはいたんだけど、既に何十とリポジトリを作っていてメンテナンスしきれてない僕がまた新しく抱え込むのは世界に不幸を増やす事になるのではないか……と思って、「他の誰かがやってくれないかなあ」と淡い期待を抱きながら待ってたんだけど、僕の不満が解消されるような物が出てくる気配が一向になかったので、カッとなった勢いで2つほど作ってAMOに登録してみた。ああ、またつまらぬ物を作ってしまった……
Scrollbar Like Scroller（スクロールバー風スクロール）は、いくつかのAndroidアプリ（具体的にはJota Text Editorとか）で実装されていた「基本的にはパンスクロールだけど、必要に応じてスクロールバーも使える」的な挙動を実現する物。はい、どこからどう見てもパクリです。
ビューポートの大きさの解像度とタッチイベントの座標の解像度が違うという点でドツボに填って難儀したけど、タッチイベントの座標を現在のズーム率とかけ算した値がどうやらビューポートのサイズと同じ解像度になるようだったので、どうにかそれらしい動きを実現できた。
縦にクソ長い2chまとめだとかTogetterまとめだとかを見た後で最初の方までスクロールするのにパンスクロールのためのスワイプ操作で画面をひたすらこするのにウンザリしていて、このままじゃ画面か指が削れて無くなっちまうよ！！！という悩みはこれで解消されると思う。
Open Local File（ローカルファイルを開く）は、名前の通りで、なぜかAndroid版Firefoxに標準で付いてない「ローカルファイルを選択して開く」機能を加えるだけの物。一旦ダウンロードして保存したXPIファイルをファイルブラウザからFirefoxを指定して開こうと思ったら、関連付けでJota Text Editor固定になってしまっててどう頑張っても開けず、関連付けを設定し直すのもイヤだったので、作った。
nsIFilePickerでやってるんだけど、modeGetFolderが未実装だったり最後に開いたディレクトリを記録・反映できなかったりと、PC版と同じように作るのはやはり難しいのだなあ。という事を改めて思い知らされた感じです。
あと選択範囲のリンクをまとめて保存する機能なんかも欲しかったんだけどゼロから作るのはさすがに辛かったので、これはSave Link Menusを改造して作った。
デスクトップ版FirefoxとAndroid版FirefoxではAPIが違う部分が多いので（低レベルのAPIは共通でもUIに近い部分は全然違う）、まだまだおぼつかない感じだし、ちょっと凝ったことをやろうとするとドキュメントが無いというかつてのMozilla Application Suite時代のアドオン開発を想起させられる手探りっぷりだけど、必要になったらさっと作れるくらいにはなれるといいなあ。
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:
- "Drag as Child" is difficult to perform with tab animation · Issue #399 · piroor/treestyletab
- Turn off tab animations · Issue #499 · piroor/treestyletab
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文字目は大文字にしたほうがよい。ということは言えるようだ。
プロジェクト名や社名や製品名の英語表記について、「テキストデータの中では大文字始まり」「ロゴタイプでは小文字始まり」という使い分けがなされている事例をよく見る。例えばこんなの。
- Ubuntu
- Debian
- Red Hat
- Mozilla
- Node.js
- Twitter（過去に使われていたロゴマークやTweetボタンでは「twitter」に見える書体が使われていた）
振り返ってみると、「固有名詞だがテキストデータ上も小文字始まりである」というケースは、日本人が書いている以外の例を僕は見た事がない気がする（Gemのパッケージ名だとかコマンド名だとかは例外ね）。
例えばミクシィは、ロゴタイプが小文字始まりの「mixi」だが、Webサイト上のテキストデータも小文字始まりの「mixi」で統一されているようだ。mixi自身が提供する英語版コンテンツでも小文字始まり。でも外部の人が編集したと思われる英語版Wikipediaのページでは、大文字始まりで表記されている。
英語ネイティブの人達にとってはどういう感覚なのだろうか？という事を知りたくて英語版Wikipediaで固有名詞の英語におけるキャピタライゼーションについての記述を参照したら、「summer」や「winter」などのごく少数の例外を除いて、固有名詞は大文字始まりで表記するのが原則であるという風なことが書かれていた。
そういえば以前に読んだ記事で、TwitterだかGoogleだかが、サービス名や社名を小文字始まりで書いたり、「ググる」みたいな俗語として「googling」を使ったりということについて、文句を言っているとか、辞書にそういう見出しで掲載するんじゃないと非難しているとか、そういう話を見たことがあったと思う。
英語ネイティブな人が身近にいないから、外してるかもなって思うんだけど、彼らにとっては、「固有名詞は大文字始まりで書くのが原則である、小文字始まりの固有名詞は不自然である」という感覚は、「印象を柔らかくしたいので小文字で表記したい」という欲求よりも優先度・重要度が高い……というか、 後者を優先するという発想が出てこないほどに、前者の感覚が常識として浸透している という事なのかなあ、と、僕は思っている。
もっと言うと、（mixiがそうしているように）日本人が固有名詞を頑なに小文字表記で書きたがるというのは、彼らから見たら、日本語の事を分かっていないDQN親が中二病な発想でキラキラネームを子供に付けてキャッキャ言ってるようなものなんじゃないのかなあ、と、僕には思えてしまう。いや、英語ネイティブの人達がほんとにそう思ってるかどうかは知らないけど、僕はmixiのような事例を見る度に、「うあああニワカが厨二病発症して俺ルール貫いてるよおおお！！ 英語の本家であらせられるところのネイティブの人達に失笑されてるに違いないよおおお！！」と、無意味に恥ずかしく感じてしまう。
と、ここまで書いたところでこのサイトの名前も小文字始まり表記である事に今頃気が付いて、どう見ても完全にブーメランなのでした。