さて、このエントリが１００個目だったりします。今日は年内最終仕事日ですので、まあキリもいいかも。

さて、前回紹介した「RESTful Web サービス」です。昨晩寝床で早速読んで（夜中になるとコードを追うのは面倒なので飛ばしましたが。サンプルソースがRubyな本って初めて...）ました。やはり期待にたがわぬ面白本です。で今日会社で早速布教。

で...やはり「REST」って言葉を知らないエンジニアはまだ多いですね。要するにこれ、たとえば前回の紹介記事の URL が、

http://blog.pasonatech.co.jp/nextblog/sugiura/5854.html

であって、決して

http://blog.pasonatech.co.jp/nextblog/blog.cgi?mode=view&user=sugiura&id=5854

じゃないこと....の哲学的根拠みたいなものです（メチャ単純化して言うと）。ですから、「ブログというもの自体の設計」に、この REST の哲学はある程度影響があります。MovableType だと、XML-RPC ベースの投稿API（MovableTypeAPIで有名ですが...）を持っていますが、もう一つの流れとして AtomPub（旧名AtomAPI） による投稿API がある（前アンドキュメンティッドでしたね...今どうなんだろ）わけです。この AtomPub が広く使われている代表的な REST の実例です（ブログサービスには AtomAPIをサポートしている投稿サービスがたくさんあります....）。たとえば投稿するのに HTTP の PUT メソッドを使い、投稿削除するのに DELETE メソッドを使う...というのは、いかにも「RESTっぽい」仕様です。

まあ、REST とは「いくつかの特徴を備えた Web サービス設計の方法論」ですから、単に「GET/POST 以外のメソッドを使ってるからRESTだ！」となるわけではないです。そこらへんは書籍を読むなり、この本の監訳者山本陽平氏の「REST入門」で勉強するのがいいでしょう。

で、REST の発想の根底には、やはり「今年のテーマ」（苦笑）である「温故知新」があります。言い換えると

HTTPのRFCで決まっているものを正しく活用しよう

です。最初から HTTP には PUT だ DELETE だ...のメソッドがあり、かなりキメ細かいステータスの定義があり....なのに、REST 以前では

これらが全然まともに使われていなかった

わけです。それらをキッチリ活用し、シンプル（反対はSOAP）でスケーラブルな Web サービスを構築するための基盤にしてやろう....というのが REST の目的のわけです。

この本の「はじめに」がなかなか気合入ってます。ちょいと引用すると

私たちは、驚くべき新技術について述べるために本書を執筆した。それが今ここで完成し、ホットであり、分散システムの作成方法を根本的に変えることを約束する。World Wide Web のことである。

....もちろん、これ、「マジメなジョーク」です。確かに REST化されたWWWは「ホットであり、分散システムの作成方法を根本的に変える」ものですが、これが「驚くべき新技術」....というわけではないあたりが極めて面白いところです（苦笑）。あと圧巻は付録の「最もよく使用される42のHTTPレスポンスコード」で、よく見かける一覧リストとは一線を画す、「REST視線でのHTTPレスポンスコード」になっています。「404 Not Found」と「410 Gone」の違いを説明できますか？（RFCの記述はわかりづらいんだよね....）

410 (Gone) 　重要度：中　このレスポンスコードは、404(Not Found)と似ているが、もう少し情報を提供する。リクエストされたURIが以前はリソースを参照していたが、そうではなくなったことをサーバが知っている場合に使用される。サーバはリソースの新しいURIを知らない。もし知っていれば、301(Permanent Redirect) を送信する。

ぜひぜひ勉強をオススメします。というわけで、よいお年を....

今年の本...というと、以前のエントリで「オブジェクト指向入門」と「JavaScript第５版」を私のオススメとしましたけども、年末になってトンデモナイ良書が出てました。

「RESTful WEBサービス」 L.Richardson ＆ Sam Ruby 　O'Reilly ジャパン／オーム社

要するにこれ、REST アーキテクチャに関する、初めての本格解説本です... ここらへんの情報というと、ネットでいろいろと知識を得て、私も自分で実装するサービスの参考にしていたのですが、そういう「ネットにある情報」に過ぎなかったものを、ちゃんとした書籍で解説しちゃっている....というものです。

今まで断片的にしか知らなかったこと、いろいろな情報を総合して役立てていたことを、本格的に１冊の本にしたもので、しかもこの「REST」の考え方自体が今後のＷｅｂサービス設計のキーワードになりそうなものですから、これ来年に「必読」マークが付きそうな本です....

お正月の勉強はこれで決まりです。

まだざっと見ただけですが、REST を「リソース指向アーキテクチャ」と正しく捉え、「RESTサービスが返す情報の形式」...XML だけではなくて、JSON や RDFa、あるいはマイクロフォーマットを選択する根拠の検討、Ajax によるクライアント設計、RESTful サービスを構築するフレームワークの紹介など、現時点での「面白いWeb技術」の集大成みたいな格好になっています！

ふう、年末にこういう本を出すのはちょい反則な気もします....（最近翻訳技術書でここまでアツくなったの久しぶりです） 多分来年、O'Reilly の「Microformats: Empowering Your Markup for Web 2.0」の翻訳が出る でしょうから、それも期待なんですけどね...

さて、前回和田英一先生の話の続きみたいなものです。

そういえば、職場の同僚が、和田先生の「Happy Hacking Keyboard」を使ってます。さすがに「無刻印トップ」じゃないですが（苦笑、でも見よこの美！）。で、ちょっとキーボード関連の話をしましょうか。この「Happy Hacking Keyboard」の発売元PFU には、歴代キーボード配置の画像があったりして凄いです。適当にそういう絵も参照しながら....

昔、実は Symbolics 社の Lisp マシンをいじる機会がありました。まあ、画像編集用に学校が購入したもので、学校中に Lisp なんか判るの私しかいませんでしたから、少しの間お守りをした....という程度のことです。

で、こういう Lisp マシンの伝統（MITの伝統）...で、

やたらと修飾キーの多いキーボード（いわゆる「宇宙飛行士用キーボード」です）！ Shift, Control だけじゃなくて、Meta,Super,Hyper,Top,Front ! （さすがに Alt はIBM系なのでないです）→参考（記憶にあるのと少し違う...）

という奴なんです。まあ、ここらへん「なぜ Emacs のキーバインドに Meta があるのか？」という大疑問は、「そりゃ Meta キーのあるキーボードがあったから」ということで答えられるわけです。ここらへんの話は井田昌之先生が bit に昔連載した「Emacs 解剖学」の「Emacs と keyboard」に詳しいです。

ありふれた入力デバイスのキーボード...でも、実はいろいろと歴史もあり、変形もあるわけで、ＰＣ限定で考えたとしても、キー配置一つとってもいろいろと「流派」があるわけです。「なんでこんな使わないキーがあるんだろう...」「なんでこんな変な配置があるんだろう」といった疑問に答えてくれるページもありました。

週刊鍵盤世界

これによると「JISキーボードと称して売っているキーボードは、ちゃんと JIS 規格に従ってない！」という驚きの結論をしています（苦笑）。「そういえば昔の IBM PC のキーボードってわけのわからないキーがたくさんあった....」というあたりも懐かしい話です（こんなのあったおぼえが...厳格にIBMのものじゃないですが）。

そういえば昔、

モニタがなくて、プリンタが直結しているキーボード

って見かけたことがあったんですが、要するにこういうのが、イマのキーボードの先祖に当たる、「テレタイプ端末」だったわけです。私が子供の頃、ＴＶドラマなんかで商社とか銀行が舞台、となると、紙テープを吐き出す「電話の凄いマシン」がありましたが、これが要するにテレックスという（昔ＦＡＸ配信みたいに情報を送信するメディア）で、これ用の端末を昔のコンピュータが流用していた、ということです。1930年代に生まれ、実はつい 2005 年まで国際テレックス網のサービスが行われていた...（勿論花形は1950年代）というわけです。

あ、今回とりとめがないですね。とりとめがないついでに、こんな話はどうです？

昔一部の端末(いわゆるPETSCII  、これ1963年のASCIIコードにあった仕様で、Commodore PET などのゲーム系マシンにも採用)で、「^」が「↑」で、「_」が「←」だったから、たとえば Pascal のポインタが「^」（@を使うのもあります）だったり、Smalltalk のリターン（戻り値指示）が「^」だったりする...というのがあったりします。上矢印に読み替えると納得でしょ。あと、Prolog とか Smalltalk で「←」をもともと言語要素に使っていて、実装では「:-」に置き換えられているケースもありますね。意外にキーボードの仕様がプログラミング言語に影響を与えていることだってあるわけですね.....（ま、話としちゃＣ言語入門者が「どうやってバックスラッシュを入力するんだ！」と悩むのと似てますが）。

まあ、そういう特殊キャラクタ使い言語の王者は APL ですね（懐かしい...）。これはもともとそれ用のタイプライタのボールヘッドを切り替えて書いていた...という話がありますね（ま、専用端末とかありましたし..）。

キーボード一つとっても実は歴史が長くて奥が深いわけです。

 というのは、日本最初のハッカーの名誉の呼称を持つ、東大名誉教授の和田栄一氏なんですね。そのインタビュー記事の感想...みたいな体裁で書きましょうか。

やはりタイトルがイイですね。ベテランの勲章のような Lisp と、それにいろいろ遊べる上に面白い PostScript....実際和田氏は「プログラムで生成した PostScript で、面白い３Ｄの絵を描く」というのをイマの趣味にされているようです。

実際、PostScript で超複雑な絵を、プログラム出力で描かせる、というのは私もしたことがあります。いわゆる「驚き盤」というタイプの（原始的な）アニメーションを実現する視覚的おもちゃ（ここらへんのアイデアは岩井俊雄氏に負う）なんです。12面絵があるので、まずシンプルなパターンをＣで座標計算とかさせて、その結果を PostScript で出力し、その結果を回転縮小配置して実際のイメージを作る...なんて遊びです。これを驚き盤にして実際に回してみると、棒がグネグネとウゴメいて気持ち悪くて気持ちいいですよ。

←拡大はクリック

実際、PostScript は画像イメージを回転・拡大縮小するのがすごく簡単ですから、ここらへん苦労なしです....なんっちゃって。

いいですか、PostScript はプログラミング言語です。ですから、個々のパターンはサブルーチンとして定義し、それを適用するための座標環境をいじって、回転・拡大縮小の効果を与えればいいわけです。ホントこれ、プログラミングなんです....実際、PostScript は FORTH にヒントを得たスタック指向言語で、「プログラムで絵を描く」を目的（プリンタ用記述言語）として開発されましたが、実際には何でも計算できるチューリング完全な言語です。ここでポイントなのは、「スタック指向言語」ということですね。ですから、計算はいわゆる「逆ポーランド記法」で記述することになります。たとえば、1 + 2 * 3 は、

1 2 3 * +

で記述されることになります（ま、ホントの表現は「1 2 3 mul add」になりますが）。

で....この逆ポーランド後置記法ですけども、慣れないと一見「ぎょ！」としますけど、慣れたらどってことないです。で、この記法には極めて大きなメリットがあるんです。それは、

言語をパースする際に、単語を切り出すだけでＯＫで、文法を解析する必要がない

ということです。たとえば、

for( i = s= 0; i <= 100; i++ ) { s += i; }

という当たり前な手続き型言語表現を解析するにはかなりの手間が必要（BNFとか使って文法定義をしてやって...）ですが、PostScript では変数 s に　0 から 100 までの和を計算して入れるのならば、

/s 0 def 0 1 100 { s add /s exch def } for

なんて感じで書けばＯＫです。特に { } には文法的な縛りのないトークンに過ぎませんから、パーサが文法を知っていて、「これfor文」と特別扱いする必要はありません。ただ単に「順に単語に分解する」だけで、パース処理が済んでしまうのです。そのトークン並びについては、いわゆる「シンタックス・エラー」は発生しないのです。後は「単語」をそのまま（仮想）スタックマシンに与えて実行させるだけです（勿論実行エラーは起きます）。

...というと、このアイデア、以前議論した「デザパタの Interpreter」に使える...と気がつきませんか？ FORTH/PostScript みたいなスタック言語で記述した「何かアプリ的な記述」を、デザパタ的Interpreter で解釈・実行する、というやり方です。メリットは「Interpreter の構成が（かなり）カンタンになる」ですけど、デメリットは当然「スタック言語に慣れている人が少ない」（苦笑）です。まあ、「スタック言語に慣れている人が使うんだよ！」というような、理想環境だったら、当然アプリ的記述言語に PostScript（風味の）言語を使う...というのもアリでしょう。

で...このケース、デザパタの重箱の隅をつつくと、「入れ子データ構造」は本質的ではなくなりますね。単純なスタック言語を想定すると、フラットなデータ構造でＯＫの場合がありえます...要するに、実装記述とデザパタの趣旨とを混同するのって、あまり良くないと思います。「Interpreterとは、汎用的な設計技法のひとつ」だと私は思います。

あと、和田先生のキーボードの話。あ、私が家で使ってるのこういうタイプ。だってテンキーとかあっても、プログラマだからブラインドタッチできるフルキーで数字入れるし、使わないと汚れて嫌だし、第一テンキーがある分場所取るし...で、コンピュータを買うとき、いつも別注してでもテンキーのないモデルを選んでます。以前は International な 101 を買っていたんですが、最近ないですね....（そういえば当初 Windows XP 日本語版でも情報探してハックして、101 使ってました....） 和田先生がんばれ！

お題です....少し「2007年はどんな年」と共通する部分があります。それは、

温故知新な雰囲気の強い年

という個人的な側面です。

私実は４０台半ばなので、青春って80年代初めなんですね。で、その頃の音楽というと、パンク～ニューウェーブでいわゆるインディーズブーム（イカ天より前の第１次）真っ盛りでした。特にハマったのって、原マスミと PHEW でした（あとは...ZELDAかなぁ）。で今年、久々に原マスミのライブが大阪であったので行ってしまいました。

原マスミ、というと「あまりにオリジナル過ぎて似たミュージシャンがいない」となりがちな人ですから、昔とスタンスがそう変わっているわけではないのですが、やはり全然古くなっていないのですね（勿論イラストレーターとか声優としての活躍があり、そっち経由で新しいファンもゲットしているようです）。まあ、目黒区美術館でのイラストの個展（「原マスミ大全集」）があって、３枚のアルバムのリイシューがあって、新しいファンだと「幻...」だったあたりも解消されたわけですが、やはりハマり直しました。

余勢を駆って購入したのがこれまた伝説の「アーントサリー」でした。さすがにコレ、イワクつきのアルバムでしたから、聞いた事なかったんですけど、見事にハマり。まあこれ、PHEW がデビューになるきっかけとなった70年代末の関西パンクバンドで「伝説のバンド」で有名なものです。

というわけで青春再燃しちゃいました。やはり音楽というのは一番時代があって、しかもいろいろと思い出や気分と結びついているものですから、確実に「（気分）年齢が若く」なりますね....

原マスミにせよ PHEW にせよ、ちゃんと現役のミュージシャンで今も活躍していて、しかも「オリジナリティのメチャ高い人だから、古びない」というのは元気づけられることです。来年はいろいろライブに行こう～～（ま、今回コンピュータ＆プログラミングとは関係がないですが、お題ですし。ちなみにハッカーズ大辞典music によると「ハッカーは概して音楽を好み、一風変わった面白い傾向の音楽を鑑賞することが多い」。）

最近ではけっこう80年代頭の「東京ロッカーズ」あたりからの貴重音源がよくＣＤ化されているみたいですね。やはり音楽業界も細分化されちゃって、こういう「今じゃ聞けないよね～～」というタイプの「ポップの極北に挑んだ」時代の音楽が、歴史的価値云々を超えて受け入れられて....だといいんだけどねぇ。やはりここらへんの音楽が、日本の（インディーズな）ロックの源流になっている、というのはポイントじゃないかしら。

年末進行です....ちょっとこの大ネタについて考えてみましょう。

「進歩の年」じゃないですね、どっちかいうと。全体的な傾向としては、

既存技術の見直しが進んで、温故知新な雰囲気の強い年

というイメージです。今までの流れから、Ajax をきっかけとした JavaScript の復権があって、その流れの中で「モダンなスタイルの JavaScript（ライブラリ）」の認知が進み、それが一般的に使われるようになってきた。たとえば JSON によるAjax のやり取りとか、「フツーのテクニック」になっちゃった...というような感覚？

あと、マイクロフォーマットかなぁ。これだって既存の HTML を（視点を変えて）活用しよう、というノリのものですし。カッコイイ言い方をすれば「マッシュアップの年」なのかもしれません。

この理由としては、やはり雑誌メディアの衰退、という現象が実は強く作用している気もします....何やかんや言って、雑誌は売れるために「イマこれが最先端だ！」と読者をアオる、という機能を果たしていたわけだけども、雑誌に代わるネットのオピニオンリーダーというと、別に「読者をアオる」ことを目的とするわけではないので、「現実的にちゃんと使えて、楽ができる」というあたりに存在意義ができてしまうような気もします。「先端」というものの全体的な意義が薄らいできたような印象です。

まあ、それが「成熟」というものなのかもしれませんが....

としてみると、たとえば「Javaスクールの危険」みたいな記事がもてはやされる、という状況を考えると、やはり

きっちりとコンピュータ科学の素養を備えて、ロジックに強いプログラマ

というのが、いつの時代にも最終的な「リアル・プログラマ」である、という当たり前な事実が改めて強調された年なのかもしれませんね（個人的には Lisp/Scheme/Haskell あたりが再注目されるとスゴクうれしいですけど）。

あと Java に関しては、今までの「オープンソースプロジェクトの総本山Apache=Jakarta」という一人勝ち状況が崩れて、他のオープンソースプロジェクト・コミュニティのプレゼンスも増した年...という感覚もあります。Google Code とか、あるいは老舗の Codehaus とか。「Google Guice を使って...」とか実績が出るとさらに面白くなるのでは、とは思いますね。

雑誌の衰退と同時に、書籍もあまりイイものはない感じです。個人的にはやはりメイヤーの「オブジェクト指向入門第２版」が神です。これだってホントは「今更な翻訳（原著1997年刊行）」のわけですし、あるいはフラナガンの「JavaScript第５版」にしても、名著第３版のアップトゥデイトの翻訳ですから、「新しい風が吹いた」というようなものではまったくありません。

 まあ、地道に足元を固めた年...という感じでもありますけど、着実に多元化が進んでいるようにも思います。

あ、もう少しプログラミング、に直接かかわらないレベルだと、
調べ物が何でもかんでも Wikipedia になっちゃった年
で記憶されるのかなぁ....

私はプログラマですから、デザインパターンと聞くと「GoFで示された、OOPで再利用可能性を念頭において作られた、『OOPの技』を集めてパターン化したもの」とついつい答えてしまうのですが、勿論これ、狭すぎの回答です（苦笑）。

もともと、GoFのデザインパターンだって、「建築のデザインパターン」にヒントを受けて作られたものですから、「どんなものにだって、それ用の『デザインパターン』がある」と言っても過言ではないでしょう。

中には「Webデザインのデザインパターン」（要するに視覚的＆ＵＩデザインのカタログです）というものを集めたサイトもあります。ひょっとしたらデザイナさんには有名なのかなぁ....

まあ、GoF以降のソフトウェア・エンジニアリング、というとやはり GoF があまりに必読だったために、「デザインパターン的発想」を取り入れたもの、というのは山ほどあるわけです。見方を変えれば「XP のプラクティス」だって立派に『デザインパターン』と言えるでしょう。こういう開発工程のデザインパターンとして、EPISODES（ウォード・カニンガム PLoPD#2：邦訳あり。XPに影響あり）のようにまとめたものもあったりするわけです。さらには、「デザインパターン自体のデザインパターン」（メタ・パターンですね...）だってあります（G.Meszaros＆J.Doble : A Pattern Lauguage for Pattern Writing. PLoPD#3所収）。デザインパターンはホントに「どこにでも」あるわけです。

で、もっと細かいフォーマットについての「デザインパターン」というものもあります。え、「細かいフォーマット」？ そうです、マイクロフォーマットのデザインパターンなんですね。マイクロフォーマット自体最近のものなので、ここの Wiki なんてもう「デザインパターンありき」の作り方をしちゃっているわけです.....最初から「使いやすいパターンがあったら、デザインパターンとして公開して、共有しよう！」というノリのわけです。また、「デザインパターン」として公開することでそれが、新しいマイクロフォーマットの「スタイルについてのガイドライン」の役割を果たすことを期待してもいるわけです。

ですから、デザインパターンとは、あらゆる人間の営為について、

1. 1. 繰り返し現れる問題とその解決策を、
2. 2. 定義と名称を持った「パターン」として捉え、
3. 3. それを同じことに従事する人々の間の共通語彙として共有しよう

という考え方自体にある....というのが「哲学的に」正しいデザインパターンの捉え方、ということになるのでしょうか。こういう「考え方」が「パターンマインド」というものなのですね。

人間到る処デザパタ有り

なんて格言がそのうち生まれるかも....

あ、これデザパタの Interpreter の話です。

以前のエントリで、「Excel シートのヘッダを作るのに、HTMLで書いた記述を使ってこれから colspan や rowspan だらけ（Excel = POI 側から見れば region だらけ）のヘッダを作るといい」って記事を書きましたけど、うまくいきました。

それほど大した手間じゃないのですが、書いたクラス自体は全体的なフレームワークをさらに使うものなので、特に公開とかはしないことにします。ごめんなさい。皆さんも独自に書いてみるといいですよ。

で、これデザパタ的に考えてみると、やはり一種の「Interpreter」（リンクは説明の悪例です）だろうね、ということになるわけです。ホントはツリー構造云々が重要なのではなくて、「より判りやすくメンテしやすい表現形式から、実際に使うデータ形式に変換する」というのがキモのわけですから。

よく利用局面として挙げられているのは、たとえばややこしい検索条件とかを表現するのに、

判りやすくメンテしやすい（独自な）言語を作って、その上でメンテするけども、実際に使うシーンでは、それを Interpreter が解釈して、実際の動作をさせる

という意味でしょう。ですから、

ややこしい（見栄え優先の） Excel ヘッダ定義を作るのに、そのひな型をメンテしやすい HTML（のtable）で書いておき、それを専用のパーサがPOI を使って Excel 出力に直す

というのは、まさに Interpreter の動作である...という風にも思えるわけです。

しかし、ネット上で Interpreter の説明をいろいろと参照してみると、なかなかツボを押さえたものがありません。GoFの例として挙げられた「数式を BNF を使って木構造に直し、解釈実行する」を何かそのまま書いてあるだけ...というものがほとんどです。

そんな中で、この はっぴぃ氏の「デザインパターンを読み解く」が一番まともだったように思います。たとえば、このページでは、GoFの23のパターンを独自に

上位コンセプト（あまりに用途が具体的過ぎる）

Strategy, Command, State, Intepreter

上位コンセプト（クラス構成の方法であって、テクニックではない）

FactoryMethod, AbstractFactory, Builder, Proxy, Facade, Memonto, Prototype, TemplateMethod,Mediator,Observer,Bridge

テクニック（役立つものもあるが、あまり使わないものもある）

Singleton,FlyWeight,Adaptor,Composite,Iterator,Visitor,Decorator,ChainOfResponsibility

の３カテゴリに分類し、そのうち最後の「テクニック」だけが「（デザパタとして）特徴的である」、としています。で、このページでの Interpreter の説明は、

Interpreterは、何らかのフォーマットで書かれたファイルの中身を解析した結果に適用するパターンです。解析する方法ではなく、解析した結果を利用する （！まさにこれが重要！）パターンです。
そのフォーマットとは、htmlやxml、プロパティファイルのような静的なものもあれば、ソースファイルのように処理手順を記述したものもあります（！何でもいいんだよ！）。SQL、シェル、バッチ、マクロ、XSLT等もあります。通常、パースという操作で、文法規則（！今回はXHTML！）にのっとって解析が行なわれ、解析結果はツリー構造のオブジェクトとして保存されます。全体は部分から構成され、部分はさらに小さな部分から構成されます（！HTMLのtableだってそうじゃん！）。

ネット上のデザパタ解説ページでは、かなり Interpreter ってちゃんと扱われない（大概の解説者の手に余る...）パターンの代表じゃないかしら。溜まってた不満がこのページで一気に解消されたました。

たしかに、GoF が「23のパターン」というかたちでまとめてしまったことの功罪みたいなもの...というのもあるようにも思います。極論すれば、

Emacs を作るのに、R.M.Stallman が「ファイル編集を行う命令プリミティブセット」と、それを運用するための elisp インタプリタを作ったのは、Interpreter じゃないのか！？（勿論、Emacs はOOP言語で書かれているわけじゃないです。苦笑）

と昔から私が感じていた疑問、というのも、この「GoFの23のパターン」で扱われているパターンの「レベル」がバラバラ....ということに起因しているわけです。

要するに、「デザパタというもの」を何か固定的に捉えがち、ということ自体が、実際に「デザパタを使いこなす」ための一番の障害になっているように感じますね。

付録： ExcelDesigner の仕様

HTMLのテーブルとして書かれたヘッダ構造を、Excel を生成するための内部データに変換して保持する。ExcelDesigner 同士の連結、生成した後でのテキスト置換などをサポートしている。

可能なtable定義。

td タグの中に書ける属性は、

colspan="数値"

列を連結する。

rowspan="数値"

行を連結する。

width="数値"

カラム幅を指定する。単位は pixel（から計算して適切なExcelのカラム幅値として適用する）。

align="left|center|right"

文字のアラインメントを指定する。

class="表示クラス"

そのセルについて、任意の HSSFCellStyle を適用するために、この属性で指示される「表示クラス」を、リフレクションによって参照する。参照されるゲッタメソッドは、HSSFCellStyle を返さなくてはならない。

結構実用性高いでしょ！

今の仕事が検証プロセスに入ったので、スタンバイしていないとダメですが、特に忙しくはないので、いろいろと見ていた中で拾ったネタです。

POSH = plain-old-semantic-html

の略号です。要するに HTML(XHTML)の書き方で、「厳格に意味的なタグだけを使ったスタイル」のことを示します。「表現的なタグの使い方」は一切ダメです。つまり、次の使い方は HTML(XHTML)規格がＯＫにしていようとも、POSH ではありません。

1. 1. BR で段落を作る。
2. 2. レイアウトのために TABLE タグで配置を行う（勿論、「表」を表現するための TABLE タグはＯＫです）。あるいは幅寄せ目的で BLOCKQUOTE を使う（勿論引用テキストで使うのはＯＫです）。
3. 3. 間隔をキープするために、透明画像のスペーサーを使う。
4. 4.物理表現タグ（FONT, B など）や物理表現属性（width とか align とか）を使っている（CSSで書け！という意味です）。

「よくぞこんなにカッコイイ名前を付けてくれた！」と個人的には思います。実際「こういうのがホントは良いセマンティックなスタイルだ！」とは思っていても、「それ」と指す「いい言い方を考える」というところまで、私も頭が回っていたわけではないです....

まあ、実際には、この POSH という概念は、マイクロフォーマットを実現するために、「そのベースとなるHTMLの書き方を見直そう」という流れで、「厳格にセマンティックなHTMLを！」ということで出てきたもののようです。そういえば、マイクロフォーマット関連の書籍翻訳が出る...というようなことも書かれていましたね。多分その本が出たあたりで、意外にこの POSH という言い方も広まるかも....

POSHのロゴ。かわいい！ 何か乙女ですね。

ちなみに英語の posh の意味は、「スマートな, 優雅な; ((副詞的)) スマートに; 豪勢な, 高級な; 流行の」（goo辞書より）とすごくイイ意味ですね....

クイズです。ジャイアントロボの鳴き声は？

答えは「」です（勿論ジョークですよ！）

このネタは前回の坂村健教授話の続きみたいなものです。そういえば昔、私も自分のマシンに TRON 入れたおぼえがあります。確か「1BV3体験版」じゃなかったかな。30日の利用期限があって、そのままになっちゃった....のは残念ですが、何か印象が良かったわけです。

でまあ、「イマのTRONってどうなってるの？」ということを少し調べてみました。今は例の「仮想化技術」を使って、Windows の上で動く「超漢字V」という版が発売されています。ですから、パソコンＯＳとしての BTRON も（残念なことに細々...ですが）続いているわけです。勿論、組み込み用途の ITRON は見えにくいところで結構使われていることはいうまでもありません。

BTRON（超漢字）というと、「とにかくどんな漢字でも使える（そりゃ日本産だから）」がウリのＯＳでした。お寿司屋さんであるような魚偏の漢字を集めたデモなんて懐かしいですね！ 勿論そのための「文字コード」として、いわゆる「TRONコード」というものがあるわけです。これは最初から char == 32bit で作られているわけで、最大 150万文字を収録できてしまう...というトンデモないものです。現状でも使っているのはたかが 18万文字程度ですから、Unicode でさえ問題にならないくらいに「余裕....」な文字コード体系のわけです。

ですから、実際に文字の収録を行う、TRON文字収録センターを訪れると、この TRONコードの一覧ができるわけです（ま、実際全部一覧しようとするのは無茶というものですが...）。その中に、あるんですね、「ありえない濁点付きカタカナ」。ですから、BTRONの上では、ジャイアントロボだってちゃんと「鳴ける」ことになるわけです（苦笑）。ちなみに文字コードは９面Ｂゾーン 804e になります。

ちなみに Wikipeida の BTRON の項では、よく言われる BTRON とアメリカの圧力の話での「坂村教授悲劇の英雄論」について懐疑的なことを書いています。まあ、確かに体験版を使った記憶（1996年くらい）でも「ベースは良くてもおもちゃっぽいかなぁ...」というのも感覚的にありますよね.....

さすがに坂村健教授、いいこと書きます、と思ったのは、昨日の毎日新聞のコラムです。タイトルは「イノベーション」で見出しは「やり方変える勇気を」というものです（12/16朝刊２面）。

このコラムでは、フランス最北部のリールという町で、坂村教授が見たスーパーのレジ端末の話を紹介しています。まあ、最近「セルフレジ」を見かけますが（一番良く私が使うスーパーにもあります）、それの「おおざっぱ」なバージョンみたいなものです。

それが初年度より黒字の大成功という。秘訣は従業員２０人という徹底した省力化にある。中でも貢献しているのが、お客を信じ店の運営に参加してもらうという基本コンセプト。（中略）商品ラベルのバーコードで商品種はスキャンするが個数は客が入力。賞味期限ぎりぎりの割引シールのあるなしも客が入力。さらに、支払いは銀行カードのみで、レシートはメールで送るのみで紙はない。

....え、こんなん大丈夫？となるのが日本人の「常識」というものですが、それで立派に稼動しているものだそうです。「不正な入力は0.5％。ごまかしだけではなく間違いもあるし、売れ残りやキズなど自然損失の方が多いのでこれも無視」と大胆に割り切って、その結果「何よりここまで客を信用すると、客はほめられた気になって裏切らないという」そうです（苦笑）。

このシステムのお値段ですが....要するに完全自作で１台数１０万円程度に抑えちゃっているわけです....施設にかかる初期費用が極めて安く済むのなら、こういう黒字もアリですね。

日本人って独特の完璧主義があるため、見た目の綺麗さに妙にこだわりすぎます。しかし、「ハック」という言葉の語源も「斧でやる大雑把な器用仕事」というような意味がもともとあったわけです。もちろんそれで出来たもの、は綺麗というよりも不恰好、でも目的はきっちり果たす....というようなものです。このレジシステムも、そういう意味でもしっかりと「ハック」のわけです。

今の仕事で、CSV をパースする必要が出てきました。とはいえ、

1. 1. ダブルクォーテーションで囲ってあるかどうか不問
2. 2. 区切り文字はタブかコンマかどっちでも可
3. 3. 複数行が入っているかもしれない（その場合クォートしてある）
4. 4. 文字列に入っているダブルクォーテーションとコンマが正しく解釈されるべき

....という一番キッツイ仕様です。既存コードはホントわけわからない、何回も正規表現検索・置換を繰り返すメンテ不能なコードでした....

要するに CSVって、正規表現で扱いづらい文法（というか、クォーテーションで「内部特殊文字無効」にするタイプの文法）なんですよね。そういう時、これは逆に、自前で「有限状態機械」を書いた方がずっと見通しがよくなるわけです。

まあ、昔「有限状態機械」は結構書き倒した経験もありますから、それで書いちゃいました。java.io.PushbackReader に感謝です。

けど、最近のプログラマは正規表現に慣れ過ぎている...というような気が私はしないでもないですね。正規表現はそりゃ高速にマッチングや置換をやってくれる大変便利なものですが、それでも「初期コスト」はそれなりにかかります。勿論ターゲットとなるテキストが巨大になれば、初期コストは微々たるものですが、「短い文字列の検索・置換のために、何回も動的に正規表現を作り直す」というやり方は、さすがに不効率だと思います....気にしてないプログラマ多いですね。

まあ、正規表現をコンパイルして、要するに有限状態機械を作っているわけですから、「有限状態機械の手書き」が正規表現に速度的に負けるわけがないです。そう考えると、「有限状態機械を書く」といのもまだまだレトロとは言えないのでは...と実感です。

そりゃその通りのタイトルです（苦笑）。というのも Poor Obfuscation Implementation（不十分で曖昧な実装）という名前と、そのバージョンに関して少しハマった話です。

...まあ、Poor Obfuscation Implementation というよりも、これ「Apache POI」、 Excel などを操作する Jakarta 製ライブラリの名前、という風に言った方が通りはいいですね。今のプロジェクトで使っていたバージョンが、2004 年にビルドされた 2.5 だったことにまず問題がありました。一度導入してしまうと、「ライブラリをバージョンアップして挙動が変わってないか、きっちりチェックしなくてはいけない...」ということもあって、バージョンアップしてなかったんです。

POI の場合、エクセル計算式をセルに追加する機能が、結構最近のバージョンでサポートされることになった、という事情もあって、実は 2.5 の計算式には重大な制限があって、あまり使い物にならないものだったのです。まあ、それは仕方がないです。で、ちょっと別な問題が出たので、「？？」となった私は、「これやっぱりバージョン問題？」と誤った結論に飛びついちゃったのです。

...ほんとこれ、慙愧です。ごめんなさい！ってところなのですが、責任転嫁しちゃうと、やはり「ライブラリで不出来なところがあると、全体の信用がなくなって、余計な迷路に入ることがある...『信用』:って大事！」ということです。「貧弱」と謳ってるライブラリですけど、その「貧弱さ」はMSのドキュメンテーションの貧弱さに起因するものです.....ふう。世の中うまくいかないや。

さて、今ちょっと独立したブロックの仕事を始めてしまったことで、更新が滞っていました。ごめんなさい。

とはいえ、今日のネタはそういうことから考えたことです。

新しい機能の追加ですから、既存のコードによる制約がほとんどない話です。ですから、新しい機能の部分の内部設計は自分の好きなように作れてしまいます。そういうときに、私が「これ、自分の特徴だよね」と改めて感じたことがあったんです。それは、

新しいクラスを作るときに、とにかくその呼ばれる側で、「どういうインターフェイスだったら便利なんだろう？」ということだけで、新しいクラスのインターフェイスを作っちゃう。

....まあ、これ、正しくＯＯＰ的なんでしょうね。ですから、とりあえずインターフェイスの輪郭が出来れば、クラスの輪郭も浮かび上がってくる....という発想になってきます。そう考えれば、インターフェイスで隠される実装というのは、大したことではない（極論）ということにもなるのかもしれません。

今やっているのは、Jararta POI を使ったエクセル帳票出力ですが、「こんなのが欲しい！」というだけで、こういうオブジェクトを作ったりしました。

1. 特に中計・総計とか配慮しなくても、個別データを注入するだけで自動的に中計・総計が計算されるデータ構造（Composite を少しヒネってます）

2. HSSFCellStyle を、「今持っているスタイルを少し加工して...」というように、継承オブジェクト風に扱って、しかも余計なインスタンスを生成しないスタイル・マネージャ（Prototypeかなぁ）。

.... で作ろうか？と思っているものとして、

3. 帳票ヘッダ部分を、HTML のテーブルで形式を記述すると、それを変換して Excel のヘッダを生成する HeaderDesigner。

やはり、「ねえねえ、こんなんイイでしょ！」と思えるような内部設計をするというのは、仕事の中で一番楽しいことでもありますよねぇ。