04/11/21 23:47:23
S2 Setup
JDK 1.4 or later is required to use S2. It is confirmed to work
correctly with Eclipse 3.
Import into Eclipse "seasar2" directory which is extracted from
"S2xxx.zip".
The files listed below are required to be in the CLASSPATH
in order to use Seasar2's fundamental functions like S2Container
and S2AOP.
[snip]
To use the S2 extensions(S2JTA, S2DBCP, S2JDBC, S2Unit, S2Tx,
S2DataSet), additional files are required:
[snip]
HSQLDB is distributed with S2 for your testing which needs
database functions. Before running your code including database
access, HSQLDB must be started. To start HSQLDB, double click
"bin/runHsqldb.bat".(on Windows) "lib/hsqldb.jar" is required
only in case using HSQLDB.
Oracle can be used to demonstrate S2 functions for database
access. "sql/demo-oracle.sql" is in the distribution.
After executing the sql statements with SQL*Plus or another
tools, rewrite XADataSourceImpl settings in "j2ee.dicon" to
match your environment.
699:デフォルトの名無しさん
04/11/21 23:58:43
>>698
なんかへん
700:デフォルトの名無しさん
04/11/22 00:00:09
現行の英語ドキュメントを読むと、普段英語を読むときに使うのとは
別の部分の脳細胞が刺激されるような妙な気分になる。
何かの陰謀か?
701:デフォルトの名無しさん
04/11/22 00:01:23
>>699は現行翻訳者。
702:デフォルトの名無しさん
04/11/22 01:48:54
だんだんと変な英語をさらすスレに変身中...
703:デフォルトの名無しさん
04/11/22 04:01:43
ひがさんの手法が、私が思うように、無価値であるなら、問題は、彼が自分の才能で何をするべきだったか、ではないだろうか。
なにしろこんなにまずい手法を作るには、明らかに、一連の実に風変わりな才能が必要だったから。
704:デフォルトの名無しさん
04/11/22 07:07:21
>>703
なんかへん
705:デフォルトの名無しさん
04/11/22 08:12:15
>>703は価値ある手法を持っていないか、
持っていてもひが氏のように晒す度胸が無いかのどちらかだな。
どっちにしても隠れて吠えるような事じゃなくて、
もっと具体的で建設的な書き込みできないもんかねえ。
706:デフォルトの名無しさん
04/11/22 08:19:05
たしかにUMLはお客様に理解していただくのはちょっと厳しい。
ユースケース図を見せても、
「ここは人じゃないから人の絵を使うのはやめてくれ」
とか
「この丸の中にもっと具体的に書いてくれ」
とか
「例外処理って書いてあるけど、この処理も正常な処理なんだから
例外処理って書くな」
とか結構厳しいね。
UMLは書くのにも読むのにもUMLに関する理解度を高めないといけない。
ってことは
お客様にもUMLの本でも読んでもらってUML記述が理解できるようになってもらうのか？
それともお客様に対して別のドキュメントを準備するのか？
それともお客様には確認とらずに設計進めるのか？
UMLを使わなくてお客様向けの開発ドキュメントが作れるのはいいんじゃないかな。
707:デフォルトの名無しさん
04/11/22 08:50:56
>>706
> ここは人じゃないから人の絵を使うのはやめてくれ
人の絵を使わなければいい
> この丸の中にもっと具体的に書いてくれ
具体的に書いた仕様書のページを書いておけばいい
> 例外処理って書くな
別の言葉を使えばいい
708:デフォルトの名無しさん
04/11/22 08:58:00
長期的にやるなら、UMLの本を読んでもらうとかのレベルじゃなくて、ちゃんとセミナーしてちょっとしたUMLが書けるくらいの程度にする。
709:デフォルトの名無しさん
04/11/22 09:14:17
710:デフォルトの名無しさん
04/11/22 10:19:42
とても客商売の発想とは思えません。
711:デフォルトの名無しさん
04/11/22 11:39:06
UMLのドキュメントを客に見せるって発想自体まともじゃないよ。
オブジェクト指向設計とかもそう。
どこから客に対してブラックボックスで作るかをはっきりさせとかないと客に不信感を与えたり、使用があいまいになったりする可能性があるからね。
開発が楽になるとか再利用性が高まるからって、客が理解できないドキュメント作ったりしてそれを検証してもらうなんざ愚の骨頂だね。
しかし２ちゃんでまともなカキコを期待してる705は痛いな。
ここは703みたいな負け犬の遠吠えみたいな書き込みで成り立ってるんだから。
712:デフォルトの名無しさん
04/11/22 12:08:04
燃料投下！
しかしインパクトなし。
だれか核爆弾並のインパクトのある爆弾投下してよ。
>>429みたいな笑える奴でもいいからさ
713:デフォルトの名無しさん
04/11/22 12:10:28
>>711
安いルアーですね。
714:デフォルトの名無しさん
04/11/22 12:19:50
>>711
UMLのドキュメントを客が理解できないって発想自体まともじゃないよ。
715:仁鶴
04/11/22 12:35:52
客はUMLドキュメントをざこば相談員理解できない、上沼相談員理解できる、
さて法律はどないなっておりますでしょか
716:デフォルトの名無しさん
04/11/22 14:06:49
>>714
Webを使いたくてPCを買いに行ったらCPUのスペックがとかメモリーの容量がどうの言われて知るかそんなもん！っておもっちゃ駄目なんだね。
717:デフォルトの名無しさん
04/11/22 15:18:58
まあるいユースケースを四角くクラス図におさめる。
ダメだ、715にはかなわん。
718:デフォルトの名無しさん
04/11/22 17:04:48
>>716
わけわからん
719:デフォルトの名無しさん
04/11/22 17:07:36
>>714
そうなの？
事務の流れを理解している事務員のおばちゃんとかにドキュメント見せても
理解していただけないんですけど。。。
720:デフォルトの名無しさん
04/11/22 17:13:42
711の出だしがテンプレになってんです。
ああ説明はずかしい。
721:デフォルトの名無しさん
04/11/22 20:40:06
>>720
嘘ついたのか？
722:デフォルトの名無しさん
04/11/22 22:52:11
ところで、サーバーじゃないのに「軽量JavaAPサーバー」などと誤解をふんだんにあたえつつ実体を伝えれてない言葉で報道しつづけるIT Proはどうにかしなくてもいいのか？
伝わらないキャッチフレーズほど邪魔なものはないと思うよ。
723:デフォルトの名無しさん
04/11/22 23:12:11
>722
ITProの書く記事を真に受ける奴なんて居やしない、とタカを括ってるのかもね。
名前だけは通りがいいから対処しといたほうがよろしいと思うんだが。
724:デフォルトの名無しさん
04/11/22 23:18:26
APサーバーで通ってしまったら、APサーバーを作るハメになってしまいそうだ。
725:リリース情報
04/11/22 23:49:57
S2.1.2 リリース
URLﾘﾝｸ(d.hatena.ne.jp)
S2OpenAMF 1.0.6 リリース
URLﾘﾝｸ(d.hatena.ne.jp)
726:デフォルトの名無しさん
04/11/23 01:18:25
道具はUMLでもE-R図でもいいんだが、客と会話するのに概念モデル的なものは
必要だろう。例えば渡辺幸三氏の本にあるようなやつね。
ひが氏がその辺を意識してないわけはないんだけど、くーす関係の記述を見ると、
あたかも所与の概念モデルの完成を前提として作業が始まってるかのような印象を受ける。
727:デフォルトの名無しさん
04/11/23 01:48:31
そう言えば渡辺幸三氏は羽生氏とNiftyで論争したことがあったな。争点はすっかり忘れてしまったけど。
728:デフォルトの名無しさん
04/11/23 01:54:04
>>727
長老乙。
729:デフォルトの名無しさん
04/11/23 02:43:18
で、マジカってどうなのよ？
730:デフォルトの名無しさん
04/11/23 02:49:54
>>726
ひが氏はAsIsをER分析してモデル構築で事足れり、と判断しているように見えるけど、モデル屋から見たら異論が出そうな点ではあるな。
まあ、モデル屋が考えたToBeなんかまともに機能するか分からない、顧客のAsIsなら非効率的だとしても現状業務通りに確実に動くと考えてるのかも知れん。
731:デフォルトの名無しさん
04/11/23 03:12:43
URLﾘﾝｸ(d.hatena.ne.jp)
SeasarをSpringに完全に置換可能な罠。
「英語化=競合フレームワークの目に触れる」
ことを意識しなくていいのかな。
i18nとは関係なかったね。ネタにしてスマソ。>中の人
732:デフォルトの名無しさん
04/11/23 03:16:48
確かに。
S2.1+S2Dao+S2JSFの統合フレームワークとして世に問うのが差別化としては一番有効か。
733:デフォルトの名無しさん
04/11/24 02:10:13
URLﾘﾝｸ(d.hatena.ne.jp)
> # higayasuo 『それは、結構ありますね。
> エンティティの設計書(テーブル設計)がきちんと
> してれば普通にできます。
> ユーザには、エンティティ設計書は(一応)見せますが、
> レビューという観点ではないです。
> だってレビューできないですから。』
ひが君は下っ端も顧客も馬鹿にし過ぎだと思う。
馬鹿にしたほうが当面の仕事が回るのは百も承知。
734:デフォルトの名無しさん
04/11/24 02:52:31
システム側の文法でかかれた設計書を納品して
とにかく承認だけ取らせてそれを担保にして
後で変更があれば別見積りふっかけるって方が
顧客をバカにしてる、という言い方もあるな。
735:デフォルトの名無しさん
04/11/24 03:08:18
>>734みたいな脊髄反射荒らしはいらない。
736:デフォルトの名無しさん
04/11/24 06:16:28
どっちが脊髄反射か傍目にはよく分からない
737:デフォルトの名無しさん
04/11/24 10:01:09
ここには脊髄反射の荒らししかいない
738:デフォルトの名無しさん
04/11/24 10:34:36
仕様で一言も触れていないアイコンのサイズと色が気に食わないと
バグだバグだと騒ぐからまったくダメだね。
739:デフォルトの名無しさん
04/11/26 11:52:06
>>738
スレ違い？
740:デフォルトの名無しさん
04/11/27 05:29:29
Seasar 2.1.xからservlet.jarが必須になったのでWEBアプリ以外で意味も無く必要になるのはどうか？
って、前にも書いてるやついたけど、
フレームワークなど使う場合、
フレームワークで必要とされているが、用途によっては必要ないライブラリなんてほかにもいくらでもあるんじゃないか？
と、思うのだが何故servlet.jarに関してだけ過敏になるのかなあ？
まさか、
servlet.jar=WEBｱﾌﾟﾘ専用
って認識なのかな？
741:デフォルトの名無しさん
04/11/27 11:52:52
>>740
あんまりキモチよくはない。
742:デフォルトの名無しさん
04/11/27 12:56:19
>>741
servlet.jar以外のクラスだったら関係ないのが紛れ込んでてもキモチ悪くはないのですか？
私はあんまり詳しくないのでservlet.jarもcommons-logging.jarもlog4j.jarも自作を含めたその他のライブラリもただのライブラリとして扱っているんで何が混ざっていても特に気にならないんだけど．．．
どの辺がキモチよくないのかスキルのある人の考え方を聞かせて欲しいですね。
743:デフォルトの名無しさん
04/11/27 13:52:20
>>742
微妙に煽り調子ｲｸﾅｲ
いい話だと思うから冷静に行こう
744:デフォルトの名無しさん
04/11/27 15:30:29
servlet.jarでweb専用じゃないの？
745:デフォルトの名無しさん
04/11/27 17:05:12
servlet.jarの話
まあ、
WEBアプリでも
C/Sアプリでも
スタンドアロンのアプリでも使えるライブラリを提供すれば、
必然的に無駄と思われるライブラリを含んでしまうんだからしょうがないじゃん。
俺もライブラリに何があってもそれほど気にしないし、
DIコンテナやらフレームワークが欲しい機能を提供してくれるんだったら
どんなクラスをimportしてても気にならないけどね。
それで信頼性や処理性能を損なうのであれば問題だけど。
746:デフォルトの名無しさん
04/11/27 17:41:22
ばかでかいわけでもあるまいし。
747:デフォルトの名無しさん
04/11/27 19:29:32
servlet-api.jarのサイズは91,627 バイトでつ
748:デフォルトの名無しさん
04/11/27 20:58:05
俺のところのは75,126 バイトだ
749:デフォルトの名無しさん
04/11/28 01:44:31
>>742
主観の話を議論しても意味はない。
気持ち悪いモンは気持ち悪い。
750:デフォルトの名無しさん
04/11/28 08:54:43
>>749
なんだ、理由は無いのか
751:デフォルトの名無しさん
04/11/28 23:27:50
そりゃ理由なんてねえだろ。
servlet.jarがあるのが気持ち悪いんだったら前のバージョン使ってりゃいいんだよ。
前のバージョンだって十分使えるんだから。
それか、自分で機能削除してservlet.jarを使わないようにすればいいだけ。
752:デフォルトの名無しさん
04/11/29 00:17:07
servlet.jarから必要なクラスだけぶっこ抜いたらいいんでは。
どれが必要なクラスなのか知らないけど。
753:デフォルトの名無しさん
04/11/29 00:53:47
>>752
そっちのほうが気持ち悪くねーかｗ
754:デフォルトの名無しさん
04/11/29 01:25:32
理由はないが、気持ち悪いね。
755:デフォルトの名無しさん
04/11/29 03:22:08
くーす3連発。
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
思わせぶりで煙に巻くテクニックは年の功。
756:デフォルトの名無しさん
04/11/29 07:22:23
>>755
思わせぶり≠自分が理解できない
757:デフォルトの名無しさん
04/11/29 20:33:49
「思わせぶり」って忘れたころにやってくるっていう意味じゃないの？
ほら、3年ぶりとか、久しぶりとか、そういう「ぶり」
758:デフォルトの名無しさん
04/11/30 02:47:20
面白い！
759:デフォルトの名無しさん
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"
"URLﾘﾝｸ(www.seasar.org)">
<components>
<include path="dao.dicon"/>
<component class="MemberDao" >
<aspect>dao.interceptor</aspect>
</component>
</components>
って感じだとINSERT文のarea_idの値にareaId.hashCode()の値('[I@8c5488')が入ってだめだった。
762:760
04/11/30 19:30:08
JDBCドライバのせいだった...orz
ごめんよS2Dao....
763:S2Dao
04/11/30 23:20:00
>>762
まあ、気にするな。
764:デフォルトの名無しさん
04/12/01 00:12:24
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(www.kakutani.com)
URLﾘﾝｸ(lists.sourceforge.jp)
コミュニティ粘着の皆様、本格的な出番ですよ。
765:デフォルトの名無しさん
04/12/01 00:24:31
はぶさんの発言力をひがさんにインジェクションできれば問題なしなんだろうけど。
ひがさんの技術力をはぶさんにインジェクションしたら、たちが悪そう。
766:デフォルトの名無しさん
04/12/01 00:45:34
>>763
オメエ、いいやつだな。さすがS2Daoだ。
767:デフォルトの名無しさん
04/12/01 01:12:52
>>764 takaiさんていい人そうだｗ
768:デフォルトの名無しさん
04/12/01 02:01:43
>>767
S2NazoWebの人だしな。Groovyマンセー！
769:765
04/12/02 02:18:25
えー、最強はぶっちを目指しましょうよ。
770:デフォルトの名無しさん
04/12/02 02:20:27
真面目にキャバクラとかすんのバカバカしいですよ。
771:デフォルトの名無しさん
04/12/02 12:34:13
>>770
もれも同じ読み違いしたw
772:デフォルトの名無しさん
04/12/02 21:21:25
S2StrutsのActionのPOJO化自分でやろうかと思ってたらキム氏がやるらしいな。
S2JSF待つ余裕もないし早くリリースして欲しいな。
とはいえ、自分でやろうと思ってたからわかるけど
結構面倒なんだよなあ。テストが．．．
773:デフォルトの名無しさん
04/12/02 23:37:05
失敗... orz
774:デフォルトの名無しさん
04/12/03 00:44:06
servlet.jarが入ると気持ちが悪いのは、プレゼンテーション層がないアプリで
プレゼンテーション層に依存してしまうからだろう。
階層化を意識している人は気持ち悪く思うのは当然だ。
775:デフォルトの名無しさん
04/12/03 02:37:24
rt.jarの中に入ってるswingは気持ち悪くならないのかな
776:リリース情報
04/12/03 04:09:34
S2.1.3 リリース
URLﾘﾝｸ(d.hatena.ne.jp)
777:デフォルトの名無しさん
04/12/03 08:11:04
JDBC使わないアプリで以下略
778:デフォルトの名無しさん
04/12/03 11:29:24
>>775
それはわざわざ後から入れなくてかまわないだろ。選択の自由がない。
それが気になるならJava2ME使いなされってことだし。
779:デフォルトの名無しさん
04/12/03 12:24:04
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
780:デフォルトの名無しさん
04/12/03 16:28:03
動くものが出てれば、少なくとも失敗ではない。
781:デフォルトの名無しさん
04/12/03 16:30:08
Seasar3が出るなら、Seasar2は成功だし、Seasar4が出るならSeasar3は成功。
Seasar4が出ないということになれば、Seasar3は失敗。
次につながるかどうかだと思うな。
782:デフォルトの名無しさん
04/12/03 17:49:08
予言するけど、Seaserは全てからスルーされて終わりだと思うよ
783:デフォルトの名無しさん
04/12/03 22:56:13
かわいそうなSeaser…でも漏れが応援してるのはSeasarだからいいや。
784:デフォルトの名無しさん
04/12/04 00:29:01
予言というか、seaserがスルーされていることには実績があるね
785:デフォルトの名無しさん
04/12/04 00:41:34
おれいま仕事でSeasar2使ってるけど。
786:デフォルトの名無しさん
04/12/04 02:35:33
>>780
> 動くものが出てれば、少なくとも失敗ではない。
( ´,_ゝ｀)ﾌﾟｯ
787:デフォルトの名無しさん
04/12/04 10:11:28
>785
おれも仕事で何本か書いてみた。全体の見通しがいい作りになる。
S2のルールさえ覚えれば、特別な知識がいらないってところがいい。
仕事の道具としては相当使える部類だと思う。
788:デフォルトの名無しさん
04/12/04 11:56:36
いびつな変質を遂げたユーザーコミュニティーも
こうした日本に特有な部分はユーザー会の活動にも見られる。
日本には「*ユーザー会」といったものが多数存在しており、世界に例を見ないほど発達している。
日本のなかでもさらに地方支部みたいなものが生まれるユーザー会もあるようだ
問題なのは、本流とかい離し、日本独自の動きをしてしまっていることである。
こうしたケースでは本流との開発グループとの関係は希薄であることも多く、全体として開発、
普及の促進が阻害されるケースことにもつながる。
*-jpといった感じで本流と離れてしまうことは、開発者から見ればよいことではない。
また、離れることで利権を得ようとする人たちも現れてくる。
かつてDebian Projectのリーダーとして活動していたブルース・ペレンスと話をした際にこうした状況について話したところ、
それはFake Open Sourcerだね（だから排除すべき）という結論に達した
789:デフォルトの名無しさん
04/12/04 13:58:13
>>788
S2の英語圏コミュニティができたとしても、それはfakeだから排除すべきだな
790:デフォルトの名無しさん
04/12/04 15:01:38
日本人なんか、fakeニダ
791:デフォルトの名無しさん
04/12/04 15:16:06
>>789
S2の2chコミュニティができたとしても、それはfakeだから排除すべきだな
792:デフォルトの名無しさん
04/12/04 19:48:49
>>788
出典は書いておけよ
日本におけるOSSの幻想―OSS界のガラパゴス諸島、ニッポン
URLﾘﾝｸ(www.itmedia.co.jp)
793:デフォルトの名無しさん
04/12/04 20:04:40
>>791
S2のNPOができたとしても、それはfakeだから排除すべきだな
794:デフォルトの名無しさん
04/12/05 13:16:01
本家から離れることで利権を得る状況がFakeだって事なんだから、
特に利権を得てない2chコミュニティは違うだろ。NPOはそもそも本家の話だし。
795:デフォルトの名無しさん
04/12/05 14:58:24
Fakeな「日本～ユーザー会」の例キボン
796:デフォルトの名無しさん
04/12/05 14:58:30
そもそも2ch自体がfake
797:デフォルトの名無しさん
04/12/05 15:00:04
>>795
ブルース・ペレンスが言ってるんだから本人に聞け
798:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/05 15:26:04
おもしろいから漏れもググってみた。オプソとは関係ないがこんなのもあるのな。
URLﾘﾝｸ(www.asahi-net.or.jp)
URLﾘﾝｸ(toughbook.jp)
URLﾘﾝｸ(www.infosta.or.jp)
何となく日本*ユーザ会って名前をつけたがる国民性なんじゃないかと感じたよ。
800:デフォルトの名無しさん
04/12/05 15:33:37
9) Zopeに一票
801:デフォルトの名無しさん
04/12/05 18:35:47
>>798
1)と5)は本家に影響を与えているからFakeではない。
他のユーザ会は知らん。
802:デフォルトの名無しさん
04/12/05 19:24:39
>>798
2)と8)は純粋に「ユーザー」会な希ガス。
他も日本語化とかi18nがらみでcoreな部分に携わってるひとはいないよね。
こういう状況がfakeだといっているのかな。
なんかｽﾚ違いかも。
803:デフォルトの名無しさん
04/12/05 22:58:15
たしかにZopeはうさんくさいな。
あと、SambaもI18NでTAX食ってたぞ。
IPAだ。あまりしられてないことだが。
804:デフォルトの名無しさん
04/12/05 23:22:41
それは税金の正しい使い方なので無問題。
805:デフォルトの名無しさん
04/12/05 23:30:36
S2Strutsはスレッドセーフにできてなかったのか。
驚いた。
マルチプロセッサの環境での実務使用を考えていたのに、白紙に戻ってしまった。
S2JSFも初めはそのレベルなのかな。
WEBアプリでスレッドセーフじゃないってのは相当ヤバイ問題じゃない？
がっくりだ。。。orz
まあ、俺は提供されるもの使う側で作るスキルも無いから、
作ってる人間の苦労がどの程度のものかわからないまま言いたいこと言ってるけど。
S2Strutsが改善されるとふんで突っ走る。。。わけにもいかねえしな。
シングルプロセッサ環境での使用だったら突っ走ってもよかったんだけどなあ。
あ～頭痛ぇ。どうしよう（泣）
冒険しようとした自分が悪いんだけどorz
しかし、オープンソースの品質保証ってのは難しいね。
806:デフォルトの名無しさん
04/12/05 23:46:16
>>805
ｱｲﾀﾀﾀ･･･
どこがどう問題なのか理解してる？
807:デフォルトの名無しさん
04/12/05 23:56:38
>>805
話の流れがよく分からないんだけど。
S2Strutsがスレッドセーフじゃないってのは、どの部分を指していっているのかよく分からない。
スレッドセーフの話で言えば、そもそもServlet自体自分で同期化しないとスレッドセーフじゃないし、
S2のコンポーネントもSingletonでロードする限り、ちゃんと同期化しないとスレッドセーフじゃないわけ
だけど、そういう話じゃないんだよね？
808:デフォルトの名無しさん
04/12/06 00:02:48
マルチプロセッサとスレッドセーフ性は直接関係ないだろ。
Double Checked Lockingとかでビミョーに関係あったりするけど。
809:デフォルトの名無しさん
04/12/06 00:03:50
URLﾘﾝｸ(d.hatena.ne.jp)
はぶ君はハゲヅラかぶってチチロー役やりなさい。
810:デフォルトの名無しさん
04/12/06 00:05:53
>>807
URLﾘﾝｸ(d.hatena.ne.jp)
↑嫁
811:デフォルトの名無しさん
04/12/06 00:09:40
よくわかんないけど、
この二つの日記に書いてあることのことかな？
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
勉強中の俺には何言ってるかよく分からないんだけど。
つーか、フレームワークってその辺も特に意識しなくてもちゃんとできるもんじゃないの？
812:デフォルトの名無しさん
04/12/06 00:27:32
おれはS2 + S2Dao + Struts環境で仕事してるが、S2Strutsは採用せずにAction内で
getComponent()してる。ActionはView層にしてるんだが、View層の人にまでDIの仕組みを
説明するのがどうもな、と思っただけなんだけど、結果的には良かったってことか。
813:デフォルトの名無しさん
04/12/06 00:30:16
> URLﾘﾝｸ(d.hatena.ne.jp)
なんつーか、お粗末の一言だな。
マルチスレッドでアクセスされるオブジェクトプール的なものによくある
典型的なバグパターンじゃねえか。
こんな問題が今の今まで放置されてたのかよ。
まあ、こういう問題でパフォーマンスとスレッドセーフを両立させるのは
確かに難しいがね。
J2SE 5.0が使えるんなら、java.util.concurrent.ConcurrentHashMapの
putIfAbsent()メソッドとかでかなり楽が出来るんだが。
814:デフォルトの名無しさん
04/12/06 00:43:04
>>813
> J2SE 5.0が使えるんなら、java.util.concurrent.ConcurrentHashMapの
> putIfAbsent()メソッドとかでかなり楽が出来るんだが。
元ネタのDoug Leaのutil.concurrentで代用とか。
815:デフォルトの名無しさん
04/12/06 00:47:42
ソースの前に「............................................」が続くのには意味があるの？
816:デフォルトの名無しさん
04/12/06 00:50:05
S2Strutsのスレッドセーフ対応早速リリースしたね。
そりゃそうだよね。
インパクトでかすぎだもん。
817:デフォルトの名無しさん
04/12/06 00:54:15
>>815
動いてるの確認するだけでしょ
818:デフォルトの名無しさん
04/12/06 00:54:34
プロセスがドタバタしたけどオプソの良さがでたんじゃないのかな～。
819:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/06 07:05:19
で、新しいのでちゃんと直ってるの？
821:デフォルトの名無しさん
04/12/06 07:51:22
>>820
マルチプロセッサ環境が無いから俺には確認できん。
つい最近まではあったんだけど。。。
誰かﾚﾎﾟよろ。
khi氏の書き込み待ちになってしまうのか？
彼は書いてる文面はむかつくが（性格も悪いんだろうけど）、
指摘してるポイントは正しいからね。
822:デフォルトの名無しさん
04/12/06 11:22:00
>>821
だから、マルチプロセッサとスレッドセーフと、どんな関係があるのかと。
823:デフォルトの名無しさん
04/12/06 12:11:53
MP構成でなければなかなか再現しないので実際に修正されたという確信がもてない、という関係
まあMPで試して大丈夫ならOKというものでもないんだけど。
論理的な正しさをソースコードで検証しないとどうしようもない。
824:デフォルトの名無しさん
04/12/06 22:26:35
khi氏という高スキル開発者がSeasarプロジェクトへ合流か。
順風過ぎて少し妬ましいね。
825:デフォルトの名無しさん
04/12/06 23:03:12
>>824
あまりやる気あるようには見えないけどね。
まあ、脇から問題見つけて文句言う人間がいるだけで全然違うからね。
826:デフォルトの名無しさん
04/12/06 23:35:18
>>808
マルチプロセッサだと、スレッドセーフまわりのバグに当たり易くなる。
827:デフォルトの名無しさん
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
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。