このところ私結構興奮気味ですね.....自分でも判ってますが、興奮するのも当然な変化なんですよ、ここらへんは。

しかも、Arduino にせよ Gainer にせよ、これが

オープンソースのハードウェア

だというあたりが更に面白いところです。言い換えると、

それを作るのに必要な情報は完全に公開されており、しかも、それを使って自分で作るに当たっては、販売も含めて、ライセンスを気にしなくていい

ということになります。まあ、Arduino や Gainer は

マイクロコントローラ（ＣＰＵ）　＋　周辺回路を含めた基板設計

ですから、公開してもどうってこともないといえばそうなのですが、以前「Windowsのない世界」で触れたような、途上国向けの低価格ハンドヘルド・コンピュータである「シンピュータ」も同様にオープンソース・ハードウェアだったりします。

昔読んで熱狂したものですが、パパネックの「生きのびるためのデザイン」 という本があります。パパネックはユネスコからの依頼を受けて、低開発国向けに「実際に生活の質を改善するデザイン」の活動をしていた人で、そういう視点からのデザイン批判を展開したのが「生きのびるためのデザイン」です。そこで紹介されるパパネック自身のデザインは...というと、

• 牛糞で作った電池と空き缶とトランジスタ一個だけで手作りできる低開発国向けのラジオ
• 簡単に組み立てられる教育用モニター
• 古自転車を改造した荒地で使える手押し車

といった廃物再利用（というか、入手しやすく資源を無駄にしない）素材で、特に専門的な技術・設備なしで作れる「デザイン」として、こういうモノを提案しているわけですから、これも一種の「オープンソースのハードウェア」のわけです（まあ、厳密には権利をユネスコが管理しているでしょうけどね）。

ですから、「オープンソース」という「カタチのない」ソフトウェアの世界を大きく変えた思想は、「モノ」の世界でも一定の有効性を持つ可能性があるわけです。

こういうモノを作れ！

という斬新なアイデアがあり、それの作り方が誰でのアクセスできるところに公開されており、特にライセンス料も要求されないし、作ったものを売るのも自由、という「オープンソースのハードウェア」というアイデアは実は急に出てきたものではなく、オルタナティブなデザイン運動として、きっと意外にも背景のあるものなのでしょう....（そういえば、バックミンスター・フラーだとＭＩＴで教えていた関係で、MITのハッカー文化と少し関係があったりします。意外にアメリカのアングラな文化とハッカーカルチャーの関連って深いものがありますからね）

.....あと、偶然紹介しているページ（Irresponsible Rumors 2008）を見つけたのですが、

ホビイスト向けに、３０＄で注文通りの基板を５枚焼いてくれるが、同時にその回路のマスク自体は焼いた会社が所有し、別な注文で同じような基板を求める人のために公開され、安く基板を提供できるようになる。名づけて「Open Source PCBs」（実際の基板）

というビジネスモデルの会社（Seeed Studio）が深圳にあるようです。何か車の相乗りみたいな感覚ですね...こういうのも一種の

Share ＆ Enjoy

なのかもしれません。厳密に言えばオープンソース・ハードウェアじゃないのですが、皆で「モノ」を共有しよう、というところで共通するところがありますね！

というのは、いわゆる「フィジカル・コンピューティング」という言い方です。あこれ昔は「電子工作」とか呼んでた部類の「コンピュータ」ですけども、前回・前々回のエントリで紹介した「Make Things Talking」とか Arduino とかの世界の話です。

この「フィジカル・コンピューティング」という呼び方はニューヨーク大学の教育プログラム・研究指針が発祥のようです。コンピュータの入力デバイスとして、モニタ・キーボード・マウス・プリンタ・タブレット・スピーカーとかいろいろあるわけですけども、こういう「既存のＩＯ」に「コンピュータの使い方」が制約される必要は全然なく、

自分でいくらでも面白いＩＯを考えて、実装しちゃおう。これが新しい「コンピュータの使い方」だ！

というのが、「フィジカル・コンピューティング」の考え方です。勿論、今までもこういうのはずっとあったわけですが、やはりなかなか敷居が高くて、

思いついたから、やっちゃお！

とはならないものなのですよね.....そりゃ、

1. 1. 一応アナログ電子回路知識がなけりゃ、電源をどうするか、センサの接続をどうするか、というあたりでツマヅいちゃう。
2. 2. デジタル回路の知識も必要だ....NAND ゲートを組み合わせて条件を制御するとか、７セグLED を制御して数字を表示するんだって、それなりの知識が必要なんだよね....
3. 3. で勿論プログラミングの知識は一応要る。けどアセンブリだ...今時「プログラミングを勉強するなら、まずアセンブリから！」なんて勉強する人いないだろうし....
4. 4. しかも、大概ここらへんの組み込み用ＣＰＵは省力・効率化ベースで作られているので、ハーバードアーキテクチャのRISCのチップだったりして、アセンブリ自体がわりとPCのモノと違って特殊。イチから勉強しないとね。
5. 5. であとシリアル接続なんて今もう結構廃れてるし...ツール使い方知ってる？

と結構ややこしい問題が山積みなんですね。ですから簡単に

思いついたらやっちゃお！

とならない世界だったのですが、これが変わっちゃったんです。

.Arduino もそうですが、ここらへんの便利なキットがいろいろと最近ではあります。

■Arduino

8ビットRISC ベースのAtmel AVR チップを使った制御用ボード（ＵＳＢ接続付）＋開発環境。Atmel AVR 自体が FlashROM 搭載で「とにかく繋いだらプログラムを簡単に書き込める」画期的なＣＰＵだったりします....PIC だとUV-EPROM とか EEPROM とかマスクROM とかいろいろなROMタイプ商品がありましたが、どれでもそれなりのライターへの投資が要ったりしますからね。でこの Atmel AVR のよさを発揮するための基盤のセットと開発環境が Arduino です。ですから、これ小さいながらちゃんと独立して動くコンピュータです。

■Gainer

Gainer は大垣のIAMAS で作った、USB接続でＰＣと繋いで使うI/Oモジュールです。これ自体にコントローラとして Cypress PSoC が載っており、一応これもコンピュータですが、Gainer ではスタンドアロンで動くものではありません。ＰＣに USB で繋ぎっぱなしで使います。PSoC はマイコンですが、プログラムでデジタル・アナログ入出力を切り替えれる...だけじゃなくて、内蔵でオペアンプとかフィルターとかアナログ回路が入っていて、それらをプログラムでうまく「繋いで」やれば、「アナログ回路が要らない...」という凄いことになります。大概のことがGainer だけのワンチップで済んじゃうプログラマブルな汎用入出力チップなんですね...

■USB/IO, USB/An

もともとモルフィー企画というところから出ていた、USB接続でPCと繋いで、USB経由でデジタル入出力する(USB/IO)、アナログ入力する(USB/An)キットです。コントローラとして Cypress CY7C37991A というUSBコントローラを使っていますから、これは「コンピュータ」じゃないです。ただの「USB経由で制御できるデバイス」です....けど、そういうモノで十分なケースもいろいろありそうですね。

他にもいろいろあるようですが、ここで特にこの３つを取り上げたのは、

やりたいことの汎用性・柔軟性に合わせて、いろいろなレベルでできる

というあたりを強調したいわけです....こんな比喩はどうでしょう？

Arduino：

提携関係にある独立した事業主。

Gainer：

優秀なスペシャリストがいる専属の代理店で、子会社化されている。

USB/IO：

本社から派遣された有能なセールスマン。

 しかもこれらすべて、

繋げば、動くし、プログラムだって高級言語のフレームワークを使い、ROM書き込みもまったく手間なし

という「お気楽・極楽」な環境がもう出来上がっているのです....昔、「こういう環境があったらイイな」と私も夢見たことがありましたが、それはもう現実になってしまったのです....とはいえ、このような変化は

今年に入って

バタバタと動いた感じがあります。 Arduino を日本のショップで扱い出したの今年の４月ですし、Gainer もショップ扱いは今年５月のようです....ごく最近の普及なんですよね。凄い話だと私は思ってます....

Arduinoです。オライリーから「Making Things Talk」って本が出てますね...

要するにこれ、マイコンです。かなりホビー用途っぽい雰囲気です。以前 PIC とか Z80 とかで遊んだこともありますから、こういうの興味だけは私ちゃんとありましてね....

まあ PIC だと安いのは 200円とかで、

200円でコンピュータが手に入る！（まあ丸っきりの嘘じゃないけど....）

わけですが、これはもう少し高い（3000円くらい）のですが、今までにないくらいに

とっても簡単にマイコン遊びができちゃう...

という恐るべきもののようです。というのは、

1. 1. USB 接続でプログラムを書けちゃう（書き込める）。ROMライターとか特に要らない
2. 2. 開発言語もアセンブリじゃなくて、Javaベースの高級言語が基本（アセンブリが基本で高級言語がオプション...ではない）。だからプログラミングが簡単。loop() 関数の中に「させたいこと」を記述するだけ！
3. 3. Bluetooth が使える製品もある。 携帯電話と結線で繋がなくても、無線でネットアクセスできちゃうし、家電をコントロールできるかも。
4. 4. でしかも、ハードウェア設計がオープンソースなので、すべてにおいてライセンスフリー（勿論開発ツールキットも）。

とか、結構オモシロ・コンセプトの商品になってますよ！

暇になったら（月末まで忙しい...）ぜひいじってみよ。

....ではい、興味を持ったので昼休みに買いました「Making Things Talk」。やっぱりタイトル萌えなんですけど（「おしゃべりなモノを作る」）、これパラ見ですが凄い本みたいです....だって、これマイクロコントローラ Arduino の使い方ですけども、目次から「単純なネットワーク」「ワイヤレス通信」...と、とってもじゃないですが、

マイクロコントローラの使い方

の本とは思えない内容です。これはオシャレに「ガレージ工作」を語ったオライリーの「Make:」シリーズの一環で出たものですが、従前のトラ技流の「電子工作本のデザイン」とは一線を画したオシャレなデザインに驚嘆。これはどっちか言えば

ネットワークについての、斬新な哲学書

みたいな雰囲気です.....待て続報。ちょっとびっくりしてます。

プログラミングにデバッグは付物です（当たり前）。デバッグツールというと....

で、まあいろいろとあるわけですが、こういうのも実はデバッグツールだったりします。そういうちょっと気楽ネタですよ今回は。基本的に Windows + Cygwin 環境というメジャーな環境が舞台です。

1. diff

そりゃ UNIX ツールの diff です...特に -b オプションがオススメ！ でたとえば Excel 出力だって、帳票を CSV で出してしまえば、立派に diff での比較の対象となります。ある項目だけ変わっている（その他の項目は不変）のチェックならば、うまく (g)awk で切り出してチェックしましょう。

.2. アクセサリの paint

画像編集用としては非力かもしれませんが、ごく簡単にスナップショットが取れるのは重宝します。Alt+[PrintScreen] で、特定のウィンドウだけがスナップショットできるので、これを アクセサリの paint に paste すれば、ウィンドウのイメージを比較できます。テキスト中心の内容だって、画像として比較していけないわけじゃないんですよ！

3. James

以前も触れたことがありますが、メール関連の開発をするなら MTA として James をローカルに立てるのがいいです。私は Info Mailet というものを作ってありますから、メールを受けたらこれが「メールを受けた！」ことをダンプして出力します。いちいちメーラで中身を確認する必要のないケース（単に飛んでればＯＫ）ではこっちのが楽です。

4. strings

UNIXツールの /usr/bin/strings です。私意外にコレ好きです....実行ファイルの中身を覗いて、テキストだけを抽出して、それから動作を推測する、という奴ですね。意外に使えますよ！

何でもデバッグツールといえばその通りですね。使いようです。今回珍しくお気楽なネタでした....

さて、前回「叙述性」という評価基準がある...という話をしたのですが、こういう「叙述性」というのは、実際考えてみると、深くプログラムの「宣言性」というものと関わってきます。私はですね、

プログラムは手続的（あるいは命令的）であるよりも、宣言的である方が、ずっと管理をしやすいものだ

ということを自身のプログラミングの中で「自分の信条」としているところがあります。今回はこういうお話です（細かく言うと宣言型プログラミング(Wikipedia)の第１の定義の方です）。

前回の例で言えば、

// コード1
root.add( kodomo1.add( mago1.add( himago1,
                                  himago2 ),
                       mago2.add( himago3 ),
                       mago3 ),
          kodomo2.add( mago4.add( himago4 ),
                       mago5 ) );

というプログラムと、それと同等な

// コード2
root.add( kodomo1);
root.add( kodomo2 );
kodomo1.add( mago1 );
kodomo1.add( mago2 );
kodomo1.add( mago3 );
mago1.add( himago1 );
....

とを比較した時、どちらが判りやすいでしょうか？？　まあこれは言うまでもないでしょう。　この違いは、

コード１：

root という変数が「どういう構造であるか(what)」を記述している

コード２：

root という変数の構造を「どう作るか(how)」を記述している

と言えます。要するにこれが「宣言的なプログラム」と「手続的なプログラム」の違いだと言えます。宣言的なプログラムは「それが何であるか」を記述しますが、手続的なプログラムは「それがどう動くか」を記述する...と理解するといいのかな？ この時、手続的なプログラムは大きな弱点を抱えることになります....それは

時系列

という問題ですね。今の例では順番は関係ありませんが、手続的なプログラムでは、「実行の順番」が大きな問題になります。それに対して、宣言的なプログラムでは、

それが何なのかが重要なので、どういう順番で作ろうとも、最終的な結果が記述に合致している限りどうでもいい

ということになるわけです...要するに、宣言的なプログラムでは「構築の順番」は舞台裏に回るように、うまくインターフェイスを設計することになります。たとえば何かをさせるために、決まった順番でインターフェイスを呼ばなければならないような（手続き的な）ライブラリは使いづらいに決まってます。たとえ１つインターフェイスを増やすことになっても、「セットされたオプションから内部的な状態を作り上げる」ための専用のインターフェイスを作って、「○○をセットするのが最後で、これによって最終的に内部状態が作り上げられる」というような、「時系列についての暗黙の使い方」が利用コンテキストに含まれない方がいいに決まっているわけです（たとえば Haskell だと遅延評価しますから、「関数を呼んだ順」が一般に処理の順番に反映しません....まあ Haskell は過激ですけどね）。

言い換えると、特にＯＯＰの場合は、

プログラムが「何をするのか」を順を追って記述するよりも、そのオブジェクトが「何なのか」を宣言的に記述すべきだ

ということになり、これは実際にはＯＯＰの精神とも合致するわけです。オブジェクトが備えるべきインターフェイスが、このオブジェクトが「何である」のかを決定し、それを「オブジェクトの仕様」として記述していく....これがオブジェクト指向であり宣言的であるプログラムのあり方なのでしょう。

実はこれはですね、「プログラミング言語」というものの性格にも一致する、と私は考えています。最近ではあまり意識しないといえばそうですが、高級言語でのプログラムというのは、

書いたとおりに動く、というものではない

という性格を持っているわけです。これは勿論、高級言語のモデルがいくつ変数があってもかまわない「ランダムアクセス機械」であるのに対して、実際のＣＰＵは固定された数のレジスタがあって、そのレジスタでしか計算ができなかったりする「レジスタ機械」である、というモデルの微妙な違いがあり、そのために、

高級言語のモデル　→　ＣＰＵのモデル

へ変換をする作業がコンパイル（翻訳）と呼ばれるわけです....この時、いくつ変数があってもいい「ランダムアクセス機械での記述」から「レジスタを使って計算するための記述」への変換がなされ、この時に、

そのレジスタ機械での合理的な計算の仕方

への舞台裏での変換が「最適化」と呼ばれるわけです....ですから、私たちが高級言語で書いたプログラム、というのも

実際に動く機械語コードを作るための（場合によっては大雑把な）仕様

を与えている、と言えばその通りなのですね。ですから、

そもそも高級言語で書く、ということ自体が宣言的であり、本当に手続的に書くのならばアセンブリで書くしかない

と言っても過言ではないのかもしれません。

宣言的プログラミング

という書き方は必ずしも関数型言語だけの問題ではなく、日々の実践の問題でもあるのです....

たまに見かけるインターフェイスですが....

public StringBuffer StringBuffer#append( String s );

というのが一番馴染みが深いかな？ これが StringBuffer#append() が StringBuffer を返す、というのは、要するに

append() したそのオブジェクト自身を返す

という動作です。ですからコードの最後は

return this;

で終わっているわけですね。Meyer 流の厳格に「funcion/procedure」を区別する立場だとイケナイことなのですが、

作用を受けた（副作用によって状態を変えた）自分自身を返すメソッド

なのですよね。でこういうメソッドを、意識的に作ることにどういうメリットがあるかな？というお話です。

StringBuffer#append() が自身を返す理由って、要するにこういう使い方が便利だからです。

StringBuffer sb = sb.append( a).append( "-").append(b).append("=");

勿論そうですよね....これがしたいからこそ、「自身を返すメソッド」であるわけです。同様に O/R マッピングツールの Criteria クラスもよくこういう設計をします。

 List cats = session.createCriteria(Cat.class)
     .createAlias("kittens", "kit")
     .add( Restrictions.like("kit.name", "Iz%") )
     .list();

これもホントは、Criteria が「StringBufferみたいなもの」ですから、org.hibernate.Criteria#add() などが、Criteria 自身を返して、

なんとなく SQL みたいに記述されたプログラム

の見かけを作り出すわけです....

ですから、ちょっとこういう概念はいかが？

自分自身を返すメソッドを作るのは、プログラムの「叙述性」を高めるメリットのためだ！

「叙述性」って言い方いいでしょ！ プログラムとしては別に特に機能的に変わるわけじゃないです。プログラムを

対象領域の処理について直感的に把握しやすくする目的で

言い換えれば「プログラマのために」こういう書き方を許そうとするのです...

ですから、Composite パターンで、入れ子の構造を作るメソッド add() も、やはり「自身を返すメソッド」であっていいです。なおかつ、

Composite add( Composite... args );

とうまく可変長引数を使ってやれば、こんな「叙述」ができます。

root.add( kodomo1.add( mago1.add( himago1,
                                  himago2 ),
                       mago2.add( himago3 ),
                       mago3 ),
          kodomo2.add( mago4.add( himago4 ),
                       mago5 ) );

どうです？「叙述性」を高めたプログラムとは、実際には「宣言的」でもあるようですよ。デザパタとして捉えて、何かカッコイイ名前をつけてあげたくなりました.....

 

仕事で相手先から送られてきたデータが、

おっと UTF-16 だ！

ということがありました。某ソフトでのデータの吐き出しが、そのままだと UTF-16 だったようで、別にオペレータが意図したことじゃなかったようですが....

UTF-16 だと意外にもてあまします。

1. 1. テキストフィルターで加工する時、ASCII に「見える」ものも、2byte だということを考慮すべき。
2. 2. で...BOM はどうしよう？

と、UTF-16 のままだとどうにもこうにも

テキストとしての機動性が悪い....

と、やはり UTF-8 に変換するのが吉のようです。

まあ私は UNIX 育ちですから、

テキストの先頭に「文書じゃない内容（BOM）」が入っている....

というのはハッキリ気持ちが悪いです。テキストはストリームで扱える単なる

無構造のデータ

であって、「テキストの形式」を強制されるべきではない、というのは実は「UNIX哲学」の一部なのです（言い換えるとホントは cat しても BOMがテキストストリームに現れないのが正解、ということかな）。ですから、たとえばこういう時、うっかりしますよ！

• #! で始まるシェルスクリプトを書いたとき、その前に BOM が入っていて、スクリプトだと理解してもらえなかった！
• XML の先頭に BOM が入っていて、それを理解しないパーサで解析してコケることがあるそうな....（XMLの先頭にBOMが入ってるのは規格違反ではない）
• ソースファイルの先頭に BOM が入っていて、コンパイラがそれをご親切に文法違反にしてくれるとか（gcc さえ文法違反みたいですね）。

と、意外に問題含みなものだったりします。ふう....まあ「BOM が必要」なコンテキストというのは単に

今が移行期だから

ということであるに過ぎません。とっととこういうものは要らなくなるようになってほしいですね。

昨日のことですが、同僚との間で

じゃあ、通信は Commons の httpClient を使って、マルチパートにして、file コントロールでアップロードするのと同じようにアクセスすることにしようね！

という話で作っていたのですが、あれ...同僚は httpClient でのマルチパートの使い方が判らなかったみたいで、私に「ヘルプ！」が来てしまいました....まあ、httpClient は Apache Commons の中でもポピュラーなライブラリですけども、さすがにマルチパートをしようとすると、

JavaDoc を見て、書く

という技量が必要になるわけです（まあ勿論まず「マルチパートのリクエストとは何ぞや？」という理解も必要ですが...）。やはり汎用的な Apache Commons ですから、それなりのデザパタを使った設計がなされていたり、それなりに

理解して使う

というのが必要となるレベルのライブラリなのですね...というわけで、現実的なプログラマ技量として

オープンソースライブラリを、あまり説明が書かれているわけでもない（しかも英語の） JavaDoc だけを見て使いこなす壁

というのは結構リアルにあるのかもしれません。

とはいえ、この壁を超えてスキルアップする最高の手段は、

何か面白そうなオープンソースプロダクトを選んで、それをソースレベルでキッチリ読んで、「どう動くか」「どう設計されているか」を理解する

という勉強法です。これをやれば大概の場合「生きたデザパタの理解」が得られることになるわけですから、メリットは極めて大きくオススメですよ（勿論、コストも当然かかりますが）！私の場合、log4j と James, blojsom でこれをやった経験が、極めて役に立っています。おせっかいながら、どうです？

あ、ちょっと皮肉な内容かもしれません。前回のエントリで、Kernighan & Pike の「UNIXプログラミング環境」を引き合いに出したのですが、これ今 amazon のレビューで見ると、

10件のレビューがあり、すべてが★５つ

という異常な結果になってます。いくら名著と言え、フツーもう少しバラけるものですが....けどね、懐かしいでしょ、「UNIXプログラミング環境」、勿論懐かしい人にとってはね（こういうのトートロジーですが）。

まあこの本「クラシックなUNIXのプログラマ向け紹介本」みたいなノリの本なのですが、いわゆる「UNIX哲学」を存分に語った「哲学書」でもあるわけです。

一つのことをうまくやれ！

....求める「機能の組み合わせ」はシェルでやればＯＫなんです。だから、「困難は分割せよ」という黄金則に忠実に、さまざまな UNIX シェルツールが作られた....というあたりを「語った」本がこの「UNIXプログラミング環境」です。

技術的にはこの本が紹介しているツールは、ed/sed/awk...といった「クラシックでちょい手ごわいツール」たちだし、シェルの特殊文字の記述もクラシックな端末のデフォルトのエスケープだったりして、内容ははっきり

古い

です。勿論レビュー子たちは、それを織り込み済での評価なのですよ。それでも、プログラミングの最終章が、

lex/yacc をフルに活用した、電卓の作り方

なんていう、

....無茶？

な内容だったりして、これがまたこの本の伝説さ（というかお買い得さ）を印象づけていたりします。他のＯＳ紹介本で、「このＯＳではどうやって電卓アプリを書くか？」がテーマになることなんてないと思います....どうでしょ？ まあ、この本が★５つなのは、そういう「UNIX伝説の効果」なのかもしれませんね....

1990年より始まり、本格職業プログラマとして研鑽を重ねる日々で、最後まで手元に残ったのは四冊だけでした。「プログラミング言語Ｃ」「ソフトウェア作法」、「プログラム書法」、そして「UNIXプログラミング環境」です。コンピュータを道具として使いこなし、いかに最小限で単純な、即ち信頼のおけるツールを使いこなすか。ある種の美学さえ感じさせる名著です。時代がLinuxに移っても、UNIXの真髄はシェルと/usr/binツール群をいかに使いこなすかにありと信じます。かような書物が入手困難という状況に深く杞憂を感じ、強く復刊を希望するものです。 (yos155氏のレビュー)

今している仕事で、筆者の担当するWebアプリに対して、httpClient でリクエストを発行し...という手順でアクセスすることになっているのですが、httpClient で作られるクライアントが、

その前段階で、UNIX フィルターでリクエスト内容を加工して...

という振り合いで全体の設計がなされているのが特徴です。まあ、この仕事

どうも要件がハッキリしない...

というあまりウレシクない条件での仕事だったりしますから、こういう

シェル上のフィルター・コマンドで、やり方の詳細が変わったとしても、その変化をうまく吸収（したい）

という狙いでの全体のフローですね。

というわけで、フィルターモデルって結構使えるよね、という話です。私は結構骨の髄からの UNIXist ですから、シェルのパイプラインをごちゃごちゃ組み合わせて仕事するのが大好きだったりします。だって柔軟ですからねぇ....一度憶えたら手放せませんよ。

フィルター・モデル、というと、UNIX man のベースである、nroff が強烈にフィルターモデルでした。まあ、今時 nroff を使う..なんてのは時代遅れもいいとこですが、要するに TeX（というか、PODというか...）に似た構造化テキストを清書して表示するのが nroff の仕事なのですが、たとえば....

• 数式をフォーマットしたければ、前処理で eql を、
• テーブルをフォーマットしたければ、前処理で tbl を、
• 図を埋め込みたければ pic を、
• 参考文献の参照を埋め込みたければ refer を....

という風に、実際のプロセッサである nroff に渡す前に、特別な処理を nroff が理解できるプリミティブに変換するいろいろなプリプロセッサを通して変換し、その結果を nroff でフォーマットする、という手順を踏んでいたりしました。

一応 nroff は、今でもUN*Xコアパッケージには必ずあるし、man のバックで動いてます....けど、今時 man を書いたりすることもないしね。レトロ技術もいいとこです。けど nroff は若くして亡くなったオザンナと例のカーニハンが関わった、「最初のUNIXツール」ですよ...「UNIXプログラミング環境」がここらへん詳しいです。

まあ、nroff のフィルター設計は過激ですが、

何かをさせるときに、一つ一つの守備範囲が「狭く限定された」フィルターをたくさん作って、それらを利用局面で適切なものを組み合わせて使う

というのは、非常に柔軟なシステム設計の技法です。たとえば、

CMSで投稿されたコメントが、スパムかどうか判定するのに、いろいろな側面からチェックする

のにこういうフィルターベースでのやり方も有効ですしね。で、このフィルターの最大のメリットって、

仕事が限定されており、一つ一つの条件と作用が明快なので、実装もわかりやすければ、検証も楽チン

というあたりですね、これバカにできませんよ。まあ、ここらへんを期待してかJava では java.io パッケージが、

フィルターをデザパタで捉えなおすと、Decorator になるので、Decorator ベースの設計で....

作られているわけです。（がちょいと初心者が Java でツマづく関門になってる雰囲気も...） java.io パッケージの中に、実は、FilterIn(Out)putStream/FilterReader(Writer) というクラスがありましてね、特に FilterInputStream なんぞはいつもよく使ういろいろなクラスの基底クラスだったりするわけです。そういう面でお世話になっているのですが、

自前でこの FilterInputStream を上書きして、何かさせる

というのに出くわして、アレ珍しい...という印象を持ったわけです。その利用例は、この間紹介した ftplet で、GET を発行してダウンロードする際に介入し、

置かれているファイルは正しいのに、ダウンロードされたファイルは加工されている（テストでやったのは、文字が XOR されてる）

というのをする際に、Apache ftpServer では、

1. 1. FtpSession から、ダウンロード対象ファイルの InputStream を得る。
2. 2. FtpSession から、アクセスユーザの DataConnection(出力ストリーム) を得る。
3. 3. 勝手な変換をするフィルター(FilterInputStream継承クラス)を作り、1. の InputStream を引数とするコンストラクタで初期化して、2. の DataConnection にセットする。

という流れで、本来の処理に介入する格好になります（ソース ）。まあ、これホントに、

うんこれフィルター

という感じの使い方です...大昔、ImageFilter を使い倒して書いたアプレットで、

このフィルターモデル難しい....

と悩んだことを思い出してしまいました...こういうモデルって、

そういや commons の Collections ユーティリティが Decorator だよね

というくらいで、「フィルターって敷居が高い」というイメージがあるので避けられてるのかな？などと...