Latest topics 近況報告

もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - 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
• Open Local File

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
• Facebook
• Twitter（過去に使われていたロゴマークやTweetボタンでは「twitter」に見える書体が使われていた）

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

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

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

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

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

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

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

巨大ロボや怪獣にかつて心躍らせた人、チャチいのはちょっと……と敬遠していた人にこそ見てもらいたい「パシフィック・リム」 - Sep 29, 2013

先日、パシフィック・リムを見ました。

「ハリウッドで、巨大ロボと怪獣が闘う映画が作られました」というと、こう、なんていうか、「怪獣が現れた！（最初の30分のイントロ）→人類がピンチだ！（この辺をたっぷり描く）→巨大ロボ完成した！（この辺でもう残り30分くらい）→どうにか退けた！→やったね！（エンドロール）」という感じの、ビミョーに残念な物が来るんじゃないのかなーって、本作の最初のニュースを見た時は思ったんですよ。その記事にあった画像のロボのデザインも、ああなんだかアメリカンなテイストだなあ、違うんだよなぁ「コレジャナイ」んだよなぁ……とガックリくる感じだったし。

それで映画の存在をすっかり忘れてた頃に公開が始まったわけですが、なんか妙な事になってたんですよね、自分の観測範囲の景色が。Twitterのタイムラインでは、「パシフィック・リム最高」みたいなTweetがフォローしてる人のTweetだったりその人によるRTだったりで妙に流れてるし、フィードを購読してるブログ（普段は辛口・うるさ型な感じの記事が多い）でも大絶讃されてるし。こうなると俄然興味が湧いてきまして。Tweetで紹介されてたNAVERまとめも見たりなんかして、一部の人に絶讃されてる割に興行的には苦戦しててあっという間に映画館から姿を消してしまいそうだみたいな記述も見かけて、これはちょっとほんとになるはやで見に行っとかないとヤバいなという焦りが出てきまして、コミケが終わって一段落付いた後にようやく3D吹き替え版を見てきたわけです。

結論から言うと、最高だった！！の一言に尽きます。

どのくらい良かったかというと、あまりに最高すぎて超ドハマリしちゃってうっかり2回も見に行ってしまい（初回は3D吹き替え、2回目は3D字幕）、さらにもう1回（2D字幕）行く予定になっています。同じ映画を何度も映画館まで見に行くのは人生で初めてです。パシリム成分に飢えすぎて、ブルーレイの発売（12月）を待てずにサウンドトラックのCDも買ってしまいました。

ライムスター宇多丸さんのムービーウォッチメンでも「減点はあるけど、怪獣で100億点、巨大ロボで100億点の、200億点満点からのマイナス15点くらいだ（＝19999999985点）」なんて高評価がなされてたりして、もう既に多くの人によって感想とか評論とか色々と出尽くしてしまってるんですが、せっかくだから自分も記念に書いておこう、と思って書き始めたのがこのエントリというわけです。

あらすじとか

巨大怪獣が太平洋の海底から突如出現して、環太平洋地域の都市を襲ってきましたよと（タイトルの「パシフィック・リム」とはまさに「環太平洋地域」という意味）。で、最初の何体かは核兵器で倒したけど、核兵器は使った後が大変だし、でも怪獣はまだまだやってきそうだし、なんかクリーンな倒し方が必要だと。それで開発されたのが、全高80メートルの巨大ロボット（劇中では「イェーガー」と呼称される）だと。操縦はパイロット2人が協力して行い、主にぶん殴って怪獣にダメージを与えて倒しますよと。そういう設定のお話です。

という設定から真っ先に想起されるのは多分やはり「「怪獣が現れた！（最初の30分）→人類がピンチだ！（この辺をたっぷり描く）→巨大ロボ完成した！（残り30分くらい）→どうにか退けた！→やったね！」ってな感じのハリウッド式パニックムービーテンプレだと思うのですが、本作ではこれを最初の10分くらいで「前回までのあらすじ！」みたいなノリであっさりと消化してしまいます（本作は何かの続編ではなくて完全新作なんですが、そういう感じでさらっと流されちゃうという事です）。劇中でメインのエピソードとなるのはむしろその先の、対怪獣の切り札・イェーガーを環太平洋地域の各国がそれぞれ保有するようになってから後の話。

一旦は盛り返した人類であったものの、怪獣がだんだん強くなってきて、せっかく作ったイェーガーもどんどん倒されていく。今まで快進撃だった主人公機も、新たな敵に思わぬ苦戦を強いられ、辛くも勝利したもののこちらも大ダメージで倒れてしまう。破滅が刻一刻と迫ってくる追い詰められた状況での、主人公の復活から起死回生の最終決戦までが、たっぷり2時間使って描かれています。

そう。本作は「パニックムービー」ではなく、まさしく「巨大ロボ対怪獣の映画」なのです。

それに対する思い入れも何も無い人が「こうした方がウケるから任せとけって！」といじくり倒す問題

スーパーマン然り、スパイダーマン然り、ハリウッドでは度々アメコミヒーローが実写映画化されていますが、それらは基本的にはちゃんとヒーロームービーしてる印象があります。なので、また何か別のヒーローが実写映画化されると言われても、そんなに驚きは感じないというのが僕の正直な所です。

が、巨大ロボとか怪獣とかの「日本のお家芸」のハリウッド映画化となると、俄然不安になります。というのも、「ゴジラ」をハリウッドで1998年にリメイクした「GODZILLA」が非常に残念な出来でしたし、「DRAGONBALL EVOLUTION」も、設定を聞くだけで「ないわー……」な感じでした（←ということで僕は未見）。

多分なんですけど、アメコミヒーローの実写映画は、作り手の人達の中にちゃんとそのヒーローの事が好きな人がいるんだと思うんですよ。あるいは自分自身ではそこまで好きというわけではないとしても、そのヒーローのどういう所がファンに愛されているのかという事が、皮膚感覚としてそれなりに理解できてるんじゃないでしょうか。

でも巨大ロボとか怪獣とかドラゴンボールとかになってくると、それらの題材のどこがファンに愛されているのかがさっぱり分からない、想像も付かない、肌感覚で分からない……っていうのがあるんじゃないかって思うんです。それで、分からないなりに自分の感覚でどうにか分かる形に当てはめようとして、トンチンカンな答えを出しちゃう、っていう。ハリウッド映画に限らず、いろんな所でありふれてる話ですよね、こういうの。今が旬の剛/力/彩/芽が主演する作品の原作にビブリア古書堂が大抜擢されました、みたいな（これはちょっと違うか）。

ちなみに、ロボといえばトランスフォーマーの実写化がありましたが、あれは意志を持った金属生命体型宇宙人同士の闘いの話なので、日本語で言う所の巨大ロボとは趣がちょっと異なります。あのノリでロボ対怪獣を作られると、まあ映像は多分凄いんだろうとは思うんですが、やっぱりそれはなんか違うな……って。

そういう心配は、パシフィック・リムについては、後から思うと全くの杞憂でした。なにせ監督のギレルモ・デル・トロ氏自身がとんでもないオタクで、来日した際には中野ブロードウェイのまんだらけや秋葉原のショップで怪獣グッズを買いまくるという筋金入り。一番のファン目線の持ち主が、映画監督としての実績も実力もあるプロとして、巨額の予算を好きに使って「自分が見たかった映像」を作るわけです。非常にありがたい話ですよ、これは。

「見立て」の必要がない、圧倒的な映像が持つ力

すごい映像というのは、それだけで商品価値があります。

ストーリーはかなり単純、メカデザインは（主役機は特に）ダサいくらい。でも、ものすごいコストをかけて「男の子が夢想するような巨大ロボ対怪獣の映像」を真面目に作り込んである。その圧倒的な映像の前では、他の部分の粗なんてどうでもよくなる。本作はそういうタイプの映画だと思います。

その対極として、「これは視覚的表現としてはショボいけど、本当はこういう凄い物を表現してるつもりなんですよ、だから見る人の側で見立てて脳内補完して楽しんで下さいね」という種類の作品もあります。能や狂言、文楽などに至っては、そういう「見立て」がなければ成り立ちません。観客の側が「こう見るのだな」ということを勉強しないと楽しめない、そういう娯楽です。

本作に対する世の評論等を見ていると、日本で作られる怪獣映画、特撮作品は、そういう「見立て」を強く必要とする領域に突っ込んでしまっている……といった指摘が目につきました。例えば近年ではエヴァQと同時上映された「巨神兵東京に現る」がありましたが、あれはエフェクト等はすごいなあと自分は思ったのですけれども、肝心の巨神兵自体はどうにもゴムっぽい質感が見えるというか、作り物っぽさが目立つというか……それを観客の側が「これは、実在していたらこういう物なのだ」と「見立て」ないとリアルな映像としては楽しみきれない、そういう印象を僕も受けました。

「見立て」スキルの持ち主でなければ楽しめない作品、という事を考えてハッとしました。僕自身が「見立て」スキルをあまり持っておらず、あるいは成長の過程で失ってしまっていて、古い特撮の作品（例えば「エイリアン」の第1作だったり、「ロボコップ」だったり）を見ると、セットや衣装の粗やチャチさが目について楽しみきれない、そういう所が実際にある気がしたからです。

本作は、そんな自分でも無心で楽しめました。それは、「見立て」る必要が無いほどのリアルな映像表現があったからこそなのではないかと思います。

本作の制作費（広告宣伝費含まず）は、ものの記事によると1億9千万ドル。これは「アバター」の制作費（2億ドルちょい）に迫る勢いで、日本円にすると180億円以上。予算規模では文句なしの大作です。こういう凄い額のお金がかかってる映画を、ビッグバジェットと言うという事を僕は今回初めて知ったのですけれども。それだけかければこれだけの映像が作れる。逆に言うと、これだけの映像を作るにはそれだけの金がかかる。世界中で上映して稼ぐという前提があるために1作の映画に巨額を投じられるハリウッドでしか作れないであろう、本作はそういう作品なんですね。

メカデザインが少々ダサくても全く問題なかった

本作のメカデザインは、日本のロボット物に慣れた目からすると、ぶっちゃけそんなに洗練されてない印象を受けました。洗練されてないというか、「外連味溢れる格好いいメカ」とは違うベクトルのデザインであるというか。

劇中で活躍していた「ストライカー・エウレカ」や、オープニングにチラッと登場していた「タシット・ローニン」は、そういう意味では「格好いいメカ」の系譜にある物なのですけれども、主役機の「ジブシー・デンジャー」は相当にダサイです。というか、ストライカーは当初は主役機用に作られたデザインだったらしいのですけれども、デル・トロ監督曰く「これじゃ格好良すぎるから」ということで敢えて今のジプシーのデザインに変えたんだそうで、その事からも「なるほどジプシーは誰の目から見てもやはり、流行りのラインからは外れたダサめのデザインなのだな」という事はうかがえます。

ですが、実際の映像を見ているとこれが驚くほどに気にならない。むしろ、ジプシー格好いい！！！と全力で頷いてしまう勢いです。

結局の所、「∀ガンダム」然り「地球防衛企業 ダイ・ガード」然り、本編中で活躍してそれが格好良く描かれていれば、そのメカは格好いいメカという事になるのでしょう。活躍を見た側の脳内に、あのメカは格好良く活躍していたのだという思い出が残されることによって、かつてはダサく見えたメカが、格好良く見えてきてしまう。そういう事なのだと思います。

というわけで、僕は7インチフィギュアのシリーズもだいぶ欲しくなってきてます。香港決戦に参加した4体、できれば揃えたいです。

そば屋にそばを食べに行って、実にまっとうに美味いそばが出てきた、という感覚

総括すると、僕にとってこのパシフィック・リムという作品は、「そば屋で食べた美味いもりそば」と言うことができると思います。

思えば、過去に僕が気に入ってきたメカや作品の多くは、豊富な具が売りの5品割子だったり、豪華なエビ天が載った天そばだったり、スパイスがきいたカレーそばだったりという物に例えることができるのでしょう。確かにそれらは美味かったし、何度でも好んで注文する。そば自体もそれなりに美味い。それなりに美味いんだけど、物足りないから具を付ける。

でも本当に素材から良い物を使って、腕のある職人によって打たれたそばは、もりそばだけで十分楽しめる。口に入れると、これがそばだ！という香りがプンプン漂ってきて、物足りなさを感じることがない。話が単純だとか、メカがダサイとかいうのは、「なんでこのそばには具が付いてないんだ」と文句を言うような物なのだと思います。もちろん具が付いてくればそれはきっと美味しく楽しめるのでしょうけれども、無いからダメだというものでもない。むしろ、装飾が少ないからそば自体の良さが引き立つ。ストライカーのピンチに駆け付けてレザーバックに全力で殴りかかるジプシーの格好良さは、あれが仮にスパロボオリジナルのメカのようないかにも格好いいデザインであったとしても多分格好良く感じられたでしょう。でも、あのジプシーで十分格好良いのです。もっと派手なメカにするのは、「あのジプシーであの格好良さ」に飽きてからでも遅くないでしょう。

そば屋に行って、そばカレー定食セットのカレーを食べて、「このカレー超うめえ！！！」って言ってる人がいようがいまいが、「このカレー、シャバシャバで超まずい！！！」って言ってる人がいようがいまいが、その店がそば屋である事には変わりないし、一番の売りはそばなワケです。脚本が良いのか悪いのか、演技が上手いのか下手なのか、僕には正直よく分かりませんが、少なくとも一番の売りである「巨大ロボ対怪獣」を邪魔するような違和感のあるものではなかったと思ってます。そばの味を邪魔するような薬味やつゆでないのなら、僕は文句は無いです（もちろん、美味ければそれに越した事はないのですけれども）。

これが、例えば構成が実写デビルマンのようにメタメタだったら、マコの吹き替えが「TIME」のヒロインを吹き替えた篠田真理子の声だったら、一番の売りの良さすらもスポイルするようなとんでもないものになってただろうなと思います。が、パシフィック・リムについては、場面設定、脚本、演者の演技、音楽などなど、「巨大ロボ対怪獣」という主題が映える・それを引き立ててくれる、必要十分の基準を満たすレベルであったと僕は思っています。

かつて「巨大ロボ対怪獣」に燃えたことがある人、また、それらが好きになる素地のある人に、ぜひ見て欲しい

そばが好きだったのに、気がついたら赤いきつねと緑のたぬきや乾燥麺や工場生産の安いそばでは満足できなくなってしまって、そば自体を食べなくなってしまった。でも心のどこかで、そばを食べた時のあの感動をもう1度味わいたいと思っていた。それが、職人の手打ちのそばを食べて、そばってこんなに美味い物だったんだ！と、かつての新鮮な感動を取り戻す。本作で得られるのは、そんな感動だと思います。幼い頃に巨大ロボや怪獣に燃えていたのに、でも大人になった今の目で見るとチャチさに耐えられなくて正視できなくて残念な思いをしてしまう、そんな人にこそ、パシフィック・リムはぜひ見て欲しい一作です。

また、巨大ロボや怪獣は映像がチャチいから興味ないんだよね、という人にもぜひ見て欲しいです。その人がそれらのジャンルを避けていたのが、巨大ロボや怪獣に興味が無いからではなく、たまたまこれまで出会った作品の映像のクオリティが高くなかったからだけだったのであれば、本作は、その偏見を吹き飛ばす力を持っていると思います。

レンタルのDVDなんかではなく、映画館の大スクリーンで3Dでこそ、見て欲しい。それだけの価値がある映画です。

8月9日に公開開始されて1ヶ月以上が経過し、全国的には上映がすっかり終わってしまった頃合いですが、ファンの熱い声援に支えられて、各地で本作のリバイバル上映が決定しています。現時点（9月29日）での情報は以下の通りです。

• 名古屋 中川コロナシネマワールド　10月12日（土）～10月31日（木）
• 立川シネマシティ パシフィック・リム爆音上映会リターンズ 11月3日（日）
• ユナイテッドシネマ IMAXデジタルシアター MOVIE FESTIVAL
  • 浦和・岸和田・キャナルシティ　11月9日（土）～11月15日（金）
  • 札幌・としまえん　11月16日（土）～11月21日（木）
• シネマサンシャイン　IMAX･カーニバル
  • 大和郡山　11月1日（金）～11月7日（木）
  • 衣山　11月8日（金）～11月14日（木）
  • 土浦　11月15日（金）～11月21日（木）

上記一覧は2ちゃんねるの「映画作品・人」板にあるパシフィック・リムスレからの転載です。このスレに最新の情報が集まっているようなので、映画館で見てみたいという人はチェックしておくと良いと思います。

ITpro「記者の眼」の「シス管系女子」の紹介記事がきっかけで反省した話 - Sep 28, 2013

現在発売中の日経Linux 2013年10月号にまとめ本が付録で付いてきているマンガ「#!シス管系女子」ですが、担当さんが紹介記事を書いて下さいました。

記者の眼 - マンガで日本のITを救う：ITpro

内容を抜粋しての紹介と併せて、担当さんの視点からの裏話も掲載されています。読んでいて、立ち上げ期の事を色々思い出してしまいました。

で、その勢いで前回のまとめ本と今回のまとめ本を自分で一気読みしてみたのですが……いやー、これ、文字多過ぎ。夜に読んだら寝るわマジで……。前回のまとめ本の時にそれを痛感して、「#!シス管系女子」になってからはなるべく詰め込みすぎにならないようにと意識していたつもりだったんですが、まだまだでしたね。でもこれ以上セリフを減らすと解説が成り立たなくなりそうだし、悩むところです。

っていうか、上記の記事で抜粋されているような「いまいち分かりにくいものをビジュアル化して分かりやすく解説」というのも、そもそもは、「そういう文字ばっかりの説明をやってもしょうがないじゃないか！　漫画という表現形態ならもっと絵で説明しなきゃ勿体ない！」と思っての事だったのでした。しかし、無印時代は具体的なコマンドや仕組みの説明が多かったのでまだやりやすかったんですが、シェルスクリプト編に入ってからは抽象的な概念を扱う事が増えてきたということもあって、最近はうまくビジュアル化できてないまま送り出してしまっているなあ……と改めて反省しております。

「#!シス管系女子」の宣伝ということで上記記事を書いて下さったのですが、自分を省みるいい機会になりました。初心に返って頑張らねば……！

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

English version of this entry is available.

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

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

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

• "Drag as Child" is difficult to perform with tab animation · Issue #399 · piroor/treestyletab
• Turn off tab animations · Issue #499 · piroor/treestyletab

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

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

ですが、自分の認識としては、このパッチで示されている方向での対応というのは言わば、「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ではPromiseやTaskといった仕組みが導入されており、本来であれば、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というスクリプトは、そのための物と言えそう。）

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

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

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

日経Linux 2013年10月号は「#!シス管系女子」まとめ冊子付きです - Sep 05, 2013

情報が公になったっぽいので宣伝。

もうすぐ発売の日経Linux 2013年10月号ですが、別冊付録として「#!シス管系女子」の1話から11話までのまとめ冊子が付いてきます。その代わり、連載の方はお休みです。カラー化とか手直しとか（主に）コミケとかの作業で手一杯でそこまで手が回らなかったので、休ませて頂きました……次の話を楽しみにされていた方、すみません。

• 第1話（通算14話）の一部だけカラー化してあって、シス管系女子の作り方をまとめたのはこの作業があったからでした（説明用に使ってる話はカラーにはなってません）。
• 第2話（通算15話）の連載時にやらかしてしまった技術的な間違いについては、大筋を変えない形で訂正してあります。これでやっと、胸のつかえが1つ取れた感じです……
• 表紙の絵はコミケの作業の後で描いたので、コミケの時のノリが残ってしまってちょっと絵柄が違うような気がしなくもないです。次の回から本編がいきなり描き込みが激しくなるといった事は残念ながらありません。表紙詐欺や！

別冊付録じゃなくて単行本にならへんの？というツッコミもたまに頂きますが、ページ数が足りなくて……でもまあ、内容的には風化しにくそうな鉄板のトピックを取り上げるように心がけているつもりなので、出る頃にはすっかり時代後れだよコンチクショウってことにはならない……といいなあ。

ところで、前回のまとめ冊子を自分で見ていた時に、なんかすごいギュウギュウ詰め感で、通し読みするとやたら疲れたんですよね。同じような絵が無意味に連続してしまってたり、解説を盛り込むことを優先して内容の集積度が上がってしまったりと、「解説する」という事の方にばかり意識がいってしまって、基本的な漫画力の低さが露呈してしまった……ということだったのだと思います。

なので、その後に描いた分では意識的にメリハリを付けるように気をつけてみたつもりでした。できあがった物をまだ自分は紙媒体で読んでいないのですが、さて、成果が出ているかどうか。

オフィスの広さとか - Sep 05, 2013

妻の勤務先の会社が、なんやかやでオフィスが広くなったという話を聞きました。

場所を変えずに人を雇っていったら机が増えて椅子も増えてだんだん混雑してきて、最終的には、椅子を引いたら後ろの人に当たるくらいに物理的に窮屈なレベルになってたとかなってなかったとか。横でうるさくされていると気が散って作業に集中できないタイプだと言っていたので、それだけ混んでたらまあ嫌でしょうね……と、話を聞いて思ってたんですけど。それが一気に広くなって、だいぶストレスが軽減されたそうです。

他方、自分が仕事上でお付き合いのあるとある会社のオフィスは、マンションの一室で数人のスタッフがいて作業をしているという環境でした。後ろを通過するためには椅子を引いてもらわないといけない程度……ということは、話に聞いていた妻の職場環境と同じかそれ以上の人口密度なんじゃないかと思います。が、（実際どうなのか正直な所は聞いてみないと分かりませんが）そんなに皆さんストレスフルでイライラしているという印象は受けませんでした。

人には、踏み込まれると不快になる距離、パーソナルスペースというものがあるという話を聞いたことがあります。よく知らない相手だったり、嫌いな相手だったりすると、踏み込まれたら嫌な距離は大きくなり、家族だったらその距離は小さく、恋人同士や新婚カップルや親子だとゼロ距離でも不快に感じない、と。

妻の勤務している会社は数百人規模で、顔も名前も知らない社員がいて当たり前という環境だと聞きました。その一方で、僕がお邪魔したその会社は社員数1桁台で、気心知れた仲間同士でやっているという雰囲気があった気がします。もちろん個々人の性格や考え方による部分もあるとは思いますが、パーソナルスペースが重なり合うような窮屈さでも大丈夫というのは、気の合う仲間とだから成り立つ働き方なのかなあと思ったのでした。

僕はグッデイとクリアコードとMozilla Japanのオフィスしか仕事環境としては体験したことがなかった（打ち合わせやなんかで他の会社にお邪魔しても、見られるのはだいたい会議室まで）ので、世の中にはいろんなオフィスがあるのだなあと思うのですが、僕自身はというと、作業に集中してると周りのことが見えなくなってしまうタイプなので、もしかしたら（クーラーとかがきいてれば）トイレくらいの広さのスペースででも仕事できちゃうのかもしれません……

ニオイ - Aug 24, 2013

最近、奥さんのおばあさんの米寿のお祝いで、奥さんの実家にお邪魔しまして。泊まりがけだったのとその時はめちゃめちゃ暑かったのとで、着て行った服を洗濯していただきました（翌日がお祝いの本番で、その時用には別の服を持って行っていたのです）。

その事を特に思い出すこともないまま帰ってきてしばらく経ったある日のこと、出勤するのに着た服からなんか妙に甘い香りがするんですよね。なんだこれって思って。

それで理由をずっと考えてたんですが、トイレでウンコしてるときに気がつきまして。ああこれこないだ奥さんの実家に着ていったやつだ……と。普段自分ちで使ってる洗剤と違う洗剤で洗ったから、違う香りがついてたんですね。

テレビ見てると「一日中香りが続く!」と宣伝してる洗剤があったりしますが、実際丸1日同じ甘い香りが続くと（別に常時プンプン漂ってるわけではないんですが、風向きとかでふわっと漂ってくる）、なんか……べつにここまで香らなくてもいいかな……って気がしました。彼女とか奥さんとかに近寄ったときにふわっと漂ってくるのは多分ドキがムネムネしてキュンと来るアレなのですが、31歳おっさんの自分から漂ってきてもうれしくないです……

それはそれとして。

米寿のお祝いによせてメッセージカードを孫一同から送ろうという話になったそうで、ついでだからと自分もそこに混ぜて頂きました。しかし、以前に1回しか会ったことがなくて一体何を書けばいいものやら……と本番前日夜にうんうん唸っていて、「おめでとうございます」みたいな無難なメッセージから先にペンが進まずにおり、さりとて例文集を調べたら負けかなみたいな思いもあってまた一層うんうん唸っていたのですが、ふと思いついた事があって、それを書き始めてみたら自分で結構いい事言ってんじゃねって気分になってきたので、その路線で最後まで書き切ってみたんです。で、何を書いたのかという話なんですけども。

ほとんど話した事も無い直系姻族のおばあさんだけれども、当たり前だけどその人がいなかったら僕が結婚したこの奥さんは生まれていなかったし、もちろん僕が奥さんに出会うことも無かったんですよね。結婚自体してなかったかもしれない、漫画連載なんて事もできてなかったかもしれない（今できているのは奥さんのサポートがあってこそだと結構思ってる）。家の近くを散歩して何気ない風景を見て「面白いねえ」なんてなごやかに話すこともなかっただろうし、ダイビングだってやってみもしなかっただろうし、イルカと泳ぐことも、珊瑚礁の中を泳ぐこともなかっただろう。おばあさんがいなかったら、自分の今の幸せのかなりの部分が丸ごと全部無かったんだ。

そう思うと、奥さんのルーツにあたる人が88歳で今も生きていて「ありがとう」「おめでとう」を言えるというのはすごい事なんだなあと思えてきて、そういう事をメッセージカードに書いたのでした。

それで実際お会いした時に直接「ありがとう」と言えば良かったんだけど、お祝いの席では結構緊張してしまってそこまで気が回らなくて言えなかったので、次にお会いしたときに覚えていたら言っとこうと思います。

あとそういう感じでなんだか最近自分の親とか祖父とかにも今更なんだけど感謝だったり尊敬だったりという思いを感じるようになってきていて、最近になってやっと人間らしくなってきたのかなあ今までは文字通り薄情者だったのだなあということを思ったりもしています。自分が幸せだなあと心の底から思えるようになってないと周囲、特に親への感謝なんてできないものなのかなあ、とか。かつては「なんで幸せになれないんだ」という感じの妬み嫉みだったりムカツキだったりが強くあって、それから現実を受容して無心の境地を経て、やっと感謝の気持ちに辿り着いたのかなあとか。というふうな書き方をしているとなんだか宗教体験っぽくてアレですね。

それと、親の介護がとか自分や奥さんが大怪我して介護が必要になってとか、そういう重大な問題に見舞われた時にも自分がそんな殊勝な気持ちを保っていられるのかどうかというのは未知の領域なので、どうにか殊勝な気持ちを保っていられるといいなあと思っていますという所で話を結んでおこうと思います。