【DI】Java Spring Fr ..
2:デフォルトの名無しさん
07/01/23 11:00:54
Rod Johnson著「実践J2EE システムデザイン」
URLﾘﾝｸ(www.amazon.co.jp)
TheServerSide.com - Introducing the Spring Framework
URLﾘﾝｸ(www.theserverside.com)
Rod Johnson著「J2EE Development without EJB, Expert One-on-One」2004年5月発刊予定
URLﾘﾝｸ(www.amazon.co.jp)
SourceBeatの電子出版書籍「Spring Live」
URLﾘﾝｸ(www.sourcebeat.com)
「Spring Live」サポート用Blog
URLﾘﾝｸ(www.sourcebeat.com)
Struts + Hibernate + Spring Framework のWebアプリ 作者は「Spring Live」の著者
URLﾘﾝｸ(raibledesigns.com)
Spring Frameworkを使用したJDBCプログラミングチュートリアル(作成途中)
URLﾘﾝｸ(www.buggybean.org)
eclipseプラグイン「Spring UI for Eclipse」
URLﾘﾝｸ(springui.sourceforge.net)
Spring FrameworkのWiki「Spring Pad」
URLﾘﾝｸ(wiki.bmedianode.com)
Spring Frameworkを利用した蔵書検索アプリケーション
URLﾘﾝｸ(www.commentout.com)
PicoContainerのプレゼンテーション資料日本語版(IoCの説明がわかりやすい)
URLﾘﾝｸ(cvs.picocontainer.codehaus.org)
3:デフォルトの名無しさん
07/01/23 11:27:24
コネクションプールからEntityManagerのDI生成するのは常識だろ
NetBeans＋glassfishとか全部自動でやってくれるぜ
TomcatからしかやらないようなレベルならDIコンテナも（DBによっては）コネクションプールもいらないかもしれないけどな
4:デフォルトの名無しさん
07/01/23 11:30:42
DI生成するってどういう意味？
DIって言葉の使い方がおかしい希ガス。
5:デフォルトの名無しさん
07/01/23 11:42:42
注入コードってことだな
6:デフォルトの名無しさん
07/01/23 11:54:55
>コネクションプールからEntityManagerのDI生成する
いみふ
>TomcatからしかやらないようなレベルならDIコンテナも（DBによっては）コネクションプールもいらないかもしれないけどな
これもいみふ
7:デフォルトの名無しさん
07/01/23 12:58:51
スレ違いだがglassfishて運用に耐えるクオリティなのか？
8:デフォルトの名無しさん
07/01/23 15:22:02
>>3
言葉は正しく使おうな。
脳内で勝手に進化させないように。
>>6
まったく同じこと思いました。わけわかんないね。
9:デフォルトの名無しさん
07/01/23 15:23:00
>>7
Tomcatを運用で使える程度の要件ならおｋ。
10:デフォルトの名無しさん
07/01/23 15:24:15
EntityManagerのDI？
DI生成する？
しかもコネクションプールから？
氏んでいいよ。
11:デフォルトの名無しさん
07/01/23 16:45:52
>>9
sunが9.0はまだプラットフォーム版しか出してないからな
これがスタンダード版やエンタープライズ版もだしてくるようだと大丈夫と思われ
どちらにせよ開発はglassfishで運用はsunやIBM,WebLogicの商用版ってところだろうが
どこが最初にJavaEE5対応の商用版出してくるか見もの
12:デフォルトの名無しさん
07/01/23 17:03:14
>>11
goodなコメントThanx.
>>3
nonsense
13:デフォルトの名無しさん
07/01/23 22:24:34
ﾊ,,ﾊ
('(ﾟ∀ﾟ∩_ おいらをどこかのスレに送って！
／ヽ 〈／＼ お別れの時にはお土産を持たせてね！
／|￣￣￣|.＼／
| .ﾓﾂ煮..|／
￣￣￣
現在の所持品：カスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
ＪＡＳＲＡＣが73歳おじいちゃんに音楽を演奏したんだから840万払えと告訴
判決懲役１０月、執行猶予３年（求刑・懲役１０月）
日本音楽著作権協会（JASRAC）が、名古屋の飲食店経営のおばちゃんに、
音楽を演奏したんだから1,600万円払え、と告訴し、おばちゃんは逮捕。
ｽﾚﾘﾝｸ(news4vip板)
14:デフォルトの名無しさん
07/01/23 23:13:37
>>3 のアレは煽りのつもりなのか何なのか。
ようやく変な人が出てくるくらいに普及し始めたのだと
前向きにとららえることにした。
ところで DIxAOP コンテナとして紹介されるけど
AOP を意識してる人ってどのくらい居ます？
トランザクション管理とかで間接的には使ってるんだけど。
15:デフォルトの名無しさん
07/01/23 23:19:00
spring使うからにはAOP使わないと意味ないだろー！！！
ってぐらい意識してる
16:デフォルトの名無しさん
07/01/23 23:20:22
>>15
どんなことに使うの？
17:デフォルトの名無しさん
07/01/24 01:12:20
Japan Spring User Groupにある導入事例見てみるといいよ。
ほとんどがトランザクション管理とかトレースとか一般的な使い方だったよ。
今さ、S2DxoをSpringで使えるように移植してるんだけど、AOPってこういう使い方もあるんだって勉強になる。
HibernateとかもAOPでエンハンスしてるんだよね？
18:デフォルトの名無しさん
07/01/24 04:49:17
Jythonって完成度高い？Pythonの勉強に使ってみようかと思ってるんだけど。
19:デフォルトの名無しさん
07/01/24 11:52:01
JRubyは完成度高かった。
20:デフォルトの名無しさん
07/01/28 18:12:25
javaでWeb開発やってるが、strutsとかFWをまったくつかったことがない。
オブジェクト指向がわかってないし、javaもわかってて使ってるのかも怪しい。
勉強なんかはまずしない。
こんな連中にSpringを使わせるのは危険かな？
Hibernateは無理だろうからとりあえずiBatisかDbUtilあたりから入ってみようと思ってる。
21:デフォルトの名無しさん
07/01/28 18:27:52
そんな連中にソフトウェア開発させるのが危険ｗ
でも、そういった連中に指導・指示・教育できるのならspring導入は問題ないのでは？
22:デフォルトの名無しさん
07/01/28 18:40:03
> javaでWeb開発やってるが、strutsとかFWをまったくつかったことがない。
自社製フレームワークとかすらも無いわけ？
プロジェクト毎にゼロから書きなおしてるとか？
23:デフォルトの名無しさん
07/01/28 18:59:44
他はどうとうでもなるが
＞勉強なんかはまずしない。
これは話にならんな。
知らんものは調べれば済むんだが調べようとしないのでは。
24:デフォルトの名無しさん
07/01/28 20:25:42
やっぱ無理だよね。
仮に使えるようになってもspringの何がいいの？設定ファイルうざくね？ってなるのがオチだな。
ﾊｧ。もっとまともなレベルの会社に行きたい。
みんなありがと。
25:デフォルトの名無しさん
07/01/28 20:29:41
むしろ>>20みたいな環境でこそspringが役に立つと思うが。
26:デフォルトの名無しさん
07/01/28 20:40:05
>>24
プロジェクトとしてSpringを使うことは可能。
連中にはinterfaceだけはとにかくきちんと定義することを徹底させて
(interfaceがきちんと機能を表現できてるかはお前さんがチェックする。)
実装は好き勝手にしやがれ、単体テストだけは完璧に通せと言う。
設定ファイルうざくね？とか言われたら
じゃぁお前がフレームワーク作るか？といえば黙る。
Springそのものの仕様・実装でうまく行かないところとかは
全部お前さんが調べてお前さんが直す。
これでどうにかなる。
他のメンバーの10倍以上の負担をお前さんが背負うことになるが
闇雲に突き進むより数段マシな結果が得られる。
あとコードレビューは最低週１回以上はやった方がいい。
27:デフォルトの名無しさん
07/01/28 20:43:33
>>26
同意。
ほっとくとゴミを量産されて、10倍どころの負担じゃ効かなくなる。
28:デフォルトの名無しさん
07/01/28 21:10:32
>>25
おれもそう思ったんだが、なかなか・・・
>>26
interfaceの存在は知っていても自分で宣言したことはないであろう人々だからなぁ。
やっぱ俺が使うって言ったら俺が面倒みなきゃなんないんだよな。
客と打ち合わせして、ドキュメント作って、環境構築しに行って(運用もやるので)、
コードレビュー・・・。手が回らん気がする。俺も実装やらなきゃいけないだろうし。
Springスーパーサンプルとかいう本を全員に読ませれば少しはましになるかな？
簡単だけどWebアプリの作り方が１からのってるし。
新人(そこまで馬鹿じゃないと思うが)にspringつーかjavaを理解させるのにどういうことから教えますか？
29:デフォルトの名無しさん
07/01/28 21:23:01
＞手が回らん気がする。
この状況はSpring使わない従来の作り方だと解消されるの？
であるならば従来のやり方でやったらいいんじゃないかな。
いずれにせよ一人は辛い。もう一人で良いから理解ある人を連れてくるべき。
＞どういうことから教えますか？
開発環境だけ整備してやって、あとは実地でやれでいいんじゃないの？
分からないところあったら質問に来いで十分。あなただってそうだったでしょ？
これはもうマ板の話題だと思うんだが。
30:デフォルトの名無しさん
07/01/28 21:24:11
ｔｈｘ。そろそろ引っ込みます。
31:デフォルトの名無しさん
07/01/28 23:58:38
>>28
インタフェースは全部あなたがつくってみんなに配ればいいじゃない。
んで、内製のクラスはnew禁止にする。
これでOKじゃね？
32:デフォルトの名無しさん
07/01/29 06:57:22
何か１つ業務選んで、Spring使ったプロトを作って、それをひたすら真似させたら？
33:デフォルトの名無しさん
07/01/30 22:19:25
ロジックを実装しているクラスをActionSupport実装クラス内で使いたいのですが、
インスタンスを取得するのにgetBean()をするのと、setterインジェクションを使用するのではどちらがよいのでしょうか。
もしかしたらどちらもおかしいのかもしれませんが、一般的？な方法を教えていただけないでしょうか。
34:デフォルトの名無しさん
07/01/31 08:03:31
お好きな方で♪
35:デフォルトの名無しさん
07/01/31 09:16:16
インジェクション！インジェクション！
36:デフォルトの名無しさん
07/01/31 09:38:18
異論反論インジェクション！！！
37:デフォルトの名無しさん
07/01/31 10:59:50
>>2
> eclipseプラグイン「Spring UI for Eclipse」
> URLﾘﾝｸ(springui.sourceforge.net)
これってSpring IDEよりもいいの？
Spring IDEと重複しても問題ない？
コンフリクトでEclipseが壊れるのが怖いんだけど。
なんどもEclipseを再インストールしている身分ですので
38:デフォルトの名無しさん
07/01/31 11:04:47
>>37
あれ？
名称変更された同一プロダクトじゃなかったっけ？
間違ってたらｽﾏﾝ。
39:デフォルトの名無しさん
07/01/31 12:24:14
>>37
URLが
URLﾘﾝｸ(www.springide.org)
にかわっとるね
40:デフォルトの名無しさん
07/01/31 12:24:50
見ると、Spring IDEという名前に変わってるね
41:33
07/02/01 00:36:44
>>34-36
どっちでもいいってことですか？すみません。
なんかからかわれてるようにもみえるのですが・・・
42:デフォルトの名無しさん
07/02/01 01:32:24
setter injectionを使うのが一般的。
43:デフォルトの名無しさん
07/02/01 02:01:26
半々かな
44:35
07/02/01 09:02:53
>>41
ごめん。からかってみた。
俺敵にはセッターインジェクションで。
Springに依存したコードでいいならgetBeanも選択肢って程度。
45:デフォルトの名無しさん
07/02/01 21:36:45
ちょっと書いてみればいい。
getBean だと疲れるよ。
46:デフォルトの名無しさん
07/02/01 23:46:06
すみません。質問させてください。
ログイン管理をするインターフェースが用意されていて、それを私が実装することになりました。
login(id, password)
logout()
のようなメソッドがあり、id,passが正しかったらセッションに情報を格納しようとしたのですが、
どう考えてもセッションのインスタンスが取得できません。setterインジェクションとかでどうにかなるものなのですか？
47:デフォルトの名無しさん
07/02/02 00:01:57
セッションのインスタンスってなに？
48:デフォルトの名無しさん
07/02/02 00:23:03
>>46
＞どう考えてもセッションのインスタンスが取得できません。
できないことないけど、無理してやるメリットがない。
login(context, id, password)
こうしとけ
login(userのbean, id, password)
のほうがいいけど。
49:デフォルトの名無しさん
07/02/02 01:23:08
contextってなんだ？ｗｗｗ
50:デフォルトの名無しさん
07/02/02 01:32:24
やっぱSpringかな？
時期的にも
51:デフォルトの名無しさん
07/02/02 02:09:48
>>50
でもこのスレ見る限りまともに使えてそうな奴も居ない現実
52:デフォルトの名無しさん
07/02/02 02:28:19
>>51
Strutsとかと違って、下手を引き上げるためのもんじゃないしな。
上手が楽するためのもんだから。
53:デフォルトの名無しさん
07/02/02 03:42:56
Strutsだってマトモに使えるやつ（ｒｙ
54:デフォルトの名無しさん
07/02/02 08:43:45
やっとstruts + spring + jpa の maven環境できた・・・
55:デフォルトの名無しさん
07/02/02 11:42:55
>>46
聞くならもう少し詳しく。
その説明じゃ、セッションにバインドされるクラスなのか、
セッションを扱うクラスなのか、何も分からんじゃないか。
56:デフォルトの名無しさん
07/02/02 12:19:35
そんなまじにならなくてもｗ
既に解決して用済みかもしれないしｗｗｗ
57:デフォルトの名無しさん
07/02/02 13:00:47
つかSpring2.0ならセッションスコープのインジェクションできなかったけ。
58:デフォルトの名無しさん
07/02/02 13:06:52
連投スマソ。
1.0系の時はServketFilterでHttpServletRequestを全部ThredLocal変数にいれて、
使う側、たとえばログインサービスなんかはThredLocal変数を保持したHolderクラスかなんかをインジェクションしてたな。
まあ>>46の場合はまともに考えたら、
interface LoginService {
User login(String id, String password);
void logout(User user);
}
とかなって、セッションにデータを保存なんて、
このインターフェースでやる事じゃないと思うが…。
59:デフォルトの名無しさん
07/02/02 15:43:56
Acegi
60:デフォルトの名無しさん
07/02/02 16:54:16
ThreadLocalって便利だよな。気をつけないと乱用してしまいそうだ。
61:46
07/02/02 20:12:05
>>58
まさにその状態です。＋ログイン済みならtrueを返すメソッドがあります。画面遷移毎に呼ばれるそうです。
で、私のやることはUserDaoを実装して、id,passwordをチェックして、正しければなんからかの形でログインしている状態を保持します。
いろいろ調べてみたのですが、HttpSessionを取得してBooleanかなんかで保持するのが一番簡単なのではと思いました｡
ちなみにまだ解決してません。。。
ThreadLocalを調べてみます。
62:デフォルトの名無しさん
07/02/02 20:57:02
設計がおかし・・・
63:デフォルトの名無しさん
07/02/02 20:58:19
LoginServiceはAction(Page)で使用してるんじゃないの？
サービスから取得したUserインスタンスをAction(Page)で保存させて
Filterでチェックが筋だと思うけど
あとBooleanで保持してるだけだとログインしているUserIdはどうやって
取ればいいのでしょうか？って俺速攻聞くよ
64:デフォルトの名無しさん
07/02/02 21:08:15
とーしろにAnA実装させるなんて怖いシステムになりそうだなｗｗｗ
65:デフォルトの名無しさん
07/02/02 21:37:36
spring2入門を参照しながらacegiでやればいいじゃない
66:デフォルトの名無しさん
07/02/02 22:08:28
ThreadLocal 使ってウハウハと思いきや
サーブレットコンテナでスレッドの使い回しがされてて
なんかうまく動かねーやとか言うわけだ。
67:デフォルトの名無しさん
07/02/02 22:11:56
>>46の話聞く限り、設計おかしいよね…。
68:デフォルトの名無しさん
07/02/02 22:15:03
おかしいかどうかでなくていみわかんね
69:デフォルトの名無しさん
07/02/02 22:16:57
Webアプリだとは一言も言ってないのに話が通じてるのが恐ろしい。
確定したのは61でHttpSessionと書いてからだ。
質問以前の何かが欠けてる。
70:デフォルトの名無しさん
07/02/02 22:58:21
まぁ、活気のないスレに書き込みがあるだけで俺は楽しいわけで。
Springの参考書にWebアプリのサンプル載ってたが、ログイン処理も載ってるかもよ。
71:デフォルトの名無しさん
07/02/03 00:17:40
ここでまともな会話求めるほうがおか・・・
72:デフォルトの名無しさん
07/02/03 00:57:19
>>66
その場合はspring自体もｗ
73:デフォルトの名無しさん
07/02/03 10:05:29
よし
Spring勉強しよ
74:デフォルトの名無しさん
07/02/03 10:07:11
>>73
一緒にべんきょしよ♪
75:デフォルトの名無しさん
07/02/03 19:30:35
だがお断りだ
76:デフォルトの名無しさん
07/02/04 15:25:25
勉強とかぬかしてる時点で負けｗｗｗ
77:デフォルトの名無しさん
07/02/04 21:35:23
Spring導入してるとこって少ないのか?
78:デフォルトの名無しさん
07/02/04 22:55:57
まだ少ないとは思う。案件で使うにはそれなりに使える、アーキがわかってるやつがいないと地獄みるからな。
一度暴走すると保守できなくなるし。
Strutsの時もそうだった。
79:デフォルトの名無しさん
07/02/04 23:52:30
少ないことないよ。
新規の案件でSpring使わないところは、はっきりいって単に「ついていけてない」ことを意味する段階に入っている。
（もちろん「敢えて」使わないことを選択できる技術力が高いところは除いて、の話だが。）
80:デフォルトの名無しさん
07/02/04 23:54:37
人員の自転車操業ばっかしてる業界だから
「質が安定しない」のがFrameworkがStrutsに偏る理由。
81:デフォルトの名無しさん
07/02/05 00:12:30
Web層のフレームワークは未だにStruts使ってるところは多いだろうなってのは同意するとして、
＞「質が安定しない」のが
が良く分からん。
82:デフォルトの名無しさん
07/02/05 00:30:30
毎度毎度フレームワークの使い方から覚える奴でなりたってるから
83:デフォルトの名無しさん
07/02/05 00:54:33
フレームワークの使い方云々より日本語の使い方を覚える必要がありそうだな
84:デフォルトの名無しさん
07/02/05 00:56:15
おまえが？話がかみ合わないなら無駄なレスせんでええ。
85:デフォルトの名無しさん
07/02/05 01:00:46
かなりカチンときたようだな ( ´,_ゝ｀)ﾌﾟｯ
86:デフォルトの名無しさん
07/02/05 12:28:00
そもそも>>77のネタフリから
>>80で突如Web層の話になる理由が分からん。
87:デフォルトの名無しさん
07/02/05 23:22:13
seasarのほうが使われているのかね？
88:デフォルトの名無しさん
07/02/05 23:29:14
日本でもSpringの方が多いんじゃない？
89:デフォルトの名無しさん
07/02/05 23:31:45
シーさースレ見る限りあまり使わんほうがいい気がするなしーさーは
90:デフォルトの名無しさん
07/02/05 23:47:45
それでもS2Daoは良いものだという話だ。
Sesarスレはまぁ一昔前のRubyスレがあんな感じだったじゃない。
日本語プロダクトはいろいろな人が湧くんだよ。
いい意味でも悪い意味でも。
久しぶりにSpring1.1.xのプロジェクトをメンテして
<property name="hoge" ref="fuga"/>
が動かなくて小一時間無駄にした。
1.2.xになるまでは
<property name="hoge">
<ref bean="fuga"/>
</proerty>
と書くことに気がついたときは泣きそうになった。
91:デフォルトの名無しさん
07/02/06 01:43:59
Spring Lint使えばすぐに教えてくれたのにね☆
92:デフォルトの名無しさん
07/02/06 15:41:48
俺の回りでは断然springの方が多いな。
また、俺の回りではDI使ってないプロジェクトの方が断然多いなｗ
93:デフォルトの名無しさん
07/02/06 16:18:58
これはあくまで印象（というかむしろ偏見）だが、
Seasarは同じ日本人が作ってるからかファウンデーション内のごたごた感が気になってしまって、
「プロダクトまでグダグダ・仕様が右に左にフラフラ」という印象になってしまった。
実際そうなのかどうかは問題じゃなくて、
俺個人がそう思い込んでしまったんだから、この不信感はどうしようもない。
とりあえず、Springはトランザションマネージャが気になってしまう。
まぁ、単一DBしか接続しないなら全く問題ないんだけどね。
94:デフォルトの名無しさん
07/02/06 18:07:13
Hibernate3 が出た頃、Transaction Manager 絡みで
Spring と Hibernate の両コミュニティがやや険悪になってた気がする。
95:デフォルトの名無しさん
07/02/06 19:55:37
国産プロダクトだからって使いやすいかっていうとそうでもない。
俺は基本的に日本人が作ったもの信用してないからどうしてもSpringを使ってしまうんだよ。
96:デフォルトの名無しさん
07/02/07 07:19:41
開発者の国籍なんてどうでもいい。
重要なのはその道具が俺にとって役立つかどうかだ。
97:デフォルトの名無しさん
07/02/07 07:22:00
>>96
と朝から2chやるような使えない奴が言っています
98:デフォルトの名無しさん
07/02/07 07:29:57
>>97
7:22って朝だよね？ｗｗｗ
99:デフォルトの名無しさん
07/02/07 07:42:35
>>98
ゆとりか？
100:デフォルトの名無しさん
07/02/07 07:56:26
またいみふな奴が出てきた
springが普及し始めたということか？
101:デフォルトの名無しさん
07/02/07 10:09:59
>>99
何が言いたい？
102:デフォルトの名無しさん
07/02/07 11:52:42
> 普及し始めたということか？
知名度は上がってきてる。
ただ実際の使用はまだ限定的だねえ。
予算握ってるオッサン連中説得するのが大変だもん。
ていうか絶望的に不可能な場合が多数。
103:デフォルトの名無しさん
07/02/07 11:56:38
現実は厳しいのねん。
104:デフォルトの名無しさん
07/02/07 12:00:15
ORMやWebフレームワークは、その必要性が明確なんだよな。
「使わなければぐちゃぐちゃになる。使わなくても結局スクラッチすることになる。」
DIコンテナは「使わなくても出来るけど」が説明についてくる。
105:デフォルトの名無しさん
07/02/07 12:02:45
AOPによる宣言的トランザクションあたりは説得材料にならないか？
バグが減る・使わないとぐちゃぐちゃになるとかなんとか言って。
106:デフォルトの名無しさん
07/02/07 12:07:36
短期的に見れば、宣言的トランザクションはDI&AOP導入の大きな魅力になるからね。
ただ、それを頭の固いオヤジに理解させるのが一苦労ｗ
107:デフォルトの名無しさん
07/02/07 12:45:19
宣言トランザクションを理解させる段で諦める
108:デフォルトの名無しさん
07/02/07 12:50:01
>AOPによる宣言的トランザクションあたりは説得材料にならないか？
かな〜りなる気がする。
結局は以下を責任を持って実施できるかどうかじゃない？
・Spring導入に関するメリットを上司に説明できる。
・Springについては実開発で使えるくらい検証済みである(もちろんテスト工程も含む)。
・メンバへの教育も問題ない。
・Spring導入したことによる問題は自分が全責任を負うと公言できる。
これができないなら上司を説得するのは難しいだろうし、
Spring導入しても失敗するだけかも？
上記をやっても納得してもらえないなら、上司の頭が余程固いか自分がまだ信頼されるようなエンジニアではないのどちらかでは？
109:デフォルトの名無しさん
07/02/07 14:09:30
「new がないんだが？」
「setter 書いとけばコンテナが勝手にやってくれますよ。」
「でも new ないんだよ？」
「設定に従ってコンテナが勝手に探し出して set しますから。」
「でも設定面倒じゃね？」
「その分 new が減ってますから。」
「でも面倒だよね？」
「その変わり設定変えるだけで実装を切り替えられますから。」
「実装なんて切り替える必要ないだろ？」 ←この辺りからおかしくなる
「単体テストの時にモック差し替えていろいろ試したりとか、
問題調査の時にデバッグ版に切り替えたりとか、結構便利ですよ。」
「モック差し替えって・・・リリース時と違う状態でテストすんのか？」 ←そもそもブラックボックステストを理解してない
「・・・？ そうですけど。」
「馬鹿なこと言っちゃいかんよ、君。リリースと同じじゃなきゃテストにならんだろ！」
「いや、だから単体テストだからインターフェースさえ守ってればそこは・・・」
「いかん、いかんぞ、これは。今までそんないい加減に仕事していたのか！」
「の入り口と出口さえ厳密に決まってれば、中身なんてどうでもいいじゃないですか。」 ←やや誤解される表現
「どうでもいいとはなんだ！そもそもプログラミングと言うものはだな云々」 ←大昔を語りだす
※ このやり取りはフィクションであり、実在の上司・オッサンとは一切関係がありません。
110:デフォルトの名無しさん
07/02/07 14:29:28
部下の発言が説得力ないねｗ
111:デフォルトの名無しさん
07/02/07 14:56:26
図解入りでプレゼン資料提示したり
実際に架空案件でも開発して工数比較したりしないと
新しいツールなんてそう簡単に導入に持ち込めないでしょ。
でもそんなことやってる時間は普通無い罠。
結局デカいベンダのそういうおもちゃで遊んでる部門からでも話が流れてくるのを松鹿内。
112:デフォルトの名無しさん
07/02/07 15:13:40
>新しいツールなんてそう簡単に導入に持ち込めないでしょ。
そういうこと。
個人の力でできる人もいるだろうけど、難しい人もいるだろうね。
いずれにせよ、行動しなければ松鹿内。
113:デフォルトの名無しさん
07/02/07 15:29:22
ソフトウェアアーキテクチャを握っていない立場なら確かに松鹿内なｗ
そうでないならプロジェクトにSpringを新規導入できるだけのアーキテクトがいるかどうかだろ？
そんな人材がいなければ残念ってこと。
Seasar導入できるアーキテクトでもよくてよｗ
114:デフォルトの名無しさん
07/02/07 15:32:30
>でもそんなことやってる時間は普通無い罠。
>>111の会社ではアーキテクトはあまり評価されてないんだろうなｗｗｗ
115:デフォルトの名無しさん
07/02/07 16:01:29
なんで個人攻撃しようとするかなｗ
アーキテクトなんて職種は中小ベンダじゃほとんどいないでしょ。
俺はツール売り込んでる方の人間だから悩みはいっしょなのよね。
最近は昔みたいに
「生産性上げたら人月取れなくなるからツールなどいらん」
っていう豪快な管理者がめっきりいなくなったけどね。
116:デフォルトの名無しさん
07/02/07 16:36:59
アーキテクトなんて肩書きがあるケースは少ないだろうけど、中小企業でもプロジェクトでアークテクチャを担当しなければならいケースは少なくはないでしょ。
そういった立場の奴がプライベートな時間を使ってまで新規ツールの検証をするかどうか。
現状がかなりひどいか、新し好きものの変態じゃなければしないだろうな。
どうぜ評価は変わらないのだろうから。
117:デフォルトの名無しさん
07/02/07 17:09:54
名刺の肩書きで「アーキテクト」は見たことないなｗ
中小だと、アーキテクチャは天の声で指定されることが多いんだよ。
俺「XXXフレームワーク使って良いですか？」
発注元「実績がないので駄目です。」
118:デフォルトの名無しさん
07/02/07 18:27:47
>>116
> プライベートな時間を使ってまで新規ツールの検証
この時点で「アーキテクチャを担当」とは言えないのでは。
>>117の言うとおり、「天の声」で決まるケースがほとんどでしょう。
で、それは>>111の言う「遊んでる部門」に決定権があったりすると。
119:デフォルトの名無しさん
07/02/08 00:26:39
Spring導入するくらいで、いちいち聞かなきゃよくね？
120:デフォルトの名無しさん
07/02/08 09:32:10
勇者あらわる。
121:デフォルトの名無しさん
07/02/08 10:48:15
言い訳なんて何でもよくね？
「DIコンテナ入れない場合UnitTest出来ないですけど、それでいいですか？」
「APサーバのリファレンスに、Springを使用しろと書いてありますが。」
122:デフォルトの名無しさん
07/02/08 11:41:45
豪胆だなｗ
俺は嘘ついてまで導入させようとする勇気はないなぁ…
UTできないわけでも、APサーバが求めてるわけでもないってことが、もし後でばれたら…
123:デフォルトの名無しさん
07/02/08 17:12:01
そんなことチマチマ調べる管理職にお目にかかったことがないので、
ばれない
顧客のためになることだから、独断でガンガン行くべし
124:デフォルトの名無しさん
07/02/08 21:41:17
StrutsやHibernateとかの必須ライブラリとか言っておけばいいんじゃね？ｗ
125:デフォルトの名無しさん
07/02/09 00:13:50
>>122
まるっきりの嘘でもないでしょ。
というか、良かれと思ってやってるのに「勇気がない」って。。
126:デフォルトの名無しさん
07/02/09 00:15:30
もし失敗したら責任取らないといけないからだろ。
127:デフォルトの名無しさん
07/02/09 00:24:22
大抵のことはよかれと思って始められるが、その結果が常によいとは限らない。
128:デフォルトの名無しさん
07/02/09 00:44:27
っていうかさ、必要なモノを作らずに利用するってだけじゃん。
そういうアプローチで説得していけばいいんじゃね？
129:デフォルトの名無しさん
07/02/09 01:31:41
自分以外にもSpringを使える奴がいないと難しいかもナ。
あとあと改修とか保守とか考えると
130:デフォルトの名無しさん
07/02/09 01:59:44
基本的な機能つかうだけならものすごく簡単だとおもうんだけど。。
struts-configを読めて、bean定義の読み方わからない奴なんていないとおもうぞ。
131:デフォルトの名無しさん
07/02/09 02:13:58
>>129
それはその時に担当が勉強・・・って考え方は駄目かなｗ
132:デフォルトの名無しさん
07/02/09 08:11:51
>>131
駄目に決まってんだろ。突然トラブったらどうすんだよ。「勉強中なので対応できません」？
133:デフォルトの名無しさん
07/02/09 10:36:46
DIコンテナ部分だけ使ってる限りにおいては
勉強とか一瞬だと思うんだが。
134:デフォルトの名無しさん
07/02/09 10:50:00
>>125
＞「DIコンテナ入れない場合UnitTest出来ないですけど、それでいいですか？」
POJOだけで作ってれば、DIじゃなくてもUTは出来る。
モック作るのが面倒かもしれんが、出来ないわけじゃない。
＞「APサーバのリファレンスに、Springを使用しろと書いてありますが。」
俺は、リファレンスに「Spring使わなければ駄目」って書かれてるAPサーバを知らない。
Spring必須のSPサーバってのがあるの？
135:134orz
07/02/09 10:50:58
×Spring必須のSPサーバってのがあるの？
○Spring必須のAPサーバってのがあるの？
136:デフォルトの名無しさん
07/02/09 11:16:53
>>134
そういうことじゃなくて、
よくわかってない連中をそうやって言いくるめちまえ！ってことだろ。
真に受けるなよ。コミュニケーション能力のない奴だな。
137:デフォルトの名無しさん
07/02/09 11:54:16
まるっきり嘘じゃねぇか。
138:デフォルトの名無しさん
07/02/09 12:10:29
でも少しずつ広まりつつあるのは感じられるなあ。
DIなんて知らね
↓
DIの良さがわからね ← 半年前のこのスレでこんな奴がいた
↓
導入しようとしたら拒否られた ← 今ここ
↓
普通使ってるでしょ
↓
DI古すぎ。これからはアレの時代。
139:デフォルトの名無しさん
07/02/09 13:48:07
確かに。
大手SIerなんかは、Springベースの自社フレームワーク作ってるところ多いんじゃないかな。
ただ、現場の部課長に「フリー（オープンソース）のソフトなんか信用ならねぇ」とか拒否ってるのがいたりする。
140:デフォルトの名無しさん
07/02/09 13:59:01
>>139
一昔前にStrutsがはやり始めたとき、大手SIerにはOSSを忌避して、
自社独自のWebフレームワークをスクラッチしたところが少なくなかったよな〜
結局、フレームワークのバージョンアップコストと、
（極端な例え話だが）アウトソーシングするたびに教育が必要になるから、
Strutsベースで作り直すトコが出始めた。
だが、途中からでもOSSベースに乗り換えたトコはましだった。
いまだに自社フレームワーク使ってるところは、バージョンアップがままならないばかりか、
好き勝手に拡張されたフレームワークを使ってる。
だから別の部門に移ると、同じフレームワークと思えないほど変形してることすらある。
もう、そろそろ学習しろよと思うんだよな。
141:デフォルトの名無しさん
07/02/09 14:08:01
>>136みたいなやつがリーダーのプロジェクトって
ほとんど火を吹くんだよな。最新技術オタク。
142:デフォルトの名無しさん
07/02/09 14:24:07
>>141
そういう話をしてるんじゃないだろ。話がずれてる。
むしろおまえみたいに叩くのが目的で
ずれた議論をしたがる奴がいるほうが迷惑。
火は吹くんじゃなくて、噴くんだよw
143:デフォルトの名無しさん
07/02/09 14:28:35
>まるっきりの嘘でもないでしょ。
がなければ、話の筋は通ったんだがな。
これでは知識不足にしか思えん。
144:デフォルトの名無しさん
07/02/09 14:28:38
要するに、冗談も通じずに叩きネタばかりつっこむ奴がいるとやっかいということか。
145:デフォルトの名無しさん
07/02/09 14:30:51
>>143
ホントだｗ
嘘も方便ってことなのに。
だから>>141みたいな粘着が沸いてきちゃうんだよｗ
146:デフォルトの名無しさん
07/02/09 15:12:14
自分は中小企業をいくつか経験しているが、
ここ読んでいると自分はかなり恵まれているのだと実感したｗ
給料はそんなに高くないけど、責任を負う気持ちがあればチャレンジできる環境に多謝。
147:デフォルトの名無しさん
07/02/09 15:13:36
>>146
ちょっとｳﾗﾔﾏｼｽ。
まぁ、何の責任も無しに高給貰うほうがうれしいけどなｗｗｗ
148:デフォルトの名無しさん
07/02/09 15:21:06
>何の責任も無しに高給貰うほうがうれしいけどな
確かにｗ
>ちょっとｳﾗﾔﾏｼｽ。
弊社に是非。
今ならStruts, Spring2, JPAプロジェクトにすぐにアサインですよｗ
149:デフォルトの名無しさん
07/02/09 16:53:54
ごめん。今更Strutsなんて使いたくないんだ。
と、>>147でない俺が答えてみる。
150:デフォルトの名無しさん
07/02/09 17:07:07
では、Web framework 何使ってるの？
151:デフォルトの名無しさん
07/02/09 17:13:03
んー、Strutsは要件次第ではまだいけると思うんだ。
なによりも成熟してるし実績が無数にある。
JSF・リッチ・テンプレ系は強力だし、
いつでも使えるといいんだけど人的リソースの確保がなかなか…
152:デフォルトの名無しさん
07/02/09 17:15:29
>>151
同意
153:デフォルトの名無しさん
07/02/09 17:20:00
>>149だけど、Wicket使ってるよ。
設定ファイルを書かなくていいからもう他のは使えない体だ・・・
でも、結局Spring使ってるからXMLは書くんだけどなｗ
154:デフォルトの名無しさん
07/02/09 18:25:21
最近よく耳にするWicketかあ。
プロジェクトの規模は何人くらい？
数名とか小規模なんだよね？
155:デフォルトの名無しさん
07/02/09 21:17:52
Viewは使いどころにもよると思うが、今はStrutsだろな。
JSFは開発する側はラクだが、使う側からしたら微妙に思う。
Wicketはまだ開発者集めれる段階ではない。
>「フリー（オープンソース）のソフトなんか信用ならねぇ」
こういうの言われるといつも思うんだが、自社製ソフトも信用ならねぇ。バグだらけ。
とつくづく思う。
新規に作ったほうが工数がかかり、多くのバグを仕込むことになることにやつらは気付かないのか？
156:デフォルトの名無しさん
07/02/09 22:49:45
作るやつと作らせるやつの感覚が違うのが問題
自分が作るつもりで考えないと生産性なんて
得られないおー
157:デフォルトの名無しさん
07/02/09 23:55:57
バグの無いプロダクトなんて無いからな。
管理職の考えてるのは「落とし前のつけ方」なんだよね。
フリーでいいソフトありますー採用しましたー失敗しましたー
ってなったときに部下に責任なすりつけて逃げていいんなら採用できるけど。
158:デフォルトの名無しさん
07/02/10 00:25:40
そういっていまだにＣ言語やってそう
159:デフォルトの名無しさん
07/02/10 07:32:34
>>158
Ｃ言語って何？
おじさん世代？
160:デフォルトの名無しさん
07/02/10 11:14:20
知ったかぶったガキンチョかｗ
161:デフォルトの名無しさん
07/02/10 11:39:34
会社じゃポジションがないおっさんかｗｗｗ
162:デフォルトの名無しさん
07/02/10 15:39:26
いまさらながら>>125について解説しておくと、
[UnitTestの件]
UnitTestするにはPOJOで実装する必要がある。
↓
DIなしでPOJOをアセンブルするにはファクトリが必要
↓
ファクトリなんか書くはずない。めんどくさすぎ。
↓
newしまくりで実装
↓
最下層のクラスがコンテナとくっつく
↓
テスト不能
[APサーバの件]
WebLogicのトランザクションを使用
↓
WebLogicはネストトランザクションを未サポート
↓
「WebLogic ネストトランザクション」で検索
↓
dev2dev内のページがヒット
↓
dev2dev「Springのトランザクションマネージャで出来るよ。」
163:デフォルトの名無しさん
07/02/10 15:57:58
>>162
すれが活発なのはいいけど、ばかがふえた?
UnitTestするには多くの場合、POJOが望ましいが
POJOである必要はない。
何らかの手段で依存オブジェクトを交換できるように
なっていないPOJOだとテストはやりづらい。
ネストしたトランザクションなんかほとんど使わないよ。
必要だと思っても処理を見直せば何とかなる。
164:デフォルトの名無しさん
07/02/10 16:03:51
>>162
んなことわかってるけど、上司にどう言い訳するかってはなし
165:164
07/02/10 16:04:54
ごめん
>>162じゃなくて
>>163
166:デフォルトの名無しさん
07/02/10 17:01:19
素朴に疑問なんだけど、Spring使って開発楽になった人っている？
キレイになったとか、テスト用意だったとかじゃなく、あくまで結果楽になった人。
167:デフォルトの名無しさん
07/02/10 17:01:50
ていしえ：テスト容易
168:デフォルトの名無しさん
07/02/10 17:18:54
まだまだチーム全体で経験不足なので、楽になったとは言えない。ただ、可読性とかはあがったと思う。
トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
トランザクションの設定はわかるやつが統率して更新したほうがいいよ。
新しいこととか流行の物を使わせるとモチベーションが上がるやつもいる。
そういうやつはそこそこ使えるからいいけど、なんで新しいものおぼえなｋｙ（ｒｙってやつには不評だね。
前者 -> メリットとか関係なく新しいものがつかればいい
後者 -> メリットとか関係なく勉強するのがやだ
俺も年取ると後者になるんだろうなぁ。今はちょうど中間にいるってかんじ。
Ajax系のライブラリも乱立するし、SpringMVCだとか余計なのもでてくるし、次から次へと新しいのがでてくることに飽きたというかうんざりというか。
169:デフォルトの名無しさん
07/02/10 17:33:04
.NETにようこそ
170:デフォルトの名無しさん
07/02/10 18:02:24
>>168
Seasarにいらっしゃ〜い（三枝風）
171:デフォルトの名無しさん
07/02/10 18:06:50
>>168 に近い感覚。
172:デフォルトの名無しさん
07/02/10 18:07:22
工エェェェ（´д｀）ェェェエ工
173:デフォルトの名無しさん
07/02/10 19:05:52
昨年末に買ったSpring2.0入門やっと読破したｗ
いいねこの本
174:デフォルトの名無しさん
07/02/10 19:09:12
>>173
だんな乙
なんて言わないですよ
だってここはSeasarスレではないのですからｗ
175:166
07/02/10 19:25:44
>>168
なるほどねぇ。
いやぁ、私もSpring使った開発に足つっこんじゃってて。
正直、使う前に予測してた弊害にモロにやられてるから。
ノウハウが足りないってのもあるけろ。
改めて思うのは、DI自体にそこまで価値あるのかしらっていう。
>>トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
激しく同意だけど、これってAOP的要素なんだよね。
オブジェクトの疎結合によるメリットはまだイマイチ感じれないなぁ。
176:デフォルトの名無しさん
07/02/10 20:21:51
ただ導入すればメリットをえられると思っている単細胞には、ﾅﾆを使ってもメリットは得られないだろうねぇ
そういうヤツは何も考えずにゴリゴリ書いてガッツリ結合したプログラムを、またゴリゴリメンテナンスするのが
日常だから、考えてプログラム作ること自体がデメリットになっちゃうんだよね
そういう奴らが主導権を握ったプロジェクトだと、こっちまで巻き添えくうから困る
177:デフォルトの名無しさん
07/02/10 20:23:19
>>175
使う前に予測してた弊害って何？
178:デフォルトの名無しさん
07/02/10 20:38:13
疎結合そのものにメリット感じられないなら
DI使ったプロジェクトには来ないで欲しいよ・・
179:デフォルトの名無しさん
07/02/10 20:39:20
って言うか、オブジェクト指向言語使った開発全般に（ｒｙ
180:デフォルトの名無しさん
07/02/10 20:41:44
>>175
まずは依存関係逆転の原則でググれ。
181:デフォルトの名無しさん
07/02/10 20:43:54
>>175
>> 激しく同意だけど、これってAOP的要素なんだよね。
そうなんだよね。AOPを使ってトランザクション制御を書かなくていいんだ！ってのは理解してもらえるんだよ。
try,catch,finally close()とかはみんな煩わしいと思ってるし。
問題はDIの部分なんだよね。
setterインジェクションでDaoとか渡さなくても自分でnewすればいいじゃんてなる。
やれInterface書くのめんどくさくないの？とかsetter書くのがめんどいだのいうわけよ。
Daoなんか1個実装すれば終わりだし、ORMが途中で変わるわけないだろとか。
うちの人間は極端にリソースが増えるのを嫌がるからなぁｗ わからなくもないんだけどね。
182:デフォルトの名無しさん
07/02/10 20:45:07
Interface書くのがめんどくさいとかいうヤツは
コボルでもやってりゃいいんだよ
183:デフォルトの名無しさん
07/02/10 20:46:26
>>181
そういう奴らの方がよっぽどめんどくさい事を一生懸命やっているっていう事実を
当人達が気が付いていないのが笑える
184:デフォルトの名無しさん
07/02/10 20:46:53
>>181
自分でnewして良いかどうか、
JUnitでテストケースかいてみりゃ一発でわかるだろ。
185:デフォルトの名無しさん
07/02/10 20:53:15
PGレベルのやつはspring意識しなくて良いから「勉強ダルい」なんてことはないと思われ。
上でもあるが、トランザクションやログなど、アプリケーションの動作をプログラムから排除することで、
オブジェクト指向設計したメソッド呼び出しのみに注力することができるので見通しが良くなる。
186:デフォルトの名無しさん
07/02/10 21:07:56
蜜結合大好きならスクリプト言語の世界へどうぞ。
187:デフォルトの名無しさん
07/02/10 21:44:14
宣言的トランザクションを利用する場合も
TransactionManager, DataSourceなどをBean定義ファイルで設定してるよね？
あれってDIだよね？ｗ
これはkiddingだけど、
DIの価値がよくわからなければnewすることからはじめてもいいのでは？
それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
一気にモジュールを作成してUnit Testをせずに
結合して単体テストするという文化ではnewでいけるのかも？
188:デフォルトの名無しさん
07/02/10 22:21:29
飲み過ぎだろ・・・常識的に考えてｗｗｗ
189:デフォルトの名無しさん
07/02/10 22:22:41
誤爆しましたｗ
190:デフォルトの名無しさん
07/02/10 23:37:41
あなたの常識って何ですか？東国原
191:デフォルトの名無しさん
07/02/10 23:53:40
＞DIの価値がよくわからなければnewすることからはじめてもいいのでは？
＞それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
単に、問題の存在に気づかないだけだとおもう。
192:デフォルトの名無しさん
07/02/11 00:07:00
かもなｗ
193:デフォルトの名無しさん
07/02/11 00:08:26
>>191
問題って何？
194:デフォルトの名無しさん
07/02/11 00:20:52
理解力不足と、そう思われるのがイヤで
難癖付けるヤツ
195:デフォルトの名無しさん
07/02/11 00:22:42
自分自身のこと？ｗ
196:デフォルトの名無しさん
07/02/11 00:26:03
あと、空気読めないガキ
197:デフォルトの名無しさん
07/02/11 00:26:37
なんか現状に不満みたいだねｗ
198:デフォルトの名無しさん
07/02/11 01:54:09
>>191-197
これがSpringを導入するかしないかで繰り広げられる会話か。
199:166
07/02/11 02:53:16
うあ。大反響だ。
この中で実際開発してる人っているんですよね。
理想論は理解できるけど、どれだけ『体現』してるのかな。
それも個人ではなくプロジェクトとしてね。
ISID内じゃ前からSeasar2不評だよ。
タ ブ ー だ け ど 。
200:デフォルトの名無しさん
07/02/11 03:03:48
>>199
どうでもいいけど、>>175で書いてた、使う前に予測してた弊害って何よ？ｗｗｗ
201:デフォルトの名無しさん
07/02/11 03:04:13
疎結合否定した時点で、真性かネタの二択だよ俺的には。
202:デフォルトの名無しさん
07/02/11 03:05:27
今時DIすらわからんJava開発者は、さっさとRubyあたりに移った方が身のためだと思う
多分Rubyもわからなくて廃業するだろうけどな
203:デフォルトの名無しさん
07/02/11 04:05:38
実際、楽になったといえるような香具師はいないだろうねぇ
Strutsがそうであるように、結局使いこなせなくて大変な思いだけ
が記憶に残ってしまうんだよね
とSpring使ったことないオレがイって見る
204:デフォルトの名無しさん
07/02/11 04:30:32
だからさっさとスクリプト言語でも何でも、簡単な方にいけばいいのに
DI以前のクソソースしか書けないJava開発者が、現場では一番使えない
205:デフォルトの名無しさん
07/02/11 05:27:13
ｸﾝｸﾝ
ﾑﾑｯ！！
ｺ・・・ｺﾚﾊ！！！
206:デフォルトの名無しさん
07/02/11 08:49:34
>>203
とことん楽になったよ。
あとStrutsと比較したらただのアホだから、
人前では決して口にしないように。
DIは(AOPも)パラダイムなんだから。
構造化言語、オブジェクト指向、とかと同列。
進化の方向は「関心ごとを極小にして実装に集中する」で一致してる。
207:デフォルトの名無しさん
07/02/11 10:41:51
>>203
Javaも使いこなせてないみたいだな
208:デフォルトの名無しさん
07/02/11 10:44:20
>>204
人の上に立てないやつ
209:デフォルトの名無しさん
07/02/11 10:47:07
>>199
>ISID内じゃ前からSeasar2不評だよ。
これほんと？(ぁゃιぃ)
不評な理由はなに？
210:デフォルトの名無しさん
07/02/11 11:01:34
なんかさ、
ジャヴァ・スプリング・フレームワーク と
ネギ・スプリング・フィールド って
なんかにてね？
211:デフォルトの名無しさん
07/02/11 11:03:50
ネギ・スプリング・フィールドはおまえにそっくりだな
212:デフォルトの名無しさん
07/02/11 11:59:28
なんか暖冬のせいか、馬鹿がたくさん沸いてでてきてるな
213:デフォルトの名無しさん
07/02/11 12:00:39
>>206-207
そういう意味で比較したんじゃないからｗ
日本語も読めないようなヤツだと大して使いこなせてもいないんだろう
214:デフォルトの名無しさん
07/02/11 12:16:30
必死だなｗｗｗ
215:デフォルトの名無しさん
07/02/11 12:43:38
ネタだと思いたい。
216:デフォルトの名無しさん
07/02/11 12:44:51
>>212
そりゃ、春のフレームワークだからなｗ。 Spring = 春
217:デフォルトの名無しさん
07/02/11 12:53:49
バネもってこい！
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4153日前に更新/215 KB
担当:undef