国産DIコンテナSeaserとくーす その2

1 名前：デフォルトの名無しさん [04/10/27 22:54:13] 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。 ってどうよ？みんなもう使ってるの？ 最近、気になるのでスレ立てました。 使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。 あと、開発プロセス「くーす」の話題もこちらでどうぞ。 本家 seasar.org www.seasar.org/ Seasar Projectグループ seasarproject.g.hatena.ne.jp/ ひがやすをのここだけの話 d.hatena.ne.jp/higayasuo/ 関連スレ(なのか?) Java Spring Frameworkを語るスレ pc5.2ch.net/test/read.cgi/tech/1077465099/ 754 名前：デフォルトの名無しさん mailto:sage [04/11/29 01:25:32] 理由はないが、気持ち悪いね。 755 名前：デフォルトの名無しさん mailto:sage [04/11/29 03:22:08] くーす3連発。 ttp://d.hatena.ne.jp/akon/20041127#p1 ttp://d.hatena.ne.jp/akon/20041127#p2 ttp://d.hatena.ne.jp/akon/20041128#p1 思わせぶりで煙に巻くテクニックは年の功。 756 名前：デフォルトの名無しさん mailto:sage [04/11/29 07:22:23] >>755 思わせぶり≠自分が理解できない 757 名前：デフォルトの名無しさん mailto:sage [04/11/29 20:33:49] 「思わせぶり」って忘れたころにやってくるっていう意味じゃないの？ ほら、3年ぶりとか、久しぶりとか、そういう「ぶり」 758 名前：デフォルトの名無しさん mailto:sage [04/11/30 02:47:20] 面白い！ 759 名前：デフォルトの名無しさん mailto:sage [04/11/30 13:53:04] S2JSFはまだかいな。 他と比べて「まだ出来てないこと」以外は最高だと思うので 早く欲しいですよ。 760 名前：デフォルトの名無しさん [04/11/30 18:56:44] S2Daoで配列を永続化しようとしたらだめだったorz ●DBのDDL CREATE TABLE member (...., area_id SMALLINT[], ....); ●永続クラスとそのDao public class Member { public static final String TABLE = "member"; public static final String areaId_COLUMN = "area_id"; private int[] areaId; /* * 以下アクセサー */ } public interface MemberDao { public static final Class BEAN = Member.class; public void insert(Member member); } 761 名前：デフォルトの名無しさん [04/11/30 18:57:24] 続き ●dicon <?xml version="1.0" encoding="euc-jp"?> <!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container//EN" "www.seasar.org/dtd/components.dtd"> <components> <include path="dao.dicon"/> <component class="MemberDao" > <aspect>dao.interceptor</aspect> </component> </components> って感じだとINSERT文のarea_idの値にareaId.hashCode()の値('[I@8c5488')が入ってだめだった。 762 名前：760 mailto:sage [04/11/30 19:30:08] JDBCドライバのせいだった...orz ごめんよS2Dao.... 763 名前：S2Dao mailto:sage [04/11/30 23:20:00] >>762 まあ、気にするな。 764 名前：デフォルトの名無しさん mailto:sage [04/12/01 00:12:24] ttp://d.hatena.ne.jp/khi/20041129 ttp://www.kakutani.com/20041129.html#p01 ttp://lists.sourceforge.jp/mailman/archives/seasar-user/2004-November/001244.html コミュニティ粘着の皆様、本格的な出番ですよ。 765 名前：デフォルトの名無しさん mailto:sage [04/12/01 00:24:31] はぶさんの発言力をひがさんにインジェクションできれば問題なしなんだろうけど。 ひがさんの技術力をはぶさんにインジェクションしたら、たちが悪そう。 766 名前：デフォルトの名無しさん mailto:sage [04/12/01 00:45:34] >>763 オメエ、いいやつだな。さすがS2Daoだ。 767 名前：デフォルトの名無しさん mailto:sage [04/12/01 01:12:52] >>764 takaiさんていい人そうだｗ 768 名前：デフォルトの名無しさん mailto:sage [04/12/01 02:01:43] >>767 S2NazoWebの人だしな。Groovyマンセー！ 769 名前：765 mailto:sage [04/12/02 02:18:25] えー、最強はぶっちを目指しましょうよ。 770 名前：デフォルトの名無しさん mailto:sage [04/12/02 02:20:27] 真面目にキャバクラとかすんのバカバカしいですよ。 771 名前：デフォルトの名無しさん mailto:sage [04/12/02 12:34:13] >>770 もれも同じ読み違いしたw 772 名前：デフォルトの名無しさん mailto:sage [04/12/02 21:21:25] S2StrutsのActionのPOJO化自分でやろうかと思ってたらキム氏がやるらしいな。 S2JSF待つ余裕もないし早くリリースして欲しいな。 とはいえ、自分でやろうと思ってたからわかるけど 結構面倒なんだよなあ。テストが．．． 773 名前：デフォルトの名無しさん mailto:sage [04/12/02 23:37:05] 失敗... orz 774 名前：デフォルトの名無しさん mailto:sage [04/12/03 00:44:06] servlet.jarが入ると気持ちが悪いのは、プレゼンテーション層がないアプリで プレゼンテーション層に依存してしまうからだろう。 階層化を意識している人は気持ち悪く思うのは当然だ。 775 名前：デフォルトの名無しさん mailto:sage [04/12/03 02:37:24] rt.jarの中に入ってるswingは気持ち悪くならないのかな 776 名前：リリース情報 mailto:sage [04/12/03 04:09:34] S2.1.3 リリース d.hatena.ne.jp/higayasuo/20041202#1101990683 777 名前：デフォルトの名無しさん mailto:sage [04/12/03 08:11:04] JDBC使わないアプリで以下略 778 名前：デフォルトの名無しさん mailto:sage [04/12/03 11:29:24] >>775 それはわざわざ後から入れなくてかまわないだろ。選択の自由がない。 それが気になるならJava2ME使いなされってことだし。 779 名前：デフォルトの名無しさん mailto:sage [04/12/03 12:24:04] ttp://d.hatena.ne.jp/masataka_k/20041201#p1 ttp://d.hatena.ne.jp/habuakihiro/20041203#1102003235 780 名前：デフォルトの名無しさん mailto:sage [04/12/03 16:28:03] 動くものが出てれば、少なくとも失敗ではない。 781 名前：デフォルトの名無しさん mailto:sage [04/12/03 16:30:08] Seasar3が出るなら、Seasar2は成功だし、Seasar4が出るならSeasar3は成功。 Seasar4が出ないということになれば、Seasar3は失敗。 次につながるかどうかだと思うな。 782 名前：デフォルトの名無しさん mailto:sage [04/12/03 17:49:08] 予言するけど、Seaserは全てからスルーされて終わりだと思うよ 783 名前：デフォルトの名無しさん mailto:sage [04/12/03 22:56:13] かわいそうなSeaser…でも漏れが応援してるのはSeasarだからいいや。 784 名前：デフォルトの名無しさん mailto:sage [04/12/04 00:29:01] 予言というか、seaserがスルーされていることには実績があるね 785 名前：デフォルトの名無しさん mailto:sage [04/12/04 00:41:34] おれいま仕事でSeasar2使ってるけど。 786 名前：デフォルトの名無しさん mailto:sage [04/12/04 02:35:33] >>780 > 動くものが出てれば、少なくとも失敗ではない。 ( ´,_ゝ｀)ﾌﾟｯ 787 名前：デフォルトの名無しさん mailto:sage [04/12/04 10:11:28] >785 おれも仕事で何本か書いてみた。全体の見通しがいい作りになる。 S2のルールさえ覚えれば、特別な知識がいらないってところがいい。 仕事の道具としては相当使える部類だと思う。 788 名前：デフォルトの名無しさん mailto:ｓage [04/12/04 11:56:36] いびつな変質を遂げたユーザーコミュニティーも こうした日本に特有な部分はユーザー会の活動にも見られる。 日本には「*ユーザー会」といったものが多数存在しており、世界に例を見ないほど発達している。 日本のなかでもさらに地方支部みたいなものが生まれるユーザー会もあるようだ 問題なのは、本流とかい離し、日本独自の動きをしてしまっていることである。 こうしたケースでは本流との開発グループとの関係は希薄であることも多く、全体として開発、 普及の促進が阻害されるケースことにもつながる。 *-jpといった感じで本流と離れてしまうことは、開発者から見ればよいことではない。 また、離れることで利権を得ようとする人たちも現れてくる。 かつてDebian Projectのリーダーとして活動していたブルース・ペレンスと話をした際にこうした状況について話したところ、 それはFake Open Sourcerだね（だから排除すべき）という結論に達した 789 名前：デフォルトの名無しさん mailto:sage [04/12/04 13:58:13] >>788 S2の英語圏コミュニティができたとしても、それはfakeだから排除すべきだな 790 名前：デフォルトの名無しさん mailto:sage [04/12/04 15:01:38] 日本人なんか、fakeニダ 791 名前：デフォルトの名無しさん mailto:sage [04/12/04 15:16:06] >>789 S2の2chコミュニティができたとしても、それはfakeだから排除すべきだな 792 名前：デフォルトの名無しさん mailto:sage [04/12/04 19:48:49] >>788 出典は書いておけよ 日本におけるOSSの幻想――OSS界のガラパゴス諸島、ニッポン www.itmedia.co.jp/enterprise/articles/0412/01/news009.html 793 名前：デフォルトの名無しさん mailto:sage [04/12/04 20:04:40] >>791 S2のNPOができたとしても、それはfakeだから排除すべきだな 794 名前：デフォルトの名無しさん mailto:sage [04/12/05 13:16:01] 本家から離れることで利権を得る状況がFakeだって事なんだから、 特に利権を得てない2chコミュニティは違うだろ。NPOはそもそも本家の話だし。 795 名前：デフォルトの名無しさん mailto:sage [04/12/05 14:58:24] Fakeな「日本〜ユーザー会」の例キボン 796 名前：デフォルトの名無しさん mailto:sage [04/12/05 14:58:30] そもそも2ch自体がfake 797 名前：デフォルトの名無しさん mailto:sage [04/12/05 15:00:04] >>795 ブルース・ペレンスが言ってるんだから本人に聞け 798 名前：デフォルトの名無しさん mailto:sage [04/12/05 15:11:50] >>797 むちゃゆうなよ 代わりに、「日本 ユーザー会」でGoogleに聞いておいた 12/5付 Googleの選ぶ日本〜ユーザー会 1) Samba 2) MySQL、 3) PHP 4) OpenOffice.org 5) PostgreSQL 6) KDE 7) UNIX 8) Apache 9) Zope 10) Python どれがFakeだ？ 799 名前：デフォルトの名無しさん mailto:sage [04/12/05 15:26:04] おもしろいから漏れもググってみた。オプソとは関係ないがこんなのもあるのな。 ttp://www.asahi-net.or.jp/~WT8Y-SGWR/jws.hp/index.html ttp://toughbook.jp/ ttp://www.infosta.or.jp/kagaku/index.html 何となく日本*ユーザ会って名前をつけたがる国民性なんじゃないかと感じたよ。 800 名前：デフォルトの名無しさん mailto:sage [04/12/05 15:33:37] 9) Zopeに一票 801 名前：デフォルトの名無しさん mailto:sage [04/12/05 18:35:47] >>798 1)と5)は本家に影響を与えているからFakeではない。 他のユーザ会は知らん。 802 名前：デフォルトの名無しさん mailto:sage [04/12/05 19:24:39] >>798 2)と8)は純粋に「ユーザー」会な希ガス。 他も日本語化とかi18nがらみでcoreな部分に携わってるひとはいないよね。 こういう状況がfakeだといっているのかな。 なんかｽﾚ違いかも。 803 名前：デフォルトの名無しさん mailto:sage [04/12/05 22:58:15] たしかにZopeはうさんくさいな。 あと、SambaもI18NでTAX食ってたぞ。 IPAだ。あまりしられてないことだが。 804 名前：デフォルトの名無しさん mailto:sage [04/12/05 23:22:41] それは税金の正しい使い方なので無問題。 805 名前：デフォルトの名無しさん [04/12/05 23:30:36] S2Strutsはスレッドセーフにできてなかったのか。 驚いた。 マルチプロセッサの環境での実務使用を考えていたのに、白紙に戻ってしまった。 S2JSFも初めはそのレベルなのかな。 WEBアプリでスレッドセーフじゃないってのは相当ヤバイ問題じゃない？ がっくりだ。。。orz まあ、俺は提供されるもの使う側で作るスキルも無いから、 作ってる人間の苦労がどの程度のものかわからないまま言いたいこと言ってるけど。 S2Strutsが改善されるとふんで突っ走る。。。わけにもいかねえしな。 シングルプロセッサ環境での使用だったら突っ走ってもよかったんだけどなあ。 あ〜頭痛ぇ。どうしよう（泣） 冒険しようとした自分が悪いんだけどorz しかし、オープンソースの品質保証ってのは難しいね。 806 名前：デフォルトの名無しさん mailto:sage [04/12/05 23:46:16] >>805 ｱｲﾀﾀﾀ･･･ どこがどう問題なのか理解してる？ 807 名前：デフォルトの名無しさん mailto:sage [04/12/05 23:56:38] >>805 話の流れがよく分からないんだけど。 S2Strutsがスレッドセーフじゃないってのは、どの部分を指していっているのかよく分からない。 スレッドセーフの話で言えば、そもそもServlet自体自分で同期化しないとスレッドセーフじゃないし、 S2のコンポーネントもSingletonでロードする限り、ちゃんと同期化しないとスレッドセーフじゃないわけ だけど、そういう話じゃないんだよね？ 808 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:02:48] マルチプロセッサとスレッドセーフ性は直接関係ないだろ。 Double Checked Lockingとかでビミョーに関係あったりするけど。 809 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:03:50] ttp://d.hatena.ne.jp/higayasuo/20041205#1102211983 はぶ君はハゲヅラかぶってチチロー役やりなさい。 810 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:05:53] >>807 ttp://d.hatena.ne.jp/khi/20041205 ↑嫁 811 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:09:40] よくわかんないけど、 この二つの日記に書いてあることのことかな？ d.hatena.ne.jp/khi/ d.hatena.ne.jp/skimura/searchdiary?word=%2a%5bSeasar%5d 勉強中の俺には何言ってるかよく分からないんだけど。 つーか、フレームワークってその辺も特に意識しなくてもちゃんとできるもんじゃないの？ 812 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:27:32] おれはS2 + S2Dao + Struts環境で仕事してるが、S2Strutsは採用せずにAction内で getComponent()してる。ActionはView層にしてるんだが、View層の人にまでDIの仕組みを 説明するのがどうもな、と思っただけなんだけど、結果的には良かったってことか。 813 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:30:16] > ttp://d.hatena.ne.jp/khi/20041205 なんつーか、お粗末の一言だな。 マルチスレッドでアクセスされるオブジェクトプール的なものによくある 典型的なバグパターンじゃねえか。 こんな問題が今の今まで放置されてたのかよ。 まあ、こういう問題でパフォーマンスとスレッドセーフを両立させるのは 確かに難しいがね。 J2SE 5.0が使えるんなら、java.util.concurrent.ConcurrentHashMapの putIfAbsent()メソッドとかでかなり楽が出来るんだが。 814 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:43:04] >>813 > J2SE 5.0が使えるんなら、java.util.concurrent.ConcurrentHashMapの > putIfAbsent()メソッドとかでかなり楽が出来るんだが。 元ネタのDoug Leaのutil.concurrentで代用とか。 815 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:47:42] ソースの前に「............................................」が続くのには意味があるの？ 816 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:50:05] S2Strutsのスレッドセーフ対応早速リリースしたね。 そりゃそうだよね。 インパクトでかすぎだもん。 817 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:54:15] >>815 動いてるの確認するだけでしょ 818 名前：デフォルトの名無しさん mailto:sage [04/12/06 00:54:34] プロセスがドタバタしたけどオプソの良さがでたんじゃないのかな〜。 819 名前：デフォルトの名無しさん mailto:sage [04/12/06 01:09:36] >>814 > > J2SE 5.0が使えるんなら、java.util.concurrent.ConcurrentHashMapの > > putIfAbsent()メソッドとかでかなり楽が出来るんだが。 > > 元ネタのDoug Leaのutil.concurrentで代用とか。 いや、util.concurrentのConcurrentHashMapやConcurrentReaderHashMapには putIfAbsent()のようなメソッドがないのよ。 だから、痒いところに手が届かないことがよくあるんだよね。 820 名前：デフォルトの名無しさん mailto:sage [04/12/06 07:05:19] で、新しいのでちゃんと直ってるの？ 821 名前：デフォルトの名無しさん mailto:sage [04/12/06 07:51:22] >>820 マルチプロセッサ環境が無いから俺には確認できん。 つい最近まではあったんだけど。。。 誰かﾚﾎﾟよろ。 khi氏の書き込み待ちになってしまうのか？ 彼は書いてる文面はむかつくが（性格も悪いんだろうけど）、 指摘してるポイントは正しいからね。 822 名前：デフォルトの名無しさん mailto:sage [04/12/06 11:22:00] >>821 だから、マルチプロセッサとスレッドセーフと、どんな関係があるのかと。 823 名前：デフォルトの名無しさん mailto:sage [04/12/06 12:11:53] MP構成でなければなかなか再現しないので実際に修正されたという確信がもてない、という関係 まあMPで試して大丈夫ならOKというものでもないんだけど。 論理的な正しさをソースコードで検証しないとどうしようもない。 824 名前：デフォルトの名無しさん mailto:sage [04/12/06 22:26:35] khi氏という高スキル開発者がSeasarプロジェクトへ合流か。 順風過ぎて少し妬ましいね。 825 名前：デフォルトの名無しさん mailto:sage [04/12/06 23:03:12] >>824 あまりやる気あるようには見えないけどね。 まあ、脇から問題見つけて文句言う人間がいるだけで全然違うからね。 826 名前：デフォルトの名無しさん mailto:ｓage [04/12/06 23:35:18] >>808 マルチプロセッサだと、スレッドセーフまわりのバグに当たり易くなる。 827 名前：デフォルトの名無しさん mailto:sage [04/12/07 00:21:00] >>826 つか、シングルプロセッサだと当たりにくいよね。 昔、貧乏プロジェクトでテスト環境にマルチプロセッサの環境準備できなかったことがあて。 負荷テストで相当の多重度かけて数日動かして問題なかったのに、 マルチプロセッサの本番サーバでリリースしたら初日にいきなりAccessViolationしやがったし。 負荷テストの１／１０程度の同時アクセスしかなかったんだけど出やすいんだよね。 当然だけど。 自前のものならまだしも、下請けに作らせたものだったから、 大問題になっちゃったよ。 しかも、仕様変更だとかふざけた事言いやがって！ ああ、嫌なこと思い出したなぁ。 だからうちは下請けに仕事やらせるときはマルチプロセッサ環境での負荷検証してから納品させるようにした。 下請けにとってはやな客なんだろうなあ。 828 名前：813 mailto:sage [04/12/07 00:56:06] つーか、マルチプロセッサ以前の問題でしょ。 ttp://d.hatena.ne.jp/khi/20041201#c ↑ここら辺りの頓珍漢なやりとりを見りゃ、skimura氏が HashMapクラスのAPI仕様すら理解してなかったってのは明白だ。 > ttp://java.sun.com/j2se/1.4/ja/docs/ja/api/java/util/HashMap.html > この実装は同期化されません。複数のスレッドが同時にこのマップにアクセスし、 > それらのスレッドの少なくとも 1 つが構造的にマップを変更する場合には、 > 外部で同期をとる必要があります。構造的な変更とは、1 つ以上のマッピングを > 追加または削除するオペレーションのことです。 こんなの、ちょっと知識のある人がコードレビューすりゃ一発で 指摘されるもんなのに、今まで放置されてたってのは異常。 ……って思ってたら、 > なんていうか、「オープンソース」よりも「(ソースコードの付いてる) > フリーソフト」に近い雰囲気を感じないといえば嘘になります。 って記述を見て納得。 829 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:01:44] S2Daoを仕事で使おうとしてるんだけど、これ、EntityManagerが惜しい！ SQL自動生成とEntityManagerの両立ができたらいいんだけど、出来ないのかな。 というのは、QUERYアノテーションで基本的なメソッドについてはSQL自動生成させて おいて、それとは別にEntityManagerの findObjectを使いたいんだよね。 それができれば、もしDaoによいメソッドがなければ、findObjectにQUERY アノテーションと同じ文法でWHERE句を渡してやれば好きなようにデータを取得できる。 HibernateのHSQLみたいな使い方ができる でもEntityManagerを使うためにはAbstractDaoを拡張した実装クラスを作らないとい けない。そうするとインターフェースへの自動生成ができない（実装しないと コンパイルできないし）。自動生成はしたいけど、EntityManagerのfindメソッドも一部 では使いたい。EntityManagerだけ生成できるのかJavaDocもないから良くわからん。 あとふと思ったが、H2Daoは楽は楽だが、一方でO/R Mappingフレームワークが普通に 提供している「DBから読み込んだデータのキャッシング」は提供しないね。まあ機能的に あたりまえなんだろうけど、この辺りを自分で実装する場合の負荷を考えるとどうなんだ ろか。 830 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:07:36] H2Dao(・∀・)ｲｲ 831 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:25:44] >>830 おお、ほんとだ、H2Daoってなんだ.....orz 832 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:39:10] どこかにあるっていうから、探してみたら ひが氏とも同期の話してた ttp://seasarproject.g.hatena.ne.jp/skimura/20040723 khi氏も最初の対応の後は、気づかなかったから、今まで放置だったんじゃないか？ まあ、直ったからいいけど 833 名前：デフォルトの名無しさん mailto:sage [04/12/07 03:16:30] 完璧はないんだから、すぐに対応してくれたskimura氏は立派だと思うよ、オレは S2.1.4をすぐ出した、ひが氏もそうだし それを当たり前と思うかどうかは、藻前らに任せるが 責任感もってやってくれてると思うと多少は安心する 834 名前：デフォルトの名無しさん mailto:sage [04/12/07 03:32:11] >>831 Hummer2 Desert Access Optionの略ですね。 これで砂漠も川も縦横無尽。 835 名前：デフォルトの名無しさん mailto:sage [04/12/07 04:31:29] >>829 > あとふと思ったが、H2Daoは楽は楽だが、一方でO/R Mappingフレームワークが普通に > 提供している「DBから読み込んだデータのキャッシング」は提供しないね。まあ機能的に > あたりまえなんだろうけど、この辺りを自分で実装する場合の負荷を考えるとどうなんだ > ろか。 キャッシングが提供されてないのはDTOセントリックなアーキテクチャしか 眼中にないからだと思う。 ttp://d.hatena.ne.jp/higayasuo/20040808#1091933710 ttp://d.hatena.ne.jp/higayasuo/20041010#1097399686 ただ、こういうアーキテクチャがどういうドメインに適しているかについて 全く記述がない点が不信感を煽る。 836 名前：デフォルトの名無しさん mailto:sage [04/12/07 07:13:56] キャッシュは鬼門 837 名前：デフォルトの名無しさん mailto:sage [04/12/07 09:37:00] >>829 > findObjectにQUERY > アノテーションと同じ文法でWHERE句を渡してやれば好きなようにデータを取得できる。 > HibernateのHSQLみたいな使い方ができる できるってマニュアルに書いてあるぞ。 return getEntityManager().find("ename LIKE ?", "%" + ename + "%"); ってそうじゃないの。 838 名前：デフォルトの名無しさん [04/12/07 11:13:29] キャッシュのヒット率を上げてパフォーマンスを上げようと必死なデータベースエンジニアからしてみれば O/R Mapping なんてお笑いなんだろうな 839 名前：デフォルトの名無しさん mailto:sage [04/12/07 11:29:18] >>838 キャッシュは、近いところにあることにも意味があると思うが。 SQL自体を発行しないわけだから。 840 名前：デフォルトの名無しさん mailto:sage [04/12/07 12:10:05] ttp://d.hatena.ne.jp/higayasuo/20041207#1102379088 > これは、どのようなドメインにもいえます。 （　´_ゝ`） ﾌｰﾝ 841 名前：デフォルトの名無しさん mailto:sage [04/12/07 19:35:15] >>838 O/Rマッピングが字面として聞こえてきた頃の事、これでアノ鬱陶しい SQLともおさらばだぜ、ヒャッホーと浮かれたもんだ・・・・・・・・・ あの時、うちのDBエンジニアは俺をどういう目で見てたんだろう。 勿論、恐くて聞けないが＿|￣|○||| 842 名前：デフォルトの名無しさん [04/12/07 20:39:42] くーすにしてもSeasarにしても，利用者が増えれると， 楽してお金を得る人たちがいて，ネズミ講みたいできがのらん． 843 名前：デフォルトの名無しさん [04/12/07 20:50:28] >>842 関西の毒舌蛇男が参加してから嫌な臭いがしだしましたね。 844 名前：デフォルトの名無しさん mailto:sage [04/12/07 21:42:49] >>842 どういうこと？ 845 名前：デフォルトの名無しさん mailto:sage [04/12/07 22:31:19] >>843 誰のことー？？ 846 名前：デフォルトの名無しさん [04/12/07 22:31:30] >>844 くーすはシンプルで分かりやすいですが，業務分析は扱わず今まで通りです から，業務分析をくーすに繋げるあたりの教育やらコンサルやらのビジネス がなり立つでしょう．そのスペースを狙っている人達がみえかくれ． Seasar上の開発はプログラミングというよりコーダー的な仕事になり， それに関る人達の実装技術は育たないことになり，どんどん骨抜きになりそ う． というか，そもそも技術力がないソフトハウスをSeasarはターゲットユーザ にしてる感あり． 847 名前：デフォルトの名無しさん mailto:sage [04/12/07 22:51:35] >>846 そういう技術の無い若手を採りすぎた会社にいます。 人事部長が変って大学名だけで使えない奴とりまくってしまった。 現場は悲惨だよ。 848 名前：デフォルトの名無しさん mailto:sage [04/12/07 23:16:37] >>847 その日本語も、そういう現場でつちかってしまったのですね。 849 名前：デフォルトの名無しさん mailto:sage [04/12/07 23:33:49] >>846の句読点が気になる今日この頃。 850 名前：デフォルトの名無しさん mailto:ｓage [04/12/08 00:11:26] Seaserも大分信用無くしたなぁ…。 OOやらフレームワークやら語ってた割に、排他制御すらまともに出来ていなかったなんて…。 他にも似たようなバグ抱えてるんじゃないか？ 851 名前：デフォルトの名無しさん mailto:sage [04/12/08 00:34:46] ちょっと追ってみたけど、俺みたいなのでもわかるような 基本的なところで、ぼろぼろじゃん。 Web屋ってこういうの苦手だからしょうがないのかもしれないけど。 組み込みとかの経験ばっちりあるやつを開発に参加させないとダメなんちゃう？ 852 名前：デフォルトの名無しさん mailto:sage [04/12/08 01:17:57] O-Rマッピングツールは、SELECTには使わないのがベストプラクティス。 C/U/Dだけさくっと作って、参照クエリはじっくりSQLを記述する。 853 名前：デフォルトの名無しさん mailto:sage [04/12/08 01:52:32] >>852 SELECTも、とりあえずORマッピングで遅延取得しまくりで動かしておいて、あとから必要なところだけじっくりSQLを記述する方がベストプラクティスだと思う。 854 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:07:09] どんなにO/Rマッピングを使っても 沢山の可愛そうな厨房を先導しても SQLから離れては生きられないのよ！ 855 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:12:55] >>854 それは、ORマッピングをかいかぶりすぎ。 ORマッピングはSQLの結果をマッピングしてくれるだけで、複雑なSQLを簡単にしてくれるわけではない。 JOINに関してはある程度面倒をみてくれるが。 856 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:23:42] O/RマッピングでSQLが不要になると思った奴て結構多そうだよな。 ASP.NETでJ2EEが消えると思ってる奴とどちらが多いのか気になるところだ。 857 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:29:17] >>856 で、「結局SQLが必要だからORマッピングなんか役に立たない」と勘違いしてるやつもいるね。 858 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:30:11] そして、ここをORマッピングのスレと勘違いしてるやつもいるな。 859 名前：デフォルトの名無しさん mailto:sage [04/12/08 03:13:02] >>856 SQLTemplateがCayenneやHibernateにいまごろ実装されていく様子をみると、開発者自身もそう夢見てたんだろうね。 スレ違いか。 860 名前：デフォルトの名無しさん [04/12/08 06:34:41] d.hatena.ne.jp/higayasuo/20041207#1102379088 > Fowlerはプレゼンテーション層で必要とされる構造と > ドメインオブジェクトの間にミスマッチがあるときだけ、 > DTOを使えといっていますが、たいていの場合(よほど > 単純な画面でない限り)、ミスマッチはあるものです。 ここでいうミスマッチのイメージがわかないです。 どなたか、例を挙げていただけるとうれしいのですが。 861 名前：デフォルトの名無しさん mailto:sage [04/12/08 07:57:30] >>846 業務分析を楽に稼げる仕事だと思ってるあたりがおめでたい 862 名前：デフォルトの名無しさん [04/12/08 10:00:51] >>861 よく読んだら。業務分析できない人たちへの教育やコンサルであって、 業務分析を逃げて稼ぐといういみでは。 863 名前：デフォルトの名無しさん mailto:sage [04/12/08 10:12:04] なるほどね。>>862は例えばオブジェクト指向できない人たちへの教育やコンサルについてはどう思ってるの。 そもそも社外研修を受けさせないと駄目な会社は逝ってよしって言いたいのかな。 864 名前：862 mailto:sage [04/12/08 10:33:42] >>863 まず断っておくが俺は846ではないので。 「オブジェクト指向できない人たちへの教育やコンサルについては」 どうでも良いと思っている。好きにすればよいと。 846は「そのスペースを狙っている人達がみえかくれ．」と書いている が、そこを狙っている人達の怪しさを感じ、使う気がしないといって いると読んだまで。ひがさんは良いとして、おこぼれ頂戴と虎視眈々 と狙っている人達がなんとなくくーすもSeaserもだめにしそうな感じ が俺もする。 865 名前：デフォルトの名無しさん mailto:sage [04/12/08 12:02:59] >>846 > 業務分析は扱わず今まで通りですから こういうくーすの守備範囲に関する元ネタどこ? 866 名前：デフォルトの名無しさん mailto:sage [04/12/08 12:15:41] ほい marrow.strnet.com/wiki/pukiwiki.php?%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%BC%EA%CB%A1%A4%AF%A1%BC%A4%B9 867 名前：デフォルトの名無しさん mailto:sage [04/12/08 19:05:20] そもそもJavaでサーバサイド開発というのがネタだと漏れは思ってるんで。 もうSeaserも含めてJavaな方々はネタ作りに必死だなと常々思う。 868 名前：デフォルトの名無しさん mailto:ｓage [04/12/08 19:51:55] 禿堂。 サーバサイドはPHPだよな。 869 名前：デフォルトの名無しさん mailto:sage [04/12/08 20:35:05] >>868 いや、PHPはイカンと思うが。 でも、Javaよりはマシかもね。 870 名前：デフォルトの名無しさん mailto:sage [04/12/08 22:25:59] そこで.Netですよ。 871 名前：デフォルトの名無しさん mailto:sage [04/12/08 22:57:52] >>870 .NetはPHPより悪いJavaよりさらにタチが悪い気がするな。 立ち位置がどうしよもなく中途半端だし、ＭＳだしな。 872 名前：デフォルトの名無しさん mailto:sage [04/12/08 23:21:17] >>869 で、結論はPerlということか。 873 名前：デフォルトの名無しさん mailto:sage [04/12/08 23:25:07] ＞ＭＳだしな。 ん？Microsoft製だと何かまずいの？ Microsoftのソフト開発環境はとても使いやすいが。 874 名前：デフォルトの名無しさん mailto:sage [04/12/08 23:38:46] >>867 サーバサイド開発がネタ というか、某板某スレの、「Javaはネタ→禿どう」のコンビの人みたいだね。 875 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:05:40] >873 871じゃないが、 売れてるだけあっていいところは沢山あるんだけどさ。 寄らば大樹の陰が行き過ぎて変なところから圧力かかるのがＭＳのやなとこ。 成り行きでＭＳ”ばかり”やるようになると、ほかの良い物を導入しようとしたとき 「それＭＳじゃないからヤダ」って馬鹿を言う奴がいつのまにか周り中にいたりする。 せっかく自由社会にいるのに自分から独裁者に仕えるのは悪趣味だと思うぞ。 >Microsoftのソフト開発環境はとても使いやすいが。 「俺は」使いやすいとは思わんけど。どっちかというとボーランド派だから。 ようは個人の好み。 876 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:33:52] >>875 抽象的杉。説得力皆無。 877 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:42:31] >>876 開発環境ぐらい、フリーのものを使いたいぞな。 878 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:03:28] そこで vi + gcc + gdb ですよ。 879 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:14:44] お金払うものでも、自由であればいいよ。 金払って開発環境使い始めたが最後、あとはすべてそこの製品で賄わなければ元がとれない、というものじゃなければ。 880 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:41:39] >>874 いんや、Javaはなかなかよいと漏れは思ってるよ。 SwingはなかなかいいAPI構成だと思うし、Eclipseは神だしね。 ただ、ここで議論しているようなデータベースのインターフェースとなる 業務アプリを作るときには、Javaは向いてないなってなことだ。 881 名前：デフォルトの名無しさん mailto:sage [04/12/09 02:35:07] Swingのフォームとバリューオブジェクトのビーンが相互にやりとりできる仕組みさえできればいいと思うんだけどね。 882 名前：デフォルトの名無しさん mailto:sage [04/12/09 02:41:54] だれかが言ってたようにSeasarが失敗だとするならば、その理由は、ヒガさんに全体的なモデルがなかったことだと思う。 くーすはベストプラクティスの積み上げで、全体的なモデルを構築できてないように思える。 ベストプラクティスは既知の問題には対応できるけど、未知の問題に対応するにはモデルの構築が不可欠だから。 だれかが言ってた、Seasarが失敗だというのが誤りであれば、３行目を除いては正しいとはいえなくなるわけだが。 883 名前：デフォルトの名無しさん mailto:sage [04/12/09 03:09:05] くーすという方法論とSeasarというプロダクトは別なのだが 884 名前：デフォルトの名無しさん mailto:sage [04/12/09 04:41:55] くーすって方法論なの？ 885 名前：デフォルトの名無しさん mailto:sage [04/12/09 04:42:54] Seasarは方法論なしにやってるってこと？ 886 名前：デフォルトの名無しさん mailto:sage [04/12/09 11:27:44] Seasarの開発手法はXPのひが版 Seasarでの開発手法はくーす 887 名前：デフォルトの名無しさん mailto:sage [04/12/09 11:36:00] ttp://d.hatena.ne.jp/higayasuo/20041209#1102556567 （　´_ゝ`） ﾌｰﾝ 888 名前：デフォルトの名無しさん mailto:sage [04/12/09 16:49:05] ちょっと聞きたいんだけど、振る舞いを持たないDTOって 例えば、伝票ってエンティティがあって、こいつの赤伝が欲しいって時に ステートレスなサービスオブジェクトで、わざわざ伝票の全ての金額項目を×-1していくってこと？ エンティティ自体にtoDebitNote()とか作って、それ呼べば済む話だろうに。 複数のエンティティから特定のエンティティを生成する場合とか、似たような例は あると思うけど、普通そういうロジックはエンティティ自身に持たせるんじゃないの？ サービス層がステートレスである必要性はわかるんだが、振る舞いを持たないDTOって いくらなんでもバカすぎじゃね？ ValueObjectにすら振る舞いは持たせるだろ、普通。 889 名前：デフォルトの名無しさん mailto:sage [04/12/09 18:08:33] 伝票エンティティ自体に自分自身の赤伝を作らせるのは あまり趣味ではないですな。 伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。 それは趣味なのでさておき、エンティティ自体に 赤伝生成責務を置くと、金額に-1をかけるコストに 何か変化はあるのでしょうか？ 振る舞いをデータから分離するってのは 普通業務はデータは安定していて ロジックは変化しやすいものだからってのが理由だそうです。 赤伝ってのはかなり安定した業務ロジックだから ちょっと例えが悪いかも知れませんね。 890 名前：デフォルトの名無しさん mailto:sage [04/12/09 18:17:05] >>889 > 伝票エンティティ自体に自分自身の赤伝を作らせるのは > あまり趣味ではないですな。 > 伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。 だからサービスがtoDebitNote()を呼ぶんでしょ > > それは趣味なのでさておき、エンティティ自体に > 赤伝生成責務を置くと、金額に-1をかけるコストに > 何か変化はあるのでしょうか？ だたでさえ肥大しがちなサービスからコードが減るよね。 金額なプロパティがいくつもある場合は特に。 > > 振る舞いをデータから分離するってのは > 普通業務はデータは安定していて > ロジックは変化しやすいものだからってのが理由だそうです。 > 赤伝ってのはかなり安定した業務ロジックだから > ちょっと例えが悪いかも知れませんね。 変化しやすいものを分離する理由はとはなんでしょう？ 891 名前：デフォルトの名無しさん mailto:sage [04/12/09 21:14:15] >>888 ＞＞サービス層がステートレスである必要性はわかるんだが 俺にはその必要性がわからない。 教えてくれ！ 892 名前：890 mailto:sage [04/12/09 21:26:33] >>891 > >>888 > ＞＞サービス層がステートレスである必要性はわかるんだが > 俺にはその必要性がわからない。 > 教えてくれ！ ステートフルで一度作ってみれ。難しいと思うが。 まぁ、なんちゅうか、リクエスト単位での処理を同期とか ややこしいこと考えずに作ろうとすると、必然的にステートレスになるわけだ。 StrutsのActionクラスが典型だろう。 ステートフルにしちゃうと、ややこしい同期処理を考えなきゃいけない上に 結果的にサービスオブジェクトのインスタンスを、リクエストの数だけ 生成しなきゃいけなくなるわけだ。 こんなんでよろしい？ 893 名前：デフォルトの名無しさん mailto:sage [04/12/09 22:19:32] サービスオブジェクトのインスタンスを、リクエストの数だけ生成したらいいんじゃない？ 894 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:31:05] >>892 同期処理の問題だけ？ 「同期処理とか」 の「とか」の部分について説明して欲しいな。 >>888に 「ValueObjectにすら振る舞いは持たせるだろ、普通。 」 って書いてあるけど、 ValueObjectはリクエストの数だけインスタンス作るからステートフルでもOKということ？ そもそも、くーすって状態に依存しないメソッドを使用すればテストも楽になるし、 他のメソッドなどに依存しないから再利用性も高まるし、 とか他のメリットもあったんじゃなかったっけ？ 895 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:34:14] >>892 振る舞いを持たないDTOっていくらなんでもバカすぎじゃね？ と書きながら 必然的にステートレスになるわけだ。 というところは矛盾してないか？ 振る舞いを持ったDTOはステートフルじゃねーのか？ 896 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:36:22] >>894-895 粘着に粘着するなよｗ 897 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:51:17] >>895 DTOに持たせる振る舞いはテストが面倒でもいいんだよ！ 898 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:56:31] 　 　∩＿＿＿∩　　 　　　　　　｜ 　　 | ノ＼　　　　 ヽ　 　　　　　　| 　　/　　●゛　　● |　　　　 　　　| 　 |　∪　　( _●_)　ミ　 　　　　　j 　彡､　　　|∪|　　 |　　　 　　　 Ｊ >>897。 /　　　　 ∩ノ ⊃　 ヽ　　 (　 ＼　／ ＿ノ　|　 | .＼　“　　／＿＿|　 | 　　＼ ／＿＿＿ ／ 899 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:23:47] >>896 888は粘着じゃないだろ。 まっとうな質問だと思うけど? 900 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:36:16] >>894も粘着してるようには思えないがな。 >>895は粘着っぽいけど 901 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:50:54] >>895も素朴な疑問といえば素朴な疑問だがな 902 名前：888 mailto:sage [04/12/10 00:56:21] >>893 もちろん、そうしたいならそうすればいいんでないの？ ファサードとして使えるステートレスなサービス層が無いってことで、 ロジックの見通しが悪くなるとか、透過的なトランザクション処理が やりづらくなっちゃうとかいう可能性はあるわけだけど。 >>894 「とか」の部分って何だろうね。自分で書きながらもよく解ってないかも。ｽﾏｿ ところでValueObjectの定義はわかってる？ 通貨とか税率とかそういう小さな単位のオブジェクトのことだよ？ テストはファサードになってるサービス毎に作ればいいよね。 ま、DTOっちゅうかエンティティに振る舞い持たせたからって、 テストがやりづらくなることは無いんだけど。 「状態に依存するメソッド」の状態の定義が曖昧だな。俺も、もちょっと考えてみる。 >>895 ステートレスなのはサービスで、そのステートレスなサービスがDTOに対して 支持をするわけだ。お前、今から赤伝になれ、みたいな。 同じことをサービスでやるよりは、よっぽど可読性もいいと思うんだけどなぁ。 サービスが何やってるのか一目瞭然だし。 903 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:57:34] 粘着に見える程度が、ここではまともなのです。 904 名前：デフォルトの名無しさん mailto:sage [04/12/10 01:28:15] >>888 正直、その問題に対してはくーす関係者は誰もまともに答えてないと思う。 ひが君はそっち方面の思考をすっかり停止しているし、こんの君は撹乱するだけだ。 唯一正面切って答えてるのは↓だと思うが、いまいち。 ttp://d.hatena.ne.jp/koichik/20041022#1098468196 905 名前：888 mailto:sage [04/12/10 01:41:48] >>>904 確かに難しい問題だとは思うけど、 これから世界に向けて発信して行こうっていうプロジェクトの思想としては、 ちょっとお粗末な気がするんだよ。 俺、１０年以上OOな思考にどっぷり浸かってるから、今更悪夢みたいな 手続き型の世界には戻りたくないっていう意識があるからかも知れんが、 ちょっと...なぁ。 だれかまともに答えてくれ　⇒Seasar&くーすの中の人達。 906 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:04:06] ちょっと振る舞い無し&ステートレス問題からは外れるけど、 そもそもOOな思考がばっちり出来る人ならくーすとかいらないんじゃないかな。 くーすは手続き型どっぷりな人でも、OOの恩恵が受けやすいって話だと いう事なんじゃないかなーと。 「思想」としては後ろ向きではあるよね。 どっちかというと商売寄りな発想、でも俺はそれでいいと思う。 907 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:05:36] あ、ごめん、思想がお粗末なんじゃなくて、 きちんと説明しないって事がお粗末なのか。 読み違えました。 908 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:20:57] >>837 うむ、だからそのgetEntityManager().findObject()を使うには、AbstractDaoのサブクラスを作らないといけない。 AbstractDaoをimplementsした実装クラスを作ると、insertやらgetXXやらのメソッドを実装しなくちゃいけ なくなるので、今度はSQL自動生成ができなくなる。自動生成したいメソッドもあるけど、findObjectも使いたい、 というジレンマだったわけだ。 インターフェースにメソッド名だけ定義すると、自動的に実装クラスが生成される。でもEntityManagerを 使うには実装クラスを作らないと行けない、と困ってたんだが。 でもS2DaoIntercepterのソースコードを読んで、単に実装クラスの方で、SQL自動生成したいメソッドを abstractにしとけば問題ないということに気がついた。まだ試してないけど。 909 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:21:51] >>905 > だれかまともに答えてくれ　⇒Seasar&くーすの中の人達。 「現場」だの「お客様」だのを盾にして逃げる擁護厨が出現して終わりなﾖｶｰﾝ。 910 名前：デフォルトの名無しさん mailto:sage [04/12/10 07:10:23] >>905 そんなことは、既に答えてる気がする。 www.wikiroom.com/tpircs/?higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1 量が多くて大変だけど。 911 名前：デフォルトの名無しさん mailto:sage [04/12/10 08:15:51] >>888 例えば、あるDTOを文字列に変換する必要がある場合を考えてみると、 a) dto.toString() b) service.convertToString(dto) のふたつのパターンで悩んでるってことだよね？ a)のメリットはdtoについてカプセル化することができることで、 b)のメリットはAOPなんかをはさめるってこと。 で、どっちがいいのかってのは、実のところ擬似問題なんだよね。 a)はオブジェクトのふるまいに関することで、 b)はシステムのふるまいに関すること。 888は、この両者を混同しているような気がする。 だから、きちんと答えるとすると、 「エンティティ自体にtoDebitNote()を実装してもいいけど、 それを行なう一連の手続きは、きちんとサービス層のオブジェクトの責任にしてね」 って感じになるのかな。 912 名前：デフォルトの名無しさん mailto:sage [04/12/10 08:38:13] >>908 というより、これまでと同じようにインターフェースを作って、 Daoの実装は、abstract classにして必要なメソッドだけを実装すればOK。 913 名前：デフォルトの名無しさん mailto:sage [04/12/10 10:27:34] ひが日記を読んで、こりゃやっぱり構造化分析で、 だからくーす（古酒）なんだよなーと思った。 ところで赤伝生成とtoDebitNoteってメソッド名が どうも結びつかんのでさっぱりイメージが湧かないなー とか思ってたら、はぶ氏が答えてますね。 914 名前：デフォルトの名無しさん mailto:sage [04/12/10 12:26:51] OO大好きで啓蒙好きな人は、なぜだか会計に弱い事が多い 以上、極私的な経験則に基づく極端な偏見を述べてみました 915 名前：デフォルトの名無しさん mailto:sage [04/12/10 12:59:55] >>はぶ氏 「赤伝になる」ではなく「赤伝にする」です。 ついでにdebitnoteってそのまま「赤伝」のことなんだけど、最近の辞書には 借方票ってのってますな。なんだそれって感じ。 イメージとしては自分自身のインスタンス、またはコピーインスタンスを返すような メソッドをイメージしてたんだけど、ま、単なる思い付きだったんで例えとしては最悪ですな。 結論には納得です。俺も似たような方向性なので。 >>ひが氏 保守のコストについて語りだすと泥沼になりそうなので(俺が)、一点だけ。 一番危惧しているのは、何でもかんでもサービスオブジェクトに突っ込んでしまって その結果、肥大したサービスオブジェクトが保守性を下げてしまう事なんだけども、 その辺りはどう考えてるんですか？ 適切に分割っていっても、その指針もまた、DTOにどこまで振る舞いを持たせるかっていう 命題と同じで、曖昧になりがちだし、複雑な業務になればなるほど、分割も難しいと思うんだけど。 俺の場合は、サービスオブジェクトの見通しをよくするためにエンティティに振る舞いを 持たせて、基本的にサービスオブジェクトは分割しない方針です。 一つの、一連の業務の流れの中で閉じておきたいと考えるので。 >>911 できれば、もちょっとよく読んでくれ。 一連の手続をサービスオブジェクトの責務とすることは↑で何度かそれとなく言ってる。 916 名前：デフォルトの名無しさん mailto:sage [04/12/10 13:05:23] >>914 OOは大好きだけど、啓蒙しようって気は無いよ。 寧ろ啓蒙されたいかも。 俺、そんなに偉いポストにいるわけじゃないから、 毎回アーキテクトやれるってわけじゃないし、 最近は人が作ったものを治してばっかりだし、 はぁ.. 917 名前：913 mailto:sage [04/12/10 13:20:38] 赤伝の事をDebitNoteというのかー。知らなかった・・・。 前に海外拠点向けのシステム作ったときは Revised、Adjustなんて言葉使ってたけど 考えてみればそれは販売側の業務用語だったんだな。 会計用語じゃなかったんだ。勉強になります。 918 名前：デフォルトの名無しさん mailto:sage [04/12/10 15:14:35] 俺がやった貿易システムじゃ Debit Note は請求書の事だったけどな。 専門用語英語は難しい。 ひが氏のもわかるし、915のもわかる、 いいとこどりとかバランスって事なんだろうけど それだとあいまいだしね、難しい。 俺は全部サービスに突っ込んじゃいたいかな。 肥大化しても、サービス分割はしない。 ステップ数大きいクラスが出来たら、すまん、と謝る。 うーん、気持ち悪いな。ダメか。 919 名前：デフォルトの名無しさん mailto:sage [04/12/10 17:35:52] >>918 なぜ全部サービスに突っ込みたいの? 920 名前：デフォルトの名無しさん mailto:sage [04/12/10 17:38:20] >>912 なるほどあったまい〜。 ついでに一つ聞いてもいい？ hsqlでIDENTITYとかデフォルト値使う時って、insert/update SQL書かなきゃだめ？ どうもいくらためしてもだめだったんだけど、何か良い方法はあるかな。 921 名前：デフォルトの名無しさん mailto:sage [04/12/10 18:06:02] d.hatena.ne.jp/koichik/20041209#1102615228 ここのkoichik氏の意見読んで思ったけど、 「振る舞い」って言葉の定義もあやふやなんだな。 俺が言ってる「振る舞い」ってのは単純なgetter/setterを除いた 一般的なメソッドも含んでるんだけど、くーすの中の人たちは 一連の業務ロジックと同列に捕らえているってこと？ さすがにメインストリームになる業務ロジックはサービスオブジェクトに きっちりとまとめるわけだけど、その中で各エンティティに振り分けられる処理は 振り分けたいってのが、そもそもやりたい事なわけですよ。 サービスオブジェクトの可読性を上げるためにってのと、 OO設計原則(くーすではdeprecatedなんだっけ?)に従うって意味でね。 で、現状どんな場合に振分けてるかっていうと、 １．各エンティティに閉じた振る舞い 　　(合計値の算出とか、プロパティAとプロパティBの状態からプロパティCを設定するとか) ２．1個以上のエンティティとの関連から各プロパティを設定する場合 　　(エンティティAとエンティティBからエンティティCの各プロパティを設定する、とか) 　　 「請求書オブジェクト」に「今週の通貨レート情報」を渡して請求額を算出する場合も同じかな 　　 この場合、業務ロジック、というかビジネスルールがドメインオブジェクトに存在する事になるわけだな。 ざっと見たところこんなところ。まだまだありそうな気がするけど、今忙しいし。 922 名前：デフォルトの名無しさん [04/12/10 23:48:29] 結論 　やっぱエンティティBeanだね。EJB万歳。 923 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:01:13] >>920 IDENTITYに関しては、そのうち対応してくれるっぽい。 主キー値の自動採番機能つけるっつってたから。 デフォルト値はムリぽかなぁ。 924 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:05:26] ＤＢ側で自動採番してた場合に、キーをinsert文から外すために いちいちSQLを書かないといけないという話題だとおもわれ。 別にS2Daoが採番しなくても、DBがやってくれるんだからいい。 925 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:08:25] 赤伝の話は、Repositry と Entity のどちらを界面とするかだね。 レイヤーを隔てた協調動作かどうかが、これを分ける。 検索： [A] Entity entity = Repository.findEntity(id); [B] Entity entity = Entity.find(id); 保存： [A] Repository.store(entity); [B] entity.store(); [B]のように記述しても、その裏ではたいてい[A]のようなコードが記述される。 それは、レイヤー(ドメインと言ってもよい)が違うオブジェクト同士のコラボレーションだから。 同じレイヤーに存在できるオブジェクト同士なら、[B]のように書くのが自然。 [A] FooProcessor fooProcessor; fooProcessor.process(foo, bar); [B] Foo foo; foo.process(bar); 926 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:51:22] >>921 一般的なメソッドと一連の業務ロジックの違いを定義しないと曖昧なままだと思われ 927 名前：デフォルトの名無しさん mailto:sage [04/12/11 08:07:26] >>925 staticメソッドやエンティティに永続化メソッドを持たせるのはもう古いよ。 Torqueが否定されて、エンティティ(POJO)とDAOを分けるようになったわけだからね。 絶対的なものなどないのですよ。 データと振る舞いを1つにカプセル化するのが、 OOの絶対的な原則だと思っているならたぶんそれも間違い。 928 名前：デフォルトの名無しさん mailto:sage [04/12/11 10:13:54] >>927 レイヤーに重きをおいてみてほしいんだが。 POJOとDAOを分けるのは、それぞれ明確にレイヤーが違うからだと思うよ。 自分も、Entity.store()なんてコードは書いたことないし。 929 名前：デフォルトの名無しさん mailto:sage [04/12/11 10:18:41] ついでに書くと、 下の例で[A]のように書くのは、大いなる手続き型。 レコードの件数を数えるのに、集約関数を使わずにフェッチしてカウントアップするようなもの。 930 名前：デフォルトの名無しさん mailto:sage [04/12/11 11:02:22] >>929 自然とか関係ないんだって。 その自然というのは個人的主観なんだから。 別に否定しているわけではないけど。 1.processor.process(foo, bar); 2.foo.process(bar); 3.bar.process(foo); のどれがきれいかなんてことは、どうでも良い。 人を集めてきて、いっせいにコードを書かせたときに、 1でいくと決めたほうが、誰も迷わないし、レビューもしやすいってこと。 processという振る舞いが、fooに属するのかbarに属するのか どちらにも属さないのかを適切に判断できるのは、 誰でも簡単にできることではない。 自分がプロジェクトをまかされたときに、コストをかけずに 一定の品質の物を作り出すにはどうしたら良いかという のが、たぶん、くーすの視点。 931 名前：デフォルトの名無しさん mailto:sage [04/12/11 11:27:20] つまり、やっぱ構造化＆データと処理の分離こそが正しい道だった、と。 932 名前：デフォルトの名無しさん mailto:sage [04/12/11 12:34:32] > 1でいくと決めたほうが、誰も迷わないし、レビューもしやすいってこと。 1〜3のどれで書いてもコードの複雑さが同じならそうだけど、 実際には異なるだろう。 困難な決定を先送りにしているだけではないか? 933 名前：デフォルトの名無しさん mailto:sage [04/12/11 12:36:16] >>924 そうそう、それです！現状はそれができないってことですね。 ではひがたんに要望。 insert/updateのアノテーションで、使用する(もしくは使用しない)プロパティを指定できたりすると嬉しいです。 publis static final String insert_IGNORECOLS = "id"; みたいな形で。 934 名前：デフォルトの名無しさん mailto:sage [04/12/11 12:41:04] うおっ、いいねそのアノテーション！ update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。 935 名前：デフォルトの名無しさん mailto:sage [04/12/11 15:03:56] >>930 1も2も3とれが最適かは、状況によって違うから、限定する意味無いんでない？ モジュール化、依存度の低い、ポリモーフィズムを活用した表現力の高さとかバランス見て。 だから、どれで行くと決めること自体が害悪。 936 名前：888 mailto:sage [04/12/11 16:32:34] そいじゃ、DTOには振舞い持たせない って言い切ってるくーすは害悪ってことで Final answer ? ま、そりゃ1/3冗談だとして、限定する意味はあると思うよ。もちろんその状況毎で。 デザインパターンがそうであるようにね。 それを放棄してしまっているくーすの思想には、>>932も触れてるように、かなり危惧してる。 このままメジャーになっていったとして、ほんとにそんなんでいいのか？っていう不安が拭いきれない感じ。 まず、>>926の言うとおり、一般的なメソッドと業務ロジックの 違いをはっきりと定義することが重要だと思うね。俺自身、はっきり区別できてないわけだけど。 その定義がぼんやりとでも見えてきたら、一歩前進だと思う。 937 名前：デフォルトの名無しさん mailto:sage [04/12/11 18:08:55] わざわざ早く寝たと不自然に断りながら このスレ向けを日記で回答をする人は 実は早く寝てなんかおらず、 このスレに夢中になって書きんでいた ことをひた隠しにしているだけという理解でよいでしょうか？ 938 名前：デフォルトの名無しさん mailto:sage [04/12/11 19:14:23] > そいじゃ、DTOには振舞い持たせない って言い切ってるくーすは害悪 うむ。大抵はそれでいいだろ。データ扱うときゃMapでいい。 ちょっとした四則演算で求まるもので、そんな重い処理じゃなくて、 ポリモーフィズムが生きるようなものだったらデータに振る舞い持たせてもよいと思う。 939 名前：デフォルトの名無しさん mailto:sage [04/12/11 19:42:08] そういやCOBOLでやってたときはふつーのおばちゃんが仕様書をコードに変換してた。 あれはデータと処理が分離していればこそ、だったんだろうな。 もちろん業務の相応に細かな仕様書も必要だけど。 くーすって、コーディングをそのへんまで単純にすることを期待してるんかな。 940 名前：デフォルトの名無しさん mailto:sage [04/12/11 21:41:54] >>939 > くーすって、コーディングをそのへんまで単純にすることを期待してるんかな。 ひが氏とか壺売り氏とかは盛んにそんなことを言ってるね。 ↓みたいな立場とは対極だな。 ttp://www.freeml.com/message/patterns@freeml.com/0002755 941 名前：デフォルトの名無しさん mailto:sage [04/12/11 22:40:01] ん？ 基本的にOOを深く理解した賢い人が能率良く仕事するツールだろ？ 942 名前：デフォルトの名無しさん mailto:sage [04/12/12 02:31:21] >>941 少なくともくーすの中の人の意識は>>939と同じ。 >>932の言う「困難な決定」を下っ端(もしくは中国)に spell awayするための方法論。 943 名前：デフォルトの名無しさん mailto:sage [04/12/12 11:48:23] ふつーのおばちゃんにやらせるぐらいなら、素直に機械にやらせればいいのに。 944 名前：デフォルトの名無しさん mailto:sage [04/12/12 11:49:29] >>942 だとしたら、COBOL 85 >>>>>>>>> くーす だな。 945 名前：デフォルトの名無しさん mailto:sage [04/12/12 12:32:31] >>942 困難な決定をさせないのがくーす。 >>936 業務ロジックとは、ユーザに対するサービス。 業務ロジックでないメソッドとは、ユーザに対するものではなく、 クラスの都合で必要なメソッド。 946 名前：デフォルトの名無しさん mailto:sage [04/12/12 16:00:33] なるほど。 くーすはXPとは対照的に、人間のコミュニケーションの感性を信じてないんだな。 そういう人みたことあるけど、 どうせ分かり合えないから話してもムダなんだよという空気をドバドバ吐き出しちゃってて、 ちょっと痛々しいね。 オープンソースに逃げないで現実の人間のことを考えつづけたほうがいいと思うよ。 947 名前：デフォルトの名無しさん mailto:sage [04/12/12 16:47:39] >>946 仕事なんか定型的にやるのが一番。 相手のことなんかより、自分の私生活のほうが大事。 948 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:22:09] >>947の華麗な私生活に乾杯。 949 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:29:20] つまり、ブランドの服を買いまくりってことかと。 950 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:35:42] >>946 > ちょっと痛々しいね。 おぬしの書き込みのほうが痛々しいなり。 >>288がいいことを書いているので参考にするなり。 人を信じないおぬしには、他人も人を信じないように見えるということなり。 951 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:57:42] >>936 まあ、そんなにくーすが嫌いならあんたが採用しなけりゃいいだけだと思うがね。 くーすをよりよいものにしようと考えていろいろ書き込んでるんじゃなく、 くーすそのものの考え方を否定しているみたいだけど、 人それぞれ考えかたがあるんだから採用する人しない人いていいんじゃない？ くーすの考え方に対して賛否あると思うけど、 ２ちゃんで関係ない人たちと議論するより比嘉氏の日記にコメントでもして 一度議論したほうがいいんじゃないの？ ここで盛り上がって「やっぱくーすはだめだね」って結論になっても くーす本は出るだろうし、あんたが危惧してるように くーすがこのままの形でメジャーになるかもしれないでしょ。 952 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:58:14] >>936 ＞＞一般的なメソッドと業務ロジックの違いをはっきりと定義することが重要だと思うね。 それができるぐらい技術力のある人材が豊富であれば くーすなんて必要ないと思う。 できないから、全部DTOからはずしてしまうと決めることで 余計なあいまいさを省くという考え方もでてくるのではないかな？ 豊富な技術力を有する高価なエンジニアを集めて 綺麗な設計、綺麗な実装でシステムを作るのもいいけど、 ビジネスとしてシステム開発をやるときには、 まず利益を上げられなければ話にならないから 生産性向上、コスト削減を考慮しなければならないと思う。 形式を決めてしまってあいまいさを省くことで 生産性を上げることができるかもしれないし、 単価の安い派遣会社に任せることでコストを削減できるかもしれないし 社内でくすぶっている技術力の低い人材を使うことで 社内で無駄になりがちなコストを有効活用できるかもしれない。 あんたのようなスキルの高い人材だけでシステム作るのであれば簡単だろうけど スキルの低い人材を使わざるを得ない自分のような立場の人間としては くーすのような考え方もありだと思う。 個人的には技術力の高い人材に対して数倍の「その他大勢」のプログラマを ぶら下げて開発するような形にしていかなければ会社自体が衰退していくような 危機感を感じているよ。我が社では。 953 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:09:50] 今回のスレはくーすﾈﾀで盛り上がってるね。 954 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:14:20] > 個人的には技術力の高い人材に対して数倍の「その他大勢」のプログラマを > ぶら下げて開発するような形にしていかなければ会社自体が衰退していくような > 危機感を感じているよ。我が社では。 とっとと潰れろボーケー 955 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:25:01] >>952 高スキル人員集約型と比べてくーすのコストは本当に低くなるのか。 あんたの会社で現実的に高スキル人員集約型が採用できるかは別問題。 >>954 いいツッコミだ。 956 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:27:54] なんだかなぁ もっとね、漏れはソフトウェア開発ってのはカネがいいとかどうとか そういうのを超えて、もっと使命感というか、スピリチュアルな エネルギーに満ちた仕事だと思うわけ。キカイ的に安い人集めて 自動的にうまくいく、なんてそんな工業的なもんじゃない。 そういう場は、コミュニケーション、フィードバック、信頼関係を 保つことが必要で、それをやらなきゃどうせまともなソフトウェアが 作れるはずもない。 漏れ的にはそんなことも分からん死んでもそんなクソな会社のために働きたくない。 だから漏れは今無職なのだが！　いや、しかし分かる会社もそれなりにあるはずだと信じたい。 957 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:32:16] >>955 > 高スキル人員集約型と比べてくーすのコストは本当に低くなるのか。 少なくとも取替えは出来るようになるんじゃないかな。 スキルの高い奴が集まっていても健康な奴ばかりとは限らん。 少数精鋭って言葉に幻想を抱いている奴が多いが ひとりに何かの事情が発生したら大変だぞ。 958 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:33:14] 銀の弾丸探しの種は尽きまじ 959 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:33:35] >>956 藻前がそういう会社を作って人材を募集したらいいんだよ。 960 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:38:39] >>957 むしろ、くーすは上流工程に責務を集中させるから、XP 等に比べて その部分の取替え可能性に関するリスクが高い、という見方もあると思うが。 961 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:42:53] >>956 ある漫画家が言うてました。 最高を求めて筆を入れ続けたいなら趣味か同人でやるべきで それを職業とするなら金と納期によって品質を決めるべきだと 962 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:47:19] >>961 いいソフト作るには趣味しか無いと？ 何いってんの。 趣味じゃフルタイム開発に費やせないじゃん。 そんなんでソフトウェア作れるかよ。 963 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:47:42] >>960 役割を階層化すると教育は容易くなるよ。それは上も下も関係ない。 図面ひく人、釘打つ人と分けたからって図面をひくという行為そのも のの難易度が上がるわけじゃない。 寧ろ階層辺りの必要能力が限定される分、難易度は下がる。 964 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:48:28] >>949 ぐはぁっ．(;_;) と騙ってみるテスト。 965 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:50:17] >>962 予算と納期に応じて要求を満たす動くものを作れと言ってる。 良い悪いなんて話はしてない。 敢えて良い悪いで語るなら、当初の予算を超えたり、納期に 遅れたり、そもそも要求を満たさなかったり、ましてや動かな かったりするソフトウェアは悪いソフトウェアだｗ 966 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:53:20] >>946 XPが人を信じてるなら何でペアプロなんてやらせるんだ。俺のコードを信じてないからだろ。 何で毎日ミーティングさせるんだ。3ヵ月後にちゃんと持ってくるんだからほっとけよ。 なんてことを言ってるのと似たような発言だな。 お前の言うコミュニケーションの感性って具体的に何よ？ それよりお前XPやってるのか？ 967 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:54:02] >>962 キミの趣味にフルタイムの給料を出せと？ 968 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:55:19] >>965 わかった。 とにかく急いで作らなきゃいけなくて、 まともなコード書ける人数がいないというのが現実なら、 そもそもその仕事を引き受けるべきではなかったのだ。 現実的な解はくーすを使うことではなく、客に謝りにいくことである。 そうしないと被害大きくするだけ。 969 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:56:44] 休日にも関わらず盛り上がってますねー！ 今日の ﾈﾀ 師は >>946 に ｹﾃｰｲ ！ 970 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:58:42] >>946=>>969 という認識でよろしいでしょうか。 971 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:01:46] >>956はﾈﾀだ、気をつけろ!! …って遅かったか。 972 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:16:14] >>968 「まともなコード書ける人数がいない」などという条件は何処から引っ張って来た？ 勝手に条件加えて手前勝手な結論に至って満足か？ 973 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:21:09] ﾈﾀﾆ ｾｷｽﾞｲﾊﾝｼｬ ｶｺﾜﾙｲ 974 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:33:25] >>972 もちろん満足です！ 釣れたから（藁 975 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:33:34] まぁ、Seaser自体がネタだからな 976 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:35:47] そうでつね。Seaserはﾈﾀでつね。 Seasarはﾈﾀじゃないでつけどね。 977 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:37:24] さあ久々に盛り上がってまいりました！ >>946と>>956のコンビプレーのおかげです！！ 978 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:42:38] >>962 > いいソフト作るには趣味しか無いと？ 参考までにどんなソフトを作っているのか教えてくれないか？ 979 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:43:27] >977 >>946と>>956だがネタじゃねーよ 980 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:45:19] 何と！>>946=>>956だそうです！ いよいよ盛り上がってまいりました！！ ﾈﾀ師マンセーｗ 981 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:49:15] >>979 ネタであるか否かを決定するのは本人の主観ではない。 スレの空気だ。 お気の毒。 982 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:53:02] 　　☆ ﾁﾝ 　　　 　 　 ☆　ﾁﾝ　　〃　 ∧＿∧ 　 ／￣￣￣￣￣￣￣ 　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）＜　 >>946=>>956ﾀﾝ新ﾈﾀまだー？ 　　 　 　 　 　 　 ＼＿／⊂　⊂＿)＿ ＼＿＿＿＿＿＿＿ 　　 　 　 　 　 ／￣￣￣￣￣￣￣／| 　　　　　　　　| ￣ ￣￣￣￣￣￣:|　:| 　　　　　　　　|　　　　　　　　　　　.|／ つーか、誰か新スレ立てろ。スレタイスペルミスすんなよ。 983 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:58:01] >>979 騙るな。俺が本物の>>946=>>956だ。 よーしこれからもどんどんﾈﾀ作っちゃうぞー。 984 名前：デフォルトの名無しさん mailto:sage [04/12/12 20:01:40] ほんとに946=956だとしたらさ俺ちょっと 思い当たる奴いるんでちょっと引いてしまう。 いやな、デザパタがどうとか色々というんだけど まあ何というかなヒッキーでなコミュニケーション 取れない奴だったんだなこれが。本とかいっぱい 読んでたよ。詳しい奴ではあった。 でなしょぼいアプリ一つ満足に期限どおりに作れなくて それをリーダーとか営業とかのせいにばかりしててさ ソフト開発はこうあるべきなんだとか力説してたよ。 でも社内の女の子とかからもきしょがられてさ。 結局辞めたんだけどさ。それこそくーす仕込んで使いたく なるような奴だったんだが、まさかお前じゃないよな956 985 名前：デフォルトの名無しさん mailto:sage [04/12/12 20:20:27] 結論：COBOL最強。 986 名前：デフォルトの名無しさん mailto:sage [04/12/12 21:04:40] >>966 > >>946 > XPが人を信じてるなら何でペアプロなんてやらせるんだ。俺のコードを信じてないからだろ。 ペアプロの目的のひとつはレビュー。 どんなベテランプログラマのコードだって、レビューの対象となるでしょう、ふつう。 > 何で毎日ミーティングさせるんだ。3ヵ月後にちゃんと持ってくるんだからほっとけよ。 フィードバックを素早く行いたいから、とかかな。 987 名前：デフォルトの名無しさん mailto:sage [04/12/12 21:06:26] 次のスレタイは「ネタコンテナSeas"e"r2」でいこう。 988 名前：デフォルトの名無しさん mailto:sage [04/12/12 21:16:33] >>986 つまりコミュニケーション自体が目的ではないってことだな。レビューやフィードバックをきちんと行うためのツールの一つがコミュニケーションということだ。 コミュニケーションが不要とは言わんが、コミュニケーションを連呼する奴には職場の付き合いに一体何を期待しているのかと問いたくなる。 さっさと仕事終わらせてプライベートの付き合いをしにいくほうが俺はいい。仕事が趣味の奴は会社で深い付き合いをしたいのかも知れないけどな。 989 名前：デフォルトの名無しさん mailto:sage [04/12/12 22:18:12] >>988 アジャイル厨がよく言う「コミュニケーション」の意味合いを知るには 以下の本を読むといい。付き合いとか馴れ合いみたいな意味じゃないよ。 ttp://www.amazon.co.jp/exec/obidos/ASIN/4894715791/ ちなみに監訳者の1人がくーすの中の人だったりするから事態がややこしい。 990 名前：デフォルトの名無しさん mailto:sage [04/12/12 22:19:26] て言うか、コミュニケーションの方法まで方法論に盛り込もうってのは パターン化されてないとコミュニケーションすらとれない奴の願望か？ 挨拶は文言じゃないテンションだ！ 「ぉはよぅ(ﾎﾞｿ)」とか言うくらいなら黙ってる方がマシだ。 「はよう」でもいいから、顔を上げて声を張れ。ボソボソ言うなキモイ。 >>988 職場だろうと自宅だろうと楽しめる時には場所を選ばず楽しみたい。 て言うか、アフターは無しの人？社外の人間と予定合わすの難しくな いか？ 991 名前：デフォルトの名無しさん mailto:sage [04/12/12 22:45:11] わかった。 申し訳ない。 もう傷つけあうのはやめよう。 目的はいっしょなはずだ。 Seasarという頭でっかちともとらえかねられないものに関心を示す同士として、有益なことを語ろうではないか。 992 名前：デフォルトの名無しさん mailto:sage [04/12/12 22:56:54] Seasarのどこが頭でっかちなのか わからんが言いたいことはわかった。 まずは藻舞から有益なことを語ってくれ。 993 名前：デフォルトの名無しさん mailto:sage [04/12/12 23:01:26] >>990 何でそう極端になるんだｗ 普通に同僚と飲みに行ったりもするよ。 そんなに気張ってコミュニケーションと 言わないと仕事が回らんというのが わかんないだけだ。 994 名前：デフォルトの名無しさん mailto:sage [04/12/12 23:20:20] いい感じで盛り上がってるね。 で、次スレまだ？ 995 名前：デフォルトの名無しさん mailto:sage [04/12/12 23:38:18] 誰もやってくんないので建てますた。 pc5.2ch.net/test/read.cgi/tech/1102862221/ 996 名前：デフォルトの名無しさん mailto:sage [04/12/12 23:41:34] >>995 乙 997 名前：デフォルトの名無しさん mailto:sage [04/12/13 12:14:53] >>961 その漫画家がウソ言ってるなと思うのは、 職業で出す結果は大抵妥協の産物であるというのなら、 そもそも漫画家やる意味あんのか、ってあたりだな。 妥協するというならとことん妥協してもっと安定した仕事に就いてはいかがか。 やはり、漫画を描くことに意味を見出してるからやるんだと思うんだよ。 998 名前：デフォルトの名無しさん mailto:sage [04/12/13 12:31:37] 妥協って、とことんやるもんじゃないわな。 とことんやらないから妥協という。 それに961は妥協って事は書いてませんね。 品質を考える上で、金と納期を頭に入れるべきとだけ いってて、それはプロの仕事として当たり前ですね。 そういうプロの仕事に意味を見出しても、悪くはないですよね。 勿論、とことんやるならそれもまた意味はあるけど。 ガロとかあるし。もうないの？ 999 名前：デフォルトの名無しさん mailto:sage [04/12/13 13:11:37] >>997 妥協＝安定と思っているあたりがおめでたい 1000 名前：デフォルトの名無しさん mailto:sage [04/12/13 13:12:18] 100get! 1001 名前：１００１ [Over 1000 Thread] このスレッドは１０００を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef