-Seasarのすなあそび

oss mayaa

http://d.hatena.ne.jp/habuakihiro/20050624#1119540291
羽生さんからアナウンスされましたが、7月16日（土）に「Seasarのすなあそび」と題し、Sandbox祭りを。なにを隠そう、MayaもSandboxプロジェクトなんですよ、驚いた？。。。驚かないか。祭りにマイルストーンあわせていきます。
今回のテーマは、与えられた時間内でプレゼンを終えることです。

-インジェクションのバグ修正

mayaa

.mayaファイル上にネストしたインジェクション記述を行った場合に、挙動の安定しないところがあったのですが、一通りデバッグしました。また、HTMLテンプレートをコンポーネント化したときに処理メソッドでTag.SKIP_BODYを返すべきところ、Tag.EVAL_BODY_INCLUDEを返していたところがあり、テンプレート上のタグボディの出力制御がうまくなくなっていたバグを修正。
0.9.5から0.9.6にかけての大幅な実装変更の後遺症は手当てできたかな？次の0.9.7ではひろくみなさんに見てもらいたい（見てもらっても時間のムダにならないぐらいにはなる）かと思います（といいな）。

-3層以上深いところのID

mayaa

http://d.hatena.ne.jp/dekodeko/20050607
すいません、見逃してました。実際にパッチまで作っていただいています。ありがとうございます。このパッチのポイントは、

 - String xpathExpr = "/m:maya/*[@m:id='" + id + "']"; 
 + String xpathExpr = "/m:maya//*[@m:id='" + id + "']";

上記のように、XPath式が2層目のみのm:idを見に行ってたところを3層目以上深いところのm:idも探しに行くようにしていることです。この副作用としてネスト状態のそれぞれのm:id付加エレメントが重複出力されるのを避けるためネストの子にm:idが見つかったときはその下を捨ててインジェクションツリーを作ることです。
これは悩ましい。私の実装時に脊髄反射的にこの重複出力を嫌ったのと、再帰的にXPath検索がかからないように2層目のみにm:id（および別のレゾルバではm:xpathなど）を記述できるようにしましたが、n層でm:idがかけてよいように「も」思います。しかし、決め手がない。アプリケーションを記述する際にどちらが直感的で、どちらが柔軟なのかですね。まずはこのアイディアを取り込んでみたいと思います（0.9.7にて）。特別ネガティブな要因がその後に出ない限り、n層OKで。引数にわたってくる実装クラスがSpecificationNodeImplとは限らないのと、このn層概念はm:idに限らず、m:xpathでも同じですし、さらにはユーザーがInjectionResolverを実装する場合に同じ問題に直面する可能性はありますので、copyTo(SpecificaitonNode, boolean)の機能はAPIレベルで対応してしまおうと思います。
追記
ということで、実装しました。API的にはどうかなぁ（org.seasar.maya.engine.specification.CopyToFilter）。ま、様子見で。

-m:remove

mayaa

その昔、JSTLのifがあるからいらん、と廃止したm:removeですが、新たな必要性が出てきました。プロセッサとしての処理まで持ってこない方法でテンプレートのタグを削る機能が、ネストするノードの機能に対応するものとして必要に感じています。
アダプターでなく、エンジン仕様に組み込んでしまわないとできない機能はなるべく増やさないのがよいと思うので、ちょっと考える時間を持ちます。先のn層OKの機能は、InjectionResolverの実装なので、ユーザーアプリケーションで差し替え可能なのですが、こちらはどこで実装するか。。。同じくInjectionResolverでやるのであれば気楽に、エンジン内部であれば慎重に。
やるとしたら、昔のようなm:removeプロセッサでなく、m:remove属性かと思います。m:rendered属性と同様の作りです。

-手数料収入

other

http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20050616/162863/
IT業界の会計基準を見直そうという動きですが、興味深いのは記事の図中にある、取り扱い高と手数料収入の区別がない、という点です。ゼネコン的もしくは荘園制度のような丸投げ大手SIerは、売上高がいきなり2分の1とか5分の1とかになっちゃうところもあるかも。伝票とおしてるだけの案件は、サヤだけが売上計上。。。ちょっとこの記事だけでは意味するところは確かではありませんが。
弊社は、ほぼ100%内製でやってるのと、派遣（実態・形態の別を問わず）は一切してないので、この記事で関係あるのは口約束でうんぬんかんぬん系の問題だけです。これはたしかに監査の前に注意された（笑。結果、書類を整えるよう、お客さんにお願いして回ってました。

-懇談会

mayaa

さて、先ほどまで未踏のプレキックオフ的な懇談会で千葉先生や千葉PM傘下のプロジェクトの方々とお話してきました。夜仕事が昼仕事になったのもうれしいし、なにか世間に認められた（まだはじまったばかりですが）ようなこともうれしいが、今日の出会いは久々にエキサイティングでした。Javassistのこぼれ話もありましたし。
同期は、Java2件、Ruby2件。いや、マジにすごいよみんな。まいったな。かなりがんばらないと。。。自分を棚にあげて好きほうだいにいうだけだと、笹田さんの取り組むRubyのAOTコンパイラ・VM環境というのはプログラマ冥利に尽きるネタだなと思います。世の中、なかなか自分が真剣に取り組むべきテーマというのにはめぐり合えないわけですよ。かつ、それで成果が出せるとなると本当に運の世界です。私もいろいろこまごまやってきましたが、開発テーマとしてここまでのものはそうない、と笹田さんのそれには思うところありました。おそらく成功するとしないとでは、たぶん彼の人生は大きく天と地ほども違うことになるでしょう。
BioRubyは文系の私には理解できないのが残念なのですが、どうやらアカデミックではすごい価値があるみたいです。また、西岡さんらのユーザーWEB開発フレームワーク/エンジンは成功すると一番ユーザー基盤が作れそうなテーマだと思います。そんな中、Mayaの長所は。。。無難なところですかね？成功の果実の大きさはともかく、確率は高いと思います。そんな感じ（笑。