で、肝心のフレームワークなんだけど
結局今熱いのってなんなの？

いっぱいありすぎていまいちこれっていう特徴あるやつ
ないんだよな～

最近ちょっとさわってみようかな～って思ってるのあるんだけど
誰かいじったことある人いたら所感教えて～

PAJAJ
http://pajaj.sourceforge.net/

xFrameworkPX
http://px.xframework.net/

PRADOみたいなイベントドリブンなのはどうなんだ

ちいたんでいい

やっぱり落ち担当w

もうちょっとふくらませてからｗ

いやらしい

大規模向けのFWはどれ?

ちいたん

出ると思ったｗ

ちいたん以外で

Symfony
Cake

あれ?遅いとか叩いてなかったっけか?
なぜ大規模向けと?

軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい
(重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい

とはいえ、フレームワークが案件に合う合わないもあるので、
どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。
逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。
重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。

あと、大規模=多人数と勝手に解釈したけど。

数年がかりの本当に大規模なものなら
逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある

>>564
開発期間が数年？PHPでそんな案件はほとんど無いけど。

あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように
古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。
やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな？

１年未満じゃ大規模とは言えないし

webアプリで開発に何年もかかってちゃビジネスになんね。

PHPはインタフェース部分を担当するに過ぎないから
プロジェクト全体で数年っていうのはあるよ
複数サイトを作るような事業でも共通フレームワークを作成することはあるし

単純にスピードを比較したものがよく出るけど、あまり意味無いよな。
しかも素の状態に近いベンチとか。

もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。
色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。
だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。

単純なスピード比較がよく話題が出るから、疑問に感じていた。

何が言いたいのかさっぱりだ
帰れ

必要な機能に一番近いものを使えばいいねん
多すぎず少なすぎず

それがベストだけどちょうどいいFWってそうはない気も。
まぁ、一番近いものを選べばいいが

フレームワークなんて多機能な奴はほとんど一緒だけどね
パフォーマンスくらいしか差が無い気が

大規模の意味は100万ユーザ以上が使うというアクセス数の意味で
開発の工数ではなかったけどためになった

アクセス数という意味では軽量かどうかが非常に重要と思われ
サーバの台数などのメンテナンス代が高くつくから

とはいえ重量級のものを使ってあとからプロファイリングして
リファクタリングなりすればいいような気もしてきた

必要な機能なら実装しなきゃならないんだから
効率的な実装になってるならいいんだけどね
cakeは実装が酷いよ

cakeはインターフェイスが全てだからじゃん
その辺までRailsを踏襲していると言えばそうかも

ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。
でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。
PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。
GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。

アクセス数の多さはフレームワークのスレで大規模にあたらないだろ
１ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか？
俺は普通コード量とか機能数だと思うけど

Googleは独自のフレームワーク作ってそうだけどね
てか絶対作ってる
他にも大企業は手の込んだ事やってそうだけどなあ

ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
これをひたすら繰り返して巨大化するだけ。

機能によっては違うこともあるんじゃないか。
ユーザからのデータを何かしら加工するとか、
なにか特別なアルゴリズムでデータを収集して、
それを提供するとか。

ＷＥＢＡＰＩの提供に際する共通機能とか
自動的にＤＢを保守してくれたりＨＤＤ壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか
（ＰＨＰコード内の接続先ＤＢサーバＩＰが動的に変わるって事ね）

思いつきで書いた

ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。

>>580
> ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
> mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
> ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
> これをひたすら繰り返して巨大化するだけ。

それはウェブアプリだからではなく、SNSやオンラインショップという
システムが、そうなっているってだけだろ。

たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。

それにウェブじゃないシステムが何をしているかというと、
結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。

大したことやってないのにフレームワークは重いから使わない(ｷﾘｯ
なんて言っちゃってる企業とか腐るほどあるからなぁ

>>585
インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

>>586
その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？

フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。
つーかＦＷに組み込まれてるし

何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい
やり方を検討するのが面倒くさいことだけの事が多いと思う。

論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
会社があった。
なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
全力でこけた。いろいろ間違ってる。

12のphp最適化テクニックとか、一時期ブログに出回ったけど、
そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
よくあったよね。
むしろコードが読みにくくなったり、書きにくくなったりと、
その時間のほうがもったいないとか。

大手でphp使ってサービスやってるといえばYahooなんだけど
たとえば、↓
http://www.sooey.com/journal/2007/05/26/648/
symponyだって。
でもサービスによって違いはあって
http://wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128
↑これなんてPHP?

論理削除自体間抜け

論理削除自体が間抜け？
方法がフラグってとこが間抜けってなら少しはわかる気もするが。

論理削除は必要だろ。

スレチだけど論理削除ってどういう指定にすればやりやすいですかね。
active enum('Y','N')か、status = 0 なら削除とか？

>>593
わかんね。
フラグじゃなくてカウンタにするってこと？

大規模向けではなく一番スケールアウトしやすいFWは?

スケールアウト考えたらモデルは自分で書かないときつくね？

ちｒｙ

>>595
deleted（datetime）がnullかどうか