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

あぼーん

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

特に運用まわりや障害対応のための情報収集機能、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最高
開発が楽すぎる

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

長寿スレだなｗ