たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
以前Ubuntu 8.10に導入したNautilusSVNなんだけど、一つ困った事がある。それは、コミット時のメッセージを日本語で入力するとコミットできないという点。
普通のオープンソースのプロジェクトだったら英語でやるのが当たり前だろ!!!日本語のメッセージとか死ね!!!と言う人もいるだろうけど、そんなの知るかよと。TortoiseSVNじゃ普通にできてるんだから、できない方がおかしいだろと。とかぼやきつつも仕方ないからNautilusSVNからcommitする時だけは英語でコメント付けるようにしてたけど、英語苦手だからついつい二言三言の適当なメッセージだけでcommitして、後になってログ一覧見た時に何の変更だったのか訳が分からなくなる、ということがあまりに多いのでいいかげん我慢の限界がきた。
そもそもの所で勘違いしてたんだけど、日本語が通らないのはSubversion自体の問題ではなくてNautilusSVNの問題だということについ先日やっと気がついた。ターミナルでsvn commit -m "日本語のメッセージ"てな感じで書いたらちゃんとコミットできたし。あと閉じ括弧を入力するまでは改行とかもメッセージに普通に入れられるということにも気がついた。なのでしばらくの間、コミットだけコマンドライン操作でやるようにしてみたんだけど、やっぱりめんどくさい。
この手の問題はMozillaでもよくあって、Mozillaの場合は文字列のエンコーディングを変えてやるだけで解決する場合が多いので、NautilusSVNでもきっとそうなんじゃないだろうか。と見当を付けて、思い切ってソースコードを覗いてみた。~/.nautilus/python-extensions/NautilusSvn/SvnCommit.py の中のそれらしい箇所に、ぐぐって調べた文字エンコーディング変換のコードを一行加えて、試しにコミットしてみたら無事に日本語が通るようになった。
Index: SvnCommit.py
===================================================================
--- SvnCommit.py (リビジョン 776)
+++ SvnCommit.py (作業コピー)
@@ -102,6 +102,7 @@
ctrl = XRCCTRL( self.frame, "Message" )
self.commitMessage = ctrl.GetValue()
+ self.commitMessage = self.commitMessage.encode("UTF-8")
# If the user doesn't supply a commit message we will just use the string
# "Empty message" since pysvn doesn't accept an empty string see:
# pysvn._pysvn_2_5.ClientError: callback_get_log_message required
変更箇所はほんとにこれだけ。
僕はバージョン管理システムのSubversionのクライアントとして、WindowsではTortoiseSVNを使っている。TortoiseSVNはシェル統合型のクライアントで、エクスプローラのファイルアイコンがファイルの状態(競合とか最新とか変更ありとか)に応じて変化したり、フォルダの右クリックからチェックアウトや更新や差分の表示やログの閲覧ができたりと、独自ファイラを使わない僕にとっては実に使い勝手が良い。
TortoiseSVNはWindows専用なので、UbuntuではRapidSVNを使ってたんだけど、Ubuntu 8.04LTSで使うとどーいうわけかコミットしようとすると必ず落ちる(しかもその時作業対象のフォルダをロックしたままで死にやがる)という問題が起こっていて、チェックアウトしかできなくて困ってた。コマンドラインからsvnコマンドを使えばコミットすることはできるといえばできるんだけど、根っからのGUI人間なので、いつもそうするというのは苦痛で苦痛で……
そんな時に、Nautilus向けのシェル拡張としてNautilusSvnというTortoiseSVNクローンが存在するということを教えてもらったので、是非入れよう! すぐ入れよう! 幸いページの一番下に.debなパッケージもあることだし! と思ってダブルクリックしてみたらパッケージマネージャに蹴られて撃沈して僕涙目。Python関係のパッケージの依存関係が壊れてるだかなんだかでインストールすらできなかった。
それ以来すっかり諦めてたんだけど、先日Ubuntu 8.10にアップグレードしたので今度はうまくいくんじゃないか? と思って再挑戦してみた。.debをダブルクリックしてパッケージマネージャから入れてみると、今度はインストールには成功したんだけど、再起動してもちっともそれっぽい変化が現れない。
Google検索したらUbuntuのフォーラムのトピックでGoogleコード上のプロジェクトページが紹介されていたので、これがダメだったらもう諦めよう、という気持ちでそこのWikiに書いてあったインストール手順に従って操作してみた。そしたらうまくいった。やった!!!
以下、すべてコマンドライン操作。
で、ログアウトしてログインし直した後にNautilusで適当なフォルダを開いて右クリックすると、メニューの中に「SVN Checkout」という項目が増えてた。Subversion管理下のフォルダだとフォルダやファイルのアイコンの上に状態を示す小さなアイコンが表示されるようになってて、管理下のフォルダで右クリックすればログや差分も見られる。
.debでやった時にうまくいかなかった理由については結局分からずじまいなんだけど、最初に入れる必要なパッケージの中の一つがWikiには「python-wxgtk2.6」と書かれていたのに対して、.debではpython-wxgtk2.8が入っていたので、もしかしたらこのバージョンの違いが原因だったんだろうか?
あと、この件について調べてる中でnautilus-script-collection-svnというパッケージがあることも分かった。こちらはSubversion用のシェルスクリプトをNautilusの汎用的なユーザスクリプト呼び出し機能を使って起動して使うというもののようで、パッケージをインストールした後に sudo ln -s /usr/share/nautilus-scripts/Subversion ~/.gnome2/nautilus-scripts/Subversionとしてシンボリックリンクを作成すると、次回起動時以降、Nautilusのフォルダ内での右クリックメニューの「スクリプト」サブメニューからそれぞれのシェルスクリプトを呼び出せるようになる。こちらはコミット前の「やっぱりやめとこう」みたいな取り消しができないっぽかったりSubversion管理下のファイルやフォルダの状態が特に表示されなかったりという問題があるので、NautilusSvnが使える環境だったらNautilusSvnを使った方が良さそうだ。どうしてもNautilusSvnが動かないという時のために一応メモしておく。
余談。NautilusSvnでもTortoiseSVNでも微妙に不便な点として、まあこれは仕様上当たり前なのかもしれんけど、ある場所にチェックアウトしたSubversion管理下のフォルダに対するシンボリックリンク(Windowsだったらジャンクション?)からはコミットできないという問題がある。Windowsの場合はフォルダのショートカットがあるから別にいいんだけど、Linux(GNOME)だとGUIからは簡単には「フォルダのショートカット」を作れない(アプリケーションのランチャを作って、コマンドに「nautilus "パス"」と書けば、擬似的にフォルダのショートカットを作ることはできる)ようなので、そこだけ地味に困ってる。
2009年2月9日追記。日本語のメッセージを付けてコミットできない問題に対処してみた。
熱く色々書いてみたけど、書いたら書いたで落ち着いてきてまたネガティブな見方が増してきた。
複数の動詞を繋げて……と書いたのはやっぱり僕の考えすぎ・妄想しすぎだったっぽい。がんがんコミットしてそういう方向にこれから持って行く、っていうことは可能かもしれないけど、Aza氏の想定はそういうことじゃなかったって事のような気がしてきた。やっぱりもっと単純な考えだったのか? と。
アイコンより言葉の方が分かりやすいんじゃね?という発想。アイコンをたくさん並べていちいち見比べるよりも、言葉を直接入れちゃえばよくね?という発想。その前提にあるのは「沢山の言葉が頭の中に入っていて、瞬時に適切な物が思い浮かぶ」っていうことだ。「頭の中に入って無い」のも「瞬時に思い浮かばない」のも、Ubiquityを使うためには致命的な問題となる。(だから、前のエントリの最後でもセカンドサーチ的な「動詞の提案」という案を書いたんだけど。)
そう考えると、そういう発想が出てくるのはAza氏が天才だからじゃないのか? 天才が考えたツールは凡人には使えないんじゃないのか? という疑念がムクムクと膨らんできてしまう。
タイトルが釣りっぽくて誤解されそうだけど、僕だって自分のことは凡人と思ってる。前のエントリに書いたような物が実現されたとしても、自分が使える「動詞」は10個にも満たないだろう、下手したら5個とかそのくらいだ。それ以上はとてもじゃないけど憶えられたもんじゃないだろうと思ってる。いざ使おうとしても「あー、あれ何だったっけなあ、えーと、うーんと、もうここまで(ノドのあたりを指しながら)出てきてるんだけどなああああ」とウンウン唸ってるんじゃないかって気がする。
勝手に妄想補完して勝手に舞い上がって、そしてこうして勝手にまた落ち込んでる自分が恥ずかしいなあ。
という風に考えていた所でplus7さんのコメントに気がついて、plus7さんが紹介してくださったForthというのを見てみた。おおお……これってあの日本語プログラミング言語の「Mind」の元になった物だったのか。こんな物があったとは知らなかった。そうか、「逆ポーランド記法」って、こうして見てみると確かに日本語の文法に似てるんだなあ。
上述した「根本的な問題」=天才にしか使えないのかもしれない、という点はさておいて、現状のUbiquityが英語的・関数言語的な語順を前提にしているのに対し、日本語に対応するのは逆ポーランド記法的な解釈にも対応するっていう事になるのか、と考えると、プログラムの作り事態に関わる話になってきそうで興味深いと思った。
そういえば、英語式語順は自然な思考の順番に反する(英語ネイティブの人間でも、身振り手振りで説明させると順番が「主語」「目的語」「述語(動詞)」になる)という話もあったなあ。これも何か関係してるような気がしてきた。
UxU(UnitTest.XUL)を利用したFirefoxアドオンのデバッグの例 - ククログ(2008-11-17)
XUL/Migemo 0.11.7での修正内容が典型的な「自動テストを使ったデバッグ」だったので、UxUのチュートリアルを兼ねて、会社のサイトの方に書いてみました。UxUの解説って言うよりは、テスト駆動開発自体の解説という気もしますが。
リンク先に解説してるのはpXMigemoFindのfindFirstVisibleNodeメソッドだけのデバッグ話ですが、実際にはこのメソッドはだいぶ根幹に関わる物で、このメソッドの挙動の変更によって他の機能に色々と影響が出る可能性がありました。が、他の挙動に関しては一通り自動テストを作成済みだったために、後退バグの発生で収拾不能な事態に陥るということを恐れずに安心して修正に取り組むことができた、というまさに自動テスト様々な事例だったということも忘れずに付け加えておきたい所です。
XUL/Migemoの動作で怪しい所を見つける→再現条件確定→その条件下でのテストを行うためのUxUのテストケースを作成→何かちゃんと動かない→UxUのバグ発見→抜本的修正開始→途中で疲れて寝る→抜本的修正続き→やっとチェックイン→XUL/Migemoのテストを書く気力がなくなってる→それでもめげずにテスト書き再開→UxUの別の問題発覚→心が折れかける(今ここ)
例えば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使いの英語ネイティブスピーカーの発想」とまでしか言えなくて、「大多数の英語ネイティブスピーカーの発想」がそうであるかどうかってのは分からないんだけども。
なんか気がついたらDan Kogai氏が書評書かれてた。内容には触れてないけど。このエントリからのトラフィックでAmazon.co.jpのランキングが結構上がったらしいです。すごいね。
内容の中で僕がピンと来る物は、以下のような感じです。
他はまだちゃんと見てない(ひどい)。
関連イベントのお知らせ。
FirefoxNITE:Ustream使ってダラダラやってたアレの新装開店リニューアルオープンついでのスペシャル開催みたいです。8月27日20:00から渋谷bartubeにて開催、参加費3800円。参加登録が必要なので宴会君からどうぞ。
Firefox 3 Hacks NITE:本書発売記念のトークセッション、だそうです。bartubeのソレとは全然無関係に、9月4日19:00から池袋ジュンク堂にて開催。参加費1000円ワンドリンク制(多分)で定員40名、電話か店頭で申し込む必要があるとの事です。
誰も来なくて関係者だけで反省会、というのは怖いので、物申したい方の多くのご参加と喧々囂々丁々発止のリアルモヒカンバトルに期待しております。
状況がよく分からなかったので改めて調べてみたことのまとめ。
Firefoxその他のMozilla製品のソースコードはこれまではCVSでバージョン管理されていて、MXR(Mozilla Cross-Reference)というサービスを使うと最新の内容をオンラインで検索できた。mozilla1.8(リンク先はMXR)を見ると、Firefox 2.0.0.xやThunderbird 2.0.0.xのコードを検索できる。
しかしCVSが使いにくいということで、Mercurialという別のバージョン管理システムに移行しようという話がずっと進んでいたそうで、Firefox 4を目指しているTrunkのリポジトリがmozilla-central(リンク先はMercurialのWebインターフェース)という名前でMercurial上に作成され、すでに自動ビルドも動いているという。
ちなみにMercurialがらみでよく「Hg」という単語が出てくるけれども、これは、水銀(mercury)の元素記号がHgだからだそうで、コマンドラインツールのコマンド名等も「hg」になってるんだそうな。知らんかった。
自分が把握できていなかったのは、以下の点。
結論としては、以下のことが分かった。
以下、まだ分かってないこと。
ある人は、ドキュメントは悪だと言う。毎日のように何かしら変更が加わっていくソースコードの、ある一時点に対してだけの説明を書き記した物であるドキュメントは、あっという間に陳腐化する。Google等で検索すると、すでに陳腐化したドキュメントが山のように引っかかって、正しい情報になかなか辿り着けない。書く者には多大な労力を強いて、利用する者にも無駄な労力を強いる、だからドキュメントは悪なのだという。
僕は、ドキュメントは善だと思っている。ソースコードの読み方が分からない、ハチワンダイバー(将棋のマンガ。一歩退いた所から眺めてるだけでは勝てない、9×9=81マスの将棋盤の中に潜り込むくらいに集中して臨め、ということでそういうタイトルになっている)のように「ソースコードの羅列の中に潜れない」人にとっては、ドキュメントは自分に分かる言葉で書かれた唯一の資料になるから。陳腐化したドキュメントであっても、とっかかりくらいにはなる。無いよりはあった方がいい、というのが僕の考え。
というか「分かる人」(上記の話で言えば、ソースコードの中に潜れる人)の場合はソースを見ればだいたい問題は解決するので、ドキュメントがあろうと無かろうと関係ないんじゃないだろうか? 「分からない人」のために書かれた「ドキュメント」に対して、「分かる人」が「自分には邪魔だ」と言うのはいいんだけど、「万人のために悪だ」と言うのは、言い過ぎだと僕には思える。
プログラミングに限らず、絵でもなんでも。
はてブについたコメントを見て追記。
コードでhowやwhatは書けてもwhyは表現できません!
は、なるほどなと思った。だからそれをコメントとしてソースコードに埋め込む必要があるのだなとも。
とっかかりが明後日の方向に向かってるドキュメントに対応してるオレはどうすれば...
というのは「悪いドキュメント」に当たってしまったという事であるけれども、「自分が当たったドキュメントが悪だった」「今まで当たってきたドキュメントが悪だった」からといって「全てのドキュメントは悪だ」と言うのは言い過ぎだ、と自分はやはり思う。
すっかり時機を逸してしまった感がありますが、Firefox拡張機能開発チュートリアルのPDFを公開しましたことをここに告知いたします。このサイトかもじら組のFTPサーバからダウンロードできます。Creative Commonsなので一定の条件下で自由に転載、改変、再配布可能です(誰かMDCに転載してHTML版作ってくれないかなあ……と、誰ともなしに無茶振りしておきます)。
内容は、Software Design誌2007年4月号第2特集「Firefox拡張機能開発チュートリアル」として掲載された記事をFirefox Developers Conference Summer 2007でテキストとして頒布するために再録したもの(この度の公開にあたって既知の間違いは修正してあります)で、XULやXPCOMの紹介から、実際のアドオンの作り方、オープンソースなライセンスの紹介まで一通り扱っています。Firefox 2を前提に書かれていますが、Firefox 3やThunderbirdでも基本的にはそのまま利用できます。
8月発売予定のオライリーのFirefox 3 Hacksに書いた内容は、アドオン作るの初めてという人は完全置いてけぼりなので、まずはこちらで予習される事をお勧めします。
なお、このFirefox拡張機能開発チュートリアルでチュートリアルの章を執筆されているGomitaさんが、技術評論社WebサイトにてFirefox 3でのアドオン開発記事を連載されています。御託はいいからとりあえず作らせれ! Firefox 3の機能もソッコー使いたいんだ! という場合はこっちからご覧になるのがよいかもしれません。
クレジットには名前が挙がっていませんが、PDFにしてもらう際にほとんどの作業をご担当いただいたNさん、訂正箇所の反映作業を行っていただいたMozilla Japan吉野さんに感謝です。
やっと一般公開、長かった…
(mal_blue@tumblr)ごめんなさいほんとごめんなさい。実は、2007年のDevConでテキストとして再編集して配りたいという話になった時点で、Creative Commonsにして公開したいという話も同時に出ていたと記憶しているのですが、イベント直前での判断だったのでCCにする場合のメリット・デメリットをきちんと検討できる余裕がなく、イベント終わってからに先送りされて、それっきり忘れ去られてた時間がずっとあって、今年4月のOSC長岡の頃にDevConで刷った冊子がなくなりそうだから誤字を直して増刷しようとなった時にやっとその話がまた動き出して、誤字訂正のついでにライセンスの検討と関係者各位にライセンス変更の確認(CC-BY-SA+MITライセンス)を行って、その時増刷された物の時点でもうこのライセンスになってたから実はスキャンするなり手打ちするなりして再配布されても全然OKな状態だったし、PDFもできあがってたんですが、何故かズルズルと公開が遅れてしまっていました。まあ、先日のFirefox 3 Hacks校正会の時についでに僕の担当箇所のミスを2カ所修正してもらった(nsIConverterInputStreamとnsIConverterOutputStreamを使う所でバッファサイズを決め打ちにしてしまっていたせいで、サンプルをそのまま使うと読み込む内容や書き出す内容が1024バイトでちょん切られる問題があった)ので、公開が遅くなったのが全く無意味だったというわけでもないと言いたいところなんですが。