C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[43]: オブジェクト指向熱イベントパネルディスカッション検討スレッド [3]


(過去ログ 23 を表示中)

[トピック内 82 記事 (61 - 80 表示)]  << 0 | 1 | 2 | 3 | 4 >>

■10100 / inTopicNo.61)  Re[30]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
  
□投稿者/ カンタービレ (37回)-(2007/11/11(Sun) 17:51:45)
No10096 (えムナウ さん) に返信
> >オブジェクトは時間軸の断面をベースに表現しているとして、並列化設計って何かと何かを「同時に」実行して
> >っていうのを体系的に表現することになるのでしょうか?
> UMLのシーケンス図やステート図を知っていますか?
> 時間軸や状態の移り変わりが主観点ですよね。
>
> 私のUMLの不満は、コメントでごまかさない設計がしたいということです。
> アクティビティ図・シーケンス図・ステート図で並列化設計がしづらいというのが第1点。
> クラス図でもなんかの工夫はいるんじゃないかと思っているのが2点目です。
>
UMLにシーケンス図等、時間の観点がないわけじゃないのは知ってマス。
なので「同時に」を強調して書いた意味としてはえムナウサマのおっしゃりたいコトと
あまり変わらないかも知れません。
並列を表現したい場合、どうしたって1回のシーケンス図に、複数(並列)を表しにくいですもんね。
工夫がうまく加わり、ツールとしての表現の幅が広がることは歓迎派デス。

多元性の要素があればと先に書いたのも、そういう意味合いのつもりでした。
言葉足らずでスミマセン。意図を正確に伝えるのって難しいデスね。

サービスやビジネスプロセスのモデリングを行うようなレイヤーによっては使う必要がない(意識しなくてよい)かも
知れませんが、実装段階でのモデリングにはそうした要素があってもいいのかなぁと思いました。

引用返信 編集キー/
■10101 / inTopicNo.62)  Re[32]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (100回)-(2007/11/11(Sun) 17:55:37)
現実問題としてUMLで並列処理を表現しづらいということ自体は、
具体例でビシッとは説明できないけど納得はしてもらえている様子。

渋木さん。
>構造設計と並列化では問題領域が違うから、両者を同じ土俵で表現しようとしても難しいだけであまり成果が上がらないように思うんですよ。
私。
> ファームウェアだってドキュメントを通じて発注者と確認をとります。
> 昔はフローチャートを使っていましたがUMLにしたっていいでしょう。

ここに差があるんですね。

じゃ、逆にハードウェア(HDL)やファームウェアに的確なチャートがないままでいいんでしょうか?
タイミング図や不完全なシーケンス図やIOポート表だけでプログラムを書いて保守しろと?
渋木さんはどうしていますか?
引用返信 編集キー/
■10103 / inTopicNo.63)  Re[33]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (538回)-(2007/11/11(Sun) 18:38:20)
渋木宏明(ひどり) さんの Web サイト
> じゃ、逆にハードウェア(HDL)やファームウェアに的確なチャートがないままでいいんでしょうか?

HDL は自分で書いたことないのでノーコメントで。

> タイミング図や不完全なシーケンス図やIOポート表だけでプログラムを書いて保守しろと?
> 渋木さんはどうしていますか?

まず、ファームであるかどうかに関わらず、書かねばならないことは全部書きます。
その代り、書かなくても許してもらえるものは基本まったく書きません。

UML を使うことにこだわりがないので、UML だけで書く気は毛頭ありません。
必要事項の記述に UML で不都合があるなら、その時に必要と思った説明資料を作成します。

もちろん、標準的な記法で無理なく記述可能な資料はなるべく標準的な記法で書きます。

「図」の良さは全体的な構造や構成を直観的に把握できることにあると思うので、「図」本来の意図を示す以上の情報(注記の類)はあまり盛り込みません。
そして、図で足りない分は補足資料を作ります。

独自資料は結構、表形式が多いです>自分
あ、状態遷移も表で書いたりするな。。。

引用返信 編集キー/
■10104 / inTopicNo.64)  Re[34]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (101回)-(2007/11/11(Sun) 18:49:42)
> まず、ファームであるかどうかに関わらず、書かねばならないことは全部書きます。
> その代り、書かなくても許してもらえるものは基本まったく書きません。
基本私も同じです。

> UML を使うことにこだわりがないので、UML だけで書く気は毛頭ありません。
> 必要事項の記述に UML で不都合があるなら、その時に必要と思った説明資料を作成します。
> もちろん、標準的な記法で無理なく記述可能な資料はなるべく標準的な記法で書きます。
> 「図」の良さは全体的な構造や構成を直観的に把握できることにあると思うので、「図」本来の意図を示す以上の情報(注記の類)はあまり盛り込みません。
> そして、図で足りない分は補足資料を作ります。
> 独自資料は結構、表形式が多いです>自分
> あ、状態遷移も表で書いたりするな。。。
ファームでのあるところの仕事では客先からWordで資料がきて、UMLやExcelで書類を作ります。
Wordで補足事項を書いたりもします。

大昔から変わったのはフローチャート(手書き)がUMLになった事や手書き資料がWordやExcelになったくらい。
手書き資料がテキストエディタや一太郎、WordやExcelと変わっていくのは普通だと思いますが・・・

設計方法論として進化してない世界です。
引用返信 編集キー/
■10105 / inTopicNo.65)  Re[31]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (539回)-(2007/11/11(Sun) 19:38:02)
渋木宏明(ひどり) さんの Web サイト
> IOポートを集約してクラスみたいに書いてしまうこともあるのでプロパティ間に依存線を書きたいな。

僕なら、状況にもよるけど「I/O ポートにアクセスするクラス」を作りますね。

ポートが複数あるとして、それらのポートが依存関係とかの括りでグループ化できるようなら、グループごとに別クラスとするかもしれません。

あるグループについて、目的の動作を得るためにポートへのアクセス順に制約があるのなら、「目的の動作を得るメソッド」を設置して、そのメソッドの中で規則・制約に基づいてポートにアクセスします。


引用返信 編集キー/
■10112 / inTopicNo.66)  Re[32]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (102回)-(2007/11/11(Sun) 21:49:28)
No10105 (渋木宏明(ひどり) さん) に返信
>>IOポートを集約してクラスみたいに書いてしまうこともあるのでプロパティ間に依存線を書きたいな。
> 僕なら、状況にもよるけど「I/O ポートにアクセスするクラス」を作りますね。
> ポートが複数あるとして、それらのポートが依存関係とかの括りでグループ化できるようなら、グループごとに別クラスとするかもしれません。
C++じゃなくてCだったので、1ファイルに関数をまとめてヘッダーファイルを作ってクラスっぽくしておいてます。

> あるグループについて、目的の動作を得るためにポートへのアクセス順に制約があるのなら、「目的の動作を得るメソッド」を設置して、そのメソッドの中で規則・制約に基づいてポートにアクセスします。
それは当然なんですが、それだとメソッドの中を見ないと制約や規則が見えないわけで、
なんとか図として書いておきたいんですよね。=>コメントいっぱいの出番なんです。

引用返信 編集キー/
■10117 / inTopicNo.67)  Re[33]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (542回)-(2007/11/11(Sun) 22:44:38)
渋木宏明(ひどり) さんの Web サイト
2007/11/11(Sun) 22:52:24 編集(投稿者)

> それは当然なんですが、それだとメソッドの中を見ないと制約や規則が見えないわけで、
> なんとか図として書いておきたいんですよね。=>コメントいっぱいの出番なんです。

僕なら、そこは UML で記述しません。実装の詳細なので。
そこで行うべき操作だけを示し、「ポート操作の順番などに制約があること」をコメントしておきます。

具体的な制約の内容は、それだけを別表にまとめた上で、シーケンス図やコラボレーション図的なもので説明します。(だいたいハシゴ図で用が足りるはず)

制約の内容や開発環境、仕様を伝達する相手(のスキル)などの状況によっては、さらに関数仕様にまで落としこむかもしれません。


引用返信 編集キー/
■10118 / inTopicNo.68)  Re[31]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ れい (188回)-(2007/11/11(Sun) 22:45:17)
2007/11/11(Sun) 22:56:26 編集(投稿者)

ちょっと見ない間に進んでいる…。

No10100 (カンタービレ さん) に返信
> 並列を表現したい場合、どうしたって1回のシーケンス図に、複数(並列)を表しにくいですもんね。
> 工夫がうまく加わり、ツールとしての表現の幅が広がることは歓迎派デス。

わたしはUMLあまり使わないんであてになりませんが、
並列処理を書くにはちょっと足りない気がするんですよね。

わかりやすく書くこともできなくはない気がするんですけど。

UMLを使って設計をしてると、オブジェクト指向が苦手な人でも、
だんだんとうまく設計できるようになってきますよね。
うまく設計できてないといろいろ書きづらいですから。

並列化も同じようになってくれたらいいなぁと。
もしできたら、それはハードウェアでもソフトウェアでも、
応用が利くと思うんです。

ただですねぇ。

具体的にどうしたらよいのか、
私には全くわかりません。

今まで作ってきた物を再利用すれば、
あまり脳みそを使わなくても並列化できる状況なんですが、
それらを眺めても、それらを汎化することはできませんでした。

どっかのレスで書いた「無いなら作る」というスタンスと矛盾するんですが、
私には具体的アイデアがありません。要望だけで。

並列化したとき、スレッドがたくさん絡んだようなコードを書くとき、
どのような設計図を書いているのか、書きたいのか、
皆さんの豊富な経験を聞きたいところです。

そこから何かいいアイデアがでるかも。

ですのでひどりさんとえむナウさんの議論は非常に参考になります。
えむナウさんはすごく困ってそうで、なんとなく理解できます。
ひどりさんは困ってなさそうですが、なぜなのかも知りたいですね。
引用返信 編集キー/
■10122 / inTopicNo.69)  Re[34]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 中博俊 (1198回)-(2007/11/11(Sun) 23:44:50)
中博俊 さんの Web サイト
>UMLを使って設計をしてると、オブジェクト指向が苦手な人でも、
>だんだんとうまく設計できるようになってきますよね。
>うまく設計できてないといろいろ書きづらいですから。

本当にそう?
そしてそんなものを利用しないとオブジェクト指向って苦手を克服できないの?
そんなものがあるから小難しく考えなくちゃいけなくなってしまっていない?

続きはメタボにも効くかもしれないオブ熱で!!(^^
引用返信 編集キー/
■10123 / inTopicNo.70)  Re[35]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (103回)-(2007/11/12(Mon) 00:08:32)
>続きはメタボにも効くかもしれないオブ熱で!!(^^
そうですね。
マルチコア・マルチスレッド・ハードウェア・ファームウェアとUMLに関するネタと愚痴は一通り書いたから。
この辺でオブ熱に回しますか。


引用返信 編集キー/
■10126 / inTopicNo.71)  Re[32]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (544回)-(2007/11/12(Mon) 00:11:24)
渋木宏明(ひどり) さんの Web サイト
> ひどりさんは困ってなさそうですが、なぜなのかも知りたいですね。

何度も書いてますよ (^^;

「オブジェクト指向的な構造設計で並列を表現しようとしてない」から、です。

具体的な手法というのはあまり意識していませんが、プライマリスレッド(でやるべきこと)とワーカスレッド(でやるべきこと)のモデルを別個に書いて、非同期メッセージングと同期でつなぐ、とか場合によっていろいろです。

たぶん、何パターン化には分類できる気はします。

引用返信 編集キー/
■10127 / inTopicNo.72)  Re[36]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 凪瀬 (3回)-(2007/11/12(Mon) 00:11:44)
凪瀬 さんの Web サイト
おわー。週末見てないうちにえらい議論が進んでるw
マルチスレッド分科会みたいなのが必要になるかも。

オブ熱では控えたほうがいいかもしれませんねー。
脱落者続出というか。ターゲット的に。
2次会ぐらいで内々に議論するのはいいんだけどw
引用返信 編集キー/
■10130 / inTopicNo.73)  Re[33]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ れい (189回)-(2007/11/12(Mon) 00:27:26)
No10126 (渋木宏明(ひどり) さん) に返信
>>ひどりさんは困ってなさそうですが、なぜなのかも知りたいですね。
> 「オブジェクト指向的な構造設計で並列を表現しようとしてない」から、です。

ではどうやってるのか、というのを知りたいわけです。

> たぶん、何パターン化には分類できる気はします。

そのパターンを知りたいです。

私の持ってるパターンは非常に貧弱ですが、列挙してみます。

といっても、
自分用メモをちょっと編集してを貼り付けるだけなんですケド。
設計はそのメモを考えつつ行います。

参考になるかわかりませんというか、たぶんなりませんが。


○非同期IO、もしくはそんな感じのもの。

GUIスレッド+ワーカースレッド。ある程度の時間でタスクが終わるタイプ。
一番よく使う
・ファイルのコピー
・TCPのクライアント
・画像描画
・データベース接続
など。
BackgroundWorkerは親フォームの廃棄時に問題があるので使わない。
MSDN「イベントベースの非同期パターンの概要」に書かれてるようなクラスを
自分で実装して使う。

処理が頻繁な場合はスレッドプールの利用を考える。

○監視

GUIスレッド+無限ループしてるワーカースレッド。
監視対象ごとに1クラスで1スレッド。
ワーカースレッドからイベントを挙げてメインスレッドに通知するのか、
メインスレッドからオブジェクトを定期的に監視して状態変更を知るのか、
そういった辺がいつも悩みどころ。
この辺、いいパターンが何種かあるはずだと思ってるが、思いつかない。

○細かい処理が非同期にたくさんくる場合。

GUIスレッド+スレッドプール。
イベントあるたびに計算する必要があるとき。
・デバイスからのイベント通知の度にログファイルを書く
・クリックするたびにWebにデータを送るとき、
とか。
あまり利用することは無い。

○TCPのサーバー

基本的にシングルスレッドで複数の非同期IOを処理する。
スレッドを回して、複数の同期オブジェクトを待つ形で。

1スレッド-1TCP接続は遅すぎるしスレッドの管理がめんどくさいので、ダメ。
1スレッド-多TCP接続が作りやすくてパフォーマンスもいい。
ただし、この場合は受信・送信時の処理を細かいタスクに分けなければダメ。
分けられない場合はマルチスレッドに。

○.Net Remoting

TCPを用いたサーバー/クライアントを作ったほうが
保守性も生産性も再利用性も高い。私には不必要。
久しく使っていない。

○モンテカルロシミュレーションや、それに類する分離可能な計算問題

完全に問題が分離できるので、自作Gridっぽいものに流す。

具体的には、シミュレーションをするexeを作成し、
管理下にあるノードPCにWebDAVで配布。
ノードPCはアップロードされたexeを自動実行するようになっていて(!!)
計算結果はHTTPでアップロードされたりTXTで残る。
手元PCで集計して解析。

○分離できない数値計算

数式変形などを駆使して、同期しなくていい単位になるまで分離する。(ここが難しい。)
その後、Gridに流すか、複数PCで複数exeの実行。
あとはモンテカルロと同じ。
できない場合は泣く。

たぶんこれで全部。
当面困ってないんですが、どこかダメな気がしてならないです。

No10122 (中博俊 さん) に返信
> >UMLを使って設計をしてると、オブジェクト指向が苦手な人でも、
> >だんだんとうまく設計できるようになってきますよね。
> >うまく設計できてないといろいろ書きづらいですから。
> 本当にそう?
> そしてそんなものを利用しないとオブジェクト指向って苦手を克服できないの?
> そんなものがあるから小難しく考えなくちゃいけなくなってしまっていない?

んー。上のように言ってた人はいますが、実際はどうなんでしょう。
苦手な人の気持ちは私には良くわかりません。
オブジェクト指向暦とUML暦では10倍くらい差がありますから、
UMLからオブジェクト指向を学ぶってのは少ないです。

> 続きはメタボにも効くかもしれないオブ熱で!!(^^

私はこれ以上痩せると困ります。
みなさん、がんばってきてください。

引用返信 編集キー/
■10142 / inTopicNo.74)  Re[34]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (548回)-(2007/11/12(Mon) 01:59:04)
渋木宏明(ひどり) さんの Web サイト
> そのパターンを知りたいです。

別に珍しくもなんともないですよ。

(1) 比較的少数の処理対象を、処理対象と同じ数だけスレッドを作って処理を分配し、全件の処理完了を待つ。
(2) 沢山の処理対象を、利用可能なスレッドで処理を分配し、全件の処理完了を待つ。
(3) 沢山の処理対象を、利用可能なスレッドで同時並行に処理しているように見せかける。

なんてとこですね。

非同期デリゲートで書ければ書きマス。

.NET のスレッドプールは完了待ちが面倒なのであまり使いません。
スレッド管理用のクラスを自分で作りマス。

> BackgroundWorkerは親フォームの廃棄時に問題があるので使わない。

これ、前にも書いたけど作りこみ次第ですよ。
ワーカー稼働中に FormClosing が発生したら、とりあえず FormClosing をキャンセルしておいて。。。です。

「Invoke が信用ならない」というのが理由だとしたら、BackgroundWorker を使わなくても状況は同じでしょう。

> GUIスレッド+無限ループしてるワーカースレッド。
> 監視対象ごとに1クラスで1スレッド。
> ワーカースレッドからイベントを挙げてメインスレッドに通知するのか、
> メインスレッドからオブジェクトを定期的に監視して状態変更を知るのか、
> そういった辺がいつも悩みどころ。
> この辺、いいパターンが何種かあるはずだと思ってるが、思いつかない。

僕は、プライマリスレッドからワーカースレッドに対して非同期に通知をして、応答も非同期で受け取るようにしてます。
それ以外のパターンはもっと面倒なことになった経験しかないので、可能な限り避けてます。

> ○.Net Remoting
>
> TCPを用いたサーバー/クライアントを作ったほうが
> 保守性も生産性も再利用性も高い。私には不必要。
> 久しく使っていない。

同じく。どうせポートも占有しちゃうし。
性能がいらないなら、それこそ Web サービスにしてしまいます。

> ○分離できない数値計算
>
> 数式変形などを駆使して、同期しなくていい単位になるまで分離する。(ここが難しい。)

前に書いてますが、「並列実行に向いている問題以外」を並列実行に適した問題に変形するためには、まだとーぶんの間人間様が頭を使うことになると思いマス。
ただ、計算式くらいなら近々にでもコンパイラがやってくれそうな気配はありますね。

引用返信 編集キー/
■10144 / inTopicNo.75)  Re[35]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ れい (190回)-(2007/11/12(Mon) 03:02:00)
2007/11/12(Mon) 03:18:52 編集(投稿者)

No10142 (渋木宏明(ひどり) さん) に返信
> 非同期デリゲートで書ければ書きマス。

ファイルやネットアクセスのためのIAsyncResultははよく使いますが
スレッドを生成しちゃう非同期デリゲートはあまり使いません。
スレッドライフサイクルが小さいとコストが気になって、
大きいとコンポーネント化したくなってしまうので。

> .NET のスレッドプールは完了待ちが面倒なのであまり使いません。

そういえば
非同期デリゲートのコールバックでは、
結構つかってました。

> スレッド管理用のクラスを自分で作りマス。

ここが本質でないところですよね。
再利用できるコードを持ってるからそんなに大変ではないわけですが、
これが無かったらいいのになぁと思います。

> これ、前にも書いたけど作りこみ次第ですよ。
> ワーカー稼働中に FormClosing が発生したら、とりあえず FormClosing をキャンセルしておいて。。。です。

まぁそうなんですが、Closingでいろいろやりたいことがある場合、
それとの兼ね合いで複雑になってしまいます。

外部にコードがいるならコンポーネント化する意味は減るので、
私はこの辺はあきらめました。

>>この辺、いいパターンが何種かあるはずだと思ってるが、思いつかない。
>
> 僕は、プライマリスレッドからワーカースレッドに対して非同期に通知をして、応答も非同期で受け取るようにしてます。

どうやって非同期に通知しているのでしょうか?
イベント+Invoke?
同期オブジェクト?
Windowメッセージ?
ただの同期化されたフラグ?
ポーリングするんでしょうか。

そこが、私にはうまく作れません。

>>○.Net Remoting
> 性能がいらないなら、それこそ Web サービスにしてしまいます。

Webサービスも通信コストは殆ど変わりませんからね。

忘れてましたが私もWebサービスは使ってます。
並列化の為かどうかわかりませんが。

最近はWebサービスも要らないなぁと思い始めてます。

>>○分離できない数値計算
> ただ、計算式くらいなら近々にでもコンパイラがやってくれそうな気配はありますね。

コンパイラがやってくれても、現状ではPC内での並列化しかできません。
これをどうにかして自動で分けたいんですよねぇ。
できたらだいぶ楽になるのに。
引用返信 編集キー/
■10145 / inTopicNo.76)  Re[37]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ ひろえむ (48回)-(2007/11/12(Mon) 06:37:26)
2007/11/12(Mon) 06:39:06 編集(投稿者)

No10127 (凪瀬 さん) に返信
> オブ熱では控えたほうがいいかもしれませんねー。
> 脱落者続出というか。ターゲット的に。
> 2次会ぐらいで内々に議論するのはいいんだけどw

んーそうですね(^^;

欠点を理解しておくことは大切だと思いますが、こちらの問題はマルチスレッドを表現するための方法論にまで波及しているようですので、あまり広げない方向でしょうか(^^;;

とりあえず、オブ熱では初心者もしくは初心者を教えるという方向で(^^;;

あ、もちろん、今行っている議論は引き続き盛り上がってもらってOKですよ(^^)


引用返信 編集キー/
■10148 / inTopicNo.77)  Re[38]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ シャノン (220回)-(2007/11/12(Mon) 10:53:11)
まだ誰も書いてないかなー? 既出だったらごめん。
並列処理は、Erlang とかアクター指向を調べてみると面白いかもですよー?
引用返信 編集キー/
■10156 / inTopicNo.78)  Re[39]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (104回)-(2007/11/12(Mon) 14:23:06)
No10148 (シャノン さん) に返信
> まだ誰も書いてないかなー? 既出だったらごめん。
> 並列処理は、Erlang とかアクター指向を調べてみると面白いかもですよー?
アクターモデルですね。
大昔のアクターモデルからどう進化したのか詳しく知りたいので教えてもらえますか?

引用返信 編集キー/
■10162 / inTopicNo.79)  Re[40]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (105回)-(2007/11/12(Mon) 15:04:06)
ちなみにダイクストラのモデルとその発展形としてのアクターモデルも含む並列化議論の内容は、
既に.Net FrameWorkに組み込まれています。

引用返信 編集キー/
■10203 / inTopicNo.80)  Re[41]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
 
□投稿者/ シャノン (221回)-(2007/11/13(Tue) 18:04:41)
No10162 (えムナウ さん) に返信
> ちなみにダイクストラのモデルとその発展形としてのアクターモデルも含む並列化議論の内容は、
> 既に.Net FrameWorkに組み込まれています。

むしろ詳細キボンしてみる。
引用返信 編集キー/

<前の20件 | 次の20件>
トピック内ページ移動 / << 0 | 1 | 2 | 3 | 4 >>

管理者用

- Child Tree -