昨日は期末の最終営業日、ということで、今行っている派遣先で「社員総会」がありました。この会社でも「初の試み」ということで、非常に有意義な集まりでした。

というのも、ソフトハウスで同時並行にいろいろなプロジェクトが動いている...という状態で、派遣社員も大人数だと、ついつい社内で隣の机の人が「何をやってるの？」ということさえ、よく知らない...なんてことになってしまいがちです（まあ、派遣で行ってると、聞きにくい...というのもありますよね）。ですから、「社員総会」と名前はついていても、「派遣の人も、関連会社の人も、とにかく一緒に仕事をする人は全員参加！」ということで、この集まりが持たれたわけです。

で、この「社員総会」は、社内の各プロジェクトで「何をしているか、どうなっているか、来期どうするのか」を手短に社内の他プロジェクトのメンバーに対してプレゼンテーションする、というのが主な内容でした。これ、聞いているとどのプロジェクトも非常に面白いわけです（ここではあまり細かい内容については触れないのがお約束ですね）。

今時の話で、雇用形態が流動化しているわけで、同じくプロジェクトで机を並べて仕事をしていても、「本籍」が違うのも当たり前な業界です。ですから、「一緒に仕事をしている人たちが、仕事について交流しあう場」という当たり前といえば当たり前なんですが、そういう場を会社として「改めて、作る」というのも、非常に有益なことだったりするわけです。他のプロジェクトで話題になっていること、これからしたいこと...などについて、プロジェクトを超えて交流しあうきっかけになるような、そういうイイ効果が生まれそうな期待があります。

どうもこのところ、レトロな感覚のネタが続いているような気がします...ブログって新ネタが難しいですね！

で、レトロの総まとめみたいな感じで、書いて見ましょう。「ＸＭＬ」の中で、「今の視点」からみて、非常に感心した記述があります。それは、XMLの使い方を実例で示す、ということを示すのに、「何か『有名』なボキャブラリを使って見せたほうがいいのでは？」ということで、Dublin Core と RDF を、2001年の時点できっちり紹介している記事（第１弾「XML活用の道を探る」檜山正幸筆）なのですね。ここらへんのボキャブラリは、今時だと、たとえば RSS 1.0 で、

<?xml version="1.0" encoding="utf-8"?>
<!-- まず RDF でラップして -->
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/" ← Dublin Core の NS
  xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
  xmlns:admin="http://webns.net/mvcb/"
  xmlns:cc="http://web.resource.org/cc/"
  xmlns="http://purl.org/rss/1.0/">

<!-- NS が付いていないのは rss 名前空間 -->
<channel rdf:about="http://www.nurs.or.jp/~sug/blog/">
<title>MovableTypeを制覇する</title>
<link>http://www.nurs.or.jp/~sug/blog/</link>
<description><![CDATA[<p>専用のブログである。</p>]]></description>
<!-- でこんな感じで Dublin Core が使われる -->
<dc:language>ja</dc:language>
<dc:creator>K.Sugiura</dc:creator>
<dc:date>2006-04-27T22:27:59+09:00</dc:date>
......
</rdf:RDF>

使っているようなものです。まあ、そうでなくても、トラックバックの AutoDiscovery が、同じようなかたちで「全体を包むラッパー = RDF、内容エレメント（の一部）=Dublin Core」というかたちで定義していたりとか、今時だと「とにかく求めるXMLをラップしたいなら RDF で、一般的な「著者」とか「作成日」のようなメタデータを記述するんなら Dublin Core で」とこれを使うのが常識みたいになっているような使い方を、「まだ XML　は海のものとも...（より少しマシだけど）」と保守的なエンジニアが言うような2001年という時期に、これをやってみせているわけです（勿論この時点での最先端の使い方です）。

翻ってみると、バッカス氏の大業績である BNF は、形式文法を記述する一番プログラマが好きな書き方なわけです。ですから、世の中の大概のプログラミング言語というのは、この「BNF ありき」で設計されている..というくらいに基礎的な技術なのですが、まあ、一般知名度はあまりないでしょうね。そもそも「新しいプログラミング言語を作る」なんて機会はほとんどないですから（それでもデザパタでインタプリタ・パターンやるなら知っておいた方が...）、知名度は大してなくても、実際には「これを欠いたら極めて不毛な」クラスの技術なのです。

とはいえ、もともと BNF というと、「プログラマがいつの間にか憶えている書法」だったりしますし、RDF ＆ Dublin Core だっていつの間にか目立たないところでごくフツーに使われてきています。これらは大掛かりな「革命」ではないですが、注意深い目で見れば、「着実で後戻りのない進歩」の部類なのです。表層のトレンドにはすこしも引っかからなくても、いつの間にか必要な人に届けられるような、深い流れ...みたいなものを感じて、感動した..というあたりでしょうか？

 （ちなみに RDF と Dublin Core はいわゆる「神崎先生」に少し難しいけど本格的な解説があります。これ勉強になります。)

報道によりますと、FORTRANの開発者で、バッカス・ナウア記法の考案者である、ジョン・バッカス氏が死去された...とのことです。謹んでお悔やみ申し上げます。

私なんかの世代ですと、大学のプログラミングの授業といえば、大教室座学は 汎用機のFORTRAN だったりします（さすがにオンライン編集の時代で、パンチカードは知りません）。そういえば一時仕事で FORTRAN プログラムを C に直す..なんてしたこともありました。とはいえ、もう「懐かしの....」言語ですね。

しかし、バッカス・ナウア記法（Backus Naur Form=BNF）の方はそういうわけではありません。これはどういうものか、を一言でいうと、「プログラミング言語の DTD」です。言い換えると、このバッカス・ナウア記法をベースにした、yacc文法で、「作りたいプログラミング言語構文」を記述すれば、「構文解析器」を生成してくれる古典的な unix ツールである、yacc があったりします。また、unix ですとツールのコマンドライン構文説明が、おおざっぱなＢＮＦで書かれることも結構あります...勿論、理論上は SGML(XML) のDTDだって、このBNFの子孫だったりします。

バッカス氏のコンピュータ科学への貢献はこのように非常に大きいものがありました。考えてみると、人間のさまざまな活動分野について、「その分野を作り上げた巨人たち」に存命の方が多い...というジャンルは、そんなには多くありません。勿論コンピュータ科学は相対的に若いジャンルですから、「伝説の巨人たち」に結構まだ存命の方が多くいらっしゃいます。これは面白いですね！少し調べてみましょう。この人がいない、あの人が抜けてる...なんて言わないでくださいね（基準は1970年代初めまでに大きな業績のあった人）。

こうしてみると、長生きな人が多いです....最長老は McCarthy と Naur, Chomsky あたり（1920年代生れ）ということみたいですね。

これは仕事で出てきた問題を解決する...という、リアルな話です。

階層構造のあるデータを、ベタなかたちで保存したデータがありました。つまり、

こういうものなのですが、これ自体は DB に入っているものなので、どんな順番でもソートは出来ます。で、このデータを正しく「階層」を表すかたちで、オブジェクトにしたい...という問題です。この時、DB へのアクセスは１回しかダメ、という制限があることとしましょう（効率とか考えれば不自然ではないですよね）。

勿論、DB アクセスが何回でもＯＫなら、「SELECT DISTINCT level1 FROM data」とか、繰り返しやって取る...という解決法があります。が、これがダメなケースで、一回ずるっと読んで、階層化してしまう...という処理をしたいわけです。

...実はこれって、懐かしの「コントロール・ブレーク（制御切れ）」なんですね。もう今では COBOLER とかしか使わないような、古典的ビジネス・アルゴリズムなんですが、教科書とかに載る例だと、「売上伝票から各地区、各支店、各営業担当ごとに大計・中計・小計を出せ」というタイプの問題です。とはいえ、今回はそれをオブジェクト化して扱わないといけないわけです。

で私が書いたのは、こんなコードです。

コード（少し長いです）

....というわけで、懐かしのレトロ・アルゴリズムを一ひねりして使うことになりました。ちょっとフツーの Iterator だと使いにくいので、自前で peek() が出来る（参照してもポインタの動かない）PeekableIterator というクラスを作らないといけないみたいです。いくら世の中が進歩しても、基本となるアルゴリズム（数学）は変わらないわけです。だから、こういうことに「古い知識」が役立つこともないわけではないですね。

同様のことが、私には去年、バイナリサーチをめぐってありました。これについては別にページを書いたので、そちらをご覧になるとよろしいのでは？と思います。

今回は少し毛色の違うネタです。

今一緒に働いている同僚の書いたプログラムを見た感想なのですが、DAOをうまく抽象化しようと努力して、ページングなどもうまくその中で処理をするようにしたわけです。で、結果として、JSP の中でちょこちょこ、と記述すると、「一覧リスト」の処理がほぼ単純な Bean サポートと、Struts Action（たとえば一覧からの削除）くらいで済んでしまう...というなかなかスグレもののフレームワークなのです。

これを見て思ったこと...というのは、これが一種の「宣言的プログラミング」になってきている、ということなのです（書いた同僚は意識していたわけではありませんが）。

「宣言的プログラミング」は、「目的」の仕様を記述することで、それが働くようにする、というプログラミング・パラダイムであり、「手続き型」と対立する概念です。ですから「どう実現するのか」はフレームワークの中に完全にカプセル化されてしまい、（DAOなので）「DB上のこのフィールドを取れ」という「指定」を並べて書くだけ（順番に完全に非依存に）で、一覧表示ができてしまう、ということになるわけです。ですから、本質的に「宣言的」な JSP と一緒にすることで、「（任意の）一覧リスト処理」が宣言的に記述できてしまう...ということになるわけです。なかなか凄いものです。

その背景を考えてみると、Java の Web アプリでは「JavaBeansによるプログラミング」という色彩が強く出ます。たとえば Struts を使うケースで考えれば、各ゲッタ・セッタの呼び出される順というのは、まったく任意であり、「順序非依存」なかたちになります。ですから、注意して書けば、Bean のセッタ・ゲッタというものは、「宣言的」な仕様である、という風にも解釈できるわけです（とはいえ、reset() は十分に手続き的になりますが）。

少し「宣言的」というコトバを、判りやすい例で説明しましょう。こういう処理をよく書きますよね。

public SomeObj getFoo(){
   if( foo == null ) {
      setupFooBar():
   }
   return foo;
}

このとき、こう書き直せば、初期化を行う setupFooBar() をした後に foo を返す、という意味ではなくて、「setupFooBar() であり return foo であるのが、getFoo() の定義だ」という宣言的なメソッドの「意味」になるわけです。

public OtherObj getBar() {
   setupFooBar();
   return bar;
}
// getFoo() と getBar() は非依存です
public SomeObj getFoo() {
   setupFooBar();
   return foo;
   // ホントはC風の型解釈で
   // return setupFooBar() ,foo;
   // とか return setupFooBar()  || foo;
   // と書きたいくらい..
}

private boolean setupFooBar() {
   if( foo == null ) {
      /* 構築処理をします。
      ここは手続き的ですね */
   }
   return true;
}

というわけで、本質的には「手続き的」な Java のような言語であっても、うまくフレームワーク化してカプセル化すれば、「宣言的」に書いていけることになります。実はこういうあたりがプログラミングの極意、みたいなものになるのでは、という気がします。

これは「Java: 利用可能なクラスを一覧する」の補足です。

通常の利用の場合、あのやり方でかまいませんが、Tomcat などから使う場合は、ClassLoader の扱いが通常環境と少々違うので、こんな感じになります。

// ここらへんは Tomcat の場合は常識
ClassLoader loader = Thread.currentThread().getContextClassLoader();
// ダミーとして、WEB-INF/classes にある適当なファイル（ここでは
// application.properties）を読み込む
URL dummy = loader.getResource( "application.properties" );

if( dummy == null ) {
   return null;
}
// そのＵＲＬを元に、WEB-INF/classes を示す URL を構築する
String classes = dummy.getPath();
int ind = classes.lastIndexOf( "/" );
classes = classes.substring( 0, ind );

URL url = new URL( dummy.getProtocol(), dummy.getHost(), classes );

URL [] urls = new URL [1];
urls[0] = url;

// BshClassPath をインスタンス化する
BshClassPath bcp = new BshClassPath( "", urls );

これは正規のクラスパスである WEB-INF/classes にクラスファイル（の階層）があって、それを検索利用したいケースの典型的な書き方になるようです。勿論、このurls 引数に、jar ファイルを指定すれば、Jar ファイル内部のパッケージを対象にすることになります。

今回は少し趣向を変えて、Java プログラミングの技です。

一部では有名な話なのですが、Java に「当然あると思われるような機能だけど、実はない機能」と言いますと、何と言ってこれです。

現在のクラスパス状況で、利用可能なクラスの一覧を取得する。

....まあこれ、細かいことを言うと、環境変数依存だったりするものなので、完璧な実装がしにくい機能、ということにもなるわけですが、こういう機能が欲しくなるケースってのもあります。たとえば、複雑な Strategy パターンを使っているケースで、

とにかく、○○というインターフェイスを実装したクラスを、××というパッケージ以下から探したい。

ということもあるわけです。こういうケースだと、「何か利用可能な一覧を列挙した設定ファイルを作って、その中にあるものから選ばせる」という実装が普通なのですが、強引にこれを解決してみましょう。

そのために使うのは、BeanShell というツールです。まあ、これは結構有名な「Java言語をスクリプト言語として使うインタプリタ」の実装ですから、使ったことのある方もいるのでは？とも思います。

BeanShell は Java の Jar ファイルをそのままシェル上で呼び出すことが出来たりします。また、使えるクラスの一覧を取得し....モロこれがそうですね。というわけで、BeanShell の実装の中に、「利用可能なクラスの一覧を取得する機能」があるわけです。これを使っちゃおう、というのが今回のネタです。

実際ここで使うのは BeanShell の機能のホンの一部で、クラスで言えば bsh.classpath.BshClassPath クラスが中心です（あと例外クラスの bsh.ClassPathException くらいです）。ですから、jar ファイルだと、bsh-core-2.*.jar と bsh-classpath-2.*.jar がクラスパスに通っていればＯＫです。

import bsh.classpath.BshClassPath;

import java.util.Set;
import java.util.Iterator;
import java.util.List;
import java.util.ArrayList;

public class SearchClass {
   public static void main( String [] arg ) {
      SearchClass sc = new SearchClass();

      for( int i = 0; i < arg.length; i++ ) {
         List<String> ret = sc.search( arg[i] );
         show( arg[i], ret );
      }
   }

   static void show( String search, List<String> result ) {
      System.out.println( "------" + search + "-----" );
      for( int j = 0; j < result.size(); j++ ) {
         System.out.println( result.get(j) );
      }
   }

   private BshClassPath bcp;
   SearchClass() {
      try {
         bcp = BshClassPath.getUserClassPath();
      } catch( bsh.ClassPathException e ) {
         e.printStackTrace();
      }
   }

   List<String> search( String name ) {
      List<String> ret = new ArrayList<String>();
      // パッケージ名一覧を取得する
      Set set = bcp.getPackagesSet();
      Iterator i = set.iterator();
      while( i.hasNext() ) {
         search( ret, name, (String)i.next() );
      }
      return ret;
   }

   void search( List<String> ret, String name, String packageName ) {
      // パッケージ内のクラス名を一覧する
      Set set = bcp.getClassesForPackage( packageName );
      Iterator i = set.iterator();
      while( i.hasNext() ) {
         String className = (String)i.next();
         // 内部クラスは無視する
         if( className.indexOf( "$" ) >= 0 ) {
            continue;
         }
         if( className.indexOf( name ) != -1 ) {
            ret.add( className );
         }
      }
   }
}

「温故知新 - 少し前の技術ムックを読む」の続編です。

私、というと実は結構ベテランなので、その昔「もう手続き型言語は古い！」というかけ声にノセされて、Lisp とか Prolog とか勉強したクチなんですね。まあ、ここらへんの関数型言語とか論理型言語というのは、実際の仕事で「役に立つ！」というよりも、視野を広げて「プログラマの素養」として役立つ、という雰囲気のものではあるのですが、そういう面からいくと、「XML というのもプログラミング言語である！」いうのは萌えです。

このムック第２弾「タグ・ライブラリが切り開く Web アプリ新時代」（浅海智晴筆）は、お馴染みの Taglib の解説なのですが、こういう記述があります。

XMLは、まさに上述の「ツリー構造のセマンティクスを持った単一のデータ構造」そのものだ。（略）このXMLをベースに、近い将来、データ構造とプログラムとを融合させた関数型プログラミング言語が登場するとしたら、Web ページ生成という、まさに「記号処理」の応用において大きな威力を発揮するに違いない。

というわけで、例えば次のような Lisp プログラム

(+
  (+ 100 30)
  (- 50 15)
)

と同等な表現として、

<plus>
  <plus>
   <value>100</value>
   <value>30</value>
  </plus>
  <minus>
   <value>50</value>
   <value>15</value>
  </minus>
</plus>

と書いて見せます。もちろんコレはかなり冗長なうえ、Lisp に馴れてないフツーのプログラマだと「判りにくいだけじゃん！」と言われそうなもの(ちなみに 「((100+30)+(50-15))」という式表現)なのですが、実際、XML というものは「プログラミング言語」であることは間違いないのです。たとえば、XSLT なんて、モロにプログラミング言語です。XSLT だったら、きっちりチューリング機械を構築できるんじゃないか？というくらいなものですよね。私なんぞは最初 XSLT を勉強した時には、「あ、これ何か Prolog に似てる！（パターンマッチの連鎖とかね）」と思ったくらいですし、やりようによっては単なる「埋め込み Java コードの代用」ではなくて、ちゃんとした「プログラミング言語」として作ることだって十分な形式的能力を秘めているわけです。

実際、タグ言語を「JSP の中で使う」ということから離れて、汎用的な「スクリプト言語」として使う....というと、Jakarta Commons の中に Jelly というプロジェクトがあります。これはスタンドアロンのスクリプトで、インタプリタとして、ドライバコードを書いてやれば、

<?xml version="1.0"?>
<j:jelly xmlns:j="jelly:core">
<j:set var="sum">0</j:set>
<j:forEach var="i" begin="1" end="10" step="1">
  <j:set var="sum">${sum + i}</j:set>
</j:forEach>
sum=${sum}
</j:jelly>

のようなスクリプトが、1 から 10 までの合計を計算するして出力する...という結果になります。もちろん、JSTL などで、JSP の上でこういうことを実現するやり方を御存じの読者の方もいらっしゃるでしょうが、「汎用的な言語らしさ」で言えば、スタンドアロンで動く Jelly の方が「らしい」わけですよね（苦笑）。もちろん、Jelly は JSTL などが「SQL だ、XML パースだ、メール送信だ！」といろいろな機能を盛りこんでいるのと同様に、それと同様なタグを準備していてくれています。そういう意味で「実用的で立派なスクリプト言語」であるわけです。

そこらへんが買われて、Maven の設定ファイルである maven.xml の記述「言語」みたいなかたちで、使われていたりしますので、勉強する価値はあるかも。何やかんや言って、最近の Jakarta の標準開発システムは Maven だったりしますからね。

JSTL などではあまりサポートされていない機能としては「サブルーチンの実現」があります（まあ、JSPのフラグメントはありますが...）が、Jelly だと例えばこんな風に出来たりします。

<?xml version="1.0"?>
<j:jelly xmlns:j="jelly:core"
        xmlns:define="jelly:define">
<!-- サブルーチン sumUp -->
<define:script var="sumUp">
  <j:set var="sum">0</j:set>
  <j:forEach var="i" begin="1" end="${until}"
         step="1">
    <j:set var="sum">${sum + i}</j:set>
  </j:forEach>
</define:script>
<!-- 引数 5 で呼び出すつもり -->
<j:set var="until">5</j:set>
<define:invoke script="${sumUp}"/>
sum=${sum}
<!-- 引数 20 で呼び出すつもり -->
<j:set var="until">20</j:set>
<define:invoke script="${sumUp}"/>
sum=${sum}
</j:jelly>

まあ、これは Hack Value のクチで書いたものですが、何か昔の Basic みたいです.....きっとそのうち、

(define x '(1 2 3 4))
(eval (cons '+ x))

みたいな、Lisp 臭いデータとプログラムの相互変換なんかも出来ちゃいそうな気がするんですけど（苦笑）。

さて、「温故知新 - 少し前の技術ムックを読む」の続編です。

もともと、「XML の利用法」の例としてこのムックで挙がっていた（XMLワールド第２弾「XML活用のためのガイダンス」川口耕介筆）のは、

1. 1.設定ファイルのフォーマットとして使う


2. 2.ログファイルのフォーマットとして使う


3. 3.保存データのフォーマットとして使う


4. 4.通信プロトコルとして使う

...といったあたりでした。これを「普及のきっかけ」という側面から、どういうフレームワークと結びついているのか、という視点で考え直してみましょう。

4.「通信プロトコル」という面で言えば、やはり SOAP や XML-RPC でしょうけど、ある意味、XHTML も RSS も HTTP に乗るコンテンツですから、これになるのかもしれません。

3.「保存データのフォーマット」2.「ログファイル・フォーマット」は、「データベース的機能」ということにもなるでしょうから、セマンティックWeb の考え方で、「Webがデータベース！」と捉えてしまえば、XHTML, RSS もそういう側面があります。とはいえ、「XML データベース」はまだ広く使われている...というほどでもないですね。

で、問題の1.「設定ファイル」です。まあ、これは一番素直な利用法でもあるわけです。ベーシックな DOM や SAX のライブラリでも、当然この使い方ができるわけで、「基本であっても、基本過ぎてもう一つ注目度は低い」という状況が続いていたわけです。これが変わったのは、やはり Spring の流行でしょうか。

Spring 以前にも、たとえば Avalon が、「自由なフォーマットの XML 設定ファイルを簡単に利用できるようにする」オープンソースのフレームワーク機構を提供していたわけですが、重装備な Avalon は開発者の間でブレークしたわけじゃないです。...が、ここで Spring が流行することによって、「XML設定ファイルの技術的完成」をみたように感じるのです。

言い換えると、「XML という着想」があり、それから「その利用法」が抽出され、それを「実装」するアプリやフレームワークが続く...という流れの中で、「技術的定番」と保留なく呼べるような、強力なフレームワークが登場することで、真の意味での「普及」が実現する...という風にも感じるわけです。そういう意味では、「細かいところを汎用的に面倒を見てくれるフレームワークは、やはり Sprinｇ が真打ち」というのは、正直な感想のように思います。

（ちなみに、Avalon は分裂しちゃいましたけど、これ面白いフレームワークでしたよ。あまり日本語で読める解説のないものでしたが、「James君！～Avalonから見たJames」でもご参照あれ。まあ、この記事を書いた「萌えポイント」は、要するに「XMLの活用法！」という今では当たり前すぎて、取り立てて言われなくなった「直球な表現」が何か面白い...というあたりでしょうか？）