[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 11/04 13:44 / Filesize : 259 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

国産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/

710 名前:デフォルトの名無しさん mailto:sage [04/11/22 10:19:42]
とても客商売の発想とは思えません。

711 名前:デフォルトの名無しさん mailto:sage [04/11/22 11:39:06]
UMLのドキュメントを客に見せるって発想自体まともじゃないよ。
オブジェクト指向設計とかもそう。
どこから客に対してブラックボックスで作るかをはっきりさせとかないと客に不信感を与えたり、使用があいまいになったりする可能性があるからね。
開発が楽になるとか再利用性が高まるからって、客が理解できないドキュメント作ったりしてそれを検証してもらうなんざ愚の骨頂だね。

しかし2ちゃんでまともなカキコを期待してる705は痛いな。
ここは703みたいな負け犬の遠吠えみたいな書き込みで成り立ってるんだから。

712 名前:デフォルトの名無しさん mailto:sage [04/11/22 12:08:04]
燃料投下!

しかしインパクトなし。
だれか核爆弾並のインパクトのある爆弾投下してよ。
>>429みたいな笑える奴でもいいからさ

713 名前:デフォルトの名無しさん mailto:sage [04/11/22 12:10:28]
>>711
安いルアーですね。

714 名前:デフォルトの名無しさん mailto:sage [04/11/22 12:19:50]
>>711
UMLのドキュメントを客が理解できないって発想自体まともじゃないよ。

715 名前:仁鶴 mailto:sage [04/11/22 12:35:52]
客はUMLドキュメントをざこば相談員理解できない、上沼相談員理解できる、
さて法律はどないなっておりますでしょか

716 名前:デフォルトの名無しさん mailto:sage [04/11/22 14:06:49]
>>714
Webを使いたくてPCを買いに行ったらCPUのスペックがとかメモリーの容量がどうの言われて知るかそんなもん!っておもっちゃ駄目なんだね。

717 名前:デフォルトの名無しさん mailto:sage [04/11/22 15:18:58]
まあるいユースケースを四角くクラス図におさめる。

ダメだ、715にはかなわん。

718 名前:デフォルトの名無しさん mailto:sage [04/11/22 17:04:48]
>>716
わけわからん



719 名前:デフォルトの名無しさん mailto:sage [04/11/22 17:07:36]
>>714
そうなの?
事務の流れを理解している事務員のおばちゃんとかにドキュメント見せても
理解していただけないんですけど。。。

720 名前:デフォルトの名無しさん mailto:sage [04/11/22 17:13:42]
711の出だしがテンプレになってんです。

ああ説明はずかしい。

721 名前:デフォルトの名無しさん mailto:sage [04/11/22 20:40:06]
>>720
嘘ついたのか?

722 名前:デフォルトの名無しさん mailto:sage [04/11/22 22:52:11]
ところで、サーバーじゃないのに「軽量JavaAPサーバー」などと誤解をふんだんにあたえつつ実体を伝えれてない言葉で報道しつづけるIT Proはどうにかしなくてもいいのか?
伝わらないキャッチフレーズほど邪魔なものはないと思うよ。

723 名前:デフォルトの名無しさん mailto:sage [04/11/22 23:12:11]
>722
ITProの書く記事を真に受ける奴なんて居やしない、とタカを括ってるのかもね。
名前だけは通りがいいから対処しといたほうがよろしいと思うんだが。

724 名前:デフォルトの名無しさん mailto:sage [04/11/22 23:18:26]
APサーバーで通ってしまったら、APサーバーを作るハメになってしまいそうだ。

725 名前:リリース情報 mailto:sage [04/11/22 23:49:57]
S2.1.2 リリース
d.hatena.ne.jp/higayasuo/20041122#1101117217

S2OpenAMF 1.0.6 リリース
d.hatena.ne.jp/hoso-kawa/20041122#1101105464

726 名前:デフォルトの名無しさん mailto:sage [04/11/23 01:18:25]
道具はUMLでもE-R図でもいいんだが、客と会話するのに概念モデル的なものは
必要だろう。例えば渡辺幸三氏の本にあるようなやつね。

ひが氏がその辺を意識してないわけはないんだけど、くーす関係の記述を見ると、
あたかも所与の概念モデルの完成を前提として作業が始まってるかのような印象を受ける。

727 名前:デフォルトの名無しさん mailto:sage [04/11/23 01:48:31]
そう言えば渡辺幸三氏は羽生氏とNiftyで論争したことがあったな。争点はすっかり忘れてしまったけど。



728 名前:デフォルトの名無しさん mailto:sage [04/11/23 01:54:04]
>>727
長老乙。



729 名前:デフォルトの名無しさん mailto:sage [04/11/23 02:43:18]
で、マジカってどうなのよ?

730 名前:デフォルトの名無しさん mailto:sage [04/11/23 02:49:54]
>>726

ひが氏はAsIsをER分析してモデル構築で事足れり、と判断しているように見えるけど、モデル屋から見たら異論が出そうな点ではあるな。

まあ、モデル屋が考えたToBeなんかまともに機能するか分からない、顧客のAsIsなら非効率的だとしても現状業務通りに確実に動くと考えてるのかも知れん。

731 名前:デフォルトの名無しさん mailto:sage [04/11/23 03:12:43]
ttp://d.hatena.ne.jp/shot6/20041122#p3

SeasarをSpringに完全に置換可能な罠。
「英語化=競合フレームワークの目に触れる」
ことを意識しなくていいのかな。

i18nとは関係なかったね。ネタにしてスマソ。>中の人

732 名前:デフォルトの名無しさん mailto:sage [04/11/23 03:16:48]
確かに。

S2.1+S2Dao+S2JSFの統合フレームワークとして世に問うのが差別化としては一番有効か。



733 名前:デフォルトの名無しさん mailto:sage [04/11/24 02:10:13]
ttp://d.hatena.ne.jp/shot6/20041123#p3

> # higayasuo 『それは、結構ありますね。
> エンティティの設計書(テーブル設計)がきちんと
> してれば普通にできます。
> ユーザには、エンティティ設計書は(一応)見せますが、
> レビューという観点ではないです。
> だってレビューできないですから。』

ひが君は下っ端も顧客も馬鹿にし過ぎだと思う。
馬鹿にしたほうが当面の仕事が回るのは百も承知。

734 名前:デフォルトの名無しさん mailto:sage [04/11/24 02:52:31]
システム側の文法でかかれた設計書を納品して
とにかく承認だけ取らせてそれを担保にして
後で変更があれば別見積りふっかけるって方が
顧客をバカにしてる、という言い方もあるな。

735 名前:デフォルトの名無しさん mailto:sage [04/11/24 03:08:18]
>>734みたいな脊髄反射荒らしはいらない。

736 名前:デフォルトの名無しさん mailto:sage [04/11/24 06:16:28]
どっちが脊髄反射か傍目にはよく分からない


737 名前:デフォルトの名無しさん mailto:sage [04/11/24 10:01:09]
ここには脊髄反射の荒らししかいない

738 名前:デフォルトの名無しさん [04/11/24 10:34:36]
仕様で一言も触れていないアイコンのサイズと色が気に食わないと
バグだバグだと騒ぐからまったくダメだね。



739 名前:デフォルトの名無しさん mailto:sage [04/11/26 11:52:06]
>>738
スレ違い?

740 名前:デフォルトの名無しさん mailto:sage [04/11/27 05:29:29]
Seasar 2.1.xからservlet.jarが必須になったのでWEBアプリ以外で意味も無く必要になるのはどうか?

って、前にも書いてるやついたけど、
フレームワークなど使う場合、

フレームワークで必要とされているが、用途によっては必要ないライブラリなんてほかにもいくらでもあるんじゃないか?

と、思うのだが何故servlet.jarに関してだけ過敏になるのかなあ?

まさか、
servlet.jar=WEBアプリ専用
って認識なのかな?

741 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:52:52]
>>740
あんまりキモチよくはない。

742 名前:デフォルトの名無しさん mailto:sage [04/11/27 12:56:19]
>>741
servlet.jar以外のクラスだったら関係ないのが紛れ込んでてもキモチ悪くはないのですか?

私はあんまり詳しくないのでservlet.jarもcommons-logging.jarもlog4j.jarも自作を含めたその他のライブラリもただのライブラリとして扱っているんで何が混ざっていても特に気にならないんだけど...
どの辺がキモチよくないのかスキルのある人の考え方を聞かせて欲しいですね。

743 名前:デフォルトの名無しさん mailto:sage [04/11/27 13:52:20]
>>742
微妙に煽り調子イクナイ
いい話だと思うから冷静に行こう

744 名前:デフォルトの名無しさん mailto:sage [04/11/27 15:30:29]
servlet.jarでweb専用じゃないの?


745 名前:デフォルトの名無しさん mailto:sage [04/11/27 17:05:12]
servlet.jarの話

まあ、
WEBアプリでも
C/Sアプリでも
スタンドアロンのアプリでも使えるライブラリを提供すれば、
必然的に無駄と思われるライブラリを含んでしまうんだからしょうがないじゃん。

俺もライブラリに何があってもそれほど気にしないし、
DIコンテナやらフレームワークが欲しい機能を提供してくれるんだったら
どんなクラスをimportしてても気にならないけどね。
それで信頼性や処理性能を損なうのであれば問題だけど。

746 名前:デフォルトの名無しさん mailto:sage [04/11/27 17:41:22]
ばかでかいわけでもあるまいし。

747 名前:デフォルトの名無しさん mailto:sage [04/11/27 19:29:32]
servlet-api.jarのサイズは91,627 バイトでつ

748 名前:デフォルトの名無しさん mailto:sage [04/11/27 20:58:05]
俺のところのは75,126 バイトだ



749 名前:デフォルトの名無しさん mailto:sage [04/11/28 01:44:31]
>>742
主観の話を議論しても意味はない。
気持ち悪いモンは気持ち悪い。

750 名前:デフォルトの名無しさん mailto:sage [04/11/28 08:54:43]
>>749
なんだ、理由は無いのか

751 名前:デフォルトの名無しさん mailto:sage [04/11/28 23:27:50]
そりゃ理由なんてねえだろ。

servlet.jarがあるのが気持ち悪いんだったら前のバージョン使ってりゃいいんだよ。
前のバージョンだって十分使えるんだから。
それか、自分で機能削除してservlet.jarを使わないようにすればいいだけ。


752 名前:デフォルトの名無しさん mailto:sage [04/11/29 00:17:07]
servlet.jarから必要なクラスだけぶっこ抜いたらいいんでは。
どれが必要なクラスなのか知らないけど。

753 名前:デフォルトの名無しさん mailto:sage [04/11/29 00:53:47]
>>752
そっちのほうが気持ち悪くねーかw

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さんていい人そうだw

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:sage [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:sage [04/12/06 23:35:18]
>>808
マルチプロセッサだと、スレッドセーフまわりのバグに当たり易くなる。

827 名前:デフォルトの名無しさん mailto:sage [04/12/07 00:21:00]
>>826
つか、シングルプロセッサだと当たりにくいよね。

昔、貧乏プロジェクトでテスト環境にマルチプロセッサの環境準備できなかったことがあて。
負荷テストで相当の多重度かけて数日動かして問題なかったのに、
マルチプロセッサの本番サーバでリリースしたら初日にいきなりAccessViolationしやがったし。
負荷テストの1/10程度の同時アクセスしかなかったんだけど出やすいんだよね。
当然だけど。

自前のものならまだしも、下請けに作らせたものだったから、
大問題になっちゃったよ。
しかも、仕様変更だとかふざけた事言いやがって!
ああ、嫌なこと思い出したなぁ。

だからうちは下請けに仕事やらせるときはマルチプロセッサ環境での負荷検証してから納品させるようにした。
下請けにとってはやな客なんだろうなあ。

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:sage [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:sage [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よりさらにタチが悪い気がするな。
立ち位置がどうしよもなく中途半端だし、MSだしな。

872 名前:デフォルトの名無しさん mailto:sage [04/12/08 23:21:17]
>>869
で、結論はPerlということか。

873 名前:デフォルトの名無しさん mailto:sage [04/12/08 23:25:07]
>MSだしな。

ん?Microsoft製だと何かまずいの?
Microsoftのソフト開発環境はとても使いやすいが。

874 名前:デフォルトの名無しさん mailto:sage [04/12/08 23:38:46]
>>867
サーバサイド開発がネタ

というか、某板某スレの、「Javaはネタ→禿どう」のコンビの人みたいだね。

875 名前:デフォルトの名無しさん mailto:sage [04/12/09 00:05:40]
>873
871じゃないが、
売れてるだけあっていいところは沢山あるんだけどさ。
寄らば大樹の陰が行き過ぎて変なところから圧力かかるのがMSのやなとこ。
成り行きでMS”ばかり”やるようになると、ほかの良い物を導入しようとしたとき
「それMSじゃないからヤダ」って馬鹿を言う奴がいつのまにか周り中にいたりする。

せっかく自由社会にいるのに自分から独裁者に仕えるのは悪趣味だと思うぞ。


>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が失敗だというのが誤りであれば、3行目を除いては正しいとはいえなくなるわけだが。

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
粘着に粘着するなよw

897 名前:デフォルトの名無しさん mailto:sage [04/12/09 23:51:17]
>>895
DTOに持たせる振る舞いはテストが面倒でもいいんだよ!

898 名前:デフォルトの名無しさん mailto:sage [04/12/09 23:56:31]
   ∩___∩         |
   | ノ\     ヽ        |
  /  ●゛  ● |        |
  | ∪  ( _●_) ミ       j
 彡、   |∪|   |        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
確かに難しい問題だとは思うけど、
これから世界に向けて発信して行こうっていうプロジェクトの思想としては、
ちょっとお粗末な気がするんだよ。

俺、10年以上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なんだっけ?)に従うって意味でね。

で、現状どんな場合に振分けてるかっていうと、

1.各エンティティに閉じた振る舞い
  (合計値の算出とか、プロパティAとプロパティBの状態からプロパティCを設定するとか)

2.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]
DB側で自動採番してた場合に、キーを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
まあ、そんなにくーすが嫌いならあんたが採用しなけりゃいいだけだと思うがね。

くーすをよりよいものにしようと考えていろいろ書き込んでるんじゃなく、
くーすそのものの考え方を否定しているみたいだけど、
人それぞれ考えかたがあるんだから採用する人しない人いていいんじゃない?

くーすの考え方に対して賛否あると思うけど、
2ちゃんで関係ない人たちと議論するより比嘉氏の日記にコメントでもして
一度議論したほうがいいんじゃないの?
ここで盛り上がって「やっぱくーすはだめだね」って結論になっても
くーす本は出るだろうし、あんたが危惧してるように
くーすがこのままの形でメジャーになるかもしれないでしょ。




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
予算と納期に応じて要求を満たす動くものを作れと言ってる。
良い悪いなんて話はしてない。
敢えて良い悪いで語るなら、当初の予算を超えたり、納期に
遅れたり、そもそも要求を満たさなかったり、ましてや動かな
かったりするソフトウェアは悪いソフトウェアだw

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だそうです!
いよいよ盛り上がってまいりました!!
ネタ師マンセーw

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
何でそう極端になるんだw
普通に同僚と飲みに行ったりもするよ。
そんなに気張ってコミュニケーションと
言わないと仕事が回らんというのが
わかんないだけだ。

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 名前:1001 [Over 1000 Thread]
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<259KB

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