パターンマッチ駆動....
2007.10.31
さて、ちょっと勉強している Haskell の話題から。
この Haskell という言語は、要するに「モダンな Lisp」みたいな言語です。勿論、Lisp 以降の関数型言語研究を踏まえて、
- 1. 副作用のない純粋な関数型言語
- 2. ということは、「副作用」自体を関数型言語パラダイムに適応させた「モナド」という概念がある。
- 3. 遅延実行をサポートし、本当に必要になるまで式が評価されない。
- 4. 「型クラス」の概念があって、変数型を自動で導出したりする。その上、「型クラス」はちょいとオブジェクト指向っぽく継承モデルを持っている。
...という具合に、いろいろと Lisp+ な機能がありますが、Lisp に特徴的な「データとプログラムの区別がない」というのはなしです。ですから、見た目上プログラムが prolog に近い格好になってたりします。たとえば階乗を求めるのだと、
Haskell
fac 0 = 1
fac n | n > 0 = n * fac (n-1)
Prolog
fact(0, 1).
fact(N, F) :-
N >0,
N1 is N-1,
fact(N1, F1),
F is N*F1.
という感じで似ているわけです。で、さらに、Haskell も Prolog も、いわゆる「リストのパターンマッチ」をします。たとえば、リストの長さを求める例だと、
Haskell
length [] = 0;
length (x:xs) = 1 + length xs
Prolog
length([], 0).
length([X|Y],Z) :- length(Y,W), Z is W + 1.
という感じで、(x:xs) も [X|Y] も、対象となるリストの「一番先頭の要素」:「それ以降の要素」を、パターンマッチで式の上で分解して指定する、という格好になります(で、それをさらに再適用してループを作ります)。
勿論 Prolog は関数型言語ではなく論理型言語ですから、バックトラックのような推論を持っていますけども、ここらへんの動作のキモは「パターンマッチによる再帰」ということなのです。
....で考えてみると、この「パターンマッチによる再帰」というのは、実はこういった超洗練言語たちに限ったことではなくて、たとえば XSLT でもあったりするわけです(ですから、最初 XSLT を勉強したとき、「何か Prolog に似てる~~」というのが私の感想)。こういうかっこいい書き方ではなくて、 XML で書くに過ぎませんが、やはり
<xsl:template match="item">
<xsl:value-of select="@value"/>
<xsl:apply-templates select="item"/>
</xsl:template>
のように、再帰的に自身を呼び出してパターンマッチを継続していくわけです....というように、「パターンマッチ駆動」というアイデアはかなり汎用的なものではないのでしょうか。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.31 17:17
JavaScript って一体何なの?
2007.10.29
前回のクロージャの話の続きです。
「JavaScript とは何か」ということについて、JSON のRFC(RFC4627)を書いた、Douglas Crockford が次のようなテキストを書いています。
これによると、
Cの皮を被ったLisp
JavaScriptには、Cのような中括弧や不格好なforステートメントがあるため、一般的な手続き型言語のように見えますが、それは誤りです。JavaScriptはCやJavaよりも、LispやSchemeのような関数型言語と多くの共通点を持っているのです。JavaScriptには、リストの代わりに配列があり、プロパティリストの代わりにオブジェクトがあります。関数はファーストクラスであり、クロージャも備えています。つまり括弧の対応をとる手間なしに、ラムダ(引用注:Lispで「関数」を生成する関数)を利用できるのです。
と、Lisp 風の言語である、と言っているわけです....そう意識しているプログラマはどのくらいいるのでしょうか。確かに JavaScript の関数は、「ファーストクラス」です。言語構成要素が「ファーストクラス」であるためには、
- 1. 名前を付けられる。たとえば、var f = function(n) { ..... }と無名で生成した関数に名前をつけて、それを見かけ上普通に生成した関数と同様に呼び出せるのですから、これはOKです。Javaだと関数はクラスから独立した言語構成要素ではないので、無名クラスは作れても無名関数は作れません。
- 2. 関数の引数に渡せる。たとえば、Lisp系言語によくある map(f,list) といった、第1引数の関数を第2引数のリスト(などの集合データ)の各要素に適用して、適用結果を集合データとして返す、という関数を書くことがちゃんとできます。これもOKです。勿論、この map() の第一引数に、無名関数をその場で作って渡す...というのも問題ありません。
- 3. 関数の戻り値にできる。関数を戻り値にする関数は簡単に書けます。これもOKです。
- 4. データの構成要素になれる。関数の配列なんて簡単に作れます。これもOKです。
....そうしてみると、逆に Java よりもひょっとして強力?とも思える良く出来た言語のわけです。ここらへんに改めて注目したのが例の Ajax の流行の中で、prototype.js などここらへんの機能を使い倒して書いているわけですよね.....
そういう JavaScript の強力な表現力を活用すると、たとえばこんなページがあったりします。
檜山正幸氏 プログラマのための「ゲーデルの不完全性定理」
...JavaScript は実は結構とんでもない言語だったりするわけです。
ちなみに、Crockford は「JavaScript の本」も「ひどい書籍」ばっかり....と評しています。確かに言語としての JavaScript をしっかり解説している本は稀で、その稀なO'Reilly の「JavaScript」は Crockford が賞賛するように、良い本です!
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.29 13:50
クロージャの活用
2007.10.27
今仕事で書いているプログラムで、ユーザ定義の入力フィールドである「自由項目」というのを実装するのをしています。で....なんですが、「クロージャ」の威力を改めて実感したので、今回はそういうネタです。
この「クロージャ」というのは、Java とか C とかコンパイル言語にはほとんどない概念(似たようなことを強引にすることは不可能じゃないですが...)ですけども、ぐっと身近なところで JavaScript にはしっかりあります。JavaScript では new Function() で無名関数オブジェクトを作れますが、その時に「ローカルな実行環境」を一緒に渡してやることができる、という機能です。
たとえば、JavaScript で
function newCounter() {
var i = 0;
return function() { // 無名関数を返す
i = i + 1;
return i;
}
}
var i = 99;
c1 = newCounter();
alert(c1()); // 1
alert(c1()); // 2
alert(c1()); // 3
alert(c1()); // 4
alert(c1()); // 5
alert(i); // 99。グローバルな i の参照
というのがクロージャの例です。この時、変数 i は自身を定義した new Counter() 内のローカル変数のはず...ですが、実行時には「この i, どこにあるの?」という疑問が湧くのでは...と思います。これが実は「クロージャ」です。言い換えると、この「無名関数+その中で使われる変数のセット」のことです。これを1つのオブジェクトとして変数 c1 は保持し、c1() のかたちで実行した時に、そのクロージャとして実行しますから、たとえ他にグローバルな変数 i が存在したところで、その影響はまったく受けません。
つまり、「変数とそれを扱う関数をセットにして、動的に構築して実行させる」という小規模な無名クラスみたいな使い方が出来てしまうわけです。しかも、これ、実際に呼び出した時に始めて実行される....という「遅延実行」になりますから、実際に「c1 を呼び出したコンテキスト」に基づく処理をさせることも出来てしまいます。
ですから、Servlet 側の処理で、処理内容に応じたクロージャを構築して、それを動的実行させる...ということをカンタンにやってのけることができてしまいます。このクロージャの機能は、もともと Scheme にあった機能でしたけど、そういう関数型プログラミングっぽい機能が身近にある...というのが何かうれしいです(苦笑)。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.27 15:18
MACがアップル社と関係がなく、car が車でない世界
2007.10.24
というのは、実は Lisp の話です。
私が学生時代に初めてプログラミングをし出した時期(1980年代中頃)、一番ハマった言語は Lisp でした。当時の大型計算機センターに、今は見ないようなかなりヘンな Lisp インタプリタ(「de」で関数定義し、「]」がスーパーカッコの扱いで、トップレベルに戻る)が載っていて、それを使っていろいろ遊んでいたのですが、それ以来 Lisp 系言語というのは大好きだったりします。
とすれば勿論、car は Lisp の car で、「リストの先頭要素を取る」組み込み関数(というか、Lispで一番基本的な汎用構築部品の一つ)に決まってます。ですから、例えば同じようなリスト処理をするケースで、ついつい car, cdr, cons という名前で関数(とかメソッド)を作ったりしちゃうわけです....car は車じゃないです。
じゃあ、MAC がアップル社と関係がない...というのは、これこういう事情です。
最近 Wikipedia ってスゴク充実してきたように思いませんか? で、コンピュータの歴史&雑学関連の解説がやはり Wikipedia でかなり突っ込んで書かれていて、感心することがよくあるわけですけども、そんな中で今まで名前は聞くけども、どういうものだったかもう一つハッキリ知らなかったものとして、MIT で 1960年代にあった「Project MAC」というプロジェクトのページが Wikipedia にしっかり載っているわけです。この MAC は UNIX が出来るきっかけになった Multics の開発をやっていたプロジェクトですし、Lisp の有名なバージョンに、このプロジェクトで開発された MACLisp というものがあったりします。さらに、このプロジェクトの副産物である仮想メモリを解説した「物の王様」という楽しい読み物があったりします。
というわけで、今回の記事は笑い話みたいなものです。ちょっとレトロ話題が最近多いですね。Haskell とか勉強しようかな(「カリーもあるでよ」だし...)。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.24 21:15
日立がパソコンから撤退だって
2007.10.23
今日帰ってみると、新聞に出てました。
考えてみると、日本のパソコンの元祖のメーカーだったりするわけです。そういう意味では、「日本のパソコン製造ビジネス」というものの難しさ...みたいなものも一身に抱えていたメーカーみたいな気もします。
互換機路線になってからは、日本の大手ベンダーとしては珍しく、かなり初期から Linux 搭載モデルとか、BeOS 搭載モデルといった楽しい製品を出していてくれましたね。そういうちょっとした「面白み」のあるコンピュータメーカー、という目で私なんかは見てました。
まあ、勿論日立自体は、汎用機のメーカーでもありましたし、もう少し面白い話だと、Z80セカンドソースCPUが最近生産がなくなっているのに取って代わって使われるようになっている8ビットの「H8」というCPUが(今は三菱電機との合弁のルネサステクノロジーですが...)日立製品だったりするわけです。
そういうわけで、何か妙な親近感があったメーカーだったりします。個人的にはあまり日立の家電製品にはそういうのを感じないのが不思議でありますが。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.23 21:15
21963283741はPDP-10で...
2007.10.22
美谷広海さんの記事「DEC社のPDP-10がカッコよすぎる。 」へのトラックバックみたいな感じで書きましょう。
21963283741はPDP-10で整数と浮動小数点数の両方で表現した場合に、両者のビットパターンが同一になる唯一の数値である。(HAKMEM#174 Gosper&Nelson)
このPDP-10というマシンは、MITのAIラボ文化で中心的な役割を果たした、非常に重要なマシンだったりするわけです。たとえば、このPDP-10についての、「ハッカーズ大辞典(JargonFile)」での説明は、
タイムシェアリングを実現したマシン。.....一部の命令セットは、いまだにその右に出るものがないと考えられている。...この出来事(引用注:PDP-11の後継マシンであるVAXへの一元化を目的とするPDP-10の生産中止)は、オリジナルのJargon File を生んだ技術文化と ITS の終焉を告げるものだったが、1991年の中頃の時点では、PDP-10 で産湯につかったということが、すでにハッカーの間で名誉あるベテランの勲章となっている。
....憧れましたねぇ、この PDP-10 と ITS 文化。ここらへんを理解するにはやはり、JargonFile(Guy L. Steel と Eric S. Raymond がまとめた「ハッカーズ大辞典」)と、スティーヴン・レヴィの「ハッカーズ」が二大聖典(邦訳のレベルでは)みたいなものでしょう。UNIXの発祥を語った書籍はいろいろありますが、UNIX 自体は最初ガラクタのPDP-7 でゲームをするために作られて、研究所の予算がついて、当時最新鋭 PDP-11 で実装された、という経緯なので、惜しいことに PDP-10 を素通りしてます....ですから、ホントに私なんかだと、PDP-10 とその文化いうと、直接の遺産には手がでなくても、たとえば、
- 1. R.M.ストールマンのバックグラウンドがこれ。で、FSFの活動にこの MIT のAIラボ文化がある。
- 2. ジェリー・サスマンと G. L. スティールも MIT AI ラボ文化の出身で、ここの特選言語が Lisp であり、その精華を Scheme と考えていい。
- 3. だから、ストールマンが開発した Emacs のマクロ言語が Lisp であり、gcc の中間言語がやはり Lisp の変形版。
- 4. やはり、「char =8bit ? そうもと限らないよ! たとえば PDP-10 だと char は 9bit だ!」
というあたりで「伝説のマシンとその文化」というイメージが確固として出来上がっていたりします....
まあ、とはいえ昔のことなので、たとえばメモリが今で換算して 1Mbyte くらいしかない状況でマルチユーザ・マルチタスクを実現してた...わけですから、今のマシンと比較すること自体野暮ではありますし、なんせ セントラル・プロセッサ・ユニット(わざわざカナ書きに注意)をハンドハックして、新しい命令を追加したり...なんていうワイルドな時代だったりするわけで、現在の感覚が通用しない時代の話だ、という風に割り引いて聞いてくだされば幸いです(苦笑)。
どうやら海外には PDP シリーズのファンクラブみたいなものがあるようです。→ PDPPlanet。ここにスピーカーの映像があったりします....そういえば、スタンフォード大学で開発された代替OSの WAITS には、結構マルチメディア風の機能があった....なんて聞きます。ここの学生が XEROX PARC に入って、XEROX Star を開発したわけですから、実際には Macintosh の源流は PDP-10 だった...とか(冗談)
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.22 09:28
Googleの野望
2007.10.20
DIコンテナネタが続いたのですけども、こんなものもありました。
Google Guice (ITProの日本語使い方解説ページ)
というものです。名前から判るように、Google で開発しているDIコンテナです。最近 Google は Apache とか Codehaus みたいなノリで、「Google Code」という名前でオープンソースプロジェクトのホスティングをしていまして、その成果、という格好になるものです。特に Google っぽいブラウザ回りの技術でないもので、注目されたのってこれが初めてかな(あ、OCRソフトで OCRopusというのがあるようです)。
で本題の Google Guice ですが、これの最大の特徴は、
アノテーション・ベースのDIコンテナ
という面です。ですから、どういう Injection をするのか、というのを別の設定ファイルに書かなくても、単に
import com.google.inject.Inject;
public class Client {
private HelloService service = null;
@Inject // Inject 指示のアノテーション
public void setHelloService( HelloService serv ) {
// Module クラスで指定する 、
// 適切な実装クラスが渡される
this.service = serv;
}
// 利用メソッド
public void execute() {
// Module クラスで指定した実装クラス
// の sayHello() を呼ぶ
service.sayHello();
}
}
というように「@Inject」でInject される側を指定する...という格好になります。
こういうのもあっていい....というだけではなくて、「アノテーションベースのDIコンテナ」の狙いは、今後のアノテーション・プロセッサの充実をうまく使って、例えば
@Cache
Object get(String key) {
みたいなキャッシュ指示を、特にコードを書かなくてもできちゃうようにする...というあたりにあるのかも、という気もします。これ Google の影のヒット作になるかもしれませんね(けど、com.google.inject.Inject というパッケージ名が何か妖しい....)。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.20 10:44
ハッカー版トリビアの泉
2007.10.17
「達人プログラマー」というOOPLを使った設計&開発を上達しよう!とするに当たって、非常に役立ついい本がありますが、この本に出ている「早押し問題」です。
以下の「起こりそうもない」ことで実際に起こりうるのはどれでしょうか? (注:全部起こります)
- 1. 一ヶ月(標準的なグレゴリオ暦を使用)が28日よりも少ない。
- 2. stat(".",&sb) == -1 になる(つまり、カレントディレクトリにアクセスできない)。
- 3. C++において、a = 2; b = 3; if( a + b != 5 ) exit(1); で exit(1); になる。
- 4. 三角形の内角の和が180度でない。
- 5. 1分が60秒にならない。
- 6. Java において、(a + 1) <= a になる。
....これを若いプログラマ相手に出してみると、「ホント常識が覆った....」と天を仰いでました。これらの質問は、別にトンチでも引っ掛けでもなくて、すべて「ホントに起きることがあり、それに遭遇したら自分のコードがトラブルのネタになる可能性を否定できない...」ものなのです。
- 1. 日本人には馴染みが薄いですが、西暦はローマに始まるユリウス暦からグレゴリオ暦に 1582年10月に切り替わっています。この月は 20 日しか日がありません。一種のフェンスポストエラー問題ですね....
- 2. 該当プロセス実行後にそのディレクトリが削除された、あるいはパーミッションが変更されたなど。
- 3. C++は演算子オーバーライドがある。
- 4. これは測量ソフトとか GoogleMap でもない限り起きない....かもね。数学の教養で、平面幾何学ではないユークリッド幾何学(球面幾何とか双曲幾何)の場合は180度にはならない。
- 5. 「うるう秒」がたまにあります。これは地球の自転と原子時計の刻みとの間のズレを調整するもので、1972年以降23回実施されており、最近では 2006年1月1日08:59:60秒(日本時間)という秒が挿入されています。
- 6. たとえば a が byte a = 127; だったらどうなんだろうね。
けど、これホントにハッカー好みなクイズですね....こういうトリビアルな知識を収集して面白がるというのは、かなり重度に hackish な行いのように思います。その昔のHAKMEMの頃からハッカーってこういうのが大好きだったりするわけです。
HAKMEMとは?.......MITハッカー(AIラボ文化)華やかりし頃に作られた数学・コンピュータ雑学メモ。これに貢献した人物として名が挙がっている有名人は...とか、何か凄いメンバーです。
- マーヴィン・ミンスキー(人工知能研究家)
- ビル・ゴスパー(LIFEゲームで有名)
- リチャード・ストールマン(GNU)
- ジェリー・サスマン(Scheme などを開発)
たとえば新作でこういうのはいかが?
- 7. UNIX のシステムコール close(2) が不正引数以外で -1 を返すのはどういう場合?
- 8. bash で「test $$ = `echo $$` && echo "same"」の出力は? ($$はカレントプロセスのPID)
- 9. あなたの環境(C)で printf( UNIX ) がコンパイルが通りますか?通るのならば何を出力しますか?
- 10. 書き出しOPEN中のファイルを、別プログラム(とかOSのファイルマネージャ)から削除・移動・リネームすると、あなたの環境ではどうなりますか?(これログファイル出力でよく問題になる話です)
けども、「達人プログラマ」という本のタイトルはカッコ悪いです...原題の「The Pragmatic Programmmer」の方がずっとカッコイイと思いませんか?
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.17 12:23
いわゆる一つの Generation Gap
2007.10.16
デザパタ話でごめんなさい。私デザパタって好きです....でまあ、GoF 以外のデザパタっていうと、MVC とか「マルチスレッド・プログラミングのデザパタ」とか、いろいろとあるわけですけど、今回のネタは Generation Gap です。
このパターンってそういやGoFを読んだ後で読むべき、「デザパタ副読本の定番」みたいな雰囲気の「パターンハッチング」にありましたから、かなり昔からあるパターンでしたけども、「何か外部のコードジェネレータでOOPLのソースを生成した後で」適応されるパターンだったこともあるのか、今一つ知名度が低かったような気もするわけですけども、O/Rマッピングツールでこのパターンがデフォルトで使われる(Torque)とか、これを使うのを見越した仕様があって、使うのが定番(Hibernate)というようなかたちで、そこそこ広まっているのかなぁ...というのが今日この頃の気がします。
あ、Generation Gap ってのは、外部コードジェネレータが OOPL のソースを生成する時に、実際クライアントコードから使うクラスを生成するのではなくて、その抽象基底クラスを生成して、それを継承したクラスをクライアントコードから使う...というものですね。だから、デフォルトで Generation Gap を使う Torque だと BaseTableName.java に Torque の O/Rマッピングの実体コードが生成され、同時にそれを継承する TableName.java という空実装のソースが(もし存在しなければ)作られる、という動作のものです。
知名度が今一つだったのはやはり、
外部コードジェネレータを使う場合のパターン
という側面が本質的だったということですけども、ここらへん、たとえばアノテーションベースでのコードジェネレータを作る...というようなことが今後広まるかもしれないわけですから、そういう局面で、この Generation Gap パターンの有用性、みたいなものはより広がるような雰囲気もあるわけです。ですから、Proxy パターンとうまく組み合わせて柔軟な Proxy を作る...というような用途で使えるんじゃないかなぁ、という風にも応用が見えますね。
何かイイ応用例を作ってみたい気がします....メタデータ駆動のDIコンテナである Codehaus の DNA にちょっと私が刺激を受けてるのかなぁ。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.16 10:39
幹事パターン!(苦笑)
2007.10.15
たまには息抜き。「ハッカーズ大辞典」にもハッカーのユーモアの特徴として、
大規模な知的構築物のさりげないパロディ(技術仕様書とか、RFC とか....)
というのがありますが、ちょいとこんなの見つけました。
要するにこれ、GoF のデザパタの宴会幹事に関するマジメ(?)な適用結果です。デザパタもパロディの対象になるくらいに、プログラマの間で一般化して笑いが取れるようになった...のかな?
図に乗って新幹事パターンを書くと、
- Inversion of Contorol
- 『制御の反転』
- 各自勝手に注文を出すのではなく、セット物を頼んだ後に、追加でいろいろと注文するように最初から仕組んでおくこと。今風のJ2EEな幹事が使う...かどうかは知らない。
ってどうでしょう(GoFパターンじゃないですが)。逆に言うと、デザインパターンは抽象度が高いために、こういう風なパロディ用途でも適用できちゃう...というのも反面の事実のわけですね。意外にこういう事実の方が深い...のかも。
オブジェクト指向アプローチによるモデリングを行うと、対象とする実世界をそのまま表現できる、あるいはしやすいと言われます。
あとこれ例の結城浩氏作のもの。やってくれます。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.15 16:58
ハッカーと口語文化
2007.10.12
「ハッカーズ大辞典」を参照するまでもなく、ハッカーの書いた文章というのはかなりクダけてユーモアのあるもの、という傾向があります。たとえそれが、ハードな技術文献だったとしてもね。
ですから、そういう文章を日本語訳するときも、原文の口語の勢いをそのまま日本語にしようとするために、やはりクダけた口調の口語訳になる傾向があるわけです。まあ、こういう傾向を形成するに当たって、決定的な影響があったのは、やはり山形浩生氏訳の「伽藍とバザール」でしょうし、これが「オープンソースの文化って?」という面でも一種のスタンダードになったような気もするわけです。
まあ、勿論こういう口語体を生かしたハッカー文献というと、90年代初めのASCIIの「256倍使うための本」の文体の影響が強かった気がする(私自身結構影響を受けた....)けど、このシリーズの初期に関わっていた福崎俊博氏が「ハッカーズ大辞典」の翻訳者だったりするわけで、
ハッカーらしい文章
(ついでに言えばこういう強調語を単独行にしてマークする、というのを始めたのが256文体の気がする)とは、口語でクダけて、小憎らしいユーモアがあって...というスタイルを定着させた...というような印象があります。
....なんて懐旧しちゃったのは、実は「Inversion of Control コンテナと Dependency Injection パターン」(マーチン・ファウラー・かくたに氏訳)をかなりニヤニヤしながら読んじゃった...というあたりにあります。あ、これ「DIコンテナ」という言い方を流行らせたファウラーの元論文の訳なので、技術的に非常に重要な論文なのですが....いかにもハッカーらしいのですね!
おそらく原文も比較的気取らない書き方をしているようですが、まあ、大体がファウラーとかベックの属するデザパタ&XP&smalltalkコミュニティって、文章の雰囲気が親しげで柔らかくで、個人的に大好きだったりします....何と言うのでしょうか、「無理をしないユーモア感」が漂って、このコミュニティの文体というのは、ある意味「ハッカー文体」の到達点みたいなものなのかもしれません。
(勿論この論文技術的に非常に勉強になるものです。ぜひぜひお読みあれ)
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.12 11:28
常識はすぐ古くなる....
2007.10.12
ちょっと違うネタです。
現在若いプログラマと一緒に仕事をしているわけですが、そこで遭遇したちょっとしたショックです。それは、
結構なJava開発歴があるのに、シェルのリダイレクションを知らない....
ということです。私なんかの世代は、それこそ MS-DOS の command.com の貧弱なリダイレクションに耐え、Linux の普及前から UNIX の /bin/sh に憧れつついざというときには使えるように学び、Linux で「あ~UNIX はイイ!」と実感するのが、シェルのリダイレクション&パイプによって、複雑なコマンドラインを構築して一気に面倒なことをさせる瞬間だったのですね。
勿論今は Cygwin 環境で仕事してますから、Window だと言ってもフルに GNU bash が使える状態のわけです。しかも、UNIX 標準のテキストツール類もちゃんと入っているわけです。それを使わないのはホントにもったいないですね。
たとえば、パイプライン出力を加工して、シェルスクリプトファイルを出力し、それを実行させるとか....ここらへん私は常套手段としてたりするわけですが、そういう合わせ技系のやり方を、知らないのは大きな損失のような気がします。
Eclipse とか使ってると、検索とかも Eclipse 上で出来ちゃうので、
% find web/WEB-INF/src -name '*.java' | xargs grep SomeClass | grep extends
とかすることもないのでしょう....どうもこのままだと、複雑なシェルスクリプトを書く能力ってのは貴重なものになってしまう(プログラマの片手間で書けなくなる!?)のかもしれません.....(ショックを隠しきれない)
あともしかして、過去互換しか意味がない?な技術というと、
- 1. 置換マクロ関連の技(C++ ではまだcppが現役。m4 だともともと一部のハッカーしか知らない)
- 2. 言語並みテキストフィルターである sed, awk(Perl はまだしも)
- 3. nroff (もう長らく UNIX man にしか使われておらず、これさえ HTML化が進んでる)
- 4. TeX/texinfo/info(すでに絶滅?)
...........ここらへん、Linux を初めて使い出したとき、大喜びで学んだものだったりするわけです(個人的に寂しい...)。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.12 10:42
DIコンテナあれこれ
2007.10.11
今やってるプロジェクトは、流行に合わせて Hibernate+Springだったりします。Spring とは言っても、実際にはトランザクション管理しかしていない状態なので、本当は Spring の実力の1/10も引き出してはいない...なんて状態なのです。
しかし、Spring って大きすぎますね。現状で今のプロジェクトの lib ディレクトリの中では最大(約1.9M)です。勿論これ、使うわけでもない MVCフレームワークとか、アプリから直接使ってるわけではない設定ファイルを読んで Bean をゴリゴリ構築するコンテナ機能とか、そういうコードが大量にあるわけで、こういうことになっているわけです。
とはいえ、DIコンテナって Spring の専売特許ではありません。ちょいと調べると、こんなものがあります。
| DIコンテナ | 説明 | ライセンス |
|---|---|---|
|
(国産) |
国産DIコンテナ。Convention over Configurationの考えのもとに、設定ファイルを最小限にできる。AOP可。 | Apache |
|
(Codehaus) |
最小のDIコンテナを目指しているプロジェクト。picoContainerを使って、さらに他のDIコンテナ並みの機能を実現している関連プロジェクトとして、NanoContainer がある。 |
BSD |
|
(Codehaus) |
ソースのコメントとして、DIコンテナ用の指示を書き込むことで、DIコンテナ風に振舞うアイデア物のコンテナ。このやり方を「MetaData Model」と呼んでいる。これが Avalon Phoenix 後継の Loom で使われているわけなので、少し Avalon っぽいところがある。 | ? |
|
(Apache) |
DIコンテナの元祖みたいなプロジェクトだったAvalon の Apache 内後継プロジェクト。現状では Excalibur プロジェクトの下にいる。Avalonのコードは今でも Cocoon(最新の2.2はSpringになってしまった), James, Turbin などで生きている.... | Apache |
|
(Apache) |
任意の Interface でマーキングする、Interface 指向の DI コンテナ。AOPあり。 | Apache |
|
(Apache) |
勿論Apache の J2EE サーバだが、いろいろな機能を Apache で開発されるサブプロジェクトをコンポーネントとして使う格好になっている。ここらへんを実現するのに、DIコンテナ風の発想で、JMXの MBean を拡張して GBean と名づけた機能を実装している。 | Apache |
こうしてみると、結構よりどりみどり....という気がしませんか???
余談:そういえば、PicoContainer って、Martin Fowler にヒイキされているコンテナだったりしますね.....参考:「Inversion of Control コンテナと Dependency Injection パターン PicoContainer でのコンストラクタ・インジェクション」。結構DIコンテナ開発者の間では、Type3IoC(コンストラクタ・インジェクション)の古典的例として有名なプロジェクトのようですね。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.11 09:47
こんなことも出来ないなんて!
2007.10.05
誰に言ってるか....というと、私を含めたプログラマです(苦笑)。
あすなろブログの記事で、
PCの電源と照明のON/OFFとを連動させる
というものがありました。これからちょっと思い出した話なんですけども、
PCから室内の電源ON/OFFの制御、できます?
という質問への感想なんです。
そりゃ、フツー、優秀なプログラマだってこんなことできないです。それ相応のデバイスがない限りね。私は個人的には、そういうのってある意味情けない....ことのようにも感じるわけです。閉じた箱の中の世界ではそれこそ、「何でもできる!」と威張ることができても、ごく身近な照明のON・OFFさえもできないなんて!
で、昔ここら辺調べたことがあって、少しくらいは基礎知識(できる...と威張れるほどじゃないです)がないわけでもないです。で、調べてみると...面白いものがありました。
IP制御電源装置 Aviosys IP Power 9202(秋月通商で4300円)
これ要するに、ウェブサーバとして動作する、電源コントロール機器なんですね。このサーバの上にCGIがあって、それをネット越しに操作することで、これにつないだ電源をON/OFFできちゃう....という楽しい機器です。
どうやら、台湾のAviosys というメーカが作った基盤で IP Power 9202 という商品があって、それを内蔵orコンパチくらいでいろいろなところでより使いやすくした商品が出ているみたいです。
Aviosys IP Power(本家 Aviosys)
Avaiosys IP Power 9202 はホントに基盤だけで、電源コードもコンセントじゃなくて被覆を剥いて繋ぐようなものなので、もっと手軽に使えるような商品もいろいろとあるようです。
Aviosys IP Power 9282(箱入りコンセント付き)
9282 は開発元の Aviosys で出している商品で、ちゃんと箱に入って端子がコンセントになっているものです。ちょっと欲しくなっちゃいました(苦笑)。その他...
- Aviosys IP Power 9212(箱入りタイプ・秋月価格 7800円)
- 活用例:サーバを外からリセットする
- 活用例:IP Power9202 を使って電源をコントロールしてみる(詳しい)
これがあれば、あなたも
自分はコンピュータを使って電灯のスイッチをONできるプログラマだ!
と威張ることができるのかも(笑)。
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.05 10:44
とにかく何かしてくれない?
2007.10.03
今回の話は JNDI なんです。ですから、「とにかく何かしてくれない?」というタイトルをつけたわけです。
要するに JNDI というモノは、「何をするのか」は実際に何も決まっていないサービスだったりするわけです。実際に「何をするのか」は、JNDIプロパティで指定する、サービスプロバイダによって決まる...というわけなんですね。
意外にプログラマって、「抽象論がキライで具体論が大好き!」ってキャラのことが多いような気がしないでもないです.....ですから、こういう抽象度高すぎのインターフェイスって、とっつきが良くない傾向があるような気がしますが、JNDI ってサービスは、
実は JDBC によく似てる...
という気が私はしたりするわけです。そりゃ JDBC は SQL サーバにアクセスするための、統一的なインターフェイスを提供しますが、ホントのところ、クライアントと SQLサーバとが通信するプロトコルは、そのDB製品によって固有なので、全然相互に似ている部分なんてありゃしないわけです。それでも
SQLという決まった言語を送受信することで、データベースに対する操作をする
という観念的な枠組みがあるために、何となく「JDBC=具体的なサービス」というイメージを持ちやすいだけなのではないのでしょうか???
強引にやろうと思えば、「SQL のようなインターフェイスで、DNS を検索する」なんてのもできるのかもしれません....そう考えてみれば、ほらほら
JDBC はホントにデータベースにアクセスするのだろうか???
というのが、実はかなり謎になって....きませんでしたか(苦笑)。
本題に戻ると、JNDI は「使い道非限定のサービス」で、「使うやり方」だけが決まっているサービスのわけです。結局のところ、DNS にアクセスする標準のやり方は、JNDI を介するもののわけですし、「何をする」のか決まってないために、「何でも....」という広い使い道が、今後あるのかもしれませんね。
あ、たとえば RSS などのフィード情報を蓄積して LDAP で管理して、検索するインターフェイスに使うってどうなんだろうか......
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.03 17:17
「橋渡し」のやり方
2007.10.02
logback を見ていると、要するにこれ、commons-logging + log4j みたいな使い方がデフォルトになっています。つまり、ログ取りメソッド関連は、すべて slf4j という(commons-logging相当の)別ライブラリ(どうせ開発者は同じですけど)になっていて、この slf4j 経由での呼び出しを回避して直接logbackを呼ぶ方がずっとややこしい...というような、フロントエンドライブラリ+ログ実装ライブラリの役割分担がきれいに分かれた設計になっています。
slf4j では、このライブラリが MDC (マップ化診断コンテキスト)を担当していたり、あるいは Marker という追加情報を slf4j で管理したりとか、「最大公約数の機能」しかない commons-logging よりもずっと進化したものになっています。
で....やっていて一番面白かったことというのは、
commos-logging.properties に相当する設定がない
ということなんです。実は「どのログ実装ライブラリを使うのか」を選択するプロパティがまったく存在していないのですね.....一体どうやって実装クラスを特定するのでしょうか?
実はですね、slf4j では「同じ FQCN の Bridge クラスを作って、クラスパス上に存在する Bridge クラスによって、実装を切り替える」という過激なやり方をしています....実際には org.slf4j.impl.StaticLoggerBinder という FQCN のクラスが、log4j 用、logback 用, JDK14Logger 用、commons-logging用とか、それぞれのslf4j パッケージに実装されていて、実装ロガーを切り替えたければ、適切な Bridge パッケージをクラスパスに入れる、という使い方なんです。
ホントにこれ、
そっか....実装クラス選択プロパティは、よく考えると冗長なプロパティだったんだ....
と私は結構ショックを受けてました......こういうやり方もアリなんですね。
余談:slf4j では commons-logging パッケージを、J(akarta)C(ommons)L(ogging)という略で、「JCL」と略して書いてます....この略称凄くイメージ悪いです(判らない人は大ベテランさんに聞いてください)。悪意すら感じちゃいますね.....
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.02 09:37
輝く宝石もあざやかな手法も....
2007.10.01
このところの土日は例によって、趣味の logback ソース読みです。
やはり設計能力の高い人が書いたソースには読む快感があります。私、Ceki Gülcü のソース好きなんですね.... 要するに、
- 1. 特に logback では、「パターン・アクション」方式が、結構いろいろなところで採用されていて、プログラムがかなり宣言的になってきている。これ見通しいいんですね。
- 2. logback ではかなり直交性の高いモジュール化がされており、組み合わせ自由感が強い。
- 3. 結果として、設定ファイルを解釈する JoranConfigurator が、小規模な Spring みたいなことになっている...Spring より面白いフィーチャーもいろいろあります。そのうち自分のプロジェクトで自分の設定ファイルをこれに処理させてみようかな。
- 4... まあ、その他やはりこの人才能ありますね。ソースがトンガってます。
逆に言うと実装のツメが少し甘くて、「こんなんすぐ直るじゃん...」と言いたくなるようなバグが 0.9.8 なんてリビジョンでも残ってたりするあたりがご愛嬌でしょうか。ソースのトンガり具合になかなか凄みがあるので、民主的な Apache みたいなところでは、理解されにくい部分もあるのかもしれません....
なんかやんや言って、私が log4j に首を突っ込みだしたのも、やはり多機能で面白いロガーだった、という側面があります。で、ソースを読んでいくと、これも判りやすく、技法的に啓発的なものが多くあったわけです。
プログラマの間での雑談では、「○○のソースはどうこう」という話題が(自慢込みで)結構ありますが、それだけで終わることの方がずっと多いような気もします。そういうの残念....と思うこともあるわけです。
有名な英雄詩から引用して〆ましょうか。
私にはプログラミングが1つの芸術形式だと思われてならない。
ただ、その本当の価値は
この難解な芸術に精通した者にしかわからない。
プログラミングの性質上、輝く宝石も鮮やかな手法も
鑑賞や賞賛と無縁の場所にひっそりと置かれたままにされる。
時には永遠に。
「真のプログラマMelの物語」 「ハッカーズ大辞典(福崎俊博訳)」より
投稿者 : 杉浦 こずえ | 投稿日時 : 2007.10.01 12:17





