国産DIコンテナSeasarとくーす その３
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
http://www.seasar.org/
Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/
前スレ
その１ http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２ http://pc5.2ch.net/test/read.cgi/tech/1098885253/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNG0012デフォルトの名無しさん
NGNG0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん
NGNG僕も欲しいし、賛同者>>934さんもいるみたいなので、
ちょっとコード書いてMLに流してみます。
0015デフォルトの名無しさん
NGNG> update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。
これってむしろS2Dao側で属性ごとにダーティーチェックして対応してくれるのが
正しい気がするんだが。現状のS2Daoってそういうことやってないの?
教えて君でスマソ。
0016デフォルトの名無しさん
NGNGフラグをオンにしたいだけなんだよ」とかいうときに、いちいちSQLファイル作って、
ARGSアノテーション書いてってのが邪魔臭い。
別に対した手間じゃないんだろうけど、でも全カラム一斉UPDATEがわずか一行で
定義出来るのに、それより短いSQL文のためにSQLファイルをつくんのかよ....orz
という気分になってしまう。
0017デフォルトの名無しさん
NGNGもしかして１項目変更するのが全項目変更するより簡単な処理だと思ってるの？
0018デフォルトの名無しさん
NGNG>>17
確かにクエリを組み立てる側の制御は組み立てるクエリの長さで決まるわけじゃないからねえ。
だから、ARGSアノテーションとかが必要になるんだと思うんだけど。
16は仕組みをあまり分からず書いているのかもしれないけど、
そういうユーザーの要望の中から対応すべき要望を抽出して対応することによって
ツールとかは熟成されていくんだと思うよ。
くだらなくても要望出さなかったら作者の必要な機能ばかりのツールになってしまうからね。
0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNG自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？
まぁ、いちいち噛み付かずに
>>17さんの言う通り、
ちょっとづつでも要望出してちょっとづつでも良いツールになっていってもらおうよ。
僕は一応、ソースのどの辺いじればよいのか調べています。
0021デフォルトの名無しさん
NGNG>>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
>自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？
そうです。
短いSQLのためにSQLファイルを作るのが面倒だという話です。
S2Daoは「UPDATE テーブル SET PK以外のカラム全部 WHERE PK」ってなSQLを自動生成
してくれるけど、「PK以外のカラム全部」を特定のカラムだけにするのにSQLファイルを書く
のがね。
SQLを一行書いたファイルを作るだけなんだけど、「PK以外のカラム全部」のカラムが２０個
だったりしても長いSQLが自動生成できるのと比べてしまうと、たった一つのカラムのために
SQLファイルを書くのが面倒に感じまして。
0022デフォルトの名無しさん
NGNGだって。よかったじゃん。
tp://d.hatena.ne.jp/higayasuo/20041215
002315
NGNGこういうところもS2が好きな理由です。
002515
NGNG002614
NGNG0028デフォルトの名無しさん
NGNG0029デフォルトの名無しさん
NGNGお礼がズラズラと並んでる図は信者臭くてダサいし
0030デフォルトの名無しさん
NGNG0031デフォルトの名無しさん
NGNG0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNG0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNG早く、事例集を作らないかなあ。
実績がはっきりしてナイト採用しないところもあると思うんだけどねぇ。
0037デフォルトの名無しさん
NGNGネタに騙されてるよ
0038デフォルトの名無しさん
NGNGネタ？
MLでの導入事例集作成のやり取りのことですか？
0039デフォルトの名無しさん
NGNGつーかおれ、未だにAOPの使い方がよくわかんね。コンテナ機能だけでも便利だからいいけどさ。 orz
0040デフォルトの名無しさん
NGNG0041デフォルトの名無しさん
NGNGモックオブジェクト使えないし、デリゲートも自動でできないんだぞ。だめじゃん。
0042デフォルトの名無しさん
NGNGとりあえず、ドキュメントどおりにdiconファイルに記述すればOK
0043デフォルトの名無しさん
NGNG考えながら付属のやつを使ってりゃそのうちinterceptorを自作するようになるさ。
0044デフォルトの名無しさん
NGNG> SQLを自動生成したり、Beanからバインド変数を組み立てたりという仕事は、
> これまで、BeanMetaDataにさせてました。データのことを最も知ってるクラスに
> 振る舞いを持たせるのは、自然なことだと思っていたためです。
>
> しかし、S2Daoに仕様の追加があるたびに、BeanMetaDataに変更が入るのです。
> メタ情報は全く変更されていないのにもかかわらず。
SQLの自動生成ロジックの変更によって、メタ情報に変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?
バインド変数組み立てロジックの変更によって、メタ情報の変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?
どちらも何の問題もないように思いますが。
0045デフォルトの名無しさん
NGNG> SQLを自動生成したり、Beanからバインド変数を組み立てたり
> という役割は、メタデータを管理するというBeanMetaDataの
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。
それは単に責務の割り当て方が適当でなかったために
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。
と感じるのだと思いますが。
例えば
BeanSchema.toXML
のようなメソッドはBeanMetaDataクラスに持たせるべき責務のように
思えます。
0046デフォルトの名無しさん
NGNG> モデリングするという考えは、重要ながらかなり見落とされている
> ことが多いのではないでしょうか。
よくわからないので、
具体的な例を挙げていただけませんか?
0047デフォルトの名無しさん
NGNGメソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
べきだった、という話じゃないの？
で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。
その点についてはおれは反対する要素はないぞ。
0048デフォルトの名無しさん
NGNG> SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
> メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
> べきだった、という話じゃないの？
>
> で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
> するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。
うんにゃ、
ひがさんは BeanMetaDataには振る舞いを持たせるべきではない、と言っているよ。
0049デフォルトの名無しさん
NGNGここではなくてblogのコメントに書いていただけませんか？
0050デフォルトの名無しさん
NGNG> 1つのクラスに複数の役割を持たせることになります。
なりません。
データは何一つサービスを提供しません。
よって、データは責務を持ちません。
0051デフォルトの名無しさん
NGNGS2Daoのソース読んだわけじゃないから詳しいことは分からんが、
少なくとも>>45には激しく同意。
Object指向としての理想的なモデリングは、SwingとかEclipseなんかが
参考になるとは思うんだが、その中にデータを表すってだけの
構造体みたいなクラスは見当たらんよね。ま、ドメインが違うじゃんって
いわれればそれまでだけど。
くーすはどうも退化としか思えないんだよね。
目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
柔軟性や多態性なんかが損なわれてる気がする。
0053デフォルトの名無しさん
NGNG目先のお手軽さや便利さを求めちゃ何故まずいんだろう？
それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？
0055デフォルトの名無しさん
NGNG> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。
同感です。
結局は、前々スレの686の一言につきると思う。
>686
> くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
> (予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
> 決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
> Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
> カバー、的な。
0056デフォルトの名無しさん
NGNGそのBlogに対する書き込みをニヤニヤして読んでると思われ。
必死で書き込んでる奴らは
ヒガ氏の掌で踊らされているだけだということを
自覚したほうがいいな（藁
0057デフォルトの名無しさん
NGNG>>54
> >>49
> そんな度胸ありません！
そのとおりですw
0058デフォルトの名無しさん
NGNGみなさんはいい部下をお持ちのようですね。
うちは素人だらけなので後ろ向きな方法論で結果を出すしかありません。
しかも、各自で技術力を向上させようとする前向きさも、センスもない連中が山ほどいます。まじで皆さんがうらやましいです。
0060デフォルトの名無しさん
NGNG> >>51
> 目先のお手軽さや便利さを求めちゃ何故まずいんだろう？
>
> それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
>
> オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
>
> お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？
それについては否定はしないけど、それはビジネスの話。
技術者ならくーすの技術面について話をしようぜ。
0061デフォルトの名無しさん
NGNG技術者よりの話題だと思うんだが。
まあみんな分かってるとは思うけど、くーすでいっていることは、すげえ新しいことでは
なくて、いままでビジネスの世界で生きてきた人が経験として得てきた知識と言うかノウハウ
（ともかくこの低スキルどもにコーディングをさせてこの仕事仕上げないといけないんだよ！、
とかいうやつ）だよな。それを手続きとしてまとめたもんだ。
で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
づけしたもんなんだし。
0062デフォルトの名無しさん
NGNG現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか？本当に？
アホでも素人でも妄想でも語れる現場話にしたい人は置いとくとして、エンジニア
の人達はこの結論でいいの？本当に？
006344
NGNG>で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
>呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
>づけしたもんなんだし。
それ自体は否定しないし、これらをまとめあげようとするひがさんは偉大だと思う。
ただ、的外れな指摘で「レガシーなオブジェクト指向」とかいうのはやめて欲しい。すごく迷惑。
0064デフォルトの名無しさん
NGNGヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。
それじゃ、話が合うわけねーじゃん。
つーか、なんでそんな人たちがヒガ氏やらくーすやらに興味持ってるのかさっぱりわからん。
0065デフォルトの名無しさん
NGNGくーすの技術面？
くーす語るんだったら技術面じゃなくて
ビジネスでの有効性だとかそういう話じゃないの？
0066デフォルトの名無しさん
NGNG技術的に語れる人間はこのスレには居ないって事だ。
それはそれで構わないと思う。そこは所詮２ちゃんだし？
重要なのは、このスレがヒガ氏へのＱとして機能し得るか否かって事だ。
何が言いたいかって言うと
ヒガ様、手隙の時で構いませんので、その辺をBLOGの方で技術的に解説よろ
って事だｗ
006744
NGNG> 要するに、
> ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
くーすの言う、DTOとかStatelessBusinessロジックはビジネスの話だと。
はあ、そうですか。
って、んなわけねーだろ。
0068デフォルトの名無しさん
NGNGいや、ひがさんの日記は、BeanMetaDataに振る舞いを「もたせるべきではない」という
話ではないだろ。BeanMetaDataはメタデータの管理（に直結した振る舞い）だけをすべき
だったのに、SQL自動生成とか関係ない振る舞いを持たせてしまった、という話だろ。
振る舞いとデータを分離するといってるんじゃなくて、「データにやまほど振る舞いをつけた
くなったとき、その振る舞いがデータと直結してるかどうかちょっと考えてみろ」っていって
るんだと思うけど。
まあ俺が思うのは、データに直結してないけど、そのデータを利用する機能を山ほど搭載
したFatなクラス設計（モデリング？）というは、「レガシー」なんではなくて、そんなものは
始めからオブジェクト指向の原則に反してるだろ、ということだな。
それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
かなり微妙だし、俺も正直言って間違うよ。
データと振る舞いをまとめるときに、「データと直結した振る舞いを持たせる」「データをつかった
ほげほげは別にする」というのはオブジェクト指向的には正しい判断じゃないか？
0069デフォルトの名無しさん
NGNGああ、それ自体は技術の話題だ。
でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
0070デフォルトの名無しさん
NGNG> >>67
> ああ、それ自体は技術の話題だ。
> でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
> 技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
もしそうっだったとしたら、なぜひがさんは
従来のオブジェクト指向を「レガシー」と言って技術的に批判するの?
0071デフォルトの名無しさん
NGNGここでレガシーと言われているものって、レガシーなんじゃなくて、そんなのはもともとオブジェクト指向的に
間違ってるんだし。
0072５１
NGNGいや、別にくーすに従わなきゃS2使ってバリバリにOOPなシステム作ることは
可能なわけよ。だからひが氏の実装自体には問題ない。むしろ素晴らしいと思うよ。
問題なのはくーすだよ。ただ、心配してるだけなんだけどね。
マジョリティとしての技術の方向性っちゅーのかな。それがこの先どうなっちゃうのか、とか、
くーすによってさらに加速されるであろう量産型低スキルエンジニア達の増産とか、
そいつらと一緒に、これからも仕事していかなきゃならない自分の身の振り方とかを。
ビジネス的にはそれでいいだろうけどさ、長期的に見て、まず「人」は育たないよな。
だから前々スレ686の一言に尽きるって結論になっちゃうんだけど。
ま、「レガシー」って言っちゃったのは失言でしたってこった。
どれだけ多くの人たちがあなたのBlogをチェックしてんのか忘れないでね。>>ひが氏
0073デフォルトの名無しさん
NGNGいけないんですか」とか聞く奴が毎年量産されていることを考えると、そいつらと一緒に仕事
していく手法を身につけとかないといけないってのは切実な問題かもしれん。
だって毎年量産されるんだし...
0074デフォルトの名無しさん
NGNGいろいろ覚えることあって大変だ。何がどういう役割を持っていてどう扱うのが正しいのか、
原作者にしか分からない理論（しかも、漏れ的には相当あやしい）を理解するのに何年かかるんだ。
そして覚えてそれで一体何になるのか。謎は深まる。
0075デフォルトの名無しさん
NGNG0076デフォルトの名無しさん
NGNG将来の客と現場に対する思考を停止するためのエクスキューズ用語。
0077デフォルトの名無しさん
NGNG0078デフォルトの名無しさん
NGNG示して難解フレームワーク固有の知識で壁を構築するっていうのは、
よく見かける手ではあるけどね。
シンプルな解決法は他にいくらでもあるのに。
本当にいいものは分かってもらおうという迫力が文章やコードで示されてる
のだけど、Seasarは・・・、まぁ、しょうがないな。
0079デフォルトの名無しさん
NGNGなんか凄い自信家ですねｗ
＞＞それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
＞＞かなり微妙だし、俺も正直言って間違うよ。
この辺に自惚れさが見え隠れしているように感じられるのは気のせいでしょうか？
0080デフォルトの名無しさん
NGNGそうだな。Strutsよりはマシかもしれん。
Strutsも大いなるネタの代表例でさ、あれよりいいってうのは、
果たして。大差は無いように思う。
0081デフォルトの名無しさん
NGNGくーすはWeb開発ノウハウの集合体であって、別に独自のフレームワークや固有の知識だと
思った事ないんだが。むしろ「あーたしかにそんな感じでやってるよ」ってくらいで。
逆にその「まとめよう」というところに価値があると思ってる。
0082デフォルトの名無しさん
NGNGみんな比嘉さんにもてあそばれてるなあ。
しかし、「レガシー」って括られるとそりゃ頭にきますよね。
みんな最先端を走ってるつもりなんですからねえ。
そう書けばここで盛り上がるのわかって書いてるのに
予想通りの盛り上がりを見せてるのはちょっと笑えるね。
しかし、Blogで２ちゃんのスレに煽りを入れて、
こんなにたくさんの人が踊らされるなんて、さすが比嘉さん。
0083デフォルトの名無しさん
NGNGDIスレの213=332と同様。厨がいたほうが一見盛り上がってるように見える罠。
0084デフォルトの名無しさん
NGNGそうか。やっぱり、ネタだったのか。
くそー、悔しい。
まぁ、そりゃそうか。
でも、本当にイカンのはマジなトーンで
DIコンテナORマッピングAOPとか言ってるやつらだぞ。
思わず反応してしまう・・・
0085デフォルトの名無しさん
NGNGもし本気でレガシーって思って書いてたら、S2自体の価値が疑われかねないので、
調子のって突っ走ってしまったと思いたいね。
まあ一方で、データと振る舞いの組み合わせ方は微妙な判断が必要な問題だ
と思う。その判断を卒業したてのＰＧに任せたくはないが、やらせないと低能の
ままの奴と付き合い続けなければいけないというジレンマに...
0086デフォルトの名無しさん
NGNGほんとにもてあそんぶためのネタとしてレガシーなんて言ったんだとしたら、S2に対する指示を
失いかねないネタだと思うぞ。
おれは勢い余ったんだと思うけどね。
0087デフォルトの名無しさん
NGNG0088デフォルトの名無しさん
NGNG☆ ﾃｨﾝ
☆ ﾃｨﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ ﾋｶﾞﾀｿ消火まだー？
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
DIスレをリスペクトして「ﾃｨﾝ」だ。
0089デフォルトの名無しさん
NGNG0090デフォルトの名無しさん
NGNGEJBが実は最も壮大なネタで、
それよりマシなものなら「漏れにも作れる！」
と思う香具師、たくさんいるんじゃないかね。
しかし、EJBよりマシなものできたところで、
EJB自体がネタだから、どっちにしろネタなのだ。
0091デフォルトの名無しさん
NGNGメジャーな手法を使うのは当然だよな。
0092デフォルトの名無しさん
NGNG0093デフォルトの名無しさん
NGNG0094デフォルトの名無しさん
NGNGレガシーっていってるのは、1つのクラスが役割を複数持ってる
ような設計のことでしょう。
これまでのオブジェクト指向がすべてレガシーっていってるわけじゃない。
ナイーブって言い方に変わってるね。
0095デフォルトの名無しさん
NGNG正直どう思ってるんだろう。S2Struts使うとStrutsConfとダイコンも
書かなきゃいけないし。
特に全体を追おうとするときって、目茶目茶だるい。EclipseでCtrl+クラス
で実装開いてくれるけど、インターフェース使ってると
インターフェース開くから、ダイコン見て実態クラス見てって。。。
書いてる本人は分かるから良いんだろうけどさ。
あと、お客に技術トランスファーしなきゃいけないのに
Seaser使っちゃって（一緒にやってる人がね）、おいおい
お客さん（IT企業じゃないないシステム課の人）
に分かるように説明できるのーって感じ。
やっぱりね、Seaserに限った事じゃないけど楽になるだろうって思って
使うのは、全体的に見て楽になるかを見ないといかんね。
0096デフォルトの名無しさん
NGNG＞＞この「ナイーブ」は当然 (？) without EJB のアレ (笑) です．幼稚・稚拙というニュアンス．
だそうですから。
0097デフォルトの名無しさん
NGNG対して技術的に難しい概念ってことはないと思うが。
009895
NGNG>技術的に難しい概念ってことはないと思うが。
OOで一回でも作った事がある人は難しいとは思わんとだろうけど
お客はそうじゃないし。
DBAがプログラム中にSQLがあるのとO/Rマッパ使ってるときとで
インパクトが違うのとにてるんでないかなーと。
0099デフォルトの名無しさん
NGNG実装を意識する必要はないというやり方ですからね。
気にするのは、インターフェースであり実装ではない。
実装はブラックボックスで良いと思う。
0101デフォルトの名無しさん
NGNGプロジェクトで役割を明確にしろよ。
みんながみんな実装のロジック見るわけじゃないだろ。
なんのためのインターフェースだと思ってる？
てか、Saesarをどうのこうの言う以前にOO開発できないでしょ。
そんな考え方じゃ。
0102デフォルトの名無しさん
NGNG0103デフォルトの名無しさん
NGNGちゃんと設計しろよｗ
0104デフォルトの名無しさん
NGNG0105デフォルトの名無しさん
NGNG基本を教えてください。
0106デフォルトの名無しさん
NGNG基本？
それってあんたのMY RULEのこと？
0107デフォルトの名無しさん
NGNGそうですか。
0108デフォルトの名無しさん
NGNGそうですよ。
傍観者は書き込まないでください。
0109デフォルトの名無しさん
NGNG「interface開く 〜 interfaceのタイプ階層を見て実装クラスを開く」
って2段階になるのがうざいよね。
IDE側に、interface名にカーソルあわせて「実装クラスを開く」
みたいな機能が欲しくなる時がある。実装クラスが一つの場合は
そのまま実装クラスのソースを開き、複数ある場合はドロップダウンで
選択とか。
0110デフォルトの名無しさん
NGNGS2Daoが返す、テーブルに対応したBeanとか）にいっさい振る舞いを持たせなくて、
setterとgetter以外あってはいけないとか思ってる人が多いのか。
そりゃ貧血症どころか構造体にすぎんじゃないか。
おれはモデルにほとんど機能は実装しないが、それでもそのモデルに直接関わる機能
（モデル内のインスタンス・フィールドだけで処理が片付いてしまうようなもの）はモデルに
実装するぞ。複数のモデルが絡んでくるようなものはサービスにまわす。貧血症ぎみの
クラスは多いが、それでも構造体よりはましだと思う。
■ このスレッドは過去ログ倉庫に格納されています