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

日本製Java Frameworkっていろいろ出てるけど、
まともなのって存在するの ??

たとえばどんなん？

age

こんなのみっけた。
産業用の機械のモニタをApplet化したりするときのフレームワークみたいよ。(自信なし)

JIM (Java Industrial Monitoring Framework)
http://www.javacons.gr.jp/industry/jim.html

実装例？あるいは関連製品「Web-Adapter」
http://www.yamatake.com/web-adapter/index1.htm

そもそも、フレームワークとはナンなのか？
を定義せよ。

そういえばあいまいに使ってた。
フレームとフレームワークはちがうんだもんな。

http://education.yahoo.com/reference/dictionary/entries/38/f0293800.html
1. A structure for supporting or enclosing something else, especially a skeletal support used
as the basis for something being constructed.
2. An external work platform; a scaffold.
3. A fundamental structure, as for a written work.
4. A set of assumptions, concepts, values, and practices that constitutes a way of viewing
reality.

解釈：
(1)なにかを支えたりはめ込んだりするための構造。とくに、作りかけのものを支える骨組み。
(2)足場、土台。
(3)ある書きもの(著作)がその基礎としている構造。
(4)一つの「ものの見方」を確立させている、諸々の前提、概念、価値、習慣の集まり。

(1)(2)はビル工事の足場とかか？
(4)は学問の基礎づけとかだろうな。

ソフトウェアのフレームワークっていったら、(3)とか。。
ほかの意味にも微妙にかかってるかんじで。

ごめん、1じゃないから、1のいうframeworkとはちがうかも。

イーシーワンのcFrameWorkとかは？

>>8
一貫性ないと思うよ
・この前まで
　すごく怪しげなフレームワーク。
　EJBコンソーシアムのデザイン部会で総スカン
・最近
　懲りたのか、お墨付きが欲しくてBLUEPRINT準拠を目指す
　でもSUNのPetStoreの猿真似なので、お笑いな出来
　もともとあそこ（イーシーワン）はオブジェクト指向もUMLもだめなところ
　なのに背伸びしすぎ
結局、日本にはアーキテクトが少ないから、こんなお寒い状況？

確かにcFrameWork、PetStoreとほとんど同じような気がする。
じゃあ、それまで作ってたのは何？って感じもするが。
全部作り変えたんだろうか？
メディアにはいろいろ出てるけど、なんかねぇ。

>>10
PetStore自体、悪くはないんだけど、試行錯誤的なところがあるからアーキテクチャとしての統一性が無くて。
ところで、J2EEパターンって知っている？

>>9
ううむ、そうだったのか！
添付の研修面接で「納期が半年のプロジェクトがcFrameWorkに
よって3ヶ月まで縮まった」とか凄い話ばかり聞かされたのだが
そんなもんなのかぁ

>>12
もう少し、日本にも良いアーキテクトが多くなればフレームワークの良し悪しに関してちゃんとしたジャッジが適正にされてしかるべきなんでしょうけど。
基本的にイーシーワンはインプリ最悪、アーキテクチャ不在（のわりには変なところで凝る）というのが事情通の間では常識。

age

フレームワークあげ！

日本製じゃなければまともなのか？
IBMのWCS（WebSphereCommerceSuites）と
これに乗っかる
AribaのBuyerの導入経験者いる？

WACsってどうよ？

>>17
人から聞いた話ではSessionにSerializableでないオブジェクトを入れて
いる個所があって、SessionをDBに書きこめないのでクラスタリング構成
にできなかったとか。

>>17,18
仕事でかなり使ってます。
が，いずれにせよWACsは構造上,SessionPersistanceを使えない
と思ったほうが良い。触っている人は分かっていると思うけど,
JSPBeanクラスをはじめなんでもかんでもHttpSessionに
格納する傾向があるからDB書き込みがネックになる。
ま，ソースコード込みで提供されてるから,直せる人は直せばって
ことに帰着しそうね。なお，v3.0で開発支援ツールを含めて
かなり変わるようです。

というか話題難しすぎです。アーキテクトって何？

>>20
知らなきゃマズくない？

>>21 ではおしえてよ。

いま、話題はアーキテクチュアでしょう。だんだん、提供されてるライブラリとかＡＰＩとかのもんだじゃなくなってアーキテクチュアの良し悪しが問題になってきてるよね。

>>23
具体的に日本製で良いフレームワークってあるんですか？

>>19
WACs v3.0の入手方法おせーてェ

>>25
まだでてません(笑)

ＷＡＣってどこのフレームワーク？

ヒロシが馬鹿だからしょうがあんめぇ。

cFrameWorkが雑誌Javaワールドで評価版が出ましたね。
使ってみた人の罵詈雑言きぼん

>>27
WACsならibmのだが？

人にやらせるのが本当の仕事じゃ。
難しいことやってるやつはタダの馬鹿。ヒマなんだろうな。
弱いものいじめもできないドアホ。
人間やっぱり弱いものいじめに限ります。
日記に残されないよう気をつけよう。いざ裁判になったとき
大変にマズイそうだ。そんなの残されると。

>>31
人にやらせるとカネがかかるよね。
あと、ちゃんとやってるかチェックも必要だよね。
チェックするのにも知識が必要だよね（バカだとチェックもできない）。
だったら自分でやるのが最適ソリューション♪

なんか、
テンプスタッフが
「日本最強のJava Pro集団を作ろうとしている(?)」とかで、
その研修カリキュラムに cFramework ともう一つ、
FTK/WATS Framework とかいう謎のフレームワークがあるんだけど、
これについて知っている人居る ??

テンプスターフ関連のタレコミきぼん。

>>33
> FTK/WATS Framework とかいう謎のフレームワークがあるんだけど、
知らんけど
どーせ、どっかの弱小企業の自己満足フレームワークだろ？
使えるとは思えんが

>>34
これか？
ttp://www.fmw.fujitsu.com/products/e-apl/famotik/index.html
ダサそう．．．．

その会社のサイト見てきた。

ttp://www.famotik.co.jp/wats/index.html
ttp://www.famotik.co.jp/wats/service.html
ttp://www.famotik.co.jp/wats/solution-template.html

書いてあること読んで頭痛くなってきた…
全然説明になってないでやんの。
それ以前に日本語になってない…

例えばこれ。
> XML利用
> 処理ブロック間でのインターフェースを解り易く出力データ形式の変化への対応

(ﾟДﾟ)ﾊｧ?
何が言いたいのさ???
これは物凄い電波系かも知れない。

２つ３つと日本製Framework使ったけど、どこもおさむいできだった。
なかには、これさえなけりゃ・・・、と思うようなのもあった。

海外製のフレームワーク使ったことあるわけじゃないけど、
使ってた日本製フレームワークは、たいていメーカーの技術研究部とかが作ってて、
実際に使うのは箱売りのおまけで作るような業務アプリ。
フレームワーク作る連中は実際の現場を知らないし、
フレームワーク使う連中も使い方がわからない。コミュニケーションもとれてない。
現場のメーカー技術者に質問しても本社に問い合わせ。回答がくるまで時間がかかる。
フレームワークにほんの少し手をいれれば済むとわかっていても、絶対にカスタマイズしてくれない。
ろくに機能も無いくせに・・・。
実際に実装する人間の身になってほしいもんだ。

もしフレームワークを選ぶなら、
・うたい文句は無視すること
・質問窓口がはっきりしていること
・開発者の名前がすぐにわかること
・サンプルが豊富にあること（フレームワークの一部として標準で存在するのが望ましい）
などかな・・・。いずれにせよ過剰な期待は禁物。足枷でなければまだましだと思って使うものかと。

>>33
Servletベースのフレームワークらしいぞ。

>>36
> その会社のサイト見てきた。
>
> ttp://www.famotik.co.jp/wats/index.html
> ttp://www.famotik.co.jp/wats/service.html
> ttp://www.famotik.co.jp/wats/solution-template.html

なんだか、エ○スと同系の誇大妄想系に思えるが・・・

どうせなら、「らいでん」についても語ってあげないと。
エ○スがかわいそうジャン。(藁

>>40
「らいでん」じゃなくて
Web3 Frameworkって名前になったみたい。

ttp://yasai.2ch.net/test/read.cgi/venture/993549897/

エ○スなら、この辺りで語られまくっているが。(藁

つか、
ガベージコレクションがあるからとか抜かして、
むやみにオブジェクトを作りまくり、データ構造に積込まくり、
廃れたオブジェクト参照を裏でイツマデモ抱えているような
馬鹿な作りのサーバサイドJava Frameworkは逝ってよし！

それでメモリをいっぱい買ってもらうのだ

ていうか４Ｇ以上のメモリを操れる６４ｂｉｔマシンを買わせるのだ

ＥＪＢ対応のフレームワークと言いながら、やたらとセッションオブジェクトを使うフレームワークが多い。
クラスタリングしたらまともに動くのか？

クラスタリングで可用性を考慮して、セッション情報もDBに格納するなり。

>>47
普通だったらそれでＯＫだけど、アホな作りのフレームワークだとセッションオブジェクトが大きいから、インメモリリプリケーションでも遅いくらい。
ましてやＤＢでのセッション永続化は論外。

でも「製品化」されているだけマシかもしれん…
現在のプロジェクトは完全なオリジナルカスタムフレームワーク
しかもドキュメント無し。作ったやつが「製品のマニュアル・Q&Aにしば
られたくなかったんですよ〜」なんていってやがる。
殺してやりてぇ！

>>49
確かに、UMLでフレームワークをちゃんと説明していたりするケースも少ないし。

そもそも「オリジナルカスタムフレームワーク」の品質ってどうよ？

>>33
ちと、使ってみての感想

XMLとXSLを組み合わせて、Servletが返すHTMLを生成するのが、
このフレームワークの肝みたい。
ただ、
「1つのXSLから1つのHTMLが作られる」という制約から、
HTMLを丸ごとXSLに変換しておかなくてはならないので、
あまり生産性は良くないかと…

また、Servletクラスはフレームワーク内に完全に隠蔽されているので、
「1つのXSLから1つのHTMLが作られる」という制約を外すことは
フレームワークを作った人間にしか出来ない。

困ったもんだ…

>>33
ここのと、エコスのフレームワークって、
INTERSTAGEで採用してるよね。何で？どこが良いと思ったの？

富士通関係者のレスきぼ〜ん。

ﾌｰﾝ(´ゝ｀

>>53
富士通自身も、INTERSTAGE WEBCOORDINATORってフレームワークを持っている。
ttp://software.fujitsu.com/jp/interstage/as/web/
でも、お笑いなのは、中国に生産拠点を作ってまでＥＪＢに入れ込んでいるはずなのに、WEBCOORDINATORはServlet/JSPベース。
それでBluePrints対応だって堂々と宣言しているのはトホホな感じ。

>>51
XMLとXSLを組み合わせると、XSLを変更するだけで出力仕様を変えられるっていうんだろうけど、本当に実用的なのかね。
・XSLTって結構重い
・XMLの出力自体、どうやってんの？（DOM？SAX？独自？）
・XSLの編集は手作業？
って考えると、使う気にならないなぁ．．．

日本製でないけれど、IBMのWCSを使って開発していました。
よくできているんだけれど(特にDBの構造が美しい)、
私が使った時はJavadocのドキュメントに多数の空白があり、
ドキュメノントとしての役割を成していませんでした。
あと付属しているサンプルのJSPが汚い、スクリプトレット使いまくり。
スクリプトレットのみのJSPがあったりする。

他スレで盛り上がってたので。
ttp://yasai.2ch.net/test/read.cgi?bbs=venture&key=993549897&st=836&to=848&nofirst=true

>>43
ソレ、うちのがそうだよ！
しかもログ系クラスで。

言いたかねぇけどさ、フレームワーク、フレームワークって、
ハッキリ言ってウザイ。ほとんどがただのクラスライブラリ。

枠組みで人を仕切ろう、とか、おれたちの言う通りに作れよ、
という発想そのものが根本的にキライ。

ホントに必要か？フレームワーク？
別に売り物になってボロ儲け出来るワケじゃなし...。
せいぜいプリセールス時の語りネタ。

>>60
>言いたかねぇけどさ、フレームワーク、フレームワークって、
>ハッキリ言ってウザイ。ほとんどがただのクラスライブラリ。
具体的には、どこのフレームワークがそうなの？

フレームワークはセールス的にはもはや旬を過ぎた。
が、生産性を上げるフレームワークってのはなくはないと思うし、
業務コンポーネントの流通なんてネタよりはリアリティもある。
流行りも去って、淡々とブラッシュアップしていこうかと。

>フレームワークはセールス的にはもはや旬を過ぎた。
と、いうよりも、まだ良いものはそんなに無いのでは？
>流行りも去って、淡々とブラッシュアップしていこうかと。
ほほぅ、そんなに良いフレームワークを作っているなら
情報キボンヌ

>>63
そんな良いものはまだ作れてないです。
ここで叩かれてるのと同等レベルじゃないかな。
売りを作るために名前だけの機能追加ばっかりしてて、
便利でも美しくもないものになってるし。
流行りが去ったら締め付けも弱くなるだろうから、
機能追加に追われずに、本筋に力を注げるかな・・・と。

>>56
51ではないが、それについて、

>・XMLの出力自体、どうやってんの？（DOM？SAX？独自？）
DOM使ってる

>・XSLの編集は手作業？
手作業だったナリ

>>65
さんきゅ♪

>手作業だったナリ
それはつらいと思ワレ
ブラウザ（HTML）と携帯（cHTMLとか）を同一アプリで対応するとかでなければＪＳＰのほうがラクなのでは？

イーベンチャーサポートのFrameworkはサイコーで破格です。

>>67
どこがサイコーなんだよ？
言ってみな

既出かもしれんが、webobjects-j2ee連携が、なにげによさげ。7万円で買えるし.

日本製じゃないけどこれってどうなの?

http://otn.oracle.com/products/jdev/htdocs/j2ee_with_bc4j/j2ee_with_bc4j.html

Oracleも、 JavaSoftの MVC typeII/Pet Store Demo に対応ですか。

Oracle って、データ中心アプローチ(DOA)の会社だけど、
微妙にオブジェクト指向(OO)をマークしてますよね。
BC4Jも、SQL言語上の概念を、そのままクラス化したものだったと
思います。

だから、Viewとか Relationの概念も、とりあえずOOから使いやすく
なっていて、現状のJ2EEと補完し合えそうな感じがします。(証拠なし)

＃詳細はこれから読ませていただきます(藁

日本製のフレームワークも、この前の日経コンピュータ１／１４号で各社のを紹介していたね。
どれもこれも「駄目」な予感が．．．．

私個人的にはApacheプロジェクトのStrutsは非常にいいと思っています。
他のフレームワークは良く知らないけど。
軽いし、拡張性も利くし、思想はハッキリわかるし。
何よりタダだし。

↑73です。
日本製じゃなかった。ごめんなさい。

>>73
Strutsは（・∀・）ｲｲ!!
>>72の記事でも、ウルシステムズはStrutsを使っているみたいだね。

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

sunのPetStoreのwafが分からなくてMessageDrivenBeanに挫折してしまった。

>>76
PetStore1.3かい？
新技術（ローカルインターフェースやコンテナマネジリレーションシップ）
なんかは参考になるけれど、フレームワークとしては完成度が低いね。
まあ、あれはJ2EEパターンを適用しているものの、フレームワークを
提供しようというものではないから。

ウルシステムってUMlaut（←何て読むの？コレ）ってヤツじゃない？
お台場でソニーの携帯のサイトを構築したとか？
これは日本製フレームワークに入らないの？

ここでいうフレームワークとは違うんですけども。



バランスシートとか損益計算書、固定資産、流動資産、株、etc... いわゆる会社の数字をモデル化した Java パッケージって、ありますでしょうか。

（CORBA にもそういうインターフェースを定義したものはあるんですけども、 実際に簡単に使えるパッケージが欲しいです）

フレームワークったって、そんなに必要性は感じないな。

仕様どおりに Enterprise Java Beant が動けばそれで結構。

>>78
>ウルシステムってUMlaut（←何て読むの？コレ）ってヤツじゃない？
ウルシステムのUMlaut（ウムラウト）は開発方法論を含めた広い意味でのフレームワーク
その中に、ソフトウェアフレームワークとしてStrutsを使っているということ。

やっぱりバランスシート、損益計算書は自前でプログラミングせにゃあかんのかね。

（誰か作っているとは思うんだけど・・・）

>>82
あるけど、あげない（W

>>82

いや、、、あげられないならくれなくてもかまいませんけども。

でも、こんなの結構作ってる人多いでしょ。

なら、ちょっと公開してみよっか、みたいな人が一人ぐらいいてもおかしくないと思ったんだけど・・・、うーん。

盛り上がってるのは、技術的なことばかりで、会計とかにはあまり興味ない人が多いんすかね。

>>84 そのよーな物を、メイン・フレーム系の会社で見た事ありますが、
　使用料金はそれなりにしたよーな気がします。

　素人なんで間違ってるかもしれませんが、>>79さんのおっしゃる分野って、
　ERPとか呼ばれる分野で、製品の一部として売っているかと思いますが。

Ü←ウムラウト

いい製品なら買ってもいいと思うんですけど。

ただ、用途としては、ちょっとしたシミュレーション計算を Java プログラミングの
中で行いたいといったことなんで、シンプルなモデル（GUIも要らない）さえあればいい
のです。

そういったシンプルさをもった製品というのが、果たして、存在するのかどうか。
やっぱ自前で作るかな。

>>87
IBMの（旧）プロジェクトサンフランシスコならＷＡＳのアドバンス買えば
会計を含んだ部品集をタダで使えたと思う。

SFプロジェクト、すんごい興味あります。
ほんと、洋書で出てるシリーズまとめ買いしたいくらい。

WAS アドバンスは、おいくらくらいするのでしょうか？

>>89
1CPU200万円くらいだったと思う。
但し、過度の期待はしないほうがいいYO

J2EEコンポーネントの現状調査のために、
のどから手が出るほど欲しいんです。

＃どこぞのコンソーシアムにもぐりこんで、
＃資料or試行材料として購入するしか手がない...

>>91
ec-oneからでもモラタら？

>>92 EC-ONEからSFコンポーネントをもらえるの？？！

age

Strutsいいわけねーだろーが。
フレームワークの中で最低に位置するのを知らないのか？

>>95
具体的にどういうところが？

Strutsは、JSP/Servletまわりのフレームワーク。
EJB使わないのを前提とした場合でも機能不足なのに、
３層でやろうとした場合、使い物にならない。

>>97

いいじゃん、別にEJB使わなくても。世の中のJavaのWebアプリのプロジェクトの90%以上はEJB使ってないぜ。

>>98

んなこたーないやろ。
うちは、100%EJB使ってるし。

ウルシステムは、Struts使ってEJBやってるぜ。
日経オープン読んでみそ。

マジか？
だったら、ウルのフレームワークって実態が無いのか！？

株公開後、会社崩壊のﾖｶｰﾝ

だからー
まともなフレームワークはｃFrameworkだけだって。

ウルのYがさぁ、JavaWorldの記事で、
「Frameworkの定義は人によってそれぞれです。」
ってあったの知らない？
その直後にフレームワークを構築したって言ってない？
なんかあやしくねぇ？

ウルの言っているフレームワークは、開発方法論やプロセスを含めています。
Strutsはその中の一部です。

Ｗｅｂ３フレームワーク実際に使ってみた人いる？

プロセスフレームワークだったのか・・・
RUPのカスタマイズってことだろ。
しかも、最悪のStrutsを使ってると。
完全に騙された。

>>97 Web系MVCなんてちゃんちゃら笑えるｾﾞ、って立場なんですけど、
　EJB連携上の問題点を挙げてよ。
　＃現実的な妥協案としてStruts 触り始めたの最近だけどね。

　例えば、JavaSoft pet store demo あたりに片鱗が垣間見える、
　JavaBeans - EJB間相互作用の分離、について、
　Struts では不都合があるのでしょうか？

>>105-107 まぁ、発展途上分野の国内試行例って事で、
　開発方法論＝開発プロセス＋モデリング と、
　それを裏付ける フレームワーク、コンポーネントの試作/適用を、
　がんがんがんばってほしいと思う所存です。

　ちなみに、そーゆー事ちゃんとできる人の事、ウチでは人柱っつうて尊敬してますけど。

>>109
>ウチでは人柱っつうて尊敬してますけど。
ワラタ！
そういう人を崇め奉り、万が一うまくいったらその成果をいただくのが
正解でしょう。

「日本の企業は意識してません。敵はシリコンバレーです。」
らしきこといってたやんけ＞ウル
期待してたのに・・・
所詮、豆と大差ないのか・・・

すっげーーーーーーーーーショック！！！

いんにゃ、想像力がたらんぞ。
人柱が成功して帰還した日にゃー、成功者って事になってウザイし、
次から人柱をやってくれる人がいなくなるでそ？

人柱には、挑戦的なテーマや、無理難題を押し付けて、
各種の成功要因/失敗要因に関するデータをとって、
最後に失敗させて潰すのが基本だにょー。

んで、再起しちゃったら、次の人柱になってもらうと。

↑研究開発職が確立していない、DQN企業の場合のハナシね。
　へたに研究開発が確立している企業だと、自己保身＆得手勝手入りまくりで、
　あんまおもしろくない。

>>110,112

おまえら死ね

「わたしわ、氏にましぇん」

>>109
そーゆーの、中世ヨーロッパ史なら、道化師
　　　　　　三国志なら、客家の客とか(ちぃーと不適切)、
　　　　　　現在の企業なら、ブレイン〜CTO
あたりの路線なんだけどね。

まぁ、人生なにがおもろいって、
ちょっとは現実味のある、将来こうなったらいいなっつう絵を描いて、
それを四苦八苦して実現しようとする過程にこそ、喜びがあるんでわ？

おいおい！スレのテーマからズレズレじゃん！
どうせなら、フレームワーク構築がんばっている「人柱」さん
の情報とかないの？

>>117

禿げ同。
112とかたちわる過ぎ

なんでもいいが、
ウルのＹさんがニヤケたら漫画家の蛭子さんに似ていないか？

>>120
ﾜﾛﾀ
わしは、こういうオバちゃんいるなぁとおもったが・・・

でも、うわべだけでも尊敬しとけＹＯ！！！

>>121
ははー！
そうさせていただきます。
ご指導ありがとうございます。

117さんが大勢いるような会社ってどこよ。
教えてください。

漏れの考え違いかもしれんが、
cFrameWorkやWeb3フレームワークにしても、Presentation側実装と
EJBコンポーネントとのインターフェースを標準化して、再利用性
を高めることを狙ってはいるが、本当にそれだけでいいのかね。
実はEJBコンポーネント側の設計に関してはあまり示されていない
と思うのだが。

>>123 例えば旧通産系の公募案件とかでよく名前の出るあそことか、そーでわないの？

　でも、基本は個人主義。
　DQNっぽい印象の会社で、世間的に名前を知られていなくても、
　ニーズを掘り下げて、理念は高く、でも現実に足を付けて頑張ってらっしゃる
　方が大勢いる。身近の信頼できる人に紹介してもらってはどうですか？

　ちうか、理想だけの奴集まっても成り立たんし、
　理想なしの奴だけだと発展させにくい。バランスも大切。

>>124
　アーキテクチャ・ドメインと、
　業務共通ドメイン、業務固有ドメインのお話でそ。
　アーキテクチャ・ドメインは、比較的一般性が高いので、
　たしかに目立つわな。
　業務固有ドメインだと、一般提供＝競合他社への情報提供になるから、
　公開しにくいんだろーと思う。

>公募案件

M下とかそういうの？

よくわかんないですけど。
例えばビジネス・オブジェクトとか、天才プログラマとか、究極vs至高とか(そんなのないか笑)、
旧通産省機情局とか、日本のコンピュータ・サイエンス界のスターとか集めてやってる、
あれ、の事です。

>>127
それってCBOPとかの事？

>>118 人柱さんが必要になる下等会社では、
　４層とかフレームワークの必要性とか実践しても、
　「動けばいい、無駄なことするな」ちうといて、別の場面では
　「再利用による生産性向上」とか唱え出すから、
　あまり役に立つ情報は提供できない。

　こないだNTフォールト・トレラントの説明会に行って、
　物流向けシステム開発の会社が出てて、
　「ウチは物流会社のSPIN out組でして、
　　フォークリフト免許持って現場やってた人間が C# や Javaしてますから
　　理論と実践(現場＆ビジネス戦略面)おっけです」とかのたまってたが、
　そーいう所は(J2EEフレームワークとは関係ないですが)結構信頼できそう。

　物流向けシステム開発って、ORとかグラフ理論とかバリバリ必要だし、
　やんちゃな現場の人への配慮も必要だから、すんげー面白そうだと思った。
　＃漏れの会社にもあるけど。

　そういうレベルの連中が、もっとオブジェクト指向〜業種フレームワーク分野に
　侵攻してほしいと、切に願う今日この頃...

>>128
　>>127は、公募案件の説明しただけ。
　あれに応募してるとこって、玉石混合だと思うが、
　本気で頑張ってる方は、あれへの応募を勧める。
　あちらさん(主催者側)も、本当に世の役に立つことを望んでいるしね。

　CBOPはどっちか知らん.

　技術がわかって、上層部巻き込める、
　口八丁手八丁、要領良くて誠実な、マネージャに一枚噛んでもらわないと、
　公募すら難しいけどね。

↑PS.
○応募
×公募

あと、公募案件ちぃーてるのは、
ぶっちゃけ http://www.ipa.go.jp/ のこと。

で？セキュリティ事業は？

参考スレ
http://pc.2ch.net/test/read.cgi/tech/1001950590/l50

WACsに関して全然知らないので、もう少し教えて下さい。
リンクでもいいのでお願いします。

WACsに関して全然知らないので、もう少し教えて下さい。
リンクでもいいのでお願いします。

>> 135
何が知りたいの
リンクなんてないよ。製品じゃないしね

WACsがどんなものか、どうやって手に入れるか？です。
WebSphereについているのですか？
それに対する本や資料って出ていますか？
StrutsのようにMVCフレームワークなのでしょうか？
それともライブラリとテンプレートの集合体なのでしょうか？
まったくわかりません。
よろしければ是非お願いします。

>137
>133のスレは読んだ？
WACｓの評価は概して良くない．
OODじゃなし，Javaを使うけどOOPでもない．

>>137

総じて138の言うとおり。

入手方法はIBMのSIerになるか，IBMが噛んでいるプロジェクトに
入るのが普通。著作権はあくまでIBMが持つしな。
WebSphere(WAS)についてくるわけじゃない。
製品じゃないしそれにあくまで東京のIBM部隊がつくった
ものにすぎないんでしょ。
当然本や資料もない。WACsにはドキュメントはついてるけどね。
Strutsと同じくMVCtype2のフレームワーク。

こんなとこ？

WACsって自分から使おうなんて思うシロモノじゃないよ。
将来も自分とこのハードやアプリケーションサーバーから離れられないように
するための営業の仕込んだ毒みたいなもん。
アーキテクチャはcgi以下で、時代から取り残されたCOBOラーとか多い会社でも
「すぐにナウなjavaプロジェクト始められるよ〜」ってのが唯一の売り（藁
実装する側までＯＯで書かせてくれないしEJBとかJ2EEまるでできん。
設計らしい設計できないんで使うと後のツケはでかいよ。
１０００とか２０００ステートメントのクラス作りたきゃどうぞ (^^;

>>137です。ありがとうございました。
実は社内でフレームワークを使おうって事で盛り上がっていて、
その中でIBMのがいいんでは？という意見が多勢なのです。
貴重な意見を本当にありがとうございます。
感謝します。

>>140
フレームワークってそんなもんなのですか？
なんか萎えるなぁ。
他にまともな製品ないのでしょうか。

自前で作れ＞ＡＬＬ

Assam AnyWarp

>>Assam AnyWarp
あれのどこがいいって言うんだよぉ
日立ソフト内部だって、AnyWarpを嫌がって、Struts使っている
連中がいるじゃん。

http://www.atmarkit.co.jp/fjava/devs/casestudy01/01.html
にてAssamのこと載ってるけど、個別サーブレット方式、集中
サーブレット方式という言葉は初めて聞きました。
でも個別サーブレット方式って単純な設計になるけど無駄が
多く感じます。
宗教戦争はしたくありませんが、個別って本当にいいですかね？
集中で画面が増えると既存サーブレットに手を入れないといけない
って書いてあるけどそれって設計が死んでる、もしくは個別の考え
しかできてないような気がします。
AssamってOOPはできるんですか？ネーミングルールが某みたく
きつくないですか？

>>146
>AssamってOOPはできるんですか？ネーミングルールが某みたく
>きつくないですか？
AssamはドカチンＤＯＡですがなにか？

Assamってワインバーグ氏の言うところのゴーマン法則だね。
設計の古さを機能や特徴として売っているの多いんだよねぇ。
フレームワークでそういうの。

集中サーブレット方式by日立ソ○トとか入口サーブレットbyＩ○Ｍとか
J2EEパターンについていけてない独自用語な時点で終わってる。

>>147 >>148 >>149
あが。
ドカチンDOAですかぁ。泣けてきますな。
IのWの展示会でこれからはStrutsだ、っつーてたおじさまは
Hの人だった気がするのですが。
H社内でも現場の人間にはOOは難しいんだっていいながら
DOA売り込んでる対立派閥がいるんですね。

IBMが勝手に名付けた MVC TypeII (元ﾈﾀは JSP v0.96 仕様書の JSP使用形態分類)
ってのも、本家Smalltalk他の MVC フレームワークとはｶﾅｰﾘずれててキモイ。


漏れも 6年程前に検討したけど、
・HttpRequest＝Event(の前駆体)と解釈して、
・Servlet近辺にイベント・ディスパッチャー(やRequest→Event変換)を置いて、
・Model更新→View更新の Observable-Observer関係をネグって、
やると MVCもどき にはなるが、元のMVCとは似ても似つかない…。


J2EEでは、Web層(Servlet＆JavaBean)→AppServer層(EJB)間の相互通信をシンプルにするために、
リモート・イベント通知の仕組みを作り込む必要があり、上記MVCもどきの再構成が必要になる。
この辺りは、JPSコードでも実装され、J2EEパターンとしてまとめられてるけど、
まるでゴシック様式のカテドラルでも見ているかのような眩暈を感じる。


更にさかのぼれば、オブジェクト指向のノウハウは、
パターンという、内容は明確だが抽象度や形式化が不充分なカタチでまとめられて
いるから、用語のばらつきどころか、実装解釈のばらつきもヒドイもんだ。
ただ、それは「終わってる」んじゃなくて、「ばらけていて、再利用性の障害になっている」って感じ。

＃蛇足だが、イベント・ディスパッチャーやアクセス制御機構をサーブレットの外に置けば、
＃>>149で挙げられてるやり方(集中サーブレットとか入り口サーブレット)の必然性は低い(と思う)
＃もっとも漏れは、サーブレットを一個未満で済ます主義だけど(ｗ

>>147,>>150 ドカチンＤＯＡ
Javaは、ODBを見捨てて JDBC〜ORDB方面に走った時点で、
OOとDOAの融合を目指している。

マイクロソフトもオラクルもIBMも、90年代中頃には似たような選択を済ましてたハズ。
まあ、ドカチンＤＯＡ避けたいんだったら、業務アプリから足を洗ってはいかがですか？

このあたりの事情/現状は、最近でた翻訳本
　「オブジェクト指向設計法によるデータベース設計技法―UMLによるデータ・モデリング」
　http://www.amazon.co.jp/exec/obidos/ASIN/4883030954/ref=sr_aps_b_/249-8242157-2236307
　が詳しい。
＃つうか、RDBのオブジェクト指向的解釈や、業務アプリ系のパターン集の国内発売遅すぎ。
＃漏れは、数年前からその手の洋書漁ってるYO!

>>148 設計の古さを機能や特徴として売っている
現場で製品導入して使いこなせるレベルは、所詮そのあたりだから、しょうがないよね。

業務アプリ系のパターンとか、アナパタとか、メタモデル・パターンとか、
すぐに使いこなせる人は、自分でフレームワークやパターン作ったり、
特定分野向けのパッケージ作って商売しているんだと思うよ。(汎用にするの難しいし、売れないから。)

>152
すいません。自分はへたれですのであまり大層なことは
わかりませんが、JavaがOOとDOAの融合を目指している
というのはどのへんを指してらっしゃいますか？
EJBのCMPなどがんばってるのはOODBをあきらめてはい
ないと思います。

翻訳がでるのが遅いのは本当ですね。質の低い翻訳を出される
よりはましですが。私も洋書を読みますが、高いのと国内の用語
と両方覚えなくてはならないのがつらい時があります。
全部カタカナでやってくれればいいのですが。（笑

本のご紹介、ありがとうございました。
それはまだ読んでないので読んでみます。

>153
煽りでなくなぜ現場では使いこなせないと思いますか？

いえ、皆そういうんですよ。で、現場に配属された私は腹が立つんです。
あぁ、おれは見切られたんだなぁって。（笑
私は使いこなせないとは思わないんですけどね。
ただ巨大な現場では再利用とかデザインよりも各下請けさんが
勝手に画面ごとにコーディングするほうが各社さん楽なのかな
とかも思いますけど。やっぱ足洗うべきかな。（泣藁

>151さん
6年程前に既にStrutsのアクションサーブレットのようなものを
考えられてたのですか？　すごいですね。

MVCのObserver−Observableですが、Webアプリで
ObserverをどうModelに関連づけて、Servletの起動、
Model(Bean?)の変更、Observerの起動（HTMLの出力？）
とやったのでしょう？

よければもう少し詳しく教えていただけませんか？
ヒントやポインタだけでも結構です。

あと>149さんが終わっているといったのはOOやパターンでは
なく、IやHの思考停止な商売でしょう。
パターンの用語のばらつきは商売になるのでわからずとも
語る人が多くなりすぎた嫌いがあるとおもいます。

イベントディスパッチャーというのはStrutsのアクションサーブレットと
考えてよろしいですか？
サーブレット1個未満というのは０個ですか？(笑

EVS Frameworkは（・∀・）イイ！

>>154 JavaがOOとDOAの融合を目指しているというのはどのへん

Javaが、というより、J2EE〜WebService分野限定のお話かもしれませんね。
一応補足しますと、

(1)Java APIや、Java Community Processでは、
　　ObjectDBへの対応はほとんど考えられていないように見受けられます。
　　　　http://www.jcp.org/aboutJava/communityprocess/accepted.html
(2)J2EE/EJBのEntityBeanは、データ構造とそのメンテナンス・ルーチンをまとめたものであり、
　 ObjectDBや、Serialize APIが提供する「オブジェクトの永続化機能」とは、
　 目的も機能も適用範囲も異なる、と思われます。
(3)業務アプリケーション分野の優秀な開発者の多くは、
　 RDB技術やDOA的手法(データモデリング→ビジネス・ロジック付加)に慣れており、
　 彼等には DOAの経験を生かせる OO環境を提供した方が、混乱が少ない
　 という判断が、なされているように感じます。(過去のJava APIやJSRの流れを見て。)
　

>>155 煽りでなくなぜ現場では使いこなせないと思いますか？
(1)自分自身でアーキテクチャや方法論を探索するだけの技量を持った方が少ないから。
　＃構造化〜DOAﾏﾝｾｰで、OOを知識としてしか知らない方に、洗脳手法をかけずに(ﾜﾗ
　＃納得付くで OOのメリットを説いたり、OOと彼等の手法のブリッジを提供するのは、
　＃とてつもなく知力と体力が要る仕事だろうと思います。そーゆー意味で「JavaによるOO普及」は偉大！

(2)国内では、Servletの流行まで、オブジェクト指向の軽視が続いてきたから。
　＃10年前の私の夢は、フレームワークやデザインパターン、型システム等について、
　＃あたりまえのように議論できる仕事環境の実現でした。当時を思うと隔世の感がありますが…
　＃でも、私自身はこの分野で10年間足踏みを続けていたのかもしれない。

(3)もっというと、国内では、ソフトウェア開発技術が軽視されつづけているから。
　＃優秀な人材の多くは、ソフトウェアよりハードウェアやサイエンスを志向するという実態。
　＃あるいは「ソフトウェア開発は簡単であり、現場の土方解くべき問題でしかない」という誤った考えの蔓延。

＃＃Yourdonさんのような乾いたユーモアを書くには、もっと修行が必要だと反省。

>158さん、　もったいないからage
ご丁寧にありがとうございました．
JCPまでは私は追っかけていないのでわかりませんでした．
私自信が今体験しているODAが特殊なのかもしれませんが，
私の現場ではODAはOOとは融合せず否定するものです．
その意味ではEJBとODAは絶対に混ざり合わないような気が
します．彼らのやり方ではサーブレットはデータをキャッチボール
するプログラムですし，ビーンは箱です．全く持ってOO的な
使い方はなせれていません．彼らはドキュメントからしてOOを
否定し，Javaでも手続き型プログラミングは可能だと宣言し，
彼らの提供するAPIはJavaの標準ネーミングには全く沿わず
ほぼ全てがstaticで，プリミティブ型な引数の数は限りなく多く，
Javaを少しでもかじった私にはとても信じられないものです．
Sunの進める道がODAとOOの融合であると仰られる１５８さんの
意見には私のODAに対するネガティブな感情からは多少不安を
もたらしますが，今現在のSunの進め方からすれば安心してみ
ていられると感じます．
（３）についてもう少し具体的な例をご教授願えませんでしょうか？
私はCMPのSQLの隠蔽やアプリケーションサーバが簡単に
Objectとして作成できることにOOの良さを感じているのです．
なんというか，単純な通信をうまく皮をかぶせてOOっぽくしてくれ
ているような．その方向は常に一方向で，その濃度はゆっくりと
だが徐々に濃くなっていくような．

すいません。
漏れの肛門は、なんで開発すればいいでしょうか？

すみません．ODA　−＞　DOAです．
ほんとアホですね．
逝ってきます．

>>157
聞いたことないけど。
あとホムペみたけど、これって単なるJ2EEの機能じゃん。
素人会社を狙って営業するためのネタなんだね。

159さん，ありがとうございます．

（１）は本当にそうですね．残念なことですが．でもそういう人は不景気
による生き残り競争のおかげで減ってきてはいると思います．
（３）な人は（１）な人でプログラムなんて誰が書いても同じになる，
俺が設計してやってんだよって人に多い気がします．
そんな人ほど基礎体力がなってなくて，設計がとてもひどかったり
しますが．
（２）は私にはJavaそのものとAppletの出現，Webの大流行で
花開いたと感じております．CGIにはPerl大流行という私にとって
あまりうれしくない側面がありましたから．Servletが出現してから
も，Javaで記述されたServeｒに拘ったSunは最初失敗していたと
思います．まぁ，時期的には誤差の範囲ですが．(笑

私自身はなぜOOが現場に普及しないかという答に悪い意味での
仕様書主義を感じます．彼らの仕様書記述からのWaterFallへの
拘りは凄いですから．そしてステップ数での評価でしょうか．
彼らにとってはリファクタリングを施しステップ数を減らしたり
することは信じられないことのようです．
そして最後にはやはりOOへの不信です．結局各社のSpecificな
要求への対応には抽象化も再利用もないと思っているようです．

私はちっぽけなプログラマとして，ポリモルフィズムによる単純化，
それによる信頼と変化への柔軟性．カプセル化による安定．
そしてメソッドがクラスに属すことの構造の美しさ，理解のしやすさ．
それだけでもOOが使いたくてしかたありません．でも全否定されて
しまうんです．だって，それはDFDでは表せませんから．

私も頑張って私の望むやり方が多大なメリットをもたらすのだという
ことを現場で説明できるようにならなければなりませんね．
でなければただのオタクのわがままですから．
でも最近かなり鬱です．(笑
勉強します．

日本には、フレームワークっていっぱいありますが、結局、ＯＯで開発を行う
ことを前提としているものは無いようですね。
わたくしも、assam使って開発しましたが、まさしくドカチンにふさわしい
仕様書の嵐なので辟易してしまいました。
というか、あれは、ＤＯＡ以前ですね。
だって現場では、データモデルなんて一切書かずに、テーブル定義書を直接
書いているのですから。
そういう意味では、ほとんどのフレームワークって以下の�@に対応？
�@ドカチン工学不在主義対応フレームワーク
�A一応ＤＯＡまともに考慮しているフレームワーク
�BＯＯ開発をちゃんと考慮しているフレームワーク

私見ですが、オブジェクト指向での分析クラスモデル（ＢＣＥモデル）を
フレームワーク前提での設計モデルに展開させることはそんなに難しく
ないと感じています。
＃実際にはそういったことすら説明しているフレームワークってありませんが
＃どうしてなんでしょうね？？？

一番問題なのは、ＯＯによる開発方法論に無理解な人が多すぎて、フレーム
ワークに変なことを求めすぎる傾向が強すぎることでは？

>>160
丁寧なレス、どうもありがとうございます。

「OOとDOAの融合」に関する私の説明(>>158)全然説得力ないかもしれませんね(漠。
＃結局>>152の本「オブジェクト指向設計法によるデータベース設計技法―UMLによるデータ・モデリング」の存在知って「OOとDOAの融合って路線でおっけかなぁ」と言ってみるテスト(爆
　

数ヶ月前、IBM alphaWorksの [OOとDOAの(派閥)対立] に関する記事を見たときは、
我が意を得たり などと思い、記事のURLやプリント配りまくったもんです...

が、冷静に考えてみると、OOとDOAの対立を殊更強調するのも愚かに思えます。

むしろ、OOA/OODと、DOA的手法や、Yourdonの構造化手法の連続性を踏まえて、
各手法間のギャップを埋めつつ、地道にOOのメリットを実証していくのが
現実的かもしれません。

＃仕事上でOOを試行錯誤するとか、
＃OOとDOA/構造化の違いを謙虚に示すだけでも、
＃上司や周囲の理解は不可欠ですよね。
＃なんて事をしているうちに、自分の修行は足踏み状態。

>>160　>>158（３）についてもう少し具体的な例
って、難しいです。
・ことさら相違点を強調して、拒絶反応や対立を引き起こすか、
・あるいはOOとDOAの共通基盤を明らかにした上で、
　いくつかの追加と変更をするか、
って違いなので、リファレンスを示すのは難しい。。。

>>156
ドカチン・コードの問題点とか、直すべき優先順位って、どんな感じでしょうね。
・共通機能の括りだしの欠如
・再利用性の欠如
・モデリングの欠如

＞私見ですが、オブジェクト指向での分析クラスモデル（ＢＣＥモデル）
　http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
のあたりの議論ですね。
私も、パターン本買い漁ったり、高木さんや萩本さんが Horb〜JHB MLで議論された
当時から、気にはなってます。
＃つうか、この辺りの話知ってると、
＃「Servlet＆JSPで、MVC(type1)実装しますた」みたいな議論のいい加減さに噴いちゃったりします。

結局、J2EE/MultiTear向きのアーキテクチャ・パターンは、MVCか改良MVCかPACかPADかBrokerのうちどれか1つ
なんて事はなくて、
アプリやフレームワークの実装段階では、細かい検討や投げやりな決断積み重ねて、
その結果を他に説明する段階で「MVC typeII」とか「Brokerパターン」とかお話作ってた方が、
健全な感じがします。。。

＃Struts とか Barracudaとか J2EE BluePrintが、MVCを出発点に修正図ってるのもスゴク理解できるけど。

160です
>>168
>http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
>のあたりの議論ですね。
ちなみに、萩本さんはＭＶＣ、ＰＡＣとＢＣＥモデルを同じような次元で
説明されていますけど、これって誤解を招きそう。
このスレの皆さんはレベル高いからわかっていらっしゃると思いますが
ＢＣＥはあくまでもＯＯＡにおける抽象モデルであって、
ＭＶＣ、ＰＡＣのようなアーキテクチャとは視点が違うんじゃないでしょか。
つまり、ＢＣＥでの分析モデルは、設計以降で適用されるアーキテクチャに
対してニュートラルであって、特定のアーキテクチャを示すものではない
と思うんですが、どーでしょう？

>160です
すみません。
165の間違いでした。

>>http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
>>のあたりの議論ですね。
>ちなみに、萩本さんはＭＶＣ、ＰＡＣとＢＣＥモデルを同じような次元で
>説明されていますけど、これって誤解を招きそう。
>このスレの皆さんはレベル高いからわかっていらっしゃると思いますが
>ＢＣＥはあくまでもＯＯＡにおける抽象モデルであって、
>ＭＶＣ、ＰＡＣのようなアーキテクチャとは視点が違うんじゃないでしょか。
>つまり、ＢＣＥでの分析モデルは、設計以降で適用されるアーキテクチャに
>対してニュートラルであって、特定のアーキテクチャを示すものではない
>と思うんですが、どーでしょう？

私もこの講演聴きました。クラスという細かい単位で設計する前にクラス
をおくための場に責務を与えて、その上にクラスを置くという話と、そも
そも設計課題がないままMVCを使うことはおかしいというような内容だっ
たように思いますが、この話には何ためらいもなくMVCを使っていた僕に
とっては目から鱗でした。

BCEも設計でも有効ですし、MVCもPACも特定のアーキテクチャには依存しな
いものだと思いますので、特に誤解をまねくものではないと思います。
ただPACについては、よくわからなかったので、この講演の後で萩本氏をお
っかけて質問しました。PACの場合はPACの３つでPACエージェントを構成す
るので本来ならこの中で比較するというのは適切ではないといわれていま
した。

何でみんなEVS Framework使わないの？
安いしイイのに。

>BCEも設計でも有効ですし、MVCもPACも特定のアーキテクチャには依存しな
>いものだと思いますので、特に誤解をまねくものではないと思います。
了解しました。
但し、分析モデルとしてのBCEにおける責務分担に対して、
設計モデルにおいて以下のアーキテクチャパターンを適用
した場合、それぞれにおける責務の微妙なズレをちゃんと理解
していないとまずいわけですね。
・smalltalk-MVC
・J2EE-MVC
・BCE
・PAC
話は戻りますが、日本製フレームワークってやっぱり
アーキテクチャ不在？

>>172
この会社はJ2EEの開発を行っているのですか？(藁

っで、フロントコントローラ系って何が幸せになるの？
デザイナーのオーサリングツールが使えなくて不便になるし
URLが同じになっちゃうんでServletTesterなどのServletの
ホワイトボックステストツール使いにくくなるし．．．
このバカな私に教えてやってください。

>>175
Servlet2.2以降対応のフロントコントローラなら、URL同じでなくても大丈夫じゃん。
何が幸せになるのかは微妙。フロントコントローラだけだと、アーキテクチャを縛ってくれることくらいかな。
ただアーキテクチャを縛っておくと、その上に便利な機能作りこめたりするのがいいかも。
StrutsのTaglibとか、Form自動解析/入力値再表示なんかはその例かと。
で。ServletTesterって何ですか？
それはServletUnitとかよりも遥かに幸せになれるもの？

Strutsがあるのに、なんで国産フレームワーク作る必要があるのか、ものすごーく疑問
もしかして、よっぽどヒマな人が多いと思われ（藁

あぼーん

>>177 既知外

なんかせっかく良スレになってきていたのに
勿体無いので正常化期待age

保守

ところで、
ServletやTaglibバリバリのフレームワークって、
Webサービス全盛になった時に役に立つのでしょうか ??

>>182

利用するスコープが違うからあんまり意味を持たない疑問の
ような気がするな。
182氏のいうフレームワークってStrutsとかのことでしょ？
人間が使うのがWebアプリフレームワークであって，
Webサービスを直接使用するのは人間じゃないよね。
単にStrutsにWebサービスクライアントのコードを直に
埋めるか，そのためのさらなるプロキシの仕組みを
入れればいいだけだと思う。

>>183
Webサービスをクライアント／サーバー技術として使うことも
十分あるんじゃないの？

>>184

そりゃあるよ。でもそれは182氏の疑問とは
また違った話でしょ。

それに，C/Sという位置付けということならWebアプリフレームワーク
とWebサービスアプリの関係と何も変わらないからそもそも意味的に
直交しないと思うのだが?

人間 <==> C/Sでのクライアントアプリ(Webサービスクライアント) <==> Webサービス提供側

人間 <==> WebアプリF/W(Webサービスクライアント) <==> Webサービス提供側

これってどうよ？いかにも使えそうにないサービスなんだけど。
http://www.jcreation.co.jp/venus/

>186
とうCOBOLとjavaをマッピングするのか書いていないだけに
眉唾っぽいなぁ。
特許出願中ってのも雑誌のあやしいペンダントの広告みたいだし

>>187
ＥＶＳ　Ｆｒａｍｅｗｏｒｋはそれ以下。
だって単にニュースリリースネタで発表しているんだもん。
自作自演企業（藁。

♪♪イーベンチャーサポート♪♪♪
www.evs.co.jp

社長池上は、

・ＡＳＰもダメ
　→わずか6ヶ月で撤退（結局、モノは出来なかった）

・Ｆrameworkもダメ
　→ニュースリリースは出したが、やっぱりモノは出来ていない

・人材派遣（それも違法請負派遣）
　→バカでも立ち上げやすい、違法請負派遣業にやっと落ち着く。でももうだめぽ


の３ダメ男。これはもう、逝け神ぽ。

皆さん、こんな会社にサポートされたいですか？
ｼｮﾎﾞｰﾝ━━(´･ω･`)━━

EVSはだめってことで、そろそろ新ねた。
株式会社テンアートニのWeb Developer Cafeってどうかな？
http://www.10art-ni.co.jp/product/WWB_Family/wwb-dc_index.html

見る限り……

>>190
HtmlFormESB？
Web層の責務をEJBになんで持ち込む必要があるんだ？
問い詰めたい！小一時間問い詰めたい！

>>192
何が悪い？

JDBCとかServletのラッパーを用意してよろこんでいるようなフレームワークって大抵
設計が古いよね。へんてこりんなＡＰＩ覚えるよりJDBCやServletのほうが
簡単なのに、うたい文句に踊らされる会社も多いんだよね。
結局わけわからんでフレームワークのトレーニングとかサポートで高ーい
お金払う目に．．．それでも気がつかんDQN会社も多し。

>>191

俺も同意
EJBってこういう使い方をそもそも想定してるもんではないような
気がするが…いやそりゃ動く動かないのレベルで困ることはないにしてもさ。

#画面遷移状態やリクエストパラメータのバリューオブジェクトへの変換が
#EJB層でってのは「?」だな

NECのOMEはどうですか？

>>194
動けばいいんじゃない？

>>196
それじゃフレームワークも糞もねーだろ。

http://homepage.mac.com/leverage/

今現在○○○FrameWorkの業務の要望にあわせてカスタマイズしています。
FrameWorkチームは業務側の要望を詳しく知らないし（俺）。。。
業務チームはFwを良く知らないし。
連携がまったく取れていなく、結構大変です。

むー。はい。愚痴です。

>>197
動作して、速くもの作れればいいじゃん？

なんでコレで早くモノ作れるの？
くだらないフレームワーク使うぐらいなら.NETのほうがいいな

プ逝一必死だな(和良

>プ逝一必死だな(和良

意味わかんねーよ。糞

一応、処理の共通化、画面遷移、入力チェック等、
その他色々処理ってくれるんで、大規模Web開発には必須かと思います。
はい。素から作るよりは絶対。

でも、そのうち俺は.NETに移る予定。

>>201 >>204

.NETでもこういう処理をやってくれるフレームワークが必要な罠

>>204
テン○ートニ社員？
こんなところでＰＲすんなよ。
>その他色々処理ってくれるんで、大規模Web開発には必須かと思います。
画面数の多いシステム開発には便利かも知れんが
こんなアーキテクチャじゃパフォーマンスは相当
低いだろが。

>>206
残念。
僕チンはとある○便茶との個人契約です。
辞めるけど。

>こんなアーキテクチャじゃパフォーマンスは相当
>低いだろが。
そんなアホなロジック組んでないし。
それに、今の時代はCPUに気合入れさせれば良いのかと？思うけど。

>>207
>そんなアホなロジック組んでないし。
>それに、今の時代はCPUに気合入れさせれば良いのかと？思うけど。
ちゃんとロードテストしたか？
ＣＰＵ数多くてもアフォなアーキテクチャだと本番で死ぬぞ。

分散アプリは、ミドルがどんなに賢くても、最上位層の実装
がアホだったり設定がアホだったりすると、必ずとんでもな
い性能になりますね。未だにアプリケーションの設計/実装
方法に性能が依存するわけですね。

クライアントからの1トランザクションが内部でリモートの
EJBサーバオブジェクト25個を順に舐めていくという、とん
でもない設計をしていたバカが、知り合いにいます。

SessionFacadeパターンにするか、EJBサーバオブジェクト
のクローンをクライアント側にキャッシュするなどして、
通信の発生回数を極力抑えるべき、という程度のことは、
少しでも分散アプリを扱ってきた人間なら当たり前の常識の
はずです。

確かにリモートオブジェクトをある程度シームレスに扱える
通信層ラッパーは便利でえらいと思います。でもバカに分散
アプリを一見扱えるような錯覚を与えてしまい、ろくでもな
い悲劇が量産されてもいます。こまったもんですね。

http://www.atl-systems.co.jp/
ここのはどう？

R&DのところにJAVAフレームワークがいろいろある

>>200
アセンブラでやれっつったら高級言語のほうが楽だろ？
同じ理屈でないの？＜フレームワーク

>>210
すげーぜ！
なんかここ、J2EEサーバーまで自分のところで作ってやがんの。
本当に自分の所で１００％作っていたら神だな。
でも実体はどうせTomcatやJBossをパックっている予感。
ちなみに、コンテナ自作している割には、フレームワークと
称している部分がちゃちなのには笑える。

>>213

ていうか、JSP/Servletコンテナじゃん。
そんなもの、自前製品で出す必要ないんじゃ･･･

フレームワークも、テンプレートといっている時点で
そこがみえるような・・・。

画面遷移のためのフレームワークなんてのが、べた実装してありそうだ。;<

>>214
激しく同意！！

これってどうよ？
JavaOneでセッション聞いた限りでは
たいしたこと無さそうだったけど

ttp://itpro.nikkeibp.co.jp/free/JAV/NEWS/20021014/1/

>>216

コムウェアのラズベリーはすごいっす。
他のハンパなフレームワークとは違うよ。

>>217
ふ〜ん、どの辺が？

バンドルしてる(?)開発用ツールの説明を沢山してたけど
でもそれはFrameworkの機能とは別の話だし。。。

>>216
>開発プロセスの面では、オブジェクト指向設計やJ2EETMでの開発経験が
>浅いシステムエンジニアや開発者でも、開発技法に沿って作業すること
>で、容易に業界標準のシステム構築が可能となります。
要するに、ゴムウェアのようにレベルの低い連中でも開発できるように
レベルを下げたフレームワークってこと。
さすがだね。（間違ってもこんなもの使いたくないね）

コムウェア馬鹿にすんなゴルァ！
Java関連では日本有数の開発実績持ってるんだぜ。

>>219
レベルを下げたフレームワーク使いたくないって、その通りなんだけどさ。

コムウェアの肩を持つつもりはないけど。
英語読めなかったり、”javacへのPATH”の意味がわからなかったり
「コミット」「ロールバック」を知らないようなメンバーだけだったら？
"Java"と"JavaScript"の違いがわからない人がまじっていたら？
そんなメンバーでプロジェクトを遂行しなくてはならなかったら？

たぶん >>219 は頭がいい人で、ソフトウェア技術という点では周囲にめぐまれて
いるんじゃないかなぁ。

IBMがStrutsを拡張したのをオープンソースでだすらしいね。

>>220
日本有数のデスマーチプロジェクトの実績ですか？

楽々Framework�U、名前は笑えるけどなかなか良さそうだ。
未経験者でも４日の研修でOKだってさ。

http://www.sei-info.co.jp/fw2/kinou.html

>>224
おまいら！！
なんで、トンデモなフレームワークばっかり見つけてくるんだぁ！！
そんなヒマあったらまともなフレームワークを作ってください。

>>224
・データ辞書にデータ項目を登録すると
　HTMLへの表示項目制御、入力したデータ内容のチェック
　等を自動化してくれる。
　が、なぜかＤＢへのデータアクセスは自分でＪＤＢＣの
　コーディングをする必要がある。（駄目じゃん！）
・データ登録、検索条件入力など、典型的な画面に関する
　パターンのテンプレートが用意されている。
　が、当然ながらデザインが決まっているので、ＨＴＭＬ
　の画面デザインに関する自由度が低い（自分でパターン
　作ればいいんだけどね）
・高い生産性を実現します。
　が、基本料金1000万円ってなんじゃい？
・新たにオブジェクト指向設計を導入する必要がない
　楽々Framework�Uによる開発では、これまで業務系
　システムを構築する際に利用してきたデータ中心設計
　手法（ＤＯＡ）で設計するため、開発者のかたは
　「オブジェクト指向設計」を新規に習得する必要がありません。
　が、オブジェクト指向設計もわからんヤシに
　ＤＯＡだからって設計できるとは思えん。
これくらいでよろしいでしょうか

age

オブジェクト指向設計を導入する必要がないってのは
いんちきフレームワークの証
ワインバーグの法則で「欠点を機能とする」ってヤツです。
「当社の製品はオブジェクト指向でできていません」ってことです

>>226
>>228
pu

オブジェクト指向でないことを欠点かのようにとらえることこそDQNの証。
本当の実践者なら使わなくてもいい場合が多いことに気づくもんだ。

なんで日本人は、会社でフレームワーク作りたがるの？
J2EE関連ならオプソを適当に集めて使えば、それだけ
で十分便利だと思うんだけど･･･「コスト」って単語知
らないのかねえ･･･

>>229
>オブジェクト指向でないことを欠点かのようにとらえることこそDQNの証。
>本当の実践者なら使わなくてもいい場合が多いことに気づくもんだ。
オブジェクト指向使わなくていいことを長所のように言っているから指摘
しただけだが、なにか？
本当の実践者であれば、オブジェクト指向とＤＯＡを適材適所で使いこなす
というのが正解。

>>229のおバカさんへ
226のおっしゃる通りオブジェクト指向でないことを否定しているわけじゃないんだよ。
あんなふうに売っているフレームワークにはロクなもんが無いよということ。
それにオブジェクト指向わからずjavaで作ろうなんてバカ。
Sunの提供するAPIが使いこなせねぇじゃん。
ちょっとしたWebサイトならJAIとかJavaMailぐらい使うだろ。
ま、チミのように「実現できましゃん」連呼してるコボラーにはわからん話だけどね。

>>232

>それにオブジェクト指向わからずjavaで作ろうなんてバカ。
>Sunの提供するAPIが使いこなせねぇじゃん。

キミは救いようのない馬鹿だね。煽ってみたら予想以上のDQNだったな。
JavaのAPI使いこなすのにオブジェクト指向設計のスキルなんかいるかよ。

ところで、日本ＩＢＭが作ったExtension for Strutsだけど、
皆さんどう思いますか？

>>229
悲惨なjava初心者がいるスレはここですか?

ぶーははははは

>>234

http://pc3.2ch.net/test/read.cgi/tech/1022854260/
は見てる?

http://itpro.nikkeibp.co.jp/free/NOS/NEWS/20021126/1/

Sophia Framework
http://www.s-cradle.com/index.dir/Japanese/business.dir/pro-sframework.htm

話をそらしてスマソ！
今、Strutsを使って開発している会社ってどのくらいあるのかね。
・ウルシステム（UlrautはStrutsがベース）
・日本ＩＢＭ（Struts Ext.）
・日立ソフト（Assam Anywarpはどうなるの？）
他にもコソーリとStruts採用を予定している企業が結構あるとか。
情報キボンヌ！

ファイテックラボのxTradeはフレームワークとしてどうだろう？
ここにあがっているものとは異質だろうけど。

>>240
永続化関連のコンポーネントだとか、ネット証券業務に関係のない
独自の部品は凝っているみたいだけどね。
（もっとも、今時そんなの凝ってドーする？）
肝心の業務コンポーネントはちゃらい。
こんなの数千万円で売れるとは思えん。

>>241
パフォーマンスが売りみたいだけど、業務コンポーネントの部分が弱いならだめかな。
頑張っているところは評価してあげたいけど、結局な・・・「既存のものをうまく使う」
ほうがいいかな・・・

（＾＾）

ECOSSやcFrameworkを導入するくらいなら
必要最低限のシンプルな構成で自作した方がマシってことか？

すまん、日○のCosminexusってどうなん？
知っている人、教えてくれ。
Javaを使っているということを聞いたんだが
Cosminexus Portal Frameworkってのと何がどう違うんだ？
うちの会社では、.NETと比べているようなのだが...。

>245
Cosminexusって日立のAppricationServerじゃないの？
で、Cosminexus Portal FrameworkはCosminexus上で
動作するFrameworkのことでしょ？
WebｓphereとWebｓphere e-commerceうんたら･･･のような関係では？
詳しくないんで、違うかったらごめん。

> 246
Cosminexus、っていったら全部を指すんだとおもうよ。
Interstage、っていったらEAIも含んじゃうのと一緒だし。
各製品の枕言葉でしかないから特定できないす。
SysetmWalker、っていうよりも節操あるかもね。

ACBAサイコー

（＾＾）

そろそろStrutsを標準ｴｿｼﾞｿにしよう！

>>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最高
開発が楽すぎる

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

長寿スレだなｗ