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
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。