国産DIコンテナSeaser ..
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は粘着っぽいけど
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5208日前に更新/259 KB
担当:undef