Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
JPOP王道進行とウンコ曲と「違いが分かる人」 - Oct 19, 2008
「JPOPサウンドの核心部分が、実は1つのコード進行で出来ていた」
- 日本でこの30年近くの間にヒットした曲の多くが、共通した性質、法則を持っている。
- 欧米で一時期流行ってあっという間に廃れた「ユーロビート」は日本でだけは今も親しまれているが、このユーロビートの曲もJPOPの曲と共通した性質を持っている。
- 売れないアーティストでも、この「王道進行」に則って曲を作った途端に大ヒットした。
- それさえやっとけば他はどうでもいい、ということでこの「王道進行」を使った安直な曲が粗造乱造され、日本の音楽界はとても悲惨な状況になっている。
ということを実際に曲を演奏しながら検証する動画と、JPOPのみならずヲタ好みの曲までもが同じ法則に則っていたことを証明する動画が、紹介されている。
- 王道進行に則っていて、名曲（日本でも世界でも売れる曲）
- 王道進行に則っていて、駄曲（世界では売れないが日本でだけ売れる曲）
- 王道進行に則っていなくて、名曲（世界では売れるが日本では売れない曲）
- 王道進行に則っていなくて、駄曲（日本でも世界でも売れない曲）
王道進行に則ってさえいれば売れる、ということで下らない曲を粗造乱造する日本の音楽業界の人間を批判しつつ、そのような下らない曲までも名曲と区別が付かずにありがたがって買い求める馬鹿な消費者をも、言外に批判しているわけだ。（買う馬鹿がいなきゃ、駄目な物が売れるわけがないからね。）
音楽の分野に限らずこういう話はよく出てくる（ユニクロとか）と思うけど、そういうのを見る度にいつも思うことがある。
この人のように音楽の専門家には「王道進行に則っていようがいまいが、本質的に名曲かどうかが分かる」のだろう。でも僕のように音楽の才能がない凡人には、「名曲であろうがあるまいが、王道進行に則っているかどうかしか分からない」んだよね。服に至っては、「流行に則っていようがいまいが、本質的にカッコイイかどうかが分かる」プロのファッション専門家や、「本質的に格好良かろうが悪かろうが、流行かどうかは分かる」一般人にすらも劣る、「本質的な良し悪しも流行かどうかすらも分からない」という有り様だ。
そういえば現代芸術というのは、いかにして価値観をひっくり返すかの優越感ゲームになっている、とどっかで言われているのを見た記憶がある。既製の便器に署名したり、演奏しないでピアノの前に4分半座ったりして、それを芸術と言い張った人達の話は知ってる人もそれなりにいるんじゃないだろうか。こういう人達の言う所の「一般人には違いが分からないだろうが、俺達には理解できる芸術性があるのだ。本質的にそれが名作かどうかが俺達には分かるのだ。」っていう話は、凡人の僕にはなかなか理解できない……真の意味を知ることができないのはもちろんのこと、概要すらも分からない。
僕が僕の耳で聞いて「いいな」と思った曲が音楽の専門家から「王道進行に則っていること以外に何もいい所がないクズ」と言われ、同時に、専門家が「これは名作だ」と褒めそやしている物と「クズ」との違いが僕には分からない。「いいな」と思った曲の中に、専門家が良いと言う物と悪いと言う物とが混在している。
彼ら専門家が物を選ぶ時と同じ基準で僕は物を選べていない。彼ら専門家が見ている所とは違う所しか見ないで物を選んでいる。権威たる彼ら専門家が「そこを見て物を選ぶべき」と言っているポイントで判断することができなくて、彼らが「そこで選ぶべきでない」と言っているポイントでしか物を判断できない。自分の素直な判断を信じると非難され、馬鹿にされる。
なのにその一方で、「人の言うことを気にせず自分の素直な判断を信じればいい」と、その専門家の人は言うのですよ。うん、たしかにあんたはあんたの「素直な感性」に従って物を選べば難なく「正解」できるんだろうよ。でもね、僕のような人間が自分の「素直な感性」に従って物を選んだら、「失敗」してしまうんだよ。あんたの言うことに従って行動したら、あんたに「ダメ」って言われるんだよ。訳わかんない。学習される無気力、って言葉をあんたは知ってるかい？
という風に事あるごとに考えるので、僕はその度に、何とも言えないイライラを感じる。
分割ブラウザ、マルチプルタブハンドラの連携の改善 - Oct 19, 2008
Firefox 3.1からの変更への対応に関する技術情報の中に書いたけど、分割ブラウザとマルチプルタブハンドラの連携を強化したり、分割ブラウザ側の「分割された領域」と「タブ」の連携を大幅に強化したりした。
ということをグダグダグダグダ書いてみても大して伝わらんだろうなあと思うので、実際に動いてる所のデモ動画を作ってみた。
<object width="425" height="350"> <param name="movie" value="http://www.youtube.com/v/-rfZNBy0jic"></param> <embed src="http://www.youtube.com/v/-rfZNBy0jic" type="application/x-shockwave-flash" width="425" height="350"></embed> </object>
Firefox 3.1上でなら擬似的な移動でなくホントの移動になるから、ストレスが無いし、書きかけのテキスト等が失われる心配も無いので、今以上にはるかに気軽に使えると思う。作った自分自身、これらの点がネックで今はほとんど使ってないので……
デモ動画自体の作り方もメモしておく。キャプチャはCamStudio、セッティングは「描いてみた」動画の作り方を参考に、ただしフレームレートは高めで。編集はNicoVisualEffectsでやった。CamStudio＋ffdshowでH264でエンコードしたaviが読み込めなくて詰まったけど、Wikiに挙がってたDirectShowプラグインというのをを入れたらちゃんと読み込めた。そんな具合で、初めてなんでちょっと手こずったけど、DebugMode Winkを使って作るのに比べるとタイムライン操作がやりやすいので、今後はデモ動画を作る時はこのやり方でいこうと思う。
ウィンドウ間でのタブの移動、というか、フレームの内容の入れ換え - Oct 19, 2008
Firefox 3.1からは、ウィンドウをまたいでタブを移動できるようになる。アドオンの作者はこれに合わせて修正を行わないといけない場合がある。
また、この機能を実現するために新しく用意された「表示されている2つのフレームの内容を破壊せずに入れ換える」APIは、他の目的でも利用することができる。
タブ系拡張機能 - Oct 16, 2008
そんなわけで（？）、TBE3に含まれる4つともアップデートした。
情報化タブの機能として、Firefox 3.1向けに、最後のタブのクローズボックスを強制的に表示させるオプションを加えた。本体の方でまた隠し設定がどうとか色々変わりそうな気もするけど、とりあえず現時点での仕様に合わせておく。不要になったら機能自体削除の可能性もある。
ソース表示タブは、機能は変わってないんだけど、動的に書き換えてるメソッド類がMinefieldでだいぶ変わってるようだったので、その修正が主。
マルチプルタブハンドラは、ツリー型タブの修正で書いたのと同じ要領でMenu Editorとの競合を解消したり、ツリー型タブと組み合わせた時の地味なトラブルを直したり、といった程度。
ツリー型タブ - Oct 15, 2008
ツリー型タブ 0.7.2008101501。前の版から4ヶ月も経ってた。使ってて見つけたバグはちまちま直してたんだけど他のユーザの人から英語で寄せられるバグ報告を放置放置でほったらかしてる間にまたずいぶん溜まってしまったのでちょっと頑張って処理してみた。FireGesturesの仕様変更への追従なんてもう何ヶ月も前の変更だから、もう意味が無くなってるかもしれないけど……まあ誰かに言われたら直そう（ぉぃ）。
Menu Editでタブのコンテキストメニューの項目が無限増殖する問題は、多分、分割ブラウザとの組み合わせを見越して各tabbrowser要素ごとにポップアップメニューの項目に一意なid文字列を生成するようにしていたせいだと思う。<tabbrowser id="content"/>なやつだけ特別に固定のidにするようにして、手元で試した限りでは無限増殖の問題は起こってない。マルチプルタブハンドラでも同じ問題が起こってるはずなので（報告すでに受けてたかも。あまりに多すぎて埋もれてしまってる可能性大。）、これは次のリリースで同じ修正を入れます。
Tab Mix Plusとの組み合わせで色々問題が起こってるという報告を受けてるけど、設定項目が多すぎてどの組み合わせで問題が起こるのか分からないのでお手上げです。とりあえず簡単に手元で試して再現しなかった物は放置。
カレースープ - Oct 13, 2008
このところコンビニ飯かスーパーの弁当かカップラーメンかレトルトカレーかという酷い食生活が続いていたので、一念発起して昨日タマネギとニンジンとジャガイモとカボチャを買い込んできた。味噌汁にしようと思って冷蔵庫の中を見たら、味噌がちょっとしかない（買い忘れてた）。ブイヨンは開封済みの箱の中身が1袋しかない。というわけで（？）、親が以前送ってくれて少しだけ使ったけどそれっきりになっていたカレー粉を使ってカレースープにしてみることにした。カレーライスにするつもりは最初から無いので、ブイヨンが足りない所を埋める感じ。
切った野菜とブイヨンとカレー粉と水を鍋にぶち込んで煮ること10分ちょい。できた。カレー粉の袋を見たら、カレーの作り方としては一度野菜類に全部火が通った後で火を消してから入れろ書いてあったんだけど、入れた後に気がついたのでもう後の祭り。
カボチャに皮は一応そぎ落とした後「でももったいないな」と思ったので結局全部入れた。緑黄色野菜の「緑」の部分だし。
肉っ気は皆無です。いつもそう。
カレー粉入れた時点で味の方はまあまあ（ジャングルで生き残るのにはカレー粉があればいい、ととある傭兵さんが言ってましたが至言ですね）なんだけど、人にお勧めしたり振る舞ったりする料理ではないよなあこれは。ただ空腹を満たすためだけの料理。
あと親が送ってくれた古々米を炊いて食べていますが、親は「餅米を加えるかなんかしないとおいしくない」と言ってたけど、僕の舌では、違いは分かるけど別にこのままでいいじゃんという感じです。経済的な舌ですね。
はてな投げ銭 - Oct 11, 2008
めさめさ久しぶりにはてなポイントの残高ページを見たら買った覚えもないのに10000ポイント近くあってビビった。履歴を見たら、一人で8000ポイントも投げ銭してくれてる人がいた。何という富豪投げ銭。残りも他の人による投げ銭。自分で買ったのって義援金送る時くらいで、その時も速攻全額寄付に回してたから、今あるポイントは全部貰い物ということになりますな。
対応してるページでは、はてなブックマークでブックマークする時に任意の額のポイントを送信できるので、ブックマークとしてクリップしておこうというつもりがない場合でも、書いた人への感謝とかそういうのを物として送る目的で、今後は僕も積極的に投げ銭していきたいなと思いました（あと寄付とか）。って、偉そうなこと言ってるけど元手は上記の通り貰い物なので自分は一銭も出してないわけですが。
ルーラーバーで折り返された行のカーソル位置を正しく表示できるようになったよ - Oct 11, 2008
ルーラバーだとやっぱり行ったことのある場所に行くあの呪文しか思い浮かばないという声があったので、日本語名をルーラーバーに変えた。
そのルーラーバーなんだけど、Rulerrrrrでもあった「折り返された次の行の先頭にカーソルがある時や行末にカーソルがある時にルーラー上の現在位置表示がおかしくなる（カーソル位置の計算に失敗する）問題」に真面目に取り組んで、0.2.2008101101でだいぶ改善した。
背景
ルーラーバーもRulerrrrrも、現在のカーソルの位置を計算するのには選択範囲を使っている。FirefoxやThunderbirdではカーソル位置をJavaScriptから直接取得することはできないんだけど、現在カーソルがある位置は長さ0の選択範囲として取得できるので、選択範囲が含まれているノードとか選択範囲の開始・終了位置などからどうにかこうにかして「カーソルより前に何文字あるか」を数えて、カーソル位置を割り出している。
行末にカーソルがある時
行末にカーソルがある時にカーソル位置が0（行頭）と判定されてしまっていたのは、この選択範囲から選択範囲が含まれているノードを取得できないせい。どういう事かというと、行末にカーソルがある状態というのは「テキストノード」「改行のBR要素」「テキストノード」という順番にノードが並んでいてBR要素の直前に長さ0のRangeがあるという状態で、「選択範囲が含まれているノード」は前後の要素やテキストノードではなくいきなりBODY要素になってしまう、ということでカーソル位置の求めようがなくなっていた。
そこで、TreeWalkerを使って各行のテキストノードやBR要素を走査し、compareBoundaryPoints()でそのノードがカーソルに隣接しているかどうかを調べる、という風な処理を入れてみた。これにより、行末にカーソルがある時でもカーソルより前にある文字を数えられるようになった。
折り返された行の行頭・行末判別
折り返された行の処理はもうちょっと厄介だった。普通に考えたら、「カーソル位置より前の文字数÷折り返し文字数 の余り」でカーソルの現在位置が分かるはずなんだけど、実際にはこれだけじゃダメだった。FirefoxやThunderbirdのエディタ機能では、折り返された行の行末にカーソルがある時に右キーを押すと、次の文字（折り返された次の行の先頭文字）の後の位置にカーソルが移動するのではなく、次の文字の前・仮想的な改行文字の後にカーソルが移動してしまう。折り返された後の行頭で左キーを押した時も同様。なので、いくら文字数ベースで計算しても、今「折り返された行の折り返し直前にカーソルがある」のか「折り返された後の行の先頭にカーソルがある」のかは分からない。
幸い、選択範囲の変更（＝カーソルの移動）を監視する時にはその選択範囲の変更が発生したユーザの操作の種類がある程度分かる。なので、マウス操作でのカーソル移動については、行の左の方でのクリックでカーソルが移動した時は行頭、そうでなければ行末と判定するようにした。また、キー操作でのカーソル移動については、「直前にいた位置が行頭・行の中程・行末のどれだったか」と「どのキーが押されたか」の組み合わせを元に、今カーソルがどの位置にあるかを推測するようにした。
英単語等があるせいで予定の文字数より前で折り返しが発生した時や、HTMLでプロポーショナルフォントが使用されている時、画像がある時などについてはもう完全にお手上げです。カーソルの位置をピクセル単位で取れるようなAPIが付いてくれないことには、もうどうにもなりません。
Thunderbirdにルーラーを表示する「ルーラーバー」を作ったよ - Oct 10, 2008
このサイトの方にまだ配布ページ作ってないのでとりあえずMozilla Add-onsに置いてみました。「ルーラ」と書くか「ルーラー」と書くか迷って「ルーラ」にしてしまいました。知ってる土地まで戻る魔法ではありません。→0.2で「ルーラーバー」に名前を変更したのでこのエントリの表記も「ルーラー」に統一しました。
見ての通り、Rulerrrrrのクローンです。公開終了しちゃってる上に特にオープンソースなライセンスが設定されていたわけでもないので、Rulerrrrrの改造ではなく一応フルスクラッチです。以下の点がちょっとだけRulerrrrrよりパワーアップしてます。
- 折り返されたテキストの2行目以降にカーソルがある時は、ルーラー上の強調箇所も折り返し後の位置になります（設定でRulerrrrrと同じ動作にもできます）。
- 改行箇所でテキストノードが分割されるせいでたまにルーラーの強調表示の位置がおかしくなる問題については対処済みです。
- 設定ダイアログから目盛りの表示間隔とかをカスタマイズできます。フォントによってルーラーと文字がずれる場合は、適当に拡大率を調整してください。
空行から左キーを押して一つ前の行の末尾に移動する時に、ルーラー上の強調表示がちゃんと追従してくれないとか、右キーを押して行末→行頭に移動しても強調表示は行末側に残ってしまうとか、Rulerrrrrでも見られた問題がこいつにもあります。そのうちなんとかしたいですね。→0.2.2008101101で改善しました
ていうか誰かすでにクローンを作ってるんじゃないかと思ったら案外誰もやってなかったみたいで驚いた。
メソッド名は三人称単数形にするべきかどうか - Oct 08, 2008
例えばW3C DOMでは、子ノードがあるかどうかを調べるメソッドの名前はhasChildNodes()（三人称単数形）だけど、子ノードを追加するメソッドはappendChild()（不定形、原形）となっている。どうしてこのようにバラバラなのか？ どっちかに統一しないのか？ という話。
Matz氏はRubyのメソッド名から三人称単数形を廃して原形に統一したいらしい。上に挙げたような例なら、hasChildNodesではなくhaveChildNodesという感じ。
日本語で書かれた命名規則の文書としては、ググってみたらOkapi Projectの命名規約というのが引っかかった。ここではブール値を返すメソッドは三人称単数形で始めるようにとされている。でも、「何故そう決めたのか」は書かれていない。
そもそも英語圏の人はどう考えてるんだ？ と思って「naming convention verb method」とかでググってみたところ出てきたセントラルワシントン大学のドメインで公開されているJavaの命名規則のページには、こう書かれてた。
Begin method names with a strong action verb (for example, deposit).
(snip)
If the method returns a boolean value, use is or has as the prefix for the method name.
何の説明もなく、ブール値を返す物は三人称単数形で、そうでない一般的なメソッドは原形で例が挙げられている。何故そうなのか、ということが全く述べられていない。ネイティブスピーカーの人にとってこれらの使い分けはあまりに自明すぎて、敢えて説明する必要が感じられないということなのだろうか。
僕の場合は、自分でメソッド名を考える時も、Okapi Projectの規約とだいたい同じようなルールで考えてる。そしてこのルールは上記のセントラルワシントン大学のルールとも同じだ。深く理由を考えたことはなかったけど、どうしてこれで違和感が無かったのか、改めて考えてみた。
なんとなくだけど、何かをする系のメソッドを使った文、例えばparentNode.appendChild(newChild)だったら、これに対応する英文というのは Hey, you "parentNode"! Append "newChild" to yourself as a child! みたいな「命令文」で、状態を尋ねる系のメソッドを使った文、例えばsomeNode.hasChildNodes()だったら、対応する英文は He "someNode" has some child nodes. みたいな「普通の文」なんじゃないのかなー、と思ってる。逆に言うと、これらの英文を思い浮かべてコードを書くと、自然に、普通のメソッドは原形で状態を尋ねる系のメソッドは三人称単数形になるんじゃないのか、と。He "someNode" have some child nodes. とは書かないし。
そう考えると、Matz氏は「対応する英文」をイメージしないで単純に単語レベルでメソッド名を認識していて「原形と三人称単数形が混在してるのは統一感がない。メソッド名から三人称単数形を廃して原形に統一したい。」という風に考えてるんじゃないかなー、と、僕には思える。その発想が、ネイティブスピーカー的ではないんじゃないかなー、と。
僕は、メソッド名とかで英語を使うんだったらそれを母語としている人達の発想に一番しっくりくる命名規則を使うのが筋なんじゃないかと思う。ネイティブスピーカーがこれでイイって言ってんのに母語にもしてない日本人が「こうあるべきだ」と言っても説得力がない、と思ってる。日本人的・日本語的発想にこだわるんであればそれこそなでしこみたいに日本語ベースの言語にするのが筋なんじゃないの、と。
まあ、ここで参照した命名規則はJavaのものだから、上記の発想はあくまで「Java使いの英語ネイティブスピーカーの発想」とまでしか言えなくて、「大多数の英語ネイティブスピーカーの発想」がそうであるかどうかってのは分からないんだけども。