トップページ⇒php
994コメント273KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2008/12/23(火) 00:36:15ID:???
PHPのフレームワークに関する話題用のスレッド

●国外産●
symfony
　ttp://www.symfony-project.com/
code igniter
　ttp://codeigniter.com/
Zend Framework
　ttp://framework.zend.com/manual/ja/index.html
CakePHP
　ttp://www.cakephp.org/
Yii Framework　←New!! (Dec 03, 2008)
　ttp://www.yiiframework.com/

●国産
ちいたん
　ttp://php.cheetan.net/
Ethna
　ttp://ethna.jp/
guesswork
　ttp://classic.guesswork.jp/
maple
　ttp://kunit.jp/maple/

●前スレ
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
http://pc11.2ch.net/test/read.cgi/php/1219581817/
0488nobodyさん2009/02/03(火) 12:03:09ID:???
>>487
どこのスレ来て言ってるんだよ。PHPもelse ifはできないだろうが。
0489nobodyさん2009/02/03(火) 12:05:07ID:???
まさかPHP5は可能といかいうオチ？
0490nobodyさん2009/02/03(火) 12:09:31ID:???
>>488-489
PHPでもできるよ。
0491nobodyさん2009/02/03(火) 12:21:15ID:???
>>490
ほんとだ。PHPでもできた。ｽﾏｿ。
0492nobodyさん2009/02/03(火) 12:36:42ID:???
マジレスすると、Rubyの実行速度がPHPを上回ったら、Rubyはシェアを取れると思う。
PHPで出来ることは、Rubyでも出来るからね。

Rubyの改善には期待してます。
ただし、続きはRubyスレでお願いします＞＜
0493nobodyさん2009/02/03(火) 12:46:22ID:U0x1Z73i
それは夢のまた夢
0494nobodyさん2009/02/03(火) 12:48:03ID:???
＞ ただし、続きはRubyスレでお願いします＞＜
って言いながら香ばしい餌垂らしていくんじゃねえｗ
0495nobodyさん2009/02/03(火) 12:51:48ID:???
ＰＨＰは実行時に余計な処理せずに最小処理だけして爆速にできるオプション選べるように
すればもっとシェア広がると思う。
普通使わない変数への初期値セットとか設定ファイルいちいち呼んだり余計なステップが多すぎ

<?php set_quickmode(); みたいに書いてさ・・
0496nobodyさん2009/02/03(火) 13:07:20ID:???
速くしたいだけなら、VM作ってコンパイル・最適化済みのバイトコードを、
メモリにのっけておいて実行するようにすればいいんじゃない？
大体今風に作られたスクリプトではrequireあたりも大きなボトルネックっぽいし

ただ動作速度を速くしたってこれ以上シェアが広がるとも思えんけどな
すでに棲み分けって点では十分できてるだろ
0497nobodyさん2009/02/03(火) 13:43:31ID:???
Javaにコンパイルできるぞ
0498nobodyさん2009/02/03(火) 14:31:04ID:???
JRubyでJavaとして使う
これがRubyの生きる道？
0499nobodyさん2009/02/03(火) 14:34:25ID:???
まあ、PHP以外も普通に使えるようにしとこうぜ！って話だな
0500nobodyさん2009/02/03(火) 15:28:08ID:???
パフォーマンスの面ではPHPも人のこと言えないからなぁ
高負荷サイトだと今でも、調査の結果mod_perlにしましたみたいなことあるし
0501nobodyさん2009/02/03(火) 15:45:39ID:???
っていうかフリーのＦＷって、全部実行時コンパイルじゃないの？
ＦＷの意味半減だと思うんだが。
0502nobodyさん2009/02/03(火) 15:52:23ID:???
実行時コンパイルかどうかはフレームワークの問題じゃなくて実行環境の問題な気がするが
コンパイルが通るかどうかは別として他のフレームワークでつくってZendに食わせてもいいんだし
0503nobodyさん2009/02/03(火) 16:00:32ID:???
自分の知る限りではPHPだとアプリケーションサーバとして動作する
（メジャーな、実績のある）フレームワークは存在しないし、
mod_phpもmod_{perl,python,ruby}のような常駐型として作られていないので
リクエストごとにインタプリタが動きます。

ただ、それとフレームワークのメリットとは全くもって関係ないです。
Webアプリケーションフレームワークは生産性・保守性の向上のためのもの。
コンパイルのコスト軽減にはAPCやeAccelerator等を使うのが一般的。
0504nobodyさん2009/02/03(火) 16:05:48ID:???
超有名な
ttp://www.zend.co.jp/product/zendplatform.html
これは、ダメですか。そうですか。すごいですね。
0505nobodyさん2009/02/03(火) 16:09:14ID:???
>>503
アプリケーションサーバーかつフレームワークな実装もPHP以外なら存在するのはたしかだけど
それが一緒に提供されるメリットは感じないな。
その話とインタプリタの話がどうしてつながるのかわからないんだけど？
0506nobodyさん2009/02/03(火) 16:11:52ID:???
本当ですね。Zend Platformがフレームワークだったとは寡聞にして知りませんでした。
0507nobodyさん2009/02/03(火) 16:13:50ID:???
>>506
フレームワークなんて言ってないよ。（フレームワークとしての機能もあるけど）
PHPソースをコンパイルした状態で保持して実行するよって話
0508nobodyさん2009/02/03(火) 16:16:37ID:???
>>507
失礼。前半じゃなくて後半へのレスでしたか。
0509nobodyさん2009/02/03(火) 16:19:30ID:???
>>508
どうでもいいや。わけわかんねぇ
0510nobodyさん2009/02/03(火) 17:44:52ID:???
Zend使えばJavaみたいにVMの上で動いてるのと同じような感じなるわけだが、
それじゃ不満なんだろうか。
もちろんZendFrameworkじゃないフレームワークでも問題ないし。
0511nobodyさん2009/02/03(火) 17:50:27ID:???
>>510
Zendって省略しないで。それは会社名でしょ。
Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ
0512nobodyさん2009/02/03(火) 17:50:50ID:???
>>510
金かかるんじゃねーの？
0513nobodyさん2009/02/03(火) 17:58:28ID:???
金かかるよ。それで？
0514nobodyさん2009/02/03(火) 18:06:03ID:???
最近の顧客はWebアプリケーションは無料と思ってるところ多いから、
その手のを請求したらケチつけてくるよ。ライセンスがどうなってるのか
しらねーけど。
0515nobodyさん2009/02/03(火) 18:09:42ID:???
Ａ「ＰＨＰで金が掛かるなんて聞いたことがないね」
Ｂ「フレームワークを使うからなんです。フレームワークを使えば
コードの保守・管理が楽になり色々とメリットが・・・」
Ａ「なるほど。あんたらが楽するためにこっちが金出せと？」
0516nobodyさん2009/02/03(火) 18:13:29ID:???
>>510のはフレームワークじゃなくてサーバじゃないの？
今はなきColdFusionみたいな
0517nobodyさん2009/02/03(火) 18:14:36ID:???
>Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ

なるよ
0518nobodyさん2009/02/03(火) 18:17:03ID:???
>>516
ColdFusionはまだAdobeからFlexと併売されてなかったっけ?
ていうかColdFusionやFlexこそがフレームワーク込みのサーバ製品だよね。
0519nobodyさん2009/02/03(火) 18:29:22ID:???
Flexはともかく、ColdFusionをフレームワークというのは、
PHPそれ自体がフレームワークだ！っていう程度の意味しかないような。
0520nobodyさん2009/02/03(火) 18:33:49ID:???
PHPもアクセラレータ使ったら充分速いよ
だいたいYahooがPHPで動いてるんだから99％のサイトはPHPでおk
0521nobodyさん2009/02/03(火) 18:40:07ID:???
>>517
そのVMって、どういう意味？
0522nobodyさん2009/02/03(火) 18:41:32ID:???
>>514
Webアプリが無料って・・・もしかして、それホームページ？
0523nobodyさん2009/02/03(火) 21:24:57ID:???
>>520
PHPで大規模なサイトも作れますね！スゴイ（・∀・）
ちなみに私のホームページは、なんと！１日１００アクセスぐらいです＞＜

サーバが１台で済むような小規模サイトなら>>503の対策で十分ですよねー？＾＾
>APCやeAccelerator等を使うのが一般的
0524nobodyさん2009/02/03(火) 21:35:53ID:???
http://www.atmarkit.co.jp/news/200809/11/ruby.html
Rubyが遅い理由
遅いのにはいくつか理由がある。
1つは変数に静的型がなく、コンパイル時に型が決まらないことから最適化が効きづらいこと。
しかし、これは動的言語共通だ。
ほかにRubyが遅い理由として前田氏はRubyには「関数がなく、すべてメソッドであること」があるという。
ただ、Rubyは次期開発バージョンのRuby1.9系ではインタープリタをまるごと差し替え、バイトコードを処理するVM を採用したことで多くの最適化を実施し、大幅に高速化しているという。

Pythonも3.0になったことだし、PHPの包囲網は強力だぞ！！！
Perl6.0は(ry
0525nobodyさん2009/02/03(火) 21:40:37ID:???
>>517
VM＝ヴァーチャルマシンのこと。
Javaの仕組みで使われて有名だよ。
http://d.hatena.ne.jp/keyword/VM
0526nobodyさん2009/02/03(火) 23:47:25ID:???
>>520
Yahoo!JapanはあんまりPHPで動いてないぞえ
知恵袋とかはそうだけど昔からある部分はCかJavaだお
0527nobodyさん2009/02/03(火) 23:49:55ID:???
Zend EngineがJavaのVMっぽいってこういうことだな
http://journal.mycom.co.jp/special/2004/php5/004.html
0528nobodyさん2009/02/03(火) 23:57:32ID:???
そ、それ2000年の記事ですけど、PHP5でもそうなの？
0529nobodyさん2009/02/04(水) 00:10:47ID:???
いったんバイトコードにコンパイルしてからVMで実行するのはPHP4でも5でも6でも同じ。
PythonやRuby 1.9でも大ざっぱに言うと同様の仕組みになってる。
あとはVM(エグセキュータ)に手を入れてia32/amd64だけでもJITコンパイラが搭載されるとおもしろいのだけど。
0530nobodyさん2009/02/04(水) 00:16:08ID:???
勉強になりました。
0531nobodyさん2009/02/04(水) 00:17:17ID:???
>>528
どうでもいいけど俺には2004年に見える
0532nobodyさん2009/02/04(水) 00:18:04ID:???
>>528
どうでもいいけど俺にはPHP5の記事に見える
0533nobodyさん2009/02/04(水) 00:37:31ID:???
>>527 >>529
普段意識してなかったけど、PHPってそうなってたんだ！
参考になりました。
0534nobodyさん2009/02/04(水) 00:46:03ID:???
PHPフレームワークの本が揃い、使いやすい状況にある。
ダントツ１位がないのは、それぞれ一長一短だからだろうか？
各FWのユーザーから、「この実装は、このFWではこうやっているよ。メリットはこれこれ。」という報告をよろしく！
FW同士、切磋琢磨していいとこ取りをしよう！

他のLL言語のメリット・デメリットはこちらもどうぞ
http://pc11.2ch.net/test/read.cgi/tech/1215319832
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
0535nobodyさん2009/02/04(水) 00:57:47ID:???
>>534
× こちらもどうぞ
○ こちらでどうぞ

でいいだろｗ
0536nobodyさん2009/02/04(水) 01:07:12ID:???
mod_phpが常駐しないことのメリットは、なんと言ってもデプロイが簡単なことだな。単にファイルを差し替えるだけでいいんだから。
そして、これで十分なスピードがある。
スクリプト言語の処理速度の差なんて、ウェブに限って言えばどうでもいいレベル。速度差はDB部分にかかってるわけで。
0537nobodyさん2009/02/04(水) 01:20:31ID:???
いやそんなことない。
DB部分は殆どキャッシュされてるがアクセスの多いページ、例えばサイトトップとか。
0538nobodyさん2009/02/04(水) 01:22:05ID:???
重箱の隅をつつくようで悪いけど、mod_phpそのものは常駐してますやん。
バイトコードやシンボルテーブルはリクエストの度に初期化・実行・破棄されるけど。
あとは同意。
0539nobodyさん2009/02/04(水) 01:22:45ID:???
はてなとかmixiくらいになるとその差が重要になってきて
だからわざわざめんどいmod_perl使ってるんだろ
0540nobodyさん2009/02/04(水) 01:27:58ID:???
>>537
そういうのはコンテンツキャッシュでどうとでもなる。

mixiは知らんけど、はてなの場合は中の人がPerlを使える・Perlを使いたい、
かといってCGIは遅すぎるのが理由な希ガス。
0541nobodyさん2009/02/04(水) 01:28:55ID:???
mod_perlとは懐かしい響きだ
それは確かに面倒くさそうだ。てか、未だにメンテされてるの？
0542nobodyさん2009/02/04(水) 05:45:22ID:???
常駐するから速いとも一概に言えないじゃん
Rubyなんて常駐させても遅いよ
0543nobodyさん2009/02/04(水) 11:41:49ID:cqQgvAqQ
YahooはRubyだお
0544nobodyさん2009/02/04(水) 11:53:43ID:???
RubyもいいけどPHPもね
ttp://searchblog.yahoo.co.jp/2007/09/php_at_yahoo_japan.html
0545nobodyさん2009/02/04(水) 13:04:10ID:???
世紀末Web土方伝説〜LLの拳〜
例えるなら、
Python（グーグル）…ラオウ
Ruby（楽天）…トキ
PHP（Yahoo）…ケンシロウ
Perl（はてな）…ジャギ
というポジションでしょうか？（・∀・）
0546nobodyさん2009/02/04(水) 13:07:17ID:???
Perlは（現状ではなく）役割的にはリュウケンのような気もするが
0547nobodyさん2009/02/04(水) 15:41:16ID:???
わかりやすく芸人に例えてくれ
0548nobodyさん2009/02/04(水) 15:51:12ID:???
楽天はRuby殆ど使ってないぞ
99%がPHPとJava
研究してるけど全く表に出てこないｗ
0549nobodyさん2009/02/04(水) 16:13:35ID:???
わかりやすく実写版ドラゴンボールに例えてくれ
0550nobodyさん2009/02/04(水) 16:18:51ID:???
よけいわかりにくいわｗ
0551nobodyさん2009/02/04(水) 16:20:06ID:???
>>545
Rubyはトキだと思ってたらアミバだったぜ！みたいな感じか？
PHPがケンシロウってのはｗ バットかアインくらいで妥協しておけ

ECMAScript群はきっと南斗聖拳
0552nobodyさん2009/02/04(水) 16:57:49ID:???
Googleも実はPythonあんまり使ってないんだよなｗ
サービスの殆どはCとJavaで、Pythonはヘルプ機能とか軽いところしか使われてない。
0553nobodyさん2009/02/04(水) 17:28:36ID:???
Rubyはフリーザって感じだな。
出た当初は桁外れに強くて
今でも強いイメージがあるんだけど、
実はそんなでも無い？

PHPはクリリン？ あまり強いわけじゃないが
登場回数は多い。でもよくよく考えると地球人最強？

えーと、クリリンって最後の方ではフリーザより強くなったんだっけ？
0554nobodyさん2009/02/04(水) 17:36:40ID:???
ドラゴンボール戦闘力の軌跡 なんてのがあるんだなｗ
フリーザ弱っ。天津飯つえー。

http://schiphol.2ch.net/test/read.cgi/retro/1208239286/676
フリーザ；1億2000万
ヤムチャ：3億5000万
クリリン：12億6500万
天津飯：60億4500万
公式戦闘力（｢ドラゴンボール戦闘力の軌跡｣集英社より)

0555nobodyさん2009/02/04(水) 17:37:36ID:???
うん。やけくそなインフレがよくわかる

で、ここはいったい何のスレなんだｗｗｗ
0556nobodyさん2009/02/04(水) 17:41:26ID:???
ポタラ・フュージョン公式によると、もっとすごいよ。
ttp://www.geocities.jp/poposu01/katari153.html
0557nobodyさん2009/02/04(水) 17:48:28ID:???
ヤムチャなめんなよおまいら
0558nobodyさん2009/02/04(水) 18:00:45ID:???
http://www.youtube.com/watch?v=2kCo5-7sys4&hl=ja
0559nobodyさん2009/02/04(水) 23:39:35ID:???
新しい言語どんどんできたけど
結局今でもC、Java、Perl、PHPって感じだよね
0560nobodyさん2009/02/04(水) 23:45:32ID:???
ＣとPerlとはすごいよな
JavaとPHPはウェブありきで作られた面もあるからすごくて当然だけど
0561nobodyさん2009/02/05(木) 01:18:17ID:???
糞言語ばっかりだな
0562nobodyさん2009/02/05(木) 01:57:20ID:???
JavaがWebに使われるようになったの結構後だぞ
J2EEとか最初無かったから
0563nobodyさん2009/02/05(木) 09:11:17ID:???
>>562
HotJava......
0564nobodyさん2009/02/05(木) 13:50:05ID:???
Applet...
0565nobodyさん2009/02/05(木) 18:46:36ID:???
>>562
昔を知らないんだね。Appletとかちょっと書けると結構金になったもんだぞ。
0566nobodyさん2009/02/05(木) 22:25:45ID:???
>>563
糞久しぶりに聞いたｗ
0567nobodyさん2009/02/05(木) 23:19:28ID:???
C、Java、Perl、PHPの話してるんだからAppletとかそう言う問題じゃないだろうに
Flashとかとの比較になるだろそういうのは
もともとJavaはWebでApplet作るために設計された言語じゃないって事でしょ
0568nobodyさん2009/02/05(木) 23:27:54ID:???
もっともなんだが、それ以前にずーっとスレ違(ry
0569nobodyさん2009/02/06(金) 20:36:37ID:???
Javaって元々はHOTJava系で
売ろうとしてたんでしょ？
0570nobodyさん2009/02/06(金) 20:55:40ID:???
Javaはもともとは組込用のC++の代替言語として開発された
そのうちにモザイクが発表されてこれは凄いって事になって
これからはWebだなってことでHotJavaもセットになって発表された
0571nobodyさん2009/02/07(土) 08:38:14ID:???
Javaのホワイトペーパー第一版には、言語としての素晴らしさと、
中間ファイル出すから何でも動くぜーっていうのが中心として
書かれてたと思う。HotJavaはちょっと後じゃなかったっけ？
0572nobodyさん2009/02/07(土) 09:15:33ID:???
てかJavaがweb前提ってどっから出てきた発想なんだろ
0573nobodyさん2009/02/07(土) 10:10:14ID:???
>>572
どっかの勘違い君じゃない？

例のホワイトペーパーはそんなこと１つも書いてないよ。
ホワイトペーパーってのはリリース前に出すやつね。
0574nobodyさん2009/02/10(火) 00:39:54ID:???
んっとにフレームワークの話題ってないのなｗ
とりあえず、おまいらHTML5についてどう思うよ。しょうもない言語論争してるより、切実な問題じゃないか？

俺は個人的には、フォームのクライアントヴァリデート機能に期待してるんだ。
Ajaxうんちゃらかんちゃらの工数がちょっとでも省けるんなら大歓迎したい。
0575nobodyさん2009/02/10(火) 05:46:16ID:???
解説サイトの受け売りそのままですね
0576nobodyさん2009/02/10(火) 08:54:16ID:???
受け売りというか、それ以上にありがたいというか影響の大きい新機軸なんてあったかな？
0577nobodyさん2009/02/10(火) 13:37:16ID:???
>>574
クライアントヴァリデートってオマケだろ？
本当に値が正かはサーバーで見なきゃいけない。
工数省けるってのはクライアントヴァリデートのだよね？
結局サーバーサイドのヴァリデーションは面倒なままだ。
PEARで何かあるんかも知れんが。
0578nobodyさん2009/02/10(火) 21:19:58ID:???
かったりーのでクライアントヴァリデートなしで済ませる僕ってダメなやつですか？
0579nobodyさん2009/02/11(水) 00:37:33ID:???
>577
HTMLを食わせると、それと同じ基準でバリデートしてくれるライブラリが出るだろ、きっと。
最悪でも自前で実装すれば、HTML5でサイトを作っている限りは使いまわせる。
0580nobodyさん2009/02/11(水) 07:55:43ID:???
>>578
別にいいんじゃない？
>>579
楽観的だなあ。ヴァリデートの難しさは分かってるよね？
Softbankの携帯電話のみ、とか、VISAのカードでチェックデジットが
間違ってない、とか複雑なのあるし。callbackにすりゃいいんだろうけど。
あと導線というか実装がみんなまちまちなので汎用的ライブラリを作るのは
結構大変だと思われ。現存のフォームヴァリデータの実装を見てみるといい。
ケチをつけたくなるものがほとんどだ。
0581nobodyさん2009/02/11(水) 08:04:54ID:???
むしろ逆かな
サーバアプリ側のヴァリデート設定をもとにフォームのHTMLを吐き出すライブラリができる感じ？
どのみちサーバ側でのヴァリデートはしなきゃいけないんだから。
ユーザ側の入力を少しでもしやすくする部分で手が抜けるっていうのがメリットだと思う。
0582nobodyさん2009/02/11(水) 13:18:02ID:???
>581
>サーバアプリ側のヴァリデート設定をもとにフォームのHTMLを吐き出すライブラリができる
これ、結構色んなフレームワークで既に実装されているんだが。
0583nobodyさん2009/02/11(水) 15:56:29ID:???
どっちにしても下位互換しなきゃいけないんだから
作業が減るのは相当後の話だろ
0584nobodyさん2009/02/11(水) 17:48:23ID:???
クライアントヴァリデートなんてかなりどうでもいいな
そんなに付加価値ないだろ
0585nobodyさん2009/02/11(水) 20:09:31ID:???
なんでお前らヴァリヴァリ言ってんの？
0586nobodyさん2009/02/12(木) 23:00:20ID:ANumrANN
ヴァーリトゥードゥ
0587nobodyさん2009/02/12(木) 23:04:11ID:???
ヴァリヴァリヴァリヴァリヴァリタンク♪
■ このスレッドは過去ログ倉庫に格納されています