Unofficial Planet WordPress Japan

Mac で XUL を動かす場合、Linux なんかとはやり方が違ってくるみたい。
Linux の場合は、xulrunner コマンドの引数として XUL アプリケーションの application.ini ファイルを指定するだけでよかったんだけど。
Mac の場合は、xulrunner-bin というコマンドでまず XUL アプリケーションをインストールして、そうしてできた .app ファイルを起動するという手順を踏まないといけないっぽい。

例えば XUL アプリを「my_xul_app」というディレクトリに作っていた場合、以下のようにしてインストールする。

/Library/Frameworks/XUL.framework/xulrunner-bin --install-app ./my_xul_app

そうすると、「/Applications/(Vendor)/(Name)」の位置にインストールされる。
「Vendor」とか「Name」っていうのは、「my_xul_app」ディレクトリ以下にある application.ini というファイルに書いてある情報。

インストールが上手くいくと、例えば「/Applications/jugyo/my_xul_app.app」というファイルが作成されて、こいつをダブルクリックすれば起動できる。
また、作成した XUL アプリケーションにコマンドラインオプションを渡したい場合は、ターミナルで以下のようにしてプログラムを実行すすればよい。

/Applications/jugyo/my_xul_app.app/Contents/MacOS/xulrunner [OPTION]

なんか面倒くさいな。

追記:
XUL アプリケーションのファイルもろもろは「/Applications/jugyo/my_xul_app.app/Resources/」以下に置かれるから、それを直接いじればよさそうだ。

「それ」を理解するというのは、「それ」と「それ」以外のものとの差異を認識できてるようになって初めて可能になるんじゃないかな。
一種類のプログラミング言語しか知らない人はその言語を本当に理解しているとは言い難いと思うのです。
例えば、PHP はどこがダメなのかということを理解するためには PHP 以外の言語を知る必要がある。
そうすることで逆に PHP の良いところが今まで以上に見えてくるかもしれない。

なんてね。

みんなのPython 柴田 淳 ソフトバンククリエイティブ 2006-08-22 売り上げランキング : 9407 Amazonで詳しく見る by G-Tools

この本はわかりやすくて良いですよ。
これから Python を初めてみようって人にはものすごくおすすめです。

オブジェクト指向の機能は Ruby なんかと比べると若干貧弱というか、よく言えばシンプルなのかな。
Python って Ruby みたくクロージャ書けないですよね。
そこんところがちょっと惜しい気がする。
ま、それぞれの言語にも一長一短があるわけで一概に（略）

プログラムの構造をインデントで表すっていうのはすごいアイデアだといつ見ても思う。
それのおかげでプログラムの編集が非常にやりやすい。

python のコードを書くのはなかなか楽しい。
仕事で python のプログラムを書かないといけなくなったとしたら喜んでやるな。

…

復習もかねて後で読み直そう。

大事なのって、反射神経だと思います。
ブログでもプログラミングでも。
「僕はこう思う」とか「こういうのあったら面白いんじゃないか」とか「これできるかな」とか思った瞬間にもう書き始めてる。
みたいなね。

瞬発力？

LL Future というプログラミング言語関係のイベントに行ってきましたよ。
http://ll.jus.or.jp/2008/
チケットは1000個以上売れたらしいです。
会場に来たのは800人くらいだったそうですが。
こういうイベントに1000人近くの人が集まるっていうのはすごいですね。

基調講演は Perl の作者であるラリー・ウォールさんのお話。
英語でほとんど内容わからず。
推測するに、Perl の次のバージョンである Perl6 では、表面的な部分の変更は少なめにするけど裏でユーザーが弄って言語自体をいろいろカスタマイズできるよー、みたいな事を言っていたと思います。
ていうかそもそも Perl って変な言語なんですよね。
インタープリターがスクリプトを解釈するタイミングに独自の処理を挟み込めたりするようです。
で、Perl6 ではこの機能がさらに拡張されるということなのかな（自信ない）。
どんどん変態的な言語になっていくような気がします（あんま詳しく知らないのでアレですが）。

このイベントには Ruby の作者であるまつもろゆきひろさんも来ていて、パネルディスカッションの時に、「いろいろ作り替えられすぎちゃう言語はどうかと思う」みたいなことを言ってて、これは Perl とは逆の考え方だなぁと思いました。
コードに一貫性がなくなり読みにくくなったりすることを危惧してのことだと思います。
僕もこの意見には賛成です。
ていうか僕自身が「良いデザインのものを思う存分使い倒したい」と考えるたちで、言語自体を自分でカリカリにカスタマイズしたいとか、またはカリカリにカスタマイズされたものを使いたいとかあまり思わない人間なんですね。
初期状態でそこそこ気分良く使えるのがいいんです。

デザインってその辺が非常に重要だと思っていて、例えばユーザーの利便性を考えすぎて自由度が高くなりすぎるのも良くなかったりするんですね。
初期状態で、どのくらいのレベルまでユーザーをアフォードしてくれるのか、みたいなことが重要なんじゃないかと（アフォードの使い方会ってる？）。
でも全くカスタマイズできないのもつまらないですよねぇ。
だからバランスが重要というか。
カスタマイズの仕方にもなんかしらのスマートさというかクールさが求められるようなのがいいかもしれません（どんなんやろ）。

ちょっと話が抽象的になりすぎました。
いやー、デザインって奥が深いですね。

以上、デザインにまつわる考察でした。