04/08/18 23:01
>>110
MLに投げればいいじゃん（ｗ
113:デフォルトの名無しさん
04/08/19 18:30
>>112
無責任に書きたいのでな。
114:デフォルトの名無しさん
04/08/20 11:12
最近責任のある立場ではっきりものをいえないへたれ日本人が増えてるよな。
２ｃｈが流行るわけだよ。
115:デフォルトの名無しさん
04/08/20 12:28
>>114
恥ずかしくない？
116:デフォルトの名無しさん
04/08/20 15:36
と無責任に意見をのべる114
117:デフォルトの名無しさん
04/08/20 21:11
で、藻前らぼちぼち技術的な話題はできないのか？
118:デフォルトの名無しさん
04/08/21 11:07
>>110
なんだ、かまって君だったのか
119:デフォルトの名無しさん
04/08/21 12:31
S2のコンテナ部分の特徴の一つにOGNLを使っていて、
SpringのPropertyEditorに相当する部分が不要な点が
あげられると思うんだけど、そのへんどうよ。
<arg>new java.math.BigDecimal(1)</arg>
みたいな。
120:デフォルトの名無しさん
04/08/21 14:32
>>119
> <arg>new java.math.BigDecimal(1)</arg>
どの位使う機会があるかわからないけど、便利なのは確か。
こっちの方が自然でわかりやすい。
121:デフォルトの名無しさん
04/08/21 17:47
>>119
Springのref,valueタグの役割をOGNLがやってるんだね。
122:デフォルトの名無しさん
04/09/02 01:06
EJBが難しくてよくわかんなかった俺でもS2はなんとか使い方がわかった。
くーすってやり方で設計してみたが、なんとか筋の通った設計書（らしきもの）ができた。
さて、あとはこのまま S2 で実装に落とせるかどうか。
自分が書いたシーケンス図を見ると、インターフェースやクラスにのっける機能が
明示されてるようにみえるけど、信じていいのかこれ。
123:デフォルトの名無しさん
04/09/02 08:21
>>122
やってから、また書き込め。
124:デフォルトの名無しさん
04/09/02 12:52
書いた本人が信じないで誰が信じるんだよw
でも考えてみりゃソフトウェアって書いた人間が一番信じてないことがよくあるな。
125:デフォルトの名無しさん
04/09/04 11:01
>>122
よく読むと不思議な文章だな（ｗ
よくわからないけど設計が出来てしまうのか
設計って考えながらやるもんだと思うんだが
126:122
04/09/06 22:41
実装始めたけど初手から躓いた。ドキュメントとサンプルを睨みつつ七転八倒。
結局ＤＩを理解してなかったことに２日かかって気づく。頭わるすぎ orz
なんというか、歴史あるクラス先輩に対して「そんな依存性は修正してやる」と殴りかかってる感じ。
で、さぁやってやるぞとS2Dao組み込んだら、Tomcat 起動中に s2containor の Servlet#init() で例外。
原因分からず。先が長そうでちょっと泣けた。
127:デフォルトの名無しさん
04/09/07 01:33
ガノタかよ（ｗ
128:デフォルトの名無しさん
04/09/07 06:29
>>126
例外が出たなら、トレースを見れば分かりそうな門だが。
diconファイルがどっかまちがってるんでしょ。
kijimunaを使いなさい。
URLﾘﾝｸ(sourceforge.jp)
129:122
04/09/08 20:12
Servlet#init() での例外、原因判明。
S2DaoのBEANアノテーションが内部クラス扱いになって別の.classファイルが作られてた。
で、それを JBuilder が war に入れないでやんの。関連チェック、デフォだと外れてるのか orz
そんなこんなで、やっと JBuilderX で S2 + S2Struts + S2Dao が動いた。
これ幸せかも。なんだかソースがとってもキレイ。
もう少し作りこんでからまた。
130:デフォルトの名無しさん
04/09/10 00:02
S2Tapestryの情報って無いですね。
ドキュメントもしっかりしてないので苦労してます。
131:デフォルトの名無しさん
04/09/10 08:14
ソース嫁っていうポリシーだから。
132:デフォルトの名無しさん
04/09/10 08:39
>>131
マンドクセー
そんな時間掛ける気ねーよ。
はやくS2JSFでねーかなー。
そっちならソース読んででも習得したいな。
133:デフォルトの名無しさん
04/09/10 11:19
どういうことで苦労しているのかを書けばいいんじゃないの？
134:デフォルトの名無しさん
04/09/10 11:20
使い方を調べるのに苦労します・・・とか？
135:デフォルトの名無しさん
04/09/10 14:24:29
>>133
つーかさあ、JavaDocで作成したドキュメントぐらいはねーのかよ！
136:デフォルトの名無しさん
04/09/10 15:00:17
>>135
コメントもありません。
137:デフォルトの名無しさん
04/09/10 18:15:38
S2タペのサンプルなんて足し算するだけじゃねーか！
もっと実用的なサンプルねーのか？
TapestryとS2Tapestryのアプリケーション作成時の違いってこれだけ？
あとはTapestryのドキュメント読んで作ればいいのかな？
・S2ContainerServletの設定 (web.xml)
・エンジンをS2用に変更 (*.application)
・ページ仕様にサービスの定義追加 (*.page)
・ページクラスにコンポーネントのプロパティを追加して
サービスメソッドを呼び出す (*,java)
138:デフォルトの名無しさん
04/09/10 19:02:44
依存性注入、っていうのがやっぱり今ひとつピンとこないんだが、
要は「論理設計（インターフェース設計）先行で開発せよ」ってこと？
くーすでやってると、まずインターフェースを書かないとなにも出来ないんで、
「とりあえず動くものを書け。話はそれからだ」っていうのを禁止してる感じがする。
139:デフォルトの名無しさん
04/09/10 21:23:33
>>135
getContainerするくらいだけなんだから
使うだけならJavaDocなくても困らん気がする
漏れはJavaDocが欲しいと思ったことはないな
サンプルは欲しい気がするけど
>>137
S2TapeはTapestryからS2を呼びやすくしてるだけだから
実用的なサンプルはTapestryのスレで聞いたほうがいいと思う
Tapestryについて語ろうよ！
ｽﾚﾘﾝｸ(tech板)l50
>>138
くーすは仕様先行で設計しようってだけだろ
別にDIでなくてもこういう考え方はありだと思う
140:デフォルトの名無しさん
04/09/10 22:21:02
さんぷるがほしいな。
S2Tapestry ＋ S2Dao
で、フレーム、セッションオブジェクトをバリバリ使ってるやつがいいな。
141:デフォルトの名無しさん
04/09/10 22:36:58
>>139
>別にDIでなくてもこういう考え方はありだと思う
それはそうなんだけど。「依存性を注入する」って、注入先を先に用意しないと成り立たない。
その注入先がインターフェース。この場合のインターフェースの役割って、業務システムのフレームワークでしょ？
それってつまり、DI で業務システムを組むってことは、詳細設計なき実装を不可能にする手法なのかな、と思ったわけ。
・・・作った後から仕様書書いたら切腹？
142:デフォルトの名無しさん
04/09/10 23:11:36
>>141
詳細設計なき実装が不可能？
おかしくないか？ 手続きのみの言語じゃあるまいし、設計書が無くても
コード書く前に普通、クラス構造は頭に思い浮かべるだしょ。
143:デフォルトの名無しさん
04/09/10 23:44:47
>>141
すまん漏れには何を言ってるのかよくわからん
DI関係なく藻前がどんな風に普段作ってるのか
教えてくださらんか？
144:デフォルトの名無しさん
04/09/10 23:46:05
>>140
フレームやセッションオブジェクトをバリバリ使うとS2は関係ないと思われ
145:140
04/09/11 00:30:55
>>144
TapestryでのFRAMESETの扱いや（S2とは関係ないけど）、
認証関係でセッションオブジェクト使って、
AOPで認証チェックやってるS2Tapestryのサンプルが見たいです。
ところでS2TapestryにすることでS2Daoの扱いが変わる（使いやすくなる）の？
146:141
04/09/11 02:46:18
>>143
Webは Struts で簡単な情報参照系しかやったことないので、
Windowsで作った受注出荷管理のときを例に。
１）システム機能仕様書、ERD、画面仕様書（レイアウトと処理内容、IO先）を同時並行に書く。
２）DB設計。
３）コーディング。複雑なロジックはコメントでクドクドと説明。
DBはデータ保障をトリガにおまかせ、SQLで気ままにアクセス。
基本的に１画面1クラスで機能を詰め込む。同系画面で継承は使うけど。
こんな感じ。
147:デフォルトの名無しさん
04/09/11 11:12:21
>>146
では次は 「DI は詳細設計なき実装が不可能」 と思った理由の説明を頼む。
ところで 1 画面 1 クラスってのは、どういう構造よ。
Action にビジネスロジック書いてるの？
それとも色々な Action クラスからある 1 画面の機能を詰め込んだサービスを
呼出してんの？
前者は推奨されてないし（10画面くらいのシステムなら別にいいとおも）、
後者はモデルの切り分けがおかしい。
で、同系画面では継承してる？
構造が分からないけど、サービスで切り出すのが綺麗だとおも。
継承では再利用性、メンテナンス性も低い。
148:デフォルトの名無しさん
04/09/11 11:39:06
簡単な情報参照系なら、Struts使う必要もないな。
149:デフォルトの名無しさん
04/09/11 13:02:27
作者、これまた大きくでたな。
URLﾘﾝｸ(d.hatena.ne.jp)
------------------------------------------------------
まずは、Nirvanaと組んだS2JSF。JSFは、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、ツールベンダーの思わくが先行し、現場を見てない
結果だと思われます。
しかし、それも変わってきます。HTMLをテンプレートにし、DIコンテナと組みあわせる。
これなら、現場での使用にも十分に耐えられるでしょう。
くさったJSPなんかさよならです。重厚なEJBなんてさよならです。長いこと開発者を苦しめて
きた2つの技術。JSPとEJBに終止符を打ちます。
次は、S2Flex。時期的にはこっちの方が早く出ます。リッチクライアントも、試行錯誤の時期を
終え、いよいよ普及期に入ります。
2004年。これほど開発手法が激変する年は恐らくもうないのではないでしょうか。
150:デフォルトの名無しさん
04/09/11 13:32:35
開発手法の激変といっても、Javaローカルな話だね。
処理系依存。
151:デフォルトの名無しさん
04/09/11 14:13:21
まずは、DI を組み込んだ SeasarV2。 S2は、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、作者の思わくが先行し、初心者に易しいを
ポリシーにしていたものの、実は初心者が理解できる代物ではなかったと思われます。
152:デフォルトの名無しさん
04/09/11 14:20:03
>>146
ロバストネス分析やシーケンス図を基にして「インターフェースを作る」ことを”詳細設計”と了解してる。
「設計」って考える作業でしょう。で、インターフェースって考えないと作れないから設計かな、と。
クラスそのままの引き写し構造でつくればいいってもんじゃないんでしょ。
インターフェースさえ作ってしまえば、あとは力仕事的にゴリゴリ書けそうだなと。
実装のうまい・へたはともかく「インターフェースの設計」のおかげで動きは保障されるだろうと。
お前はクラスを考えて作ったことが無いのかと問われると、たぶん頭の中でしかない。
せいぜい、主要部分のヘッダファイルを書くくらい。チームの時は実装担当者にお任せしてた。
んー。うまくまとまんないけど、DIの「構造と実装を分離する」ってのが、
・単なる実装レベルの一手段で、便利ツール的なものなのか、
・それとも設計手法に関わってくるほどのものなのか、
ってのが分かってないのかも。
>ところで 1 画面 1 クラスってのは、どういう構造よ。
勘違いされてるような。前述の例はWin32アプリ。具体的にはC++Builder。
細かい業務ロジックはフォームクラスに配置したUI部品のイベントハンドラに直書き。
重要な処理は private なメソッドに閉じ込めて、イベントハンドラから呼び出し。
たしか５０画面以上あるけど、その画面でやってることが基本的に１ファイルにまとまってて、
ほかの画面からも独立してるから頻発する改造に対応するには手っ取り早い。
Web だと通用しないかもしれないし、相当荒っぽいやり方だとは思うけど。
153:デフォルトの名無しさん
04/09/11 14:36:51
S2ﾀﾍﾟの作者もここ見てるね。
はてなに書いてたよ。
要望があれば書いてみれば。
メールしたほうがいいとは思うけど。
154:デフォルトの名無しさん
04/09/12 01:04:48
で、結局Springとどう違うの？
155:デフォルトの名無しさん
04/09/12 13:17:12
舶来か国産か
156:デフォルトの名無しさん
04/09/12 13:19:04
>>150
そうか？ .netだってSpring.netみたいなDI出てくるし
変わってくると思うけど
157:デフォルトの名無しさん
04/09/12 13:27:48
>>149に挙げられてるものはすべてJavaローカルなものだし。
.NETの人たちがMS以外のフレームワークを積極的に使うとは思えんし。
さらに言えば、コーディングレベルの話なので、本質的な変化ではないからなぁ。
仕事のやり方がかわるよりは、仕事に携わる人の種類・層が変わることの方が劇的な変化だから。
158:デフォルトの名無しさん
04/09/12 14:29:03
>>153
作者じゃないってさ。
ま、メンテナでもいいんだけどね。
確かにどうすれば普及するのかねえ。
なんかS2JSFが出てくると更に普及の可能性が低くなりそうな気がするね。
S2タペというよりはタペの話になってくるのかな。
しかしそのメンテナ曰く
＞＞そもそもドキュメントを読まなきゃ使えんと言うのが問題。
じゃ、どうやって使うんだろう？
今までマニュアルやリファレンス読んで作りながら習得してきたんだけど、
そのやり方には問題ありって事なのか？
もっと手っ取り早く習得できるやり方があるのなら大歓迎だけど．．．
159:デフォルトの名無しさん
04/09/12 14:35:28
補完してったらなんとなくわかる、ツールで適当にやってればできる、というのがいいということかな。
ドキュメントを精読しないと使えんというのは問題だろうが、だからといってドキュメントがないのも問題だな。
160:デフォルトの名無しさん
04/09/12 15:53:13
補完していくだけでセッション管理やトランザクション管理なんかが分かるフレームワークができればそりゃ普及するだろう。
というか、ウィザードで処理の雛形作ってくれるだけでも全然違うだろうね。。
つーか、そもそも補完する取っ掛かりが分からないからドキュメント見てるんだけど。
161:デフォルトの名無しさん
04/09/12 17:04:17
同様に、コメントなしでわかるプログラムが理想だが、だからといってコメントを書かなくてもいいわけではないな。
162:デフォルトの名無しさん
04/09/12 17:46:42
>>161
オブジェクト指向で書かれたプログラムでコメントなしってつらくねー？
JavaDocでもなんでもいいからオブジェクトの説明ぐらい要るだろ？
163:デフォルトの名無しさん
04/09/12 18:57:54
>>162
だが、クラス名だけで出来る限り分かるようにすべきだ。
たまにコメントがなければ、さっぱり意味の分からないクラスを見かけるが。
164:デフォルトの名無しさん
04/09/12 20:13:18
JavaDocは仕様を書くところで、
実装の説明じゃないから、
そこんとこヨロピク
165:デフォルトの名無しさん
04/09/12 20:16:38
>>163
英語分からない奴が無理やり英語の名前でクラス名つけたりするとそうなるよな。
わかんねーなら日本語をローマ字記述でクラス名書け！つーの。
166:デフォルトの名無しさん
04/09/12 22:00:38
しかし、KensyuとかHuriwakeとかHojyoとか、許せないローマ字はやめてほしい。
167:デフォルトの名無しさん
04/09/12 22:12:34
>>166
訓令式は知ってるよな。
168:デフォルトの名無しさん
04/09/12 23:30:06
>>166
S2と関係無いと思うんだけど。
169:デフォルトの名無しさん
04/09/13 00:32:58
もうね、jyoだけはやめて欲しいよ。
170:デフォルトの名無しさん
04/09/13 00:43:55
>>167
英語と混じるとはげしく違和感のあるローマ字記述法ですね？
171:デフォルトの名無しさん
04/09/13 13:16:21
>>170
英語と混じれば違和感あるのはどっちも同じ。
172:デフォルトの名無しさん
04/09/13 14:18:17
>>151
そんなあなたにEJB
173:デフォルトの名無しさん
04/09/13 14:54:00
英語に出来ない業務用語って多くね？
174:151
04/09/13 14:57:39
>>172
EJB は問題外です。今更 EJB 3.0 では DI や AOP と取り込んで
すばらしいものになりますってか。しかも 2.0 まで利用者の怒りが怖くて
互換性を残すと。金儲けする人も大変ですね。
175:デフォルトの名無しさん
04/09/13 14:58:40
EigoNiDekinaiGyomuYogo?
176:デフォルトの名無しさん
04/09/13 20:26:38
>>174
そんなあなたにドットネット
177:デフォルトの名無しさん
04/09/13 22:26:30
S2TapestryってAOPで認証チェックとかできるのですか？
そんなサンプルあれば欲しいです。
InterceptorでVisitオブジェクトをgetするために、
MethodInteceptorインターフェースを実装させてBasePageクラスを継承させるの？
なんか変ですよねえ。。。
どうすればいいのか教えてください。
いちいち、Pageクラスで認証チェックするのは手間です。。。
AOPじゃなくてもFilterとかでうまくできるのでしょうか？
178:デフォルトの名無しさん
04/09/14 01:28:11
>>173
「領収書」とかね。
179:デフォルトの名無しさん
04/09/15 00:24:00
>>178
receipt じゃだめなの?
180:デフォルトの名無しさん
04/09/15 00:28:21
>>179
じゃあ、「レシート」は？
181:デフォルトの名無しさん
04/09/15 00:36:08
日本語→英語→カタカナ
にしたときに違う意味になってしまうものは困る。
え、スレ違い？
話題ないんだからいいじゃん。
182:デフォルトの名無しさん
04/09/15 07:02:51
>>181
だったら>>177に答えてやれよ。
>>177
どうやらS2TapestryのPageクラスではAOPは使えないらしいぞ。
Tapestryは使ったこと無いけど、昨日のひが氏の日記に書いてる。
183:デフォルトの名無しさん
04/09/15 07:21:38
Tapestryは内部的にオブジェクトを生成するので、S2でインスタンス生成を握れない。
だからouterでDIを使うことはできるけど、S2AOPは使えない。
認証部分をS2から取ってくるコンポーネントに任せればいけるかも。
やったことないからわからんけど。
それでできるなら、もちろん認証部分のコンポーネントはDI可能。
184:デフォルトの名無しさん
04/09/26 23:22:30
そろそろS2JSFでる頃かな？
期待age
185:デフォルトの名無しさん
04/09/27 11:41:06
S2JSFは期待したいね。Kijimunaも良くなってきたから楽しみだ。
186:デフォルトの名無しさん
04/09/28 09:55:02
そもそものJSFのオープンな実装って出ないのかなぁ。
187:デフォルトの名無しさん
04/09/28 09:58:59
ともあれ、こういったコンポーネントはSpringの方が充実していくだろうから、オレとしてはSpringでDICONが使えるようにして欲しい。
今みたいな、同じ役割のメジャー&めんどくさいフレームワークとマイナー&お手軽フレームワークが並列する状況どうにかならんもんか。
188:デフォルトの名無しさん
04/09/28 22:03:26
軽いフレームワーク -> メジャーになる -> 要望に応えて重量級になる
189:デフォルトの名無しさん
04/09/29 03:56:43
>>188
核の部分は変わらないし、OGNL使ってるから高機能だし、Springに比べてお手軽なのは変わらんと思うよ。
SpringでDICONが使えるようになってほしい。
もしくはSeasarでSpringXXXが使えるようになってほしい。
190:デフォルトの名無しさん
04/09/29 06:52:35
>>189
そのDICONってなに?
Spring固有の機能使ってなければ、SeasarでSpringXXXはうごくんじゃないの。
191:デフォルトの名無しさん
04/09/29 09:23:06
>>190
Spring固有の機能使うからSpringXXXなんだと思う。
192:デフォルトの名無しさん
04/09/29 20:24:15
なんかFlexに力入れてるからS2JSF遅れそうだね
193:デフォルトの名無しさん
04/09/30 00:04:59
その分S2Tapeが強化されそうだし気長に待ってもいいんじゃない？
194:デフォルトの名無しさん
04/09/30 01:02:37
Tapeなんて使いもはん。
195:デフォルトの名無しさん
04/09/30 07:05:56
>>189
その使いたいSpringXXXってどんなやつ?
196:デフォルトの名無しさん
04/09/30 15:49:43
>>195
SpringHibernateとかSpringDAOとかJSF Springとか、Seasarでも並行開発されているヤツ。
今後もSpringの方が先行しつつ並行開発されていくヤツ。
197:デフォルトの名無しさん
04/09/30 17:41:30
>>196
素直にSpring使うほうがいいんじゃないか？
198:デフォルトの名無しさん
04/09/30 19:58:14
>>197
そしたら、Seasarの存在意義が。
199:デフォルトの名無しさん
04/09/30 20:59:38
SpringXXXを使いたいならSpringを使うほうがいいだろ。
漏れはS2DaoのためにSeasarを使ってるし。
200:デフォルトの名無しさん
04/09/30 21:37:22
S2JSFがそのうち出てくるのに今更S2Tapeやる気は起きない。
YSFとかでも勉強しとくかな。
201:デフォルトの名無しさん
04/09/30 22:02:08
お前らの会話は訳が分からん。
今後は文章に含まれる英字の量は全体に対して1%までと
規定するから、厳守するように。
202:デフォルトの名無しさん
04/09/30 22:35:29
SeasarのSpringより優れている点ってどこ？
203:デフォルトの名無しさん
04/09/30 22:43:17
NirvanaとかMyFacesがあるでしょ ＞186
204:デフォルトの名無しさん
04/09/30 22:54:13
＞202
国産・マニュアルが日本語、イベントも国内
今のところ、S2本体のソースがシンプルで追えなくもない
S2DAOが凄い、一方でS2HibernateもありO-Rマッパーの選択肢がある
Flash、Flexといったフロントエンドへの対応が進み出している
blog、MLでダイレクトにひが氏やコミッタにリクエストや質問を投げれる、
且つ、即座に採用されたり、回答がある
今のところ、Springと比較すると学習がお手軽、Spring MVCなんかを
DIって何？ってな新人さんに説明するのは難しいかも
お客さんのオプソ懸念に対して保険として国内での有償サポが準備？
まだ提唱されて間もないが、くーすといった開発方法論が芽生え始めている。
205:デフォルトの名無しさん
04/09/30 23:34:25
>204
S2Daoは確かに凄い。SQLを使える人なら間違いなく感激すると思う。
DB周りのコードがほとんど消えてなくなるんで、なんだか騙されてるような気がしてくる。
くーすは考え方はすっきりしてて分かりやすいけど、いざ実装しようとすると困る。
Strutsでいうと、Actionクラス＝くーすのコントロールで実装してみて一応それっぽくなったけど、
「ロジック層が業務フローを制御する」って言われると、コントロールがStruts依存になってるから駄目っぽいし。
でもコントロールをわざわざActionクラスと別に書くなんて面倒くさいし。書けといわれれば書くけどさ。
広く使われるには、誰かがくーす用のFramework的なものを書かんと難しいんじゃなかろうか。
206:デフォルトの名無しさん
04/09/30 23:39:47
NirvanaってJSFタグ吐き出すだけだと思ってた。
実装もあるんだ。
207:デフォルトの名無しさん
04/09/30 23:49:09
>>204
SpringMVCはWebでは使う必要なさそうだね。
S2DAOとSpringDAOの違いってどうなの？
定数アノテーションっていうのはCayenneと同じでおもしろいと思うけど。
OGNLと定数アノテーションがSpringとの大きな違いなのかな？
WEB+DB PRESSに解説記事が載ってたけど、ムダに大きいデータ構造で、ムダに本質的ではなさそうな部分が長いサンプルに読む気が萎えた。
208:デフォルトの名無しさん
04/10/01 00:04:13
それにしても、オープンソースプロジェクトってある程度広まって使えるようになったころに、プロジェクト自体があぼーんするからなぁ。
あまり大きなフレームワークは使いたくないというのが本音だ。
Seasarも、某社が会社の事業としてサポートするような、法人としての取り組みができるようにしたほうがいいと思うな。
そのためにはSeasarで利益が出せるようなしくみが必要になるんだけど。
でも、そうしないと、オープンソースプロジェクトって長続きしないよね。
209:デフォルトの名無しさん
04/10/01 12:18:22
>>208
一応、電通国際情報サービスがサポートするらしいね。
ところで、S2Daoでディスクキャッシュ機能があるとか昔日記に書いてあったが、
どうやればできるの？
210:デフォルトの名無しさん
04/10/01 12:28:16
>>209
SpringやらSeasarは今後3年くらいかけて浸透するだろうから、機能をあわてて実装するよりも、プロジェクトが5年10年続くようにがんばってほしいな。
211:デフォルトの名無しさん
04/10/01 21:22:31
>>210
浸透ってのがどの程度を言ってんのか分からないけど、俺はなんか違うとおも。
例えば Web アプリと言えば、Tomcat や Struts は浸透してるとおもう。
これが 3 年後に Tomcat と Struts、んで DI コンテナは何？ ってなことにはならない希ガス。
汎用 DI コンテナはフレームワーク作成者や新しいもん好きが使うものであって
システム構築者には汎用的すぎる。特化してるっぽい S2xxx や Springxxx とか
あるけど、まだ DI 使うとこんなすごいことができるみたいなオモチャに見える。
DI コンテナが浸透するんではなくて、フレームワークやライブラリが DI を
使用するのは当たり前になり （DI は自前でも良いし、cglib、javassist、BCEL、asm
なんでもいい） DI を冠することも無くなり、開発者に意識させないと思う。
212:デフォルトの名無しさん
04/10/01 21:37:16
>>211
もちろん、DI+AOPは基盤技術になるわけだから、本来表に出るもんではないと思うよ。
オブジェクト指向のためにJavaを使うんじゃなくて、Javaって便利だけどこれってオブジェクト指向に基づいてるらしいよ、みたいな。
なんかめっちゃ楽なんやけど、これってDIとかAOPっていうもののおかげらしいで、と。
ていうか、使用するのは当たり前ってことは浸透してるということなんじゃないかと。
ただ、そのためには実装とそれに基づいた実用部品が必要で。
その実装として、今はSpringとSeasarがあるわけだ。
あと、DI自体は使うのが非常に楽で、使えば結構自動的にアプリケーションの多層化やら部品化ができるから、やっぱりその利点を認められて広まると思う。
AOPは、末端開発者が積極的に使うものというよりは、コンポーネント提供者が利用して、末端開発者は何も考えなくてよくなる、という仕組みだと思ってる。
AOPこそ、開発者に意識させないものだと思うな。
使う言葉が違うだけで同じことを言ってる気がしなくもないが。
213:212
04/10/01 21:56:03
そういえば、誰かDIconファイルを視覚化して編集するツール作ってるみたいだけど、あれってもうちょっと発展させたらなつかしのAPPGALLERYみたいになるね。
ありがちなビジネスロジックの呼び出し仕様を集めたインターフェイスを登録しておけば、そいつを視覚化したものを配置して、メソッドつなぎあわせればアプリケーションになる、と。
呼び出し先の引数と同じ型のプロパティ持ってたらそれを自動的に渡して、みたいな。
ダブルクリックしたらそこのソース編集とか。
よくない？
214:デフォルトの名無しさん
04/10/01 22:07:23
>206
スマソ、HTML2JSP、JSFのコンバータだった。
215:デフォルトの名無しさん
04/10/01 22:09:25
>209
キャッシュはまだ未実装な筈
216:デフォルトの名無しさん
04/10/02 11:52:35
>>213
懐かしいな。そうなるといいな。
217:デフォルトの名無しさん
04/10/02 14:11:49
>>205
Actionは、業務ロジッククラスの一つのメソッドを呼ぶだけに白ってことだから
そんなめんどくさいことないだろう。
これまでも、Actionにロジックをおくなって言われてたわけだから、
そんなにかわんないだろう。
218:デフォルトの名無しさん
04/10/02 20:13:54
ひが君の日記より
> 実装上は、バウンダリから呼び出されるメソッドは、インターフェースになり、
> コンポーネント内からしか呼び出されないメソッドは、実装クラスのpublicメソッドに
> なります。
> 内部からしか呼び出されないのに、実装クラスのpublicメソッドにするのは、
> テストをしやすくするためです。別にprivateメソッドでもリフレクションを使って
> 呼び出せますが、コンポーネントを使う方は、インターフェースしか見ないので、
> 特にpublicでも問題ないと思います。
内部メソッドを public にか。俺はこれをダサいと思わん神経を疑う。
219:デフォルトの名無しさん
04/10/02 20:27:05
ひが君の日記より
> くーすは、というより私は、各開発者のスキルをまったくあてにしていません。
> ドライに聞こえるかもしれませんが、現実のプロジェクトを乗り切るには、
> そう考えざるを得ないのです。そして、どんな人でも一定の品質のものを
> 作り上げるための仕組みを考えるのです。
要は
S2 使う側の香具師はバカかアホしか居ねーから簡単に使えるようにしますよ w
バックエンドの難しい仕組みはスキルのある俺様しか理解できないですよ w
と。
正論だが、それを公開日記でいうおまえはどうしようもないバカだ。
220:デフォルトの名無しさん
04/10/02 20:27:52
このご時世に「ダサい」という言葉を使う神経を疑う
221:デフォルトの名無しさん
04/10/02 20:31:48
>>218-219
なんか嫌なことでもあったか？
こんなところで愚痴ってもしょうがないぞｗ
奴の日記読んでるんだったら、
奴が２ちゃんなんか読まないし仮に読んだとしても気にも留めない奴だって分かってるだろ。
ここじゃなくて奴の日記にコメントしろよ。
面と向かって文句言えないから陰口叩くちゃねらーの典型だなｗ
222:221
04/10/02 20:33:06
ちなみに私はＤＩコンテナ信者です
223:デフォルトの名無しさん
04/10/02 20:37:59
>>221
別に嫌なことなんか無いが、奴は最近方向が少しずれてきた希ガス。
224:221
04/10/02 22:09:45
確かにS2もいろいろなところで取り上げられてるしね。
調子に乗るのもわらなくはないけど。。。
まあ周りの取り巻き連中が持ち上げまくってるのかもしれないね。
個人的には調子に乗ってもいいから、S2JSFをきっちり作り上げて欲しい。
それと、S2Dao。
この２つさえきっちり作ってサポートしてくれれば持ち上げまくってもいいよｗ
225:デフォルトの名無しさん
04/10/03 01:55:24
別に調子に乗ってるようには見えないけどな。正論なら公開の場で書いてても
いいんじゃないかと思うし間違ったことは書いてない。
そもそもフレームワークってそういうもんだろ。そんなに嫌いなら見なきゃいいのにｗ
226:デフォルトの名無しさん
04/10/03 02:09:35
嫌いなら見なきゃいい、みたいな生産的じゃない発言増えたなぁ。板的に。
227:デフォルトの名無しさん
04/10/03 02:35:42
嫌々見て２ちゃんで愚痴ってるのが生産的だとも思わないなぁ。漏れ的に。
228:デフォルトの名無しさん
04/10/03 02:44:07
既存のRUPなんかで提唱されている手法を実践しようと
して苦しんだことがないから馬鹿にされているように感じるんでしょ。
くーすが嫌なら一般的にいわれているようなユースケース駆動
なんかの設計でやってみればいいじゃない。俺はやってみて
これがだれでもできる方法だとは思えないからくーすの
思想には賛成できるけど。(具体的な手法に関しては置いといて)
229:デフォルトの名無しさん
04/10/03 03:15:38
>>224
サポーターはサポートするべきだから。
230:デフォルトの名無しさん
04/10/03 08:52:29
>219
>S2 使う側の香具師はバカかアホしか居ねーから簡単に使えるようにしますよ w
バカかアホしか居ねー「と考えないと現実的に回らない」
>バックエンドの難しい仕組みはスキルのある俺様しか理解できないですよ w
バックエンドの難しい仕組み「を全員が意識しなけりゃならない状況は現実的じゃない」
曲解はやめような。
それ以前に、沢山の人を使ったことがあるかってことだな。
沢山の人の能力を全部把握して適切な仕事を振るなんてできやしないんだから、
全員が並の能力でも大丈夫な方法を模索するのは正しいと思う。
231:デフォルトの名無しさん
04/10/03 08:54:39
そういう意味ではくーすはある程度の人数を想定した開発・設計プロセスなのかな。
たとえばうちみたいに一人二人で1-3ヶ月やるようなプロジェクトでくーすに従って。。。というのはどうなんだろ。
232:デフォルトの名無しさん
04/10/03 09:37:22
>>231
ひとりふたりだと、プロセスがなくてもまわるっちゃまわる。
それでもプロセスの採用は有用だと思うよ。
233:デフォルトの名無しさん
04/10/03 11:09:50
>>219
その日記は明らかにプロの現場を指してる。
あの子が欲しい、この子は要らない、相談しましょ、そうしましょ
ってできないし、勝手に配人されるし、何より初めて会った人が
何をどこまで知ってるかなんて分からない。
アレとソレとコレを知ってる人が居ないと回せませんとか言った
ら、それこそ自分自身が要らない子になってしまうｗ
234:デフォルトの名無しさん
04/10/03 11:54:24
日記の内容なんて本当は関係ないんだろうな。
粘着したいだけなんだろきっと。口実が欲しいんだよ。
そんなことよりもS2JSF激しくキボンヌ！出してくれたらひが氏ラブｗ
235:デフォルトの名無しさん
04/10/03 12:40:10
心配するな。
ひが君は、ちゃんとここ読んでるから。
236:デフォルトの名無しさん
04/10/03 12:54:14
なんだひが「君」に釜ってほしいだけか
237:デフォルトの名無しさん
04/10/03 14:50:48
ひがたんにカマ掘ってほしいＹＯ
238:デフォルトの名無しさん
04/10/03 15:30:17
>>237
喜んで掘りそうな予感。
239:デフォルトの名無しさん
04/10/03 15:39:31
何で？ >>237っていい男なの？
240:デフォルトの名無しさん
04/10/03 15:40:40
ひがたんが・・・
241:デフォルトの名無しさん
04/10/03 16:04:01
ウホッ・・・！！！
242:デフォルトの名無しさん
04/10/03 16:42:25
>>230
> 全員が並の能力でも大丈夫な方法を模索するのは正しいと思う。
俺が正論って言ったのをフォローしてるだけか。ってか、おまい、奴の言った
「各開発者のスキルをまったくあてにしていません。」
に自分が含まれていないって曲解してないか？
「易しいこと、優しいこと･･･」
一人のサポーターが挙げてくれた S2 の哲学的ともいえるテーマを、
ひが君琉に言うとこうなるのか。本質は同じだが、明らかにひが君はうんこ。
あのファウラーでさえ、自分はまだまだ未熟と言ってるのに（ry
243:デフォルトの名無しさん
04/10/03 17:21:02
そんなにひが君のうんこを食いたいのか藻前はｗ
藻前が粘着したおかげで易しさと優しさがサイトから
消えたんだから満足しろよ。ひが君に優しく易しくして
欲しいのか？
244:デフォルトの名無しさん
04/10/03 17:47:46
実際易しかったのかもしれんが、優しくはないからな。
使えばわかる、ソース見ればわかる、だもん。
245:デフォルトの名無しさん
04/10/03 17:56:40
>>242
半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ
246:デフォルトの名無しさん
04/10/03 18:16:39
>>245
あんたよく見てるな
ほんとだ。感動した！
247:デフォルトの名無しさん
04/10/03 18:47:34
＞244
使わないと「知った」だけで「出来た」にも「判る」にもならんと思う。
誰もに優しくは努力目標にしても、マニュアルもかなり改変されてるしな。
AOPとS2DAOなんかは更に判り易くなったんじゃなかろうか。
板が荒れるとフォモか巣加戸炉になるな。
248:デフォルトの名無しさん
04/10/03 19:44:46
板は荒れてない。荒れてるのはスレだ。
荒れているひとりがいるだけなんだがな。
249:デフォルトの名無しさん
04/10/03 23:43:18
>>244
使ってみる。ソースを見てみる。は、技術者として当然の行動文法。
教えてくれるのが当然君は芯でいいよ。
250:デフォルトの名無しさん
04/10/04 00:09:45
呼ばれてるぞ。
URLﾘﾝｸ(d.hatena.ne.jp)
251:デフォルトの名無しさん
04/10/04 00:12:40
まあソースを見ろとまでは言わんけどな。見ると勉強になるのは間違いないが。
ここで粘着してひが君を自分の思うとおりに動かしたい奴がいるってことだろ。
S2とか技術には興味が無いんだよ。興味があるのはひが君そのものなんじゃないの？
だから取り巻きも気に入らないしスキルがどうこう書いてると自分のことを責められてる
気がして可愛さ余って憎さ百倍になってんだな。ホモのストーカーって恐いな。
252:デフォルトの名無しさん
04/10/04 00:17:28
>>250
もし>>219が行くなら俺もギャラリーで参加したいｗ
253:デフォルトの名無しさん
04/10/04 00:34:08
そうか、見てるのか・・・・・・・
なんか急にこのスレも格調が上がった様な気がしないでもないｗ
254:デフォルトの名無しさん
04/10/04 01:31:10
ほらほら新しいバージョンが出ましたよ
S2JSFもちゃんと作るってさ
255:デフォルトの名無しさん
04/10/04 02:48:48
なんかなあ
漏れは219でもないし、219を擁護するつもりなんざ全くない（むしろ叩きたry）けど
ここじゃなくて自分のblogで批判つーか「来いや」はな・・・
はぶ氏にどんな事情があってここに書き込まないのかは知らんが、
どっちもやってることのレベルは大して変わらんな
256:デフォルトの名無しさん
04/10/04 03:00:44
自分の署名になる自分のブログで書くってのは
意味はあると思いますがどうでしょう。
255さんの意見がハブ氏の（あっカタカナで変換したら
これまた沖縄くさい感じに！）ブログに書かれていたら
結構面白いんじゃないかなあ。
でも2ちゃんで書き捨てる気楽さも確かにあるし
それだけにあけすけに本心も出る面もありますな。
257:デフォルトの名無しさん
04/10/04 03:44:31
S2JSF期待age
258:デフォルトの名無しさん
04/10/04 04:53:29
ひがひがとはぶはぶは、こんがらがることもあったりなかったりするけど、重さ的にだいぶ違う。
259:デフォルトの名無しさん
04/10/04 05:12:03
>>249
そういう考え方は、それはそれでいいと思うけど、それを「優しさ」というのかな、と。
260:デフォルトの名無しさん
04/10/04 06:07:45
>>255
いや、ちゃんとそこらへんに書き込んでると思うが。
261:デフォルトの名無しさん
04/10/04 06:13:08
なんにせよ、2chの書き込みに反応するのは意味があるにしても得策ではない。
262:デフォルトの名無しさん
04/10/04 06:33:34
>259
誰に優しいか、っていうと「ビジネスする技術者に」なんだろう。作者と同種の人が対象なんだよ。
効率的な実装手段を求めてもがいてるような。教えて君や駆け出しの新人は入ってないと思われ。
それに、ソースはうまくいかんときにデバッガで追うくらいで十分。
ソース読まなきゃ使えないほど難しくもないし、声高に叫ぶほどドキュメントがないわけでもない。
263:デフォルトの名無しさん
04/10/04 07:03:23
>>262
もう記述は外れてるからどうこういってもしかたないんだけど、「初心者にもやさしい」というニュアンスだったような気がするんだけど。
「ドキュメントが豊富です」と声高に叫ぶほどドキュメントが充実してたわけでもないし。
要は、宣伝文句と実情が異なってたからどうよ、と思ってたわけさ。
264:デフォルトの名無しさん
04/10/04 07:14:34
>>263
J2EEとコンテナ、アスペクトの初心者には充分やさしいと思う。
さすがにJava初心者にはやさしくない。ていうか、インターフェースでプログラミングすると
いうことをSQLできます、COBOLやってました。という人々に理解してもらうのは、すげー難しいぞ（W
265:デフォルトの名無しさん
04/10/04 07:30:21
まあ、問題は初心者っていったときに、なにか勉強しはじめた人のことではなくて「初心者という生き物」のことを指してしまうことがあるからなぁ。
宣伝文句と実情が異なってたときに、オレとしては実情の方をあわせて「これでどうよ？」となってほしかったのだけど、宣伝の方が取り下げられてしまったのは残念だ。
マンパワーの問題もあるだろうし、しかたないのだろうけど。
実情が伴ってきたときに、またあの宣伝文句を掲げてくれれば、と思う。
266:デフォルトの名無しさん
04/10/04 10:06:16
>>255
ここに実名で書き込むヤシはいないだろ。
267:デフォルトの名無しさん
04/10/04 10:10:42
>>265
マンパワーの問題というよりも、ここでの粘着振りに
ひが氏がうんざりしちゃったんじゃないのかな
コンテナのドキュメントが急に書き換わったり
意地になってた気がする。
268:羽生
04/10/04 11:07:35
羽生と申します。2chで本名で書くのもどうかと思いますけど、けじめはつけておきます。
まず、ここに書き込まない理由は、
１．私は長文になってしまうので「長文ウゼー」って言われるからです。
改行が多すぎて書き込み出来ません、ともなります。
２．誰がどの書き込みをしたのかわからないので、脊髄反射的な会話に
しかならないからです。ハンドル名であっても一貫していれば、書き込みの
流れから行間を読むことで解釈のずれを埋める工夫が出来ますが、
そういう機能がないため「書き手の気持ち」を類推することが出来ず、
結果として言葉尻だけを取り上げることが多いからです。
これは、「私には」しんどいことです。
３．追いかけるのが大変だからというのもあります。自分の発言にレスがあったら、
きちんと返さなければという強迫観念があります。blogの場合は、あくまでも「コメント」ですので、
それに対してレスをしなければという気持ちは大らかでいられるのですが、
掲示板などだと常にウォッチしなければということで、日常に入り込んでしまいます。
忙しいときにはそれが苦痛になるので、控えています。これはMLもそうです。
４．自分が発する言葉は自分の心からしか出ません。ですから匿名であっても
責任が生じます。しかしトリップをわざわざ取ったりなど、仕組みとして「自分の責任」を
表明するのが面倒です（取ったこと無いし取り方を調べるのも面倒^^;）。
ですからここで自分の名前によって書いても、騙りと思われたりする可能性を考えると
blogのほうが確実だと考えています。
以上です。その上で、もう少し書きたいと思います。
269:羽生
04/10/04 11:09:45
まず、「優しさ」ということを掲げることについては、誰も反対はしないと考えています。
要点は、これを「理念・目標」と捉えるか、「宣伝」と捉えるか、でしょう。
では、これについて、
「私は宣伝と受け止めた。ついては宣伝に反している。改めるべきだ」
と考えた場合に、意味のある形につながるように取れる行動として、
例えば次のようなことがあるのではないか、と思うのです。
「優しさ、と書いているが、自分には優しさが足りてないように感じる。
ついては、まず、こういうドキュメントを追加してみてはどうだろうか。」
そして、ほんの少しでも叩き台として出していただければ、それが呼び水となります。
ゼロから1への最初の一歩が大変なのです。マンパワーの問題もありますが、
そもそもご指摘があったように、知ってしまっている人間にとっては、ここが足りてないのか
という最初の気付きは難しいものです。
せっかくオープンソースであり、しかも英語圏に比べれば圧倒的に身近な国産のプロジェクトなのですから、
前向きな小さなはじめの一歩をいただければと思うのです。これをMLに投げてもらうだけでも随分と有効です。
MLも別にyahooメールで書いてもらっても構わないのです。同じ問題意識の発露であった場合に、
少なくとも、ここで汚い言葉でののしるよりもどれだけ有効で、どれだけ他の人の役に立つでしょう。
ですから、私はここで文句を言ってるだけというのは、実はこういう問題意識を持ってのことではなく、
それはポーズであって、実は別の感情が潜んでいるのではないか、という風に感じてしまいます。
このスレに書いたことでさえ、ひがさんはちゃんと受け止めて反映しています。
JavaDocプロジェクトも徐々にですが着実に進んでいるのも、例えばからさわぎで
「2chでも指摘されてますが、JavaDocいる人ってどれくらいいます？」というようなやり取りをして、
そこからちゃんと取り組みが始まっています。拒絶はしていません。
ですから、もっと誰もが受け入れやすい形でご提案いただければすごく嬉しいです。
270:羽生
04/10/04 11:11:34
引き続きですみません。
さて、私はこのスレの位置付けというのは初心者にとって大きいため、
ここで不当に貶されるのは、S2へのアンチマーケティングをされていると考えています。
というのは、Seasarで検索するとこのスレがヒットします。知識のないひと（スキルがない
のとは別です）が、ここを見てどう思うか、ということを考えると、必ずしも実情が伝わる
とは思えないのです。
というのは、「優しさ」という言葉尻とその周辺のことばかりが取り沙汰されていますが、
では技術的にどうか、などのことは全然触れられていません。端的に言えば、ひがさんや
取り巻き（この表現の意図もよくわかりませんが）の人格に対する話しかないのです。
ということは、人格に関する情報だけで技術水準を判断されてしまいかねません。
つまり「優しさ」の守り手たらんとしている誰か（誰か、としかいいようがありません）の
発言が結果として、「優しさを必要としている人」の無知識につけ込んでいるようにも感じます。
私たちがやっていることが、全て必要にして十分なレベルにあるなどとは到底いえませんが、
残念ながら客観的に評価されているようには思えません。
こういう部分は優れている、こういう部分はもっと改善が必要だ、というように、要素ごとに
きちんと評価して総合判断を提示するのが、技術者の基本ではないかと私は考えています。
その評価結果が厳しいものであってもそれは謙虚に受け止めてさらに取り組みます。
その意味において、残念ながら非常に一方的な負の感情のみで書かれているようにしか
見えないものが多いのです。ここでまた、S2そのものに対するのではなく別の感情が潜んで
いるのではないかと考えたりもします。
271:羽生
04/10/04 11:16:01
とりあえず最後です。
このようなことを踏まえた上で、他人を「うんこ」だの何だのという言葉を使うというのはどうなんですか？
実名で「これを書いたのは私です」と胸を張って公の場でいえますか？ いえるのであれば結構です。
是非、私と会いましょう。いえないのであれば、それは後ろめたいという気持ちを持っているのです。
後ろめたさを自分で作って抱え込んでどうするのですか。匿名であろうとなかろうと、言葉は自分の心からでるものなのです。
その負の感情をなだめようとして匿名でさらに汚い言葉を使っても、それは悪循環に陥るだけです。
その負の感情の源泉が、Seasarプロジェクトの不出来さに起因するのであれば、わざわざ自分の気持ちを
痛めつけるのではなく、お持ちのスキルとその問題意識を良い方向に発揮してください。歓迎いたします。
もし、Seasarプロジェクトに起因しているのでないなら、それは申し訳ありませんが八つ当たりに過ぎません。
自分の心で解決していくことです。ただそれも、例えばからさわぎのような場所で、普段会わないような
広い範囲の方々と話をするだけでも、何かが見えてくるかもしれません。
実際、からさわぎはJavaは殆どわからないという方も多く参加されています。
そして宴会の場で、技術ではないことでも意見交換が出来て非常に役に立ったという感想を
お持ちの方も多くいらっしゃいます。
「来いや」は確かに言葉が乱暴かもしれませんが、本心です。多くの方が前向きに（S2に対して、ではなくて、
自分の将来に対して）取り組んでいる場に触れるだけでも全然気持ちが変わります。
私も別に年中元気なわけではありません。しかし皆さんとお会いすると元気をいただけます。
私も少しでも皆さんの元気のお役に立てるようになりたいと思ってます。
是非、お会いしましょう。前向きなケンカは必ず第3の素敵なアイディアを生み出します。別にケンカしなくてもいいんですけどね(^^)
今後ともS2およびSeasarプロジェクトへの叱咤激励をよろしくお願いいたします＞all
尚、やっぱり恐いので基本的にここでは書きません。2chで実名出すのはやっぱりドキドキしますよ（ｗ
272:デフォルトの名無しさん
04/10/04 11:21:18
心配しなくても、実名の人に対して叩くほどの度胸はもちあわせておりませんよ。
トリップは適当に「羽生#seasar2004」みたいな#のあとに何かつけたらMD5かなんかの文字列になるだけなので、つけたほうがよさげです。
273:デフォルトの名無しさん
04/10/04 11:26:44
>>268-271
長文乙
274:デフォルトの名無しさん
04/10/04 11:37:14
長文ｳｾﾞｰ
275:デフォルトの名無しさん
04/10/04 11:40:58
>>268-271
ﾈﾀﾆﾏｼﾞﾚ(ry
276:デフォルトの名無しさん
04/10/04 11:49:43
ハブカブアガル。微妙に。ちょっとだけ。
277:デフォルトの名無しさん
04/10/04 13:18:10
つか、
>>242
>>に自分が含まれていないって曲解してないか？
含まれてるのを前提として>>230を読み直しても、全然問題ないんだけど。
どう読んだら>>230がそういう曲解に見えるんだ！？
おまい、ひがさんの直下のプロジェクトやったことあるんだろ。
うらやましいなぁ。漏れは馬鹿にされるぐらいの勢いでケアしてもらった方が、安心できるけどな。
11月のからさわぎには絶対参加しよう。
278:デフォルトの名無しさん
04/10/04 13:33:53
>>277
はぶたんには、長文乙と伝えてくれ。
ひがたんには、うほっと(ry
279:デフォルトの名無しさん
04/10/04 13:59:55
それよりオマエら、S2のSがSpringのSとまぎらわしいと思ったことはないか？
オレはある。
プレフィックスはまぎらわしくないものにするべきだ。
ここは「夜の」をつけることにして大人の雰囲気を醸し出すようにするのはどうだろう？
つまり「S2Struts」「S2Hibernate」「S2Dao」を「夜のStruts」「夜のHibernate」「夜のDao」とするのだ。
これでSpringより大人な感じが伝わるのではないかと思う。
280:デフォルトの名無しさん
04/10/04 15:13:19
それは素敵な案だが少し淫靡な香りが漂う気がする。
そこで大衆の支持を得るために「冬の」をプレフィックスに
するというのはどうだろうか。春（Spring）に対抗するのだ。
「冬のStruts」「冬のHibernate」「冬のDao」とするのだ。
これでSpringよりも婦女子の人気もバッチリだろう。
281:太田＠会社
04/10/04 15:22:57
私はどちらかというと方法論者(Methodologist, 社内でRUPとかの推進をしています)で，その立場からSeasarを応援(期待)しています。
理想的には純粋なOO分析，設計でRUPなのですけど，スキルやリソース，コストの観点からは最低レベルの技術者でも一定の枠組みに従って開発できる仕組みと方法論が必要というのが現実のところです。Seasarと「くーす」はその一つの回答となっていると考えました。
こちらでもはぶさんのおっしゃられているようにもう少し建設的な意見があると良いかなと思うのですがどうでしょうか。
282:デフォルトの名無しさん
04/10/04 15:40:36
>>280
冬ソナかよ！
283:デフォルトの名無しさん
04/10/04 16:20:52
>>281
そんなに否定的な意見ばっかりかなぁ？
否定的意見に対する反論もあるし、後は読んだ人が自分で判断することなのでは。
284:デフォルトの名無しさん
04/10/04 16:24:41
>>281
匿名の場合、ネガティブな部分が大きく出て、建設的な意見は出にくいと思う。
ナイスアイデアは名乗ってから言いたいからな。
逆に、否定的な意見をここで拾えばよろしい。
>>279-280のようなとても建設的な意見もあるが。
っていうか笑わせるな。ひさびさ腹いたくなった。
285:デフォルトの名無しさん
04/10/04 16:33:30
否定的なことを建設的に書けばいいんじゃないかな。
特定個人をとやかくいうんじゃなくて例えばJavaDocがない
とかならS2DaoのここだけでもJavaDoc書けやゴルァとかな。
何をやればもっと良くなるのかを指摘してやればいいんじゃないかな。
286:デフォルトの名無しさん
04/10/04 17:00:55
全体的な指摘だと、こうするべきっていうのは書きにくいからなぁ。
現状サイトが貧弱だし、最初の入り口になるナビゲーションが非常にとぼしい。
最初になにをすればいいかわからないしな。
何度も言ってるけど、使ってみないとなにができるかわからない。
DIやAOPがなんであるかを知っていないと、使おうと思わないだろうな。
こういうのは、「ここをこう」みたいなヒトコトじゃ指摘できないんだよね。
ま、とりあえずホームページの体裁を整えて欲しい。
作者のブログとはいえプロダクトとはあまり関係ない話題を引用してきてどうこういうのはどうかと思うが。
287:デフォルトの名無しさん
04/10/04 17:35:04
トップページは何の更新もないし、タイムスタンプで新しくなったのがわかっても、ダウンロードするまで何がかわったかわからないし。
で、よくみたらブログにはちゃんと書いてあったりする。
288:デフォルトの名無しさん
04/10/04 19:26:46
>>287
それははなからブログをチェックするのが正解かと。
289:デフォルトの名無しさん
04/10/04 19:34:44
>>281
２ちゃんのスレは「小さなはじめの一歩」次第でどうとでも変わります。
一旦方向性をみつけると、良くも悪くもそちらへ爆走します。
どちらに向いて爆走するかは「小さなはじめの一歩」次第です。
太田氏が「方法論者(Methodologist, 社内でRUPとかの推進をしています)」であるなら
その現場で培われた成功例(例えば、知識のない人にどう啓蒙していったのか、どうや
って教育したのか、何を見せどう説明したのか等など)を書き込んでもらえると、このス
レにとって「前向きな小さなはじめの一歩」に成り得ると思うんですが・・・・・・・・
勿論、ただの要望で「もしよろしければ」という話です。
290:デフォルトの名無しさん
04/10/04 19:56:47
>>288
そういう情報は、「公式サイト」には書いてないからねぇ。
別に広めるつもりがないならかまわないけど。
雑誌なんかでSeasar知った人が、ブログをチェックしないといけないとは考えないだろ。
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
291:デフォルトの名無しさん
04/10/04 21:59:47
国産じゃデファクトスタンダードには間違っても為らないワケで。
国産唯一の利点は「ドキュメントに読みやすい日本語が期待できる」だが、
それも無いし。
結論：ｲﾗﾈ
292:デフォルトの名無しさん
04/10/04 22:23:32
デファクトスタンダードは難しいだろうけど、ニッチでもいいじゃん。
世の中みんながトヨタやフォードに乗ってるわけでもなければ、
OracleやDB2を使ってるわけでもないんだから。
つーか、デファクトはEJB3.0なんじゃないの？
実際の小さい仕事で使ってみて今、基本部分が出来上がったとこ。
業務ルールとそれのつなげ方を分けて管理できるライブラリ、って感じで使ってみたけど
なかなかイイよ。俺は手抜きしてついつい業務ロジックを大きく作っちゃうんだけど、
単純なクラスをDICONで連結する構造が、結構自然に簡単にできた。
慣れるまで１週間くらいはかかったけど。さすがに１時間じゃ無理ぽ。
あと、バックエンドが簡単になったらフロントの Struts の辛さ倍増。
はやくS2JSF使わせてけろ。
293:デフォルトの名無しさん
04/10/04 22:37:47
>>292
使ってみれば、いいことはわかるんだよ。
そのための情報が少ないのが問題だね。
ブログ騒ぎで「ここだけの話」を見てみたら、リリース情報が逐一載っていた。
唖然とした。
公式サイトのチェックはしてて、新しいもののリリースは最近ないものだと思っていた。
294:デフォルトの名無しさん
04/10/05 00:05:04
公式サイトのwhat's newが欲しいってのはわかるなー。
295:デフォルトの名無しさん
04/10/05 00:35:33
MLでは逐一リリース告知されているわけだが
296:デフォルトの名無しさん
04/10/05 01:04:23
sourceforgeにも、リリースメモがあると思うが。
297:デフォルトの名無しさん
04/10/05 01:09:10
要するに興味ないくせに文句だけは言いたいわけだ
298:デフォルトの名無しさん
04/10/05 02:21:15
>>293-294
URLﾘﾝｸ(sourceforge.jp)
299:デフォルトの名無しさん
04/10/05 03:09:38
探さないのが問題だとも言えるし、探さないと見つけられないようなのが問題だとも言えるかも。
300:デフォルトの名無しさん
04/10/05 07:09:43
>>295-298
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
301:デフォルトの名無しさん
04/10/05 07:16:45
とりあえず、公式サイトは吉田カバンなみ。
302:デフォルトの名無しさん
04/10/05 09:17:27
ていうか、Seasarに文句言ってるヤシは、Springを使ってるの？
303:太田＠会社
04/10/05 10:31:46
289さん>
とりあえず社内外で
URLﾘﾝｸ(patterns-wg.fuka.info.waseda.ac.jp)
なことや，社内でのRUP研修で紹介して興味を持ってもらっている段階です。
私は開発ではなくテストが専門なので，その分野から攻めていって「テストが効率が上がる」というと興味を持ってくれるSEが多いです。
304:太田＠会社
04/10/05 10:36:55
あとはオブジェクト指向分析・設計の研修ですと，
やはりみなさまオブジェクト協調関係の生成をどのオブジェクトがどういったタイミングですべきかについて悩むが多いです。
そこで，Robert C. Martinのオブジェクト指向の基本原則などとからめて，DIコンテナを説明し，
もっともとっつきやすい(私の主観ですが)，Seasarを紹介するという形です。
305:デフォルトの名無しさん
04/10/05 11:22:56
モノ自体の仕組みとしてはとっつきやすいと思う。
SeasarのBean定義はSpringより少ない記述量でできる。
だから、わかってる人が近くにいれば、とっつきやすいと思う。
問題はわかっている人が近くにいないとき、Springの方が情報が得やすいということ。
306:デフォルトの名無しさん
04/10/05 12:57:39
>>305
>Springの方が情報が得やすいということ。
そうか？
Springは機能やら専門用語が多すぎて、わけわからん。
307:デフォルトの名無しさん
04/10/05 14:08:15
>>306
書籍に記述もあるし、網羅したリファレンスもあるし、そのモノが難しいというのは置いておいて、情報は得やすいと思う。
AOPのための記述とか、Seasarに比べるとアホみたいにめんどい。
もっと簡単な記述があるのかもしれないけど。
308:デフォルトの名無しさん
04/10/05 14:58:08
S2のJavadoc、@authorの下の行にコメント書いてある。
作者はJavadoc使ったことねぇのかな？少し笑えたぞ。
309:デフォルトの名無しさん
04/10/05 18:10:02
「2chに悪意を持って書き込む奴がいる」って何をいまさらｗ
310:デフォルトの名無しさん
04/10/05 18:59:41
善意がないだけで、悪意もないと思うんだけどね。
無責任なだけで。
「Seasar2はインストールするだけでシステムが不安定」とか事実ではないこと書けば、それは悪意があるんだろうけど。
311:デフォルトの名無しさん
04/10/05 19:00:08
>>309
ところで、どこに書いてあるの？
それ。
312:デフォルトの名無しさん
04/10/05 19:34:49
なんか、サイトの構築始まってるね。
左側のメニューにWhat's newが欲しい、とか、ロードマップが欲しいぞな、とかは思うが。
まあとにかく要望は出せばキリがないからほっといて、早いトコサイトインできるようにがんばって欲しいね。
せっかくWEB+DB PRESSに寄稿したり、JAVA PRESSに記事が載ったりしてんだからね。
記事みてサイトにアクセスして迷子になってあきらめる人がいるだろうから。
313:デフォルトの名無しさん
04/10/05 19:55:27
307を書き込むときに、AOPのドキュメントってこんなに充実してたかなぁと思ったんだけど、やっぱり書き直されてたのね。
サイトの更新履歴も欲しいぞな。
ブログベースってことで、どうなるのかしらんけど。
まあ、関係者のブログの関連するネタを整理して、アイドルネタを省いたものになるという感じか。
314:デフォルトの名無しさん
04/10/05 21:38:25
EJB以外を使う香具師は、厨房。
315:デフォルトの名無しさん
04/10/05 21:45:06
>314
そんな餌（ｒｙ
316:デフォルトの名無しさん
04/10/05 22:05:08
というか、厨房でもなんでもいいから、動くものを早く手軽に、ってことだな。
いくら高尚で美しい設計でも、利用開始に間に合わないんじゃ仕方ない。
317:デフォルトの名無しさん
04/10/05 22:18:29
>316
他のコンポーネントやテーブル設計を待たずに実装とテストのフェーズに入れる＞S2Unitによるリードタイムの短縮
S2OpenAMFやS2FlexみたくWebベースでHTML以外のUIの選択肢でも連携する手立てが用意されてるのもS2の良いところかもな。
318:デフォルトの名無しさん
04/10/05 22:24:55
>317
他のコンポーネント→他の’関連する’コンポーネント’の実装’
>313
S2DAOのドキュメントも刷新されてますね。
319:デフォルトの名無しさん
04/10/05 22:30:46
真剣に「くーす」で設計してみようと思って、ひがさんの↓
ダイコン事態の設計手法と、その２
を読んだ。
最後の「何か合コン誘われたから行ってくるわ」が気になったので読んで見た。
関係ねーじゃねぇか＞くーす
もう帰る。ｳﾜｧｧｰﾝ
320:デフォルトの名無しさん
04/10/05 22:37:44
>316
御意＞いくら高尚で美しい設計
美しい設計はあくまでメンテナンス性の為の一手段に過ぎない。
そうありたいし、心掛けてるが納期に間に合って、利益を生むのが大々前提。
で、プロジェクトには新人さんも（使用するテクノロジーに）不慣れな人間も居るのが当たり前。
彼らが、この先淘汰されるかどうかは知ったことでは無いが、現実の案件をデスマらせない
には、個々のスキルに任さないのは一つの立派な考え方。
数を集めるより少数精鋭の方がコストメリットもあるとは思うけど、愚痴をたれても仕方無い。
というわけでS2が選択肢としてあって、使ってるんだが。
321:デフォルトの名無しさん
04/10/05 22:41:10
>319
御愁傷様（藁。くーすについては大阪のからさわぎの資料がテンプレも付いてるので興味深いな。
322:316
04/10/05 23:03:41
じゃあDIは美しくない設計なのか、というと、そうじゃないんだよね。
むしろ、DIだと設計をしなくてよくなるので、美しいとか美しくないとか判定する必要もない。
各機能各層について独立したクラスを作って、ゴンゴン組み立てればいいわけだから。
どこでオブジェクト生成してどこに保持してどうやって受け渡すか、それをいかに美しい設計で実現するかなんて考える必要はないんだから。
もちろんミクロやマクロの設計はしないといけないけど、それはEJBだって助けてくれるもんじゃない。
それにミクロやマクロの設計は楽しいし。
323:デフォルトの名無しさん
04/10/05 23:19:30
without hairとか、禿げ本、禿げ会とかさー、言語の壁を隠れ蓑にして、
先人（Rod）をリスペクトしない姿勢が、鼻につくんだよ。
お前ら、Rod本人に向かって、禿げって言えんのかよ。
324:デフォルトの名無しさん
04/10/05 23:25:07
他者に優しいのが、XPのペアプロに代表される少数精鋭の徒弟制度。
「スキルの無い奴」とか
「彼らが、この先淘汰されるかどうかは知ったことでは無い」とか、
結局お前、自分に優しいだけちゃうんかと。
325:デフォルトの名無しさん
04/10/05 23:33:39
>>324
それ作者にも言ってやれ。
326:デフォルトの名無しさん
04/10/05 23:39:53
>324
少数精鋭のXP、って時点でスキルの無い奴がはじき出されてるぞ。
仕事なんだから、最低水準の質を確保する仕組みってのは求めて当たり前でしょ。
そこから先、どう仕事に取り組むかは個人の問題なんだから。
327:デフォルトの名無しさん
04/10/05 23:43:41
>323
コミッタでも近しい関係者でも無いよ。確かにイクナイ ＞お前ら、Rod本人に向かって、禿げって言えんのかよ。
禿しく同意だ。が、ひが氏本人が言い出した訳でもあるまい。
323本人の発言ではないと思うが、かといって逆にウンコ呼ばわりしたら同じ穴の狢でしょ？
>324
少数精鋭の徒弟制度がすくすくと育てば、ある意味で素晴らしいと思う。
で、’まず’自分に優しいのは当たり前だろ？社内のみならず協力会社を含めた遍く全ての他者が
今後、どう身を振るかまで慈悲深く’優しく’すんのかい？
328:デフォルトの名無しさん
04/10/06 00:48:38
>>323
Rodにハゲと言える仲になりたい。
329:デフォルトの名無しさん
04/10/06 02:12:53
つーか難癖つけすぎ。
粗探しばっかりでは面白くない。
330:デフォルトの名無しさん
04/10/06 02:24:16
まぁ、１のことを１０の言葉で語る人のことはさておき
（cocoon本のころは良かったのになぁ）、ちょっと本質的なネタを
振ってみたいな。
(1) S2を使うと、本当にテストがしやすくなるのか
(2) S2を使うと、本当によいものができるのか
(3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
(4) S2を使わないと、上記のようなことはできないのか
(5) 成果物全体がS2に汚染されるけど、それはOKなのか
まぁこの際S2をDIコンテナと言い換えてもいいや。
いくつかモノを作ってみたが、(1)はまぁ同意できる。
EJB使ってるとFactory駆使しないと結合を切れないが、
その辺をフレームワークとして統括できるのは便利。
(2)～(3)は、ツールで解決するものか？という気がぬぐえない。
あと、テストパターン研究会でも話題になったが、ソースコード
トレースがし難くなるのは避けられないという問題もある。
(4)は程度の問題か。(5)はメリットとの天秤になるのかな。
インテグレーションクラス周辺だけ使う、というのが現実的か。
ところで、S2が正しくinjectionしてくれるかどうかの
テストはどう書けば？（汗）
というわけで皆の意見を聞きたい。
331:デフォルトの名無しさん
04/10/06 03:11:04
似たような方向の技術ならスタンダードなものを選んで習得するのが鉄則。
となると、EJB以外の選択肢は無い訳で。
332:sage
04/10/06 05:47:27
>>330
>ソースコードトレースがし難くなるのは避けられない
これはDIの概念を読んだときからずっと気になってた。スキルの低い技術者が
出入りする大規模なプロジェクトでは影響がでかくない？
モデリングがちゃんとできる人がインターフェースの設計まで
きっちり終えてからコーディングさせないとメンテ不能なソースになりそう。
ひが氏はクラス図すらいらないみたいな事をどこかで言ってた気がするけど。
開発者もメンテナもくーすに従えば解決するのだろうか？
333:332
04/10/06 05:49:57
sage間違えて恥ずかちぃ
334:デフォルトの名無しさん
04/10/06 06:27:38
>>323
何だSpring派がS2叩きしてるだけか
335:デフォルトの名無しさん
04/10/06 06:29:10
>>324
少数精鋭をどう育てるの？
336:デフォルトの名無しさん
04/10/06 06:32:15
>>324
スキルのない奴が淘汰されるのは当然だろ？
337:デフォルトの名無しさん
04/10/06 06:33:15
>>323
で、オマエはRodの言ってることどれだけ理解して実践してるの？
338:デフォルトの名無しさん
04/10/06 06:36:42
で、お前等結局
１）S2が邪魔
２）ひがが嫌い
３）羽生がウザイ
のどれYO？
339:219
04/10/06 06:38:27
俺のおかげでスレも伸びたし S2 も注目されたわけだ。感謝汁！
340:デフォルトの名無しさん
04/10/06 06:55:09
羽生ウザイ
羽生はキチガイ
羽生はデブ
羽生はウンコ
羽生は氏ね！
341:デフォルトの名無しさん
04/10/06 07:17:30
>323
Spring派とかいうわけでも無いんじゃね？
>331
EJBとがどこがどう似てるんだろ？スタンダードってのは
2.0なのか、それとも先の3.0のことを指してるんだろうか？
先のことを指すんであればそれこそJDOも含めて、流れが
どうなるか判らんと思うんだが
>330
(2)、(3)は今後のくーす次第かな、S2を使うからどうなるわけでもない。
(4)は疑問自体が難しいな、逆にどう思います？
(5)についてはDIコンテナが依存性を注入するので汚染？と
言われてもと思うんだけど
だからトレースやりづらくなるというのは判らなくもない
342:デフォルトの名無しさん
04/10/06 07:19:48
>340
ID表示が無い板だからといって朝から釣りはやめような
343:デフォルトの名無しさん
04/10/06 07:25:08
＞＞３４２オマエ羽生だな（ｗ
344:デフォルトの名無しさん
04/10/06 07:25:54
羽生氏ね（藁
345:デフォルトの名無しさん
04/10/06 07:29:44
219頑張れ！219は正しい！219はネ申！羽生氏ね！
346:デフォルトの名無しさん
04/10/06 07:34:43
>343
釣れて小躍りしてるかもしれんけど赤の他人だ、
数少ない君の人生の喜びを奪って申し訳無い。
>332
どうだろう？メンテナというかカットオーバーしてチーム
が解散、保守は引継ぎってところで発生する問題点は
まだ言及されてないんじゃないかな。
diconのまとめかたを含めて330のトレースの問題が
出てくるかもしれない。
347:デフォルトの名無しさん
04/10/06 08:59:40
>>330
全て、S2やSpringを使えば無条件にというわけではないというのは前提。
> (1) S2を使うと、本当にテストがしやすくなるのか
コンポーネントが独立するので異なる環境で動かしやすくなる。
> (2) S2を使うと、本当によいものができるのか
よいものの定義にもよる。
同じものであれば早くできるようになると考えれば、よいものにするための時間が多く取れるのでよいものができる確率が高いといえるかも
> (3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
スキルが低い人が一定の品質を保てるのではなくて、スキルが低い人がいても一定の品質を保てる、だと思われ。
コンポーネントの独立度が高くなるので、スキル低い人の影響が減らせる。
> (4) S2を使わないと、上記のようなことはできないのか
DI+AOPを使わないと、初期コストがかかりがち。
ただし、その場合はプロジェクト用フレームワークをかっちり作ることになるので、DI+AOPを単純に使う場合よりも楽にできるかも。
でも、同じ努力をDI+AOPを使ってやったらもっとやりやすくなるだろう。
> (5) 成果物全体がS2に汚染されるけど、それはOKなのか
設計がDI前提のものになるだけで、個々はあまり依存しない。POJOだし。
だから、S2とSpringを切り替えることも、S2を使わなくすることも、個々の部分には影響なくできる。
と思う。
348:デフォルトの名無しさん
04/10/06 09:02:27
ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ
ただ、インターフェースの設計をかっちりやらないとダメなのは同意
くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが
349:デフォルトの名無しさん
04/10/06 11:28:08
今更だが。
>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ
スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w
350:デフォルトの名無しさん
04/10/06 12:21:09
>>349
いや、キミを判別しやすくて便利だから構わんのだけど。
351:デフォルトの名無しさん
04/10/06 16:19:56
>んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。
クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。
352:デフォルトの名無しさん
04/10/06 17:59:54
要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。
きちんとドキュメントは残しましょうって事ですかね。
353:デフォルトの名無しさん
04/10/06 18:01:39
ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。
354:デフォルトの名無しさん
04/10/06 18:48:42
そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。
355:デフォルトの名無しさん
04/10/06 18:57:14
>ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。
diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？
まあくーすとは路線が違うのかもしれんが。
356:デフォルトの名無しさん
04/10/06 19:14:53
DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。
357:デフォルトの名無しさん
04/10/06 19:19:09
>>355
そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。
オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。
くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。
358:デフォルトの名無しさん
04/10/06 19:30:30
あー、見積りは嬉しいかも
359:デフォルトの名無しさん
04/10/06 20:16:01
くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。
360:デフォルトの名無しさん
04/10/06 20:22:12
結論：EJB3.0 >>> Spring >>>>> S2
361:デフォルトの名無しさん
04/10/06 20:30:32
EJB3.0が本当に良いならS2EJBが出るような気もするがな
362:デフォルトの名無しさん
04/10/06 21:18:38
SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。
363:デフォルトの名無しさん
04/10/06 21:56:25
>360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。
364:デフォルトの名無しさん
04/10/06 22:04:01
>360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。
365:デフォルトの名無しさん
04/10/06 22:13:01
是非>>360にEJBとJDOの統合による将来像というのを教えてもらいたい
366:デフォルトの名無しさん
04/10/06 23:24:06
ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々
367:デフォルトの名無しさん
04/10/06 23:35:52
はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。
もちっと余裕があるサイトに引っ越したほうがいいような。
368:デフォルトの名無しさん
04/10/06 23:48:29
ロジックとデータの分離って、やりにくくね？
369:デフォルトの名無しさん
04/10/06 23:54:26
>>366
自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。
370:デフォルトの名無しさん
04/10/07 00:07:47
>>368
やりにくい部分もあるけど、やれる部分のほうが多くない？
371:330
04/10/07 00:25:56
みんな朝からありがﾄﾝ
提案目的は、S2が使えるシチュエーションと注意事項を確認したい、ということね。
330で提示した中で、
(2)と(3)を聞いた意味は、自然なモデリングを変に崩すことになったり、制約が変な方に
働いて妙なものができてこないか
(4)は、書き方がまずかったが、DIパターンの目的である「依存関係のreasonableな分離」
を実現するためにS2は適切なのか
(5)は、importが云々という話の他に、例えば、「コンポーネントはsingleton、状態はク
ライアントが持つ」という考え方に染まったコードになり、理解者（というより共感者？）
以外は気持ち悪い思いをするよね？ということ。
個人的に気になるのは、作成するソフトウェアの複雑性を緩和するブレイクスルーがない
ように見えることなんだよな。
例えば、状態はクライアントに持たせ、コンポーネントはステートレスという思想という
か制約。データとロジックを分離させる方が有効なケースがあるのはわかる。コンポーネ
ントを作りやすくなるケースがあるのもOK（小規模な場合しか想像できないが）。
ただ、一般的には複雑性が増すわけで、適用箇所次第では、複雑性のしわ寄せがクライア
ント側にくるだろうし、コンポーネントも組みにくくなる。
さらに、346が言うように、思想を理解させなければ、こうやって組まれた構成の第三者
の理解およびメンテナンスが困難だ。
というわけで、ぶっちゃけた話、ある程度大きなアプリの適用例とメイキングオブが知り
たいわけだが。これは身をもって体験するのが一番か？
S2に限らず、J2EEのメリットが出るような規模のサンプルって、ほとんど表に出てこない
しね。抽象的か、短すぎる事例報告だけ。というわけで、もーちょっと様子見かな。
372:デフォルトの名無しさん
04/10/07 00:27:23
>>370
「構造体と関数」って感じで慣れないな。
どうしてもドメインモデルで考えてしまうYO。
ロジックをビジネスロジックとビジネスルールに分けて、
ルールの方はドメインオブジェクトに記述するのはどうだろ。
問題はS2DAOでとってきたEntityに他との関連をインジェクト
しないといけないとこだな。
373:330
04/10/07 00:27:49
あ、ソースコードトレースがしにくいってのは、メタデータ使う
フレームワーク全般に言える事ね。オブジェクト指向レベル
どうこうというよりは、頭の中の回路を頻繁に切り替えるのが
おっくう。該当箇所探索もフレームワークのメタデータ特有の
探索方法に特化した知識や支援手段が必要になるのがウザイ。
だいたい、インピーダンスミスマッチがないレイヤーで、
別言語(?)によるコンフィギュレーション使う必然性って
あるんかいな。
テスターは再ビルド権限がないとか、SIerには再ビルド許さん
けど自由度は与えたいとか、そういう運用的理由なら、
わからんでもないが。
というわけで、DIコン使うならPico/HiveMind派（しょーもない着眼点だな、おい）。
374:デフォルトの名無しさん
04/10/07 00:33:41
・言葉がダサイ
「ダイコン」「くーす」「から騒ぎ」ちょと恥ずかしい。
・オタくさい
から騒ぎの後、アニソンカラオケ大会。きしょい。
375:デフォルトの名無しさん
04/10/07 00:48:22
Web層 フレームワーク固有のオブジェクト
↑
DTO
↓
ビジネスロジック層 DTO or ドメインオブジェクト
↑
ドメインオブジェクト
↓
ビジネスルール層 ドメインオブジェクト
↑
ドメインオブジェクト
↓
データアクセス層
こんな感じか。
376:デフォルトの名無しさん
04/10/07 00:51:41
戻り値にDIするインターセプタかな。
377:デフォルトの名無しさん
04/10/07 01:12:22
>372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？
>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。
>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。
378:デフォルトの名無しさん
04/10/07 01:33:48
>>377
Picoについては
URLﾘﾝｸ(www.picocontainer.org)
この辺みとけ。お前に与えられた時間は２分間だ（意味が逆）
クソ長いメソッドが多いが、エイリアスで短い名前も用意されてる。
>>367
ブザマだよな（苦笑）。
サービス運用規模の見積もり失敗でつか。
まーボランティアでそれなりの環境用意するのは金かかるので
大変なのはわかるが、今年は2004年です。
379:デフォルトの名無しさん
04/10/07 01:38:17
>>377
思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。
・他エンティティとの関連
User.isMemberOf(Group)みたいなメソッドが欲しい。
ロジック層でisMember(Group, User)ってなるとヤだなって思う。
ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。
380:デフォルトの名無しさん
04/10/07 01:41:39
>>371
ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。
そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。
XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。
381:デフォルトの名無しさん
04/10/07 01:47:54
それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。
382:デフォルトの名無しさん
04/10/07 01:48:36
記述の選択肢が少ない、というのが肝ね。
383:デフォルトの名無しさん
04/10/07 01:55:40
S2はマンセーだけどくーすは疑問
DI（IoC）に関しては >380の言うエントロピーの軽減が目的ってことでFA。
どのコンテナがいいか。
SpringやPicoと比べると、設定の手軽さと機能の豊富さでS2が一番だと思う。
欲しい機能があったとき、Rod Johnsonにメール出すより、ひがさんのblog
にコメントする方が敷居が低いし、レスポンスも速い。
Springはクドい。
くーすは、今公開されているサンプルやトライアル程度では、実際のプロジェクト
になったときに上手くいくか判断しかねる。
本を執筆中ということだけど、付録CDに実装までのサンプルでもあればいいのだが。
今までの開発手法（ユースケース駆動とか）も、本では上手く言ってるけど、
実際大変じゃんってことで、くーすを考案中なんだし、くーすも同じ轍を踏まない
とも限らんすね。
384:デフォルトの名無しさん
04/10/07 02:29:30
おれはDIコンテナってのは、ファクトリを自前でがりがり書く代わりにコンテナに
お願いできる（ファクトリ機能の外出し）ってことで理解してる。
それ以外の部分（Hibernate連携とか）はあくまでオプションだと思ってる。
くーすはよくわからん。資料がたりん....
385:デフォルトの名無しさん
04/10/07 02:53:44
くーすの内容をみずにレス
よくある開発手法は、一般的にやろうとしてたり、実装と独立しようとしてて、使えなくなってると思われ。
くーすの場合は、業務システムをSeasar使って作るという具合に、用途を限定しているから、変に一般化しようとしなければ問題ないんじゃなかろうか。
386:デフォルトの名無しさん
04/10/07 02:55:05
>>385
資料っていうか、資料へのリンクがない気がする。
たぶん、探せば資料はきっとある。
387:デフォルトの名無しさん
04/10/07 02:55:10
くーすは特にSeasar2に限定されるものではなかったような。
388:デフォルトの名無しさん
04/10/07 02:56:07
限定じゃなくて、前提だね。
389:デフォルトの名無しさん
04/10/07 03:04:20
ごめん、はてなの解説を「Diconを使ったときの・・・」と読み取ってしまってた。
あのへんのブログをぐるぐる回ったけど、くーす自体にはたどり着けなかった。
390:デフォルトの名無しさん
04/10/07 03:06:06
もうこういうの飽きた
391:デフォルトの名無しさん
04/10/07 03:07:58
っていうか、くーすってどこにあるの？
392:371
04/10/07 03:10:42
>>380
大筋で同意。うまく言葉にできなかったことを、シンプルな言葉でまとめてくれてありがと。
オブジェクト指向はデータとアルゴリズムをバインドさせることで、エントロピーを低減させた
と考えることができるが（C++普及前夜に、関数ポインタを構造体に持たせたコードが増えたのが
なつかしいな）、そういう視点でのブレイクスルーがあるの？ということを
言いたかった。
自由度が小さい記述方法を使うことで局所的なエントロピーは下がると思うが、
全体的にはどうなんだろ。フレームワークと、その根底に流れる思想を理解するための
情報量の扱い、という意味で。
「くーす」という哲学を理解というか納得した者同士は、下げられるって
ことなんだろうな、たぶん。
393:デフォルトの名無しさん
04/10/07 03:25:19
>>391
弟子による「くーす」教本
URLﾘﾝｸ(marrow.strnet.com)
ひが尊師やその弟子たちによる教えへのポインタ
URLﾘﾝｸ(www.wikiroom.com)
「ダイコン時代５秒前」くらいまでは読んでみてから、
拾い読みするといいかも。少なくとも修羅場突破用
割り切り基準としては優れている。
394:デフォルトの名無しさん
04/10/07 03:32:03
クレクレ君ばっかだね
395:デフォルトの名無しさん
04/10/07 03:36:29
>>393
ありがと。
396:デフォルトの名無しさん
04/10/07 03:37:57
>>394
あなたみたいに頭よくないからね。
397:デフォルトの名無しさん
04/10/07 03:53:58
>>383
> 設定の手軽さと機能の豊富さでS2が一番だと思う。
設定の手軽さで一番、というのは理解できん。
XMLのvalidation考えると特に。
ある程度大きな、例えばconstractor injectionの
インスタンス数が100とか言い出すと、コストが逆転する
かもしれんけど（まぁそこまでいくとXMLも専用エディタ
使わんと苦しいな）。
フィーリングとしてどれくらい？＞リーズナブルな規模
機能の豊富さはXMLの表現力と等価なわけで、情報量が（略）。
相手が日本人だと楽、というのは同意。自分も含めて
技術者として情けないがな……。一時期、Xalanコミュニティ
とかに顔つっこんでみたことがあるけど、やっぱりスケール
の違いを感じた。ロシア人の英語はよめねー。
>>384
そうね。個人的にもそこがコアだと思う。
AOPはそれを効率よく実現するための手段という考え。
そもそも「FactoryやAFactoryはDIコンテナで代用
できます！」ってのは、DIがFactoryの一流派だけ
なんじゃないかと小一時間（略
398:デフォルトの名無しさん
04/10/07 10:26:57
>>367
鯖提供者募集中だそうです。
399:デフォルトの名無しさん
04/10/07 11:07:16
しかし、こういうリフレクション全開のしくみが定着すると、いままで語られてた
「型安全性」だとか「コンパイルによる事前検証」のメリットってどうよ？と思わないでもない。
400:デフォルトの名無しさん
04/10/07 14:10:56
>>399
大いにそう思う。
いままでだと、型の安全性ってのは基本的にコンパイラが
あるていどの保証(とはいってもぴんきりだが)を
してくれていたわけだが、そういった部分に頼れないと
いうことだからね。
401:デフォルトの名無しさん
04/10/07 16:46:22
強い型付けはJavaのウリでもあるけども、オブジェクト指向的な利点を
徹底利用しにくいところもあったね。たとえばListnerを使ったコールバック的な
委譲モデルでも、おれはListnerインターフェイスをimplementsするんじゃなくて、
モデル側にMethodオブジェクトを渡してやるほうがなんぼかましじゃないかと
思ったりもするし。
たとえばThreadにRunnableオブジェクトを渡すんじゃなくて、実行して
ほしいMethodを渡して、Thread側ではinvoke()するとかのほうがもっとフレキシ
ブルなんじゃないかと。Runnableをimplementsする必要すらなくなるし。
こういう、型なんて関係ない、メソッドがあればいい、という使い方は本来、
オブジェクト指向ならではだったわけで。
DIコンテナの場合、利用側ではインターフェイスをもとにしたプログラミングを
行なうわけで、型安全性も十分保証できてると思うし。
402:デフォルトの名無しさん
04/10/07 17:14:14
キャストごりごりのコードになるよね？
403:デフォルトの名無しさん
04/10/07 17:28:17
>>401
C#のデリゲート、MSがJavaの仕様に入れようと提案したら
Sunに断られたそうで。
404:デフォルトの名無しさん
04/10/07 17:29:09
そうだな、DIコンテナ使うとキャストは増える。Object型返すしなあ。
たしかにそこでの型安全性は低くなってると思う。Cast例外って
実行時例外だったよなあ。
405:デフォルトの名無しさん
04/10/07 17:39:34
キャストは増えない。setter使えば勝手に入れてくれるから
406:デフォルトの名無しさん
04/10/07 18:37:15
最初の入り口さえどうにかすれば、あとは大丈夫という感じだね。
そういえば。
オブジェクトの遅延生成ができるともっといいね。
遅延というか、オンデマンド。
getXxx使ったときに生成されるような。
じゃないとイモヅル式にオブジェクトが生成されてしまう。
できるんだっけ？
407:デフォルトの名無しさん
04/10/07 19:26:43
>>405
いやコンテナ内のオブジェクトはいいんだよ。増えるところは
S2の例：
Hello hello = (Hello) container.getComponent(Hello.class);
この部分ね。まあ対した問題じゃないんだけどね。文法上
cast失敗を気にする必要もないだろうし。
408:デフォルトの名無しさん
04/10/07 19:58:36
使うとわかるけどcontainerの外でcontainerを使う方が珍しいと思う
409:sage
04/10/07 20:27:27
まー依存性注入するところでcontainer使うんだから、
奇麗に設計できている場合はそうね。
410:デフォルトの名無しさん
04/10/07 20:43:38
インスタンスがいもづる式に生成されまくるという問題ってないの？
411:デフォルトの名無しさん
04/10/07 20:57:04
インスタンスはcontainerが保持しているから問題なし
412:デフォルトの名無しさん
04/10/07 21:15:04
そのメモリはどこから出てくるの？
413:デフォルトの名無しさん
04/10/07 21:24:48
>>380はエントロピーって言葉に何か間違ったイメージを持ってるな
414:デフォルトの名無しさん
04/10/07 21:34:59
>410
基本はSingletonだ
415:デフォルトの名無しさん
04/10/07 21:36:14
ソフトウェアにおけるエントロピーの定義を教えてくれませんか？
416:デフォルトの名無しさん
04/10/07 22:09:49
>>414
そうすると、ソフトウェア中で必要なオブジェクトがすべて生成されてしまうことにならないかな。
417:デフォルトの名無しさん
04/10/07 22:13:33
>>415
これぐらいは自力で調べる癖をつけようね。
URLﾘﾝｸ(ja.wikipedia.org)
これの「情報理論におけるエントロピー」のところにある。
> ある確率分布 p(x) をもつ確率変数 X が与えられたとき、
>
> H(X) = -Σ_{x∈X}{p(x)log(p(x))}
>
>この量 H を 確率変数 X のエントロピー という。
418:デフォルトの名無しさん
04/10/07 22:20:41
>>413
その言葉のもつ本来の意味を知らず、また、知ろうともせず、
単に語感やニュアンスだけでカッコいい言葉を使ってみる、
というのはどこに行ってもありがちだけどね。
>>380の言わんとしていることは分かったけど。
419:デフォルトの名無しさん
04/10/07 22:23:27
>>415
ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
整理されてなく、どこになにがあるかわからないソフトウェアはエントロピーが高い。
Javaのコードは選択肢が多いから、一行の情報量が多い。
対して、SeasarやSpringなどのBean定義ファイルは選択肢が少ないので情報量が少ない。
また、規模の大きいソフトウェアも、行ごとの情報量が大きくなる。
系が閉じているときのエントロピーの総和は一定なので、どこかのエントロピーを下げようと思うとどこかにエントロピーを押し付ける必要がある。
整理してどこになにがあるか推測しやすい状態で、選択肢の少ないコーディング技術を使って、コード量を少なくすると、エントロピーが低くなる。
作成するソフトウェアのエントロピーを下げようと思えば、ライブラリやフレームワークを使うことのほかに、開発管理がある。
管理された成果物のエントロピーは低いけど、管理作業自体のエントロピーが高いから。
420:415
04/10/07 22:35:34
>>417,419
ありがとうございました。勉強になりました。
421:デフォルトの名無しさん
04/10/07 22:58:07
くーすを実案件に適用した例ってあるのかな？
422:デフォルトの名無しさん
04/10/07 23:05:47
いまオフショア開発でやってるんじゃなかったっけ？
423:デフォルトの名無しさん
04/10/07 23:08:14
>>420
-log(p(x))っていうのが情報量ね。確率の対数。で、エントロピーは情報量の平均(期待値)
424:デフォルトの名無しさん
04/10/07 23:17:48
×確率の対数
○確率の逆数の対数
文法のルールが多いほどコードのエントロピーは低くなる。
だから、Javaのコードは型の緩い言語よりエントロピーが低くなるんだね。
そのかわり、文法を勉強するためのエントロピーが高くなる。
425:デフォルトの名無しさん
04/10/08 01:13:25
>>416
すべて生成したとしてもデータを持たないオブジェクトという前提ならそれほど問題ないのでは？
426:デフォルトの名無しさん
04/10/08 01:15:39
>416
ソフトウェア中で必要なすべてじゃなくて、DIContainerに登録されているものすべて。
prototypeとouterを除く。
なんでもかんでもDIContainerに登録するわけじゃないよ。
多分416が思ってるほど多くはない。
427:デフォルトの名無しさん
04/10/08 01:23:41
JFrameとかを登録する方針にしたら、えらいことなりそうだけど。
428:デフォルトの名無しさん
04/10/08 01:35:41
VBとかDelphiで起動時に全フォームクリエイトしておいて
使うときにはShow()するような感じ？
Delphiでちゃんとしたアプリ作るときはちゃんと生成・消滅を管理するけど(VBはシラネ)、
429:デフォルトの名無しさん
04/10/08 01:45:53
そう、そんな感じ。
JFrameはシングルトンにしなければいいのかな。
430:デフォルトの名無しさん
04/10/08 03:27:40
＞ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
…ヲイヲイ…。
431:デフォルトの名無しさん
04/10/08 03:43:00
JFrameをDIContainerに登録するなら、prototypeになるはずだから
問題なしだ。VB、Delphiは良く知らんが、一つだけインスタンスを
生成しておいて、必要な時はコピーを生成してShow()するようになる。
これくらい分からんような奴らが、「ドキュメントすくねえ」とか
「全然優しくねえ」とかほざいてるのであれば、ひが氏は気に留める
必要ない。ドキュメント整備した所で使えねーよ。
S2Daoの機能強化やS2JSFの方に注力して欲しい。
432:デフォルトの名無しさん
04/10/08 05:12:15
前に羽生さんに粘着してた香具師がいたような。。。
ここにもいたりしてw
433:デフォルトの名無しさん
04/10/08 09:14:31
>>430
じゃエントロピーってなに？
434:デフォルトの名無しさん
04/10/08 09:45:49
>>417の定義のままだと思うのだが。
435:デフォルトの名無しさん
04/10/08 09:51:35
>>433
俺≠430だけど、こんな感じじゃない。
持ちうるデータのバリエーションの許容量⇒情報量
それの系全体(平均)⇒エントロピー
あるいは、バリエーションの許容量ではなく
絶対量そのものを指す人も多いかも。
どちらにせよ、Wikipediaのと違いはないと思う。
436:433
04/10/08 10:00:18
>>435
実は、情報量と書いてる部分も、エントロピーと書くべきだった気がする。
情報量っていうのは、たとえばJavaコードを1行取り出したときに
S2Container container = S2ContainerFactory.create(PATH);
だったときにどれだけ意外性があるか、という、それぞれの事象に対する量だからね。
437:デフォルトの名無しさん
04/10/08 10:06:07
>>431
こういう、足りない点を指摘するやつをバカにする方が、スレを荒らしてるわけだが。
こうやって評判落とすようなマネするのって、ヒガさんに実は恨みがあるから？
438:デフォルトの名無しさん
04/10/08 10:55:14
>>432
そりゃいるだろ。2chだからな。
439:デフォルトの名無しさん
04/10/08 10:57:34
>>437
恨みはないかもしれないが
妬みややっかみを持っている
ヤシはいるんだろうな。
440:デフォルトの名無しさん
04/10/08 10:58:46
>>438
羽生さんもいるくらいだからな。
441:デフォルトの名無しさん
04/10/08 11:00:56
>>439
で、ひがさんを擁護するフリをして、Seasar2は敷居が高い、とか、欠点に対する指摘を受け付けない、とかそういう逆宣伝をしてるわけか。
442:デフォルトの名無しさん
04/10/08 11:03:29
>>440
羽生さんがいるところには常に粘着するわけか。
大変だな。羽生さんも追っかけもｗ
443:デフォルトの名無しさん
04/10/08 11:04:03
恨みを買ってもしょうがないようなところあるからな。
人の話を遮って自分だけ延々と喋るし。
たいていは人の話に耳を貸さないくせにそれは相手によるし。
嫌いなやつは多いだろう。
444:デフォルトの名無しさん
04/10/08 11:07:09
>>443
まあそういう話はスレ違いってことで。
呼び出しくらうよ。
445:デフォルトの名無しさん
04/10/08 11:08:04
>>443
何だオマエ知り合いなのか。
本人に直接言ってやれよｗ
446:デフォルトの名無しさん
04/10/08 11:12:59
直接言えないから粘着してるんだよｗ
447:デフォルトの名無しさん
04/10/08 11:15:20
それにしても、よく観察してるね。
448:デフォルトの名無しさん
04/10/08 11:22:09
DIの利点って、分からん奴らにはメソッドの仕様だけ渡して、
その部分だけ他に影響を与えずに作らせることができるという
ことだと思います。
Rodの本なんかを読んだり、ソース調べたり、自分で試したり
できる人とできない人で、Seasarに関わる人は分化されるのです。
S２を作る人、使う人、使われる人の３種類になるのでしょう。
それぞれのスキルにあった役割を与える。これも優しさです。
使われる人は、他に問題を波及させずにとりあえず、与えられた
メソッドの実装を行えばよくなります。
使う人は、実装を外注しやすくなり、Springと比べてもテストや
設定が格段に楽になります。
その点の説明が公式サイトにないので（日記にはあるが）使われる人が
勘違いして、ちょっと調べれば分かることをここでゴチャゴチャ騒いで
いることでしょう。
ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。