top / index / prev / next / target / source
日記形式でつづる いがぴょんコラム ウェブページです。
今月からヒトミ先輩の配下で仕事をすることになりました。Curl関連の方式設計のあたりを担当する雰囲気です。
ヒトミ先輩とチームを編成させていただけることになりました。Curlという製品周りの方式設計を担う見通しです。
私は 会社に入って最初に触ったOSは UNIX (NEC EWS4800/30) でした。(RDBMSはInformixでした) だからコンピュータに関する学習は UNIXから初めました。(むろん小学校のころにFORTRANやフローチャートを勉強しましたし、中学校の時には BASIC と機械語で ゲームを書いたりしたことはありますけれど…)
そんななか、UNIXに染まる、とでも言うのでしょうか、基本的に「ストリーム指向」というものを最初に突きつけられました。当時は 何を言っているのかぜんぜん理解できませんでしたけれどもね。今振り返ってみるとストリーム指向というのは良くできているなぁ、と痛感します (そして運良く身に付いています)。処理量の変化に対してメモリ消費量は基本的に変化しないのは魅力です。(そして当然実現すべきことです)また 処理量に対して 処理時間も基本的に 処理量に対するリニアー(線形)な時間コストだけで済みます。(そしてこれも当然 実現すべきことです)業務アプリを作成するひとは あるいはあまり気にしなくて良いことなのかもしれませんが、××ライブラリのたぐいを実装する人・そしてあるいはフレームワークといったものを開発するひとは、基本的にメモリ消費量や処理時間に関することを必ず気にしているので、いろんなものをストリームで表現できないものかと日々これ切磋琢磨していることでしょう。だから有能な人は基本的にListやMapを利用せずに、逐次処理的な設計を心がけているように見受けられます。(優秀な人を観察した結果、そのように見えます)
ストリームもいろいろなのですが、例えばバイトストリームであると 基本的に1種類のデータしか処理することができません。でも、それはいろいろなバリエーションによって亜種があります。たとえばリレーショナルデータベースにおけるカーソルという概念も 観点を変えるとストリームという体裁を表しています。結果セットに対して、ロウという概念を持って逐次処理が可能なプログラミングインタフェースを提供してくれます。データベースというものはとてつもなく大量のデータを蓄えていることがあるので、カーソルのような概念を持って逐次処理しないと とても有限のコンピュータリソースにおけるデータ処理は不可能です。
そういった観点を持ったうえで XMLのプログラミング環境について見てみると、とても「ストリーム指向」の体裁をもった SAXというインタフェースがあります。これがすごく良くできています。まず基本的に逐次処理が可能です。そして ストリーム指向でありながら、バイトストリームとは異なり データに意味を持たせることができます。ある意味バイトストリームのみであったストリーム指向に一石を投じる、そのようなプログラミング環境でもあるのです。 SAX2インタフェースを、そしてContentHandlerをうまく組み合わせると、業務処理のおのおのを SAXインタフェースで実装して、ストリーム指向なプログラミング環境が実現できます。単なるXML処理のためのSAXインタフェースでは無くって、業務処理をストリーム指向で実現するための新たなパラダイムであるように見えてきました。
「ストリーム指向」も「SAXインタフェース」も別段新しいものでもないので、どこかの人が「SAXインタフェースによる一般業務システム開発」は 既に実現されているかも知れませんね。ただ私の知る範囲では あまりそういう実例を見たことが無かったので、ここに書いておきます。この「SAXインタフェースで一般業務システム開発」が現実のものとして普及してくると、「リレーショナルデータベース指向」の次にくるべきパラダイムが登場するのかも知れません。そして、その時代のデータストアは何かしらXMLデータベースでしょうけれども、その実装は SAXストリームと関連が強い実装になっているであろうと考えます。
2005.05.07追記 どんどん たわいもないアイデアが沸いてきます。
Javaリフレクションのインスペクション結果を SAX2のContentHandlerを介して返答する。
ディレクトリのような階層構造を SAX2のContentHandler形式で返答する。
SAX2ベースの ContentHandlerのマージおよびスプリット、フォークの実現、およびその実装例の例示。 →マージについては、ストリームとは異なるので、
総称すると ContentHandlerStream に相当するものが有効と考えます。Javaのストリームチェインと同様に コンストラクタでチェインするContentHandlerを指定する感じになります。 2005.06.07時点 ちなみに Googleで ContentHandlerStream を検索してもヒットはなかったです。
SAX2インタフェースって 次世代感や逐次処理感が漂っていて私はとっても好みなのですけれどもね。
2005.05.07追記 a-sanに、「Visitorパターン」についてのサジェスチョンを頂きました。勉強してみますです。
先日の 2005/06/01 日記: 徹夜明け , ひと昔まえのコンピュータ・ソフトウェア・エンジニアの夢とは… を書いた後、よくよく考えてみたら、そもそも私がオペレーティングシステムを開発できるスキルを身につけたい、と思った動機は
という、ロボットアニメファン指向な動機だったような記憶がよみがえってきました。ああ、なんてことだ。(そういえば私の世代で第一線を担っているコンピュータソフトウェアエンジニアの多くもガンダムファンですね…)特に ボトムズ(といかスコープドッグ)のOSに強い興味がありました。あれが作りたかったです。湯煙です。でも惜しむべきは最近では フロッピーディスクが使われなくなってきてしまった、ロボットの稼働が終了した時点で「湯煙の出る外部記憶媒体」というものが実現できないのが残念です。(というかそんなに熱かったら、データが飛ぶような気もしますが…) ※ボトムズを見ていた人にしかわからない話題です。
ちなみにコンピュータのユーザインタフェースとして、音声部分は バイファムのときのUIが理想です。あの声質 (つまり声質とかメッセージ内容が バイファムのそれが一番しっくりするのです)でないとダメなんです。ちなみに警告音については初代ガンダムが私の理想です。(どこかの都電荒川線の駅の発車アラームで ニュータイプ回避がしたくなるような警告音があります)
楽典とか勉強したい、というのも ロボットアニメに登場するユーザインタフェースの音の部分の実現が 本来の目的であったような気がしてきました。…本来の私の目的を忘れてしまっていたことに気がついたのは衝撃でした。しかし本来の目的が ロボットのオペレーティングシステムを開発したいというものだったとは…。目的を忘れていたのも衝撃ですが、それが動機だったのも衝撃。