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

【PHP】フレームワー� ..

708:nobodyさん
08/06/20 00:41:52
svnって開発時には使うけど稼働時に使うか？

709:nobodyさん
08/06/20 01:08:36
>>708
稼動時でもバグが見つかれば更新しないといけないから
稼働環境でもマージ作業せなあかんやろ

710:nobodyさん
08/06/20 02:15:40
何この頭悪そうな話題のずれて行き方

711:nobodyさん
08/06/20 12:38:43
PRADOわかる人いる？

712:nobodyさん
08/06/23 10:47:52 isKyS0yI
以前、使ってみた（というか実験してみた）ことある。

以下、個人の感想だが、設計は面白いが、web用のフレームワークとして間違った方向に行ってる気がしたので、実践では使ってない。
フレームワークの勉強をするにはいいとは思うよ。

713:nobodyさん
08/06/23 16:04:32
>>712の言うweb用のフレームワークとして間違った方向とか正しい方向とかは意味不明だが、
PRADOは構築ルール縛りをするには良いとおもう。
開発効率は生だとものすごく悪いので、Radを待つか自前でつくるなりしないと使い物にならん。

714:nobodyさん
08/06/25 00:06:13
そういや、Kohanaって話題になったことある？
CIからforkして、PHP5 Strictと安定性・堅牢性を進めると聞いてるけど。
ググっても日本語サイト少ない・・・

715:nobodyさん
08/06/25 01:09:00
Kohana使ってるよ。
日本語情報どころか英語の情報もあまりない。

716:nobodyさん
08/06/25 11:12:53 2TehNRcN
>>713
詳しく書かないでｽﾏﾝ。

自分の感じた事を伝えようと思って、昔実験したサンプルを見ながら今書いてるんで現在のバージョンとは違うかもしれんけど

home.page
<com:TForm>
<com:TButton Text="Click me" OnClick="buttonClicked" />
</com:TForm>

確か、テンプレート風にこう書いて

Home.php
class Home extends TPage
{
public function buttonClicked($sender,$param)
{
$sender->Text="Hello World!";
}
}

で、アクションはこう書くだろ？
なんか、symfonyだと（というか、俺の主に使ってるフレームワークがsymfonyなのでそれとの比較になるが）request、responseっていうのがあって、webアプリなんだなぁ、と見るからに分かるんだが、
Pradoの場合、これ見るだけだとwebアプリだって分からないんじゃない？と思って「間違った方向」って言ってしまったんだ。
あくまで個人的な感想だと思って「間違った方向」については受け流してくれ。

# 改めて見るとやっぱり面白いフレームワークだとは思うな。
# ただ、実際に使うのは、request responseが無いとか、どうしても実装に何か無理がありそうな気がしてしまう、というのが感想な訳だ。
# バリバリに使ってる人の感想を聞いてみたい所かも？

717:nobodyさん
08/06/25 13:22:19
Webアプリ、しかもPHPでDelphi丸出しは厳しいものがあるよね

718:nobodyさん
08/06/25 17:48:03
>>716
なるほど。２．０の仕様だな。

719:nobodyさん
08/06/25 19:18:36
突然すんません。

いまいち『フレームワーク』ってのがわからないんです。

ググって調べたりしてるんだけど、『？』な感じなんです。

すご～くカンタンでいいんで説明してくれる方いませんでしょうか？
あと、こんなオレにおすすめの本あったら紹介して下さい。

プログラムは一応、データベースとか使って基本的なCMSとかつくれます。

今度、作ろうと思ってるサイトがあるんですが、『フレームワーク』ってのを
使った方がいいような感じがしてここへきました。

よろしくお願いします。

720:nobodyさん
08/06/25 19:20:21
ググれ

721:nobodyさん
08/06/25 19:39:02
>>719
framework
【名】
1. 骨組み｛ほねぐみ｝、フレームワーク、枠組み｛わくぐみ｝、下部構造｛かぶこうぞう｝、骨格｛こっかく｝

なんか作るときに土台が出来てると楽だろ？
でもその土台に制限されてしまうこともある。

722:nobodyさん
08/06/25 19:49:30
>>721
ありがとうございます。

ググってました。

『車』で例えるとしたら、
”キーを回すとエンジンがかかる”とかの仕組みができていて
一から作らなくてもいいってことなんでしょうか？

『いろんな仕組みのセットがあって、ボタンひとつで簡単に組み込める』
みないな感じですかね…？

723:nobodyさん
08/06/25 20:15:21
>>722
家を建てるに当たって、その骨組みが出来ているって感じ。
で、その骨組みに合わせて作っていくので、やりやすいよと。

>>722の車の例えだと、PEARとか見たいなライブラリだね。フレームワークではない。

724:nobodyさん
08/06/25 20:27:52
>>723
ありがとうございます。

ってことは、一戸建ての骨組みができている状態からスタートして
中身の部屋とかキッチンとかを入れて（？）いく。ような感じ？

フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？

今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。

725:nobodyさん
08/06/25 20:34:00 gyu7FUKS
直訳すると枠組み、だと思うんだが、骨組みの方が俺的にもしっくり来るね。

PHPを粘土と例えて、像を作ってみよう、という事になった時の事を考えてみると
いきなり粘土で像を作る事はできると思うが、やっぱり、予め骨組みあった方が作りやすいだろ？

でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。

>>716
なるほど。という事は現在は大分変わってるのか。
そのうち、また見てみる事にするよ。

726:nobodyさん
08/06/25 20:34:34
>>724
そういうところで悩む人は、多分人のソースなんかあんまり読まない様なタイプの
人だろうから、いっぺん使ってみるのは勉強になるんではないかと偏見だけど思う。

まあ業務に使うかどうかは置いておいて、PHPでお仕事しているんなら触って損は
無いかと思う。

727:nobodyさん
08/06/25 20:40:00
こんな抽象的な話を聞いて何が分かるんだろうｗ

728:nobodyさん
08/06/25 20:41:46
>>724
ページの遷移部分だとか、データの検証(バリデーション)部分だとかが簡単に出来たり、
フレームワーク自身が持っているライブラリが便利だったりとか。
データベースへのアクセスに関しては各フレームワーク共に工夫されてて凄く使いやすいです。

＞フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？

そうですね。「ちいたん」見たいなライトウェイトなフレームワークは一戸建てな感じで、
synfonyやEthnaやCakePHPなんかはマンションみたいな巨大なプロジェクトの開発に向いてるかと。

＞今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。

フレームワークは、できるなら使ってみたほうがいいと思います。
開発の規模や趣味趣向によって合う合わないってのはあると思いますが、
プログラムを組む上での手法として、勉強になる部分は大きいですし。

とりあえず、賛否両論歩けど、CodeIgniterなんかを触ってみてはいかがでしょう。
日本語のマニュアルが充実しているのと、割かしライトウェイトなので、扱いやすいのではないでしょうか。

729:nobodyさん
08/06/25 20:43:00
>>725
ありがとうございます。

>>でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
これ気になります…

>>726
ありがとうございます。

自分はまだ、人のソースをじっくり見て分かる所まで行ってないと思います。
なんか、好きなようにしたくて。ソースはかなり変かもしれません。

今『CakePHP』の関連サイトを見てました。
CakePHPってどうでしょうか？

明日、ジュンク堂とか行って関連本探してこようと思います。

730:nobodyさん
08/06/25 20:46:21 gyu7FUKS
下げ忘れた（汗）

>今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
>普通（？）に作るのがいいのか。という所なんです。
なるほど。フレームワークを学習するのには、コストがかかるからそういう風に悩むのは正しい姿勢だと思うよ。

で、まずは、どれだけの時間があるか？という所をはっきりさせるべきだと思うね。今書いたように「コストがかかる」から。

フレームワークを使わないでもできない事はないレベル & 時間が無い（半年以下）なら、たぶん今まで通り作った方がいいと思う。
（半年、というの人によるかな。でも、最低1ヶ月は学習する時間が欲しい。）

かなり大きなアプリになる予定（設計がまだ未定。先が見えない）& 時間がある、というのなら、なにかフレームワークを使う事を考えた方がいい。
後で付け足す事になったとしても、フレームワークで作ってあると、部品を付け足せるように設計されている（事が多い）からね。

・・・実際のお客様というのは、かなーり想定外の要求してくるから、それでも吸収できないくらいの事を言ってくる事もあるんだがな・・・

731:nobodyさん
08/06/25 20:47:14
もうすでに無駄なコストかかってるんでは

732:nobodyさん
08/06/25 20:53:37
また忘れた（汗）
ってか、みんなレス早いな。

>>でも、骨組みが、犬の骨組みだとしたら
実際には、webアプリの骨組みだから、あまり気にしないで大丈夫だと思う。
まぁ、時間あるならいくつかいじってみて、そのフレームワークの癖を見ておくのもいい勉強になるはず。
（あぁ。結構勉強してそうだからこんな事言っちまったが・・・たぶん、PEARを使いこなせる・・・使えるくらいの力量あるよね？もし無かったとしたら、まずは、ライブラリを使いこなせるようになってから、がいいと思う。）

# Cakeについては、使ってないので他の方に

733:nobodyさん
08/06/25 20:58:58
>>729
CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、一回作っていいかもしれない。
普通にプログラム作ってるだけだったりすると、なんでこんな動きするのか分からないような動きする。

今後、フレームワークを使わないプログラムを書くにしても、凄く勉強になるよ。

734:nobodyさん
08/06/25 21:03:51
>>728
ありがとうございます。

CodeIgniterってのは聞いたことがなかったのでちょっと
見てきます。

>>730
ありがとうございます。

メインはデザイン仕事でやっているので、時間はそれなりに
とれそうです。
自分としても勉強したい部分もあります。

ライブラリに関しては…”使いこなしてる”とまでは…

>>733
ありがとうございます。
>CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、

やっぱりそれが一番かもしれませんね。

>普通にプログラム作ってるだけだったりすると、
なんかコワイですね。

明日本屋行ってきます！

皆さん、いきなりなのに本当にいろいろありがとうございました！

735:nobodyさん
08/06/25 21:41:34
「フレームワークを使えば、アプリケーションを効率よく開発できます」
っていう言葉は、誤解を招く売り文句だと思う。

現実には、フレームワークの内部動作を調べて、
中で何をやってるかだいたい分かるレベルになって初めて
効率よく安全なアプリを自信を持って作れるようになる。
と思うけどな。

736:nobodyさん
08/06/25 22:45:59
>>735
正しい動作がしないとか、問題が出たときに見ればいいんじゃないのかね。
そのためにチュートリアルとか、マニュアルサイトとかあるわけだし。

PHPやるのに、PHPの関数のソースコードまで読まないでしょ？

737:nobodyさん
08/06/25 23:06:49
>>736
それはその通りなんだけどね
世の中には、想像を絶するような要求をしてくる人がいたりして、そういう要求を満たす為には・・・という事なんじゃないかな。
普通は、チュートリアルをこなせば（一応）使えるようなレベルにはなるはず。

とはいえ、そのレベルだと、そのフレームワーク臭さ（？）が抜けないアプリしか出来ないけど。

あぁ。現在のPHPのフレームワークはRAD機能がついているのばっかりだから、そういう奴で標準的なアプリを作って試してみるといいんだな。
で、そのフレームワークらしさが気に入ったら使えばいいと。

738:nobodyさん
08/06/25 23:22:18
>>735
Emacsとかviのような変態エディタみたいなもんか
操作を覚えるまでの過程を考えると必ずしも開発効率が向上するとは限らないみたいな

739:nobodyさん
08/06/25 23:42:13
>>737
ちょっと話題とずれるけど、
URLﾘﾝｸ(d.hatena.ne.jp)
最近、こんなの見つけた。

各フレームワークで同一アプリケーションを作成して、その使いやすさだとか、コーディング量が少ないのがどれか
とかを決めるような大会みたい。

740:nobodyさん
08/06/26 00:01:32
>>736
PHPのソースコード（C++?）は読まないけど、マニュアルは死ぬほど読む
ヴァージョンの差異もでかいしorz

んで、フレームワークでソースコードを読むのは、PHP程ドキュメントが整備されて
いないから、っていうのが一番大きい気がする。「正しい動作」とか「使い方」が、実は
サンプルを含めてソースを読まなきゃわからない、みたいな。

だから「問題が出たとき」だけソースを読めばいいとは思わない。
というか、それで現行のフレームワークが使える気がしない俺がいる

741:nobodyさん
08/06/26 00:06:30
>>736
たまにPHPのソースコード(Cだよ)も読むよ

>>738
そうそう
苦労量保存の法則

でも、覚えてしまえば、品質を保ったままで開発スピード
を上げられるから、やればやるほど楽して儲けられるはず。

742:nobodyさん
08/06/26 00:40:00
>>740,>>741
なるほど～。

フレームワークってちょろっと眺めてちょっと使ってみる、ぐらいしかしたこと無いわけだけど、
確かに理解しきるのは困難極めそう。

実際、Webで結構出てるPHPフレームワークって、日本の企業さんとかはつかってるところあるのかな？

743:nobodyさん
08/06/26 05:27:45
そんなの使いまくりにきまってるやん
企業が使わずしてどこで使うの

744:nobodyさん
08/06/26 07:21:25
大きめの企業でなら、Ethnaとか一時期多かったんじゃない？
さすがにCakePHPやちいたんを使うようなイメージは持ちにくい

まあベンチャーというか中小業者なら、担当者の趣味で半年
単位で採用フレームワークが変わってても驚かない
それをもって企業が使っていると言うのは、抵抗があるけど

745:nobodyさん
08/06/26 07:26:20
フレームワークを使ってない企業の方が少ないだろ

746:nobodyさん
08/06/26 14:03:08
日本で作られたフレームワークは使う気がしない。

やっぱり世界規模で進んでいるものの方が安心だよね。

747:nobodyさん
08/06/26 14:07:52
>>746
そーでもない。マルチバイトって何？おいしいの？っていう開発者？も
英米圏にはてんこ盛りだということを忘れてはいけない

だからといって国産が使いやすいわけでも無いけど、日本はそれなりに
良い線いってるんじゃ無いかとも思う。
世界規模にならないのは、コミュニティやドキュメントが英語ベースじゃ
ないからだけじゃね？

748:nobodyさん
08/06/26 14:16:13
今時UTF8対応じゃないフレームワークは、使う気がしない。

749:nobodyさん
08/06/26 14:18:26
そんなのあるか？

750:nobodyさん
08/06/26 14:25:59
まあメールライブラリはそのまま使えると思わない方が無難
Validationや文字数カウントが入る部分も微妙

UTF-8に限定すれば問題は少ないだろうけどね・・・。
コメントのコピーライト部分のラテン文字が必ず文字化けして
いるのは多分仕様です。・・・奴らはUTF-8使ってるのか？

751:nobodyさん
08/06/26 14:41:05
ひと昔前までの印象としては欧州産はまだマシで、米国産はI18NとかM17Nとかいう発想が無いのが多かった気がする

752:nobodyさん
08/06/26 19:00:58 0xtx7Zko
ethnaがとっつきやすくてよかった。
必要最小限の機能でやりたい事は全部やれた。

753:nobodyさん
08/06/26 22:54:59
これからSmartyの仕事にかかる。本当に馬鹿らしい。もうこれでPHPの仕事を最後にしたい。

754:nobodyさん
08/06/27 00:09:22
なるほど。Ethnaとかは使われてるんだね。

自社開発のクローズなフレームワーク使ってるっていう例も多いの？

755:nobodyさん
08/06/27 00:25:40
俺はもうPHPを捨てたぜ！
もう醜いのはうんざりだ
これからはRubyたんとちゅっちゅするんだ

756:nobodyさん
08/06/27 01:10:55
醜いのにうんざりしたと言いながら、よりにもよってRubyかいな

ありゃ便利だけど、あくまでbetter perlであって綺麗な世界ではないぜ
まだJavaScriptの方が一貫性と綺麗な世界、シンプルさ保っててる
醜いこと嫌ってweb用となら、pythonも併せて検討した方がいいかもね
Rubyが気になるようなら、もしかしたら君は醜いモノもある程度必要としている方の人かもしれん

もし醜くないことだけが評価されるなら、CのCGIはもっと普及していることだろうw

757:nobodyさん
08/06/27 02:15:02
PythonよりRubyの方が美しく書けるだろJK
PythonのOOは後付で一貫してない部分があるし
OOPと手続き型の混在感がある
JSは悪くはないが、まじめなだけが取り柄でおもしろみに欠ける

758:nobodyさん
08/06/27 03:07:52
醜く書き散らせてこそLL
汚く書きたくなきゃ制約の多い言語で十分だ
PHPに不満ある奴は、もっと泥に塗れられる言語を求めてるんだぜ
QIQとか、自由度と混沌を一緒に提案してくれてるんだ
本家にマージされてほしいぜ

あとJSはまじめどころか変態だぜw

759:nobodyさん
08/06/27 03:35:51
うむ。JSはPythonもC++0xも取り込もうとしている変態言語（褒め言葉）

760:nobodyさん
08/06/27 09:10:17
あいかわらずレベル低いやつらしかいないな。

761:nobodyさん
08/06/27 09:32:26
RubyはPerlをオブジェクト指向風に作り直したような感じだもんな。

762:nobodyさん
08/06/27 09:37:50
760みたいなこと書く奴が最もカス

763:nobodyさん
08/06/28 19:37:31
非phpのfwを見て回ったが
CGIを高速に運用する環境で決定打を持つものがないな
どれも不安定っぽい
そう考えるとmod_phpの安定感は偉大だった

764:nobodyさん
08/06/29 02:47:07
別にここはPHPまんせースレというわけでもないんだけどね
>>763の言いたいことはわかるけど、「PHPのフレームワーク」っていう
テーマからは見事にずれてるなｗ

765:nobodyさん
08/06/29 02:48:58
>>764に補足
素のPHPに不満足な人間がすなわちフレームワークに関心を持つんだと俺は思ってる

766:nobodyさん
08/06/29 02:52:54
>>763 に対してもうちょっと書いてみる
多分、競合相手は「CGI」ではなく、例えばTomcatベースのJavaプラットフォームだったり
asp含む.NetのWindowsサーバだったり。
あなたの持ち出した基準では、そういうプラットフォームのお話であって。

そういうレベルでは（良くも悪くも）このスレの関心の範囲外だと言ってみる

767:nobodyさん
08/06/29 19:24:11
そして人は皆、perl+mod_perlに戻るのだ

768:nobodyさん
08/06/29 19:31:13 k12JEG0L
PHP版Railsという意味ではSymfonyとCakePHPとどっちが
本命なんでしょうかね？

769:nobodyさん
08/06/29 19:42:33
答えはどっちも否

770:nobodyさん
08/06/29 19:52:21
PHPにRailsは馴染まなかったってこと？

771:nobodyさん
08/06/29 19:57:50
蛙の子は蛙
鵞鳥は白鳥にはなられへんねん！

772:nobodyさん
08/06/29 20:24:04
関西弁は嫌い

773:nobodyさん
08/06/29 20:25:38
鵞鳥が読めずにググった俺涙目

774:nobodyさん
08/06/29 20:32:14
PHP版RailsってまんまAkelosじゃん

775:nobodyさん
08/06/29 20:33:32
あひるって最近は、公園に行ってもいそうでいないからなあ。

776:nobodyさん
08/06/29 21:16:06
>>774
Akelosがどんなのか見てきたけど、こりゃ完全コピーだなｗ

777:nobodyさん
08/06/29 22:15:09
Port of Ruby on Rails development framework and designed to work for PHP4 and PHP5.
と書いてあるだろ。
むしろPHP4に対応しちゃっている部分を問題視しろ。

778:nobodyさん
08/07/01 12:45:16
お前らそろそろPHP4対応じゃないと、とか言わないよね？

779:nobodyさん
08/07/02 06:01:43
PHPのsingletonって意味ねーよな
リクエストからレスポンスまでしかオブジェクトが存在しないのに
singletonだろうが何だろうがたいして意味ねーよ

780:nobodyさん
08/07/02 08:47:37
>>779
そーなんだ！

781:nobodyさん
08/07/02 23:39:22
>>780
分かってないみたいだが、そうだよ。define()でいい。

782:nobodyさん
08/07/03 00:26:16
スレッドセーフ的には使えんて事？

783:nobodyさん
08/07/03 01:56:11
スレッドは関係ないだろ

784:nobodyさん
08/07/03 01:59:48
PHP自体スレッドセーフじゃない

785:nobodyさん
08/07/03 07:18:34
>>781
全然良くねーよ。定数にできるのはスカラーのみ。オブジェクトは不可。
PHPでシングルトンパターンは専らグローバル変数を使わずに
共通のインスタンスを使い回すのに使われる。
Javaでの使われ方とは違うけど、意味がないわけではない。

あとPHPでスレッドプログラミングはできないけど、ZTSを有効にしてビルドされた
PHPはApache2のworker MPMみたいなマルチスレッドサーバ上でスレッドセーフに動作する。
リンクされているライブラリやサードパーティ製拡張モジュールに関しては保証されないけど。

786:nobodyさん
08/07/03 07:23:17
確かになんでdefine?と思った

787:nobodyさん
08/07/03 07:24:12
>>785
> PHPでシングルトンパターンは専らグローバル変数を使わずに
> 共通のインスタンスを使い回すのに使われる。

まあPHP4でのシングルトン実装は、みんな$GLOBALSへの放り込みだったけどなｗ
シングルトンのつもりで設計したのに & を付け忘れてオブジェクトコピーしまくってたり。
過去の話になってくれて、本当にめでたい。

788:nobodyさん
08/07/03 08:06:55
>>787
そういえばPEARで $GLOBALS['_クラス名']['instances'] = array(); とかあったｗ（ていうか今でもある）
今は↓みたいなのが多いね。ものによっては__construct()をprivate/protectedにしてたり。
public static function getInstance() {
static $obj = null;
if ($obj === null) { /* 初期化 */ }
return $obj;
}

789:nobodyさん
08/07/03 08:31:08
static $obj = null;
if ($obj === null) { /* 初期化 */ }
return $obj;
}
↑なんだそりゃｗ

790:nobodyさん
08/07/03 11:54:17
>>788ってごく普通の書き方だと思うが。PHP4でもほぼ一緒。

791:nobodyさん
08/07/03 12:46:50
>>790
ダウト？ｗｗｗ

static がないから $GLOBALSに入れる、それがPHP4クオリティって話だろ？

792:nobodyさん
08/07/03 13:01:00
あほか、php4だってstaticくらいあるだ

793:nobodyさん
08/07/03 13:09:24
4でも関数のstatic変数はあり。5だとクラスのstatic変数に突っ込んだりはするね。

794:nobodyさん
08/07/03 13:14:16
知らんかった。勉強になった。

んじゃ、むしろ>>788の書き方は（関数宣言を除けば） PHP4、5共用の書き方ってこと？
PHP5なら、クラス変数にした方がわかりやすいじゃん？って思ってしまうが、この書き方の
メリットってある？

795:nobodyさん
08/07/03 14:11:05
PHP5の場合普通クラス変数に入れる
PHP4が苦渋の策だっただけ

796:nobodyさん
08/07/03 14:29:05
一応、メソッド内のstaticだと、自クラスの他メソッドからも直接さわれない、
超private変数にはなる、のかなｗ・・・メリット？

797:nobodyさん
08/07/03 14:56:36
もうphp4は許してやれよ

798:nobodyさん
08/07/03 14:57:42
static変数の場合スコープがそのメソッドのみになるから
singletonという意味ではそうしないと意味がないような
クラスプロパティだと書き換えられる

799:nobodyさん
08/07/03 14:59:52
>>794
5だとstaticを付けなきゃいけないとか、4だと関数名の前に & を付けて、
呼び出し時も & が必要とか、微妙な違いがある。しかも内部的に等価じゃないし。
5だとクラス変数にしたほうがいいね。

800:nobodyさん
08/07/03 15:05:49
>>798
そのクラスの中からしか書き換えられないから何の問題もない
っていうか、普通singletonってそういうもの

801:nobodyさん
08/07/03 21:05:31
で、そのSingletonとやらをどう有効に使えるのかね？ｗ
PHPだぞ、これ。Javaじゃない。
ふっつーにグローバル変数で何の問題も起きない。起こしたら本格的に痴呆だ。

802:nobodyさん
08/07/03 21:17:58
まあそうね
PHPSDLとかイロモノ出て来てるの見ると、色々考えちまうがw

803:nobodyさん
08/07/03 21:26:56
>>801
ライブラリやフレームワークでの記述の統一が無視できないと思う。

あんたの書いたライブラリで$GLOBALS['hogehoge']['pagepage']['instance']とか、
誰が使うかｗ
Hogehoge::getInstance() の方が憶えやすいし、見通しがいいに決まってるじゃないか。
ただの$_SESSIONアクセサ+アルファで、別にそれほど目立った特色のないSession
クラスや同様のCookieクラスが一部で存在する意味もそれだろ。

こういった要素を軽視する人間と一緒に作業できそうな気はあまりしない

804:nobodyさん
08/07/03 21:46:38
>>803
>>801はフレームワーク不要とか言ってる人と同一人物じゃないかな？
趣味プログラマだと思うから、状況が違うんでしょう。
おそらくJavaで仕事したこともないからこその発言に見えるね。
なので議論は（フレームワーク不要論と同様に）平行線になるね。

805:nobodyさん
08/07/03 21:52:42
まともなJava屋から「グローバル変数で何の問題も起きない」なんて発言が出るわけないもんな。

806:nobodyさん
08/07/03 22:03:42
>>801
>>803とは違うことだけど、安全性の問題かな

このファイルをincludeすると、$なんとかっていうグローバル変数が
定義されますっていうのはちょっと・・・。
グローバル変数への格納・利用が、同一人物が同時期に書いたソース
のみで起こるんならまだいいんだけどね。

Xoopsも結構良くできてたけど、プラグインを作るときにこの辺が物凄く
引っかかった。クラスベースでも、覚えたりソース読んだりするのは同じ
なんだけど、少なくとも汚染されていない保証っていうのかな、そういう
ものが大事だと俺は感じた。

807:nobodyさん
08/07/03 22:08:54
あまりむやみにグローバル変数を作るのはよくないけれど、限定された使い方ならいいと思う。
どうせシングルトンの対象になるのって、DBコネクションとか限られてるんだから。

808:nobodyさん
08/07/03 22:37:22
Singletonだと継承した時、Singleton部分を再実装しないといけない
どうせSingletonの意味は薄いんだから、クラスは普通に書いて
Factoryで管理した方がいいかもね

809:nobodyさん
08/07/03 22:43:15
>>808
意味がわからない。kwsk plz

810:nobodyさん
08/07/03 22:55:35
>>808
agaviはContextクラスがAgaviModelの派生クラスのファクトリーになってて、
IAgaviSingleModelインターフェイスを実装している場合はSingletonになるようにしてる。

811:nobodyさん
08/07/03 22:57:16
>>808
想定しているのはこういうのじゃなくて？
＃これなら継承しても特に問題なさそうなんだけど・・・

class A
{
protected static $obj;
public static function singleton()
{
if(!isset(self::$obj)){
self::$obj = new stdClass();
}
return self::$obj;
}
}
class B extends A{}

var_dump(B::singleton());

812:nobodyさん
08/07/03 23:14:16
ああ。なんとなくここまで流れで見えてきたポイントがある。

>>811 での Bクラスの singleton() では、例えば Aクラスを継承した
Cクラス・Dクラス・・・でも、「同じ」インスタンスが返ってくるなｗ

class B extends A{}
+ class C extends A{}

var_dump(B::singleton());
+ var_dump(C:::singleton());

んで、ぐーーーーっと戻るが、>>788 での記述でAクラスが書かれて
いたとすると、結果が変わる。
BクラスとCクラスでは、戻ってくるインスタンスが違う。
結局、こういうことなのかな？

詳しい人、解説頼む

813:nobodyさん
08/07/03 23:30:04
時代はSingletonなのか？　

>>809
オブジェクトを管理しやすいんじゃないか？

814:nobodyさん
08/07/05 12:22:18
シングルトンは初期化のタイミング気にしなくて良いのも大きいやん

815:nobodyさん
08/07/05 15:04:11
>>813
シングルトンは昔からあるデザインパターンの一つだよ。

816:nobodyさん
08/07/05 21:17:29
DIコンテナがあればシングルトンパターンなんて使わねーから。
そんなことより、JavaもPerlもRubyもMVCフレームワークって
ほぼ１択なのにPHPは乱立してんの？
決定版が出てこない時点で終わってるな。

817:nobodyさん
08/07/05 21:51:53
>>816
ある意味、PHPの敷居の低さかな。もともとWEBフレームワークみたいなものだから、
基本機能（CookieだとかHTTP周りとか、出力とかサーバへのデプロイとかもろもろ）を
スキップしていきなり構築出来るし、書いてみれば結構できちゃった、みたいな感じじゃね？

818:nobodyさん
08/07/06 03:59:03
>>816
DIコンテナ何使ってる？

819:nobodyさん
08/07/07 15:48:06
・DIコンテナって何？その用途・利点は？
・DIコンテナとsingletonの関連は？
・DIコンテナを使ったPHPフレームワークってある？その得意とするケースは？

初心者が、ここでこれくらい聞いてもいい？

820:nobodyさん
08/07/07 16:02:09
だーめっ☆

821:nobodyさん
08/07/07 17:53:08
>>816
> ほぼ１択なのにPHPは乱立してんの？

PHPがオープンだからじゃないかな？

Javaも最近オープンになってきたから
フレームワーク増えてきているよね。

822:nobodyさん
08/07/07 18:39:37
>>819
ググれカス

823:nobodyさん
08/07/07 21:40:56
話についていけない！
Javaを勉強しないといけませんか？＾＾

824:nobodyさん
08/07/07 23:15:27
>>823
やさしいJAVA

825:nobodyさん
08/07/07 23:23:56
>>824
いやいやｗそれデザパタとかないしｗ

まずは、DIコンテナが有効なのかどうか、その辺の話が出来ないのか？
ググっても古い情報しかないのは、もう廃れたのか、常識的に使われている
からなのか、どうなんだ

基本的に、手法がXML等の外部設定ファイルだろ？PHPに馴染むとは思えん。
俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。

826:nobodyさん
08/07/08 15:28:51
PHPになじむかどうか以前に、

XMLなどの外部設定ファイルで設定するのって
大変だよ。

827:nobodyさん
08/07/08 17:39:01
>>816
Javaのフレームワークがほぼ一択だと思ってるなら、無知すぎ。
Rubyは開発者が少なすぎの過疎言語だったから。
Perlも廃れた言語だから。
Pythonも多い。

PHPも、乱立っても紹介が多いだけで、実際使われてるフレームワークは
限られてる

828:nobodyさん
08/07/08 19:27:16
>>826
特にXMLは大変だな。あの可読性の低さは尋常じゃない
専用エディタ使え？ああそうですね

829:nobodyさん
08/07/08 21:14:00
PHPって、まともなクラスライブラリがないから、それぞれ独自でフレームワークを実装し出すんだよ。

830:nobodyさん
08/07/08 21:14:32
DIコンテナ=XMLの設定ファイル使う、じゃないでしょ。
yamlの奴とかもあるよ

831:nobodyさん
08/07/08 21:16:09
>>829
zfってそこまとめようとしてるように感じたんだがな
その視点で言うと普及しなさそうで失敗ぽいけど

832:nobodyさん
08/07/08 21:21:43
ZendFrameworkに関しては、使える部分はあるんだけどね。
ともすればRouterやControllerあたりに目を奪われて、ライブラリ
部分の評価がおざなりになってしまったりする。

例えばCIに持ち込むとかすればいいし、双方ともそれが簡単に
出来るように作ってはあるんだけど、その時に何というか気持ち悪い

何故かと考えたが、クラス・変数・関数・ファイル名等の命名規則が、
分散しすぎているせいもあるなあというのが最近の実感。
異質な気持ち悪さがあるのは、きっと命名規則等も分散して

833:nobodyさん
08/07/08 21:22:18
>>832
最後の行はゴミｗ消したい

834:nobodyさん
08/07/08 21:29:32
5.3の名前空間使えるようになったら少しはマシになるかな

835:nobodyさん
08/07/08 21:38:19
>>834
多分、それが普及するまでまた３年くらいかかるんじゃね？
名前空間全開で使ってると使用者が増えないという、何という二の舞ｗ

んで、5.2のサポート終了まで引っ張るとか。

836:nobodyさん
08/07/08 21:46:15
3と4と5で文法や仕様が大きく変わって、全部に対応するライブラリやフレームワークを構築するのが困難。

837:nobodyさん
08/07/08 21:48:24
3とかあり得ないし、4に対応するものを新しく書く必要もない、と思うけどね
4はそれこそ、今までの遺産でがんばれば良いじゃない

838:nobodyさん
08/07/08 22:09:17 PfgpRR5R
>>832
CodeIgniterにZendFrameworkのライブラリを引っ張ってくる＝いいとこ取りで、楽ができますか？
ＭＶＣならルーティングとか、コアになる部分は、どのフレームワーク使ってもに似たような処理になっているでしょうか？＾＾

839:nobodyさん
08/07/08 22:12:20
幕の内弁当のようにいろいろな具が詰まったフレームワークを、いったんバラバラの具に分解して
自由に組み合わせて食べられるとウマー？

時間があったら、フレームワークのコードを読んでみるか…。

840:nobodyさん
08/07/08 22:12:52
Perl5.0が1994年、Perl5.6でさえ2000年にリリースされてる。これが圧倒的なボリュームのCPANがあるPerlと、Pearが尻すぼみに終わり、Zendが始まりもしなかったPHPの違い。

841:nobodyさん
08/07/08 22:34:22
>>838
別にそんなに難しくないし、メリットはあるとおもう。例えばZend_Pdfとか持って来たり。

lib/Zend 以下をごっそりvendor/とかにコピーしてinclude_pathを通すのが一番楽だけど、
依存に注意しながら必要なものだけを持ってくるのでも、それほど難しくない。
例外が２系統投げられるので、その辺が気になるなら対処して。

CIの場合はそれほどコアに密着したライブラリって無いので、例えばSessionとかDbとか
も、好きなものを使おうと思えば使える。Registryとか、なんでCIにないのかなって思ったし。

＃そうすると、CIの機能をいくらか無視することにもなるかもだけど、それで幸せになれるならおｋ

で、問題はそれをやると、ソースがカオスになると。メソッドの命名規則なんか、CIはZFの
対局にいると言っても過言ではないとおもうし。
＃クラスにprefixつけない、CamelCase嫌い、クラスファイル名でもCamelCase式と
＃ lowercase-underscore式の、独自ルールによる混在、もろもろ・・・

そこに上乗せする俺のソースはどっちで書けばすっきりするんだああ、となるよ。

842:nobodyさん
08/07/09 00:45:59
DIの設定がXML地獄てSpring2.5とか使ったことないのか？
ここのアホ住人は。
今は、XMLにはほとんど記述せずにアノテーションでお手軽に記述できるんだよ。

843:nobodyさん
08/07/09 00:54:02
>>842
そうやって、どんどんJava風を進めて行くわけですね。＞アノテーション
出来れば、そのメリット・デメリットを絡めたレスが欲しいなぁ。

なんでJavaで一般的なものがPHPで一般的でないか、それを、
「遅れている」等としか捉えられないのなら、少しおかしいと思っていいよｗ

844:nobodyさん
08/07/09 01:06:31
>>843
842は設定ファイル云々に突っ込んでるだけでしょ

845:nobodyさん
08/07/09 01:12:38
>>844
それを言うなら、XML言い出した大本の>>825では自嘲している
> 俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。

むしろ、DI派の具体的な書き込みが無いから発展しないんだろうが。

846:nobodyさん
08/07/09 01:20:27
本当に、PHPでDIとかDaoとか、「これはいい！」と思って使ってる人っているの？

847:nobodyさん
08/07/09 02:45:49
そもそもPHPやRubyのような動的言語には、DIみたいな回りくどい書き方は不要。
静的言語の融通の効かなさを誤魔化すために生み出されたものだし。

848:nobodyさん
08/07/09 10:02:19
Tomcatの再起動とか面倒だったりするもんな。

849:nobodyさん
08/07/09 12:00:32 QmvziGkH
自分のプログラム技術が上手なことに気付いた
アルゴリズム能力は知識で補えない、もって生まれた能力

850:nobodyさん
08/07/09 20:19:04 My9jWWGd
>>849
オリジナルの式を組めるなら凄いな

851:nobodyさん
08/07/09 21:05:11
ゆがんだ車輪を再発明しまくってる悪寒
アルゴリズムってか、ロジックレベルで言ってるんでは無かろうかとも思う

ってか、何これ。コピペ？

852:nobodyさん
08/07/09 23:28:12
>>849

世界ＩＴコンテスト、慶大生が３位入賞
　世界の学生がＩＴ（情報技術）の開発力を競う「イマジンカップ」（米マイクロソフト主催）の第6回世界大会が
8日までパリで開かれ、「アルゴリズム部門」で、慶応大の高橋直大さん（20）が3位に入賞した。
日本人の3位以内の入賞は初めて。アルゴリズムはコンピューターソフトの基礎となる計算手法で、
高橋さんのアルゴリズムの独創性などが評価された。

　アルゴリズム部門のコンテストは数学パズルのような9問の課題を24時間の制限時間内に
コンピューターを駆使して解法を考案する。高橋さんは「好きな算数や数学の考え方をいかした。
2、3分しか寝なかった」と話した。

パリの大会には100カ国以上から124チームが参加した。予選を含めた総参加人数は20万人を超える。（パリ支局）(11:01)

URLﾘﾝｸ(www.nikkei.co.jp)

853:nobodyさん
08/07/10 03:46:42
何このきもい流れ

854:nobodyさん
08/07/10 03:57:12
>>853
「DIコンテナ」のこと？それとも
「自分のプログラム技術が上手なことに気付いた」の方？

はっきりしろやｗ卑怯者がｗｗｗ

855:nobodyさん
08/07/10 04:07:03
「自分のプログラム技術が上手なことに気付いた」の方に決まってんじゃん
なんで卑怯者？？？

856:nobodyさん
08/07/10 04:08:03
ネタが無いんだよｗ

857:nobodyさん
08/07/10 10:37:59 R+kirKl3
で、ここでPHPフレームワークの話をしよう！
ってなると、話がピタッと止まるから面白いｗ

858:nobodyさん
08/07/10 12:07:19
あぁ、Java厨が嵐に来ているだけだからね。

859:nobodyさん
08/07/10 12:11:37
PHPフレームワークの話題は規模が大きくなったので、
各フレームワーク専用スレに移行しております。

860:nobodyさん
08/07/11 18:54:57
どんなふうにしてクラスを作ればいいのか？
クラス作成の適切な方法を調べています。

分析（モデリング）→設計の流れにおいて、
・構造化プログラミングだとDFD
・オブジェクト指向プログラミングだとUML

ユースケースドリブン＝ユースケース図→ロバストネス分析→クラス図を作成する？
アーキテクチャセントリック＝アーキテクチャ（基盤）としてのフレームワークを選定→フレームワークの流儀に従って機能（クラス等）をどんどん追加していく？
…ということでしょうか？

本やサイトを調べると、Javaの事例がたくさん出てきました。

861:nobodyさん
08/07/11 19:04:44
なら死ぬ気でJavaやれよ。俺はJavaを書くと慢性的に薄い血尿が出てた頃を思い出すからコリゴリだけどな。

862:nobodyさん
08/07/11 19:28:36
javaのコードをphpに置き換えりゃいいじゃねえか・・・

863:nobodyさん
08/07/11 19:37:29
そうして行数や文字密度ばかりでかい、可読性最低のソースが量産されるのですね

864:nobodyさん
08/07/11 19:49:05
Javaは勉強しました。
＝簡単なアプレットを作れます。

オブジェクト指向分析→設計って、言語の仕様に依存しないで使えますよね？
クラス作成は、適当でも動くものは作れるけど、先人が体得してきた上手いやり方を知りたいです。

デザインパターンは、これから勉強してみます。

865:nobodyさん
08/07/11 19:53:01
構造化プログラミングの設計は、わかりやすいと思います。
文書を作成する場合も、フローチャート図やDFD図を書けば、人に説明できる。
データベース設計もER図で書ける。

オブジェクト指向設計はこれから勉強しますが、体当たりで試行錯誤するより、典型的な勉強方法を知りたいです。

866:nobodyさん
08/07/11 23:06:34
近道して楽しようと思わないことかな

867:nobodyさん
08/07/11 23:37:05 3Q95O5fB
オブジェクト指向設計は、まだ方法論が確立されていないのですか？
群雄割拠＞＜

868:nobodyさん
08/07/12 02:04:01
>>866
それは、自分で私は低脳プログラマですって言ってるようなものだぞ。

869:nobodyさん
08/07/12 09:41:14 jBMGyyJi
オブジェクトはな・・・Cの構造体を勉強してみると感じが分かるやもしれぬ。

が、そもそもCの勉強コスト自体が高いかね。
でも、勉強しておくと、後々効いてくる。

870:nobodyさん
08/07/12 09:52:14
オブジェクト指向を学習したいならPHPなんてしない方がいい
関連書籍のレベルも低いし

871:nobodyさん
08/07/12 11:05:18
オブジェクト指向なんて難しい事を考えずに、
関数の寄せ集めって考えれば、すごく楽なのに。

872:nobodyさん
08/07/12 11:12:05
関数の寄せ集めとは違うぞ。
より便利に関数・・・というか、プログラミングを、と考えていくとオブジェクト指向につながっては行くけどな。

873:nobodyさん
08/07/12 11:19:45
>>868
なんで？

874:nobodyさん
08/07/12 11:38:13
関数と変数の寄せ集めじゃない？

875:nobodyさん
08/07/12 11:39:05
>>873
楽したがる人の方が優秀っていうのは定説

876:nobodyさん
08/07/12 11:46:50
>>875
根拠を詳しく

877:nobodyさん
08/07/12 12:02:11
>>876
どうせ「ソースは自分」だろうからほっとけ。

オブジェクト指向はOOPだけ見てると、どうしても小手先的な話が多くなりがちだから
OODも勉強したほうが良いとは思う。ただ、これに関して自分が呼んだ範囲でよかったと
思える本は、Booch先生の「Booch法：オブジェクト指向分析と設計」ぐらい。
しかもこれはもう絶版で再版はされないだろうから、中々に難しい。

878:nobodyさん
08/07/12 12:26:50
>>876
少しはぐぐれ

879:nobodyさん
08/07/12 12:33:16
>>877
じゃあ、自分の言葉で、「OODも勉強したほうが良い」と思われることを一つでもよろしく

例えば設計手法としてドメインモデルに基づいた「名前」の抽出とか、そう言った具体的な
ものは、"OOではなく"普通に有効なものだと思う。
何がOOのエッセンスか、その辺がよくわからない。

例えば新しい手法が出てきたとして、それがある場面で有効であっても、付帯する、
例えばJavaを前提としたUMLの書式であったりJavaの文脈であったり、そういった
ものはあまり普遍的ではないように感じる。
例： Beanとかなんとか書いてある本を、PHPで実際に参考にするのは非常に難しい。

880:nobodyさん
08/07/12 12:41:03
>>879
> "OOではなく"普通に有効なものだと思う。

色々あるだろうけど、それはその通りだと思うよ。
ただ、例えばモジュール化とかの方法論は、機能単位に分解することを前提にしてたり、
して、モデリングの方法論としては使用されていなかったというだけの話で。

OO言語が流行るまで、個々のエンジニアレベルでOO的な思考がされていなかったのかと
言えば、そんなことはないでしょ。ただ、共通的なモデルとしては語られなかっただけで。
でも、それが出来るようになったのは、それなりに大きい。

後半は何言ってるかわからんから、コメントは控える。

881:nobodyさん
08/07/12 15:09:10 2oBRlMWN
モデル駆動型アーキテクチャ - Wikipedia
Wikipedia項目ﾘﾝｸ
>フォレスターリサーチは2006年に MDA は死に体（D.O.A.）であるとした

OOA/OOD業界には、SIerが儲けるためのバスワードが混ざっているんでしょうか？

882:nobodyさん
08/07/12 15:11:44 2oBRlMWN
×　バスワード
○　バズワード

バズワード - 【buzzword】(特にビジネスの世界における)流行語。
バズワード(buzzword)とは一見専門用語のように見えるがそうではない、明確な合意や定義のない用語のことである。

883:nobodyさん
08/07/12 16:00:51
OOA/OOD業界って何？って話があるけど、そもそもOOをまともに語れるSIerなんてそんなに居ないと思う。
昔、IBMでさえ、「VBはOO言語だから、VBで作ったシステムはオブジェクト指向技術で作られているんだ」なんて
意味の無いことを主張してたし。

ただ、近いところだと、SOAなんかはバズだなぁって思う。

884:nobodyさん
08/07/12 17:44:37
いや意味なくはないだろw
具体的に何が気に障ったのか判らんが

885:nobodyさん
08/07/12 17:54:21 bJKqKB86
ethnaみたいなシンプルなFWで十分
MVCとヴァアリデートだけできればいいし

886:nobodyさん
08/07/12 19:26:06
> MVCとヴァアリデートだけできればいいし

逆に、それ以外で要らないものって何だ？

887:nobodyさん
08/07/12 19:35:29
MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
のことかも

でも、ぶっちゃけヴァリデートはテンプレートライブラリと同程度にフレームワーク
からの独立性や選択肢が欲しいな。
一時期HTML_QuickFormが流行ったのは、独立したヴァリデーションライブラリの
側面もあったからだと俺は思ってる

888:nobodyさん
08/07/12 20:05:09
>>884
別に自分の話じゃないよ。
興味があるなら、九大病院　IBM オブジェクト指向　でググって見てちょ。

889:nobodyさん
08/07/12 21:52:20
>>887
> MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
> やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
> のことかも

俺もそれのことだろうとは思ったのよ。
でも、本当にそんな便利なものをいらないと
言っているのかと疑問になってね。

890:nobodyさん
08/07/12 22:01:37
今時PHPてどこの乞食だよｗｗｗ

891:nobodyさん
08/07/12 22:05:04 yMqg6CvP
九大病院　IBM オブジェクト指向に一致する日本語のページ約 320 件

URLﾘﾝｸ(bizboard.nikkeibp.co.jp)
日経コンピュータ 1998/08/17号
大規模オブジェクト指向開発が破綻　早期稼働を狙いVisual　Basicへ変更
九州大学医学部附属病院は98年5月，医師や看護婦のあらゆる業務を支援する「新医療情報システム」を予定より1年以上遅れて全面稼働させた。
当初は97年1月から順次稼働させる予定だったが，システム・インテグレータとして開発を担当した日本アイ・ビー・エムのプロジェクト管理の甘さなどが原因で，開発が大幅に遅れてしまった。

最初smalltalkを使って、頓挫してVisualBasicに変更＝オブジェクト指向プログラミングを捨てて、構造化プログラミングでデスマーチに対処したんですね？

892:nobodyさん
08/07/12 22:08:56
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
スルガ銀行は2008年3月6日、日本IBMに111億700万円の損害賠償を求める訴訟を東京地方裁判所に提起したと発表した。
「新経営システム」の開発を委託したが、「IBMの債務不履行により開発を中止せざるを得なくなった」（広報）ことにより被った損害や逸失利益などの賠償を求めたもの。
　
スルガ銀が導入を目指していたのは、IBMのオープン勘定系パッケージ「NEFSS/Corebank」。
2004年9月にプロジェクトを開始していた。
当初は2008年1月の稼働を目指していたが、開発遅れにより、延期していた。

俺なら111億円も弁償できないよ＞＜
PHPで月100万円儲けられれば十分です(^^)v

893:nobodyさん
08/07/12 22:10:53
>>888
結構古い話なのね
肝心の97年のnikkeiBPの記事がリンク切れなのでぐぐっても良く判らないな。
URLﾘﾝｸ(bizboard.nikkeibp.co.jp)
有料記事化してたこいつかな（SMLのML漁った方が早いのかな）

ともあれあの当時のVBでOO云々っていう事なら
俺も無理ある話だと同感ましたわ。

2006/7にも受注してんのな
URLﾘﾝｸ(www-06.ibm.com)
こっちの話題はいまんところ見当たんない感じ

次ページ