|
[最近のツッコミ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [全文検索] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ☆基本的に個人的なリンク集、偶に思い出したように文章を綴る日記。 ☆JAVA・Ruby・RELAX NGネタ中心です。O:原文,P:ポップアップ辞書,t:和訳 ☆[category]:カテゴリフィルタ画面 ☆[blogger]:Blogger出張所。徒然。 ☆[kuro]:個人的ライブラリ開発プロジェクト「Kuro Project」サイト。 ☆[kuro-pj]Kuro Project開発日誌。 ☆[ruby]Ruby学習日誌。 ☆[vox]:VOX出張所。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
JSFのUIコンポーネントと(X)HTMLのUIタグのマッピングにおける相性の悪さは明白。
FaceletはXHTMLのみサポート(XML名前空間併用)するテンプレートを採用することでJSP独自
仕様をビューファイルから追い出している、独自のコンポーネント定義機能を持つため、
新しくUIコンポーネントをタグライブラリとして作成する必要もない。
デザインとロジックの分離という観点からみるとベストとはいえないが現行のJSPよりはベター。
パフォーマンスに難がある模様、その点が改善されればJSP後継ビュー技術の本命になるかも。
Faceletのテンプレート機能はjsfcという独自属性を付加することでJSFのUIコンポーネント
とXHTMLのUIタグのマッピングを実現しているもののUIコンポーネントとXHTMLのUIタグの
属性が1対1のマッピングとなるため、XHTMLのUIタグに存在しない属性がテンプレートに
含まれることになり、あまりスマートとはいえない。
Faceletの(X)HTMLテンプレートへのアプローチは表面上デザインとロジックの分離を
実現しているように見えるものの本質的には解決になっていない。
JSFとの整合性を第一に考えるなら、Faceletのようなアプローチではなく、UIコンポーネント
自体の作成を現行のJSPベースから(X)HTMLテンプレートを採用したテンプレートエンジンベースに
差し替えるアプローチのほうがベターではないかと思う。但しこのアプローチでは軽量かつ高速な
テンプレートエンジンが必須。
WebWork2ではこれと類似のアプローチを採用し、UIタグライブラリへのVelocity組込で
UIタグの拡張を容易にしている。
YARVが1.9.1に入るのはほぼ確実の模様。
JavaのClassファイルに当たる仕組みをRuby1.9.1で簡単に使えるようにしてもらいたい。
ソースファイルを隠すという側面もあるがあらかじめ中間コードにコンパイルしておくことで
実行時における中間コードへの変換処理がいらなくなり、実行速度がその分だけ速くなる
と思うので。
[抜粋]
Q4 (青木さん)
コード隠したい人に対して対応は?
A4 (ささださん)
Java でいう class ファイルみたいものにする仕組みは、すでにある。しかし、それを簡単に使えるようにするのは priority の低い話。誰かに頼まれればやるけど。
----
Q1 Ruby on Rails の中の ActiveSupport の機能のいくつかを吟味して標準に取り入れて欲しい。
A1 (まつもとさん)
(それらの機能が) 悪いとは言わないが、だからといって汎用言語にこれはどうか、というものもあり。こちらからこう変えろと口出しはしない。小出しに要望 (RCR) にしてもらって、ひとつずつ議論していくのがよい。どれが欲しいかどんどん教えて欲しい。
Q5 (永井さん)
今後、拡張ライブラリが YARV の上で動くようになると思うが、C で拡張ライブラリを書く場合に、どのようなところに注意したらよいか?
A5 (ささださん)
現在の C API はほとんど使えるようになっている。ごく一部、使えなくなった API があったり、より効率の良い新しい API が提供されたりしている。
1).本当に有用かどうかは抜きにして新しいモノ好きで直にそれを使いたがる。
2).複雑なロジックを組み立てその複雑さを隠蔽しないことで、そのロジックを組むことの
できる自分をアピールし、一種の自己陶酔に浸る。
3).新しい言語仕様に眼がなく、それを使ったライブラリを直に作りたがる。
1については自分に当て嵌まる気もするので、自戒せねば。
2については当てはまらない。ライブラリ設計において複雑なロジックは隠蔽し外には水面を優雅に
滑るように泳ぐ白鳥のように見せることが大事だと思う。
3についても当て嵌まらない。新しい言語仕様を使うライブラリを作るなら、言語仕様の理解上の
難易度を設定し、難易度の高い仕様を使うロジックは極力隠蔽すべきだと思う。
なるべく、作成するライブラリの外部インターフェースには言語の新規仕様を織り込まない。
こうすることで作成したライブラリの外部インターフェイスは言語の特定のバージョンに依存せず、
中身を作り込むことで互換性を維持できる。
この特許は有効なら、どの言語のORマッパにでも適用できる。この特許の有効性がまず第一の焦点...
先行発明が確実にあるだろうな。こんな特許を通す特許認定期間ってどうよ?
RedHat、Oracle、IBM等の協力タッグで返り討ちが関の山。
EJB3はHibernateからの派生、Hibernateの特許侵害で訴えた時点でJCPに加入する大企業全てを
敵に回したも同然。
/* from InfoQ(on off) and TSS(on off) */
Richard Monson-Haefel氏のブログによると先行実装(Next(Steve Jobs氏が率いNeXTSTEP・
OPENSTEPを産み出し、後にAppleに買収された)による実装、WebObjectsの一部EOFの前身)
があり、特許は無効とのこと(on off)。
RedHatを組し易しとみて金銭奪取に動いた単なる特許ゴロ...。
GoogleのページランクではSpringが頭一つほど勝ってます By Googleツールバー。
Googleからの来訪数はユニークビジター数ではないのでそれを宣伝するのはあまり...。
Googleでのヒット数はユニークユーザ数とは必ずしも関係しないので宣伝するのはあまり...。
後発がどんなに頑張ろうと、デファクト化した先発にはまず勝てません。
WebWorkがStrutsより優れていたにも関わらず、Strutsには勝てず、結局Strutsの
サブプロジェクトに吸収されてしまったという前例もあります。
逆転するには他の追随を許さない圧倒的なブレイクスルーが必要です。
Springは熱い議論が場外乱闘よろしく各所のブログ等で繰り広げられていて、そこに著名エンジニア
が顔を出して論戦を展開し、盛り上げています。良いアイデアは吸収していこうという雰囲気を感じます、
このことでコミュニティが活性化しているようにも思います。
実際にSpringを利用した外部OSSプロジェクトの数は多く、ASFのプロダクトにもあります。
Springにはボトムアップをしていこうという姿勢をなんとなく感じます。
Seasarについてはメイン開発者と数人のハイレベルエンジニア?によるトップダウンという
姿勢を感じます、メイン開発者と数人のハイレベルエンジニア?が幹を決め、それに従って
他のエンジニアが動いているという印象を受けます。
あと、両コミュニティの外部OSSコミュニティとの連携もあります。
Springコミュニティは積極的に外部OSSコミュニティとの連携を行い、Spring関連機能のコントリビュート
も積極的に行っているようにみえます。Seasarコミュニティはそのオールインワンの姿勢が
表すように、自分たちの仲間内だけで閉じているようにみえます。悪く言えば、Seasarコミュニティは
既存のOSSプロダクトからアイデアやそこに使われている実装手法を真似るだけ真似てお返しは
していないようにみえるともいえます。
開発コミュニティに関しても人間関係と同じで"Give&Takeが基本"だと思います。
外部OSSコミュニティと積極的に連携する場合に発生するデメリットがそのメリットを上回っている
と思っているのでしょうか?個人的にはそのメリットはデメリットを遥かに上回ると思うのですが...。
#Satoさんのツッコミへの返答
#Struts Action Framework2.0は Struts1.X系への互換レイヤでWebWorkを包んでいるように思います
#(間違った認識かもしれません)、ある意味ではWebWorkの勝利ですが、ブランドとしては敗北ではないかと...。
#ひがさんのツッコミへの返答
#私個人の外側から見た見解(感想)です、別に冒涜しているつもりはありません。断定口調はニュアンスが
#違うので、修正しました。断定口調で書いてしまったことはお詫び致します。
#十分に推敲してから文章を書いているわけではないので、ご容赦下さい。
#羽生章洋さんのツッコミへの返答
#この文章はあくまで私一個人の感想にすぎないんですが...。
#少なくともSeasar2に関しては先行DIコンテナの"DIコンテナ"というアイデアの猿真似を
#していると悪くいえばいえます、Springについても同様ですが。Springについては他OSS
#開発コミュニティに対してそれを補うだけのお返しをしていっているようにみえます。
#ひがさんのツッコミ2への返答
#"盗む"を"真似る"と同じ意味で使っていました。"盗む"というのは悪い印象を与える言葉なので訂正します。
#"盗む"という言葉を安易に使ってしまったことをお詫び致します。
#「盗む」、「真似る」="Takeのみしている"ということです。Take(頂戴)した以上、お返しをする
#(Giveする)必要があると個人的には思っています、それがOSSコミュニティであったとしても。
#Takeして作ったプロダクトをOSSで公開したからといってそれがGiveしていることにはならない
#というのが私の個人的な見解です。
#ひがさんのツッコミ3への返答
#同一コミュニティ内でのことは問題にはしていません。
#開発コミュニティ間を想定しています。Take(頂戴)したなら、倍返しくらいではじめて
#お返し(Give)したことになると思います。OSSなんだからソースを読んで真似たいなら
#どうぞでは...。
#ひがさんのツッコミ4への返答
#この文章でのSeasarコミュニティはSeasarプロダクトの開発コミュニティ全体を指しています。
#他のOSSコミュニティのほとんどがTake(頂戴)しているだけだから、自分たちもそれでいいと
#いうのは余りにも...。
#Take(頂戴)した以上、何らかのお返しを他の開発コミュニティに対してするべきだと思います。
#それが必ずしも直接Take(頂戴)したOSSコミュニティである必要はなく、他のOSSコミュニティ
#にお返し(Give)しても構わないとは思います。
#Take(頂戴)したのがお返し(Give)したのよりずっと多いのではアレですが...。
#Springコミュニティに対してお返し(Give)するとすれば、問題点の指摘と解決策の提案でしょうね、
#「Springのココが駄目だから、Seasar2だよ」というのでは...、
#「お返し」=「貢献」と判断してもらっても構いません。
#koichikさんのツッコミへの返答
#「〜コミュニティ」がユーザを含んでいる点でニュアンスが異なっていたので「〜コミュニティ」1
#を「〜開発コミュニティ」に訂正します。ひとまず読み換えて下さい。
#Seasar開発コミュニティにSeasar関連の外部開発コミュニティが合流したことは双方に
#メリットがあり、GiveとTakeが相殺されていて、外部開発コミュニティへのお返しには
#あたらないと思っています。
#RELAX NGの作者である村田真氏はXMLスキーマ言語の専門家です、W3C XML Schemaの
#現行仕様の勧告化前にその問題点を指摘し勧告化を阻止しようと動いていた人物の一人だと
#思います(間接的にかもしれませんが...)。RELAX NGの前身であるRELAXはW3C XML Schemaの
#勧告前に公開されています。もう一つの前身であるTREXの作者であるJames Clark氏も
#XMLスキーマ言語の専門家であり、村田真氏と同様にW3C XML Schemaの現行仕様の問題点を
#認識し、現行仕様の勧告化阻止に向けて動いていたと思います。
#RELAX NGがW3C XML Schemaのアイデアを真似ているとは到底思えませんが...似ていると
#すればXML構文を採用しているところくらいでしょう。
#両氏共にW3C XML Schemaの現行仕様の問題点を指摘した上で現行仕様に手を入れても
#どうにもならないと判断しているのだと思います(村田真氏のブログ等をよんでの認識です)。
#W3C XML Schemaに関しては専門家による問題点の指摘及び解決策の提案が既に行われて
#いるにも関わらず、問題解決が遅々として進まず、全面的問題解決には至っていないようですが...。
#Springコミュニティへのお返しに関しては私個人の見解を述べただけです。競合がお返し(Give)に
#なるというのはTake(頂戴)した側に都合の良い解釈だと思います。
#sugimotokazuyaさんのツッコミへの返答
#koichikさんへのツッコミに書いたことで返答とさせていただきます。
#羽生章洋さんのツッコミ2への返答
#すみません、うっかり敬称書き忘れてました。
#羽生章洋さんのツッコミ3,4への返答
#上に"〜全体"と書いたのはSeasar2.NETもSeasar2.PHPもSesar開発コミュニティの一部であり、
#別コミュニティとは考えていないという意味です。Seasar開発コミュニティのプロダクト
#全体が外部OSSプロダクトの真似をしているという意味ではありません。
#S2Buri等に関しては私は門外漢なので、コメントは控えさせていただきます。
#JBoss云々に関してですが、jBPM自体が外部プロダクトの買収であることは知っています。
#JBossは企業戦略としてOSS戦略を採用しているので、純粋?なOSS開発コミュニティとは
#毛色が異なると認識しています。
#Seasar開発コミュニティが日本発Java系OSS開発コミュニティとして世界に出て行くのなら、
#他のJava系OSS開発コミュニティの手本となるくらいジェントルであってほしいという
#私の希望(願望)も入っています。
#「海外に出て行く」と折に触れて宣伝するOSSコミュニティは珍しいと思いますが...。
#Seasar開発コミュニティが国内のOSS開発コミュニティとして目につくので、私個人の
#希望的願望もあり見る目が厳しくなっています。
#1デベロッパとして自分の開発物(スクラッチ)をOSSとして公開することを考えた場合、私は寛大
#ではないので周りのOSS開発コミュニティに対してGive&Takeであることを期待します。
#それが期待できないならOSSではなくフリーウェアとしての公開に止めます、私は寛大
#ではないのでフリーウェア化がせいぜいです。
#HN考え中さんのツッコミへの返答
#痛み入ります。
#koichikさんのツッコミ2への返答
#私個人の作成物のOSS化に関しては羽生さんとお会いしたときに「フリーウェアとして公開
#しているライブラリをOSS化する気はない?」と尋ねられたことがあるので、書いたまでです。
#OSSに幻想を抱いていると言われればそのとおりです。Give&Takeが幻想なら私個人としては
#自作物でもって総体としてのOSS開発コミュニティに参加する気にはなれません。ソフトウェアの
#規模的にGive&Takeが期待できないので自作物でもって総体としてのOSS開発コミュニティに
#参加しない方は結構いるのではないかと思います。ある程度規模の大きなソフトウェア
#で複雑な内部構造であれば簡単に真似られてしまうことはありませんが、小規模で
#コンパクトなら真似ることは容易です。Give&Takeが幻想なら、自分一人でメンテナンス
#できるコンパクトなソフトウェアを何時の間にか真似られてしまう危険を冒してまでOSS化
#するメリットはありません。公開(Give)することでユーザがついてユーザからバグ報告等
#(Take)があることを前提としなければ、OSSの開発は長続きしません。Give&Takeがなければ
#何時の間にか開発が停滞、公開サイトは開店休業状態と化し、そのOSSは
#フェードアウトしていきます。SF.JPを少し捜せば開店休業状態のモノはすぐに見つかります。
#RELAX NGとW3C XML Schemaの間には明確な違いが存在します。RELAX NGは村田真氏の
#考案した生垣オートマトン理論という基盤に基づいて設計されています。対してW3C XML Schema
#には論理的基盤はありません。論理的根拠があるのとないのとでは大違いだと思います。
#IoC(DI)という考え方は1998出版の本に既に登場しています。
#対して"DIコンテナ"というアイデアはPicoContainerまで登場しませんでした。
#Seasar2やSpringは先行DIコンテナの"DIコンテナ"というアイデアを真似ているとはいえる
#と思います。Seasar2とSpringの内部構造の違いは認識しています。ただ「Springの
#XML解析が遅い」等の内部構造に依存していない部分での問題点の指摘と解決案の提案は
#できるのではないかと思います、それをネタにして「Springは駄目、Seasar2」とやるのは
#違うのではないかと思います。
#Mayaaの"HTMLテンプレート"のアイデアはMayaaオリジナルではなく"Nirvana"や"Taspestry"
#からアイデアをTakeしたと認識しています。"HTMLテンプレート"ベースのテンプレートエンジンの
#アイデア自体はMayaaよりずっと前にRubyのAmrita(PN.essaさん作)で既に実装されていて、
#Mayaa発のアイデアというわけではありません。
#koichikさんのツッコミ3への返答
#上の文章は私個人の見解というか感想文です。感想に根拠を求められても困ります。
#私個人の思い込みもおそらく入って書いています、書いたことが全て間違っているというのなら
#それで構いません。感想に根拠を与えるために時間を掛ける気はないので。
#ただSeasar開発コミュニティがもっと外側からどのように見られているかを意識したほうが
#いいのは確かです。外側にいる人間にはコミュニティの実態はまったくわかりません。
#掲示板等を通してコミュニティ内の人間に接する機会のある人間にはなんとなくわかる
#でしょうが、そういう機会を持たない人間には実態は全くわかりません。
#他のOSS開発コミュニティの開発物に対して攻撃的であるとかオールインワン
#("the Seasar Foundation"のOSSプロダクトで全スタックカバー)というメッセージばかり
#発していると、私ほどではないにしろ、"the Seasar Foundation"に対して良い印象を
#持たない人間は増えていくと思います。
#私のように母国語が同じで意思疎通のできる人間が相手なら認識の間違いを指摘することは
#簡単です。母国語が違う人間相手にはそうはいきませんし、私のように自分のブログ等で
#間違った認識であっても書いてくれれば認識違いを正すことはできますが、心のなかで
#漠然と誤認識をしている人間相手に認識違いを正すことは難しいと思います。
#それなりの時間(数十時間以上)を掛けて自作したモノをGive&Takeが幻想でTakeのみされる
#のならオープンソースにはしないという考え方が異常ですか?私の公開しているフリーウェア
#は内部構造が単純で正規表現とオブジェクト指向とJavaを理解している人であればコードを
#一日も掛けずに理解できてしまうようなシロモノです、実装にはそれでもそれなりの
#時間を要しました、愛着もあります。愛着のあるモノを簡単に手放す気にはなれません。
#反面、ユーザとしてOSSを利用させていただいている身としては総体としてのOSS開発
#コミュニティに対して自作物(スクラッチ)のOSSとしての公開という形ではなくても何らかの
#お返しをしたいという気持ちはあります。積極的に参加・活動したい特定のOSS開発
#コミュニティ等には今のところ出会っていませんが...。
#koichikさんのツッコミ3への返答
#「事実であるかのように書いている」というのはあなたを含む読者の勝手な思い込み
#で、こちらに根拠を示せというのは筋違いです。そんなことは知ったことではありません。
#また、私が書いた他のエントリにまで枠を広げてここで議論する気はありません。
#Web上の情報は玉石混交が常であり、私の書いた文書が事実かどうかは読む側が調査
#して判定すべきことです。
#岡本さんやたけぞうさんがSeasar開発コミュニティとは全く別に活動されている部分まで
#Seasar開発コミュニティの外部との連携というのはどうかと思いますよ。
#Teedaに関しては羽生さんからスクラッチであることはお聞きしていますが、MyFacesの
#コードを読んで使えなかったから別に作ったということであって直接コードを利用して
#いなくても一種の派生であると認識しています。
#PerlのCatalyastやPythonのTurboGearsがRoRにインスパイアされて作成されたの
#とはちょっと違いますが似たような理屈です。
#JavaWorldのある号の記事でSeasar2にはほとんど言及されていないにも関わらずSeasar2
#についてちょこっと触れた文章が間違っていたのをその記事の著者が悪意をもって書いたかの
#ようにSeasar2メイン開発者のブログに書かれていたことがありました。それは明確な根拠が
#あって書かれているのでしょうか?私がFUDとも受け取れる文章を書くことがあるのは
#認めますが、私の書いた軽率な文章を糾弾されるのなら、身内の書いた文章にも眼を
#光らせておいてほしいものです。
#koichikさんのツッコミ4への返答
#Teedaの派生云々に関してですが、要するにあなたはコードを流用していなければ派生には
#当たらないというわけですね?、それは開発エンジニアの世界では当たり前ですが、一般の
#社会では開発エンジニアのお馬鹿な主張と言われてもしょうがないですし、その主張は
#一般の社会では通用しないと思いますよ。例えばMacOSやWindowsはXeroxのパロアルト
#研究所で開発されたAltoの派生物であると一般的には考えられています、これに関しても
#あなたの主張ではコードを流用していないから派生にはあたらないわけですね?
#マイクロソフトのMS-DOSについてもマイクロソフトとは関係しない個人が作ったモノ
#(名前はど忘れ)の説明書を読んでゼロから書かれたモノという話について私は「MS-DOSは
#ある個人が作ったモノの派生である」と認識しますが、あなたの主張ではコードを
#流用していないから派生には当たらないというわけですね?
#私はエンジニアですが、開発エンジニアでない第三者が同じようなことを書いたと仮に
#想定した場合でもあなたは開発エンジニアのの常識が通用しない相手に対して
#「頭の悪い主張」という論法で相手を攻撃するんでしょうね、きっと。
#「"読者の勝手な思いこみ"こそが重要」というのはあなたサイドの主張、それに
#"対して知ったことではないし、指摘箇所を訂正・修正する気もありません。
#"読者の勝手な思いこみ"はこちらにとってどうでもよく、「ASIPって馬鹿だな、奇人・変人だよ」
#と別の場所に書かれていても全然気になりません。
#「"読者の勝手な思いこみ"こそが重要」というのであれば、こことはどこか別の場所に
#「ここに書かれている何月何日のエントリには事実とは異なることが書かれている」
#と掲載しておいて、来訪者数の多いサイトにでもそこへのリンクを張っておけば済む問題です。
#「そこに該当箇所からリンクを張れ」ということであれば張ってもいいです。
#「私が書いた文章("脅す"云々の件は別)」くらいで名誉毀損の訴訟を起こせば私よりは
#"the Seasar Foundation"のほうが物笑いの種になると思います、2CH辺りがとびつくでしょうね。
#指摘箇所への追記は行いませんが、指摘箇所とこのエントリが同じカテゴリに含まれる
#ようには変更しました。
#ちなみにご参考までにこの文章を書き始めて現在までのここへのユニークビジター数(http://asip.tdiary.netのみ)の
#推移を載せておきます、7/5:446、7/6:825、7/7:674。平常時のユニークビジター
#数はよくて百数十くらいです。目くじらを立てて訂正を求めたり、名誉毀損だと騒がなければ
#いけないほどの規模のユニークビジター数には程遠いです。
#JavaWorldの件について謝罪文が掲載されていたことまでは知りませんでした。
#koichikさんのツッコミ5への返答
#Googleからの来訪数云々は私が読み違えていたので修正しました、Googleでのヒット数は
#ここのようにただリンクしているモノ、"the Seasar Foundatin"開設メーリングリストの
#WEBアーカイブ等々も含まれますので、書いていることは的外れではないはず。
#JavaWorld云々の件は「読んで私のように感じる人間もいる」ということの例です、
#「"読者による思い込み"こそが大事」に対して"読者による思い込み"の一例として書いた
#ことでもあります、自分たちに対する攻撃?には「"読者による思い込み"こそが大事」
#と応戦するのなら身内の書いた文章に対する"読者による思い込み"はどう扱うのかと
#いう問いかけでもありました。
#「"作者の悪意であるかのように書かれている"」という私の認識をkoichikさんが「それは
#誤解」と宣言すれば、そこで終わる話です、態々訂正するほどのことではないと思っています。
#Teedaに関しては「JSF仕様書を読むだけ」でなく、その実装にあたって「MyFacesの
#コードを流用はしていないが、コードを読んではいる」こともふまえて、派生としています。
#CatalystやTuboGearsを例に出したのはまずかったかもしれません、JBossとGeronimo
#の関係を例にするべきでした。
#koichikさんのツッコミ6への返答
#「JBossとGeronimoの関係」について書いておきます。
#Geronimoの歴史は元々JBoss(APサーバ)の開発への参加者の一部がJBossのライセンス(LGPL)
#やJBossGroupの方針に異を唱え、別のAPサーバの開発を始めたことから始まります。
#Geronimoの初期のプロトタイプにはJBossのコードが一部(かなり?)流用されていたため、
#JBoss Group(JBoss Inc?)がGeronimoの開発者に対して抗議を行いました。
#その後、GeronimoからJBoss由来のコードが削除され現在に至っています。
#そのような歴史的経過があるので、「JBossとGeronimoのの関係」を例に出しました。
#有識者の方、「JBossとGeronimoの関係」について間違いがあればフォロー願います。
#私が上記の感想文を書くにあたってそう感じた根拠?はありますが、それを
#指し示して議論する気はありません。何度「根拠を示せ」といわれてもこちらに
#その気はないので、堂々巡りになるだけで時間の無駄にしかなりませんよ。
#要するにkoichikさんが言いたいのは「自分たちに対して何か批判めいたことを書くのであれば
#綿密に調査して自分たちが100%納得する明確な根拠を用意してから書け」ということですね?
#koichikさんは私の"Give&Take"の考えを読んで「お近づきしたくない人種」だと書かれ
#ましたが、私の仮説が正しければ「批判するなら綿密に調査して100%明確な根拠を
#用意しろ」というような人と私はお近づきになりたくはないですね。
#JBossWorldの件については私が誤解していたことを認めます。
#koichikさんのツッコミ7への返答
#「JBossとGeronimoの関係」がそのまま「TeedaとMyFacesの関係」に当てはまるとは一言も
#言っていません、自分に都合の良いように曲解誤解するのはやめてください。
#あなたのようなケツのこまい人(私の感想です)とこれ以上対話する気になれないので
#7/10(月)の24時までにこの文章を残しSeasarについてこの日記上で一言でも触れた文章
#全てからSeasarに触れた部分を削除します。以後、Seasarについての文章は2度と書きません。
#あなたのような人と同じコミュニティ(the Seasar Foundation)に参加している人に
#この日記で私が個人的に収集している情報等を閲覧されたくないので該当すると思われる
#方(アンテナに登録している方等)には「この日記がSeasarに関して何か書かない限り
#2度とこの日記を読まない、もしSeasarについて何か書かれた場合は該当する文章のみ読む」
#ように通達して下さい、よろしくお願いします。
#先程(7/10 0:00すぎ)には書き忘れましたが、こちらがthe Seasar Foundation参加の人間に
#読まれたくない以上、the Seasar Foundation参加の人間の書いたブログをこちらが読む
#のはフェアではない(おかしい)ので、もちろん、こちらのアンテナからも該当するブログ
#を7/10の24:00までに削除します。
#koichikさんのツッコミ8への返答
#今「Seasarについて何も書かない」と宣言しても数年後?、それを忘れてうっかり
#書いてしまうことはありえます。カッコ悪くて結構です。私は記憶力は確かなほう
#なので「書くことはまずありえない」とは思いますが、何年も先のことはわからない
#ので「カッコ悪い」ことを書いてしまいました。
#例えば"the Seasar Foundation"から私が褒めちぎりたくなる様なプロダクトが発表されて
#(今のところ、それほどのプロダクトには出会っていませんが...)ついうっかりその
#プロダクトのことを書いてしまうかもしれません、それもカッコ悪いことなんですね。
#「Seasarについて何も書かない」のうちには"Seasarの活動"についてだけでなく
#"Seasarのプロダクト"について書くことも含まれます。
#私がこの日記上でSeasarに関して触れている部分を全て削除する以上、他所で
#"the Seasar Foundation"参加の人間により少しでも引用されている私の
#書いた文章の切れ端について(「脅す」云々の件の部分は別)その削除を希望します。7/10の
#24:00以降で結構ですので削除願います。
#「Seasarに関する一切の事柄を頭の中からデリート及び私個人の情報網から消す、
#そんな団体やプロダクトがあることさえ記憶の隅に残さない」ことに決めました、Seasar
#(団体、プロダクト)は世の中に存在しないモノとして認識する(扱う)ようにします。
#同じ世界に存在するモノとの認識が余計なことを書くことに繋がっている気がする
#ので、Seasar(団体、プロダクト)は自分とは全く関係のない別の世界に存在すると
#思うようにしますとも言い換えられます。
#Seasarへの個人的な注目...あぼ〜ん。
#
##ここからは勝手な独り言
#"the Seasar Foundation"に参加している人(koichik氏以外)がこのブログを読んだり、
#"the Seasar Foundation"に参加している人(koichik氏以外)がこのブログに書かれている
#文章を引用するのは実は別に構わないんです。アンテナやブログ等から削除する必要はありません、
#上の削除依頼文章はムカついてきた時に勢いで書いてみただけです。
#"the Seasar Foundation"の活動やプロダクトについては宣言したとおり、二度と
#書きません。
#
#このブログで"the Seasar Foundation"の活動やプロダクトについて触れた箇所を(この文章を
#除いて)全て(?)削除しました。
#削除し忘れている箇所があれば、ご指摘願いします。
特定のOSS開発コミュニティ自体が他のOSS開発コミュニティとの連携を宣言していなくても、
特定のOSS開発コミュニティに参加している人間が他のOSS開発コミュニティに参加し特定の
OSSコミュニティのOSSプロダクト関連機能を他のOSS開発コミュニティにコントリビュート
していれば、「あるOSS開発コミュニティが他のOSS開発コミュニティ
と(間接的に)連携している」といっても差し支えないように思います。
Seasar2とSpringについてちょっと書いておきます。
別にSpringが好きというわけでもなく、Seasar2が嫌いというわけでもありません。
「Seasar2が好きだから、Springを攻撃するというのはどうよ」というだけです。
個人的にはSunやIBMや海外?の最先端の技術者はDolphinで追加されるメソッドリファレンス
やプロパティ等の新機能を見据えた上で現行のDIコンテナの先にある軽量コンテナの姿を既に
思い描いているのだと最近は思っています。DIコンテナについてJCPで仕様化の動きになっていない
のであながち的外れでないのではないでしょうか?
つづく...文章推敲中。
#ツッコミ2つに気になる固有名詞があったので、ツッコミ自体を修正したモノを再掲しておきます。
HN考え中(2006-07-06 05:10)
ASIPさんの日記にはときどき軽率な発言があるように感じています。よく考えたうえで書き、さらには推敲してから公開するようにしたほうがいいと思います。そのような努力も、ひろい意味でOSSへの貢献になると思いますし、逆にそういうことをせずに、単に思いついたままに特定のプロジェクトを賞賛・罵倒して(それも根拠も明確でないまませいぜい主観的な理屈づけのみで書き放って)いたのでは、ひろい意味でOSSの活動に迷惑をかけるだけになるのではないでしょうか。
批判をするなというのではありません。賞賛するなというのでもありません。批判にも賞賛にもなっていない(そのためプロダクトに関する議論にも進展していかない)と思ったというだけです。このままではこの日記とツッコミ欄は「ASIPさんに議論の仕方をティーチングする場」というだけの価値しかなくなってしまうのではないかと思います。それではもったいないでしょう?
今後の発展を期待します。いまの方向性には良い評価はできませんが、改善の余地はあると思います。がんばってください。
とおりすがり (2006-07-06 08:28)
HN考え中さんに賛成。
ASIPさん、かなり強いというか誤解を生みやすい言葉を使うくせに根拠・論理・主張とか明確でないですよね?
ひがさん、koichikさん、羽生章洋さんの問いに関してきちんと答えないと
議論として成り立たないと思うのですけど。
HN考え中さんとかぶりますけど、今のASIPさんの意見だけ見ると、どうにもヒステリック
にしか読めないです。ジェントルとかそれ以前に筋道が通ってない。
批判する意見でも筋道とおってればこの話の流れにはならないと思いますよ。
OSSをよくするための、きちんとした議論を期待しています。
あぼ〜ん。上記の削除宣言に基づき、削除しました。
大企業のサポートあるいはバックアップが得られないと難しい気はしています。
日本で中規模以上のシステム開発となると大概、大企業あるいはその関連会社が元請けです。
使われるフレームワークやライブラリも元請けから指定される場合が多いのが現状。
元請けの内部で選定する場合には自社独自のモノか海外・国内で既に実績の多数あるモノ
を選考対象にしているはず。
また、大企業やその関連会社にとって実装技術はそれほど重要ではなく、顧客の要望を
満足できるモノであれば何でもよく、新しいモノに飛びつく必要性も感じないという感じ
だと思います。
元請けは構築したシステムが問題を起こした場合、顧客に対して責任を負う立場に
あるので、実績があり且つ自分たちで面倒をみれるモノを選んで当然です。
元請けによる選定でなくとも既に自社内でフレームワークを構築している場合、余程の
メリットがなければ学習コストを掛けてまで乗り換えは行わないのが現実です。
日本で巷のJava技術者と交流して自分たちで作ったJava系OSSプロダクトを宣伝しても
それが利用の拡大に繋がるかは上記の点からみて疑問です。
OSSプロダクト関連のイベントに参加するエンジニアは若手が多いので、システムに
利用するフレームワークの最終決定に関与できない場合も多々あると思います。
海外と日本では事情が異なると思うので、海外での普及を優先して日本での普及は
後回しにするというのもありかもしれません。
日本での普及を優先するなら巷のJava技術者よりはシステムに利用するフレームワーク
の決定権を握る層へのアタックが必要な気がします、アタック方法はわかりませんが...。
Ruby、Perl、Python等のLL言語のOSSプロダクトはそのほとんどがエンドユーザを
対象にしたモノであり、無料のレンタルサーバ等に設置して簡単に利用できます。
企業向けシステムの実装に使われる事の多いJavaとユーザサイドに近いLL言語の
OSSプロダクトでは領域が異なるので普及においてあまり参考にはなりません。
文章推敲中...。
「こちらがGiveする以上、Takeしてもらう必要がある」とは対人間関係で思っている
わけではありません。ただ、相手にこちらへお返ししようという姿勢(相手にとっての
Give、こちらにとってのTake)がなく、こちらがGiveするばかりではこちらからの
Giveは長続きしませんし、そんな相手にGiveし続ける気はありません。
対人間関係では「こちらがGiveする以上、相手にこちらへお返ししようという姿勢を
望む」ということです。
メモメモφ。
接着剤にスギないんだよね。A社の接着剤だろうがB社の接着剤だろうが結局は
接着剤というモノの範疇という点では同じ。
接着剤の多少の善し悪しで大騒ぎするのは馬鹿馬鹿しいので、この日記で接着剤の
比較は行わない予定。
ネジや釘で繋いでいたところに接着剤が出てきて便利になったのは認めますけどね。
でてます。
#プロジェクト・コンフィグレーション・ダイアログが新しく。
#これまではプロジェクトのランゲージレベルがそのままモジュールのランゲージ
#レベルでしたが、今回の変更によりプロジェクトとプロジェクトを構成するモジュール
#のランゲージレベルを切り離してプロジェクトを構成できるようになりました。
サービス。サービスなので、APサーバ上に実装しても単体で実装しても良い。
類似点があるにしても、接着剤とサービスの比較は無意味。
APサーバにしてもDIコンテナにしても結局のところ、接着剤としてサービスを繋ぐモノ。
例えばGeronimoはGBeanアーキテクチャを実現するためにDIコンテナを内包しているけれど、
上に載るサービスが貧弱なのでユーザ数はまだそんなに多くはない。
自分も含めてユーザにとって内部構造はさほど重要なファクタではなく、大概、上に載るサービスの
充実度・完成度を選択基準にする。
DIコンテナとEJB3コンテナとでフルタイムでその開発に従事するエンジニアの人数の桁数が
どれくらい違うのかは謎。
大企業は自社開発orパートナーのAPサーバを推進...DIコンテナじゃ儲けにならない。
EJB3に関しては又聞きの又聞きなので情報の真偽はわかりませんが、ある大企業の
基幹系ではないけれどクリティカルな実稼動中のシステムで既に利用されている模様
(APサーバはJBoss4.x)。EJB3の本格採用に向けた動きは既に始まっているようですね。
つづく...文章推敲中。
ジダン氏の両親は移民。移民に対する侮辱であることが立証されれば、ヨーロッパが
その移民政策の転換で揺れているこの時期、イタリアだけでなくヨーロッパ全土を
巻き込んだ移民による大暴動の引き金になりかねないことを危惧しているからかもしれません。
...と書いてから数時間後にインタビュアからの「問題の言葉はこれですか」に「そうです」となった模様。
世の中にはしょうもないことですぐに侮辱だのなんだの言い出す人がいますが、自分のルーツを
傷つけられたわけでもないのにすぐそんな言葉を持ち出したがる人の神経はどうなっている
んでしょうね、疑問です。
最新に未対応な拡張機能を強制的に実行可能にしてしまう拡張機能。
/* from TechCrunch(on off) */
メモメモφ。
Before...
# koichik [> #「"作者の悪意であるかのように書かれている"」という私の認識をkoichikさんが「それは > #誤解」と宣言..]
# shot [ >#Teedaに関しては「JSF仕様書を読むだけ」でなく、 >その実装にあたって「MyFacesのコードを流用はし..]
# koichik [> #JBossとGeronimoの関係について書いておきます。 その関係があなたの言う「派生」の例というわけでし..]
# koichik [> #「JBossとGeronimoの関係」がそのまま「TeedaとMyFacesの関係」に当てはまるとは一言も >..]
# shot [7/5のSpring vs Seasarのこのエントリは残すのでしょうか?]