04/12/07 00:21:00
>>826
つか、シングルプロセッサだと当たりにくいよね。
昔、貧乏プロジェクトでテスト環境にマルチプロセッサの環境準備できなかったことがあて。
負荷テストで相当の多重度かけて数日動かして問題なかったのに、
マルチプロセッサの本番サーバでリリースしたら初日にいきなりAccessViolationしやがったし。
負荷テストの１／１０程度の同時アクセスしかなかったんだけど出やすいんだよね。
当然だけど。
自前のものならまだしも、下請けに作らせたものだったから、
大問題になっちゃったよ。
しかも、仕様変更だとかふざけた事言いやがって！
ああ、嫌なこと思い出したなぁ。
だからうちは下請けに仕事やらせるときはマルチプロセッサ環境での負荷検証してから納品させるようにした。
下請けにとってはやな客なんだろうなあ。
828:813
04/12/07 00:56:06
つーか、マルチプロセッサ以前の問題でしょ。
URLﾘﾝｸ(d.hatena.ne.jp)
↑ここら辺りの頓珍漢なやりとりを見りゃ、skimura氏が
HashMapクラスのAPI仕様すら理解してなかったってのは明白だ。
> URLﾘﾝｸ(java.sun.com)
> この実装は同期化されません。複数のスレッドが同時にこのマップにアクセスし、
> それらのスレッドの少なくとも 1 つが構造的にマップを変更する場合には、
> 外部で同期をとる必要があります。構造的な変更とは、1 つ以上のマッピングを
> 追加または削除するオペレーションのことです。
こんなの、ちょっと知識のある人がコードレビューすりゃ一発で
指摘されるもんなのに、今まで放置されてたってのは異常。
……って思ってたら、
> なんていうか、「オープンソース」よりも「(ソースコードの付いてる)
> フリーソフト」に近い雰囲気を感じないといえば嘘になります。
って記述を見て納得。
829:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/07 01:07:36
H2Dao(・∀・)ｲｲ
831:デフォルトの名無しさん
04/12/07 01:25:44
>>830
おお、ほんとだ、H2Daoってなんだ.....orz
832:デフォルトの名無しさん
04/12/07 01:39:10
どこかにあるっていうから、探してみたら
ひが氏とも同期の話してた
URLﾘﾝｸ(seasarproject.g.hatena.ne.jp)
khi氏も最初の対応の後は、気づかなかったから、今まで放置だったんじゃないか？
まあ、直ったからいいけど
833:デフォルトの名無しさん
04/12/07 03:16:30
完璧はないんだから、すぐに対応してくれたskimura氏は立派だと思うよ、オレは
S2.1.4をすぐ出した、ひが氏もそうだし
それを当たり前と思うかどうかは、藻前らに任せるが
責任感もってやってくれてると思うと多少は安心する
834:デフォルトの名無しさん
04/12/07 03:32:11
>>831
Hummer2 Desert Access Optionの略ですね。
これで砂漠も川も縦横無尽。
835:デフォルトの名無しさん
04/12/07 04:31:29
>>829
> あとふと思ったが、H2Daoは楽は楽だが、一方でO/R Mappingフレームワークが普通に
> 提供している「DBから読み込んだデータのキャッシング」は提供しないね。まあ機能的に
> あたりまえなんだろうけど、この辺りを自分で実装する場合の負荷を考えるとどうなんだ
> ろか。
キャッシングが提供されてないのはDTOセントリックなアーキテクチャしか
眼中にないからだと思う。
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
ただ、こういうアーキテクチャがどういうドメインに適しているかについて
全く記述がない点が不信感を煽る。
836:デフォルトの名無しさん
04/12/07 07:13:56
キャッシュは鬼門
837:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/07 11:29:18
>>838
キャッシュは、近いところにあることにも意味があると思うが。
SQL自体を発行しないわけだから。
840:デフォルトの名無しさん
04/12/07 12:10:05
URLﾘﾝｸ(d.hatena.ne.jp)
> これは、どのようなドメインにもいえます。
（ ´_ゝ`） ﾌｰﾝ
841:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/07 21:42:49
>>842
どういうこと？
845:デフォルトの名無しさん
04/12/07 22:31:19
>>843
誰のことー？？
846:デフォルトの名無しさん
04/12/07 22:31:30
>>844
くーすはシンプルで分かりやすいですが，業務分析は扱わず今まで通りです
から，業務分析をくーすに繋げるあたりの教育やらコンサルやらのビジネス
がなり立つでしょう．そのスペースを狙っている人達がみえかくれ．
Seasar上の開発はプログラミングというよりコーダー的な仕事になり，
それに関る人達の実装技術は育たないことになり，どんどん骨抜きになりそ
う．
というか，そもそも技術力がないソフトハウスをSeasarはターゲットユーザ
にしてる感あり．
847:デフォルトの名無しさん
04/12/07 22:51:35
>>846
そういう技術の無い若手を採りすぎた会社にいます。
人事部長が変って大学名だけで使えない奴とりまくってしまった。
現場は悲惨だよ。
848:デフォルトの名無しさん
04/12/07 23:16:37
>>847
その日本語も、そういう現場でつちかってしまったのですね。
849:デフォルトの名無しさん
04/12/07 23:33:49
>>846の句読点が気になる今日この頃。
850:デフォルトの名無しさん
04/12/08 00:11:26
Seaserも大分信用無くしたなぁ…。
OOやらフレームワークやら語ってた割に、排他制御すらまともに出来ていなかったなんて…。
他にも似たようなバグ抱えてるんじゃないか？
851:デフォルトの名無しさん
04/12/08 00:34:46
ちょっと追ってみたけど、俺みたいなのでもわかるような
基本的なところで、ぼろぼろじゃん。
Web屋ってこういうの苦手だからしょうがないのかもしれないけど。
組み込みとかの経験ばっちりあるやつを開発に参加させないとダメなんちゃう？
852:デフォルトの名無しさん
04/12/08 01:17:57
O-Rマッピングツールは、SELECTには使わないのがベストプラクティス。
C/U/Dだけさくっと作って、参照クエリはじっくりSQLを記述する。
853:デフォルトの名無しさん
04/12/08 01:52:32
>>852
SELECTも、とりあえずORマッピングで遅延取得しまくりで動かしておいて、あとから必要なところだけじっくりSQLを記述する方がベストプラクティスだと思う。
854:デフォルトの名無しさん
04/12/08 02:07:09
どんなにO/Rマッピングを使っても
沢山の可愛そうな厨房を先導しても
SQLから離れては生きられないのよ！
855:デフォルトの名無しさん
04/12/08 02:12:55
>>854
それは、ORマッピングをかいかぶりすぎ。
ORマッピングはSQLの結果をマッピングしてくれるだけで、複雑なSQLを簡単にしてくれるわけではない。
JOINに関してはある程度面倒をみてくれるが。
856:デフォルトの名無しさん
04/12/08 02:23:42
O/RマッピングでSQLが不要になると思った奴て結構多そうだよな。
ASP.NETでJ2EEが消えると思ってる奴とどちらが多いのか気になるところだ。
857:デフォルトの名無しさん
04/12/08 02:29:17
>>856
で、「結局SQLが必要だからORマッピングなんか役に立たない」と勘違いしてるやつもいるね。
858:デフォルトの名無しさん
04/12/08 02:30:11
そして、ここをORマッピングのスレと勘違いしてるやつもいるな。
859:デフォルトの名無しさん
04/12/08 03:13:02
>>856
SQLTemplateがCayenneやHibernateにいまごろ実装されていく様子をみると、開発者自身もそう夢見てたんだろうね。
スレ違いか。
860:デフォルトの名無しさん
04/12/08 06:34:41
URLﾘﾝｸ(d.hatena.ne.jp)
> Fowlerはプレゼンテーション層で必要とされる構造と
> ドメインオブジェクトの間にミスマッチがあるときだけ、
> DTOを使えといっていますが、たいていの場合(よほど
> 単純な画面でない限り)、ミスマッチはあるものです。
ここでいうミスマッチのイメージがわかないです。
どなたか、例を挙げていただけるとうれしいのですが。
861:デフォルトの名無しさん
04/12/08 07:57:30
>>846
業務分析を楽に稼げる仕事だと思ってるあたりがおめでたい
862:デフォルトの名無しさん
04/12/08 10:00:51
>>861
よく読んだら。業務分析できない人たちへの教育やコンサルであって、
業務分析を逃げて稼ぐといういみでは。
863:デフォルトの名無しさん
04/12/08 10:12:04
なるほどね。>>862は例えばオブジェクト指向できない人たちへの教育やコンサルについてはどう思ってるの。
そもそも社外研修を受けさせないと駄目な会社は逝ってよしって言いたいのかな。
864:862
04/12/08 10:33:42
>>863
まず断っておくが俺は846ではないので。
「オブジェクト指向できない人たちへの教育やコンサルについては」
どうでも良いと思っている。好きにすればよいと。
846は「そのスペースを狙っている人達がみえかくれ．」と書いている
が、そこを狙っている人達の怪しさを感じ、使う気がしないといって
いると読んだまで。ひがさんは良いとして、おこぼれ頂戴と虎視眈々
と狙っている人達がなんとなくくーすもSeaserもだめにしそうな感じ
が俺もする。
865:デフォルトの名無しさん
04/12/08 12:02:59
>>846
> 業務分析は扱わず今まで通りですから
こういうくーすの守備範囲に関する元ネタどこ?
866:デフォルトの名無しさん
04/12/08 12:15:41
ほい
URLﾘﾝｸ(marrow.strnet.com)
867:デフォルトの名無しさん
04/12/08 19:05:20
そもそもJavaでサーバサイド開発というのがネタだと漏れは思ってるんで。
もうSeaserも含めてJavaな方々はネタ作りに必死だなと常々思う。
868:デフォルトの名無しさん
04/12/08 19:51:55
禿堂。
サーバサイドはPHPだよな。
869:デフォルトの名無しさん
04/12/08 20:35:05
>>868
いや、PHPはイカンと思うが。
でも、Javaよりはマシかもね。
870:デフォルトの名無しさん
04/12/08 22:25:59
そこで.Netですよ。
871:デフォルトの名無しさん
04/12/08 22:57:52
>>870
.NetはPHPより悪いJavaよりさらにタチが悪い気がするな。
立ち位置がどうしよもなく中途半端だし、ＭＳだしな。
872:デフォルトの名無しさん
04/12/08 23:21:17
>>869
で、結論はPerlということか。
873:デフォルトの名無しさん
04/12/08 23:25:07
＞ＭＳだしな。
ん？Microsoft製だと何かまずいの？
Microsoftのソフト開発環境はとても使いやすいが。
874:デフォルトの名無しさん
04/12/08 23:38:46
>>867
サーバサイド開発がネタ
というか、某板某スレの、「Javaはネタ→禿どう」のコンビの人みたいだね。
875:デフォルトの名無しさん
04/12/09 00:05:40
>873
871じゃないが、
売れてるだけあっていいところは沢山あるんだけどさ。
寄らば大樹の陰が行き過ぎて変なところから圧力かかるのがＭＳのやなとこ。
成り行きでＭＳ”ばかり”やるようになると、ほかの良い物を導入しようとしたとき
「それＭＳじゃないからヤダ」って馬鹿を言う奴がいつのまにか周り中にいたりする。
せっかく自由社会にいるのに自分から独裁者に仕えるのは悪趣味だと思うぞ。
>Microsoftのソフト開発環境はとても使いやすいが。
「俺は」使いやすいとは思わんけど。どっちかというとボーランド派だから。
ようは個人の好み。
876:デフォルトの名無しさん
04/12/09 00:33:52
>>875
抽象的杉。説得力皆無。
877:デフォルトの名無しさん
04/12/09 00:42:31
>>876
開発環境ぐらい、フリーのものを使いたいぞな。
878:デフォルトの名無しさん
04/12/09 01:03:28
そこで vi + gcc + gdb ですよ。
879:デフォルトの名無しさん
04/12/09 01:14:44
お金払うものでも、自由であればいいよ。
金払って開発環境使い始めたが最後、あとはすべてそこの製品で賄わなければ元がとれない、というものじゃなければ。
880:デフォルトの名無しさん
04/12/09 01:41:39
>>874
いんや、Javaはなかなかよいと漏れは思ってるよ。
SwingはなかなかいいAPI構成だと思うし、Eclipseは神だしね。
ただ、ここで議論しているようなデータベースのインターフェースとなる
業務アプリを作るときには、Javaは向いてないなってなことだ。
881:デフォルトの名無しさん
04/12/09 02:35:07
Swingのフォームとバリューオブジェクトのビーンが相互にやりとりできる仕組みさえできればいいと思うんだけどね。
882:デフォルトの名無しさん
04/12/09 02:41:54
だれかが言ってたようにSeasarが失敗だとするならば、その理由は、ヒガさんに全体的なモデルがなかったことだと思う。
くーすはベストプラクティスの積み上げで、全体的なモデルを構築できてないように思える。
ベストプラクティスは既知の問題には対応できるけど、未知の問題に対応するにはモデルの構築が不可欠だから。
だれかが言ってた、Seasarが失敗だというのが誤りであれば、３行目を除いては正しいとはいえなくなるわけだが。
883:デフォルトの名無しさん
04/12/09 03:09:05
くーすという方法論とSeasarというプロダクトは別なのだが
884:デフォルトの名無しさん
04/12/09 04:41:55
くーすって方法論なの？
885:デフォルトの名無しさん
04/12/09 04:42:54
Seasarは方法論なしにやってるってこと？
886:デフォルトの名無しさん
04/12/09 11:27:44
Seasarの開発手法はXPのひが版
Seasarでの開発手法はくーす
887:デフォルトの名無しさん
04/12/09 11:36:00
URLﾘﾝｸ(d.hatena.ne.jp)
（ ´_ゝ`） ﾌｰﾝ
888:デフォルトの名無しさん
04/12/09 16:49:05
ちょっと聞きたいんだけど、振る舞いを持たないDTOって
例えば、伝票ってエンティティがあって、こいつの赤伝が欲しいって時に
ステートレスなサービスオブジェクトで、わざわざ伝票の全ての金額項目を×-1していくってこと？
エンティティ自体にtoDebitNote()とか作って、それ呼べば済む話だろうに。
複数のエンティティから特定のエンティティを生成する場合とか、似たような例は
あると思うけど、普通そういうロジックはエンティティ自身に持たせるんじゃないの？
サービス層がステートレスである必要性はわかるんだが、振る舞いを持たないDTOって
いくらなんでもバカすぎじゃね？
ValueObjectにすら振る舞いは持たせるだろ、普通。
889:デフォルトの名無しさん
04/12/09 18:08:33
伝票エンティティ自体に自分自身の赤伝を作らせるのは
あまり趣味ではないですな。
伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。
それは趣味なのでさておき、エンティティ自体に
赤伝生成責務を置くと、金額に-1をかけるコストに
何か変化はあるのでしょうか？
振る舞いをデータから分離するってのは
普通業務はデータは安定していて
ロジックは変化しやすいものだからってのが理由だそうです。
赤伝ってのはかなり安定した業務ロジックだから
ちょっと例えが悪いかも知れませんね。
890:デフォルトの名無しさん
04/12/09 18:17:05
>>889
> 伝票エンティティ自体に自分自身の赤伝を作らせるのは
> あまり趣味ではないですな。
> 伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。
だからサービスがtoDebitNote()を呼ぶんでしょ
>
> それは趣味なのでさておき、エンティティ自体に
> 赤伝生成責務を置くと、金額に-1をかけるコストに
> 何か変化はあるのでしょうか？
だたでさえ肥大しがちなサービスからコードが減るよね。
金額なプロパティがいくつもある場合は特に。
>
> 振る舞いをデータから分離するってのは
> 普通業務はデータは安定していて
> ロジックは変化しやすいものだからってのが理由だそうです。
> 赤伝ってのはかなり安定した業務ロジックだから
> ちょっと例えが悪いかも知れませんね。
変化しやすいものを分離する理由はとはなんでしょう？
891:デフォルトの名無しさん
04/12/09 21:14:15
>>888
＞＞サービス層がステートレスである必要性はわかるんだが
俺にはその必要性がわからない。
教えてくれ！
892:890
04/12/09 21:26:33
>>891
> >>888
> ＞＞サービス層がステートレスである必要性はわかるんだが
> 俺にはその必要性がわからない。
> 教えてくれ！
ステートフルで一度作ってみれ。難しいと思うが。
まぁ、なんちゅうか、リクエスト単位での処理を同期とか
ややこしいこと考えずに作ろうとすると、必然的にステートレスになるわけだ。
StrutsのActionクラスが典型だろう。
ステートフルにしちゃうと、ややこしい同期処理を考えなきゃいけない上に
結果的にサービスオブジェクトのインスタンスを、リクエストの数だけ
生成しなきゃいけなくなるわけだ。
こんなんでよろしい？
893:デフォルトの名無しさん
04/12/09 22:19:32
サービスオブジェクトのインスタンスを、リクエストの数だけ生成したらいいんじゃない？
894:デフォルトの名無しさん
04/12/09 23:31:05
>>892
同期処理の問題だけ？
「同期処理とか」
の「とか」の部分について説明して欲しいな。
>>888に
「ValueObjectにすら振る舞いは持たせるだろ、普通。 」
って書いてあるけど、
ValueObjectはリクエストの数だけインスタンス作るからステートフルでもOKということ？
そもそも、くーすって状態に依存しないメソッドを使用すればテストも楽になるし、
他のメソッドなどに依存しないから再利用性も高まるし、
とか他のメリットもあったんじゃなかったっけ？
895:デフォルトの名無しさん
04/12/09 23:34:14
>>892
振る舞いを持たないDTOっていくらなんでもバカすぎじゃね？
と書きながら
必然的にステートレスになるわけだ。
というところは矛盾してないか？
振る舞いを持ったDTOはステートフルじゃねーのか？
896:デフォルトの名無しさん
04/12/09 23:36:22
>>894-895
粘着に粘着するなよｗ
897:デフォルトの名無しさん
04/12/09 23:51:17
>>895
DTOに持たせる振る舞いはテストが面倒でもいいんだよ！
898:デフォルトの名無しさん
04/12/09 23:56:31
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ >>897。
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
899:デフォルトの名無しさん
04/12/10 00:23:47
>>896
888は粘着じゃないだろ。
まっとうな質問だと思うけど?
900:デフォルトの名無しさん
04/12/10 00:36:16
>>894も粘着してるようには思えないがな。
>>895は粘着っぽいけど
901:デフォルトの名無しさん
04/12/10 00:50:54
>>895も素朴な疑問といえば素朴な疑問だがな
902:888
04/12/10 00:56:21
>>893
もちろん、そうしたいならそうすればいいんでないの？
ファサードとして使えるステートレスなサービス層が無いってことで、
ロジックの見通しが悪くなるとか、透過的なトランザクション処理が
やりづらくなっちゃうとかいう可能性はあるわけだけど。
>>894
「とか」の部分って何だろうね。自分で書きながらもよく解ってないかも。ｽﾏｿ
ところでValueObjectの定義はわかってる？
通貨とか税率とかそういう小さな単位のオブジェクトのことだよ？
テストはファサードになってるサービス毎に作ればいいよね。
ま、DTOっちゅうかエンティティに振る舞い持たせたからって、
テストがやりづらくなることは無いんだけど。
「状態に依存するメソッド」の状態の定義が曖昧だな。俺も、もちょっと考えてみる。
>>895
ステートレスなのはサービスで、そのステートレスなサービスがDTOに対して
支持をするわけだ。お前、今から赤伝になれ、みたいな。
同じことをサービスでやるよりは、よっぽど可読性もいいと思うんだけどなぁ。
サービスが何やってるのか一目瞭然だし。
903:デフォルトの名無しさん
04/12/10 00:57:34
粘着に見える程度が、ここではまともなのです。
904:デフォルトの名無しさん
04/12/10 01:28:15
>>888
正直、その問題に対してはくーす関係者は誰もまともに答えてないと思う。
ひが君はそっち方面の思考をすっかり停止しているし、こんの君は撹乱するだけだ。
唯一正面切って答えてるのは↓だと思うが、いまいち。
URLﾘﾝｸ(d.hatena.ne.jp)
905:888
04/12/10 01:41:48
>>>904
確かに難しい問題だとは思うけど、
これから世界に向けて発信して行こうっていうプロジェクトの思想としては、
ちょっとお粗末な気がするんだよ。
俺、１０年以上OOな思考にどっぷり浸かってるから、今更悪夢みたいな
手続き型の世界には戻りたくないっていう意識があるからかも知れんが、
ちょっと...なぁ。
だれかまともに答えてくれ ⇒Seasar&くーすの中の人達。
906:デフォルトの名無しさん
04/12/10 02:04:06
ちょっと振る舞い無し&ステートレス問題からは外れるけど、
そもそもOOな思考がばっちり出来る人ならくーすとかいらないんじゃないかな。
くーすは手続き型どっぷりな人でも、OOの恩恵が受けやすいって話だと
いう事なんじゃないかなーと。
「思想」としては後ろ向きではあるよね。
どっちかというと商売寄りな発想、でも俺はそれでいいと思う。
907:デフォルトの名無しさん
04/12/10 02:05:36
あ、ごめん、思想がお粗末なんじゃなくて、
きちんと説明しないって事がお粗末なのか。
読み違えました。
908:デフォルトの名無しさん
04/12/10 02:20:57
>>837
うむ、だからそのgetEntityManager().findObject()を使うには、AbstractDaoのサブクラスを作らないといけない。
AbstractDaoをimplementsした実装クラスを作ると、insertやらgetXXやらのメソッドを実装しなくちゃいけ
なくなるので、今度はSQL自動生成ができなくなる。自動生成したいメソッドもあるけど、findObjectも使いたい、
というジレンマだったわけだ。
インターフェースにメソッド名だけ定義すると、自動的に実装クラスが生成される。でもEntityManagerを
使うには実装クラスを作らないと行けない、と困ってたんだが。
でもS2DaoIntercepterのソースコードを読んで、単に実装クラスの方で、SQL自動生成したいメソッドを
abstractにしとけば問題ないということに気がついた。まだ試してないけど。
909:デフォルトの名無しさん
04/12/10 02:21:51
>>905
> だれかまともに答えてくれ ⇒Seasar&くーすの中の人達。
「現場」だの「お客様」だのを盾にして逃げる擁護厨が出現して終わりなﾖｶｰﾝ。
910:デフォルトの名無しさん
04/12/10 07:10:23
>>905
そんなことは、既に答えてる気がする。
URLﾘﾝｸ(www.wikiroom.com)
量が多くて大変だけど。
911:デフォルトの名無しさん
04/12/10 08:15:51
>>888
例えば、あるDTOを文字列に変換する必要がある場合を考えてみると、
a) dto.toString()
b) service.convertToString(dto)
のふたつのパターンで悩んでるってことだよね？
a)のメリットはdtoについてカプセル化することができることで、
b)のメリットはAOPなんかをはさめるってこと。
で、どっちがいいのかってのは、実のところ擬似問題なんだよね。
a)はオブジェクトのふるまいに関することで、
b)はシステムのふるまいに関すること。
888は、この両者を混同しているような気がする。
だから、きちんと答えるとすると、
「エンティティ自体にtoDebitNote()を実装してもいいけど、
それを行なう一連の手続きは、きちんとサービス層のオブジェクトの責任にしてね」
って感じになるのかな。
912:デフォルトの名無しさん
04/12/10 08:38:13
>>908
というより、これまでと同じようにインターフェースを作って、
Daoの実装は、abstract classにして必要なメソッドだけを実装すればOK。
913:デフォルトの名無しさん
04/12/10 10:27:34
ひが日記を読んで、こりゃやっぱり構造化分析で、
だからくーす（古酒）なんだよなーと思った。
ところで赤伝生成とtoDebitNoteってメソッド名が
どうも結びつかんのでさっぱりイメージが湧かないなー
とか思ってたら、はぶ氏が答えてますね。
914:デフォルトの名無しさん
04/12/10 12:26:51
OO大好きで啓蒙好きな人は、なぜだか会計に弱い事が多い
以上、極私的な経験則に基づく極端な偏見を述べてみました
915:デフォルトの名無しさん
04/12/10 12:59:55
>>はぶ氏
「赤伝になる」ではなく「赤伝にする」です。
ついでにdebitnoteってそのまま「赤伝」のことなんだけど、最近の辞書には
借方票ってのってますな。なんだそれって感じ。
イメージとしては自分自身のインスタンス、またはコピーインスタンスを返すような
メソッドをイメージしてたんだけど、ま、単なる思い付きだったんで例えとしては最悪ですな。
結論には納得です。俺も似たような方向性なので。
>>ひが氏
保守のコストについて語りだすと泥沼になりそうなので(俺が)、一点だけ。
一番危惧しているのは、何でもかんでもサービスオブジェクトに突っ込んでしまって
その結果、肥大したサービスオブジェクトが保守性を下げてしまう事なんだけども、
その辺りはどう考えてるんですか？
適切に分割っていっても、その指針もまた、DTOにどこまで振る舞いを持たせるかっていう
命題と同じで、曖昧になりがちだし、複雑な業務になればなるほど、分割も難しいと思うんだけど。
俺の場合は、サービスオブジェクトの見通しをよくするためにエンティティに振る舞いを
持たせて、基本的にサービスオブジェクトは分割しない方針です。
一つの、一連の業務の流れの中で閉じておきたいと考えるので。
>>911
できれば、もちょっとよく読んでくれ。
一連の手続をサービスオブジェクトの責務とすることは↑で何度かそれとなく言ってる。
916:デフォルトの名無しさん
04/12/10 13:05:23
>>914
OOは大好きだけど、啓蒙しようって気は無いよ。
寧ろ啓蒙されたいかも。
俺、そんなに偉いポストにいるわけじゃないから、
毎回アーキテクトやれるってわけじゃないし、
最近は人が作ったものを治してばっかりだし、
はぁ..
917:913
04/12/10 13:20:38
赤伝の事をDebitNoteというのかー。知らなかった・・・。
前に海外拠点向けのシステム作ったときは
Revised、Adjustなんて言葉使ってたけど
考えてみればそれは販売側の業務用語だったんだな。
会計用語じゃなかったんだ。勉強になります。
918:デフォルトの名無しさん
04/12/10 15:14:35
俺がやった貿易システムじゃ
Debit Note は請求書の事だったけどな。
専門用語英語は難しい。
ひが氏のもわかるし、915のもわかる、
いいとこどりとかバランスって事なんだろうけど
それだとあいまいだしね、難しい。
俺は全部サービスに突っ込んじゃいたいかな。
肥大化しても、サービス分割はしない。
ステップ数大きいクラスが出来たら、すまん、と謝る。
うーん、気持ち悪いな。ダメか。
919:デフォルトの名無しさん
04/12/10 17:35:52
>>918
なぜ全部サービスに突っ込みたいの?
920:デフォルトの名無しさん
04/12/10 17:38:20
>>912
なるほどあったまい～。
ついでに一つ聞いてもいい？
hsqlでIDENTITYとかデフォルト値使う時って、insert/update SQL書かなきゃだめ？
どうもいくらためしてもだめだったんだけど、何か良い方法はあるかな。
921:デフォルトの名無しさん
04/12/10 18:06:02
URLﾘﾝｸ(d.hatena.ne.jp)
ここのkoichik氏の意見読んで思ったけど、
「振る舞い」って言葉の定義もあやふやなんだな。
俺が言ってる「振る舞い」ってのは単純なgetter/setterを除いた
一般的なメソッドも含んでるんだけど、くーすの中の人たちは
一連の業務ロジックと同列に捕らえているってこと？
さすがにメインストリームになる業務ロジックはサービスオブジェクトに
きっちりとまとめるわけだけど、その中で各エンティティに振り分けられる処理は
振り分けたいってのが、そもそもやりたい事なわけですよ。
サービスオブジェクトの可読性を上げるためにってのと、
OO設計原則(くーすではdeprecatedなんだっけ?)に従うって意味でね。
で、現状どんな場合に振分けてるかっていうと、
１．各エンティティに閉じた振る舞い
(合計値の算出とか、プロパティAとプロパティBの状態からプロパティCを設定するとか)
２．1個以上のエンティティとの関連から各プロパティを設定する場合
(エンティティAとエンティティBからエンティティCの各プロパティを設定する、とか)
「請求書オブジェクト」に「今週の通貨レート情報」を渡して請求額を算出する場合も同じかな
この場合、業務ロジック、というかビジネスルールがドメインオブジェクトに存在する事になるわけだな。
ざっと見たところこんなところ。まだまだありそうな気がするけど、今忙しいし。
922:デフォルトの名無しさん
04/12/10 23:48:29
結論
やっぱエンティティBeanだね。EJB万歳。
923:デフォルトの名無しさん
04/12/11 01:01:13
>>920
IDENTITYに関しては、そのうち対応してくれるっぽい。
主キー値の自動採番機能つけるっつってたから。
デフォルト値はムリぽかなぁ。
924:デフォルトの名無しさん
04/12/11 01:05:26
ＤＢ側で自動採番してた場合に、キーをinsert文から外すために
いちいちSQLを書かないといけないという話題だとおもわれ。
別にS2Daoが採番しなくても、DBがやってくれるんだからいい。
925:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/11 01:51:22
>>921
一般的なメソッドと一連の業務ロジックの違いを定義しないと曖昧なままだと思われ
927:デフォルトの名無しさん
04/12/11 08:07:26
>>925
staticメソッドやエンティティに永続化メソッドを持たせるのはもう古いよ。
Torqueが否定されて、エンティティ(POJO)とDAOを分けるようになったわけだからね。
絶対的なものなどないのですよ。
データと振る舞いを1つにカプセル化するのが、
OOの絶対的な原則だと思っているならたぶんそれも間違い。
928:デフォルトの名無しさん
04/12/11 10:13:54
>>927
レイヤーに重きをおいてみてほしいんだが。
POJOとDAOを分けるのは、それぞれ明確にレイヤーが違うからだと思うよ。
自分も、Entity.store()なんてコードは書いたことないし。
929:デフォルトの名無しさん
04/12/11 10:18:41
ついでに書くと、
下の例で[A]のように書くのは、大いなる手続き型。
レコードの件数を数えるのに、集約関数を使わずにフェッチしてカウントアップするようなもの。
930:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/11 11:27:20
つまり、やっぱ構造化＆データと処理の分離こそが正しい道だった、と。
932:デフォルトの名無しさん
04/12/11 12:34:32
> 1でいくと決めたほうが、誰も迷わないし、レビューもしやすいってこと。
1～3のどれで書いてもコードの複雑さが同じならそうだけど、
実際には異なるだろう。
困難な決定を先送りにしているだけではないか?
933:デフォルトの名無しさん
04/12/11 12:36:16
>>924
そうそう、それです！現状はそれができないってことですね。
ではひがたんに要望。
insert/updateのアノテーションで、使用する(もしくは使用しない)プロパティを指定できたりすると嬉しいです。
publis static final String insert_IGNORECOLS = "id";
みたいな形で。
934:デフォルトの名無しさん
04/12/11 12:41:04
うおっ、いいねそのアノテーション！
update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。
935:デフォルトの名無しさん
04/12/11 15:03:56
>>930
1も2も3とれが最適かは、状況によって違うから、限定する意味無いんでない？
モジュール化、依存度の低い、ポリモーフィズムを活用した表現力の高さとかバランス見て。
だから、どれで行くと決めること自体が害悪。
936:888
04/12/11 16:32:34
そいじゃ、DTOには振舞い持たせない って言い切ってるくーすは害悪ってことで Final answer ?
ま、そりゃ1/3冗談だとして、限定する意味はあると思うよ。もちろんその状況毎で。
デザインパターンがそうであるようにね。
それを放棄してしまっているくーすの思想には、>>932も触れてるように、かなり危惧してる。
このままメジャーになっていったとして、ほんとにそんなんでいいのか？っていう不安が拭いきれない感じ。
まず、>>926の言うとおり、一般的なメソッドと業務ロジックの
違いをはっきりと定義することが重要だと思うね。俺自身、はっきり区別できてないわけだけど。
その定義がぼんやりとでも見えてきたら、一歩前進だと思う。
937:デフォルトの名無しさん
04/12/11 18:08:55
わざわざ早く寝たと不自然に断りながら
このスレ向けを日記で回答をする人は
実は早く寝てなんかおらず、
このスレに夢中になって書きんでいた
ことをひた隠しにしているだけという理解でよいでしょうか？
938:デフォルトの名無しさん
04/12/11 19:14:23
> そいじゃ、DTOには振舞い持たせない って言い切ってるくーすは害悪
うむ。大抵はそれでいいだろ。データ扱うときゃMapでいい。
ちょっとした四則演算で求まるもので、そんな重い処理じゃなくて、
ポリモーフィズムが生きるようなものだったらデータに振る舞い持たせてもよいと思う。
939:デフォルトの名無しさん
04/12/11 19:42:08
そういやCOBOLでやってたときはふつーのおばちゃんが仕様書をコードに変換してた。
あれはデータと処理が分離していればこそ、だったんだろうな。
もちろん業務の相応に細かな仕様書も必要だけど。
くーすって、コーディングをそのへんまで単純にすることを期待してるんかな。
940:デフォルトの名無しさん
04/12/11 21:41:54
>>939
> くーすって、コーディングをそのへんまで単純にすることを期待してるんかな。
ひが氏とか壺売り氏とかは盛んにそんなことを言ってるね。
↓みたいな立場とは対極だな。
URLﾘﾝｸ(www.freeml.com)
941:デフォルトの名無しさん
04/12/11 22:40:01
ん？
基本的にOOを深く理解した賢い人が能率良く仕事するツールだろ？
942:デフォルトの名無しさん
04/12/12 02:31:21
>>941
少なくともくーすの中の人の意識は>>939と同じ。
>>932の言う「困難な決定」を下っ端(もしくは中国)に
spell awayするための方法論。
943:デフォルトの名無しさん
04/12/12 11:48:23
ふつーのおばちゃんにやらせるぐらいなら、素直に機械にやらせればいいのに。
944:デフォルトの名無しさん
04/12/12 11:49:29
>>942
だとしたら、COBOL 85 >>>>>>>>> くーす だな。
945:デフォルトの名無しさん
04/12/12 12:32:31
>>942
困難な決定をさせないのがくーす。
>>936
業務ロジックとは、ユーザに対するサービス。
業務ロジックでないメソッドとは、ユーザに対するものではなく、
クラスの都合で必要なメソッド。
946:デフォルトの名無しさん
04/12/12 16:00:33
なるほど。
くーすはXPとは対照的に、人間のコミュニケーションの感性を信じてないんだな。
そういう人みたことあるけど、
どうせ分かり合えないから話してもムダなんだよという空気をドバドバ吐き出しちゃってて、
ちょっと痛々しいね。
オープンソースに逃げないで現実の人間のことを考えつづけたほうがいいと思うよ。
947:デフォルトの名無しさん
04/12/12 16:47:39
>>946
仕事なんか定型的にやるのが一番。
相手のことなんかより、自分の私生活のほうが大事。
948:デフォルトの名無しさん
04/12/12 17:22:09
>>947の華麗な私生活に乾杯。
949:デフォルトの名無しさん
04/12/12 17:29:20
つまり、ブランドの服を買いまくりってことかと。
950:デフォルトの名無しさん
04/12/12 17:35:42
>>946
> ちょっと痛々しいね。
おぬしの書き込みのほうが痛々しいなり。
>>288がいいことを書いているので参考にするなり。
人を信じないおぬしには、他人も人を信じないように見えるということなり。
951:デフォルトの名無しさん
04/12/12 17:57:42
>>936
まあ、そんなにくーすが嫌いならあんたが採用しなけりゃいいだけだと思うがね。
くーすをよりよいものにしようと考えていろいろ書き込んでるんじゃなく、
くーすそのものの考え方を否定しているみたいだけど、
人それぞれ考えかたがあるんだから採用する人しない人いていいんじゃない？
くーすの考え方に対して賛否あると思うけど、
２ちゃんで関係ない人たちと議論するより比嘉氏の日記にコメントでもして
一度議論したほうがいいんじゃないの？
ここで盛り上がって「やっぱくーすはだめだね」って結論になっても
くーす本は出るだろうし、あんたが危惧してるように
くーすがこのままの形でメジャーになるかもしれないでしょ。
952:デフォルトの名無しさん
04/12/12 17:58:14
>>936
＞＞一般的なメソッドと業務ロジックの違いをはっきりと定義することが重要だと思うね。
それができるぐらい技術力のある人材が豊富であれば
くーすなんて必要ないと思う。
できないから、全部DTOからはずしてしまうと決めることで
余計なあいまいさを省くという考え方もでてくるのではないかな？
豊富な技術力を有する高価なエンジニアを集めて
綺麗な設計、綺麗な実装でシステムを作るのもいいけど、
ビジネスとしてシステム開発をやるときには、
まず利益を上げられなければ話にならないから
生産性向上、コスト削減を考慮しなければならないと思う。
形式を決めてしまってあいまいさを省くことで
生産性を上げることができるかもしれないし、
単価の安い派遣会社に任せることでコストを削減できるかもしれないし
社内でくすぶっている技術力の低い人材を使うことで
社内で無駄になりがちなコストを有効活用できるかもしれない。
あんたのようなスキルの高い人材だけでシステム作るのであれば簡単だろうけど
スキルの低い人材を使わざるを得ない自分のような立場の人間としては
くーすのような考え方もありだと思う。
個人的には技術力の高い人材に対して数倍の「その他大勢」のプログラマを
ぶら下げて開発するような形にしていかなければ会社自体が衰退していくような
危機感を感じているよ。我が社では。
953:デフォルトの名無しさん
04/12/12 18:09:50
今回のスレはくーすﾈﾀで盛り上がってるね。
954:デフォルトの名無しさん
04/12/12 18:14:20
> 個人的には技術力の高い人材に対して数倍の「その他大勢」のプログラマを
> ぶら下げて開発するような形にしていかなければ会社自体が衰退していくような
> 危機感を感じているよ。我が社では。
とっとと潰れろボーケー
955:デフォルトの名無しさん
04/12/12 18:25:01
>>952
高スキル人員集約型と比べてくーすのコストは本当に低くなるのか。
あんたの会社で現実的に高スキル人員集約型が採用できるかは別問題。
>>954
いいツッコミだ。
956:デフォルトの名無しさん
04/12/12 18:27:54
なんだかなぁ
もっとね、漏れはソフトウェア開発ってのはカネがいいとかどうとか
そういうのを超えて、もっと使命感というか、スピリチュアルな
エネルギーに満ちた仕事だと思うわけ。キカイ的に安い人集めて
自動的にうまくいく、なんてそんな工業的なもんじゃない。
そういう場は、コミュニケーション、フィードバック、信頼関係を
保つことが必要で、それをやらなきゃどうせまともなソフトウェアが
作れるはずもない。
漏れ的にはそんなことも分からん死んでもそんなクソな会社のために働きたくない。
だから漏れは今無職なのだが！ いや、しかし分かる会社もそれなりにあるはずだと信じたい。
957:デフォルトの名無しさん
04/12/12 18:32:16
>>955
> 高スキル人員集約型と比べてくーすのコストは本当に低くなるのか。
少なくとも取替えは出来るようになるんじゃないかな。
スキルの高い奴が集まっていても健康な奴ばかりとは限らん。
少数精鋭って言葉に幻想を抱いている奴が多いが
ひとりに何かの事情が発生したら大変だぞ。
958:デフォルトの名無しさん
04/12/12 18:33:14
銀の弾丸探しの種は尽きまじ
959:デフォルトの名無しさん
04/12/12 18:33:35
>>956
藻前がそういう会社を作って人材を募集したらいいんだよ。
960:デフォルトの名無しさん
04/12/12 18:38:39
>>957
むしろ、くーすは上流工程に責務を集中させるから、XP 等に比べて
その部分の取替え可能性に関するリスクが高い、という見方もあると思うが。
961:デフォルトの名無しさん
04/12/12 18:42:53
>>956
ある漫画家が言うてました。
最高を求めて筆を入れ続けたいなら趣味か同人でやるべきで
それを職業とするなら金と納期によって品質を決めるべきだと
962:デフォルトの名無しさん
04/12/12 18:47:19
>>961
いいソフト作るには趣味しか無いと？
何いってんの。
趣味じゃフルタイム開発に費やせないじゃん。
そんなんでソフトウェア作れるかよ。
963:デフォルトの名無しさん
04/12/12 18:47:42
>>960
役割を階層化すると教育は容易くなるよ。それは上も下も関係ない。
図面ひく人、釘打つ人と分けたからって図面をひくという行為そのも
のの難易度が上がるわけじゃない。
寧ろ階層辺りの必要能力が限定される分、難易度は下がる。
964:デフォルトの名無しさん
04/12/12 18:48:28
>>949
ぐはぁっ．(;_;)
と騙ってみるテスト。
965:デフォルトの名無しさん
04/12/12 18:50:17
>>962
予算と納期に応じて要求を満たす動くものを作れと言ってる。
良い悪いなんて話はしてない。
敢えて良い悪いで語るなら、当初の予算を超えたり、納期に
遅れたり、そもそも要求を満たさなかったり、ましてや動かな
かったりするソフトウェアは悪いソフトウェアだｗ
966:デフォルトの名無しさん
04/12/12 18:53:20
>>946
XPが人を信じてるなら何でペアプロなんてやらせるんだ。俺のコードを信じてないからだろ。
何で毎日ミーティングさせるんだ。3ヵ月後にちゃんと持ってくるんだからほっとけよ。
なんてことを言ってるのと似たような発言だな。
お前の言うコミュニケーションの感性って具体的に何よ？
それよりお前XPやってるのか？
967:デフォルトの名無しさん
04/12/12 18:54:02
>>962
キミの趣味にフルタイムの給料を出せと？
968:デフォルトの名無しさん
04/12/12 18:55:19
>>965
わかった。
とにかく急いで作らなきゃいけなくて、
まともなコード書ける人数がいないというのが現実なら、
そもそもその仕事を引き受けるべきではなかったのだ。
現実的な解はくーすを使うことではなく、客に謝りにいくことである。
そうしないと被害大きくするだけ。
969:デフォルトの名無しさん
04/12/12 18:56:44
休日にも関わらず盛り上がってますねー！
今日の ﾈﾀ 師は >>946 に ｹﾃｰｲ ！
970:デフォルトの名無しさん
04/12/12 18:58:42
>>946=>>969
という認識でよろしいでしょうか。
971:デフォルトの名無しさん
04/12/12 19:01:46
>>956はﾈﾀだ、気をつけろ!!
…って遅かったか。
972:デフォルトの名無しさん
04/12/12 19:16:14
>>968
「まともなコード書ける人数がいない」などという条件は何処から引っ張って来た？
勝手に条件加えて手前勝手な結論に至って満足か？
973:デフォルトの名無しさん
04/12/12 19:21:09
ﾈﾀﾆ ｾｷｽﾞｲﾊﾝｼｬ ｶｺﾜﾙｲ
974:デフォルトの名無しさん
04/12/12 19:33:25
>>972
もちろん満足です！
釣れたから（藁
975:デフォルトの名無しさん
04/12/12 19:33:34
まぁ、Seaser自体がネタだからな
976:デフォルトの名無しさん
04/12/12 19:35:47
そうでつね。Seaserはﾈﾀでつね。
Seasarはﾈﾀじゃないでつけどね。
977:デフォルトの名無しさん
04/12/12 19:37:24
さあ久々に盛り上がってまいりました！
>>946と>>956のコンビプレーのおかげです！！
978:デフォルトの名無しさん
04/12/12 19:42:38
>>962
> いいソフト作るには趣味しか無いと？
参考までにどんなソフトを作っているのか教えてくれないか？
979:デフォルトの名無しさん
04/12/12 19:43:27
>977
>>946と>>956だがネタじゃねーよ
980:デフォルトの名無しさん
04/12/12 19:45:19
何と！>>946=>>956だそうです！
いよいよ盛り上がってまいりました！！
ﾈﾀ師マンセーｗ
981:デフォルトの名無しさん
04/12/12 19:49:15
>>979
ネタであるか否かを決定するのは本人の主観ではない。
スレの空気だ。
お気の毒。
982:デフォルトの名無しさん
04/12/12 19:53:02
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ >>946=>>956ﾀﾝ新ﾈﾀまだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
つーか、誰か新スレ立てろ。スレタイスペルミスすんなよ。
983:デフォルトの名無しさん
04/12/12 19:58:01
>>979
騙るな。俺が本物の>>946=>>956だ。
よーしこれからもどんどんﾈﾀ作っちゃうぞー。
984:デフォルトの名無しさん
04/12/12 20:01:40
ほんとに946=956だとしたらさ俺ちょっと
思い当たる奴いるんでちょっと引いてしまう。
いやな、デザパタがどうとか色々というんだけど
まあ何というかなヒッキーでなコミュニケーション
取れない奴だったんだなこれが。本とかいっぱい
読んでたよ。詳しい奴ではあった。
でなしょぼいアプリ一つ満足に期限どおりに作れなくて
それをリーダーとか営業とかのせいにばかりしててさ
ソフト開発はこうあるべきなんだとか力説してたよ。
でも社内の女の子とかからもきしょがられてさ。
結局辞めたんだけどさ。それこそくーす仕込んで使いたく
なるような奴だったんだが、まさかお前じゃないよな956
985:デフォルトの名無しさん
04/12/12 20:20:27
結論：COBOL最強。
986:デフォルトの名無しさん
04/12/12 21:04:40
>>966
> >>946
> XPが人を信じてるなら何でペアプロなんてやらせるんだ。俺のコードを信じてないからだろ。
ペアプロの目的のひとつはレビュー。
どんなベテランプログラマのコードだって、レビューの対象となるでしょう、ふつう。
> 何で毎日ミーティングさせるんだ。3ヵ月後にちゃんと持ってくるんだからほっとけよ。
フィードバックを素早く行いたいから、とかかな。
987:デフォルトの名無しさん
04/12/12 21:06:26
次のスレタイは「ネタコンテナSeas"e"r2」でいこう。
988:デフォルトの名無しさん
04/12/12 21:16:33
>>986
つまりコミュニケーション自体が目的ではないってことだな。レビューやフィードバックをきちんと行うためのツールの一つがコミュニケーションということだ。
コミュニケーションが不要とは言わんが、コミュニケーションを連呼する奴には職場の付き合いに一体何を期待しているのかと問いたくなる。
さっさと仕事終わらせてプライベートの付き合いをしにいくほうが俺はいい。仕事が趣味の奴は会社で深い付き合いをしたいのかも知れないけどな。
989:デフォルトの名無しさん
04/12/12 22:18:12
>>988
アジャイル厨がよく言う「コミュニケーション」の意味合いを知るには
以下の本を読むといい。付き合いとか馴れ合いみたいな意味じゃないよ。
URLﾘﾝｸ(www.amazon.co.jp)
ちなみに監訳者の1人がくーすの中の人だったりするから事態がややこしい。
990:デフォルトの名無しさん
04/12/12 22:19:26
て言うか、コミュニケーションの方法まで方法論に盛り込もうってのは
パターン化されてないとコミュニケーションすらとれない奴の願望か？
挨拶は文言じゃないテンションだ！
「ぉはよぅ(ﾎﾞｿ)」とか言うくらいなら黙ってる方がマシだ。
「はよう」でもいいから、顔を上げて声を張れ。ボソボソ言うなキモイ。
>>988
職場だろうと自宅だろうと楽しめる時には場所を選ばず楽しみたい。
て言うか、アフターは無しの人？社外の人間と予定合わすの難しくな
いか？
991:デフォルトの名無しさん
04/12/12 22:45:11
わかった。
申し訳ない。
もう傷つけあうのはやめよう。
目的はいっしょなはずだ。
Seasarという頭でっかちともとらえかねられないものに関心を示す同士として、有益なことを語ろうではないか。
992:デフォルトの名無しさん
04/12/12 22:56:54
Seasarのどこが頭でっかちなのか
わからんが言いたいことはわかった。
まずは藻舞から有益なことを語ってくれ。
993:デフォルトの名無しさん
04/12/12 23:01:26
>>990
何でそう極端になるんだｗ
普通に同僚と飲みに行ったりもするよ。
そんなに気張ってコミュニケーションと
言わないと仕事が回らんというのが
わかんないだけだ。
994:デフォルトの名無しさん
04/12/12 23:20:20
いい感じで盛り上がってるね。
で、次スレまだ？
995:デフォルトの名無しさん
04/12/12 23:38:18
誰もやってくんないので建てますた。
ｽﾚﾘﾝｸ(tech板)
996:デフォルトの名無しさん
04/12/12 23:41:34
>>995
乙
997:デフォルトの名無しさん
04/12/13 12:14:53
>>961
その漫画家がウソ言ってるなと思うのは、
職業で出す結果は大抵妥協の産物であるというのなら、
そもそも漫画家やる意味あんのか、ってあたりだな。
妥協するというならとことん妥協してもっと安定した仕事に就いてはいかがか。
やはり、漫画を描くことに意味を見出してるからやるんだと思うんだよ。
998:デフォルトの名無しさん
04/12/13 12:31:37
妥協って、とことんやるもんじゃないわな。
とことんやらないから妥協という。
それに961は妥協って事は書いてませんね。
品質を考える上で、金と納期を頭に入れるべきとだけ
いってて、それはプロの仕事として当たり前ですね。
そういうプロの仕事に意味を見出しても、悪くはないですよね。
勿論、とことんやるならそれもまた意味はあるけど。
ガロとかあるし。もうないの？
999:デフォルトの名無しさん
04/12/13 13:11:37
>>997
妥協＝安定と思っているあたりがおめでたい
1000:デフォルトの名無しさん
04/12/13 13:12:18
100get!
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。