トップページ⇒php
1001コメント310KB

【PHP】フレームワークについて語るスレ9【総合】

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2007/12/11(火) 23:37:20ID:???
前スレ
http://pc11.2ch.net/test/read.cgi/php/1192604501/
0102nobodyさん2007/12/14(金) 15:55:58ID:???
>>101
===はもちろん知ってるが
やっぱりおかしいだろ
0103nobodyさん2007/12/14(金) 16:09:12ID:???
>>102
自動的に型変換するんだからおかしくないだろ
0104nobodyさん2007/12/14(金) 16:23:21ID:???
自動変換ったって
ヌルストリング→0
何らかの文字→1
になるのが普通の感覚じゃね？
0105nobodyさん2007/12/14(金) 16:48:46ID:???
てゆーか、==で比較してる奴なんているの？
0106nobodyさん2007/12/14(金) 16:55:03ID:???
>>105
結構いる。マニュアルもろくに読まないタイプ。

しかしPHPの暗黙の型変換は糞仕様だからハマリやすいな。
0107nobodyさん2007/12/14(金) 20:00:04ID:???
みんなもういいかげんphpなんかやめてioLanguageやろうぜ！

http://www.iolanguage.com/about/
0108nobodyさん2007/12/14(金) 22:10:43ID:???
いや、俺は普通に使ってる。 > ==
ちゃんとわかってて使う分にはいいんじゃないの?
っていうか、全部===や!==ってっやてるわけ?
0109nobodyさん2007/12/14(金) 22:20:12ID:???
>>108
俺はそう。
あぶかっしくて比較なんか出来ない。
つか、比較ちゃうやん。
01101082007/12/14(金) 22:23:14ID:???
>>98
文字列と0が常に等価となる訳でもない。
(int)"123abc"==123 になる。

サニタイジングしてれば不意に文字列と数値を比較するときなんてそうそうないけどなぁ。
===や!==を使うときは関数が0やfalseやnullを返す可能性があるときぐらいかな。
0111nobodyさん2007/12/15(土) 01:35:35ID:???
・比較演算子を使う時、両辺のどちらかが数値の場合には暗黙で数値に変換される
・上記の変換で文字列が数値変換される時のルールが
　「数値と解釈できる文字列から始まっていれば」その数値になり、「その他の場合」は0になる

"str" == 0 // true, "str" -> 0
"123str" == 123 // true, "123str" -> 123
"str123" == 123 // false, "str123" -> 0
"1.0str" == 1 // true, "1.0str" -> 1

・数値と文字列を比較すると暗黙で変換されるのでそうしないことを心掛ける
・想定する型比較と違う型が来る可能性がある場合はキャストしておく
のが重要、っていうか普通に書いてる分には困らない

あとこの型変換の仕様だけを出してきて「PHPの言語仕様は糞だ」
っていう奴はPHPより糞
PHPにはもっと言語仕様が糞なところはいっぱいある、
それはPHPユーザが一番知っている
0112nobodyさん2007/12/15(土) 03:17:51ID:???
"123str" -> 123
こんな中途半端な変換迷惑なだけです(><)
0113nobodyさん2007/12/15(土) 05:36:41ID:???
PHPの型変換はやっぱ変だよねえ。もっともnumber型とstring型で、型宣言できるようにした方がバグの混入が防げて結局効率的だと思うね。intとかfloatとか細かく分ける必要はないけど。
01141082007/12/15(土) 06:24:55ID:???
型宣言は今更のような気もするが...、まぁ動的型変換はなくてもいいかな。
宣言により型が決っちまうとfopenとかstrpos等、失敗したときなんかにfalse(boolean)を
返してしまうものは、上で誰かが書いてたけどそれこそ例外を投げてくれないといけなくなる。
そこまで求めるのなら他の言語へいった方が早くね?
0115nobodyさん2007/12/15(土) 06:31:39ID:???
そもそも複雑なプログラムを組むのにPHPを使うのが間違いなんじゃないの。
手早く簡素なコード組むためのもんだろ、PHPって。
0116nobodyさん2007/12/15(土) 07:26:06ID:???
>>112

CSS用だろ。
0117nobodyさん2007/12/15(土) 13:43:35ID:???
スキル低いウェブデザイナーが使う言語だからね。
使い続けていくうちにノウハウたまってくると、Javaでミドルウェア化してしまった方が便利。
PHPでの再利用なんてゴミだし、運用メンテが面倒。
0118nobodyさん2007/12/15(土) 16:49:00ID:???
>>53
嘘付くな。
固定文字列を変更できるかどうかは実装依存。
0119nobodyさん2007/12/15(土) 17:28:36ID:???
どっから固定文字列の話が出てきたんだ?
0120nobodyさん2007/12/15(土) 17:32:00ID:???
＞ char str[] = "hoge";

どう見ても文字列定数です
0121nobodyさん2007/12/15(土) 19:31:34ID:???
実装依存だけど、むしろできない方が多いんじゃないかな
0122nobodyさん2007/12/15(土) 19:44:39ID:???
そうなの？Cはほとんど知らないけど、うちのDebianに入ってたgccでは出来た。

#include <stdio.h>

int main()
{
char str[] = "hoge";
str[0] = 'm';
printf("%s\n", str);
}
0123nobodyさん2007/12/15(土) 19:48:39ID:???
おまえら、C FAQ の1.32くらい読んどけ
0124nobodyさん2007/12/15(土) 20:16:47ID:???
オープンソースで配布するんでもなけりゃ、バイナリになってしまえば・・・
0125nobodyさん2007/12/15(土) 20:25:06ID:???
試してみたが、上のgccに加え、bcc55(bcc32.exe), VC++2005(cl.exe)でもできたな。
仕様上は不定かもしれんが、できない方が多い、かどうかは別かも。

というか、間違いなくスレ違い。以降は自重する。
0126nobodyさん2007/12/15(土) 20:40:00ID:???
ここはPHP一筋の人だけのスレです
他言語も使ってる意志の弱い奴は去れ
0127nobodyさん2007/12/15(土) 21:36:19ID:???
>>126
勝手にそんなこと決めんな。
つか、他の言語やってない奴なんてほとんどいないだろ。
それに他の言語の知識は何かと役立つ。
0128nobodyさん2007/12/15(土) 21:48:41ID:???
今のところ実装が一つだけのPHPは幸せだな・・・と思いきや言語仕様も無いようなもんかｗ
まあそれはRubyも同じだけど
（Windows版で商用につかってる超マイノリティは無視だ）
0129nobodyさん2007/12/15(土) 21:58:55ID:???
>>127
＞それに他の言語の知識は何かと役立つ。
これは他のスレでやるべきだろw
スレタイを読んでからレスはするべきだと思うわ。
0130nobodyさん2007/12/16(日) 00:52:29ID:???
ワイズノットが民事再生手続開始
http://slashdot.jp/articles/07/12/15/1414237.shtml
ワイズノット脂肪でPHPも連鎖的に脂肪ｗｗｗ
0131質問2007/12/16(日) 01:48:45ID:6S6s0OEC
[1]よく使うPHPフレームワークは？
[2]昔使っていたPHPフレームワークは？
[3]PHP4系とPHP5系どっちらを多く使う？
[4]テンプレートシステムを使うとしたら何使う？
[5]IDEとかは使う？
[6]よく使うRDBは？
[7]PHP以外でWEBアプリを作るとしたら何を使う？
0132nobodyさん2007/12/16(日) 02:11:10ID:???
>>131
叩かれるの承知で書いてみる。
1.俺俺 今後はZendFW?
2.俺俺
3.PHP4 漸く5に移行中。
4.Smarty
5.PDTなんだがVs.Phpを使ってみたい。
6.PostgreSQL
7.Mono(ASP.NET C#)
0133nobodyさん2007/12/16(日) 02:46:26ID:???
俺も便乗してみる
[1]cakephp
[2]ethna+syrup+かなりのオレオレ改造(使用頻度は低いけどまだ使う事はあると思う)
[3]しがらみが無ければ5系だけど、安い案件ばかりなので選ぶ自由がほぼない
[4]Smarty
[5]PDT
[6]PostgreSQL
[7]RubyとPythonが興味あるけどどっちもほとんどいじってない（；´Д｀）
0134nobodyさん2007/12/16(日) 06:12:58ID:???
>>98
それ少しスレ違いやろ、テーマに沿って書き込めやボケ
0135nobodyさん2007/12/16(日) 06:21:49ID:???
>>134
スレ違いの書き込みなんていくらでもあるのになんでそこだけキレたんだ？
0136nobodyさん2007/12/16(日) 06:28:37ID:???
phpはフレームワークに向いてない言語くさいね
どれだけの時間がかかるか知らないけど
便利なライブラリと実用性がphpほど追いつけば
最終的にはRORがWEBプログラムの主流になるね
0137nobodyさん2007/12/16(日) 06:31:25ID:???
>>134
国分「PHPが糞言語と分かってどんな気持ちだった？
0138nobodyさん2007/12/16(日) 06:35:10ID:???
PHPはフレームワークに向いてないから乱立するんだよな
今の水準よりも上のフレームワークはもう出来ないだろう
早い話がPHPでrailsを超えるフレームワークを作るのは言語的に無理
0139nobodyさん2007/12/16(日) 06:36:05ID:???
>>131
答えてみる
1. rhaco
2. Ethna（現役）
3. 5
4. rhaco
5. 使わない
6. MySQL / SQLite
7. Python
0140nobodyさん2007/12/16(日) 06:38:42ID:???
フレームワーク全盛になったのを機会に
ｐｈｐの時代がそろそろ終わりそうな気がする
0141nobodyさん2007/12/16(日) 06:39:52ID:???
[1]symfony
[2]mojavi
[3]5
[4]使わない
[5]Zend
[6]MySQL
[7]Python
0142nobodyさん2007/12/16(日) 06:46:33ID:???
[1]Phrame
[2]なし
[3]PHP3
[4]html
[5]Iメモ帳
[6]CSV
[7]CGI
0143nobodyさん2007/12/16(日) 08:11:44ID:???
pythonの引数の自由度の高さは異常
キーワード引数
*args
**args
あたりはPHPもパクるべき
0144nobodyさん2007/12/16(日) 08:44:45ID:???
>>143
なんでテーマからずれるかな
0145nobodyさん2007/12/16(日) 09:22:33ID:???
Ethna使ってた人はrhacoに行くパターンも多いんだな
haltさんとかriafさんとかが使ってるのも大きいんだろう
0146nobodyさん2007/12/16(日) 10:42:49ID:???
[1]俺俺railsもどき
[2]俺俺
[3]PHP5系
[4]俺俺からincludeしてviewのPHPファイル読むだけ。
[5]ZendStudio。VS.Php試用版使って、安いしこっちでも良かったと後悔中。
[6]MySQL。ライセンス考えたらこれしかない。
[7]Java。てか配布用にPHPでやってるだけ。ASP.NETも好きだけどレンタル鯖が高いからやめ。
0147nobodyさん2007/12/16(日) 10:56:16ID:???
[1]Zend
[2]-
[3]5
[4]Zend
[5]Eclipse
[6]MySQL
[7]Java+WebObjects
0148nobodyさん2007/12/16(日) 14:15:36ID:???
>131
アンカー付けないと、何がなんだかわからんね。

[1]symfony
[2]Mojavi3
[3]5
[4]今のところ無し
[5]前はZend Studio
[6]PostgreSQL
[7]Ruby（Rails）

これに加え、
[8]気になってるPHPフレームワーク

を付け加えて欲しいな。

俺は
[8] Akelos
0149nobodyさん2007/12/16(日) 14:39:02ID:???
みったんフレームワーク使ってる奴出てこい。
0150nobodyさん2007/12/16(日) 15:42:25ID:???
一般に公開してないからみったんだけだろ
0151nobodyさん2007/12/16(日) 16:27:32ID:???
Framework全般に直接関係する事じゃないんだけど
文字エンコードってどれ使ってる？
一昔前はEUC-JPが常識って感じだったけど、最近はUTF-8が多いんだろうか。
FrameworkによってはUTF-8使うのを半ば必須みたいに書いてるのもあるし。
昔はPHPで検索かけて色々サンプルとか見ても、設定の例もサンプルの中身も大抵EUC-JPだったよね。

自分はその頃からそれがなんだか嫌で、ASP.NETもやってるんだけどこっちはUTF-8が相性良くて
これといって文字コード関係で悩まされた事がないんで好きなんだけど
やっぱまだEUC派って多い？

JavaとPHPは初めてやった時やたらエンコード関連の文字化けで悩まされた・・・
特にアップロード機能とかメールとか絡むと。

これからはPHPでもUTF-8がデファクトスタンダードになっていくのかなあ。
なっていって欲しいけど。
0152nobodyさん2007/12/16(日) 17:11:25ID:???
みったんフレームワークマニュアルだけ公開してるんだっけ？
ていうか知ってる奴いるのか
0153nobodyさん2007/12/16(日) 17:18:18ID:???
ttp://longinus.org/src/mars/manual/index.html

これか
公開してない割りにはドキュメント整備しすぎだろ
0154nobodyさん2007/12/16(日) 17:23:39ID:???
商売だからさ
0155nobodyさん2007/12/16(日) 17:29:14ID:???
PEARに依存してるフレームワークは使う気にならないんだよなあ。
相手先でそれが使えるとは限らないから。
単体で動くのが一番楽で環境依存しないからいい。
0156nobodyさん2007/12/16(日) 17:45:35ID:???
PEARもパッケージに含めたらいいんじゃないの
0157nobodyさん2007/12/16(日) 20:07:08ID:???
UNIXのコマンドラインツールは今でもEUC前提のが多い。UNIX上で開発しようとすると、EUCがやりやすい。
0158nobodyさん2007/12/16(日) 20:14:36ID:???
みったんフレームワークDIコンテナも付いてるな
0159nobodyさん2007/12/16(日) 21:17:33ID:???
>>157
でも最近はDBをUTF8にすることって多くない？
0160nobodyさん2007/12/16(日) 21:22:28ID:???
utf8の完全勝利っぽいですよ、最近。
0161nobodyさん2007/12/16(日) 21:43:10ID:???
PEARがあった方が楽、環境に依存した方が楽
0162nobodyさん2007/12/16(日) 21:54:20ID:???
DBをSJISにしてこそPHPプロ
0163nobodyさん2007/12/16(日) 23:19:35ID:???
Ajaxが絡んでくるので最初からUTF-8の方が変換がない分楽。
PostgreSQL7.xとEUCでやってたらつっこめない文字とかあるし。
01641632007/12/16(日) 23:25:50ID:???
さらにスレチネタになるんだが文字コードついでに...
㈱とかをPDTだとEUCで保存できない。
㈱って入力されたら「株式会社」と変換したいだけなんだが。
0165nobodyさん2007/12/16(日) 23:57:50ID:???
http://blog.ohgaki.net/index.php/yohgaki/2007/12/16/squirrelmail-1
SquirrelMailに攻撃コード埋め込まれてPHP普通に脂肪ｗｗｗ
0166nobodyさん2007/12/17(月) 00:14:19ID:???
>>164
で？
0167nobodyさん2007/12/17(月) 00:20:03ID:???
>>155
FWに依存してるのは良くてPEARに依存するのがダメな理由は？
相手先で使えると限らないのはFWも一緒では？

>>157
んなこたない
ターミナルUTF-8にしてそれが原因でUNIX上で困った事とか特にない
0168nobodyさん2007/12/17(月) 00:22:48ID:???
>>166
>>163+164でUTF-8でいいじゃんってことだけ。
0169nobodyさん2007/12/17(月) 01:59:39ID:???
前スレ

------------------------------------------------
　□ 962　 nobodyさん　 [sage] 2007/12/09(日) 22:40:08 ID:???

>>960
それ（変換とか）よりもSJISの場合はダメ文字絡みがやっぱり一番大きいと思うんだ。
シングルバイト圏の作るライブラリとか。

大体文字コードの変換なんてかつては「必要悪」だったのが今やただのオーバヘッドや
不具合の温床だと思ってそれほど間違ってるかな。

要はWindowsさえ次のOSでごにょごにょやってSJIS(CP932？)捨ててくれれば、問題の
大部分はweb系に関してはほとんど片づきそうな気もする。

------------------------------------------------

これEUCも一緒だろ。ダメ文字が無いってだけで、ラテン文字入ったら文字コード変換は必須。
お前ら直近でループしてるんじゃねえよｗ
0170nobodyさん2007/12/17(月) 08:02:39ID:???
俺はmysql使ってるから
すべてUTF-8に統一すればいいんだよ
0171nobodyさん2007/12/17(月) 08:03:59ID:???
文字コードで議論してるやつは
激しくスレ違いだけどな！
0172nobodyさん2007/12/17(月) 09:28:32ID:???
改修案件で、初めてオレオレFWというやつを触ることになった。

1つ1つのメソッドがやってることはコメントに書いてくれてるんだが、それがどういう順番に動作して
いるのか意味不明。
コントローラ内に平気でSQL直書きしてあったり、SQL文組み立てのメソッドがあったりする。
モデルは単にネイティブ関数のラップ。（Pear::DBもどきをモデルと言い張ってるorz）
それのどこがMVCやねん！と突っ込みたくなるが、コメントには「これはMVCフレームワーク」とか
書いてあるｗ

中途半端なコメントじゃない系統立てたドキュメント残してくれるならともかく、自己満FWを使ったなら
改修も一生面倒見てほすぃ。
0173nobodyさん2007/12/17(月) 09:33:34ID:???
ソースレベルデバッガで追えばいい。てかWEBのデバッグなんか楽勝だろ。
リクエスト出して最後に何か吐いて終わりなんだし。
スパゲティになりようがない。
php1枚にプログラムもHTMLべた書きのウンコソースメンテするよりはマシだと思うぞ。
0174nobodyさん2007/12/17(月) 11:58:48ID:???
WEBなんてprint_r使えば
どこでもいつでもすぐデバッグできるよ
0175nobodyさん2007/12/17(月) 22:58:15ID:???
クラスを多用するとprintデバッグじゃきつくなる。その点からもウェブにオブジェクト指向は控えるべきと言える。
0176nobodyさん2007/12/17(月) 23:10:02ID:???
ソースレベルデバッグしろっての・・・
0177nobodyさん2007/12/18(火) 09:33:48ID:???
どなたか数n行でMVCの基本構造のコードを書いてください
0178nobodyさん2007/12/18(火) 09:38:53ID:???
だが断る
0179nobodyさん2007/12/18(火) 09:53:40ID:???
どなたかフレームワークの構造を簡単に教えてください。
0180nobodyさん2007/12/18(火) 10:37:40ID:???
>>179
ttp://codezine.jp/a/article.aspx?aid=104
これを読むといいよ。
0181nobodyさん2007/12/18(火) 10:37:47ID:???
M->DB制御
V->HTML制御
C->MとVをコントロールする中間管理職
0182nobodyさん2007/12/18(火) 11:41:55ID:???
>>181
勉強しなおせ
0183nobodyさん2007/12/18(火) 11:51:44ID:???
>>182
つり？
0184nobodyさん2007/12/18(火) 12:49:19ID:???
http://ja.wikipedia.org/wiki/Model_View_Controller
0185nobodyさん2007/12/18(火) 13:14:07ID:???
>>181
Modelはテーブルを具現化したものとは限らないとおも。
0186nobodyさん2007/12/18(火) 13:16:50ID:???
>>183
お前がつり？
0187nobodyさん2007/12/18(火) 13:19:19ID:???
ぁ、ぁのう、どなたかフレームワークの構造を簡単に教えてください。
できれば単純なものをコードで書いて頂ければ幸いです。
0188nobodyさん2007/12/18(火) 13:38:03ID:6timmGHR
// ここに前処理

for ($i = 0; $i < 100; $i++) {
// ここに処理
}

// ここに後処理


何かの処理を100回繰り返すフレームワーク
どうだすごいだろ。えへん
0189nobodyさん2007/12/18(火) 13:58:25ID:???
ツッコミづらい
0190nobodyさん2007/12/18(火) 14:23:59ID:???
>>181
簡単に表現すればそんなもんだろ
0191nobodyさん2007/12/18(火) 14:25:56ID:???
>>185
おまえみたいなのが
MにCの処理させたりすんだろうがボケ
きっちりわけろよ！
0192nobodyさん2007/12/18(火) 14:28:57ID:???
単純なコードにするのがフレームワークなのに
フレームワークを単純なコードでかけるか！
0193nobodyさん2007/12/18(火) 14:29:54ID:???
フレームワークばっかり使ってると脳が解けるよ
0194nobodyさん2007/12/18(火) 14:34:08ID:???
>>186
なにも具体的な反論できないとこみると、釣りみたいだな
0195nobodyさん2007/12/18(火) 14:55:05ID:???
>>187
フレームワークのやることは、ユーザからのリクエストに応じて、呼び出す関数やクラスを決定し、実際に呼び出すだけ。それをどれだけ便利にできるかで、各フレームワークの特徴が出る。

<?php
// _actionパラメータの値を調べる。なければ 'index' を使う。
$action = $_REQUEST['_action'];
if (! $action) $action = 'index';

// 関数 do_$action() を実行する（例えば do_index(), do_list() など）。
// これらの関数はアクションを処理するのでアクションハンドラと呼ばれる。
// フォーム値のチェックやDB操作はアクションハンドラの中で行う。
require_once("$action.php");
$funcname = "do_$action";
$ret = $function();

// 配列が返されたら、テンプレートを読み込んで表示する。
// 文字列が返されたら、それをURLとみなし、リダイレクトする。
if (is_array($ret)) {
  $template = "templates/$action.php";
  extract($ret);
  include($template);
} else if (is_string($ret)) {
  header("Location: $ret");
}
?>
0196nobodyさん2007/12/18(火) 15:02:43ID:???
MVCを現実の何かに例えて・・・
とか考えたのだが、いい例が浮かばない・・・

M：銀行（お金貸す側）
V：企業、個人（お金借りる側）
C：国（ルール決める側）

こりゃぜんぜん違うしなー
おまいら何か妙案ありませぬか？
0197nobodyさん2007/12/18(火) 18:37:09ID:???
Mに具体的に何やらせれば良いのかが良くわかりません。
詰まる所、DBやファイルからデータを引っ張って来たり、書き込んだりって言う処理を汎用的に使える様にしたプログラムはMですか？
0198nobodyさん2007/12/18(火) 19:35:00ID:???
どっかからとってきたデータをごにょごにょ加工するのがMで加工したデータをどのテンプレートに渡すか決めるのがCでそれを表示するのがVでつ
0199nobodyさん2007/12/18(火) 19:37:57ID:???
>>184嫁よ
0200nobodyさん2007/12/18(火) 19:40:23ID:???
まあModelかと。
逆にみんなそこまでは判ってて、それだけ考えてピンとこなくなってる奴いるんじゃないかなー
モデル化すべき部品が数えるほどしかない場合って、MVCに拘っても特に嬉しい事ないのよね

M：金全般の定義と、基本的な処理の実装
　・価値クラス
　　・価値クラスを継承した「動産」
　　・価値クラスを継承した「不動産」
　　・価値クラスを継承した「貨幣」
V：金扱う場所や事例
　・不動産屋
　・コンビニのレジ
　・自動販売機
C：制御部分
　・不動産屋がModel扱う場合の処理
　・レジのバイトの応対、帳簿の付け方
　・自動販売機に入った貨幣の形状認識、押された商品と釣り銭の出力

続く
0201nobodyさん2007/12/18(火) 19:41:23ID:???
>>200は>>197宛でした。

続き

>>200の例で、分離による嬉しい事の例：
・法律が変わって資産計上の仕方が変わった場合に、モデルが分離していれば
　基本的な処理の段階に修正を加えて全体の整合性を保てる。
・コンビニがポイント制導入したとしても「コンビニのポイントモデル」を
　追加してコンビニのView/Controller変えることで、「他の事例への影響」を
　完全に切り離せる。
・貨幣偽装事件が相次いで貨幣の形が変わった場合、自動販売機の制御部分を
　変えるだけで済む。他の概念には影響しない。

こういう全体像の場合、モデルを「貨幣」として実装しても組み上げる事は可能。
でも変更対応性は損なわれるし、そもそも証券やら信用やら扱うと「貨幣」を
継承するのは無理があるし、等価的に扱えない。
特にコントローラー側が泣く。
上記の例でも、動産／不動産の価値と実貨幣価値を、「常に整合性が保たれる
ように変換」する作業が必要になってしまう。
で、貨幣ではなく「価値」という概念でモデルを抽象化しとく、と。

冗長になったなぁ。判りやすくはねえな。
人に教える時に悩むのが、実際に何かシステムを作らなくちゃいけないときに
上記の例でいう「価値をくくりだせばいいんだ」という着想をどうやって行う
べきかって話なんだよね。MVCってOOADが要る、っていうかOOADしっかり
考えられる奴はMVC必要なかったりするしな

PHP関係なくてすまん
■ このスレッドは過去ログ倉庫に格納されています