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

1 名前：nobodyさん mailto:sage [2008/08/24(日) 21:43:37 ID:???] 前スレ pc11.2ch.net/test/read.cgi/php/1202521438/ 501 名前：nobodyさん mailto:sage [2008/11/08(土) 17:38:16 ID:???] >>499 ApacheやらLinuxやら使ってて「高くついた」って感じたことはないなあ。 むしろ安い労働力まで付いてきて、お得感しかないのが大多数では？ｗ もちろん、大規模に「ガッツリ」儲ける分野では違うんだろうけど。 502 名前：nobodyさん mailto:sage [2008/11/08(土) 18:55:54 ID:???] 中・小規模向けのフレームワークって何が良い？ cakeはどうもパフォーマンスが悪すぎて嫌なんだよねえ 503 名前：nobodyさん mailto:sage [2008/11/08(土) 21:49:38 ID:???] 中・小ならEthnaでいいんじゃないの。 CIという手もあるが。 504 名前：nobodyさん mailto:sage [2008/11/08(土) 23:30:51 ID:???] ご冗談でしょう 505 名前：nobodyさん mailto:sage [2008/11/09(日) 05:48:00 ID:???] Ethnaとか、未だに選択肢に残ってるのかな？ 仕事で昔触ったときに、いろいろドン引きした記憶があるんだが。 アクションを準備していないURL指定すると「全ファイル」のrequireを し始めてプチDOSアタックになってしまう自前オートロード（笑）とかｗ 506 名前：nobodyさん mailto:sage [2008/11/09(日) 09:19:25 ID:???] 大規模ならCI or ZFのチョイスってことでFA? 507 名前：nobodyさん mailto:sage [2008/11/09(日) 11:56:58 ID:???] CIってPHP4にも対応しててコードに無理が出てるみたいな話も聞くんだけど 大規模で使えるようなものなの？ 小規模にしてもcakeとどっちが楽なんだろう 508 名前：nobodyさん mailto:sage [2008/11/09(日) 13:41:32 ID:???] ドッチかと言われればcakeだろ でもcakeもイマイチなのはよくわかる 509 名前：nobodyさん mailto:sage [2008/11/09(日) 14:55:46 ID:???] ciで大規模はきつい そういうふうには作られていない 510 名前：nobodyさん mailto:sage [2008/11/09(日) 15:03:14 ID:???] だよね 低機能だし だからこそある程度自分達で実装しやすい面もあるから 逆に大規模での需要はありうるけど かといって小規模でもCIはどうなんだろう 軽量なのは良いんだけど 511 名前：nobodyさん mailto:sage [2008/11/09(日) 16:23:48 ID:???] >>496 儲けなくても、一度つぶれた会社が オプソで蘇ってうまくいってるケースはある 512 名前：nobodyさん mailto:sage [2008/11/09(日) 16:25:12 ID:???] オープンソースは技術的には最良の手段だよ 利益に繋げられるビジネスモデルを考えられるか、実行出来るかが問題 513 名前：nobodyさん mailto:sage [2008/11/09(日) 19:20:35 ID:???] そこが最大の問題だと思う。 ぶっちゃけメシ食えなきゃしょうがない 514 名前：nobodyさん mailto:sage [2008/11/09(日) 19:27:31 ID:???] オープンソースにかかわってるエンジニアがこれほどたくさんいるという事実は 形は違えど、オープンソースで稼げるってことの裏返しじゃないかと思うのは甘い？ 515 名前：nobodyさん mailto:sage [2008/11/09(日) 19:29:10 ID:???] でも市場取らないとどうにもならない面もある もしオープンソースな製品が何一つ無い分野があったら、オープンソースな製品を立ち上げる事で その分野で一気に市場を奪える可能性がある 516 名前：nobodyさん mailto:sage [2008/11/09(日) 20:01:09 ID:???] >>513 gimpにしてもblenderにしても、オプソで生活してる開発者はいくらでもいる。 お前みたいな無知が日本には多いから、ボランティアみたいに見られるのは しょうがないと思うけど。 517 名前：nobodyさん mailto:sage [2008/11/09(日) 23:36:37 ID:???] 日本ではあまり話を聞かない気がするけど・・ 518 名前：nobodyさん mailto:sage [2008/11/10(月) 01:02:25 ID:???] しかもFWの話で画像系とか3D系はちょっと実感わかないかも 519 名前：nobodyさん mailto:sage [2008/11/10(月) 10:55:17 ID:???] 携帯サイト向けの機能も持ったフレームワークってあるの？ 520 名前：nobodyさん mailto:sage [2008/11/10(月) 11:15:09 ID:???] DeNAのMobaSiFみたいなものってPHPでは聞いたことないなぁ 521 名前：nobodyさん mailto:sage [2008/11/10(月) 15:28:02 ID:???] 携帯サイトって出力を携帯むけにするだけじゃないの？ なんか特別に機能必要け？ 522 名前：nobodyさん mailto:sage [2008/11/10(月) 15:29:05 ID:???] セッションとかＰＣと同じじゃ動かないんだよ そのほか端末識別番号の取得やらいろいろある 523 名前：nobodyさん mailto:sage [2008/11/10(月) 16:04:14 ID:???] そうそう。まともにサービスを開発したことがあったら、 携帯対応ほど煩雑なものはないと思えるよ。 キャリアと機種によって全然違う挙動するからね。 セッションもレイアウトも画像も。ま、小さいところでは絵文字とか。 524 名前：nobodyさん mailto:sage [2008/11/10(月) 16:05:21 ID:???] 機種によって動かなかったりするからテストもコーディングも面倒 525 名前：nobodyさん mailto:sage [2008/11/10(月) 16:55:03 ID:???] KEMPは? KEMP ke-tai.org ke-tai.org/index.php?KEMP 526 名前：nobodyさん mailto:sage [2008/11/10(月) 17:07:31 ID:???] それはＰＣ携帯両用サイトじゃなく携帯サイト作成のためのフレームワークっぽい 527 名前：nobodyさん mailto:sage [2008/11/10(月) 17:09:27 ID:???] 両方できるものが欲しいのか すまそ というより両方やろうとしている時点で間違っていると思う 小規模、小機能ならありえるけど 528 名前：nobodyさん mailto:sage [2008/11/10(月) 17:15:23 ID:???] 両対応サイトであったとしても別物と考えよ 529 名前：nobodyさん mailto:sage [2008/11/10(月) 17:24:25 ID:???] KEMPとやらはPHP5で動かない 携帯とＰＣで別フレームワークを使うとしたら 共通の機能を変更した場合どうすんの？ 530 名前：nobodyさん mailto:sage [2008/11/10(月) 18:47:01 ID:???] セッション動かないのはクッキーがないからだろ？ 単にget引数方式にしたらいいだけじゃないの？ 531 名前：nobodyさん mailto:sage [2008/11/10(月) 19:02:38 ID:???] >>529 当然それぞれ変更する 532 名前：nobodyさん mailto:sage [2008/11/10(月) 19:04:27 ID:???] >>530 リファラーを送っちまう機種でそんなことしたら、セッションハイジャックされるべ 533 名前：nobodyさん mailto:sage [2008/11/10(月) 19:05:00 ID:???] 実際携帯サイト向けのソリューションはいくつかあるんだけど 国内では情報少ないね 534 名前：nobodyさん mailto:sage [2008/11/10(月) 19:10:08 ID:???] >>530 POSTフォームだとACTIONに指定したパラメータを送らないっていう機種もあるしな そういう機種ではPOSTフォームでセッションを維持できない。 535 名前：nobodyさん mailto:sage [2008/11/10(月) 19:23:29 ID:???] 結局機種判別をして処理振り分けるような事をする必要があるんだよね 536 名前：nobodyさん mailto:sage [2008/11/10(月) 19:35:22 ID:???] ttp://gihyo.jp/dev/feature/01/mobasif/0001 ここに書いてあるのでもまだまだ序の口だな。間違ってるとこもあるし。 いまんとこ、オープンソースだとMobaSiF最強じゃないかな。 537 名前：nobodyさん mailto:sage [2008/11/10(月) 19:47:32 ID:???] 携帯の文字コードは、そろそろUTF-8統一でいいんでしょうか？ 538 名前：nobodyさん mailto:sage [2008/11/10(月) 19:48:52 ID:???] 結局そういうのは自分とこで作るしかないんじゃね 539 名前：nobodyさん mailto:sage [2008/11/10(月) 19:54:03 ID:???] >>536 Perlじゃん >>538 別に汎用的な機能だから広く使われるものが無い現状が異常 携帯関連開発の低レベル差だと思う 540 名前：nobodyさん mailto:sage [2008/11/10(月) 20:24:13 ID:???] うん。perlなんだけどさ。 スレチ承知であえて、携帯だけはPerlでって思えるぐらいの完成度だと思う。 541 名前：nobodyさん mailto:sage [2008/11/10(月) 21:08:55 ID:???] だいたい携帯は規格が無さ杉なんだよ ＯＳも別々のが乗ってるし エンドユーザーにとってメリットがある事じゃないんだが、不経済だなあ 542 名前：nobodyさん mailto:sage [2008/11/10(月) 22:50:10 ID:???] >>541 それと、各社・各世代仕様のまとめ情報が少なすぎる。 ググれば出てきそうなクッキー仕様や対応文字コード等の情報が、ほとんど無い。 会社で仕事なんかでは資料を作るんだから、暇な自営業者あたりが自分メモで 作ってても良さそうなもんなんだが。 フレームワーク辺りと違って、いじって面白くないのと、商売上公開したくないって のと、その他もろもろ理由はあるんだろうけど。 543 名前：nobodyさん mailto:sage [2008/11/10(月) 22:58:35 ID:???] Androidに期待 544 名前：nobodyさん mailto:sage [2008/11/10(月) 23:09:02 ID:???] 携帯はフルブラウザで見る以外は廃止にすべき 545 名前：nobodyさん mailto:sage [2008/11/10(月) 23:39:13 ID:???] MobaSiF読んでPHP用携帯FWを作るプロジェクトとか 546 名前：nobodyさん mailto:sage [2008/11/11(火) 00:37:30 ID:???] そもそも初期のｉモードなんかの仕様がダメ杉 547 名前：nobodyさん mailto:sage [2008/11/11(火) 02:17:34 ID:???] >>545 PerlのコードをPHPのコードに変換するジェネレーターがあれば、簡単に移植できるかな？ 548 名前：nobodyさん mailto:sage [2008/11/11(火) 02:22:07 ID:???] oshiete1.goo.ne.jp/qa863429.html Perlコードを、自動的にPHPコードに変換してくれる、そんな「ドラえもん」のようなプログラムがありましたら教えて下さい！ 無いですねえ。 www.cs.wcupa.edu/~rkline/perl2php/ Perl/Php Translation 549 名前：nobodyさん mailto:sage [2008/11/11(火) 07:51:48 ID:???] そういやperlで思い出したけど PHP on parrotて進んでるんでしょうか？ 550 名前：nobodyさん mailto:sage [2008/11/13(木) 08:51:01 ID:???] >>540 Perlの事情あまりしらはい。ﾗｲﾌﾞﾗﾘのどういうとこが携帯向き? 551 名前：nobodyさん [2008/11/13(木) 10:31:16 ID:kdvrTOAA] で、肝心のフレームワークなんだけど 結局今熱いのってなんなの？ いっぱいありすぎていまいちこれっていう特徴あるやつ ないんだよな〜 最近ちょっとさわってみようかな〜って思ってるのあるんだけど 誰かいじったことある人いたら所感教えて〜 PAJAJ ttp://pajaj.sourceforge.net/ xFrameworkPX ttp://px.xframework.net/ 552 名前：nobodyさん mailto:sage [2008/11/13(木) 14:00:08 ID:???] PRADOみたいなイベントドリブンなのはどうなんだ 553 名前：nobodyさん mailto:sage [2008/11/13(木) 16:16:39 ID:???] ちいたんでいい 554 名前：nobodyさん mailto:sage [2008/11/13(木) 23:25:55 ID:???] やっぱり落ち担当w 555 名前：nobodyさん mailto:sage [2008/11/13(木) 23:27:41 ID:???] もうちょっとふくらませてからｗ 556 名前：nobodyさん mailto:sage [2008/11/13(木) 23:41:23 ID:???] いやらしい 557 名前：nobodyさん mailto:sage [2008/11/14(金) 13:45:00 ID:???] 大規模向けのFWはどれ? 558 名前：nobodyさん mailto:sage [2008/11/14(金) 13:52:53 ID:???] ちいたん 559 名前：nobodyさん mailto:sage [2008/11/14(金) 13:53:13 ID:???] 出ると思ったｗ 560 名前：nobodyさん mailto:sage [2008/11/14(金) 14:12:00 ID:???] ちいたん以外で 561 名前：nobodyさん mailto:sage [2008/11/14(金) 14:31:47 ID:???] Symfony Cake 562 名前：nobodyさん mailto:sage [2008/11/14(金) 14:34:00 ID:???] あれ?遅いとか叩いてなかったっけか? なぜ大規模向けと? 563 名前：nobodyさん mailto:sage [2008/11/14(金) 14:42:11 ID:???] 軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい (重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい とはいえ、フレームワークが案件に合う合わないもあるので、 どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。 逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。 重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。 あと、大規模=多人数と勝手に解釈したけど。 564 名前：nobodyさん mailto:sage [2008/11/14(金) 14:50:52 ID:???] 数年がかりの本当に大規模なものなら 逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある 565 名前：nobodyさん mailto:sage [2008/11/14(金) 15:31:36 ID:???] >>564 開発期間が数年？PHPでそんな案件はほとんど無いけど。 あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように 古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。 やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな？ 566 名前：nobodyさん mailto:sage [2008/11/14(金) 16:00:34 ID:???] １年未満じゃ大規模とは言えないし 567 名前：nobodyさん mailto:sage [2008/11/14(金) 16:19:50 ID:???] webアプリで開発に何年もかかってちゃビジネスになんね。 568 名前：nobodyさん mailto:sage [2008/11/14(金) 16:22:17 ID:???] PHPはインタフェース部分を担当するに過ぎないから プロジェクト全体で数年っていうのはあるよ 複数サイトを作るような事業でも共通フレームワークを作成することはあるし 569 名前：nobodyさん mailto:sage [2008/11/14(金) 16:31:35 ID:???] 単純にスピードを比較したものがよく出るけど、あまり意味無いよな。 しかも素の状態に近いベンチとか。 もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。 色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。 だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。 単純なスピード比較がよく話題が出るから、疑問に感じていた。 570 名前：nobodyさん mailto:sage [2008/11/14(金) 16:52:52 ID:???] 何が言いたいのかさっぱりだ 帰れ 571 名前：nobodyさん mailto:sage [2008/11/14(金) 22:44:45 ID:???] 必要な機能に一番近いものを使えばいいねん 多すぎず少なすぎず 572 名前：nobodyさん mailto:sage [2008/11/14(金) 23:35:14 ID:???] それがベストだけどちょうどいいFWってそうはない気も。 まぁ、一番近いものを選べばいいが 573 名前：nobodyさん mailto:sage [2008/11/14(金) 23:36:59 ID:???] フレームワークなんて多機能な奴はほとんど一緒だけどね パフォーマンスくらいしか差が無い気が 574 名前：nobodyさん mailto:sage [2008/11/14(金) 23:49:38 ID:???] 大規模の意味は100万ユーザ以上が使うというアクセス数の意味で 開発の工数ではなかったけどためになった アクセス数という意味では軽量かどうかが非常に重要と思われ サーバの台数などのメンテナンス代が高くつくから とはいえ重量級のものを使ってあとからプロファイリングして リファクタリングなりすればいいような気もしてきた 575 名前：nobodyさん mailto:sage [2008/11/14(金) 23:58:04 ID:???] 必要な機能なら実装しなきゃならないんだから 効率的な実装になってるならいいんだけどね cakeは実装が酷いよ 576 名前：nobodyさん mailto:sage [2008/11/14(金) 23:59:29 ID:???] cakeはインターフェイスが全てだからじゃん その辺までRailsを踏襲していると言えばそうかも 577 名前：nobodyさん mailto:sage [2008/11/15(土) 02:26:07 ID:???] ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。 でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。 PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。 GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。 578 名前：nobodyさん mailto:sage [2008/11/15(土) 02:37:10 ID:???] アクセス数の多さはフレームワークのスレで大規模にあたらないだろ １ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか？ 俺は普通コード量とか機能数だと思うけど 579 名前：nobodyさん mailto:sage [2008/11/15(土) 02:38:10 ID:???] Googleは独自のフレームワーク作ってそうだけどね てか絶対作ってる 他にも大企業は手の込んだ事やってそうだけどなあ 580 名前：nobodyさん mailto:sage [2008/11/15(土) 02:50:13 ID:???] ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。 mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。 ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。 これをひたすら繰り返して巨大化するだけ。 581 名前：nobodyさん mailto:sage [2008/11/15(土) 02:53:39 ID:???] 機能によっては違うこともあるんじゃないか。 ユーザからのデータを何かしら加工するとか、 なにか特別なアルゴリズムでデータを収集して、 それを提供するとか。 582 名前：nobodyさん mailto:sage [2008/11/15(土) 03:02:01 ID:???] ＷＥＢＡＰＩの提供に際する共通機能とか 自動的にＤＢを保守してくれたりＨＤＤ壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか （ＰＨＰコード内の接続先ＤＢサーバＩＰが動的に変わるって事ね） 思いつきで書いた 583 名前：nobodyさん mailto:sage [2008/11/15(土) 04:39:48 ID:???] ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。 584 名前：nobodyさん mailto:sage [2008/11/15(土) 05:03:15 ID:???] >>580 > ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。 > mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。 > ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。 > これをひたすら繰り返して巨大化するだけ。 それはウェブアプリだからではなく、SNSやオンラインショップという システムが、そうなっているってだけだろ。 たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。 585 名前：nobodyさん mailto:sage [2008/11/15(土) 05:05:22 ID:???] それにウェブじゃないシステムが何をしているかというと、 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。 586 名前：nobodyさん mailto:sage [2008/11/15(土) 05:47:54 ID:???] 大したことやってないのにフレームワークは重いから使わない(ｷﾘｯ なんて言っちゃってる企業とか腐るほどあるからなぁ 587 名前：nobodyさん mailto:sage [2008/11/15(土) 09:41:57 ID:???] >>585 インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。 ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。 >>586 その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？ 588 名前：nobodyさん mailto:sage [2008/11/15(土) 13:00:48 ID:???] フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。 つーかＦＷに組み込まれてるし 589 名前：nobodyさん mailto:sage [2008/11/15(土) 13:15:36 ID:???] 何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい やり方を検討するのが面倒くさいことだけの事が多いと思う。 論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。 あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている 会社があった。 なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。 全力でこけた。いろいろ間違ってる。 590 名前：nobodyさん mailto:sage [2008/11/15(土) 14:11:03 ID:???] 12のphp最適化テクニックとか、一時期ブログに出回ったけど、 そのテクニックが使われるタイミングを考えると、誤差でしかないとか、 よくあったよね。 むしろコードが読みにくくなったり、書きにくくなったりと、 その時間のほうがもったいないとか。 591 名前：nobodyさん mailto:sage [2008/11/15(土) 14:39:00 ID:???] 大手でphp使ってサービスやってるといえばYahooなんだけど たとえば、↓ www.sooey.com/journal/2007/05/26/648/ symponyだって。 でもサービスによって違いはあって wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128 ↑これなんてPHP? 592 名前：nobodyさん mailto:sage [2008/11/15(土) 14:39:25 ID:???] 論理削除自体間抜け 593 名前：nobodyさん mailto:sage [2008/11/15(土) 14:54:51 ID:???] 論理削除自体が間抜け？ 方法がフラグってとこが間抜けってなら少しはわかる気もするが。 594 名前：nobodyさん mailto:sage [2008/11/15(土) 14:55:03 ID:???] 論理削除は必要だろ。 595 名前：nobodyさん mailto:sage [2008/11/15(土) 15:09:50 ID:???] スレチだけど論理削除ってどういう指定にすればやりやすいですかね。 active enum('Y','N')か、status = 0 なら削除とか？ 596 名前：nobodyさん mailto:sage [2008/11/15(土) 15:11:46 ID:???] >>593 わかんね。 フラグじゃなくてカウンタにするってこと？ 597 名前：nobodyさん mailto:sage [2008/11/15(土) 16:06:02 ID:???] 大規模向けではなく一番スケールアウトしやすいFWは? 598 名前：nobodyさん mailto:sage [2008/11/15(土) 16:34:55 ID:???] スケールアウト考えたらモデルは自分で書かないときつくね？ 599 名前：nobodyさん mailto:sage [2008/11/15(土) 16:57:52 ID:???] ちｒｙ 600 名前：nobodyさん mailto:sage [2008/11/15(土) 17:24:52 ID:???] >>595 deleted（datetime）がnullかどうか

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef