日本製Java Frameworkの駄目さ加減を語り合うスレ

>>338-339
その意見は、5〜6年前の感覚では正しいが、
今更Servletみたいに、HTTPをそのままObject化しただけのモデル上に、
直接アプリを書くのはどうか？と思う。

6〜7年前、JavaでWebアプリケーションを書くにあたり、
1)HTTPのObjectWrapping
2)ThreadPooling
を手っ取り早く実現する手段として、Servlet標準は重要だった。

しかし6〜7年前当時ですら、OOアーキテクチャ設計上の目標としては、
分散MVCみたいなのをスマートかつ効率的に実装する事こそ重要な課題だった。
そして、その課題に対する回答は、今で言う
1.DynamicHTML(client side scripting)
2.XMLベースのWebサービス・アーキテクチャ(XSL Translatingや、SOAP/MS.NET)
等にあると、私は当時より認識している。

Servletを勘違いしている人が約一名。

>>347 で、どこが？

>>346
一人だけまったくスコープの違う話をしているような気がするのは俺だけか?
みんな現在主流のWebアプリアーキテクチャ上での解決策として、
JSPがいいか悪いかを論じているのに、
そもそも現行のアーキテクチャが古い→その上で動くJSPも当然ダメ
なんて言ってもしょうがないと思うんだけど。
5〜6年前の感覚云々言っているけど、DHTMLもWebサービスも、
まだ全然メインストリームじゃないでしょ。

ところで、DHTML+Webサービスのアーキテクチャが、
現在のCGI代替系アーキテクチャに比べて優れている点って、
どのあたり?

>>349
ズレは意図してます。
もっと掘り込んで本質に迫らなきゃだめやん、てな意図で発言してるわけだが。

DHTMLは、もはや当たり前に普及してる技術ですね。
大抵は、HTMLにスクリプトの断片を埋め込むだけの原始的な作業
になっちゃってるんで、今更誰も意識はしないけど、
・スクリプトの安定化、軽量化の作業の手間とか、
・複数スクリプトの管理/ダウンロード方法とか、あるいは
・ウィンドウ/フレーム/イベント管理スクリプトの自動生成とか、
のノウハウ集約/フレームワーク化が不十分なまま、
下級プログラマ向けやっつけ仕事に成り下がっている感がある。

Webサービス技術は、まだ普及しそうにないなー。某調査会社の弁では、
「ﾌﾞﾛｰﾄﾞﾊﾞﾝﾄﾞｲﾝﾌﾗの普及した2004〜5年にはWebサービスがブレークするから、
　今年中には開発始めないと負け犬ｹﾃｰｲだぞｺﾞﾗｧ」だそうですが（ｗ

＞DHTML+Webサービスのアーキテクチャが、
＞現在のCGI代替系アーキテクチャに比べて優れている点
比較すべき点は多々あるけど、UI〜イベント管理方面限定で話を煎じ詰めれば、
・UIやイベントの制御/管理を、メタレベルでスマートに行える(可能性が高い)
って点に尽きるんじゃないかなぁー。
もちろん、土方プログラマの方々は、複雑なフレームワークを覚えるよりは、
ひたすら手書きで再利用性のないコードをゴリゴリ書くのをお好みなので、
Webサービスみたいなのは流行りにくいんだろうけど。漏れは土方ではないんで。

あ、土方は土方でも、VB/VC++系プログラマは、Webサービスと相性が良い、
と言われているね。
つーか、10年前から居るそのあたりの開発者をターゲットに開発されたフレームワークだ、ともいえるが

＞みんな現在主流のWebアプリアーキテクチャ上での解決策として、
＞JSPがいいか悪いかを論じているのに、
＞そもそも現行のアーキテクチャが古い→その上で動くJSPも当然ダメ
＞なんて言ってもしょうがないと思うんだけど。
この部分は同意して反省。
要するに、
1.JSP中にスクリプトレット書きまくる輩が存在するのは、
　好ましくないが現状認めざるを得ない派と
2.JSP中にはJavaBean参照コードを書く程度に留めて、
　残りの処理は別のフレームワークに任せる派と
3.JSP全部糞。別のフレームワーク使え派
の議論だったわけね。

んー。JSPなんて、大したもんじゃないから、もっと建設的な努力した方がいいよ。
JSPエンジンなんて、性能/安定性度外視すれば一週間で書ける内容だし、
本当ｺｱの部分だけなら、１日あれば書ける内容なんだから。
とゆー意味で、上記3.に近い立場かな。漏れは。

っていうか、カスタマイズ性を重視するなら、
フレームワーク構築は時代遅れ。

これからは、アスペクトで機能追加する方向へ逝け
(ってまだ初期製品レベルだけど)
　http://pc2.2ch.net/test/read.cgi/tech/1054642415/l50

>>353
Aspect-oriented や Subject-oriented みたく
宣言的でadaptiveなプログラミングを組み合わせられると、
ユーザー、デベロッパは共に楽ができるよね。

ルールエンジンはまだまだ高いからなあ。
JSRにも上ってたし、Jakartaにもプロジェクトがあるし、仕事で使えるのは3年先くらい？

>>350
>・UIやイベントの制御/管理を、メタレベルでスマートに行える(可能性が高い)
>って点に尽きるんじゃないかなぁー。

WebサービスにもDHTMLにも詳しくないので今ひとつピンとこないのだが、
それって、UIのイベントをWebサービス使って
サーバサイドのプログラムに簡単にディスパッチできますよ、ってこと?
もしそうだとしたら、Strutsとかのフレームワークに比べて、特別
有利な点とは思えないのだが。
あと、DHTMLを使ってVBみたいな頻度の多いイベント制御をWebサービスで
行うことを意図している?
確かにブロードバンドのインフラは整ってきつつあるけど、
サーバの負荷やネットワークトラフィックの問題もあるから、
分散システムとして、あんまりいいアーキテクチャとは
俺には思えないんだけど・・・

>>354
ルールエンジンって、アーキテクチャ屋観点から見て、検討に値するものなの？
あと、実装系は何？JRuleあたり？

>>352
あと、

>んー。JSPなんて、大したもんじゃないから、もっと建設的な努力した方がいいよ。
>JSPエンジンなんて、性能/安定性度外視すれば一週間で書ける内容だし、
>本当ｺｱの部分だけなら、１日あれば書ける内容なんだから。

この部分は全く意味が分かりません。
JSPなんて俺様なら簡単にかけちまうぞ、っていう自慢話をしているだけで、
まったくJSPを批判していないですよ。

View(=JSP)というスレの流れの中で

>>346 分散M「V」Cみたいなのを・・・
の次に
>>1.DynamicHTML(client side scripting)
>>2.XMLベースのWebサービス・アーキテクチャ(XSL Translatingや、SOAP/MS.NET)

と出てきたのだから、質問側が
>>349 DHTML+Webサービスのアーキテクチャが、
とするのは仕方がないが、

350=346が「View」+Webサービスのアーキテクチャ
を訂正するどころか「比較すべき点は・・・」以降でViewとWebサービスを絡めて
解説しているのはどういうことだ？WebサービスにViewは関係なんじゃないか？

私の方が勘違い？

>>355

350は「主張系」の書きこみなんじゃないかと疑いはじめました。

>んー。JSPなんて、大したもんじゃないから、もっと建設的な努力した方がいいよ。
>JSPエンジンなんて、性能/安定性度外視すれば一週間で書ける内容だし、
>本当ｺｱの部分だけなら、１日あれば書ける内容なんだから。
はもともと無視するとして。

>>355
正確に意味が伝わるかどうか、自信ないんだが。

おっしゃられる内容は「分散イベント処理」であって、
それは「分散MVC」の一実装に過ぎず、Webに向いているとも思えない。

Web用 分散MVCの肝は、

・通信量やサーバ負荷、通信遅延の問題を避けるために、
　細かいイベントは一々サーバに処理を投げずに、
　クライアント側でローカル処理すべきである(DHTML等)

・元祖MVC流の、Model状態変化をUIに反映するモデルと
　Web流の、画面遷移で状態遷移を表わすモデル
　の間の不整合の解決。(サーバ上で例えばXSLT等を使って、
　クライアント側画面要素(DOM)を一方通行で直接操作可能にする)

ってな点にあると思う。
前者だけでも、ある程度複雑な画面変化を作り込めるわけだが、
サーバ状態変化をクライアントの画面変更に翻訳するコードを
いくつも書いてみると、後者が必要な事を実感できる。
この二つをシームレスに組み合わせると、
・画面変更やイベント処理の場所(C/S)を、後から変更したり、
・Webブラウザの能力に応じ、適切なUIを提供する、といった
「UIやイベントの制御/管理を、メタレベルでスマートに行う」事が
可能になると思う。

あと、Webサービスの話題は、この議論の流れからは若干逸れてしまう訳だが、
より高度な分散処理(サービス連携機能)を実現し、
またアプリの処理形態の自由度を確保するためには、
・通信プロトコルの抽象化、RPC形態への翻訳 (XML RPC/IDL〜SOAP,.NET)
も必要だと思う。

ってな観点から見ると、CGI互換JavaAPIっていい加減レガシーなのよねー

> 2.JSP中にはJavaBean参照コードを書く程度に留めて、
> 　残りの処理は別のフレームワークに任せる派と
　
現状ではこれが大勢を占めてると思われ。
だから無理矢理否定する必要もない。

わくわく。フレーム勃発かな♥

>>357,>>360
その部分は言ってるとおりの事で、
「JSPの標準としての位置付けは大切だけど、
　そんなに複雑・難解なもんじゃないんだから、
　文句を言う暇があったら、さっさと改善APIやフレームワークを作って、
　それをスムースに普及させる方法考えりゃいーじゃん」
って言いたいだけ。

>>358
　>>362
　このスレがView限定だとゆーのは判るが、
　MVC TypeII(ﾌﾟ 自体疑ってかかる気合はないのか？

>>359
　合掌。土方仕事乙

>>364
>>細かいイベントは一々サーバに処理を投げずに、
>>クライアント側でローカル処理すべきである(DHTML等)
と絡めて解説してた「Webサービス」の定義を書いて、
「364は知っている人」ということを証明してほしいのだが。

>>355
それとも「出張系」と解釈して無視した方が良いですかねえ。

>>365 ご質問の意味が皆目理解できませんが、何か？
貴方の前では「知らない振りしてる人」を演じた方がよろしいようだ

むしろ>>358が出張系のﾖｶｰﾝ。
＃マジ >>365の意味わからん

自分に理解できない事柄にブチあたった時、
その対応方法を見れば、その人の真価がわかる
　　　　　　　　　　　　　　 --- 詠み人知らず

>>365
読み返してみました。なーるほど。>>346の
＞2.XMLベースのWebサービス・アーキテクチャ(XSL Translatingや、SOAP/MS.NET)
って書き方が悪くて、妙なイメージ提供していて、そこが>>365の疳に触ったんだな。
じゃ、項目2 を明確に分離して書き直しておきます。

　1.DynamicHTML(client side scripting)
　2.XMLベースのWebアプリケーション・アーキテクチャ(XSLTやEnhydra,Cocoon)
　3.Webサービス・アーキテクチャ(SOAP/MS.NET)

で、Webサービスについては、多少話題から逸れるけど>>362って事で。

Webブラウザの操作を、情報システムが受け取ってデータを更新することを考える。
(参照ではなく更新オペレーション)

Webブラウザ側で何をしようが、HTTPとして表現されたリクエストしか発行できないから、
リクエストの内容が妥当かどうかを検査する責任はすべて情報システム側にある。

DHTMLで選択肢リストを動的に制御しようが、
値のNumericalCheckをJavaScriptで実装しようが、
まったく同じ検査を情報システム側で再度実施しなければならない。
(HTTPリクエストなんて簡単に生成できるからね)

上述した「検査」をWebブラウザに委譲できない限り、アーキテクチャの質的な変化はないと思う。
そこまで変化できないなら、プレゼンテーションをJSPで構築してなんら問題ないでしょ。


逆にWebブラウザに処理を委譲するならば、HTTPを通過するより前に「実施した処理を保証する仕組み」が必要だと思う。
たとえばこんな感じ。
・委譲された妥当性検査処理コンポーネントには、委譲したシステムのデジタル署名がなされている
・Webブラウザは、妥当性処理後の情報にブラウザ側のデジタル署名を行う
・HTTP上は、デジタル署名済みデータが流れる
・システムは、送られてきたデータの署名を確認して、正常に妥当性検査された値だと確認する
・システムは、(妥当性検査することなしに)送られてきた値を受け入れる

ここまでの責務を担当できるフレームワークならば、喜んで使う。
つーか、Webブラウザの守備範囲じゃないか。

ttp://science.2ch.net/test/read.cgi/infosys/1015465665/l50
で、出張が突っ込まれた後にも
>>366-367
みたいなレスがついてた。

みんな同一人物だったりして。
「#」ついてるし。

>>370
自分で100回読み直してごらん。

日本製Java Framework(w

>>370
ナイス・アイデア。
漏れも、JavaScriptでそれ書いた(簡易版＆試行ｺｰﾄﾞだけど)。

あと、例えば RelaxやXMLscheme で書いた値範囲の定義を、
サーバ側及びクライアント側のチェック・コードに自動変換して、
クライアント側フォームに自動で送れれば、結構便利だね。

>>372
　貴方は、>>369≠>>370である事に気付いておられないようだ。
　合掌。

玉石混合だな、をいをい

>>369
そういうことではない。質問者の
「DHTML+Webサービス」のアーキテクチャ
という言葉を正さずに(質問者が悪いって言ってるわけじゃないよ。質問してるんだから)
「DHTML+Webサービス」の解説をしてるのがおかしいと言っている。
あなたの「Webサービス」の定義とは？

>>377 >>362の最終行を良く嫁。見当違い

>>349 お手数ですが、
　　　「DHTML＋Webサービスのアーキテクチャ」ではなく、
　　　「DHTML＋XMLベースのWebアプリ・アーキテクチャ」
　　　と言い換えて頂けますか？
　　　理由は、>>369,>>377あたりをご参照願います。
　　　　　　　　　　　　　　　　　　　　　　　　　以上

>>361
うーん、正直難しくてあんまりよく分からないのだが、
せっかくなのでもう少し質問させてもらう。

>・通信量やサーバ負荷、通信遅延の問題を避けるために、
>　細かいイベントは一々サーバに処理を投げずに、
>　クライアント側でローカル処理すべきである(DHTML等)

これはまあ、分かる。Webクライアントにある程度処理を委譲できれば
どれほど楽かと思ったことは何回もある。
だけど、DHTMLの技術自体はだいぶ昔からあるのに、
未だにメインにはなれていないような気がするのだけど、何故だろう。
あと、リッチなWebクライアントっていう発想自体は他にも
JavaAppletやMSのなんとか（なんだっけ）とか色々あったけど、
どれも廃れているよね。
思うに、何千万、何億という人を相手にしなければならないWebの世界で、
クライアント側の統一を行うのはものすごく困難だからでは?
クライアント側をリッチにすればするほど、バージョン互換の問題や、
セキュリティホールの問題が出てくる。
リッチなWebクライアントというのは技術屋のエゴのような気がするのよ。
そう考えた時に、「CGI系Webアプリはレガシー」と言い切って良いのだろうか。
俺は、この先もメインはこれのような気がしている。

後で、もう一個の方も質問するよ。

知らない人が
>>379
を見ると、私が表現上の揚げ足をとってるみたいに見えるので、例えを交えます。

「強力農薬＋無農薬野菜」アーキテクチャーの利点は？
と質問されて、そのままそれの利点なるものを解説し出した人がいたため、
あなたの「無農薬野菜」の定義は？と突っ込んでいるのが私。
これは揚げ足取りというレベルではない。

>>380 =355
というわけなので、質問しても無駄かも。

>元祖MVC流の、Model状態変化をUIに反映するモデルと
>Web流の、画面遷移で状態遷移を表わすモデル
>の間の不整合の解決。(サーバ上で例えばXSLT等を使って、
>クライアント側画面要素(DOM)を一方通行で直接操作可能にする)

これがどうもあんまりイメージが沸かない。
サーバ側からクライアント側（ブラウザ）に非同期でメッセージを送って、
Modelの変更をクライアントに伝える、っていう
わけじゃないのだよね?
これが分からないから、下のことも何故可能になるのかがよく分からない。

>・画面変更やイベント処理の場所(C/S)を、後から変更したり、
>・Webブラウザの能力に応じ、適切なUIを提供する、といった
>「UIやイベントの制御/管理を、メタレベルでスマートに行う」事が
>可能になると思う。

>>381
いや、俺は>>369でもうある程度回答になっていると
思っていたのだけど・・・

JSPだけでごりごりやるぐらいならServerSide JavaScriptがいいっすよ。
クライアントサイドのコードとサーバーサイドのコードが
さくさく同じコードでかけるし、ＣやＪａｖａのコードも
呼びだせます。
しょぼいＢ２Ｂのシステムぐらいならこれで充分動いてます。
難点はネスケのサーバーしかだめだし、普及もしなかったことっす。

>>384
そんな傍流は捨てろボケ

つっこんでくれてありがとう

>>381
　>>369,>>379 で訂正済みの内容について、
　訂正により質問が無意味になったにもかかわらず、
　無意味かつ不適切な比喩(排中律)を持ち出して
　質問を続ける貴方の真意を図りかねますが、何か？

　要するに、>>362,>>369,>>379で、一連の糞議論とWebサービスを峻別しましたが、
　それを無視して混乱した質問を繰り返しているのは、
　残念ながら >>358貴方です。

　ちょぃとした誤解をなかなか解いていただけないもんで、
　口調がきつくなってスマソ。

粘着だな

>>380
基本はおっしゃる通りだと思います。

現在のスクリプトの使用用途(値チェック,誤動作抑制,簡単なインタラクティビティ提供)
については、必須なものとして今後も使われ続けていくでしょうが、
それ以外の用途への使用は、過去に試され尽くしたうえで廃れてしまったので、
もはや用途拡大はない、と思います。

顧客が「このページにインタラクティビティを追加しる！」って言いだしちゃったら、
flush使うとか、scriptを恐る恐る追加するとか、対応せざるを得ないけどね。

>>380
　はぁーあ。なんかクライアント・スクリプト・ヲタと勘違いされちゃってて、
　いい加減萎えてしまった

>>390
筋違いな意見だったか?悪かったね。
あなたの技術力は認めてやるから、俺にも分かるように教えてくれよ。
興味を持って聞いているのだから。
でも、346のあなたのアーキテクチャは、
クライアントサイドのスクリプティング技術を前提になりたっていると
はっきり書いているのだから、あながち筋違いな
意見だとは思っていないんだけどな。

>>390
ほら、粘着刺激したよ。責任とってね。

粘着かい・・・
悪かった、もういいよ。

>>355 すまそ。先週漏れのドタマに創造の女神が舞い降りたんで(注:電波系ではない)
　結論まで一気に逝けるかな？と思ったんだが、なんか粘着議論に付き合ってたら萎えちゃった。
　気力が回復したら、>>382,>>391に対応しまつ。

　パラダイムが違う人と議論したり、パラダイムの前提を多分に否定した考察をするのは、
　本来楽しい事なんだけど、SEによくありがちな常識を常識と信じて疑わないタイプの人と話すと、
　結構疲れるんだ。
　んな意味で、Java〜オブジェクト・ブームのど真ん中で、アスペクト指向の研究黙々とやって成果を出した連中は、すげぇと思うよ。少なくとも5〜10年は時代の流れと別の事をやってたわけだから

>>383=355
指摘されてWebサービスを分けただけではダメなんですよ。
Webサービスがなにか分からずその言葉を使ってるってことは、
＜＜＜かつ尊大な解説をしている＞＞＞
他の部分も説得力がない「出張系な書きこみ」になるわけですよ。
そんな偽者の人と議論しても355の無駄になるでしょう。

２，３行Webサービスの定義を書けばすむ話なのに。

普通の書きこみならここまで突っ込まないけど、JSPのようなものを作るのは
簡単って言ってる人だから。

話の流れと関係無いが、
JSP作るのって簡単か？あの仕様の字句/構文パーサなんか今更書きたくないぞ、俺。
AppleWOやTapestryみたいな構造を作るほうが、まだ楽っぽ。

HttpServletベースのアーキテクチャがダメダメって言う話は、VHSがβを駆逐した話
みたいなもんか？
HTTPで何でも転送なんて、理屈じゃまともじゃないとだれもが思うと思うんだけど、
すでに巨大なシェアがあり、既得権が生まれつつあるのでどうにもならんでしょ。

>>395＝358＝デムパ認定しておきます。
人の話を素直に聞かず、また人の能力を疑ってかかる、君みたいな人物は、不要だよ

>>396
漏れはJSPみたいなのは嫌いなんだけど、
JSP登場後1〜2年しても社内導入が進んでなかったんで、
「JSPなんて糞。んなもん簡単に実装/利用できるんやから、
　さっさと導入して問題検出して次行こうぜ次」
つうノリで JSPの単純さを示す意図で
似たようなサーバ・ページ・エンジン書きました。

HttpServletベースのアーキテクチャがダメダメかどうかわかりませんが、
HttpServletが依然仕事の中心であるような、古いつまらない仕事は、
全て他の方に任せる事にしてます。

>>395 の問題点は「Webサービス」の定義が簡単だと思っている事。
多分「SOAPの説明」を「Webサービスの説明」だと思い込んでるんやないかぁー(ｹﾞﾗｹﾞﾗ
新しい技術概念を、他から学んで丸暗記するだけの、情報処理試験対策みたいな勉強しかしてないんじゃねぇーの(悲惨)

あと、文章の強調に大小記号(＜＞)使うようなヤシは、
到底 Webやってる人間には見えんな

結論：情死す板で議論すると、かならず >>355みたいな粘着が発生して、
　　　意味のない議論を延々繰り広げてしまうんで、
　　　情死す板でまともな議論をしようとする努力は不毛である。
　　　

あぼーん

あぼーん

あぼーん

あぼーん

あぼーん

あぼーん

あーあ

>>401
いいや。知ったかぶりが、自分の実力以上のことを書きやすいから。
偽者に乗ってレスつけたりしちゃだめだぞ。

>>355

>>399　で「SOAP」という偽者が検索するヒントが出てしまったため、
もったいぶらずにタネあかしをします。

SOAP，XMLなど個々の技術はさておき、Webサービスには
　「画面を介さずに」　相手のプログラムを動かす技術
という側面があります。（これがすべてではないが）
なので、「少しでも」知ってる人にとっては
「DHTML」+Webサービスのアーキテクチャー
はありえないのです。

ネットだけで情報を集めて「主張系」書きこみをする輩
の手助けをする書きこみになってしまいましたが、
355がこういう輩のレスを無視する助けになれば幸いです。

じゃぁ、>>358もゴミって事だな。実に下らん展開だ。

第三者として口挟ませて頂けば、
>>346＝>>350＝>>399＝普通のWeb開発者
>>358＝>>410＝沢村＝偽者＝スレを腐らせる常連粘着
だと思うけどなぁ。

なんで>>358はこんなに低レベルの煽りをやっているのだろう？
>>358は、何か日常生活に不平不満でも溜まっているのか？

JSPｴﾝｼﾞﾝ･ｻｰﾌﾞﾚｯﾄの手書きもできずに
JSPを議論する低ｽｷﾙな自称SEが居るｽﾚは、ここですか？

>>401
× >>355
○ >>358
結論：情死す板で議論すると、かならず >>358みたいな粘着が発生して、
　　　意味のない議論を延々繰り広げてしまうんで、
　　　情死す板でまともな議論をしようとする努力は不毛である。

自分に理解できない事を言われると、
議論の小さな瑕疵を見つけて相手を偽者と決め付ける。
そんなことじゃ、成長できないよ。

まぁ>>358は情死す板に常駐してる業界外の煽りだろうから、
こんなこと言っても無駄だと思うけど。

低レベルだと思うなら無視しろよ。
無視すんのが一番だ

頭と性格が悪くて粘着なので、単に敬遠されているだけなのに、
　　「自分は議論や煽りで未だ負けた事がない」
と勘違いしている>>358の居るスレはここでつか？

>>413
Kernighan＆Plaugerの「ソフトウェア作法」やLisp文化、オープンソース文化では、
ソフトウェア開発者が自身で作成/拡張可能なツールやプリプロセッサを使って、
自身の開発環境を進化させる、とゆーのはよくあるテクニックだ。

自身で作成/拡張可能なソフトウェア・ツールのメリットとしては、
不定形で捉え所のない「ノウハウ」を、ツールとして形式化する事で、
・形式化を通じて、ノウハウの改善が容易になる
・そのツールを使う複数のメンバー間で「ノウハウの共有」が可能になる
・そのツールの振る舞いや限界を適切に理解し、適切に活用できる
ってな点が挙げられる。至極あたりまえな話だけど。

「フレームワーク」や「フレームワークの作成/拡張」にも、似たようなメリットがある。
フレームワークを使うだけにとどまらず、自分で作成し拡張する事を通じてこそ、
自分や自分の所属する文化の発展に参加する事ができる。
その意味では、フレームワークの駄目さ加減をあげつらうばかりでなく、
その分析結果を元に、自らフレームワークの作成/改善に手を染める事こそ、
望ましい姿勢ではないだろうか？
但しヘタレなフレームワークを標準として他人に押し付ける事の有害性は、
常に意識する必要があるだろう。(>>1 がスレタイで主張しているのは、このあたりかな？)

>>418
「ノウハウの形式化」ってのは、そんなにメリットのある事かな？
本来、不定形で柔軟な「ノウハウ」を、
変更が面倒な「ソフトウェア・ツール」にまとめてしまう事で、
・仕事の改善スピードが落ちたり、・柔軟性が欠落する、
というデメリットもあるのでは？

>>419
形式化すればお茶の子で対応できる定型仕事を、
毎回毎回、死に物狂いの飛躍として不安定かつ不確実にこなすよーな、
リスキーでデンジャラスな生き方を望むのであれば、
形式化の努力は不要です。

普通の人は、意識的にせよ無意識にせよ、また程度や手段の差はあれど、
自分の仕事を定型部分と不定形な部分に切り分け、定型部分を増やす事を通じて、
仕事に熟練する。
この定型部分を洗練する一手段が、形式化　なのではないかな

>>419
サイト固有のスペックがそうさせる傾向にはあるよな。
ビジネスロジックに限らず。
>>420は正論だが現場とは乖離してるよ。

>>419
不定形で柔軟な「ノウハウ」が「ソフトウェアツール」への「設定」
に置き換わってるんじゃないの？ちゃんとしたツールなら。
「設定」の方法を覚えるのが面倒になってるで、相変わらず「（こん
どはその設定に関する）ノウハウ」が重要になってるとか。
RDBMSとかAPサバとかさ。

>>418
釣りご苦労さま。
このスレには「ソフトウェア・ツール」(邦題：ソフトウェア作法、監訳：木村泉)
という原点を共有できる方が、なかなか現れないね。

UNIX＆C言語文化の古典「ソフトウェア・ツール」の実践すら困難な仕事環境で働く人々は、
一体どんな希望や展望を持って日々を過ごしているのだろう？
そして、このスレの人達は「ソフトウェア・ツール」の実践すら不十分なまま、
一体「フレームワーク」の何を語ろうとしているのだろう？

他人事ながら、彼らがリーダ・クラスやプロマネとして活躍する現場の
悲惨さに、同情を禁じえない。

>>421
　>>420は正論だが現場とは乖離してるよ。

おっしゃる意味は、実体験としてすごくよく理解できるが、
「そこを何とか変革しよう」と現場で努力する方と一緒に
仕事できるように犠牲払って努力してるんで、
決して「共感」はできないっす。

_._._._._._._._._._._._._._._._._._._._.

　インターネット〜Webの一般向け立ち上がり当初(1994〜1996)っから、
この分野は 熟練や定型化 とは無縁の土方仕事になる予兆があった。
（無秩序に HTMLとCGIを書き散らして、デザインやリンクで整合性とれば、いっちょ上がり、だからね）

　次にJavaサーバ技術や、その上のフレームワークが登場し、
それらがオープンソース化される事で、一気に業界水準が上がる予感があった。
Webに要求されてる「迅速かつ低コストなサービス提供」という側面も、
うまくいけば基本サービスや定型処理のフレームワーク化を促進しそうな予感があった。
　（例えばフォーム＆ＤＢ処理の一括管理、ワークフロー管理、サービス連携、等々)

しかし現実はどうだ？
ソフトウェア開発技術がつたなくて、
既存の業務アプリや業務パッケージの構築/メンテ、サーバ開発
といった手段ではキャリア・アップできない連中が、
いきおい＆アイデア一発で勝負をかける分野になってしまった。

その現実を否定してもはじまらないし、
おそらくある意味正しい結果なのだろう。
しかし、10年近く前のオブジェクト指向技術者の夢
からすると、悲しすぎる現実であるずら。

>>422
ソフトウェア・ツールの意味を理解されていないように感じられました。
RDBMSやAPサーバ自体を独自開発/拡張するよーな難易度の高い事を、
「ソフトウェア・ツール」は求めていません。

現場で、複雑な一体型アプリやサーバを作るのは無理あり過ぎなんで、
むしろﾁｮﾛｯとコード書けばお役立ちツールやお役立ち機能拡張ができ、
それを組み合わせれば複雑な機能を実現できるやん、
という話です。ぶっちゃけ開発者が自己拡張可能な仕事環境。

Javaサーバ環境との対応関係を表面的にさらっと示しとくと、
　[ソフトウェア・ツール]　　　[Javaサーバ環境]
　パイプでつないだコマンド群　クラスやスレッドを駆使したクラスライブラリ
　　　　　　　　　　　　　　　Apache module、ServletChaining, JSTL等々
　プリプロセッサで言語拡張　　JSPやXMLを使った言語拡張
　移植性　　　　　　　　　　　WebやJavaやXMLって環境選ばないし
てなかんじぃ。もうちょっと深い思想があるよーな気もするが。

というか「設定が面倒」って、、、
そもそも開発じゃなくて構築の話じゃないですか（ｗ

＞＞４２５
その対応関係、つまんないでつ。
「オブジェクト指向は昔からあった」親父と同じニホイがしまつ。

んな事書いてると「Servlet使って、MVCを完全に実装しますた」系ワカモノが、
「Servletｴﾝｼﾞﾝ使ってるので、ソフトウェア・ツールの実践は完璧でつ」
とか言い出しちゃうよ、

あぼーん

>>425 プリプロセッサで言語拡張

・バイトコード編集技術
・アスペクト指向言語
を入れとくの、忘れただろ。
ポストプロセッサ系技術だから、
ちょっと対比しにくいのかな？

あぼーん

あぼーん

>>428
多少話しがずれるけど、対比表に追加してみます。

　　　　【ソフトウェア・ツール(K＆Ｐ) と Javaサーバ環境 の対比】

　[ソフトウェア・ツール]　　　　　　　　[Javaサーバ環境]
　パイプでつないだコマンド群　　　　クラスとスレッドを駆使したクラスライブラリ/サーバ、
　　　　　　　　　　　　　　　　　　　　　　Apache module、ServletChaining, JSTL等々
　プリプロセッサで言語拡張　　　　　JSPやXMLを使った言語拡張
　(ポストプロセッサで言語拡張)　　　JBoss4等のアスペクト指向導入
　移植性　　　　　　　　　　　　　　　　　Web､XML、Javaは環境依存度が低い

あぼーん

>>421
＞サイト固有のスペックがそうさせる傾向にはあるよな。
＞ビジネスロジックに限らず。

どうすりゃいいんだろうね、
ノウハウ/ツール/フレームワーク構築　というスローテンポな要素を、
ビジネス展開やサイト間の差別化競争　のようなハイテンポな動きに
対応させるには？

>>43
　それやる能力があったら、
　みんなベンチャー作って独立してるって。

　あと、大手ならツール/フレームワーク構築なリードタイムを確保するために、
　勝手な標準/デファクト・スタンダードをさっさとぶち立てて、
　技術的啓蒙力や販売力駆使して、
　ネタ探し中経営者層や先走り開発者層に流し込むだろ（ｗ

　それをやれる所はほんの一握りだから、残りのみんなは苦労してるんだ

関係ないけど、ム板の同様なスレと比べて、こちらのスレはアレだね。
ム板は、この分野の技術動向や技術者の関心をリアルに反映しているんだけど、
こっちの板は、アレだからしょうがないのかな。