08/01/30 14:52:35
>>834
まったく同じならいいんだろうけど
そういうわけじゃないからね
S2はとりあえずメインの開発が止まってくれてよかった
メインのバージョンがアップデートされる速度が速すぎて
周辺ライブラリが対象とするバージョンとかならず開きがでてたから
今後はツールサポートに力を入れてほしいな
Eclipse以外のプラグインも作るとか、単独で動けるツールとか
ライブラリだけだとどんなによくても開発環境としては弱いからね
>>836
先にDBの関連作るところが多いと思う
細かいフィールドはあとから追加するにしても
838:デフォルトの名無しさん
08/01/30 15:07:15
>>837
JPAのツールが使えないような違いって？
839:デフォルトの名無しさん
08/01/30 15:48:14
>>837
そんなのがいちゃSuperAgileできないから対象外だろ常考
細かいフィールド
常にJavaのEntity中心で開発できるからいいじゃん。
IDEで全て追える！
840:デフォルトの名無しさん
08/01/30 17:03:18
今回はどこのアンチSeasar君だろ
841:デフォルトの名無しさん
08/01/30 23:42:03
>>837
JPAのEntityとの非互換ってあったっけ？
JPAのアノテーション全部使っているわけではないというのは知ってるけど
それは別に無視すればいいだけだし
DBについては、Railsのmigration的な機能を望む声は多いと思うし
DBAがいてはSuperAgileできないというのに同意
842:デフォルトの名無しさん
08/01/31 00:22:29
＞DBAがいてはSuperAgileできないというのに同意
漏れは要件定義とDBAとプログラマ兼ねている貧乏人だけど、
DBAが要るのとSuperAgileは関係ないと思うが。
先にDB設計してからアプリの設計に入るけど。
843:デフォルトの名無しさん
08/01/31 00:44:04
すべてIDEで完結することが重要
あれやこれや行き交うのがなくなることは良いと思う。
DBをJavaオブジェクトとして表現できるのはいいと思う
844:デフォルトの名無しさん
08/01/31 00:58:37
>>842
「専任の」DBAね。自分がDBAなら無問題
そういう場合、カラム一つ追加するのも書類書いて申請とかなんだよ
しかも対応は翌日以降とかな。アジリティのかけらもねぇ
845:842
08/01/31 01:15:11
>>843
漏れはDB2の人だけど、SQLの実行計画とか統計情報見てアレコレ分析&チューニングするところは
IDEでは出来んけど、それ以外の作業はEclipseで出来るのでSuperAgileとそれは
関係ないと思うが。
>>844
ちょっとDBAの立場から言うと基本的に「自分の設計は神」と思い込んでいるので
他人が「カラム増やせ」とか言われたら、本当に必要なの？ってヒヤリングするので、
そういうので対応がトロいとか言われるのはあるな。
ただ、元COBOLerなんかは横長DBにカラム追加設計して必要以上にこねくりまわす性癖があるから
あれはあれでウザく感じる。
846:デフォルトの名無しさん
08/01/31 11:19:03
DBを作ってるんじゃない。システムを作ってるんだ。
システムがうまく回るようにDBを設計すべき。
DBAが「自分が一番」なんて思ってるとうんこ
847:デフォルトの名無しさん
08/01/31 12:13:17
>845
チューニングなんて開発段階からするか？
俺はしない。
848:835
08/01/31 13:30:01
おれはアプリケーションよりの人間だけど(DBA に「カラム追加して」と頼むほう,）
、>>842 の言っていることには同意する。
>>843
別に Eclipse のプラグインで DB をいじりたいと思わない。
餅は餅屋、自分は OsqlEdit と SqlPlus じゃないと効率が悪い。
>>847
細かいチューニング(インデックス張るとか)は結合ぐらいからやり始めるけど、
開発終わってから「横長のテーブルがイヤなので正規化します」なんて、プログラム側でも Entity が変わって
超めんどくさいことになるじゃないですか。
設計や開発の初期にテーブルを作るときに、明らかに変えたほうがいいことは、最初から変えておいたほうがいい。
「横長DBをキレイにすること」を、チューニングと考えるか設計変更と考えるかの違いかもしれないけど。
849:デフォルトの名無しさん
08/01/31 14:07:58
正規化はチューニング違う。全然違う。
850:デフォルトの名無しさん
08/01/31 15:19:10
チューニングの観点でいうと、非正規系にすることのほうが多いと思うが。
>848
わざわざSQLをEclipseで発行するなんて書いてねーっての。
Eclipseにはリファクタリングっていうのがあるの知ってる？
しかもS2JDBCは基本SQL書かない。
DBをただの永続化の場所と捉えることからの機能なんだよ。
851:デフォルトの名無しさん
08/01/31 15:31:29
>>850
>チューニングの観点でいうと、非正規系にすることのほうが多いと思うが。
だよな。ここの住人がどれだけDBに無頓着かがわかった。
852:デフォルトの名無しさん
08/01/31 16:10:28
どんなシステムを作るかにもよるだろ。
チューニングはあとからでOKとか言ってる奴はちんまいWebアプリしか作ったことないような奴だ。
853:デフォルトの名無しさん
08/01/31 16:26:15
大きいWEBアプリだと開発途中にどんなチューニングをするんですか？
854:デフォルトの名無しさん
08/01/31 17:47:21
大小やWEBか否かに限らず、DBチューニングは普通後からやる。
実行計画見ながらSQLを見直したり、
インデックスを検討したり、Oracleだったらヒント句書いたりな。
855:デフォルトの名無しさん
08/01/31 23:49:46
必要な時に必要なことを必要なだけする。
これぞアジャイル
856:デフォルトの名無しさん
08/02/01 01:06:28
>>853
大きいシステムだととりあえずDBは横長に作ります。
857:デフォルトの名無しさん
08/02/01 02:18:41
現実問題ＤＢのチューニングを後からやるとか言っても、
設計が悪かったらチューニングも焼け石に水なのはほとんどの
DBAが知っている現実なワケだが。
858:デフォルトの名無しさん
08/02/01 02:55:35
|￣￣￣￣￣￣￣￣|
| 次でボケて!!! |
|＿＿＿＿＿＿＿＿|
∧∧ ||
( ﾟдﾟ)||
/ づΦ
859:デフォルトの名無しさん
08/02/01 03:21:12
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
これを使えばDBのチューニングなんていらないんじゃないか？
860:デフォルトの名無しさん
08/02/01 04:31:35
>>859
Nice boke.
861:デフォルトの名無しさん
08/02/01 08:14:49
ｗｗｗ
862:デフォルトの名無しさん
08/02/01 12:07:33
developerWorksキタ━━(゜∀゜)━━ッ!!
URLﾘﾝｸ(www.ibm.com)
863:デフォルトの名無しさん
08/02/01 17:33:14
>>862
あれ、 中村氏(taedium って人だよね?）のメアドが isid になっている。
豆蔵をやめて isid に転職したのかな?
864:デフォルトの名無しさん
08/02/02 03:59:45
isidに引き抜かれたんだよ
865:デフォルトの名無しさん
08/02/02 09:51:11
豆蔵がいやになったところを拾われた
866:デフォルトの名無しさん
08/02/02 14:27:35
最近豆蔵の有名な人がよく辞めてるのか？
867:デフォルトの名無しさん
08/02/02 15:47:17
最近始まったことじゃないし。
868:デフォルトの名無しさん
08/02/03 14:52:11
EclipseにSeasar2のプラグインと
Apache-Tomcatをインストールしたのですが、
ビルドの仕方がわかりません。
どうしたらいいのでしょうか？
869:デフォルトの名無しさん
08/02/03 15:06:47
メニューにプロジェクトのビルドってのがどっかにあるから探せ。
わからなければ、キミには向いていないってことよ。
870:デフォルトの名無しさん
08/02/03 15:23:45
ひがタソ
ドメイン層とパーシステンス層とごっちゃになっておかしくなってないか？
871:868
08/02/03 20:00:29
>>869
回答ありがとうございます。
ProjectはBuild automatically clean にチェックが入っています。
しかし新しく作成したディレクトリがTomcatで表示されません。
webapp直下にjsp-xxxというフォルダを作ったのですが。
872:デフォルトの名無しさん
08/02/03 20:09:22
>>871
スレ違いだな
873:デフォルトの名無しさん
08/02/03 20:14:52
>>872
了解です。よそに行ってきます。
ありがとうございました。
874:デフォルトの名無しさん
08/02/03 22:07:27
君子は豹変すと言うけど、人の後追いばかりで確固たる信念を持たない奴が
なんかの拍子に発言力持って適当フレームワーク乱発するのって害の方が多い気がする…。
ドメインモデルの件に関しては久しぶりに頭に血が上った。
で、その
875:デフォルトの名無しさん
08/02/03 22:15:51
君子は過去の自分がどうだったかにとらわれないから豹変するわけだが。彼も自分が君子であるつもりなんだろうな。
俺から見れば人として軸がぶれているだけだが。
876:デフォルトの名無しさん
08/02/03 22:45:39
>>870
そもそもドメインモデルの定義ってなによ？
動きを持たなければならないのか？というところか。
877:デフォルトの名無しさん
08/02/03 22:58:48
ひがたんが豹変して振り回されるのは人として軸がぶれてるヤツだけ
確固たる信念を持ってればひがたんが豹変しても笑って眺めるだけ
878:デフォルトの名無しさん
08/02/03 23:10:40
>>876
オブジェクト指向的アプローチであって
DBに引っ張られるような設計をしないこと
ここあたり参考になるかな？
URLﾘﾝｸ(otndnld.oracle.co.jp)
879:デフォルトの名無しさん
08/02/03 23:51:28
>>878
メリットは？
再利用が効くとか？芸術的だとか？
デメリットももちろん知ってるよな？
はっきりいって技術レベルが低い日本で純粋なドメインモデルでやっていけることは少ない。
層間のDTOやそれと同じようなことをするのは面倒だし。
880:デフォルトの名無しさん
08/02/04 00:28:43
>>879
俺に噛み付くなよ
普通に現実的なのはTableModuleだろう
DomainModelにこだわるようでこだわれない不思議なひがたんに聞いてよ
881:デフォルトの名無しさん
08/02/04 00:34:32
だいたい技術レベルが高くないと使えないっつー時点で
オナニーだな。
882:デフォルトの名無しさん
08/02/04 00:46:19
>>881
DomainModelパターンですよね。技術者のオナニーですよね。
883:デフォルトの名無しさん
08/02/04 00:48:56
DomainModel使うのに、それほど技術レベルが必要かねぇ？
そりゃモデル組むほうは技術が必要だが、殆どの層はモデル使う方なわけで。
それに、システムが複雑になってくれば来るほど、DomainModelは効果的だよ。
884:デフォルトの名無しさん
08/02/04 02:28:50
>>883
組むほうを使うほうの人数に相対するぐらい確保できればいいけどね。
言ってることは分かるが理想論過ぎる
885:デフォルトの名無しさん
08/02/04 02:31:20
>>883
そうやって層を分けると使えないモデルができあがる悪寒
886:884
08/02/04 02:46:23
>>885
残念ながら使えるんだよ。DomainModel単体では。
でもプレゼンテーション層や永続化層で使いにくいからDTOを作るのよ。
887:デフォルトの名無しさん
08/02/04 02:55:18
>>886
そういう意味じゃなくてさ
人の方を使うのと作るのに層を分けるとだな、
なんだよこの糞モデルはぁ～っっ使えねぇーーーっ
てことになるって話だよ
888:デフォルトの名無しさん
08/02/04 09:14:43
>>887
使うほうはモデルを直接操作することはあんまりないと思うが。
889:デフォルトの名無しさん
08/02/04 23:33:08
>>888
直接とか間接とかって意味じゃなくてさ
使えないってのは役に立たないって話だよ
890:デフォルトの名無しさん
08/02/04 23:40:32
>>889
あぁ、君のことか
891:デフォルトの名無しさん
08/02/04 23:54:23
誰がうまいこと言えと
892:デフォルトの名無しさん
08/02/05 11:33:46
元理事はchuraに提言する前にescafeどうにかしろ
キャラ付けしただけで忘れてんじゃじゃねーか
いつになったらオールインワンのダウンロードできるんだよ
893:デフォルトの名無しさん
08/02/05 20:07:39
あの元理事は本業からしてそんな感じだからOKOK。