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

>>33
FTK/WATS Framework といえば
・データソースの定義方法が独自。(裏でDriverManager使ってるらしぃ)
・定義情報はweb.xml等に書くんじゃなくて、これまた独自。(定義方法がまたﾜｹﾜｶﾗﾝので困った...)
・HashtableExとかいう独自データ構造しかDataAccessorのパラメータとして受け付けない。
等々なんで、J2EEのフレームワークじゃないね。
Servlet黎明期に作られたモノを見てるような気がしますた。

>>251
なんかそこのフレームワークって独自だよね。
Componentという名の独自クラスを継承して業務アプリ作るんだけど
Component継承クラスはHTTPリクエストからレスポンスの間ひとつしか
フレームワークから呼ばれないから適切なモジュール分割なんて全然無理だし。

>>251
>・定義情報はweb.xml等に書くんじゃなくて、これまた独自。(定義方法がまたﾜｹﾜｶﾗﾝので困った...)
そう。だからデプロイ方法も全く違うし。
これだけJ2EE標準を無視したサーバサイドJavaフレームワークも珍しいと。

>>253
日本にはJ2EEを無視したイミフメイFWが大量にありそうだ。
俺の勤務先でも、今そんなの作ってる。

多分設計担当の技術担当役員が、情報収集能力も英語の仕様
書を読む能力もなかったんだろうな。

サーバサイドJava=J2EEと思い込んでいる輩

xTradeは？

インプリメンテーションで独自性を打ち出すのは何の問題もないが、俺様インターフ
ェイスのわけわかフレームワークは、仕様管理もユーザの教育も全部コストを丸抱え
になって、いいことは何もないと思うんだが。

J2EE＋JAXファミリーのカバーする範囲は、殆どのサーバーサイド処理になるはずだ。
頼むからインターフェイスの仕様くらいあわせようよ…
お前らの作ったインターフェイスがカタワな俺様フレームワークの仕様を勉強するの、
面倒くさいんだよ…

どこかのアフォＳＩが、サンのWAF(WebApplicationFramework)と紛らわしい名前のカタワFW作ってたなぁ

（＾＾）

俺様フレームワークage

なんだ？

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

他社の俺様フレームワークを受け継ごうとする会社はＤＱＮ。
優秀な会社は他の条件が良くても俺様フレームワークがあるが為に案件全体を断る。
フルリプレースしかしないっていって。

２年前だったら、独自のフレームワークを作る意味はあったかもしれない。
しかし、Ｓｔｒｕｔｓとか無料で利用できるそこそこの品質のフレームワークが
定着してきた今となっては、なんで、俺様流にこだわる理由があるのかね。

Struts=Struts原作者の俺様フレームワーク

>Struts=Struts原作者の俺様フレームワーク
最初はそうだろうが、現在ではオープンソースとして
カナーリ洗練されているが、何か？

>カナーリ洗練されているが、何か？
ブラウザ以外をクライアントにした事例をまともに聞きませんが何か？

>ブラウザ以外をクライアントにした事例をまともに聞きませんが何か？
そりゃそうだろ（藁
StrutsはHTTPクライアント前提のフレームワーク。
リッチクライアントならAXIS使いなさいってこった。

>StrutsはHTTPクライアント前提のフレームワーク
へーそーなんだぁ
じゃあ、俺様流にこだわるとこはHTTPクライアント以外が
ターゲットだったりするんじゃねぇか？

>じゃあ、俺様流にこだわるとこはHTTPクライアント以外が
>ターゲットだったりするんじゃねぇか？
それが、笑っちゃうのが、俺様流のほとんどが、ＨＴＴＰ
クライアント。
ところで、StrutsがHTTPクライアント前提ということも
知らなかったって、269って相当なDQN？

StrutsっていうかMVCのVとCしか関知していないフレームワークは
最近どーでもいいって感じ
どれ使ってもコスト的には５０歩１００歩
それより誰かMのとこをどーにかしてほすい

JAVA PRESS vol.29におもろい記事がある
「サーブレット／JSPとことん現場主義宣言
最新技術を知り，テクニックを磨き，そして洞察力を高める！
第5章■フレームワークとその先にあるもの
間違いだらけのフレームワークの捉え方 」
http://www.gihyo.co.jp/magazines/javapress/contents

>>271
だから、その程度（VとC）の部分で、HTTPクライアントだったら
Strutsでいいじゃないの？
>どれ使ってもコスト的には５０歩１００歩
だったら俺様流作って無駄な時間つぶすのはおやめなさいって
ことでいいでしょ？

>それより誰かMのとこをどーにかしてほすい
Mの部分をフレームワーク化するのは、作る側にとっても使う側
にとっても相当難易度が高い。
逆に言うと、フレームワーク化してFrozen Spotにするような
汎用的業務要件ってそんなにないと思うのだが。

>>263
日本各地の低レベルSIerが、己の技術の誇示のために、二番煎じフレームワークを
量産していますな。俺の派遣先でも作ってますよ。ｵﾏｴﾗﾉｵﾅﾆｰなんかﾐﾀｸﾓﾈｴ つД`)

>>273
全く同意
フレームワークという意味もわからぬ連中が作ったフレームワークが
どれだけあることか....

だいたい、なんでフレームワークとやらを作るのかといえば、フレームワーク
化した部分を再利用することで、システム開発のコストを抑えるのが目的だよな。

んでもって、世の中には大体においてよくやってくれる安価(もしくはタダ)
なフレームワークがすでに存在する。

ソレにもかかわらず、二番煎じを自分で作り、その全てに関する保守のコスト
と、二番煎じフレームワークの利用方法についての教育に関するコストを丸が
かえして、既存の二番煎じを自作する意味って、まるでないと思う。

Strutsに問題があるなら、ASFライセンスのオプソなんだから、自分で修正して
使えばいいだけだ。金かからんし、保守責任も修正範囲だけですむ。

ということで、手段と目的の区別もつかない技術バカのオナニーでしかないとい
うのが俺の持論。

手付かずの新規分野やニッチ領域のためになら、いくらでも作ってくれ、と思う
けどな。どこにそんなものがあるのかしらんが。

>>275がイイコト言った！

じゃああげてやれよ

楽々、ありゃ、フレームワークなのか？
使えそうにないなと思ったが・・・

>>272
MVCのVC部分は、アーキテクチャ中心のフレームワークなんで、
再利用し易く、標準的実装を入手しやすく、評価もある程度定まっていて、
「とりあえずフレームワークというものの使用方法/構築方法を習得する」のに、適しているんだろうね。
だから、VC部分のフレームワークの自作が悪いとは思わない。もっとも、その自作品を実業務で使ったら、生産性やメンテナンス性の改善にだいぶ時間がかかりそうだけど(w

MVCのM部分に相当する、業務領域のフレームワーク化は、
一朝一夕に実現できるとは思わず、地道に試行錯誤と再構築を繰り返して行くしか方法がないんじゃないかな・・・

>だから、VC部分のフレームワークの自作が悪いとは思わない
勉強目的だったらね。
でも間違っても、パフォーマンスや信頼性を十分に検証していない
フレームワークを販売したり、他人に利用させたりしちゃだめよん。

>>280
低レベルSIerは、その勉強用の出来そこないを売って回って、顧客の囲い込み
に利用しようとするロクデナシ吸血鬼連中の巣窟です。

元を正せば、能無しのくせに功名心だけやたら強い一部の馬鹿の暴走だったり
するけどな。

>>278

どういう定義で捕らえているのかわからんけどフレームワークでしょ。
cFrameworkとかStrutsとかWACsとかいろいろ挙げられているのを
フレームワークというのであれば、楽々Frameworkだけを除外する理由はないし。

個人的にはあの思いっきりえへへ囲い込みますよ的なつくりが好きになれないけど。

俺様フレームワークについていろいろ意見も出てるけど、
まあ会社として納得して使うんならいいんでない。
フレームワークなんてミドルウェアといっしょで、それだけでは価値を産まないんだから
なに使ったって最終的にきっちり動いて満足されるものができるのであればいいじゃない。
囲い込まれても生産性向上が実現できて短期的に安ければOKという判断も
それ自体が悪いわけでないし。

> フレームワークというのであれば、楽々Frameworkだけを除外する理由はないし。
ハリウッドプリンシパルからすればフレームワークではないと思うが。

>>283

なるほどね。でも バージョン2だと今までの画面別サーブレットから
FrontController型に変わったんでなかったっけ？

>>284
FrontControllerを使ったからフレームワークというのはね。
フレームワークの基本的考え方としては、
・フレームワーク自体はFrozenSpot
・フレームワークに呼び出される個別実装部分がHotSpot
てのが常識じゃない？
ここで議論しているのがMVCフレームワークだとしたら
楽々はバージョン２でも（本来フレームワーク内でしかるべき機能まで）
HotSpotだらけだと思うのだが。
ｃFrameWorkもしかり。

技術的にどんなに腐ってたりショボいFrameworkでもいいから、
短期開発できてそれなりのパフォーマンスが出せればユーザーとしては
それで問題無しです。
そういう意味ではここで叩かれてる楽々も悪くないと思うのだが。

>>286
そうだね、それを本当に実現できれば問題なし。
但し、フレームワークと名乗るのはどうかなってこと。
ついでに言えば、あれで基本価格1,000万円ってのはどうかと思う。

あぼーん

なんか、、、住○電○情○システムの人間が混入してるな・・・
恥ずかしくないんかね？書いてて。
本当に意図するものが、「短期開発できてそれなりのパフォーマンスが出る」のか？
あれを使ってやで？？
本当にユーザの立場でSE、PGしてたら絶対そんな意見でねーはずだが・・・

283=285=287だが
>>289
の言うとおりだと思う。
アーキテクチャとして信頼性、パフォーマンス面での検証が不十分
なものを売りもんにしちゃいけないよね。
楽○フレームワークの作成者が説明していたが、
もともと、ユーザー系システム子会社では、ＣＯＢＯＬは組めるが
Ｊａｖａで構築する技術者はいないから、ちょうど、ＭＳＡｃｃｅｓｓで
簡単にマスター更新画面やデータ入力画面を構築できるような開発環境
が必要だったとのこと。
＃だったらＡｃｃｅｓｓ使えばいいだろうが．．．．．
Ｊａｖａ技術者が不足していた頃だったら、こういう極端に生産性を
重視したアプローチも場合によってはＯＫだが、少なくとも金融系の
勘定システムなんかや、一般企業の基幹系システムに適用しちゃだめよ。

某帝大の病院情報システムをPerlで作り込もうとしてポシャった案件
あったけど、あれってEdgeのFramework使ってたら失敗しなかったの
かねぇ？
っていうか、数十億円規模のシステムなのになぜPerlで作り始めたの
だろうか。

>>291
EdgeのフレームワークってSledgeのことか？
Perlで作ったフレームワークなんて頭おかしいんじゃねぇか？
もしかして291ってEdge社員か？

あぼーん

2001年に中日ドラゴンズに１０億円という巨額の金額で入団した川崎憲次郎。
しかし彼は入団してから２年間、１軍のマウンドで1球も投げていない。 怪我は治っているが、２軍での投球も拒否。
最近では自宅での休養（サボリ）を続けているという。
ちなみにヤクルトの伊藤選手も同じような状況であるが、本人からの要望で給料の８〜９割を返還している。 一方川崎憲次郎はビタ１文も返してはいない。
もちろん税金等の問題があり、そんな単純ではないが１本１０円のワクチンを１０億円で買うならば１億人の人口が救えるのだ。
食料に困っている１億人の人たちにうまい棒を買ってあげられるのだ。
必死に生きて餓死していく人たちの前で川崎憲次郎は優雅な生活を楽しんでいる。
こんなことは許されない。皆もオールスターのファン投票で川崎憲次郎に投票し、出場させるのだ！！
5月23日の中間発表ではセリーグの先発２位につけている！！
投票は6月22日まで！！
https://allstar.sanyo.co.jp/vote/
中日・川崎憲次郎、依然先見えず…
http://www.zakzak.co.jp/spo/s-2003_02/s2003021502.html

>>285
いいこといった！
Frameworkの特徴をうまく説明しているよ。
使わせてもらおっと。

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

なにげに良スレ
それにしても、どっかの雑誌で読んだような発言が多いな。
もしかして本人達降臨？

>297

良スレかな？
製品をけなしてるだけだと思うが。
とはいえ、私の勤務先も某社に騙され某Frameworkを活用したシステム開発に
億単位の金をつぎ込んでしまった...
やばし...

>>291
> 数十億円規模のシステムなのになぜPerlで作り始めたのだろうか。

別にPerlでも何でもいいんじゃない？
金額によって使用する言語がかわるほうがおかしいよ。
(使用する製品はかわるかもしれないけどさ。)
開発者たちが自信をもって使えるものであれば、Perlだろうと
PHPだろうとJavaだろうとSchemeだろうと何だっていいよ。
つーか、そんなに金があるんなら、ほんっっとに優秀な人間だけを
雇えば、どんな言語使ったって成功するよ。

>>299
暗黙の前提が適切ではないな。
ほんっっとに優秀な人間は数が少ない。
ほんっっとに優秀な人間がいても、依頼したいときに空いているわけではない。

ただし、数十億円の規模のシステムにperlを適用するのには、俺も疑問だ。
相当数の人間が関わるプロジェクトには、できるだけ強制が多い言語を使いたい。
Javaくらいに「制約を色々とかけられる言語」の方が適切。

>299

Perlだと記述の自由度が高いので、コーディング規約で書き方を
ガチガチに固めないと地獄かもね。
スキルのバラツキが大きいと、読むのも大変なメンバーが出てくる。

スキルのバラツキを補うのがFramework、という認識でいいのでしょうか？
家の会社ではNRIの.NET対応のFramework導入するぞ〜とか言ってるPJが
ありますが、果たして効果はいかほどか。

>>301
フレームワークはハリウッドシステム。
ライブラリのように「呼び出す」部分を記述するのではなく、
フレームワークから「呼び出される」部分を記述する。

スキルのバラツキを抑える効果はあくまで副産物。
ハリウッドの俳優にだって、ハリソンフォードのような役者バカもいればディカプリオみたいな大根もいる。

285だけど、
オブジェクトワークスもかなり糞なフレームワークだよ。
あそこは、大規模処理はCOBOL＋OLTP（日立のTP1)でバックエンドを
構築し、フロントのみをJ2EEもしくは.NETでやるというモンゴル騎馬軍団
戦法が好きだから画面（JSPやASP）と画面遷移を定義するところに異様な
くらい親切なエディット環境を提供したりする。
楽々といい、オブジェクトワークスといい、敷居を下げるのはいいが、
大規模システム構築には所詮それなりのスキルが必要。
言い過ぎだったらゴメン

>>302
どうでもいいが、ハリソン君は大根だろ？
ﾎﾟｶｰﾝと口開けた間抜け面専門の。
役者バカとはロバート・デ・ニーロのような俳優のことを言うのだ。

>>302
> スキルのバラツキを抑える効果はあくまで副産物。

なら真の目的は？

究極の目的は生産性の向上なのかな？
それを実現する為にはスキルのバラツキをカバーする必要がある、と。

DQNソフト屋がJ2EEなどのクラスを１つでも理解しないで済むこと（藁

あぼーん

あぼーん

>>305
>>306
構造というか方式を統一するという目的もある。両方とも優秀なものとしても
フレームワークAを使ったものを、素で書いたものに相当するプログラム
と
フレームワークBを使ったものを、素で書いたものに相当するプログラム
がシステムに混在していたのではわかり辛い。

あと設計規約を自動的に守らせるという目的もある。
フレームワークA相当で書きましょう、と言っても、すべて書かせたら
守られない部分が出てくる。
「呼ばれる部分」のみ書くのであれば、自動的に縛れる。

あぼーん

intra-martってどうよ。
次のバージョンでStrutsにも対応とか言ってるが・・・。

とりあえず、cFrameworkよりは、まともなFrameworkに見える。

あぼーん

あぼーん

EC-Oneってまだ生きてるの？最首しゃちょーだっけ？元気なのか？

日本人無能技術者連中がStrutsの二番煎じでアーダコーダっているあいだに、
JakartaではTapestryがでてしまったな。JSPが本格的にいってよしになりそうだ。

>>316
Tapestoryどうよ？

>>317
ビュー作成にJSP使わないって、スッキリして良いよ。
JSPってもともと問題があるソリューションだからな。

その意義を理解したがらないやつも多いだろうな〜。
せっかくJSP覚えたのにやめたくない！とかな。ｱﾎｶ

>>318
問題多いかなあ。
カスタムタグを併用する限り、かなり柔軟な仕掛けだと思うけど。
(JSTLはあんまし詳しくないが、便利そう)

具体的に何が問題なの？

日本の中堅以上のソフト会社のstrutsもどきで日本一ダメポな
フレームワークはどこのですか？

あと、ｱﾎﾟｰのWOもどきのフレームワーク作ってる会社があったら、
教えてホスィ

>>321
それこそTapestryでどうよ。今月Jakartaデビューの新鮮素材。
Sourceforgeでずっと開発されてたんだけどね。

>>320
もっともｽﾊﾞﾗｼｲネタは、日本IBMのSTXだろ。
ｱﾚをみて、同じ日本人でいることが恥ずかしいと思ったよ。

Eclipse作ってる連中とかと、本当に同じ会社なのか？

>>319
JSPのソースと、Javaソースに変換されたJSPと、Javaクラスファイルに
コンパイルされたJSPで、それぞれの処理ステップ位置のマッピングが
取れません。jasperやその他各種APサバ付属のJSPパーサ間で、生成され
るJavaソースコードそしてJavaクラスファイルに、仕様の統一は全く取れ
ていません。

さて、
・デバッグどうします？
・サーバー(JSP実行環境)移行どうします？

> JSPのソースと、Javaソースに変換されたJSPと、Javaクラスファイルに
> コンパイルされたJSPで、それぞれの処理ステップ位置のマッピングが
> 取れません。
すくなくとも変換後のJavaソースとクラスファイルはマッピングとれるから
jdbでもデバッグできるぞ

> 生成されるJavaソースコードそしてJavaクラスファイルに、仕様の統一は全く取れていません。
仕様の統一じゃなくて実装の統一だとおもうが
なんでJavaソース、Javaクラスレベルで統一とれてなきゃいかんのかがわからん
JSPレベルで統一してればいいんじゃねーの？
生成されたクラスファイルの移行するわけじゃあるまいし

>>324

> ・デバッグどうします？
例外スタックトレースの行番号が合わないってことかな。

だいたいの環境に、JSPのトランスレート後Javaソースを残す設定があるだろ。それを参照するよ。
少なくともJRun、WebLogicはできる。
というか、JSPの仕組み上、トランスレート後Javaソースが生成されないわけがない。
ならば、普通のプロダクトならそれを残す仕組みは用意してるはず。
(メモリ上のStreamとしてJavaソースを生成したりすれば、ファイル出力は不要になるかな？)

> ・サーバー(JSP実行環境)移行どうします？
JSPはJSPの範囲だけで仕様が規定されてるんだから、それはあたりまえの話。
JSP の specification に載ってる変換後Javaコードも、あくまでexampleだし。

プレゼンテーションの役割って、ごく単純な型(プリミティブ型、String, Date)の整形のみだから、JSPはうってつけだと思う。
ここでいう「整形」とは、Bold書体にしたり、表示サイズを大きくしたり、値をレイアウトしたりすることね。

>>325
凄いレベルで一致したｹｺｰﾝですな

>>322
まぁ、ｱﾎﾟｰWOは半分冗談だけど。
(初代から、興味持って試行版ﾀﾞｳﾝしたり３年間出た本も買ったけど、結局放置。
チョブスの夢の後を追っかけだしたら、商売上がったりだからな)

むしろ、最近JBossの対応が話題になってる
AOP (アスペクト指向) について、
Java フレームワークに組み込む猛者がもっと出てきてホスィ
と思う６月の土曜日朝

324を読んで、
>>・サーバー(JSP実行環境)移行どうします？
変換後のservletソースやそれをコンパイルしたclassは、
アプリケーションルートの外にできあがる。
jspレベルで仕様が統一されていれば問題ないのでは？

って書こうと思ったけど、眠かったので次の日に書くことにした。

>>325 読んで
ｹｺｰﾝ系？

>>326 読んで
うわ、あまかった。世の中には結ばれるべき人達というのはいるのだな。
これはあの娘をあきらめろという暗示なのか・・・

サーバー移行とは違うのですが。

コマンドプロンプトからTomcatを起動している場合
正常に動作しているアプリケーションが、
NTサービスからTomcatを起動した場合は
「ドライバおよびソースが見つかりません。」
というログをはきやがります。

どういうことでしょうか。

DBを使わないものは正常に動作します。

>>320 もっともｽﾊﾞﾗｼｲネタは、日本IBMのSTXだろ。
えっ！？日本IBMってWACS以外にも日本製モドキあるんですね。

Perlでつくればレスポンス悪いだろう

ビューの作成方法について、JSP以外の解決策を知らない奴が、JSPは良いと思う
のは当たり前だと思うが、最高ってのはどうなんでしょうね。

ビュー作るのにWebObjectとかTapestryとかがやっているやり方とか、あるい
はApache-Cocoonがやっているやり方について、検討したことあるかえ？

知らないってのは幸せですな。

あぼーん

個人的には、JSPはWindowsASPの亡霊(ASP使いを取り込むための、
マーケティング優先の糞仕様)だと思っているので、はよなくなって
ほしい。

Jason HeightもArticle書いてるよ。生JSPは糞だって。

それ言い出したら、レガシー対応のJDBCやJ2EE Connector Architecture、
CGIをオブジェクト指向にしてスレッド対応しただけのServletも糞

>>337
話が全然ちゃうやんけ。
「Java上で」今まで他の環境でやっていたことを代替する手段を
提供するのは「Javaコミュニティにとって」必要不可欠。

JSPは、「Javaで」もっとましなやり方があるのでイラネ。

ついでに、呼ばれる度にプロセス再起動のCGIじゃなくて、プロセスは一つ、
呼ばれる度にスレッド割り当てて処理するっていう構造は、CGIより進ん
でいるので、Servletは糞でもなんでもないでしょ。

Perlで同じことやってもええと思うほ。現に、Rubyで同じことをやって
いる人はイッパイいるでそ。

>>332
↓STXね。
http://www-6.ibm.com/jp/software/websphere/developer/j2ee/struts/

JSPってどうにも性に合わない。構造がデブすぎ。やれっていわれりゃやるけどさぁ。JSP使ってる有名なサイトってどこ？

>>336
>Jason HeightもArticle書いてるよ。生JSPは糞だって。

それ読みたいんだが、ソースを教えてくれないかな。
「生JSP」と言うからには、もしJSPを使うのならこうしてこう使えみたいなことが書いてあると期待。

>>336
JSPを次のどっちの意味でとらえている？
　・スクリプトレットもばりばりに記述可能とする、Javaソース混在HTMLファイル
　・key=value程度に単純化された文字列を整形、レイアウトする機構
自分は後者としか考えていない。
だから、プレゼンテーションが何であろうがまったく気にしない。
「スキルがなくても修正可能なところ」をとらえてJSPは柔軟だと感じているのですよ。
Velocityとかでも全くかまわないけど、逆にまだ標準的に流布しているとは言いにくい。


自分がWebアプリをデザインするときも、JSPには「<%= obj.getName() %>」みたいなスクリプトレットしか書かせないし、
JSPに渡る時点までに、ある意味key=valueの文字列マップ状態にしてしまう。

Portalみたいなサービス志向コンポーネントを組み合わせるアーキテクチャは好きだし、
Cocoonみたくフィルタのチェイニング機構も大好き。

ただし。
ツールのサポートを常に使えるわけじゃない。
現時点で「だいたいにおいて標準といえるもの」くらいしか使わずに開発するのが顧客のためだ。
プロダクト依存はできる限り避けたい。
スキルのない技術者でも実装・メンテナンスできる技術で実装したい。
XSLT-Transformみたいな高価な処理をアプリケーションサーバでがしがし使うのはまだ不安だ。
(そろそろXSLTくらいは大丈夫かな)
保守の頃まで面倒見ていられない。


だから、JavaServerFacesには早く標準となってJ2EE仕様に含まれてくれることを期待している。

>>342
>JSPを次のどっちの意味でとらえている？
>　・スクリプトレットもばりばりに記述可能とする、Javaソース混在HTMLファイル
>　・key=value程度に単純化された文字列を整形、レイアウトする機構
>自分は後者としか考えていない。
>だから、プレゼンテーションが何であろうがまったく気にしない。
>「スキルがなくても修正可能なところ」をとらえてJSPは柔軟だと感じているのですよ。
>Velocityとかでも全くかまわないけど、逆にまだ標準的に流布しているとは言いにくい。

それなら同意。ただ、そういった制約を掛けているのが現状アプリ開発の現場
での約束によるもので、仕様ではないというところに問題を感じていたのでつ。

各々のアプリ開発者のレベルでキッチリそこまで約束が出来るなら、JSPでも
何ら問題ないだわ。

昔なんでもASPに書いてた馬鹿連中がなんでもJSPに書いて、メンテ
不能の糞を生産している現場が隣にあって、現在少々鬱なのでした。

二言目には「こんなことするカスタムタグつくってよ〜」
(ｵｲｵｲ、そりゃビジネスロジックの一部じゃネえのｶﾖ…)
MVC分離もヘッタクレもない、思慮0の連中は纏めて逝ってほしい。

>>341
ポインタ忘れた。米国ｵﾗｲﾘのどこかにおいてあったよ。
適当にｸﾞｸﾞｯﾃｸﾚ。

JSPで書きすぎなのがダメなんだろ？
いいじゃん枯れて来てるし、小さく書けばいいんだろ？
サイトの制約でいろいろ乗せられないとこもあるしさー。

>>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
　それやる能力があったら、
　みんなベンチャー作って独立してるって。

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

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

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

あぼーん

単一システムの開発を対象にしたフレームワークと、
複数システムの共有を対象にしたフレームワークでは、
思想から設計から何もかもが違ってくる。

特に運用まわりや障害対応のための情報収集機能、SingleSignOn機能との連携など、気にすべき点は多い。
こっちのほうがはるかに面白いが、商用製品として有名になることは少ないわな。
企業独自の環境や運用ポリシーと密接に絡む部分が大きくなるから。

技術的関心だけじゃシステムはつくれんわな。

>>438
論旨明瞭にしる

>>438
政治的な問題とかもあるしね。

>>438
食い扶持を支える金だな。

>>438-441
何でスレタイとずれた切れ方するのかなぁー？非論理的SE？

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

字句/構文パーサを手軽に素早く構築するためのバックグラウンド知識が不足してるんとちゃうかー。
大学一年生が書きそうな、ランダムロジックもどきのパーサを、力技で書く事想像してたりして(w

あぼーん

>>437
どっかで飽きるほど聞いた内容だと思ったら、あなたは・・・。

んで？JBoss4かSunOneで、AOPのお勉強でも始めたのかい(ｗ

あぼーん

てかstrutsとvelocity使えばいいじゃん。

あぼーん

Strutsを使ってアプリ独自のフレームワークを作ってからが本当の開発。

>>444
誰ですか？

JSP並のパーサを作ってる／作れる人なんて、見たことないよ。
俺の会社がそうなだけかもしれないけど。
そんなに簡単に作れる物なの?

>>450
おれの会社もそこまではいない。

>>448
大まかに言って、そんな感じの仕事が流行っている事は認めるが
「アプリ独自のフレームワーク」ってのが意味不明つーか自己矛盾だなー。

特定分野業務の
「アプリケーション・フレームワーク化」とか「業務フレームワーク」
っつうなら、それなりに意味あると思うけど。

特定分野の業務アプリについて、
業務アプリの「アプリケーション・フレームワーク化」とか
業務処理内容の「業務フレームワーク化」っつうなら、
それなりに意味あると思うけど。

>>442
いまどきyacc/lexまたはそのモドキをつかってパーサをかくなんて、よっぽど
暇じゃなきゃやらん、といっているだけだが。
低レベルの字句解析/構文解析は、作るのは簡単でも妥当性検証は偉く大変だぞ。
お前こそそっち方面で仕事したことあるのか？？？

>>452
俺は再利用性をあんまり考えないでフレームワーク作ることが
多いんだけど、そういうのってだめでしょうか。
アプリケーションに統一感を持たせたい、とか
まともにやっていると煩雑な処理をフレームワークで吸収して
開発を楽にしたりとか、再利用なくても
フレームワークを作るメリットってそれなりにあるんじゃないかと
思っているんですけど。

>>454
なんで物事をそこまで複雑化して妄想するかな。
JSPの文法/仕様って、「妥当性検証」が必須になるほど複雑か？
チェックすべきポイントの具体例を上げてみて下さい。

>>455
最近はそーゆーのあんま推奨されないみたいねぇー。
でも、開発スタイルは人それぞれ、の部分があるから、
もしもそーゆーやり方が許されてるなら、
それを追求すればいいんじゃない？

漏れは「フレームワーク」と「再利用」を直結させるのはマズイ戦略だと思うし、
リファクタリング的手法でフレームワーク構築していくのは好きだけど。

さりげなくあげ。

あぼーん

turbineじゃだめなの？

>>456
ごめん、良く考えてなかった。
JSPパーサって、単にJSPの構文をパースしてJavaのソースを吐けば
いいだけなんだね。はいたソースがちゃんとコンパイルできるかどう
か、あるいはちゃんと動くかどうかについて責任をとる必要ないん
だった。

…ほんとにそれでいいのかな？と思うけどね。

NTTの若手社員が会社の不正経理、ドロドロの内紛を赤裸々に内部告発！
http://jbbs.shitaraba.com/business/216/
　　　　　　　　　　　　

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

今日はここまでは山崎荒らしは来ませんでしたｗ

今のところ NIT の Salsa が最高。

ジェネシスって聞いたことある人います？

>>464

その名前は聞いたことあるぞ。Strutsベースの自社製F/Wだったけか…

アプリケーションフレームワークが
strutsだろうが、turbineだろうがなんでもいいのよ。

もんだいはドメインフレームワークがつくれないってこと
なんだとおもうけど。

要求仕様がふにゃふにゃしているところで
どれだけ精度のたかいドメインフレームワークが
つくれるかだとおもう。

大規模で。

反復型開発しなきゃいかんだろうけど、
客がついてこない。
教育しつつ、だったら客寄せパンダのような
思いっきりできる人に神の声を
だしてもらうひつようがあるかも..

EJBをドメインフレームワークといってしまうのはありですか？

ドメインフレームワークって、モノになった事例って存在するの？
例えばIBM SanFransiscoとかで業務ＡＰ組んで、効率化図れた事例とかあるのでしょうか。

要求仕様のブレ幅を考えると、まず実現不能だと思うのですが

>>469 厨房ﾊｯｹｿ
ERPとかパッケージ製品で、独自言語でビジネス・オブジェクト階層提供してるヤシは、
ドメインフレームワークに数えないんだろうか？
C++とかJavaじゃないと、フレームワークとはみなさないとか（ｗ
だからって、ABAPプログラマーになりたいとは思わんが（ｗ

CERNとか、素粒子実験の解析＆シミュレーション用に、
オブジェクト指向の数値計算ライブラリ〜クラスライブラリを構築してるけど、
あれは「事務処理」じゃないから「ドメイン・フレームワーク」に入れないとか（ｗ

数式処理システムなんかも、
数式を記号処理するためのドメイン・フレームワーク
といえるものを、３０年も前から構築しているわけだが（ｗ

結局 >>469 は、
「オブジェクト指向で再利用」を提唱しながら、
自分ではろくすっぽコードも書けず、フレームワークも設計できず、
自分が無能と謗られると「ドメイン・フレームワークの成功例などないっ！」
って言い訳する、駄目駄目(自称)コンサルじゃないかな？

おまいみたいな奴が業界にぶら下がってるから、業界の信用が低下するんだよ。
さっさと回線切って、LANケーブルで首釣っちまえ！

21世紀にもなって、ナイーブな発言をする>>469は、死滅ですか？

>>450-451,>>461 晒し上げ
あと、>>461 それでいーんだよ、プリ・プロセッサの手軽さを維持するためには。


[450]非決定性名無しさん<sage>
03/07/03 00:03
JSP並のパーサを作ってる／作れる人なんて、見たことないよ。
俺の会社がそうなだけかもしれないけど。
そんなに簡単に作れる物なの?

[451]非決定性名無しさん<>
03/07/03 02:00
>>450
おれの会社もそこまではいない。

[460]非決定性名無しさん<>
03/07/04 23:57
>>456
ごめん、良く考えてなかった。
JSPパーサって、単にJSPの構文をパースしてJavaのソースを吐けば
いいだけなんだね。はいたソースがちゃんとコンパイルできるかどう
か、あるいはちゃんと動くかどうかについて責任をとる必要ないん
だった。

…ほんとにそれでいいのかな？と思うけどね。

>>474
あほか。JSPはデバッグが苦痛だ。
EcilpseなどのIDEでデバッグを経験したことが少しでもあるマトモなJava
開発者なら、なにを好き好んでそんな「靴の上から水虫を掻く」ような真似
せにゃナランのじゃ、と思うはず。

JSPは、生産性を向上するのにあまり役に立ってないと思うぞ。
動かすまでは簡単だが。デバッグとテストとメンテはつらい。
これからJavaでWeb鯖システム作る奴は、悪いこといわないから
JSFにしとけ。

>>475-476
ふーん。よかったね。
おまえ、ゆりかもめ沿線企業のJavaWorld厨みたいだな（ｗ
過去の話とこれからの話を区別できない厨がナニを言っても、
説得力をもたないよ（ｗ

>>477
だから情報システム板はレベルがアレだと・・・(rya

>>476 JSPは、生産性を向上するのにあまり役に立ってないと思うぞ。

ふーん、そんな主張をしている人がいるとは　はつみみ　です

情報システム板は、コーディングもフレームワークもロクにできない
なんちゃってSEの溜まり場だからなー

きっと、　　
・今すぐ使える技術範囲と、
・今すぐは使えないけど独自技術でカバーできる範囲と、
・将来使えるかもしれんが、あまり多勢に影響を与えない範囲
の切り分けもできない屑なんだろうな

>>475
経歴の浅さがヴぁれヴぁれですな。C言語もそうなんだよ、知らなかったかい（ｗ
JSP出力Javaソース行と、
JSPソースコード行の
対応関係情報を出力するように、
JSP仕様なり処理系なりを拡張すれば、
C言語なみのデバッグは可能になると思うが。
それ以前に、JSPとJavaソースの対応関係を頭で考えられないタコは、
JSPのデバッグすべきではないと思う。

つまり、JSPの処理系くらいサラっと作れる技術者がいない企業は、
今後の新技術導入に際しても永遠に負け組みｹﾃｰｲ、って事だ（ｗｗｗ

あと、これからJSP処理系作るとか言い出すSEが仮に居たら、
そいつもかなりアレなんで要注意

＞＞４８２
Lispのマクロ展開も、時として非常に難解だよなー。

マジメにソフトウェアに関わってる人間にとって、
そんなの当たり前の話であって、
それを今更、鬼の首でも取ったようにあげつらう>>475は、
きっと十分な教育を受ける機会がなかったんだろう・・・合掌

>>482
>JSPソースコード行の 対応関係情報を出力するように、
>JSP仕様なり処理系なりを拡張すれば、 C言語なみの
>デバッグは可能になると思うが。
「作れば」可能だということぐらいは理解してるつもりだったが…
今更、寿命もさして長くない処理系を自作したくないだけだったよ。

>つまり、JSPの処理系くらいサラっと作れる技術者がいない企業は、
>今後の新技術導入に際しても永遠に負け組みｹﾃｰｲ、って事だ（ｗｗｗ
そんなに簡単なのか。今の勤務先は、俺も含めて負け組みだ（ｳｴｰﾝ

>>486
君にそーゆーの作る力があるかどうかは不明なわけだが。

閑話休題
ドメイン・フレームワークの話はどこ行ったんだ？

ドメイン・フレームワーク・・・

Jakarta厨にとっては、
ドメイン・フレームワークってのも、apache.org周辺の人が、
自分の担当する業界用にオープン・ソースで作ってくれて、
自分はそれを使うだけでボロい商売ができる
「公共資源」って認識なんじゃないかな。

自分の担当する業界のフレームワークくらい、自分で作れよ（ｗ
それができないんだったら、ORCAとか、業界統一フレームワーク(?)がある業界に仕事替えしろ（W

あぼーん

ドメイン・フレームワークくんでみたんだが、
なんかアプリケーションフレームワーク上に
アプリケーションフレームワーク組んでる状態に
陥りそうになってなんどもモデルをちゃらしてしまった。

自分の力不足は当然だが、
どうも業務モデルから、細かい実装まで理解してないと
まともな物ができないんじゃないかとおもっている。

これができるのが、アーキテクトってことなのか。

あぼーん

あとERPなどをドメインモデルの解決方法
という考え方もあるけど、
実際のドメインってのが
ERPベンダが売りやすくするには
という問題領域の解決によっていて
それを営業が隠して売ってるようにもみえる。

ERP ではないけど Siebel のアーキテクチャを
勉強してそうおもった。
よくできてるけど、やっぱりこのソフト
ユーザではなく自社に風見鶏が向いてるっておもう。

ユーザは、それを承知で使っているのかは
きになるところ。

あと、ドメインを業界統一ととらえるかと、
たとえばあるユーザ企業の抱える問題領域
（わたしはこっちにとった）
にとらえるかで、
議論は分散してしまうかも。

なんか、包含関係にあるものを別物であるかのように語っていて、萎えた。

ドメイン・フレームワークも重要だけど、
アーキテクチャ・フレームワークも最近ようやく次世代に移行しつつあるのねぇ。

JSFは未勉強だが、
三年以上前に格闘してたAOSD、XForms、Portlet、なんて所が、
よーやく雑誌じゃヴぁわーるど　で特集されてるのを見てニヤーリ。

じゃヴぁ・わーるど　も所詮、標準化＆普及後に後追いする雑誌だもんな、しょーがねぇよな

JSFをこの時期にとりあげたのは、今までの流れからすれば頑張ったほうじゃない？
確かRIはまだEA版が出されてるだけだよね？

偏執会議で、ネタに優劣付けて優先順位決めてるか、はたまたライターが偏ってるんだろうな。
＃標準化作業前の技術や、JSR段階で実装例も出てない技術を、
＃記事にまで膨らませられるヤシは少ないだろうし。

>>494
JSF,XForms,Portlet
　　どれも、Webクライアントのユーザ・インターフェース関連技術で、
　　面白みがないな（ｗ
俺にとっては、どーでもいい話題だ・・・

>>498
そんなこと言ってないでもうちょっと掘り下げてみなよ。
例えばJSF。本質をとらえれば面白みが見えてくるよ。

そーゆー貴方は、こちらへどーぞ
【UI FW】Java Server Facesと戯れるスレ【ﾏﾀｰﾘ】
　http://science.2ch.net/test/read.cgi/infosys/1060502160/

1 ：非決定性名無しさん ：03/08/10 16:56
Java Server Facesってどうよ。

自分の手で実際に試したヤシが、
感想や課題などをレポートするスレ。

煽り、荒らし等には、徹底した放置で、ﾏﾀｰﾘとおながいします。

＃ホームページ一ページ訳しただけで、放置状態でつが・・・

あぼーん

>>494,>>498-499
入力データ検証とか Portletの話題は、
結構早い時期に、記事で触れてたよ

ってーか、初物食いすりゃーいいってもんでもないでしょ

JSF。

・UIコンポーネントの外観を提供し、またその状態を管理するAPI
つうのは、携帯電話用コンテンツ変換ｹﾞｰﾄｳｪｲやら、Web Swing (名前不正確)で、
大分前から出てたな。それをJSRが標準化しただけ。

・イベントのハンドリングと、入力データ検証をするAPI
分散MVCとかMVC typeII以来の流れだなー。
なんか新しい技術要素とか、シンプルで素晴らしい設計とか、あるの？

>>476 ：475 ：03/08/05 00:19
＞JSPは、生産性を向上するのにあまり役に立ってないと思うぞ。
＞動かすまでは簡単だが。デバッグとテストとメンテはつらい。
＞これからJavaでWeb鯖システム作る奴は、悪いこといわないから
＞JSFにしとけ。

Servlet→JSP→JSF って、
無茶苦茶連続性ある技術やん。
なんで別物であるかのような嘘を書くの？

>>475 晒し上げ

>>504
ServletとJSPとの連続性は疑問だなあ。
かなり無茶してるし。

少なくとも、JSPは苦手・・・。

>>505
おっしゃる意味がよくわかりません。
可能なら、詳しく説明して頂けないでしょうか？

＃ServletとJSPって、内と外をひっくり返しただけの関係なんだよな

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

>>506
JSPはASPをパクっただけかと。
Servletとの関係は、Servletに変換・コンパイルされるというだけ。
そういう意味で、連続性に疑問と書いた。

で、「内と外をひっくり返しただけの関係」とは？

>>508
こんな感じだろ。

ServletでもPerlでも、HTMLコンテンツを一々
printメソッド呼び出しに文字列として記述するのは、記述性が悪くて激しく面倒
　↓
表示データを、テンプレートとか表示体(死語)として分離記述すれば、
記述性は向上。しかしコードとデータの対応関係が自明ではなく、管理が面倒
　↓
「XXXX Server Page」の誕生
・MVC または　Document-Viewのフレームワークを前提に、管理の合理化を検討。
・HTMLコンテンツはView部に記述するはず。
・View部は、表示データ量は多いが、
　コードの記述量はさほど多くないはず。
・と、ゆーか、コードには主に制御構造書く程度にして、
　複雑な機能はModelやDocumentに相当する外部コンポーネントに分離記述しよう。
→分量の少ないコードの方を囲って(quoteして)しまえ。←これが【ひっくりかえした】ということ。
　〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
　quote方法は、htmlのタグ形式を適当に拡張しちまおう。(当時はまだXMLが普及してなかったから)

　↓
「TagLibの誕生」
・Server Page は(XML以前に仕様が決められたから)、
　簡単なタグ記述で、複雑な機能を呼び出す「抽象化機能」が足りない。
・XMLを使ってServerPageを拡張しよう！
・しかしXMLは中立なデータ構造に過ぎないから、
　コードとの対応関係を定める取っ掛かりがないなぁ
　(当時は)まだXML関連の標準も、流動的だし。
→taglib用の名前空間とマッピング規則を決め、
　taglib形式で機能記述するフレームワークを作ろう！
→taglibライブラリの標準化は、
　ベンダーが試行錯誤してから決めよう(→STL)

　↓
そして「JSF誕生」
・JavaのWebアプリ向けフレームワークは、
　MVC type2で決まりだな
・じゃぁ、そろそろMVC type2向けフレームワークの標準化
　でも始めるか
・View部は当然、JSPとTagLibベースで行こう
・今のフレームワークの機能要求水準は、こんな感じかな(Struts等眺めて)
　・イベント・ソースとハンドラーの自由な接続
　・Viewとアプリケーション・データソースの自由な接続
　・画面遷移、ページ・ナビゲーションのサポートも必要だ
　・多種多様なモバイル機器に対応するためには、
　　画面表示の抽象化と、具体的なデバイスへの翻訳機構が必要だな
　　このあたりもTagLibで記述させよう・・・
・・・以下、面倒だから略

んー、煽りにﾏｼﾞﾚｽしまくるのは疲れるなぁー。
要するに
　Servlet ： コードが本文、データは引用　として記述
　JSP　　　：　データが本文、コードは引用　として記述
ってのが「内と外をひっくり返しただけの関係」なわけ。
JSPservlet作ってみれば、実感できる。
これでServlet→JSPへの発展に連続性がある事を説明できた、と。

次はJSP→JSFへの発展の連続性を、誰か説明しる！

>>512
煽りじゃないんだけどね・・・。

まあ、「ひっくりかえした」という表現でいいたいことは理解したよ。
PerlのCGIとPHPとの関係みたいなもんだな。

あと、Servlet から JSPが生まれた経緯も理解した。
たぶん、キミの言っている「連続性」もわかったよ。

とはいえ、発展の仕方はイマイチだったよなあ・・・。
すごく無理に無理を重ねているように思えるよ。
JSPはMVCモデルとしては大失敗だと思っている。
(ASPも同様。)

素直にテンプレートにするか(WebMacro, Velocity)
コンポーネントにするか(Tapestry)
どちらかにすりゃよかったのに・・・。

>>493
>>なんか、包含関係にあるものを別物であるかのように語っていて、萎えた。


たとえばERPの人事モジュールをつかうことと、
人事システムを構築することは包含関係かと考えたが、
一見包含しているようにも見えるけど、
情報システムに対する効果を考えると
ちがうんではない？
とおれはおもうのだけど。

萎えちゃったのは、もうしわけない。

Webサービスだとか、Strutsだとかを語っていって
情報システムの本質について真っ向から議論しないと
アーキテクトとしての体力がこれ以上ついていかないとおもうのだけど。

サイエンス系なんで、あまり事務処理系には突っ込みたくないんでつ。
サイエンス系ベンチャー企業の業務システム支援とかなら、
多少興味持てるとは思うんだけど・・・従来の中小企業向けシステムをそのまま導入するのが良いことなのか悪いことなのか、判断できていないから、当座は避けておきたいでつ

↑いちおう
×業務システム支援
○業務支援システム

＃ＰＤＡ用日本語変換システムが、勝手に単語を補完してしまつた。。。

と、ゆーか、フレームワーク化なんて、必要性を認めた人間が主体的に模索して、構築なり標準化していくべきもの。
業務系フレームワークに、これっぽっちも興味がない漏れが口出しすべきジャンルではないのでつ。

＃フレームワーク構築用フレームワークとか、メタな話ならがぜん興味あるけどね。
＃業務システム構築・・・多分一生やらねぇだろうなー

というような、泥臭い部分を他人任せにするよな姿勢が、
世間一般の研究開発部門では、ありがち。
そしてそれは、しょうがない事だと思う。

アーキテクトがフレームワークという桃源郷を示して
まがりなりにも業務SEを誘惑して見せたんだから、
その実態に文句を言うばかりじゃなく、
今度は業務SEが業務系システムのドメイン・フレームワーク化の魅力を示して、
アーキテクトを誘惑する番なのではないか？

お客さんやプロジェクト・メンバーに対しては、
いつもやってることだよね？
不平不満ばっかで、魅力あるビジョンを示せないＳＥには、
誰もついて行かないと思うけど。。。

てなわけで、ほれ頑張れ！！！

>>513
JSPは、政治的な理由（ASP使いをJava陣営に引き抜く）で誕生した
ある意味いかがわしい技術ですよ。

メジャーになってしまって引っ込みつかないですが。

何故にそこまでJSPを目の仇にしたいのか、
あんたの主旨が全然理解できますぇーん。
JSFもJSPベースな訳だし（ｗ
Tapestryと言わず、WebObjectsやりゃーいーじゃん。

つべこべ言わず、業務ＳＥ発ドメイン・フレームワーク提案でも練れ！

>>519
そうだねえ・・・。
そして、Sun はまた同じ轍を踏もうとしている・・・。
Java 開発者を 1000万人にしたいって・・・。
無茶はやめてけれ。

>>520
誰に対するレスなのかわからんけどｗ
あんた、JSP 信者？
それとも、雑誌に洗脳された JSP 初心者？

やれやれ、だからこの板はレベルが（ｗ

劣っている人間にも二種類居て、
優れた人間の発言に耳を貸し、自分との違いを冷静に分析できる人と、
ちょっとした仮定や歴史的経緯に目もくれず、ひたすら相手を叩き、成長の機会を踏みにじる人と、
二種類居るようだね。そして、>>521君は間違いなく後者だな。井の中の蛙の煽りくんよぉ（ｗｗｗ

このスレにも>>521みたいな基地外が平気でレス付けるようになっちまった。
この板、もう役に立たねぇな。後は、ＯＯ2003シンポジウムのレポートするヤシが来るのを待つ事にするか

>>519
そーゆーのは「営業上の理由」と言う。
「政治的理由」っつうのは例えば、
SunがIBMを味方に付ける為に、IBMの企業システム部門の戦略を渋々受け入れる
ような事を指すんだよ。

田舎に居ると言語感覚まで麻痺しちまうんかぃ（ｗ

>>513
そもそも MVC type2誕生の経緯を生暖かい目で見守っていた俺としては、
WebにMVC当てはめようとするIBMの感覚こそ、センス悪いと思うが（ｗ
オリジナルSmalltalkのMVCとは、
通信・表示機構が全然違うWeb上で、
MVCを主張するというのは、木に竹を繋ぐような無理のある話。
それに飛びつく開発者も逝かれていると思うし、
Web MVCがなかなか成熟せず、複雑化して混乱を招いているのもむべなるかな（ｗ

もっとシンプルな解決策を模索すべきだと、俺は思うよ。

ってな議論は、この板でも数年前にやったんだけど（ぷ

まぁ、人の揚げ足鳥に終始して、本質的な議論をいつまでたっても始めない厨房相手にするのは、時間の無駄だったな

キチガイというやつもキチガイかもｗ

ここからは、>>520の駄目さ加減を語るスレになりましたｗ

× MVC type2
○ MVC model2
なのな。。。
語源になったJSP 0.96のドキュメントは、既に闇の彼方へ消え、
世間一般でMVC＝MVC model2 て事になってるのね

ドメイン・フレームワークはどうなった？

アダプティブ・オブジェクトモデルはどうよ？
きっとアナパタの亡霊を見そうな気がするが（ｗ

あぼーん

>>530
なんか今日午後チュートリアルがあるみたい

>>513
＞JSPはMVCモデルとしては大失敗だと思っている。
＞(ASPも同様。)

ﾔﾚﾔﾚ、MVC至上主義者がまた一人…
JSPはMVCを前提としてる訳ではないでそ。
MVCっぽく使うとしたらこーなる、って例としてMVC model2を出しただけで。

MVC type2って、名前はMVCだけどようするに
プレゼンテーションとビジネスロジックをきっちり
分けましょうってだけのことでしょ。
シンプルでいいアーキテクチャだと思うぞ。何が失敗なの？

>>533
そういうキミは、カッコいい画面もつくれるし、素晴らしいロジックも
組めるんでしょうね・・・うらやましいよ（ｗ

>>534
JSP が MVC type2 に適用するのに全く向いてないという点で、失敗なんだよ。

>535
> JSP が MVC type2 に適用するのに全く向いてないという点で、失敗なんだよ。

よろしければ、何故、どの様な点が向いていないのかを、解説していただけませんか？

また、MVC に向いているプレゼンテーションレイヤのアーキテクチャは何とお考えですか？

2chでも、フレームワーク作っているという人たちは多いけど
Struts以上のフレームワークを出す自信があるのだろーか。
そこんところの率直な意見、キボンヌ

Strutsの優位点は、優れている事ではなく、デファクト・スタンダードに地位に付けた事。
そこがわかっていない >>537 のフレームワークは、きっとすばらしく普及阻害要因だらけなんだろうなぁ

基礎のものは大体いい感じで信頼性の高いソフトが
出てきたから、ここらで業務ソフトでも信頼性の高い
ソフトを作らなきゃいかんよね。

で、さしあたって、人事や会計のソフトをオープンソース
で作ってはどうよと思ってるんだが、そういうのをやってる
っていう人は他にいるかしら。

JSPは、

　　Presentation-Logic-Storage (PLS)アーキテクチャ　
　　(いわゆる3tears)。

DBMSベンダーの唯我独尊アーキテクチャなのら。
プレゼンテーションだロジックだ言い出した奴は、
DQNなDOA屋ｹﾃｰｲ

>>540
アプリケーションの 3-tiers アーキテクチャというと、
　・プレゼンテーション
　・アプリケーションロジック
　・データモデル
　・データインタフェース
と分けると思っていたんだが。
Storage(= データベース)はこの中に含まれない。

これは Martin Fowler『アナリシスパターン』で紹介されてた呼び方に準じているのだが、
3-tiersの説明でいちばんしっくりくるのがこれだった。

んで、Fowler はこんなことを薦めている。
　アプリケーションロジックとプレゼンテーションの間に、
　プレゼンテーションごとのFacadeを配置するのが望ましい。

C/S全盛の頃の話だが、今でも変わらぬ原則だと思うんだが。


プレゼンテーションとロジックの分離が、
タグライブラリだけでもまだ不足しているという意見なら同意。

そういう基礎的なところはいいんだけど。



SAPやらInterstageやらなにやら「フレームワークで高信頼性・短期納期を実現」
とかなんとか、（理屈は分かるし今後数十年はそういう流れになってくとは思うが）
今のカタログとか見てみると、幻想を売ってるだけじゃねーかと思うようなもんばかり
なんだよな。

漏れの認識では、幻想を売ってうまいこといっているから、幻想が具現化するのも
十年後くらいにはなんとかなりそうで、そのときには他のプラットフォームは追いつ
けない状況になってそう。

ってことは、今の「重要な価値（ノウハウ）は個人のプログラマに積み重ねられている」という状況から
「大きな企業が価値を持つ」という方向になっていっていくわけで、これは望ましい変化だと思う。

大きい企業が価値を持つ、というよりは、ちゃんとトップが「企業」に価値を持たせようとすれば
それが報われる状況になるということで。それは単に（本当に多いパターンの）単に社員を働か
せて経営陣が搾取するだけのＳＩ企業を淘汰していくようになるから、これはよいことだ。

> 単に社員を働かせて経営陣が搾取するだけのＳＩ企業

なんだそりゃ？
北朝鮮か？

Httpベースのサバクラシステムは、そもそもMVCに向いていないという罠。

>>546
>>370に書いたんだが。

>>545

IT業は人月ビジネス。人を貸してりゃ稼げるイージーな経営が嫌いなだけ。

>>547
妄想議論ｲｸﾅｲ

370 名前： 非決定性名無しさん 投稿日： 03/06/15 16:06

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

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

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

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


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

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

>>550
いい書き込みだ。すばらしい。
でもデジタル署名って、内容が改ざんされていないことは保証できても
データが妥当かどうかの保証ってできないんじゃないかな？
やっぱりデータを受け入れる側でのチェックは必要だよ。

おれとしては、どのみちサーバー側でデータの妥当性を検証する必要が
あると思う。どちらかというと、サーバー側での妥当性検証を省くので
はなく、クライアント側とサーバー側とで妥当性検証のロジックを共通
化する方向を検討したい。

クライアント側での妥当性検証は、実際のところJavaScriptでやるしか
ない。ということは、サーバー側で同じJavaScriptを実行してやれば、
妥当性検証ロジックが共通化できるということだ。

今までは、クライアント側はJavaScripで、サーバー側はPHPやらPerl
やらで書いていたから2度手間だしメンテナンスが大変だった。
しかしサーバー側でJavaScripを実行すれば、そんな面倒から解放される。
サーバーサイドJavaScript万歳！

・・・妄想かなー。結構いいと思うんだけど。

>>550
普通にクライアントはJavaアプリでだめですか？
状態維持だって暗号化だって自由自在。

>>552
Flashアプリでだめですか？

>>551
脳味噌イカレてるんでないか

WACの酷さにビビッた。
史上最低です。

訂正
×WAC
○WACS

>>551
別にサーバ側JavaScriptに拘らなくても、
XML Schemeから、値チェック用コードを二種類生成して
クライアント側とサーバ側で実行してやれば良いではないか
と書いてみるバリデーション

>551
>557
ていうか，struts validatorがもうすでに
client side, server side両方，ひとつの定義ファイルからやってくれるのだが．
ご存知？

>>556

具体的に最低なところをきぼんぬ
アンチパターン化すれ

>>550 は
たとえC/S別々のコードが自動生成されたところでHTTPを通ってしまえば何の意味もない
みたいな意味では？

しかしこの分野も停滞甚だしいな。
数年前やってた事と、strutsと、ほとんど一緒（ｗ

>>557,558
それは値チェックが単純な場合のみだよね？
値が整数であるとか、メールアドレスであるとか、最大値と最小値ぐらいしか
制限がない場合とか。
値チェックがもっと複雑になると、宣言的な記述では難しく、どうしても
プログラムを書いてチェックを行うしかない。
そうなると、そのプログラムは結局なんらかの言語で書くしかないんだよね。

例えばだな、3つの数値を入力してもらって、その合計が100以下であることを
チェックしたいとしよう。それはStrutsでも簡単にできる？
設定ファイルにちょこちょこっと記述したら、サーバーサイドとクライアント
サイドの両方のコードを生成してくれる？
できるのかなー。ちょっと調べてみよう。

>>560
さりげなくいいフォローしてくれてたね。ありがと。

通常のアプリケーションでは、ユーザからの入力をうけとる部分と
それを処理する部分が同じだから、入力チェックは１回でいい。
しかしクライアント・サーバ型だと、入力をうけとる部分（クライ
アント）とそれを処理する部分（サーバ）が分かれている。
よってクライアントが本当に信用できるという保証がないかぎり、
サーバ側でも入力チェックはしないといけないよね。

そうだな、例えるなら発注した品物をお店が受取り検査するような
もんかな。
発注先でも品質検査はやっているだろうが、それでも受け取るほう
でも検査はしないとだめだようね。
こんなたとえでわかってもらえるかなー。

>>562

はぁ？なんか、基礎のできていない素人さん出現ですか？
XML Schemeで表現しにくい範囲型なら、
OCLあたりで制約条件書いてvalidatorでチェック、
つうのが妥当じゃないかな。
OCLで宣言的に範囲書くのも難しいんなら、
プログラム記述言語で書かれた判定メソッド呼び出してチェックするとか、
静的に範囲チェックを行うのが難しいなら、例外ハンドラーと関連づけるとか
(この場合必ずしも事前チェックの意味をなさないが)、
いくらでも手はあるでしょ。

一体 >>562 は、何を主張したいの？

>>563
これも意味不明。
クライアント側での値範囲チェックは、
通信遅延の大きなネットワークを介さずに、
小回りの効くローカル処理で、インタラクティブなエラー修正をさせたい、
って意図で、設けられているんだよ。

碩学の>>563には、想像もできないんだろうけど？？？

>>563
礼を言われておいてナンなんだけど、
>>550 の主眼は
　「信頼できる検査処理」をWebブラウザへ委譲できなきゃ意味がない。
ということだよ。

まっとうなシステムならば、サーバー側での検査は全項目について行われる。
そのうちの任意項目についてはクライアント側でも行われる(>>565 のような理由で)。
逆に、DBの参照制約違反みたくサーバー側でしか実施できない処理もある。

このとき同種の処理について2種類のコードを書かなきゃならないところを、
Struts はXMLスキーマで共通化させている。
開発者が楽をするためのまっとうな方向だとは思う。

ただし、どのみち従来と変わらずHTTPを通ってしまうのだから、
フレームワークとしては進化していてもアーキテクチャとしては変わっていない。
もっと気軽にPKIが使えるよう広まってくれないかなあ。

>>566
＞　「信頼できる検査処理」をWebブラウザへ委譲できなきゃ意味がない。

はぁー。
鶏をさばくのに牛刀、ってな感じがしないでもないですが。
ECの与信処理、決済処理みたく、秘匿性と改竄耐性のある分散処理が必要な
フォーム・データって、そんなに多いんですかねぇ。

そこまで重要なフォーム・データなら、
ふつーSSL経由で ActiveX or Java {Applet|Application} (ryaku

つか、要するに、
WS Security 系統の規格を充実させて、
(ファットな)クライアント側で使えるようにしてほしい、
って所か。

ウチの昔の上司みたいなネタ振りだな。

既にトップベンダー各社が揃い踏みで必死で標準化してる分野に薀蓄垂れて、
寿命の短いニッチなソリューションを、ハイテクのごとく客に売り込む輩

×ニッチなソリューション
○非標準でローカルなソリューション

>>569
国内ベンダーでも、標準化活動を随分してるらしいけど、
それですら、標準化による勝算のない、技術的検討活動への参加
でしかないらしいよ。

ましてや、標準化動向とは無関係な、中途半端なローカルなソリューションを提案されても（汗
草の根活動とか大切だけど、どーせなら、標準化のなされていない分野で、
正々堂々と勝負すればいいのにねぇー

>>566
＞>>550 の主眼は
＞　「信頼できる検査処理」をWebブラウザへ委譲できなきゃ意味がない。
＞ということだよ。

「Webブラウザへ委譲できなきゃ意味が無い」って、どーゆー価値観に基づく判断なのだろう。
そもそも、Webブラウザ側に、
プレゼンテーション処理と入出力処理を全部委譲する事すら現実的ではないのに。
Ｍ＄に右へ倣えで、ファット・クライアント・マンセーとかするつもりでつか？

クライアントの重量法則
　クライアント環境の流行は、数年おきに、
　軽量マンセーになったり、重量級マンセーになったりする。
　しかし、流行が軽重どちらに流れようと、
　顧客の財布は軽くなる一方である。

>567
どうでもいいが重要なデータに
セキュリティぼろぼろのactiveXを
使うというのは何の冗談だ？

揚げ足鶏好きだな（ｗ

Ｍ＄のファット・クライアントとでも書き直せば、
君の下卑た揚げ足鶏精神を満たす事ができるかどうか・・・。

>>575
この板の粘着は、
・ＪＳＦはＪＳＰではない、とか、
・ＳｅｒｖｌｅｔとＪＳＰは連続性がない、とか、
出鱈目なレッテル張りするだけの厨房だから、
いちいち上げ足取りの相手をする必要ないよ。

ところで、>>382=>>355と、>>566読み返してみて、気付いたのだが。

この板の自称ＳＥさんは、
　「HTTPみたいな軽量プロトコル使う以上、
　　サーバ側にクライアントを操作するためのクライアント・ピア・オブジェクトが必要になる」
という事実を理解できていないように感じる。

＃ここでピア・オブジェクトと言ってるのは、
＃テンプレートだったり、サーバ・ページだったり、
＃あるいはDOMだったり、色々な形態を取るけどね。

普通にMVCをネットワーク経由に拡張しようとすると、
まずぶち当たる問題なんだけどね

サーバ上のピア・オブジェクトを無視したいのなら、
ファット・クライアントに走るのも良いかもねぇー（ニコニコ

あるいは、新世代のシン・クライアントとして、
SOAPを喋れて、記述がHTML並に簡単な、SOAPブラウザー
とか開発したら、もしかすると売れるかもよ（ニタニタ

よし、SOAPを喋れるSOAPletとか、i-SOAppli とか作るぞー

>>574
どうでもいいが重要なデータに
セキュリティぼろぼろのWinサーバを
使うという冗談が好きな人も多いんだから、、、

>この板の自称ＳＥさんは、
>　「HTTPみたいな軽量プロトコル使う以上、
>　　サーバ側にクライアントを操作するためのクライアント・ピア・オブジェクトが必要になる」
>という事実を理解できていないように感じる。

そんな馬鹿いたか？どのへん？

ファットクライアントとサーバ間でメッセージパッシングし合ってぱっつんぱっつん

でもえーじゃないか

じゃあいい加減、
ドメインフレームワークに議論を絞るって方向で。
以降、クライアント周りフレームワークは無視ってことで
よろしく。

レスの数が増えれば増えるほど、レベルが低下する掲示板はここでつか？

>>564
なんか話ずれてない？
おれは、
・どうせクライアント側とサーバー側とで同じように値チェックを行わないと
　いけないんなら、両方で違う言語のプログラムを書くんじゃなくて、
　両方とも同じ言語(JavaScript)で書いて実行できればいいんじゃない？
という話をした。

それにたいしてあんたが
・XML Schemeから、値チェック用コードを二種類生成して
　クライアント側とサーバ側で実行してやれば良いではないか
と書いた。このアイデアはいいと思うし、実際Strutsで行われていることも
知っている。

だけどこの方法にも限界があって、
・単純な値チェックならそれでもいいけど、複雑な値チェックはどうしても
　なんらかのプログラム言語で書かないといけないよね
と書いた。つまり結局はプログラミングをなくすことはできない。
だから最初の問題（クライアント側とサーバ側とで別々のプログラムを
用意しなくてはいけないこと）は解決されていないことになる。

そしたらあんた、
・OCLで宣言的に範囲書くのも難しいんなら
　プログラム記述言語で書かれた判定メソッド呼び出してチェックする
これって意味ないじゃん。
制約条件を宣言的に記述するだけでいろんな言語のプログラムを自動的に
生成できることに、あんたの主張の意味があるんじゃないの？
結局プログラムを作成しなきゃいけないんだったら、最初の問題の解決に
なってないじゃん。

おれはあんたが何を主張したいのかわからないよ。

>>564
つーかさ、人を「基礎のできていない素人さん」呼ばわりしといて
「XML Scheme」はないんでない？
557と564の両方で使っているから、typoじゃないよね。
まあおれはOCL知らない素人だけど。
それともXMLをSchemeに変換して実行でもするのかね？
＃そういやそんな研究もあったなあ。

>585-586
熱くなるのもいいが、２ちゃんで特定の相手を
「あんた」呼ばわりするような反論の書き方は
いかがなものかと思うので、少し冷静になれや。

こういうのは第三者に説得力を持たせることが重要よ。

ちなみに漏れは564でも何でもない通りすがりの人だよ。

>>565
ことの発端となった550を読んで見ろよ。
> 上述した「検査」をWebブラウザに委譲できない限り、アーキテクチャの質的な変化はないと思う
と書いてあるだろ。
おれは、それは無理だ、Webブラウザ（クライアント側）でどんなにチェックを
行っても、サーバ側でも同じようにチェックをしなきゃいけないぞ、ってことを
563で書いたんだよ。

つまり今問題にしているのは「クライアント側でチェックすればサーバ側での
チェックは不要か否か」であって、「クライアント側でチェックを行う目的は
何か？」ではないんだけど。

しかしあんたも小難しい言葉知ってるねえ。『碩学』なんて、あんたに言われる
まで知らなかったよ。

せきがく 0 【▼碩学】
〔「碩」は大きい意〕学問が広く深いこと。また、その人。

これって褒め言葉？あ、皮肉か。
＃つーか、こんな言葉持ち出すあんたのほうが碩学だよ。

>>586
× XML Scheme
○ XML Schema
ね。
w3cのTR出てすぐ斜め読みして応用考えた口だけど、
Lispマニアだから手が勝手に Schemeとか打ってしまったみたい。
スマソ(w


>>585
＞制約条件を宣言的に記述するだけでいろんな言語のプログラムを自動的に
＞生成できることに、あんたの主張の意味があるんじゃないの？

そのような主張は、しておりませんが、何か？
行間を勝手に妄想するタイプの方ですか？


＞結局プログラムを作成しなきゃいけないんだったら、最初の問題の解決に
＞なってないじゃん。

入力チェックを、XML SchemaやOCLで記述できないとしたら、
プログラミング言語と同等の表現力を持つ言語で入力チェックを記述する必要がある
かと思いますが、何か？
何か、素晴らしい魔法をご存知なのですか？

>>588
＞つまり今問題にしているのは「クライアント側でチェックすればサーバ側での
＞チェックは不要か否か」であって、「クライアント側でチェックを行う目的は
＞何か？」ではないんだけど。


その話は、>>370-374で既に終わってるような気がします。
あえて>>547-550で、再提起されているのは、
どんな意図で、何を主張されているのですか？


また、
　>>546 Httpベースのサバクラシステムは、そもそもMVCに向いていないという罠。
に対するレスとして、
　>>547 >>370に書いたんだが。
　>>550 (370のコピペ)
という事ですが、>>370のどこが、
>>546の意見「MVC(typeI)はHTTPベースのクラサバ(＝軽量プロトコル、シンクライアント)に適さない」
という意見と等価だと、主張されるのでしょうか？


分散システムの両端で、値チェックをする必要の有無は、
>>370に書かれているように、ファット・クライアントなり、クライアント側コンポーネントでも
解決できると思います。
そしてその問題は、分散MVCとかいうならまだしも、
MVC typeIとは丸きり無関係な話だと理解しておりますが。


人の意見をまるきり無視して、
見当違いな主張をされる貴方は、
普段の生活でも、大きな障害を抱えいるのでは、ありませんか？

>>589

> そのような主張は、しておりませんが、何か？

じゃあ何がいいたいの？

>>557 には
>XML Schemeから、値チェック用コードを二種類生成して
>クライアント側とサーバ側で実行してやれば良いではないか
とあったから、クライアント用とサーバ用のプログラムが自動生成
できることを主張してるんだと思ったんだけど。

>行間を勝手に妄想するタイプの方ですか？

すまない、主張がよくわからんから補ってしまったよ。
ばかなおれでもわかるように説明してくれ。

と書いて、匿名掲示板の罠に嵌った罠。

要するに、このスレには、
　>>370=>>550 の話題を提供した人と、
　>>588と、
　>>565=>>590=漏れと、
少なくとも三種類の人 (２名以上居るかどうかは定かでない（ｗ)
が居る訳ね。

じゃあ、
>>588

クライアント・コンポーネント無しのシンクライアント(Webブラウザ)を前提とする限り、
分散システムの両端で、値チェックが必要なケースが多いでしょうね。常識的な話だけど。

で、>>588は、煽り以外の目的で、一体何を主張したいの？
同じ主張を何度も何度もしつこく繰り返しているだけで、
新しい主張が見えないわけだが。

ところで議論の発端になった>>370は、
ファット・クライアントなり、クライアント側コンポーネントで実装可能な、
二重チェック回避方法を示している。
そして、そーゆー事をするフレームワークはないね、と締めくくっている。

>>370を素直に解釈すると、
「UI側フレームワーク(VC部分)の機能向上の一つとして、
　ユーザ・インターフェース(入力チェック含む！)の向上を目指すとすれば、
　処理の委譲が可能なクライアント
　(＝ファットクライアント、クライアント側スクリプト、クライアント側コンポーネント等)
　が必要になるね」
という意見に受け取れる。

>>590
>その話は、>>370-374で既に終わってるような気がします。

しらねーよ、そんな昔のこと。
全部読まなきゃ書いちゃいけないのかい。

おれは370も546も547も書いてねーよ。
なんで550から始まった話題に、それより前のことを持ち出すんだよ。
MVC Type I なんて話題にしてないっつーの。


>人の意見をまるきり無視して、

あんたほどじゃねーよ。

>見当違いな主張をされる貴方は、

あんたほどじゃねーよ。

>普段の生活でも、大きな障害を抱えいるのでは、ありませんか？

あんたほどじゃねーよ。

【このスレで議論すべき事】

1. 日本製JavaFrameworkの駄目さ加減(w
2. その改善方法
3. 良いフレームワークの実例、デファクト・スタンダード等の情報交換(w
　3-1. UI/アーキテクチャ側フレームワークの進展・・・Struts以降 (WO等)
　3-2. 業務ドメイン・フレームワークの状況
4. その他なんでも（・∀・）ｲｲ

…ってわざわざ見て見たら、370のコピペが550だったのね。しらんかった。
もしかして、釣られたのか？
ｼｮﾎﾞｰﾝ

>>593
スレの流れを読まずに嘴挟むのは、いかがなものか？

一般社会では、そーゆー態度を
「人の意見をまるきり無視して、見当違いな主張をする 」
と呼ぶんだよ、わかったかい

>>593＝情死す板の常駐煽りに類する人物、と判明。

この件終了

ほっしゅ

あーあ、Forte 4GL　よかったなぁ〜
価格が高すぎたのと、登場が速すぎたのが敗因か

相変わらずこの板には怪しい上げ荒しが住み着いて、気に入らないスレのdat落としを画策してるようだな

>>599
Forte 4GLって何？

>>601
その昔、Forteって製品があったんだよ。会社の名前もForte。
CORBAをベースにした分散オブジェクト開発/実行環境。

言語はForte 4GL(C++ライクだったけど、今考えるとJavaに似てた)、ローカルの環境で
一括して開発したものを、別々のノードに分割して配置できた。

結局泣かず飛ばずでSunに買収されて単なるJavaのIDEになってしまった。
そのなれの果てが今のSunONE Studio。

学術スレage

今年もＪａｖａＯＮＥあるの？

みかかゴムウェアのらずべりとかいう
のを初めて知ったのがJavaONEだった

またへんなものみつけられるかな

何気に旧>>604と現>>604の間に透明あぼーんが入ったね。
一体なにがあったの？

>>605
透明あぼーん、って何？

http://www.jtc2004.com/ >>604

これってどう？
ttp://www.hitachi.co.jp/New/cnews/031023.html

>>607
てかきょういったけど、J2EEはやっぱ停滞してるなあ。
話題が前にすすんでかないもんな
JAVAONE時から。

これはJavaOneの縮小再生産だし。
仕方ないでしょ

つうか、IBMが出ない時点でダメぽ。

>>611
「エクリプス」なんて下品なこと言ってるから、仲が悪くなるのはしょうがないよ。
ほんと低俗。

nttdataのterasolunaの感想は。ダメだな。全くもってダメ。

>>609
替わりにJBossがある。

たとえばどんなん？

↑なんであげ荒らしばかり繰り返すの？
他人に迷惑だとは思わないの？
一行レスばかり繰り返して。
あなたの人間性を疑います。

>>616
例の山崎パンだか吉田勝利が荒してるんだろうよ。

最近、ヤツとおぼしきコテを叩きまくったから、ヤツも荒れてるんだろうよ。

関係ない話で恐縮だが。

フレームワークの有望な市場として、業務系アプリ市場がある、とつい最近まで勘違いしてた。
俺のメインの領域じゃないから、あくまでもよく知らない市場に関する想像ね。

けど、しかし、やっぱ、業務系は、どこまでいっても果てしなく不毛だな。
最近、ちょっと業務系に関わらざるを得なくなって痛感してる。
不毛な理由は、次の通り。
1. 業務系を破綻なくこなすことは容易。しかし、それはとてつもなく単調かつ低スキルな仕事でしかない。(詳細略)
2. 業務系で儲けようと思ったら、果てしなく工数を膨らませて、ほとんど無意味で実装の糞にも役立たない「設計」をやる要員を増やす必要がある。
　こいつらが、単調な仕事を普通に破綻なくこなす忍耐力と常識とスキルを持ってれば、
　問題は無いのだが。無駄仕事にぶら下がっても平気な連中っつうのは、大抵、幾つも問題を抱えてる連中が多い。
　結果、工数獲得のための無駄無駄要員が、プロジェクトの健全さを根幹からなぎ倒す、
　という珍事が多発する。
3. 他方、業務系フレームワークを構築して、生産性と品質を上げるべき任務の人達。
　こいつらは、2.の連中とレベルが違い過ぎるし、さりとて2.の連中にすら完全な仕事をさせるに足る、
　シンプルで合理的なフレームワークを組み立てるには、能力が寸足らず。

ってな現状を踏まえて、なんかポスト業務フレームワークな地平を切り開かなくてはならない私の立場。
つらいな〜(藁
海外の著名コンサルの人達は、ど〜やって仕事を組み立ててるんだろう。。。

>>618
俺は今まさに 3. の領域に進もうとしている。
1. や 2. のような馬鹿に「馬鹿」と言わずに慇懃に仕事をするのはもう終わりだ。

テクニカルなフレームワークも、もうメーカーから調達すりゃあいいやという気分だ。
本当のビジネスオーナーと話をする、仕事をする。

>>619は、コンサルになると主張してるらしいが、>>618のどこにもそんな話題は書いて無い。
そんな注意力散漫なきみの相手をしなきゃならん顧客重役に同情するよ。

>>616

意味不明なヒステリーだな。生理？

>>619
読解力がないヴァカ。


>>620
ただの揚げ足鳥。

>>621
赤シャカ？

氏にたい

＞＞623
いつでもどうぞ。

>>621
氏ね

仲間由紀恵って異常に可愛いよな

これからよくなる。

日本人は論理的な思考ができないのだ。
当然日本製フレームワークなんかできっこない。

日本はアメリカのフレームワークでできてるからな。

最近銀行に行ってるけど、
彼らのようなCOBOLやPL/Iのコテコテな業務系の会社にとっては
Javaなんてあまり興味ないみたいだな。
基幹系をJavaで書き変える予算も度胸も能力もないし、
Javaはしょせん情報系で使う言語なんだとわかた。

最後の一行が前の行までと繋がってない

Would you like Seaser2?

あの…これ…落としものですよ…

　　　　　　　　 .∧__,,∧
　　　　　　　　（´・ω・`）
　　　　　　　　 (つ幸と）
　　　　　　　　 ｀ｕ―ｕ´

　　あなたのすぐ後ろに落ちていましたよ？

ｇｇ

age

InterStageってどう？

ｽｺｽｺ　 ,ｨﾍ⌒ヽﾌ　　ﾌﾞﾋﾌﾞﾋ-
　　　　／ ( 　・ω・）) -=3　
　ε//　　 し ﾍ⌒ヽﾌ　　　ｱｱ-ﾝ
　　( ( 　_,.ノ( 　・ω・）) -=3　
　　　し しー し─Ｊ

age

>>422
> ぶっちゃけ開発者が自己拡張可能な仕事環境。

開発者が自己拡張可能な環境、と言えば
Eclipse上の EMFやXSDが、ずいぶんいい感じに発展してきたね。
クローズド・ソース商売のどっかとは、対照的だ

古い話題へのレスで恐縮だが、最近話題のGoogle map, Gmailは
結局 JavaScript:+DHTML+Webサービスで実装されたワナ。

DHTMLﾌｶｰﾂというところが、渋いね。

リファレンスは、このあたり
　http://www.google.com/search?num=50&hl=ja&q=DHTML+Google+Gmail&lr=lang_ja

そろそろ過去ログ行きかな

　 　　 　 　 　 　 　 　 　　ｒ､
　 　 　 　 　 　 　 　 　 　 | :.＼
　 　 　 　　　_＿＿＿ 　 ﾉ ;;::　ｷ
　 　 　 　　　＼、 ..::-｀"゛　_　　iヘ
　 　 　 　　　　　Y　,　 　　 ○　ヾ＼
　 　 　 　　　　/^ｆ:○　ｆ⌒ヽ　 　}　}
　 　 　 　　　　|: .|:..　　.）　 |　　ノ　|　　　　
　 　 　 　　 　　ゝ:ヾ..　 ⌒"　..,ｲ、ｲ
　 　 　 　　　　　 ＼;"ヽ::...　∠ ヽ ＼
　 　 　 　　 　γ⌒:|:: .}"　 　　⌒＼ ＼
　 　 　 　　 　 |　 ;/　/　　　　,ｨﾍ.　＼ ヽ
　 　 　 　　　　|　/　/　　　　ﾉ 　 ＼___ノ
　 　 　 　　　　| "　/　 　　/
　 　 　 　　 　 ゝ__ﾉ　 　　/

>>641
Ajax (Asynchronous JavaScript + XML)つうやつだね。
Google Mapsとか、最近のSoftwareDesign誌で記事になってる

そーだね。
Ajaxで、thin clientタイプの分散イベント処理が普及し始めたわけだ。
そんなレベルの話が２年前には通じない・・・それが情報システム板クオリティ

>>632
Seaserは知らない。
Seasarなら知ってる。

>>358と>>560がこのスレを潰した、
とゆー結論で

>>560は全然関係ないだろ。
とにかく技術論のど真ん中で、幼稚な突っ込み入れて
議論を妨害してくるキチガイがいるのが、
２ちゃん

>>645
Ajaxは使われている技術だけ見ればいまさら感がありますが、
普及の障害になる古いブラウザがほぼ退場したのは今年の事ですよね。
ノウハウ解説やライブラリも今年になってから揃ったし、
結果的にはブームになってから動いても間に合ったのでは？

location.hashを使ったセッション復元　(ノウハウ解説、2005/02/27)
http://la.ma.la/blog/diary_200502270128.htm
XMLHttpRequestについて　(ブラウザ検証、2005/04/06)
http://www.hawk.34sp.com/stdpls/xml/xmlhttprequest.html
JKL.ParseXML - XML→JSON展開クラス　(ライブラリ、2005/05/18)
http://www.kawa.net/works/js/jkl/parsexml.html

>>647-648
>>346-417あたりを読み返しましたが、
>>358がなにを勘違いしているかは>>410ではっきりしています。
(DHTML+Webサービスはありえないと思い込んでいる)
>>411-417まで358の方が間違っていると表明しています。

他人の間違いを見つけたと勘違いしてはしゃいでいる人が
ひとりいただけで、ちゃんと分かっている人も多かったわけです。
はしゃぐ人は自分の方が間違っていると分かったとたんに消えます。
単にどこが間違っているか指摘して議論を続ければ済む話でしょう。

>>649
議論の整理をどうもありがとうございました。

次の議論の方向付けは難しい所ですね。


>> Ajaxは使われている技術だけ見ればいまさら感がありますが、
>> 普及の障害になる古いブラウザがほぼ退場したのは今年の事ですよね。
>> ノウハウ解説やライブラリも今年になってから揃ったし、
>> 結果的にはブームになってから動いても間に合ったのでは？

いや、普及待ってからつうよりｗ
元ﾈﾀは、10年近く前、Javaサーバ応用パッケージ企画でして。
当時はJ2EE〜XML〜Apache系ｵｰﾌﾟﾝｿｰｽもまだ出ていないという・・・

>>649
議論の整理をどうもありがとうございました。

でも、議論の続きを方向付けるのは、なかなか難しそうですね。


>> Ajaxは使われている技術だけ見ればいまさら感がありますが、
>> 普及の障害になる古いブラウザがほぼ退場したのは今年の事ですよね。
>> ノウハウ解説やライブラリも今年になってから揃ったし、
>> 結果的にはブームになってから動いても間に合ったのでは？

いや、普及待ってからつうよりｗ
元ﾈﾀは、10年近く前、Javaサーバ応用パッケージ企画でして。
当時はJ2EE〜XML〜Apache系ｵｰﾌﾟﾝｿｰｽもまだ出ていないという・・・

>>396
>>418
ドメイン特化言語
　　http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainSpecificLanguage

　　ドメイン特化言語(DSL:Domain Specific Language)とは、ある問題に特化したコンピュータ言語のことです。
　　いろんな問題に対応できる汎用的な言語のことではありません。ドメイン特化言語についてはこれまでも
　　議論されてきましたし、コンピュータが使われてきたのと同じくらい長い間使われてきました。

　　DSLを頻繁に使用しているコミュニティに、Unixコミュニティがあります。
　　そこではDSLは「リトル言語」や「ミニ言語」などと呼ばれています
　　（この伝統について、Eric Raymondが素晴らしい議論を提供してくれています）。
　　最も一般的なUnixスタイルは、言語の文法を定義し、
　　コード生成機能を使ってDSLから汎用的な言語を生成する、
　　あるいは、そのDSL用のインタプリタを書くことです。
　　こういったことを簡単にするツールがUnixにはたくさん揃っています。

　　LispやSmalltalkのコミュニティにもDSLの伝統があります。
　　しかしこれは、Unixコミュニティとは違ったやり方で行われています。
　　新しい言語を作るというよりも、汎用的な言語をDSLに変化させるのです
　　（Paul GrahamがProgramming Bottom-Upの中でこのことについてうまく説明しています）。
　　この「言語内DSL」では、プログラミング言語それ自体を元にしてDSLを定義します。
　　これはどの言語でもできる一般的なやり方です。
　　私も問題を解決するためのDSLを作るために、関数を定義することを常に考えてきました。
　　すかしながら、LisperやSmalltalkerたちは私よりもずっと深くこの方法に取り組んでいます。

　　これら2つの流れは、PragDaveの言葉でうまく合流しました。達人プログラマーたちは
　　ずっとDSLのファンだったのです。 DSLは元々、Unixの伝統から来たものでした
　　（The Pragmatic Programmer（日本語『達人プログラマー』）のセクション12に素晴らしい議論が載っています
　　――これは「達人の極意12」と呼んでもいいかもしれません）。
　　インタビューのなかでDaveはこう言っています。
　　「コード生成はいつも使うけど、Rubyでプログラミングしているときはほとんど使わない」と。

　　私はいつもDSLを作成するのと似たようなことを、設計を肉付けする際に行っています
　　――クラスやメソッドがDSLとなるように開発するのです。
　　できることなら、そのとき使っている言語でこれをやりたいのですが、
　　もしできないならできないで、コード生成を使うことになるでしょう。

>>651
昨今のAjaxブームは、やはりDHTMLの人の仕事みたいですね。
DHTMLの命名はともかく、起源はNetscape Navigator 2.0〜4.7だと思いますが。

Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ
　　http://satoshi.blogs.com/life/2005/06/ajax.html

　　[追記]　読者の一人に「ここに書かれている考えはどこから来ているのですか？」と聞かれたので、お答えします。
　　実は、現在米国 Google で活躍している Adam Bosworth と Gary Burd と私は、
　　マイクロソフトで Internet Explorer 4.0 を一緒に開発していた仲です。
　　マイクロソフトが XML と DHTML の機能を初めて導入したブラウザーです。
　　あの当時から、彼らとは「次世代ウェブ・アプリケーション」の話ばかりしていました。
　　非同期通信の話とか、ＵＩをブロックしないだとか、XML over HTTP の話はその時に始まった話です。
　　ある意味で、Adam も私も、１０年近く同じことを言い続けているわけですね。
　　Gary が私の誘いを蹴って Google に行くと行ったときに、あやしいと思ったのですが、
　　案の定あんなことを始めてしまいました。私も人のことを言える立場ではありませんが（笑）。

ゴッゴルage

正直に言えよ、お前ら。
・・・プログラム作りを楽しみたいだけだろ？

公私混同。
ま、それでも良いけどな。

保守

仕事すら楽しめない馬鹿は生きている資格なし。

InterStageってD●c●m●の某Aシステムで使ってるだろ。
ディズニーのキャラクター名のやつ

だからいつも・・・

なんだ？
アラジンドビンハゲチャビンか？

二段モーション禁止

キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ
キューブシステムの松本が住み着いてるのはここでちゅ、両替逝ってきまちゅ

キューブシステムの松本君の尻を追いかけてるキモヲヤジ永宗
キューブシステムの松本君の尻を追いかけてるキモヲヤジ永宗
キューブシステムの松本君の尻を追いかけてるキモヲヤジ永宗
キューブシステムの松本君の尻を追いかけてるキモヲヤジ永宗
キューブシステムの松本君の尻を追いかけてるキモヲヤジ永宗

現実に動いている企業情報システムは、
　・楽々(SEI)
　・オブジェクトワークス(NRI)
この２つのフレームワークが多いね。

UIだけだと、Struts使っているの多いけど
大概、CORBAやそれに似た仕組みが裏にいて、背後に
ＲＤＢを抱えたマシーンがいる。
>>303の話だと、楽々やオブジェクトワークスとやっていること同じだ。

大規模システムで一番重要なのは、ＲＤＢ。
データのモデリングが適切でないと、開発が難しくて頓挫してしまうことが
多いね。

というかRDBをいつまでも使い続けるのも限界が近づいて
いるような気もするのだが。

早いところOODBの時代が来て欲しいね。
DAOとか作るのは本当に馬鹿馬鹿しい。

まぁ、大規模システムだと簡単には切り替えられないだろうし、
更新系のトランザクションが多い場合はRDBの方が今のところ速い
ようなので簡単にはいかないだろうが、それにしてもなぁって感じが
している。

>>665
アンタの狭い視野と根拠不明の断言に脱尿

>>665-666
シリアライズして永続化　こういうの使っているの？
OODB - オブジェクト指向データベース
http://pc8.2ch.net/test/read.cgi/db/1057157392/

確かに大規模システムでの構築例が無さそう。
ＳＱＬで書けとか指定してくると言うレスあった。
O/Rマッピングやデータ中心アプローチ(DOA)ベースで
満足みたいに読み取れるレスもあった。

ペンネーム： 668番
得意技：　　　旬を逃した見当違いの書き込み
弱点：　　　　 知能

何千万件とか大量処理バッチがないとか
バックアップシステムが必要ないとか
そういう責任があまりないシステムなら
OODBで遊んでもいいんじゃないか。

日本製Java フレームワークでまともそうで注目されているものって
いったら、あれでしょ

Seasar2


国産DIコンテナSeasarとくーす　その５
http://pc8.2ch.net/test/read.cgi/tech/1135986150/l50

ｽｺｽｺ　 ,ｨﾍ⌒ヽﾌ　　ﾌﾞﾋﾌﾞﾋ-
　　　　／ ( 　・ω・）) -=3　
　ε//　　 し ﾍ⌒ヽﾌ　　　ｱｱ-ﾝ
　　( ( 　_,.ノ( 　・ω・）) -=3　
　　　し しー し─Ｊ

>>671
DIコンテナも中途半端だよね。
SpringもSeasar2にしても。

なんかお約束が多すぎるし、大して作るのが楽になるわけでもない。
こういう流れが技術的な進歩なのかなぁ。単なるゴマ化しじゃないの？
使用するハードの値段を下げるために、ソフトを作るのがどんどん大変に
なっているだけのような気がするのだが。

ペンネーム： 673番
得意技：　　　旬を逃した見当違いの書き込み
弱点：　　　　 社会経験、実務経験、知能

Seasar2 作るのが楽になるものではない。
いっぱいドキュメントがあって、お約束が書いてある。
この規約に従って書けば、表現のバラツキが減少し
メンテナンスコストが減るというもの。

お客がフレームワーク使えと言ってくる場合、
そのフレームワークの文献や情報が豊富で
サポートがあって、均質化効果の高いものを
指定してくる。それ以上の効果はお客は関知しないよ。

>>675
というか「均質化効果」とかやらも疑わしいと思うのだが。
実際に複数のSpringプロジェクトに参加してみて、作り手に
よるバラつきが減少していたとはとても思えない。

さらに使用したDIそのものが、いつまで寿命が続くかわかったもんじゃないと
思うから、メンテナンスコストが減少すると断言できるものじゃ
ないと思う。

>>676
おまえはSun社内の人間ですか？
それともやっぱくるくるぱぁ〜か

>>677
というかこのバカは、「Springプロジェクト」を、
「Springフレームワークを使ったユーザ・プロジェクト」
の省略形だと勘違いしている、に1000ﾊﾞｰﾗ。

ついでに、このバカは見苦しい言い訳を始める、に10000ﾊﾞｰｶ

>>678
俺も
「Springフレームワークを使ったユーザ・プロジェクト」
って意味で読み流してしまったばい。

毎日人の悪口書き込みごくろうさん、
そんなヒマがあったらお前のキモイ嫁の相手してろや永宗ｗ
そんなヒマがあったらお前のキモイ嫁の相手してろや永宗ｗ
そんなヒマがあったらお前のキモイ嫁の相手してろや永宗ｗ
そんなヒマがあったらお前のキモイ嫁の相手してろや永宗ｗ
そんなヒマがあったらお前のキモイ嫁の相手してろや永宗ｗ

いろいろ、参考になりました。
もうすぐｄａｔ落ちかな。。。

>>681
うん、そろそろｄａｔ落ち

ec-oneって偽装派遣やってる？
ってかここはﾌﾞﾗｯｸ？

楽々の会社で働いてる俺が来ましたよ。

駄目だ駄目だと批評するだけ
じゃあ何で君が作らない

永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!
永宗〜〜 お前の腐ったスキルの伝授なんかいらねーよ。バカ。これで一ヶ月 １５０万円！!

age

>>685
　>>594

>>685
　>>671

ここを荒してた>>358がまた荒しやってるよ

http://pc11.2ch.net/test/read.cgi/prog/1175612938/

成長しねぇ禿だな

中小企業がつくった自社開発ふれーむわーく
自動生成とか叫んでいる会社のふれーむわーく

バグばかり出てダメダメなんですけど
使えね
spring使えね

Javaってフレームワークが乱立していて正直ウザいんですが、どうなんでしょ？
乱立しているわりにはまともに使えるやつないじゃん
時代の波に飲まれてすぐに廃れるような技術に
携わりたいとは俺は思わんねｗ

ninja-va

w

DAOがすごい邪魔。
プロジェクトによって、使い方理解しないといけない。

しかもDAOをテストしないで、リリースするな。

落ちない

AJAX時代の到来をずっと以上に議論していた
記念碑的スレだからな

AJAX時代の到来をそのずっと以前から議論していた
記念碑的スレだからな

javaフレームワークのトレンドをレポートしてるページを見っけた。

厳しいジョブマーケットで生き抜くには
http://www.infoq.com/jp/news/2008/03/turbulent-job-market

技術に関する限り、Struts、Spring、Hibernate、AJAXフレームワーク、JavaServer Facesを学習するのに時間を費やすのが一番です。

JAVA初心者なんだけど、使いやすい企業のフレームワークってあるの？

全部ストラッツ系じゃないの？

企業用で、よく使われているのはストラッツ以外だと
cFrameWorkなんか見かける。

SpingやSeasar2の領域　DIコンテナとかぶる。

やっぱりエスナでしょ（ｗ

terasolunaどうよ？バッチも出てきたし使えるかね？

Seasar2ばんざい

>>702
XMLでのマッピング(Spring由来)が、ものすごく苦しい。
Struts由来の部分は、extendsしているクラスがウザい。
独自部分は、とてもナチュラルでいい。

Seasar2とJSFベースのterasolunaがあったらいいのにね。

Seasar2ばんざいだぉ。EJB3使いたいという顧客の要件も
2007年時点で満たせて対応できたし、XMLのマッピング DICONは楽だし。
Seasar2は、古いメインフレームやUNIXからの歴史をインスパイアした部分があって
バランス的に最高だと思う。

　　　 | |　　 　 　＼　　　　　 ∧＿∧　　　　　　　 ∧＿∧　　　　　/
　　　　ﾉ__丶 ∧＿∧＼　ﾊｧ...（　＞＜） ≡3　　　　（＞＜　）うう… /__|
　　 　 ||鬼||（　＞＜） 　＼　　|　　⊃ヽC 　　　　 Ｃ/⊂　　|　　　　/|||||
　 ＿　||殺||./ 　 ［¢､)　　＼　 ､＿（　）） 　 　　（ （　）＿ノ 　　　/ |￣|_∧ ｳｳ･･･
　 ＼　||し ||∪￣￣.￣￣＼ ＼　 　 　 　　∧∧∧∧∧　　　　 /　| 　|＜；）
　　||＼.`~~´　（(二ﾟ｡◎彡） ＼ ＼　　　＜　の　　　わ　＞　　/ 　 |　 |⊂ | わかんないんです…
　　||＼||￣￣￣￣￣￣￣||￣ 　 ＼　 ＜　　　 　　か　＞　 /　　 |　 | ∪
　　 .　 ||￣￣￣￣￣￣￣|| 　　　　 ＼＜　予　　　ん　＞　/
　わかんないんです… 　 　 　　　　　 ＜　 　　　　な　＞ /
――――――――――――――― ＜　感　　　い　＞―――――――――――――――――
　　　　　 ∧ 　　　　　　　　　　 　 ∧　 ＜　 　 　 　ん　＞
　　　　　/　ヽわかんないんです/　ヽ ＜　 !!!　　　で　＞
　　　　/　　 ヽ　　　　　　　　　　/　　ヽ＜　　　　　 す　＞　　　　　　 ∧＿∧∩　／￣￣
　　　/　　　　ヽ＿＿＿＿＿＿/　　　　 / ∨∨∨∨∨ヽ　　　　　　 （；＞＜ ノ＜先生、わかんないです！
　　/ 　　　　　　　　　　　　 　 　 　　　 /　　　　　　　　　 ＼　　＿_／ノ　　 /　　 ＼＿＿
　/　 ┯━┯　 　　　　　　　┯━┯　/　わかりません　　 ＼ ＼　￣￣￣￣￣￣＼
.|　　　）　　 ） ＿＿＿＿＿　 ） 　　）/　たすけてください！　 ＼||＼　　　　　　　　　 ＼
|　　 （ 　　（　ヽ　　　　　　/ （ 　　（/　　　　　（＞＜； ）　　　　　 ＼ ||￣￣￣￣￣￣￣||
　　　　　　　　　　　　　　　　　　　/　　　　 　 ∩∩　.）　　　　　　　 ＼
　　　　　　　　　　　　　　　　　　 /　　　　　　 （＿（＿つ　　　　　　　　＼

>>683
イーシーワンは森○っていう開発部長やってる人の態度が悪いことで有名だよ
俺の周りで彼と面接している人は皆そう言ってるよ

あのよー、
おまえらバカを競うなら誰でもできるんだよ。
オレの特技を聞きたいか？
教えてやるよ。
今まで付き合ったオンナをどうすればキれるか。
あっ、イッ･･･

Struts2勉強中
Struts1と全然違うw

最近お客様をよいしょするためにTERASOLUNA使えって言われてるんですけど、実際のところどうなんですかね。下記のスレッドとか見るといまいちっぽいですが。


http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=47891&forum=12

>>709
Springを好きになれるかどうかで決まる。
Strutsの拡張は、イイ感じで、それをSpringに繋いである。

SpringのXML地獄が、全然解消していない。

>>601
ｵﾔｽﾐ…
　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

Ｊａｖａの次は

>>712
Eiffelと言いたいけど開発環境が広まってないからねぇ。
Webとの整合性も.NETとはどうにかって感じだし。

あと問題は「軽いノリ」で開発することが出来ない言語だってことだな。

今の20〜30代の人は「軽いノリ」で開発するのが好きな人が多くて
(というかそういうのがフツーの開発スタイルだと信じているね)
抵抗感が強いんじゃないかな。

「軽いノリ」のJavaオブジェクト指向が、何故か、変に冗長で、変に複雑な
システムを量産している気がする。
誰も最初にマトモに検討しないからね。(それがフツーだと信じている
人ばっかりだし)

1985年に出た言語がJavaの次と言うのは何とも信じがたいが、かと言って語れる程
調べている訳ではないから何も言えんけど。ScalaとかClojureとかJVM上で動作する
Java以外の言語が伸びてくる気はする。

>>714
というかJVMが限界だと思うんだよ。
もはや諸悪の根源でしかない。
ソースが公開されているにしても、結局ブラックボックス化しているから、そこに
問題が集中している。

ネイティブなオブジェクトを生成できるコンパイラの復権を望む。

JAVAの時代は　もうおわりなのかね？

Javaが終わりなら、レガシー化するので
レガシー資産も増えるということだな。

>>711
　Z
　 z
　　z
　＜⌒／ヽ-､_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

>>717
レガシィ資産のお守りと
レガシィ資産の次世代基盤への移行
どちらを目指しますか？

レガシィ資産で、次世代への移行するほど
資産価値があるのは、ミッションクリティカルな部分だろうな。

Webサーバではなく、APサーバやDBサーバのレガシィ資産だけな気がする。
UI部分って、スクラッチで作り直すのでは？

また、クラウドコンピューティングになった時に、刷り合わせやカスタマイズに
どんな手法をとるのかにもよるな。

>>718
　　　　　幽体離脱
　　　　∧∧ ∩
　　　 (`･ω･)/
　　　⊂　　ノ
　　　　(つノ
　　　　 (ﾉ
　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

　＿＿＿　　　　　　　
　＿_／＿　　　　　/　　　　＿|＿　　＼　　　　 ＿|＿　＼　　＿|＿/＿　　|　　＿|＿　
　　　￣／　　　　/　　　　　　/　　　|　　　　　　 __|＿　　　　┌-┐　｜ 　｜ 　 　| 　　　　　　　　　　
　　　／　　　　　/⌒ヽ　　　　　　＿|　　　　　／　|　　ヽ　　　|二|　|　|　　｜ 　 ＿| 　　　　　　　　　　　
　　　＼＿　 　/　　　|＿　　　　（__丿＼　　　＼ノ　　 ノ　　　|　｜　__| 　　.レ （__丿＼ 　　　　
　　　　　　　　　　　　　　

　　　　　 ／　　　　　　　　　　＿＿　___l__　　　　　　　　　　＼
　　　　／|￣|￣|￣|￣　　　　　|__|　__|__|__ __|_ヽ　　　　 ／　　　　　　|　　　　　　　|　　　　＼　　＿|＿　　＼
　　　　￣|￣|￣|￣|￣　　　　　|__|　　＿_ 　|　　　　　／⌒ヽ　　　　　|　　　　　　　|　　　　　| 　　 /　　　|
　　　　￣￣￣￣￣￣　　　　　レ|　　|＿|　∨　　　　　　　　|　　　　　|　　　　　　　|　　　　　|　　　　　 ＿|
　　　　／　｜　＼　＼.　　　　 　|　　|＿| ノ ＼l　　　　__＿ノ　　　　　ヽ＿ノ 　　　 レ　　　　　　　　　（__丿＼　　○

▼日本ソフト技研株式会社
　私たちの強みは「常に最先端の開発」に携わっていることです。
【募集職種】
システムエンジニア、ソフトウェアエンジニア、Web開発エンジニア、ネットワークエンジニア、SI営業／セールスエンジニア
　◆人間の可能性に挑戦　◆業界未経験者歓迎
【勤務地】　 本社（東京都国立市）
【詳細】 http://www.e-nstec.com/recruit.html

社長がアルツハイマー。人の話を理解も判断もできないモウロク爺。
問題多過ぎでハロワ出入禁止。人材エージェントも何処も取引謝絶でもう大変。
あんまり人が集まらないので、必死に社員募集してるよ。
終電までは絶対に帰れません。サービス残業・休出当たり前、給与は随時sage。
人生設計もできません。専務の親父がキチガイ社長。
パワハラなんて日常茶飯事、典型的な同族ＤＱＮブラック会社。
もの好きな方はドブ板営業・体力勝負のブラック会社で足掻いて下さい。
主任以上は毎日早朝７時に出社。連日８時からアルツハイマー社長の拷問会議が待っています。
未経験、ＤＱＮ、中卒、中高年、病人・・どこにも雇って貰えない貴方でも、ここなら面接30分で
当日から勤務出来ます！もちろん寮も完備！日本全国ご応募大歓迎！
今日の情勢にあって救世主のような会社です。
仕事のない方は是非ともご応募下さい。

【F】冨士通アドバンストエンジニアリング株式会社
http://science6.2ch.net/test/read.cgi/infosys/1227483464/
【F】冨士通ｱﾄﾞﾊﾞﾝｽﾄｴﾝｼﾞﾆｱﾘﾝｸﾞ・2
http://science6.2ch.net/test/read.cgi/infosys/1243838176/
FFCS
http://science6.2ch.net/test/read.cgi/infosys/1137323117/
FFCS倒産
http://science6.2ch.net/test/read.cgi/infosys/1216648609/
【冨士】FFCといえば松岡だよな【ﾌｧｺﾑ】
http://science6.2ch.net/test/read.cgi/infosys/1238021748/
FFC
http://science6.2ch.net/test/read.cgi/infosys/1139142143/
【Fulitsu】株式会社冨士通
http://science6.2ch.net/test/read.cgi/infosys/1234672237/
四国冨士ファコムシステム株式会社
http://science6.2ch.net/test/read.cgi/infosys/1172097857/
冨士ファコムシステム株式会社
http://science6.2ch.net/test/read.cgi/infosys/1198391520/
【FJ】冨士ﾌｧｺﾑｼｽﾃﾑ株式会社・２
http://science6.2ch.net/test/read.cgi/infosys/1236003190/
富士ﾌｧｺﾑ綜合スレッド
http://science6.2ch.net/test/read.cgi/infosys/1218689654/
【求人せず】糞冨士ﾌｧｺﾑｼｽﾃﾑ�梶yFFCS】
http://science6.2ch.net/test/read.cgi/infosys/1147013342/
株式会社冨士ﾌｧｺﾑ制御
http://science6.2ch.net/test/read.cgi/infosys/1133790907/

冨士ファコムシステム株式会社

リクルートのrframeworkは最悪

【理学博士】アイズファクトリー【労基法違反】
http://science6.2ch.net/test/read.cgi/infosys/1218718722/

VERSACE

【理学博士】アイズファクトリー【労基法違反】
http://science6.2ch.net/test/read.cgi/infosys/1218718722/

Cravis v4はなかなかよいよ！！

宣伝していいかな？
Server Side JavaScript で Web 上からアプリを開発できる
Webアプリの CMS 的なフレームワークのサイトを立ち上げたん
だけどクローラーしか来ないんで...

http://wsjs.dip.jp:8008/

ボロクソに言って貰って結構です。放置プレイよりましなんで。

正直、フレームワーク開発って大変。ゴールがない。

S2Struts最高
開発が楽すぎる

この静けさは…
不景気でみんなクビかな？

長寿スレだなｗ