1001コメント360KB

EJB(初心者歓迎）

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

NGNG

EJBを勉強しています。
かなり複雑です。
そこでマッタリとEJBを語りましょう。
特にプログラミング技法など）

0685デフォルトの名無しさん

NGNG

じゅあみんな恵まれた環境で仕事してるんですね。

0686デフォルトの名無しさん

NGNG

分散オブジェクト系はCORBAもEJBも経験したが、やはりEJBの方が工数的に余裕が出る印象。
CORBAだと、>>684の悩みがあっというまに吹き出す可能性が高い。
＞MVCなんだけどその思想も崩れつつあります。
で、自前のFWを準備することになるが、EJB程の完成度は望めない。

0687デフォルトの名無しさん

NGNG

>>682
数年後を考えてみませう。

因みに5年前、Javaはおもちゃ同然の糞と、多くの
セクト主義はびこる日本人技術者に蔑まれていました。

0688デフォルトの名無しさん

NGNG

>>674さん
あなたはプログラムが趣味でしょ。
ビジネス的な思考でシステム開発している人はEJBを
>>おれは有効に使っているけど。
なんて発言でないと思うけど。

0689デフォルトの名無しさん

NGNG

>>684
メンテやってるのですか？メンテ要員ってデキナイ君の配置＋神１人（障害時のみ）
配置されることが多いから思想なんてぐちゃぐちゃに掻き回される。
私が過去に携わったシステムで、４年後に再度見ることになったのだが・・・・
実装レベルで見直すと酷い物でした。

0690デフォルトの名無しさん

NGNG

>>688

書いた後に何か言われそうだとは思ったけど、なんでそう思うのかを
説明してくれないかな。

ちなみに仕事以外でプログラムはしません。

0691デフォルトの名無しさん

NGNG

でも、確かにjavaはできるけど、OO的なモデリングやプログラミングはダメって
香具師は多いと思う。
モジュールレベルでいい感じに作られてたのに、一人のプログラマのせいで
それがぐっちゃんこにされてしまう事もあるし。
人選びは重要だけど、自社の人員資源ではもう無理！って感じる人は多いと思う。

0692デフォルトの名無しさん

NGNG

>>690
EJBで開発するのと単にJDBC経由で開発するので
技術者のスキルも、かかる工数も大幅に変わってくる。
開発での採算が合わなくなる。
EJBもJDBCもユーザーからすればどうでもいい話。
ならば、やすくシステム作るように提案したほうが
現場から喜ばれるでしょ。

0693デフォルトの名無しさん

NGNG

>>691
似たような経験あるな。
確かにJAVAだが、そりゃねぇだろおいみたいな。

0694デフォルトの名無しさん

NGNG

>>683
　>>居るところには居る。
ならばあなたの意見
　>>その不便さと、公知のほぼ標準化された仕組みを利用している
　>>ことによる保守、改変作業の容易さのトレードオフかと。
はやっぱり大嘘！！

0695デフォルトの名無しさん

NGNG

>>692

確かにユーザからしたらどっちでもいい話ではあるが、工数が大幅に変わる
というのはEJBを使うと工数が大幅に増えると言っているの？
そんなこと全然ないよ。

今やっているプロジェクトはjava初心者もいるけど、EJBでやっているよ。
ステートレスセッションBeanでEJB Commandパターン使っているから、EJB
を使っているということを意識していないと思うけど。

rollback、commit書かなくて済むから現場も喜んでいるよ。

0696デフォルトの名無しさん

NGNG

ｵｲｵｲ、EJB開発って、開発者にとって難しいか？？？

0697デフォルトの名無しさん

NGNG

どうも、EJBは面倒くさいことを簡単にしてくれているという
ごく基本的なことをわかっていない人がいるようで。

生RMIやCORBAでガリガリ、あるいはソケット直でゴリゴリやる
より100倍楽。

0698デフォルトの名無しさん

NGNG

>>694
>>683だが、>>675にあらず。

0699デフォルトの名無しさん

NGNG

>>695
既にEJB開発のためのフレームワークを開発したのですね。

0700デフォルトの名無しさん

NGNG

EJBはコーダーにとっては退屈ではないかな。
設計者には面白いかもしれんが。

0701デフォルトの名無しさん

NGNG

>>692
エンドユーザーが技術についてどうでもいいことくらいは、言わなくても誰もが認知済みでしょう。
少なくとも情シス部門は保守まで考えた視点で、どの技術を用いるかの決断はする。
やすく提案して、エンドユーザーに喜ばれた事例ってあるんですか？
部長クラスには喜ばれるだろうが、エンドユーザーはＵＩ以外で喜びませんよ。

0702デフォルトの名無しさん

NGNG

ＦＦＸ２でコンプリート95%越えても
だれも兄貴との性交イベント発生しないのだが？
これって不良品？
コンプしたら発生する？

0703デフォルトの名無しさん

NGNG

まあ、たまにシステムにやったら詳しくて、モデリングそのものにガンガン
口出してくるエンドユーザーもいるけど。

0704デフォルトの名無しさん

NGNG

そもそも普通のシステム開発（95％）で
>>生RMIやCORBAでガリガリ、あるいはソケット直でゴリゴリやる
こんな需要ないね。

需要がないのに
>>どうも、EJBは面倒くさいことを簡単にしてくれているという
>>ごく基本的なことをわかっていない人がいるようで。
この意味は理解できない。

0705デフォルトの名無しさん

NGNG

>>699

開発と言えるほどのことじゃなくて、EJBデザインパターンという本を
丸写ししただけのものです。

0706デフォルトの名無しさん

NGNG

>>704
あるよ。少なくともCORBAは。
「普通の」ってどういう基準で言ってるのかわからんけど、
分散オブジェクトの技術としてはEJBもCORBAも同じ。
CORBAでもAPサーバを利用すれば随分プログラミングが楽になる。
もちろん、APサーバ依存になってしまうが。

0707デフォルトの名無しさん

NGNG

高レベル言語で抽象化を突き詰めた結果、いろんな実装技術があるわけでしょ？
上記文章で、何を言いたいのかは俺自信わからないわけだが。

0708デフォルトの名無しさん

NGNG

>>701
エンドユーザーに喜ばれたとは書いてないですよ。
開発会社が利益が出て喜ぶでしょ。

0709デフォルトの名無しさん

NGNG

>>704
おいおい、プロセス間通信を必要としない仕組みは、そもそもEJBの
適用範囲外だが。

0710デフォルトの名無しさん

NGNG

>>706
その依存ってやつがどうしても嫌でしょうがない。
根本の仕様を押えておけば苦にならないだろうけど、
初学者にとってベンダ独自仕様は邪魔以外の何者でもない。

0711デフォルトの名無しさん

NGNG

あんたら、そろそろ寝ないとエンドユーザーどころか同僚からも喜ばれないよ。

0712デフォルトの名無しさん

NGNG

>>706
分散オブジェクトでなければ開発できないシステムの規模や条件について
具体的に説明してくれれば理解できるのですが。

0713デフォルトの名無しさん

NGNG

>>710
＞初学者にとってベンダ独自仕様は邪魔以外の何者でもない。
それは、EJBやCORBAに限らずだね。

0714デフォルトの名無しさん

NGNG

>>710
JDBCだって、DBとJDBCドライバに依存しますが。

0715デフォルトの名無しさん

NGNG

>>710
XML-APIだってXerces/Xalanつかうか(以下略

0716デフォルトの名無しさん

NGNG

>>714
依存部分もよく理解すればjavaのインターフェース内で処理できる場合が多い。

0717デフォルトの名無しさん

NGNG

つうか、J2EE準拠のAPサーバでベンダ独自仕様なんて、滅多に使わないでしょ。

無いとは言わないが。

0718デフォルトの名無しさん

NGNG

今のプロジェクトではXarcex,Xalan,Xml4J、いろんなXMLapiがごちゃ混ぜです。

0719デフォルトの名無しさん

NGNG

>>714
依存してねーだろ。もしかしてSQLのこと言ってんの？ﾌﾟ

0720デフォルトの名無しさん

NGNG

>>719
第３者だけど。依存している部分はあるよ。
BLOBデータのあつかいとか。

0721デフォルトの名無しさん

NGNG

>>720
あ、そうでした。いきがってスンマソン

0722デフォルトの名無しさん

NGNG

>>719
ｵｲｵｲ,夜中に付き合ってみたら、要するにど素人かよ…

JDBCの各インターフェイスに対して、機能が全て実装されているとは限らんよ。
ドライバの実装依存。幾つかの機能は、そもそもDBが持ってないから実装されない
こともある。即ちDB依存。

0723デフォルトの名無しさん

NGNG

ん、コネクションまわりで少々クセがあったような。
うろ覚え。

0724デフォルトの名無しさん

NGNG

やれやれ。

0725デフォルトの名無しさん

NGNG

最近EJBと言う名前は良く聞くのですが、これを利用して
何ができるようになるんでしょうか？
皆さんがEJBを使って目指すものって何ですか？

0726デフォルトの名無しさん

NGNG

>>725
EJBをサポートするアプリケーションサーバを使えば、
分散オブジェクトで作るシステムを(ﾏｯｻﾗから自作するよりは)
簡単に作れる。

分散オブジェクト自体がイロイロ面倒なので、ボタン一つでポイ
というほど簡単ではないですが。

0727デフォルトの名無しさん

NGNG

EJB学ぶ前提ってことで、とりあえずRMIをやろうと思ってよ。
お決まりのHelloWorldをリモートメソッド呼び出しによりやってみたが、
うまく動作しない。サンプルコードを動かすだけでこの手順は複雑すぎ。
これだけ時間かけてHelloWorldはないだろ。。。
で、いくつか思ったことがあったんだけど、スタブとスケルトンって沢山できない？
サンプルレベルなら１組でいいだろうけど。

0728727

NGNG

スレ違いだけどeclipseでrmicを動かす方法あるの？
外部ツールとかに割り当てて試してはみたけど、これまたうまく動作しないどころか
まったく反応なし。

0729デフォルトの名無しさん

NGNG

>>727
全ての通信手順を一つのやり方に出来るので、規模が小さい時は不便なだけだ
けど、規模が大きくなってくると便利だよ。
でもって、EJBはRMIスタブとスケルトンの存在もラップして、もうちょっと抽
象度の高いレベルにしてくれているので、もっと便利。というだけの話。

0730デフォルトの名無しさん

NGNG

>>728
Antにしたら？タスクあるから。

0731デフォルトの名無しさん

NGNG

素朴な疑問だけどRMIって同一マシンで複数VMじゃテストできないの？
//127.0.0.1:1099/ほげほげ
片方のVMにレジストしたらいいのかな。試してみよ。

0732デフォルトの名無しさん

NGNG

>>729
インターフェースなので当たり前ですが、
一度作成したスタブ・スケルトンはリモートメソッドの追加等がない限り、再コンパイルの必要なし。
ってのはちょっと感動した。なにせ初学者なもので・・・。

0733デフォルトの名無しさん

NGNG

>>731
？エクスポートしてレジストリにバインドすれば、VMまたいでコールできるの
がRMIでっしゃろ？

レジストリへのバインドも、レジストリサーバに対する登録依頼のプロセス間
通信。レジストリサーバが、そのURLのドメイン部分で持ってこれる場所にｱﾚﾊﾞ
ｲｲだけっス。

0734デフォルトの名無しさん

NGNG

EJBを使用するとアベイラビリティ、スケーラビリティがあがるといわれてますが、
なぜでしょうか？

私の認識ではEJBの持つ下記の性質のためだと思っていますが、
間違っていたらご指摘してください。
アベイラビリティ → 位置透過性（クラスタ対応＋CMT）
スケーラビリティ → 位置透過性（リモート呼び出し）

EJBを本当に使う必要があるのか迷っています。

またエンティティBeanは実際の業務ＡＰで皆さん使われてますか？
私の意見としては更新系にしかエンティティBeanは使えないと思っています。

使っている方はテーブルとエンティティBeanをどのようにマッピングしているのでしょうか？
CMP＋CMRを使ってテーブル：エンティティBean=１：１で対応させているのでしょうか？

業務ＡＰでＥＪＢを開発した方の意見をお願いします！

0735デフォルトの名無しさん

NGNG

Javaを使ったバッチ処理って皆さんJ2EE使われていますか？

通常のClassでJDBCでがちがち書いた方が良さそうな気がしますが、
どうなのでしょう？
JSP、Servlet、セッションBeanはまず使わないだろうし。
エンティティBean、MessageDrivenBeanは使われていたりするのでしょうか？
一括更新だからメモリを食って効率も割るそうですなぁ・・・

0736デフォルトの名無しさん

NGNG

>>735
漏れのところはJDBCでがちがち書いてる。
バッチでJ2EE使ったら許容時間超えそうで怖い。
といいますか、バッチのような単純処理にJ2EEを使うメリットありますか？

0737735

NGNG

>>736
回答どうもです！
私としてはバッチでJ2EEを使うメリットを下記のように考えましたが、

エンティティBean
→ １．トランザクション自動制御
　　２．エンティティBeanのオンラインとの共有化

やはりエンティティBeanでは性能を考えると辛いような気がします。

0738デフォルトの名無しさん

NGNG

なぜバッチ？
もう少し具体的な説明頼む（何をするか

0739735

NGNG

>>738
なぜバッチかというと現状Cで作成したバッチ処理を
Java（J2EE）で実装した場合どのようになるかを検討しています。

バッチ処理の内容としてはDBの一括更新＋CSVファイルの作成です。
説明不足で申し訳ありません。

0740デフォルトの名無しさん

NGNG

夜間バッチと言ったら、やってることはどこも大差ないと思われる。
最初は、JNIコールでやって、徐々にJavaに移行したら？

0741デフォルトの名無しさん

NGNG

>>737
>トランザクション自動制御
整合性で同期とるのはダメなの？

0742デフォルトの名無しさん

NGNG

AppletからEJBを呼ぶときって皆さんどうされてますか？
おそらく２つの手法があると思っています。
どちらのパターンが推奨されるのでしょうか？
メリットは私の推測ですが間違っていたらご指摘してください。

１．APPLET→Servlet→EJB
　　　メリット：ファイヤウォールを越えられる

２．APPLET→EJB
　　　メリット：速度が速い、コーディング量が減る。

0743デフォルトの名無しさん

NGNG

>>742
EJBをもう少し理解された方がよろしいかと思います。

0744742

NGNG

>>743
どこか間違っていますでしょうか？

0745デフォルトの名無しさん

NGNG

>>742
間違いなく１でしょう。
セキュリティから考えてみてもIIOPなどのポートをインターネットに公開すべきではありません。

>２．APPLET→EJB
>　　　メリット：速度が速い、コーディング量が減る。

コーディング量は減りますが速度が速くなるとは限りません。
サーブレットと通信するモデルは結果だけやり取りすれば良いので通信量を減らすことが出来ますが、
直接EJBを扱う場合は、IIOPなどのオーバヘッド、スタブのシリアライズ、デシリアライズやセキュリティの確認のための通信が
発生するため、かなりの通信量が発生します。
EJBの分散機能はノードがかなり近くにある状況で利用するのが、よりと思います。

0746デフォルトの名無しさん

NGNG

>>734
どなたか734に対して意見をいただけませんか？

0747デフォルトの名無しさん

NGNG

J2EEで大規模開発をやろうと思っています。
通常はフレームワークを使わないと品質がまばらになってかなり辛いと思うのですが、
実際はどうなんでしょうか？

あと、フレームワークはいろいろ調べてみたところcFrameworkが良さそうですが、
実際どうなんでしょう？
実際のプロジェクトで使われている方の意見が聞きたいです。

cFrameworkで非同期や会話型のAPは作れますか？

0748デフォルトの名無しさん

NGNG

>>747
非同期も会話型も無理だろう。

0749デフォルトの名無しさん

NGNG

>>748
ということはオンライン同期処理しかできないということですか？

0750デフォルトの名無しさん

NGNG

J2EEを使って、１万件のデータを検索してその結果を表示する場合、
１００件ずつくらい分けてHTMLに出力するというのが一般のやり方だと思っていますが、
その実装方式って皆さんどうされてますか？（どこでそのデータを保持していますか？
）
StatefulSessionBeanを使われてますか？
HttpSessionで処理されてますか？

個人的には「StatelessSessionBean」＋「HttpSesion」の方が
メモリが消費されずに済むので良いと思っています。

0751デフォルトの名無しさん

NGNG

お前のケツ毛にPL/SQL

0752ふぁそ

NGNG

>>747
cFramework使うぐらいならStruts使っとけ。
傾き書けている会社の使ってもろくなことにならない。
今ならStruts使えるエンジニアのほうが集まるだろうし
使えるようになりたいエンジニアもcFrameworkよりは多いと思われ。

0753デフォルトの名無しさん

NGNG

>>750
「StatelessSessionBean」＋「HttpSesion」良いと思います。
ただし、大量の検索結果を一時保管する際には、プライマリキーの配列
だけを保存しておく必要があるかもしれません。

0754デフォルトの名無しさん

NGNG

cFramework使った事あるよ。
どこが特別優れているのかはわからんが、
使いやすかった覚えはある。

0755デフォルトの名無しさん

NGNG

age

0756デフォルトの名無しさん

NGNG

>>750
普通にカーソル使ったら？

0757デフォルトの名無しさん

NGNG

簡単にやろうとすると、こんなんもありかな？
requestで処理して、アプリケーションでは保持しない。

SELECT * FROM (検索SELECT文) WHERE ROWNUM<=最終行
MINUS SELECT * FROM (検索SELECT文) WHERE ROWNUM<開始行

0758デフォルトの名無しさん

NGNG

>EJBを本当に使う必要があるのか迷っています。

セキュリティや分散などの機能を利用しないのであればあまり必要はないかもしれません。
ただ、開発が容易なSLSBで強固なトランザクション制御を簡単に利用できるなど、逆に「使わない理由」というのも見当たりません。
EntityBeanはこれからの仕様ですから無理に利用しなくても良いと思います。なにせやっとORDER BYできるようになったぐらいですから。
ただし本格的なオブジェクト指向をやる場合は透過的なオブジェクトの永続化層が必要ですから、
これを自作するよりは、JDOやEntityBeanなどのミドルウェアを導入するのが開発工数の節約になるでしょう。
また標準の機能であるので、自作した永続化層より保守が容易であることも導入の理由となるかもしれません。

>私の意見としては更新系にしかエンティティBeanは使えないと思っています。

そんなことはありません。
現在のほとんどのアプリケーションサーバーは読み出し結果をキャッシュする機構を備えているので、
読み出し時のパフォーマンスはかなり改善されています。
ただし、照会結果が大量の場合はJDBCを直接利用するアプローチを取るのが一般的です。
照会結果が少量の場合はEntityBeanでEJB QLを利用するのがいいと思います。
これらを使い分けることにより開発工数を減らすことが出来ます。

オブジェクト指向で開発するならEntityBeanが一番手っ取り早いです。
手持ちのアプリケーションサーバーに機能がついていますから。
ただし、普通のwebアプリケーションの開発であればStrutsとSLSBとDAOパターンなどで（なんとなく）出来てしまうので、
よくわからないものに手を出して、プロジェクトを失敗させたくない人はEntityBeanは使わないほうが良いでしょう。

0759デフォルトの名無しさん

NGNG

>>750
1万件は多いね・・・。一時的にHttpSessionに置くにしても多すぎる。検索->切断を繰り返すと容易にシステムダウンできる。
一番パフォーマンスが良いのは、カーソルをキャッシュしておいて表示する度フェッチする方法だけど、
これも危険、コネクションプールを使い尽くす可能性がある。。

私がやっていたのはシステム内にオブジェクト管理クラスを用意してそこで照会、オブジェクトの作成、キャッシュをさせるという方法。
最初の検索は時間がかかるけどそれ以降はキャッシュヒット率が上がってくると10倍くらいのパフォーマンスの向上があった。
キャッシュするオブジェクト数も管理できるのでメモリも食いつぶす必要がない。

特定の照会系に絞ってキャッシュ機構を構築するのが一番いいと思う。

0760デフォルトの名無しさん

NGNG

EJBを使用するとアベイラビリティ、スケーラビリティがあがるといわれてますが、
なぜでしょうか？

私の認識ではEJBの持つ下記の性質のためだと思っていますが、
間違っていたらご指摘してください。
アベイラビリティ → 位置透過性（クラスタ対応＋CMT）
スケーラビリティ → 位置透過性（リモート呼び出し）

0761デフォルトの名無しさん

NGNG

>>759
キャッシュするのは解るけど、
数万件のデータを保持するオブジェクトって大丈夫なの？
都度、DBアクセスする方が安全のような気がするんだけど。

0762デフォルトの名無しさん

NGNG

>>761
それは難しいところ。
1万件の照会を毎回やり直せる体力がDBにあるなら、それでいいと思うよ。
ないのであれば、キャッシュするしかない。

0763デフォルトの名無しさん

NGNG

>>762
５０万件から数万件引っ張ってくることを想定すると、
PreperedStatementキャッシュ、ﾃｰﾌﾞﾙｲﾝﾃﾞｯｸｽを用いたとしても
一定人数以上から同時アクセスされると容易に死ねるような気がする。
とすると、キャッシュ容量は十分に考慮しなければならない。

それ以前に、１万件画面に引っ張ってくる状況って殆どないように思える。

0764デフォルトの名無しさん

NGNG

キャッシュしてるのは、変更が少ないマスター系のデータ？
そういうデータをシングルトンで保持しておくのは良くある方法かと思ってた。

0765デフォルトの名無しさん

NGNG

>>764
マスター系はキャッシュの恩恵得られやすいだろうね。
しかし、「住所マスター」これってデカくねーか？

0766デフォルトの名無しさん

NGNG

>>763
@ITにPreperedStatementキャッシュについての記事があったね。なかなか使えそう。

0767デフォルトの名無しさん

NGNG

1回の検索で1万件ってそんなに多いかな？
行もさほど大きくなく、条件も単純でソートエリア大量消費しなければ、
DBにとってはさほど酷な仕事じゃないと思う。
システムによりけりだが。

0768デフォルトの名無しさん

NGNG

>>767
> 行もさほど大きくなく、条件も単純でソートエリア大量消費しなければ、
自分で条件特定してるじゃん。それで酷ではないって言うのはどうかと。
１万件ってそんなに多くないが、いろんな側面を考慮すると酷な場合もあり得る。
システムによりけりで、一概に言えないと思われる。

0769デフォルトの名無しさん

NGNG

異なるEJBメソッドの呼び出しから、同一テーブルの同一カラムの値を更新する場合。
どうやって排他制御されるんでしょうか。

Webからほぼ同時に異なるリクエストが到着して、
異なるセッションビーンのメソッドから、
同一のエンティティビーンABCBeanのsetterメソッドを呼び出すとします。

このときって、どういう風に更新されるの？
どっちかが失敗するの？

0770デフォルトの名無しさん

NGNG

普通に後勝ち。
それがシステム上マズイならアプリで排他制御を実装すべし。

0771デフォルトの名無しさん

NGNG

>>769
コンテナが良きに計らってくれるんじゃないの？

0772デフォルトの名無しさん

NGNG

>>769
分離レベルによる。

0773デフォルトの名無しさん

NGNG

EJBだけでストアドプロシージャ使えますか？　

0774デフォルトの名無しさん

NGNG

>>773
JDBCを使わないとだめ。

0775デフォルトの名無しさん

NGNG

HttpSession session =request.getSession(true);
session.setAttribute("ID","XXXXX");

sessionにbean以外の登録って出来ますか？

0776デフォルトの名無しさん

NGNG

0777デフォルトの名無しさん

NGNG

>>775ネタ？
お前のbeanがObject以外から派生してるなら無理

0778デフォルトの名無しさん

NGNG

JBOSSはSUNからJ2EE準拠の認定取れたんでしょうか？
J2EE準拠テストを提供されたとかいうニュースが3ヶ月ぐらい前にあったが。

0779__

NGNG

0780デフォルトの名無しさん

NGNG

>>778
まだ。それに多分取れない。

0781デフォルトの名無しさん

NGNG

JDKのj2eeより軽いって、jbossってどういう仕組みなんだろうなぁ。

0782デフォルトの名無しさん

NGNG

>>781
単にj2eeがパフォーマンス重視で作ってないだけだろ。

0783デフォルトの名無しさん

NGNG

サーバーとクライアントでデータをやりとりするアプレットの業務アプリ
を作ってるんですが、サーブレットも使わずわざわざソケットをつかって
サーバーサービスをつくり、これでクライアントとデータをやりとりして
ます。単純なデータのやりとり、単純なセッション管理しかできないしろ
ものなんですが、このようなやり方ってお薦めできる技法でしょうか？

0784デフォルトの名無しさん

NGNG

>>783
IMF技法をお勧めする。
IMFとは、Implementation Method Falsificationの略で直訳すると
「実現方法改ざん」である。初心者にはお勧めできないが。

■ このスレッドは過去ログ倉庫に格納されています